[jira] [Commented] (CLOUDSTACK-9756) IP address must not be allocated to other VR if releasing ip address is failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956398#comment-15956398 ] ASF GitHub Bot commented on CLOUDSTACK-9756: Github user kishankavala commented on the issue: https://github.com/apache/cloudstack/pull/1917 Code LGTM > IP address must not be allocated to other VR if releasing ip address is > failed > --- > > Key: CLOUDSTACK-9756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.10.0.0 > > > Apply rule (delete) is success on failure of ip assoc on back end. Cloudstack > ignored the ip assoc failure. > Due to this the ip got freed and assigned to another network/account. It > caused the ip to be present in more than one router. > Fix: Failing the apply rule (delete) on ipassoc failure > Repro steps: > 1. Configure PF/static nat/Firewall rules > 2. Delete the rule configured. > On deleting the rule, fail the ip assoc on the router. > 3. Delete rule fails because ip assoc got failed. > For RVR: > 1. acquire several public ips, > 2. add some rules on those public ips, so ips should show up in RVR, > 3. change ipassoc.sh in RVR, make it always returns error on disassociate ip. > 4. disassociate ip from UI, ip should is freed even though disassociate > fails inside VR. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956349#comment-15956349 ] ASF GitHub Bot commented on CLOUDSTACK-9099: Github user kishankavala commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1996#discussion_r109835294 --- Diff: server/src/com/cloud/user/AccountManager.java --- @@ -198,4 +200,11 @@ void buildACLViewSearchCriteria(SearchCriteria s public static final String MESSAGE_ADD_ACCOUNT_EVENT = "Message.AddAccount.Event"; public static final String MESSAGE_REMOVE_ACCOUNT_EVENT = "Message.RemoveAccount.Event"; +public static final ConfigKey UseSecretKeyInResponse = new ConfigKey( +"Advanced", +Boolean.class, +"use.secret.key.in.response", +"true", --- End diff -- As per discussion in PR # 1152, default value should be false. Any failing tests due to this change have to be fixed. > SecretKey is returned from the APIs > --- > > Key: CLOUDSTACK-9099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0 >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > Fix For: 4.10.0.0, 4.9.3.0 > > > The sercreKey parameter is returned from the following APIs: > createAccount > createUser > disableAccount > disableUser > enableAccount > enableUser > listAccounts > listUsers > lockAccount > lockUser > registerUserKeys > updateAccount > updateUser -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9861) Expire VM snapshots after configured duration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956292#comment-15956292 ] ASF GitHub Bot commented on CLOUDSTACK-9861: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2026 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-616 > Expire VM snapshots after configured duration > - > > Key: CLOUDSTACK-9861 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9861 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Abhinandan Prateek > > Currently, users can keep VM snapshots for an indefinite time period. > Long-lived snapshots can cause stability issues on the hypervisor. > Requirement: Add a timeout for VM Snapshots, whereby snapshots get > automatically deleted after a given time period. This would be available at > account level, with a default value determined by a global setting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9861) Expire VM snapshots after configured duration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956281#comment-15956281 ] ASF GitHub Bot commented on CLOUDSTACK-9861: Github user abhinandanprateek commented on the issue: https://github.com/apache/cloudstack/pull/2026 @blueorangutan package > Expire VM snapshots after configured duration > - > > Key: CLOUDSTACK-9861 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9861 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Abhinandan Prateek > > Currently, users can keep VM snapshots for an indefinite time period. > Long-lived snapshots can cause stability issues on the hypervisor. > Requirement: Add a timeout for VM Snapshots, whereby snapshots get > automatically deleted after a given time period. This would be available at > account level, with a default value determined by a global setting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9861) Expire VM snapshots after configured duration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956282#comment-15956282 ] ASF GitHub Bot commented on CLOUDSTACK-9861: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2026 @abhinandanprateek a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Expire VM snapshots after configured duration > - > > Key: CLOUDSTACK-9861 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9861 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Abhinandan Prateek > > Currently, users can keep VM snapshots for an indefinite time period. > Long-lived snapshots can cause stability issues on the hypervisor. > Requirement: Add a timeout for VM Snapshots, whereby snapshots get > automatically deleted after a given time period. This would be available at > account level, with a default value determined by a global setting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9861) Expire VM snapshots after configured duration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956240#comment-15956240 ] ASF GitHub Bot commented on CLOUDSTACK-9861: GitHub user abhinandanprateek opened a pull request: https://github.com/apache/cloudstack/pull/2026 CLOUDSTACK-9861: Expire VM snapshots after configured duration Default value of the account level global config vmsnapshot.expire.interval is -1 that conforms to legacy behaviour A positive value will expire the VM snapshots for the respective account in that many hours You can merge this pull request into a Git repository by running: $ git pull https://github.com/shapeblue/cloudstack ir25-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/2026.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2026 commit 1c6a30a0e65f2bc9b1d97920d1562b35f3b682ee Author: Abhinandan Prateek Date: 2017-03-28T12:07:59Z CLOUDSTACK-9861: Expire VM snapshots after configured duration Default value of the account level global config vmsnapshot.expire.interval is -1 that conforms to legacy behaviour A positive value will expire the VM snapshots for the respective account in that many hours > Expire VM snapshots after configured duration > - > > Key: CLOUDSTACK-9861 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9861 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Abhinandan Prateek > > Currently, users can keep VM snapshots for an indefinite time period. > Long-lived snapshots can cause stability issues on the hypervisor. > Requirement: Add a timeout for VM Snapshots, whereby snapshots get > automatically deleted after a given time period. This would be available at > account level, with a default value determined by a global setting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9861) Expire VM snapshots after configured duration
Abhinandan Prateek created CLOUDSTACK-9861: -- Summary: Expire VM snapshots after configured duration Key: CLOUDSTACK-9861 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9861 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Abhinandan Prateek Currently, users can keep VM snapshots for an indefinite time period. Long-lived snapshots can cause stability issues on the hypervisor. Requirement: Add a timeout for VM Snapshots, whereby snapshots get automatically deleted after a given time period. This would be available at account level, with a default value determined by a global setting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9572) Snapshot on primary storage not cleaned up after Storage migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956154#comment-15956154 ] ASF GitHub Bot commented on CLOUDSTACK-9572: Github user mrunalinikankariya commented on the issue: https://github.com/apache/cloudstack/pull/1740 In ACS, all the snapshots are deleted from primary storage as soon as it is successfully backed up and copied on secondary storage, hence this issue is not valid for ACS. However a ticket should be raised to analysis and understand how incremental snapshots work if not a single copy kept on primary. > Snapshot on primary storage not cleaned up after Storage migration > -- > > Key: CLOUDSTACK-9572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.8.0 > Environment: Xen Server >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Issue Description > === > 1. Create an instance on the local storage on any host > 2. Create a scheduled snapshot of the volume: > 3. Wait until ACS created the snapshot. ACS is creating a snapshot on local > storage and is transferring this snapshot to secondary storage. But the > latest snapshot on local storage will stay there. This is as expected. > 4. Migrate the instance to another XenServer host with ACS UI and Storage > Live Migration > 5. The Snapshot on the old host on local storage will not be cleaned up and > is staying on local storage. So local storage will fill up with unneeded > snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9783) Improve metrics view performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955877#comment-15955877 ] ASF GitHub Bot commented on CLOUDSTACK-9783: Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1944 Please ommit my last comment, we were using commons-beanutils version 1.8.3 instead of 1.9.2 LGTM [root@ussarlabcsmgt41 cloudstack]# cat /tmp//MarvinLogs//DVIXST/results.txt test_list_clusters_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_clusters_metrics | Status : SUCCESS === ok test_list_hosts_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_hosts_metrics | Status : SUCCESS === ok test_list_infrastructure_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_infrastructure_metrics | Status : SUCCESS === ok test_list_pstorage_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_pstorage_metrics | Status : SUCCESS === ok test_list_vms_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_vms_metrics | Status : SUCCESS === ok test_list_volumes_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_volumes_metrics | Status : SUCCESS === ok test_list_zones_metrics (test_metrics_api.TestMetrics) ... === TestName: test_list_zones_metrics | Status : SUCCESS === ok -- Ran 7 tests in 142.134s OK > Improve metrics view performance > > > Key: CLOUDSTACK-9783 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9783 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0, 4.9.3.0 > > > Metrics view is a pure frontend feature, where several API calls are made to > generate the metrics view tabular data. In very large environments, rendering > of these tables can take a lot of time, especially when there is high > latency. The improvement task is to reimplement this feature by moving the > logic to backend so metrics calculations happen at the backend and final > result can be served by a single API request. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9679) Allow master user to manage subordinate user uploaded template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955821#comment-15955821 ] ASF GitHub Bot commented on CLOUDSTACK-9679: Github user pdion891 commented on the issue: https://github.com/apache/cloudstack/pull/1834 @pdumbre @karuturi @syed I thinks this introduce an issue where a domain admin cannot get a template by id. a domain admin can list feature template and get a template via `ids=` but not with `id=` The example bellow is perform with a domain admin account to list public+featured template at root domain: ``` (beta2r1-ninja) > list templates templatefilter=featured filter=name,id count = 9 template: +--+-+ | id | name | +--+-+ | 513b3a6d-c011-46f0-a4a3-2a954cadb673 | CoreOS Alpha 1367.5.0 | | 0c04d876-1f85-45a7-b6f4-504de435bf12 |Debian 8.5 PV base (64bit) | | 285f2203-449a-428f-997a-1ffbebbf1382 | CoreOS Alpha | | 332b6ca8-b3d6-42c7-83e5-60fe87be6576 | CoreOS Stable | | 3b705008-c186-464d-ad59-312d902420af | Windows Server 2016 std SPLA | | 4256aebe-a1c1-4b49-9993-de2bc712d521 | Ubuntu 16.04.01 HVM | | 59e6b00a-b88e-4539-aa3c-75c9c7e9fa6c | Ubuntu 14.04.5 HVM base (64bit) | | 3ab936eb-d8c2-44d8-a64b-17ad5adf8a51 | CentOS 6.8 PV | | 7de5d423-c91e-49cc-86e8-9d6ed6abd997 | CentOS 7.2 HVM | +--+-+ (beta2r1-ninja) > list templates templatefilter=featured id=7de5d423-c91e-49cc-86e8-9d6ed6abd997 filter=name,id Error 531: Acct[b285d62e-0ec2-4a7c-b773-961595ec6356-Ninja-5664] does not have permission to operate within domain id=c9b4f83d-16eb-11e7-a8b9-367e6fe958a9 cserrorcode = 4365 errorcode = 531 errortext = Acct[b285d62e-0ec2-4a7c-b773-961595ec6356-Ninja-5664] does not have permission to operate within domain id=c9b4f83d-16eb-11e7-a8b9-367e6fe958a9 uuidList: (beta2r1-ninja) > list templates templatefilter=featured ids=7de5d423-c91e-49cc-86e8-9d6ed6abd997 filter=name,id count = 1 template: +--++ | id | name | +--++ | 7de5d423-c91e-49cc-86e8-9d6ed6abd997 | CentOS 7.2 HVM | +--++ ``` > Allow master user to manage subordinate user uploaded template > -- > > Key: CLOUDSTACK-9679 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9679 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: pallavi Dumbre > > REPRO STEPS > == > 1. Create Master User Aaron > 2. Create common user feixiang within tenant Aaron > 3. Login as feixiang, upload template CentOS56 > 4. Login as Aaron, go to Template view ,unable to see feixiang's template > CentOS56 > EXPECTED BEHAVIOR > == > Login as master user can view all subordinate user's template > > ACTUAL BEHAVIOR > == > Only master user itself upload template to manageable > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9512) listTemplates ids returns all templates instead of the requested ones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955741#comment-15955741 ] Pierre-Luc Dion commented on CLOUDSTACK-9512: - Hi [~rajanik], I've just look at this issue and is not visible in 4.10 at the moment. should we close this issue ? {code} (beta1t2-ninja) > list templates templatefilter=all ids=e85972ad-9267-4798-a9c2-175141653bb9,74fa60e2-93a7-46bf-b410-c64471a21e78 filter=id,name count = 2 template: +--+-+ | id | name | +--+-+ | e85972ad-9267-4798-a9c2-175141653bb9 | Windows Server 2008 R2 ent BYOL | | 74fa60e2-93a7-46bf-b410-c64471a21e78 | Windows Server 2016 CORE SPLA | +--+-+ {code} > listTemplates ids returns all templates instead of the requested ones > - > > Key: CLOUDSTACK-9512 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9512 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Template >Affects Versions: 4.8.1 > Environment: CentOS 7.2 + VMWare 5.5u3 + NFS primary/secondary storage >Reporter: Boris Stoyanov >Priority: Critical > Labels: 4.8.2.0-smoke-test-failure > Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0 > > > Actual call form the logs: > {code}{'account': u'test-a-TestListIdsParams-KYBF19', > 'domainid': u'41c6fda1-84cf-11e6-bbd2-066638010710', > 'ids': > u'a4bcd20f-0c4c-4999-bb5e-02aab8f763a1,10a429da-829b-4492-9674-26b1c172462e,d3a9a86d-17a1-4199-8116-ceefc6ef31d5', > > 'apiKey': > u'LIN6rqXuaJwMPfGYFh13qDwYz5VNNz1J2J6qIOWcd3oLQOq0WtD4CwRundBL6rzXToa3lQOC_vKjI3nkHtiD8Q', > > 'command': 'listTemplates', > 'listall': True, > 'signature': 'Yo7dRnPdSch+mEzcF8TTo1xhxpo=', > 'templatefilter': 'all', > 'response': 'json', > 'listAll': True}{code} > When asking to list 3 or more > {code}(local) SBCM5> list templates templatefilter=all > ids=a4bcd20f-0c4c-4999-bb5e-02aab8f763a1,10a429da-829b-4492-9674-26b1c172462e,d3a9a86d-17a1-4199-8116-ceefc6ef31d5{code} > You receive all templates (count: 14) > Response > {code} > { > "count": 14, > "template": [ > { > "account": "system", > "checksum": "4b415224fe00b258f66cad9fce9f73fc", > "created": "2016-09-27T17:38:31+0100", > "crossZones": true, > "displaytext": "SystemVM Template (vSphere)", > "domain": "ROOT", > "domainid": "41c6fda1-84cf-11e6-bbd2-066638010710", > "format": "OVA", > "hypervisor": "VMware", > "id": "6114746a-aefa-4be7-8234-f0d76ff175d0", > "isdynamicallyscalable": true, > "isextractable": false, > "isfeatured": false, > "ispublic": false, > "isready": true, > "name": "SystemVM Template (vSphere)", > "ostypeid": "41db0847-84cf-11e6-bbd2-066638010710", > "ostypename": "Debian GNU/Linux 5.0 (64-bit)", > "passwordenabled": false, > "size": 3145728000, > "sshkeyenabled": false, > "status": "Download Complete", > "tags": [], > "templatetype": "SYSTEM", > "zoneid": "b8d4cea4-6b4b-4cfb-9f17-0a6b31fec09f", > . > . > . > . > . > > }{code} > Marvin failure: > {code}2016-09-29 11:43:39,819 - CRITICAL - FAILED: test_02_list_templates: > ['Traceback (most recent call last):\n', ' File > "/usr/lib64/python2.7/unittest/case.py", line 369, in run\n > testMethod()\n', ' File "/marvin/tests/smoke/test_list_ids_parameter.py", > line 253, in test_02_list_templates\n"ListTemplates response expected 3 > Templates, received %s" % len(list_template_response)\n', ' File > "/usr/lib64/python2.7/unittest/case.py", line 553, in assertEqual\n > assertion_func(first, second, msg=msg)\n', ' File > "/usr/lib64/python2.7/unittest/case.py", line 546, in _baseAssertEqual\n > raise self.failureException(msg)\n', 'AssertionError: ListTemplates response > expected 3 Templates, received 14\n']{code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955355#comment-15955355 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/1935 @blueorangutan test > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29 > 2017-01-26 06:07:44,319 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled projects to cleanup > ... > // Failure due to domain is alr
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955356#comment-15955356 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1935 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29 > 2017-01-26 06:07:44,319 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ct
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955335#comment-15955335 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1935 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-614 > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29 > 2017-01-26 06:07:44,319 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled projects to cleanup > ...
[jira] [Commented] (CLOUDSTACK-9842) Unable to map root volume usage to VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955316#comment-15955316 ] ASF GitHub Bot commented on CLOUDSTACK-9842: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/2012 Tested this change. LGTM for test > Unable to map root volume usage to VM > - > > Key: CLOUDSTACK-9842 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9842 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > If a VM is cold migrated the vm_instance_id and uuid of volume is nullified. > So there is no link between volume and vm. > With this the ROOT volume usage can not be mapped to a VM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9208) Assertion Error in VM_POWER_STATE handler.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955310#comment-15955310 ] ASF GitHub Bot commented on CLOUDSTACK-9208: Github user DaanHoogland commented on the issue: https://github.com/apache/cloudstack/pull/1997 @jayapalu your check is ok, what is not ok is that it is needed. Somehow a stop can be send to a VM for which no host is known? I am worried about the reason of your fix and that we might obscure it. Why is a stop command attempted on a vm for which no host is known? > Assertion Error in VM_POWER_STATE handler. > -- > > Key: CLOUDSTACK-9208 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9208 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal >Priority: Minor > > 1. Enable the assertions. > LOG > 2015-12-31 04:09:06,687 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-981a85d4) (logid:863754b8) Found 0 networks to > update RvR status. > 2015-12-31 04:09:07,394 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Ping from 5(10.147.40.18) > 2015-12-31 04:09:07,394 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Process host VM state > report from ping process. host: 5 > 2015-12-31 04:09:07,416 INFO [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Unable to find matched > VM in CloudStack DB. name: New Virtual Machine > 2015-12-31 04:09:07,420 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Process VM state report. > host: 5, number of records in report: 5 > 2015-12-31 04:09:07,420 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) VM state report. host: > 5, vm id: 69, power state: PowerOff > 2015-12-31 04:09:07,530 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) VM state report is > updated. host: 5, vm id: 69, power state: PowerOff > 2015-12-31 04:09:07,540 INFO [c.c.v.VirtualMachineManagerImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) VM r-69-VM is at Stopped > and we received a power-off report while there is no pending jobs on it > 2015-12-31 04:09:07,541 ERROR [o.a.c.f.m.MessageDispatcher] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Unexpected exception > when calling > com.cloud.vm.ClusteredVirtualMachineManagerImpl.HandlePowerStateReport > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.cloudstack.framework.messagebus.MessageDispatcher.dispatch(MessageDispatcher.java:75) > at > org.apache.cloudstack.framework.messagebus.MessageDispatcher.onPublishMessage(MessageDispatcher.java:45) > at > org.apache.cloudstack.framework.messagebus.MessageBusBase$SubscriptionNode.notifySubscribers(MessageBusBase.java:441) > at > org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:178) > at > com.cloud.vm.VirtualMachinePowerStateSyncImpl.processReport(VirtualMachinePowerStateSyncImpl.java:87) > at > com.cloud.vm.VirtualMachinePowerStateSyncImpl.processHostVmStatePingReport(VirtualMachinePowerStateSyncImpl.java:70) > at > com.cloud.vm.VirtualMachineManagerImpl.processCommands(VirtualMachineManagerImpl.java:2879) > at > com.cloud.agent.manager.AgentManagerImpl.handleCommands(AgentManagerImpl.java:309) > at > com.cloud.agent.manager.DirectAgentAttache$PingTask.runInContext(DirectAgentAttache.java:192) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTas
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955306#comment-15955306 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user rafaelweingartner commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1935#discussion_r103529571 --- Diff: server/src/com/cloud/user/DomainManagerImpl.java --- @@ -273,82 +284,145 @@ public boolean deleteDomain(long domainId, Boolean cleanup) { @Override public boolean deleteDomain(DomainVO domain, Boolean cleanup) { -// mark domain as inactive -s_logger.debug("Marking domain id=" + domain.getId() + " as " + Domain.State.Inactive + " before actually deleting it"); -domain.setState(Domain.State.Inactive); -_domainDao.update(domain.getId(), domain); -boolean rollBackState = false; -boolean hasDedicatedResources = false; +GlobalLock lock = getGlobalLock("AccountCleanup"); +if (lock == null) { +s_logger.debug("Couldn't get the global lock"); +return false; +} + +if (!lock.lock(30)) { +s_logger.debug("Couldn't lock the db"); +return false; +} try { -long ownerId = domain.getAccountId(); -if ((cleanup != null) && cleanup.booleanValue()) { -if (!cleanupDomain(domain.getId(), ownerId)) { -rollBackState = true; -CloudRuntimeException e = -new CloudRuntimeException("Failed to clean up domain resources and sub domains, delete failed on domain " + domain.getName() + " (id: " + -domain.getId() + ")."); -e.addProxyObject(domain.getUuid(), "domainId"); -throw e; -} -} else { -//don't delete the domain if there are accounts set for cleanup, or non-removed networks exist, or domain has dedicated resources -List networkIds = _networkDomainDao.listNetworkIdsByDomain(domain.getId()); -List accountsForCleanup = _accountDao.findCleanupsForRemovedAccounts(domain.getId()); -List dedicatedResources = _dedicatedDao.listByDomainId(domain.getId()); -if (dedicatedResources != null && !dedicatedResources.isEmpty()) { -s_logger.error("There are dedicated resources for the domain " + domain.getId()); -hasDedicatedResources = true; -} -if (accountsForCleanup.isEmpty() && networkIds.isEmpty() && !hasDedicatedResources) { -_messageBus.publish(_name, MESSAGE_PRE_REMOVE_DOMAIN_EVENT, PublishScope.LOCAL, domain); -if (!_domainDao.remove(domain.getId())) { -rollBackState = true; -CloudRuntimeException e = -new CloudRuntimeException("Delete failed on domain " + domain.getName() + " (id: " + domain.getId() + -"); Please make sure all users and sub domains have been removed from the domain before deleting"); -e.addProxyObject(domain.getUuid(), "domainId"); -throw e; -} -_messageBus.publish(_name, MESSAGE_REMOVE_DOMAIN_EVENT, PublishScope.LOCAL, domain); +// mark domain as inactive +s_logger.debug("Marking domain id=" + domain.getId() + " as " + Domain.State.Inactive + " before actually deleting it"); +domain.setState(Domain.State.Inactive); +_domainDao.update(domain.getId(), domain); + +boolean rollBackState = false; + +try { +long ownerId = domain.getAccountId(); +if (BooleanUtils.toBoolean(cleanup)) { +tryCleanupDomain(domain, ownerId); } else { -rollBackState = true; -String msg = null; -if (!accountsForCleanup.isEmpty()) { -msg = accountsForCleanup.size() + " accounts to cleanup"; -} else if (!networkIds.isEmpty()) { -msg = networkIds.size() + " non-removed networks"; -} else if (hasDedicatedResources) { -msg = "dedicated resources."; -} + removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain); +}
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955307#comment-15955307 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user rafaelweingartner commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1935#discussion_r103529869 --- Diff: server/test/com/cloud/user/DomainManagerImplTest.java --- @@ -134,4 +164,69 @@ public void testFindDomainByIdOrPathValidId() { Assert.assertEquals(domain, domainManager.findDomainByIdOrPath(1L, "/validDomain/")); } +@Test(expected=InvalidParameterValueException.class) +public void testDeleteDomainNullDomain() { +Mockito.when(_domainDao.findById(DOMAIN_ID)).thenReturn(null); +domainManager.deleteDomain(DOMAIN_ID, testDomainCleanup); +} + +@Test(expected=PermissionDeniedException.class) +public void testDeleteDomainRootDomain() { + Mockito.when(_domainDao.findById(Domain.ROOT_DOMAIN)).thenReturn(domain); +domainManager.deleteDomain(Domain.ROOT_DOMAIN, testDomainCleanup); +} + +@Test +public void testDeleteDomainNoCleanup() { +domainManager.deleteDomain(DOMAIN_ID, testDomainCleanup); +Mockito.verify(domainManager).deleteDomain(domain, testDomainCleanup); + Mockito.verify(domainManager).removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain); +Mockito.verify(domainManager).cleanupDomainOfferings(DOMAIN_ID); +Mockito.verify(lock).unlock(); +} + +@Test +public void testRemoveDomainWithNoAccountsForCleanupNetworksOrDedicatedResourcesRemoveDomain() { + domainManager.removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain); + Mockito.verify(domainManager).publishRemoveEventsAndRemoveDomain(domain); +} + +@Test(expected=CloudRuntimeException.class) +public void testRemoveDomainWithNoAccountsForCleanupNetworksOrDedicatedResourcesDontRemoveDomain() { +domainNetworkIds.add(2l); + domainManager.removeDomainWithNoAccountsForCleanupNetworksOrDedicatedResources(domain); +Mockito.verify(domainManager).failRemoveOperation(domain, domainAccountsForCleanup, domainNetworkIds, false); +} + +@Test +public void testPublishRemoveEventsAndRemoveDomainSuccessfulDelete() { +domainManager.publishRemoveEventsAndRemoveDomain(domain); +Mockito.verify(_messageBus).publish(Mockito.anyString(), Matchers.eq(DomainManager.MESSAGE_PRE_REMOVE_DOMAIN_EVENT), +Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain)); +Mockito.verify(_messageBus).publish(Mockito.anyString(), Matchers.eq(DomainManager.MESSAGE_REMOVE_DOMAIN_EVENT), +Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain)); +Mockito.verify(_domainDao).remove(DOMAIN_ID); +} + +@Test(expected=CloudRuntimeException.class) +public void testPublishRemoveEventsAndRemoveDomainExceptionDelete() { +Mockito.when(_domainDao.remove(DOMAIN_ID)).thenReturn(false); +domainManager.publishRemoveEventsAndRemoveDomain(domain); +Mockito.verify(_messageBus).publish(Mockito.anyString(), Matchers.eq(DomainManager.MESSAGE_PRE_REMOVE_DOMAIN_EVENT), +Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain)); +Mockito.verify(_messageBus, Mockito.never()).publish(Mockito.anyString(), Matchers.eq(DomainManager.MESSAGE_REMOVE_DOMAIN_EVENT), +Matchers.eq(PublishScope.LOCAL), Matchers.eq(domain)); +Mockito.verify(_domainDao).remove(DOMAIN_ID); +} + +@Test +public void testFailRemoveOperation() { +try { +domainManager.failRemoveOperation(domain, domainAccountsForCleanup, domainNetworkIds, true); --- End diff -- Now that you removed the use of `rollBackState`, made the method last problematic to test. Therefore, you can use the `@Test(expected=...)`, instead of this very unusual construction here. > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resour
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955305#comment-15955305 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user rafaelweingartner commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1935#discussion_r102538324 --- Diff: server/src/com/cloud/user/DomainManagerImpl.java --- @@ -109,6 +112,20 @@ @Inject MessageBus _messageBus; +static boolean rollBackState = false; --- End diff -- @nvazquez I have been thinking about this variable you introduced here. I think it can cause problems (concurrency problems). The `DomainManagerImpl` is a singleton. Therefore, it should not have state variables. The `rollBackState ` is acting as a state variable for requests that use `com.cloud.user.DomainManagerImpl.deleteDomain(DomainVO, Boolean)`. The problem is that every call should have its own context/state for `rollBackState`. However, this will not happen with the current implementation. I think we should re-work the use of that variable. What do you think? > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transa
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955300#comment-15955300 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1935 @borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29 > 2017-01-26 06:07:44,319 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955297#comment-15955297 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/1935 @blueorangutan package > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29 > 2017-01-26 06:07:44,319 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled projects to cleanup > ... > // Failure due to domain is
[jira] [Commented] (CLOUDSTACK-9764) Delete domain failure due to Account Cleanup task
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955177#comment-15955177 ] ASF GitHub Bot commented on CLOUDSTACK-9764: Github user nvazquez commented on the issue: https://github.com/apache/cloudstack/pull/1935 @borisstoyanov I've rebased master branch, can we re-run tests on this PR? > Delete domain failure due to Account Cleanup task > - > > Key: CLOUDSTACK-9764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9764 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > Fix For: 4.10.0.0 > > > It was noticed in production environments that {{deleteDomain}} task failed > for domains with multiple accounts and resources. Examining logs it was found > out that if Account Cleanup Task got executed after domain (and all of its > subchilds) got marked as Inactive; and before delete domain task finishes, it > produces a failure. > {{AccountCleanupTask}} gets executed every {{account.cleanup.interval}} > seconds looking for: > * Removed accounts > * Disabled accounts > * Inactive domains > As {{deleteDomain}} marks domain to delete (and its subchilds) as Inactive > before deleting them, when {{AccountCleanupTask}} is executed, it removes > marked domains. When there are resources to cleanup on domain accounts, > domain is not found throwing exception: > {{com.cloud.exception.InvalidParameterValueException: Please specify a valid > domain ID}} > h3. Example > {{account.cleanup.interval}} = 100 > {noformat} > 2017-01-26 06:07:03,621 DEBUG [cloud.api.ApiServlet] > (catalina-exec-8:ctx-50cfa3b6 ctx-92ad5b38) ===END=== 10.39.251.17 -- GET > command=deleteDomain&id=1910a3dc-6fa6-457b-ab3a-602b0cfb6686&cleanup=true&response=json&_=1485439623475 > ... > // Domain and its subchilds marked as Inactive > 2017-01-26 06:07:03,640 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Marking domain id=27 > as Inactive before actually deleting it > 2017-01-26 06:07:03,646 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=27 > 2017-01-26 06:07:03,670 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=28 > 2017-01-26 06:07:03,685 DEBUG [cloud.user.DomainManagerImpl] > (API-Job-Executor-29:ctx-23415942 job-7165 ctx-fe3d13d6) Cleaning up domain > id=29 > ... > // AccountCleanupTask removes Inactive domain id=29, no rollback for it > 2017-01-26 06:07:44,285 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 removed accounts to cleanup > 2017-01-26 06:07:44,287 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled accounts to cleanup > 2017-01-26 06:07:44,289 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 3 inactive domains to cleanup > 2017-01-26 06:07:44,292 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=27 > 2017-01-26 06:07:44,297 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,301 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=28 > 2017-01-26 06:07:44,304 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:ctx-b8a01824) Rolling back the transaction: Time = 2 Name = > AccountChecker-1; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy63.remove:-1-DomainManagerImpl.removeDomain:248-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:62 > 2017-01-26 06:07:44,307 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Removing inactive domain id=29 > 2017-01-26 06:07:44,319 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:ctx-b8a01824) Found 0 disabled projects
[jira] [Commented] (CLOUDSTACK-9690) Scale CentOS7 VM fails with error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955082#comment-15955082 ] ASF GitHub Bot commented on CLOUDSTACK-9690: Github user jayantpatil1234 commented on the issue: https://github.com/apache/cloudstack/pull/1849 @sudhansu7 There is one file "Upgrade4910to4920.java", which does not have any changes, still that get added in PR. If possible could you remove that file? Otherwise code looks good. LGTM for code > Scale CentOS7 VM fails with error > -- > > Key: CLOUDSTACK-9690 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9690 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > Scale CentOS7 VM fails with error "Cannot scale up the vm because of memory > constraint violation" > When creating VM from CentOS 7 template on the XenServer with dynamically > scaling enabled, instance starts with base specified memory instead of memory > * 4 as static limit. > As the result, attempt to scale VM throws error in MS log: > {noformat} > java.lang.RuntimeException: Job failed due to exception Unable to scale vm > due to Catch exception com.cloud.utils.exception.CloudRuntimeException when > scaling VM:i-24-3976-VM due to > com.cloud.utils.exception.CloudRuntimeException: Cannot scale up the vm > because of memory constraint violation: 0 <= memory-static-min(2147483648) <= > memory-dynamic-min(8589934592) <= memory-dynamic-max(8589934592) <= > memory-static-max(2147483648) > {noformat} > REPO STEPS > = > # Enable dynamic scaling in Global settings > # Register an CentOS 7 tempplate(with tools) and tick dynamic scaling > # Deploy VM with this template > # Start the VM and try to change service offering > EXPECTED RESULT: VM should start with static limit 4x and > scale up when offering is changed > ACTUAL RESULT: VM starts with maximum static limit of and > doesn't scale up with error in ms log : > Cannot scale up the vm because of memory constraint violation: -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955053#comment-15955053 ] ASF GitHub Bot commented on CLOUDSTACK-9560: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/1726 tag:mergeready > Root volume of deleted VM left unremoved > > > Key: CLOUDSTACK-9560 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.8.0 > Environment: XenServer >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > In the following scenario root volume gets unremoved > Steps to reproduce the issue > 1. Create a VM. > 2. Stop this VM. > 3. On the page of the volume of the VM, click 'Download Volume' icon. > 4. Wait for the popup screen to display and cancel out with/without clicking > the download link. > 5. Destroy the VM > Even after the corresponding VM is deleted,expunged, the root-volume is left > in 'Expunging' state unremoved. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9690) Scale CentOS7 VM fails with error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955048#comment-15955048 ] ASF GitHub Bot commented on CLOUDSTACK-9690: Github user jayakarteek commented on the issue: https://github.com/apache/cloudstack/pull/1849 @sudhansu7 Tested the fix, LGTM. I am able to change from small computer offering to medium computer offering for centos-7. > Scale CentOS7 VM fails with error > -- > > Key: CLOUDSTACK-9690 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9690 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > Scale CentOS7 VM fails with error "Cannot scale up the vm because of memory > constraint violation" > When creating VM from CentOS 7 template on the XenServer with dynamically > scaling enabled, instance starts with base specified memory instead of memory > * 4 as static limit. > As the result, attempt to scale VM throws error in MS log: > {noformat} > java.lang.RuntimeException: Job failed due to exception Unable to scale vm > due to Catch exception com.cloud.utils.exception.CloudRuntimeException when > scaling VM:i-24-3976-VM due to > com.cloud.utils.exception.CloudRuntimeException: Cannot scale up the vm > because of memory constraint violation: 0 <= memory-static-min(2147483648) <= > memory-dynamic-min(8589934592) <= memory-dynamic-max(8589934592) <= > memory-static-max(2147483648) > {noformat} > REPO STEPS > = > # Enable dynamic scaling in Global settings > # Register an CentOS 7 tempplate(with tools) and tick dynamic scaling > # Deploy VM with this template > # Start the VM and try to change service offering > EXPECTED RESULT: VM should start with static limit 4x and > scale up when offering is changed > ACTUAL RESULT: VM starts with maximum static limit of and > doesn't scale up with error in ms log : > Cannot scale up the vm because of memory constraint violation: -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955002#comment-15955002 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user ustcweizhou commented on the issue: https://github.com/apache/cloudstack/pull/1950 it would be nice if this can be merged into 4.10.0.0 > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > 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.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955000#comment-15955000 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user ustcweizhou commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1950#discussion_r109633875 --- Diff: debian/control --- @@ -16,14 +16,15 @@ Description: A common package which contains files which are shared by several C Package: cloudstack-management Architecture: all Depends: ${misc:Depends}, ${python:Depends}, openjdk-8-jre-headless | java8-runtime-headless | java8-runtime, cloudstack-common (= ${source:Version}), tomcat6 | tomcat7, sudo, jsvc, python-mysql.connector, libmysql-java, augeas-tools, mysql-client, adduser, bzip2, ipmitool, lsb-release +Recommends: init-system-helpers (>= 1.14) --- End diff -- @rhtyd Sorry I just noticed your comment. I will remove all 3 lines Recommends: init-system-helpers (>= 1.14) I am not sure if it will cause any issue. Please test it. > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > 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.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9208) Assertion Error in VM_POWER_STATE handler.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954977#comment-15954977 ] ASF GitHub Bot commented on CLOUDSTACK-9208: Github user jayapalu commented on the issue: https://github.com/apache/cloudstack/pull/1997 @ramkatru I am not sure about Daan comments. The tests results are positive. > Assertion Error in VM_POWER_STATE handler. > -- > > Key: CLOUDSTACK-9208 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9208 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal >Priority: Minor > > 1. Enable the assertions. > LOG > 2015-12-31 04:09:06,687 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-981a85d4) (logid:863754b8) Found 0 networks to > update RvR status. > 2015-12-31 04:09:07,394 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Ping from 5(10.147.40.18) > 2015-12-31 04:09:07,394 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Process host VM state > report from ping process. host: 5 > 2015-12-31 04:09:07,416 INFO [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Unable to find matched > VM in CloudStack DB. name: New Virtual Machine > 2015-12-31 04:09:07,420 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Process VM state report. > host: 5, number of records in report: 5 > 2015-12-31 04:09:07,420 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) VM state report. host: > 5, vm id: 69, power state: PowerOff > 2015-12-31 04:09:07,530 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) VM state report is > updated. host: 5, vm id: 69, power state: PowerOff > 2015-12-31 04:09:07,540 INFO [c.c.v.VirtualMachineManagerImpl] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) VM r-69-VM is at Stopped > and we received a power-off report while there is no pending jobs on it > 2015-12-31 04:09:07,541 ERROR [o.a.c.f.m.MessageDispatcher] > (DirectAgentCronJob-3:ctx-3ba82e46) (logid:02dcbd48) Unexpected exception > when calling > com.cloud.vm.ClusteredVirtualMachineManagerImpl.HandlePowerStateReport > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.cloudstack.framework.messagebus.MessageDispatcher.dispatch(MessageDispatcher.java:75) > at > org.apache.cloudstack.framework.messagebus.MessageDispatcher.onPublishMessage(MessageDispatcher.java:45) > at > org.apache.cloudstack.framework.messagebus.MessageBusBase$SubscriptionNode.notifySubscribers(MessageBusBase.java:441) > at > org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:178) > at > com.cloud.vm.VirtualMachinePowerStateSyncImpl.processReport(VirtualMachinePowerStateSyncImpl.java:87) > at > com.cloud.vm.VirtualMachinePowerStateSyncImpl.processHostVmStatePingReport(VirtualMachinePowerStateSyncImpl.java:70) > at > com.cloud.vm.VirtualMachineManagerImpl.processCommands(VirtualMachineManagerImpl.java:2879) > at > com.cloud.agent.manager.AgentManagerImpl.handleCommands(AgentManagerImpl.java:309) > at > com.cloud.agent.manager.DirectAgentAttache$PingTask.runInContext(DirectAgentAttache.java:192) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concur
[jira] [Commented] (CLOUDSTACK-8939) VM Snapshot size with memory is not correctly calculated in cloud.usage_event (XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954965#comment-15954965 ] ASF GitHub Bot commented on CLOUDSTACK-8939: Github user niteshsarda commented on the issue: https://github.com/apache/cloudstack/pull/914 I have tested this and **LGTM** for test. Following are the test results : **Before applying fix :** [root@xenserver-jay ~]# xe vbd-list vm-name-label=i-2-120-VM empty=false params=vdi-uuid vdi-uuid ( RO): 674c2c07-954e-4fa0-943a-979a71748727 [root@xenserver-jay ~]# xe vdi-list params=physical-utilisation,sm-config,is-a-snapshot uuid=674c2c07-954e-4fa0-943a-979a71748727 is-a-snapshot ( RO) : false physical-utilisation ( RO): 81256448 sm-config (MRO): host_OpaqueRef:a3c1c534-b5e3-6cb5-10af-b56dead63fc0: RW; vhd-parent: 1aac168d-22d2-4796-8669-48a3f4361dfc [root@xenserver-jay ~]# xe vdi-list params=physical-utilisation,sm-config,is-a-snapshot uuid=1aac168d-22d2-4796-8669-48a3f4361dfc is-a-snapshot ( RO) : false physical-utilisation ( RO): 233251328 sm-config (MRO): vhd-blocks: eJxjYEAB7AykARFGPc1cN4UVJGqDAUYG5tZJF0ymbpi4bYUCAxPJ+nn2sDQLMGwTYzzI0OvAQob1AgIBip6BrAIrG0jWDAEAQmQNjA==; vhd-parent: 55943089-24fa-4fbe-a44e-e57fe9a080ed [root@xenserver-jay ~]# xe vdi-list name-label=Suspend\ image params=all uuid ( RO): 105fbe1d-973b-4d8d-82e7-96246669a769 name-label ( RW): Suspend image name-description ( RW): Suspend image is-a-snapshot ( RO): true snapshot-of ( RO): snapshots ( RO): snapshot-time ( RO): 20170401T07:49:50Z allowed-operations (SRO): forget; generate_config; update; resize; destroy; clone; copy; snapshot current-operations (SRO): sr-uuid ( RO): 99b84794-d0d6-46c6-fa42-07af5b423b8c sr-name-label ( RO): d2fecabd-61cf-3458-a120-ea01a4f91c29 vbd-uuids (SRO): crashdump-uuids (SRO): virtual-size ( RO): 782237696 physical-utilisation ( RO): 6144 location ( RO): 105fbe1d-973b-4d8d-82e7-96246669a769 type ( RO): Suspend sharable ( RO): false read-only ( RO): false storage-lock ( RO): false managed ( RO): true parent ( RO): missing ( RO): false other-config (MRW): content_id: 842a46b4-bffd-70fb-b00a-47c39de8959b xenstore-data (MRO): sm-config (MRO): vhd-parent: 638118a6-5f85-4c35-9aa8-d19793a144a8 on-boot ( RW): persist allow-caching ( RW): false metadata-latest ( RO): false metadata-of-pool ( RO): tags (SRW): [root@xenserver-jay ~]# xe vdi-list uuid=638118a6-5f85-4c35-9aa8-d19793a144a8 params=all uuid ( RO): 638118a6-5f85-4c35-9aa8-d19793a144a8 name-label ( RW): base copy name-description ( RW): is-a-snapshot ( RO): false snapshot-of ( RO): snapshots ( RO): snapshot-time ( RO): 19700101T00:00:00Z allowed-operations (SRO): forget; generate_config; update; resize; destroy; clone; copy; snapshot current-operations (SRO): sr-uuid ( RO): 99b84794-d0d6-46c6-fa42-07af5b423b8c sr-name-label ( RO): d2fecabd-61cf-3458-a120-ea01a4f91c29 vbd-uuids (SRO): crashdump-uuids (SRO): virtual-size ( RO): 782237696 physical-utilisation ( RO): 548430336 location ( RO): 638118a6-5f85-4c35-9aa8-d19793a144a8 type ( RO): User sharable ( RO): false read-only ( RO): true storage-lock ( RO): false managed ( RO): false parent ( RO): missing ( RO): false other-config (MRW): xenstore-data (MRO): sm-config (MRO): vhd-blocks: eJz7/x8/+MGAAgD69CDZ on-boot ( RW): persist allow-caching ( RW): false metadata-latest ( RO): false metadata-of-pool ( RO): tags (SRW): mysql> select * from cloud.usage_event where resource_name like "i-2-120-VM%" \G *** 1. row *** id: 84
[jira] [Commented] (CLOUDSTACK-9848) VR commands exist status is not checked in python config files
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954941#comment-15954941 ] ASF GitHub Bot commented on CLOUDSTACK-9848: Github user bvbharatk commented on the issue: https://github.com/apache/cloudstack/pull/2018 code changes LGTM. > VR commands exist status is not checked in python config files > -- > > Key: CLOUDSTACK-9848 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9848 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > > When iptables rules are configured on the VR failures or exceptions are not > detected in VR because iptables commands exit/return status is not > checked.Also in exception catch failure is not returned. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9860) CloudStack should be able to pass 'hard' shutdown instruction to hosts to force a guest instance shutdown
Paul Angus created CLOUDSTACK-9860: -- Summary: CloudStack should be able to pass 'hard' shutdown instruction to hosts to force a guest instance shutdown Key: CLOUDSTACK-9860 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9860 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Reporter: Paul Angus The 'force' option provided with the stopVirtualMachine API command is often assumed to be a hard shutdown sent to the hypervisor, when in fact it is for CloudStacks' internal use. CloudStack should be able to send the 'hard' power-off request to the hosts. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-8944) Template download possible from new secondary storages before the download is 100 % complete
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954681#comment-15954681 ] ASF GitHub Bot commented on CLOUDSTACK-8944: Github user yvsubhash closed the pull request at: https://github.com/apache/cloudstack/pull/921 > Template download possible from new secondary storages before the download is > 100 % complete > > > Key: CLOUDSTACK-8944 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8944 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 > Environment: xenserver host with nfs storage >Reporter: subhash yedugundla > > ISSUE > == > Secondary Storage ( Parent is NULL in the database ) > after secondary storage is added from the CloudStack GUI which in turn > leads to a invalid download URL for a template > > TROUBLESHOOTING > === > The parameter provided when the Secondary storage created > Name: > Provider:NFS > Zone:dev3-z1 > Server:192.168.125.12 > Path:/vol/dev03/test > when we add secondary storage > {noformat} > 2015-06-11 07:27:40,686 TRACE [c.c.u.d.T.Statement] > (catalina-exec-19:ctx-11906a2c ctx-550a6e46) (logid:0fb48736) Closing: > com.mysql.jdbc.JDBC4PreparedStatement@7e703121: INSERT INTO image_store > (image_store.id, image_store.name, image_store.uuid, image_store.protocol, > image_store.url, image_store.image_provider_name, image_store.data_center_id, > image_store.scope, image_store.created, image_store.role, image_store.parent, > image_store.total_size, image_store.used_bytes) VALUES (0, _binary'sec3', > _binary'471d5edc-424e-41fb-a21e-47e53670fe62', _binary'nfs', > _binary'nfs://10.104.49.65/nfs/sec3', _binary'NFS', 1, 'ZONE', '2015-06-11 > 01:57:40', 'Image', null, null, null) > mysql> select * from image_store where id=3 \G; > *** 1. row *** > id: 3 > name: sec3 > image_provider_name: NFS > protocol: nfs > url: nfs://10.104.49.65/nfs/sec3 > data_center_id: 1 > scope: ZONE > role: Image > uuid: 471d5edc-424e-41fb-a21e-47e53670fe62 > parent: NULL > created: 2015-06-11 01:57:40 > removed: NULL > total_size: NULL > used_bytes: NULL > 1 row in set (0.00 sec) > {noformat} > Template download falils if the parent is NULL > The URL published when the customer extract the template gives 403 forbidden > error. > Example : > Template id:3343 > The URL is below. > https://210-140-168-1.systemip.idcfcloud.com/userdata/8aa50513-e60e-481f-989d-5bbd119504df.ova > > The template is stored on the new mount-point (je01v-secstr01-02 ) > {noformat} > root@s-1-VM:/var/www/html/userdata# df -h > Filesystem Size Used Avail Use% Mounted on > rootfs 276M 144M 118M 55% / > udev 10M 0 10M 0% /dev > tmpfs 201M 224K 201M 1% /run > /dev/disk/by-uuid/1458767f-a01a-4237-89e8-930f8c42fffe 276M 144M 118M 55% / > tmpfs 5.0M 0 5.0M 0% /run/lock > tmpfs 515M 0 515M 0% /run/shm > /dev/sda1 45M 22M 21M 51% /boot > /dev/sda6 98M 5.6M 88M 6% /home > /dev/sda8 368M 11M 339M 3% /opt > /dev/sda10 63M 5.3M 55M 9% /tmp > /dev/sda7 610M 518M 61M 90% /usr > /dev/sda9 415M 248M 146M 63% /var > 10.133.245.11:/je01v-secstr01-01 16T 11T 5.5T 66% > /mnt/SecStorage/8c0f1709-5d1d-3f0e-b100-ccfb873cf3ff > 10.133.245.11:/je01v-secstr01-02 5.9T 4.0T 1.9T 69% > /mnt/SecStorage/22836274-19c4-301a-80d8-690f16530e0a **THIS ONE > From the SSVM > root@s-1-VM:/var/www/html/userdata# ls -lah | grep 3343 > lrwxrwxrwx 1 root root 83 May 20 06:11 > 8aa50513-e60e-481f-989d-5bbd119504df.ova -> > /mnt/SecStorage/null/template/tmpl/19/3343/d93d6fcf-bb4e-3287-8346-a7781c39ecdb.ova > > {noformat} > The symbolic link is > "/mnt/SecStorage/null/template/tmpl/19/3343/d93d6fcf-bb4e-3287-8346-a7781c39ecdb.ova". > > We assumed the problem is that the link contains "null" directory. > The correct symbolic link should be > "/mnt/SecStorage/22836274-19c4-301a-80d8-690f16530e0a/template/tmpl/19/3343/d93d6fcf-bb4e-3287-8346-a7781c39ecdb.ova" -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-8944) Template download possible from new secondary storages before the download is 100 % complete
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954680#comment-15954680 ] ASF GitHub Bot commented on CLOUDSTACK-8944: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/921 Closing this PR, as this is no longer needed > Template download possible from new secondary storages before the download is > 100 % complete > > > Key: CLOUDSTACK-8944 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8944 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2 > Environment: xenserver host with nfs storage >Reporter: subhash yedugundla > > ISSUE > == > Secondary Storage ( Parent is NULL in the database ) > after secondary storage is added from the CloudStack GUI which in turn > leads to a invalid download URL for a template > > TROUBLESHOOTING > === > The parameter provided when the Secondary storage created > Name: > Provider:NFS > Zone:dev3-z1 > Server:192.168.125.12 > Path:/vol/dev03/test > when we add secondary storage > {noformat} > 2015-06-11 07:27:40,686 TRACE [c.c.u.d.T.Statement] > (catalina-exec-19:ctx-11906a2c ctx-550a6e46) (logid:0fb48736) Closing: > com.mysql.jdbc.JDBC4PreparedStatement@7e703121: INSERT INTO image_store > (image_store.id, image_store.name, image_store.uuid, image_store.protocol, > image_store.url, image_store.image_provider_name, image_store.data_center_id, > image_store.scope, image_store.created, image_store.role, image_store.parent, > image_store.total_size, image_store.used_bytes) VALUES (0, _binary'sec3', > _binary'471d5edc-424e-41fb-a21e-47e53670fe62', _binary'nfs', > _binary'nfs://10.104.49.65/nfs/sec3', _binary'NFS', 1, 'ZONE', '2015-06-11 > 01:57:40', 'Image', null, null, null) > mysql> select * from image_store where id=3 \G; > *** 1. row *** > id: 3 > name: sec3 > image_provider_name: NFS > protocol: nfs > url: nfs://10.104.49.65/nfs/sec3 > data_center_id: 1 > scope: ZONE > role: Image > uuid: 471d5edc-424e-41fb-a21e-47e53670fe62 > parent: NULL > created: 2015-06-11 01:57:40 > removed: NULL > total_size: NULL > used_bytes: NULL > 1 row in set (0.00 sec) > {noformat} > Template download falils if the parent is NULL > The URL published when the customer extract the template gives 403 forbidden > error. > Example : > Template id:3343 > The URL is below. > https://210-140-168-1.systemip.idcfcloud.com/userdata/8aa50513-e60e-481f-989d-5bbd119504df.ova > > The template is stored on the new mount-point (je01v-secstr01-02 ) > {noformat} > root@s-1-VM:/var/www/html/userdata# df -h > Filesystem Size Used Avail Use% Mounted on > rootfs 276M 144M 118M 55% / > udev 10M 0 10M 0% /dev > tmpfs 201M 224K 201M 1% /run > /dev/disk/by-uuid/1458767f-a01a-4237-89e8-930f8c42fffe 276M 144M 118M 55% / > tmpfs 5.0M 0 5.0M 0% /run/lock > tmpfs 515M 0 515M 0% /run/shm > /dev/sda1 45M 22M 21M 51% /boot > /dev/sda6 98M 5.6M 88M 6% /home > /dev/sda8 368M 11M 339M 3% /opt > /dev/sda10 63M 5.3M 55M 9% /tmp > /dev/sda7 610M 518M 61M 90% /usr > /dev/sda9 415M 248M 146M 63% /var > 10.133.245.11:/je01v-secstr01-01 16T 11T 5.5T 66% > /mnt/SecStorage/8c0f1709-5d1d-3f0e-b100-ccfb873cf3ff > 10.133.245.11:/je01v-secstr01-02 5.9T 4.0T 1.9T 69% > /mnt/SecStorage/22836274-19c4-301a-80d8-690f16530e0a **THIS ONE > From the SSVM > root@s-1-VM:/var/www/html/userdata# ls -lah | grep 3343 > lrwxrwxrwx 1 root root 83 May 20 06:11 > 8aa50513-e60e-481f-989d-5bbd119504df.ova -> > /mnt/SecStorage/null/template/tmpl/19/3343/d93d6fcf-bb4e-3287-8346-a7781c39ecdb.ova > > {noformat} > The symbolic link is > "/mnt/SecStorage/null/template/tmpl/19/3343/d93d6fcf-bb4e-3287-8346-a7781c39ecdb.ova". > > We assumed the problem is that the link contains "null" directory. > The correct symbolic link should be > "/mnt/SecStorage/22836274-19c4-301a-80d8-690f16530e0a/template/tmpl/19/3343/d93d6fcf-bb4e-3287-8346-a7781c39ecdb.ova" -- This message was sent by Atlassian JIRA (v6.3.15#6346)