History   View   Links to this page 2013 April 4 | 09:50 am

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

Agenda

Minutes

Attending: Michael Fiedler, David Liu, Martin Pain, Steven Rowles, Steve Speicher, Paul McMahan, John Arwe

  • Specification Issues
    • No new issues
  • Implementation Updates
    • No new reports
  • Automation V3
    • Scenario owners
      • Paul McMahan agreed to own Plan Configuration Scenarios . Possible intersection with the OSLC Reconciliation workgroup noted and interest to collaborate on this scenario will be solicited.
      • Louis Paul is tentative owner of the [ Lifecycle Workflow scenario ](Automation Orchestration\Lifecycle Workflow Scenarios (Partial V2 Carryover)) but this is yet to be confirmed.
      • Mike Fiedler will own the Core V3 Alignment scenario
      • Notification scenarios : Scenario definition and requirements needed. Could the Tracked Resource Set specification satisfy the requirements? Need to answer questions around responsiveness vs overhead.
  • Temporary deployment scenarios
    • Martin Pain and Stephen Rowles walked through the scenario and proposed approaches documented on the wiki
    • Discussion
      • One key concept is having consumers somehow register interest in deployed environments
        • possible approach: consumers POST to the provider and create a “Consumer Interest” resource and link to the result. Good if more than a simple flag needed for the interest association. Martin does not believe more than a simple flag is needed, but can investigate
      • Need to discuss how environments are modeled - could represent 000s of compute/network resources
        • Simple as link in result contribution or could be something much more involved
      • Responsibility for teardown once environment has no one interested in it
        • Orchestrator or provider who did the initial deployment - likely (?) has a corresponding plan for teardown.
      • When multiple consumers are interested in an environment, do they need to know about mutual interest/usage? how to discover?
      • Follow-on to previous: When a deployed environment is complex (think network + appServer + dbServer + clients + …), how does the orchestrator know when the whole thing can be torn down. TODO: Michael Fiedler to start a mailing list thread on this.
  • Workgroup business
    • A doodle poll will be created to find a time for weekly meetings going forward
    • Next meeting: Thursday, 4 April at 10AM Eastern US Time

Comments on Minutes

  • Discussion point 1: “Martin does not believe more than a simple flag is not needed, but can investigate” should be “Martin does not believe more than a simple flag is needed, but can investigate”

  • Discussion point 2: I don’t like the word “environments”. If we are talking about deployment, I prefer the term “deployed resource(s)” to be completely ambiguous about what was deployed. I hope we should be able to talk about it in the singular - represented by the single automation result - even if there are 1000s of compute/network resources.

    • Therefore any “link in result contribution” would be to some other domain/protocol’s representation of the same thing that the automation result represents - it would not be linking to anything defined in the OSLC auto spec. I see the auto result as representing the complete set of “deployed resources” or, if only one resource was deployed, then I see it as representing that “deployed resource” itself, not merely being an intermediate piece of RDF holding state and a link to a representation of the deployed resource. But I unerstand others’ views may vary on this.

  • Discussion point 3: I consider the orchestrator & the provider who did the initial deployment (if you mean the composite deployment, rather than the individual components) to be the same actor. And yes, it is that actor who is responsible for the teardown. Then the component results/resources are torn down by the ‘client’ who set them up (in this case the orchestrator), which from the point of view of the component providers is exactly the same as if it were controlled from a simple client not an orchestrator.

    • The “likely (?) has a corresponding plan for teardown” comment, if I understand it correctly, refers to one of the possible approaches for representing teardown, and is not the one I suggest we take.

  • Discussion point 4: If consumers are programmed to be aware of multi-use (as I would suggest this only be a MAY-level req on the client’s side) then they would know which property to look at in the auto result representation to see other clients who are registered as using it, IF we decide to have the link from the auto result to the client identifier (which is my suggested direction). If we have the link in the other direction, then the multi-use-aware clients would know what query toperform to find this out on the provider. If we allow cross-provider links, then we need some way for the clients to look up which other providers they should query (and this complexity is why I suggest the links from auto result to client).