[Pgi-wg] PGI TelCon 2009-03-13 Meeting Minutes available for Comments

[Steven Newhouse]

> - No splitting, please. If the group grows too big to be maintained, it
> will need to be reduced to its original efficient core.

Not having the call IMHO increases the forces for splitting - which I agree would be bad.

> - I do see these Wednesday meetings as a very unfortunate sign of a
> split that goes against the original group intention. Let me remind
> again: the group aims at transferring "academic" versions of BES. JSDL
> and GLUE into one-two profiles that are used in production. Separating
> BES and JSDL from GLUE and security is counterproductive, IMHO - or at
> least is against the original group intention.

The reality is that the original group has been very lax in documenting why in detail there is a need for PGI. It is good to see this finally happen. Andrew kindly volunteered to step in on the last call to move things forward and to help pull the group out of the security rat hole that it has got itself in to and to get some forward movement. We should be thanking him and leveraging his experience in academia and commerce in delivering distributed computing systems than flaunting this 'production' grid label around.

Implementations of these 'academic' versions of BES & JSDL are being used in commercial production grids. Don't ask me which - I want to avoid quality time with lawyers. This academic vs. production grids is becoming an increasingly irritating distinction that keeps being flaunted around - and as the conversations in Catania made clear there is no point in trying to come up with a definition.

Yes, CREAM, ARC & UNICORE have interface that are different to BES & JSDL. Yes they have throughput requirements that were not necessarily considered when BES & JSDL were assembled.

But for deployment certification we REQUIRE performance and capability - not a specific function call. There are many ways this can be delivered AND be interoperable.

> I have nothing against
> Andrew taking care of BES and JSDL, but this is not the remit of PGI,
> where "P" stands for "Production".

I'm honestly not sure what to make of this statement! Profiling BES & JSDL is clearly well within the remit of PGI.

Steven