DICE Meeting 2002-11-28

Agenda

1. Definitions
2. Why reorganise
3. Feedback
4. Groups/Teams
5. Issues
6. What next

Minutes

Definitions

Due to ambiguity and different interpretation of what various phrases meant there was an attempt to clarify the following definitions:

• DICE
  Many people currently think of DICE as only being the commodity desktop machines, rather than being some overall system. The Distributed Informatics Computing Environment should perhaps more correctly refer to all aspects of supported computing within Informatics. This would include any LCFG-managed machines (commodity boxes and servers), networks (connectivity), DNS, LDAP, backups, etc. The principle is that even if there are self-managed machines on the network they are still making use of services such as networking, firewalling, DNS, etc. Whatever we finally decide, we need to come up with terms that allows us to distinguish between the different aspects and in particular will allow us a convenient and non-confusing way to refer to the standard DICE commodity box.
  [ACTION: CEG]
• Line management
  Under the new structure for DICE COs a line manager will have the following responsibilities
  • management of an individual's majority work, typically associated with their 'home' group.
  • their personal welfare and personnel related matters (appraisals, etc)
  • to resolve prioritisation matters with respect to other demands on a CO's time
• High Quality Service
  One of the overall aims of DICE is that once things have settled down and migration from legacy is complete, there should be more resource available for developing individual services. With running larger scale services there will probably be more effort needed to make them robust and reliable. However, it is also expected that services will be developed to provide more features/facilities than was perhaps possible under the legacy services due to lack of resource.

Why reorganise

With the initial rollout of DICE, which included basic infrastructure, some services and the first wave of commodity machines, there are now lots of Informatics-wide aspects to daily operations. The scale of operation is much larger than before. We need effective ways of cross-site working to provide:

• clear indication of who is running and/or responsible for what
• a set of escalation procedures for dealing with problems
• clear indication of how planning and development of DICE will be done.

Feedback

uncertainty:

there has been a degree of uncertainty about the impact of DICE on each of the sites. This has been exacerbated by the need to deploy DICE to such tight timescales which has left no time to clarify issues and any misunderstandings. Some of the items discussed at the meeting, particularly about support, helped clarify certain issues. up.

support:

There was a long discussion about support for users in general, and in particular for non-DICE platforms.

• support model
  we'll help anyone and we'll try to fix anything, within reason. What we need to avoid is giving any single user a disproportionate amount of time as it isn't scalable.
• supported hardware
  The types of hardware supported by default is in transition as we migrate from support policies at the three sites to a more common one. Sites have existing supported architectures and will continue to support them for the life of hardware that is already purchased. However, Computing Committee needs to make a formal policy statement on what hardware is supported under DICE. This will not preclude any particular hardware but will make recommendations and indicate levels of support.

transition from Solaris:

there is a significant support load related to moving users from Solaris to DICE for the non-KB sites. This is both for getting users migrated from their environment/setups that work under legacy and also for getting required legacy functionality available under DICE (eg, BP's /corpora). This will be a noticeable proportion of work in order to get remaining users migrated by September 2003. CEG acknowledged that this was important and would require effort to be allocated to it.
The recent meeting between COs and users at FH about migrating to DICE had indicated that this aspect of the transition would be greatly helped by access to local CO/CSO help in person rather than just via the normal channel of the web form.

Issues

line management/groups

The current proposal ties line management to groups. Concerns were noted that this might present a difficulty for an individual if their natural interests were in an area where they would get a different line manager. At a time of reorganisation there is a natural tendency to want to change as few things as possible. It might even influence a CO's expression of interest as a way to not changing line manager. It was also suggested that with COs still split between sites it was perhaps better to have an individual's line manager located at the same site. In practice there are several COs not managed locally and it does not appear to have been a problem. The concern was noted.

site management

Under the current proposals there is no officially designated role that corresponds to the local site managers that have existed at each site. The main reason for this is the concern that it would act as a magnet for a wide variety of tasks that would be better being dealt with under the relevant group or team. However, it was acknowledged that this is a difficult area and will need further thought and consultation.

database

management and organisation of the database is part of the Services group. It was inadvertently missed out of the most recent draft proposals (posted to cos@inf 22/11/2002). A full list of teams in fact has still to be created---see below.

role of Technology/Development group

The first draft proposals (posted to cos@inf 29/10/2002) mentioned that the Technology/Development group would tend not to have a specific set of members but rather have people seconded as required. The intention is that all COs get an equal opportunity to do development work if they are interested rather restricting it to a limited set of individuals. This idea was not mentioned in the revised proposals so it was confirmed that this view still applies. A comment noted was that consequently its operation is different from other groups with respect to line management, since by definition it will have very few, if any, permanent members.

teams

the current full list of teams has not been finalised. It was agreed that this will be done as soon as possible by CEG in order to facilitate the process of COs expressing their interests.

[ACTION: CEG]

What next

Timetable

CEG are keen that a new structure is in place sooner rather than later to reduce the uncertainty and provide the mechanisms for managing DICE. The current goal is to the reorganisation decided before the Xmas break so that the new structure takes from the start of the New Year.

Interests

COs need to let CEG know what their interests are. Current line managers will be discussing these with individuals over the next few days. There is a meeting planned for Thursday 5 December where CEG hope to collate the information coming back from COs and make a first pass at a list of team members.

 : Deploy : Meetings 

Please contact us with any comments or corrections. Unless explicitly stated otherwise, all material is copyright The University of Edinburgh