Oxana, I don't believe the objective was to separate the discussion from the main group - rather to accelerate overall progress by doing two concurrent tasks. That's why we wanted to separate out the JSDL/BES stuff, so that we would not need to wait for agreement on security to make progress on the JSDL/BES/GLUE stuff. On a separate yet related note. One of the problems in coming to consensus in OGSA-BES was on meta-data retrieval, specifically around WS-RF. There was a strong contingent against WS-RF, and so we have the bes get_attributes method. Now for my question: do all of the "production grid infrastructures" participating in PGI support WS-RF? (Genesis II supports the OGSA-WSRF-BP, and I think Unicore does, and so does Globus). A -----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Oxana Smirnova Sent: Monday, March 16, 2009 12:44 PM To: pgi-wg@ogf.org Subject: Re: [Pgi-wg] PGI TelCon 2009-03-13 Meeting Minutes available for Comments Hi all, I posted the following comments to gridforge: == - No splitting,please. If the group grows too big to be maintained, it will need to be reduced to its original efficient core. - 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. I have nothing against Andrew taking care of BES and JSDL, but this is not the remit of PGI, where "P" stands for "Production". == Cheers, Oxana m.riedel@fz-juelich.de пишет:

Hi PGI team,

as having no secretary today I drafted (not necessarily complete) minutes, which are available in GridForge:

http://forge.gridforum.org/sf/discussion/do/listPosts/projects.pgi-wg/discus sion.meetings.topc4258

Please feel free to comment on the miuntes.

More precise actions in preparation for the telcons will follow ASAP.

Take care, Morris

---------------------------------------------------------------------------- ----

Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany

Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel

Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656

Skype: MorrisRiedel

'We work to improve ourselves and the rest of mankind.'

------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich

Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- ------------------------------------------------------------------- _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

as far as I know, gLite does not currently support WS-RF. For sure, the gLite CREAM execution service does not.

I'm not aware of any EGEE service in production use that is based around WS-RF. But sending an email like this is the best way of finding out! Steven

Andrew Grimshaw wrote: [...]

I'm not suggesting that we make WSRF a requirement by any stretch of the imagination ...

I would like to contribute my point of view to the discussion about existing specifications. I'm personally not against any existing WS-* specification, and I'm willing to implement everything we decide is necessary for our "PGI-profile" (or "PGI-specification", or whatever). However, from a strictly technical point of view, my concerns can be summarized by the attached diagram. Each node denotes a WS-* specification; the red nodes are the WS-RF specification family. I put an arc from X to Y iff in the "Normative References" section of document X there is an entry for document Y. Note: this does _NOT_ mean that specification X strictly depends on specification Y, but it was easy to quickly understand the "relations" among specifications. Furthermore, I stopped at the first level (I did not check the "dependencies" of WS-Topics, WS-BaseNotification and so forth, but I think that it would be a nice exercise to try some day...). The general point is that the WS-* family of specifications has internal dependencies which make implementation efforts quite time consuming, because you not only need to support specification X, but also all other specifications which X depends upon. Note that there are some libraries implementing some of these specifications (in the past, for example, we used OpenSAML to support the SAML specification), but nevertheless specific hooks to these libraries must be made in the main application code, which is still time-consuming. In my opinion there is a solution around this problem, and is exactly we discussed about the WS-SecureAddressing specification. Should we decide that a PGI-compliant execution service MUST implement specification WS-X, we should explicitly state which (hopefully SMALL) strict subset of WS-X MUST be supported; the rest of WS-X of course MAY be supported, but that is not required. In this way I hope that implementers won'd need to skim through hundreds of pages of additional specifications, and needing to implement them as dependencies for our PGI stuff. For the WS-SecureAddressing stuff we talked about requiring to recognize basically a URI embedded inside a small XML fragment containing an appropriate namespace telling which security setting the endpoint supports. If we are able to state that in a precise and hopefully self-contained way, I think that we will make implementers (starting from myself :-) ) extremely happy. Moreno. -- Moreno Marzolla INFN Sezione di Padova, via Marzolo 8, 35131 PADOVA, Italy EMail: moreno.marzolla@pd.infn.it Phone: +39 049 8277103 WWW : http://www.dsi.unive.it/~marzolla Fax : +39 049 8756233

- 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

I was not intending to withdraw from the security discussion - but to do both. A

-----Original Message----- From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of Oxana Smirnova Sent: Monday, March 16, 2009 5:07 PM To: pgi-wg@ogf.org Subject: Re: [Pgi-wg] PGI TelCon 2009-03-13 Meeting Minutes available for Comments

...

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

True, Andrew was exactly the one who brought the previously not addressed security issue to this group on January 7, and I support him, as I agree it is an important point. Now, I do not see how exactly the group will be helped by Andrew withdrawing from the activity he started. Or maybe I misunderstood things, and he is going to keep pulling in both directions?

As for the call on Wednesday, I suppose we have the 3 co-chairs who have full powers to decide on this. Please let us not repeat the same trick as last Friday.

Cheers, Oxana _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

And one more coment here:

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.

I'm hearing of not-to-be-named elusive commercial grids quite often, and I'd love to learn from their experience. If they are happy with the existing standards - good for them. Being so much shrouded in secrecy, they obviously have no need to interoperate. In our case, the key motivation has been clear: interoperability between 3 specific non-secret production grids; this group spawned from GIN and thus it is not surprising indeed that it has problems often opposite to those of secret grids.

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.

Can't tell for BES, but for JSDL all our requirements were quickly and famously deemed to be out of scope. You JSDL guys even took pride in it and printed a T-shirt ;-) Seriously, one key fragment in this picture is GLUE2, which was developed mostly by gLite, ARC and Unicore people, and the very origin of PGI lies in integrating these 3 standards. Obviously, those who do not need GLUE2 may have a different opinion, but PGI started as a BES/JSDL/GLUE2 integration effort, and its motto used to be "Stay focused".

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.

In infrastructures driven by user needs requirements can be quite specific, and definitions of performance may vary. For example, WLCG has even a special SRM 2.2 MoU, describing such extremely specific details, it makes people crying. This is of course an extreme example, but I will be surprised if there is any EGEE user who is concerned about standard interfaces. They are however interested to see (a) their jobs running the way they like it and (b) their jobs running everywhere. There's also very important (c): since public money are involved, politicians want to see it blinking and beeping, this is why Laurence added latitude and longitude to the mandatory Glue attributes ;-) I have a nagging feeling that GLUE2, being the raison d'etre for this group, is falling between the cracks. I hope these historical background notes of mine help to clear up misunderstandings. Cheers, Oxana

hi Steven, pgi folks Steven Newhouse wrote: Re: [Pgi-wg] PGI TelCon 2009-03-13 Meeting Minutes available for Comments

Which started off with a secret meeting at CERN and is now continuing with the co-chairs going off into a closed huddle to define their requirements! Hmmm... openness!

- That meeting was called by the needs of the three middleware teams ARC/gLite/Unicore. - we wanted to synchronize the way we extend/use JSDL/BES/Glue since all of us had to extend these specs because we found that they were not suitable for our requirements, these *specs without extension* were only useful for us to participate in interop demos on SCxx and co. - the fact: none of the three middleware teams could go to BES/JSDL/GLUE as it is, that would have been a disaster and a huge lost of functionality - we realized that there may be a need for a radical change, a slight profiling may not be sufficient. - the term "production" came as an opposite to the "hello grid demo" world. - then we were invited to move our activity under OGF. - ... and the progress slowed down, we couldn't even finish with cleaning up our own drafts. - everything, including all the draft internal notes are in the gridforge. There is no "secret" any longer.

The WG chairs seem to want to serialise and slow down the progress... there seems to be willingness within the WG to parallelise and speed up. Interesting contradiction! I think this is the first time of seen this at OGF!

Steven, the available human resources of the three middleware teams are finite. There are things you can't parallelise. The group started outside of OGF as a dedicated activity to solve the problem of the 3 software stacks. We still would like to achieve that even within OGF. We believe that we can be more efficient if we formulate our own ideas ourself. Give us time to write up the drafts available in the gridforge in a better consumable form. bye, Balazs