Time: 11:00AM Eastern US
Agenda
Minutes
Attending: John Arwe, Martin Pain, Yih-Shin Tan, Paul McMahan, Charles Rankin
Lurking: Steve Speicher
- Automation Specification Version 2.0 Issues
- Martin pointed out issues 1 (being addressed in 3.0) and 7 from his implementation report
- 7 non-normative; seems like a candidate for the best practices companion doc to define terminology per sub-domain that Automation defines. Implementations then have something common they can use (or not), but it’s more likely to lead to a consistent result.
- Logged by Martin as issue 4
- 15 August minutes adopted without change
- Proposal to modify content of Automation WG page
- No objections
- Paul encourages us to be consistent across working groups so humans reading see a consistent result and they “just know” where to find things as much as possible
- Leaving final decision to next week in order to get a more representative sample of WG feedback
- Automation V3 Orchestration Scenarios
- Current owners of these carry-overs from V2 do not have any plans to actively drive them.
- One product group suggested as a catcher, email is out to them.
- Absent a positive response, Arwe recommends shelving it (abandoned pile) next week.
- Automation V3 Temporary deployment scenarios
- Martin asked why John had said in emails that a link to an Automation Plan is not enough to execute it. John pointed out that the consumer needs to know where the Automation request Creation factory is. The presence of a
:serviceProvider link from the Plan might be enough, but we would need to cover this in the spec.
- It was suggested that the target of the
:teardown link be a resource that contains properties such as the required/optional value and the link to the teardown Automation Plan. This would help represent multiple pieces of information about the teardown, as well as allow the target to be consistent between the Plan and the Result. (However the Result’s :teardown resource would contain a result-specific teardown Plan link, where the Plan’s :teardown resource would link to a general teardown Plan, if any.)
- Charles questioned requirement for predicate on Plan in Aug 22 Proposal, segue back to updated scenario content. If the user can find the “deploy” plan, why not the “teardown”? Is this a search problem really?
- Paul/Martin: to the human users, all this Automation business is chaff/distraction. They just need an environment to use, and if one has to be built or not, “implementation detail” from human point of view.
- Martin: Also, we want teardown to be the default in the Service Virtualization case, not requiring extra work on the part of the user.
- Alternatives discussion … really “other ideas”, NOT mutually exclusive
- 3: Charles and Arwe dubious on advantage of “extra” level of indirection; Martin says there is no concrete near-term requirement for it at this point, just trying to keep it extensible and allow general introspection of operations
- Charles: poking at “does it have to be a single resource that’s produced?”. No decision; Martin prefers one. Kind of a ‘special’ form of contribution.
- No one on to represent other V3 scenarios
