Purpose

Assist Grid sites to realise that a VO-ID card information changed and they need to change local configuration files. The VO Configurator tool is offered for this purpose.

Meetings

• 2008/07/25 Triggering bug, Request for policy statement and email thread.
• 2008/02/25 Agenda
• 2008/01/31 Agenda
• 2007/12/18 Notes
• 2007/11/08 Notes (lines 33-43 in the text)
• 2007/10/26 Agenda

Doc

• Policy statement for storing VO Configuration data. Approved by the EGEE PEB on 2008/02/07.
• CIC development plan (contains related items)

Technical config. info

By Gergo with comments by Gilles and Maarten for use by Dimitar, following the 2007/12/18 meeting:

A.) On the CIC portal.

  1) All the defined FQAN (must be unique) for the VO listed with their associated 'bind'
    string (may be empty) and with a flag which says that this FQAN is compulsory to
    be configured on all sites or not.

    Example (today's pre-defined values):
    "/alice/Role=lcgadmin" sgm yes
    "/atlas/Role=production" prd yes

Here:
    '/alice/Role=lcgadmin' - Is the FQAN
    'sgm'                  - Is the bind string.

         This is the string which defines that users
         coming with the given FQAN will be mapped to
         the unix users listed in users.conf and having
         the same bind string. _It has to be filled
         for all the FQAN listed_

    'yes'                  - Is the flag that says it has to be
                             configured on all site.

                             yes = compulsory
                             no  = optional


  2) A version and/or a date associated with the VO ID card which
    has to be changed automatically and incrementaly on _every_ changes.

  3) A version and/or a date associated with the VO ID card which
    specify the earliest version still acceptable to be configured on
    a site. This is the one together with the latest version (A2) that
    will be checked against the site configuration to decide the
    up-to-dateness of a site.


B.) On the YAIM tool.

  1.) A1 has to be repeated (or directly inserted from the CIC portal).
      There should be an additional box next to each (optional) FQAN
      for the site admins to able to select the optional FQANs for their
      site.

  2.) The YAIM tool should generate a tarball which contains the
      groups.conf file for each VO supported by the site.

      This groups.conf for each VO should contain the compulsory and
      the selected optional FQANs.

      The tarball should contain the version of the VO ID card for each
      VO.

      The format of the tarball is something to be decided between
      YAIM and Dimitar, soon.

C.) On YAIM:

   1.) Has to set up and download an insert mechanism that downloads
       the tarball.
       This should not be done in the configuration time but probably
       should be a separate command allowing site admins the check
       out and examine VO ID cards at any time without reconfiguring
       their nodes and avoiding CIC portal/YAIM tool downtimes.

   2.) [ INTERNAL, you don't have to care about ]
       Has to implement a method to combine the groups.conf files
       in a way that other YAIM functions and utilities keep working
       and stay backward compatible.

   3.) Has to publish the version of the VO ID card to the information
       system. This is a static information and can be done at
       configuration time using for ex:

      GlueHostApplicationSoftwareRunTimeEnvironment:VOID-atlas-<version>

   4.) There will be a possibility of having a groups.local which will
       contain -edited by the site admin -those mapping which are not
       in the CIC portal i.e. very local to the site.


   Note: YAIM is never going to configure default priorities/shares for
         the batch system for the VO. YAIM just creates the mapping but
         the batch system shares has to be set by the site admin !


D.) On SAM tests:

    1.) A new SAM test has to be written very similar to the 'caver'
        test, which checks that the version of the VOID card configured
        on the site is equal or greate then the earliest acceptable
        version for the given VO (A3).

        The test will look into the information system specified by
        the LCG_GFAL_INFOSYS variable in the environment of the
        WN the test is executed on and finds the corresponding
        GlueHostApp..... and compare with (A3).

        (A3) should be fetched dynamically during the test since
         we have a lot of VO and they will change quickly so, it is
        not worth to hard-wire the A3s for each VO into the SAM test
        (like in the case of the CAs) because then we have to change
        the rpms quickly.


        This test can be judged/set as critical by the VO admins.


Next steps:

 Ia.) The publications of the 'bind' strings in the CIC portal.
      This is important since it is not possible to recognize a priori
      for each VO which FQANs are used for sgm/prd purposes.
      (See the LHCb example...)

      The sgm and prd _has to_ be used for Production and LCG admin
      users the rest for other FQANs should be invented.

      [ Proposal
      A bind should be unique inside the VO and the YAIM tool should
      convert these binds to ensure that they are unique among all
      the VO.
      ]

 Ib.) Even if the publications of bind string is not yet implemented
      in the CIC portal Dimitar can start working on the .tgz
      generation.

 IIa.) Once Ia and Ib is ready we can start testing YAIM-tool YAIM
       interaction.

 IIb.) At the same time SAM test can be written.


The whole stuff does not require synchronous update, sites can upgrade
start using this facility asynchronously and a 'patient period' for the
SAM test criticality can be applied for some months...

Further explanation:

 a.) The optional FQANs are those which are somehow treated specially
at some site, for example the BUDAPEST site will choose a distinct mapping 
for example to /atlas/higgs because we would like to give higher priority to those users. 

Actions

• Dimitar: Document the VO Configurator.
• Kai: Follow the steps in Dimitar's documentation and send feedback to Dimitar.
• Maarten: Estimate development effort for moving groups.conf data into a directory structure (per VO) with different content per site.
• Gergo/Maria: Estimate development effort for implementing changes into yaim.
• Cal/Cedric: Estimate development effort for non-yaim sites.
• PIotr/David: Estimate development effort for a useful SAM test comparing last-update-date on VO-ID and (what?) at the site.

History

A number of savannah patches, release notes, EGEE broadcasts, special meetings, twikis and presentations are used today to inform the sites about required configuration changes. Examples: LCGVOConfigForSites, VOConfigForSites2007, VOConfigForSitesMay2007.

People involved

forum-vo-configuration@cernNOSPAMPLEASE.ch includes:

• M.Alandes/G.Debreczeny (yaim),
• D.Shiyachki (VO Configurator),
• G. Mattieu, C. L'Orphelin (CIC),
• M. Litmaath (VO configuration data on service nodes)
• R.Rumler (OAG),
• K.Neuffer (ROCs/Sites),
• M.Dimou(VOMS/GGUS),
• R.Mollon (VOMS/Data Management),
• C.Loomis, C.Duprillot (NA4),
• F. Schaer, LHC VO Admins and the vo-managers-group (VOs),
• D. Collados, P.Nyczyk (SAM).

-- MariaDimou - 07 Feb 2008