| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
@JoaoJandre , I haven´t got my head around how exactly this would work yet but it seems promising. |
Sorry, something went wrong.
|
@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? |
Sorry, something went wrong.
Codecov ReportAttention: 135 lines in your changes are missing coverage. Please review.
@@ 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. |
Sorry, something went wrong.
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Sorry, something went wrong.
@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? |
Sorry, something went wrong.
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 isTagARule parameter as true when calling the APIs to make the tags be interpreted as rules. |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
There was a problem hiding this comment.
good code , but needs good functional verification
Sorry, something went wrong.
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 6180 |
Sorry, something went wrong.
|
@DaanHoogland a [SF] Trillian-Jenkins matrix job (centos7 mgmt + xenserver71, rocky8 mgmt + vmware67u3, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests |
Sorry, something went wrong.
|
[SF] Trillian test result (tid-6627)
|
Sorry, something went wrong.
|
[SF] Trillian test result (tid-6628)
|
Sorry, something went wrong.
|
[SF] Trillian test result (tid-6629)
|
Sorry, something went wrong.
|
@JoaoJandre can you solve the conflicts? |
Sorry, something went wrong.
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Sorry, something went wrong.
@DaanHoogland I guess the conflicts solved themselves :D |
Sorry, something went wrong.
There was a problem hiding this comment.
@JoaoJandre do we need to move storage_pool_view to the view file now as per #7417?
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 7860 |
Sorry, something went wrong.
|
@shwstppr @GutoVeronezi are we good with this one? |
Sorry, something went wrong.
LGTM, nothing more from my side. |
Sorry, something went wrong.
|
@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? |
Sorry, something went wrong.
@JoaoJandre I added an issue for documentation and assigned you (#8283 ) merging |
Sorry, something went wrong.
@DaanHoogland Okay, I'll add it to my tasks and do it in the following days. |
Sorry, something went wrong.
Co-authored-by: João Jandre <joao@scclouds.com.br>
| Back | FazBrowse Home | New Git URL |
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] == milk
When 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_rule in the following tables:
Furthermore, those same tables will have their tag column type changed from varchar(255) to text, 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 1 with rule tags[0] == 'milk' and Storage 2 with rule tags[0] == 'cereal'
With the following situation in the environment:
Storage 1 with rule tags[0] == 'milk' and Storage 2 with tag cereal
Regarding Hosts:
Regarding deploying VMs:
With the following situation in the environment:
Host 1 with rule tags[0] == 'milk', Host 2 and Host 3 with rule tags[0] == cereal
With the following situation in the environment:
Host 1 with rule tags[0] == 'milk', Host 2 and Host 3 with tag cereal
Regarding quota activation rules: