CLOUDSTACK-9875: Unable to re-apply Explicit dedication to VM#2042
Conversation
|
Followed the above, steps error shows up will adding back the affinity, Patch works fine, affinity can be set without any exceptions. LGTM
|
ACS CI BVT RunSumarry: Link to logs Folder (search by build_no): https://www.dropbox.com/sh/r2si930m8xxzavs/AAAzNrnoF1fC3auFrvsKo_8-a?dl=0 Failed tests:
Skipped tests: Passed test suits: |
|
Failed test case (test_03_RVR_Network_check_router_state) is not related to this fix. |
| _accountMgr.checkAccess(caller, null, false, owner, ag); | ||
| // Root admin has access to both VM and AG by default, | ||
| // but | ||
| // make sure the owner of these entities is same |
There was a problem hiding this comment.
sameOwner flag is set to false in _accountMgr.checkAccess(). Update the above comment, as the owner of the entity is not the same.
| } | ||
| } | ||
| } | ||
| } |
Problem: When a VM is deployed with in an Affinity group which has the cluster dedicated to a subdomain (zone is dedicated to parent domain) it is getting successful. We can also stop the vm and remove the affinity group, but if you want to add back the affinity it is failing. Root cause: During VM deployment there is clear check on affinity type (account/domain). Here since the acl_type is "domain" it does not expect to be same owner for entities. But during update of affinity to VM there is no specific check for acl_type "domain". Solution: Fix is to make the access check similar to VM deployment where it does not expect to be same owner for entities if the acl_type is "domain".
|
@blueorangutan package |
|
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. |
|
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1421 |
|
@blueorangutan test |
|
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
Trillian test result (tid-1830)
|
|
Tests LGTM, failures are not related to this PR. Merging. |
Problem:
When a VM is deployed with in an Affinity group which has the cluster dedicated to a subdomain (zone is dedicated to parent domain) it is getting successful. We can also stop the vm and remove the affinity group, but if you want to add back the affinity it is failing.
Following are the steps to reproduce
Root cause:
During VM deployment there is clear check on affinity type (account/domain). Here since the acl_type is "domain" it does not expect to be same owner for entities.
But during update of affinity to VM there is no specific check for acl_type "domain".
Solution:
Fix is to make the access check similar to VM deployment where it does not expect to be same owner for entities if the acl_type is "domain".