Time: 11:00AM Eastern US (contact MichaelFiedler if you’d like to participate)
Agenda
- Main agenda items:
- Specification issues
- Implementation updates
- Open forum for implementers to provide updates
- Review 23 May Minutes
- Automation V3
- V3 Scenarios.
- Automation Template Scenario update
- Use of HTTP 202 response in Automation artifacts. Discussion here
- Automation agent/worker update.
- Temporary deployment scenarios.
- Synchronous automation and persistence of results and implication for teardown. Discussion here
- “From the writing of the first version of the spec, what thoughts were
there around the problems that might arise from results being deleted
before consumers expect? Does a 404 (or an empty query result) necessarily
mean it has finished? Or could that mean it hasn’t started yet?”
- mechanism to trigger additional actions such as teardown. Follow-on to additional automation plan vs state change vs DELETE vs other discussion.
- Additional scenarios?
- Workgroup business
- 6 June meeting cancelled.
- 13 June meeting at 11AM Eastern US
- New chair for 20 June and 27 June meetings?
Minutes
Attending: Michael Fiedler, John Arwe, David Liu, Martin Pain, Vaibhav Srivastava, Steve Speicher,Yih-Shin Tan, Umberto Caselli
- Specification issues
- Clarified the synchronous automation scenario and the fact that there is no requirement that providers persist results in this case. Suggestion was made to more fully describe the synchronous scenarios and variations on it in the primer.
- Implementation updates
- Umberto Caselli will provide an implementation report for Tivoli Workload Scheduler
- Automation V3 Scenarios
- Agent/worker discussion
- One possible way of thinking about workers are as automation providers themselves. Providers who need a worker to run an automation would create an automation request on the worker and later retrieve the result
- Assumes the agent can implement a full provider. In many cases workers are meant to be lightweight or relatively “dumb”.
- However, this could be a good fit for the orchestration scenarios. Providers knowing how to request work of each other.
- Polling workers vs. push workers
- Existing implementations of both types in the workgroup’s experience. The Lyo sample is a polling worker.
- Polling allows workers to decide who picks the job up (consideration for job characteristics, worker capabilities, etc)
- Specialized workers vs generic workers
- Examples: test automation worker for a specific test tools vs job scheduling worker capable of running any program or script
- Need a means for to describe the capabilities of workers, whether through admin definition or dynamic registration/advertisement
- How do providers find a subset of agents capable of executing an automation and apply policies to select one, whether push or pull.
- There are touchpoints here with the execution environment scenarios around environment matching.
- Use of the HTTP 202 pattern
- Complimentary to scenarios around setting states
- RFC2616/httpbis definition would effectively support its use for monitoring long running operations.
- Workgroup business
- June 6th meeting cancelled
- June 13th will be held
- June 20th, June 27th and July 4th to be discussed.
