-- PerditaStevens - 06 May 2014


of meeting held Wednesday June 11th, 2014, 2-3pm.

Present: Tim Colles, Dave Robertson, Alastair Scobie, Perdita Stevens. Apologies: Neil McGillivray , Michael Rovatsos.


Corrections were made to the attendance list (DR was present) and content of AOCB (we also discussed the membership of the group).

Actions had been done (or were done during this meeting) except that the "So you're teaching a course" page still needs to be finalised and placed on the central web (action MR, PS, NMcG ) DONE (via new teaching FAQ)

Time and date of next meeting

To be arranged electronically given that not everyone was present.

Action: PS to arrange.

Progress on the EL7/SL7 port

AS reported that we had hoped to be able to upgrade to EL7/SL7 over this summer for next academic year, but this is now impossible because its release schedule has been delayed. (RHE7, the commercial release, came out yesterday; the free version will be several - 6-8? - more weeks, leaving us insufficient time to do the development and deployment before the new academic year. In earlier similar circumstances we have used Fedora instead, but our experience with those ports has shown that this is an impractical (and costly) option because they have very short support windows. In any case, we're too late for this now; we will have to wait until next summer before upgrading the teaching machines. This will incur some more effort upgrading individual packages used in teaching to more modern version than is in our current distribution, but there seems to be no alternative. Staff desktops can be upgraded as and when, so research software is less of a problem: from October or so, a member of staff who needs a more up to date version of research software can have their own desktop upgraded individually.

Following up from Reset the Net, are there further things we should do?

No. PFS is outstanding, but this requires a later version of Apache. When we do the next OS upgrade this will be automatic, so no further action is required for now.

Data storage, management and archiving update

Various aspects:

- Data planning. This seems to be about deciding in advance of research being done, e.g. while preparing a proposal, what data should be collected, e.g. with what metadata. We discussed scepticism about how detailed such information could realistically be in our fields. In the absence of a requirement to do this for our own grant proposals we do not need to take any action; should such a requirement emerge we expect it to be straightforward to give advice.

- Data share, the facility to present data to the public. Kerry Miller has given a presentation on this to the Research Committee and we think the time is ripe to ask her to come and give one open to everyone. We discussed the merits of doing this over the summer while some people are away vs doing it next semester when people are here but busier, and preferred the former.

Action: AS to ask her.

- Data store. We are still not sure how this will work technically or be presented to users. There are three main possibilities:

A: central facility used "as is" over NFS or SAMBA. Strategy committee disliked this option, when AS presented it recently, for security reasons. It would also be much less usable for our users. (AS writes:) People could use Samba from their own self-managed machines and that would be reasonably secure. They could even "mount" from a self-managed linux box, but that wouldn't work for a self-managed machine with multiple users. We could "mount" via NFS if we didn't care about the security concerns, but we'd possibly want to restrict this to DICE machines only. This is our least preferred option.

B: running AFS (a new ed.ac.uk cell, not an extension of our existing inf.ed.ac.uk cell) on top of GPFS. Orlando from IS and Neil Brown are looking at this. The technical concern is that doing this might impact the performance of the rest of the facility. If this turns out not to be a problem, this is our preferred option. We hope to know by September, but this depends on Orlando's availability.

C: running AFS directly on an allocation of physical storage. This is more work than A for us, but considerably less than B, and is likely to give us less throughput because we will have a small number of dedicated spindles instead of sharing the 150 spindles allocated to CSE. This would be better than A but worse than B for us.

- Data archiving. Little to report; requirements capture has only just begun. We need to engage when we can.


Transition to the new project prioritisation and tracking process is underway, with most of the underlying data structure in place, but we are not in a position to announce the changes to staff, telling them how to access the new "improved visibility" information and how to submit a project proposal at any time. TC reports that we should be able to do that in early July, after a few cycles of COs using the new mechanisms internally have taken place to iron out any issues.

We discussed AS's draft account expiry policy. The only significant issue is whether to have longer delays in the staff expiry process than the university standard. This seems desirable, but we wondered whether there may be some legal reason for the university's surprisingly short periods. If not, we'll use the 180 days AS suggested.

Action: AS to ask IS about this (and depending on the reply, make sure the new policy whatever it is is published somewhere on the web?)

MR had mailed asking about:

- an MSc project database he wanted implemented; Tim reported that he didn't think this had been prioritised by MR in their last discussion of teaching projects, but MR should talk to him if there is misunderstanding. Tracking individual projects is not in the remit of CSG.

- how the withdrawn IS forums should be replaced. He reports that Compsoc and student reps may be willing to host their own forum, if we do not plan to have a replacement. In fact Alison has put a Drupal forum mechanism in place and it will be used by some of Paul Anderson's students over the summer, so using that more generally is a possibility. However, if students wanted something different and were prepared to run it, that might be an excellent idea; the recurrent problem is lack of student engagement with the various mechanisms we've tried, so if they can solve that problem we'd be delighted. They should be encouraged to give staff access, and computing staff would be happy to discuss it if that would help.

Topic revision: r5 - 06 Oct 2014 - 13:30:46 - PerditaStevens
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies