[CKS] Simplify logic for scaling CKS cluster service offerings

[nvazquez]

Description

This PR improves the scaling of CKS clusters logic with the introduction of the advanced options to specify service offerings per node types from PR #9102.

Originally raised on: #9102 (review)

The following cases for scaling CKS clusters offerings are considered:

1. Create CKS cluster specifying only default/global offering -> Scale CKS cluster offering to a new offering -> All VMs scaled to the new offering
2. Create CKS cluster specifying only default/global offering -> Scale CKS cluster offering for control nodes -> Only control nodes offerings are updated -> Scale CKS cluster offering for worker nodes -> Only worker nodes offerings are updated
3. Create CKS cluster specifying default offering, and also for worker and control nodes -> The worker and control node offerings take precedence over the default offering so VMs are created with the specific node type offering -> Scale CKS cluster default offering -> All VMs service offerings are updated accordingly despite the default offering is the same as before or a new one.

Case 3 using the same default offering:

Before scaling:

(localcloud) 🐱 > list kubernetesclusters id=265f3b8a-f8a7-4439-972e-7bc07f09f91a filter=serviceofferingname,controlofferingname,workerofferingname,
{
  "count": 1,
  "kubernetescluster": [
    {
      "controlofferingname": "Control-Offering",
      "serviceofferingname": "CKS - 2GB",
      "workerofferingname": "Worker-Offering"
    }
  ]
}
(localcloud) 🐱 > list virtualmachines filter=id,name,serviceofferingname,
{
  "count": 2,
  "virtualmachine": [
    {
      "id": "80f80aa9-7389-4783-a425-0a164e0be096",
      "name": "cks-control-1978f42dcf9",
      "serviceofferingname": "Control-Offering"
    },
    {
      "id": "35ac65c6-b001-4757-a40b-d5347e44367d",
      "name": "cks-node-1978f431ec7",
      "serviceofferingname": "Worker-Offering"
    }
  ]
}

After scaling:

(localcloud) 🐱 > list virtualmachines filter=id,name,serviceofferingname,
{
  "count": 2,
  "virtualmachine": [
    {
      "id": "80f80aa9-7389-4783-a425-0a164e0be096",
      "name": "cks-control-1978f42dcf9",
      "serviceofferingname": "CKS - 2GB"
    },
    {
      "id": "35ac65c6-b001-4757-a40b-d5347e44367d",
      "name": "cks-node-1978f431ec7",
      "serviceofferingname": "CKS - 2GB"
    }
  ]
}
(localcloud) 🐱 > list kubernetesclusters id=265f3b8a-f8a7-4439-972e-7bc07f09f91a filter=serviceofferingname,controlofferingname,workerofferingname,
{
  "count": 1,
  "kubernetescluster": [
    {
      "controlofferingname": "CKS - 2GB",
      "serviceofferingname": "CKS - 2GB",
      "workerofferingname": "CKS - 2GB"
    }
  ]
}

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 36 lines in your changes missing coverage. Please review.

Project coverage is 16.57%. Comparing base (5b7c3b4) to head (9f9e13c).

Files with missing lines	Patch %	Lines
...er/actionworkers/KubernetesClusterScaleWorker.java	0.00%	36 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #11063   +/-   ##
=========================================
  Coverage     16.57%   16.57%           
- Complexity    13967    13968    +1     
=========================================
  Files          5743     5743           
  Lines        510468   510468           
  Branches      62073    62069    -4     
=========================================
+ Hits          84616    84617    +1     
+ Misses       416390   416389    -1     
  Partials       9462     9462           

Flag	Coverage Δ
uitests	3.90% <ø> (ø)
unittests	17.47% <0.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nvazquez]

Putting the PR on draft as the current code introduces a regression on the UI operations providing the same offering for one of the node types:

[nvazquez]

Hi @bernardodemarco I have updated the PR - after simplifying the logic the use case you reported on the previous PR indicated that nodes should have been updated as well and I think that is fine, sorry for the confusion. I have updated the PR description with an example of the specific case (number 3)

[nvazquez]

@blueorangutan package

[blueorangutan]

@nvazquez a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13861

[nvazquez]

@blueorangutan test

[blueorangutan]

@nvazquez a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

[blueorangutan]

[SF] Trillian Build Failed (tid-13582)