Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Wiki Pages Project: GLUE     Wiki > PhoneMeeting20071121 > View Wiki Page
wiki1908: PhoneMeeting20071121

Entities to be discussed:

Phone Meeting

Agenda

Participants:

  • Sergio Andreozzi (CNAF)
  • Michele Carpenè (CNAF)
  • Marco Canaparo (CNAF)
  • Stephen Burke (RAL)
  • Balazs Konya (Lund University)

Apologize:

  • Shiraz Memon (FZJ)
  • Felix Ehm (CERN)
  • Laurence Field (CERN)

Minutes Review

  • Accepted

Review Open Questions since last OGF sent to the list

Discussing UserDomain

  • Stephen: do we have a model for VO's organized in hierarchy?
  • Sergio: VOMS supports VO's described as DAG
  • Stephen: yes, but at the moment we use FQAN to express policies; EGEE has a WG working on defining policies for Computing and Storage Resources; e.g.: LCAS/LCMAPS have order in applying rules, we may need to capture them
  • Open Questions:
    • in policies, you have a subject; this subject is expected to be published in the information service? (e.g., group as UserDomain)
    • how do we render the Policy in XML; i.e. what is the parent element?
    • can we have policies expressed following different schemes for the same entity?
    • added action: artf6080

<AdminDomain ID="urn:infn:cnaf">

  • <Service ID="urn:infn:cnaf:wms">
    • <Endpoint ID="urn:infn:cnaf:wms:wmproxy">
    • <AccessPolicy>
      • <Scheme>VOMS-FQAN</Scheme>
      • <Rule>VOMS:/CMS/Production</Rule>
      • <TrustedCA></TrustedCA>
      • <TrustedCA></TrustedCA>
    • </AccessPolicy>
    • <AccessPolicy>
      • <Scheme>NORDUGRID</Scheme>
      • <Rule>VOMS:/CMS/Production</Rule>
      • <TrustedCA></TrustedCA>
      • <TrustedCA></TrustedCA>
    • </AccessPolicy>
    • </Endpoint>
  • </Service>
</AdminDomain>

<AdminDomain ID="urn:infn:cnaf">

  • <Service ID="urn:infn:cnaf:wms">
    • <Endpoint ID="urn:infn:cnaf:wms:wmproxy">
    • ....
    • </Endpoint>
  • </Service>
  • <AccessPolicy>
    • <Scheme>VOMS-FQAN</Scheme>
    • <Subject>....<Subject>
    • <Rule></Rule>
    • <TrustedCA></TrustedCA>
    • <TrustedCA></TrustedCA>
    • <TrustedCA></TrustedCA>
  • </AccessPolicy>
</AdminDomain>

<UserDomain ID="urn:VO:CMS">

  • <Level>0</Level><
</UserDomain>

<UserDomain ID="urn:VO:CMS:production">

  • <Level>1</Level>
</UserDomain>
  • back to userDomain
    • Balazs: main purpose is to describe VOs or groups
    • Sergio: the missing information is if this should be explicitely referenced by Policies or not; how it should be used in policies
    • Stephen: we could decouple UserDomain and UserGroup
    • Sergio: having a common entity can give more flexibility in query
      • e.g.: to query VOs: Level=0, to query up to third level: Level<3
      • moreover, most of the attributes are optionals
    • Stephen: decoupling is good for relational implementation
      • we should ask for opinions from othe Grids
  • ManagerService: change to Endpoint, it was defined before the change of Service to Endpoint
    • Stephen: we may need more attributes, in EGEE there are different types of VOs
      • e.g.: approved VOs, regional VOs
    • Stephen: we may also want to represent Grids such as EGEE, GridPP
    • Balazs: we can use adminDomain
    • Sergio: we have both hierarchical associations and peer relationships

New actions:

 




The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help