Flexible tags for hosts and storage pools #7489
Conversation
|
@JoaoJandre , I haven´t got my head around how exactly this would work yet but it seems promising. |
|
@JoaoJandre could a global setting and its use in the deployment planner be enough to make the deployment and related lifecycles are strictly or non-strictly allowed the by deployment planner? |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #7489 +/- ##
=============================================
+ Coverage 18.33% 29.17% +10.84%
- Complexity 17808 31127 +13319
=============================================
Files 5059 5195 +136
Lines 344296 366930 +22634
Branches 49577 53735 +4158
=============================================
+ Hits 63132 107065 +43933
+ Misses 272093 245223 -26870
- Partials 9071 14642 +5571
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This would be the simplest solution; however, it would be limited as well. A setting like that would either make all hosts accept or not accept offerings without tags (the same with storage pools). The solution proposed in this PR makes the hosts and storage tags much more flexible; for instance, you could have hosts that accept untagged offerings, while others do not. Furthermore, being able to write a rule in JS opens space for operator creativity, and they would have a much finer control/understanding over their cloud environment. Also, the current behavior is kept; therefore, the use of tag as rules is optional. |
|
Sounds interesting - as long as we keep the original behaviour a default (backward compatibility), I think this would be an interesting feature. It does add complexity (as with anything else), so proper documentation should be in place. |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
@JoaoJandre , can you reply this comment, please? As I read this the old behaviour is intact without change. But is there any risk that a user may think they use an old fashion tag but end up creating a dynamic one? |
Sure, as I stated on #7489 (comment), the current behavior is kept; therefore, the use of tag as rules is optional. Users have to explicitly inform the |
|
@blueorangutan package |
|
@DaanHoogland a [SF] 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. |
DaanHoogland
left a comment
DaanHoogland
left a comment
There was a problem hiding this comment.
good code , but needs good functional verification
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 6180 |
|
@blueorangutan test matrix |
|
@DaanHoogland a [SF] Trillian-Jenkins matrix job (centos7 mgmt + xenserver71, rocky8 mgmt + vmware67u3, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-6627)
|
|
[SF] Trillian test result (tid-6628)
|
|
[SF] Trillian test result (tid-6629)
|
|
@JoaoJandre can you solve the conflicts? |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
@DaanHoogland I guess the conflicts solved themselves :D |
shwstppr
left a comment
shwstppr
left a comment
There was a problem hiding this comment.
@JoaoJandre do we need to move storage_pool_view to the view file now as per #7417?
|
@shwstppr done |
|
@blueorangutan package |
|
@shwstppr 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 test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
from the backend: Smoke tests completed. 117 look OK, 1 have errors, 0 did not run
github api rate limit hit, but I think we are ok with this one, @shwstppr. |
|
@blueorangutan package |
|
@GutoVeronezi 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. |
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 7860 |
|
@shwstppr @GutoVeronezi are we good with this one? |
LGTM, nothing more from my side. |
|
@DaanHoogland I'm good as it already has the required approvals. @JoaoJandre should we add some notes in the documentation to highlight the new behaviour? |
@JoaoJandre I added an issue for documentation and assigned you (#8283 ) merging |
@DaanHoogland Okay, I'll add it to my tasks and do it in the following days. |
Co-authored-by: João Jandre <joao@scclouds.com.br>
8 participants
Description
Currently when setting tags for a resource, a host for example, offerings with those tags will be directed towards that resource. However, offerings without any tags may also be directed towards it. Making it so even after tagging a resource, with the intention of making it exclusive to certain types of offerings, this exclusiveness might be ignored.
Furthermore, the current tag system only allows the user to inform a simple list of tags, without the possibility to create more complex rules, like checking if the offering has certain pairs of tags.
To address the described problems, we propose to create a new feature to allow users to use JS to create more complex tagging rules in the following APIs:
For this, we will use the JS interpreter introduced in #5909. We will introduce a new preset variable, called "tags", which can be used to refer to the offering's tags list that will be paired with the resource. A simple example of a rule using this preset variable is:
tags[0] == cereal && tags[1] == milkWhen setting a resource with this tag rule, only offerings whose first tag is cereal and second tag is milk will be accepted, offerings without tags will not be accepted. Although, this simple rule does not care for the rest of the offering's tags, so an offering with a third tag will also be accepted, no matter what the tag is.
To allow users to keep using the current tagging system without any hassle, we propose to introduce a new parameter to the affected APIs to inform if ACS should treat them the classic way, or to try to interpret it a rule in JS.
In order to support this behavior, we need to store which way the tags should be interpreted by ACS. We propose to add a new column called
is_tag_a_rulein the following tables:Furthermore, those same tables will have their tag column type changed from
varchar(255)totext, to allow rules that have more than 255 characters.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Unit tests were created, and some were updated. Moreover, manual tests were performed:
Regarding creating and updating storage pools (SP)
With the following situation in the environment:
Storage 1with ruletags[0] == 'milk'andStorage 2with ruletags[0] == 'cereal'milkcerealbananaWith the following situation in the environment:
Storage 1with ruletags[0] == 'milk'andStorage 2with tagcerealmilkcerealRegarding Hosts:
updateHostAPI to update a host tag to a flexible tagRegarding deploying VMs:
With the following situation in the environment:
Host 1with ruletags[0] == 'milk',Host 2andHost 3with ruletags[0] == cerealmilkcerealbananaWith the following situation in the environment:
Host 1with ruletags[0] == 'milk',Host 2andHost 3with tagcerealmilkcerealbananaRegarding quota activation rules:
value.host.isTagARule