During today’s TOSCA Language Ad-Hoc meeting, we discussed the lack of a clear “mental model” for events that may need to be processed by a TOSCA orchestrator. We discussed the following potential “categories” of events:
- There seems to be a distinction between synchronous and asynchronous events. Synchronous event are “commands” issued by some external entity (e.g. an administrator or some management
system that invokes APIs). Asynchronous events are the result of changes in the external “implementations” (i.e. the services under management). These changes are observed by some type of monitoring system, and are reported asynchronously as events or notifications.
- While there was a suggestion that synchronous and asynchronous events should be treated the same by an orchestrator, I’m having a hard time seeing how this is possible. Based on the
current TOSCA specification, synchronous events (“commands”) result in the execution of workflows, which ultimately call interface operations. Asynchronous events, on the other hand, result in the triggering of event/condition/action policies (which in turn
may execute workflows). I’m not sure how these two could be harmonized.
- As it relates to synchronous events (“commands”) it seems to me that all of these commands can be reduced to simple CRUD operations:
- Create a service
- Read a service
- Update a service
- Delete a service
- In my implementation, I have exactly these 4 canonical operations. What allows all management operations to be reduced to one of these 4 operations is the set of arguments that is
passed:
- The “Create” operation takes a service template, a set of service input values, and (optionally) the name of the workflow that needs to be run to realize the service in the external
world
- The “Read” operation just takes a service id
- The “Update” operation takes a service id and one or more of the following:
- Update service input values
- An updated service template
- The name of a workflow that needs to be run
- The “Delete” operation takes a service id and (optionally) the name of a workflow that needs to be run
Please provide feedback and comments so we can iterate on this and solidify the mental model, which will help streamline our future discussions.
Thanks,
Chris
|