Software Provisioning in EGI

One of the interesting questions lurking since the whole EGEE -> EGI transition was how decisions about software would be made. Under EGEE it was fairly simple - There were people in the project to write gLite, deploy it and use it. Under EGI, all three groups are separate, with only really the middle group in the middle belonging to EGI-Inspire; which is a significant shift.

I'm mostly focussing on some parts of this session; trying to give an overall flavour rather than bog down in details.

UMD Roadmap (Steve Newhouse)

The UMD is software developed within EGI, either from EC projects, or work by NGI's. EGI select for quality, based on user requirements and operations needs. Steve's made the example that showing something working from your own laptop to your own desktop; whilst it might be interesting as a demostrator, probably hasn't demonstrated the needed robustness for deployment.

This software is more influencable that the software that comes through RedHat and Apache, for example. In those cases, EGI can choose what to deploy. This talk is mostly about the UMD.

It's interesting that there is a distinction drawn between Functionalities (thing that software does) and Capabilities (things users want); which allows for emergent behaviour - a rather enlightened approach to software requirements that I wish was used more often.

Feed in requirements occurs from Operations Management Board and the User Community Board; representing the two sides of needs. The Technology Coordination Board makes the decisions, and feeds these into the providers. Previously, the TCB was known as the Middleware Coordination Board, and it says something about the thinking that it's less middleware-centric.

The first version of the UMD, numbered version 0, and Steve presented a number of questions for us to think about; such as is there gaps, too much detail, etc. It doesn't define implementations, that's for providers to input later.

There are three areas of Capabilities - Functional (end user); Security (and accounting); and Operational. There's an interesting diagram that shows Security and Operational as horizontal items, with the Functional ones vertically arranged (i.e. all the Functional capabilities are roughly independent, cross cutting the Security and Operational concerns). Steve presented an overview of the current set of these Capabilities

There was some discussion; Mario David identified Resource Information as a desired Capability. Fabric management causes some concerns; mostly around installation and configuration ease, I think - and was put down as an area needing further discussion. Stephen Burke brought up Interfaces, which seems to be something for next iteration, once providers are identified. But an important one, of course. Balázs Kónya (of ARC, so no doubt with a provider hat on) asked about distribution and timescales; which can't be defined yet as it's too early in the process.

The next couple of talks discussed some details of the quality testing EGI will do. It was interesting to identify the (potential) software providers in the room, as they asked the questions! There were more questions that time allowed, so I think that there will be side discussions on some of these points later!

In summary, an interesting introduction; but it's clear that whilst the bones of the process is there, some more detailed work needs to be done.