OSLC Automation Spec V1 Issues
This section captures the issues raised via review comments on:
Issues are organized via the specification outline.
Note: dates below use US format (mm/dd/yyyy)
Here's what the states mean:
- OPEN - indicates that we have no response for the issue yet
- RESOLVED - indicates that we have a response that we believe resolves the issue
- RESOLVED - indicates it is resolved as by above definition and edits in the draft specification have been made.
- CLOSED - issue has been resolved and the resolution has been reviewed by the workgroup
- DEFERRED - indicates that issue will be addressed in guidance after the specification converges
- TABLED - indicates that issue will be reconsidered at some later but unspecified date
Issues during draft development
- TABLED - Suggestion from JohnArwe: Move the compliance table to an appendix and reference it here. Different from what other specs do but potentially more friendly for casual readers.
- The compliance table is still in the body - but it has been updated to improve readability. (MichaelFiedler, 16 Feb 2012)
- RESOLVED - The Core specification makes Query Capabilities and the OSLC Query Syntax MAY items. Currently, they are defined in Automation as MUST (cf. CM and QM specification). Do we want to relax these requirements for Automation? or keep them as MUST?
- Workgroup consensus is that they remain as MUST requirements.
- RESOLVED - The current specification defines an
oslc_auto:automationinstructions
attribute on Automation Plans. Intent is to capture (reference or inline) a service provider specific resource representing how an automation will be executed. This could be a script, binary, text instructions representing what the automation will do, etc. Is this required for the V1 scenarios.
- Workgroup consensus is that these instructions are not required for the scenarios in V1 of the specification.
- OPEN - State enumerations. There are at least three attributes in the automation request and result which could have an enumerated set of values:
oslc_auto:status
, oslc_auto:desiredStatus
and oslc_auto:verdict
. Does the specification need to specify the legal values for these attributes? See the CM spec's definition of state predicate properties for a possible approach: CmSpecificationV2#State_Predicates and CmSpecificationV2#Resource_ChangeRequest.
- 21 Feb 2012: Specification updated with state predicates for
oslc_auto:verdict
. Still open: Are state predicates needed for oslc_auto:state
and oslc_auto:desiredState
?
- RESOLVED - the relationship from an Automation Request to an Automation Plan was recently changed from exactly-one to zero-to-one. Objections? There seems to be a possible use case where you create the request in some holding state and later hook it to a specific test plan and move the desired state to ready-to-run state. Too advanced for V1?
- Workgroup consensus was that Automation Request -> Plan and Automation Result -> Plan should be exactly-one. Spec updated
- RESOLVED - Automation Results currently refer to exactly-one Automation Request and exactly-one Automation Plan. Should these be zero-to-one. Can results be created in the absence of plans?
- Workgroup consensus was that Automation Request -> Result should be zero-to-one and Automation Result -> Plan should be exactly-one. Spec updated
- RESOLVED - Need the workgroup to review the delegated UI table and come to agreement on MUST/SHOULD/MAY for each artifact type.
- 21 Feb 2012 - Reviewed by workgroup - no disagreements raised
- OPEN - Parameter Definitions have been partially restored in the spec (Description of them, HTTP support table). Should they be a separate resource type or just left as defined in the Automation Plan with a range of oslc:Property?