Time: 11:00AM Eastern US (contact MichaelFiedler if you’d like to participate)

Agenda

• Main agenda items:
  • Specification issues
    • Automation Specification Version 2.0 Issues
    • New issue: Resource format inconsistency. Mailing list thread here
    • New issues?
  • Implementation updates
    • Open forum for implementers to provide updates
  • Review 16 May Minutes
  • Automation V3
    • V3 Scenarios.
      • Temporary deployment scenarios.
        
        • Discussions of barriers to entry and teardown plans here
          • notion of profiles for basic/generic and advanced/purpose built consumers and providers
          • at what level is this handled in the spec (promoting interop) vs handled in guidance or profile documentation (promoting simplicity)
        • Additional discussion on teardown scenarios here
          • representations of resources by automation artifacts
    • If time allows: updates on Automation agent/worker scenarios.
    • Additional scenarios?
  • Workgroup business
    • Next meeting: Thursday, 30 May at 11 AM Eastern US
      • Chair for this meeting?
    • Proposal to cancel June 6th meeting.

Minutes

Attending: Michael Fiedler, Steve Speicher, Martin Pain, Heather Fraser-Dube, Vaibhav Srivastava, David Liu, Umberto Caselli, John Arwe , Paul McMahan, Rohit Shetty

• Specification Issues

  • 2.0 spec updated for minor issue discussed 23 May

• V3 Specification discussion

  • Automation profiles - generic vs purpose built providers and consumers

    • General recognition of both types of providers and consumer
    • Desire to protect scenarios where consumers/providers without knowledge of each other can function, while enabling more advanced scenarios
    • Open source samples are a way to provide examples of successful advanced interactions (e.g. the Automation adapter sample in Lyo)
    • Suggestion to start a wiki page documenting the concept of profiles, examples of applications to existing implementations and expectations of consumers.

  • Teardown scenarios

    • Automation plan per action (VM example: start, stop, teardown) vs. using state changes to trigger actions
    • General feeling that automation plan per action not the right approach. State changes feel more correct
    • But, change the state in what resource? Automation result seems artificial in some cases.
      • For providers which are thin adapters, possible there are no other OSLC resources, Result is the only place to do it. Desire to have teardown scenarios work for OSLC without any further knowledge of the providers details.
    • In some deployment teardown scenarios, the Result is the deployment. DELETE on the result URL to teardown?

• Next meeting: 30 May at 11AM Eastern US