***SPAM*** Sec: Discussion about agrreement of attributes
Hi PGI team, as promised to Etienne and as being part of our security topics is also a refinement of used attributes in our interops reaching an agreement between our infrastructures. Clearly we have the base given by the VOMS AC-defined FQANs - however the structure should be a discussion as well. However, this seems to be very 'EGEE' focussed. I have four topics for discussion in this context: (1) Considering interops between Grids we should provide an attribute that basically indicates if a user may 'belong' to a specific production Grid (e.g.DEISA, EGEE, NAREGI). Currently, VOs seem to be the top hierarchy - however I think it would be good to bring up attributes for that to distinguish at policy level which elements of policies should be used, e.g. users of TeraGrid in DEISA have a special policy, etc. (2) DEISA view, addressing the question of Etienne slightly), taking my talk of OGF25 into account if you would like to know more: Talk about how users can involved with DEISA: http://www.ogf.org/OGF25/materials/1557/2009-03-02_DEISA_DECI_Riedel.pdf Thus DEISA has basically two top-level attributes: DECI projects (that can be maybe categorized in scientifically defined VOs building different groups for each DECI project) and Virtual Communities (that are basically on the same level as DECI projects but completely seperated from it). Given that the virtual community is maybe part of a larger defined scientific group (e.g. astro), I see that also virtual communities can be defined as groups in parallel to DECI projects (so groups) - however, virtual communities have a kind of 'prioritized' access and thus there should be maybe a better differentiation avoiding going to deep in attribute hierarchies. (3) Agreements between attribute differences between job management and data management (4) What do others think about the FQANs and its use - some critics or missing links I maybe have not talked about yet? 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.' ----- Original Message ----- From: m.riedel@fz-juelich.de Date: Monday, March 30, 2009 10:48 am Subject: [Pgi-wg] MWSG Meeting Slides (Drafts)
Hi PGI team,
I received some contributions already and setup a first draft for the slides I will present tomorrow!
They are in GridForge - so please comment the whole day today:
http://forge.gridforum.org/sf/docman/do/downloadDocument/projects.pgi-wg/doc...
The discussions about attributes and constraints I will start just after the coffee break here. ;-)
Best regards from Zuerich, Morris
------------------------------------------------------------------- ------------------------------------------------------------------- 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
------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------
Hi Morris, I see nobody reacted yet on this, and actually it came with a "SPAM" label. FWIW, some comments:
(1) Considering interops between Grids we should provide an attribute that basically indicates if a user may 'belong' to a specific production Grid (e.g.DEISA, EGEE, NAREGI).
No, this an admittedly bad idea. A VO is a VO, a Grid is a Grid. Several Grids may serve the same VO, it already happens. Even if it was not ambiguous, I do not even see where could you place this attribute, and what possibly can make use of it?
Currently, VOs seem to be the top hierarchy - however I think it would be good to bring up attributes for that to distinguish at policy level which elements of policies should be used, e.g. users of TeraGrid in DEISA have a special policy, etc.
This is something to be implemented in the respective Policy Decision Point services of these Grids, or whatever analogous service they utilize. It has nothing to do with a VO. A VO may pre-date any Grid, you can't expect the VO attributes being all re-shuffled every time a new Grid appears or an old one gets renamed.
(2) DEISA view, addressing the question of Etienne slightly), taking my talk of OGF25 into account if you would like to know more:
Talk about how users can involved with DEISA: http://www.ogf.org/OGF25/materials/1557/2009-03-02_DEISA_DECI_Riedel.pdf
I don't see what is the question here? Fine, DEISA has this differentiation between two different kinds of VOs, so what is the implications for others, or for standards?
(3) Agreements between attribute differences between job management and data management
What attributes should be different, and why? Do you think a user can have different privileges regarding job and data management, for example? How will you ensure consistency?
(4) What do others think about the FQANs and its use - some critics or missing links I maybe have not talked about yet?
*I* think it is extremelly VOMS-specific term, and as such is internal to VOMS. I wouldn't spend time on profiling FQANs. Cheers, Oxana
participants (2)
-
m.riedel＠fz-juelich.de -
Oxana Smirnova