HistoryViewLinks to this page Revision from: 2013 August 6 | 05:59 pm
This is the revision from 2013 August 6 at 05:59 pmView the current live version of the article.

This document provides high-level scenario descriptions and links to elaborated scenarios that have been identified by the working group as possible scenarios to be used in driving V3 Automation scenarios

Some scenarios are carry-overs from the Automation V2 scenarios for consideration for V3

Contents


Core Scenarios

Automation Plan Execution Environments

To successfully execute and AutomationPlan, a specific environment is required. Providers should be able advertise and consumers discover this environmental data. This would enable scenarios around provisioning and environment matching. Concepts from the OSLC Reconciliation workgroup are likely relevant.

Automation Agent or Worker Scenarios (V2 Carryover)

Automation Worker scenarios deal with the interactions between an OSLC Automation provider and other entities which perform the actual execution of the automation. Examples are build engines, test automation agents or the worker nodes in a queueing or job scheduling system. Possible goals of specifying these interactions in OSLC would be:

  • provider/worker interactions based on open specification or standard instead of private API
  • provider/worker interchangeability (perhaps, but not necessarily, across automation sub-domains)
  • common patterns for initiating and tracking automation and creating/retrieving results.

Automation Orchestration\Lifecycle Workflow Scenarios (Partial V2 Carryover)

This set of scenarios concerns creation, configuration and execution of multiple automation workflows. An application might be automations which provide ene-to-end coverage of an application lifecycle; orchestrating the execution of builds, multiple types of test and deployment to various test and production environments. Concepts from the Configuration Data scenarios above, the OSLC Configuration Management workgroup and the W3C Linked Data Platform workgroup are likely relevant. Possible goals of specifying these interactions in OSLC would be:

  • Automation provider-to-provider interactions
  • Enable cross-provider workflow composition
  • Apply appropriate automations to environments based on configuration/topology

Temporary deployment scenarios (Tear-down and multiple use)

The results of some automated deployment is temporary, and requires a tear down or clean up stage once it is no longer required. The behaviour of this usage differs depending on whether it is one client or multiple clients who are using the deployed resource. Possible goals of specifying these interactions in OSLC would be:

  • Allow orchestrators or clients to free up deployed resources when they are no longer needed, saving costs etc
  • Enable clients to manage multiple-client use of deployed resources

Automation template scenarios

  • Owner: Umberto Caselli
  • Scenarios: Automation Template Scenarios

    • Some consumers want a template of an Automation Request which is “mostly” ready to use to request an execution.
    • End-user creates the template and schedules it for execution in the future
    • At the future time, the real Automation Request is submitted with perhaps a final few parameter values supplied

Partial Scenarios or Use Cases

OSLC Core V3 Alignment

  • Owner: Michael Fiedler

Automation V3 will need to be aligned with the OSLC Core v3 Specifications. The details of the exact impact are not yet known. W3C LDP workgroup representations of resources and containers, V2 compatibility, linking guidance and authentication guidance are among the topics of interest.

Notifications (V2 carryover) - OUT OF SCOPE for V3

This scenario centers around the ability to receive event-based triggers based on changes to (probably a subset of) OSLC Automation resources, primarily Automation Requests and Automation Results. This is in contrast to the current model of querying (polling) for changes.