This is an automated email from the ASF dual-hosted git repository.
rohit pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cloudstack.git
The following commit(s) were added to refs/heads/master by this push:
new cd637fd CLOUDSTACK-9875: Unable to re-apply Explicit dedication to VM
(#2042)
cd637fd is described below
commit cd637fd05f7c893824319c3040288166c82d6371
Author: harikrishna-patnala <[email protected]>
AuthorDate: Wed Dec 20 17:12:46 2017 +0530
CLOUDSTACK-9875: Unable to re-apply Explicit dedication to VM (#2042)
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".
---
.../affinity/AffinityGroupServiceImpl.java | 23 ++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git
a/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
b/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
index f2c91c8..fd0b937 100644
--- a/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
+++ b/server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
@@ -449,12 +449,23 @@ public class AffinityGroupServiceImpl extends ManagerBase
implements AffinityGro
throw new InvalidParameterValueException("Unable to find
affinity group by id " + affinityGroupId);
} else {
// verify permissions
- _accountMgr.checkAccess(caller, null, true, owner, ag);
- // Root admin has access to both VM and AG by default, but
make sure the
- // owner of these entities is same
- if (caller.getId() == Account.ACCOUNT_ID_SYSTEM ||
_accountMgr.isRootAdmin(caller.getId())) {
- if (ag.getAccountId() != owner.getAccountId()) {
- throw new PermissionDeniedException("Affinity Group "
+ ag + " does not belong to the VM's account");
+ if (ag.getAclType() == ACLType.Domain) {
+ _accountMgr.checkAccess(caller, null, false, owner, ag);
+ // make sure the affinity group is available in that domain
+ if (caller.getId() == Account.ACCOUNT_ID_SYSTEM ||
_accountMgr.isRootAdmin(caller.getId())) {
+ if (!isAffinityGroupAvailableInDomain(ag.getId(),
owner.getDomainId())) {
+ throw new PermissionDeniedException("Affinity
Group " + ag + " does not belong to the VM's domain");
+ }
+ }
+ } else {
+ _accountMgr.checkAccess(caller, null, true, owner, ag);
+ // Root admin has access to both VM and AG by default,
+ // but
+ // make sure the owner of these entities is same
+ if (caller.getId() == Account.ACCOUNT_ID_SYSTEM ||
_accountMgr.isRootAdmin(caller.getId())) {
+ if (ag.getAccountId() != owner.getAccountId()) {
+ throw new PermissionDeniedException("Affinity
Group " + ag + " does not belong to the VM's account");
+ }
}
}
}
--
To stop receiving notification emails like this one, please contact
['"[email protected]" <[email protected]>'].
