date:20141104

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

2014-11-04 Thread Ilia Shakitko (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread Olivier Lemasle (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread Ram Ganesh (JIRA)


 [ 
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

2014-11-04 Thread Thijs Houtenbos (JIRA)

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.

2014-11-04 Thread ASF subversion and git services (JIRA)

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-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=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=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=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

[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

2014-11-04 Thread Koushik Das (JIRA)


 [ 
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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

2014-11-04 Thread Koushik Das (JIRA)


 [ 
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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=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=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=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

[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=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=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=prepareHostForMaintenanceid=f68de59b-3d28-452f-b82b-86fca83f6f16response=jsonsessionkey=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: v1, Flags: 110, 
 [{com.cloud.agent.api.MaintainAnswer:{willMigrate:true,result:true,wait:0}}]
  }
 2014-08-18 19:16:00,713 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-3:ctx-5d223414 job-690

[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

2014-11-04 Thread Rajani Karuturi (JIRA)


 [ 
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

2014-11-04 Thread Joris van Lieshout (JIRA)

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

[jira] [Commented] (CLOUDSTACK-7839) Unable to live migrate an instance to another host in a cluster from which the template has been deleted

2014-11-04 Thread Joris van Lieshout (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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(ApiServer.java:531)
 at

[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-tabpanelfocusedCommentId=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.

2014-11-04 Thread frank zhang (JIRA)


 [ 
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-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


 [ 
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-tabpanelfocusedCommentId=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

2014-11-04 Thread Chandan Purushothama (JIRA)


 [ 
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.

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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

2014-11-04 Thread Chandan Purushothama (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 remaining commands...
 2013-12-10 20:57:36,678 INFO  [cloud.agent.Agent]

[jira] [Closed] (CLOUDSTACK-7769) [Automation] Fix the script test_ssvm.py - SSVM Gateway Assertion is not valid in EIP-ELB case

2014-11-04 Thread Chandan Purushothama (JIRA)


 [ 
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.

2014-11-04 Thread ASF subversion and git services (JIRA)


 [ 
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-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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:
noformat
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

[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-tabpanelfocusedCommentId=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:
 noformat
 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

[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 listStoragePoolszoneid=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=listStoragePoolszoneid=703c747a-19ab-417b-bd92-2bdd1720b450response=jsonsessionkey=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(VmWorkJobHandlerProxy.java:107)
 at

[jira] [Commented] (CLOUDSTACK-6772) [UI]need to change popup message fo Attach volume failure Unexpected exception

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at

[jira] [Created] (CLOUDSTACK-7841) Existed connections are disconnected when update load balancer configuration

2014-11-04 Thread Sheng Yang (JIRA)

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-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

2014-11-04 Thread Sheng Yang (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 public_ip -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

2014-11-04 Thread Sheng Yang (JIRA)


 [ 
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

2014-11-04 Thread Anthony Xu (JIRA)


 [ 
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=queryAsyncJobResultjobId=62f6830a-c409-4449-a9c5-6a35b7b9fbedresponse=jsonsessionkey=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 run of VM work job: 
 com.cloud.vm.VmWorkStop for VM 3, job origin: 30
 2014-04-18 16:43:52,617 ERROR

[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 rajanikarut...@gmail.com
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 jessicaw...@apache.org
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 jessicaw...@apache.org
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 sheng.y...@citrix.com
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-tabpanelfocusedCommentId=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

2014-11-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 rajanikarut...@gmail.com
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-tabpanelfocusedCommentId=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

2014-11-04 Thread Rajani Karuturi (JIRA)


 [ 
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