index / Automation Meetings / This page

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

Agenda

Chair: Martin

• 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 17 oct minutes
  • Action from last meting:
    • Timeline for PostV2 - TODO: Detail who will be the first ‘trial’ implementors, and determine when they can try implementing it.
    • New oslc:usage URI for template creation dialogs - TODO: #templateCreation should be #TemplateCreation
    • Actions - TODO: getting proposal more spec-ready
  • Automation V.next (Post-V2)
    • Automation Scenarios V3 status
      • Nothing to discuss on: Automation Template Scenarios done, apart from action above. Temporary deployment scenarios being covered by “Actions” work.
      • Orchestration Scenarios.
        
        • Do we want to include the write-up previously discussed despite not addressing the problem tying output values to input values?
    • “Actions” work in Core:
      • http://open-services.net/wiki/core/Actions-2.0-Scenarios/ - changed to better reflect the relationship between the requirements and the scenarios. Recent changes in green (and blue, as in next point).
      • http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/. “While I’m not entirely done, there are some questions from Martin’s draft that we might be able to close on (response incorporated into this draft for at least one, see largest read block). Blue is a temporary decoration for recently drafted normative text, in case anyone wonders. There is a draft of the first profiles there now, for both Automation and CM.”
    • New work - John A.
  • Workgroup business
    • Next meeting: 31st October at 11AM Eastern US
• Items for later phases:
  • New oslc:usage URI for template creation dialogs - Needs to go into vocab document when we go into finalization

Actions carried over/not yet due:

Minutes

Attending: Martin P, Paul M, John A, Jing, Mike F

Apologies: Steve S, Umberto

• Last week’s minutes accepted
• Trial implementers - we will need 2 before finalisation. Lyo can be one. Can just be non-released prototypes. The more, and the more coverage, the better. Very few hard requirements.
• Umberto not present to comment on templates
• TODO: Normalise current version to “v2.1”, not “v3” or “postv2”.
• MP would like to see orchestration write-up in primer
• Actions 2.0
  • ITOpsToDev looks more about linking than state transitioning.
  • Auto reqs - “would be ideal to” reuse existing interaction patterns that clients already know. (reuse language)
  • Auto scenario requires unattended execution - make it a SHOULD for providers to provide an implementation that can be driven unattended.
    • Use case: multi-select 100 bugs/tickets/ etc & transition all of them
  • TODO: Ask CM to review & confirm they are comfortable with the reqs & specs as at the moment. Especially the complexity added by the extensibility, etc, values.
  • TODO: Answer last red Q.
  • Resource shape tables in there by tomorrow. Equiv desc currently in desc.
  • Added “when linked to by action:action predicate” to MUST contain “action:request” MUST. MP happy with this solution. TODO: Remove red question.
  • Constraint requiring zero-parameter option. MP proposes “SHOULD” in “parameters” core section (not in profiles). No objections.
  • JA proposes renaming action:action to action:availableAction.
    • MP: executableAction?
    • MP voted for action:action. As chair, wins.
    • Raise it as a review point when we review the spec.
  • How does a consumer know if it can execute an actions
    • TODO: MP to think through how some key examples would work - both identifying actions that can be used, and how they know they can’t execute other ones.
  • Delegated dialog
    • How does the client find it?
    • TODO: Flesh out how delegated UIs play in here. - Umberto’s imput is important, as Tivoli uses them a lot. Umberto & Martin to both propose how they would see it.
• New work - John
  • Some products have approached me about new near-term work that seems closely related to Automation, but distinct from what’s in scope for 2.1
  • Centered around availability:
    • Exposing availability state (which for them is a complex multi-property set of information, not a simple string or URI)
    • Exposing availability groups of various flavors
    • Actions to change the state - mainly start/stop, of various kinds. Their actions are typically long-running so they’re interested in re-using the Automation/Actions work we’ve been incubating with CM.
  • This seems like natural follow-on work to 2.1. It’s not clear that it’s worthwhile creating a separate WG for this, given the public plans to move to OASIS and the actions overlap.
  • JA proposing making separate workflow in Automation WG. Decision for chairs how much coordination of what type they want.
    • Logistically, it might be easier to have separate Automation meetings to incubate this post-2.1 work in parallel with 2.1 … largely disjoint set of participants.
    • Paul: Consult with Steve Speicher, from something done in CM (experimental resources) - not sure if that is a pattern that worked out well.
    • JA: Steve has seen this, since I knew he was traveling this week; he actually suggested running it under Automation independently.

Actions resulting from this meeting