EGEE-III INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks gLite Build Programme and Multi-Platform Support Presenter: Eamonn Kenny Location:Ataturk Hall, EGEE’08 Date:24 th September 2008 Time:16:50-17:10

Enabling Grids for E-sciencE EGEE-III INFSO-RI Overview gLite Restructuring Node Builds Description Different Branches (Integration, Development, PPS) Integration Dashboard Results Multi-Platform Support Platform Independence Going Forward…

Enabling Grids for E-sciencE EGEE-III INFSO-RI gLite Restructuring Previous Work in EGEE-II: -Summary of the code changes done in the gLite restructuring: -Investing a small amount of effort in restructuring saves time in deployment related issues later on Good work done so far: -Reduced entanglement of server/clients -In some cases, clear separation of functions into meta- packages (APIs, cli, interfaces) Possible Areas of Improvement: -Build client side without server side in ETICS -Platform independent

Enabling Grids for E-sciencE EGEE-III INFSO-RI Node Builds Client Nodes:glite-WN, glite-UI Server Nodes:glite-RB, glite-LB, … Move from monolithic builds to ‘per node’ builds. Allows developers and integrators to focus on the parts that can be released while deferring problematic parts of the build, speeding up the release cycle. Development, build, certification and post-production more tightly coupled since meta-package creation is automated. Less work in moving and sustaining a node type for a new platform type. Description prepared by SA3 and ETICS:

Enabling Grids for E-sciencE EGEE-III INFSO-RI Proposed Branch Separation Proposal, not proven as of yet

Enabling Grids for E-sciencE EGEE-III INFSO-RI Branch Usage Integration Branch:glite_branch_3_1_0 Software configurations locked. Results can be regression tested. Proven to work. This is one full project build resulting in the generation of many RPMs, tarballs, SRPMs and debs packages. Packages picked up by SA3 to create meta-packages. Development Branch:glite_branch_3_1_0_dev Allow JRA1 to quickly input changes in the build using this development branch. Locking is not enforced allowing SA3 to change configurations for new platforms (assisting JRA1). Focussed comparisons of nodes differences is easier to visualize (for EMT, JRA1, SA3).

Enabling Grids for E-sciencE EGEE-III INFSO-RI Branch Usage (2) PPS Branch: glite_branch_3_1_0_pps Takes the development branch when ready to move to certification. Configurations will be locked. Patches added by SA3 to the PPS branch. Accounting records for all nodes will be recorded in ETICS. First Tests:glite-WN_branch_3_1_0_1_dev glite-WN meta-package to be produced for SL5 x86/x86_64. comparison with SL4 x86/x86_64 easier to follow. glite-UI SL5 x86/x86_64 should be easy to produced on top of this.

Enabling Grids for E-sciencE EGEE-III INFSO-RI Node Builds (initial work)

Enabling Grids for E-sciencE EGEE-III INFSO-RI Multi-Platform Support

Enabling Grids for E-sciencE EGEE-III INFSO-RI ETICS and Platform Independence ETICS contains: ${libdir}=lib/lib64, ${platformArch}=i386/x86_64/amd64. RPMs can use: %{_libdir}, %{_arch}. Moved so far: VOMS, gridsite to platform independent configurations. ETICS in many cases only needs a default configuration per component. More issues will appear when moving to Unix platforms. Use: FHS and LSB for ETICS/middleware. Separate software into configure, compile, install and package (ETICS does a lot of packaging for you). ETICS needs to be independent of ‘internal dependencies’. New client will help here.

Enabling Grids for E-sciencE EGEE-III INFSO-RI Going Forward… Contact us regarding changing configurations, development branch changes. More to be done to have server/client side CODE and BUILD separation. Node separation benefits to multi-platform support need to be proven. EGI/NGI considerations are necessary. Going forward we want other partners in the project to be able to pick up on new platform support.