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
Related: Scenario of usage by orchestration - an attempt to pull together a scenario of different areas of the spec (v2 and proposed v3) that cmight be used by an orchestrator (whether OSLC-based or any other technology, as long as it can consume OSLC).
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
Partial Scenarios or Use Cases
OSLC Core V3 Alignment
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.
