Skip to content

Actions Specification Strategy

Jump to bottom
Jim Amsden edited this page May 6, 2019 · 1 revision

Notes taken when analyzing the strategy for OSLC Core 3.0 and support for Actions.

Actions status

  1. The specification is incomplete and there is no document editor assigned
  2. There is no one on the Core TC that has the background sufficient to contribute to this specification
    1. Other than Martin or Nick who have limited time due to work on other specifications
  3. Actions are referenced in the CM specification to change the state of a change request (although the actions and bindings are not specified in the CM specification): OSLC CM servers may allow ChangeRequest state change through [OSLCActions].

The CM TC started work on a separate CM actions spec, but then deprecated that waiting for Actions in Core to develop. They will then create an Actions profile to do CM functions. This didn’t expose a complete state machine. Change request have an oslc_cm:state property that describes the current and target states.

Why was this exposed in a standard way? There was a Requirement to track changes, through references, suspect links, reviews and approvals. Requirements link to change request and need to be able to update the change request. There was no standard way of changing the change request state other than GET and PUT. Many requirements tools don’t allow simply changing the state, they also required users to to provide a resolution. This couldn’t be describe using a simple PUT. DOOR9 and RRC had different ways to do the state change, and a standard way was needed.

Perhaps a better solution is to keep the enforcement of these constraints in the servers that manage the resources. Attempting a PUT on a change request should fail if there is missing information or the oslc_cm:state cannot be changed from its current to new value for any reason. It would be the CM tool that would do this, not the RM tool as the CM tool is where the process descriptions and change request states and rules are created. If a delegation dialog is used to change the state, then the constraints could be handled directly by validation in the dialog.


  4. The Config-mgt spec used to indicate servers MUST implement Actions and SHOULD implement Automation. Actions that must be provided include:
    1. create a stream
    2. create a baseline
    3. finding a configuration that has a given component
    4. creating a new stream
    5. committing a baseline
    6. etc.
  5. Actions has now been removed, but Automation are still planned to be used.
  6. CM Actions specification 3.0 was deprecated and was intended to utilize Core actions. These actions were only state transitions on a change request, not general actions. Moved to oslc-domains TC: change-mgt-actions.html, but was never completed
  7. Do these operations need to be standardized? Is Actions the right way to do it? Could it be done in a domain specific way for Config-Mgt?
  8. Code.Speaks is an attempt to implement OSLC Automation in a simpler way. It was a general experiment to build an OSLC provider as simple as possible using REST and Agile principles. It was not specifically Automation, but was targeting issues with OSLC Automation 2.0. Code.Speaks doesn’t address Actions.
  9. Are we in a position to standardize Automation and Actions?

Actions is probably not as simple as it could be. Automation is much more complicated, and was never completed or implemented. This implies we may want to defer these specifications until we have studied them further.
  10. Should we consider leaving the Automation and Actions 2.0 specifications and gain more experience in “active” resources (having a state machine capable of RESTful events and actions), Pipeline before introducing these as OASIS standards?

That would be OK, but a TC specification should probably not normatively refer to non-standard specifications. It can, its up to the TC to decide if this would be a barrier to standardization.
  11. If Actions is in the Core TC, would there be any expectations on servers to implement it?
    1. What is MUST in Core? This is not entirely understood. The different specifications in Core could be considered different options that servers could implement. This needs to be clarified. No core capabilities are a MUST, all are MAY or SHOULD and optional. The MUSTs apply to how a capability is provided if it is provided.
  12. Should Actions be moved into Automation as they are cross-referenced?

April 8, 2015 Call to discuss the state and future of the Actions specification Martin P Pain/UK/IBM@IBMGB, Nick Crossley/Irvine/IBM@IBMUS, Samuel Padgett/Durham/IBM@IBMUS

Can a CM 3.0 spec depend on an open-service.net specification. Could be referenced in a non-normative way. This was done with a generic property to refer to non-normative Resource Shape. Just reference some mechanism for describing

CM does require query support already. Can possibly change that. If CM is the only 3.0 spec using it, then too heavyweight. If deferred out of CM, would have to rely on POST only. But not right to have the whole of actions for only config-mgt. Core overview doesn’t say what the MUST, MAY or SHOULD on the spec parts The intent is that each Core spec/capability is optional - you could just implement Preview.

Nick wouldn’t want to do some subset of an Actions specification that may or may not exist. Would go back to LDP-BCs new one for every stream that would be the container for each baseline on that stream. Header to describe how long it would take. Client would have a different logic flow. Create a stream is a simple POST, can be done instantly and is not recursive. Concerned about the performance aspect of LDP-BCs because of the memberships triples that have to be maintained. A Stream could be an LDP container for baselines. The problem with LDP-BCs is that membership triples are mandatory with a specific predicate - can reuse an existing triple, but have to use the standard one too. Everything has to be reflected in LQE. Every triple has to be considered. Could be a very large number of members of a configurations. Creating a new baseline could result in millions of triples.

Use an action to create a resource instead of POST. There is a container of all the baselines and streams - a component. An action creates a whole set of baselines in different containers. A POST on a specific container that effects other containers doesn’t seem right. Action can post to something that isn’t a container.

CM group meets tomorrow. Nick will bring the topic up there. He won’t post his Actions dependent version (keep the current TBDs in place) and discus for both the CM and config-mtg spec. If CM doesn’t want to push Actions, then config-mtg shouldn’t either. Sam will be on the call for CM.

This is to confirm we will have a meeting of the OSLC CCM TC tomorrow (April 8, 2015) at 10am US Eastern Time, 7am Pacific. There is one main topic to discuss: the possible removal of dependencies on the Actions specification. For Change Management, this might mean defining a simple way to update states on change requests that's specific to Change Management, or even not including state transitions at all for Change Management in 3.0. For Configuration Management, this would mean using additional LDPCs for streams to create baselines of those streams, and probably exposing additional link headers to expose other capabilities.

In terms of capability, there is no dependency on Actions, some difference in client interactions, but isn’t an issue yet, no implementation costs as no-one has implemented

All of Config Mgt specifications are somewhat speculative. OSLC is not the typical configuration management. No specification on how a resource is created or is put under version management. Its all about managing configurations of configurations - never been done before.

Actions is over specified for CM.

Main links

Clone this wiki locally