Guest OS rules

[BryanMLima]

Description

Currently, ACS provides a feature that enables a guest OS preference for a specific host, prioritizing VMs based on its OS. However, this functionality allows VMs with different OSes to be deployed in a host with a Guest OS defined, as expected as it is only a preference configuration; this is not always desired. For example, keeping proprietary OS in the same host could reduce licensing costs.

This PR tackles this scenario, allowing JavaScript rules, using the JS interpreter introduced in #5909, to direct VMs to specific hosts based on their OS. Different from the guest OS preference, these guest OS rules will be strict. This new feature added a new field, Guest OS as JS rule in the host edit view to allow users the creation of these rules.

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

Screenshots (if appropriate):

How Has This Been Tested?

In a local lab with two hosts (host-1 and host-2) I created the guest OS rule vmGuestOs.toLowerCase().indexOf("debian") != -1 for host-2, and deployed multiple VMs using templates and ISOs.

• I deployed VMs with Ubuntu and CentOS and verify that host-2 was filtered during the deployment.
• I tried to migrate these VMs to host-2 and verified that it was not possible.
• I deployed a Debian VM and verified that both hosts were considered in the deployment process.
• I managed to migrate this VM from host-1 to host-2 and vice versa.

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

I tried to deploy VMs in the same lab without the guest OS rules defined and validated that the deployment of VMs were being done as expected.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 3.51%. Comparing base (cbc1ae7) to head (125f1cd).
⚠️ Report is 3 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (cbc1ae7) and HEAD (125f1cd). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (cbc1ae7)	HEAD (125f1cd)
unittests	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##               main   #10098       +/-   ##
=============================================
- Coverage     18.08%    3.51%   -14.57%     
=============================================
  Files          6037      464     -5573     
  Lines        542546    40158   -502388     
  Branches      66431     7561    -58870     
=============================================
- Hits          98126     1413    -96713     
+ Misses       433404    38555   -394849     
+ Partials      11016      190    -10826     

Flag	Coverage Δ
uitests	3.51% <ø> (-0.01%)	⬇️
unittests	?

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.

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[sureshanaparti]

@blueorangutan package

[blueorangutan]

@sureshanaparti 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 13624

[blueorangutan]

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 13720

[blueorangutan]

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 13731

[DaanHoogland]

@BryanMLima can you look at the conflicts?

[BryanMLima]

@BryanMLima can you look at the conflicts?

I will take a look this week, apologies for disappearing 😅 .

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[github-actions]

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

[rajujith]

@BryanMLima Since this is for the 4.22.1 release, could you retarget the PR to the 4.22 branch?

[sureshanaparti]

Hi @BryanMLima is this PR ready? can you resolve the conflicts (and rebase with 4.22 if this can be targeted for 4.22.1).

[winterhazel]

@blueorangutan package

[blueorangutan]

@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

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

[winterhazel]

@blueorangutan package

[blueorangutan]

@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

[winterhazel]

Tested manually.

In an environment with 2 hosts, host-1 and host-2:

1. I configured host-2's guest OS rule to vmGuestOs.toLowerCase().indexOf('ubuntu') !== -1. host-1's rule remained empty.
2. I deployed some VMs using Ubuntu and Macchinina templates.
3. I verified that host-2 received only Ubuntu VMs, while host-1 received both Ubuntu and Macchinina VMs.
4. I attempted to migrate the Macchinina VMs that were in host-1, and validated that no hosts were returned as compatible, as host-2 only accepts Ubuntu VMs.

As this PR also affects GenericRuleHelper, I also validated that the flexible tags feature was still working:

1. I configured host-1's host tags to tags.indexOf('test-tag') !== -1, and cleaned the guest OS rules of both host-1 and host-2. host-2's host tags remained empty.
2. I created two compute offerings, one without tags and another with the tag test-tag.
3. I deployed some VMs using both compute offerings, and validated that host-1 only received VMs using the compute offering with the test-tag tag.

[blueorangutan]

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