[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350594#comment-16350594 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - blueorangutan commented on issue #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444#issuecomment-362630952 Trillian test result (tid-2220) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 17385 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2444-t2220-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_accounts.py Intermitten failure detected: /marvin/tests/smoke/test_affinity_groups_projects.py Intermitten failure detected: /marvin/tests/smoke/test_affinity_groups.py Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_deploy_vm_iso.py Intermitten failure detected: /marvin/tests/smoke/test_deploy_vm_root_resize.py Intermitten failure detected: /marvin/tests/smoke/test_deploy_vms_with_varied_deploymentplanners.py Intermitten failure detected: /marvin/tests/smoke/test_deploy_vm_with_userdata.py Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py Intermitten failure detected: /marvin/tests/smoke/test_iso.py Intermitten failure detected: /marvin/tests/smoke/test_list_ids_parameter.py Intermitten failure detected: /marvin/tests/smoke/test_loadbalance.py Intermitten failure detected: /marvin/tests/smoke/test_metrics_api.py Intermitten failure detected: /marvin/tests/smoke/test_migration.py Intermitten failure detected: /marvin/tests/smoke/test_multipleips_per_nic.py Intermitten failure detected: /marvin/tests/smoke/test_nested_virtualization.py Intermitten failure detected: /marvin/tests/smoke/test_network_acl.py Intermitten failure detected: /marvin/tests/smoke/test_network.py Intermitten failure detected: /marvin/tests/smoke/test_nic.py Intermitten failure detected: /marvin/tests/smoke/test_over_provisioning.py Intermitten failure detected: /marvin/tests/smoke/test_password_server.py Intermitten failure detected: /marvin/tests/smoke/test_portforwardingrules.py Intermitten failure detected: /marvin/tests/smoke/test_primary_storage.py Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_projects.py Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py Intermitten failure detected: /marvin/tests/smoke/test_reset_vm_on_reboot.py Intermitten failure detected: /marvin/tests/smoke/test_router_dhcphosts.py Intermitten failure detected: /marvin/tests/smoke/test_router_dns.py Intermitten failure detected: /marvin/tests/smoke/test_router_dnsservice.py Intermitten failure detected: /marvin/tests/smoke/test_routers_iptables_default_policy.py Intermitten failure detected: /marvin/tests/smoke/test_routers_network_ops.py Intermitten failure detected: /marvin/tests/smoke/test_routers.py Intermitten failure detected: /marvin/tests/smoke/test_secondary_storage.py Intermitten failure detected: /marvin/tests/smoke/test_service_offerings.py Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py Intermitten failure detected: /marvin/tests/smoke/test_templates.py Intermitten failure detected: /marvin/tests/smoke/test_usage.py Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_router_nics.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 22 look OK, 45 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_create_iso_with_checksum_sha1 | `Error` | 65.39 | test_iso.py test_02_create_iso_with_checksum_sha256 | `Error` | 65.40 | test_iso.py test_03_create_iso_with_checksum_md5 | `Error` | 65.40 | test_iso.py test_04_create_iso_with_no_checksum | `Error` | 65.39 | test_iso.py test_01_create_iso | `Failure` | 1513.02 | test_iso.py ContextSuite context=TestISO>:setup | `Error` | 3027.23 | test_iso.py ContextSuite context=TestAccounts>:setup | `Error` | 0.00 | test_accounts.py ContextSuite context=TestAddVmToSubDomain>:setup
[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350165#comment-16350165 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - blueorangutan commented on issue #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444#issuecomment-362555052 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow deletion of roles without causing concurrent exception > > > Key: CLOUDSTACK-10269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: Future, 4.11.1.1, 4.12.0.0 > > > Deletion of a role renames the role with a timestamp, when roles are > created/deleted aggresively it may cause concurrent exceptions. The fix is to > follow how other cloudstack entities are removed where name uniqueness need > to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350164#comment-16350164 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - rhtyd commented on issue #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444#issuecomment-362554954 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow deletion of roles without causing concurrent exception > > > Key: CLOUDSTACK-10269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: Future, 4.11.1.1, 4.12.0.0 > > > Deletion of a role renames the role with a timestamp, when roles are > created/deleted aggresively it may cause concurrent exceptions. The fix is to > follow how other cloudstack entities are removed where name uniqueness need > to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350132#comment-16350132 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - blueorangutan commented on issue #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444#issuecomment-362550533 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1689 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow deletion of roles without causing concurrent exception > > > Key: CLOUDSTACK-10269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: Future, 4.11.1.1, 4.12.0.0 > > > Deletion of a role renames the role with a timestamp, when roles are > created/deleted aggresively it may cause concurrent exceptions. The fix is to > follow how other cloudstack entities are removed where name uniqueness need > to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350099#comment-16350099 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - rhtyd commented on issue #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444#issuecomment-362544096 Roles related tests pass: ``` Test to ensure 4 default roles cannot be deleted ... === TestName: test_default_role_deletion | Status : SUCCESS === ok Test to check role, role permissions and account life cycles ... === TestName: test_role_account_acls | Status : SUCCESS === ok Test for role-rule enforcement in case of multiple mgmt servers ... === TestName: test_role_account_acls_multiple_mgmt_servers | Status : SUCCESS === ok Test to ensure role in use cannot be deleted ... === TestName: test_role_inuse_deletion | Status : SUCCESS === ok Tests normal lifecycle operations for roles ... === TestName: test_role_lifecycle_create | Status : SUCCESS === ok Tests role update ... === TestName: test_role_lifecycle_delete | Status : SUCCESS === ok Tests that default four roles exist ... === TestName: test_role_lifecycle_list | Status : SUCCESS === ok Tests role update ... === TestName: test_role_lifecycle_update | Status : SUCCESS === ok Tests role update when role is in use by an account ... === TestName: test_role_lifecycle_update_role_inuse | Status : SUCCESS === ok Tests concurrent order updation of role permission ... === TestName: test_rolepermission_lifecycle_concurrent_updates | Status : SUCCESS === ok Tests creation of role permission ... === TestName: test_rolepermission_lifecycle_create | Status : SUCCESS === ok Tests deletion of role permission ... === TestName: test_rolepermission_lifecycle_delete | Status : SUCCESS === ok Tests listing of default role's permission ... === TestName: test_rolepermission_lifecycle_list | Status : SUCCESS === ok Tests order updation of role permission ... === TestName: test_rolepermission_lifecycle_update | Status : SUCCESS === ok Tests update of Allow to Deny permission of a rule ... === TestName: test_rolepermission_lifecycle_update_permission | Status : SUCCESS === ok Tests negative test for setting incorrect value as permission ... === TestName: test_rolepermission_lifecycle_update_permission_negative | Status : SUCCESS === ok -- Ran 16 tests in 33.095s ``` This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow deletion of roles without causing concurrent exception > > > Key: CLOUDSTACK-10269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: Future, 4.11.1.1, 4.12.0.0 > > > Deletion of a role renames the role with a timestamp, when roles are > created/deleted aggresively it may cause concurrent exceptions. The fix is to > follow how other cloudstack entities are removed where name uniqueness need > to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350098#comment-16350098 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - blueorangutan commented on issue #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444#issuecomment-362544043 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow deletion of roles without causing concurrent exception > > > Key: CLOUDSTACK-10269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: Future, 4.11.1.1, 4.12.0.0 > > > Deletion of a role renames the role with a timestamp, when roles are > created/deleted aggresively it may cause concurrent exceptions. The fix is to > follow how other cloudstack entities are removed where name uniqueness need > to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350097#comment-16350097 ] ASF GitHub Bot commented on CLOUDSTACK-10269: - rhtyd opened a new pull request #2444: CLOUDSTACK-10269: On deletion of role set name to null URL: https://github.com/apache/cloudstack/pull/2444 During deletion of role, set name to null. This fixes concurrent exception issue where previously it would rename the deleted role with a timestamp. Pinging for review - @DaanHoogland @nvazquez @borisstoyanov and others. @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow deletion of roles without causing concurrent exception > > > Key: CLOUDSTACK-10269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: Future, 4.11.1.1, 4.12.0.0 > > > Deletion of a role renames the role with a timestamp, when roles are > created/deleted aggresively it may cause concurrent exceptions. The fix is to > follow how other cloudstack entities are removed where name uniqueness need > to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10269) Allow deletion of roles without causing concurrent exception
Rohit Yadav created CLOUDSTACK-10269: Summary: Allow deletion of roles without causing concurrent exception Key: CLOUDSTACK-10269 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10269 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: 4.11.1.1, 4.12.0.0, Future Deletion of a role renames the role with a timestamp, when roles are created/deleted aggresively it may cause concurrent exceptions. The fix is to follow how other cloudstack entities are removed where name uniqueness need to be honoured, i.e. by setting the field to null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350082#comment-16350082
]
ASF GitHub Bot commented on CLOUDSTACK-10054:
-
DaanHoogland commented on a change in pull request #2244:
CLOUDSTACK-10054:Volume download times out in 3600 seconds
URL: https://github.com/apache/cloudstack/pull/2244#discussion_r165599968
##
File path: core/src/main/java/com/cloud/storage/template/QCOW2Processor.java
##
@@ -40,6 +40,11 @@
private StorageLayer _storage;
+ @Override
+ public FormatInfo process(String templatePath, ImageFormat format, String
templateName, long processTimeout) throws InternalErrorException {
+ return process(templatePath, format, templateName);
Review comment:
this is not right. it closes the door for implementing this for KVM (and
other below) If this is really not applicable for any format but the VMware/OVA
bit it should not be on the generic interface.
If we do expect future implementation teh call hierarchy must be reversed:
the specific version calling the more generic one.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Volume download times out in 3600 seconds
> -
>
> Key: CLOUDSTACK-10054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: mrunalini
>Priority: Major
>
> Problem Statement -
> When tried to download a volume of type Vmware with large size, it fails in
> an hour before generating the URL.
> It can be seen in the ssvm logs that ova generation tar command fails/timed
> out in an hour. The volume is of 800GB and we should be able to increase the
> timeout. Unfortunately there is not method to do that. There is no global
> parameter to update the timeout for this operation.
> Solution
> Add a global parameter 'vmware.backup.session.timeout' for all the tar
> commands(commands taking long time)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350079#comment-16350079
]
ASF GitHub Bot commented on CLOUDSTACK-10054:
-
DaanHoogland commented on a change in pull request #2244:
CLOUDSTACK-10054:Volume download times out in 3600 seconds
URL: https://github.com/apache/cloudstack/pull/2244#discussion_r165599968
##
File path: core/src/main/java/com/cloud/storage/template/QCOW2Processor.java
##
@@ -40,6 +40,11 @@
private StorageLayer _storage;
+ @Override
+ public FormatInfo process(String templatePath, ImageFormat format, String
templateName, long processTimeout) throws InternalErrorException {
+ return process(templatePath, format, templateName);
Review comment:
this is not right. it closes the door for implementing this for KVM (and
other below) If this is really not applicable for any format but the VMware/OVA
bit it should not be on the generic interface.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Volume download times out in 3600 seconds
> -
>
> Key: CLOUDSTACK-10054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: mrunalini
>Priority: Major
>
> Problem Statement -
> When tried to download a volume of type Vmware with large size, it fails in
> an hour before generating the URL.
> It can be seen in the ssvm logs that ova generation tar command fails/timed
> out in an hour. The volume is of 800GB and we should be able to increase the
> timeout. Unfortunately there is not method to do that. There is no global
> parameter to update the timeout for this operation.
> Solution
> Add a global parameter 'vmware.backup.session.timeout' for all the tar
> commands(commands taking long time)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350060#comment-16350060 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - houthuis opened a new pull request #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442 ENVIRONMENT = XenServer Version : 6.2 , 7 ISSUE == Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are still active Repro. steps followed == Disabled Cluster from UI. Deploy a new VM Expected Behavior === After disabling the cluster , the hosts should be disabled. and no VM's can be deployed Note: it's the same results for XenServer or simulator, can't deploy on disabled hosts, but can deploy on disabled cluster Solution: Added a check to skip disabled clusters when selecting a host to deploy on. Deploying on a disabled cluster will now result in a InsufficientServerCapacityException, if no enabled clusters are found. i didn't want to propagate disabling a cluster down to the hosts, because then you would have to enable all the hosts again when you enable the cluster, and we won't know which hosts should be left in a disabled state This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350034#comment-16350034
]
ASF GitHub Bot commented on CLOUDSTACK-10147:
-
houthuis closed pull request #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster
can still deploy VM's
URL: https://github.com/apache/cloudstack/pull/2442
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
index cc244ce41ba..5d8ad0a7051 100644
--- a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
+++ b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
@@ -1040,6 +1040,11 @@ private DeployDestination
checkClustersforDestination(List clusterList, Vi
for (Long clusterId : clusterList) {
ClusterVO clusterVO = _clusterDao.findById(clusterId);
+if (clusterVO.getAllocationState() ==
Grouping.AllocationState.Disabled) {
+s_logger.debug("Cannot deploy in disabled cluster " +
clusterId + ", skipping this cluster");
+avoid.addCluster(clusterVO.getId());
+}
+
if (clusterVO.getHypervisorType() !=
vmProfile.getHypervisorType()) {
s_logger.debug("Cluster: " + clusterId + " has HyperVisorType
that does not match the VM, skipping this cluster");
avoid.addCluster(clusterVO.getId());
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Disabled Xenserver cluster can still deploy VMs
>
>
> Key: CLOUDSTACK-10147
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, UI
>Affects Versions: 4.10.0.0, 4.9.2.0
> Environment: Xenserver 6.2, 7
>Reporter: Glenn Wagner
>Assignee: Henko Holtzhausen
>Priority: Major
>
> ENVIRONMENT
> =
> XenServer Version : 6.2 , 7
> ISSUE
> ==
> Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are
> still active
> Repro. steps followed
> ==
> Disabled Cluster from UI.
> Deploy a new VM
> Expected Behavior
> ===
> After disabling the cluster , the hosts should be disabled. and no VM's can
> be deployed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9338) updateResourceCount not accounting resources of VMs with custom service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350023#comment-16350023 ] ASF GitHub Bot commented on CLOUDSTACK-9338: DaanHoogland commented on issue #2443: [CLOUDSTACK-9338] ACS is not accounting resources of VMs with custom service offering properly URL: https://github.com/apache/cloudstack/pull/2443#issuecomment-362529970 As @bwsw (wow a company involved) says, accounting is important and needs a lot of tlc. If we don't make regression tests and write fix over fix, regressions are bound to happen, @rafaelweingartner . So if you have the mental and clock space for it , please do. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > updateResourceCount not accounting resources of VMs with custom service > offering > > > Key: CLOUDSTACK-9338 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9338 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Cloudmonkey, UI >Affects Versions: 4.5.2, 4.8.0 > Environment: CloudStack 4.5.1 > MariaDB 10.0 and 10.1 >Reporter: Francois Scheurer >Assignee: Rafael Weingärtner >Priority: Major > > listAccount on a domain returns 0 for cputotal and memorytotal if the domain > accounts own VMs using a ComputeOffering with custom=enabled. > Basically, looking into the vm_instance table you get the service_offering_id > and in the service_offering table you find normally the amount of CPU/RAM > allocated for the VM. > But if your VM's ComputeOffering has custom=enabled, then you need to get the > specific CPU/RAM values from the user_vm_details table: > mysql> select * from user_vm_details WHERE vm_id=957; > Apparently the listAccount code is not doing that and it just returns zero, > because the service_offering table has cpu=0 and ram_size=0 for > ComputeOfferings with custom=enabled. > solution: the SQL query of listAccount should also look in the > user_vm_details table for matching rows. (instead of just querying in the > service_offering table) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350016#comment-16350016
]
ASF GitHub Bot commented on CLOUDSTACK-10147:
-
houthuis closed pull request #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster
can still deploy VM's
URL: https://github.com/apache/cloudstack/pull/2442
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
index cc244ce41ba..5d8ad0a7051 100644
--- a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
+++ b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
@@ -1040,6 +1040,11 @@ private DeployDestination
checkClustersforDestination(List clusterList, Vi
for (Long clusterId : clusterList) {
ClusterVO clusterVO = _clusterDao.findById(clusterId);
+if (clusterVO.getAllocationState() ==
Grouping.AllocationState.Disabled) {
+s_logger.debug("Cannot deploy in disabled cluster " +
clusterId + ", skipping this cluster");
+avoid.addCluster(clusterVO.getId());
+}
+
if (clusterVO.getHypervisorType() !=
vmProfile.getHypervisorType()) {
s_logger.debug("Cluster: " + clusterId + " has HyperVisorType
that does not match the VM, skipping this cluster");
avoid.addCluster(clusterVO.getId());
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Disabled Xenserver cluster can still deploy VMs
>
>
> Key: CLOUDSTACK-10147
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, UI
>Affects Versions: 4.10.0.0, 4.9.2.0
> Environment: Xenserver 6.2, 7
>Reporter: Glenn Wagner
>Assignee: Henko Holtzhausen
>Priority: Major
>
> ENVIRONMENT
> =
> XenServer Version : 6.2 , 7
> ISSUE
> ==
> Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are
> still active
> Repro. steps followed
> ==
> Disabled Cluster from UI.
> Deploy a new VM
> Expected Behavior
> ===
> After disabling the cluster , the hosts should be disabled. and no VM's can
> be deployed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350017#comment-16350017 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - houthuis opened a new pull request #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442 ENVIRONMENT = XenServer Version : 6.2 , 7 ISSUE == Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are still active Repro. steps followed == Disabled Cluster from UI. Deploy a new VM Expected Behavior === After disabling the cluster , the hosts should be disabled. and no VM's can be deployed Note: it's the same results for XenServer or simulator, can't deploy on disabled hosts, but can deploy on disabled cluster Solution: Added a check to skip disabled clusters when selecting a host to deploy on. Deploying on a disabled cluster will now result in a InsufficientServerCapacityException, if no enabled clusters are found. i didn't want to propagate disabling a cluster down to the hosts, because then you would have to enable all the hosts again when you enable the cluster, and we won't know which hosts should be left in a disabled state This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350009#comment-16350009
]
ASF GitHub Bot commented on CLOUDSTACK-10147:
-
houthuis closed pull request #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster
can still deploy VM's
URL: https://github.com/apache/cloudstack/pull/2442
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
index cc244ce41ba..5d8ad0a7051 100644
--- a/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
+++ b/server/src/main/java/com/cloud/deploy/DeploymentPlanningManagerImpl.java
@@ -1040,6 +1040,11 @@ private DeployDestination
checkClustersforDestination(List clusterList, Vi
for (Long clusterId : clusterList) {
ClusterVO clusterVO = _clusterDao.findById(clusterId);
+if (clusterVO.getAllocationState() ==
Grouping.AllocationState.Disabled) {
+s_logger.debug("Cannot deploy in disabled cluster " +
clusterId + ", skipping this cluster");
+avoid.addCluster(clusterVO.getId());
+}
+
if (clusterVO.getHypervisorType() !=
vmProfile.getHypervisorType()) {
s_logger.debug("Cluster: " + clusterId + " has HyperVisorType
that does not match the VM, skipping this cluster");
avoid.addCluster(clusterVO.getId());
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Disabled Xenserver cluster can still deploy VMs
>
>
> Key: CLOUDSTACK-10147
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, UI
>Affects Versions: 4.10.0.0, 4.9.2.0
> Environment: Xenserver 6.2, 7
>Reporter: Glenn Wagner
>Assignee: Henko Holtzhausen
>Priority: Major
>
> ENVIRONMENT
> =
> XenServer Version : 6.2 , 7
> ISSUE
> ==
> Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are
> still active
> Repro. steps followed
> ==
> Disabled Cluster from UI.
> Deploy a new VM
> Expected Behavior
> ===
> After disabling the cluster , the hosts should be disabled. and no VM's can
> be deployed
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10147) Disabled Xenserver cluster can still deploy VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350010#comment-16350010 ] ASF GitHub Bot commented on CLOUDSTACK-10147: - houthuis opened a new pull request #2442: CLOUDSTACK-10147 Disabled Xenserver Cluster can still deploy VM's URL: https://github.com/apache/cloudstack/pull/2442 ENVIRONMENT = XenServer Version : 6.2 , 7 ISSUE == Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are still active Repro. steps followed == Disabled Cluster from UI. Deploy a new VM Expected Behavior === After disabling the cluster , the hosts should be disabled. and no VM's can be deployed Note: it's the same results for XenServer or simulator, can't deploy on disabled hosts, but can deploy on disabled cluster Solution: Added a check to skip disabled clusters when selecting a host to deploy on. Deploying on a disabled cluster will now result in a InsufficientServerCapacityException, if no enabled clusters are found. i didn't want to propagate disabling a cluster down to the hosts, because then you would have to enable all the hosts again when you enable the cluster, and we won't know which hosts should be left in a disabled state This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Disabled Xenserver cluster can still deploy VMs > > > Key: CLOUDSTACK-10147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10147 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Xenserver 6.2, 7 >Reporter: Glenn Wagner >Assignee: Henko Holtzhausen >Priority: Major > > ENVIRONMENT > = > XenServer Version : 6.2 , 7 > ISSUE > == > Disabled Xenserver Cluster can still deploy VM's , hosts in the cluster are > still active > Repro. steps followed > == > Disabled Cluster from UI. > Deploy a new VM > Expected Behavior > === > After disabling the cluster , the hosts should be disabled. and no VM's can > be deployed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350007#comment-16350007 ] ASF GitHub Bot commented on CLOUDSTACK-4045: houthuis opened a new pull request #2382: CLOUDSTACK-4045 IP address acquired with associateIpAddress is marked as source NAT URL: https://github.com/apache/cloudstack/pull/2382 added a check for network state when determining whether a new IP should be source NAT. this prevents associated IP's to be marked as source NAT when the network is in allocated state, causing disassociateIpAddress to fail later Code will now throw a InvalidParameterValueException in the above scenario. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Henko Holtzhausen >Priority: Major > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350006#comment-16350006
]
ASF GitHub Bot commented on CLOUDSTACK-4045:
houthuis closed pull request #2382: CLOUDSTACK-4045 IP address acquired with
associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/server/src/main/java/com/cloud/network/IpAddressManagerImpl.java
b/server/src/main/java/com/cloud/network/IpAddressManagerImpl.java
index c00359c92f0..d0b3098c3d3 100644
--- a/server/src/main/java/com/cloud/network/IpAddressManagerImpl.java
+++ b/server/src/main/java/com/cloud/network/IpAddressManagerImpl.java
@@ -1370,16 +1370,7 @@ public IPAddressVO associateIPToGuestNetwork(long ipId,
long networkId, boolean
}
}
-NetworkOffering offering =
_networkOfferingDao.findById(network.getNetworkOfferingId());
-boolean sharedSourceNat = offering.getSharedSourceNat();
-boolean isSourceNat = false;
-if (!sharedSourceNat) {
-if (getExistingSourceNatInNetwork(owner.getId(), networkId) ==
null) {
-if (network.getGuestType() == GuestType.Isolated &&
network.getVpcId() == null && !ipToAssoc.isPortable()) {
-isSourceNat = true;
-}
-}
-}
+boolean isSourceNat = isSourceNatAvailableForNetwork(owner, ipToAssoc,
network);
s_logger.debug("Associating ip " + ipToAssoc + " to network " +
network);
@@ -1417,6 +1408,25 @@ public IPAddressVO associateIPToGuestNetwork(long ipId,
long networkId, boolean
}
}
+protected boolean isSourceNatAvailableForNetwork(Account owner,
IPAddressVO ipToAssoc, Network network) {
+NetworkOffering offering =
_networkOfferingDao.findById(network.getNetworkOfferingId());
+boolean sharedSourceNat = offering.getSharedSourceNat();
+boolean isSourceNat = false;
+if (!sharedSourceNat) {
+if (getExistingSourceNatInNetwork(owner.getId(), network.getId())
== null) {
+if (network.getGuestType() == GuestType.Isolated &&
network.getVpcId() == null && !ipToAssoc.isPortable()) {
+if (network.getState() == Network.State.Allocated) {
+//prevent associating an ip address to an allocated
(unimplemented network).
+//it will cause the ip to become source nat, and it
can't be disassociated later on.
+throw new InvalidParameterValueException("Network is
in allocated state, implement network first before acquiring an IP address");
+}
+isSourceNat = true;
+}
+}
+}
+return isSourceNat;
+}
+
protected boolean isSharedNetworkOfferingWithServices(long
networkOfferingId) {
NetworkOfferingVO networkOffering =
_networkOfferingDao.findById(networkOfferingId);
if ((networkOffering.getGuestType() == Network.GuestType.Shared)
diff --git a/server/src/test/java/com/cloud/network/IpAddressManagerTest.java
b/server/src/test/java/com/cloud/network/IpAddressManagerTest.java
index 0bf92ee2f69..fe11292e826 100644
--- a/server/src/test/java/com/cloud/network/IpAddressManagerTest.java
+++ b/server/src/test/java/com/cloud/network/IpAddressManagerTest.java
@@ -17,38 +17,74 @@
package com.cloud.network;
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.exception.ResourceUnavailableException;
+import com.cloud.network.dao.IPAddressDao;
+import com.cloud.network.dao.IPAddressVO;
+import com.cloud.network.dao.NetworkDao;
+import com.cloud.network.dao.NetworkVO;
+import com.cloud.network.rules.StaticNat;
+import com.cloud.network.rules.StaticNatImpl;
+import com.cloud.offerings.NetworkOfferingVO;
+import com.cloud.offerings.dao.NetworkOfferingDao;
+import com.cloud.user.AccountVO;
+import com.cloud.utils.net.Ip;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
+import org.mockito.Mockito;
import org.mockito.MockitoAnnotations;
-
-import com.cloud.network.dao.IPAddressDao;
-import com.cloud.network.dao.IPAddressVO;
-import com.cloud.network.rules.StaticNat;
-import com.cloud.network.rules.StaticNatImpl;
-import com.cloud.utils.net.Ip;
-
-import static org.mockito.Mockito.when;
+import org.mockito.Spy;
import java.util.Collections;
import java.util.List;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
import static
