[jira] [Commented] (CLOUDSTACK-7424) [Automation] Failed to restart network

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7424:
---

1. In the automation test because restart network prior test cases caused the 
router to enter in stopping state. Please correct those.
2. For restart network test case update the test case to check the router state 
for 'Running/Stopped' before restarting network.

I am assigning this issue to Chandan, Please look at the above points. 
If there is real in cloudstack for router stopping state then update this bug 
and assign to me.

Thanks,
Jayapal


 [Automation] Failed to restart network
 --

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


 Error Executing the test case 
 *integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC*
 *Error Message*
 Job failed: {jobprocstatus : 0, created : u'2014-08-24T07:31:03+', cmd : 
 u'org.apache.cloudstack.api.command.user.network.RestartNetworkCmd', userid : 
 u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
 u'01faacdc-294b-4209-a855-2dc8ea0aa2b4', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Failed to restart 
 network'}, accountid : u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs 
 available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=multiple_ips_per_n
 *Stacktrace*
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /usr/local/lib/python2.7/dist-packages/ddt.py, line 114, in wrapper
 return func(self, *args, **kwargs)
   File 
 /root/cloudstack/test/integration/component/test_multiple_ips_per_nic.py, 
 line 1186, in test_network_restart_cleanup_false
 network.restart(self.apiclient, cleanup=False)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 
 2626, in restart
 return(apiclient.restartNetwork(cmd))
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 1899, in restartNetwork
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Job failed: {jobprocstatus : 0, created : u\'2014-08-24T07:31:03+\', cmd 
 : u\'org.apache.cloudstack.api.command.user.network.RestartNetworkCmd\', 
 userid : u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
 u\'01faacdc-294b-4209-a855-2dc8ea0aa2b4\', jobresultcode : 530, jobresulttype 
 : u\'object\', jobresult : {errorcode : 530, errortext : u\'Failed to restart 
 network\'}, accountid : u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=multiple_ips_per_n
 
 ==
 *Error in the Management Server Log*:
 ==
 {code}
 2014-08-24 07:31:03,602 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending apply static nat rules commands to the backend
 2014-08-24 07:31:03,621 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending apply vpc ip association commands to the backend
 2014-08-24 07:31:03,638 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending apply vpc ip association commands to the backend
 2014-08-24 07:31:03,640 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Sending network 
 shutdown to VpcVirtualRouter
 2014-08-24 07:31:03,653 DEBUG [c.c.n.NetworkModelImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Service 
 SecurityGroup is not supported in the network id=314
 2014-08-24 07:31:03,654 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending setup guest network command to the backend
 2014-08-24 07:31:03,663 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 

[jira] [Assigned] (CLOUDSTACK-7437) [Automation] Fix the script test_escalations_snapshots.py - unable to find a snapshot with id

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye reassigned CLOUDSTACK-7437:
--

Assignee: Gaurav Aradhye

 [Automation] Fix the script test_escalations_snapshots.py - unable to find 
 a snapshot with id
 ---

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


 Do not add the created snapshot to the cleanup resources since it has been 
 consciously deleted during the test case (test_01). Since the snapshot is no 
 longer there the cleanup_resources method results in an error.
 integration.component.test_escalations_snapshots.TestSnapshots.test_01_list_volume_snapshots_pagination
  (from nosetests)
 *Error Message*
 Job failed: {jobprocstatus : 0, created : u'2014-08-24T19:01:28+', 
 jobresult : {errorcode : 530, errortext : u'unable to find a snapshot with id 
 43'}, cmd : 
 u'org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd', userid 
 : u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
 u'0fb9d284-9908-4e37-b176-b83eb2792399', jobresultcode : 530, jobinstanceid : 
 u'2b4a7334-c477-4dbb-a870-3a6c1ed5fcfb', jobresulttype : u'object', 
 jobinstancetype : u'Snapshot', accountid : 
 u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=escalations_snapsh
 *Stacktrace*
   File /usr/lib/python2.7/unittest/case.py, line 361, in run
 self.tearDown()
   File 
 /root/cloudstack/test/integration/component/test_escalations_snapshots.py, 
 line 106, in tearDown
 cleanup_resources(self.apiClient, self.cleanup)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py, line 
 121, in cleanup_resources
 obj.delete(api_client)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 986, 
 in delete
 apiclient.deleteSnapshot(cmd)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 784, in deleteSnapshot
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Job failed: {jobprocstatus : 0, created : u\'2014-08-24T19:01:28+\', 
 jobresult : {errorcode : 530, errortext : u\'unable to find a snapshot with 
 id 43\'}, cmd : 
 u\'org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd\', 
 userid : u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
 u\'0fb9d284-9908-4e37-b176-b83eb2792399\', jobresultcode : 530, jobinstanceid 
 : u\'2b4a7334-c477-4dbb-a870-3a6c1ed5fcfb\', jobresulttype : u\'object\', 
 jobinstancetype : u\'Snapshot\', accountid : 
 u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=escalations_snapsh
 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-7425) [Automation] Failed to create network offering due to Invalid Service - Lb

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye reassigned CLOUDSTACK-7425:
--

Assignee: Gaurav Aradhye

 [Automation] Failed to create network offering due to Invalid Service - Lb
 --

 Key: CLOUDSTACK-7425
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7425
 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


 On Executing *test_persistent_networks.py* script, following error was seen 
 during creation of network offering.
 *nose.suite.ContextSuite context=TestRestartPersistentNetwork:setup* 
 *Error*
 Execute cmd: createnetworkoffering failed, due to: errorCode: 431, 
 errorText:Invalid service  Lb   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=persistent_network
 *Stacktrace*
   File /usr/local/lib/python2.7/dist-packages/nose/suite.py, line 208, in 
 run
 self.setUp()
   File /usr/local/lib/python2.7/dist-packages/nose/suite.py, line 291, in 
 setUp
 self.setupContext(ancestor)
   File /usr/local/lib/python2.7/dist-packages/nose/suite.py, line 314, in 
 setupContext
 try_run(context, names)
   File /usr/local/lib/python2.7/dist-packages/nose/util.py, line 470, in 
 try_run
 return func()
   File 
 /root/cloudstack/test/integration/component/test_persistent_networks.py, 
 line 1352, in setUpClass
 conservemode=False)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 
 2039, in create
 return NetworkOffering(apiclient.createNetworkOffering(cmd).__dict__)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 1864, in createNetworkOffering
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Execute cmd: createnetworkoffering failed, due to: errorCode: 431, 
 errorText:Invalid service  Lb\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=persistent_network
 
 ===
 Logs on Management Server:
 ===
 {code}
 2014-08-24 07:29:03,321 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-11:ctx-9045f4ed) ===START===  10.220.135.73 -- GET  
 apiKey=YuaraAK9l9g2KJCAw3APnrD2aNpVmhAesCvWFxlDvGCb0NcARH_sKQxfRM6WF-SCAxikI8awlxCrmw010lUFzgserviceproviderlist%5B2%5D.provider=VirtualRouterdisplaytext=Test+Nw+off+isolated+persistent-J1SARJserviceproviderlist%5B0%5D.service=Dhcpserviceproviderlist%5B4%5D.provider=VirtualRouterserviceproviderlist%5B1%5D.provider=VirtualRouteravailability=Optionalconservemode=Falseserviceproviderlist%5B3%5D.service=Dnsserviceproviderlist%5B0%5D.provider=VirtualRouterserviceproviderlist%5B1%5D.service=Lbserviceproviderlist%5B4%5D.service=PortForwardingsupportedservices=Dhcp%2CDns%2CSourceNat%2CPortForwarding%2C+Lbtraffictype=GUESTresponse=jsonname=Test+Nw+off+isolated+persistent-7NEHE0ispersistent=Trueserviceproviderlist%5B3%5D.provider=VirtualRouterguestiptype=Isolatedserviceproviderlist%5B2%5D.service=SourceNatcommand=createNetworkOfferingsignature=CSPMyaOuzQIuJ7pds6h0z1Zrz6Y%3D
 2014-08-24 07:29:03,324 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-25:ctx-4341a2a9 ctx-fe97e223 ctx-49ec168d) ===END===  
 10.220.135.73 -- GET  
 username=User-JEOYWOaccount=test-TestUserLogin-test_01_non_root_admin_Privileges-CCFZPYdomainid=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75firstname=Userlastname=Useremail=user%40test.comapiKey=YuaraAK9l9g2KJCAw3APnrD2aNpVmhAesCvWFxlDvGCb0NcARH_sKQxfRM6WF-SCAxikI8awlxCrmw010lUFzgcommand=createUsersignature=ibJAEjnOZiNMtVgyWqHd1HW4W3w%3Dresponse=json
 2014-08-24 07:29:03,332 INFO  [c.c.a.ApiServer] 
 (catalina-exec-11:ctx-9045f4ed ctx-fab16efe ctx-a9b84bb9) Invalid service  Lb
 2014-08-24 07:29:03,332 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-11:ctx-9045f4ed ctx-fab16efe ctx-a9b84bb9) ===END===  
 10.220.135.73 -- GET  
 

[jira] [Commented] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-6755:
--

Problem;
---
 GRE tunnel networks are internal networks in XenServer. A XenServer network 
created on a XenServer, is visible across the hosts in the clusters. Only on 
the first host on which a VM is launched there is a bridge created 
automatically. When a VM is launched on a different host in the cluster, but on 
the same network, VM start will fail with VM_REQUIRES_NETWORK exception as 
bridge is not automatically created by the Xenserver. To overcome this issue, 
there is a hack put into CloudStack, so that bridge is create for internal 
network that is backing GRE tunnel network. A vif is created on to the network 
and plugged in to dom0 which will result in the bridge getting created. But 
this approach will results in only creating 7 tunnel networks as for any 
dom0/domu only 7 vif's can be connected

Root Cause Analysis:
--
Root cause is using the dom0 vif connected to a GRE tunnel network as a forcing 
function to create bridge on the host. this VID is never deleted resulting in 
accumulation of vif's on dom0.

Proposed Solution:


Proposed solution is to ensure VIF gets deleted after bridge is created and at 
least one VIF (from the domU/guest VM's) is connected to the bridge. 

QA steps:
-

To verify the fix works. 

  - Please create more that 7 GRE tunnel networks and verify CloudStack no 
longer restricts only 7 GRE tunnel networks.
  - also verify there are no unnecessary VIF's (that are connected to GRE 
tunnel networks) attached to dom0.





 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

 Key: CLOUDSTACK-6755
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6755
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
  Labels: ovs
 Fix For: 4.4.0

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 

[jira] [Updated] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

[Murali Reddy (JIRA)]

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

Murali Reddy updated CLOUDSTACK-6755:
-

Labels: DEV_REVIEWED ovs  (was: ovs)

 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

 Key: CLOUDSTACK-6755
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6755
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 

[jira] [Updated] (CLOUDSTACK-6757) [OVS] Deleting networks does not unplug nics from dom0 on xenserver

[Murali Reddy (JIRA)]

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

Murali Reddy updated CLOUDSTACK-6757:
-

Labels: DEV_REVIEWED ovs  (was: ovs)

 [OVS] Deleting networks does not unplug nics from dom0 on xenserver
 ---

 Key: CLOUDSTACK-6757
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6757
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0


 [OVS] Deleting networks does not unplug nics from dom0 on xenserver
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with xen cluster
 2.Create physical network with GRE isolation
 3.Create network offering with virtual networking and ovs as the service 
 provider
 4.Create couple of guest networks with above network offering
 5.Deploy few vms in each network
 6.Delete the guest networks
 Expected Result:
 ==
 When CS creates tunnel networks it plugs a vif on dom0 for every tunnel 
 tunnetwork. However it does not unplug the vif from dom0 even-though the 
 network is deleted.
 Observations:
 ===
 We can see that bridge is getting deleted from the host bug the vif is not 
 getting unplugged from dom0.
 Attaching MS log file. Please look for bridge named OVSTunnel989 in the log 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-2251) Automation: Dedicated Resources - Public IP Addresses and VLANs per Tenant

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-2251: Automation - dedicated guest VLAN ranges feature


 Automation: Dedicated Resources - Public IP Addresses and VLANs per Tenant 
 ---

 Key: CLOUDSTACK-2251
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2251
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Sudha Ponnaganti
Assignee: Gaurav Aradhye
 Fix For: 4.3.0






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6757) [OVS] Deleting networks does not unplug nics from dom0 on xenserver

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-6757:
--

Problem;
---
GRE tunnel networks are internal networks in XenServer. A XenServer network 
created on a XenServer, is visible across the hosts in the clusters. Only on 
the first host on which a VM is launched there is a bridge created 
automatically. When a VM is launched on a different host in the cluster, but on 
the same network, VM start will fail with VM_REQUIRES_NETWORK exception as 
bridge is not automatically created by the Xenserver. To overcome this issue, 
there is a hack put into CloudStack, so that bridge is create for internal 
network that is backing GRE tunnel network. A vif is created on to the network 
and plugged in to dom0 which will result in the bridge getting created. This 
bug describes the scenario where the VIF's created on dom0 are not getting 
deleted when a network is deleted.

Root Cause Analysis:
--
Root cause is using the dom0 vif connected to a GRE tunnel network as a forcing 
function to create bridge on the host. this VID is never deleted even when a 
network object created on XenServer is deleted.

Proposed Solution:

Proposed solution is to get rid of the hack the use vif connected to dom0 as a 
forcing function to create bridge. With the fix in CLOUDSTACK-6925, we no 
longer need dom0 vif.

QA steps:
-

CLOUDSTACK-6925: actually fixes the use dom0 VIF issue. With CLOUDSTACK-6925, 
there is no longer any vif''s are connected to dom0. Please ensure when GRE 
tunnel network is created there is no VIF that gets plugged into dom0.

 [OVS] Deleting networks does not unplug nics from dom0 on xenserver
 ---

 Key: CLOUDSTACK-6757
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6757
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0


 [OVS] Deleting networks does not unplug nics from dom0 on xenserver
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with xen cluster
 2.Create physical network with GRE isolation
 3.Create network offering with virtual networking and ovs as the service 
 provider
 4.Create couple of guest networks with above network offering
 5.Deploy few vms in each network
 6.Delete the guest networks
 Expected Result:
 ==
 When CS creates tunnel networks it plugs a vif on dom0 for every tunnel 
 tunnetwork. However it does not unplug the vif from dom0 even-though the 
 network is deleted.
 Observations:
 ===
 We can see that bridge is getting deleted from the host bug the vif is not 
 getting unplugged from dom0.
 Attaching MS log file. Please look for bridge named OVSTunnel989 in the log 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-1466) [Automation] Limit Resources on domains/accounts

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-1466: Automation - Secondary Storage Test Cases


 [Automation] Limit Resources on domains/accounts 
 -

 Key: CLOUDSTACK-1466
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1466
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.1.0
Reporter: Girish Shilamkar
Assignee: Ashutosk Kelkar
Priority: Critical
 Fix For: 4.3.0

 Attachments: LimitResourcesTestPlan1.xlsx


 Automate attached test plan for feature - Limit resources on domain/accounts 
 (cpu/memory/primary storage/secondary storage)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-3014) unable to start instance because ssh to router is failing

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-3014:
--

Labels: DEV_REVIEWED  (was: )

 unable to start instance because ssh to router is failing
 -

 Key: CLOUDSTACK-3014
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3014
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: esx 5.1 , master build
Reporter: Srikanteswararao Talluri
Assignee: Jayapal Reddy
Priority: Blocker
  Labels: DEV_REVIEWED
 Fix For: 4.2.0

 Attachments: management-server.log.zip


 1. deploy an advanced zone with vmware esx 5.1 
 2. try to deploy a VM
 Following exception is encountered:
  Failed to authentication SSH user root on host 10.147.40.164
 2013-06-15 01:36:13,977 ERROR [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Unable to execute NetworkUsage command on DomR 
 (10.147.40.164), domR may not be ready yet. failure due to Exception: 
 java.lang.Exception
 Message: Failed to authentication SSH user root on host 10.147.40.164
 java.lang.Exception: Failed to authentication SSH user root on host 
 10.147.40.164
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(VmwareResource.java:5451)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2301)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:480)
   at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 2013-06-15 01:36:13,980 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Executing resource GetDomRVersionCmd: 
 {accessDetails:{router.ip:10.147.40.164,router.name:r-8-VM},wait:0}
 2013-06-15 01:36:13,980 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Run command on domR 10.147.40.164, 
 /opt/cloud/bin/get_template_version.sh 
 2013-06-15 01:36:13,981 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Use router's private IP for SSH control. IP : 
 10.147.40.164
 2013-06-15 01:36:14,081 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.101.255.119 -- GET  
 command=queryAsyncJobResultjobId=43dde7f6-fb5d-4ead-8691-5071feb44dfdresponse=jsonsessionkey=tN07%2BJ4GVSCHGNV%2FPjdO3V%2Bs3Tg%3D_=1371220848020
 2013-06-15 01:36:14,163 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===END===  10.101.255.119 -- GET  
 command=queryAsyncJobResultjobId=43dde7f6-fb5d-4ead-8691-5071feb44dfdresponse=jsonsessionkey=tN07%2BJ4GVSCHGNV%2FPjdO3V%2Bs3Tg%3D_=1371220848020
 2013-06-15 01:36:14,231 ERROR [utils.ssh.SshHelper] 
 (DirectAgent-18:10.147.40.30) Failed to authentication SSH user root on host 
 10.147.40.164
 2013-06-15 01:36:14,235 ERROR [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) GetDomRVersionCmd failed due to Exception: 
 java.lang.Exception
 Message: Failed to authentication SSH user root on host 10.147.40.164
 java.lang.Exception: Failed to authentication SSH user root on host 
 10.147.40.164
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2143)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:488)
   at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 

[jira] [Commented] (CLOUDSTACK-3014) unable to start instance because ssh to router is failing

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-3014:
---

Problem:
---
Start instance failed in vmware environment with below error.
Failed to authentication SSH user root on host 10.147.40.164 where 
10.147.40.164 is the router.

Root Cause Analysis:

SSH to router from the MS is failed because of the mismatch in public/private 
key mismatch.
As part of the cloudstck steup router private key and MS/host public key should 
have correct 
key pair.

chek the authorized_keys  is iso by mounting and .ssh/id_rsa.pub in MS (for 
VMware)/host (xen,kvm).
IF both are not same, QA used the old setup to test the iso this cause the 
issue.

This issue is setup issue in QA setup.

Proposed solution:
-
1. You should place the iso in MS
2. clear the host tags.
3. Force reconnect or restart the MS so that iso, all the files from the MS are 
pushed to host.
4. Destroy the system vms are recrated.


QA Verification steps:
---
ssh to VR from the MS/host should success.
VM create should also success.

Authomation test case is not required for this



 unable to start instance because ssh to router is failing
 -

 Key: CLOUDSTACK-3014
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3014
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: esx 5.1 , master build
Reporter: Srikanteswararao Talluri
Assignee: Jayapal Reddy
Priority: Blocker
  Labels: DEV_REVIEWED
 Fix For: 4.2.0

 Attachments: management-server.log.zip


 1. deploy an advanced zone with vmware esx 5.1 
 2. try to deploy a VM
 Following exception is encountered:
  Failed to authentication SSH user root on host 10.147.40.164
 2013-06-15 01:36:13,977 ERROR [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Unable to execute NetworkUsage command on DomR 
 (10.147.40.164), domR may not be ready yet. failure due to Exception: 
 java.lang.Exception
 Message: Failed to authentication SSH user root on host 10.147.40.164
 java.lang.Exception: Failed to authentication SSH user root on host 
 10.147.40.164
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(VmwareResource.java:5451)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2301)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:480)
   at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 2013-06-15 01:36:13,980 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Executing resource GetDomRVersionCmd: 
 {accessDetails:{router.ip:10.147.40.164,router.name:r-8-VM},wait:0}
 2013-06-15 01:36:13,980 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Run command on domR 10.147.40.164, 
 /opt/cloud/bin/get_template_version.sh 
 2013-06-15 01:36:13,981 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Use router's private IP for SSH control. IP : 
 10.147.40.164
 2013-06-15 01:36:14,081 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.101.255.119 -- GET  
 command=queryAsyncJobResultjobId=43dde7f6-fb5d-4ead-8691-5071feb44dfdresponse=jsonsessionkey=tN07%2BJ4GVSCHGNV%2FPjdO3V%2Bs3Tg%3D_=1371220848020
 2013-06-15 01:36:14,163 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===END===  10.101.255.119 -- GET  
 command=queryAsyncJobResultjobId=43dde7f6-fb5d-4ead-8691-5071feb44dfdresponse=jsonsessionkey=tN07%2BJ4GVSCHGNV%2FPjdO3V%2Bs3Tg%3D_=1371220848020
 2013-06-15 01:36:14,231 ERROR [utils.ssh.SshHelper] 
 

[jira] [Updated] (CLOUDSTACK-3014) instance start failed because mis match in VR ssh key pair

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-3014:
--

Summary: instance start failed because mis match in VR ssh key pair   (was: 
unable to start instance because ssh to router is failing)

 instance start failed because mis match in VR ssh key pair 
 ---

 Key: CLOUDSTACK-3014
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3014
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: esx 5.1 , master build
Reporter: Srikanteswararao Talluri
Assignee: Jayapal Reddy
Priority: Blocker
  Labels: DEV_REVIEWED
 Fix For: 4.2.0

 Attachments: management-server.log.zip


 1. deploy an advanced zone with vmware esx 5.1 
 2. try to deploy a VM
 Following exception is encountered:
  Failed to authentication SSH user root on host 10.147.40.164
 2013-06-15 01:36:13,977 ERROR [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Unable to execute NetworkUsage command on DomR 
 (10.147.40.164), domR may not be ready yet. failure due to Exception: 
 java.lang.Exception
 Message: Failed to authentication SSH user root on host 10.147.40.164
 java.lang.Exception: Failed to authentication SSH user root on host 
 10.147.40.164
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(VmwareResource.java:5451)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2301)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:480)
   at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   at java.util.concurrent.FutureTask.run(FutureTask.java:166)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
   at java.lang.Thread.run(Thread.java:679)
 2013-06-15 01:36:13,980 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Executing resource GetDomRVersionCmd: 
 {accessDetails:{router.ip:10.147.40.164,router.name:r-8-VM},wait:0}
 2013-06-15 01:36:13,980 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Run command on domR 10.147.40.164, 
 /opt/cloud/bin/get_template_version.sh 
 2013-06-15 01:36:13,981 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) Use router's private IP for SSH control. IP : 
 10.147.40.164
 2013-06-15 01:36:14,081 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.101.255.119 -- GET  
 command=queryAsyncJobResultjobId=43dde7f6-fb5d-4ead-8691-5071feb44dfdresponse=jsonsessionkey=tN07%2BJ4GVSCHGNV%2FPjdO3V%2Bs3Tg%3D_=1371220848020
 2013-06-15 01:36:14,163 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===END===  10.101.255.119 -- GET  
 command=queryAsyncJobResultjobId=43dde7f6-fb5d-4ead-8691-5071feb44dfdresponse=jsonsessionkey=tN07%2BJ4GVSCHGNV%2FPjdO3V%2Bs3Tg%3D_=1371220848020
 2013-06-15 01:36:14,231 ERROR [utils.ssh.SshHelper] 
 (DirectAgent-18:10.147.40.30) Failed to authentication SSH user root on host 
 10.147.40.164
 2013-06-15 01:36:14,235 ERROR [vmware.resource.VmwareResource] 
 (DirectAgent-18:10.147.40.30) GetDomRVersionCmd failed due to Exception: 
 java.lang.Exception
 Message: Failed to authentication SSH user root on host 10.147.40.164
 java.lang.Exception: Failed to authentication SSH user root on host 
 10.147.40.164
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
   at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2143)
   at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:488)
   at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at 

[jira] [Commented] (CLOUDSTACK-7218) [Automation] NPE observed while deleting account in automation run

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7218:
---

Problem:

Two public ips are set for static nat of vm ips. 
IP1 --vm1Ip1, IP2--vm1Ip2 (vm secondary ip).

Reproducing steps:

1) Create network.
2) Deploy the vm. Create a secondary ip address for vm. So the vm has 2 ips 
now: vIp1 and vIp2
3) Associate 2 public ip addresses to the network: IP1 and IP2
4) Enable 2 static nats: one for vIp1/IP1, another for vIp2/IP2
5) Delete the VM, Delete the network.

You will hit the NPE. Because during the vm expunge static nat will get 
disabled just for one of the public ip addresses.
 And the second one will still have the vmId assigned; and NPE will happen when 
we try to access the vm that no longer exists.


Root Cause Analysis:

VM is set to static nat, IP1--vm1Ip1, IP2--vm1Ip2.
While expunging the vm we deleted only one public ip static nat associated with 
the vm.
The below method _ipAddressDao.findByAssociatedVmId(vmId)  is getting the 
public ip and it returns only one ip.

Due to this on vm expunge only one ip static nat is removed and during the 
destroy network second public
ip trying to access deleted vm details caused the NPE.

Proposed solution:
--
In cleanup VM resources deleting all static nats associated with this vm.
Added findAllByAssociatedVmId method get all public ips associated static nat 
with this vm.

QA Verification steps:
---
1) Create network.
2) Deploy the vm. Create a secondary ip address for vm. So the vm has 2 ips 
now: vIp1 and vIp2
3) Associate 2 public ip addresses to the network: IP1 and IP2
4) Enable 2 static nats: one for vIp1/IP1, another for vIp2/IP2
5) Delete the VM, Delete the network.

Restart network should successful.

test_multiple_ips_per_nic.py:test_add_static_nat_rule test should pass.


 [Automation] NPE observed while deleting account in automation run
 --

 Key: CLOUDSTACK-7218
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7218
 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: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.5.0


 This issue is observed in automation log, NPE thrown while deleting account
 2014-07-31 02:20:56,102 DEBUG [c.c.n.r.RulesManagerImpl] 
 (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) There are no static 
 nat
  rules to apply for ip id=28
 2014-07-31 02:20:56,105 WARN  [c.c.u.AccountManagerImpl] 
 (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) Failed to cleanup 
 accou
 nt 
 Acct[b1cf2381-ab36-4ebc-90ff-f08acaf5e02d-test-account-TestVmNetworkOperations-test_add_static_nat_rule_1_ISOLATED-YI0OCS]
  due to
 java.lang.NullPointerException
 at 
 com.cloud.network.rules.RulesManagerImpl.createStaticNatForIp(RulesManagerImpl.java:1391)
 at 
 com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1321)
 at 
 com.cloud.network.rules.RulesManagerImpl.revokeAllPFAndStaticNatRulesForIp(RulesManagerImpl.java:1104)
 at sun.reflect.GeneratedMethodAccessor524.invoke(Unknown Source)
 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 
 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.$Proxy105.revokeAllPFAndStaticNatRulesForIp(Unknown 
 Source)
 at 
 com.cloud.network.IpAddressManagerImpl.cleanupIpResources(IpAddressManagerImpl.java:540)
 at 
 com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:936)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.cleanupNetworkResources(NetworkOrchestrator.java:2650)
 at 
 

[jira] [Updated] (CLOUDSTACK-7218) [Automation] NPE observed while deleting account in automation run

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7218:
--

Labels: DEV_REVIEWED  (was: )

 [Automation] NPE observed while deleting account in automation run
 --

 Key: CLOUDSTACK-7218
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7218
 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: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Priority: Critical
  Labels: DEV_REVIEWED
 Fix For: 4.5.0


 This issue is observed in automation log, NPE thrown while deleting account
 2014-07-31 02:20:56,102 DEBUG [c.c.n.r.RulesManagerImpl] 
 (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) There are no static 
 nat
  rules to apply for ip id=28
 2014-07-31 02:20:56,105 WARN  [c.c.u.AccountManagerImpl] 
 (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) Failed to cleanup 
 accou
 nt 
 Acct[b1cf2381-ab36-4ebc-90ff-f08acaf5e02d-test-account-TestVmNetworkOperations-test_add_static_nat_rule_1_ISOLATED-YI0OCS]
  due to
 java.lang.NullPointerException
 at 
 com.cloud.network.rules.RulesManagerImpl.createStaticNatForIp(RulesManagerImpl.java:1391)
 at 
 com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1321)
 at 
 com.cloud.network.rules.RulesManagerImpl.revokeAllPFAndStaticNatRulesForIp(RulesManagerImpl.java:1104)
 at sun.reflect.GeneratedMethodAccessor524.invoke(Unknown Source)
 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 
 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.$Proxy105.revokeAllPFAndStaticNatRulesForIp(Unknown 
 Source)
 at 
 com.cloud.network.IpAddressManagerImpl.cleanupIpResources(IpAddressManagerImpl.java:540)
 at 
 com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:936)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.cleanupNetworkResources(NetworkOrchestrator.java:2650)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2196)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:793)
 at 
 com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:667)
 at 
 com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1441)
 at sun.reflect.GeneratedMethodAccessor542.invoke(Unknown Source)
 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 
 org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 at 
 org.springframework.aop.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 

[jira] [Commented] (CLOUDSTACK-6923) deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-6923:
---

Problem:
---
LB stickiness policy can be deleted by Id, where as for listing LB stickiness 
policy by id in API is not there.

Root Cause Analysis:
---
listLBStickinessPolicies API was taking LBID to list stickiness policies 
associated with LB rule.
But in API there is param to list by id.

Proposed solution:
--
Added API param to list stickiness policies by id.

Verification steps:
---
1. Configure the LB rule with stickiness policy.
2. list all stickies associated with this LB rule using 
listLBStickinessPolicies.
3. Take id and list stickies by id.


 deleteLBStickinessPolicy takes in the id of stickiness policy but the list 
 stickiness policy doesn't take the stickiness id
 ---

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


 deleteLBStickinessPolicy takes in the id of stickiness policy but the list 
 stickiness policy doesn't take the stickiness id.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6923) deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-6923:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 deleteLBStickinessPolicy takes in the id of stickiness policy but the list 
 stickiness policy doesn't take the stickiness id
 ---

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


 deleteLBStickinessPolicy takes in the id of stickiness policy but the list 
 stickiness policy doesn't take the stickiness id.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6922) createFireWall and EgressFwRule share the same action event

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-6922:
---

Problem:

Create Firewall rule and Create Egress firewall rule action event is same.
There should be different event for each API flow.

Root Cause Analysis:

After calling create firewall rule PAI and create Egress firewall rule API in 
logs
action event for both is showing same. It also be seen in event table.

Proposed solution:
--
Updated firewall service for  seperate event for each API.

Verification steps:
--
1. Create firewall rule
2. Create Egress firewall rule.
3. logs and event table should show seperate event for each API



 createFireWall and EgressFwRule share the same action event
 ---

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


 3 fixes required here.
 createFireWall and EgressFwRule share the same action event - why ? This 
 should be changed.
 There is no started and completed action event for createFireWall and the 
 manager entry method is used by a lot of other apis, so how to put in the 
 action event annotation ?
 deleteFireWallRule - FIREWALL.CLOSE event is used by a bunch of apis. We need 
 to separate it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6922) createFireWall and EgressFwRule share the same action event

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-6922:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 createFireWall and EgressFwRule share the same action event
 ---

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


 3 fixes required here.
 createFireWall and EgressFwRule share the same action event - why ? This 
 should be changed.
 There is no started and completed action event for createFireWall and the 
 manager entry method is used by a lot of other apis, so how to put in the 
 action event annotation ?
 deleteFireWallRule - FIREWALL.CLOSE event is used by a bunch of apis. We need 
 to separate it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-6899:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 listNics doesn't have vm id in response but does take vm id as a param
 --

 Key: CLOUDSTACK-6899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
  Labels: AUTOMATION_REQ, DEV_REVIEWED
 Fix For: 4.4.0


 listNics API doesn't have vm id in response but does take vm id as a param



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6899) listNics doesn't have vm id in response but does take vm id as a param

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-6899:
---

Problem:
---
listnics API is taking vm id as param but in the response there is no vm id.

Root Cause Analysis:
---
In API response the vmid details is not included.

Proposed solution:

Included vmid details in the list nics API response.

Verification steps:
--
Call the listnics API with vmid param and verify that the vmid in response.



 listNics doesn't have vm id in response but does take vm id as a param
 --

 Key: CLOUDSTACK-6899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
  Labels: AUTOMATION_REQ, DEV_REVIEWED
 Fix For: 4.4.0


 listNics API doesn't have vm id in response but does take vm id as a param



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7246) VM deployment failed due to wrong in script name createipalias.sh

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7246:
--

Labels: DEV_REVIEWED  (was: )

 VM deployment failed due to wrong in  script name createipalias.sh
 --

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


 1. added multiple ip range.
 2. deployed vm in shared network failed.
 3. createipalias failed because cloudstack referring 'createipalias.sh' but 
 the file in VR is 'createIpAlias.sh'



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7246) VM deployment failed due to wrong in script name createipalias.sh

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7246:
---

Problem:

Deploying vm in shared network with multiple ip range is failed due to 
incorrect script name.

Root Cause Analysis:

Cloudstack is calling script with 'createipalias.sh' but the actual name is 
'createIpAlias.sh'

Reproducing steps:
--
1. add multiple ip range.
2. deploy vm in shared network to get ip from the added ip range.
3. createipalias failed because cloudstack referring 'createipalias.sh' but the 
file in VR is 'createIpAlias.sh'

Proposed solution:
--
Corrected the script name in VRScripts.java

Verification steps:
---
1. Add multiple ip range.
2. deploy vm in shared network to get ip from the added ip range.
3. VM deployment should successful and alias interface in VR should get created.


 VM deployment failed due to wrong in  script name createipalias.sh
 --

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


 1. added multiple ip range.
 2. deployed vm in shared network failed.
 3. createipalias failed because cloudstack referring 'createipalias.sh' but 
 the file in VR is 'createIpAlias.sh'



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7104) VPC public ips not configured after network implement from implementing

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7104:
---

Problem:

In VPC, network implemented after GC VPC public ips are configured on the VR.

Root Cause Analysis:
--
When network is implemented after GC, ipassoc is not performed on this network.
Due to this public ip address is not configured on VR.

Proposed solution:
--
In IpAddressManager we have method to check ipassoc is needed or not in 
checkIfIpAssocRequired.
Returning true when network state is implementing.

QA Verification steps:
---
1. create vpc and create tier in vpc.
2. Set network.gc to low in the global settings.
3. Acquire ip and configure PF rule on the ip.
4. Stop all the vms in the tier.
5. network will remove all the rules and ips on the router after the network gc 
interval.
6.start the vm. Once the vm is started go to VR check all public ips on VR are 
configured correctly.
Command to check in VR:
ip addr show


 VPC public ips not configured after network implement from implementing
 ---

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


 Reproducing steps:
 1. create vpc and create tier in vpc.
 2. Set network.gc to low in the global settings.
 3. Acquire ip and configure PF rule on the ip.
 4. Stop all the vms in the tier.
 5. network will remove all the rules and ips on the router after the network 
 gc interval.
 6. Now start the vm, observe that the PF public ip is not configured on the 
 interface. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7104) VPC public ips not configured after network implement from implementing

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7104:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 VPC public ips not configured after network implement from implementing
 ---

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


 Reproducing steps:
 1. create vpc and create tier in vpc.
 2. Set network.gc to low in the global settings.
 3. Acquire ip and configure PF rule on the ip.
 4. Stop all the vms in the tier.
 5. network will remove all the rules and ips on the router after the network 
 gc interval.
 6. Now start the vm, observe that the PF public ip is not configured on the 
 interface. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7104) VPC public ips not configured after network implement from implementing

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7104:
---

Problem:

In VPC, network implemented after GC VPC public ips are configured on the VR.

Root Cause Analysis:
--
When network is implemented after GC, ipassoc is not performed on this network.
Due to this public ip address is not configured on VR.

Proposed solution:
--
In IpAddressManager we have method to check ipassoc is needed or not in 
checkIfIpAssocRequired.
Returning true when network state is implementing.

QA Verification steps:
---
1. create vpc and create tier in vpc.
2. Set network.gc to low in the global settings.
3. Acquire ip and configure PF rule on the ip.
4. Stop all the vms in the tier.
5. network will remove all the rules and ips on the router after the network gc 
interval.
6.start the vm. Once the vm is started go to VR check all public ips on VR are 
configured correctly.
Command to check in VR:
ip addr show


 VPC public ips not configured after network implement from implementing
 ---

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


 Reproducing steps:
 1. create vpc and create tier in vpc.
 2. Set network.gc to low in the global settings.
 3. Acquire ip and configure PF rule on the ip.
 4. Stop all the vms in the tier.
 5. network will remove all the rules and ips on the router after the network 
 gc interval.
 6. Now start the vm, observe that the PF public ip is not configured on the 
 interface. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7028) [RVR] Static NAT does not work after the fail-over in additional public range

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7028:
--

Summary: [RVR] Static NAT does not work after the fail-over in additional 
public range  (was:  Static NAT does not work after the fail-ove)

 [RVR] Static NAT does not work after the fail-over in additional public range
 -

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


 On fail over, in master router route got missed.
 Reproducing steps:
 1. Create RVR network and acquire additional public ip range (ex: 47 vlan and 
 10.147.47.x subnet)
 2. create a static nat rue on additional range public ip and add firewall 
 rule for port 22-22
 3. ssh to public ip, it get connected to vm
 4. Now make master VR down, backup wil become master.
 5. On master router on eth3 there default route got missed, which is causing 
 the ingress traffic is coming to eth3 is going out via eth2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7452) Task: Remove test_data.cfg file from config folder of marvin as it is no longer in use

[Gaurav Aradhye (JIRA)]

Gaurav Aradhye created CLOUDSTACK-7452:
--

 Summary: Task: Remove test_data.cfg file from config folder of 
marvin as it is no longer in use
 Key: CLOUDSTACK-7452
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7452
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
 Fix For: 4.5.0


There are two files present in config folder currently, test_data.cfg and 
test_data.py.

The file test_data.py is used to store all the data related to the tests 
(dictionaries) and test_data.cfg file is not used. It was used previously.

Hence the file test_data.cfg should be removed to avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7452) Task: Remove test_data.cfg file from config folder of marvin as it is no longer in use

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye updated CLOUDSTACK-7452:
---

Status: Reviewable  (was: In Progress)

 Task: Remove test_data.cfg file from config folder of marvin as it is no 
 longer in use
 --

 Key: CLOUDSTACK-7452
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7452
 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


 There are two files present in config folder currently, test_data.cfg and 
 test_data.py.
 The file test_data.py is used to store all the data related to the tests 
 (dictionaries) and test_data.cfg file is not used. It was used previously.
 Hence the file test_data.cfg should be removed to avoid confusion.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7028) [RVR] Static NAT does not work after the fail-over in additional public range

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7028:
---

Problem:
---
Static NAT does not working after fail over in RVR. This issue there only for 
the additional public subnets case.

Root Cause Analysis:

For additional public subnet case in RVR when fail over happens there is no 
mechanism to add routes for the additional subnets
in eanble_pubip.sh 

When back up switch to master, during this enable_pubip.sh is called. Its 
responsibility to bring up public interfaces and add routes for the 
interface.

Due to this the ingress traffic coming in eth3 is going out via eth2.
To add routes gateway and device infomation which is not available in the 
router dynamically.

Proposed solution:

Once we have gw and device information in VR we can add routes for additional 
subnets.
So the gw and device information we are maintaining in 
/var/cache/cloud/ifaceGwIp in VR.
Using this information adding routes for additional public subnet interfaces in 
enable_pubip.sh when VR switches to master.

QA Verification steps:

To verify this we need two isolated public subnets in the lab.
In our current lab all public subnets are reachable from each other. In this 
case you can't reproduce the issue.
Take public subnet ex: 52, 53. From 52 subnet gateway 53 subnet should not be 
reachable.

Verfication steps:
1. Create RVR network and acquire additional public ip range (ex: 47 vlan and 
10.147.47.x subnet)
2. create a static nat rue on additional range public ip and add firewall rule 
for port 22-22
3. ssh to public ip, it get connected to vm
4. Now make master VR down, backup wil become master.
5. On master router on eth3 there should be default route. 
command to check:
ip route show table Table_ethdevNum
7. Static nat rule on public ip of additional subnet should work.
8. Make sure by capturing the traffic enter in device and leave the same device.


 [RVR] Static NAT does not work after the fail-over in additional public range
 -

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


 On fail over, in master router route got missed.
 Reproducing steps:
 1. Create RVR network and acquire additional public ip range (ex: 47 vlan and 
 10.147.47.x subnet)
 2. create a static nat rue on additional range public ip and add firewall 
 rule for port 22-22
 3. ssh to public ip, it get connected to vm
 4. Now make master VR down, backup wil become master.
 5. On master router on eth3 there default route got missed, which is causing 
 the ingress traffic is coming to eth3 is going out via eth2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7028) [RVR] Static NAT does not work after the fail-over in additional public range

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7028:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 [RVR] Static NAT does not work after the fail-over in additional public range
 -

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


 On fail over, in master router route got missed.
 Reproducing steps:
 1. Create RVR network and acquire additional public ip range (ex: 47 vlan and 
 10.147.47.x subnet)
 2. create a static nat rue on additional range public ip and add firewall 
 rule for port 22-22
 3. ssh to public ip, it get connected to vm
 4. Now make master VR down, backup wil become master.
 5. On master router on eth3 there default route got missed, which is causing 
 the ingress traffic is coming to eth3 is going out via eth2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6843) [Automation] List listServiceOfferings api fails with NPE

[Koushik Das (JIRA)]

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

Koushik Das commented on CLOUDSTACK-6843:
-

Testing: Run the API mentioned in the description and verify that there is no 
NPE

 [Automation] List listServiceOfferings api fails with NPE
 -

 Key: CLOUDSTACK-6843
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6843
 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: KVM - RHEL 6.3
 4.4-forward brach
Reporter: Rayees Namathponnan
Assignee: Koushik Das
 Fix For: 4.4.0

 Attachments: management-server.rar


 Create advanced zone in KVM, and execute below  api 
 http://10.223.49.195:8096/?command=listServiceOfferingsissystem=truesystemvmtype=secondarystoragevm
 API failes with below NPE
 2014-06-04 09:22:12,874 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-3:ctx-bbfc4fe7) ===START===  10.223.240.194 -- GET  
 jobid=6ad437e8-e8a5-43f0-9836-9a971895f2ffapiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx8lvuonsbqknPHnIFYT5xNhEvUEAcommand=queryAsyncJobResultresponse=jsonsignature=vWt6TJzRGujyODUGV4qlWRw2PnU%3D
 2014-06-04 09:22:12,889 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-3:ctx-bbfc4fe7 ctx-6459f16c ctx-ee0f0e0d) ===END===  
 10.223.240.194 -- GET  
 jobid=6ad437e8-e8a5-43f0-9836-9a971895f2ffapiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx8lvuonsbqknPHnIFYT5xNhEvUEAcommand=queryAsyncJobResultresponse=jsonsignature=vWt6TJzRGujyODUGV4qlWRw2PnU%3D
 2014-06-04 09:22:15,343 ERROR [c.c.a.ApiServer] (ApiServer-2:ctx-b32fc69a 
 ctx-2409f636) unhandled exception executing api command: 
 [Ljava.lang.String;@3e2251cf
 com.cloud.utils.exception.CloudRuntimeException: Caught: 
 com.mysql.jdbc.JDBC4PreparedStatement@5998caad: SELECT 
 service_offering_view.id, service_offering_view.uuid, 
 service_offering_view.name, service_offering_view.display_text, 
 service_offering_view.tags, service_offering_view.use_local_storage, 
 service_offering_view.system_use, service_offering_view.cpu, 
 service_offering_view.speed, service_offering_view.ram_size, 
 service_offering_view.nw_rate, service_offering_view.mc_rate, 
 service_offering_view.ha_enabled, service_offering_view.limit_cpu_use, 
 service_offering_view.is_volatile, service_offering_view.host_tag, 
 service_offering_view.default_use, service_offering_view.vm_type, 
 service_offering_view.customized_iops, service_offering_view.min_iops, 
 service_offering_view.max_iops, service_offering_view.hv_ss_reserve, 
 service_offering_view.sort_key, service_offering_view.bytes_read_rate, 
 service_offering_view.bytes_write_rate, service_offering_view.iops_read_rate, 
 service_offering_view.iops_write_rate, service_offering_view.created, 
 service_offering_view.removed, service_offering_view.domain_id, 
 service_offering_view.domain_uuid, service_offering_view.domain_name, 
 service_offering_view.domain_path, service_offering_view.deployment_planner 
 FROM service_offering_view WHERE service_offering_view.system_use = 1  AND  
 AND service_offering_view.removed IS NULL  ORDER BY 
 service_offering_view.sort_key DESC  LIMIT 0, 500
 at 
 com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
 at 
 com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
 at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
 at 
 com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
 at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
 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 
 

[jira] [Updated] (CLOUDSTACK-7424) [Automation] Failed to restart network

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7424:
--

Assignee: Chandan Purushothama  (was: Jayapal Reddy)

 [Automation] Failed to restart network
 --

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


 Error Executing the test case 
 *integration.component.test_multiple_ips_per_nic.TestVmNetworkOperations.test_network_restart_cleanup_false_3_VPC*
 *Error Message*
 Job failed: {jobprocstatus : 0, created : u'2014-08-24T07:31:03+', cmd : 
 u'org.apache.cloudstack.api.command.user.network.RestartNetworkCmd', userid : 
 u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
 u'01faacdc-294b-4209-a855-2dc8ea0aa2b4', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Failed to restart 
 network'}, accountid : u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs 
 available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=multiple_ips_per_n
 *Stacktrace*
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /usr/local/lib/python2.7/dist-packages/ddt.py, line 114, in wrapper
 return func(self, *args, **kwargs)
   File 
 /root/cloudstack/test/integration/component/test_multiple_ips_per_nic.py, 
 line 1186, in test_network_restart_cleanup_false
 network.restart(self.apiclient, cleanup=False)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 
 2626, in restart
 return(apiclient.restartNetwork(cmd))
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 1899, in restartNetwork
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Job failed: {jobprocstatus : 0, created : u\'2014-08-24T07:31:03+\', cmd 
 : u\'org.apache.cloudstack.api.command.user.network.RestartNetworkCmd\', 
 userid : u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
 u\'01faacdc-294b-4209-a855-2dc8ea0aa2b4\', jobresultcode : 530, jobresulttype 
 : u\'object\', jobresult : {errorcode : 530, errortext : u\'Failed to restart 
 network\'}, accountid : u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=multiple_ips_per_n
 
 ==
 *Error in the Management Server Log*:
 ==
 {code}
 2014-08-24 07:31:03,602 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending apply static nat rules commands to the backend
 2014-08-24 07:31:03,621 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending apply vpc ip association commands to the backend
 2014-08-24 07:31:03,638 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending apply vpc ip association commands to the backend
 2014-08-24 07:31:03,640 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Sending network 
 shutdown to VpcVirtualRouter
 2014-08-24 07:31:03,653 DEBUG [c.c.n.NetworkModelImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Service 
 SecurityGroup is not supported in the network id=314
 2014-08-24 07:31:03,654 DEBUG [c.c.n.r.VpcVirtualNetworkApplianceManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Router r-229-VM is 
 in Stopping, so not sending setup guest network command to the backend
 2014-08-24 07:31:03,663 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Lock is acquired for 
 nic id 476 as a part of remove vm VM[DomainRouter|r-229-VM] from network 
 Ntwk[314|Guest|37]
 2014-08-24 07:31:03,667 DEBUG [c.c.n.NetworkModelImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Service 
 SecurityGroup is not supported in the network id=314
 2014-08-24 07:31:03,668 WARN  [c.c.v.VirtualMachineManagerImpl] 
 (API-Job-Executor-82:ctx-6738c61c job-1529 ctx-3eaba8e6) Unable to remove vm 
 

[jira] [Commented] (CLOUDSTACK-7212) Failed to create LB rule on public port 8081

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7212:
---

Problem:
--
Configuring LB rule on public port 8081 is failing with VR as LB provider.

Root Cause Analysis:

Haproxy in VR is listening on the port 8081 for stats. 
If you try to configure the LB rule on public port 8081 again, haproxy is 
trying listen on 8081 which fails.
Due to this configure LB rule API fails.

Proposed solution:
--
In virtual router element throwing error when LB is configured on public port 
8081.

1. Allow haproxy on port 8081 change the stats port. We can't change this 
because it breaks backward compatibility.
2. So not allowing port 8081 for haproxy.

Verification steps:
-
1. Create isolated network.
2. Acquire public ip and configure LB rule with public port 8081.
3. We should get an error.



 Failed to create LB rule on public port 8081
 

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


 Creating to LB rule on public port 8081 is failed on VR as a LB provider.
 This is because the haproxy in VR is listening on the public ip for LB stats.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7245) listIsos call does not return isdynamicallyscalable in the response attributes as mentioned in API docs

[Damodar Reddy T (JIRA)]

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

Damodar Reddy T commented on CLOUDSTACK-7245:
-

Problem:
-
From CCP-4.3 onwards we were not returning isdynamicallyscalable parameter 
in the response for the API call listIsos.
Root Cause Analysis:
-
We are not setting the field isDynamicallyScalable in TemplateResponse.java 
Object for listIsos call. Due to this in the response it was not populating 
this parameter into the response.
Proposed Solution:

Populate the field isDynamicallyScalable by calling setDynamucallyScalable() 
method in TemplateResponse.java in listIsos call in 
TemplateJoinDaoImpl.newIsoResponse()
QA Notes:
---
Please note that we are not capturing isDynamicallyScalable value while 
registering an ISO which is a UI defect

 listIsos call does not return isdynamicallyscalable in the response 
 attributes as mentioned in API docs
 ---

 Key: CLOUDSTACK-7245
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7245
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Management Server
Affects Versions: 4.2.1
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
 Fix For: 4.5.0


 There is no way to tell whether a particular iso listed is dynamically 
 scalable or not. Even in the cloudstak UI, 'Dynamically Scalable' is listed 
 in the template details while its not there in the ISO details.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7212) Failed to create LB rule on public port 8081

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7212:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 Failed to create LB rule on public port 8081
 

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


 Creating to LB rule on public port 8081 is failed on VR as a LB provider.
 This is because the haproxy in VR is listening on the public ip for LB stats.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6750) [OVS] With stretched network deploying vm in a ovs disabled zone does not fail

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-6750:
--

Test case does not exist for testing this scenario.

 [OVS] With stretched network deploying vm in a ovs disabled zone does not 
 fail 
 ---

 Key: CLOUDSTACK-6750
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6750
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0

 Attachments: management-server.rar


 [OVS] With stretched network deploying vm in a ovs disabled zone does not 
 fail 
 Steps to reproduce:
 
 1.Bring up CS with two advanced zones say z1  z2 using xen clusters
 Create physical networks in both the zones with GRE isolation
 2.Create network offering with virtual network and ovs as the provider and 
 with StretchedL2Subnet enabled
 3.Create guest network with above offering in zone z2
 4.Deploy vm in the above network in z2
 5.Disable ovs service providers in zone z1
 6.Now deploy vm in z1 with stretched network created in z2
 Result:
 ==
 VM deployment was successful in z1 even though ovs provider was disabled. 
 Also ovs bridge and tunnel ports were created on both the hosts in z1z2
 Expected Result:
 ==
 VM deployement in z1 with ovs network created in z2 should fail since ovs 
 service provider is disabled in z1



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6757) [OVS] Deleting networks does not unplug nics from dom0 on xenserver

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-6757:
--

Test case does not exist for testing this scenario.

 [OVS] Deleting networks does not unplug nics from dom0 on xenserver
 ---

 Key: CLOUDSTACK-6757
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6757
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0


 [OVS] Deleting networks does not unplug nics from dom0 on xenserver
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with xen cluster
 2.Create physical network with GRE isolation
 3.Create network offering with virtual networking and ovs as the service 
 provider
 4.Create couple of guest networks with above network offering
 5.Deploy few vms in each network
 6.Delete the guest networks
 Expected Result:
 ==
 When CS creates tunnel networks it plugs a vif on dom0 for every tunnel 
 tunnetwork. However it does not unplug the vif from dom0 even-though the 
 network is deleted.
 Observations:
 ===
 We can see that bridge is getting deleted from the host bug the vif is not 
 getting unplugged from dom0.
 Attaching MS log file. Please look for bridge named OVSTunnel989 in the log 
 file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6755) [OVS] Can't create more than 7 GRE tunnel networks in xen cluster

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-6755:
--

Test case does not exist for testing this scenario.

 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 -

 Key: CLOUDSTACK-6755
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6755
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller, XenServer
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Blocker
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0

 Attachments: management-server.rar, ovstunnel.log, xensource.log


 [OVS] Can't create more than 7 GRE tunnel networks in xen cluster
 Steps to reproduce:
 ==
 1.Bring up CS in advanced zone with Xen cluster
 2.Create physical network with GRE isolation
 3.Create isolated network offering with virtual networking and OVS as the 
 service provider
 4.Create 8 guest networks with above offering and deploy vms in each network
 Result:
 ==
 CS would create 7 networks successfully and deploying vm in 8th network would 
 fail because Tunnel network creation would fail for 8th network
 Following is the log snippet from MS log:
 2014-05-23 10:18:12,784 DEBUG [c.c.n.e.OvsElement] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Checking if OvsElement 
 can handle service Connectivity on network test1-ovs
 2014-05-23 10:18:12,789 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Creating tunnels with OVS 
 tunnel manager
 2014-05-23 10:18:12,800 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Ask host 1 to configure 
 bridge for network:227
 2014-05-23 10:18:12,807 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Sending  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-89:job-253/job-254 ctx-800616c3) Seq 
 1-6553863357730929719: Executing:  { Cmd , MgmtId: 7332683579487, via: 
 1(xen-host-13), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.OvsSetupBridgeCommand:{name:OVSTunnel991,hostId:1,networkId:227,wait:0}}]
  }
 2014-05-23 10:18:12,808 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-268:ctx-46e3abbc) Seq 1-6553863357730929719: Executing request
 2014-05-23 10:18:12,991 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) Create a vif on dom0 for tunnel network for 
 account OVSTunnel991
 2014-05-23 10:18:13,056 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-268:ctx-46e3abbc) createTunnelNetwork failed
 com.cloud.utils.exception.CloudRuntimeException: Could not find available VIF 
 slot in VM with name: Control domain on host: xen-host-13
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getLowestAvailableVIFDeviceNum(CitrixResourceBase.java:3990)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:928)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.findOrCreateTunnelNetwork(CitrixResourceBase.java:1003)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5268)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:528)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
 at 
 com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 

[jira] [Commented] (CLOUDSTACK-6750) [OVS] With stretched network deploying vm in a ovs disabled zone does not fail

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-6750:
--

Problem;
---
A VM can be launched in a network, where network is created in one zone, but VM 
is being launched in different zone. This can be possible if the network 
supports ability to stretch across the zones. A new capability 'strechedl2' is 
added for the 'connectivity' service. If a network is created with network 
offering which has 'strechedl2' capability enabled for the 'connectivity' 
service enabled, then network can be stretched to different zone than one in 
which it is created. However 'Connectivity' service provider specified in the 
network offering need to be enabled in the zone to be able to extend the 
network. So if the 'Connectivity' service provider is not enabled in the zone 
then VM deployment and extending network to new zone should fail. But as 
reported this is not happening which needs to be fixed.

Root Cause Analysis:
--
Root cause of the bug is that this scenario is not though when the feature 
implemented.


Proposed Solution:

Add a validation check to ensure the 'Connectivity' service provider is enabled 
in the zone before extending the network to a new zone.

QA steps:
-
Disable connectivity service provider in the zone, and verify that when you a 
extend a network created in a different zone to the zone in which connectivity 
service provider is disables, deploy VM should fail.

Conversely when 'Connectivy' service provider is enabled then extending the 
network to new zone which has connectivity service provider is enabled should 
succeed.

 [OVS] With stretched network deploying vm in a ovs disabled zone does not 
 fail 
 ---

 Key: CLOUDSTACK-6750
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6750
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
  Labels: DEV_REVIEWED, ovs
 Fix For: 4.4.0

 Attachments: management-server.rar


 [OVS] With stretched network deploying vm in a ovs disabled zone does not 
 fail 
 Steps to reproduce:
 
 1.Bring up CS with two advanced zones say z1  z2 using xen clusters
 Create physical networks in both the zones with GRE isolation
 2.Create network offering with virtual network and ovs as the provider and 
 with StretchedL2Subnet enabled
 3.Create guest network with above offering in zone z2
 4.Deploy vm in the above network in z2
 5.Disable ovs service providers in zone z1
 6.Now deploy vm in z1 with stretched network created in z2
 Result:
 ==
 VM deployment was successful in z1 even though ovs provider was disabled. 
 Also ovs bridge and tunnel ports were created on both the hosts in z1z2
 Expected Result:
 ==
 VM deployement in z1 with ovs network created in z2 should fail since ovs 
 service provider is disabled in z1



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7182) NPE while trying to deploy VMs in parallel in isolated network

[Koushik Das (JIRA)]

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

Koushik Das updated CLOUDSTACK-7182:


Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 NPE while trying to deploy VMs in parallel in isolated network
 --

 Key: CLOUDSTACK-7182
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7182
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: Koushik Das
Assignee: Koushik Das
  Labels: AUTOMATION_REQ, DEV_REVIEWED
 Fix For: 4.5.0


 Repro steps:
 - Create an account
 - Deploy around 50 VMs in parallel in a new network (VR not created)
 This is a race condition and NPE is not always hit. Below is the log snippet.
 2014-03-06 12:20:15,121 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-233:ctx-210c1052) Creating VIF for i-4-98-VM on nic 
 [Nic:Guest-10.1.1.105-null]
 2014-03-06 12:20:15,127 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-233:ctx-210c1052) Catch Exception: class 
 java.lang.NullPointerException due to java.lang.NullPointerException
 java.lang.NullPointerException
 at 
 com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173)
 at 
 com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:701)
 2014-03-06 12:20:15,128 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-233:ctx-210c1052) Unable to start i-4-98-VM due to
 java.lang.NullPointerException
 at 
 com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173)
 at 
 com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
at 
 

[jira] [Updated] (CLOUDSTACK-7133) [Automation] Failed to reboot Virtual Machine - Runtime Exception - Unable to Start VM

[Koushik Das (JIRA)]

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

Koushik Das updated CLOUDSTACK-7133:


Labels: DEV_REVIEWED  (was: )

 [Automation] Failed to reboot Virtual Machine - Runtime Exception - Unable to 
 Start VM
 --

 Key: CLOUDSTACK-7133
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7133
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Koushik Das
Priority: Critical
  Labels: DEV_REVIEWED
 Fix For: 4.5.0

 Attachments: management-server(1).zip


 =
 Runtime Exception during VM Reboot Job:
 =
 2014-07-11 15:10:51,329 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-119:ctx-2cd21b46 job-420/job-422) Complete async job-422, 
 jobStatus: FAILED, resultCode: 0, result: 
 rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHIAE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3dhYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3VwcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAlkpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBSZXNvdXJjZSBbSG9zdDoxXSBpcyB1bnJlYWNoYWJsZTogSG9zdCAxOiBVbmFibGUgdG8gc3RhcnQgaW5zdGFuY2UgZHVlIHRvIGNhbid0IGZpbmQgcmVhZHkgdGVtcGxhdGU6IDIwMyBmb3IgZGF0YSBjZW50ZXIgMXVyAB5bTGphdmEubGFuZy5TdGFja1RyYWNlRWxlbWVudDsCRio8PP0iOQIAAHhwDnNyABtqYXZhLmxhbmcuU3RhY2tUcmFjZUVsZW1lbnRhCcWaJjbdhQIABEkACmxpbmVOdW1iZXJMAA5kZWNsYXJpbmdDbGFzc3EAfgAETAAIZmlsZU5hbWVxAH4ABEwACm1ldGhvZE5hbWVxAH4ABHhwcnQAIGNvbS5jbG91ZC52bS5WbVdvcmtKb2JEaXNwYXRjaGVydAAYVm1Xb3JrSm9iRGlzcGF0Y2hlci5qYXZhdAAGcnVuSm9ic3EAfgALAAAB-3QAP29yZy5hcGFjaGUuY2xvdWRzdGFjay5mcmFtZXdvcmsuam9icy5pbXBsLkFzeW5jSm9iTWFuYWdlckltcGwkNXQAGEFzeW5jSm9iTWFuYWdlckltcGwuamF2YXQADHJ1bkluQ29udGV4dHNxAH4ACwAAADF0AD5vcmcuYXBhY2hlLmNsb3Vkc3RhY2subWFuYWdlZC5jb250ZXh0Lk1hbmFnZWRDb250ZXh0UnVubmFibGUkMXQAG01hbmFnZWRDb250ZXh0UnVubmFibGUuamF2YXQAA3J1bnNxAH4ACwAAADh0AEJvcmcuYXBhY2hlLmNsb3Vkc3RhY2subWFuYWdlZC5jb250ZXh0LmltcGwuRGVmYXVsdE1hbmFnZWRDb250ZXh0JDF0ABpEZWZhdWx0TWFuYWdlZENvbnRleHQuamF2YXQABGNhbGxzcQB-AAsAAABndABAb3JnLmFwYWNoZS5jbG91ZHN0YWNrLm1hbmFnZWQuY29udGV4dC5pbXBsLkRlZmF1bHRNYW5hZ2VkQ29udGV4dHEAfgAadAAPY2FsbFdpdGhDb250ZXh0c3EAfgALNXEAfgAdcQB-ABp0AA5ydW5XaXRoQ29udGV4dHNxAH4ACwAAAC50ADxvcmcuYXBhY2hlLmNsb3Vkc3RhY2subWFuYWdlZC5jb250ZXh0Lk1hbmFnZWRDb250ZXh0UnVubmFibGVxAH4AFnEAfgAXc3EAfgALAAAB0HEAfgARcQB-ABJxAH4AF3NxAH4ACwAAAdd0AC5qYXZhLnV0aWwuY29uY3VycmVudC5FeGVjdXRvcnMkUnVubmFibGVBZGFwdGVydAAORXhlY3V0b3JzLmphdmFxAH4AG3NxAH4ACwAAAU50ACRqYXZhLnV0aWwuY29uY3VycmVudC5GdXR1cmVUYXNrJFN5bmN0AA9GdXR1cmVUYXNrLmphdmF0AAhpbm5lclJ1bnNxAH4ACwAAAKZ0AB9qYXZhLnV0aWwuY29uY3VycmVudC5GdXR1cmVUYXNrcQB-AClxAH4AF3NxAH4ACwAABFZ0ACdqYXZhLnV0aWwuY29uY3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3J0ABdUaHJlYWRQb29sRXhlY3V0b3IuamF2YXQACXJ1bldvcmtlcnNxAH4ACwAAAlt0AC5qYXZhLnV0aWwuY29uY3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3IkV29ya2VycQB-AC9xAH4AF3NxAH4ACwAAAtJ0ABBqYXZhLmxhbmcuVGhyZWFkdAALVGhyZWFkLmphdmFxAH4AF3NyACZqYXZhLnV0aWwuQ29sbGVjdGlvbnMkVW5tb2RpZmlhYmxlTGlzdPwPJTG17I4QAgABTAAEbGlzdHEAfgAGeHIALGphdmEudXRpbC5Db2xsZWN0aW9ucyRVbm1vZGlmaWFibGVDb2xsZWN0aW9uGUIAgMte9x4CAAFMAAFjdAAWTGphdmEvdXRpbC9Db2xsZWN0aW9uO3hwc3IAE2phdmEudXRpbC5BcnJheUxpc3R4gdIdmcdhnQMAAUkABHNpemV4cAB3BAB4cQB-ADt4
 2014-07-11 15:10:51,338 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-119:ctx-2cd21b46 job-420/job-422) Done executing 
 com.cloud.vm.VmWorkStart for job-422
 2014-07-11 15:10:51,343 DEBUG [c.c.v.UserVmManagerImpl] 
 (API-Job-Executor-108:ctx-d1b37d15 job-420 ctx-b9cc76f0) Unable to start VM 
 f1d98737-f934-4811-b7ef-402844e3b451
 java.lang.RuntimeException: Job failed due to exception Resource [Host:1] is 
 unreachable: Host 1: Unable to start instance due to can't find ready 
 template: 203 for data center 1
   at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114)
   at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
   at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 

[jira] [Commented] (CLOUDSTACK-7182) NPE while trying to deploy VMs in parallel in isolated network

[Koushik Das (JIRA)]

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

Koushik Das commented on CLOUDSTACK-7182:
-

Issue reported as part of parallel VM deployment tests, so that is already 
known to QA.
Additionally network regression tests should also be run.
Testing done:
-
1. Ran the network related tests under /test/integration/smoke folder using 
Simulator. Also the other smoke tests didn’t cause any new failures.
2. Also ran the following VPC test using simulator:
a. created vpc, VR gets started as part of this
b. created network in the vpc
c. deployed vm in network created in step#2
3. Manually ran the following tests using simulator (for both regular VR and 
VPC VR):
a. VR stop/start via API when the network is in Implemented state. Network 
implement shouldn’t be triggered in this case.
Deployed VM, network gets implemented, stopped/started VR. Repeated this for 
VPC as well.
b. VR start via API when network is Allocated state. It should trigger network 
implement process. This test case is a good one to test the chicken-egg problem 
– VR triggers network implement, and network implement in turn triggers the 
provider implementation – which is the virtual router itself.
Deployed VM, network gets implemented, destroyed VM, after sometime VR gets 
stopped and network goes to allocated state. At this point started the VR. Also 
repeated same for VPC.
4. Ran #3 using XS setup as well
The following tests were also done by Alena as part of code review. These needs 
to be executed as well and automated if not already done.
1. Update guest network when the network is a) implemented b) not implemented.
2. associate ip address list to account
3. start previously stopped router when the network is a) implemented b) not 
implemented
4. create nic for vm from the network that is a) implement b) not implemented.
5. deploy multiple vms for the same network in parallel (tried for 4)

 NPE while trying to deploy VMs in parallel in isolated network
 --

 Key: CLOUDSTACK-7182
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7182
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: Koushik Das
Assignee: Koushik Das
  Labels: AUTOMATION_REQ, DEV_REVIEWED
 Fix For: 4.5.0


 Repro steps:
 - Create an account
 - Deploy around 50 VMs in parallel in a new network (VR not created)
 This is a race condition and NPE is not always hit. Below is the log snippet.
 2014-03-06 12:20:15,121 DEBUG [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-233:ctx-210c1052) Creating VIF for i-4-98-VM on nic 
 [Nic:Guest-10.1.1.105-null]
 2014-03-06 12:20:15,127 WARN  [c.c.h.x.r.CitrixResourceBase] 
 (DirectAgent-233:ctx-210c1052) Catch Exception: class 
 java.lang.NullPointerException due to java.lang.NullPointerException
 java.lang.NullPointerException
 at 
 com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173)
 at 
 com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1084)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1137)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1766)
 at 
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:627)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at 

[jira] [Updated] (CLOUDSTACK-6843) [Automation] List listServiceOfferings api fails with NPE

[Koushik Das (JIRA)]

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

Koushik Das updated CLOUDSTACK-6843:


Labels: DEV_REVIEWED  (was: )

 [Automation] List listServiceOfferings api fails with NPE
 -

 Key: CLOUDSTACK-6843
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6843
 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: KVM - RHEL 6.3
 4.4-forward brach
Reporter: Rayees Namathponnan
Assignee: Koushik Das
  Labels: DEV_REVIEWED
 Fix For: 4.4.0

 Attachments: management-server.rar


 Create advanced zone in KVM, and execute below  api 
 http://10.223.49.195:8096/?command=listServiceOfferingsissystem=truesystemvmtype=secondarystoragevm
 API failes with below NPE
 2014-06-04 09:22:12,874 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-3:ctx-bbfc4fe7) ===START===  10.223.240.194 -- GET  
 jobid=6ad437e8-e8a5-43f0-9836-9a971895f2ffapiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx8lvuonsbqknPHnIFYT5xNhEvUEAcommand=queryAsyncJobResultresponse=jsonsignature=vWt6TJzRGujyODUGV4qlWRw2PnU%3D
 2014-06-04 09:22:12,889 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-3:ctx-bbfc4fe7 ctx-6459f16c ctx-ee0f0e0d) ===END===  
 10.223.240.194 -- GET  
 jobid=6ad437e8-e8a5-43f0-9836-9a971895f2ffapiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx8lvuonsbqknPHnIFYT5xNhEvUEAcommand=queryAsyncJobResultresponse=jsonsignature=vWt6TJzRGujyODUGV4qlWRw2PnU%3D
 2014-06-04 09:22:15,343 ERROR [c.c.a.ApiServer] (ApiServer-2:ctx-b32fc69a 
 ctx-2409f636) unhandled exception executing api command: 
 [Ljava.lang.String;@3e2251cf
 com.cloud.utils.exception.CloudRuntimeException: Caught: 
 com.mysql.jdbc.JDBC4PreparedStatement@5998caad: SELECT 
 service_offering_view.id, service_offering_view.uuid, 
 service_offering_view.name, service_offering_view.display_text, 
 service_offering_view.tags, service_offering_view.use_local_storage, 
 service_offering_view.system_use, service_offering_view.cpu, 
 service_offering_view.speed, service_offering_view.ram_size, 
 service_offering_view.nw_rate, service_offering_view.mc_rate, 
 service_offering_view.ha_enabled, service_offering_view.limit_cpu_use, 
 service_offering_view.is_volatile, service_offering_view.host_tag, 
 service_offering_view.default_use, service_offering_view.vm_type, 
 service_offering_view.customized_iops, service_offering_view.min_iops, 
 service_offering_view.max_iops, service_offering_view.hv_ss_reserve, 
 service_offering_view.sort_key, service_offering_view.bytes_read_rate, 
 service_offering_view.bytes_write_rate, service_offering_view.iops_read_rate, 
 service_offering_view.iops_write_rate, service_offering_view.created, 
 service_offering_view.removed, service_offering_view.domain_id, 
 service_offering_view.domain_uuid, service_offering_view.domain_name, 
 service_offering_view.domain_path, service_offering_view.deployment_planner 
 FROM service_offering_view WHERE service_offering_view.system_use = 1  AND  
 AND service_offering_view.removed IS NULL  ORDER BY 
 service_offering_view.sort_key DESC  LIMIT 0, 500
 at 
 com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
 at 
 com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
 at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
 at 
 com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
 at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
 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 

[jira] [Updated] (CLOUDSTACK-7425) [Automation] Failed to create network offering due to Invalid Service - Lb

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye updated CLOUDSTACK-7425:
---

Status: Reviewable  (was: In Progress)

 [Automation] Failed to create network offering due to Invalid Service - Lb
 --

 Key: CLOUDSTACK-7425
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7425
 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


 On Executing *test_persistent_networks.py* script, following error was seen 
 during creation of network offering.
 *nose.suite.ContextSuite context=TestRestartPersistentNetwork:setup* 
 *Error*
 Execute cmd: createnetworkoffering failed, due to: errorCode: 431, 
 errorText:Invalid service  Lb   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=persistent_network
 *Stacktrace*
   File /usr/local/lib/python2.7/dist-packages/nose/suite.py, line 208, in 
 run
 self.setUp()
   File /usr/local/lib/python2.7/dist-packages/nose/suite.py, line 291, in 
 setUp
 self.setupContext(ancestor)
   File /usr/local/lib/python2.7/dist-packages/nose/suite.py, line 314, in 
 setupContext
 try_run(context, names)
   File /usr/local/lib/python2.7/dist-packages/nose/util.py, line 470, in 
 try_run
 return func()
   File 
 /root/cloudstack/test/integration/component/test_persistent_networks.py, 
 line 1352, in setUpClass
 conservemode=False)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 
 2039, in create
 return NetworkOffering(apiclient.createNetworkOffering(cmd).__dict__)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 1864, in createNetworkOffering
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Execute cmd: createnetworkoffering failed, due to: errorCode: 431, 
 errorText:Invalid service  Lb\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=persistent_network
 
 ===
 Logs on Management Server:
 ===
 {code}
 2014-08-24 07:29:03,321 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-11:ctx-9045f4ed) ===START===  10.220.135.73 -- GET  
 apiKey=YuaraAK9l9g2KJCAw3APnrD2aNpVmhAesCvWFxlDvGCb0NcARH_sKQxfRM6WF-SCAxikI8awlxCrmw010lUFzgserviceproviderlist%5B2%5D.provider=VirtualRouterdisplaytext=Test+Nw+off+isolated+persistent-J1SARJserviceproviderlist%5B0%5D.service=Dhcpserviceproviderlist%5B4%5D.provider=VirtualRouterserviceproviderlist%5B1%5D.provider=VirtualRouteravailability=Optionalconservemode=Falseserviceproviderlist%5B3%5D.service=Dnsserviceproviderlist%5B0%5D.provider=VirtualRouterserviceproviderlist%5B1%5D.service=Lbserviceproviderlist%5B4%5D.service=PortForwardingsupportedservices=Dhcp%2CDns%2CSourceNat%2CPortForwarding%2C+Lbtraffictype=GUESTresponse=jsonname=Test+Nw+off+isolated+persistent-7NEHE0ispersistent=Trueserviceproviderlist%5B3%5D.provider=VirtualRouterguestiptype=Isolatedserviceproviderlist%5B2%5D.service=SourceNatcommand=createNetworkOfferingsignature=CSPMyaOuzQIuJ7pds6h0z1Zrz6Y%3D
 2014-08-24 07:29:03,324 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-25:ctx-4341a2a9 ctx-fe97e223 ctx-49ec168d) ===END===  
 10.220.135.73 -- GET  
 username=User-JEOYWOaccount=test-TestUserLogin-test_01_non_root_admin_Privileges-CCFZPYdomainid=56ab18f0-2b4d-11e4-89bd-1e5d0e053e75firstname=Userlastname=Useremail=user%40test.comapiKey=YuaraAK9l9g2KJCAw3APnrD2aNpVmhAesCvWFxlDvGCb0NcARH_sKQxfRM6WF-SCAxikI8awlxCrmw010lUFzgcommand=createUsersignature=ibJAEjnOZiNMtVgyWqHd1HW4W3w%3Dresponse=json
 2014-08-24 07:29:03,332 INFO  [c.c.a.ApiServer] 
 (catalina-exec-11:ctx-9045f4ed ctx-fab16efe ctx-a9b84bb9) Invalid service  Lb
 2014-08-24 07:29:03,332 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-11:ctx-9045f4ed ctx-fab16efe ctx-a9b84bb9) ===END===  
 10.220.135.73 -- GET  
 

[jira] [Updated] (CLOUDSTACK-7439) [Automation] Fix the script test_tags.py - Unable to find resource by uuid since it is already destroyed

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye updated CLOUDSTACK-7439:
---

Status: Reviewable  (was: In Progress)

 [Automation] Fix the script test_tags.py - Unable to find resource by uuid 
 since it is already destroyed 
 ---

 Key: CLOUDSTACK-7439
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7439
 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


 I am not sure whether we allow creation of tags on destroyed VMs. Currently 
 that Use case fails.
 *Error Message*
 Job failed: {jobprocstatus : 0, created : u'2014-08-24T15:44:22+', cmd : 
 u'org.apache.cloudstack.api.command.user.tag.CreateTagsCmd', userid : 
 u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
 u'37f08e53-2f4a-40d5-a241-687948b2afb8', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Unable to find 
 resource by uuid 9ea1264a-3914-41b4-9807-28e442ce752d and type UserVm'}, 
 accountid : u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=tags
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_tags.py, line 2249, 
 in test_22_create_tag_destroyed_vm
 tags={'region': 'India'}
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 
 3783, in create
 return Tag(apiclient.createTags(cmd).__dict__)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 2294, in createTags
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Job failed: {jobprocstatus : 0, created : u\'2014-08-24T15:44:22+\', cmd 
 : u\'org.apache.cloudstack.api.command.user.tag.CreateTagsCmd\', userid : 
 u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
 u\'37f08e53-2f4a-40d5-a241-687948b2afb8\', jobresultcode : 530, jobresulttype 
 : u\'object\', jobresult : {errorcode : 530, errortext : u\'Unable to find 
 resource by uuid 9ea1264a-3914-41b4-9807-28e442ce752d and type UserVm\'}, 
 accountid : u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=tags
   



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-7439) [Automation] Fix the script test_tags.py - Unable to find resource by uuid since it is already destroyed

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye reassigned CLOUDSTACK-7439:
--

Assignee: Gaurav Aradhye

 [Automation] Fix the script test_tags.py - Unable to find resource by uuid 
 since it is already destroyed 
 ---

 Key: CLOUDSTACK-7439
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7439
 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


 I am not sure whether we allow creation of tags on destroyed VMs. Currently 
 that Use case fails.
 *Error Message*
 Job failed: {jobprocstatus : 0, created : u'2014-08-24T15:44:22+', cmd : 
 u'org.apache.cloudstack.api.command.user.tag.CreateTagsCmd', userid : 
 u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
 u'37f08e53-2f4a-40d5-a241-687948b2afb8', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'Unable to find 
 resource by uuid 9ea1264a-3914-41b4-9807-28e442ce752d and type UserVm'}, 
 accountid : u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=tags
 Stacktrace
   File /usr/lib/python2.7/unittest/case.py, line 332, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_tags.py, line 2249, 
 in test_22_create_tag_destroyed_vm
 tags={'region': 'India'}
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 
 3783, in create
 return Tag(apiclient.createTags(cmd).__dict__)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 2294, in createTags
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Job failed: {jobprocstatus : 0, created : u\'2014-08-24T15:44:22+\', cmd 
 : u\'org.apache.cloudstack.api.command.user.tag.CreateTagsCmd\', userid : 
 u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
 u\'37f08e53-2f4a-40d5-a241-687948b2afb8\', jobresultcode : 530, jobresulttype 
 : u\'object\', jobresult : {errorcode : 530, errortext : u\'Unable to find 
 resource by uuid 9ea1264a-3914-41b4-9807-28e442ce752d and type UserVm\'}, 
 accountid : u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=tags
   



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7437) [Automation] Fix the script test_escalations_snapshots.py - unable to find a snapshot with id

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye updated CLOUDSTACK-7437:
---

Status: Reviewable  (was: In Progress)

 [Automation] Fix the script test_escalations_snapshots.py - unable to find 
 a snapshot with id
 ---

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


 Do not add the created snapshot to the cleanup resources since it has been 
 consciously deleted during the test case (test_01). Since the snapshot is no 
 longer there the cleanup_resources method results in an error.
 integration.component.test_escalations_snapshots.TestSnapshots.test_01_list_volume_snapshots_pagination
  (from nosetests)
 *Error Message*
 Job failed: {jobprocstatus : 0, created : u'2014-08-24T19:01:28+', 
 jobresult : {errorcode : 530, errortext : u'unable to find a snapshot with id 
 43'}, cmd : 
 u'org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd', userid 
 : u'77df13d2-2b4d-11e4-89bd-1e5d0e053e75', jobstatus : 2, jobid : 
 u'0fb9d284-9908-4e37-b176-b83eb2792399', jobresultcode : 530, jobinstanceid : 
 u'2b4a7334-c477-4dbb-a870-3a6c1ed5fcfb', jobresulttype : u'object', 
 jobinstancetype : u'Snapshot', accountid : 
 u'77df055e-2b4d-11e4-89bd-1e5d0e053e75'}   Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=escalations_snapsh
 *Stacktrace*
   File /usr/lib/python2.7/unittest/case.py, line 361, in run
 self.tearDown()
   File 
 /root/cloudstack/test/integration/component/test_escalations_snapshots.py, 
 line 106, in tearDown
 cleanup_resources(self.apiClient, self.cleanup)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py, line 
 121, in cleanup_resources
 obj.delete(api_client)
   File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 986, 
 in delete
 apiclient.deleteSnapshot(cmd)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 784, in deleteSnapshot
 response = self.connection.marvinRequest(command, response_type=response, 
 method=method)
   File 
 /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line 
 379, in marvinRequest
 raise e
 'Job failed: {jobprocstatus : 0, created : u\'2014-08-24T19:01:28+\', 
 jobresult : {errorcode : 530, errortext : u\'unable to find a snapshot with 
 id 43\'}, cmd : 
 u\'org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd\', 
 userid : u\'77df13d2-2b4d-11e4-89bd-1e5d0e053e75\', jobstatus : 2, jobid : 
 u\'0fb9d284-9908-4e37-b176-b83eb2792399\', jobresultcode : 530, jobinstanceid 
 : u\'2b4a7334-c477-4dbb-a870-3a6c1ed5fcfb\', jobresulttype : u\'object\', 
 jobinstancetype : u\'Snapshot\', accountid : 
 u\'77df055e-2b4d-11e4-89bd-1e5d0e053e75\'}\n
 Logs available at 
 http://xenrt.hq.xensource.com/control/queue.cgi?action=testlogsid=804076phase=Paralleltest=escalations_snapsh
 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7453) Network rate field specified with negative value in service offering results in db Exception

[Saksham Srivastava (JIRA)]

Saksham Srivastava created CLOUDSTACK-7453:
--

 Summary: Network rate field specified with negative value in 
service offering results in db Exception
 Key: CLOUDSTACK-7453
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7453
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.5.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.5.0


add service offering, add system service offering:
enter negative value for  network rate field.

result: status dialog  displayed   with :
  DB exception on followed by various DB record fields.


DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@32ec7dc1: INSERT INTO 
network_offerings (network_offerings.name, network_offerings.unique_name, 
network_offerings.display_text, network_offerings.nw_rate, 
network_offerings.mc_rate, network_offerings.traffic_type, 
network_offerings.specify_vlan, network_offerings.system_only, 
network_offerings.service_offering_id, network_offerings.tags, 
network_offerings.default, network_offerings.availability, 
network_offerings.state, network_offerings.created, 
network_offerings.guest_type, network_offerings.dedicated_lb_service, 
network_offerings.shared_source_nat_service, 
network_offerings.specify_ip_ranges, network_offerings.sort_key, 
network_offerings.uuid, network_offerings.redundant_router_service, 
network_offerings.conserve_mode, network_offerings.elastic_ip_service, 
network_offerings.eip_associate_public_ip, 
network_offerings.elastic_lb_service, network_offerings.inline, 
network_offerings.is_persistent, network_offerings.egress_default_policy, 
network_offerings.concurrent_connections, network_offerings.keep_alive_enabled, 
network_offerings.supports_streched_l2, network_offerings.internal_lb, 
network_offerings.public_lb) VALUES (_binary'nw1', _binary'nw1', _binary'nw1', 
-7, 10, 'Guest', 0, 0, null, null, 0, 'Optional', 'Disabled', '2014-07-17 
00:34:41', 'Isolated', 1, 0, 0, 0, 
_binary'd1305b80-c31e-459b-8499-068261f34bd7', 0, 0, 0, 0, 0, 0, 0, 1, 4096, 0, 
0, 0, 1)} 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[Gaurav Aradhye (JIRA)]

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

Gaurav Aradhye reassigned CLOUDSTACK-7434:
--

Assignee: Gaurav Aradhye

 [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 

[jira] [Commented] (CLOUDSTACK-7027) Leftover of SNAT rule was causing network down under L3 switch

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy commented on CLOUDSTACK-7027:
---

Problem:

On additional public subnet removing public ip is not deleting SNAT rules.
It is reproduced when ip is added as first ip but while removing the ip is 
removed as non first ip.

Root Cause Analysis:

For additional public subnet (non source nat network) the first is selected as 
first ip from the list which is retrieved from the DB.
When you have few ips delete/add operation on it changes the ips order.

Configure static nat on max ip first. configure few static nats on smaller ips.
While removing remove the max ip first so that it is not selected as first ip.
Due to this the SNAT rules configured on this are untouched on the VR.

While adding source nat rules are added for the first ip.

Proposed solution:
---
To delete SNAT rules, while disable static nat on ip from the non source nat 
network setting source nat flag to true.
This is to make sure the SNAT rules are got removed.

Verification steps:

1. Add additional public range.
2. acquire public ips 
3. configure pf/firewall rules on public ip
4. observe that SNAT rules on public ip in 'iptables -t nat -L -nv'
5. remove ip/rules on that ip (select the max ip from the acquired pool) 
6. Repeat the acquire, config rule, remove rules.
Make sure that there is SNAT rules for the removed ip.



 Leftover of SNAT rule was causing network down under L3 switch
 --

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


 Reproducing steps:
 1. Add additional public range.
 2. acquire public ips 
 3. configure pf/firewall rules on public ip
 4. observe that SNAT rules on public ip in 'iptables -t nat -L -nv'
 5. remove ip/rules on that ip (select the max ip from the acquired pool) 
 6. Repeat the acquire, config rule, remove rules. 
 You can observe SNAT rules for removed ip on router.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7027) Leftover of SNAT rule was causing network down under L3 switch

[Jayapal Reddy (JIRA)]

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

Jayapal Reddy updated CLOUDSTACK-7027:
--

Labels: AUTOMATION_REQ DEV_REVIEWED  (was: )

 Leftover of SNAT rule was causing network down under L3 switch
 --

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


 Reproducing steps:
 1. Add additional public range.
 2. acquire public ips 
 3. configure pf/firewall rules on public ip
 4. observe that SNAT rules on public ip in 'iptables -t nat -L -nv'
 5. remove ip/rules on that ip (select the max ip from the acquired pool) 
 6. Repeat the acquire, config rule, remove rules. 
 You can observe SNAT rules for removed ip on router.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7453) Network rate field specified with negative value in service offering results in db Exception

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7453: Network rate field specified with negative value in service 
offering results in db Exception


 Network rate field specified with negative value in service offering results 
 in db Exception
 

 Key: CLOUDSTACK-7453
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7453
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.5.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.5.0


 add service offering, add system service offering:
 enter negative value for  network rate field.
 result: status dialog  displayed   with :
   DB exception on followed by various DB record fields.
 DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@32ec7dc1: INSERT INTO 
 network_offerings (network_offerings.name, network_offerings.unique_name, 
 network_offerings.display_text, network_offerings.nw_rate, 
 network_offerings.mc_rate, network_offerings.traffic_type, 
 network_offerings.specify_vlan, network_offerings.system_only, 
 network_offerings.service_offering_id, network_offerings.tags, 
 network_offerings.default, network_offerings.availability, 
 network_offerings.state, network_offerings.created, 
 network_offerings.guest_type, network_offerings.dedicated_lb_service, 
 network_offerings.shared_source_nat_service, 
 network_offerings.specify_ip_ranges, network_offerings.sort_key, 
 network_offerings.uuid, network_offerings.redundant_router_service, 
 network_offerings.conserve_mode, network_offerings.elastic_ip_service, 
 network_offerings.eip_associate_public_ip, 
 network_offerings.elastic_lb_service, network_offerings.inline, 
 network_offerings.is_persistent, network_offerings.egress_default_policy, 
 network_offerings.concurrent_connections, 
 network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, 
 network_offerings.internal_lb, network_offerings.public_lb) VALUES 
 (_binary'nw1', _binary'nw1', _binary'nw1', -7, 10, 'Guest', 0, 0, null, null, 
 0, 'Optional', 'Disabled', '2014-07-17 00:34:41', 'Isolated', 1, 0, 0, 0, 
 _binary'd1305b80-c31e-459b-8499-068261f34bd7', 0, 0, 0, 0, 0, 0, 0, 1, 4096, 
 0, 0, 0, 1)} 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7453) Network rate field specified with negative value in service offering results in db Exception

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7453: Network rate field specified with negative value in service 
offering results in db Exception


 Network rate field specified with negative value in service offering results 
 in db Exception
 

 Key: CLOUDSTACK-7453
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7453
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.5.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.5.0


 add service offering, add system service offering:
 enter negative value for  network rate field.
 result: status dialog  displayed   with :
   DB exception on followed by various DB record fields.
 DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@32ec7dc1: INSERT INTO 
 network_offerings (network_offerings.name, network_offerings.unique_name, 
 network_offerings.display_text, network_offerings.nw_rate, 
 network_offerings.mc_rate, network_offerings.traffic_type, 
 network_offerings.specify_vlan, network_offerings.system_only, 
 network_offerings.service_offering_id, network_offerings.tags, 
 network_offerings.default, network_offerings.availability, 
 network_offerings.state, network_offerings.created, 
 network_offerings.guest_type, network_offerings.dedicated_lb_service, 
 network_offerings.shared_source_nat_service, 
 network_offerings.specify_ip_ranges, network_offerings.sort_key, 
 network_offerings.uuid, network_offerings.redundant_router_service, 
 network_offerings.conserve_mode, network_offerings.elastic_ip_service, 
 network_offerings.eip_associate_public_ip, 
 network_offerings.elastic_lb_service, network_offerings.inline, 
 network_offerings.is_persistent, network_offerings.egress_default_policy, 
 network_offerings.concurrent_connections, 
 network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, 
 network_offerings.internal_lb, network_offerings.public_lb) VALUES 
 (_binary'nw1', _binary'nw1', _binary'nw1', -7, 10, 'Guest', 0, 0, null, null, 
 0, 'Optional', 'Disabled', '2014-07-17 00:34:41', 'Isolated', 1, 0, 0, 0, 
 _binary'd1305b80-c31e-459b-8499-068261f34bd7', 0, 0, 0, 0, 0, 0, 0, 1, 4096, 
 0, 0, 0, 1)} 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7153) addNicToVirtualMachine not BaseAsyncCreate but creates an entity

[Damodar Reddy T (JIRA)]

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

Damodar Reddy T commented on CLOUDSTACK-7153:
-

Problem:
---
When event bus is enabled and while adding a nic to a VM, This creates an 
entity into nic but will not put the created entity's uuid into the event bus 
message.
Root Cause Analysis:
---
In UserVmManager.addNicToVirtualMachine which is called by addNicToVmCmd was 
not putting the created entity's uuid into the CallContext so the Event NIC 
Complete was not able to get the id during event complete call so was not 
putting the same into event bus message.
Solution proposed:

Put the created entity's uuid into CallContext before returning from 
UserVmManager.addNicToVirtualMachine call
QA Notes:
---
Make sure the entity's uuid is coming in event bus message during event 
complete call.


 addNicToVirtualMachine not BaseAsyncCreate but creates an entity
 

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


 addNicToVirtualMachine not BaseAsyncCreate but creates an entity.
 We need them to be BaseAsyncCreate so that Eventbus while publishing the 
 completed events can put in the entity id. Right now there is a generic logic 
 where after create function when the id is created its pushed into the 
 context so that Eventbus can use it to publish the created UUID. If its not 
 baseAsyncCreate you will have to go into each api and put the id in the 
 context.
 Currently following is the generic code had put in ApiServer.java. We will 
 have to do specifically into your api. Do this only if there is a hard reason 
 not to make it baseasyncCreate
 Class entityClass = 
 EventTypes.getEntityClassForEvent(createCmd.getEventType());
 if (entityClass != null)
 ctx.putContextParameter(entityClass.getName(), objectId);



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7413) Task: Adding required_hardware tag to regression test cases so that the test cases are picked up by simulator accordingly

[Girish Shilamkar (JIRA)]

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

Girish Shilamkar resolved CLOUDSTACK-7413.
--

Resolution: Fixed

 Task: Adding required_hardware tag to regression test cases so that the test 
 cases are picked up by simulator accordingly
 -

 Key: CLOUDSTACK-7413
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7413
 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: Girish Shilamkar
Assignee: Girish Shilamkar
  Labels: automation
 Fix For: 4.5.0


 Regression test cases need to be tagged with required_hardware tag so that 
 the test cases are picked up by simulator accordingly.
 tag selfservice needs to be replaced by required_hardware=false
 tag provisioning needs to be replaced by required_hardware=true



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7124) Failed to apply site-to-site VPN using Site2SiteVpnCfgCommand

[Azo (JIRA)]

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

Azo commented on CLOUDSTACK-7124:
-

We have this issue with the version 4.4.0. 
Could be possilbe to include this fix in 4.4.1?

 Failed to apply site-to-site VPN using Site2SiteVpnCfgCommand
 -

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


 
 Management Server Log:
 
 2014-07-17 14:20:29,540 WARN  [o.a.c.f.j.AsyncJobExecutionContext] 
 (StatsCollector-3:ctx-d1bbb5cd) Job is executed without a context, setup 
 psudo job for the executing thread
 2014-07-17 14:20:29,594 DEBUG [c.c.a.t.Request] 
 (StatsCollector-3:ctx-d1bbb5cd) Seq 4-2465720795985346640: Received:  { Ans: 
 , MgmtId: 200888983222606, via: 4, Ver: v1, Flags: 10, { 
 GetStorageStatsAnswer } }
 2014-07-17 14:20:29,597 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-157:ctx-a2223711) Seq 1-6784391363656943196: Executing request
 2014-07-17 14:20:30,095 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-157:ctx-a2223711) Seq 1-6784391363656943196: Response Received: 
 2014-07-17 14:20:30,096 DEBUG [c.c.a.t.Request] 
 (StatsCollector-3:ctx-d1bbb5cd) Seq 1-6784391363656943196: Received:  { Ans: 
 , MgmtId: 200888983222606, via: 1, Ver: v1, Flags: 10, { 
 GetStorageStatsAnswer } }
 2014-07-17 14:20:31,380 ERROR [c.c.u.s.SshHelper] 
 (DirectAgent-156:ctx-8941a517) SSH execution of command 
 /opt/cloud/bin/router_proxy.sh ipsectunnel.sh 169.254.0.19 -A -l 
 10.220.166.68 -n 10.2.1.0/24 -g 10.220.160.1 -r 10.220.166.67 -N 10.1.1.0/24 
 -e 3des-md5;modp1536 -i 3des-md5;modp1536 -t 86400 -T 3600 -s ipsecpsk 
 -d 0 -p  has an error status code in return. result output: inet 
 10.220.166.68/20 brd 10.220.175.255 scope global eth1
 iptables: No chain/target/match by that name.
 iptables: No chain/target/match by that name.
 iptables: No chain/target/match by that name.
 iptables: No chain/target/match by that name.
 021 no connection named vpn-10.220.166.67
 000 terminating all conns with alias='vpn-10.220.166.67' 
 021 no connection named vpn-10.220.166.67
 021 no connection named vpn-10.220.166.67
 003 no secrets filename matched /etc/ipsec.d/ipsec.*.secrets
 iptables: Bad rule (does a matching rule exist in that chain?).
 iptables: Bad rule (does a matching rule exist in that chain?).
 iptables: Bad rule (does a matching rule exist in that chain?).
 iptables: Bad rule (does a matching rule exist in that chain?).
 /opt/cloud/bin/ipsectunnel.sh: line 165: [: -ne: unary operator expected
 can not load config '/etc/ipsec.conf': 
 /etc/ipsec.d/ipsec.vpn-10.220.166.67.conf:12: bad duration value salifetime=s 
 [s]
 000 initiating all conns with alias='vpn-10.220.166.67' 
 021 no connection named vpn-10.220.166.67
 ISAKMP SA NOT found but checking IPsec;IPsec SA not found;Site-to-site VPN 
 have not connected
 ISAKMP SA NOT found but checking IPsec;IPsec SA not found;Site-to-site VPN 
 have not connected
 ISAKMP SA NOT found but checking IPsec;IPsec SA not found;Site-to-site VPN 
 have not connected
 ISAKMP SA NOT found but checking IPsec;IPsec SA not found;Site-to-site VPN 
 have not connected
 ISAKMP SA NOT found but checking IPsec;IPsec SA not found;Site-to-site VPN 
 have not connected
 021 no connection named vpn-10.220.166.67
 000 terminating all conns with alias='vpn-10.220.166.67' 
 021 no connection named vpn-10.220.166.67
 021 no connection named vpn-10.220.166.67
 003 no secrets filename matched /etc/ipsec.d/ipsec.*.secrets
 bash: modp1536: command not found
 bash: modp1536: command not found
 2014-07-17 14:20:31,381 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-156:ctx-8941a517) Seq 1-6784391363656943194: Response Received: 
 2014-07-17 14:20:31,381 DEBUG [c.c.a.t.Request] 
 (DirectAgent-156:ctx-8941a517) Seq 1-6784391363656943194: Processing:  { Ans: 
 , MgmtId: 200888983222606, via: 1, Ver: v1, Flags: 100, 
 [{com.cloud.agent.api.Answer:{result:false,details:inet 
 10.220.166.68/20 brd 10.220.175.255 scope global eth1\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: No 
 chain/target/match by that name.\n021 no connection named 
 \vpn-10.220.166.67\\n000 terminating all conns with 
 alias='vpn-10.220.166.67' \n021 no connection named 
 \vpn-10.220.166.67\\n021 no connection named \vpn-10.220.166.67\\n003 no 
 

[jira] [Commented] (CLOUDSTACK-7419) Document How to configure SAML SSO/SLO with CloudStack

[sebastien goasguen (JIRA)]

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

sebastien goasguen commented on CLOUDSTACK-7419:


[~bhaisaab] yes put it in the admin guide somewhere...

 Document How to configure SAML SSO/SLO with CloudStack
 --

 Key: CLOUDSTACK-7419
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7419
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (CLOUDSTACK-7451) Network offering with VPC does not allow selecting virtual router's system offering

[Jessica Wang (JIRA)]

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

Jessica Wang updated CLOUDSTACK-7451:
-

Comment: was deleted

(was: https://issues.citrite.net/i#browse/CS-21319)

 Network offering with VPC does not allow selecting virtual router's 
 system offering
 

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

 REPRO STEPS
 ==
 Try to create a new network offering
 Select VPC
 Select any service like DHCP
 Uncheck VPC
 Now we can select VR Service offering
 Select VPC again, now we cannot select VR Service offering
 EXPECTED BEHAVIOR
 ==
 With VPC enabled network offering we should be able to select VR Service 
 offering
 ACTUAL BEHAVIOR
 ==
 With VPC enabled network offering we are not able to select VR Service 
 offering



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7083) Implement SAML 2.0 plugin

[ASF subversion and git services (JIRA)]

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

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

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

Merge branch 'saml2'

Implements CLOUDSTACK-7083

Branch: saml2
Proposal: http://markmail.org/message/4ba4ztmqpud3l4uo
JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-7083
FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin
Unit tests: Tests for each auth cmd class, SAMLUtils and SAMLAuthenticator, 
fixes unit test for ApiServlet
Build status: clean build works with unit tests, testing using mvn3.0.5 and jdk 
1.7


 Implement SAML 2.0 plugin
 -

 Key: CLOUDSTACK-7083
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7083
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Cloudmonkey, IAM, UI
Reporter: Rohit Yadav
Assignee: Rohit Yadav
  Labels: features
 Fix For: 4.5.0


 FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7083) Implement SAML 2.0 plugin

[ASF subversion and git services (JIRA)]

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

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

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

Merge branch 'saml2'

Implements CLOUDSTACK-7083

Branch: saml2
Proposal: http://markmail.org/message/4ba4ztmqpud3l4uo
JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-7083
FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin
Unit tests: Tests for each auth cmd class, SAMLUtils and SAMLAuthenticator, 
fixes unit test for ApiServlet
Build status: clean build works with unit tests, testing using mvn3.0.5 and jdk 
1.7


 Implement SAML 2.0 plugin
 -

 Key: CLOUDSTACK-7083
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7083
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Cloudmonkey, IAM, UI
Reporter: Rohit Yadav
Assignee: Rohit Yadav
  Labels: features
 Fix For: 4.5.0


 FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be above SMB Username field.

[Jessica Wang (JIRA)]

Jessica Wang created CLOUDSTACK-7454:


 Summary: UI  zone wizard  Hyper-V  primary storage/secondary 
storage  move SMB Domain field to be above SMB Username field.
 Key: CLOUDSTACK-7454
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7454
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang


So, it will be clear that the SMB User field does NOT expect format 
domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be right on to of SMB Username field.

[Jessica Wang (JIRA)]

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

Jessica Wang updated CLOUDSTACK-7454:
-

Summary: UI  zone wizard  Hyper-V  primary storage/secondary storage  
move SMB Domain field to be right on to of SMB Username field.  (was: UI  zone 
wizard  Hyper-V  primary storage/secondary storage  move SMB Domain field to 
be above SMB Username field.)

 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be right on to of SMB Username field.
 ---

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

 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be on to of SMB Username field.

[Jessica Wang (JIRA)]

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

Jessica Wang updated CLOUDSTACK-7454:
-

Summary: UI  zone wizard  Hyper-V  primary storage/secondary storage  
move SMB Domain field to be on to of SMB Username field.  (was: UI  zone 
wizard  Hyper-V  primary storage/secondary storage  move SMB Domain field to 
be right on to of SMB Username field.)

 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be on to of SMB Username field.
 -

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

 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be on top of SMB Username field.

[Jessica Wang (JIRA)]

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

Jessica Wang updated CLOUDSTACK-7454:
-

Summary: UI  zone wizard  Hyper-V  primary storage/secondary storage  
move SMB Domain field to be on top of SMB Username field.  (was: UI  zone 
wizard  Hyper-V  primary storage/secondary storage  move SMB Domain field to 
be on to of SMB Username field.)

 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be on top of SMB Username field.
 --

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

 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be on top of SMB Username field.

[Jessica Wang (JIRA)]

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

Jessica Wang resolved CLOUDSTACK-7454.
--

Resolution: Fixed

 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be on top of SMB Username field.
 --

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

 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be on top of SMB Username field.

[Jessica Wang (JIRA)]

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

Jessica Wang closed CLOUDSTACK-7454.



 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be on top of SMB Username field.
 --

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

 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be on top of SMB Username field.

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-7454: UI  zone wizard  Hyper-V  primary storage/secondary storage 
 move SMB Domain field to be on top of SMB Username field.


 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be on top of SMB Username field.
 --

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

 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7454) UI zone wizard Hyper-V primary storage/secondary storage move SMB Domain field to be on top of SMB Username field.

[Jessica Wang (JIRA)]

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

Jessica Wang updated CLOUDSTACK-7454:
-

Attachment: 3_after_jessica_checkin.PNG
2_after_jessica_checkin.PNG
1_before_jessica_checkin.PNG

 UI  zone wizard  Hyper-V  primary storage/secondary storage  move SMB 
 Domain field to be on top of SMB Username field.
 --

 Key: CLOUDSTACK-7454
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7454
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang
 Attachments: 1_before_jessica_checkin.PNG, 
 2_after_jessica_checkin.PNG, 3_after_jessica_checkin.PNG


 So, it will be clear that the SMB User field does NOT expect format 
 domain\user.



--
This message was sent by Atlassian JIRA
(v6.2#6252)