DICE Meeting 2002-02-05

Agenda

1. KDC/LDAP master - updates (Tim)
2. '-doc' proposal (Paul/Lex)
3. CEG report reading (Jeremy)
4. Coding Language (Alastair)
5. Tasks/Actions/Timescales
6. Review of Reports

Decisions

1. '-doc' proposal accepted.
2. Coding Languages: unless there are extenuating circumstances coding/scripting should be in C, PERL or Bourne Shell.
3. Tasks/Actions/Timescales
   • Reports to include summary of changes
   • Sub-tasks to be identified where possible (no longer than one week, preferably smaller)
   • Actions to be nominated to be completed for the next meeting.
4. Review of Reports
   • Documentation: the DICE doc pages do not need any documentation for components under DICE as they will always be available on the LCFG pages.
   • Common home directories:
     1. /legacy will be available on every machine in legacy and DICE worlds.
     2. Your primary home directory will appear under /legacy even if you are on a machine in your primary domain.
     3. The naming convention is /legacy/<site>/home/<olduser>. (We may also mount other legacy stuff under here.)

Actions

1. KDC/LDAP master: sorting login issue
   [Tim]
2. Tasks/Actions/Timescales: Send round a template for report change summaries.
   [Jeremy]
3. Tasks/Actions/Timescales: Send round a template for actions.
   [Jeremy]
4. Tasks/Actions/Timescales: Circulate magic for getting CVS to tag the latest changes
   [Simon ]
5. Tasks/Actions/Timescales: Tag the reports repository every meeting.
   [Jeremy]
6. Tasks/Actions/Timescales: Alter schedule on deploy page.
   [Jeremy]
7. Reports/Misc: decide what/when WRT machine purchase
   [Alastair/Jeremy/Ken]
8. Reports/Misc: make OM overview document available
   [Jeremy]
9. Reports/Printing: check authorisation model is adequate.
   [Toby ]
10. Reports/Mail:talk to posties about delivery performance to ed.ac.uk.
    [Morna]
11. Reports/Mail: make new proposal about how legacy mail addresses will be handled and circulate
    [Jeremy/Neil/Craig/Morna]
12. Reports/Documentation: Release management to be clarified
    [Paul]
13. Reports/Documentation: How DICE and LCFG components/documentation are split.
    [Alison]
14. Reports/Common home directories:Add notes about firewall/netgroup issues wrt to filesystem exporting
    [George]
15. Reports/Common home directories:Need to sort out lists of trusted machines for exporting to
    [George]
16. Reports/Filesystem Maps: Need a way to pick up RPMs; access to mirror servers required (????) Alastair to mail Bill.
    [Alastair]

Minutes

1. KDC/LDAP master - update (Tim)

   The servers are up and running happily but there is a problem with getting them accessed at login. Subsequent accesses eg ldapsearch are fine. Tim to talk to Simon.

   [ACTION: Tim]
2. '-doc' proposal (Paul/Lex)

   [NB You need to login to the cos@informatics archive first to get to the link below.]

   Lex's proposal was accepted.

3. CEG report reading (Jeremy)

   CEG have read all the reports and noted various actions which are being communicated directly to task owners or individuals.

4. Coding Language (Alastair)

   The DICE team discussed this in the early days of DICE and recommended that coding should be done only in languages where there is the most likely and extensive experience given the large number of potential maintainers. This information had not been widely disseminated at that stage.

   Consequently, the decision is that only 'C', PERL, and Bourne Shell should be used unless there are very strong extenuating circumstances.

   Currently there are some known exceptions, namely use of Tcl for some of the network management software and use of BASH for some of the LDAP glue code and gurgle for Informatics database report writing.

   If it is essential to use an alternative language then where possible this should be kept to a minimum and provided with a wrapper interface in the recommended language.

   It was also noted the in the heady, idealistic, early days of DICE there was the wish expressed that there would be time for peer review of code. Maybe next year...

5. Tasks/Actions/Timescales

   Tasks: the reports are now difficult to deal with as you can't tell what are the major changes since last time. We could mess around with CVS to identify literally the text that has changed but it is more convenient to have the report writer summarise the change succintly in a change summary in the report. Changes will be with respect to the last reporting meeting (ie, 2 weeks before).

   • Send round a template for change summary.
     [ACTION: Jeremy]
   • Circulate magic for getting CVS to tag the latest changes
     [ACTION: Simon ]
   • Send round a template for actions.
     [Jeremy]

   Actions: we need better reporting on what stage tasks have got to, what actions have been identified and what goals groups are setting for each time.

   We decided:

   • actions identified should be no longer than a week duration and preferably smaller duration (although not too fine-grained).
   • tasks should identify at least one action that will be complete for the next reporting meeting, preferably more actions depending on time available.

   NB: please would report writers regularly update the estimated time to completion of all their Stage 1 tasks.

   Timescales: Alastair clarified that the plan is to have testing going on during June and that machines will be deployed, at KB at least, later in July and on in to August.

   The deployment timescales mentioned on the deploy will be updated.

   [ACTION: Jeremy]

6. Review of Reports

   Only those reports that were discussed in detail are listed. Brief summaries are below. More substantive discussions are summarised later.

   Misc:

   Alastair/Ken/Jeremy need to discuss when machines are going to get ordered.

   Printing:

   Simon needs to know if the authorisation model will provide what is necessary for Printing. Initial implementatin of printer access control will be barebones but it is important to get the model right.

   Mail issues:

   Morna is going to talk to other posties to checkl if there are regular mail delivery problems to .ed.ac.uk.

   Legacy:

   legacy groups need to talk to each other to cover common problems.

   LCFG:

   people need to tell Paul about component ownership and what has been converted. There is an overview OM document that needs to be made available.

   Apps/BP:

   remove comment about NFS distribution.

   Documentation

   Clarified that 'components' refers only to LCFG scripts formerly called objects. There had been a misunderstanding over this so some proposals of the documentation task no longer apply.

   The DICE doc pages do not need any documentation for components under DICE as they will always be available on the LCFG pages.

   It was not clear that we need to refer to documentation for more than one release on the DICE/doc page. The correct place to look for documentation relating to a release in use is likely to be on the machine running that release.

   There are two main issues unresolved here:

   1. how to indicate the current and old releases, what naming conventions are needed and how releases are managed. Input is needed from Paul on this one.
      [ACTION: Paul]
   2. exactly who the DICE documentation is targetted at and how it is split vis a vis LCFG. More investigation is needed
      [ACTION: Alison]
   Minor issues: Simon pointed out that a) using '.' in names is liable to break things and b) it is important to have the link reference be to a destination that doesn't change (so we don't want things like 'current' in the URL).

   Common Home Directories

   Various issues were clarified regarding mounting and copying. There was agreement that we want to get this out of the way as soon as possible which determined that we would have to mount users home space on both legacy and DICE machines. The main problem is that there are many students who have file space on two sites and after common home directories are implemented will still need access to both but before DICE machines exist. Hence we need to make /legacy available everywhere.

   • /legacy will be available on every machine in legacy and DICE worlds.
   • Your primary home directory will appear under /legacy even if you are on a machine in your primary domain.
   • The naming convention is /legacy/<site>/home/<olduser>. (We may also mount other legacy stuff under here.)
   Other issues:
   • need to sort out firewalling/netgroups related to exporting to all site. This needs to be added to the network documents.
     [ACTION: George]
   • need to check that all UIDs are unique. This info is available from automatic database extracts. (This will be part of task list for common home directories so not listed as an action here.)
   • need to clarify issues around GID usage under DICE and with respect to how filesystems are to be exported but maintain group access. Being discussed publically.
   • generation of lists of trusted hosts ot export to. May export to subnets
     [ACTION: George]
   Filesystem Maps
   • Need a way to pick up RPMs; access to mirror servers required (????) Alastair to mail Bill.
     [ACTION: Alastair]
   • removeable media will include floppy/CD/ZIP/smart media (???? not sure what this comment was in response to)

 : Deploy : Meetings 

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