Namespaces and service templates in CDB

Friday 20 Jun 2008, 11:00 → 12:30 Europe/Zurich

513/1-027 (CERN)

We have started to use namespaces in CDB. 1) for staging purpose (test, preprod, prod) 2) for organising templates I would like that we meet and agree on the 2nd point. What do we call "service templates" ? What do they content ? How do we organise cluster-specific templates ? Etc This should go inline with the proposal for the new profile structure proposed by FIO-FS. See http://lemonweb03.cern.ch/cdb-tpl-view/tpl_view.php?profile=profiles/profile_lxb6641 already discussed at previous brainstormings. It has been agreed to follow the new stucture for SLC5 machines. For an example of a SERVICE template, see: http://lemonweb03.cern.ch/cdb-tpl-view/tpl_view.php?profile=prod/services/afs_client/config For minutes of previous meetings, see http://indico.cern.ch/categoryDisplay.py?categId=244

Present: Tim Bell (minutes, thanks !!), Ricardo Silva, Miguel Anjo, Ulrich Schwickerath, Steve Traylen. Sophie Lemaitre, Giuseppe Lore, Matthias Schroder, Veronique Lefebure

The new CDB structure and service profiles were reviewed in detail.

• /retired will be set up to cover machine profiles where the machines are retired. Other templates are maintained in CVS and can therefore be recovered after deletion. Duplicate profiles in retired have unique names.
  
• /vpd will contain all the machine specific information such as serial numbers.
  
• /hardware/memory should be removed as this is a duplicate of /hardware/rams. Though the name is not easy to say or read, it is the Quattor standard and this is one of the prime objectives of the re-organisation of CDB.
  
• Services templates are defined in /services.
  
  • They can also be used to define new users such as oracle or apache. Components which are included multiple times should be marked as unique in order to avoid that including 2 service profiles resets the values from the 1st instantiation.
  • afs_client service was examined in detail. The current configuiration of the AFS version would need to be adjusted to make it OS independent.
    
  • For those services where the machine service managers are very concerned about the exact software level required, a service profiles can allow a default version to be overridden by the cluster definitions.
    
  • The LSF service profiles are one of the most complicated cases and further discussion is required to find how to fit into the current model.
• The site/configuration tree will be modified to include the various enclosure combinations and non-quattor systems. Veronique will review further how these changes can be made since the original proposal was not felt to be 'clean' enough.
  
  • The people_acls tree should be renamed acls.
    
• /repository should stay as it is rather than move under /os as this is the Quattor standard.
  
• The default OS configurations will now be minimal. Service managers will need to include the packages required.
  
  • Sendmail daemon should be configured by default as outgoing only in the minimal configuration.
    
  • Package add-ons such as libX11 should follow the standard Unix package list conventions such as 'text tools'. These lists should be incoporated into a new /packagelists structure. These templates should make the appropriate tests inside to remain OS independent even if the names of the RPMs are different between different versions.