EMI JRA1 Data Area GLUE2.0 FAQ

This document records the Working Group decisions about consistent interpretation of the GLUE2.0 spec. It is intended to be read alongside the specification.

About the WG

  • Q: Which components are concerned?
    • A: dCache, DPM & STORM, and relevant clients. Other services such as FTS will have to implement GLUE2.0 but are not explicitly involved in the WG.

  • Q: What InfoSys implementation are we interested in?
    • A: The current EGI one, ie BDII.

  • Q: How will the work be validated?
    • A: By the creation of gstat2 probes, which can subsequently be reused for production monitoring

  • Q: How should the info providers be configured?
    • A: All concerned services use YAIM, so changes here must be coordinated

General GLUE2.0 observations

  • Q: Which entities are required?
    • A: All entities are expected to be necessary

  • Q: Which attributes are required?
    • A: Attributes which are optional according to the spec can be identified by a multiplicity which includes the value '0'. The WG maintains a list of such attributes which it regards as mandatory, the rest are at the discretion of the implementers. Mandatory list:
      • All capacity related attributes, FreeSize, ReservedSize, UsedSize etc...

Particular Attributes

  • Q: How do we ensure unique IDs?
    • A: Implementer should pick a hostname which is associated with the service and reasonably persistent, and append the string '/data'. They can then append further information as they see fit. Note that this is not intended to be parsed.

  • Q: Which Type is my service?
    • A: servicetype_t is an open enumeration. Use a type of org.emi-eu., eg org.emi-eu.dCache.

  • Q: Do we need to create new capabilities?
    • A: No, capabilities are optional.

  • Q: Do I need to list all the trustedCA records
    • A: No, it's optional, ignore it.

  • Q: How is QualityLevel handled
    • A: This should be configurable by the administrator, so they can indicate the level of service expected.

  • Q: What do the *Size attributes mean?
    • A: Where possible, the "Usage of Glue Schema v1.3 for WLCG Installed Capacity information" should be considered authoritative. This may require further discussion.

Glue 1.3 Mappings

  • Q: How are the GlueVOInfoLocalID entry to be handled?
    • A: A StorageShare should be created for each GlueVOInfoLocalID entry, this includes details such as 'Path'

  • Q: What should be done with the GlueService entries currently published for SRM?
    • A: These are no longer required as the relevant information should be in StorageEndpoint

  • Q: What about GlueServiceDataKey for glite-version etc?
    • A: Ignore this for GLUE2.0

  • Q: How do we handle a GLUE 1.3 GlueSA with N>1 GlueVOInfo entries in GLUE 2.0?
    • A: N Glue 2.0 StorageShares with a common SharingID

Other Issues

  • Q: How can a site publish the full managed capacity they offer, even if at any one time some of it is unavailable, eg for maintenance?
    • A: A special StorageShare can be created for this purpose. A convention would need to be established to identify it.

  • Q:
    • A:
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2011-01-18 - OliverKeeble
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback