Plan and milestones for the creation of the new ROC Iniciativa de Grid da America Latina e Caribe

A plan for the start-up has been drafted by the CERN ROC.

The main constraint to the schedule is represented by the schedule of the GGUS releases . In fact due to many dependencies all the operational tools have to be re-configured in a nearly synchronous way, which can happen only in proximity of a GGUS release, which is scheduled once per month

Excluding that we manage to catch the November release (not feasible), we are left with two windows around the 16th of December and the 27th of January.

The December window forces us to adopt a (very tight schedule that will deliver the new ROC IGALC in operations just before the Christmas Holidays. It requires very focused commitment by IGALC. To be discussed.

The January window allows us to adopt a (second schedule) that will deliver the new ROC IGALC in operations at the end of January. The tasks are of course the same so this plan is not necessarily more relaxed than the first. Only it only later so it gives the new ROC more time to get used and digest the many new bits of information and procedures they are dealing with these days. Furthermore it fits better with the dates proposed by IGALC for visiting CERN. Compatibly with the deadlines of IGALC I would vote for this second plan.

Tentative milestones have been set accordingly in this document (dates from the January schedule in square brackets)

• December plan

• January plan

1. DNS domain name: igalc.org
2. name of the new ROC:the ROC manager, the ROC manager's deputies, the ROC security contact.:
   

            ROC Name: IGALC

                        PT-BR:            Iniciativa de Grid da America Latina e Caribe
                        SP:                   Iniciativa de Grid de America Latina y Caribe
                        EN:                  Latin America and the Caribbean Grid Initiative
                        FR:                  Initiative de Grille de l'Amérique Latine et Caraïbe 

            ROC Manager:                                    Diego Carvalho ( d.carvalho@igalc.org )
            ROC Manager Deputy:           Ramon Diacovo  ( ramon@igalc.org )

            ROC Security Contact:           Diego Carvalho ( d.carvalho@igalc.org )

            ROC Services Operator:         Frederico de Oliveira ( fred@igalc.org )
            ROC System Manager:           Allan Alvaro ( allan@igalc.org ) 

1. mailing list to contact the ROC, for ROC management purposes: roc@igalc.org
2. mailing list to contact the ROC for security purposes: security@igalc.org
3. mailing list to contact the ROC for user support purposes: support@igalc.org
4. Web site for the new ROC as a reference point for the public and maybe the administrators of the sites belonging to the ROC: http://www.igalc.org
5. Internal twiki or other means of communication targeted at the members of the ROC team: http://www.igalc.org/wiki
6. Certification infrastructure
   • A ROC bdii, containing the entries that are available in production, plus the services run at the site(s) to be certified: cert-is.igalc.org
   • A WMS able to submit to the CE(s) belonging to the sites to be certified: cert.eela.ufrj.br
   • A ROC Nagios: nagios.igalc.org
7. Desired date to start: ASAP

Description: kick-off of the new ROC IGALC

Date: 11-Nov-09

Agenda:

• presentation
• assessment of the required infrastructure
  • services
  • sites
  • support structure
• review and approval of schedule * tasks and milestones

Chair: Antonio Retico

Participants:

• ROC IGALC: Diego Carvalho, Frederico de Oliveira, Ramon Diacovo
• ROC CERN: Antonio Retico

*Presentation*
Short introduction of the parties. Antonio is deputy ROC Manager at CERN since 2005 and is in charge of following up the creation of the new ROC. IGALC operates in the framework of the EELA project where operations procedures (e.g. operators sending ticket to the sites based on the results of monitoring tools) are already existing and applied. In particular the project has got experience with SAM (running their own instance), Nagios (service running in Spain) and gLite middleware services such as BDII, VOMS and WMS. So they believe that startng operating as an EGEE a ROC will be just a matter of adapting procedures that they already apply to the new requirements.
Antonio points out that the implementation of regional procedures of a ROC are totally under the ROC's control, provided that the EGEE parameter are met (in terms of quality of service). Currently the QoS is defined by the minimal availability and reliability requirements and the control mechanism is instrumented in EGEE by the COD (Central Operator on Duty) that watches on the timely follow-up of alarms across the regions. e.g. the EGEE requires that the sites are able to meet certain minimal a/r criteria based on the results of the SAM, but doesn't define the site certification procedure. In the framework of the start-up of the new ROC the regional site certification procedure is to be defined and it will be checked by ROC CERN in order to verify its compliance to the existing EGEE metrics.

*Assessment of the proposed infrastructure*

Antonio notices that some of the links provided (e.g. the web site and the domain) look like placeholders. He points out that AFAIK EGEE is concerned the only real requirement is that ROC contact points are duly defined on a public web and responsive . The web site (as the wiki for internal documents) is not a requirement in itself but rather a best practice based on experience. A dedicated section in other existing web site is perfectly acceptable. As an example Diego shows the EELA operations web. Antonio insists on the responsiveness of the contact points (mailing lists) provided. He will use them throughout the whole creation process to test.

A clarification on the requirements about BDIIs:

• there is one non-functional requirement coming from EGEE for each region to run a top-level BDII. This BDII is a "reflector" that has to contain all the EGEE sites (list to be provided) and not only the sites pertinent to the region. It should be accessible by all EGEE users (although it will be preferably accessed by users in the region). This requirement is meant to distribute the load on the information system among different servers.This BDII in not to be considered a ROC operational service but has to be run by a site in the region.
• for site certification purposes the ROC is recommended to run a top-level BDII as an operational service. This one can contain a subset of the sites (e.g. only sites in the regions, both certified and uncertified). This is not a requirement but a best practice.

Sites:
Sites in predicate for the migration to the new ROC are recognised to be UFRJ-IF and CEFET-RJ

Support:
The ROC is fully responsible of the dispatch of tickets internally, provided that the GGUS workflow is satisfied. Antonio noticed that different choices have been made by the various ROCs in that respect. A longer permanence at CERN for training would allow to have a better idea of the implications of running a regional TT system. This will however be out of the scope of the start-up because Diego confirms that the visit at CERN won't last longer than one week.

Approval of the plan: The plan presented was reviewed and approved with no reserve. A particular attention has to be given to the participation to the CERN ROC Rota which is difficult to fully achieve remotely. Agreement to use IM as a fast communication method.

The following points will be attacked initially by IGALC

• certification bdii (operational at cert-is.igalc.org)
  BDII_HTTP_URL="http://eu-eela.eu/bdii/bdii.php?infrastructure=igalc
• VOMS (operational at voms.eela.ufrj.br) (not required)
• preparation for ROD Rota (documentation provided)
• dteam VO registration (request done)
• GOCDB registration & role request (request done)
• enrollment to mailing lists enrollment defined at https://twiki.cern.ch/twiki/bin/view/LCG/ToStartAtCernROD
• GGUS registration
• top-level bdii ( URL Available at http://egee-roc-cern.web.cern.ch/egee-roc-cern/index.php?dir=./bdii/ )
• Nagios
• WMS (not strictly required. to be used for your certification procedure supporting the set of VOs supported by the certified sites + ops + the VO used for certification (e.g. dteam).
• OS and middleware repository
• SLA with UFRJ-IF and CEFET-RJ (template available at https://twiki.cern.ch/twiki/bin/view/LCG/CERNROCProcedures#SLD_with_sites
• preliminary website containing contact personnel