[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195875#comment-14195875
]
Olivier Lemasle commented on CLOUDSTACK-6850:
-
[~svscorp], cpu cores, cpu speed and memory are returned in usages *only* if
the instance uses a *dynamic compute offering" (or "custom" service offering:
cpu & memory are not specified in the service offering but when the VM is
launched).
With ACS 4.4.0, if I use this service offering (with {{iscustomized=true}}):
{code:xml}
4daeb7bc-5ded-435f-801b-a5d89c5524d1
CustomOffering
CustomOffering
2014-09-09T15:33:12+0200
shared
false
false
false
false
false
true
{code}
usage records look like this:
{code:xml}
admin
06c0bf94-3821-11e4-9b36-0050569ed71c
ee30148e-3820-11e4-9b36-0050569ed71c
2d4a129a-f952-4867-9136-5706d890301c
testCustom allocated (ServiceOffering: 12) (Template:
205)
0.17 Hrs
2
0.17
a4c7c8a2-fa4d-450c-8544-9444182d1859
testCustom
4daeb7bc-5ded-435f-801b-a5d89c5524d1
152e70b1-31cb-4d84-8a68-1fba941cd817
a4c7c8a2-fa4d-450c-8544-9444182d1859
XenServer
1
600
1024
2014-11-04'T'08:55:00+01:00
2014-11-04'T'09:05:00+01:00
{code}
For a "normal" service offering ({{iscustomized=true}}), the usage record looks
like this:
{code:xml}
admin
06c0bf94-3821-11e4-9b36-0050569ed71c
ee30148e-3820-11e4-9b36-0050569ed71c
2d4a129a-f952-4867-9136-5706d890301c
test2 running time (ServiceOffering: 1) (Template:
205)
0.17 Hrs
1
0.17
efa24dfe-4ab6-4c91-b390-29dfd2184d58
test2
f27ba533-efe7-46a2-b9cf-b509c15e5dcf
152e70b1-31cb-4d84-8a68-1fba941cd817
efa24dfe-4ab6-4c91-b390-29dfd2184d58
XenServer
2014-11-04'T'08:55:00+01:00
2014-11-04'T'09:05:00+01:00
{code}
> Cpu cores, cpu speed and memory are not returned by listUsageRecords
>
>
> Key: CLOUDSTACK-6850
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Usage
>Affects Versions: 4.3.0, 4.4.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
> Fix For: 4.4.0
>
>
> When using dynamic custom offerings, cpu cores, cpu speed and ram values are
> recorded in usage_vm_instance table while parsing the usage events.
> But these details are not populated in cloud_usage table, and are not
> returned by the listUsageRecords command. Therefore, there is no way to know
> the historical values for cpu and memory using API.
> We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and
> return them in listUsageRecords response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195875#comment-14195875
]
Olivier Lemasle edited comment on CLOUDSTACK-6850 at 11/4/14 9:08 AM:
--
[~svscorp], cpu cores, cpu speed and memory are returned in usages *only* if
the instance uses a *dynamic compute offering" (or "custom" service offering:
cpu & memory are not specified in the service offering but when the VM is
launched).
With ACS 4.4.0, if I use this service offering (with {{iscustomized=true}}):
{code:xml}
4daeb7bc-5ded-435f-801b-a5d89c5524d1
CustomOffering
CustomOffering
2014-09-09T15:33:12+0200
shared
false
false
false
false
false
true
{code}
usage records look like this:
{code:xml}
admin
06c0bf94-3821-11e4-9b36-0050569ed71c
ee30148e-3820-11e4-9b36-0050569ed71c
2d4a129a-f952-4867-9136-5706d890301c
testCustom allocated (ServiceOffering: 12) (Template:
205)
0.17 Hrs
2
0.17
a4c7c8a2-fa4d-450c-8544-9444182d1859
testCustom
4daeb7bc-5ded-435f-801b-a5d89c5524d1
152e70b1-31cb-4d84-8a68-1fba941cd817
a4c7c8a2-fa4d-450c-8544-9444182d1859
XenServer
1
600
1024
2014-11-04'T'08:55:00+01:00
2014-11-04'T'09:05:00+01:00
{code}
For this "normal" service offering ({{iscustomized=false}}, cpu and ram
specified):
{code:xml}
f27ba533-efe7-46a2-b9cf-b509c15e5dcf
Small Instance
Small Instance
1
500
512
2014-09-09T14:58:43+0200
shared
false
false
false
false
false
false
{code}
the usage record looks like this:
{code:xml}
admin
06c0bf94-3821-11e4-9b36-0050569ed71c
ee30148e-3820-11e4-9b36-0050569ed71c
2d4a129a-f952-4867-9136-5706d890301c
test2 running time (ServiceOffering: 1) (Template:
205)
0.17 Hrs
1
0.17
efa24dfe-4ab6-4c91-b390-29dfd2184d58
test2
f27ba533-efe7-46a2-b9cf-b509c15e5dcf
152e70b1-31cb-4d84-8a68-1fba941cd817
efa24dfe-4ab6-4c91-b390-29dfd2184d58
XenServer
2014-11-04'T'08:55:00+01:00
2014-11-04'T'09:05:00+01:00
{code}
To sum up, you will have cpu and ram information in the service offering OR in
the usage record.
was (Author: olemasle):
[~svscorp], cpu cores, cpu speed and memory are returned in usages *only* if
the instance uses a *dynamic compute offering" (or "custom" service offering:
cpu & memory are not specified in the service offering but when the VM is
launched).
With ACS 4.4.0, if I use this service offering (with {{iscustomized=true}}):
{code:xml}
4daeb7bc-5ded-435f-801b-a5d89c5524d1
CustomOffering
CustomOffering
2014-09-09T15:33:12+0200
shared
false
false
false
false
false
true
{code}
usage records look like this:
{code:xml}
admin
06c0bf94-3821-11e4-9b36-0050569ed71c
ee30148e-3820-11e4-9b36-0050569ed71c
2d4a129a-f952-4867-9136-5706d890301c
testCustom allocated (ServiceOffering: 12) (Template:
205)
0.17 Hrs
2
0.17
a4c7c8a2-fa4d-450c-8544-9444182d1859
testCustom
4daeb7bc-5ded-435f-801b-a5d89c5524d1
152e70b1-31cb-4d84-8a68-1fba941cd817
a4c7c8a2-fa4d-450c-8544-9444182d1859
XenServer
1
600
1024
2014-11-04'T'08:55:00+01:00
2014-11-04'T'09:05:00+01:00
{code}
For a "normal" service offering ({{iscustomized=true}}), the usage record looks
like this:
{code:xml}
admin
06c0bf94-3821-11e4-9b36-0050569ed71c
ee30148e-3820-11e4-9b36-0050569ed71c
2d4a129a-f952-4867-9136-5706d890301c
test2 running time (ServiceOffering: 1) (Template:
205)
0.17 Hrs
1
0.17
efa24dfe-4ab6-4c91-b390-29dfd2184d58
test2
f27ba533-efe7-46a2-b9cf-b509c15e5dcf
152e70b1-31cb-4d84-8a68-1fba941cd817
efa24dfe-4ab6-4c91-b390-29dfd2184d58
XenServer
2014-11-04'T'08:55:00+01:00
2014-11-04'T'09:05:00+01:00
{code}
> Cpu cores, cpu speed and memory are not returned by listUsageRecords
>
>
> Key: CLOUDSTACK-6850
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Usage
>Affects Versions: 4.3.0, 4.4.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
> Fix For: 4.4.0
>
>
> When using dynamic custom offerings, cpu cores, cpu speed and ram values are
> recorded in usage_vm_instance table while parsing the usage events.
> But these details are not populated in cloud_usage table, and are not
> returned by the listUsageRecords command. Therefore, there is no way to know
> the historical values for
[jira] [Created] (CLOUDSTACK-7835) Deleted volumes with null UUID and no removed timestamp in database still appear
Sanjay Tripathi created CLOUDSTACK-7835: --- Summary: Deleted volumes with null UUID and no removed timestamp in database still appear Key: CLOUDSTACK-7835 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7835 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Environment: XS 6.2 Latest code from 4.5 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.5.0 Occasionally when CS deletes a volume, it does not fully delete it out of the database. Instead an entry is left behind with a null UUID and no removal timestamp, so the volume appears in the CS UI. However any attempt to view the volume's information will result in an exception. And since there is no UUID, there is no way I know of to ask CS's API to do anything with them. mysql> select id,name,uuid,created,attached from volumes where removed is null order by id asc; id nameuuidcreated attached 8 vol3NULL2014-10-16 23:16:34 2014-10-16 23:17:47 11 vol4NULL2014-10-17 02:54:44 2014-10-17 02:55:47 15 vol6NULL2014-10-17 11:09:32 2014-10-17 11:11:23 19 vol10 NULL2014-10-17 14:54:35 2014-10-17 14:56:09 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195945#comment-14195945 ] Ilia Shakitko commented on CLOUDSTACK-6850: --- Last example with a "normal" SO, you meant iscustomized=false - right? > Cpu cores, cpu speed and memory are not returned by listUsageRecords > > > Key: CLOUDSTACK-6850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0 >Reporter: Olivier Lemasle >Assignee: Olivier Lemasle >Priority: Critical > Fix For: 4.4.0 > > > When using dynamic custom offerings, cpu cores, cpu speed and ram values are > recorded in usage_vm_instance table while parsing the usage events. > But these details are not populated in cloud_usage table, and are not > returned by the listUsageRecords command. Therefore, there is no way to know > the historical values for cpu and memory using API. > We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and > return them in listUsageRecords response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195947#comment-14195947 ] Olivier Lemasle commented on CLOUDSTACK-6850: - Yes, I've edited my previous answer. > Cpu cores, cpu speed and memory are not returned by listUsageRecords > > > Key: CLOUDSTACK-6850 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0, 4.4.0 >Reporter: Olivier Lemasle >Assignee: Olivier Lemasle >Priority: Critical > Fix For: 4.4.0 > > > When using dynamic custom offerings, cpu cores, cpu speed and ram values are > recorded in usage_vm_instance table while parsing the usage events. > But these details are not populated in cloud_usage table, and are not > returned by the listUsageRecords command. Therefore, there is no way to know > the historical values for cpu and memory using API. > We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and > return them in listUsageRecords response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5807) Problem with shared datastore in VMware cluster with only one host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5807: --- Assignee: Likitha Shetty > Problem with shared datastore in VMware cluster with only one host > -- > > Key: CLOUDSTACK-5807 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5807 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.3.0 > Environment: ESX 5.1 >Reporter: Mike Tutkowski >Assignee: Likitha Shetty > Fix For: 4.4.0 > > > I created a volume on a SAN and connected my one and only ESX host in the > cluster to it via CHAP. The iSCSI target was detected and I was able to > create a datastore with it (manually through vSphere Client). > The problem is that the VMware server resource detects this new datastore and > automatically introduces it to CloudStack as host-based primary storage. > This is a problem because it should really be cluster-based primary storage. > If I were to add another ESX host to this cluster, I don't think it could > access this primary storage as it is currently configured in CloudStack. > The logic to detect if a datastore on an ESX host is local must be somewhat > flawed. > I believe if I had two or more hosts in my cluster and performed this > datastore operation that it would not have detected this as host-based > primary storage and I would have been able to manually add the datastore to > CloudStack as cluster-based primary storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7836) S2S VPN CIDR list max 200 chars and only RFC1918
Thijs Houtenbos created CLOUDSTACK-7836: --- Summary: S2S VPN CIDR list max 200 chars and only RFC1918 Key: CLOUDSTACK-7836 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7836 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.1.0 Reporter: Thijs Houtenbos Priority: Minor When creating a S2S VPN within Cloudstack there are two problems with the CIDR list field: 1. It only accepts RFC1918 addresses 2. It's length is limited to 200 characters, which is too short -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
Mihaela Stoica created CLOUDSTACK-7837: -- Summary: [UI] CIDR field not completely visible in multi-edit view Key: CLOUDSTACK-7837 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 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.0, 4.5.0 Reporter: Mihaela Stoica Assignee: Mihaela Stoica Priority: Minor Network - Guest networks > IP Addresses > Configuration > Firewall (available for Advanced Networks only): The Source CIDR field is not completely visible. We should make the column wide enough to fit the CIDR value without ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7837: --- Attachment: screenshot-1.png > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > 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.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7837: --- Attachment: (was: screenshot-1.png) > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > 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.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7837: --- Attachment: screenshot-1.png > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > 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.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7739) Add new vGPU types K160Q, K180Q, K280Q to the CloudStack UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-7739. - Resolution: Fixed > Add new vGPU types K160Q, K180Q, K280Q to the CloudStack UI > --- > > Key: CLOUDSTACK-7739 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7739 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.5.0 > > > NVidia will be releasing a new vGPU driver, it will make new vGPU types > available on both XS 6.2 SP1 and XS 6.5. > Both the XenServer and the CloudStack API will pick these new types up, but > CloudStack GUI need some changes as the vGPU types are hard-coded here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7838) UI - Dashboard should be more clear in representing what "storage" and "Primary storage allocated" capacities mean.
Gabor Apati-Nagy created CLOUDSTACK-7838: Summary: UI - Dashboard should be more clear in representing what "storage" and "Primary storage allocated" capacities mean. Key: CLOUDSTACK-7838 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: pre-4.0.0 Reporter: Gabor Apati-Nagy Assignee: Gabor Apati-Nagy Fix For: 4.5.0 Make the wordings better on the Resources tab of a Zone. "Storage" -> "Primary Storage Used" "CPU" -> "CPU allocated" Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7835) Deleted volumes with null UUID and no removed timestamp in database still appear
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196011#comment-14196011 ] ASF subversion and git services commented on CLOUDSTACK-7835: - Commit 1d503bb8533d2a7b2a36ac4b76b50308b714494d in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1d503bb ] CLOUDSTACK-7835: Deleted volumes with null UUID and no removed timestamp in database still appear. Also removed CREATING -> DESTROY via DESTROYREQUESTED, which was causing the volume to get stuck in expunging state. > Deleted volumes with null UUID and no removed timestamp in database still > appear > > > Key: CLOUDSTACK-7835 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7835 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes > Environment: XS 6.2 > Latest code from 4.5 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.5.0 > > > Occasionally when CS deletes a volume, it does not fully delete it out of the > database. > Instead an entry is left behind with a null UUID and no removal timestamp, so > the volume appears in the CS UI. However any attempt to view the volume's > information will result in an exception. > And since there is no UUID, there is no way I know of to ask CS's API to do > anything with them. > mysql> select id,name,uuid,created,attached from volumes where removed is > null order by id asc; > idnameuuidcreated attached > 8 vol3NULL2014-10-16 23:16:34 2014-10-16 23:17:47 > 11vol4NULL2014-10-17 02:54:44 2014-10-17 02:55:47 > 15vol6NULL2014-10-17 11:09:32 2014-10-17 11:11:23 > 19vol10 NULL2014-10-17 14:54:35 2014-10-17 14:56:09 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7372) [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to migrate to the other host in the cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196010#comment-14196010
]
ASF subversion and git services commented on CLOUDSTACK-7372:
-
Commit 7a8f511014ea15373b96c19d812e97010384e2ec in cloudstack's branch
refs/heads/master from [~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a8f511 ]
CLOUDSTACK-7372: [vGPU] When a host is put in maintenance mode, vGPU enabled VMs
failed to migrate to the other host in the cluster.
Migration for vGPU VMs is not supported in XS, so instead of migrating them to
new server, stopping them.
> [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to
> migrate to the other host in the cluster
> --
>
> Key: CLOUDSTACK-7372
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7372
> 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
> Environment: Xenserver 6.2.5 + PV drivers
> CS - 4.5.0
>Reporter: Abhinav Roy
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone CS setup with 2 XEN hosts in a cluster having same
> configuration and vGPU cards.
> 2. Create 2 VMs with vGPU offering on Host1
> 3. Put Host1 in maintenance mode
> Expected behavior:
> =
> VMs should migrate to Host 2 and Host1 should go to "maintenance" state
> Observed behavior :
> =
> VMs fail to migrate to Host2 with the following error and Host1 is stuck in
> "prepareformaintenance" state.
> 2014-08-18 19:16:00,608 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-a55c13e9) ===START=== 10.144.7.6 -- GET
> command=prepareHostForMaintenance&id=f68de59b-3d28-452f-b82b-86fca83f6f16&response=json&sessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D&_=1408369336934
> 2014-08-18 19:16:00,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) submit async job-690, details:
> AsyncJobVO {id:690, userId: 2, accountId: 2, instanceType: Host, instanceId:
> 8, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"id":"f68de59b-3d28-452f-b82b-86fca83f6f16","response":"json","sessionkey":"XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d","ctxDetails":"{\"com.cloud.host.Host\":\"f68de59b-3d28-452f-b82b-86fca83f6f16\"}","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1408369336934","uuid":"f68de59b-3d28-452f-b82b-86fca83f6f16","ctxAccountId":"2","ctxStartEventId":"983"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-18 19:16:00,653 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) ===END=== 10.144.7.6 -- GET
> command=prepareHostForMaintenance&id=f68de59b-3d28-452f-b82b-86fca83f6f16&response=json&sessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D&_=1408369336934
> 2014-08-18 19:16:00,654 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-3:ctx-5d223414 job-690) Add job-690 into job monitoring
> 2014-08-18 19:16:00,655 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-3:ctx-5d223414 job-690) Executing AsyncJobVO {id:690,
> userId: 2, accountId: 2, instanceType: Host, instanceId: 8, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"id":"f68de59b-3d28-452f-b82b-86fca83f6f16","response":"json","sessionkey":"XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d","ctxDetails":"{\"com.cloud.host.Host\":\"f68de59b-3d28-452f-b82b-86fca83f6f16\"}","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1408369336934","uuid":"f68de59b-3d28-452f-b82b-86fca83f6f16","ctxAccountId":"2","ctxStartEventId":"983"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-18 19:16:00,683 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq
> 8-5623307084725485586: Sending { Cmd , MgmtId: 213737702773493, via:
> 8(cldstk-R720-66), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2014-08-18 19:16:00,684 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq
> 8-5623307084725485586: Executing: { Cmd , MgmtId: 213737702773493, via:
> 8(cldstk-R720-66), Ver: v1, Flags: 100111,
> [{"com.cloud.ag
[jira] [Updated] (CLOUDSTACK-7838) UI - Dashboard should have more clean category names
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy updated CLOUDSTACK-7838: - Summary: UI - Dashboard should have more clean category names (was: UI - Dashboard should be more clear in representing what "storage" and "Primary storage allocated" capacities mean.) > UI - Dashboard should have more clean category names > > > Key: CLOUDSTACK-7838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: pre-4.0.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy > Fix For: 4.5.0 > > > Make the wordings better on the Resources tab of a Zone. > "Storage" -> "Primary Storage Used" > "CPU" -> "CPU allocated" > Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7837: --- Attachment: IssueFixed.png > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > 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.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7838) UI - Update category names on Resources tab of a Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy updated CLOUDSTACK-7838: - Summary: UI - Update category names on Resources tab of a Zone (was: UI - Dashboard should have more clean category names) > UI - Update category names on Resources tab of a Zone > - > > Key: CLOUDSTACK-7838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: pre-4.0.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy > Fix For: 4.5.0 > > > Make the wordings better on the Resources tab of a Zone. > "Storage" -> "Primary Storage Used" > "CPU" -> "CPU allocated" > Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7421) [Automation] Exceptions in orchestrate* methods from virtualMachineManagerImpl are shown in log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das reopened CLOUDSTACK-7421:
-
> [Automation] Exceptions in orchestrate* methods from
> virtualMachineManagerImpl are shown in log
> ---
>
> Key: CLOUDSTACK-7421
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7421
> 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: Rayees Namathponnan
>Assignee: Koushik Das
> Fix For: 4.5.0
>
>
> Steps to reproduce
> 1 ) Deploy VM
> 2) Add one more nic
> 3) remove default nic the VM
> Result
> Below exception thrown in log, it should be handled with proper messgae
> cloud.vm.VmWorkRemoveNicFromVm for VM 30, job origin: 248
> 2014-08-23 09:50:33,665 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-61:ctx-5c747fe0 job-248/job-249) Unable to complete
> AsyncJobVO {id:249, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkRemoveNicFromVm, cmdInfo:
> rO0ABXNyACJjb20uY2xvdWQudm0uVm1Xb3JrUmVtb3ZlTmljRnJvbVZtxM1Xh9nBu10CAAFMAAVuaWNJZHQAEExqYXZhL2xhbmcvTG9uZzt4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAB50ABlWaXJ0dWFsTWFjaGluZU1hbmFnZXJJbXBsc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cABI,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 90928106758026, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Sat Aug 23 09:50:32 PDT 2014}, job origin:248
> com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from
> VM[User|i-18-30-TestVM] in Ntwk[222|Guest|17], nic is default.
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:2963)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:4690)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica updated CLOUDSTACK-7837: --- Status: Reviewable (was: In Progress) > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > 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.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7837) [UI] CIDR field not completely visible in multi-edit view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196028#comment-14196028 ] Mihaela Stoica commented on CLOUDSTACK-7837: Review request: https://reviews.apache.org/r/27568/ > [UI] CIDR field not completely visible in multi-edit view > - > > Key: CLOUDSTACK-7837 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7837 > 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.0, 4.5.0 >Reporter: Mihaela Stoica >Assignee: Mihaela Stoica >Priority: Minor > Attachments: IssueFixed.png, screenshot-1.png > > > Network - Guest networks > IP Addresses > Configuration > Firewall (available > for Advanced Networks only): > The Source CIDR field is not completely visible. > We should make the column wide enough to fit the CIDR value without > ellipsizing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7421) [Automation] Exceptions in orchestrate* methods from virtualMachineManagerImpl are shown in log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196036#comment-14196036
]
ASF subversion and git services commented on CLOUDSTACK-7421:
-
Commit 0327c2b13e9712a63d865ff755a9fec421eb0af5 in cloudstack's branch
refs/heads/master from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0327c2b ]
CLOUDSTACK-7421
Unnecessary exception in MS logs while removing default NIC from VM. Following
changes are made:
1. Changed the exception from CloudRuntimeException to
InvalidParameterValueExecption.
2. Moved out validation logic to UserVMManagerImpl from
VirtualMachineManagerImpl.
3. Handling InvalidParameterValueException from async API calls so that they
are not logged as ERROR in MS logs.
> [Automation] Exceptions in orchestrate* methods from
> virtualMachineManagerImpl are shown in log
> ---
>
> Key: CLOUDSTACK-7421
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7421
> 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: Rayees Namathponnan
>Assignee: Koushik Das
> Fix For: 4.5.0
>
>
> Steps to reproduce
> 1 ) Deploy VM
> 2) Add one more nic
> 3) remove default nic the VM
> Result
> Below exception thrown in log, it should be handled with proper messgae
> cloud.vm.VmWorkRemoveNicFromVm for VM 30, job origin: 248
> 2014-08-23 09:50:33,665 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-61:ctx-5c747fe0 job-248/job-249) Unable to complete
> AsyncJobVO {id:249, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkRemoveNicFromVm, cmdInfo:
> rO0ABXNyACJjb20uY2xvdWQudm0uVm1Xb3JrUmVtb3ZlTmljRnJvbVZtxM1Xh9nBu10CAAFMAAVuaWNJZHQAEExqYXZhL2xhbmcvTG9uZzt4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAB50ABlWaXJ0dWFsTWFjaGluZU1hbmFnZXJJbXBsc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cABI,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 90928106758026, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Sat Aug 23 09:50:32 PDT 2014}, job origin:248
> com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from
> VM[User|i-18-30-TestVM] in Ntwk[222|Guest|17], nic is default.
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:2963)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:4690)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7421) [Automation] Exceptions in orchestrate* methods from virtualMachineManagerImpl are shown in log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das resolved CLOUDSTACK-7421.
-
Resolution: Fixed
> [Automation] Exceptions in orchestrate* methods from
> virtualMachineManagerImpl are shown in log
> ---
>
> Key: CLOUDSTACK-7421
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7421
> 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: Rayees Namathponnan
>Assignee: Koushik Das
> Fix For: 4.5.0
>
>
> Steps to reproduce
> 1 ) Deploy VM
> 2) Add one more nic
> 3) remove default nic the VM
> Result
> Below exception thrown in log, it should be handled with proper messgae
> cloud.vm.VmWorkRemoveNicFromVm for VM 30, job origin: 248
> 2014-08-23 09:50:33,665 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-61:ctx-5c747fe0 job-248/job-249) Unable to complete
> AsyncJobVO {id:249, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkRemoveNicFromVm, cmdInfo:
> rO0ABXNyACJjb20uY2xvdWQudm0uVm1Xb3JrUmVtb3ZlTmljRnJvbVZtxM1Xh9nBu10CAAFMAAVuaWNJZHQAEExqYXZhL2xhbmcvTG9uZzt4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAB50ABlWaXJ0dWFsTWFjaGluZU1hbmFnZXJJbXBsc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cABI,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 90928106758026, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Sat Aug 23 09:50:32 PDT 2014}, job origin:248
> com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from
> VM[User|i-18-30-TestVM] in Ntwk[222|Guest|17], nic is default.
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:2963)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateRemoveNicFromVm(VirtualMachineManagerImpl.java:4690)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7835) Deleted volumes with null UUID and no removed timestamp in database still appear
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196049#comment-14196049 ] ASF subversion and git services commented on CLOUDSTACK-7835: - Commit a53d39c1b687df22768613d556637c34354cb96b in cloudstack's branch refs/heads/4.5 from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a53d39c1 ] CLOUDSTACK-7835: Deleted volumes with null UUID and no removed timestamp in database still appear. Also removed CREATING -> DESTROY via DESTROYREQUESTED, which was causing the volume to get stuck in expunging state. > Deleted volumes with null UUID and no removed timestamp in database still > appear > > > Key: CLOUDSTACK-7835 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7835 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes > Environment: XS 6.2 > Latest code from 4.5 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.5.0 > > > Occasionally when CS deletes a volume, it does not fully delete it out of the > database. > Instead an entry is left behind with a null UUID and no removal timestamp, so > the volume appears in the CS UI. However any attempt to view the volume's > information will result in an exception. > And since there is no UUID, there is no way I know of to ask CS's API to do > anything with them. > mysql> select id,name,uuid,created,attached from volumes where removed is > null order by id asc; > idnameuuidcreated attached > 8 vol3NULL2014-10-16 23:16:34 2014-10-16 23:17:47 > 11vol4NULL2014-10-17 02:54:44 2014-10-17 02:55:47 > 15vol6NULL2014-10-17 11:09:32 2014-10-17 11:11:23 > 19vol10 NULL2014-10-17 14:54:35 2014-10-17 14:56:09 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7372) [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to migrate to the other host in the cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196048#comment-14196048
]
ASF subversion and git services commented on CLOUDSTACK-7372:
-
Commit 9168d826dad42b73f03aaa1170d5387f7c19b07d in cloudstack's branch
refs/heads/4.5 from [~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9168d82 ]
CLOUDSTACK-7372: [vGPU] When a host is put in maintenance mode, vGPU enabled VMs
failed to migrate to the other host in the cluster.
Migration for vGPU VMs is not supported in XS, so instead of migrating them to
new server, stopping them.
> [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to
> migrate to the other host in the cluster
> --
>
> Key: CLOUDSTACK-7372
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7372
> 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
> Environment: Xenserver 6.2.5 + PV drivers
> CS - 4.5.0
>Reporter: Abhinav Roy
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone CS setup with 2 XEN hosts in a cluster having same
> configuration and vGPU cards.
> 2. Create 2 VMs with vGPU offering on Host1
> 3. Put Host1 in maintenance mode
> Expected behavior:
> =
> VMs should migrate to Host 2 and Host1 should go to "maintenance" state
> Observed behavior :
> =
> VMs fail to migrate to Host2 with the following error and Host1 is stuck in
> "prepareformaintenance" state.
> 2014-08-18 19:16:00,608 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-a55c13e9) ===START=== 10.144.7.6 -- GET
> command=prepareHostForMaintenance&id=f68de59b-3d28-452f-b82b-86fca83f6f16&response=json&sessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D&_=1408369336934
> 2014-08-18 19:16:00,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) submit async job-690, details:
> AsyncJobVO {id:690, userId: 2, accountId: 2, instanceType: Host, instanceId:
> 8, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"id":"f68de59b-3d28-452f-b82b-86fca83f6f16","response":"json","sessionkey":"XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d","ctxDetails":"{\"com.cloud.host.Host\":\"f68de59b-3d28-452f-b82b-86fca83f6f16\"}","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1408369336934","uuid":"f68de59b-3d28-452f-b82b-86fca83f6f16","ctxAccountId":"2","ctxStartEventId":"983"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-18 19:16:00,653 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) ===END=== 10.144.7.6 -- GET
> command=prepareHostForMaintenance&id=f68de59b-3d28-452f-b82b-86fca83f6f16&response=json&sessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D&_=1408369336934
> 2014-08-18 19:16:00,654 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-3:ctx-5d223414 job-690) Add job-690 into job monitoring
> 2014-08-18 19:16:00,655 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-3:ctx-5d223414 job-690) Executing AsyncJobVO {id:690,
> userId: 2, accountId: 2, instanceType: Host, instanceId: 8, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"id":"f68de59b-3d28-452f-b82b-86fca83f6f16","response":"json","sessionkey":"XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d","ctxDetails":"{\"com.cloud.host.Host\":\"f68de59b-3d28-452f-b82b-86fca83f6f16\"}","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1408369336934","uuid":"f68de59b-3d28-452f-b82b-86fca83f6f16","ctxAccountId":"2","ctxStartEventId":"983"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-18 19:16:00,683 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq
> 8-5623307084725485586: Sending { Cmd , MgmtId: 213737702773493, via:
> 8(cldstk-R720-66), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2014-08-18 19:16:00,684 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq
> 8-5623307084725485586: Executing: { Cmd , MgmtId: 213737702773493, via:
> 8(cldstk-R720-66), Ver: v1, Flags: 100111,
> [{"com.cloud.agent
[jira] [Resolved] (CLOUDSTACK-7372) [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to migrate to the other host in the cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjay Tripathi resolved CLOUDSTACK-7372.
-
Resolution: Fixed
> [vGPU] When a host is put in maintenance mode, vGPU enabled VMs failed to
> migrate to the other host in the cluster
> --
>
> Key: CLOUDSTACK-7372
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7372
> 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
> Environment: Xenserver 6.2.5 + PV drivers
> CS - 4.5.0
>Reporter: Abhinav Roy
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps :
> ==
> 1. Deploy an advanced zone CS setup with 2 XEN hosts in a cluster having same
> configuration and vGPU cards.
> 2. Create 2 VMs with vGPU offering on Host1
> 3. Put Host1 in maintenance mode
> Expected behavior:
> =
> VMs should migrate to Host 2 and Host1 should go to "maintenance" state
> Observed behavior :
> =
> VMs fail to migrate to Host2 with the following error and Host1 is stuck in
> "prepareformaintenance" state.
> 2014-08-18 19:16:00,608 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-a55c13e9) ===START=== 10.144.7.6 -- GET
> command=prepareHostForMaintenance&id=f68de59b-3d28-452f-b82b-86fca83f6f16&response=json&sessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D&_=1408369336934
> 2014-08-18 19:16:00,651 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) submit async job-690, details:
> AsyncJobVO {id:690, userId: 2, accountId: 2, instanceType: Host, instanceId:
> 8, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"id":"f68de59b-3d28-452f-b82b-86fca83f6f16","response":"json","sessionkey":"XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d","ctxDetails":"{\"com.cloud.host.Host\":\"f68de59b-3d28-452f-b82b-86fca83f6f16\"}","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1408369336934","uuid":"f68de59b-3d28-452f-b82b-86fca83f6f16","ctxAccountId":"2","ctxStartEventId":"983"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-18 19:16:00,653 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-a55c13e9 ctx-5208dce9) ===END=== 10.144.7.6 -- GET
> command=prepareHostForMaintenance&id=f68de59b-3d28-452f-b82b-86fca83f6f16&response=json&sessionkey=XUBDEpbw7%2BbvhRUGB0j2dKXFW08%3D&_=1408369336934
> 2014-08-18 19:16:00,654 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-3:ctx-5d223414 job-690) Add job-690 into job monitoring
> 2014-08-18 19:16:00,655 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-3:ctx-5d223414 job-690) Executing AsyncJobVO {id:690,
> userId: 2, accountId: 2, instanceType: Host, instanceId: 8, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"id":"f68de59b-3d28-452f-b82b-86fca83f6f16","response":"json","sessionkey":"XUBDEpbw7+bvhRUGB0j2dKXFW08\u003d","ctxDetails":"{\"com.cloud.host.Host\":\"f68de59b-3d28-452f-b82b-86fca83f6f16\"}","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1408369336934","uuid":"f68de59b-3d28-452f-b82b-86fca83f6f16","ctxAccountId":"2","ctxStartEventId":"983"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-08-18 19:16:00,683 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq
> 8-5623307084725485586: Sending { Cmd , MgmtId: 213737702773493, via:
> 8(cldstk-R720-66), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2014-08-18 19:16:00,684 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-3:ctx-5d223414 job-690 ctx-4be20e99) Seq
> 8-5623307084725485586: Executing: { Cmd , MgmtId: 213737702773493, via:
> 8(cldstk-R720-66), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2014-08-18 19:16:00,684 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-30:ctx-d6521262) Seq 8-5623307084725485586: Executing request
> 2014-08-18 19:16:00,713 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-30:ctx-d6521262) Seq 8-5623307084725485586: Response Received:
> 2014-08-18 19:16:00,713 DEBUG [c.c.a.t.Request] (DirectAgent-30:ctx-d6521262)
> Seq 8-5623307084725485586: Processing: { Ans: , MgmtId: 213737702773493,
> via: 8, Ver: v
[jira] [Resolved] (CLOUDSTACK-7835) Deleted volumes with null UUID and no removed timestamp in database still appear
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-7835. - Resolution: Fixed > Deleted volumes with null UUID and no removed timestamp in database still > appear > > > Key: CLOUDSTACK-7835 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7835 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes > Environment: XS 6.2 > Latest code from 4.5 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.5.0 > > > Occasionally when CS deletes a volume, it does not fully delete it out of the > database. > Instead an entry is left behind with a null UUID and no removal timestamp, so > the volume appears in the CS UI. However any attempt to view the volume's > information will result in an exception. > And since there is no UUID, there is no way I know of to ask CS's API to do > anything with them. > mysql> select id,name,uuid,created,attached from volumes where removed is > null order by id asc; > idnameuuidcreated attached > 8 vol3NULL2014-10-16 23:16:34 2014-10-16 23:17:47 > 11vol4NULL2014-10-17 02:54:44 2014-10-17 02:55:47 > 15vol6NULL2014-10-17 11:09:32 2014-10-17 11:11:23 > 19vol10 NULL2014-10-17 14:54:35 2014-10-17 14:56:09 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi reassigned CLOUDSTACK-7242:
---
Assignee: Rajani Karuturi (was: Kishan Kavala)
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3197) UI: NTier: User is required to scroll down every single time to "Create Network" after creation of 3 Network Tiers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner updated CLOUDSTACK-3197: --- Fix Version/s: (was: 4.4.0) Future > UI: NTier: User is required to scroll down every single time to "Create > Network" after creation of 3 Network Tiers > -- > > Key: CLOUDSTACK-3197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: Chandan talked to Sonny about this bug and Sonny said he > will move the "Create Network" icon to the top. >Reporter: Chandan Purushothama >Assignee: Sonny Chhen > Fix For: Future > > Attachments: UICapture21.PNG > > > Users are required to scroll down to see the "Create Network" Box on the Main > VPC page after creation of three network tiers. To search for an option > presented below the list of network tiers is not user friendly. > Attached the corresponding Screenshot to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3338) Please provide an icon for "assignVMs" action in internal LB rule detailView
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Turner updated CLOUDSTACK-3338: --- Fix Version/s: (was: 4.4.0) Future > Please provide an icon for "assignVMs" action in internal LB rule detailView > > > Key: CLOUDSTACK-3338 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3338 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Sonny Chhen > Fix For: Future > > Attachments: assignVMs_to_internalLBrule.jpg > > > Action "assignVMs" is in "ui/scripts/vpc.js". > Please see my attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7839) Unable to live migrate an instance to another host in a cluster from which the template has been deleted
Joris van Lieshout created CLOUDSTACK-7839: -- Summary: Unable to live migrate an instance to another host in a cluster from which the template has been deleted Key: CLOUDSTACK-7839 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7839 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.6.0 Reporter: Joris van Lieshout Priority: Critical ACS throws an null pointer exception when you try to live migrate an instance to another host in a cluster and the template of that instance has been deleted. I have pasted the exception below. Steps to reproduce the issue: 1. create an instance from iso 2. stop the instance 3. create a template from the root volume 4. create a new instance from that template 5. leave the instance running 6. delete the template 7. try the live migrate the instance to another host in the cluster The migrate button in the web interface will not respond. The exception below can be found in the management-server log 2014-11-04 14:08:45,509 ERROR [cloud.api.ApiServer] (TP-Processor49:ctx-35286d62 ctx-3de77f98) unhandled exception executing api command: findHostsForMigration java.lang.NullPointerException at com.cloud.storage.StorageManagerImpl.storagePoolHasEnoughSpace(StorageManagerImpl.java:1561) at org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.filter(AbstractStoragePoolAllocator.java:199) at org.apache.cloudstack.storage.allocator.ClusterScopeStoragePoolAllocator.select(ClusterScopeStoragePoolAllocator.java:110) at org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.allocateToPool(AbstractStoragePoolAllocator.java:109) at com.cloud.server.ManagementServerImpl.findSuitablePoolsForVolumes(ManagementServerImpl.java:1250) at com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1150) at sun.reflect.GeneratedMethodAccessor643.invoke(Unknown Source) 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.$Proxy193.listHostsForMigrationOfVM(Unknown Source) at org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:323) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:53) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:115) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:112) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:74) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(Acce
[jira] [Commented] (CLOUDSTACK-7839) Unable to live migrate an instance to another host in a cluster from which the template has been deleted
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196092#comment-14196092
]
Joris van Lieshout commented on CLOUDSTACK-7839:
Additional information:
The public boolean "storagePoolHasEnoughSpace" in StorageManagerImpl.java has a
loop that goes through all volumes. The second if statement in the loop is
where the NP exception is thrown because _templateDao.findById returns no
templates
for (Volume volume : volumes) {
if (volume.getTemplateId() != null) {
VMTemplateVO tmpl =
_templateDao.findById(volume.getTemplateId());
if (tmpl.getFormat() != ImageFormat.ISO) {
allocatedSizeWithtemplate =
_capacityMgr.getAllocatedPoolCapacity(poolVO, tmpl);
}
}
if (volume.getState() != Volume.State.Ready) {
totalAskingSize = totalAskingSize +
getVolumeSizeIncludingHvSsReserve(volume, pool);
}
}
This SQL statement will show that the removed field of vm_template is not null
causeing findById to return nothing.
select vm_template.name, vm_template.removed from vm_instance join vm_template
on vm_instance.vm_template_id=vm_template.id where vm_instance.name like
'%testinstancefromtmpl1%';
vm_template.name, vm_template.removed
'testinstancetmp','2014-11-04 09:21:34'
> Unable to live migrate an instance to another host in a cluster from which
> the template has been deleted
>
>
> Key: CLOUDSTACK-7839
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7839
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.6.0
>Reporter: Joris van Lieshout
>Priority: Critical
>
> ACS throws an null pointer exception when you try to live migrate an instance
> to another host in a cluster and the template of that instance has been
> deleted.
> I have pasted the exception below.
> Steps to reproduce the issue:
> 1. create an instance from iso
> 2. stop the instance
> 3. create a template from the root volume
> 4. create a new instance from that template
> 5. leave the instance running
> 6. delete the template
> 7. try the live migrate the instance to another host in the cluster
> The migrate button in the web interface will not respond.
> The exception below can be found in the management-server log
> 2014-11-04 14:08:45,509 ERROR [cloud.api.ApiServer]
> (TP-Processor49:ctx-35286d62 ctx-3de77f98) unhandled exception executing api
> command: findHostsForMigration
> java.lang.NullPointerException
> at
> com.cloud.storage.StorageManagerImpl.storagePoolHasEnoughSpace(StorageManagerImpl.java:1561)
> at
> org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.filter(AbstractStoragePoolAllocator.java:199)
> at
> org.apache.cloudstack.storage.allocator.ClusterScopeStoragePoolAllocator.select(ClusterScopeStoragePoolAllocator.java:110)
> at
> org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.allocateToPool(AbstractStoragePoolAllocator.java:109)
> at
> com.cloud.server.ManagementServerImpl.findSuitablePoolsForVolumes(ManagementServerImpl.java:1250)
> at
> com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1150)
> at sun.reflect.GeneratedMethodAccessor643.invoke(Unknown Source)
> 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.$Proxy193.listHostsForMigrationOfVM(Unknown Source)
> at
> org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
> at com.cloud.api.ApiServer.queueCommand(Ap
[jira] [Updated] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7537: -- Fix Version/s: (was: 4.5.0) > RBD pool secret should be masked in logs > > > Key: CLOUDSTACK-7537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Kishan Kavala >Assignee: Kishan Kavala > > RBD pool authentication secret key is logged in plain text in management > server and agent logs at the following places: > - While adding pool to MS > - When MS send modifyStorage pool command to agent > secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7537: -- Affects Version/s: 4.2.0 > RBD pool secret should be masked in logs > > > Key: CLOUDSTACK-7537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Kishan Kavala >Assignee: Kishan Kavala > > RBD pool authentication secret key is logged in plain text in management > server and agent logs at the following places: > - While adding pool to MS > - When MS send modifyStorage pool command to agent > secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7537: -- Assignee: (was: Kishan Kavala) > RBD pool secret should be masked in logs > > > Key: CLOUDSTACK-7537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Kishan Kavala > > RBD pool authentication secret key is logged in plain text in management > server and agent logs at the following places: > - While adding pool to MS > - When MS send modifyStorage pool command to agent > secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6717) [OVS][UI]VPC network creation page does not display custom network offering created for vpc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196276#comment-14196276 ] Stephen Turner commented on CLOUDSTACK-6717: >From Alena's comment, it sounds as if this is probably not a UI issue, but >rather that the network offering doesn't have the right settings. Sanjeev, >could you check that? Thanks. > [OVS][UI]VPC network creation page does not display custom network offering > created for vpc > --- > > Key: CLOUDSTACK-6717 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6717 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 > Environment: Latest build from 4.4 branch with commit > e6961fd21bb6d793302c234d0f409f66dc498072 >Reporter: Sanjeev N >Assignee: Sanjeev N >Priority: Critical > Fix For: 4.4.0 > > Attachments: vpc_tier.PNG > > > [SDN][UI]VPC network creation page does not display custom network offering > created for vpc > Steps to Reproduce: > > 1.Bring up CS in advanced zone with xen cluster > 2.Create physical network with GRE isolation > 3.Create Region level vpc > 4.Create isolated network offering for vpc with virtualnetworking service and > ovs as the service provider > 5.Enable the network offering > 6.In region level vpc try to create tier with above created network offering > Result: > == > Add tier in VPC page does not display the custom vpc offering created with > ovs provider. It only shows the default vpc offerings in the drop down list. > Attaching screen shot to describe the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3952: -- Assignee: (was: Kishan Kavala) > Persist VR nic details in DB for additional public ranges > - > > Key: CLOUDSTACK-3952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Kishan Kavala > Fix For: 4.4.0, 4.5.0 > > > For non-vpcs VR, nics are dynamically created for addtional IP ranges with > different Vlan. Prepare fro migration doesn't setup the destination host > correctly due to this and migration fails. > Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6690) [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang updated CLOUDSTACK-6690:
-
Fix Version/s: (was: 4.4.0)
> [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
> --
>
> Key: CLOUDSTACK-6690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6690
> 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.0
>Reporter: manasaveloori
>Assignee: Jessica Wang
> Fix For: 4.5.0
>
> Attachments: Listview.jpg
>
>
> 1. Create VPC.
> 2. Create a tier network with network offering having support for internal LB.
> 3. Deploy a VM under this tier network.
> 3. VPC->tier->internal LBCon figure internal LB.
> 4. Now assign the VM to internal LB.
> While assigning we are haviing 2 options to select the VM.
> Listview on left hand side is not valid.
> Assigning the VM by using the Listview does not configure the lb rule:
> Logs
> 2014-05-16 16:00:58,946 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Executing AsyncJobVO {id:444, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd,
> cmdInfo:
> {"response":"json","id":"c2ca8600-0cf9-44a0-8443-da5c743cbd49","sessionkey":"e9nTmi2e/Ci2Oy/hkABO5FRlkI8\u003d","cmdEventType":"LB.ASSIGN.TO.RULE","virtualmachineids":"","ctxUserId":"2","httpmethod":"GET","_":"1400236258357","ctxAccountId":"2","ctxStartEventId":"541"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7322717913215, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-16 16:00:59,016 WARN [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-12:job-444 ctx-723e9aab) List of vms to assign to the lb,
> is empty
> 2014-05-16 16:00:59,029 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Complete async job-444, jobStatus: FAILED,
> resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
> to assign load balancer rule"}
> 2014-05-16 16:00:59,042 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Done executing
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> for job-444
> Attaching the screen shot for the same.
> Able to assign VM to internal LB uisng the select button on right hand side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7838) UI - Update category names on Resources tab of a Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy updated CLOUDSTACK-7838: - Component/s: UI > UI - Update category names on Resources tab of a Zone > - > > Key: CLOUDSTACK-7838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: pre-4.0.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy > Fix For: 4.5.0 > > > Make the wordings better on the Resources tab of a Zone. > "Storage" -> "Primary Storage Used" > "CPU" -> "CPU allocated" > Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7840) UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong
Gabor Apati-Nagy created CLOUDSTACK-7840: Summary: UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong Key: CLOUDSTACK-7840 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7840 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Gabor Apati-Nagy Assignee: Gabor Apati-Nagy Priority: Minor Fix For: 4.5.0 The Control Tip that is displayed when the user opens the 'Add Primary Storage' dialog and then clicks on 'Provider' doesn't seem to be correct - it seems to be the text that is displayed when selecting a Zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7834) Web UI shows all DHCP/PXE providers in cloud when admin click DHCP/PXE IP for A zone.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang resolved CLOUDSTACK-7834. - Resolution: Fixed > Web UI shows all DHCP/PXE providers in cloud when admin click DHCP/PXE IP for > A zone. > - > > Key: CLOUDSTACK-7834 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7834 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Baremetal >Affects Versions: 4.5.0 >Reporter: frank zhang >Assignee: frank zhang > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6690) [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang resolved CLOUDSTACK-6690.
--
Resolution: Fixed
> [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
> --
>
> Key: CLOUDSTACK-6690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6690
> 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.0
>Reporter: manasaveloori
>Assignee: Jessica Wang
> Fix For: 4.5.0
>
> Attachments: Listview.jpg, jessica-2014-11-04.PNG
>
>
> 1. Create VPC.
> 2. Create a tier network with network offering having support for internal LB.
> 3. Deploy a VM under this tier network.
> 3. VPC->tier->internal LBCon figure internal LB.
> 4. Now assign the VM to internal LB.
> While assigning we are haviing 2 options to select the VM.
> Listview on left hand side is not valid.
> Assigning the VM by using the Listview does not configure the lb rule:
> Logs
> 2014-05-16 16:00:58,946 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Executing AsyncJobVO {id:444, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd,
> cmdInfo:
> {"response":"json","id":"c2ca8600-0cf9-44a0-8443-da5c743cbd49","sessionkey":"e9nTmi2e/Ci2Oy/hkABO5FRlkI8\u003d","cmdEventType":"LB.ASSIGN.TO.RULE","virtualmachineids":"","ctxUserId":"2","httpmethod":"GET","_":"1400236258357","ctxAccountId":"2","ctxStartEventId":"541"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7322717913215, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-16 16:00:59,016 WARN [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-12:job-444 ctx-723e9aab) List of vms to assign to the lb,
> is empty
> 2014-05-16 16:00:59,029 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Complete async job-444, jobStatus: FAILED,
> resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
> to assign load balancer rule"}
> 2014-05-16 16:00:59,042 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Done executing
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> for job-444
> Attaching the screen shot for the same.
> Able to assign VM to internal LB uisng the select button on right hand side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6690) [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang updated CLOUDSTACK-6690:
-
Attachment: jessica-2014-11-04.PNG
> [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
> --
>
> Key: CLOUDSTACK-6690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6690
> 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.0
>Reporter: manasaveloori
>Assignee: Jessica Wang
> Fix For: 4.5.0
>
> Attachments: Listview.jpg, jessica-2014-11-04.PNG
>
>
> 1. Create VPC.
> 2. Create a tier network with network offering having support for internal LB.
> 3. Deploy a VM under this tier network.
> 3. VPC->tier->internal LBCon figure internal LB.
> 4. Now assign the VM to internal LB.
> While assigning we are haviing 2 options to select the VM.
> Listview on left hand side is not valid.
> Assigning the VM by using the Listview does not configure the lb rule:
> Logs
> 2014-05-16 16:00:58,946 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Executing AsyncJobVO {id:444, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd,
> cmdInfo:
> {"response":"json","id":"c2ca8600-0cf9-44a0-8443-da5c743cbd49","sessionkey":"e9nTmi2e/Ci2Oy/hkABO5FRlkI8\u003d","cmdEventType":"LB.ASSIGN.TO.RULE","virtualmachineids":"","ctxUserId":"2","httpmethod":"GET","_":"1400236258357","ctxAccountId":"2","ctxStartEventId":"541"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7322717913215, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-16 16:00:59,016 WARN [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-12:job-444 ctx-723e9aab) List of vms to assign to the lb,
> is empty
> 2014-05-16 16:00:59,029 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Complete async job-444, jobStatus: FAILED,
> resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
> to assign load balancer rule"}
> 2014-05-16 16:00:59,042 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Done executing
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> for job-444
> Attaching the screen shot for the same.
> Able to assign VM to internal LB uisng the select button on right hand side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6690) [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196580#comment-14196580
]
Jessica Wang commented on CLOUDSTACK-6690:
--
fixed (as my attached screenshot)
> [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
> --
>
> Key: CLOUDSTACK-6690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6690
> 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.0
>Reporter: manasaveloori
>Assignee: Jessica Wang
> Fix For: 4.5.0
>
> Attachments: Listview.jpg, jessica-2014-11-04.PNG
>
>
> 1. Create VPC.
> 2. Create a tier network with network offering having support for internal LB.
> 3. Deploy a VM under this tier network.
> 3. VPC->tier->internal LBCon figure internal LB.
> 4. Now assign the VM to internal LB.
> While assigning we are haviing 2 options to select the VM.
> Listview on left hand side is not valid.
> Assigning the VM by using the Listview does not configure the lb rule:
> Logs
> 2014-05-16 16:00:58,946 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Executing AsyncJobVO {id:444, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd,
> cmdInfo:
> {"response":"json","id":"c2ca8600-0cf9-44a0-8443-da5c743cbd49","sessionkey":"e9nTmi2e/Ci2Oy/hkABO5FRlkI8\u003d","cmdEventType":"LB.ASSIGN.TO.RULE","virtualmachineids":"","ctxUserId":"2","httpmethod":"GET","_":"1400236258357","ctxAccountId":"2","ctxStartEventId":"541"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7322717913215, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-16 16:00:59,016 WARN [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-12:job-444 ctx-723e9aab) List of vms to assign to the lb,
> is empty
> 2014-05-16 16:00:59,029 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Complete async job-444, jobStatus: FAILED,
> resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
> to assign load balancer rule"}
> 2014-05-16 16:00:59,042 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Done executing
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> for job-444
> Attaching the screen shot for the same.
> Able to assign VM to internal LB uisng the select button on right hand side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7840) UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy updated CLOUDSTACK-7840: - Status: Reviewable (was: In Progress) > UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong > -- > > Key: CLOUDSTACK-7840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.5.0 > > > The Control Tip that is displayed when the user opens the 'Add Primary > Storage' dialog and then clicks on 'Provider' doesn't seem to be correct - it > seems to be the text that is displayed when selecting a Zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7838) UI - Update category names on Resources tab of a Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy updated CLOUDSTACK-7838: - Status: Reviewable (was: In Progress) > UI - Update category names on Resources tab of a Zone > - > > Key: CLOUDSTACK-7838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: pre-4.0.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy > Fix For: 4.5.0 > > > Make the wordings better on the Resources tab of a Zone. > "Storage" -> "Primary Storage Used" > "CPU" -> "CPU allocated" > Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7384: Assignee: Jessica Wang > [LXC][UI] show change service offering command option only when VM is in stop > state > --- > > Key: CLOUDSTACK-7384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: change.png > > > we should show change service offerings of a LXC VM in stop state in > Instance detail tab , the way we do it in KVM VMs. > Currently we show change service offering option in LXC VMs when VM is > running as well > Attaching screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196624#comment-14196624 ] Stephen Turner commented on CLOUDSTACK-7384: Thank you for your email. I am on vacation until Friday 7th November. For urgent questions, please contact my manager, andrew.hal...@citrix.com. Thank you very much, -- Stephen Turner Sr Manager, XenServer Citrix > [LXC][UI] show change service offering command option only when VM is in stop > state > --- > > Key: CLOUDSTACK-7384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: change.png > > > we should show change service offerings of a LXC VM in stop state in > Instance detail tab , the way we do it in KVM VMs. > Currently we show change service offering option in LXC VMs when VM is > running as well > Attaching screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196663#comment-14196663 ] ASF subversion and git services commented on CLOUDSTACK-7384: - Commit 25e514a28e94ab32d452da45d8e6b42ab39ccffb in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=25e514a ] CLOUDSTACK-7384: UI > Instances > detailView > change service offering option > hide it when VM state is Running and hyperviror is LXC. > [LXC][UI] show change service offering command option only when VM is in stop > state > --- > > Key: CLOUDSTACK-7384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: change.png > > > we should show change service offerings of a LXC VM in stop state in > Instance detail tab , the way we do it in KVM VMs. > Currently we show change service offering option in LXC VMs when VM is > running as well > Attaching screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196668#comment-14196668 ] ASF subversion and git services commented on CLOUDSTACK-7384: - Commit 4d62dbb8ba3e3d987a92d8c872302901bc23e0bc in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4d62dbb ] CLOUDSTACK-7384: UI > Instances > detailView > change service offering option > hide it when VM state is Running and hyperviror is LXC. > [LXC][UI] show change service offering command option only when VM is in stop > state > --- > > Key: CLOUDSTACK-7384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: change.png > > > we should show change service offerings of a LXC VM in stop state in > Instance detail tab , the way we do it in KVM VMs. > Currently we show change service offering option in LXC VMs when VM is > running as well > Attaching screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7384. -- Resolution: Fixed > [LXC][UI] show change service offering command option only when VM is in stop > state > --- > > Key: CLOUDSTACK-7384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: change.png > > > we should show change service offerings of a LXC VM in stop state in > Instance detail tab , the way we do it in KVM VMs. > Currently we show change service offering option in LXC VMs when VM is > running as well > Attaching screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7383: Assignee: Jessica Wang > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7383: - Priority: Critical (was: Major) > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7720) No IP Address Validation for Acquire new secondary IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196757#comment-14196757 ] ASF subversion and git services commented on CLOUDSTACK-7720: - Commit 2a1793283a1ea28494bebc3b195a98feff6e6cbc in cloudstack's branch refs/heads/master from [~gabora] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2a17932 ] CLOUDSTACK-7720: No IP Address Validation for Acquire new secondary IP -Removed required constraint from the IP address field (this is an optional field) > No IP Address Validation for Acquire new secondary IP > - > > Key: CLOUDSTACK-7720 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7720 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.5.0 > > > Steps: > 1. Go to Instances --> NICs tab. > 2. Click on the View Secondary IPs > 3. Click on Acquire new secondary IP > There is No IP address validation for "Acquire new secondary IP". > Additionally, this field should be a required field. Clicking "Ok" generates > an IP, but it can be confusing to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7753: - Assignee: Sanjeev N (was: Chandan Purushothama) > [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small > detecting memory incorrectly > - > > Key: CLOUDSTACK-7753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 > 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: Alex Brett >Assignee: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6623) Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196767#comment-14196767 ] edison su commented on CLOUDSTACK-6623: --- Nobody want this feature for now, so move it to next feature. > Register template does not work as expected, when deploying simulator and xen > zones simultaneously on a single management server. > - > > Key: CLOUDSTACK-6623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: edison su >Priority: Critical > Fix For: 4.6.0 > > > when we setup simulator and xenserver both in separate zones on a single > management server, The register template always behaves as if it is executing > on the simulator. i.e. register template is always successful and it dose not > initiate the actual download when calling the register template API against > xen-zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7838) UI - Update category names on Resources tab of a Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196766#comment-14196766 ] ASF subversion and git services commented on CLOUDSTACK-7838: - Commit fad6c7514f23b3785818771cd1d3e626af7274b9 in cloudstack's branch refs/heads/master from [~gabora] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fad6c75 ] CLOUDSTACK-7838: UI - Update category names on Resources tab of a Zone -Changed wording: "Storage" -> "Primary Storage Used", "CPU" -> "CPU allocated", Memory -> "Memory Allocated" > UI - Update category names on Resources tab of a Zone > - > > Key: CLOUDSTACK-7838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: pre-4.0.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy > Fix For: 4.5.0 > > > Make the wordings better on the Resources tab of a Zone. > "Storage" -> "Primary Storage Used" > "CPU" -> "CPU allocated" > Memory -> "Memory Allocated" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6623) Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-6623: -- Fix Version/s: (was: 4.5.0) 4.6.0 > Register template does not work as expected, when deploying simulator and xen > zones simultaneously on a single management server. > - > > Key: CLOUDSTACK-6623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: edison su >Priority: Critical > Fix For: 4.6.0 > > > when we setup simulator and xenserver both in separate zones on a single > management server, The register template always behaves as if it is executing > on the simulator. i.e. register template is always successful and it dose not > initiate the actual download when calling the register template API against > xen-zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196755#comment-14196755 ] Chandan Purushothama commented on CLOUDSTACK-7753: -- Alex, I already looked into it. Sanjeev is aware of this issue. Hence I am assigning the bug to him Thank you, Chandan. > [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small > detecting memory incorrectly > - > > Key: CLOUDSTACK-7753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 > 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: Alex Brett >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > Deployed VM has the following memory configuration on the VM: > [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem > MemTotal: 363416 kB > MemFree: 81864 kB > [root@Atoms-VM-2 ~]# > Which is around 354.8984375 MB > But the Service Offering specified specifies 512 MB as shown below: > mysql> select id,name,instance_name,state,service_offering_id from > vm_instance where id=59 \G > id: 59 >name: Atoms-VM-2 > instance_name: i-36-59-VM > state: Running > service_offering_id: 1 > 1 row in set (0.00 sec) > mysql> select * from service_offering where id=1 \G > id: 1 >cpu: 1 > speed: 500 > ram_size: 512 >nw_rate: NULL >mc_rate: NULL > ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL >default_use: 0 >vm_type: NULL > sort_key: 0 >is_volatile: 0 > deployment_planner: NULL > 1 row in set (0.00 sec) > mysql> -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196771#comment-14196771 ] edison su commented on CLOUDSTACK-5933: --- HI Sateesh, it's vmware related, so assign it to you. > Problem with VMware snapshot when datastore has a space in its name > --- > > Key: CLOUDSTACK-5933 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.3.0 > Environment: Management Server on Ubuntu 12.04.1 > ESXi 5.1 >Reporter: Mike Tutkowski >Assignee: Sateesh Chodapuneedi > Fix For: 4.5.0 > > > I have two hosts in my VMware cluster. > I elected to have vSphere Client use its default names for the datastore of > each host's local storage. > These names are the following: "datastore1" and "datastore1 (1)" > Note the presence of a space in the second datastore name. This space causes > our creation of a VM snapshot to return to the management server an incorrect > path field. > For example, let's say the path in the DB of our root disk is abcxyz before > the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, > it is still abcxyz. > The problem is in this method in VmwareStorageManagerImpl: > extractSnapshotBaseFileName > That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7840) UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196769#comment-14196769 ] ASF subversion and git services commented on CLOUDSTACK-7840: - Commit 1f21f399ab7711534febd77bb695e6c149293481 in cloudstack's branch refs/heads/master from [~gabora] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1f21f39 ] CLOUDSTACK-7840: UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong -Removed the invalid help text. > UI control tip for 'Add Primary Storage' -> 'Provider' seems wrong > -- > > Key: CLOUDSTACK-7840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.5.0 > > > The Control Tip that is displayed when the user opens the 'Add Primary > Storage' dialog and then clicks on 'Provider' doesn't seem to be correct - it > seems to be the text that is displayed when selecting a Zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-5933: -- Assignee: Sateesh Chodapuneedi (was: edison su) > Problem with VMware snapshot when datastore has a space in its name > --- > > Key: CLOUDSTACK-5933 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.3.0 > Environment: Management Server on Ubuntu 12.04.1 > ESXi 5.1 >Reporter: Mike Tutkowski >Assignee: Sateesh Chodapuneedi > Fix For: 4.5.0 > > > I have two hosts in my VMware cluster. > I elected to have vSphere Client use its default names for the datastore of > each host's local storage. > These names are the following: "datastore1" and "datastore1 (1)" > Note the presence of a space in the second datastore name. This space causes > our creation of a VM snapshot to return to the management server an incorrect > path field. > For example, let's say the path in the DB of our root disk is abcxyz before > the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, > it is still abcxyz. > The problem is in this method in VmwareStorageManagerImpl: > extractSnapshotBaseFileName > That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5452) KVM - Agent is not able to connect back if management server was restarted when there are pending tasks to this host.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196733#comment-14196733 ] edison su commented on CLOUDSTACK-5452: --- It's due to limitation of current agent model, can't cancel a running task on the agent side. The problem is: if there is running task which takes forever to finish, we can't do anything about it, unless restart agent and kill all the running processes spawned by java agent. Need human intervention in this case. We have to manually kill this jobs, otherwise, the system will be in inconsistent state. > KVM - Agent is not able to connect back if management server was restarted > when there are pending tasks to this host. > - > > Key: CLOUDSTACK-5452 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5452 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > KVM - Agent is not able to connect back if management server was restarted > when there are pending tasks to this host. > Steps to reproduce the problem: > Set up - Advanced zone with 2 KVM ( RHEL 6.3) hosts. > Deployed few Vms. > Started snapshot for ROOT volume of the VMs. > When the snapshot processes are still in progress , restart management > server. > When the management sever started , the KVM hosts remain in disconnected > state. > Attempt to stop Vms /start Vms fails because of having no connection to the > host. > Following is seen in agent logs: > 2013-12-10 20:56:46,640 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:56:46,640 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:56:51,641 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:56:51,642 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:56:56,642 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:56:56,643 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:01,644 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:01,644 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:06,644 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:06,645 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:11,645 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:11,646 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:16,647 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:16,647 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:21,648 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:21,648 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:26,649 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:26,675 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:31,676 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:31,677 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:36,678 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remain
[jira] [Closed] (CLOUDSTACK-7769) [Automation] Fix the script "test_ssvm.py" - SSVM Gateway Assertion is not valid in EIP-ELB case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama closed CLOUDSTACK-7769. Resolution: Fixed Fix has already been made and the Fix has been tested > [Automation] Fix the script "test_ssvm.py" - SSVM Gateway Assertion is not > valid in EIP-ELB case > > > Key: CLOUDSTACK-7769 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7769 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > SSVM and CPVM's gateway in EIP-ELB Setup is present in the Public Network and > not in the private network. Hence needs to avoid that assertion in EIP-ELB > Setup scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5452) KVM - Agent is not able to connect back if management server was restarted when there are pending tasks to this host.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-5452: -- Fix Version/s: (was: 4.5.0) 4.6.0 > KVM - Agent is not able to connect back if management server was restarted > when there are pending tasks to this host. > - > > Key: CLOUDSTACK-5452 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5452 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Critical > Fix For: 4.6.0 > > > KVM - Agent is not able to connect back if management server was restarted > when there are pending tasks to this host. > Steps to reproduce the problem: > Set up - Advanced zone with 2 KVM ( RHEL 6.3) hosts. > Deployed few Vms. > Started snapshot for ROOT volume of the VMs. > When the snapshot processes are still in progress , restart management > server. > When the management sever started , the KVM hosts remain in disconnected > state. > Attempt to stop Vms /start Vms fails because of having no connection to the > host. > Following is seen in agent logs: > 2013-12-10 20:56:46,640 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:56:46,640 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:56:51,641 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:56:51,642 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:56:56,642 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:56:56,643 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:01,644 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:01,644 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:06,644 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:06,645 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:11,645 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:11,646 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:16,647 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:16,647 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:21,648 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:21,648 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:26,649 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:26,675 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:31,676 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:31,677 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:36,678 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-10 20:57:36,678 INFO [cloud.agent.Agent] (Agent-Handler-2:null) > Cannot connect because we still have 1 commands in progress. > 2013-12-10 20:57:41,678 INFO [cloud.agent.Agent] (Agent-Handler-2:null) Lost > connection to the server. Dealing with the remaining commands... > : -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196810#comment-14196810 ] ASF subversion and git services commented on CLOUDSTACK-7645: - Commit 4e80253b36967d12c9782f382e335ef7a45dd243 in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e80253 ] CLOUDSTACK-7645 [UI] Fix incorrect strings 'label.no' and 'label.added.network.offering' > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Stephen Turner >Assignee: Mihaela Stoica >Priority: Critical > Fix For: 4.5.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197010#comment-14197010 ] ASF subversion and git services commented on CLOUDSTACK-7383: - Commit a43fba64dacb55da6dedf6140beb5f692a486e61 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a43fba6 ] CLOUDSTACK-7383: UI > Instances > detailView > snapshot option > hide this option when hypervisor is LXC. > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197014#comment-14197014 ] ASF subversion and git services commented on CLOUDSTACK-7383: - Commit 68396521098a25aee68d038c72a2fc7f253d62c0 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6839652 ] CLOUDSTACK-7383: UI > Instances > detailView > snapshot option > hide this option when hypervisor is LXC. > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7383. -- Resolution: Fixed > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7487) [UI] Public, Featured, routing option are not shown while registering templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7487: Assignee: shweta agarwal (was: Jessica Wang) shweta, I'm unable to reproduce this bug. Please provide: (1) database dump (against 4.5 release). (2) steps to reproduce: e.g. (i) log in as admin/password (ii) click Templates tab (iii) click Register Template button (iv) choose zone "AAA" in dropdown thank you. Jessica > [UI] Public, Featured, routing option are not shown while registering > templates > > > Key: CLOUDSTACK-7487 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7487 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal > Fix For: Future > > Attachments: template.png > > > Repro steps: > Open RegisterTemplate dialog box > Notice Public, Featured and routing option check boxes are not shown while > registering templates > Attaching screenshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7487) [UI] Public, Featured, routing option are not shown while registering templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197032#comment-14197032 ] Jessica Wang edited comment on CLOUDSTACK-7487 at 11/4/14 10:53 PM: shweta, I'm unable to reproduce this bug. Please provide: (1) database dump (against 4.5 release). (2) steps to reproduce: e.g. (i) log in as admin/password (ii) click Templates tab (iii) click Register Template button (iv) choose "All Zones" in zone dropdown. thank you. Jessica was (Author: jessicawang): shweta, I'm unable to reproduce this bug. Please provide: (1) database dump (against 4.5 release). (2) steps to reproduce: e.g. (i) log in as admin/password (ii) click Templates tab (iii) click Register Template button (iv) choose zone "AAA" in dropdown thank you. Jessica > [UI] Public, Featured, routing option are not shown while registering > templates > > > Key: CLOUDSTACK-7487 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7487 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal > Fix For: Future > > Attachments: template.png > > > Repro steps: > Open RegisterTemplate dialog box > Notice Public, Featured and routing option check boxes are not shown while > registering templates > Attaching screenshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6851) ResourceTagResponse does not have "id" field due to which resource level permission cannot be granted to any specific resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-6851: - Description: This enhancement is related to IAM feature, specially writing automated IAM marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in future release. Fix Version/s: (was: 4.5.0) Future > ResourceTagResponse does not have "id" field due to which resource level > permission cannot be granted to any specific resource > -- > > Key: CLOUDSTACK-6851 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6851 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.4.0 >Reporter: Namita Chaudhari >Assignee: Min Chen > Labels: None > Fix For: Future > > > This enhancement is related to IAM feature, specially writing automated IAM > marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in > future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7650) with wrong checksum volume got uploaded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7650: --- Fix Version/s: (was: 4.5.0) 4.6.0 > with wrong checksum volume got uploaded > > > Key: CLOUDSTACK-7650 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7650 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.5.0 >Reporter: prashant kumar mishra >Assignee: Nitin Mehta > Fix For: 4.6.0 > > Attachments: Logs_DB.rar > > > steps to reproduce > > 1-upload a volume with wrong checksum > 2-try to attach to a vm > Expected > -- > upload volume should fail > Actual > --- > volume got uploaded and attached successfully -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7650) with wrong checksum volume got uploaded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197073#comment-14197073 ] Animesh Chaturvedi commented on CLOUDSTACK-7650: Corner case no impact to functionality so IMHO can be punted out of 4.5 > with wrong checksum volume got uploaded > > > Key: CLOUDSTACK-7650 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7650 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.5.0 >Reporter: prashant kumar mishra >Assignee: Nitin Mehta > Fix For: 4.6.0 > > Attachments: Logs_DB.rar > > > steps to reproduce > > 1-upload a volume with wrong checksum > 2-try to attach to a vm > Expected > -- > upload volume should fail > Actual > --- > volume got uploaded and attached successfully -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7290) VO classes shouldn¹t have any class variables declared as native type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-7290: Fix Version/s: (was: 4.5.0) 4.6.0 > VO classes shouldn¹t have any class variables declared as native type > - > > Key: CLOUDSTACK-7290 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7290 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > > VO classes which are the mapping of schema to Java objects shouldn¹t > have any class variables declared as native type. Because native types > have default values whereas schema columns can be null and declaring as > native types masks that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7289) Bugs seen when declaring a class variable as native type (long) and have its getter method returning the corresponding object (Long) and vice versa
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta updated CLOUDSTACK-7289:
Fix Version/s: (was: 4.5.0)
4.6.0
> Bugs seen when declaring a class variable as native type (long) and have its
> getter method returning the corresponding object (Long) and vice versa
> ---
>
> Key: CLOUDSTACK-7289
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7289
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.0
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.6.0
>
>
> Declare a variable as native type (long) and have its getter method
> returning the corresponding object (Long). This is what I fixed with
> CLOUDSTACK-7272.
> Example below. This should be fixed in the entire code base.
> Autoboxing causes NPE or defaults some values. The vice versa should be
> fixed as well meaning declaring hostId as Long and returning as native
> type (long).
> long hostId
> Long getHostId(){
> return hostId;
> }
> Right Implementation (hostId is declared as Long)
> Long hostId;
> Long getHostId(){
> return hostId;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3658) [DB Upgrade] - Deprecate several old object storage tables and columns as a part of 41-42 db upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-3658: Fix Version/s: (was: 4.5.0) 4.6.0 > [DB Upgrade] - Deprecate several old object storage tables and columns as a > part of 41-42 db upgrade > > > Key: CLOUDSTACK-3658 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3658 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Storage Controller >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.6.0 > > Attachments: cloud-after-upgrade.dmp > > > We should deprecate the following db tables and table columes as a part of > 41-42 db upgrade due to recent object storage refactoring: > -Upload > -s3 > -swift > -template_host_ref > -template_s3_ref > -template_swift_ref > -volume_host_ref > -columes (s3_id, swift_id, sechost_id) from snapshots table. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2112) VM went in stopped state after live migration failed while vmscaleup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-2112: Fix Version/s: (was: 4.4.0) Future > VM went in stopped state after live migration failed while vmscaleup > - > > Key: CLOUDSTACK-2112 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2112 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Assignee: Nitin Mehta > Fix For: Future > > Attachments: apilog.log, catalina.out, management-server.log > > > Setup is on top of commit "2057221f4f1fd5afde422b367fc416d4e44275cb " > Vm went in stopped state when migration failed while scaling up . > Step to reproduce > - > 1-Create zone ,pod ,cluster with one host > 2-Deploy vms so that no resource left on host > 3-Add another host to same cluster > 4-Try Scaleup vm from small instance to medium instance > 5-Since no resource available on current host CS will try to live migrate vm > 6-power of target host > Expected > - > vm should remain running state even after scaleup failure > Actual > -- > VM went in stooped state > Snippet of MS log > -- > 2013-04-19 10:57:16,443 DEBUG [cloud.capacity.CapacityManagerImpl] > (HA-Worker-0:work-3) VM state transitted from :Migrating to Stopped with > event: AgentReportStoppedvm's original host id: 1 new host id: null host id > before state transition: 10 > 013-04-19 10:59:17,556 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-19:null) Unable to migrate VM(i-2-33-VM) from > host(57d25f98-9aad-4c3a-9c34-9b663ae0c95f) due to Task failed! Task record: > uuid: 806bc37d-b495-8554-4b60-e3a8218c1fbd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-7590:
---
Description:
Deletion of account marks the account as removed in the database but doesnt
remove the record from the database as shown below:
mysql> select * from account where removed is not null \G
*** 1. row ***
id: 7
account_name: CSRegularVPNClientUser
uuid: 96e06a77-fa96-4e38-b380-023d406d445e
type: 0
domain_id: 1
state: enabled
removed: 2014-09-20 00:33:41
cleanup_needed: 0
network_domain: NULL
default_zone_id: NULL
default: 0
1 row in set (0.00 sec)
mysql>
*If anyone wants to recreate the account with the same name. It fails with the
below exception:*
{noformat}
2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
CSRegularVPNClientUser, accountId: 6 timezone:null
2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
transaction: Time = 16 Name = catalina-exec-11; called by
-TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer] (catalina-exec-11:ctx-bfa880b6
ctx-e82baf36 ctx-1b71100c) unhandled exception executing api command:
[Ljava.lang.String;@5b4cfa82
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
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 $Proxy67.persist(Unknown Source)
at
com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
at
com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
at
com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
com.cloud.user.AccountManagerImpl.createUserAccount(AccountManagerImpl.java:1027)
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:601)
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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framewo
[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197147#comment-14197147
]
Animesh Chaturvedi commented on CLOUDSTACK-7590:
[~rahulrege] can you be more specific in which schema change you are referring
to
> Deletion of Account is not deleting the account from the database
> -
>
> Key: CLOUDSTACK-7590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
> 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: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> Deletion of account marks the account as removed in the database but doesnt
> remove the record from the database as shown below:
>
> mysql> select * from account where removed is not null \G
> *** 1. row ***
> id: 7
>account_name: CSRegularVPNClientUser
>uuid: 96e06a77-fa96-4e38-b380-023d406d445e
>type: 0
> domain_id: 1
> state: enabled
> removed: 2014-09-20 00:33:41
> cleanup_needed: 0
> network_domain: NULL
> default_zone_id: NULL
> default: 0
> 1 row in set (0.00 sec)
> mysql>
> *If anyone wants to recreate the account with the same name. It fails with
> the below exception:*
> {noformat}
> 2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
> CSRegularVPNClientUser, accountId: 6 timezone:null
> 2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
> transaction: Time = 16 Name = catalina-exec-11; called by
> -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
> 2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception
> executing api command: [Ljava.lang.String;@5b4cfa82
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> 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
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> 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 $Proxy67.persist(Unknown Source)
> at
> com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
> at
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
> at
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
> at
> com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> com.cloud.user.AccountManagerImpl.createUserAccount(AccountManagerImpl.java:1027)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
[jira] [Updated] (CLOUDSTACK-7558) [UI]list storage pools under "Migrate" root volume is not listing the primary storage of other clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7558: - Component/s: (was: UI) API > [UI]list storage pools under "Migrate" root volume is not listing the primary > storage of other clusters. > > > Key: CLOUDSTACK-7558 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7558 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Storage Controller >Affects Versions: 4.5.0 > Environment: 1zone,1pod,2 clusters with 2 cluster wide primary > storage pools. >Reporter: manasaveloori >Assignee: Jessica Wang > Fix For: 4.5.0 > > > 1. Clusters C1 with PS1 and cluster PS2both are cluster wide primary > storages. > 2. deployed a VM with data disk under C1. > 3. stopped the VM. > 4. Migrate the root/data volume from PS1 to PS2. > Observation: > under Migration...the drop down is not listing the primary storage of other > clusters. > As this is supported operation the UI should list them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7558) [UI]list storage pools under "Migrate" root volume is not listing the primary storage of other clusters.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang reassigned CLOUDSTACK-7558:
Assignee: Animesh Chaturvedi (was: Jessica Wang)
Animesh,
This is an API issue, not UI issue.
Please assign this issue to an API developer.
=
API developer,
Please fix API response of "listStoragePools&zoneid=xxx" to include primary
storages under other clusters.
(Currently, the API response includes only primary storages under the same
cluster.)
p.s. Here is API call and API response in my attached screenshot:
http://10.215.3.26:8080/client/api?command=listStoragePools&zoneid=703c747a-19ab-417b-bd92-2bdd1720b450&response=json&sessionkey=aR4zci84VtlKHbSL5lhL3ceQZlE%3D&_=1415144054018
{
"liststoragepoolsresponse": {
"count": 2,
"storagepool": [
{
"id": "156766ce-7979-3648-9367-4237533237d3",
"zoneid": "703c747a-19ab-417b-bd92-2bdd1720b450",
"zonename": "jw1",
"podid": "f7197096-593a-480a-934d-71eb27c147f1",
"podname": "jw1-pod",
"name": "alena",
"ipaddress": "10.223.110.232",
"path": "/export/home/jessica/jw1_24hours_E",
"created": "2014-08-14T15:11:08-0800",
"type": "NetworkFilesystem",
"clusterid": "f275f6c2-cfc9-450e-83bb-1fde50937e7c",
"clustername": "jw1-cluster",
"disksizetotal": 11810778316800,
"disksizeallocated": 85899345920,
"tags": "24hoursTag",
"state": "Maintenance",
"scope": "CLUSTER",
"storagecapabilities": {
"VOLUME_SNAPSHOT_QUIESCEVM": "false"
}
},
{
"id": "723fb9fe-634f-3b68-962a-d14cb6eac0a8",
"zoneid": "703c747a-19ab-417b-bd92-2bdd1720b450",
"zonename": "jw1",
"podid": "f7197096-593a-480a-934d-71eb27c147f1",
"podname": "jw1-pod",
"name": "jw1_primary",
"ipaddress": "10.223.110.232",
"path": "/export/home/jessica/jw1_primary",
"created": "2014-08-12T08:59:36-0800",
"type": "NetworkFilesystem",
"clusterid": "f275f6c2-cfc9-450e-83bb-1fde50937e7c",
"clustername": "jw1-cluster",
"disksizetotal": 11810778316800,
"disksizeallocated": 136713338880,
"disksizeused": 6581751611392,
"state": "Up",
"scope": "CLUSTER",
"storagecapabilities": {
"VOLUME_SNAPSHOT_QUIESCEVM": "false"
}
}
]
}
}
> [UI]list storage pools under "Migrate" root volume is not listing the primary
> storage of other clusters.
>
>
> Key: CLOUDSTACK-7558
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7558
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Storage Controller
>Affects Versions: 4.5.0
> Environment: 1zone,1pod,2 clusters with 2 cluster wide primary
> storage pools.
>Reporter: manasaveloori
>Assignee: Animesh Chaturvedi
> Fix For: 4.5.0
>
>
> 1. Clusters C1 with PS1 and cluster PS2both are cluster wide primary
> storages.
> 2. deployed a VM with data disk under C1.
> 3. stopped the VM.
> 4. Migrate the root/data volume from PS1 to PS2.
> Observation:
> under Migration...the drop down is not listing the primary storage of other
> clusters.
> As this is supported operation the UI should list them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7558) [UI]list storage pools under "Migrate" root volume is not listing the primary storage of other clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7558: - Attachment: jessica-2014-11-04.PNG > [UI]list storage pools under "Migrate" root volume is not listing the primary > storage of other clusters. > > > Key: CLOUDSTACK-7558 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7558 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Storage Controller >Affects Versions: 4.5.0 > Environment: 1zone,1pod,2 clusters with 2 cluster wide primary > storage pools. >Reporter: manasaveloori >Assignee: Animesh Chaturvedi > Fix For: 4.5.0 > > Attachments: jessica-2014-11-04.PNG > > > 1. Clusters C1 with PS1 and cluster PS2both are cluster wide primary > storages. > 2. deployed a VM with data disk under C1. > 3. stopped the VM. > 4. Migrate the root/data volume from PS1 to PS2. > Observation: > under Migration...the drop down is not listing the primary storage of other > clusters. > As this is supported operation the UI should list them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6772) [UI]need to change popup message fo Attach volume failure "Unexpected exception"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta resolved CLOUDSTACK-6772.
-
Resolution: Won't Fix
> [UI]need to change popup message fo Attach volume failure "Unexpected
> exception"
> --
>
> Key: CLOUDSTACK-6772
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6772
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.4.0
>Reporter: prashant kumar mishra
>Assignee: Nitin Mehta
>Priority: Minor
> Fix For: 4.5.0
>
> Attachments: management-server.log
>
>
> step to reproduce
> ==
> 1-tried to attach a volume( size> available size on PS)
> 2-Attach volume failed
> 3-UI pop up a message " Unexpected exception"
> Expected
> ===
> we should clearly pop up message like " no suitable primary storage found"
> Logs
>
> 2014-05-27 10:01:51,360 DEBUG [c.c.s.StorageManagerImpl]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Insufficient
> un-allocated capacity on: 1 for volume allocation: [Vol[8|vm=null|DATADISK]]
> since its allocated percentage: 1.6727310608597301 has crossed the allocated
> pool.storage.allocated.capacity.disablethreshold: 0.85, skipping this pool
> 2014-05-27 10:01:51,361 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457)
> ClusterScopeStoragePoolAllocator returning 0 suitable storage pools
> 2014-05-27 10:01:51,364 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457)
> ZoneWideStoragePoolAllocator to find storage pool
> 2014-05-27 10:01:51,372 WARN [o.a.c.e.o.VolumeOrchestrator]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Unable to find
> suitable primary storage when creating volume fifty
> 2014-05-27 10:01:51,381 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Invocation
> exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Unable
> to find suitable primary storage when creating volume fifty
> 2014-05-27 10:01:51,382 INFO [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Rethrow
> exception com.cloud.utils.exception.CloudRuntimeException: Unable to find
> suitable primary storage when creating volume fifty
> 2014-05-27 10:01:51,382 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39) Done with run of VM work
> job: com.cloud.storage.VmWorkAttachVolume for VM 6, job origin: 38
> 2014-05-27 10:01:51,384 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39) Unable to complete
> AsyncJobVO {id:39, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkAttachVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YYfiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAAZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAAg,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7204337877055, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Tue May 27 10:01:50 EDT 2014}, job origin:38
> com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable
> primary storage when creating volume fifty
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:447)
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:734)
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1186)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1054)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2475)
> 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:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerPr
[jira] [Commented] (CLOUDSTACK-6772) [UI]need to change popup message fo Attach volume failure "Unexpected exception"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197199#comment-14197199
]
Nitin Mehta commented on CLOUDSTACK-6772:
-
We can log it but cant say the primary storage since to the end user its not
visible and he cant do anything with it. Only cloud admins sees the primary
storage
> [UI]need to change popup message fo Attach volume failure "Unexpected
> exception"
> --
>
> Key: CLOUDSTACK-6772
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6772
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.4.0
>Reporter: prashant kumar mishra
>Assignee: Nitin Mehta
>Priority: Minor
> Fix For: 4.5.0
>
> Attachments: management-server.log
>
>
> step to reproduce
> ==
> 1-tried to attach a volume( size> available size on PS)
> 2-Attach volume failed
> 3-UI pop up a message " Unexpected exception"
> Expected
> ===
> we should clearly pop up message like " no suitable primary storage found"
> Logs
>
> 2014-05-27 10:01:51,360 DEBUG [c.c.s.StorageManagerImpl]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Insufficient
> un-allocated capacity on: 1 for volume allocation: [Vol[8|vm=null|DATADISK]]
> since its allocated percentage: 1.6727310608597301 has crossed the allocated
> pool.storage.allocated.capacity.disablethreshold: 0.85, skipping this pool
> 2014-05-27 10:01:51,361 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457)
> ClusterScopeStoragePoolAllocator returning 0 suitable storage pools
> 2014-05-27 10:01:51,364 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457)
> ZoneWideStoragePoolAllocator to find storage pool
> 2014-05-27 10:01:51,372 WARN [o.a.c.e.o.VolumeOrchestrator]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Unable to find
> suitable primary storage when creating volume fifty
> 2014-05-27 10:01:51,381 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Invocation
> exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Unable
> to find suitable primary storage when creating volume fifty
> 2014-05-27 10:01:51,382 INFO [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39 ctx-e6180457) Rethrow
> exception com.cloud.utils.exception.CloudRuntimeException: Unable to find
> suitable primary storage when creating volume fifty
> 2014-05-27 10:01:51,382 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39) Done with run of VM work
> job: com.cloud.storage.VmWorkAttachVolume for VM 6, job origin: 38
> 2014-05-27 10:01:51,384 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-1:ctx-bf2f08f1 job-38/job-39) Unable to complete
> AsyncJobVO {id:39, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkAttachVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YYfiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAAZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAAg,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7204337877055, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Tue May 27 10:01:50 EDT 2014}, job origin:38
> com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable
> primary storage when creating volume fifty
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:447)
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:734)
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1186)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1054)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2475)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImp
[jira] [Created] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration
Sheng Yang created CLOUDSTACK-7841: -- Summary: Existed connections are disconnected when update load balancer configuration Key: CLOUDSTACK-7841 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7841 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.5.0 Applying load balancer rules breaks existing connections and causes short outage. That's because our currently logic of handling haproxy reload configuration is not graceful enough, and focused on how to recover from failed newly configuration. There would be a way to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197230#comment-14197230 ] ASF subversion and git services commented on CLOUDSTACK-7841: - Commit 4b3217fe57f2aa4f7e6b967588158c26a7a9634a in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4b3217f ] CLOUDSTACK-7841: Gracefully reload haproxy config The old way would disconnect all the existing connections through haproxy when reload the config. This new way would ensure that all the existing connections would still alive after reload the config. > Existed connections are disconnected when update load balancer configuration > > > Key: CLOUDSTACK-7841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.5.0 > > > Applying load balancer rules breaks existing connections and causes short > outage. > That's because our currently logic of handling haproxy reload configuration > is not graceful enough, and focused on how to recover from failed newly > configuration. > There would be a way to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197232#comment-14197232 ] ASF subversion and git services commented on CLOUDSTACK-7841: - Commit c15ed74f63559dca7692cfcfe695e195c3401454 in cloudstack's branch refs/heads/4.5 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c15ed74 ] CLOUDSTACK-7841: Gracefully reload haproxy config The old way would disconnect all the existing connections through haproxy when reload the config. This new way would ensure that all the existing connections would still alive after reload the config. > Existed connections are disconnected when update load balancer configuration > > > Key: CLOUDSTACK-7841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.5.0 > > > Applying load balancer rules breaks existing connections and causes short > outage. > That's because our currently logic of handling haproxy reload configuration > is not graceful enough, and focused on how to recover from failed newly > configuration. > There would be a way to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197241#comment-14197241 ] Sheng Yang commented on CLOUDSTACK-7841: Verification steps: Positive verification on LB rules: 1. Start two vms in a network. Open port 22 in firewall. Set LB rules for 22 for two vms. 2. Ssh using public IP, then doing ping gateway or other commands which able to continuous monitor the connectivity. 3. Add a new LB rule in the same network. Before fix: the existing connection would be dropped. After fix: the existing connection would always works. Negative verification on LB rules after fix: 1,2. Same as step 1,2 above. 3. Log into VR, run: " netcat -l -p 1 ", which would listen on port 1, and would result in haproxy fail to listen on the port later. 4. Assign LB rule on port 1. It would failed to apply since haproxy won't able to listen on port 1. But the existing connection still works after fix. > Existed connections are disconnected when update load balancer configuration > > > Key: CLOUDSTACK-7841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.5.0 > > > Applying load balancer rules breaks existing connections and causes short > outage. > That's because our currently logic of handling haproxy reload configuration > is not graceful enough, and focused on how to recover from failed newly > configuration. > There would be a way to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-7841. Resolution: Fixed > Existed connections are disconnected when update load balancer configuration > > > Key: CLOUDSTACK-7841 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7841 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.5.0 > > > Applying load balancer rules breaks existing connections and causes short > outage. > That's because our currently logic of handling haproxy reload configuration > is not graceful enough, and focused on how to recover from failed newly > configuration. > There would be a way to improve this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6459) Unable to enable maintenance mode on a Primary storage that crashed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Xu updated CLOUDSTACK-6459:
---
Assignee: Anthony Xu (was: Min Chen)
> Unable to enable maintenance mode on a Primary storage that crashed
> ---
>
> Key: CLOUDSTACK-6459
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6459
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.4.0
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.4.0, 4.5.0
>
> Attachments: kern.zip, management-server.log.2014-04-18.gz,
> mysql_cloudstack_dump.zip
>
>
> Primary storage in my setup got powered off. I am not able to enable
> maintenance mode on this primary storage.
> Enabling maintenance mode on the primary storage fails with the following
> error. It eventually timed out after trying many times
> 2014-04-18 16:43:50,020 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-1:ctx-bd92e323 ctx-7d4c2498) ===END=== 10.214.5.40 -- GET
> command=queryAsyncJobResult&jobId=62f6830a-c409-4449-a9c5-6a35b7b9fbed&response=json&sessionkey=WBpwG%2FryPRNNB1GRuHqam1zbtS8%3D&_=1397865006850
> 2014-04-18 16:43:50,495 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-9:null) SeqA 2-792: Processing Seq 2-792: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-04-18 16:43:50,504 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-9:null) SeqA 2-792: Sending Seq 2-792: { Ans: ,
> MgmtId: 6638073284439, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-04-18 16:43:52,539 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-143:ctx-16ea61bc) Async 600 seconds timeout for task
> com.xensource.xenapi.Task@8aa497e8
> 2014-04-18 16:43:52,563 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-143:ctx-16ea61bc) unable to destroy
> task(com.xensource.xenapi.Task@8aa497e8) on
> host(0d2ea73b-12c0-433c-b1c3-e1f193e68f6e) due to You gave an invalid object
> reference. The object may have recently been deleted. The class parameter
> gives the type of reference given, and the handle parameter echoes the bad
> value given.
> 2014-04-18 16:43:52,564 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-143:ctx-16ea61bc) Catch exception
> com.cloud.utils.exception.CloudRuntimeException when stop VM:i-3-3-DR due to
> com.cloud.utils.exception.CloudRuntimeException: Shutdown VM catch
> HandleInvalid and VM is not in HALTED state
> 2014-04-18 16:43:52,569 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-143:ctx-16ea61bc) 10. The VM i-3-3-DR is in Running state
> 2014-04-18 16:43:52,572 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-143:ctx-16ea61bc) Seq 1-2385781902599520418: Response Received:
> 2014-04-18 16:43:52,573 DEBUG [c.c.a.t.Request]
> (DirectAgent-143:ctx-16ea61bc) Seq 1-2385781902599520418: Processing: { Ans:
> , MgmtId: 6638073284439, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Catch
> exception com.cloud.utils.exception.CloudRuntimeException when stop
> VM:i-3-3-DR due to com.cloud.utils.exception.CloudRuntimeException: Shutdown
> VM catch HandleInvalid and VM is not in HALTED state","wait":0}}] }
> 2014-04-18 16:43:52,576 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Seq 1-2385781902599520418:
> Received: { Ans: , MgmtId: 6638073284439, via: 1, Ver: v1, Flags: 10, {
> StopAnswer } }
> 2014-04-18 16:43:52,591 WARN [c.c.v.VirtualMachineManagerImpl]
> (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Unable to stop vm
> VM[User|i-3-3-DR]
> 2014-04-18 16:43:52,616 DEBUG [c.c.c.CapacityManagerImpl]
> (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) VM state transitted from
> :Stopping to Running with event: OperationFailedvm's original host id: 1 new
> host id: 1 host id before state transition: 1
> 2014-04-18 16:43:52,616 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Invocation exception, caused
> by: com.cloud.utils.exception.CloudRuntimeException: Unable to stop
> VM[User|i-3-3-DR]
> 2014-04-18 16:43:52,617 INFO [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Rethrow exception
> com.cloud.utils.exception.CloudRuntimeException: Unable to stop
> VM[User|i-3-3-DR]
> 2014-04-18 16:43:52,617 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-2:job-30/job-31) Done with
[jira] [Commented] (CLOUDSTACK-6851) ResourceTagResponse does not have "id" field due to which resource level permission cannot be granted to any specific resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197304#comment-14197304 ] Min Chen commented on CLOUDSTACK-6851: -- This enhancement is related to IAM feature, specially writing automated IAM marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in future release. > ResourceTagResponse does not have "id" field due to which resource level > permission cannot be granted to any specific resource > -- > > Key: CLOUDSTACK-6851 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6851 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.4.0 >Reporter: Namita Chaudhari >Assignee: Min Chen > Labels: None > Fix For: Future > > > This enhancement is related to IAM feature, specially writing automated IAM > marvin testcases. Since IAM is disabled in 4.5.0, mark this bug to fix in > future release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7427) Bug in Cloudstack 4.2 Root Admin API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197309#comment-14197309 ] Min Chen commented on CLOUDSTACK-7427: -- This is invalid, accountName and domainId in updateAccountCmd are not necessarily required if the user provided "id" as parameter. > Bug in Cloudstack 4.2 Root Admin API > > > Key: CLOUDSTACK-7427 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7427 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: santhosh >Assignee: Min Chen > Fix For: 4.6.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > There is bug in parameters of updateAccount > http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/updateAccount.html > Fix : accountname and domainid must be true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7427) Bug in Cloudstack 4.2 Root Admin API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7427. -- Resolution: Invalid > Bug in Cloudstack 4.2 Root Admin API > > > Key: CLOUDSTACK-7427 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7427 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: santhosh >Assignee: Min Chen > Fix For: 4.6.0 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > There is bug in parameters of updateAccount > http://cloudstack.apache.org/docs/api/apidocs-4.2/root_admin/updateAccount.html > Fix : accountname and domainid must be true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197612#comment-14197612
]
ASF GitHub Bot commented on CLOUDSTACK-7242:
GitHub user karuturi opened a pull request:
https://github.com/apache/cloudstack/pull/34
CLOUDSTACK-7242: Adding a securing config using configDepo doesnt work
In ConfigurationVo, changed the setter to do the encryption if required
like the getter. Called the setter in constructor as well.
Removed references of encryption check in different places.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/karuturi/cloudstack 4.5
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/34.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #34
commit 2d5451c5ed6688f26edd5bd0a86cf5616ee4729d
Author: Rajani Karuturi
Date: 2014-11-04T12:46:50Z
Fixed CLOUDSTACK-7242: Adding a securing config using configDepo doesnt work
In ConfigurationVo, changed the setter to do the encryption if required
like the getter. Called the setter in constructor as well.
Removed references of encryption check in different places.
commit 0c2dc46bfdc9150ebbc8af6dd8bbf628c4b05c21
Author: Jessica Wang
Date: 2014-11-04T19:33:15Z
CLOUDSTACK-7384: UI > Instances > detailView > change service offering
option > hide it when VM state is Running and hyperviror is LXC.
commit f9060bc6a07560af8fc2fe93037c9ee66f1ca71e
Author: Jessica Wang
Date: 2014-11-04T22:42:29Z
CLOUDSTACK-7383: UI > Instances > detailView > snapshot option > hide this
option when hypervisor is LXC.
commit c52605641381eb4007010e01bbcc596d8c04591a
Author: Sheng Yang
Date: 2014-11-05T00:26:23Z
CLOUDSTACK-7841: Gracefully reload haproxy config
The old way would disconnect all the existing connections through haproxy
when
reload the config.
This new way would ensure that all the existing connections would still
alive
after reload the config.
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197616#comment-14197616
]
ASF GitHub Bot commented on CLOUDSTACK-7242:
Github user karuturi closed the pull request at:
https://github.com/apache/cloudstack/pull/34
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197620#comment-14197620
]
ASF GitHub Bot commented on CLOUDSTACK-7242:
GitHub user karuturi opened a pull request:
https://github.com/apache/cloudstack/pull/35
Fixed CLOUDSTACK-7242: Adding a securing config using configDepo doesnt ...
In ConfigurationVo, changed the setter to do the encryption if required
(like the getter). Called the setter in constructor as well.
Removed references of encryption check in different places.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/karuturi/cloudstack CLOUDSTACK-7242
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/35.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #35
commit 561bf08175edf878f6568641c65f63cabf70d6b8
Author: Rajani Karuturi
Date: 2014-11-04T12:46:50Z
Fixed CLOUDSTACK-7242: Adding a securing config using configDepo doesnt work
In ConfigurationVo, changed the setter to do the encryption if required
like the getter. Called the setter in constructor as well.
Removed references of encryption check in different places.
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197668#comment-14197668
]
ASF subversion and git services commented on CLOUDSTACK-7242:
-
Commit c3e5964dcbbd3b3ff34562aeeb9f8daa154ee7d1 in cloudstack's branch
refs/heads/4.5 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3e5964 ]
Fixed CLOUDSTACK-7242: Adding a securing config using configDepo doesnt work
In ConfigurationVo, changed the setter to do the encryption if required
like the getter. Called the setter in constructor as well.
Removed references of encryption check in different places.
Reviewed-by: Santhosh Edukulla
This closes #35
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi resolved CLOUDSTACK-7242.
-
Resolution: Fixed
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7242) adding a Secure config using the new ConfigDepot and ConfigKey breaks the build when encryption is enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14197696#comment-14197696
]
ASF GitHub Bot commented on CLOUDSTACK-7242:
Github user karuturi closed the pull request at:
https://github.com/apache/cloudstack/pull/35
> adding a Secure config using the new ConfigDepot and ConfigKey breaks the
> build when encryption is enabled
> --
>
> Key: CLOUDSTACK-7242
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt
> if its a secure or hidden field. But, it doesn’t encrypt while adding the
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>@Override
> public String getValue() {
> return (("Hidden".equals(getCategory()) ||
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
> }
> public void setValue(String value) {
> this.value = value;
> }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able
> to introduce any new secure/hidden configs unless you put the encrypted value
> in the db before.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
