*Deploy an instance of a service and allocate where need is greatest during system operations*
|Actors||Service Deployer (Integrated Observatory Operator), Service Consumer (Application Developer)|
|References||UC.R1.15 Put Services Anywhere|
|Uses||UC.R2.31 Define New Service Interface
UC.R2.44 Define Service Type During Runtime
|Is Used By|
|Extends||UC.R1.17 Replicate Service|
|Is Extended By|
|In Acceptance Scenarios||None|
|Primary Service||Elastic Computing Services|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
Deploy a service instance, given a service type definition and associated service implementation. The service instance is to be started up to a particular operating environment, for example in a given physical region or computational environment. The service instance should be automatically configured for compatibility with the designated environment. Once running, the service instance is discoverable by its attributes, and can also be found by the appropriate service type identifier. The operator may change deployment policy during runtime of the system.
- The system is operational (i.e. this is not an integration time activity as in R1).
- There exist multiple distinct running service instances.
- The operator has permissions to modify the running services and deploy new ones.
- A service instance can have many worker processes (managed by the HA service agent), in the same or different deployment locations.
- Policy is defined mostly on the service instance (HA service agent) level.
The Service Deployer has defined a service type and associated it with one or more matching service instances for the type.
- The Service Deployer finds a defined service type for a given task
- This is done via UI, by querying the Directory Service, or by accessing the Resource Registry directly
- Selection is done at the discretion of the Service Deployer, such as Python implementation only
- There may be a default implementation of the service type
- The Service Deployer keeps service type identifier and service implementation identifier
- The Service Deployer defines a new service instance
- Through an operator console, ideally
- The Service Deployer provides service type identifier and service implementation identifier (optional if a default exists)
- The Service Deployer provides service process configuration information
- Configuration is applicable to all or some processes for one service instance, on initial creation or subsequent service process spawns.
- The service process definition includes default values, or even fields in the place of values, where the service process needs configuration variables (e.g., IP address) filled out before it runs, as defined by the service deployer
- (optional) The Service Deployer defines access policy
- A service instance, like any resource, is given a unique service instance identifier on creation. The service instance is associated with a service type and one service implementation in the Resource Registry.
- <3> The Service Deployer defines the location and deployment policy for the service processes of one service instance
- There are multiple processes for the service. The number of processes and deployment arrangement (which site, execution engine, etc) is determined by policy.
- This is performed through an operator console, ideally.
- This step can be done for a new or a running service instance.
- The Service Deployer provides a given set of characteristics for deployment, performance, scope, configuration.
- The service instance defines the need for one or multiple service processes as part of its creation, as well as during steady state operation and in the presence of process failures.
- If multiple processes are providing a service instance, this is hidden from the view of the requester of a service instance (worker queue load balancing)
- Service processes for one service instance can be deployed in different locations (i.e. available capability containers)
- The Service Deployer can specify a previously provisioned Execution Engine where a service process should be instantiated.
- The Service Deployer may instead specify a deployment policy, such that a minimum number of service processes are created to guarantee high availability, with the service processes spread across multiple execution environments. For elastic scaling scenarios, a minimum and maximum bound of service processes may be specified, as well as a monitoring function leading to provisioning/termination of service processes and their distribution to existing capability containers.
- The Service Deployer finalizes the service deployment configuration.
- System reaction: Service processes are "spawned" on Capability Containers by a responsible service agent.
- The service agent spawns new service processes as configured on existing capability container instances; the spawned process may be on another capability container instance (i.e., another execution node) than the agent process.
- The agent identifies a process definition (service package with specific version) when spawning a process. This package can be loaded from a software component repository service onto the specific capability container and instantiated.
- The service supervisor (agent) may have policy to dynamically grow and shrink the number of service processes providing the service, for instance to react elastically to demand (see Scaling the Processing).
- The Service Deployer publishes the new service instance
- Through an operator console
- The service instance is registered with the Directory Service.
- The Service Deployer assigns a defined name to the service instance
- A Service Consumer discovers service instances by their attributes, and can also find them by the service type identifier.
- Discovery occurs through querying the Directory Service
- Via API or UI
- Discovery occurs through querying the Directory Service
- <3> (optional) The Service Deployer can restart a service instance
- This means bringing down all existing service processes for the instance and restarting them according to defined deployment configuration
- (optional) The Service Deployer deactivates a service instance
- This means bringing down all existing service processes for the instance
- Service Consumers will receive an error when invoking the service
- <3> (optional) The Service Deployer removes (decommissions) a service instance
- This means making a service instance unavailable for future execution.
The system has modified the service directory and the operational service instances and processes to reflect the operator changes, and the effective "launch plan" of the system reflects the operator changes.
These comments provide additional context (usually quite technical) for editors of the use case.
If two different services get instantiated on the same operational unit there may be conflicts (e.g., one of them assumes that a different version of Java is the default than the other and the contextualization overrides that default). Those are subtle differences, difficult to manage on a higher level as conflicts, but will make things not work.