IPv6 transition Vincenzo Spinoso EGI Operations

Goal EGI is preparing a transition plan to IPv6 EGI Operations is going to assess the IPv6 readiness of the EGI infrastructure and software Need to plan properly WLCG is going to deploy their services under dual-stack mode (v4+v6) by April 2018

Operational tools: development and operations assess the IPv6 readiness of the products and test them against IPv6 clients EGI Operations in touch with all service responsibles to get details about IPv6 readiness  IN PROGRESS Comments: - Some services not IPv6 because the hosting site is not IPv6 (PARTIAL) - Some don’t have any plans yet for IPv6, so we are somehow triggering the plans

Operation Centres/Resource Centres assess the IPv6 readiness of the overall infrastructure (real machines, cloud managers) for each RC Asked at EGI Operations meeting to start collecting information  next meeting on March 13th Each NGI to collect and follow for each RC Transition plans/timeline Network readiness status, DNS readiness Services readiness status

UMD Release Team Enabled IPv6 in UMD process OK for UMD but if a product is not IPv6 it is not yet rejected Not yet for CMD First results: DPM issues with the MySQL version coming from SL6 Probably SL6 is an issue by itself if some application (like MySQL) is not IPv6 compliant, CentOS7 will probably eventually resolve the issue TPs to declare IPv6 readiness status for products https://wiki.egi.eu/wiki/Middleware_products_verified_for_the_support_of_IPv6 Then Release Manager to directly follow up with single TPs

Planning transition to dual stack mode Need to plan very in advance M1 All core/EGI services IPv6 ready All supported products are IPv6 ready A given fraction of sites is IPv6 ready M1 set the deadline (say) 6 months later Intermediate milestones needed? Restrict milestone to a specific set of «core» services (CE, SE…)

Middleware and operations Vincenzo Spinoso EGI Operations

decommissioning dCache 2.10 endpoints, deadline at the end of April Preview 1.8.0 AppDB info (sl6) dpm-dsi 1.9.11, frontier-squid 3.5.23-2.1, LFC 1.9.0 Preview 2.8.0 AppDB info (CentOS 7)

UMD 4.4 – “February release” C7: FTS3 3.5.7, Frontier 3.5.24, Frontier 2.7.27, dCache SRM client 3.03.1 SL6: VOMS 3.5.1, ARC 15.03.10, Frontier 3.5.24, Frontier 2.7.27, dCache SRM client 3.03.1 APEL queued: need to figure out exactly how to verify it: cross-product, probably good to have more SR reports for different products UMD 4.5 (“May release”) work in progress to include first WN/UI for C7, still missing some important clients CREAM for C7?

CMD CMD-OS (OpenStack) CMD-ONE (OpenNebula) Update planned on March switching to Xenial as sites are abandoning Ubuntu 14 for Ubuntu 16 (LTS) C7: cASO, APEL SSM, BDII, rOCCI client Xenial: cASO, BDII, rOCCI client, keystone-VOMS CMD-ONE (OpenNebula) Switching to OpenNebula 5, several sites adopting it + rOCCI server updates will be only for ONE5 Setting up ONE5 testbed at CESGA, will early adopt cloudkeeper Then a release date can be set rOCCI (libs, client, server), jOCCI, ONe handler (Handler for OpenNebula), cloudkeeper, Indigo products