Skip to main content

Deployment Planning

On initiating a deployment, a Deployment Plan is created. A Deployment Plan is used to instantiate Workloads on to the Clusters.

To start with, a plan will be presented to you on the basis of the placement rules determining on which Cluster each application will be deployed.

  1. If you agree with the plan, click on Proceed to go ahead with the Deployment.
  2. If not, then click on Cancel to continue making changes to the Package.

What is Planning?​

When a package deployment is being planned, the basic unit to which rules are applied is the Application. The rules will determine which Cluster the members of the Application will be deployed into and as such only the effective Placement Rules on an Application are considered. Effective rules may be defined on the Application directly or on the owning Package with the following rules. Note that each individual Application or Package may only define one rule which has either a MinOf or MaxOf selector Operator. To be specific, if a Package or Application has a single MinOf operator defined, or a single MaxOf operator defined, it may have neither a MinOf or MaxOf selector added even if they apply to different keys.

Understand how the different selector operators work on OGC.

Inheritance rules, applied in order:

  1. If an Application has a rule operator with a MinOf or MaxOf Operator, no rules of MinOf or MaxOf type will be inherited from the Package regardless of key.
  2. If a rule with a specific key is present on an Application’s containing Package, and not present on the Application, the rule is inherited and treated as applicable to the Deployment planning.
  3. If a rule with a specific key is present on an Application that rule's definition is applied.

Understanding Planning Algorithm​

The planning algorithm comprises a list of filters applied to all Clusters registered to a Project. Each Application in the Project causes a run of the planning sequence in order to determine which Cluster (and which Nodes within that Cluster) the Application should be deployed to.

A filter accepts and returns a list of Clusters. The order of the incoming list should be treated as significant, filters removing Clusters from the list should not alter the order of the remaining Clusters. The initial input is a list of all the clusters assigned to the Project which owns the Application to be deployed, in age order (oldest first).

The filters are:

  1. Cluster Available: Removes all clusters which do not have a status of Up.
  2. Compute Sufficient: Removes all clusters which do not have at least one Node with sufficient Compute resources to run the Application.
  3. Memory Sufficient: Removes all clusters which do not have at least one Node with sufficient Memory resources to run the Application.
  4. Storage Sufficient: Removes all clusters which do not have VolumeProviders corresponding to the StorageRequest-type Mounts across the Application’s Containers.
  5. General Label Compliance: Removes all clusters which do not have Labels matching the the Application’s Placement rules. Note that in the case of MinOf and MaxOf selectors, this filter checks only for the existence of the required Label on the Cluster and does not filter on the min/max operation.
  6. Extant Resources: If the Application has been previously deployed, and the previously targeted cluster is in the incoming list, and there are extant persistent resources (e.g. PVCs) from the previous deployment belonging to the application on that Cluster, all other clusters are removed from the list.
  7. Min/Max Label Compliance: If the Application has a MinOf or MaxOf selector, this filter removes all Clusters which do not have the Label value which corresponds to the selector. Example: The incoming list contains three Clusters - A, B and C. Cluster A has a cost Label of value “10”, cluster B a cost Label of value “7” and cluster C has a cost label of value “15”. Against a rule specifying MinOf cost, this filter would detect cluster B as being labelled with the minimum cost value (7) and remove A and C from the list. If clusters B and C both had a cost of 7, they would both remain in the filter’s output list.
  8. Tiebreaker: In the event that multiple clusters reach the final filter, the list will be trimmed to one candidate (the oldest, which should still be the first in the list).

Filters are executed in the order given above. If the output of any given filter is an empty list the planning algorithm has failed and should cease execution with a suitable exception.

Effects on Persistent Resources​

The evaluation order of the filters, combined with possible changes to configurations (e.g. Cluster Labels) means that the possibility exists that a previously-deployed Application can no longer be assigned to a Cluster it was previously hosted on. In this case, it is expected that the deployment process will create new PVCs and PVs to fulfil persistent entity requirements on whatever new cluster is targeted for the Application by the planning algorithm. No automated effort will be made by OGC to tidy the “out of bounds” old Volumes and other resources.