Time: 11:00AM Eastern US

Agenda

• Main agenda items:

  • Specification issues

    • Automation Specification Version 2.0 Issues
      • After-finalization #4: OPEN - The OSLC Automation terms “Plans”, “Requests” and “Results” are not always suitable for display to all users, as they would not be aware of their OSLC meanings. There is no guidance on what wording to use when presenting these to users. The separate sub-domains might have different terminology that is appropriate.
        • 22 Aug 2013 - Proposal for Automation terminology guidance

  • Implementation updates

    • Open forum for implementers to provide updates
    • Summarize any new implementation reports
      • Identify new issues to open in Core and Automation
  • Review 22 August minutes
  • Automation V3
    • Automation Scenarios V3 status - Topics TBD based on attendance. Possibilities include:
      • Scenario issues
        • Temporary deployment scenarios
          • Is Aug 15 proposal for additional automation plan relationships considered rejected in favor of continuing discussion around Aug 22 proposal?
        • Orchestration Scenarios.
          
          • Agreement on shelving this scneario?
          • Otherwise:
            • Plan-to-plan relationships
            • How to represent the graph/flowchart of execution?
            • Input/Output relationships (Plans and Results in general, also input parameters and result contributions)
        • Automation Template Scenarios. Discuss scheduling scenarios around this.
        • Automation Agent/Worker Scenarios. Discuss whether this is in scope or out.
  • Workgroup business
    • Next meeting: 5 September at 11AM Eastern US

Minutes

Attending: Michael Fiedler, Umberto Caselli, Steve Speicher, Steven Rowles, Martin Pain, John Arwe, Charles Rankin

• Terminology issue - preference for including in an existing document.
• Hudson/Jenkins implementation - still in plan, currently on the backburner

• Scenario discussions

  • teardown attribute for use on plans and results

    • on a plan it is likely a resource reference. Likely a blank node or a reference to another plan.
    • Could contain optional/required information in addition to a plan reference.
    • At design time could point to existing teardown plans and even contain parameter information.

    • oslc:usage can be used in a plan definition to indicate its intended use. Define some possible values in automation.

    • TODO: Need examples

  • Brief discussion on actions - plan/request/results establish resources. Still need a mechanism to control (start/stop).
    
    • Proposed reuse of oslc_cm:action
  • Creation factory discovery
    • Consumers need more than a link to a plan. Need some related service provider info. Specifically the location of a creation factory for autmation requests.
    • Teardown resource could link factory or ServiceProvider
    • Plan already has optional predicate to find service provider. Do we need to hint further on Creation Factory to use? Do we need to say anything here about the default case?
    • some discussion that perhaps the teardown resource contains what is needed to run the plan: Plan reference, service provider reference, parameters
  • oslc_auto:produces: single resource or multiple? - need some text somewhere (informative) around the thought process on this.
    • clients need to figure out how to tell one from the other. make it 0..N
  • Orchestration scenarios
    • scenario owners not interested in driving further in V3
    • Content for Primer: How existing teardown + template scenarios can be used for orchestration - how would a custom orchestrator use the existing automation artifacts and concepts