[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249648#comment-14249648 ] Andrija Panic commented on CLOUDSTACK-7907: --- Managed to capture the problem where deploying new VM and after pressing FINISH - simply nothing happens: Actually, the output from the Chrome Debuging tools, from Console is: "Failed to load resource: the server responded with a status of 501 (Not Implemented)" (and this is the URL/api call...for that error) https://domainnamehere.com/client/api?command=deployVirtualMachine&response=json&sessionkey=T8NpBoassMQje21Flr%2Bde%2BDn9Gg%3D&zoneid=3d1dcf11-d482-4f28-a2dd-6afcb51545d2&templateid=528a4bf0-05b7-4c18-959c-8236465fb3f6&hypervisor=KVM&serviceofferingid=6dadbc20-2020-4980-af15-5ce3c247e21c&diskofferingid=d1065467-c35a-4ef2-9b33-c45ed022e2c6&size=100&networkids=7e047b58-2685-412b-a36e-6e166f97f73c&displayname=app2&name=app2&_=1418807454035 I have then clicked on the link provided, and the API call was executed fine, and new VM created... > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > Labels: ui > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8066) There is not way to know the size of the snapshot created
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi reassigned CLOUDSTACK-8066: --- Assignee: Sanjay Tripathi (was: Gaurav Aradhye) > There is not way to know the size of the snapshot created > - > > Key: CLOUDSTACK-8066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Sanjay Tripathi > Labels: automation > Fix For: 4.5.0 > > > The listSnapshots command does not return the size of the snapshot nor the > createSnapshot command. > There is no way to know the size of the snapshot and hence consider it in the > secondary storage limits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8066) There is not way to know the size of the snapshot created
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-8066: Fix Version/s: (was: 4.5.0) 4.6.0 > There is not way to know the size of the snapshot created > - > > Key: CLOUDSTACK-8066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Sanjay Tripathi > Labels: automation > Fix For: 4.6.0 > > > The listSnapshots command does not return the size of the snapshot nor the > createSnapshot command. > There is no way to know the size of the snapshot and hence consider it in the > secondary storage limits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8082) Guest Machine is unable to load DHCP Address
prashant created CLOUDSTACK-8082: Summary: Guest Machine is unable to load DHCP Address Key: CLOUDSTACK-8082 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8082 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Environment: Xen Server Reporter: prashant Hi, When I am creating instance in Cloudstack sometimes it is unable to load the IP for eth0. When checked the virtual router found following in dnsmsq.conf file #conf-file=/etc/dnsmasq.more.conf conf-dir=/etc/dnsmasq.d dhcp-option=option:router,10.1.1.1 dhcp-option=6,10.1.1.1,8.8.8.8,8.8.4.4 dhcp-client-update dhcp-optsfile=/etc/dhcpopts.txt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8083) How to migrate existing vCenter VMs to Cloudstack
prashant created CLOUDSTACK-8083: Summary: How to migrate existing vCenter VMs to Cloudstack Key: CLOUDSTACK-8083 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8083 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: prashant I want to migrate my existing infrastructure to cloudstack as it is deployed in ESXI5.5 . There is around 300Vms which needs to be migrated. Please let me know the step how to do this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8066) There is not way to know the size of the snapshot created
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-8066. - Resolution: Fixed > There is not way to know the size of the snapshot created > - > > Key: CLOUDSTACK-8066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Sanjay Tripathi > Labels: automation > Fix For: 4.6.0 > > > The listSnapshots command does not return the size of the snapshot nor the > createSnapshot command. > There is no way to know the size of the snapshot and hence consider it in the > secondary storage limits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8066) There is not way to know the size of the snapshot created
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249699#comment-14249699 ] ASF subversion and git services commented on CLOUDSTACK-8066: - Commit 9153b8bede3350750cb7a78891e0479cc72aa2ec in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9153b8b ] CLOUDSTACK-8066: There is not way to know the size of the snapshot created. > There is not way to know the size of the snapshot created > - > > Key: CLOUDSTACK-8066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Sanjay Tripathi > Labels: automation > Fix For: 4.6.0 > > > The listSnapshots command does not return the size of the snapshot nor the > createSnapshot command. > There is no way to know the size of the snapshot and hence consider it in the > secondary storage limits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner updated CLOUDSTACK-7907: --- Component/s: (was: UI) API > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner updated CLOUDSTACK-7907: --- Labels: (was: ui) > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249731#comment-14249731 ] Stephen Turner commented on CLOUDSTACK-7907: Thanks for capturing the problem. The server responded with a 501? That's very odd: it sounds as if it's an API problem. > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8074) [Automation] global name 'TestEgressAfterHostMaintenance' is not defined - /maint/ test_multiple_ip_ranges.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249762#comment-14249762 ] ASF subversion and git services commented on CLOUDSTACK-8074: - Commit 7cf94260ee6adc49df97214ea7410dd387be11e5 in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7cf9426 ] CLOUDSTACK-8074: Fixed maint/test_multiple_ip_ranges.py Signed-off-by: SrikanteswaraRao Talluri > [Automation] global name 'TestEgressAfterHostMaintenance' is not defined - > /maint/ test_multiple_ip_ranges.py > - > > Key: CLOUDSTACK-8074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8074 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Ashutosk Kelkar >Assignee: Ashutosk Kelkar > Labels: automation > Fix For: 4.5.0 > > > global name 'TestEgressAfterHostMaintenance' is not defined > Stacktrace > File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 209, in run > self.setUp() > File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 292, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 315, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in > try_run > return func() > File > "/root/cloudstack/test/integration/component/maint/test_multiple_ip_ranges.py", > line 90, in setUpClass > cls.testClient = super(TestEgressAfterHostMaintenance, cls).getClsTestClient() > 'global name \'TestEgressAfterHostMaintenance\' is not defined\n -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8055) Tagging test cases which can't be run on simulator accordingly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249760#comment-14249760 ] ASF subversion and git services commented on CLOUDSTACK-8055: - Commit 831cb1130e55ac321b481ae9b9bc77855c98fc3d in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=831cb11 ] CLOUDSTACK-8055: test_portable_ip.py - Tagging test case which can't be run on simulator Signed-off-by: SrikanteswaraRao Talluri > Tagging test cases which can't be run on simulator accordingly > -- > > Key: CLOUDSTACK-8055 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8055 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > The test cases which can't be run on simulator should be tagged accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249755#comment-14249755 ] Ian Duffy commented on CLOUDSTACK-8038: --- Huge +1 on getting this done, the copying over of the template is by far the slowest part of bringing up devcloud 4. In the past I have used 2gb ubuntu or debian templates which kinda works but isn't a great solution. Lately I've been looking at using alpine linux: https://www.alpinelinux.org/ but my image is still around 500mb. Would be amazing to see something under 100mb. The Xen PV stuff can be pretty tricky, I've found grub2 1.99-21 seems to handle it best. I got config parsing errors with anything older/newer. > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8074) [Automation] global name 'TestEgressAfterHostMaintenance' is not defined - /maint/ test_multiple_ip_ranges.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249763#comment-14249763 ] ASF subversion and git services commented on CLOUDSTACK-8074: - Commit c3508f61a18384e9201d3d1dc87c35c67e200039 in cloudstack's branch refs/heads/4.5 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3508f6 ] CLOUDSTACK-8074: Fixed maint/test_multiple_ip_ranges.py Signed-off-by: SrikanteswaraRao Talluri > [Automation] global name 'TestEgressAfterHostMaintenance' is not defined - > /maint/ test_multiple_ip_ranges.py > - > > Key: CLOUDSTACK-8074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8074 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Ashutosk Kelkar >Assignee: Ashutosk Kelkar > Labels: automation > Fix For: 4.5.0 > > > global name 'TestEgressAfterHostMaintenance' is not defined > Stacktrace > File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 209, in run > self.setUp() > File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 292, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/dist-packages/nose/suite.py", line 315, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/dist-packages/nose/util.py", line 470, in > try_run > return func() > File > "/root/cloudstack/test/integration/component/maint/test_multiple_ip_ranges.py", > line 90, in setUpClass > cls.testClient = super(TestEgressAfterHostMaintenance, cls).getClsTestClient() > 'global name \'TestEgressAfterHostMaintenance\' is not defined\n -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8071) [Automation] Creation of Snapshot fails - errorText:unable to verify user credentials and/or request signature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249759#comment-14249759 ] ASF subversion and git services commented on CLOUDSTACK-8071: - Commit 391108ff533bdaa40356538ccf04a77498398ad9 in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=391108f ] CLOUDSTACK-8071: Fixed api key issue in test_snapshots_improvement.py Signed-off-by: SrikanteswaraRao Talluri > [Automation] Creation of Snapshot fails - errorText:unable to verify user > credentials and/or request signature > -- > > Key: CLOUDSTACK-8071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8071 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Ashutosk Kelkar >Assignee: Ashutosk Kelkar > Labels: automation > Fix For: 4.5.0 > > > The test case fails with error: "Api key not related to valid account". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8071) [Automation] Creation of Snapshot fails - errorText:unable to verify user credentials and/or request signature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249766#comment-14249766 ] ASF subversion and git services commented on CLOUDSTACK-8071: - Commit ed5bc1c7ea1885e95c7cad0045243c7f43e9f516 in cloudstack's branch refs/heads/4.5 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ed5bc1c ] CLOUDSTACK-8071: Fixed api key issue in test_snapshots_improvement.py Signed-off-by: SrikanteswaraRao Talluri > [Automation] Creation of Snapshot fails - errorText:unable to verify user > credentials and/or request signature > -- > > Key: CLOUDSTACK-8071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8071 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Ashutosk Kelkar >Assignee: Ashutosk Kelkar > Labels: automation > Fix For: 4.5.0 > > > The test case fails with error: "Api key not related to valid account". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8081) [Automation] Fix VMSnapshot Test Case Failures in "test_escalations_instances.py" test script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249761#comment-14249761 ] ASF subversion and git services commented on CLOUDSTACK-8081: - Commit 6674f95cdd268652d109558eabb3402a4e6f7e43 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6674f95 ] CLOUDSTACK-8081: Fixed VM snapshot test cases in test_escalation_instances.py and also dealt cleanup issues Signed-off-by: SrikanteswaraRao Talluri > [Automation] Fix VMSnapshot Test Case Failures in > "test_escalations_instances.py" test script > - > > Key: CLOUDSTACK-8081 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8081 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > VM snapshot test cases are failing in this test suite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8055) Tagging test cases which can't be run on simulator accordingly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249765#comment-14249765 ] ASF subversion and git services commented on CLOUDSTACK-8055: - Commit 94814603db6d825d23710071d4aba1c5893d3360 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9481460 ] CLOUDSTACK-8055: test_portable_ip.py - Tagging test case which can't be run on simulator Signed-off-by: SrikanteswaraRao Talluri > Tagging test cases which can't be run on simulator accordingly > -- > > Key: CLOUDSTACK-8055 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8055 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > The test cases which can't be run on simulator should be tagged accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8084) [Automation] Fix test_add_remove_network.TestFailureScenariosAddNetworkToVM.test_17_add_nic_different_zone
Gaurav Aradhye created CLOUDSTACK-8084:
--
Summary: [Automation] Fix
test_add_remove_network.TestFailureScenariosAddNetworkToVM.test_17_add_nic_different_zone
Key: CLOUDSTACK-8084
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8084
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
Fix For: 4.5.0
The test case failed in cleanup operation while deleting the network.
Error Message
Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created :
u'2014-12-15T22:24:53+', cmd :
u'org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd', userid :
u'2f1ad6e2-848d-11e4-af34-8e4219cb0651', jobstatus : 2, jobid :
u'88e2de77-89c0-47de-bdb6-7b8d354a8ead', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Failed to delete
network'}, accountid : u'2f1ac986-848d-11e4-af34-8e4219cb0651'}
Stacktrace
File "/usr/lib/python2.7/unittest/case.py", line 361, in run
self.tearDown()
File
"/root/cloudstack/test/integration/component/test_add_remove_network.py", line
1184, in tearDown
raise Exception("Warning: Exception during cleanup : %s" % e)
'Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created :
u\'2014-12-15T22:24:53+\', cmd :
u\'org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd\', userid :
u\'2f1ad6e2-848d-11e4-af34-8e4219cb0651\', jobstatus : 2, jobid :
u\'88e2de77-89c0-47de-bdb6-7b8d354a8ead\', jobresultcode : 530, jobresulttype :
u\'object\', jobresult : {errorcode : 530, errortext : u\'Failed to delete
network\'}, accountid : u\'2f1ac986-848d-11e4-af34-8e4219cb0651\'}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8081) [Automation] Fix VMSnapshot Test Case Failures in "test_escalations_instances.py" test script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249764#comment-14249764 ] ASF subversion and git services commented on CLOUDSTACK-8081: - Commit daabe92a992f072c6305b14b88fcda99e19a7190 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=daabe92 ] CLOUDSTACK-8081: Fixed VM snapshot test cases in test_escalation_instances.py and also dealt cleanup issues Signed-off-by: SrikanteswaraRao Talluri > [Automation] Fix VMSnapshot Test Case Failures in > "test_escalations_instances.py" test script > - > > Key: CLOUDSTACK-8081 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8081 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > VM snapshot test cases are failing in this test suite. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8055) Tagging test cases which can't be run on simulator accordingly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249832#comment-14249832 ] ASF subversion and git services commented on CLOUDSTACK-8055: - Commit b6bac7f67335454b6146ebf56b1c6a47842107c1 in cloudstack's branch refs/heads/master from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b6bac7f ] bug-id:CLOUDSTACK-8055cleaned up test tags, removed unecessary tags. reviewed-by: SrikanteswaraRao Talluri Signed-off-by: SrikanteswaraRao Talluri > Tagging test cases which can't be run on simulator accordingly > -- > > Key: CLOUDSTACK-8055 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8055 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > The test cases which can't be run on simulator should be tagged accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249862#comment-14249862 ] Rohit Yadav commented on CLOUDSTACK-8038: - Hi [~nuxro], I tested this yesterday with KVM; - Failed to work with reset password (scripts missing?) - SSH did not work - Failed to get IP from DHCP, setup networking I'll explore the build process later this week. > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249868#comment-14249868 ] Nux commented on CLOUDSTACK-8038: - Don't waste any time trying it until I update the issue, I'm still working on it. :) > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249873#comment-14249873 ] Andrija Panic commented on CLOUDSTACK-7907: --- Yes...problem is: after only 10-15 (max 30sec) seconds of having issue, checked console, I clicked on the link in the console, so the API call was again executed - and new VM was deployed fine... > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249878#comment-14249878 ] Stephen Turner commented on CLOUDSTACK-7907: Understood, which is why it's odd. Why would the server return a 501 and then succeed shortly afterwards? > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249939#comment-14249939 ] Alexey Samarin commented on CLOUDSTACK-7907: I also have this bug, and if create vm from the user admin - no problem. But when I try to create the VM as a regular user - nothing happens, nothing in the logs also. Аfter an attempt to create a VM, in the Web console appears - the element is not found. CS version: 4.4.1 > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250024#comment-14250024 ] Rohit Yadav commented on CLOUDSTACK-8038: - Got it! Keep us posted, thanks. > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7957) [Automation] After Assigning a VM to a Different Account - PrimaryStorageTotal value of the Different Account is not Updated properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-7957.
---
Resolution: Cannot Reproduce
Do you forget to create vm with data disk in step 4?
> [Automation] After Assigning a VM to a Different Account -
> PrimaryStorageTotal value of the Different Account is not Updated properly
> -
>
> Key: CLOUDSTACK-7957
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7957
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
>
> *Steps to Reproduce:*
> 1. Create an Account. Observe the primarystoragetotal Information:
> {noformat}
> {
> primarystorageavailable: u'Unlimited',
> domain: u'ROOT',
> domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
> vpclimit: u'Unlimited',
> iplimit: u'Unlimited',
> volumelimit: u'Unlimited',
> memorytotal: 0,
> secondarystorageavailable: u'Unlimited',
> vmtotal: 0,
> cputotal: 0,
> vpctotal: 0,
> id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
> cpuavailable: u'Unlimited',
> snapshotlimit: u'Unlimited',
> networklimit: u'Unlimited',
> iptotal: 0,
> volumetotal: 0,
> projectlimit: u'Unlimited',
> state: u'enabled',
> networktotal: 0,
> accounttype: 2,
> networkavailable: u'Unlimited',
> primarystoragetotal: 0,
> templatelimit: u'Unlimited',
> snapshottotal: 0,
> templateavailable: u'Unlimited',
> vmlimit: u'Unlimited',
> vpcavailable: u'Unlimited',
> memoryavailable: u'Unlimited',
> secondarystoragetotal: 0,
> templatetotal: 0,
> projecttotal: 0,
> user: [
> {
> username:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> account:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
> firstname: u'test',
> created: u'2014-11-19T14: 24: 52+',
> lastname: u'test',
> domain: u'ROOT',
> id: u'3108696d-5bb2-43e4-a5dc-9b7e095e5e6d',
> iscallerchilddomain: False,
> state: u'enabled',
> accounttype: 2,
> email: u'test-acco...@test.com',
> isdefault: False,
> accountid: u'40f4c89b-2964-4c54-9aff-5e537faee4f9'
> }
> ],
> groups: [
>
> ],
> projectavailable: u'Unlimited',
> isdefault: False,
> primarystoragelimit: u'Unlimited',
> secondarystoragelimit: u'Unlimited',
> volumeavailable: u'Unlimited',
> name:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> vmavailable: u'Unlimited',
> ipavailable: u'Unlimited',
> memorylimit: u'Unlimited',
> cpulimit: u'Unlimited',
> snapshotavailable: u'Unlimited'
> }
> {noformat}
> 2. Deploy a VM from the default template (2 GB Size) with a disk offering of
> 2GB. Observe primarystoragetotal Information of the account as 4GB.
> {noformat}
> {
> primarystorageavailable: u'Unlimited',
> domain: u'ROOT',
> domainid: u'd32d07d4-6fe6-11e4-8b15-0e412070d892',
> vpclimit: u'Unlimited',
> iplimit: u'Unlimited',
> volumelimit: u'Unlimited',
> memorytotal: 128,
> secondarystorageavailable: u'Unlimited',
> vmtotal: 1,
> cputotal: 1,
> vpctotal: 0,
> id: u'40f4c89b-2964-4c54-9aff-5e537faee4f9',
> networkavailable: u'Unlimited',
> snapshotlimit: u'Unlimited',
> networklimit: u'Unlimited',
> iptotal: 1,
> volumetotal: 2,
> projectlimit: u'Unlimited',
> state: u'enabled',
> networktotal: 1,
> sentbytes: 0,
> accounttype: 2,
> receivedbytes: 0,
> cpuavailable: u'Unlimited',
> primarystoragetotal: 4,
> templatelimit: u'Unlimited',
> snapshottotal: 0,
> templateavailable: u'Unlimited',
> vmlimit: u'Unlimited',
> vpcavailable: u'Unlimited',
> memoryavailable: u'Unlimited',
> secondarystoragetotal: 0,
> templatetotal: 0,
> projecttotal: 0,
> vmrunning: 1,
> groups: [
>
> ],
> projectavailable: u'Unlimited',
> isdefault: False,
> primarystoragelimit: u'Unlimited',
> secondarystoragelimit: u'Unlimited',
> volumeavailable: u'Unlimited',
> name:
> u'test-a-TestVolumeLimits-test_assign_vm_different_account_1_root_domain_admin-ECMKAT',
> vmavailable: u
[jira] [Commented] (CLOUDSTACK-8075) UI > Instances menu > Add Instance > Select a template > add a new tab (4th tab): "shared" tab.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250317#comment-14250317 ] ASF subversion and git services commented on CLOUDSTACK-8075: - Commit 11fa48108ffc5ef7b276f7261b29eaca406105b8 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=11fa4810 ] CLOUDSTACK-8075: UI > Instances menu > Add Instance > Select template/ISO > "shared" tab > select a shared template, click Next button => fix error "unable to find matched template object". > UI > Instances menu > Add Instance > Select a template > add a new tab (4th > tab): "shared" tab. > --- > > Key: CLOUDSTACK-8075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: after_UI_fix_2014-12-16.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8075) UI > Instances menu > Add Instance > Select a template > add a new tab (4th tab): "shared" tab.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250318#comment-14250318 ] ASF subversion and git services commented on CLOUDSTACK-8075: - Commit ff62ccc13e6f2b2346adca03f240f59d92d87f92 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff62ccc ] CLOUDSTACK-8075: UI > Instances menu > Add Instance > Select template/ISO > "shared" tab > select a shared template, click Next button => fix error "unable to find matched template object". > UI > Instances menu > Add Instance > Select a template > add a new tab (4th > tab): "shared" tab. > --- > > Key: CLOUDSTACK-8075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: after_UI_fix_2014-12-16.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8077) Not able to deploy VM using a shared template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-8077. -- Resolution: Fixed > Not able to deploy VM using a shared template. > -- > > Key: CLOUDSTACK-8077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8077 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: IAM >Affects Versions: 4.4.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Steps to reproduce the problem: > Create 2 users under ROOT - san1 and san2 > As san1: > 1. Register a template(private) > 2. Update template permission , so that it is shared with san2. > 3. Listing template permission , shows that this template is shared with san2. > 4. As san2 , Listing templates with templatefilter=shared , lists template > test1 that was shared with san2. > 5. As use san2 , try to deploy VM using the shared template - test1. > This errors out following error message and return code- 531 > "Acct[c4c843e4-98a4-4384-9410-281243dfaa88-san2] does not have permission to > operate with resource Acct[08dd8e5e-bb06-40fc-9a94-9eed073a358a-san1]" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8077) Not able to deploy VM using a shared template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250342#comment-14250342 ] Min Chen commented on CLOUDSTACK-8077: -- In service layer, we incorrectly perform template permission check by checking if VM owner has permission to the template owner, which caused the error. Instead we should perform permission by checking if VM owner has permission to the template. Fixed with above commit. > Not able to deploy VM using a shared template. > -- > > Key: CLOUDSTACK-8077 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8077 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: IAM >Affects Versions: 4.4.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Steps to reproduce the problem: > Create 2 users under ROOT - san1 and san2 > As san1: > 1. Register a template(private) > 2. Update template permission , so that it is shared with san2. > 3. Listing template permission , shows that this template is shared with san2. > 4. As san2 , Listing templates with templatefilter=shared , lists template > test1 that was shared with san2. > 5. As use san2 , try to deploy VM using the shared template - test1. > This errors out following error message and return code- 531 > "Acct[c4c843e4-98a4-4384-9410-281243dfaa88-san2] does not have permission to > operate with resource Acct[08dd8e5e-bb06-40fc-9a94-9eed073a358a-san1]" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-315) Infrastructure view does not show capacity values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-315. - Resolution: Fixed This has already been fixed with count statistis returned in our list API. > Infrastructure view does not show capacity values > - > > Key: CLOUDSTACK-315 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-315 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.0, 4.2.0 > Environment: master branch >Reporter: Rohit Yadav >Assignee: Min Chen >Priority: Minor > Fix For: 4.5.0, 4.4.3 > > > Goto Infrastructure, it won't post a GET request to get list of capacities, > no. of hosts, zones, routers etc.; and fails to show any capacity values. > This was observed on master branch, > head=16fa74b7293039db75fdc6851c35e194b33f2135. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-315) Infrastructure view does not show capacity values
[ https://issues.apache.org/jira/browse/CLOUDSTACK-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250380#comment-14250380 ] Min Chen edited comment on CLOUDSTACK-315 at 12/17/14 7:39 PM: --- This has already been fixed with count statistics returned in our list API. was (Author: minchen07): This has already been fixed with count statistis returned in our list API. > Infrastructure view does not show capacity values > - > > Key: CLOUDSTACK-315 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-315 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.0, 4.2.0 > Environment: master branch >Reporter: Rohit Yadav >Assignee: Min Chen >Priority: Minor > Fix For: 4.5.0, 4.4.3 > > > Goto Infrastructure, it won't post a GET request to get list of capacities, > no. of hosts, zones, routers etc.; and fails to show any capacity values. > This was observed on master branch, > head=16fa74b7293039db75fdc6851c35e194b33f2135. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8079) If the cluster capacity threshold is reached, HA-enabled VM is not migrated on another host during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250507#comment-14250507 ] ASF subversion and git services commented on CLOUDSTACK-8079: - Commit f5d4736c8787977b1143adc9a3a7b44edb7f6fd6 in cloudstack's branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5d4736 ] CLOUDSTACK-8079: If the cluster capacity threshold is reached, HA-enabled VM is not migrated on another host during HA Changes: - When there is HA we try to redeploy the affected vm using regular planners and if that fails we retry using the special planner for HA (which skips checking disable threshold) Now because of job framework the InsufficientCapacittyException gets masked and the special planners are not called. Job framework needs to be fixed to rethrow the correct exception. - Also the VM Work Job framework is not setting the DeploymentPlanner to the VmWorkJob. So the HA Planner being passed by HAMgr was not getting used. - Now the job framework sets the planner passed in by any caller of the VM Start operation, to the job > If the cluster capacity threshold is reached, HA-enabled VM is not migrated > on another host during HA > - > > Key: CLOUDSTACK-8079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Prachi Damle >Assignee: Prachi Damle >Priority: Critical > Fix For: 4.5.0 > > > When the host goes down. Cloudstack will try to migrate the VM's for which HA > is enabled to other hosts in cluster. > If the migration fails using default Planners due to cluster threshold > reached, CloudStack HAManager uses an HAPlanner which overrides any threshold > checks set to avoid such failures. > This is not seen happening with 4.5 codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8022) [Automation] Deletion of Domain with Cleanup set to "true" fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250505#comment-14250505
]
ASF subversion and git services commented on CLOUDSTACK-8022:
-
Commit 141a71b518f2a051917e287683013b97785f360f in cloudstack's branch
refs/heads/master from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=141a71b ]
CLOUDSTACK-8022: [Automation] Deletion of Domain with Cleanup set to "true"
fails
Changes:
- This is a race condition between the deleteDomain thread and AccountChecker
thread. DeleteDomain thread marks the domain as inactive and proceeds for
cleanup, AccountChecker thread that runs at the same time cleans up any domains
marked as inactive.
- When the DeleteDomain thread finds that domain is already removed, it need
not error out since the domain deletion has already happened
> [Automation] Deletion of Domain with Cleanup set to "true" fails
>
>
> Key: CLOUDSTACK-8022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8022
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> The following test case in test_persistent_rules.py fails:
> {code}
> @attr(tags=["advanced"])
> def test_vpc_force_delete_domain(self):
> # steps
> # 1. Create account and create VPC network in the account
> # 2. Create two persistent networks within this VPC
> # 3. Restart/delete VPC network
> # Validations
> # 1. In case of Restart operation, restart should be successful
> #and persistent networks should be back in persistent state
> # 2. In case of Delete operation, VR servicing the VPC should
> #get destroyed and sourceNAT ip should get released
> child_domain = Domain.create(self.apiclient,
> services=self.services["domain"],
> parentdomainid=self.domain.id)
> try:
> account_1 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> account_2 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> self.services["vpc"]["cidr"] = "10.1.1.1/16"
> vpc_1 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_1.name,
> domainid=account_1.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_1.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> vpc_2 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_2.name,
> domainid=account_2.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_2.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> persistent_network_1 = Network.create(
> self.api_client, self.services["isolated_network"],
> networkofferingid=self.persistent_network_offering_NoLB.id,
> accountid=account_1.name, domainid=account_1.domainid,
> zoneid=self.zone.id, vpcid=vpc_1.id, gateway="10.1.1.1",
> netmask="255.255.255.0")
> response = verifyNetworkState(self.apiclient,
> persistent_network_1.id,
> "implemented"
> )
> exceptionOccured = response[0]
> isNetworkInDesiredState = response[1]
> exceptionMessage = response[2]
> if (exceptionOccured or (not isNetworkInDesiredState)):
> raise Exception(exceptionMessage)
> self.assertIsNotNone(
> persistent_network_1.vlan,
> "vlan must not be null for persistent network %s" %
> persiste
[jira] [Commented] (CLOUDSTACK-8078) [Automation] Deletion of Affinity Groups - CloudRuntimeException: No Event Pubish can be wrapped within DB Transaction!
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250506#comment-14250506
]
ASF subversion and git services commented on CLOUDSTACK-8078:
-
Commit 74720830cdfa3a376682f43c375e834bdb81052d in cloudstack's branch
refs/heads/master from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7472083 ]
CLOUDSTACK-8078: [Automation] Deletion of Affinity Groups -
CloudRuntimeException: No Event Pubish can be wrapped within DB Transaction!
Changes:
- The event of deleteing an affinity group is published on the MessageBus
so that IAM Service can listen and process the event, However the publish
operation should not be handled within a DB transaction, since it may take
longer and hold the DB transaction for long unnecessarily
-Publish any events to MessageBus outside of the transaction
> [Automation] Deletion of Affinity Groups - CloudRuntimeException: No Event
> Pubish can be wrapped within DB Transaction!
> ---
>
> Key: CLOUDSTACK-8078
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8078
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.5.0
>Reporter: Prachi Damle
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> See error during deleteAffinityGroup
>
> CloudRuntimeException:
>
> 2014-12-14 18:29:51,636 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-61c26d76 job-485) (logid:82f62d53) Add job-485 into
> job monitoring
> 2014-12-14 18:29:51,641 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-25:ctx-e231fbde ctx-25d0c1ac ctx-18c538f9) (logid:78eae0c5)
> submit async job-485, details: AsyncJobVO {id:485, userId: 2, accountId: 2,
> instanceType: AffinityGroup, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.affinitygroup.DeleteAffinityGroupCmd,
> cmdInfo:
> {"response":"json","id":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxDetails":"{\"org.apache.cloudstack.affinity.AffinityGroup\":\"319dc948-606c-4045-81a3-1fd385fb12c1\"}","cmdEventType":"AG.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxAccountId":"2","ctxStartEventId":"1705","apiKey":"lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg","signature":"Oc6n9ljuRmBDy9KAh5ZgO1sEP/k\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 94761346572491, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-14 18:29:51,641 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-61c26d76 job-485) (logid:59ee6d42) Executing
> AsyncJobVO {id:485, userId: 2, accountId: 2, instanceType: AffinityGroup,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.affinitygroup.DeleteAffinityGroupCmd,
> cmdInfo:
> {"response":"json","id":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxDetails":"{\"org.apache.cloudstack.affinity.AffinityGroup\":\"319dc948-606c-4045-81a3-1fd385fb12c1\"}","cmdEventType":"AG.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxAccountId":"2","ctxStartEventId":"1705","apiKey":"lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg","signature":"Oc6n9ljuRmBDy9KAh5ZgO1sEP/k\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 94761346572491, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-14 18:29:51,641 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-25:ctx-e231fbde ctx-25d0c1ac ctx-18c538f9) (logid:78eae0c5)
> ===END=== 10.81.29.18 -- GET
> id=319dc948-606c-4045-81a3-1fd385fb12c1&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=deleteAffinityGroup&response=json&signature=Oc6n9ljuRmBDy9KAh5ZgO1sEP%2Fk%3D
> 2014-12-14 18:29:51,646 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-b127c144) (logid:fb950f22) ===START=== 10.81.29.18 --
> GET
> jobid=59ee6d42-9964-4e99-86e5-cd83ace8c0a2&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=queryAsyncJobResult&response=json&signature=4tcHbecYJkvrJxVV00AJe2HShXc%3D
> 2014-12-14 18:29:51,663 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-b127c144 ctx-a6c508cb ctx-65259123) (logid:fb950f22)
> ===END=== 10.81.29.18 -- GET
> jobid=59ee6d42-9964-4e99-86e5-cd83ace8c0a2&apiKey=lA1vMT9CPy47zN3KD8
[jira] [Commented] (CLOUDSTACK-8079) If the cluster capacity threshold is reached, HA-enabled VM is not migrated on another host during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250679#comment-14250679 ] ASF subversion and git services commented on CLOUDSTACK-8079: - Commit a7861aa5faabc9ce9422ae2c903471fbf8239abc in cloudstack's branch refs/heads/4.5 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a7861aa ] CLOUDSTACK-8079: If the cluster capacity threshold is reached, HA-enabled VM is not migrated on another host during HA Changes: - When there is HA we try to redeploy the affected vm using regular planners and if that fails we retry using the special planner for HA (which skips checking disable threshold) Now because of job framework the InsufficientCapacittyException gets masked and the special planners are not called. Job framework needs to be fixed to rethrow the correct exception. - Also the VM Work Job framework is not setting the DeploymentPlanner to the VmWorkJob. So the HA Planner being passed by HAMgr was not getting used. - Now the job framework sets the planner passed in by any caller of the VM Start operation, to the job > If the cluster capacity threshold is reached, HA-enabled VM is not migrated > on another host during HA > - > > Key: CLOUDSTACK-8079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Prachi Damle >Assignee: Prachi Damle >Priority: Critical > Fix For: 4.5.0 > > > When the host goes down. Cloudstack will try to migrate the VM's for which HA > is enabled to other hosts in cluster. > If the migration fails using default Planners due to cluster threshold > reached, CloudStack HAManager uses an HAPlanner which overrides any threshold > checks set to avoid such failures. > This is not seen happening with 4.5 codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8078) [Automation] Deletion of Affinity Groups - CloudRuntimeException: No Event Pubish can be wrapped within DB Transaction!
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250685#comment-14250685
]
ASF subversion and git services commented on CLOUDSTACK-8078:
-
Commit 01ae7120ac2d8a9c673ab5d54d45f604a4a88581 in cloudstack's branch
refs/heads/4.5 from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=01ae712 ]
CLOUDSTACK-8078: [Automation] Deletion of Affinity Groups -
CloudRuntimeException: No Event Pubish can be wrapped within DB Transaction!
Changes:
- The event of deleteing an affinity group is published on the MessageBus
so that IAM Service can listen and process the event, However the publish
operation should not be handled within a DB transaction, since it may take
longer and hold the DB transaction for long unnecessarily
-Publish any events to MessageBus outside of the transaction
Conflicts:
server/src/org/apache/cloudstack/affinity/AffinityGroupServiceImpl.java
> [Automation] Deletion of Affinity Groups - CloudRuntimeException: No Event
> Pubish can be wrapped within DB Transaction!
> ---
>
> Key: CLOUDSTACK-8078
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8078
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.5.0
>Reporter: Prachi Damle
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> See error during deleteAffinityGroup
>
> CloudRuntimeException:
>
> 2014-12-14 18:29:51,636 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-61c26d76 job-485) (logid:82f62d53) Add job-485 into
> job monitoring
> 2014-12-14 18:29:51,641 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-25:ctx-e231fbde ctx-25d0c1ac ctx-18c538f9) (logid:78eae0c5)
> submit async job-485, details: AsyncJobVO {id:485, userId: 2, accountId: 2,
> instanceType: AffinityGroup, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.affinitygroup.DeleteAffinityGroupCmd,
> cmdInfo:
> {"response":"json","id":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxDetails":"{\"org.apache.cloudstack.affinity.AffinityGroup\":\"319dc948-606c-4045-81a3-1fd385fb12c1\"}","cmdEventType":"AG.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxAccountId":"2","ctxStartEventId":"1705","apiKey":"lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg","signature":"Oc6n9ljuRmBDy9KAh5ZgO1sEP/k\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 94761346572491, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-14 18:29:51,641 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-61c26d76 job-485) (logid:59ee6d42) Executing
> AsyncJobVO {id:485, userId: 2, accountId: 2, instanceType: AffinityGroup,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.affinitygroup.DeleteAffinityGroupCmd,
> cmdInfo:
> {"response":"json","id":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxDetails":"{\"org.apache.cloudstack.affinity.AffinityGroup\":\"319dc948-606c-4045-81a3-1fd385fb12c1\"}","cmdEventType":"AG.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxAccountId":"2","ctxStartEventId":"1705","apiKey":"lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg","signature":"Oc6n9ljuRmBDy9KAh5ZgO1sEP/k\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 94761346572491, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-14 18:29:51,641 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-25:ctx-e231fbde ctx-25d0c1ac ctx-18c538f9) (logid:78eae0c5)
> ===END=== 10.81.29.18 -- GET
> id=319dc948-606c-4045-81a3-1fd385fb12c1&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=deleteAffinityGroup&response=json&signature=Oc6n9ljuRmBDy9KAh5ZgO1sEP%2Fk%3D
> 2014-12-14 18:29:51,646 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-b127c144) (logid:fb950f22) ===START=== 10.81.29.18 --
> GET
> jobid=59ee6d42-9964-4e99-86e5-cd83ace8c0a2&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=queryAsyncJobResult&response=json&signature=4tcHbecYJkvrJxVV00AJe2HShXc%3D
> 2014-12-14 18:29:51,663 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-b127c144 ctx-a6c508cb ctx-65259123) (logid:fb950f22)
> ===END=== 10
[jira] [Resolved] (CLOUDSTACK-8022) [Automation] Deletion of Domain with Cleanup set to "true" fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Damle resolved CLOUDSTACK-8022.
--
Resolution: Fixed
> [Automation] Deletion of Domain with Cleanup set to "true" fails
>
>
> Key: CLOUDSTACK-8022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8022
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> The following test case in test_persistent_rules.py fails:
> {code}
> @attr(tags=["advanced"])
> def test_vpc_force_delete_domain(self):
> # steps
> # 1. Create account and create VPC network in the account
> # 2. Create two persistent networks within this VPC
> # 3. Restart/delete VPC network
> # Validations
> # 1. In case of Restart operation, restart should be successful
> #and persistent networks should be back in persistent state
> # 2. In case of Delete operation, VR servicing the VPC should
> #get destroyed and sourceNAT ip should get released
> child_domain = Domain.create(self.apiclient,
> services=self.services["domain"],
> parentdomainid=self.domain.id)
> try:
> account_1 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> account_2 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> self.services["vpc"]["cidr"] = "10.1.1.1/16"
> vpc_1 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_1.name,
> domainid=account_1.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_1.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> vpc_2 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_2.name,
> domainid=account_2.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_2.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> persistent_network_1 = Network.create(
> self.api_client, self.services["isolated_network"],
> networkofferingid=self.persistent_network_offering_NoLB.id,
> accountid=account_1.name, domainid=account_1.domainid,
> zoneid=self.zone.id, vpcid=vpc_1.id, gateway="10.1.1.1",
> netmask="255.255.255.0")
> response = verifyNetworkState(self.apiclient,
> persistent_network_1.id,
> "implemented"
> )
> exceptionOccured = response[0]
> isNetworkInDesiredState = response[1]
> exceptionMessage = response[2]
> if (exceptionOccured or (not isNetworkInDesiredState)):
> raise Exception(exceptionMessage)
> self.assertIsNotNone(
> persistent_network_1.vlan,
> "vlan must not be null for persistent network %s" %
> persistent_network_1.id)
> persistent_network_2 = Network.create(
> self.api_client, self.services["isolated_network"],
> networkofferingid=self.persistent_network_offering_NoLB.id,
> accountid=account_2.name, domainid=account_2.domainid,
> zoneid=self.zone.id, vpcid=vpc_2.id, gateway="10.1.1.1",
> netmask="255.255.255.0")
> response = verifyNetworkState(
> self.apiclient,
> persistent_network_2.id,
> "implemented")
> exceptionOccured = response[0]
> isNetworkInDesiredState = response[1]
> exceptionMessage = response[2]
> if (exceptionOccured or (
[jira] [Commented] (CLOUDSTACK-8022) [Automation] Deletion of Domain with Cleanup set to "true" fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250684#comment-14250684
]
Prachi Damle commented on CLOUDSTACK-8022:
--
Commit hash:1c5e8ebb3113e97c6c0be9b602f9a15852f2d2fd
Contained in branches: 4.5
Contained in no tag
> [Automation] Deletion of Domain with Cleanup set to "true" fails
>
>
> Key: CLOUDSTACK-8022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8022
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> The following test case in test_persistent_rules.py fails:
> {code}
> @attr(tags=["advanced"])
> def test_vpc_force_delete_domain(self):
> # steps
> # 1. Create account and create VPC network in the account
> # 2. Create two persistent networks within this VPC
> # 3. Restart/delete VPC network
> # Validations
> # 1. In case of Restart operation, restart should be successful
> #and persistent networks should be back in persistent state
> # 2. In case of Delete operation, VR servicing the VPC should
> #get destroyed and sourceNAT ip should get released
> child_domain = Domain.create(self.apiclient,
> services=self.services["domain"],
> parentdomainid=self.domain.id)
> try:
> account_1 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> account_2 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> self.services["vpc"]["cidr"] = "10.1.1.1/16"
> vpc_1 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_1.name,
> domainid=account_1.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_1.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> vpc_2 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_2.name,
> domainid=account_2.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_2.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> persistent_network_1 = Network.create(
> self.api_client, self.services["isolated_network"],
> networkofferingid=self.persistent_network_offering_NoLB.id,
> accountid=account_1.name, domainid=account_1.domainid,
> zoneid=self.zone.id, vpcid=vpc_1.id, gateway="10.1.1.1",
> netmask="255.255.255.0")
> response = verifyNetworkState(self.apiclient,
> persistent_network_1.id,
> "implemented"
> )
> exceptionOccured = response[0]
> isNetworkInDesiredState = response[1]
> exceptionMessage = response[2]
> if (exceptionOccured or (not isNetworkInDesiredState)):
> raise Exception(exceptionMessage)
> self.assertIsNotNone(
> persistent_network_1.vlan,
> "vlan must not be null for persistent network %s" %
> persistent_network_1.id)
> persistent_network_2 = Network.create(
> self.api_client, self.services["isolated_network"],
> networkofferingid=self.persistent_network_offering_NoLB.id,
> accountid=account_2.name, domainid=account_2.domainid,
> zoneid=self.zone.id, vpcid=vpc_2.id, gateway="10.1.1.1",
> netmask="255.255.255.0")
> response = verifyNetworkState(
> self.apiclient,
> persistent_network_2.id,
> "implemented")
> exceptionOccured = response[
[jira] [Resolved] (CLOUDSTACK-8079) If the cluster capacity threshold is reached, HA-enabled VM is not migrated on another host during HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-8079. -- Resolution: Fixed > If the cluster capacity threshold is reached, HA-enabled VM is not migrated > on another host during HA > - > > Key: CLOUDSTACK-8079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Prachi Damle >Assignee: Prachi Damle >Priority: Critical > Fix For: 4.5.0 > > > When the host goes down. Cloudstack will try to migrate the VM's for which HA > is enabled to other hosts in cluster. > If the migration fails using default Planners due to cluster threshold > reached, CloudStack HAManager uses an HAPlanner which overrides any threshold > checks set to avoid such failures. > This is not seen happening with 4.5 codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8078) [Automation] Deletion of Affinity Groups - CloudRuntimeException: No Event Pubish can be wrapped within DB Transaction!
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Damle resolved CLOUDSTACK-8078.
--
Resolution: Fixed
> [Automation] Deletion of Affinity Groups - CloudRuntimeException: No Event
> Pubish can be wrapped within DB Transaction!
> ---
>
> Key: CLOUDSTACK-8078
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8078
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server
>Affects Versions: 4.5.0
>Reporter: Prachi Damle
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> See error during deleteAffinityGroup
>
> CloudRuntimeException:
>
> 2014-12-14 18:29:51,636 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-37:ctx-61c26d76 job-485) (logid:82f62d53) Add job-485 into
> job monitoring
> 2014-12-14 18:29:51,641 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-25:ctx-e231fbde ctx-25d0c1ac ctx-18c538f9) (logid:78eae0c5)
> submit async job-485, details: AsyncJobVO {id:485, userId: 2, accountId: 2,
> instanceType: AffinityGroup, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.affinitygroup.DeleteAffinityGroupCmd,
> cmdInfo:
> {"response":"json","id":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxDetails":"{\"org.apache.cloudstack.affinity.AffinityGroup\":\"319dc948-606c-4045-81a3-1fd385fb12c1\"}","cmdEventType":"AG.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxAccountId":"2","ctxStartEventId":"1705","apiKey":"lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg","signature":"Oc6n9ljuRmBDy9KAh5ZgO1sEP/k\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 94761346572491, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-14 18:29:51,641 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-37:ctx-61c26d76 job-485) (logid:59ee6d42) Executing
> AsyncJobVO {id:485, userId: 2, accountId: 2, instanceType: AffinityGroup,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.affinitygroup.DeleteAffinityGroupCmd,
> cmdInfo:
> {"response":"json","id":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxDetails":"{\"org.apache.cloudstack.affinity.AffinityGroup\":\"319dc948-606c-4045-81a3-1fd385fb12c1\"}","cmdEventType":"AG.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"319dc948-606c-4045-81a3-1fd385fb12c1","ctxAccountId":"2","ctxStartEventId":"1705","apiKey":"lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg","signature":"Oc6n9ljuRmBDy9KAh5ZgO1sEP/k\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 94761346572491, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-12-14 18:29:51,641 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-25:ctx-e231fbde ctx-25d0c1ac ctx-18c538f9) (logid:78eae0c5)
> ===END=== 10.81.29.18 -- GET
> id=319dc948-606c-4045-81a3-1fd385fb12c1&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=deleteAffinityGroup&response=json&signature=Oc6n9ljuRmBDy9KAh5ZgO1sEP%2Fk%3D
> 2014-12-14 18:29:51,646 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-b127c144) (logid:fb950f22) ===START=== 10.81.29.18 --
> GET
> jobid=59ee6d42-9964-4e99-86e5-cd83ace8c0a2&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=queryAsyncJobResult&response=json&signature=4tcHbecYJkvrJxVV00AJe2HShXc%3D
> 2014-12-14 18:29:51,663 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-b127c144 ctx-a6c508cb ctx-65259123) (logid:fb950f22)
> ===END=== 10.81.29.18 -- GET
> jobid=59ee6d42-9964-4e99-86e5-cd83ace8c0a2&apiKey=lA1vMT9CPy47zN3KD8yIgNWohJMRRXquiiQuvhThpUBpW5g6HsFxn_fEKQwLDnlrYUtNeATQsr8psheiAaBAcg&command=queryAsyncJobResult&response=json&signature=4tcHbecYJkvrJxVV00AJe2HShXc%3D
> 2014-12-14 18:29:51,665 ERROR [o.a.c.f.m.MessageBusBase]
> (API-Job-Executor-37:ctx-61c26d76 job-485 ctx-f17ad124) (logid:59ee6d42) NO
> EVENT PUBLISH CAN BE WRAPPED WITHIN DB TRANSACTION!
> com.cloud.utils.exception.CloudRuntimeException: NO EVENT PUBLISH CAN BE
> WRAPPED WITHIN DB TRANSACTION!
> at
> org.apache.cloudstack.framework.messagebus.MessageBusBase.publish(MessageBusBase.java:167)
> at
> org.apache.cloudstack.affinity.AffinityGroupServiceImpl$2.doInTransactionWithoutResult(AffinityGroupServiceImpl.java:304)
> at
> com.cloud.utils.db.TransactionCallbackNoReturn.
[jira] [Commented] (CLOUDSTACK-8022) [Automation] Deletion of Domain with Cleanup set to "true" fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250687#comment-14250687
]
ASF subversion and git services commented on CLOUDSTACK-8022:
-
Commit 1c5e8ebb3113e97c6c0be9b602f9a15852f2d2fd in cloudstack's branch
refs/heads/4.5 from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1c5e8eb ]
CLOUDSTACK-8022: [Automation] Deletion of Domain with Cleanup set to "true"
fails
Changes:
- This is a race condition between the deleteDomain thread and AccountChecker
thread. DeleteDomain thread marks the domain as inactive and proceeds for
cleanup, AccountChecker thread that runs at the same time cleans up any domains
marked as inactive.
- When the DeleteDomain thread finds that domain is already removed, it need
not error out since the domain deletion has already happened
> [Automation] Deletion of Domain with Cleanup set to "true" fails
>
>
> Key: CLOUDSTACK-8022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8022
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> The following test case in test_persistent_rules.py fails:
> {code}
> @attr(tags=["advanced"])
> def test_vpc_force_delete_domain(self):
> # steps
> # 1. Create account and create VPC network in the account
> # 2. Create two persistent networks within this VPC
> # 3. Restart/delete VPC network
> # Validations
> # 1. In case of Restart operation, restart should be successful
> #and persistent networks should be back in persistent state
> # 2. In case of Delete operation, VR servicing the VPC should
> #get destroyed and sourceNAT ip should get released
> child_domain = Domain.create(self.apiclient,
> services=self.services["domain"],
> parentdomainid=self.domain.id)
> try:
> account_1 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> account_2 = Account.create(
> self.apiclient, self.services["account"],
> domainid=child_domain.id
> )
> self.services["vpc"]["cidr"] = "10.1.1.1/16"
> vpc_1 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_1.name,
> domainid=account_1.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_1.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> vpc_2 = VPC.create(
> self.apiclient,
> self.services["vpc"],
> vpcofferingid=self.vpc_off.id,
> zoneid=self.zone.id,
> account=account_2.name,
> domainid=account_2.domainid)
> vpcs = VPC.list(self.apiclient, id=vpc_2.id)
> self.assertEqual(
> validateList(vpcs)[0],
> PASS,
> "VPC list validation failed, vpc list is %s" %
> vpcs)
> persistent_network_1 = Network.create(
> self.api_client, self.services["isolated_network"],
> networkofferingid=self.persistent_network_offering_NoLB.id,
> accountid=account_1.name, domainid=account_1.domainid,
> zoneid=self.zone.id, vpcid=vpc_1.id, gateway="10.1.1.1",
> netmask="255.255.255.0")
> response = verifyNetworkState(self.apiclient,
> persistent_network_1.id,
> "implemented"
> )
> exceptionOccured = response[0]
> isNetworkInDesiredState = response[1]
> exceptionMessage = response[2]
> if (exceptionOccured or (not isNetworkInDesiredState)):
> raise Exception(exceptionMessage)
> self.assertIsNotNone(
> persistent_network_1.vlan,
> "vlan must not be null for persistent network %s" %
> persistent_
[jira] [Commented] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250823#comment-14250823 ] Nux commented on CLOUDSTACK-4735: - Just hit this baby in 4.4.2 + KVM. :( > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250852#comment-14250852 ] Andrija Panic commented on CLOUDSTACK-4735: --- me too, me too (4.4.1) > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250852#comment-14250852 ] Andrija Panic edited comment on CLOUDSTACK-4735 at 12/18/14 12:06 AM: -- me too, me too (4.4.1) - me on KVM... was (Author: andrija): me too, me too (4.4.1) > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250989#comment-14250989 ] ilya musayev commented on CLOUDSTACK-7907: -- Alex and Andrija Besides management-server.log file, there should also be an api log file, can you see your call there? The management server log file should also log this api request, would it be possible to include the log file and 200 lines above and 200 below the api call? Regards ilya > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14250995#comment-14250995 ] ilya musayev commented on CLOUDSTACK-7907: -- I use to have this issue as well, but lately - i cannot reproduce it. What Alexey is mentioning seems to be javascript related, where as what you mentioning is api server issue. Alex, if you see this issue more often, please launch a firebug, attempt to reproduce this error and include the exact error line you see console. Thanks ilya > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251003#comment-14251003 ] Stephen Turner commented on CLOUDSTACK-7907: Thank you for your email. I am on vacation until Monday 5th January. For urgent questions, please contact my manager, andrew.hal...@citrix.com. Thank you very much, -- Stephen Turner Sr Manager, Citrix > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8085) Fails to attach a volume (is made from a snapshot) to a VM with using local storage as primary storage.
Keiichi Yusa created CLOUDSTACK-8085:
Summary: Fails to attach a volume (is made from a snapshot) to a
VM with using local storage as primary storage.
Key: CLOUDSTACK-8085
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8085
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM, Snapshot, Volumes
Affects Versions: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2
Environment: - Builds up with 155 hosts and a cloudstack server.
- Each host equips these.
+ Xeon E5-2680 (10 cores, 20 threads).
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All hosts are networked by InfiniBand and 10GbE.
- Using CentOS6.6 (64bit)
- Using local storage on all hosts as primary storage.
- Using S3 compatible storage (RadosGW) as secondary storage.
Reporter: Keiichi Yusa
Priority: Critical
Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2
CloudStack fails to attach a DATADISK volume (This DATADISK volume is made from
a snapshot) to a VM with using local storage as primary storage.
Reproduction procedure:
# To use local storage as primary storage.
# Take a snapshot of a VM's ROOT/DATADISK volume. (By clicking [Take Snapshot]
button on WebUI.)
# Create a new DATADISK volume from this snapshot. (By clicking [Create Volume]
button on WebUI.)
# Try to attach this new DATADISK volume to a VM. (By Clicking [Attach Disk]
button on WebUI.)
When we execute these, CloudStack fails attach this new DATADISK volume to the
VM with occuring the following error:
{noformat}
"Failed to attach local data volume snapshot-test-std-stop to VM
snapshot-test-0001 as migration of local data volume is not allowed"
{noformat}
At this time, Cloudstack puts a exception in management-server.log. (Please see
[1])
We investigate our CloudStack environment about this problem.
We notice that Cloudstack behaves as follows:
* CloudStack creates a new DATADISK volume at primary storage of any one of the
hosts when a user creates the volume from a snapshot by executing [Create
Volume]. (This primary storage is local storage on the host.)
* Now, the user deploys a new VM (or uses a existing VM). In many cases, the
new DATADISK volume is deployed to a host different from the host that is
deployed the VM.
* User will attach the new DATADISK volume to the VM. When the user executes
[Attach Disk], CloudStack tries to migrate the new DATADISK volume to the host
that is deployed the VM in order to attach the new DATADISK volume to the VM.
* However, CloudStack fails this migration because we use local storage as
primary storage.
[1] Exception in managemnet-server.log
{noformat}
2014-12-02 19:37:10,807 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-50:ctx-a0ef6a5a) Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException: Failed to attach local data
volume snapshot-test-std-stop to VM snapshot-test-0001 as migration of local
data volume is not allowed
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1292)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1156)
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1126)
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:622)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy197.attachVolumeToVM(Unknown Source)
at
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at
com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
at
com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
at
org.apache.cloudstack.ma
[jira] [Created] (CLOUDSTACK-8086) [Automation][Simulator] Simulator needs a Portable IP Range to execute PortableIP Test Cases
Chandan Purushothama created CLOUDSTACK-8086: Summary: [Automation][Simulator] Simulator needs a Portable IP Range to execute PortableIP Test Cases Key: CLOUDSTACK-8086 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8086 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently test cases are failing in Simulator, since the portable IP Range dictionary is empty in testdata.py. Fake IP Range information needs to be provided so that the test cases can be run without any issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251043#comment-14251043 ] ilya musayev commented on CLOUDSTACK-4735: -- work around, disable the zone, expunge/delete all system vms, fix the problem with sysvm start, enable zone > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251043#comment-14251043 ] ilya musayev edited comment on CLOUDSTACK-4735 at 12/18/14 2:31 AM: work around, disable the zone, expunge/delete all system vms, fix the problem with sysvm start, enable zone edit: can you see expunge task in logs? was (Author: serverchief): work around, disable the zone, expunge/delete all system vms, fix the problem with sysvm start, enable zone > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251088#comment-14251088 ] ilya musayev commented on CLOUDSTACK-8038: -- Nux, Please consider creating ova for vmware instead of vmdk that cannot be digested by cloudstack. If you want me to share a script that rolls ova's from vmdk, let me know, Thanks ilya > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251100#comment-14251100 ] ilya musayev commented on CLOUDSTACK-8038: -- Nux, I don't know if you will be able to roll vmware tools support on the distro of linux you are running and keep the size small at the same time, but at the least if you have e1000 nic module and lsilogic controller module, vm should boot in vmware. One method to consider is to build http://sourceforge.net/projects/open-vm-tools/files/open-vm-tools/stable-9.4.x/ once and then copy the modules and libs over to this appliance. The size of the VM will increase by few megs - but nothing horrible. Regards ilya > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8087) Fix component/maint/test_vpc_on_host_maintenance.py
Ashutosk Kelkar created CLOUDSTACK-8087: --- Summary: Fix component/maint/test_vpc_on_host_maintenance.py Key: CLOUDSTACK-8087 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8087 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.5.0 The test case fails while creating VPC when the hosts are in maintenance state. The VPC should be created with start parameter as False in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251306#comment-14251306 ] Rajani Karuturi commented on CLOUDSTACK-4735: - to overcome this, I set nic_id, reservation_id and taken to NULL in op_dc_ip_address_alloc table. > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251329#comment-14251329 ] Nux commented on CLOUDSTACK-8038: - Ilya, The kernel supports e1000 and lsi (FUSION) as well as pv drivers for all hypervisors, let me know if you have any additions, pull requests welcome. https://github.com/NuxRo/macchinina/blob/master/configs/kernel/dotkernelconfig Vmware/xenserver/hyperv tools on the other hand are going to be tricky to add. First of all they require quite a bit of space and deps, second need to compile them against uClibc (some are not even open source). My first priority is to release something that boots everywhere and has the scripts, then root resize would be nice, then we can see about these tools, but they will certainly affect size significantly. Thanks for input! > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251340#comment-14251340 ] Nux commented on CLOUDSTACK-8038: - Ilya, Re Ova, please share the scripts. Had no idea the vmdk images can't be used. Thanks! Lucian > Create a new reusable tinylinux appliance for all hypervisors > - > > Key: CLOUDSTACK-8038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 > 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: Future, 4.6.0 > > > Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 > MB in size) that has the reset password/ssh-public-key scripts for testing > purposes. Make this available for everyone for various hypervisors - Xen, > VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251350#comment-14251350 ] Daniel Hertanu commented on CLOUDSTACK-4735: That's how I fixed it at the time... Having 4 management IP addresses, I found in the table op_dc_ip_address_alloc two of them being reserved so I simply did this (after I took a backup of the database): mysql> update op_dc_ip_address_alloc set nic_id=NULL,reservation_id=NULL,taken=NULL where id=1; Don’t forget to replace the id above with the proper id from your database. > Management IP address pool exhausted > > > Key: CLOUDSTACK-4735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.1.0 > Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), > XenServer 6.1 >Reporter: Daniel Hertanu > > With only one computing node in the Zone, rebooting it without enabling > maintenance mode on it, determines the management IP addresses pool to be > exhausted as a result of CloudStack attempting continuously to provision the > system VMs. Regardless the expunge delay or interval values, the management > IPs are not released anymore and the common error reported in the logs is: > 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-22:job-72) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
