Entities to be discussed: Service, Endpoint

Phone Meeting

• Date: 16 Nov 2007
• Time: 9 AM Chicago, 3 PM London, 4 PM Rome (conversion to other timezones)
• Duration: 1,5h
• Calling number: +41 22 76 77000 (ask to be connected to "Glue Schema Meeting")
• Shared screen session information:
  • URL: http://glue-wg.glance.net
  • Key: 1611

Agenda

• Scheduling next meetings:
  • Proposal up to the end of November
    • 20/NOV, 22/NOV, 27/NOV, 29/NOV
    • 1,5 h starting from 3 PM UK
• LDAP Implementation (left from yesterday telecon)
• Discussion about examples of Service, Share, SharePolicy, ShareState and UserDomain
• AOB

Meeting Material

• Latest XML Schema and examples
• Example LDIF
• Latest GLUE 2.0 spec
• Example Relational Model

Participant

• Sergio and Marco (INFN-CNAF)
• Felix and Laurence (CERN)
• Stephen Burke (RAL)
• Shiraz (FZJ)
• Balazs (Lund University)

Minutes

Next telecons:

• 20,21 Nov - 4 PM UK - 1,5h
• 27,29 Nov - 3 PM UK - 1,5h

LDAP

DIT

• Balazs: we need to specify also the DIT

• Laurence:
  • two styles of rendering
    • single entry style
    • multiple entry style

• Stephen: dn should be called using ID
• Sergio: dn should be built using classNameAttributeName

Prefix/Namespace

• Prefix
  • Should be use commont prefix/namespace in the attributes?
  • Balazs: no, OID is the identifier

• schema A:
  • objectclass: GlueLocation
  • attributeName: Location

• schema B:
  • objectclass: XXXLocation
  • attributeName: Location

if I configure an LDAP server to load schema A and B location attributes will collide

• to be investigated by Laurence;

• • drop prefix from attribute names

• • add prefix GLUE to both attribute names

Representing relationships

• dn: ComputingServiceID="..", AdminDomainID=""
• dn: ComputingEndpointID="A", ComputingServiceID="..", AdminDomainID=""
• dn: ComputingEndpointID="B", ComputingServiceID="..", AdminDomainID=""
• dn: ComputingShareID="A", ComputingServiceID="..", AdminDomainID=""
• dn: ComputingShareID="B", ComputingServiceID="..", AdminDomainID=""
• dn: ComputingResourceID="B", ComputingServiceID="..", AdminDomainID=""
• dn: ComputingEndpoint_Share="AandB", ComputingServiceID="..", AdminDomainID=""

• Stephen: at which level we publish the relationships? especially for those belonging to different levels of the DIT or being published by different publishers (i.e. GRIS in gLite)

Resolving relationships

• about query:
  • Stephen: it would be nice to see the queries to resolve relationships
  • Sergio: possibly require 3 queries
  • Balazs: you can run them at the client side, you get the sub-tree and then check at the client

• for the rendering, it is still early to work at the attribute level
• suggestion: extend to design the DIT and the way to model relationships

Back to the GLUE Spec

• Endpoint Class
  • Stephen: Steve was suggesting that we should

• • Sergio: this problem was raised also in the past
    • can be seen in two different ways:
      • should be model and reflected in the conceptual model
      • not a concern of the conceptual model,

• Action: verify for each class what are the dynamic attributes

• • for endpoint, only state and stateInfo are the dynamic values

• if we isolate dynamic values in independent classes,

• e.g.:
  • <endpoint ID="">
    • <endpointState>
    • </endpointState>
  • </endpoint>

• Capability:
  • Stephen: do we keep capability both here and in service?
  • Sergio: will provide initial enumeration for both then we discuss again

• ServingState: open, close
• AcceptingState: open, close

vs.

• ServingState: production, draining, closed, queueing

• Stephen:
• Suggest downtime info go in a different object
• evalute if 1-to-many relationship should apply
  • an endpoint having multiple scheduled downtime
• TrustedCA should go together with access control information

Action

• Balazs: to check if UR WG adopt dateType XML Schema type or POSIX timestamp
• Laurence: investigate the pro/con of having prefix in ldap attributes/classes names
• Sergio: draft list of service/endpoint capabilities