HistoryViewLinks to this page 2013 June 6 | 06:53 am

This is a candidate solution for the Temporary deployment scenarios.

In reaction to the solutions in Temporary deployment: Automation Result state, it was suggested that the deployed resource should be modeled as its own RDF resource, and a link from the Automation Result should mark that resource as a contribution to the result. Then that other resource could have some (well-defined?) means of modeling its state, including the request to tear it down.

These points were raised in response to that suggestion:

  • The fact that the state currently defined for the Automation Result describes the state of the deployment process, and that perhaps a separate state model should be used for the deployed resource once deployment has completed, is a valid point.
  • Would the state use an OSLC-defined vocabulary, or one specific to the resource type? If OSLC-defined, then it seems strange requiring other resource types to use our vocabulary. If from other vocabularies, then there’s no way for a generic OSLC client to achieve teardown.
  • Also, some providers are lightweight adapters/wrappers on to an existing API, and may not want to expose additional RDF resources (plus there may be no appropriate vocabulary to do so).
  • As a compromise, we could define an OSLC-defined state vocabulary, which could be used either on the result contribution resources, or on the Automation Result itself (as a separate state property to the one that already exists), and the consumers should be instructed to look in both locations. This is being tracked as a separate suggestion: Temporary deployment: Separate state vocabulary.