Enable code to be called by anax on a target edge node before and/or after deploying a workload, and before and/or after removing a workload. Allow optional implicit and explicit configuration to be passed to the code from a workload's Service Definition or Deployment Policy. Determine if there should also be node restart and workload upgrade and rollback events.
- As a solution architect, I want developers to be able to call third party components before or after specific workload lifecycle events so that the component can take action at the right time (before a change happens or immediately after the change takes effect).
- As a solution architect, and have the lifecycle pause while the I want third party components to be loosely (not tightly) coupled to Open Horizon through an event subscription mechanism so that Open Horizon's functionality is not hampered by a potential error condition in the environment or the third-party component.
- As a solution architect or developer, I expect the eventing solution used by Open Horizon to use one or more common standards for the event "hooks" so that integrating with third-party components is easy to do, well-understood, and well-supported by existing libraries.
- As a solution architect, I want Open Horizon to pause deployment while subscribed third-party component(s) take(s) action . I expect Open Horizon to pass information along with the event so that there is minimal opportunity for race conditions and resource contentions to take place.
- As a solution architect, any pause in deployment should have a reasonable timeout so that deployments cannot be unintentionally stopped by a misconfigured or malicious process subscribed to an event.
- As a third-party component developer or integrator, I expect events to pass a payload containing information about the workload, workload configuration, host, node configuration, and optionally information about the third-party solution's desired configuration so that the third-party component understands the workload and deployment target. can completely understand the operating environment and context to take appropriate action.
- As a developer, I expect documentation to be provided describing the structure and contents of an event payload so that the feature is easy to understand and use.
- As a developer, I expect documentation to list all of the interesting moments when events can be thrown so that I know what events exist. And
- As a developer, I expect to find examples showing how to subscribe to events and use the provided payloads so that I can learn by example.
- As a system administrator integrating the deployed workload with a third-party solution, I expect to be able to subscribe to one or more events using a common and secure eventing standard. I expect the event to include a payload in a common format (JSON?). I expect the payload to include information about the workload, workload configuration, host, node configuration, and optionally information about the third-party solution's desired configuration. And I expect to be able to subscribe (and unsubscribe) to events without codeQA engineer, I anticipate using the examples to create unit and end-to-end tests so that the expected usage has ample test coverage.