Automation Additional Relationships Proposal

Contents

• Introduction
• Scenarios
  • Deployment requiring automated teardown
• Proposal
• Examples
  • Deployment and teardown
  • Application to Orchestration scenarios

Introduction

During the Automation Scenarios V3 discussions in the workgroup, a requirement has surfaced to relate Automation Plans to each other and to relate Automation Plans to the types of resources they are capable of producing. Both the Temporary deployment scenarios and the Automation Workflow Scenarios have aspects to them which require being able to make these connections. This document presents a proposed approach for workgroup discussion.

Scenarios

A scenario will be used to illustrate this proposal:

Deployment requiring automated teardown

This scenario is documented in full here. In summary, a consumer needs to be able to determine which Automation Plan deploys virtual services and which Automation Plan can be used to un-deploy or teardown the resources when they are no longer needed.

Proposal

Add one new attribute and four new relationships to the Automation Plan resource:

If more than one oslc_auto:sequentialAutomationPlan link is present, the links represent a collection of plans from which the next one in sequence can be selected. No order of execution is implied.

IF a consumer who created the automation request knows when the produced resource is no longer required, it SHOULD call the reversal plan when the produced resource is no longer required. (For example, if it needs a deployment for a specific program execution, when that execution has completed it would then call the reversal plan as the need for the deployment has passed.)

Alternative Approach: Instead of creating 4 new relationships, just create 1: oslc_auto:hasRelationship and use reified statements to further qualify the type of the relationship. Define 3 enumerated constants in the specification for use in the reification: oslc_auto:reversion, oslc_auto:sequential and oslc_auto:parallel.

Add one new attribute to the Automation Result resource:

Examples

Some partial turtle examples illustrating the use of the above attributes for the scenarios. No guarantees on syntactical correctness right now.

Deployment and teardown

• The initial Automation Plan for deployment:

<http://example.com/autoPlan/123>
   a oslc_auto:AutomationPlan;
   ...
   oslc_auto:produces crtv:ServiceInstance;
   oslc_auto:reversionAutomationPlan <http://example.com/autoPlan/456>.

• The resulting Automation Result

<http://example.com/autoResult/123>
   a oslc_auto:AutomationResult;
   oslc_auto:produced <http://example.com/virtualServiceInstances/789>
   ...
   oslc_auto:reportsOnAutomationPlan <http://example.com/autoPlan/123>;
   oslc_auto:contribution [
      crtv:name "Instance ABC of Application XYZ";
      privateNS:serviceLocation <http://example.com/virtualServiceInstances/789>;
      privateNS:serviceExpiration 10d;
   ].

• The teardown AutomationPlan

<http://example.com/autoPlan/456>
   a oslc_auto:AutomationPlan;
   ...
   oslc_auto:inputParameter [
      oslc:name "serviceToTeardown";
      oslc:valueType oslc:Resource;
      oslc:range crtv:ServiceInstance;
      oslc:propertyDefinition <http://open-services.net/ns/auto#ParameterDefinition>;
   ].

• Finally, the Automation Request for the teardown

<http://example.com/autoRequest/456>
   a oslc_auto:AutomationRequest
   ...
   oslc_auto:inputParameter [
      oslc:name "serviceToTearDown";
      rdf:value <http://example.com/virtualServiceInstances/789>;
   ].

Application to Orchestration scenarios

For the Automation Workflow Scenarios, the idea that these workflows could be linear or could branch and merge has been discussed. The above relationships would help support sequential/linear (oslc_auto:sequentialAutomationPlan) and branching (oslc_auto:parallelAutomationPlan) but do not address merge. The oslc_auto:reversionAutomationPlan also allows a kind of “popping of the stack” depending on how it is used and implemented by the provider.