Value Statement

the goal is:

I have an Applicationset containing only one VM and it is only deployed to one Cluster (but two are available).

Now we want to check how to automatically simulate a move from one cluster to the other

Example: Reacting to Increased VM Count

To ensure your PlacementDecision changes when more VMs are added to a cluster, you must use a dynamic prioritizer. The built-in ResourceAllocatableCPU and ResourceAllocatableMemory are the most direct ways to achieve this without custom code.

Initial State:

You have two clusters, cluster1 and cluster2, both with 1000m allocatable CPU. Your Placement object selects one cluster based on available CPU. The controller places a VM on cluster1 because its score is higher (or it was chosen first).

1. Placement object

spec:
  numberOfClusters: 1
  prioritizerPolicy:
    configurations:
      - scoreCoordinate:
          builtIn: ResourceAllocatableCPU
        weight: 1

Change Occurs:

Another VM is manually placed on cluster1. The available CPU on cluster1 decreases to 800m. The available CPU on cluster2 remains at 1000m.

Placement Controller Reaction:

The controller detects this change. It re-evaluates the scores for both clusters:

cluster1 score (based on ResourceAllocatableCPU) decreases.

cluster2 score remains high.

The controller now sees that cluster2 is the most suitable cluster. It updates the PlacementDecision to select cluster2 instead of cluster1.

This new decision can be consumed by your workload automation, which can then migrate or "push" the VM from cluster1 to cluster2 to rebalance the workload. This process happens automatically without manual intervention on the Placement object itself.

In summary, you don't need to change the Placement object to react to these events. The object's purpose is to define the rules, and the OCM placement controller's job is to enforce those rules by continuously monitoring and updating decisions as the clusters' states evolve.

Definition of Done for Engineering Story Owner (Checklist)

• ...

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [ ] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• [ ] Security has been assessed and incorporated into your threat model.

Multidisciplinary Teams Readiness

• [ ] Create an informative documentation issue using the [Customer
  Portal_doc_issue template](
  https://github.com/stolostron/backlog/issues/new?assignees=&labels=squad%3Adoc&template=doc_issue.md&title=),
  and ensure doc acceptance criteria is met. Link the development issue to
  the doc issue.
• [ ] Provide input to the QE team, and ensure QE acceptance criteria
  (established between story owner and QE focal) are met.

Support Readiness

• [ ] The must-gather script has been updated.