Operational Meeting

Neil

These were accepted.

Actions completed:

• "om file configure" issues (on mp-unit list)
• Move from FH now almost done

Actions added:

• mp-unit to add profile resources for machine criticality
• inf-unit to document bonding issues
• Alastair to follow up on "home directories" discussion
• services-unit to follow up on AFS discussion
• Alison (documentation project) to look at AFS documentation ideas

Report from Computing Executive Group

Reports from units.

• Infrastructure.

  4. Bonded network interfaces

     inf-unit will document the issues with bonded interfaces somewhere.

• Managed Platform.

• Research and Teaching.

  • It's hoped that the removal of /platspec can be completed by the end of March. Iain will be issuing a status update soon.

• Services.

  1. Disk performance issues

     Alastair noted that he hadn't tested AFS performance with RAID 10 arrays, just VMs. We should probably also get hold of some SSDs for testing.

  2. Move to the new openafs component

     Clients are now using the new component too. There'll be a week or two of "stopped component" reports while this shakes down.

  3. Problems with the groups web server

     Services-unit will be looking at ways to throttle excessive web server traffic.

  • It was noted that there's now just one remaining "live" web server (groups) at Forrest Hill, which is waiting for some AIAI experiments to complete before it can be moved.

• User Support.

  • RT has moved to a new server, "venom" in Appleton Tower.

Topics for discussion

• Issues relating to home directories on DICE desktops

  Alastair raised the question of local home directories on desktop machines: if we did provide these, what issues would arise? Considerable discussion ensued, with the following points made (in no particular order):

  • It's good to be flexible if we can. If we can't, we should be clear as to why. Things may be possible but not sensible.
  • These should be purely local home directories. Allowing cross-mounting would be a support nightmare: the service would be much less robust, as a result of interdependencies, and there would be the expectation that desktops would have to be always up for use from elsewhere.
  • We're trying to get rid of amd, which is at the moment required for mixed local and network home directories to work. Could autofs substitute?
  • Whatever we do has to be manageable within our existing resources. If we have to put development effort in, something else won't be done.
  • How much had the AFS problems of a couple of months ago affected perceptions? Would it not be a better use of resources to try to make the existing AFS service more robust?
  • ANC had local home directories in the past. They now like the advantages of AFS, and have no wish to change back.
  • At the moment we could only offer either /disk/scratch/ or a local home directory, due to the way the fstab component works. The former is quite heavily used.
  • AFS's disconnected mode is working well in 1.5.x, and should be in 1.6 in due course. This might offer a better solution for some users, though there would still be some user-education issues to sort out.
  • How would backups work? Automatically back up the local home directories, or expect users to copy their important work elsewhere? What happens when (not if!) something goes wrong? And who pays for the data recovery?
  • Could we have "minimal" local home directories as a way to work around performance issues (e.g. firefox)? Is this a sensible thing to want to do in the first place? We should bear in mind the "platspec" experience.
  • Could we auto-create such minimal directories when network directories were unavailable? How would content be reconciled afterwards?
  • How would this impact on machine upgrades? Machines would be unavailable for much longer, as data got copied around. Repartitioning would be harder.
  • Whatever we do should be as a result of clear costing of the options and with an eye on the likely takeup. There would have to be a project (and perhaps a meta-project), of course.
  • If people are to be able to choose local home directories, the implications should be made totally clear to them and they should agree explicitly.

  Alastair will think about where to go from here.

• AFS issues

  Simon had noted three AFS areas which could be improved upon, as a result of his "CO clinic" discussions:

  1. man-pages are not particularly helpful. Indeed, they really only make sense if you already know what they're telling you. They're for reference purposes, in other words, rather than tutorial.

     Other documentation is available, but some of it is a bit out of date. Perhaps we should put some effort into improving it and submitting it back upstream, as we might expect to benefit from this in the longer term?

     Adopting AFS has meant that kerberos is much more visible now than it was in the past, and there's a whole new vocabulary and set of concepts for users to learn. Workshops for users were suggested, and thought to be a very good idea. They could be short and concentrate on specific issues, such as "what's a principal", ACLs and so on. Presentation material could be useful as user documentation, and we might even record them for future reference.

     The documentation project will pick this up.

  2. Long-running jobs still cause issues for users.

     The idea of packaging up the necessary commands and checks in a script received unanimous support. Such a script could check the user's environment, prompt for additional information as necessary, send messages to support, and generally hide all the nasty bits.

     The services-unit will get something put together.

  3. We don't have a tidy solution for cron jobs.

     Simon suggested that we should set up a "scripts server", akin to scripts.mit.edu, which would know how to handle users' credentials. This would also have the advantage that desktop machines could be put to sleep for longer periods, with a saving in energy efficiency.

     The services-unit will look into this too.

  Creating projects for the above would be a good way to record the ideas; and if anyone asks we could point people at them.

AOCB

The next meeting will be on Wednesday 10th March in room 4.31.