|
|
|
Actions discussed:
Alastair has done part of this, but there's also input needed from Alison.
Provisionally scheduled as part of the TDM on the 30th.
Actions added or revived:
Actions completed:
Now being discussed at CEG
Blog articles discussed:
Craig will do this soon, as he hopes to have the changes in place by the start of term.
Report from Computing Executive Group
Alastair gave a verbal report on his discussion with Tony Weir.
Reports from Units
Alastair noted that MPU's plans to test out the IBM array are probably not going to be possible in practice. They propose instead holding back moving the array until later in the migration process, and that they might need to have the old switches left in service for a while as a result. This shouldn't be a problem.
It didn't see that there would be any real problems caused by the switch's replacement, so inf-unit will propose a time after discussion with the techs.
The question was raised as to whether DICE_STICK_WITH_SL65 has been made a noop yet. MPU will check.
The proposed quotas were agreed. Services-unit now need to update the computing.help pages to match.
Has SL7 printing to the IS "charged" queues been tested yet? Gordon reckoned it had been, but will check again.
Alison will email returning students to warn them about the SL7 upgrade, and that they should expect to see some differences in behaviour as a result.
The DICE SL7 release notes on computing.help could do with being reviewed and updated. One issue which might need clarification is the choice of session (sic) manager. MPU and RAT will update as required.
There is a saved "SL7" search on RT.
Lindsey will describe her bitlocker issues to Alastair, for forwarding on to CCPAG.
Toby re-raised the issue of automatically re-enabling accounts, some of which might be long dormant. After some more discussion it was agreed that it would make sense to defer this for now.
For future reference, Toby's reasoning is as follows...
"We automatically disable accounts in the following cases:
"Prometheus now has a closer exposure to the database and so greater exposure to vagaries, upstream feed changes, etc. e.g. On the 1st August all the continuing students disappeared from our feed and so entered lifecycle. This was mitigated at the database side, but required manual intervention to restore all the additional roles which students previously possessed.
"We also see individual cases of students being present in our feed (with account-granting roles), disappearing from our feed for a while and then reappearing (with roles) again. This is difficult to know how to deal with automatically. Defining the interface between prometheus and the database is the subject of a project. [1]
"To address some of this, we would like to be able to automatically re-enable accounts which have been previously disabled, but which now possess account-granting roles again. The issue with this is that we have a large number of accounts which are currently disabled. These can be many years old, as we are not currently deleting old accounts. There is a pending project to deal with this [2]. From a security perspective, we also do not think it would be wise to automatically re-enable accounts which may be unused/unneeded.
"We have a project to look at automatically disabling/suspending (wording to be refined) accounts which have not been used in the last X period of time [3]. It makes sense to use the logic to be developed here in any automatic re-enabling of accounts.
"This would make an active account dependent on two criteria:
"Our goal, with account management, is to automate everything that can sensibly be automated and to report on that which can't."
[1] https://computing.projects.inf.ed.ac.uk/#363
Roger raised the question of gnome for new users again. Even though we thought we had decided on this some time ago, a fair amount of discussion ensued.
The general consensus was that gnome3 was the least worst option for new users, though we should expect that a fair few of them would later opt for something else. Previous users upgrading from SL6 might well need some support.
Should we all use the defaults ourselves? Most of those present didn't use gnome3, for various reasons. There is an argument that we should use it so that we are familiar enough with it to be able to support users. On the other hand, we should also be familiar with those users' other options, for the same reason.
At present the choice of WM doesn't follow the user between machines.
Graham suggested that it might make sense for VM migrations to be more automated than they currently are. Alastair was wary about this, as migrations had been known to fail sometimes, though this seems to be less now than it had been in the past, and when they do there can be a fair amount of manual fixup required.
Migrations can take 10-30 minutes each, and are done one at a time. There's a reluctance to set something off which might fail overnight leaving machines out of service for some time. Could the migration process be made failsafe in some way?
Not migrating can be a hassle too, as it's then necessary for MPU to ask Units about their to-be-suspended machines, so that sys-announce messages can be composed. Some of this would have to be done even for migrating machines, though, as there would be some at-risk time for them.
As a slight diversion, there was some discussion about putting machines' "roles" into their profiles in some way.
Alastair didn't want to commit much MPU time to this, as the VM service is only an "interim" one, but they will experiment a little to see if some useful automation could be done.
(None suggested)
AOCB
Neil noted some issues with playing most course videos (RT#73519). Fortunately it seems they can be converted.
The next meeting will be on 23rd September 2015 at 10:00. Room to be confirmed. George will convene.
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|
