GLUE2.1 related changes to the AppDB RESTful API

In GLUE2.0, the templates (instance types) that each site service endpoint provided where applicable to all VM images provided by the same endpoint. With the advent of GLUE2.1, a new high-level concept got introduced, the “share”, which groups images and templates and binds them to a specific “policy”, such as a VO. In order to properly support GLUE2.1, some endpoints of the AppDB RESTful API had to be revised with small backwards-compatible changes.

API consumers will notice an increase of almost-identical templates and images in responses API of relevant resources, most of them differentiated only by the VO they belong to. Clients should honor the VO specified inside templates, in order to have valid image/template pairs. Some examples follow:

Sites Resource

Querying the “sites” resource for the “INFN-CATANIA-STACK” site:

https://appdb.egi.eu/rest/1.0/sites/91514G0

In the response below we see that each “provider:template” element has a nested “vo:vo” element; this means that the template in question only applies to images for the vo.dariah.eu VO. The same logic applies to JSON-encoded responses as well

XML:

<provider:template group_hash="0f275a44a422dc1626574af3c1fa481b">
        <provider_template:resource_id>8c3bded5-f640-4870-8ed0-f73d3f8eca8e</provider_template:resource_id>
        <provider_template:resource_name>8c3bded5-f640-4870-8ed0-f73d3f8eca8e</provider_template:resource_name>
        <provider_template:main_memory_size>2048</provider_template:main_memory_size>
        <provider_template:logical_cpus>1</provider_template:logical_cpus>
        <provider_template:physical_cpus>1</provider_template:physical_cpus>

        ...

        <vo:vo id="15524">vo.dariah.eu</vo:vo>

        ...

        <provider_template:cpu_multiplicity>singlecpu-singlecore</provider_template:cpu_multiplicity>
      </provider:template>

JSON:

"template": [
  {
    "group_hash": "0f275a44a422dc1626574af3c1fa481b",
    "resource_id": "8c3bded5-f640-4870-8ed0-f73d3f8eca8e",
    "resource_name": "8c3bded5-f640-4870-8ed0-f73d3f8eca8e",
    "main_memory_size": "2048",
    "logical_cpus": "1",
    "physical_cpus": "1",

    ...

    "vo": {
      "id": "15524",
      "value": "vo.dariah.eu"
    },

    ...

    "cpu_multiplicity": "singlecpu-singlecore"   
  }
]

Some issues to note:

  • “siteservice:image” elements in the response already contained the VO information, nested within the “siteservice:occi” sub-element, and thus have not changed in this respect.

  • for compatibility’s sake, in order to reduce the need for refactoring 3rd party API clients, the name of the occi element in image data sections and occi_endpoint_url in the top level of the site service response has been preserved, and is used even if the site service endpoint is that of a native API, such as OpenStack.

  • Consumers should also retrieve the projectid attribute of the “siteservice:occi” element under “siteservice:image”, which is necessary to make authenticated actions for the specific image, when the endpoint uses OIDC.

VA providers resource

Similar changes apply to the “va_providers” API resource, where a “vo:vo” element has been added to each “provider:template” element, and the “projectid” attribute to each “provider:image” element.

The new GLUE2.1 schema has introduced new entities such as shares and managers which in turn break the previous schema. Also to avoid future namespace collisions we changed the endpoints layout. You can view the current schema on the AppDB Information System APIs

Changes in rest endpoint layout:

- /rest/sites/{siteId}/services -> /rest/sites/{siteId}/cloud/computing/endpoints
- /rest/services -> /rest/cloud/computing/endpoints
- /rest/images -> /rest/cloud/computing/images
- /rest/templates -> /rest/cloud/computing/templates
- /rest/statuses -> /rest/monitor/status
- /rest/downtimes -> /rest/monitor/downtimes