• Date: 03 April 2008
• Time: 4 PM CET (conversion to other timezones)
• Duration: 1,5h
• Calling number: +41 22 76 77000 (ask to be connected to "GLUE Meeting")

Agenda

• still open: architecture in StorageCapacity - an open enumeration ?
• clearify necessity for StorageShare.Type - is the replacement by ExpirationMode sufficient?
• Resource 1..* --- 1..* Environment
• Comments on Pauls description for the entities

Participants

• SB, Stephen Burke (RAL)
• JJ, Jens Jensen (RAL)
• ML, Maarten Litmaath (CERN)
• FE, Felix Ehm (CERN)
• OS, Owen Synge (DESY)
• PM, Paul Miller (DESY)

Minutes

• StorageShare.Type:

• StorageCapacity.Architecture:
  • ML notes that for WLCG this does not have any senseful meaning.
  • FE pointed out that the attribute has been moved within schema entities already 3 times which reflects that there is no clear opinion about the meaning and that it cannot be assigned to any entity adequately.
  • ML remembered that in Glue 1.3 this attribute was pushed only by management in order to spell things out as they are.
  • OS raised the issue that although the architecture is optional there is the danger of becoming important over the time.
  • SB asked what the use-cases for this information are.

ACCEPTED: remove Architecture from StorageShare

• Resource 1..* --- 1..* Environment (raised from PM description discussion)
  • FE brought up the example of having a StorageService containing two resources (StoRM + TSM) creating ONE StorageEnvironment (custodial-nearline)
  • ML stated that the idea of changing the relationship actually supports a use case demanded by Flavia Donno to identify storage resources with buggy software versions.

ACCEPTED that this relation is needed in order to satisfy those use cases.

• Comments on Paul's description for the storage entities:
  • PM offered to publish a new version of a description of the entities he had sent around wher most comments from JJ and ML are included. The descriptions are going to be put into the schema document when have been iteratively refined.

• AOB
  • SB mentioned the missing feature of the old CESEBind entity
  • JJ stated that this could also be right place to put information like local available protocols

There is a common opinion that the binding shouldn't be too complicated (e.g. adding VO specific access policies). It should be an entity which describes minimally the binding of a ComputingService to a StorageService. discussion continues next session