The minutes from the last two meetings are now available: http://open-services.net/wiki/automation/AutomationMeetings20131212/
Attending: Martin, Tim, John A, Juergen, Steve S Apologies: Umberto - Nothing ready to discuss about Availability - will discuss this in the new year. - Discusses interaction patterns and their relation to implementation profiles. - MP to send changes to Actions spec out to WG. - MP to write up scenario about dialog for later execution/dialog for later teardown. - SS may propose a simpler alternative. - Intend to meet 19th Dec. Then break for 2 weeks. http://open-services.net/wiki/automation/AutomationMeetings20131121/ 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) - Availability - Description of availability resources from [[ http://open-services.net/wiki/automation/Availability-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) Kind regards, Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint chair E-mail: [email protected] Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
