date:20140910


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7378.
--

 [rhel7] usage server installation is failing with java7 dependency
 --

 Key: CLOUDSTACK-7378
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7378
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Damodar Reddy T
Priority: Blocker
 Fix For: 4.5.0


 usage server installation is failing with java7 dependency on rhel 7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal reopened CLOUDSTACK-7316:


verified on EAP1 build. Problem still exists

 hitting java.lang.reflect.InvocationTargetException while starting usage 
 server
 ---

 Key: CLOUDSTACK-7316
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Damodar Reddy T
Priority: Blocker
 Fix For: 4.5.0

 Attachments: usage.tar.gz


 Repro steps:
 Install MS and usage server
 Start MS and usage server
 Bug:
 Usage server will stop after starting
 usage log shows :
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
 Caused by: org.springframework.beans.factory.BeanCreationException: Error 
 creating bean with name 'vmDiskUsageParser': Injection of autowired 
 dependencies failed; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Could not autowire 
 field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
 at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
 at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
 at 
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
 at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:83)
 at com.cloud.usage.UsageServer.start(UsageServer.java:57)
 ... 5 more
 Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
 autowire field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:514)



--
This message was sent by Atlassian JIRA

[jira] [Updated] (CLOUDSTACK-7518) SSVM stop/start is not initiating the download for Partially downloaded ISO's


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada updated CLOUDSTACK-7518:
-
Attachment: ssvmlogs.zip

 SSVM stop/start is not initiating the download for Partially downloaded ISO's 
 --

 Key: CLOUDSTACK-7518
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7518
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template, XenServer
Affects Versions: 4.5.0
Reporter: Sailaja Mada
Priority: Critical
 Fix For: 4.5.0

 Attachments: isologs.zip, ssvmlogs.zip


 Setup:
 1. Configure Adv Zone with XS 6.5 
 2.  Register Windows 2012 ISO , Waited for it to download 20% 
 3. Stop SSVM 
 4. ISO details gets the status as SSVM Agent  disconnected
 5. Start SSVM 
 Observation: 
 SSVM stop/start is not initiating the download for Partially downloaded 
 templates/ISO's 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6634) DOC: update the ldap section of the admin guide

2014-09-10 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128144#comment-14128144
 ] 

ASF GitHub Bot commented on CLOUDSTACK-6634:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack-docs-admin/pull/20


 DOC: update the ldap section of the admin guide
 ---

 Key: CLOUDSTACK-6634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6634
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0
Reporter: Rajani Karuturi
Assignee: Rajani Karuturi
  Labels: ldap
 Fix For: 4.4.0


 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.3/accounts.html#using-an-ldap-server-for-user-authentication
 there are changes/enhancements in the way ldap server is configured since 4.3 
 documentation needs to be updated with the latest info.
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/LDAP+user+provisioning



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7525) UI: Edit SecurityGroup rules tags

2014-09-10 Thread Ilia Shakitko (JIRA)

Ilia Shakitko created CLOUDSTACK-7525:
-

 Summary: UI: Edit SecurityGroup rules tags
 Key: CLOUDSTACK-7525
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7525
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Ilia Shakitko
Priority: Minor
 Fix For: 4.5.0


Some time back tagging was added for SecurityGroup rules to the API, but it's 
not available via UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128206#comment-14128206
]

Brenn Oosterbaan commented on CLOUDSTACK-7184:
--

I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd
suggest that possibly CS be a little more thorough before deciding a VM is
down...maybe via channels other than the agent/VR?

John is right on the money here. Although the patch comitted by Daan does give
the possibility to specify a check interval for the Xen storage heartbeat
script (instead of using the default of 5 seconds) it is not the root cause of
this issue.

There are two mechanisms at work here. The xen heartbeat script which checks if
the storage is reachable on a specific hypervisors, and Cloudstack which
determines if a hypervisor is up or not.

When we set the Xen heartbeat interval to 180 seconds we basicly said: it's ok
for vm's living on a hypervisor to 'hang' for 180 seconds in case of storage
fail-overs or other issues.
Cloudstack has it's own checking mechanisms to determine if a hypervisor is
down or not. Those checks are not in line with the xen heartbeat interval.
Which means that even though we decided 180 seconds of unavailability is fine,
Cloudstack tries to connect to the hypervisor 3 times (in ~30 seconds) and then
decides it is down and starts the vm's on another hypervisor.
That is the issue/bug Remi meant to identify when filing this ticket.

I personally feel there should be two additional global options:
hypervisor.heartbeat.interval and hypervisor.heartbeat.max_retry.
This would allow us to decide to (for instance) set the interval to 15 seconds
and the max_retry to 12. Which would then add up to 180 seconds as well.
Since the default heartbeat timeout is 60 seconds I would set the defaults for
these to a combination which allows for 60 seconds as well. Otherwise you will
never be sure the hypervisor it self has actually rebooted and thus VM
corruption could still take place.

regards,

Brenn

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

Key: CLOUDSTACK-7184
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Blocker

Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did
discover this and marked the host as down, and immediately started HA. Just
18 seconds later the hypervisor returned and we ended up with 5 vm's that
were running on two hypervisors at the same time.
This, of course, resulted in file system corruption and the loss of the vm's.
One side of the story is why XenServer allowed this to happen (will not
bother you with this one). The CloudStack side of the story: HA should only
start after at least xen.heartbeat.interval seconds. If the host is down long
enough, the Xen heartbeat script will fence the hypervisor and prevent
corruption. If it is not down long enough, nothing should happen.
Logs (short):
2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
.
2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl]
(AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on
the VMs
.
2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager
Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event =
AgentDisconnected, Host id = 505, name = mccpvmXX]
cs marks host down: 2014-07-25 05:03:31,920
cs marks host up: 2014-07-25 05:03:49,655

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128206#comment-14128206
]

Brenn Oosterbaan edited comment on CLOUDSTACK-7184 at 9/10/14 8:09 AM:
---

There are two mechanisms at work here. The xen heartbeat script which checks if
the storage is reachable on a specific hypervisors, and Cloudstack which
determines if a hypervisor is up or not.

When we set the Xen heartbeat interval to 180 seconds we basicly said: it's ok
for vm's living on a hypervisor to 'hang' for 180 seconds in case of storage
fail-overs or other issues.
Cloudstack has its own checking mechanisms to determine if a hypervisor is down
or not. Those checks are not in line with the xen heartbeat interval. Which
means that even though we decided 180 seconds of unavailability is fine,
Cloudstack tries to connect to the hypervisor 3 times (in ~30 seconds) and then
decides it is down and starts the vm's on another hypervisor.
That is the issue/bug Remi meant to identify when filing this ticket.

I personally feel there should be two additional options:
hypervisor.heartbeat.interval and hypervisor.heartbeat.max_retry.
This would allow us to decide to (for instance) set the interval to 15 seconds
and the max_retry to 12. Which would then add up to 180 seconds as well.
Since the default heartbeat timeout is 60 seconds I would set the defaults for
these to a combination which allows for 60 seconds as well. Otherwise you will
never be sure the hypervisor it self has actually rebooted and thus VM
corruption could still take place.

regards,

Brenn

was (Author: boosterb...@schubergphilis.com):
I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd
suggest that possibly CS be a little more thorough before deciding a VM is
down...maybe via channels other than the agent/VR?

There are two mechanisms at work here. The xen heartbeat script which checks if
the storage is reachable on a specific hypervisors, and Cloudstack which
determines if a hypervisor is up or not.

regards,

Brenn

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did
discover this and marked the host as down, and immediately started HA.

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128217#comment-14128217
]

Brenn Oosterbaan commented on CLOUDSTACK-7184:
--

Implementing the solution above looks like the fastest/easiest fix to me.

Ideally you would want a second heartbeat script on the hypervisor as well. One
which checks if Cloudstack has been able to communicate with the hypervisor,
and if not fences the hypervisor using the same interval and retry counts as
Cloudstack.
This would allow us to set different timeouts for different scenario's without
the possibility of corrupted VM's:
- If the storage is unreachable but the hypervisor is up and running - wait
until storage timeout value is reached and reboot.
- If the hypervisor has crashed OR the networking stack for that hypervisor is
stuck/unreachable - wait until the hypervisor max retry value is met, HA the
vm's and reboot the hypervisor.

That way we could decide to set the hypervisor.heartbeat.interval to 5 and the
hypervisor.heartbeat.max_retry to 6 and the storage timeout to 180. Which would
effectively say: if storage is down wait 180 seconds, if something else
happened only wait 30 seconds.

But this should probably be a feature request.

regards,

Brenn

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada updated CLOUDSTACK-7526:
-
Attachment: screenshot-1.png

 [UI]Incorrect Field value  with Template/ISO details  page while adding 
 Tags(Key and Value) (label.add)
 ---

 Key: CLOUDSTACK-7526
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526
 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: Sailaja Mada
 Fix For: 4.5.0

 Attachments: screenshot-1.png


 Steps:
 1.  Access Management Server UI 
 2. Go to Templates = Details of any of the template 
 Observation: 
 Observed Incorrect Field value  with Template/ISO details  page while adding 
 Tags(Key and Value) (label.add)
 Attached screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128217#comment-14128217
]

Brenn Oosterbaan edited comment on CLOUDSTACK-7184 at 9/10/14 8:25 AM:
---

Implementing the solution above looks like the fastest/easiest fix to me.

Ideally you would want a second heartbeat script on the hypervisor. One which
checks if Cloudstack has been able to communicate with the hypervisor, and if
not fences the hypervisor using the same interval and retry counts as
Cloudstack.
This would allow us to set different timeouts for different scenario's without
the possibility of corrupted VM's:
- If the storage is unreachable but the hypervisor is up and running - wait
until storage timeout value is reached and reboot.
- If the hypervisor has crashed OR the networking stack for that hypervisor is
stuck/unreachable - wait until the hypervisor max retry value is met, HA the
vm's and reboot the hypervisor.

But this should probably be a feature request.

regards,

Brenn

was (Author: boosterb...@schubergphilis.com):
Implementing the solution above looks like the fastest/easiest fix to me.

But this should probably be a feature request.

regards,

Brenn

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada updated CLOUDSTACK-7526:
-
Fix Version/s: 4.5.0

 [UI]Incorrect Field value  with Template/ISO details  page while adding 
 Tags(Key and Value) (label.add)
 ---

 Key: CLOUDSTACK-7526
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526
 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: Sailaja Mada
 Fix For: 4.5.0

 Attachments: screenshot-1.png


 Steps:
 1.  Access Management Server UI 
 2. Go to Templates = Details of any of the template 
 Observation: 
 Observed Incorrect Field value  with Template/ISO details  page while adding 
 Tags(Key and Value) (label.add)
 Attached screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO details page while adding Tags(Key and Value) (label.add)

Sailaja Mada created CLOUDSTACK-7526:


 Summary: [UI]Incorrect Field value  with Template/ISO details  
page while adding Tags(Key and Value) (label.add)
 Key: CLOUDSTACK-7526
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526
 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: Sailaja Mada


Steps:

1.  Access Management Server UI 
2. Go to Templates = Details of any of the template 

Observation: 
Observed Incorrect Field value  with Template/ISO details  page while adding 
Tags(Key and Value) (label.add)

Attached screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO/Network/Instance details page while adding Tags(Key and Value) (label.add)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada updated CLOUDSTACK-7526:
-
Summary: [UI]Incorrect Field value  with Template/ISO/Network/Instance 
details  page while adding Tags(Key and Value) (label.add)  (was: [UI]Incorrect 
Field value  with Template/ISO details  page while adding Tags(Key and Value) 
(label.add))

 [UI]Incorrect Field value  with Template/ISO/Network/Instance details  page 
 while adding Tags(Key and Value) (label.add)
 

 Key: CLOUDSTACK-7526
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526
 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: Sailaja Mada
 Fix For: 4.5.0

 Attachments: screenshot-1.png


 Steps:
 1.  Access Management Server UI 
 2. Go to Templates = Details of any of the template 
 Observation: 
 Observed Incorrect Field value  with Template/ISO details  page while adding 
 Tags(Key and Value) (label.add)
 Attached screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7526) [UI]Incorrect Field value with Template/ISO/Network/Instance details page while adding Tags(Key and Value) (label.add)

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada updated CLOUDSTACK-7526:
-
Description: 
Steps:

1.  Access Management Server UI 
2. Go to Templates = Details of any of the template 

Observation: 
Observed Incorrect Field value with Template/ISO/Network/Instance details page 
while adding Tags(Key and Value) (label.add)

Attached screen

  was:
Steps:

1.  Access Management Server UI 
2. Go to Templates = Details of any of the template 

Observation: 
Observed Incorrect Field value  with Template/ISO details  page while adding 
Tags(Key and Value) (label.add)

Attached screen


 [UI]Incorrect Field value  with Template/ISO/Network/Instance details  page 
 while adding Tags(Key and Value) (label.add)
 

 Key: CLOUDSTACK-7526
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7526
 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: Sailaja Mada
 Fix For: 4.5.0

 Attachments: screenshot-1.png


 Steps:
 1.  Access Management Server UI 
 2. Go to Templates = Details of any of the template 
 Observation: 
 Observed Incorrect Field value with Template/ISO/Network/Instance details 
 page while adding Tags(Key and Value) (label.add)
 Attached screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7517) FTP modules are not loaded in VR


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128229#comment-14128229
 ] 

ASF subversion and git services commented on CLOUDSTACK-7517:
-

Commit b4f03a1339c67438a2a9cf94dd81b98cdfb458b9 in cloudstack's branch 
refs/heads/master from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b4f03a1 ]

CLOUDSTACK-7517: loading ftp modules in VR


 FTP modules are not loaded in VR
 

 Key: CLOUDSTACK-7517
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7517
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.5.0


 To have Active FTP working in isolated networks VRs need the have the 
 following modules loaded
 modprobe nf_nat_ftp
 root@r-7-QA:~# lsmod | grep ftp
 root@r-7-QA:~# modprobe nt_nat_ftp
 FATAL: Module nt_nat_ftp not found.
 root@r-7-QA:~# modprobe nf_nat_ftp
 root@r-7-QA:~# lsmod | grep ftp
 nf_nat_ftp 12420  0 
 nf_conntrack_ftp   12533  1 nf_nat_ftp
 nf_nat 17924  2 nf_nat_ftp,iptable_nat
 nf_conntrack   43121  7 
 nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7517) FTP modules are not loaded in VR


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-7517.
---
Resolution: Fixed

 FTP modules are not loaded in VR
 

 Key: CLOUDSTACK-7517
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7517
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.5.0


 To have Active FTP working in isolated networks VRs need the have the 
 following modules loaded
 modprobe nf_nat_ftp
 root@r-7-QA:~# lsmod | grep ftp
 root@r-7-QA:~# modprobe nt_nat_ftp
 FATAL: Module nt_nat_ftp not found.
 root@r-7-QA:~# modprobe nf_nat_ftp
 root@r-7-QA:~# lsmod | grep ftp
 nf_nat_ftp 12420  0 
 nf_conntrack_ftp   12533  1 nf_nat_ftp
 nf_nat 17924  2 nf_nat_ftp,iptable_nat
 nf_conntrack   43121  7 
 nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7517) FTP modules are not loaded in VR

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128231#comment-14128231
 ] 

Jayapal Reddy commented on CLOUDSTACK-7517:
---

Problem:
---
FTP inbound service is not working in isolated networks.
Created ingress rules for ftp on public ip and accessing ftp service in VM from 
the public network got failed.

Root cause analysis:
-
ftp connection tracking modules are missed in VR. Due to which the ftp data 
connections are failing.

Proposed solution:
---
loading nf_nat_ftp module in VR using the modprobe command.
nf_nat_ftp, nf_conntrack_ftp modules got loaded.

root@r-7-QA:~# lsmod | grep ftp
root@r-7-QA:~# modprobe nf_nat_ftp
root@r-7-QA:~# lsmod | grep ftp
nf_nat_ftp 12420  0 
nf_conntrack_ftp   12533  1 nf_nat_ftp
nf_nat 17924  2 nf_nat_ftp,iptable_nat
nf_conntrack   43121  7 
nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark
root@r-7-QA:~#


Verification steps:
--
1.  In isolated network enable static nat for VM1 and open firewall port for 
20-21

2. 
a. In VM1 install  ftp server.
   
http://ostechnix.wordpress.com/2013/12/15/setup-ftp-server-step-by-step-in-centos-6-x-rhel-6-x-scientific-linux-6-x/
b. stop iptables on the User VM
c. add a new file in ftp sever path. ex: /var/ftp/pub/test.txt

3. verify in VR for modules loaded or not, refer commands in proposed solution 
section
4. Now connect to ftp server from public side and do file transfer.
   Use both cmd line and browser for connecting.

#cmdline:

JayMac:~ jayapalreddy$ ftp 10.147.52.115
Connected to 10.147.52.115.
220 (vsFTPd 2.0.5)
Name (10.147.52.115:jayapalreddy): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp ls
229 Entering Extended Passive Mode (|||20997|)
150 Here comes the directory listing.
drwxr-xr-x2 004096 Sep 10 03:52 pub
226 Directory send OK.
ftp
ftp pwd
Remote directory: /
ftp cd pub
250 Directory successfully changed.
ftp ls
229 Entering Extended Passive Mode (|||5789|)
150 Here comes the directory listing.
-rw-r--r--1 00  35 Sep 10 03:52 test.txt
226 Directory send OK.
ftp get test.txt
local: test.txt remote: test.txt
229 Entering Extended Passive Mode (|||21044|)
150 Opening BINARY mode data connection for test.txt (35 bytes).
100% 
|*|
35   12.43 KiB/s00:00 ETA
226 File send OK.
35 bytes received in 00:00 (1.28 KiB/s)
ftp

#From web browser:
ftp://10.147.52.115/pub/test.txt




 FTP modules are not loaded in VR
 

 Key: CLOUDSTACK-7517
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7517
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.5.0


 To have Active FTP working in isolated networks VRs need the have the 
 following modules loaded
 modprobe nf_nat_ftp
 root@r-7-QA:~# lsmod | grep ftp
 root@r-7-QA:~# modprobe nt_nat_ftp
 FATAL: Module nt_nat_ftp not found.
 root@r-7-QA:~# modprobe nf_nat_ftp
 root@r-7-QA:~# lsmod | grep ftp
 nf_nat_ftp 12420  0 
 nf_conntrack_ftp   12533  1 nf_nat_ftp
 nf_nat 17924  2 nf_nat_ftp,iptable_nat
 nf_conntrack   43121  7 
 nf_conntrack_ftp,nf_nat_ftp,nf_conntrack_ipv4,nf_nat,iptable_nat,xt_state,xt_connmark



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7519) [Task] Use bound/unbound menthods instead of calling API directly from test case


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128239#comment-14128239
 ] 

ASF subversion and git services commented on CLOUDSTACK-7519:
-

Commit 81d5dd9bcda185ff83820f8dd6233cf80f8efaed in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81d5dd9 ]

CLOUDSTACK-7519: Using bound/unbound methods instead of directly calling API 
methods from test case

Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org


 [Task] Use bound/unbound menthods instead of calling API directly from test 
 case
 

 Key: CLOUDSTACK-7519
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7519
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
  Labels: automation
 Fix For: 4.5.0


 test_templates.py file has many instances where direct APIs are called from 
 the test case. Instead we have the methods in base library that can be used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

2014-09-10 Thread Daan Hoogland (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128240#comment-14128240
 ] 

Daan Hoogland commented on CLOUDSTACK-7184:
---

Brenn's idea seems sane to me, I will add the config items for the 
ping-check/fencing as well

 HA should wait for at least 'xen.heartbeat.interval' sec before starting HA 
 on vm's when host is marked down
 

 Key: CLOUDSTACK-7184
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Blocker

 Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did 
 discover this and marked the host as down, and immediately started HA. Just 
 18 seconds later the hypervisor returned and we ended up with 5 vm's that 
 were running on two hypervisors at the same time. 
 This, of course, resulted in file system corruption and the loss of the vm's. 
 One side of the story is why XenServer allowed this to happen (will not 
 bother you with this one). The CloudStack side of the story: HA should only 
 start after at least xen.heartbeat.interval seconds. If the host is down long 
 enough, the Xen heartbeat script will fence the hypervisor and prevent 
 corruption. If it is not down long enough, nothing should happen.
 Logs (short):
 2014-07-25 05:03:28,596 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
 .
 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX.  Starting HA on 
 the VMs
 .
 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager 
 Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 505, name = mccpvmXX]
 cs marks host down: 2014-07-25  05:03:31,920
 cs marks host up: 2014-07-25  05:03:49,655



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128253#comment-14128253
]

Remi Bergsma commented on CLOUDSTACK-7184:
--

+1!

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)

Remi Bergsma created CLOUDSTACK-7527:


 Summary: XenServer heartbeat-script: make it reboot faster (when 
fencing)
 Key: CLOUDSTACK-7527
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.3.0, 4.4.0
Reporter: Remi Bergsma
Priority: Minor


xenheartbeat.sh:

I've seen the 'reboot' command hang, even though it has the force option 
specified (last line of the script). Wouldn't it be better to invoke it like 
this:

echo b  /proc/sysrq-trigger

Tested it, starts boot sequence immediately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128266#comment-14128266
 ] 

Remi Bergsma edited comment on CLOUDSTACK-7184 at 9/10/14 9:34 AM:
---

@[~dahn] Now that you're working on this script, please also look at 
CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx!



was (Author: remibergsma):
[~dahn] Now that you're working on this script, please also look at 
CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx!


 HA should wait for at least 'xen.heartbeat.interval' sec before starting HA 
 on vm's when host is marked down
 

 Key: CLOUDSTACK-7184
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Blocker

 Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did 
 discover this and marked the host as down, and immediately started HA. Just 
 18 seconds later the hypervisor returned and we ended up with 5 vm's that 
 were running on two hypervisors at the same time. 
 This, of course, resulted in file system corruption and the loss of the vm's. 
 One side of the story is why XenServer allowed this to happen (will not 
 bother you with this one). The CloudStack side of the story: HA should only 
 start after at least xen.heartbeat.interval seconds. If the host is down long 
 enough, the Xen heartbeat script will fence the hypervisor and prevent 
 corruption. If it is not down long enough, nothing should happen.
 Logs (short):
 2014-07-25 05:03:28,596 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
 .
 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX.  Starting HA on 
 the VMs
 .
 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager 
 Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 505, name = mccpvmXX]
 cs marks host down: 2014-07-25  05:03:31,920
 cs marks host up: 2014-07-25  05:03:49,655



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128266#comment-14128266
 ] 

Remi Bergsma commented on CLOUDSTACK-7184:
--

[~dahn] Now that you're working on this script, please also look at 
CLOUDSTACK-7527 (https://issues.apache.org/jira/browse/CLOUDSTACK-7527). Thx!


 HA should wait for at least 'xen.heartbeat.interval' sec before starting HA 
 on vm's when host is marked down
 

 Key: CLOUDSTACK-7184
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Blocker

 Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did 
 discover this and marked the host as down, and immediately started HA. Just 
 18 seconds later the hypervisor returned and we ended up with 5 vm's that 
 were running on two hypervisors at the same time. 
 This, of course, resulted in file system corruption and the loss of the vm's. 
 One side of the story is why XenServer allowed this to happen (will not 
 bother you with this one). The CloudStack side of the story: HA should only 
 start after at least xen.heartbeat.interval seconds. If the host is down long 
 enough, the Xen heartbeat script will fence the hypervisor and prevent 
 corruption. If it is not down long enough, nothing should happen.
 Logs (short):
 2014-07-25 05:03:28,596 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
 .
 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX.  Starting HA on 
 the VMs
 .
 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager 
 Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 505, name = mccpvmXX]
 cs marks host down: 2014-07-25  05:03:31,920
 cs marks host up: 2014-07-25  05:03:49,655



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error

2014-09-10 Thread ASF subversion and git services (JIRA)

Rohit Yadav created CLOUDSTACK-7528:
---

 Summary: When AlertManager fails to sendAlert it does not log the 
actual issue/error
 Key: CLOUDSTACK-7528
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


AlertManager has a sendAlert method, the impls try to send emailAlerts but if 
they fail they log it as warning the subject/error but don't log the actual 
error. This message in logs is useless for users/admins as we tell them that 
there is an issue but don't share with them at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128267#comment-14128267
 ] 

ASF subversion and git services commented on CLOUDSTACK-7528:
-

Commit 885c02dbd8b40d654f4a84fca8474ff88bc7ca5e in cloudstack's branch 
refs/heads/4.3 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=885c02d ]

CLOUDSTACK-7528: More verbose logging when sending alert fails

When sendAlert is called on an AlertManager impl, if it fails it logs that
something was wrong but does not log the body of the issue/error. This means
we tell the user/admin that there was an issue but don't share the issue
with them at all as the email alert fail (or that they were not initialized).

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 When AlertManager fails to sendAlert it does not log the actual issue/error
 ---

 Key: CLOUDSTACK-7528
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 AlertManager has a sendAlert method, the impls try to send emailAlerts but if 
 they fail they log it as warning the subject/error but don't log the actual 
 error. This message in logs is useless for users/admins as we tell them that 
 there is an issue but don't share with them at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128276#comment-14128276
 ] 

ASF subversion and git services commented on CLOUDSTACK-7528:
-

Commit 91fd8d7cd5d5a83bf75f5f2972ad2eb2a4a07694 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=91fd8d7 ]

CLOUDSTACK-7528: More verbose logging when sending alert fails

When sendAlert is called on an AlertManager impl, if it fails it logs that
something was wrong but does not log the body of the issue/error. This means
we tell the user/admin that there was an issue but don't share the issue
with them at all as the email alert fail (or that they were not initialized).

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
(cherry picked from commit 885c02dbd8b40d654f4a84fca8474ff88bc7ca5e)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

Conflicts:
server/src/com/cloud/alert/AlertManagerImpl.java
usage/src/com/cloud/usage/UsageAlertManagerImpl.java


 When AlertManager fails to sendAlert it does not log the actual issue/error
 ---

 Key: CLOUDSTACK-7528
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 AlertManager has a sendAlert method, the impls try to send emailAlerts but if 
 they fail they log it as warning the subject/error but don't log the actual 
 error. This message in logs is useless for users/admins as we tell them that 
 there is an issue but don't share with them at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)

2014-09-10 Thread Daan Hoogland (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daan Hoogland reassigned CLOUDSTACK-7527:
-

Assignee: Daan Hoogland

 XenServer heartbeat-script: make it reboot faster (when fencing)
 

 Key: CLOUDSTACK-7527
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.3.0, 4.4.0
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Minor

 xenheartbeat.sh:
 I've seen the 'reboot' command hang, even though it has the force option 
 specified (last line of the script). Wouldn't it be better to invoke it like 
 this:
 echo b  /proc/sysrq-trigger
 Tested it, starts boot sequence immediately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7434) [Automation] Fix the script test_custom_hostname.py - Internal name comparision appears to be wrong


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye resolved CLOUDSTACK-7434.

Resolution: Fixed

 [Automation] Fix the script test_custom_hostname.py - Internal name 
 comparision appears to be wrong
 -

 Key: CLOUDSTACK-7434
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7434
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 
 Error Log from the client results info:
 
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.69
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=YuaraAK9l9g2KJCAw3APnrD2aNpVmhAesCvWFxlDvGCb0NcARH_sKQxfRM6WF-SCAxikI8awlxCrmw010lUFzgresponse=jsoncommand=listVirtualMachinessignature=J07ySQE7LwJA%2FYsOK4ouiEPsM7Y%3Did=6548a12c-b999-495b-83bc-b928dcee99eblistall=True
  HTTP/1.1 200 1645
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG: 
 Response : [{domain : u'ROOT', domainid : 
 u'56ab18f0-2b4d-11e4-89bd-1e5d0e053e75', haenable : False, templatename : 
 u'CentOS 5.6(64-bit) no GUI (XenServer)', securitygroup : [], zoneid : 
 u'eb811e7d-59d4-4c72-a965-80d9e30572d1', cpunumber : 1, ostypeid : 142, 
 passwordenabled : False, instancename : u'i-220-406-VM', id : 
 u'6548a12c-b999-495b-83bc-b928dcee99eb', hostname : u'cl09-B-02', displayvm : 
 True, state : u'Running', guestosid : 
 u'56bf8060-2b4d-11e4-89bd-1e5d0e053e75', details : {hypervisortoolsversion : 
 u'xenserver56'}, memory : 128, serviceofferingid : 
 u'27fc8179-da86-419e-99dd-f438e7b91c63', zonename : u'XenRT-Zone-0', 
 isdynamicallyscalable : True, displayname : u'TestVM', tags : [], nic : 
 [{networkid : u'435fb179-7868-48bd-bfb7-0efa86ee93ef', macaddress : 
 u'02:00:56:8b:00:01', isolationuri : u'vlan://3074', type : u'Isolated', 
 broadcasturi : u'vlan://3074', traffictype : u'Guest', netmask : 
 u'255.255.255.0', ipaddress : u'192.168.200.171', id : 
 u'95c36dd9-31e7-4be1-899b-20d5a36bf322', networkname : 
 u'test-TestInstanceNameFlagTrue-test_01_custom_hostname_instancename_false-AWTN42-network',
  gateway : u'192.168.200.1', isdefault : True}], cpuspeed : 100, templateid : 
 u'56af8f20-2b4d-11e4-89bd-1e5d0e053e75', affinitygroup : [], account : 
 u'test-TestInstanceNameFlagTrue-test_01_custom_hostname_instancename_false-AWTN42',
  hostid : u'1065d9b2-260a-4642-bffe-b2523db3d798', name : 
 u'VM-6548a12c-b999-495b-83bc-b928dcee99eb', created : 
 u'2014-08-24T09:17:35+', hypervisor : u'XenServer', rootdevicetype : 
 u'ROOT', rootdeviceid : 0, serviceofferingname : u'Tiny Instance', 
 templatedisplaytext : u'CentOS 5.6(64-bit) no GUI (XenServer)'}]
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG: 
 vm.displayname: TestVM, original: TestVM
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG: 
 select id from account where uuid = 'd7313bc7-14ce-4df1-8949-f70c542e98a4';
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG: 
 select id from vm_instance where uuid = 
 '6548a12c-b999-495b-83bc-b928dcee99eb';
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG: 
 Query result: 406
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): DEBUG: 
 Internal name: i-220-406-TestVM
 test_01_user_provided_hostname 
 (integration.component.test_custom_hostname.TestInstanceNameFlagTrue): 
 CRITICAL: FAILED: test_01_user_provided_hostname: ['Traceback (most recent 
 call last):\n', '  File /usr/lib/python2.7/unittest/case.py, line 332, in 
 run\ntestMethod()\n', '  File 
 /root/cloudstack/test/integration/component/test_custom_hostname.py, line 
 289, in test_01_user_provided_hostname\nVM internal name should match 
 with that of the format\n', '  File /usr/lib/python2.7/unittest/case.py, 
 line 516, in assertEqual\nassertion_func(first, second, msg=msg)\n', '  
 File /usr/lib/python2.7/unittest/case.py, line 927, in 
 assertMultiLineEqual\nself.fail(self._formatMessage(msg, 
 standardMsg))\n', '  File /usr/lib/python2.7/unittest/case.py, line 413, in 
 fail\nraise self.failureException(msg)\n', 'AssertionError: VM internal 
 name should match with that of the format\n']

[jira] [Resolved] (CLOUDSTACK-7519) [Task] Use bound/unbound menthods instead of calling API directly from test case


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye resolved CLOUDSTACK-7519.

Resolution: Fixed

 [Task] Use bound/unbound menthods instead of calling API directly from test 
 case
 

 Key: CLOUDSTACK-7519
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7519
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
  Labels: automation
 Fix For: 4.5.0


 test_templates.py file has many instances where direct APIs are called from 
 the test case. Instead we have the methods in base library that can be used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7516) test_snapshots.py - VM Deploy failed because the account was using template belonging to different account to deploy the instance

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye updated CLOUDSTACK-7516:
---
Status: Reviewable  (was: In Progress)

 test_snapshots.py - VM Deploy failed because the account was using template 
 belonging to different account to deploy the instance
 -

 Key: CLOUDSTACK-7516
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7516
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
  Labels: automation
 Fix For: 4.5.0


 Following test case failed:
 integration.component.test_snapshots.TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate
 Reason:
 Execute cmd: deployvirtualmachine failed, due to: errorCode: 531, 
 errorText:Acct[51d00171-895e-4893-90c8-6630b98f852a-test-TestCreateVMSnapshotTemplate-BJ9XFN]
  does not have permission to operate with resource 
 Acct[e7b7973c-3512-11e4-9ac6-1a6f7bb0d0a8-admin]
 Solution:
 Create the template with the api client of the account itself, and not the 
 api client of root domain account. So that account will have permission to 
 use the resources (template)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128283#comment-14128283
 ] 

ASF subversion and git services commented on CLOUDSTACK-7528:
-

Commit f4f5ea3cc02d931416579514a3289a607f7c5cac in cloudstack's branch 
refs/heads/hotfix/4.4/CLOUDSTACK-7528 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f4f5ea3 ]

CLOUDSTACK-7528: More verbose logging when sending alert fails

When sendAlert is called on an AlertManager impl, if it fails it logs that
something was wrong but does not log the body of the issue/error. This means
we tell the user/admin that there was an issue but don't share the issue
with them at all as the email alert fail (or that they were not initialized).

(cherry picked from commit 91fd8d7cd5d5a83bf75f5f2972ad2eb2a4a07694)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

Conflicts:
server/src/com/cloud/alert/AlertManagerImpl.java


 When AlertManager fails to sendAlert it does not log the actual issue/error
 ---

 Key: CLOUDSTACK-7528
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 AlertManager has a sendAlert method, the impls try to send emailAlerts but if 
 they fail they log it as warning the subject/error but don't log the actual 
 error. This message in logs is useless for users/admins as we tell them that 
 there is an issue but don't share with them at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128284#comment-14128284
 ] 

ASF subversion and git services commented on CLOUDSTACK-7527:
-

Commit f497fceabb8c200cf2dacd87aa450f429dd9d385 in cloudstack's branch 
refs/heads/hotfix/4.4/CLOUDSTACK-7184 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f497fce ]

CLOUDSTACK-7527 reboot faster by writing to /proc/sysrq-trigger

 XenServer heartbeat-script: make it reboot faster (when fencing)
 

 Key: CLOUDSTACK-7527
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.3.0, 4.4.0
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Minor

 xenheartbeat.sh:
 I've seen the 'reboot' command hang, even though it has the force option 
 specified (last line of the script). Wouldn't it be better to invoke it like 
 this:
 echo b  /proc/sysrq-trigger
 Tested it, starts boot sequence immediately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)

2014-09-10 Thread Daan Hoogland (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128286#comment-14128286
 ] 

Daan Hoogland commented on CLOUDSTACK-7527:
---

included this in branch hotfix/4.4/CLOUDSTACK-7184

 XenServer heartbeat-script: make it reboot faster (when fencing)
 

 Key: CLOUDSTACK-7527
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.3.0, 4.4.0
Reporter: Remi Bergsma
Assignee: Daan Hoogland
Priority: Minor

 xenheartbeat.sh:
 I've seen the 'reboot' command hang, even though it has the force option 
 specified (last line of the script). Wouldn't it be better to invoke it like 
 this:
 echo b  /proc/sysrq-trigger
 Tested it, starts boot sequence immediately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav closed CLOUDSTACK-7528.
---
Resolution: Fixed

Fixed on 4.3, 4.4 and master branches.

 When AlertManager fails to sendAlert it does not log the actual issue/error
 ---

 Key: CLOUDSTACK-7528
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 AlertManager has a sendAlert method, the impls try to send emailAlerts but if 
 they fail they log it as warning the subject/error but don't log the actual 
 error. This message in logs is useless for users/admins as we tell them that 
 there is an issue but don't share with them at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7472.
--

 Change cloudstack agent.properties file for rhel 7 to include 
 kvmclock.disable=true
 ---

 Key: CLOUDSTACK-7472
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


 We need to minimize manual steps that needs to be done after agent 
 installation so change cloudstack agent.properties file for rhel 7 to include 
 kvmclock.disable=true



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7473) [LXC]putting host into maintenance is failing

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7473.
--

 [LXC]putting host into maintenance is failing 
 --

 Key: CLOUDSTACK-7473
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7473
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
 Attachments: agent.log.tar.gz, ms.tar.gz


 Repro stesp:
 1. create a zone with a LXC cluster having 2 host
 2. create few LXC vms
 3. Put one host into maintenance which has some VM  running
 Bug:
 Putting host into maintenance will never pass. host will remain in preparing 
 for maintenance stage and then goes to disconnect state.
 Agent log shows :
 2014-09-02 19:08:12,663 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-1:null) Failed to execute while migrating domain: 
 org.libvirt.LibvirtException: this function is not supported by the 
 connection driver: virDomainMigrate2
 2014-09-02 19:08:12,665 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-1:null) Seq 1-3693233169420517550:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.MigrateAnswer:{result:false,details:org.libvirt.LibvirtException:
  this function is not supported by the connection driver: 
 virDomainMigrate2,wait:0}}] }
 2014-09-02 19:08:13,004 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Request:Seq 1-3693233169420517551:  { Cmd , 
 MgmtId: 233845178472723, via: 1, Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.MigrateCommand:{vmName:i-2-7-VM,destIp:10.147.28.49,hostGuid:2b2a1b9f-7582-378f-b54f-1dbb8f69e239-LibvirtComputingResource,isWindows:false,vmTO:{id:7,name:i-2-7-VM,type:User,cpus:1,minSpeed:128,maxSpeed:128,minRam:134217728,maxRam:134217728,arch:x86_64,os:Red
  Hat Enterprise Linux 
 7.0,platformEmulator:Other,bootArgs:,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:QY0cKnTfogzaS49R283f1g==,params:{Message.ReservedCapacityFreed.Flag:false},uuid:caf07a92-9f6c-49df-a7e4-27289e715448,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:981fe152-6ee5--ae41-474736c881cf,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-7,size:647321600,path:981fe152-6ee5--ae41-474736c881cf,volumeId:7,vmName:i-2-7-VM,accountId:2,format:DIR,provisioningType:THIN,id:7,deviceId:0,hypervisorType:LXC}},diskSeq:0,path:981fe152-6ee5--ae41-474736c881cf,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:647321600}},{data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{id:0,format:ISO,accountId:0,hvm:false}},diskSeq:3,type:ISO}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,pxeDisable:false,nicUuid:95826449-4163-46b8-91b7-8bf94f19ab8e,uuid:d4db3da8-4e6c-4e29-b6bb-a6613d55fa2f,ip:10.147.30.166,netmask:255.255.255.0,gateway:10.147.30.1,mac:06:54:96:00:00:07,dns1:10.140.50.6,broadcastType:Vlan,type:Guest,broadcastUri:vlan://30,isolationUri:vlan://30,isSecurityGroupEnabled:true}]},executeInSequence:false,wait:0}}]
  }
 2014-09-02 19:08:13,005 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Processing command: 
 com.cloud.agent.api.MigrateCommand
 2014-09-02 19:08:13,006 DEBUG [kvm.resource.LibvirtConnection] 
 (agentRequest-Handler-4:null) can't find connection: KVM, for vm: i-2-7-VM, 
 continue
 2014-09-02 19:08:13,018 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Live migration of instance i-2-7-VM initiated
 2014-09-02 19:08:13,103 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-5:null) Waiting for migration of s-1-VM to complete, 
 waited 1000ms
 2014-09-02 19:08:13,118 INFO  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Migration thread for i-2-7-VM is done
 2014-09-02 19:08:13,119 DEBUG [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-4:null) Failed to execute while migrating domain: 
 org.libvirt.LibvirtException: this function is not supported by the 
 connection driver: virDomainMigrate2
 2014-09-02 19:08:13,124 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-4:null) Seq 1-3693233169420517551:  { Ans: , MgmtId: 
 233845178472723, via: 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.MigrateAnswer:{result:false,details:org.libvirt.LibvirtException:

[jira] [Commented] (CLOUDSTACK-7520) [UI] keep advanced search parameters visible after search has been run


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128302#comment-14128302
 ] 

ASF subversion and git services commented on CLOUDSTACK-7520:
-

Commit 75cd79a2382486385b5ae901c5b5c45cbd1505fc in cloudstack's branch 
refs/heads/master from [~mihaelas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=75cd79a ]

CLOUDSTACK-7520: [UI] keep advanced search parameters visible after search has 
been run.

- Preserve the advanced search parameters, so that when the advanced search box 
is shown again,
it is populated with the values selected/entered previously, unless they have 
navigated away from the search results page,
or applied any additional filters/search parameters.

Signed-off-by: Mihaela Stoica mihaela.sto...@citrix.com
Signed-off-by: Rajani Karuturi rajanikarut...@gmail.com


 [UI] keep advanced search parameters visible after search has been run
 --

 Key: CLOUDSTACK-7520
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7520
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: Mihaela Stoica
Assignee: Mihaela Stoica
 Fix For: 4.5.0


 After user runs an advanced search, the parameters they have entered into the 
 search box disappear.
 - This causes confusion, because users often can't remember what they have 
 searched for to get their current search results.
 - Parameters entered into the advance search box should remain visible after 
 user runs the
  search, to mitigate confusion and enable way-finding.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7520) [UI] keep advanced search parameters visible after search has been run


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica resolved CLOUDSTACK-7520.

Resolution: Fixed

 [UI] keep advanced search parameters visible after search has been run
 --

 Key: CLOUDSTACK-7520
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7520
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: Mihaela Stoica
Assignee: Mihaela Stoica
 Fix For: 4.5.0


 After user runs an advanced search, the parameters they have entered into the 
 search box disappear.
 - This causes confusion, because users often can't remember what they have 
 searched for to get their current search results.
 - Parameters entered into the advance search box should remain visible after 
 user runs the
  search, to mitigate confusion and enable way-finding.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7529) Make consistent use of CommandType.UUID in api layer

Rohit Yadav created CLOUDSTACK-7529:
---

 Summary: Make consistent use of CommandType.UUID in api layer
 Key: CLOUDSTACK-7529
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7529
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: Future, 4.5.0


CommandType.UUID may not be consistently used, we just need to check it across 
API layer and try to fix it where ever possible.

cc Ilia Shakitko i.shaki...@tech.leaseweb.com



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7507) [LXC] router VMs are not migrating to other host in the cluster putting its original host into maintenance


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7507.
--

Verified fixed. 

though router VM is not migrating across cluster for which I am filing separate 
bug 

 [LXC] router VMs are not migrating to other host in the cluster putting its 
 original host into maintenance
 --

 Key: CLOUDSTACK-7507
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7507
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0


 Repro steps: 
 Create a Zone with LXC cluster having two host in the LXC cluster
 Launch a VM in this cluster 
 Put LXC host to maintenance which has router VM
 Bug;
 Router VM does not migrates to other available host
 Expected Result:
 Router VM  should migrate to other host in the cluster



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance

shweta agarwal created CLOUDSTACK-7530:
--

 Summary: [LXC] router VMs are not migrating to other cluster if  
we put its original host into maintenance
 Key: CLOUDSTACK-7530
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
 Fix For: 4.5.0




Repro steps:
Create a Zone with  two LXC clusters each having one host 
Launch a VM in this cluster
Put LXC host to maintenance which has router VM

Bug;
Router VM does not migrates to other available host in another cluster

Expected Result:
Router VM should migrate to other host in the  2nd cluster 

Additional info to support my case :
1. When i started manually router vm it started in other cluster without issue
2. Other system vm like CPVM and SSVM in similar situation moves/recreated  for 
one cluster to another cluster . 







--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.

2014-09-10 Thread Anshul Gangwar (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshul Gangwar resolved CLOUDSTACK-6898.

Resolution: Fixed

 [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from 
 inside the console), the console gets stuck at a point.
 ---

 Key: CLOUDSTACK-6898
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6898
 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
 Environment: Hyper-V
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.4.0

 Attachments: CS-6898.jpg


 Steps :
 ==
 1. Deploy a Hyper-V setup with advanced zone.
 2. Deploy a VM.
 3. Now open the console of the VM from CS UI.
 4. Now reboot the VM from CS or from inside the console of VM
 Expected behavior :
 ===
 1. The console should be accessible when the the VM is rebooting and after it 
 boots up.
 Observed behavior :
 ==
 The console gets stuck at the point of stopping the VM and remains in that 
 state.
 Even if you close the console and reopen , it remains in the same state.
 Attaching a screenshot for that.
 Workaround :
 
 Either close the console or even in the open state don't do any activity on 
 it for 3 mins. After that it becomes accessible again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7503) [Hyper-V] Logging meaningless response string from Hyper-v Agent

2014-09-10 Thread Anshul Gangwar (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshul Gangwar resolved CLOUDSTACK-7503.

Resolution: Fixed

committed to master

 [Hyper-V] Logging meaningless response string from Hyper-v Agent
 

 Key: CLOUDSTACK-7503
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7503
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Logging meaningless response string from Hyper-v Agent



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6898) [Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from inside the console), the console gets stuck at a point.

2014-09-10 Thread Anshul Gangwar (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anshul Gangwar updated CLOUDSTACK-6898:
---
Fix Version/s: (was: 4.4.0)
4.5.0

[Hyper-V] Open the console of a VM from CS, reboot the VM ( from CS or from
inside the console), the console gets stuck at a point.
---

Attachments: CS-6898.jpg

Either close the console or even in the open state don't do any activity on
it for 3 mins. After that it becomes accessible again.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7502) [UI] Host detail page - Display KVM agent version and Qemu version


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica updated CLOUDSTACK-7502:
---
Attachment: KVM host.png

 [UI] Host detail page - Display KVM agent version and Qemu version
 --

 Key: CLOUDSTACK-7502
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7502
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: Mihaela Stoica
Assignee: Mihaela Stoica
 Fix For: 4.5.0

 Attachments: KVM host.png


 UI - Host detail page - Display KVM agent version and Qemu version.
 For KVM hosts, Host detail page should include KVM agent version and Qemu 
 version.
 The information can be obtained via listHosts API command, details field: 
 CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version 
 is the version of kvm agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7502) [UI] Host detail page - Display KVM agent version and Qemu version


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128329#comment-14128329
 ] 

Mihaela Stoica commented on CLOUDSTACK-7502:


Screenshots attached showing the UI change, only visible for KVM hosts.

 [UI] Host detail page - Display KVM agent version and Qemu version
 --

 Key: CLOUDSTACK-7502
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7502
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: Mihaela Stoica
Assignee: Mihaela Stoica
 Fix For: 4.5.0

 Attachments: KVM host.png, XenServer host.png


 UI - Host detail page - Display KVM agent version and Qemu version.
 For KVM hosts, Host detail page should include KVM agent version and Qemu 
 version.
 The information can be obtained via listHosts API command, details field: 
 CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version 
 is the version of kvm agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7502) [UI] Host detail page - Display KVM agent version and Qemu version


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mihaela Stoica updated CLOUDSTACK-7502:
---
Attachment: XenServer host.png

 [UI] Host detail page - Display KVM agent version and Qemu version
 --

 Key: CLOUDSTACK-7502
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7502
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: Mihaela Stoica
Assignee: Mihaela Stoica
 Fix For: 4.5.0

 Attachments: KVM host.png, XenServer host.png


 UI - Host detail page - Display KVM agent version and Qemu version.
 For KVM hosts, Host detail page should include KVM agent version and Qemu 
 version.
 The information can be obtained via listHosts API command, details field: 
 CCP.Qemu.Img.Version is the version of qemu image, and CCP.KVM.Agent.Version 
 is the version of kvm agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7504) [LXC] ha enabled VM not started on other host of cluster when original host is put to maintenance


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7504.
--

 [LXC] ha enabled VM not started on other host of cluster when original host 
 is put to maintenance
 -

 Key: CLOUDSTACK-7504
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7504
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0

 Attachments: Ms.tar.gz


 Repro steps:
 Create a LXC zone with two lxc host in a cluster
 Create a HA enabled Service offering
 Create a VM  with ha enabled service offerings
 Put host on maintenance which has this ha enabled VM
 Expected result :
 HA enabled VM should start on other available LXC host in the cluster
 Bug:
 HA enabled VM  stops but don't start on other hosts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7478) [LXC] VM creation should fail when creating LXC VM with data disk and w/o having ceph as primary storage

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7478.
--

Verified fixed

 [LXC] VM creation should fail when creating LXC VM with data disk and w/o 
 having ceph as primary storage
 

 Key: CLOUDSTACK-7478
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7478
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Critical
 Fix For: 4.5.0

 Attachments: agent.log.tar.gz, ms.tar.gz


 Repro steps:
 1. Create a LXC zone with only nfs
 2. Create a VM  with data disk
 Bug:
 VM  creations passes without giving error that data disk needs ceph storage
 Even usage events for data disk is also generated.
 VM  shows no data disk with it
 dumxml of VM shows:
 domain type='lxc' id='11480'
   namei-2-21-VM/name
   uuid7da917bf-dd91-4185-92ce-a419b6a7e396/uuid
   descriptionCentOS 6.3 (64-bit)/description
   memory unit='KiB'524288/memory
   currentMemory unit='KiB'524288/currentMemory
   vcpu placement='static'1/vcpu
   cputune
 shares500/shares
   /cputune
   resource
 partition/machine/partition
   /resource
   os
 type arch='x86_64'exe/type
 init/sbin/init/init
   /os
   features
 acpi/
 apic/
 pae/
   /features
   cpu
   /cpu
   clock offset='utc'
 timer name='kvmclock' present='no'/
   /clock
   on_poweroffdestroy/on_poweroff
   on_rebootrestart/on_reboot
   on_crashdestroy/on_crash
   devices
 emulator/usr/libexec/libvirt_lxc/emulator
 filesystem type='mount' accessmode='passthrough'
   source 
 dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/138ef448-03d7-4344-92a9-3e981b8826b6'/
   target dir='/'/
 /filesystem
 interface type='bridge'
   mac address='06:00:f8:00:00:06'/
   source bridge='brem1-30'/
   target dev='vnet1'/
   model type='virtio'/
   bandwidth
 inbound average='25600' peak='25600'/
 outbound average='25600' peak='25600'/
   /bandwidth
 /interface
 serial type='pty'
   target port='0'/
 /serial
 console type='pty' tty='/dev/pts/0'
   source path='/dev/pts/0'/
   target type='lxc' port='0'/
   alias name='console0'/
 /console
 memballoon model='none'/
   /devices
   seclabel type='none' model='selinux'/
 /domain



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-755) nTier Apps 2.0 : Ability to give isolated network any IP network, not just unique from super-net

2014-09-10 Thread Adrian Lewis (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128364#comment-14128364
 ] 

Adrian Lewis commented on CLOUDSTACK-755:
-

Has anything come of this? It does seem like a fairly significant limitation 
that needs addressing, especially if a potential fix just needs to be committed.

 nTier Apps 2.0 : Ability to give isolated network any IP network, not just 
 unique from super-net
 

 Key: CLOUDSTACK-755
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-755
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Kishan Kavala

 This item is a sub task (2.11) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Users want flexibility in defining the IP Network for each of their tiers. 
 Users can specify a sub-network out of the VPC super-net for any specific 
 tier and they are limited to specifying only a network out of the super-net 
 defined while creating a VPC.
 Specifying cidr while creating VPC can be made optional. If VPC cidr is not 
 specified, users can create a tier with any IP network. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128368#comment-14128368
 ] 

ASF subversion and git services commented on CLOUDSTACK-6099:
-

Commit 57c69a8ba02a9d327629fd8665262efc94813d3a in cloudstack's branch 
refs/heads/4.3 from [~bharat.kumar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=57c69a8 ]

CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute 
offerings with NPE

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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:616)
 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 $Proxy210.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:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 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

[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128369#comment-14128369
 ] 

ASF subversion and git services commented on CLOUDSTACK-6099:
-

Commit 2b7b837b28f847eedf3cd7bd034dc23ba43d8a63 in cloudstack's branch 
refs/heads/master from [~bharat.kumar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2b7b837 ]

CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute 
offerings with NPE


 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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:616)
 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 $Proxy210.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:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 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

[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128370#comment-14128370
 ] 

ASF subversion and git services commented on CLOUDSTACK-6099:
-

Commit 56c7fc800ad12e2e3ccbf7fc79aaacd709f036b2 in cloudstack's branch 
refs/heads/hotfix/4.4/CLOUDSTACK-6099 from [~bharat.kumar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=56c7fc8 ]

CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute 
offerings with NPE

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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:616)
 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 $Proxy210.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:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 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

[jira] [Resolved] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoi


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav resolved CLOUDSTACK-6099.
-
Resolution: Fixed

 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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:616)
 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 $Proxy210.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:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 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:111)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at

[jira] [Assigned] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye reassigned CLOUDSTACK-7351:
--

Assignee: Gaurav Aradhye  (was: Girish Shilamkar)

 [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
 

 Key: CLOUDSTACK-7351
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0

 Attachments: CLOUDSTACK-7351.rar


 This issue observed while running the test case 
 integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
 This test case deploying VM with below command 
 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
 account=test-TestVMAcc
 ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Ydomainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8displayname=testserversignature=4xBMTxK5iiaze
 Fgwm2GisNo1SvM%3Dzoneid=a99226f1-d924-4156-8157-90bec0fa6579apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
 TzASxzSN0OSUnfoQstartvm=Truetemplateid=5cc1e055-5f49-4f12-91da-d01bf7ee509ccommand=deployVirtualMachineresponse=jsondiskofferingid=543
 e345e-645a-4bf9-bd4e-af1db46470e7serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
 This deployment failed with below error 
 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
 Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
 parameter is needed to deploy VM or the hypervisor parameter value passed is 
 invalid
 Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye updated CLOUDSTACK-7351:
---
Status: Reviewable  (was: In Progress)

 [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
 

 Key: CLOUDSTACK-7351
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0

 Attachments: CLOUDSTACK-7351.rar


 This issue observed while running the test case 
 integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
 This test case deploying VM with below command 
 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
 account=test-TestVMAcc
 ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Ydomainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8displayname=testserversignature=4xBMTxK5iiaze
 Fgwm2GisNo1SvM%3Dzoneid=a99226f1-d924-4156-8157-90bec0fa6579apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
 TzASxzSN0OSUnfoQstartvm=Truetemplateid=5cc1e055-5f49-4f12-91da-d01bf7ee509ccommand=deployVirtualMachineresponse=jsondiskofferingid=543
 e345e-645a-4bf9-bd4e-af1db46470e7serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
 This deployment failed with below error 
 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
 Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
 parameter is needed to deploy VM or the hypervisor parameter value passed is 
 invalid
 Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7135) [Automation] Fix the script test_baremetal.py - Can't have more than one Guest network in zone with network type Basic


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128376#comment-14128376
 ] 

Gaurav Aradhye commented on CLOUDSTACK-7135:


Sent mail to Sheng Yang and Frank Zhank on dev list. Reply awaited.
Test case tries to create a guest network in basic zone but fails because guest 
network is already present in the setup.

 [Automation] Fix the script test_baremetal.py - Can't have more than one 
 Guest network in zone with network type Basic
 

 Key: CLOUDSTACK-7135
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7135
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 
 Error Message:
 
 test_baremetal (integration.component.test_baremetal.TestBaremetal): DEBUG: 
 Sending GET Cmd : createNetwork===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.73
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMAzoneid=1displaytext=defaultBaremetalNetworknetworkofferingid=84c3e203-139e-4412-ab81-8a6abecb3e35response=jsonname=defaultBaremetalNetworkcommand=createNetworksignature=alemHuTsxw31sTOaAyaZn2Cw4N8%3D
  HTTP/1.1 431 165
 test_baremetal (integration.component.test_baremetal.TestBaremetal): ERROR: 
 Exception:['Traceback (most recent call last):\n', '  File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 308, in __parseAndGetResponse\nresponse_cls)\n', '  File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py,
  line 150, in getResultObj\nraise 
 cloudstackException.CloudstackAPIException(respname, errMsg)\n', 
 CloudstackAPIException: Execute cmd: createnetwork failed, due to: 
 errorCode: 431, errorText:Can't have more than one Guest network in zone with 
 network type Basic\n]
 Traceback (most recent call last):
   File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 308, in __parseAndGetResponse
 response_cls)
   File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/jsonHelper.py,
  line 150, in getResultObj
 raise cloudstackException.CloudstackAPIException(respname, errMsg)
 CloudstackAPIException: Execute cmd: createnetwork failed, due to: errorCode: 
 431, errorText:Can't have more than one Guest network in zone with network 
 type Basic
 test_baremetal (integration.component.test_baremetal.TestBaremetal): ERROR: 
 marvinRequest : CmdName: marvin.cloudstackAPI.createNetwork.createNetworkCmd 
 object at 0x302ebd0 Exception: ['Traceback (most recent call last):\n', '  
 File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 375, in marvinRequest\nraise self.__lastError\n', 
 CloudstackAPIException: Execute cmd: createnetwork failed, due to: 
 errorCode: 431, errorText:Can't have more than one Guest network in zone with 
 network type Basic\n]
 Traceback (most recent call last):
   File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 375, in marvinRequest
 raise self.__lastError
 CloudstackAPIException: Execute cmd: createnetwork failed, due to: errorCode: 
 431, errorText:Can't have more than one Guest network in zone with network 
 type Basic
 test_baremetal (integration.component.test_baremetal.TestBaremetal): 
 CRITICAL: EXCEPTION: test_baremetal: ['Traceback (most recent call last):\n', 
 '  File /usr/lib/python2.7/unittest/case.py, line 332, in run\n
 testMethod()\n', '  File 
 /home/jenkins/workspace/xenrt-reg-basic-xs/cloudstack.git/test/integration/component/test_baremetal.py,
  line 110, in test_baremetal\nnetwork = Network.create(self.apiclient, 
 self.services[network], zoneid=self.zoneid, 
 networkofferingid=networkoffering.id)\n', '  File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/lib/base.py,
  line 2591, in create\nreturn 
 Network(apiclient.createNetwork(cmd).__dict__)\n', '  File

[jira] [Updated] (CLOUDSTACK-7134) [Automation] Fix the script test_reset_ssh_keypair.py - Advanced Zone VM is being deployed in a Basic Zone deployment


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye updated CLOUDSTACK-7134:
---
Status: Reviewable  (was: In Progress)

 [Automation] Fix the script test_reset_ssh_keypair.py - Advanced Zone VM is 
 being deployed in a Basic Zone deployment
 ---

 Key: CLOUDSTACK-7134
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7134
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 =
 Error Message:
 =
 est_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 DEBUG: Response : {jobprocstatus : 0, created : u'2014-07-11T16:46:43+', 
 cmd : u'org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin', 
 userid : u'9f654606-08ed-11e4-887d-928d578f5db8', jobstatus : 1, jobid : 
 u'e7c495f1-6324-4253-a453-494e2a36ae02', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {domain : u'ROOT', domainid : 
 u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', haenable : False, templatename : 
 u'Cent OS Template-9UKJWR', securitygroup : [{egressrule : [], account : 
 u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', 
 description : u'Default Security Group', tags : [], ingressrule : [], id : 
 u'980df1d5-b24b-4851-b86c-2fd149692a57', name : u'default'}], zoneid : 
 u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', cpunumber : 1, ostypeid : 12, 
 passwordenabled : True, instancename : u'i-150-92-VM', id : 
 u'e391e779-2efe-4c6a-ad1f-e03d0867165f', hostname : u'swordtail', displayvm : 
 True, state : u'Running', guestosid : 
 u'7cd2c9a6-08ed-11e4-887d-928d578f5db8', details : {hypervisortoolsversion : 
 u'xenserver56'}, memory : 128, serviceofferingid : 
 u'5a70bf03-2147-4426-80a9-11d76f658c7b', zonename : u'XenRT-Zone-0', 
 isdynamicallyscalable : False, displayname : u'VM', tags : [], nic : 
 [{networkid : u'd792af3b-8e8d-4830-aa96-0933f42c71a3', macaddress : 
 u'06:95:c6:00:00:12', type : u'Shared', broadcasturi : u'vlan://untagged', 
 traffictype : u'Guest', netmask : u'255.255.240.0', ipaddress : 
 u'10.220.114.151', id : u'1ba07040-dbaa-419e-8941-a7ba6f922676', networkname 
 : u'guestNetworkForBasicZone', gateway : u'10.220.112.1', isdefault : True}], 
 cpuspeed : 100, jobstatus : 0, templateid : 
 u'b9946974-966c-4a74-8c57-c9a55e08542d', password : u'kU8pbbvtg', 
 affinitygroup : [], account : 
 u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', hostid 
 : u'71c113f0-a559-4c9f-95b0-1bfeec463a9c', name : 
 u'VM-e391e779-2efe-4c6a-ad1f-e03d0867165f', created : 
 u'2014-07-11T16:46:43+', hypervisor : u'XenServer', jobid : 
 u'e7c495f1-6324-4253-a453-494e2a36ae02', rootdevicetype : u'ROOT', 
 rootdeviceid : 0, serviceofferingname : u'Tiny Instance', templatedisplaytext 
 : u'Cent OS Template'}, accountid : u'9f6536a2-08ed-11e4-887d-928d578f5db8'}
 test_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 DEBUG: Payload: {'account': 
 u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', 
 'domainid': u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', 'zoneid': 
 u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', 'apiKey': 
 u'Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA',
  'command': 'associateIpAddress', 'signature': 
 '52qNzGUlB0gK2dd/0r/tdZKGWaE=', 'response': 'json'}
 test_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 DEBUG: Sending GET Cmd : associateIpAddress===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.73
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?account=test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XDdomainid=7ccbf6bc-08ed-11e4-887d-928d578f5db8zoneid=ae56b8ba-3fd6-4f63-b71f-32128f86688aapiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMAcommand=associateIpAddresssignature=52qNzGUlB0gK2dd%2F0r%2FtdZKGWaE%3Dresponse=json
  HTTP/1.1 533 129
 test_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 ERROR: Exception:['Traceback (most recent call last):\n', '  File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 308, in __parseAndGetResponse\nresponse_cls)\n', '  File

[jira] [Assigned] (CLOUDSTACK-7134) [Automation] Fix the script test_reset_ssh_keypair.py - Advanced Zone VM is being deployed in a Basic Zone deployment


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye reassigned CLOUDSTACK-7134:
--

Assignee: Gaurav Aradhye  (was: Girish Shilamkar)

 [Automation] Fix the script test_reset_ssh_keypair.py - Advanced Zone VM is 
 being deployed in a Basic Zone deployment
 ---

 Key: CLOUDSTACK-7134
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7134
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 =
 Error Message:
 =
 est_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 DEBUG: Response : {jobprocstatus : 0, created : u'2014-07-11T16:46:43+', 
 cmd : u'org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin', 
 userid : u'9f654606-08ed-11e4-887d-928d578f5db8', jobstatus : 1, jobid : 
 u'e7c495f1-6324-4253-a453-494e2a36ae02', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {domain : u'ROOT', domainid : 
 u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', haenable : False, templatename : 
 u'Cent OS Template-9UKJWR', securitygroup : [{egressrule : [], account : 
 u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', 
 description : u'Default Security Group', tags : [], ingressrule : [], id : 
 u'980df1d5-b24b-4851-b86c-2fd149692a57', name : u'default'}], zoneid : 
 u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', cpunumber : 1, ostypeid : 12, 
 passwordenabled : True, instancename : u'i-150-92-VM', id : 
 u'e391e779-2efe-4c6a-ad1f-e03d0867165f', hostname : u'swordtail', displayvm : 
 True, state : u'Running', guestosid : 
 u'7cd2c9a6-08ed-11e4-887d-928d578f5db8', details : {hypervisortoolsversion : 
 u'xenserver56'}, memory : 128, serviceofferingid : 
 u'5a70bf03-2147-4426-80a9-11d76f658c7b', zonename : u'XenRT-Zone-0', 
 isdynamicallyscalable : False, displayname : u'VM', tags : [], nic : 
 [{networkid : u'd792af3b-8e8d-4830-aa96-0933f42c71a3', macaddress : 
 u'06:95:c6:00:00:12', type : u'Shared', broadcasturi : u'vlan://untagged', 
 traffictype : u'Guest', netmask : u'255.255.240.0', ipaddress : 
 u'10.220.114.151', id : u'1ba07040-dbaa-419e-8941-a7ba6f922676', networkname 
 : u'guestNetworkForBasicZone', gateway : u'10.220.112.1', isdefault : True}], 
 cpuspeed : 100, jobstatus : 0, templateid : 
 u'b9946974-966c-4a74-8c57-c9a55e08542d', password : u'kU8pbbvtg', 
 affinitygroup : [], account : 
 u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', hostid 
 : u'71c113f0-a559-4c9f-95b0-1bfeec463a9c', name : 
 u'VM-e391e779-2efe-4c6a-ad1f-e03d0867165f', created : 
 u'2014-07-11T16:46:43+', hypervisor : u'XenServer', jobid : 
 u'e7c495f1-6324-4253-a453-494e2a36ae02', rootdevicetype : u'ROOT', 
 rootdeviceid : 0, serviceofferingname : u'Tiny Instance', templatedisplaytext 
 : u'Cent OS Template'}, accountid : u'9f6536a2-08ed-11e4-887d-928d578f5db8'}
 test_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 DEBUG: Payload: {'account': 
 u'test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XD', 
 'domainid': u'7ccbf6bc-08ed-11e4-887d-928d578f5db8', 'zoneid': 
 u'ae56b8ba-3fd6-4f63-b71f-32128f86688a', 'apiKey': 
 u'Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMA',
  'command': 'associateIpAddress', 'signature': 
 '52qNzGUlB0gK2dd/0r/tdZKGWaE=', 'response': 'json'}
 test_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 DEBUG: Sending GET Cmd : associateIpAddress===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.73
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?account=test-TestResetSSHKeypair-test_01_reset_keypair_normal_user-D073XDdomainid=7ccbf6bc-08ed-11e4-887d-928d578f5db8zoneid=ae56b8ba-3fd6-4f63-b71f-32128f86688aapiKey=Ra1mlXzCZU0K1l4MKDWdRbQDU67PCQuRnKYv3hyc-Q8hSvCSFjB32UtifLbS6oYpMeKaf0BCuUidMw0LqZeCMAcommand=associateIpAddresssignature=52qNzGUlB0gK2dd%2F0r%2FtdZKGWaE%3Dresponse=json
  HTTP/1.1 533 129
 test_01_reset_keypair_normal_user 
 (integration.component.test_reset_ssh_keypair.TestResetSSHKeyUserRights): 
 ERROR: Exception:['Traceback (most recent call last):\n', '  File 
 /local/jenkins/workspace/xenrt-reg-basic-xs/work.64/env/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
  line 308, in __parseAndGetResponse\nresponse_cls)\n', '  File

[jira] [Resolved] (CLOUDSTACK-7433) [Automation] Fix the script test_deploy_vm_userdata_reg.py - Host credentials are hardcoded in the script

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye resolved CLOUDSTACK-7433.

Resolution: Fixed

 [Automation] Fix the script test_deploy_vm_userdata_reg.py - Host 
 credentials are hardcoded in the script
 ---

 Key: CLOUDSTACK-7433
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7433
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Srikanteswararao Talluri
Priority: Critical
 Fix For: 4.5.0


 The host credentials are hardcoded in the script. Please take the host 
 specific information from test_data.py which is configurable.
 *Error Message*
 SSH Connection Failed   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=deploy_vm_userdata
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File 
 /root/cloudstack/test/integration/component/test_deploy_vm_userdata_reg.py, 
 line 209, in test_deployvm_userdata_post
 cmd
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py, line 
 198, in get_process_status
 ssh = SshClient(hostip, port, username, password)
   File /usr/local/lib/python2.7/dist-packages/marvin/sshClient.py, line 81, 
 in __init__
 raise internalError(SSH Connection Failed)
 'SSH Connection Failed\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=deploy_vm_userdata
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128389#comment-14128389
 ] 

ASF subversion and git services commented on CLOUDSTACK-6099:
-

Commit 015276350e41b30bde049ca0852811ed6262da16 in cloudstack's branch 
refs/heads/4.4 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0152763 ]

Merge remote-tracking branch 'origin/hotfix/4.4/CLOUDSTACK-6099' into 4.4


 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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:616)
 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 $Proxy210.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:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 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

[jira] [Commented] (CLOUDSTACK-7528) When AlertManager fails to sendAlert it does not log the actual issue/error

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128387#comment-14128387
 ] 

ASF subversion and git services commented on CLOUDSTACK-7528:
-

Commit f4f5ea3cc02d931416579514a3289a607f7c5cac in cloudstack's branch 
refs/heads/4.4 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f4f5ea3 ]

CLOUDSTACK-7528: More verbose logging when sending alert fails

When sendAlert is called on an AlertManager impl, if it fails it logs that
something was wrong but does not log the body of the issue/error. This means
we tell the user/admin that there was an issue but don't share the issue
with them at all as the email alert fail (or that they were not initialized).

(cherry picked from commit 91fd8d7cd5d5a83bf75f5f2972ad2eb2a4a07694)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

Conflicts:
server/src/com/cloud/alert/AlertManagerImpl.java


 When AlertManager fails to sendAlert it does not log the actual issue/error
 ---

 Key: CLOUDSTACK-7528
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7528
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 AlertManager has a sendAlert method, the impls try to send emailAlerts but if 
 they fail they log it as warning the subject/error but don't log the actual 
 error. This message in logs is useless for users/admins as we tell them that 
 there is an issue but don't share with them at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPo

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128388#comment-14128388
 ] 

ASF subversion and git services commented on CLOUDSTACK-6099:
-

Commit 56c7fc800ad12e2e3ccbf7fc79aaacd709f036b2 in cloudstack's branch 
refs/heads/4.4 from [~bharat.kumar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=56c7fc8 ]

CLOUDSTACK-6099 live migration is failing for vm deployed using dynaic compute 
offerings with NPE

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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:616)
 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 $Proxy210.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:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 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

[jira] [Resolved] (CLOUDSTACK-7510) Add usageid parameter to the listUsageRecords API call

2014-09-10 Thread Rajani Karuturi (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi resolved CLOUDSTACK-7510.
-
Resolution: Fixed

Updated Branches:
  refs/heads/master 75cd79a23 - 70142c4ac

Added usageid parameter to the listUsageRecords API call. Can be used only 
together with type parameter specified

Signed-off-by: Ilia Shakitko i.shaki...@tech.leaseweb.com
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

Commit: 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=70142c4acb84a2d2b1fe8806c159493e4a556532

 Add usageid parameter to the listUsageRecords API call
 --

 Key: CLOUDSTACK-7510
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7510
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Management Server
Reporter: Ilia Shakitko
Priority: Minor
 Fix For: 4.5.0


 Working with Usage server and usage records very often I need to get only 
 records for that particular usage ID. For example when filtering out 
 network_bytes_received/sent with big amount of data it's not very fast to 
 process hundreds of objects looking for the only one you need.
 It would be useful to have an ability to filter out usage records only for 
 specific resource ID.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7531) [LXC] ha enabled VM not restarted once a shutdown host is restarted

shweta agarwal created CLOUDSTACK-7531:
--

 Summary: [LXC] ha enabled VM not restarted once a shutdown host is 
restarted
 Key: CLOUDSTACK-7531
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7531
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kiran Koneti
 Fix For: 4.5.0


Repro steps:
1. Create a Zone with two cluster each having one LXC host
2. Create some ha enabled VM
3. Shutdown host machine  having ha enabled VM and wait till the status of 
agent is disconnected on MS
4. start host machine

Bug:
Ha enabled VM goes to stop state as soon as Host machine comes up and agent 
status is up on CS

Expected result:
HA enabled VM  should restart 

Additional information
For all that time when Host was shutdown the agent state was disconnected and 
all the HA enabled is shown as up and running but as soon as I restarted Host 
the HA enabled VM stopped . Ideally HA thread should kick in and restart those 
VM on other or same host . 



Attaching MS and agent log 





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7531) [LXC] ha enabled VM not restarted once a shutdown host is restarted


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7531.
--
Resolution: Invalid

After some time I noticed HA VM  restarted 

 [LXC] ha enabled VM not restarted once a shutdown host is restarted
 ---

 Key: CLOUDSTACK-7531
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7531
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kiran Koneti
 Fix For: 4.5.0


 Repro steps:
 1. Create a Zone with two cluster each having one LXC host
 2. Create some ha enabled VM
 3. Shutdown host machine  having ha enabled VM and wait till the status of 
 agent is disconnected on MS
 4. start host machine
 Bug:
 Ha enabled VM goes to stop state as soon as Host machine comes up and agent 
 status is up on CS
 Expected result:
 HA enabled VM  should restart 
 Additional information
 For all that time when Host was shutdown the agent state was disconnected and 
 all the HA enabled is shown as up and running but as soon as I restarted Host 
 the HA enabled VM stopped . Ideally HA thread should kick in and restart 
 those VM on other or same host . 
 Attaching MS and agent log 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7477) [LXC] the workaround for cpu,cpuacct are co-mounted problem of libvirt is removed when agent shutsdown and restarted

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal closed CLOUDSTACK-7477.
--

 [LXC] the workaround for cpu,cpuacct are co-mounted problem of libvirt is 
 removed when agent shutsdown and restarted
 

 Key: CLOUDSTACK-7477
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7477
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker

 Repro steps:
 1. Create a LXC setup
 2. create few vms 
 3. shut down host LXC agent
 4. Once Agent states become disconnected start host gain
 Bug
 Note all the mounts in host
 mount
 proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
 sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
 devtmpfs on /dev type devtmpfs 
 (rw,nosuid,seclabel,size=3981488k,nr_inodes=995372,mode=755)
 securityfs on /sys/kernel/security type securityfs 
 (rw,nosuid,nodev,noexec,relatime)
 tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
 devpts on /dev/pts type devpts 
 (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
 tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
 tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755)
 cgroup on /sys/fs/cgroup/systemd type cgroup 
 (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
 pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
 cgroup on /sys/fs/cgroup/cpuset type cgroup 
 (rw,nosuid,nodev,noexec,relatime,cpuset)
 cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
 (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
 cgroup on /sys/fs/cgroup/memory type cgroup 
 (rw,nosuid,nodev,noexec,relatime,memory)
 cgroup on /sys/fs/cgroup/devices type cgroup 
 (rw,nosuid,nodev,noexec,relatime,devices)
 cgroup on /sys/fs/cgroup/freezer type cgroup 
 (rw,nosuid,nodev,noexec,relatime,freezer)
 cgroup on /sys/fs/cgroup/net_cls type cgroup 
 (rw,nosuid,nodev,noexec,relatime,net_cls)
 cgroup on /sys/fs/cgroup/blkio type cgroup 
 (rw,nosuid,nodev,noexec,relatime,blkio)
 cgroup on /sys/fs/cgroup/perf_event type cgroup 
 (rw,nosuid,nodev,noexec,relatime,perf_event)
 cgroup on /sys/fs/cgroup/hugetlb type cgroup 
 (rw,nosuid,nodev,noexec,relatime,hugetlb)
 configfs on /sys/kernel/config type configfs (rw,relatime)
 /dev/mapper/rhel_rack3pod1host49-root on / type xfs 
 (rw,relatime,seclabel,attr2,inode64,noquota)
 selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
 systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
 (rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
 mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
 hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)
 debugfs on /sys/kernel/debug type debugfs (rw,relatime)
 sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
 sunrpc on /proc/fs/nfsd type nfsd (rw,relatime)
 /dev/mapper/rhel_rack3pod1host49-home on /home type xfs 
 (rw,relatime,seclabel,attr2,inode64,noquota)
 /dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
 10.147.28.7:/export/home/shweta/goleta.lxc.primary on 
 /mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424 type nfs 
 (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.147.28.7,mountvers=3,mountport=47246,mountproto=udp,local_lock=none,addr=10.147.28.7)
 fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
 it again contains all those cgroups mount point which we deleted earlier as a 
 part of LXC agent instalation .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users

2014-09-10 Thread Sanjeev N (JIRA)

Sanjeev N created CLOUDSTACK-7532:
-

 Summary: [Templates] Template status is not shown in UI/API 
response for non-default account users
 Key: CLOUDSTACK-7532
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, Template
Affects Versions: 4.5.0
 Environment: Latest build from master with commit:
c33fea2cd27664db32c1173e98511470bf0a0724
Reporter: Sanjeev N
Priority: Critical


[Templates] Template status is not shown in UI/API response for non-default 
account users

Steps to Reproduce:
===
1.Bring up CS with latest build
2.Create one account under root domain
3.Register template using the account created above
4.After the template download is completed verify the template status using the 
account created at step2

Expected Result:
==
In UI/API response status field should be there and it should be set to 
Download Complete after the successful template download.

Actual Behavior:

Status is shown only for the default admin user. But it is not showed to other 
account users.

Impact:
==
Marvin tests which use template register would fail because of the status filed 
missing.
Following is the code from base.py where the tests are failing:
 elif 'Downloaded' in template.status:
time.sleep(interval)
becasue template.status is NoneType 

API:

http://10.147.40.10:8080/client/api?command=listTemplatessessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3Dtemplatefilter=selfid=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa_=1410351906876
API Response:
===
listtemplatesresponse 
cloud-stack-version=4.5.0-SNAPSHOTcount1/counttemplateid550ad6ac-38d2-11e4-a56e-d4ae527ccfaa/idnameCentOS
 5.6(64-bit) no GUI (XenServer)/namedisplaytextCentOS 5.6(64-bit) no GUI 
(XenServer)/displaytextispublictrue/ispubliccreated2014-09-10T15:59:38+0530/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonestrue/crossZonesostypeid572126ea-38d2-11e4-a56e-d4ae527ccfaa/ostypeidostypenameCentOS
 5.6 
(64-bit)/ostypenameaccountsystem/accountzoneid680f7c3a-a9ee-4ed3-b594-981d56f8da4b/zoneidzonenamez2/zonenamesize21474836480/sizetemplatetypeBUILTIN/templatetypehypervisorXenServer/hypervisordomainROOT/domaindomainid54e9d4e4-38d2-11e4-a56e-d4ae527ccfaa/domainidisextractabletrue/isextractablechecksum905cec879afd9c9d22ecc8036131a180/checksumsshkeyenabledfalse/sshkeyenabledisdynamicallyscalabletrue/isdynamicallyscalable/template/listtemplatesresponse

In the above API response status field is missing.
This bug is easily reproducible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users

2014-09-10 Thread Sanjeev N (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sanjeev N updated CLOUDSTACK-7532:
--
Attachment: template_status.PNG

Attached screenshot to describe the issue.

 [Templates] Template status is not shown in UI/API response for non-default 
 account users
 -

 Key: CLOUDSTACK-7532
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Template
Affects Versions: 4.5.0
 Environment: Latest build from master with commit:
 c33fea2cd27664db32c1173e98511470bf0a0724
Reporter: Sanjeev N
Priority: Critical
  Labels: api, templates
 Attachments: template_status.PNG


 [Templates] Template status is not shown in UI/API response for non-default 
 account users
 Steps to Reproduce:
 ===
 1.Bring up CS with latest build
 2.Create one account under root domain
 3.Register template using the account created above
 4.After the template download is completed verify the template status using 
 the account created at step2
 Expected Result:
 ==
 In UI/API response status field should be there and it should be set to 
 Download Complete after the successful template download.
 Actual Behavior:
 
 Status is shown only for the default admin user. But it is not showed to 
 other account users.
 Impact:
 ==
 Marvin tests which use template register would fail because of the status 
 filed missing.
 Following is the code from base.py where the tests are failing:
  elif 'Downloaded' in template.status:
 time.sleep(interval)
 becasue template.status is NoneType 
 API:
 
 http://10.147.40.10:8080/client/api?command=listTemplatessessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3Dtemplatefilter=selfid=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa_=1410351906876
 API Response:
 ===
 listtemplatesresponse 
 cloud-stack-version=4.5.0-SNAPSHOTcount1/counttemplateid550ad6ac-38d2-11e4-a56e-d4ae527ccfaa/idnameCentOS
  5.6(64-bit) no GUI (XenServer)/namedisplaytextCentOS 5.6(64-bit) no GUI 
 (XenServer)/displaytextispublictrue/ispubliccreated2014-09-10T15:59:38+0530/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonestrue/crossZonesostypeid572126ea-38d2-11e4-a56e-d4ae527ccfaa/ostypeidostypenameCentOS
  5.6 
 (64-bit)/ostypenameaccountsystem/accountzoneid680f7c3a-a9ee-4ed3-b594-981d56f8da4b/zoneidzonenamez2/zonenamesize21474836480/sizetemplatetypeBUILTIN/templatetypehypervisorXenServer/hypervisordomainROOT/domaindomainid54e9d4e4-38d2-11e4-a56e-d4ae527ccfaa/domainidisextractabletrue/isextractablechecksum905cec879afd9c9d22ecc8036131a180/checksumsshkeyenabledfalse/sshkeyenabledisdynamicallyscalabletrue/isdynamicallyscalable/template/listtemplatesresponse
 In the above API response status field is missing.
 This bug is easily reproducible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128418#comment-14128418
 ] 

ASF subversion and git services commented on CLOUDSTACK-7351:
-

Commit 3411fbaccafbce8f99af4714a26f38a2c17d8a9e in cloudstack's branch 
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3411fba ]

CLOUDSTACK-7351: Passing hypervisor type while deploying VM using ISO

Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org


 [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
 

 Key: CLOUDSTACK-7351
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0

 Attachments: CLOUDSTACK-7351.rar


 This issue observed while running the test case 
 integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
 This test case deploying VM with below command 
 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
 account=test-TestVMAcc
 ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Ydomainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8displayname=testserversignature=4xBMTxK5iiaze
 Fgwm2GisNo1SvM%3Dzoneid=a99226f1-d924-4156-8157-90bec0fa6579apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
 TzASxzSN0OSUnfoQstartvm=Truetemplateid=5cc1e055-5f49-4f12-91da-d01bf7ee509ccommand=deployVirtualMachineresponse=jsondiskofferingid=543
 e345e-645a-4bf9-bd4e-af1db46470e7serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
 This deployment failed with below error 
 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
 Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
 parameter is needed to deploy VM or the hypervisor parameter value passed is 
 invalid
 Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7522) RPM builds should exit status 1, if there are failure in MVN build

2014-09-10 Thread Rayees Namathponnan (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan updated CLOUDSTACK-7522:

Priority: Blocker  (was: Major)

 RPM builds should exit status 1, if there are failure in MVN build 
 ---

 Key: CLOUDSTACK-7522
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7522
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Damodar Reddy T
Priority: Blocker
 Fix For: 4.5.0


 Steps to reproduce 
  execute RPM build command 
 var=$(bash ./package.sh --pack noredist --build)
  while executing MVN command kill java killall -9 java
 see the output,  echo $var to see the output
 Expected result 
 RPM build should exited error
 Actual result
 RPM build not exited with error , it return Done, see the output 
 .cloudstack.framework.config.impl.ConfigDepotAdminTest log4j:WARN No 
 appenders could be found for logger 
 (org.apache.cloudstack.framework.config.impl.ConfigDepotImpl). log4j:WARN 
 Please initialize the log4j system properly. log4j:WARN See 
 http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Tests 
 run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.091 sec Results : 
 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- 
 maven-jar-plugin:2.4:jar (default-jar) @ cloud-framework-config --- [INFO] 
 Building jar: 
 /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/framework/config/target/cloud-framework-config-4.5.0-SNAPSHOT.jar
  [INFO] [INFO] --- maven-site-plugin:3.3:attach-descriptor 
 (attach-descriptor) @ cloud-framework-config --- [INFO] [INFO] 
  
 [INFO] Building Apache CloudStack API 4.5.0-SNAPSHOT [INFO] 
  
 [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-api 
 --- [INFO] Deleting 
 /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api
  (includes = [target, dist], excludes = []) [INFO] [INFO] --- 
 maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-api --- 
 [INFO] Starting audit... Audit done. [INFO] [INFO] --- 
 maven-remote-resources-plugin:1.3:process (default) @ cloud-api --- [INFO] 
 [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
 cloud-api --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to 
 copy filtered resources. [INFO] Copying 4 resources [INFO] Copying 3 
 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile 
 (default-compile) @ cloud-api --- [INFO] Compiling 939 source files to 
 /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api/target/classes
  RPM build errors: Done
 [root@build-test centos63]# vi package.sh
 Looks like this is happening after below commit 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=7ea7deded031b43042c68db0f7c5c6c8b21c18c2
 if revert this commit rpm exit with return 1, if there are issue with mvn 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report

2014-09-10 Thread Chandan Purushothama (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7493:
-
Attachment: client_managementLogs.zip

Jayapal,

It is the basic use case of egress rule that failed: The log snippet shown 
below is taken from client logs. Notice the parameters passed and the jobstatus.

{code}
2014-09-09 05:33:10,240 - DEBUG - Sending GET Cmd : 
createEgressFirewallRule===
2014-09-09 05:33:10,286 - DEBUG - === Jobid: 
856ae190-e3a6-4eb4-b682-234aeddc3484 Started ===
2014-09-09 05:33:10,286 - DEBUG - Payload: {'signature': 
'lsdLVNfCIelufUHs6LixL3riffw=', 'apiKey': 
u'nzr3aEbj9wPt-8pe8xsx510O7g_xfhA3xmozRaWajWqYmipFRoCqryYq8akuHmQ8Q-D7Px7ohg-MgRuBjzESbA',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'856ae190-e3a6-4eb4-b682-234aeddc3484'}
2014-09-09 05:33:10,286 - DEBUG - Sending GET Cmd : 
queryAsyncJobResult===
2014-09-09 05:33:10,315 - DEBUG - Response : {jobprocstatus : 0, created : 
u'2014-09-09T05:33:10+', cmd : 
u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd', 
userid : u'c00195ee-37d3-11e4-a979-ba3c937e668f', jobstatus : 0, jobid : 
u'856ae190-e3a6-4eb4-b682-234aeddc3484', jobresultcode : 0, jobinstanceid : 
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7', jobinstancetype : u'FirewallRule', 
accountid : u'c00185cc-37d3-11e4-a979-ba3c937e668f'}
2014-09-09 05:33:15,320 - DEBUG - === 
JobId:856ae190-e3a6-4eb4-b682-234aeddc3484 is Still Processing, Will TimeOut 
in:3595 
2014-09-09 05:33:15,321 - DEBUG - Payload: {'signature': 
'lsdLVNfCIelufUHs6LixL3riffw=', 'apiKey': 
u'nzr3aEbj9wPt-8pe8xsx510O7g_xfhA3xmozRaWajWqYmipFRoCqryYq8akuHmQ8Q-D7Px7ohg-MgRuBjzESbA',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'856ae190-e3a6-4eb4-b682-234aeddc3484'}
2014-09-09 05:33:15,321 - DEBUG - Sending GET Cmd : 
queryAsyncJobResult===
2014-09-09 05:33:15,341 - DEBUG - Response : {jobprocstatus : 0, created : 
u'2014-09-09T05:33:10+', jobresult : {networkid : 
u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e', protocol : u'all', fordisplay : True, 
cidrlist : u'0.0.0.0/0', tags : [], state : u'Active', id : 
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7'}, cmd : 
u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd', 
userid : u'c00195ee-37d3-11e4-a979-ba3c937e668f', jobstatus : 1, jobid : 
u'856ae190-e3a6-4eb4-b682-234aeddc3484', jobresultcode : 0, jobinstanceid : 
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7', jobresulttype : u'object', 
jobinstancetype : u'FirewallRule', accountid : 
u'c00185cc-37d3-11e4-a979-ba3c937e668f'}
2014-09-09 05:33:15,342 - DEBUG - ===Jobid:856ae190-e3a6-4eb4-b682-234aeddc3484 
; StartTime:Tue Sep  9 05:33:10 2014 ; EndTime:Tue Sep  9 05:33:15 2014 ; 
TotalTime:-5===
2014-09-09 05:33:15,342 - DEBUG - Response : {jobprocstatus : 0, created : 
u'2014-09-09T05:33:10+', jobresult : {networkid : 
u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e', protocol : u'all', fordisplay : True, 
cidrlist : u'0.0.0.0/0', tags : [], state : u'Active', id : 
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7'}, cmd : 
u'org.apache.cloudstack.api.command.user.firewall.CreateEgressFirewallRuleCmd', 
userid : u'c00195ee-37d3-11e4-a979-ba3c937e668f', jobstatus : 1, jobid : 
u'856ae190-e3a6-4eb4-b682-234aeddc3484', jobresultcode : 0, jobinstanceid : 
u'cfdbb542-bd36-41c2-9b8f-9e74f1b94bc7', jobresulttype : u'object', 
jobinstancetype : u'FirewallRule', accountid : 
u'c00185cc-37d3-11e4-a979-ba3c937e668f'}
{code}

I attached the management server log and test client execution logs to the bug 
report,

Thank you,
Chandan.

 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 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: Rajesh Battala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: client_managementLogs.zip


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG

[jira] [Commented] (CLOUDSTACK-6360) Usage server failed to start with 4.4 build

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129160#comment-14129160
 ] 

ASF subversion and git services commented on CLOUDSTACK-6360:
-

Commit 90287cc60aca81fb9a372584936c557d446739f9 in cloudstack's branch 
refs/heads/master from rayeesn
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=90287cc ]

CLOUDSTACK-6360: adding mysql-connector to class path and it will be loaded 
while starting cloudstack-usage


 Usage server failed to start with 4.4 build
 ---

 Key: CLOUDSTACK-6360
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6360
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.3.0, 4.4.0
 Environment: 4.4 Build
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Priority: Critical
 Fix For: 4.4.0


 step 1 : Create 4.4 build and install usage server
 step 2 : start usage sever 
 Result 
 Failed to start usage server with below error 
 java.lang.UnsupportedClassVersionError: com/cloud/usage/UsageServer : 
 Unsupported major.minor version 51.0
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
 at 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
 at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
 at 
 org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:151)
 08/04/2014 12:32:19 5982 jsvc.exec error: Cannot load daemon
 08/04/2014 12:32:19 5980 jsvc.exec error: Service exit with a return value of 
 3
 cloudstack-usage.err (END)
 We already defined 4.4 support with JAVA IP, but usage server trying to start 
 with 1.6 
 we need to fix this in vi /etc/rc.d/init.d/cloudstack-usage
 # The first existing directory is used for JAVA_HOME (if JAVA_HOME is not 
 defined in $DEFAULT)
 JDK_DIRS=/usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-openjdk-i386 
 /usr/lib/jvm/java-6-openjdk-amd64 /usr/lib/jvm/java-6-sun 
 /usr/lib/jvm/jre-1.6.0 /usr/lib/j2sdk1.5-sun /usr/lib/jre-openjdk



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7523) java.lang.NullPointerException when listing accounts.

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129163#comment-14129163
 ] 

ASF subversion and git services commented on CLOUDSTACK-7523:
-

Commit 7a555b398fffafcca0a88aed56c6f8d57d8b3ae1 in cloudstack's branch 
refs/heads/master from [~frank.zhang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a555b3 ]

CLOUDSTACK-7523
java.lang.NullPointerException when listing accounts


  java.lang.NullPointerException when listing accounts.
 --

 Key: CLOUDSTACK-7523
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7523
 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: Build from master
Reporter: Sangeetha Hariharan
Assignee: frank zhang
Priority: Critical
 Fix For: 4.5.0


 Deploy a fresh Management server.
 After this try to list Accounts , by going to Accounts tab in UI.
 There is no entries returned and the UI keeps spinning.
 listAccounts() fail with return code - 530 .
  
 2014-09-09 12:38:59,932 INFO  [a.c.c.a.ApiServer] 
 (catalina-exec-18:ctx-0c561c21 ctx-dcbc1d59) (userId=2 accountId=2 
 sessionId=600DA8E1BD8DC8B8DF75DD5B5FC9E7E9) 10.215.3.17 -- GET 
 command=listAccountsresponse=jsonsessionkey=2%2Bf%2BWC0FhPn6j%2BiLp3mj2POhdsY%3DlistAll=truepage=1pagesize=20_=1410305103203
  530 null
 Following exception seen in management server logs:
 2014-09-09 08:39:22,417 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-7:ctx-d2a3ffdc) ===START===  10.216.50.29 -- GET  
 command=listAccountsresponse=jsonsessionkey=XkWSjL0e3Xe3ckgR5jW2CsSYOeA%3DlistAll=truepage=1pagesize=20_=1410290672605
 2014-09-09 08:39:22,832 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-d2a3ffdc 
 ctx-9db713ee) unhandled exception executing api command: 
 [Ljava.lang.String;@1a1bdce4
 java.lang.NullPointerException
 at 
 com.cloud.api.query.dao.AccountJoinDaoImpl.setResourceLimits(AccountJoinDaoImpl.java:144)
 at 
 com.cloud.api.query.dao.AccountJoinDaoImpl.newAccountResponse(AccountJoinDaoImpl.java:79)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.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 com.sun.proxy.$Proxy111.newAccountResponse(Unknown Source)
 at com.cloud.api.ApiDBUtils.newAccountResponse(ApiDBUtils.java:1788)
 at 
 com.cloud.api.query.ViewResponseHelper.createAccountResponse(ViewResponseHelper.java:353)
 at 
 com.cloud.api.query.QueryManagerImpl.searchForAccounts(QueryManagerImpl.java:1835)
 at 
 org.apache.cloudstack.api.command.user.account.ListAccountsCmd.execute(ListAccountsCmd.java:93)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:273)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:117)
 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:114)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:76)
 at

[jira] [Commented] (CLOUDSTACK-6278) Baremetal Advanced Networking support

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129162#comment-14129162
 ] 

ASF subversion and git services commented on CLOUDSTACK-6278:
-

Commit e06fa18ed2ee2ee6a417e089cf5ac6bde11d0079 in cloudstack's branch 
refs/heads/master from [~frank.zhang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e06fa18 ]

CLOUDSTACK-6278
Baremetal Advanced Networking support


 Baremetal Advanced Networking support
 -

 Key: CLOUDSTACK-6278
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6278
 Project: CloudStack
  Issue Type: New Feature
  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


 functional spec link: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Baremetal+Advanced+Networking+Support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang reassigned CLOUDSTACK-7462:


Assignee: Jessica Wang

 UI: Edit tags buttons do not work on ACL List tab
 -

 Key: CLOUDSTACK-7462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
Assignee: Jessica Wang
 Attachments: tags_jsonobj_empty.jpg


 Steps to reproduce:
 -Go to Network
 -Select VPC view from the dropdown
 -Create a VPC if there is none present
 -On a VPC, click on Configure button
 -If needed, proceed and set the minimal required settings (eg. tier)
 -Click on the Routers Network ACL Lists button, the ACLs are now listed
 -Click on any item to open its detail view
 -Select the ACL List Rules tab
 Click on the Edit tags button of any the existing entries in the grid
 Expected result:
 -Tag editor should appear and tags should be editable
 Actual result:
 -Tag editor appears, but empty. Missing features: list, add, remove tags.
 Note:
 -Tag editor has a Done button, so it can be closed and the user can proceed 
 using the UI, however tags are not listable and editable. Loss of tags 
 functionality.
 -The issue is seems to be related to CLOUDSTACK-5486.
 -Screenshot attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab

2014-09-10 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang resolved CLOUDSTACK-7462.
--
Resolution: Fixed

 UI: Edit tags buttons do not work on ACL List tab
 -

 Key: CLOUDSTACK-7462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
Assignee: Jessica Wang
 Attachments: tags_jsonobj_empty.jpg


 Steps to reproduce:
 -Go to Network
 -Select VPC view from the dropdown
 -Create a VPC if there is none present
 -On a VPC, click on Configure button
 -If needed, proceed and set the minimal required settings (eg. tier)
 -Click on the Routers Network ACL Lists button, the ACLs are now listed
 -Click on any item to open its detail view
 -Select the ACL List Rules tab
 Click on the Edit tags button of any the existing entries in the grid
 Expected result:
 -Tag editor should appear and tags should be editable
 Actual result:
 -Tag editor appears, but empty. Missing features: list, add, remove tags.
 Note:
 -Tag editor has a Done button, so it can be closed and the user can proceed 
 using the UI, however tags are not listable and editable. Loss of tags 
 functionality.
 -The issue is seems to be related to CLOUDSTACK-5486.
 -Screenshot attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129262#comment-14129262
 ] 

ASF subversion and git services commented on CLOUDSTACK-7462:
-

Commit a39bf18bc7eb3c55286ed74aa473e32cbe980ec8 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a39bf18 ]

CLOUDSTACK-7462: UI  Network  VPC  Router  Network ACL Lists  click an 
entry from list  Details tab  ACL List Rules tab  click Edit icon on any 
existing rule  fix the JavaScript error args.jsonObj is undefined.


 UI: Edit tags buttons do not work on ACL List tab
 -

 Key: CLOUDSTACK-7462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
 Attachments: tags_jsonobj_empty.jpg


 Steps to reproduce:
 -Go to Network
 -Select VPC view from the dropdown
 -Create a VPC if there is none present
 -On a VPC, click on Configure button
 -If needed, proceed and set the minimal required settings (eg. tier)
 -Click on the Routers Network ACL Lists button, the ACLs are now listed
 -Click on any item to open its detail view
 -Select the ACL List Rules tab
 Click on the Edit tags button of any the existing entries in the grid
 Expected result:
 -Tag editor should appear and tags should be editable
 Actual result:
 -Tag editor appears, but empty. Missing features: list, add, remove tags.
 Note:
 -Tag editor has a Done button, so it can be closed and the user can proceed 
 using the UI, however tags are not listable and editable. Loss of tags 
 functionality.
 -The issue is seems to be related to CLOUDSTACK-5486.
 -Screenshot attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang updated CLOUDSTACK-7462:
-
Attachment: after_my_checkin_2.PNG
after_my_checkin_1.PNG

 UI: Edit tags buttons do not work on ACL List tab
 -

 Key: CLOUDSTACK-7462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
Assignee: Jessica Wang
 Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, 
 tags_jsonobj_empty.jpg


 Steps to reproduce:
 -Go to Network
 -Select VPC view from the dropdown
 -Create a VPC if there is none present
 -On a VPC, click on Configure button
 -If needed, proceed and set the minimal required settings (eg. tier)
 -Click on the Routers Network ACL Lists button, the ACLs are now listed
 -Click on any item to open its detail view
 -Select the ACL List Rules tab
 Click on the Edit tags button of any the existing entries in the grid
 Expected result:
 -Tag editor should appear and tags should be editable
 Actual result:
 -Tag editor appears, but empty. Missing features: list, add, remove tags.
 Note:
 -Tag editor has a Done button, so it can be closed and the user can proceed 
 using the UI, however tags are not listable and editable. Loss of tags 
 functionality.
 -The issue is seems to be related to CLOUDSTACK-5486.
 -Screenshot attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129294#comment-14129294
 ] 

Jessica Wang commented on CLOUDSTACK-7462:
--


Problem:
--- 
as described in the reporter


QA notes:
-
Steps to reproduce:
UI  Network  VPC  Router  Network ACL Lists  click an entry from list  
Details tab  ACL List Rules tab  click Edit icon on any existing rule 
 

Expected result:
-
Edit tags pops up successfully (as in my attached screenshot 
after_my_checkin_2)

 UI: Edit tags buttons do not work on ACL List tab
 -

 Key: CLOUDSTACK-7462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
Assignee: Jessica Wang
  Labels: DEVREV
 Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, 
 tags_jsonobj_empty.jpg


 Steps to reproduce:
 -Go to Network
 -Select VPC view from the dropdown
 -Create a VPC if there is none present
 -On a VPC, click on Configure button
 -If needed, proceed and set the minimal required settings (eg. tier)
 -Click on the Routers Network ACL Lists button, the ACLs are now listed
 -Click on any item to open its detail view
 -Select the ACL List Rules tab
 Click on the Edit tags button of any the existing entries in the grid
 Expected result:
 -Tag editor should appear and tags should be editable
 Actual result:
 -Tag editor appears, but empty. Missing features: list, add, remove tags.
 Note:
 -Tag editor has a Done button, so it can be closed and the user can proceed 
 using the UI, however tags are not listable and editable. Loss of tags 
 functionality.
 -The issue is seems to be related to CLOUDSTACK-5486.
 -Screenshot attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jessica Wang closed CLOUDSTACK-7462.

UI: Edit tags buttons do not work on ACL List tab
-

Key: CLOUDSTACK-7462
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
Assignee: Jessica Wang
Labels: DEVREV
Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG,
tags_jsonobj_empty.jpg

Steps to reproduce:
-Go to Network
-Select VPC view from the dropdown
-Create a VPC if there is none present
-On a VPC, click on Configure button
-If needed, proceed and set the minimal required settings (eg. tier)
-Click on the Routers Network ACL Lists button, the ACLs are now listed
-Click on any item to open its detail view
-Select the ACL List Rules tab
Click on the Edit tags button of any the existing entries in the grid
Expected result:
-Tag editor should appear and tags should be editable
Actual result:
-Tag editor appears, but empty. Missing features: list, add, remove tags.
Note:
-Tag editor has a Done button, so it can be closed and the user can proceed
using the UI, however tags are not listable and editable. Loss of tags
functionality.
-The issue is seems to be related to CLOUDSTACK-5486.
-Screenshot attached.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7462) UI: Edit tags buttons do not work on ACL List tab


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang updated CLOUDSTACK-7462:
-
Labels: DEVREV  (was: )

 UI: Edit tags buttons do not work on ACL List tab
 -

 Key: CLOUDSTACK-7462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
Reporter: Gabor Apati-Nagy
Assignee: Jessica Wang
  Labels: DEVREV
 Attachments: after_my_checkin_1.PNG, after_my_checkin_2.PNG, 
 tags_jsonobj_empty.jpg


 Steps to reproduce:
 -Go to Network
 -Select VPC view from the dropdown
 -Create a VPC if there is none present
 -On a VPC, click on Configure button
 -If needed, proceed and set the minimal required settings (eg. tier)
 -Click on the Routers Network ACL Lists button, the ACLs are now listed
 -Click on any item to open its detail view
 -Select the ACL List Rules tab
 Click on the Edit tags button of any the existing entries in the grid
 Expected result:
 -Tag editor should appear and tags should be editable
 Actual result:
 -Tag editor appears, but empty. Missing features: list, add, remove tags.
 Note:
 -Tag editor has a Done button, so it can be closed and the user can proceed 
 using the UI, however tags are not listable and editable. Loss of tags 
 functionality.
 -The issue is seems to be related to CLOUDSTACK-5486.
 -Screenshot attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.

[
https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129408#comment-14129408
]

Nitin Mehta commented on CLOUDSTACK-5685:
-

Basically the logic is something like this
Keleven has made VirtualNetworkApplianceManagerImpl.java (router's Manager)
listener to vm's state transitions.
So whenever a state transition happens and if it is a VR and old state =
stopped and new state = running and the event which triggered is out of band
(FollowAgentPowerOnReport) then reboot the router through CS which would
result in reprogramming the rules as well.

[Vmsync] - When VR is rebooted outside of cloudstack , there is no change in
state detected by cloudstack resulting in VR not bieng programmed with any
rules.
--

Key: CLOUDSTACK-5685
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5685
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: Kelven Yang
Fix For: 4.4.0

[Vmsync] - When VR is rebooted outside of cloudstack , there is no change in
state detected by cloudstack resulting in VR not being programmed with any
rules.
PreReq:
Have few Vms deployed using Cloudstack.
Have PF,Static NAT,LB and Egress rules programmed for the Vms.
Steps:
Outside of Cloudstack, Reboot VR.
After the successful reboot of VR , there are no rules being programmed in
the VR for the Vms.
Currently , VM sync does not detect any change of state in the router when
router is rebooted. So there is no way for CS to know that the router needs
to be reprogrammed.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129406#comment-14129406
 ] 

Nitin Mehta commented on CLOUDSTACK-5685:
-

commit ee2adab7c7c9cf42eaf93c7eedb6dd32ebd8b501
Author: Kelven Yang kelv...@gmail.com
Date:   Mon Feb 10 16:58:49 2014 -0800

reboot VR if a out-of-band power-on event is detected

 [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in 
 state detected by cloudstack resulting in VR not bieng programmed with any 
 rules.
 --

 Key: CLOUDSTACK-5685
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5685
 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: Kelven Yang
 Fix For: 4.4.0


 [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in 
 state detected by cloudstack resulting in VR not being programmed with any 
 rules.
 PreReq:
 Have few Vms deployed using Cloudstack.
 Have PF,Static NAT,LB and Egress rules programmed for the Vms.
 Steps:
 Outside of Cloudstack, Reboot  VR.
 After the successful reboot of VR , there are no rules being programmed in 
 the VR for the Vms.
 Currently , VM sync does not detect any change of state in the router when 
 router is rebooted. So there is no way for CS to know that the router needs 
 to be reprogrammed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-5685) [Vmsync] - When VR is rebooted outside of cloudstack , there is no change in state detected by cloudstack resulting in VR not bieng programmed with any rules.

[
https://issues.apache.org/jira/browse/CLOUDSTACK-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129408#comment-14129408
]

Nitin Mehta edited comment on CLOUDSTACK-5685 at 9/11/14 12:07 AM:
---

Basically the logic is something like this
Kelven has made VirtualNetworkApplianceManagerImpl.java (router's Manager)
listener to vm's state transitions.
So whenever a state transition happens and if it is a VR and old state =
stopped and new state = running and the event which triggered is out of band
(FollowAgentPowerOnReport) then reboot the router through CS which would
result in reprogramming the rules as well.

was (Author: nitinme):
Basically the logic is something like this
Keleven has made VirtualNetworkApplianceManagerImpl.java (router's Manager)
listener to vm's state transitions.
So whenever a state transition happens and if it is a VR and old state =
stopped and new state = running and the event which triggered is out of band
(FollowAgentPowerOnReport) then reboot the router through CS which would
result in reprogramming the rules as well.

[Vmsync] - When VR is rebooted outside of cloudstack , there is no change in
state detected by cloudstack resulting in VR not bieng programmed with any
rules.
--

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs

Nitin Mehta created CLOUDSTACK-7533:
---

 Summary: Wrong download URL generated when using multiple SSVMs
 Key: CLOUDSTACK-7533
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Template
Affects Versions: 4.5.0
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129447#comment-14129447
 ] 

Nitin Mehta commented on CLOUDSTACK-7533:
-

I have multiple SSVMs and when the they try to download a template it fails 
because the URL which is generated goes to the wrong SSVM. Repro steps are:
Step1.In GUI
Templates-[Select Template]-Download Template.
Step2.Popup is displayed
Status
Please click http://localhost/userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova 
to download template
Step3.I clicked the URL,But Error.
Not Found
The requested URL /userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova was not 
found on this server.
In the logs we can see command to s-6-VM(Public IP:210.140.175.4)
2014-08-28 10:50:09,479 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Seq 27-1502609496: 
Sending { Cmd , MgmtId: 345048705118, via: 27(s-6-VM), Ver: v1, Flags: 100011, 
[{com.cloud.agent.api.storage.CreateEntityDownloadURLCommand:{installPath:template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova,parent:87db3e8a-360a-3ad1-bfad-ff4edc8e817c,extractLinkUUID:5de8b2dd-be47-465f-81bc-ee809d805f7d.ova,data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova,uuid:13e155cb-88f5-4ade-8a69-a60cd3e47edc,id:296,format:OVA,accountId:9,hvm:true,displayText:10G-TemplateFromVolume,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://jx.local/je01v-xc/standard,_role:Image}},name:9952142b1-11f7-3cc2-91d1-aa1a0e196453,hypervisorType:VMware}},accountId:0,wait:0}}]
 }
But the Public IP address of the Template-download-URL is 210.140.175.2 
(s-2-VM's Public IP)
2014-08-28 11:03:35,901 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Complete async 
job-30320, jobStatus: SUCCEEDED, resultCode: 0, result: 
org.apache.cloudstack.api.response.ExtractResponse/template/
{id:13e155cb-88f5-4ade-8a69-a60cd3e47edc,name:10G-TemplateFromVolume,accountid:5124ddac-553c-4287-b87b-594bbeed6cc5,state:DOWNLOAD_URL_CREATED,zoneid:af9c6a06-b56c-4853-9332-588f8a91d35c,zonename:je01v,extractMode:HTTP_DOWNLOAD,url:http://localhost/userdata/5de8b2dd-be47-465f-81bc-ee809d805f7d.ova}

 Wrong download URL generated when using multiple SSVMs
 --

 Key: CLOUDSTACK-7533
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.5.0
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs

2014-09-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129447#comment-14129447
 ] 

Nitin Mehta edited comment on CLOUDSTACK-7533 at 9/11/14 12:44 AM:
---

I have multiple SSVMs and when the they try to download a template it fails 
because the URL which is generated goes to the wrong SSVM. Repro steps are:

Step1.In GUI
Templates-[Select Template]-Download Template.

Step2.Popup is displayed
Status
Please click http://localhost/userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova 
to download template

Step3.I clicked the URL,But Error.
Not Found
The requested URL /userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova was not 
found on this server.
In the logs we can see command to s-6-VM(Public IP:x)

2014-08-28 10:50:09,479 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Seq 27-1502609496: 
Sending { Cmd , MgmtId: 345048705118, via: 27(s-6-VM), Ver: v1, Flags: 100011, 
[{com.cloud.agent.api.storage.CreateEntityDownloadURLCommand:{installPath:template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova,parent:87db3e8a-360a-3ad1-bfad-ff4edc8e817c,extractLinkUUID:5de8b2dd-be47-465f-81bc-ee809d805f7d.ova,data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova,uuid:13e155cb-88f5-4ade-8a69-a60cd3e47edc,id:296,format:OVA,accountId:9,hvm:true,displayText:10G-TemplateFromVolume,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://jx.local/je01v-xc/standard,_role:Image}},name:9952142b1-11f7-3cc2-91d1-aa1a0e196453,hypervisorType:VMware}},accountId:0,wait:0}}]
 }
But the Public IP address of the Template-download-URL is 210.140.175.2 
(s-2-VM's Public IP)
2014-08-28 11:03:35,901 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Complete async 
job-30320, jobStatus: SUCCEEDED, resultCode: 0, result: 
org.apache.cloudstack.api.response.ExtractResponse/template/
{id:13e155cb-88f5-4ade-8a69-a60cd3e47edc,name:10G-TemplateFromVolume,accountid:5124ddac-553c-4287-b87b-594bbeed6cc5,state:DOWNLOAD_URL_CREATED,zoneid:af9c6a06-b56c-4853-9332-588f8a91d35c,zonename:je01v,extractMode:HTTP_DOWNLOAD,url:http://localhost/userdata/5de8b2dd-be47-465f-81bc-ee809d805f7d.ova}


was (Author: nitinme):
I have multiple SSVMs and when the they try to download a template it fails 
because the URL which is generated goes to the wrong SSVM. Repro steps are:
Step1.In GUI
Templates-[Select Template]-Download Template.
Step2.Popup is displayed
Status
Please click http://localhost/userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova 
to download template
Step3.I clicked the URL,But Error.
Not Found
The requested URL /userdata/f1d07d2d-0756-4231-962b-c39ae9ee68b9.ova was not 
found on this server.
In the logs we can see command to s-6-VM(Public IP:210.140.175.4)
2014-08-28 10:50:09,479 DEBUG [c.c.a.t.Request] 
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Seq 27-1502609496: 
Sending { Cmd , MgmtId: 345048705118, via: 27(s-6-VM), Ver: v1, Flags: 100011, 
[{com.cloud.agent.api.storage.CreateEntityDownloadURLCommand:{installPath:template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova,parent:87db3e8a-360a-3ad1-bfad-ff4edc8e817c,extractLinkUUID:5de8b2dd-be47-465f-81bc-ee809d805f7d.ova,data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/9/296/9952142b1-11f7-3cc2-91d1-aa1a0e196453.ova,uuid:13e155cb-88f5-4ade-8a69-a60cd3e47edc,id:296,format:OVA,accountId:9,hvm:true,displayText:10G-TemplateFromVolume,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://jx.local/je01v-xc/standard,_role:Image}},name:9952142b1-11f7-3cc2-91d1-aa1a0e196453,hypervisorType:VMware}},accountId:0,wait:0}}]
 }
But the Public IP address of the Template-download-URL is 210.140.175.2 
(s-2-VM's Public IP)
2014-08-28 11:03:35,901 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-19:ctx-5e736e89 job-30320 ctx-3b8f0421) Complete async 
job-30320, jobStatus: SUCCEEDED, resultCode: 0, result: 
org.apache.cloudstack.api.response.ExtractResponse/template/
{id:13e155cb-88f5-4ade-8a69-a60cd3e47edc,name:10G-TemplateFromVolume,accountid:5124ddac-553c-4287-b87b-594bbeed6cc5,state:DOWNLOAD_URL_CREATED,zoneid:af9c6a06-b56c-4853-9332-588f8a91d35c,zonename:je01v,extractMode:HTTP_DOWNLOAD,url:http://localhost/userdata/5de8b2dd-be47-465f-81bc-ee809d805f7d.ova}

 Wrong download URL generated when using multiple SSVMs
 --

 Key: CLOUDSTACK-7533
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.5.0
Reporter: Nitin Mehta

[jira] [Commented] (CLOUDSTACK-7533) Wrong download URL generated when using multiple SSVMs


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129450#comment-14129450
 ] 

ASF subversion and git services commented on CLOUDSTACK-7533:
-

Commit f3b5a6ebc70d5bfb2c77b6aa359d7eb79b4507e5 in cloudstack's branch 
refs/heads/master from [~nitinme]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f3b5a6e ]

CLOUDSTACK-7533: Wrong download URL is generated when using multiple SSVMs in a 
zone. The public ip of the url would sometime point to the wrong ssvm when the 
url was created on another one.
Fix the bug by removing the command CreateEntityDownloadURLCommand from the 
host delegation. This results in same ssvm for creating the symlink on ssvm and 
same public ip being used for generating the url on MS.


 Wrong download URL generated when using multiple SSVMs
 --

 Key: CLOUDSTACK-7533
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7533
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.5.0
Reporter: Nitin Mehta
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report

2014-09-10 Thread Rajesh Battala (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajesh Battala updated CLOUDSTACK-7493:
---
Assignee: Jayapal Reddy  (was: Rajesh Battala)

 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 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: Jayapal Reddy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: client_managementLogs.zip


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
 10.220.165.184
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script: 
 firewall_egress.sh with args:  -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604:  { Cmd , 
 MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604:  { Ans: , 
 MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector 
 found 0 templates to clean up in storage pool: 
 XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 templates to cleanup on template_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 snapshots to cleanup on snapshot_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 volumes to cleanup on volume_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) firewall_egress.sh execution result: true
 2014-09-03 18:04:37,940 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq

[jira] [Commented] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129593#comment-14129593
 ] 

Jayapal Reddy commented on CLOUDSTACK-7493:
---

Hi Chandan,

The attached logs did not have information about the failure. All the logs are 
showing success.


1. Can you please attach logs for PROVING the rules got failed in VR ? How are 
you saying it is failing VR ?
After rule configuration is your egress traffic is not going out ?
After rule configuration did you see iptables rules configuration on the VR and 
saying it got failed ?

2. Is the rules configuration success when you run manually ?

Please provide relevant logs for this bug description.

Thanks,
Jayapal




 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 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: Jayapal Reddy
Priority: Blocker
 Fix For: 4.5.0

 Attachments: client_managementLogs.zip


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
 10.220.165.184
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script: 
 firewall_egress.sh with args:  -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604:  { Cmd , 
 MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604:  { Ans: , 
 MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector 
 found 0 templates to clean up in storage pool: 
 XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 templates to cleanup on template_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 snapshots to cleanup on snapshot_store_ref for

[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-7493:
--
Assignee: Chandan Purushothama  (was: Jayapal Reddy)

 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 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: Blocker
 Fix For: 4.5.0

 Attachments: client_managementLogs.zip


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
 10.220.165.184
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script: 
 firewall_egress.sh with args:  -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604:  { Cmd , 
 MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604:  { Ans: , 
 MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector 
 found 0 templates to clean up in storage pool: 
 XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 templates to cleanup on template_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 snapshots to cleanup on snapshot_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 volumes to cleanup on volume_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) firewall_egress.sh execution result: true
 2014-09-03 18:04:37,940 DEBUG [c.c.a.m.DirectAgentAttache]

[jira] [Comment Edited] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129593#comment-14129593
 ] 

Jayapal Reddy edited comment on CLOUDSTACK-7493 at 9/11/14 4:14 AM:


Hi Chandan,

The attached logs did not have information about the failure. All the logs are 
showing success.


1. Can you please attach logs for PROVING the rules got failed in VR ? How are 
you saying it is failing VR ?
After rule configuration is your egress traffic is not going out ?
After rule configuration did you see iptables rules configuration on the VR and 
saying it got failed ?

2. Is the rules configuration success when you run manually ?

If you assume failure from the details it is not true. The details is shown 
script execution logs which can be ignored. Only see the result. 

[{com.cloud.agent.api.Answer:{result:true,details:iptables v1.4.14: 
Couldn't load target `_FW_EGRESS_RULES':No such file or directory\n\nTry 
`iptables -h' or 'iptables --help' for more information.\niptables: No 
chain/target/match by that name.\niptables: No chain/target/match by that 
name.\niptables: No chain/target/match by that name.\niptables v1.4.14: 
Couldn't load target `_FW_EGRESS_RULES':No such file or directory\n\nTry 
`iptables -h' or 'iptables --help' for more information.\niptables: No 
chain/target/match by that name.\niptables: No chain/target/match by that 
name.\n,wait:0}}] }

Please provide relevant logs for this bug description.

Thanks,
Jayapal





was (Author: jayapal):
Hi Chandan,

The attached logs did not have information about the failure. All the logs are 
showing success.


1. Can you please attach logs for PROVING the rules got failed in VR ? How are 
you saying it is failing VR ?
After rule configuration is your egress traffic is not going out ?
After rule configuration did you see iptables rules configuration on the VR and 
saying it got failed ?

2. Is the rules configuration success when you run manually ?

Please provide relevant logs for this bug description.

Thanks,
Jayapal




 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 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: Blocker
 Fix For: 4.5.0

 Attachments: client_managementLogs.zip


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
 10.220.165.184
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]

[jira] [Reopened] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sailaja Mada reopened CLOUDSTACK-7498:
--

This issue is reproducible.  With user logout/login to the UI , it works fine 
first time.  Second time it gets into the issue again.   

 [UI] Register ISO option is failing to invoke ISO registration page with 
 ReferenceError: osTypeObjs is not defined
 --

 Key: CLOUDSTACK-7498
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7498
 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: Sailaja Mada
Priority: Critical
 Attachments: registerisoUI.png


 Steps:
 1. Install 4.5 cloudstack
 2. Access Management Server UI and tried register ISO 
 Observations :
 1. It is not invoking Register ISO page and failing with ReferenceError: 
 osTypeObjs is not defined
 Attached the screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129617#comment-14129617
 ] 

Jayapal Reddy commented on CLOUDSTACK-7493:
---

You can ignore the errors in details and check only result.
I was suspecting that you might be looking at the logs in details. So same 
thing I have updated in the bug.
But when you file if it has out this explicitly then it might has closed that 
day only.

In VR when we run the script we try to delete before creating. Such commands 
cause these errors.
We can suppress these messages in the script it self.

With updated calling script mechanism, the script got called from the host 
itself. Earlier the script called from
vmops so that error logs are not passed to MS.

Thanks,
Jayapal

 [Automation] Egress Firewall Rule fails to create on the Virtual Router in 
 Hyper-V Setup - Reports Success instead of failure report
 

 Key: CLOUDSTACK-7493
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
 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: Blocker
 Fix For: 4.5.0

 Attachments: client_managementLogs.zip


 ==
 Error in management Server log:
 ==
 {code}
 2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===  
 10.220.135.217 -- GET  
 jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Sending  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request] 
 (API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq 
 1-4477422454536405316: Executing:  { Cmd , MgmtId: 174253150778429, via: 
 1(10.220.163.36), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
  }
 2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP : 
 10.220.165.184
 2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script: 
 firewall_egress.sh with args:  -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
 2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604:  { Cmd , 
 MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604:  { Ans: , 
 MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector 
 found 0 templates to clean up in storage pool: 
 XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
 2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector 
 found 0 templates to cleanup on template_store_ref for store: 
 cifs://10.220.163.36/storage/secondary
 2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl] 
 (StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage

[jira] [Resolved] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report