index / Automation Meetings / This page
Time: 11:00AM Eastern US (Currently 3pm UTC)
Chair: Umberto - Martin
Actions from last meeting not covered by agenda
All covered in agenda
Actions carried over/not yet due:
- Actions 2.0
- remove requirements (on Actions from Automation) from auto page - duplicated in Core Actions scenarios page - MP/JA
- Generic consumer cases are not on scenarios page. - MP
- Flesh out separation of interaction pattern from restrictions - MP
Attending: Umberto, Martin, Jurgen, John
- New implementation: Jenkins (by Sam in Rational) - not in implementation reports (yet)
- Actions - UI/dialogs
- UC approves of reuse of template dialogs
- UC suggested similarities between scenario (A) and Jurgen’s availability scenarios.
- Jurgen hasn’t considered UI flow yet, but are interested in it.
- Execute now vs execute later (template). Execute now = default? However default might need to be used to distinguish between multiple.
- Link to creation factory?
- UC: we could link to service provider (as there are many things we could look for).
- MP : link to factory makes it a lot simpler
- Two different types of “execute later” - user present vs user absent
- Prefilling execution dialog with result from template dialog.
- MP to put together examples of “execute later user absent” with path - reusing interaction patterns from action:request. (Also joins back with earlier work on identification of profiles, re: interaction patterns)
- Description of availability resources from http:open services.netwikiautomationAvailability Scenarios
- State = available or not available. (or intermediate, or problem)
- Advanced features, such as history and replication metadata would be optional, as not all products provide them.
- Discussion of “Obtain list of workloads” scenario.
- Question on “Start & stop workload” scenario: UC: Why query observed states (steps 7 & 8) after you have already seen the automation result complete successfully? Jurgen: It might affect subsequent steps, but is optional.
- UC: Consumers would preferably be able to support new unrecognised action types on providers.
- MP: We could expose in the RDF how the properties will change. So consumers don’t need anything hard-coded based on types of actions.
- UC: some actions won’t change the state, e.g. “recycle” (moves from available to available).
- MP: Consumers shouldn’t rely on it. But we can still make it available for when it makes sense.
- JA: For plans which are a “vote” into a policy, the plan can succeed (the vote is cast) but the state hasn’t changed.
- MP: We need a mechanism beyond “state” for determining completion for actions that don’t change state (e.g. “recycle”).
- Jurgen: The time that the state change happened will change.
- MP: I’m happy that there is a way to define how the consumer detects the change - we just need to define it. (and make sure the simple cases stay simple)