Page History

...

Deployment process

Services deployment map exchange process - is a process of change deployed services state.

Unified steps of service deployments exchangeprocess:

• Each node makes a decision if it should apply actions (deploy/undeploy) on local services and send map of local deployed services to the coordinatorand sends single deployments message to the coordinator through comm-spi (p2p). The message contains deployments errors and count of locally deployed instances of services related to the current deployment process;
• Coordinator aggregates single maps and deployments messages, then builds and sends full services deployments map message over the to all nodes through disco-spi;
• All nodes update services informations information and complete initiators futures if needed;

...

1. Initiator sends DynamicServicesChangeRequestBatchMessage request using discovery spi to change service state [deploy, undeploy]. The request will be stored by all nodes in own queue to be processed, event if the coordinator failed;
2. All nodes process tasks from queue, when deployment request received each node calculates a new service’s assignments independently using deterministic assignments function and apply actions (deploy, undeploy) if needed, then node builds single map deployments message ServicesSingleMapMessage that contains services id and amount of instances were deployed on this single node and sends the message over comm-spi to coordinator (p2p);
3. Once the coordinator receives all single map deployments messages then it builds ServicesFullMapMessage that contains services deployments across the cluster and sends the message over discovery spi through disco-spi to be processed by all nodes;

...

          byte flags; // Change’s types flags [deploy, undeploy, etc.]

}

class ServicesSingleMapMessage ServicesSingleDeploymentsMessage {

          ServicesDeploymentExchangeId exchIdServicesDeploymentProcessId depId;

          Map<IgniteUuid, ServiceSingleDeploymentsResults> results;

...

          Collection<byte[]> errors; // Serialized exceptions to avoid issues at spi-level

}

class ServicesFullMapMessage  ServicesFullDeploymentsMessage  {

          ServicesDeploymentExchangeId exchIdServicesDeploymentProcessId depId;

          Collection<ServiceFullDeploymentsResults> results;

...

          Map<UUID, ServiceSingleDeploymentsResults> results; // Per node

}

class ServicesDeploymentExchangeId ServicesDeploymentProcessId {

          AffinityTopologyVersion topVer;

...

All nodes handle requests of service’s state changes and put it them into deployment queue, but only the coordinator aggregates single maps deployments messages received from nodes and builds a full map deployments to finish exchange. If coordinator left or fail during deployment exchange another server node will become the coordinator and continue the process.

Topology change

Each topology change event (NODE_JOIN/LEFT/FAILED event) causes service's states causes  deployment task. Assignments will be recalculated and applied for each deployed service if needed.

Services reassignment process takes into account previous assignments to avoid redundant redeployments.

If left/failed node had not deployed any services, then deployment task will be finished without sending messages.

Cluster activation/deactivation

...

• • local services are being redeployed;
  • requests are handling as usual;

Service deployment failures policy

ServiceDeploymentFailuresPolicy describes rules of handling deployment errors during deployment exchange process. Policy is configurable per service level using ServiceConfiguration.

There were implemented 2 basic policy:

• IGNORE - ignores deployment errors and deploy services as is;
CANCEL - cancels deployed instances in case of any errors
• • ;

Deployment errors propagation

...