index / Automation Meetings / This page

Time: 11:00AM Eastern US (Currently 4pm UTC)

Agenda

• Main agenda items:
  • Specification issues
    • Automation Specification Version 2.0 Issues
      • Any new?
  • Implementation updates
    • Open forum for implementers to provide updates
    • Summarize any new implementation reports
  • Review 3 oct minutes
  • Automation V.next (Post-V2)
    • Automation Scenarios V3 status - Topics TBD based on attendance. Possibilities include:
      • Scenario issues
        • Temporary deployment scenarios
          • Generic “Actions” approach updated: Exposing arbitrary actions on RDF resources
        • Automation Template Scenarios.
          • Umberto updating draft spec - progress?
    • Orchestration Scenarios.
      
      • Charles looking into writing up how orchestration scenarios can be achieved through 2.0 resources
    • Documents:
      • V.next draft specification
        • MF Updated licence & contributor sections
        • Change highlighting - MF
  • Workgroup business
    • Next meeting: 17th October at 11AM Eastern US
• Items for next week (17th Oct):
  • Schedule for convergence/finalisation

Actions from last meeting

Actions carried over/not yet due:

Minutes

Attending: Umberto, Martin, John, Steve S, Mike F, Paul M

• Minutes accepted
• Michael confirmed Actions doc was intelligible
• Umberto’s action for template changes to move to next week
• Charles’ orchestration is companion doc, won’t hold up spec
• Michael made changes to spec draft.
  • We will need to revisit who the contributors are who should be listed
• Highlighting changes:
  • CSS is present for and tags
  • HTML diff tool - can compare the two specs without any work from us
  • Agreed intended approach for showing changes is to use HTML diff tool. Plus adding a note to any new complete sections.
• Actions
  • Applying Actions to teardown
    • Can include rdf:Type of requestBodyParameter’s object in Action’s RDF
      • Prevents a round trip - will always be needed to determine if the consumer can understand this requestBodyParameters
  • In Automation profile
    • Actions have URIs
    • Resource context MUST be in AutoPlan URI
    • update example with changes - MP
  • On plan
    • Reusing action:Action seems acceptable
      • Need Action spec to allow for zero action:request properties, which implies that it is not executable at the current time.
      • We need to allow providers to require parameters, as some actions are meaningless without them. But they SHOULD include a zero-required-parameters implementation if it makes sense to do so (just to encourage implementors to think “how can I make it easy for consumers” - to remind them that some consumers may not have a user present to give parameter values).
  • CM
    • Still want time to apply it to scenarios. Will get back to us.
    • Will define their own profile - only POST
    • This is usable for CM’s scenarios, but more verbose. There are some benefits in clarity in the RDF.
    • CM-defined action rdf:type could imply the values for other triples, if we don’t mind the presence of inference.
      • If CM providers wanted to be consumable from generic providers they would have to include the triples explicitly.
      • Does mean CM’s profile allows it to produce Actions that wouldn’t be consumable by generic Action consumers, but that’s a decision for the CM WG.
      • Can’t think of many generic action consumers of CM state transitions
        • What about dashboards? They could support Actions for generic resources.
• Orchestration in 2.0 resources
  • Data chaining is causing problems. How to get data from one into the other without knowing the implementation details? How do contributions map to input parameters?
  • Most other stuff seems straightforward.
  • Charles will follow up with email.

Actions resulting from this meeting