1. EGEE-II INFSO-RI-031688 Enabling Grids for E-sciencE www.eu-egee.org EGEE and gLite are registered trademarks gLite configuration (plans) Robert Harakaly SA3 CERN

2. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 2 Introduction Short history Current status Overview on glite-yaim versions Plans for future Discussion

3. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 3 History gLite 3.0: Inhomogeneous configuration of the middleware due to different configuration approaches of LCG and gLite Generally agreed need of improvement of existing YAIM Need to simplify the configuration management New configuration requirements

4. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 4 The goals Unify the configuration process for gLite and LCG services Support new configuration requirements –DNS like VO naming –... Add flexibility to the configuration Simplify configuration development/maintenance Keep all (most of) already existing YAIM functionality Minimize impact on the users Evolutionary approach

5. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 5 Current status/YAIM overview Three YAIM versions: –glite-yaim-3.0.0: in production (only critical bugfixes) –glite-yaim-3.0.1: DNS VO naming (current development branch) –glite-yaim-3.1: split yaim glite-yaim-3.0.1-6: full support for DNS VO naming. Currently sent to extended testing to sites willing test the new features. It has only partial support for hierarchical configuration storage. glite-yaim-3.1: Currently the prototype is written and is tested. It will replace glite-yaim-3.0.x as the sites will upgrade to new gLite release. This should contain a full support of hierarchical configuration storage and separated management of the service configuration.

6. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 6 glite-yaim-3.0.1 overview Already discussed during the EGEEII conference. DNS like VO naming, partial support of hierarchical configuration storage Modified special account (sgm, prd) management Improved queue management Potentially short living branch (?) Preview release sent to the sites for external testing. https://uimon.cern.ch/twiki/bin/view/LCG/YaimGuide301

7. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 7 # YAIM example site configuration file - adapt it to your site! MY_DOMAIN=my.domain # Node names # Note: - SE_HOST --> Removed, # - REG_HOST --> There is only 1 central CE_HOST=my-ce.$MY_DOMAIN RB_HOST=my-rb.$MY_DOMAIN WMS_HOST=my-wms.$MY_DOMAIN PX_HOST=my-px.$MY_DOMAIN BDII_HOST=my-bdii.$MY_DOMAIN MON_HOST=my-mon.$MY_DOMAIN FTS_HOST=my-fts.$MY_DOMAIN REG_HOST=lcgic01.gridpp.rl.ac.uk # VO-BOX - Set this if you are building a VO-BOX VOBOX_HOST=my-vobox.$MY_DOMAIN.... # lxb1431.cern.ch specific parameters VOS=”atlas alice” # lxb1430.cern.ch specific parameters VOS=dteam SW_DIR=$VO_SW_DIR/dteam DEFAULT_SE=$CLASSIC_HOST STORAGE_DIR= $CLASSIC_STORAGE_DIR/dteam QUEUES="dteam" SGM=... USERS=ldap://lcg-vo.cern.ch/... VOMS_SERVERS=" 'vomss://lcg-voms:8443/voms/dteam...'" VOMSES=" 'dteam lcg-voms.cern.ch 15004....'" #gLite CE specific parameters.... # gLite-CE node-info.d entry gliteCE_FUNCTIONS=" config_sysconfig_edg config_host_certs config_edgusers config_users config_mkgridmap config_lcgenv config_bdii config_crl config_java config_glite_ce config_add_glite_env config_gip_vo_tag config_torque_submitter_ssh config_gip_software_plugin config_gip_service" YAIM hierarchical storage

8. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 8 Other changes Changes in the groups.conf file The groups.conf file allows to define an optional 5 th field. It allows to define for a user a VO name which will overwrite the information from the FQAN. Special accounts management The sgm and prd users are mapped to pool users. Queue management Added _GROUP_ENABLE variables contains a space separated list of VO names and VOMS FQANs. It defines which groups are allowed to access the queue. OPSQUEUE_GROUP_ENABLE="ops /VO=atlas/GROUP=/atlas/ROLE=lcgadmin”

9. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 9 glite-yaim-3.1 Supposed to be a standard YAIM distribution for gLite 3.1 Modular packaging : –service should provide everything needed for its configuration  glite-yaim-core (CLI and general/core functionality)  glite-yaim- (glite-yaim-CE, glite-yaim-WMS) provide: oNode-info entry (yaim/siteinfo/node-info.d) oService specific configuration functions (yaim/functions) oService specific configuration parameters (yaim/siteinfo/services) oService documentation is distributed with corresponding service can be managed independently from the other services can be managed externally

10. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 10 Plans for glite-yaim-3.1 Full support of hierarchical storage Separated service configuration management Removed lcg-CE and lcg-RB services (supported only in 3.0.x) YAIM functions ‘re-engineering’. –Separation of all service related code from the core library.  None (or necessary minimum) of “if service == ‘XYZ’” in the library code. Most evident cases: config_gip, config_mkgridmap. The service related code (ex. config_gip_ce) should move to the service related package. –Optimization of python configuration code New features (currently in the discussion) –Will be discussed soon (many different requests)

11. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 11 Changes for users in 3.1 Changes in YAIM are mostly “internal” therefore change for user should be zero. Except: –Non supported services: lcg-CE and lcg-RB targets will be removed. Target CE will be an alias for glite-CE. RB not clear if it should be removed or be an alias to WMSLB –Advanced configurations like local scripts (overwriting of default yaim scripts). The function naming and the functionality inside of each function will change during the re-engineering process.  To be discussed: The best way of informing about the changes

12. Enabling Grids for E-sciencE EGEE-II INFSO-RI-031688 12 YAIM testing Xen based virtual configuration testbed Deployed and tested all yaim releases before going to certification Needed also to verify 3 rd party configuration Possibility to have configuration verification by the developer before certification