date:20140520


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

Jayapal Reddy updated CLOUDSTACK-6714:
--

Affects Version/s: 4.3.0

 Service monitoring conf is has issue with script in vmware
 --

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


 There is issue in monitor_service.sh echo service name to conf file.
 setup1:
 root@r-13-VM:~#  s=[loadbalancing]; echo $s;
 i
 root@r-13-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]
 Dev setup:
 root@r-4-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]



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

[jira] [Assigned] (CLOUDSTACK-6714) Service monitoring conf is has issue with script in vmware


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

Jayapal Reddy reassigned CLOUDSTACK-6714:
-

Assignee: Jayapal Reddy

 Service monitoring conf is has issue with script in vmware
 --

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


 There is issue in monitor_service.sh echo service name to conf file.
 setup1:
 root@r-13-VM:~#  s=[loadbalancing]; echo $s;
 i
 root@r-13-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]
 Dev setup:
 root@r-4-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]



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

[jira] [Updated] (CLOUDSTACK-6714) Service monitoring conf is has issue with script in vmware


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

Jayapal Reddy updated CLOUDSTACK-6714:
--

Fix Version/s: 4.4.0

 Service monitoring conf is has issue with script in vmware
 --

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


 There is issue in monitor_service.sh echo service name to conf file.
 setup1:
 root@r-13-VM:~#  s=[loadbalancing]; echo $s;
 i
 root@r-13-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]
 Dev setup:
 root@r-4-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]



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

[jira] [Created] (CLOUDSTACK-6714) Service monitoring conf is has issue with script in vmware

2014-05-20 Thread ASF subversion and git services (JIRA)

Jayapal Reddy created CLOUDSTACK-6714:
-

 Summary: Service monitoring conf is has issue with script in vmware
 Key: CLOUDSTACK-6714
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6714
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jayapal Reddy


There is issue in monitor_service.sh echo service name to conf file.

setup1:
root@r-13-VM:~#  s=[loadbalancing]; echo $s;
i
root@r-13-VM:~# s=[loadbalancing]; echo $s;
[loadbalancing]

Dev setup:
root@r-4-VM:~# s=[loadbalancing]; echo $s;
[loadbalancing]



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

[jira] [Commented] (CLOUDSTACK-6714) Service monitoring conf is has issue with script in vmware


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

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

Commit 45f6bac727bf6631153ac8e17dd7b074759052eb in cloudstack's branch 
refs/heads/4.4-forward from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=45f6bac ]

CLOUDSTACK-6714: monitor script echo service command is added with quotes


 Service monitoring conf is has issue with script in vmware
 --

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


 There is issue in monitor_service.sh echo service name to conf file.
 setup1:
 root@r-13-VM:~#  s=[loadbalancing]; echo $s;
 i
 root@r-13-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]
 Dev setup:
 root@r-4-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]



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

[jira] [Created] (CLOUDSTACK-6715) [SDN] Inconsistency in ovs-flow table after vm migration from one host to another

Sanjeev N created CLOUDSTACK-6715:
-

 Summary: [SDN] Inconsistency in ovs-flow table after vm migration 
from one host to another 
 Key: CLOUDSTACK-6715
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6715
 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
Priority: Critical
 Fix For: 4.4.0


[SDN] Inconsistency in ovs-flow table after vm migration from one host to 
another 

Steps to reproduce:

1.Bring up CS in advanced zone with two xen hosts in a cluster
2.Create physical network with GRE isolation
3.Create isolated network with OVS provider 
4.Deploy few vms in the network and make sure that all the vms(including VR) 
are deployed on only one host.
5.Now migrate one vm to another host in the cluster and verify flow tables for 
this isolated network bridge on both the xen hosts

Result:
===
Inconsistency in flow tables on both the xen hosts

Following it the flow table from the host before vm migration (All the vms and 
VR were only on this host before vm migration):
[root@xen-host-14 ~]# ovs-ofctl dump-flows xapi4
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1173.14s, table=0, n_packets=0, n_bytes=0, 
priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1,output:2
 cookie=0x0, duration=1173.15s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=1203.276s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=1,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=1226.258s, table=0, n_packets=901, n_bytes=85612, 
priority=0 actions=NORMAL
 cookie=0x0, duration=1173.129s, table=0, n_packets=0, n_bytes=0, 
priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:1,output:2
 cookie=0x0, duration=1203.286s, table=0, n_packets=0, n_bytes=0, 
priority=1200,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 cookie=0x0, duration=1173.167s, table=0, n_packets=7, n_bytes=1494, 
priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL

Flow table after vm migration on the same host:
[root@xen-host-14 ~]# ovs-ofctl dump-flows xapi4
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=992.789s, table=0, n_packets=0, n_bytes=0, priority=0 
actions=NORMAL
[root@xen-host-14 ~]#

Ports info on the bridge after vm migration:
[root@xen-host-14 ~]# ovs-vsctl list-ports xapi4
t986-2-1
vif11.0
vif12.0


Flow table on the target host where vm was migrated to:
[root@xen-host-13 ~]# ovs-ofctl dump-flows xapi4
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1025.129s, table=0, n_packets=0, n_bytes=0, 
priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2
 cookie=0x0, duration=1025.139s, table=0, n_packets=0, n_bytes=0, 
priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
 cookie=0x0, duration=1032.932s, table=0, n_packets=0, n_bytes=0, 
priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop
 cookie=0x0, duration=1033.247s, table=0, n_packets=0, n_bytes=0, priority=0 
actions=NORMAL
 cookie=0x0, duration=1025.119s, table=0, n_packets=0, n_bytes=0, 
priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2
 cookie=0x0, duration=1032.942s, table=0, n_packets=0, n_bytes=0, 
priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
 cookie=0x0, duration=1025.148s, table=0, n_packets=1, n_bytes=42, 
priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL

[root@xen-host-13 ~]# ovs-vsctl list-ports xapi4
t986-1-2
vif17.0

Following is the log snippet from both the hosts during vm migration (tunnel 
creation during vm migration):

2014-05-20 11:31:21DEBUG [root]  VMOPS enter  create_tunnel 
2014-05-20 11:31:21DEBUG [root] Creating tunnel from host 2 to host 1 with 
GRE key 986
2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'--timeout=30', 'wait-until', 'bridge', 'xapi4', '--', 'get', 'bridge', 
'xapi4', 'name']
2014-05-20 11:31:21DEBUG [root] bridge xapi4 for creating tunnel - VERIFIED
2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
'add-port', 'xapi4', 't986-2-1', '--', 'set', 'interface', 't986-2-1', 
'type=gre', 'options:key=986', 'options:remote_ip=10.147.40.13']
2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'port', 't986-2-1', 'interfaces']
2014-05-20 11:31:22DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'interface', '01be01e9-c4b1-4b90-9ac0-199f2c797719', 'options:key']
2014-05-20 11:31:22DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 'get', 
'interface', '01be01e9-c4b1-4b90-9ac0-199f2c797719', 'options:remote_ip']
2014-05-20 11:31:22DEBUG [root] Tunnel interface

[jira] [Updated] (CLOUDSTACK-6715) [SDN] Inconsistency in ovs-flow table after vm migration from one host to another

2014-05-20 Thread ASF subversion and git services (JIRA)


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

Sanjeev N updated CLOUDSTACK-6715:
--

Attachment: ovstunnel-host14.log
ovstunnel-host13.log
management-server.rar

Attached MS log file and ovstunnel.log files from both the xen hosts.

 [SDN] Inconsistency in ovs-flow table after vm migration from one host to 
 another 
 --

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

 Attachments: management-server.rar, ovstunnel-host13.log, 
 ovstunnel-host14.log


 [SDN] Inconsistency in ovs-flow table after vm migration from one host to 
 another 
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with two xen hosts in a cluster
 2.Create physical network with GRE isolation
 3.Create isolated network with OVS provider 
 4.Deploy few vms in the network and make sure that all the vms(including VR) 
 are deployed on only one host.
 5.Now migrate one vm to another host in the cluster and verify flow tables 
 for this isolated network bridge on both the xen hosts
 Result:
 ===
 Inconsistency in flow tables on both the xen hosts
 Following it the flow table from the host before vm migration (All the vms 
 and VR were only on this host before vm migration):
 [root@xen-host-14 ~]# ovs-ofctl dump-flows xapi4
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1173.14s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1,output:2
  cookie=0x0, duration=1173.15s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=1203.276s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=1,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=1226.258s, table=0, n_packets=901, n_bytes=85612, 
 priority=0 actions=NORMAL
  cookie=0x0, duration=1173.129s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:1,output:2
  cookie=0x0, duration=1203.286s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=1173.167s, table=0, n_packets=7, n_bytes=1494, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 Flow table after vm migration on the same host:
 [root@xen-host-14 ~]# ovs-ofctl dump-flows xapi4
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=992.789s, table=0, n_packets=0, n_bytes=0, priority=0 
 actions=NORMAL
 [root@xen-host-14 ~]#
 Ports info on the bridge after vm migration:
 [root@xen-host-14 ~]# ovs-vsctl list-ports xapi4
 t986-2-1
 vif11.0
 vif12.0
 Flow table on the target host where vm was migrated to:
 [root@xen-host-13 ~]# ovs-ofctl dump-flows xapi4
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1025.129s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2
  cookie=0x0, duration=1025.139s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=1032.932s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop
  cookie=0x0, duration=1033.247s, table=0, n_packets=0, n_bytes=0, priority=0 
 actions=NORMAL
  cookie=0x0, duration=1025.119s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2
  cookie=0x0, duration=1032.942s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
  cookie=0x0, duration=1025.148s, table=0, n_packets=1, n_bytes=42, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 [root@xen-host-13 ~]# ovs-vsctl list-ports xapi4
 t986-1-2
 vif17.0
 Following is the log snippet from both the hosts during vm migration (tunnel 
 creation during vm migration):
 2014-05-20 11:31:21DEBUG [root]  VMOPS enter  create_tunnel 
 2014-05-20 11:31:21DEBUG [root] Creating tunnel from host 2 to host 1 
 with GRE key 986
 2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
 '--timeout=30', 'wait-until', 'bridge', 'xapi4', '--', 'get', 'bridge', 
 'xapi4', 'name']
 2014-05-20 11:31:21DEBUG [root] bridge xapi4 for creating tunnel - 
 VERIFIED
 2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
 'add-port', 'xapi4', 't986-2-1', '--', 'set', 'interface', 't986-2-1',

[jira] [Assigned] (CLOUDSTACK-6650) Reorder Cluster list in deployment planner to protect GPU enabled hosts from non-GPU VM deployment

2014-05-20 Thread Sanjay Tripathi (JIRA)


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

Sanjay Tripathi reassigned CLOUDSTACK-6650:
---

Assignee: Sanjay Tripathi

 Reorder Cluster list in deployment planner to protect GPU enabled hosts from 
 non-GPU VM deployment
 --

 Key: CLOUDSTACK-6650
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6650
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
 Environment: MS 4.4
 XS 620SP1
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
 Fix For: 4.4.0


 If CS environment has GPU cards then for non-GPU enabled VM deployments, 
 deployment planner should check the non-GPU hosts first and if they are out 
 of capacity then deploy in  GPU enabled hosts.
 For now, this restriction is imposed at cluster level not at zone level, so 
 to protect GPU resources, CS should give lower priority to clusters which has 
 GPU enabled host and high priority to clusters which contains non-GPU enabled 
 hosts.



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

[jira] [Commented] (CLOUDSTACK-6712) NPE in findJobInstanceUuid() in ApiDBUtils


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

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

Commit 5b525aadf32a4d57d0b8d398bf084fe452916963 in cloudstack's branch 
refs/heads/4.4 from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b525aa ]

CLOUDSTACK-6712: NPE in findJobInstanceUuid() in ApiDBUtils


 NPE in findJobInstanceUuid() in ApiDBUtils
 --

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


 NPE in findJobInstanceUuid() in ApiDBUtils.
 There is no check that 'job.getInstanceId() == null' before trying to get 
 instance UUID from the job.



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

[jira] [Commented] (CLOUDSTACK-6714) Service monitoring conf is has issue with script in vmware

2014-05-20 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-6714: monitor script echo service command is added with quotes


 Service monitoring conf is has issue with script in vmware
 --

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


 There is issue in monitor_service.sh echo service name to conf file.
 setup1:
 root@r-13-VM:~#  s=[loadbalancing]; echo $s;
 i
 root@r-13-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]
 Dev setup:
 root@r-4-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]



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

[jira] [Resolved] (CLOUDSTACK-6714) Service monitoring conf is has issue with script in vmware


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

Jayapal Reddy resolved CLOUDSTACK-6714.
---

Resolution: Fixed

 Service monitoring conf is has issue with script in vmware
 --

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


 There is issue in monitor_service.sh echo service name to conf file.
 setup1:
 root@r-13-VM:~#  s=[loadbalancing]; echo $s;
 i
 root@r-13-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]
 Dev setup:
 root@r-4-VM:~# s=[loadbalancing]; echo $s;
 [loadbalancing]



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

[jira] [Resolved] (CLOUDSTACK-6319) Cannot create OVS network offering for VPC


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

Murali Reddy resolved CLOUDSTACK-6319.
--

Resolution: Fixed

its fixed in 4.4

 Cannot create OVS network offering for VPC
 --

 Key: CLOUDSTACK-6319
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6319
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
 Environment: Advanced zone with GRE isolation
 Xenserver 6.2.0 + SP1 
Reporter: Florin Dumitrascu
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.4.0

 Attachments: ovs_offering_vpc.jpg


 When creating the OVS network service offering and selecting VPC box, 
 I am not able to select Ovs from the Virtual Networking Provider drop 
 box, everything in there is greyed out.
 See below screenshot:
 http://imgur.com/ciJxZYs
 Solution:
  From: Murali Reddy [mailto:murali.re...@citrix.com]
  Sent: Tuesday, April 01, 2014 9:45 AM
  To: Florin Dumitrascu; d...@cloudstack.apache.org
  Cc: Jessica Wang; Nguyen Anh Tu (t...@apache.org); Alena Prokharchyk
  Subject: Re: Does OVS network provider support VPC ? (Cloudstack 
  4.3.0)
 
  There is explicit check added only to let providers that are marked as 
  VPC providers in the network offering for VPC. In 4.2 and 4.3 its hard 
  coded as below preventing Ovs to be used in VPC. Can you please a file 
  bug for 4.3.1? We just have to add Ovs in here.
 
  supportedProviders = Arrays.asList(Provider.VPCVirtualRouter,
  Provider.NiciraNvp, Provider.InternalLbVm, Provider.Netscaler) in VPC 
  manager



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

[jira] [Resolved] (CLOUDSTACK-6593) Connectivity service capabilites should be matched with the provider only if at least one capability is specified


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

Murali Reddy resolved CLOUDSTACK-6593.
--

Resolution: Fixed

 Connectivity service capabilites should be matched with the provider only if 
 at least one capability is specified
 -

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


 Connectivity service capabilites should be matched with the provider only if 
 at least one capability is specified.
 Currently even if 'StrechedL2'Subnet' capability is not specified, 
 'Connectivity' service provider is matched if provider supports 
 'StrechedL2'Subnet' capability. Fix should avoid the check, and only if the 
 createNetworkOffering 'StrechedL2'Subnet' capability is specified then it 
 should match against 'Connectivity' service provider



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

[jira] [Resolved] (CLOUDSTACK-6592) OVS distributed routing: make populate flooding rules transactional


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

Murali Reddy resolved CLOUDSTACK-6592.
--

Resolution: Fixed

 OVS distributed routing: make populate flooding rules transactional
 ---

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


 Currently when a tunnel port or vif is created/destroyed, L2 flooding table 
 is updated with new set of flooding rules which reflect the current set of 
 VIF's and tunnel ports that needed to be in the broadcast domain of tier. But 
 way its done is sequential with ovs-ofctl getting executed with each update.
 This bug is to club all the flow rule updates in to a single file and use 
 file option of ovs-ofctl to update the bridge.



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

[jira] [Resolved] (CLOUDSTACK-6161) distributed routing and network ACL with OVS plug-in


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

Murali Reddy resolved CLOUDSTACK-6161.
--

Resolution: Fixed

This feature is already implemented for 4.4

 distributed routing and network ACL with OVS plug-in
 

 Key: CLOUDSTACK-6161
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6161
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.4.0


 Support distributed routing and network ACL with OVS plug-in.
 Use-cases and functional specification can be found here:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/OVS+distributed+routing+and+network+ACL



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

[jira] [Resolved] (CLOUDSTACK-6686) NetworkACLItemCidrsDaoImpl uses firewallRuleId instead of networkAclItemId


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

Murali Reddy resolved CLOUDSTACK-6686.
--

Resolution: Fixed

 NetworkACLItemCidrsDaoImpl uses firewallRuleId instead of networkAclItemId
 --

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


 there is bug possible due to copy-paste, of the dao impl. Instead of use 
 network acl id, firewall id is bieng referred in the 
 NetworkACLItemCidrsDaoImpl.



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

[jira] [Resolved] (CLOUDSTACK-6685) OVS distributed firewall: source CIDR mismatch while populating ingress egress network ACL


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

Murali Reddy resolved CLOUDSTACK-6685.
--

Resolution: Fixed

 OVS distributed firewall: source CIDR mismatch while populating ingress  
 egress network ACL
 

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


 OVS distributed firewall: source CIDR mismatch while populating ingress  
 egress network ACL. source cidr is populated in nw_dst for both ingress and 
 egress ACL's same. 
 For egress ACL it should be set as 
  nw_src = tier's cidr nw_dst = source cidr in network ACL
 for ingress ACL it should be 
  nw_dst = tier's cidr nw_src = source cidr in network ACL



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

[jira] [Resolved] (CLOUDSTACK-6609) OVS distributed routing: ensure tunnels are created if not created already when OvsVpcPhysicalTopologyConfigCommand update is recived

2014-05-20 Thread ASF subversion and git services (JIRA)


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

Murali Reddy resolved CLOUDSTACK-6609.
--

Resolution: Fixed

 OVS distributed routing: ensure tunnels are created if not created already 
 when OvsVpcPhysicalTopologyConfigCommand update is recived
 -

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


 OVS distributed routing: ensure tunnels are created if not created already 
 when OvsVpcPhysicalTopologyConfigCommand update is recived.
 Currently if the tunnel creation fails, there is not retry logic. So use 
 OvsVpcPhysicalTopologyConfigCommand updates as an opputiunity to ensure 
 proper tunnels are established between the hosts.



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

[jira] [Commented] (CLOUDSTACK-6563) Integrate dependencies into MSI Windows installer


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

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

Commit 61c765b23027784483c5130c24373b0d1773e107 in cloudstack's branch 
refs/heads/master from [~damoder.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=61c765b ]

CLOUDSTACK-6563: Integrating setuptools for python into MSI

Signed-off-by: Abhinandan Prateek aprat...@apache.org


 Integrate dependencies into MSI Windows installer
 -

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






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

[jira] [Resolved] (CLOUDSTACK-6365) support virtual host and ssl in rabbitMQ event bus


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

Murali Reddy resolved CLOUDSTACK-6365.
--

Resolution: Fixed

 support virtual host and ssl in rabbitMQ event bus
 --

 Key: CLOUDSTACK-6365
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6365
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.1.0, 4.2.0, 4.3.0, 4.4.0
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.4.0


 AMQP servers has support for virtual host to isolate the different 
 application/users using same server. In any practical deployments its likely 
 that virtual hosts will be used. currently integration with AMQP servers for 
 event bus does not support virtual host.
 Also current communication between the management server (AMQP client) and 
 AMQP server is not secure. AQMP supports ssl which needs to be supported by 
 CloudStack.
 This bug is to add virtual host and ssl support in to RabbitMQ plug-in .



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

[jira] [Resolved] (CLOUDSTACK-5569) enhance OVS plug-in to support region level VPC and guest networks that span zones


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

Murali Reddy resolved CLOUDSTACK-5569.
--

Resolution: Fixed

Implementation for this feature is completed, and functionality is present in 
4.4. resolving the bug.

 enhance OVS plug-in to support region level VPC and guest networks that span 
 zones
 --

 Key: CLOUDSTACK-5569
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5569
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.4.0


 enhance OVS plug-in to support region level VPC and guest networks that span 
 zones.
 As part of this enhancement, ovs plug-in shall implement both the use cases 
 defined in CLOUDSTACK-5567 and CLOUDSTACK-5568



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

[jira] [Resolved] (CLOUDSTACK-5568) introduce notion of guest network that spans multiple zones


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

Murali Reddy resolved CLOUDSTACK-5568.
--

Resolution: Fixed

Implementation for this feature is completed, and functionality is present in 
4.4. resolving the bug.

 introduce notion of guest network that spans multiple zones
 ---

 Key: CLOUDSTACK-5568
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5568
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.4.0


 introduce notion of guest network that spans multiple zones. in current CS, 
 guest network is tied to a zone. Guest network can not span multiple zones. 
 This enhancement is to introduce notion of guest network that can span 
 multiple zones.



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

[jira] [Resolved] (CLOUDSTACK-5567) enable VPC at region level


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

Murali Reddy resolved CLOUDSTACK-5567.
--

Resolution: Fixed

Implementation for this feature is completed, and functionality is present in 
4.4. resolving the bug.

 enable VPC at region level
 --

 Key: CLOUDSTACK-5567
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5567
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.4.0


 Currently VPC in CloudStack is a zone level entity. So tiers with in the VPC 
 are confined to the zone to which VPC belongs. For an application deployed in 
 current model of VPC failure of the zone is a single point of failure. It is 
 desirable to make VPC a region level entity, where tiers in the VPC can be 
 created in different zones of the region. When tiers can be created in 
 different zones, application hosted in VPC can be architected to be highly 
 available masking zone failures by having redundant tiers in different zones.
 This enhancement targets only VPC tiers built with overlay networking. 



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

[jira] [Resolved] (CLOUDSTACK-6608) OVS distributed firewall: default ACL rule is not getting applied when a tier in VPC is created.


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

Murali Reddy resolved CLOUDSTACK-6608.
--

Resolution: Fixed

 OVS distributed firewall: default ACL rule is not getting applied when a tier 
 in VPC is created.
 

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


 OVS distributed firewall: default ACL rule is not getting applied when a tier 
 in VPC is created. Current logic in OVS tunnel manager is updating ACL table 
 on the host only when ACL is replace, but not for the default ACL that gets 
 applied when network is created.
 Fix should ensure OvsVpcRoutingPolicyConfigCommand update is send to the 
 hosts on which VPC spans when tier is created.



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

[jira] [Resolved] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table


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

Jayapal Reddy resolved CLOUDSTACK-6485.
---

Resolution: Cannot Reproduce

Create gateway is creating in latest 4.4.  So marking it as Can't reproduce.

 [vpc] new private gateway network is registered wrong in network table
 --

 Key: CLOUDSTACK-6485
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
Reporter: Anton Opgenoort
Assignee: Daan Hoogland
Priority: Critical

 When creating a private gateway for a VPC router on a network not yet known 
 to Cloudstack, Cloudstack ‘documents’ this network in the networks table.
 For normal guest networks, which should be associated with a single VPC, 
 Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to 
 provision all networks and nics on a VPC router when it is created. Since 
 this table is all about network provisioning it makes sense to ‘document’ the 
 network cidr and gateway present in that nework. For guest tiers this usually 
 is the VPC router itself, so the interface IP’s on a VPC router are the 
 gateway IP’s found in the networks table.
 Unfortunately the VPC_ID is also recorded for the private gateway network 
 when it is first created. So the first VPC to be plugged on the private 
 gateway network also has that same network associated as a guest network 
 tier, instead of just a private gateway network.
 This by itself will not quickly become a problem, because private gateways 
 are first plugged on a running vpc router which is not likely to be recreated 
 any time soon after that.
 But as soon as this first ever VPC router on the private gateway network is 
 recreated due to a destroy of the VPC Router, all associated networks are 
 looked up in the networks table. 
 Because the private gateway network is ‘documented’ with the actual upstream 
 gateway used by the VPC router defintion, the VPC router provisions a NIC on 
 the private gateway network using the IP address of the actual upstream 
 gateway creating an IP conflict on the private gateway network, effectively 
 breaking down the upstream gateway functionality for all attached private 
 gateways of other vpc's.



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

[jira] [Updated] (CLOUDSTACK-6707) [SDN] OVS bridge/tunnel ports are not getting deleted from Host even though there are no vms in the network


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

Sanjeev N updated CLOUDSTACK-6707:
--

Assignee: Murali Reddy

 [SDN] OVS bridge/tunnel ports are not getting deleted from Host even though 
 there are no vms in the network
 ---

 Key: CLOUDSTACK-6707
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6707
 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 branch with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Murali Reddy
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.rar, ovstunnel-host13.log, 
 ovstunnel-host14.log


 [SDN] OVS bridge/tunnel ports are not getting deleted from Host even though 
 there are no vms in the network
 Steps to Reproduce:
 
 1.Bring up CS in advanced zone with two hosts in a cluster
 2.Create physical network with GRE isolation
 3.Create network with Connectivity service and OVS as the provider
 4.Deploy couple of vms in the above network.
 5.Migrate vms to one host and make sure that all the vms (including vr) are 
 running only on one host
 6.Verify tunnel ports on the host where there are no vms running
 Expected Result:
 ==
 Tunnel ports and ovs bridge shall be deleted from the host where no vms are 
 running
 Actual result:
 ===
 OVS bridge and tunnel ports are still present even after migrating all the 
 vms to another host in the cluster
 Observations:
 
 Following bridge info is from the host on with all system vms and guest vms 
 are running
 [root@xen-host-13 ~]# ovs-vsctl list-br
 xapi0
 xapi1
 xapi2
 xenbr0
 xenbr1
 On the host where only guest vms are running
 [root@xen-host-14 ~]# ovs-vsctl list-br
 xapi2
 xenbr0
 xenbr1
 Before migration:
 ==
 [root@xen-host-13 ~]# ovs-vsctl list-ports xapi2
 t997-1-2
 vif12.0
 vif13.0
 [root@xen-host-14 ~]# ovs-vsctl list-ports xapi2
 t997-2-1
 vif7.0
 After migration:
 =
 [root@xen-host-13 ~]# ovs-vsctl list-ports xapi2
 t997-1-2
 vif12.0
 vif13.0
 vif15.0
 [root@xen-host-13 ~]#
 Following is the target host on which no vms are running:
 [root@xen-host-14 ~]# ovs-vsctl list-br
 xapi2
 xenbr0
 xenbr1
 [root@xen-host-14 ~]# ovs-vsctl list-ports xapi2
 t997-2-1



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

[jira] [Updated] (CLOUDSTACK-6715) [SDN] Inconsistency in ovs-flow table after vm migration from one host to another


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

Sanjeev N updated CLOUDSTACK-6715:
--

Assignee: Murali Reddy

 [SDN] Inconsistency in ovs-flow table after vm migration from one host to 
 another 
 --

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

 Attachments: management-server.rar, ovstunnel-host13.log, 
 ovstunnel-host14.log


 [SDN] Inconsistency in ovs-flow table after vm migration from one host to 
 another 
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with two xen hosts in a cluster
 2.Create physical network with GRE isolation
 3.Create isolated network with OVS provider 
 4.Deploy few vms in the network and make sure that all the vms(including VR) 
 are deployed on only one host.
 5.Now migrate one vm to another host in the cluster and verify flow tables 
 for this isolated network bridge on both the xen hosts
 Result:
 ===
 Inconsistency in flow tables on both the xen hosts
 Following it the flow table from the host before vm migration (All the vms 
 and VR were only on this host before vm migration):
 [root@xen-host-14 ~]# ovs-ofctl dump-flows xapi4
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1173.14s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:1,output:2
  cookie=0x0, duration=1173.15s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=1203.276s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=1,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=1226.258s, table=0, n_packets=901, n_bytes=85612, 
 priority=0 actions=NORMAL
  cookie=0x0, duration=1173.129s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:1,output:2
  cookie=0x0, duration=1203.286s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
  cookie=0x0, duration=1173.167s, table=0, n_packets=7, n_bytes=1494, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 Flow table after vm migration on the same host:
 [root@xen-host-14 ~]# ovs-ofctl dump-flows xapi4
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=992.789s, table=0, n_packets=0, n_bytes=0, priority=0 
 actions=NORMAL
 [root@xen-host-14 ~]#
 Ports info on the bridge after vm migration:
 [root@xen-host-14 ~]# ovs-vsctl list-ports xapi4
 t986-2-1
 vif11.0
 vif12.0
 Flow table on the target host where vm was migrated to:
 [root@xen-host-13 ~]# ovs-ofctl dump-flows xapi4
 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=1025.129s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,dl_dst=ff:ff:ff:ff:ff:ff actions=output:2
  cookie=0x0, duration=1025.139s, table=0, n_packets=0, n_bytes=0, 
 priority=1200,ip,in_port=2,nw_dst=224.0.0.0/24 actions=NORMAL
  cookie=0x0, duration=1032.932s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop
  cookie=0x0, duration=1033.247s, table=0, n_packets=0, n_bytes=0, priority=0 
 actions=NORMAL
  cookie=0x0, duration=1025.119s, table=0, n_packets=0, n_bytes=0, 
 priority=1100,ip,nw_dst=224.0.0.0/24 actions=output:2
  cookie=0x0, duration=1032.942s, table=0, n_packets=0, n_bytes=0, 
 priority=1000,in_port=1,dl_dst=ff:ff:ff:ff:ff:ff actions=drop
  cookie=0x0, duration=1025.148s, table=0, n_packets=1, n_bytes=42, 
 priority=1200,in_port=2,dl_dst=ff:ff:ff:ff:ff:ff actions=NORMAL
 [root@xen-host-13 ~]# ovs-vsctl list-ports xapi4
 t986-1-2
 vif17.0
 Following is the log snippet from both the hosts during vm migration (tunnel 
 creation during vm migration):
 2014-05-20 11:31:21DEBUG [root]  VMOPS enter  create_tunnel 
 2014-05-20 11:31:21DEBUG [root] Creating tunnel from host 2 to host 1 
 with GRE key 986
 2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
 '--timeout=30', 'wait-until', 'bridge', 'xapi4', '--', 'get', 'bridge', 
 'xapi4', 'name']
 2014-05-20 11:31:21DEBUG [root] bridge xapi4 for creating tunnel - 
 VERIFIED
 2014-05-20 11:31:21DEBUG [root] Executing:['/usr/bin/ovs-vsctl', 
 'add-port', 'xapi4', 't986-2-1', '--', 'set', 'interface', 't986-2-1', 
 'type=gre', 'options:key=986', 'options:remote_ip=10.147.40.13']
 2014-05-20 11:31:21DEBUG [root]

[jira] [Closed] (CLOUDSTACK-6607) Create VPC is failing.


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

manasaveloori closed CLOUDSTACK-6607.
-


Verified the issue.
Working fine.

 Create VPC is failing.
 --

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

 Attachments: management-server.log


 Deploy CS using Xenserver 6.2.
 Create a VPC.
 Observed that VPC creation is failing  with below exception:
 2014-05-08 04:29:48,225 WARN  [c.c.h.x.r.XenServer56Resource] 
 (DirectAgent-95:ctx-70fed5e6) Failed to get network usage stats due to
 java.lang.Exception:  vpc network usage plugin call failed
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.VPCNetworkUsage(XenServer56Resource.java:183)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.execute(XenServer56Resource.java:194)
 at 
 com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:58)
 at 
 com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:93)
 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 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-05-08 04:29:48,229 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-95:ctx-70fed5e6) Seq 1-126100789566377982: Response Received:
 2014-05-08 04:29:48,231 DEBUG [c.c.a.t.Request] (DirectAgent-95:ctx-70fed5e6) 
 Seq 1-126100789566377982: Processing:  { Ans: , MgmtId: 7672522866886, via: 
 1, Ver: v1, Flags: 110, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:10,name:r-10-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
  GNU/Linux 7(32-bit),bootArgs: vpccidr=10.0.0.0/16 
 domain=cs2cloud.internal dns1=10.140.50.6 template=domP name=r-10-VM 
 eth0ip=169.254.1.131 eth0mask=255.255.0.0 type=vpcrouter 
 disable_rp_filter=true,rebootOnCrash:false,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:91408a0b18abbc99,params:{},uuid:6e38c35d-7c5d-4982-bddf-f21b7063e1db,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:c8cf4a4d-e552-4b82-943e-af3df990a445,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:c040ab5c-6f99-3d0b-9377-dcf76c5798de,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryxen,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryxen/?ROLE=PrimarySTOREUUID=c040ab5c-6f99-3d0b-9377-dcf76c5798de}},name:ROOT-10,size:262144,path:e6ed1394-ee6b-44d5-8599-688e5efe30a7,volumeId:11,vmName:r-10-VM,accountId:2,format:VHD,id:11,deviceId:0,hypervisorType:XenServer}},diskSeq:0,path:e6ed1394-ee6b-44d5-8599-688e5efe30a7,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:262144}}],nics:[{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:55d14c0b-b7ff-4698-9387-ec3e16034d36,ip:169.254.1.131,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:01:83,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false}]},_iqnToPath:{},result:true,wait:0}},{com.cloud.agent.api.check.CheckSshAnswer:{result:true,wait:0}},{com.cloud.agent.api.GetDomRVersionAnswer:{templateVersion:Cloudstack
  Release 4.4.0 Fri Apr 11 18:25:32 UTC

[jira] [Created] (CLOUDSTACK-6716) /usr has been sized to small and ends up being 100% full on SSVM and CVM

2014-05-20 Thread Joris van Lieshout (JIRA)

Joris van Lieshout created CLOUDSTACK-6716:
--

 Summary: /usr has been sized to small and ends up being 100% full 
on SSVM and CVM
 Key: CLOUDSTACK-6716
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6716
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: Future, 4.3.0, 4.4.0
Reporter: Joris van Lieshout


The systemvmtemplate for 4.3 and 4.4 has a too small /usr volume and ends up 
100% full on Secondary Storage VMs and Console VMs.

root@v-xxx-VM:~# df -h
Filesystem  Size  Used Avail Use% 
Mounted on
rootfs  276M  144M  118M  55% /
udev 10M 0   10M   0% 
/dev
tmpfs   100M  156K  100M   1% 
/run
/dev/disk/by-uuid/0721ecee-214a-4143-8d88-a4075cc2cd89  276M  144M  118M  55% /
tmpfs   5.0M 0  5.0M   0% 
/run/lock
tmpfs   314M 0  314M   0% 
/run/shm
/dev/xvda1   45M   22M   21M  51% 
/boot
/dev/xvda6   98M  5.6M   88M   6% 
/home
/dev/xvda8  368M   11M  339M   3% 
/opt
/dev/xvda10  63M  5.3M   55M   9% 
/tmp
/dev/xvda7  610M  584M 0 100% 
/usr
/dev/xvda9  415M  316M   78M  81% 
/var



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

[jira] [Created] (CLOUDSTACK-6717) [OVS][UI]VPC network creation page does not display custom network offering created for vpc

Sanjeev N created CLOUDSTACK-6717:
-

 Summary: [OVS][UI]VPC network creation page does not display 
custom network offering created for vpc
 Key: CLOUDSTACK-6717
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6717
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 branch with commit 
e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Gabor Apati-Nagy
Priority: Critical
 Fix For: 4.4.0


[SDN][UI]VPC network creation page does not display custom network offering 
created for vpc

Steps to Reproduce:

1.Bring up CS in advanced zone with xen cluster
2.Create physical network with GRE isolation
3.Create Region level vpc
4.Create isolated network offering for vpc with virtualnetworking service and 
ovs as the service provider
5.Enable the network offering
6.In region level vpc try to create tier with above created network offering

Result:
==
Add tier in VPC page does not display the custom vpc offering created with ovs 
provider. It only shows the default vpc offerings in the drop down list.

Attaching screen shot to describe the issue.




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

[jira] [Updated] (CLOUDSTACK-6717) [OVS][UI]VPC network creation page does not display custom network offering created for vpc


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

Sanjeev N updated CLOUDSTACK-6717:
--

Attachment: vpc_tier.PNG

Attached screen shot to describe the issue.

 [OVS][UI]VPC network creation page does not display custom network offering 
 created for vpc
 ---

 Key: CLOUDSTACK-6717
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6717
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 branch with commit 
 e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Gabor Apati-Nagy
Priority: Critical
 Fix For: 4.4.0

 Attachments: vpc_tier.PNG


 [SDN][UI]VPC network creation page does not display custom network offering 
 created for vpc
 Steps to Reproduce:
 
 1.Bring up CS in advanced zone with xen cluster
 2.Create physical network with GRE isolation
 3.Create Region level vpc
 4.Create isolated network offering for vpc with virtualnetworking service and 
 ovs as the service provider
 5.Enable the network offering
 6.In region level vpc try to create tier with above created network offering
 Result:
 ==
 Add tier in VPC page does not display the custom vpc offering created with 
 ovs provider. It only shows the default vpc offerings in the drop down list.
 Attaching screen shot to describe the issue.



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

[jira] [Commented] (CLOUDSTACK-6716) /usr has been sized to small and ends up being 100% full on SSVM and CVM

2014-05-20 Thread Joris van Lieshout (JIRA)


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

Joris van Lieshout commented on CLOUDSTACK-6716:


I already have a solution for this. Will submit the patch on review board today.

 /usr has been sized to small and ends up being 100% full on SSVM and CVM
 

 Key: CLOUDSTACK-6716
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6716
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: Future, 4.3.0, 4.4.0
Reporter: Joris van Lieshout

 The systemvmtemplate for 4.3 and 4.4 has a too small /usr volume and ends up 
 100% full on Secondary Storage VMs and Console VMs.
 root@v-xxx-VM:~# df -h
 Filesystem  Size  Used Avail Use% 
 Mounted on
 rootfs  276M  144M  118M  55% 
 /
 udev 10M 0   10M   0% 
 /dev
 tmpfs   100M  156K  100M   1% 
 /run
 /dev/disk/by-uuid/0721ecee-214a-4143-8d88-a4075cc2cd89  276M  144M  118M  55% 
 /
 tmpfs   5.0M 0  5.0M   0% 
 /run/lock
 tmpfs   314M 0  314M   0% 
 /run/shm
 /dev/xvda1   45M   22M   21M  51% 
 /boot
 /dev/xvda6   98M  5.6M   88M   6% 
 /home
 /dev/xvda8  368M   11M  339M   3% 
 /opt
 /dev/xvda10  63M  5.3M   55M   9% 
 /tmp
 /dev/xvda7  610M  584M 0 100% 
 /usr
 /dev/xvda9  415M  316M   78M  81% 
 /var



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

[jira] [Created] (CLOUDSTACK-6718) [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the service provider for services other than VirtualNetworking

Sanjeev N created CLOUDSTACK-6718:
-

 Summary: [OVS][UI] Isolated network offering (non-vpc) creation 
page shows ovs as the service provider for services other than 
VirtualNetworking
 Key: CLOUDSTACK-6718
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6718
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.4.0


[OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the 
service provider for services other than VirtualNetworking

Steps to Reprodude:

1.Bring up CS in advanced zone 
2.In UI navigate to Service Offerings - Network Offerings-  and click on 
Add Network Offering and choose Guest Type as Isolated.
3.In Supported Services section in Network offering creation page the drop down 
list for LB,StaticNAT and PF services show OVS as one of the supported service 
providers
But OVS does not support those services. 

Attaching screen shot to describe the issue.




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

[jira] [Updated] (CLOUDSTACK-6718) [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the service provider for services other than VirtualNetworking


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

Sanjeev N updated CLOUDSTACK-6718:
--

Attachment: ovs_no.PNG

Attaching screen shot to describe the issue.

 [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the 
 service provider for services other than VirtualNetworking
 -

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

 Attachments: ovs_no.PNG


 [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the 
 service provider for services other than VirtualNetworking
 Steps to Reprodude:
 
 1.Bring up CS in advanced zone 
 2.In UI navigate to Service Offerings - Network Offerings-  and click 
 on Add Network Offering and choose Guest Type as Isolated.
 3.In Supported Services section in Network offering creation page the drop 
 down list for LB,StaticNAT and PF services show OVS as one of the supported 
 service providers
 But OVS does not support those services. 
 Attaching screen shot to describe the issue.



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

[jira] [Reopened] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table


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

Daan Hoogland reopened CLOUDSTACK-6485:
---


It is a clear and present danger in our production environment. reopening

 [vpc] new private gateway network is registered wrong in network table
 --

 Key: CLOUDSTACK-6485
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1
Reporter: Anton Opgenoort
Assignee: Daan Hoogland
Priority: Critical

 When creating a private gateway for a VPC router on a network not yet known 
 to Cloudstack, Cloudstack ‘documents’ this network in the networks table.
 For normal guest networks, which should be associated with a single VPC, 
 Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to 
 provision all networks and nics on a VPC router when it is created. Since 
 this table is all about network provisioning it makes sense to ‘document’ the 
 network cidr and gateway present in that nework. For guest tiers this usually 
 is the VPC router itself, so the interface IP’s on a VPC router are the 
 gateway IP’s found in the networks table.
 Unfortunately the VPC_ID is also recorded for the private gateway network 
 when it is first created. So the first VPC to be plugged on the private 
 gateway network also has that same network associated as a guest network 
 tier, instead of just a private gateway network.
 This by itself will not quickly become a problem, because private gateways 
 are first plugged on a running vpc router which is not likely to be recreated 
 any time soon after that.
 But as soon as this first ever VPC router on the private gateway network is 
 recreated due to a destroy of the VPC Router, all associated networks are 
 looked up in the networks table. 
 Because the private gateway network is ‘documented’ with the actual upstream 
 gateway used by the VPC router defintion, the VPC router provisions a NIC on 
 the private gateway network using the IP address of the actual upstream 
 gateway creating an IP conflict on the private gateway network, effectively 
 breaking down the upstream gateway functionality for all attached private 
 gateways of other vpc's.



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

[jira] [Assigned] (CLOUDSTACK-6667) Can't provision a site-to-site VPN with multiple CIDRs

2014-05-20 Thread Alex Hitchins (JIRA)


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

Alex Hitchins reassigned CLOUDSTACK-6667:
-

Assignee: Alex Hitchins

 Can't provision a site-to-site VPN with multiple CIDRs
 --

 Key: CLOUDSTACK-6667
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6667
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.2.1
 Environment: CloudStack 4.2.1
Reporter: Paul Angus
Assignee: Alex Hitchins
Priority: Critical

 When attempting to create a site-to-site VPN with multiple remote CIDRs ie:
 172.1.0.0/16,172.11.0.0/16
 CloudStack reports that 172.1.0.0/16,172.11.0.0/16 is an invalid CIDR.
 CloudStack code does not appear to be enumerating the string as two comma 
 separated CIDRs.



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

[jira] [Resolved] (CLOUDSTACK-6084) [Automation] Failed to create private gateway


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

Jayapal Reddy resolved CLOUDSTACK-6084.
---

Resolution: Cannot Reproduce

Create gateway is creating in latest 4.4. So marking it as Can't reproduce

 [Automation] Failed to create private gateway
 -

 Key: CLOUDSTACK-6084
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6084
 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: xenserver 6.2 ,advanced zone
Reporter: Srikanteswararao Talluri
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.4.0


 Steps to reproduce:
 = 
# 1) Create VPC
 self.createVPC()
 # 2) Create ACl
 self.createACL()
 # 3) Create ACl Item
 self.createACLItem()
 # 4) Create network with ACL
 self.createNetwork()
 # 5) create private gw
 self.createPvtGw()
 Logs can be found here : 
 http://jenkins.buildacloud.org/view/cloudstack-qa-master/job/test-matrix-master/3/distro=centos63,hypervisor=xen,profile=xen62/artifact/3.tar.bz2
 ===START===  10.208.8.5 -- GET  
 physicalnetworkid=200vpcid=e1f5910c-1352-4274-9326-f8413f41d4bfsourcenatsupported=trueaclid=bdca388c-c6cf-4757-b72d-c07e22ff9fa5vlan=30response=jsonnetmask=255.255.255.0apiKey=ZVang0oygdXeY5o3XEz4X3i60YHJj5nVE8gN6hR_zlBWzIoxby09FIxK_a-UlWl_jzLen_4I8oXgmQLppn3ikwcommand=createPrivateGatewaysignature=2Z89SOGldeUm9Lfg10R8rcx%2FRZ0%3Dipaddress=10.147.30.200gateway=10.147.30.1
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,779 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-335:ctx-48012a52) Ping from 1(apache-81-3)
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,808 DEBUG [network.vpc.VpcManagerImpl] (catalina-exec-3:ctx-d5a8de3b 
 ctx-fa9b0854 ctx-5b785c5e) Creating Private gateway for VPC [VPC [6-new vpc]
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,808 INFO  [network.vpc.VpcManagerImpl] (catalina-exec-3:ctx-d5a8de3b 
 ctx-fa9b0854 ctx-5b785c5e) creating new network for vpc [VPC [6-new vpc] 
 using broadcast uri: 30
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,834 DEBUG [contrail.management.ContrailGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Refusing to design 
 this network
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,834 DEBUG [network.guru.MidoNetGuestNetworkGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) design called
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,835 DEBUG [network.guru.MidoNetGuestNetworkGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Refusing to design 
 this network, the physical isolation type is not MIDO
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,835 DEBUG [network.guru.NiciraNvpGuestNetworkGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Refusing to design 
 this network
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,840 DEBUG [network.opendaylight.OpendaylightGuestNetworkGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Refusing to design 
 this network
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,841 DEBUG [network.guru.OvsGuestNetworkGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Refusing to design 
 this network
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,857 DEBUG [network.guru.SspGuestNetworkGuru] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) SSP not configured 
 to be active
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,858 DEBUG [engine.orchestration.NetworkOrchestrator] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Releasing lock for 
 Acct[bcbb718a-93c7-11e3-af4f-b6c8db337241-system]
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,858 DEBUG [cloud.network.NetworkServiceImpl] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Created private 
 network Ntwk[230|Guest|5]
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,864 DEBUG [cloud.network.NetworkServiceImpl] 
 (catalina-exec-3:ctx-d5a8de3b ctx-fa9b0854 ctx-5b785c5e) Private network 
 Ntwk[230|Guest|5] is created
 Feb 12 02:23:49 cloudstack-centos63.fmt.vmops.com local0: 2014-02-12 
 10:23:49,891 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-310:ctx-dca6e64d) Ping from

[jira] [Resolved] (CLOUDSTACK-6498) [Automation] unable to start management server after restart

2014-05-20 Thread Harikrishna Patnala (JIRA)


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

Harikrishna Patnala resolved CLOUDSTACK-6498.
-

Resolution: Cannot Reproduce

Not able to reproduce it now, so closing.

 [Automation] unable to start management server after restart
 

 Key: CLOUDSTACK-6498
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6498
 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: advanced zone
 xenserer 6.2
Reporter: Srikanteswararao Talluri
Assignee: Harikrishna Patnala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: cloud.sql, log.tar.gz


 on the daily automation environment, After the zone is deployed , system VMs 
 came up fine. After setting few global settings, I tried to restart 
 management server, it never came up again. I could see some db exceptions 
 related to duplicate keys.
 I will attach management server logs to this bug for your reference.
 Caught SQLException when inserting system account
 com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: 
 Duplicate entry '1' for key 'PRIMARY'
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
 at com.mysql.jdbc.Util.getInstance(Util.java:386)
 at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529)
 at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990)
 at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151)
 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625)
 at 
 com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318)
 at 
 org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
 at 
 org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
   
 
 14761,2-9 96%



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

[jira] [Created] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC

2014-05-20 Thread sadhu suresh (JIRA)

sadhu suresh created CLOUDSTACK-6719:


 Summary: OVS:VPC:UI wizard allowing to add non OVS enabled network 
to distributed VPC
 Key: CLOUDSTACK-6719
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6719
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.4.0
Reporter: sadhu suresh
Assignee: Gabor Apati-Nagy
 Fix For: 4.4.0



problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network 
to  VPC created  with OVS+distributed VPC VR

Steps to Reprodude:

1.Bring up CS in advanced zon
2.create a vpc offering with OVS and along with other all supported  services
3. create a VPC with above network offering
4.try to create non ovs network(i.e network created default isolated vpc 
offering) on ovs based VPC.

actual result:
allowing to add non OVS enabled network to  OVS  enabled VPC

expected result:
it should not allow to add  non OVS enabled network to  OVS  enabled VPC.



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

[jira] [Updated] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC

2014-05-20 Thread sadhu suresh (JIRA)


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

sadhu suresh updated CLOUDSTACK-6719:
-

Component/s: Management Server
Description: 
problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network 
to  VPC created  with OVS+distributed VPC VR

Steps to Reprodude:

1.Bring up CS in advanced zon
2.create a vpc offering with OVS and along with other all supported  services
3. create a VPC with above network offering
4.try to create non ovs network(i.e network created default isolated vpc 
offering) on ovs based VPC.

actual result:
allowing to add non OVS enabled network to  OVS  enabled VPC

expected result:
it should not allow to add  non OVS enabled network to  OVS  enabled VPC.

  was:

problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network 
to  VPC created  with OVS+distributed VPC VR

Steps to Reprodude:

1.Bring up CS in advanced zon
2.create a vpc offering with OVS and along with other all supported  services
3. create a VPC with above network offering
4.try to create non ovs network(i.e network created default isolated vpc 
offering) on ovs based VPC.

actual result:
allowing to add non OVS enabled network to  OVS  enabled VPC

expected result:
it should not allow to add  non OVS enabled network to  OVS  enabled VPC.

   Assignee: Murali Reddy  (was: Gabor Apati-Nagy)

 OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC
 

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


 problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled 
 network to  VPC created  with OVS+distributed VPC VR
 Steps to Reprodude:
 
 1.Bring up CS in advanced zon
 2.create a vpc offering with OVS and along with other all supported  services
 3. create a VPC with above network offering
 4.try to create non ovs network(i.e network created default isolated vpc 
 offering) on ovs based VPC.
 actual result:
 allowing to add non OVS enabled network to  OVS  enabled VPC
 expected result:
 it should not allow to add  non OVS enabled network to  OVS  enabled VPC.



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

[jira] [Created] (CLOUDSTACK-6721) VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment

2014-05-20 Thread ASF subversion and git services (JIRA)

Murali Reddy created CLOUDSTACK-6721:


 Summary: VolumeApiServiceImpl is sending wrong type for 
updateAsyncJobAttachment
 Key: CLOUDSTACK-6721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.4.0


VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment. Its 
sending lower case 'volume' instead of 'Volume' resulting in instance type 
matching logic failure in APIDB utils



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

[jira] [Commented] (CLOUDSTACK-6721) VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment


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

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

Commit c5d48c05307c0bceb17cae78976595f814b3aba3 in cloudstack's branch 
refs/heads/4.4-forward from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5d48c0 ]

CLOUDSTACK-6721: VolumeApiServiceImpl is sending wrong type for
updateAsyncJobAttachment

fix sends 'Volume' instead of 'volume'


 VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment
 ---

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


 VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment. Its 
 sending lower case 'volume' instead of 'Volume' resulting in instance type 
 matching logic failure in APIDB utils



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

[jira] [Updated] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN


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

Daan Hoogland updated CLOUDSTACK-6444:
--

Priority: Trivial  (was: Blocker)

 [Automation] test_01_primary_storage_iscsi  failed on 
 test_primary_storage.py - Wrong iscsi path format - it should be 
 /targetIQN/LUN 
 

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

 Attachments: management-server.log.2014-04-16.gz


 Error Message:
 Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
   begin captured logging  
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 STARTED : TC: test_01_primary_storage_iscsi :::
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 sending GET request: listZones {}
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
  HTTP/1.1 200 735
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Request: 
 http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
  Response: { listzonesresponse : { count:2 ,zone : [  
 {id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
  
 {id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
  ] } }
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 sending GET request: listPods {'zoneid': 
 u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
  HTTP/1.1 200 314
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Request: 
 http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
  Response: { listpodsresponse : { count:1 ,pod : [  
 {id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
  ] } }
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 sending GET request: listClusters {'zoneid': 
 u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Computed Signature by Marvin: CGgAerZxK5EJBr34YnPiWBJHqWg=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET

[jira] [Created] (CLOUDSTACK-6722) [OVS][UI] Network created with StretchedL2Subnet is not available for vm deployement in other zones

Sanjeev N created CLOUDSTACK-6722:
-

 Summary: [OVS][UI] Network created with StretchedL2Subnet is not 
available for vm deployement in other zones
 Key: CLOUDSTACK-6722
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6722
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller, UI
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Gabor Apati-Nagy
Priority: Critical
 Fix For: 4.4.0


[OVS][UI] Network created with StretchedL2Subnet is not available for vm 
deployement in other zones

Steps to Reproduce:
=
1.Bring up CS with two or more zones say zone1 and zone2
2.Create physical networks with GRE isolation in all the zones
3.Create isolated network offering with VirtualNetwork service and ovs as the 
service provider and with StretchedL2Subnet Capability 
4.In zone1 create guest network with above network offering
5.Deploy few vms in zone1 in the above network
6.In zone2 try to deploy vm in above network

Result:
==
vm deployment wizard  does not show the network created in zone1 in list of 
available networks for vm deployment. It only shows the network created in zone2

Expected Result:
=
Wizard should show networks created in zone2 as well as stretched networks 
created in other zones

Vm deployment in zone2 with stretched network created in zone1 works fine with 
API



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

[jira] [Commented] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN


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

Daan Hoogland commented on CLOUDSTACK-6444:
---

Changed to trivial, as it was ignored after comments.

 [Automation] test_01_primary_storage_iscsi  failed on 
 test_primary_storage.py - Wrong iscsi path format - it should be 
 /targetIQN/LUN 
 

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

 Attachments: management-server.log.2014-04-16.gz


 Error Message:
 Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
   begin captured logging  
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 STARTED : TC: test_01_primary_storage_iscsi :::
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 sending GET request: listZones {}
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
  HTTP/1.1 200 735
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Request: 
 http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
  Response: { listzonesresponse : { count:2 ,zone : [  
 {id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
  
 {id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
  ] } }
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 sending GET request: listPods {'zoneid': 
 u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.240.161
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
  HTTP/1.1 200 314
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Request: 
 http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
  Response: { listpodsresponse : { count:1 ,pod : [  
 {id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
  ] } }
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 sending GET request: listClusters {'zoneid': 
 u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
 test_01_primary_storage_iscsi 
 (integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG: 
 Computed Signature by Marvin: CGgAerZxK5EJBr34YnPiWBJHqWg=
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection

[jira] [Commented] (CLOUDSTACK-6675) NPE while executing updatePortForwardingRule

2014-05-20 Thread ASF subversion and git services (JIRA)


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

Daan Hoogland commented on CLOUDSTACK-6675:
---

Chandan, please follow up on your issues. Can this be closed?

 NPE while executing updatePortForwardingRule
 

 Key: CLOUDSTACK-6675
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6675
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Alena Prokharchyk
Priority: Blocker
 Fix For: 4.4.0


 NPE hit while executing updatePortForwardingRule CS API. I am blocked on 
 executing a Use Case which is based on this API.
 =
 NullPointerException:
 =
 2014-05-14 11:44:45,215 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-d408ed7f) ===START===  127.0.0.1 -- GET  
 apikey=dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQcommand=updatePortForwardingRulefordisplay=falseid=b767a533-e3ed-45ad-ab2b-68ea806438f6response=jsonapikey=dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQsignature=jF8MpXvj4u4NKyajmbuFBPAcw2M%3D
 2014-05-14 11:44:45,286 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-10:ctx-d408ed7f ctx-3df22ad6 ctx-84f5b16f) submit async 
 job-886, details: AsyncJobVO {id:886, userId: 1, accountId: 1, instanceType: 
 None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.user.firewall.UpdatePortForwardingRuleCmd, 
 cmdInfo: 
 {response:json,id:b767a533-e3ed-45ad-ab2b-68ea806438f6,ctxDetails:{\Network\:\b767a533-e3ed-45ad-ab2b-68ea806438f6\,\com.cloud.network.rules.FirewallRule\:23},cmdEventType:NET.RULEMODIFY,ctxUserId:1,httpmethod:GET,uuid:b767a533-e3ed-45ad-ab2b-68ea806438f6,ctxAccountId:1,ctxStartEventId:1859,signature:jF8MpXvj4u4NKyajmbuFBPAcw2M\u003d,apikey:dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQ,fordisplay:false},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 6638073284439, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-05-14 11:44:45,287 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-d408ed7f ctx-3df22ad6 ctx-84f5b16f) ===END===  
 127.0.0.1 -- GET  
 apikey=dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQcommand=updatePortForwardingRulefordisplay=falseid=b767a533-e3ed-45ad-ab2b-68ea806438f6response=jsonapikey=dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQsignature=jF8MpXvj4u4NKyajmbuFBPAcw2M%3D
 2014-05-14 11:44:45,288 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-110:job-886) Add job-886 into job monitoring
 2014-05-14 11:44:45,292 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-11:ctx-3d255b35) ===START===  127.0.0.1 -- GET  
 apikey=dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQcommand=queryAsyncJobResultjobId=0571d334-e071-4073-b404-1e388195733bresponse=jsonapikey=dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQsignature=EKX465Tc%2B3NvETQRtvhWEynB%2Faw%3D
 2014-05-14 11:44:45,295 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-110:job-886) Executing AsyncJobVO {id:886, userId: 1, 
 accountId: 1, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.user.firewall.UpdatePortForwardingRuleCmd, 
 cmdInfo: 
 {response:json,id:b767a533-e3ed-45ad-ab2b-68ea806438f6,ctxDetails:{\Network\:\b767a533-e3ed-45ad-ab2b-68ea806438f6\,\com.cloud.network.rules.FirewallRule\:23},cmdEventType:NET.RULEMODIFY,ctxUserId:1,httpmethod:GET,uuid:b767a533-e3ed-45ad-ab2b-68ea806438f6,ctxAccountId:1,ctxStartEventId:1859,signature:jF8MpXvj4u4NKyajmbuFBPAcw2M\u003d,apikey:dXvODaGH1UvF0WKs63T_wCXsVEs5nFTJaNhBJCGF3sCYwgbuvUaelZf6V8tWjTsyB53LSIT9Wf4UUUQKSz8UXQ,fordisplay:false},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 6638073284439, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-05-14 11:44:45,308 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
 (consoleproxy-1:ctx-a4771a58) Zone 1 is ready to launch console proxy
 2014-05-14 11:44:45,308 WARN  [c.c.a.d.ParamGenericValidationWorker] 
 (API-Job-Executor-110:job-886 ctx-0ab7a373) Received unknown parameters for 
 command updatePortForwardingRule. Unknown parameters : ctxdetails
 2014-05-14 11:44:45,314 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-110:job-886) Unexpected exception while executing

[jira] [Commented] (CLOUDSTACK-6720) Async job events are not published on event bus


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

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

Commit 6f2a193b7c047a9c9db832dacb3d3105ff1f3a79 in cloudstack's branch 
refs/heads/master from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6f2a193 ]

CLOUDSTACK-6720: Async job events are not published on event bus

fix ensures publishOnEventBus() is called on submit, update, complete
phase of job procesing


 Async job events are not published on event bus
 ---

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


 Async job events are not published on event bus after underlying mechanism to 
 publish the events is changed to use message bus.
 publishOnEventBus is not called in AsyncJobManagerImpl.java after submit, 
 update, complete phases of async job.



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

[jira] [Commented] (CLOUDSTACK-6721) VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment

2014-05-20 Thread ASF subversion and git services (JIRA)


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

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

Commit 17fe6cdda4fd7452554c5ceac8724a76a99a477c in cloudstack's branch 
refs/heads/master from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=17fe6cd ]

CLOUDSTACK-6721: VolumeApiServiceImpl is sending wrong type for
updateAsyncJobAttachment

fix sends 'Volume' instead of 'volume'

Conflicts:
server/src/com/cloud/storage/VolumeApiServiceImpl.java


 VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment
 ---

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


 VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment. Its 
 sending lower case 'volume' instead of 'Volume' resulting in instance type 
 matching logic failure in APIDB utils



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

[jira] [Created] (CLOUDSTACK-6723) [DynamicallyAddingGuestOs]Observed NPE when VM is deployed using the guest OS which has no mapping to any hypervisor

manasaveloori created CLOUDSTACK-6723:
-

 Summary: [DynamicallyAddingGuestOs]Observed NPE when VM is 
deployed using the guest OS which has no mapping to any hypervisor
 Key: CLOUDSTACK-6723
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6723
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.4.0
Reporter: manasaveloori
Priority: Critical
 Fix For: 4.4.0


1. Add a guest os using API
I added it using cloudmonkey:
 add guestos name=test oscategoryid=11 osdisplayname=test1centos
mysql select category_id,name,uuid,display_name from guest_os where 
display_name=test1centos;
+-+--+--+--+
| category_id | name | uuid | display_name |
+-+--+--+--+
|  11 | test | 8c413100-8b68-49c3-b81c-372c3ba8f998 | test1centos  |
+-+--+--+--+
1 row in set (0.00 sec)

2. did not create any mapping for this OS to hypervisor.
mysql select hypervisor_type ,guest_os_name,hypervisor_version from 
guest_os_hypervisor where guest_os_name=test1centos;
Empty set (0.00 sec)
3. Registered the template using the above created OS type.
4. Now deploy a VM using the template.

Observation:

Observed NPE in Ms logs and deploy VM is failing.


2014-05-20 17:08:53,747 DEBUG [c.c.n.NetworkModelImpl] 
(Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Service SecurityGroup is not 
supported in the network id=206
2014-05-20 17:08:53,749 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
(Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Checking if we need to 
prepare 1 volumes for VM[User|i-2-13-VM]
2014-05-20 17:08:53,750 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
(Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) No need to recreate the 
volume: Vol[13|vm=13|ROOT], since it already has a pool assigned: 1, adding 
disk to VM
2014-05-20 17:08:53,773 ERROR [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Failed to start instance 
VM[User|i-2-13-VM]
java.lang.NullPointerException
at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:96)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014-05-20 17:08:53,780 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Cleaning up resources for the 
vm VM[User|i-2-13-VM] in Starting state
2014-05-20 17:08:53,783 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Seq 1-7387310763771167224: 
Sending  { Cmd , MgmtId: 7672522866886, via: 1(Rack1Pod1Host28), Ver: v1, 
Flags: 100011,

[jira] [Updated] (CLOUDSTACK-6723) [DynamicallyAddingGuestOs]Observed NPE when VM is deployed using the guest OS which has no mapping to any hypervisor


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

manasaveloori updated CLOUDSTACK-6723:
--

Attachment: mysqldump44.dmp
management-server.rar

 [DynamicallyAddingGuestOs]Observed NPE when VM is deployed using the guest OS 
 which has no mapping to any hypervisor
 

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

 Attachments: management-server.rar, mysqldump44.dmp


 1. Add a guest os using API
 I added it using cloudmonkey:
  add guestos name=test oscategoryid=11 osdisplayname=test1centos
 mysql select category_id,name,uuid,display_name from guest_os where 
 display_name=test1centos;
 +-+--+--+--+
 | category_id | name | uuid | display_name |
 +-+--+--+--+
 |  11 | test | 8c413100-8b68-49c3-b81c-372c3ba8f998 | test1centos  |
 +-+--+--+--+
 1 row in set (0.00 sec)
 2. did not create any mapping for this OS to hypervisor.
 mysql select hypervisor_type ,guest_os_name,hypervisor_version from 
 guest_os_hypervisor where guest_os_name=test1centos;
 Empty set (0.00 sec)
 3. Registered the template using the above created OS type.
 4. Now deploy a VM using the template.
 Observation:
 Observed NPE in Ms logs and deploy VM is failing.
 2014-05-20 17:08:53,747 DEBUG [c.c.n.NetworkModelImpl] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Service SecurityGroup is 
 not supported in the network id=206
 2014-05-20 17:08:53,749 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Checking if we need to 
 prepare 1 volumes for VM[User|i-2-13-VM]
 2014-05-20 17:08:53,750 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) No need to recreate the 
 volume: Vol[13|vm=13|ROOT], since it already has a pool assigned: 1, adding 
 disk to VM
 2014-05-20 17:08:53,773 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Failed to start instance 
 VM[User|i-2-13-VM]
 java.lang.NullPointerException
 at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:96)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-05-20 17:08:53,780 DEBUG [c.c.v.VirtualMachineManagerImpl]

[jira] [Updated] (CLOUDSTACK-6723) [DynamicallyAddingGuestOs]Observed NPE when VM is deployed using the guest OS which has no mapping to any hypervisor


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

manasaveloori updated CLOUDSTACK-6723:
--

Environment: 
[root@RHEL63test ~]# cloudstack-sccs
813ada1f691b146c368d25777185cac40958a892

 [DynamicallyAddingGuestOs]Observed NPE when VM is deployed using the guest OS 
 which has no mapping to any hypervisor
 

 Key: CLOUDSTACK-6723
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6723
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.4.0
 Environment: [root@RHEL63test ~]# cloudstack-sccs
 813ada1f691b146c368d25777185cac40958a892
Reporter: manasaveloori
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.rar, mysqldump44.dmp


 1. Add a guest os using API
 I added it using cloudmonkey:
  add guestos name=test oscategoryid=11 osdisplayname=test1centos
 mysql select category_id,name,uuid,display_name from guest_os where 
 display_name=test1centos;
 +-+--+--+--+
 | category_id | name | uuid | display_name |
 +-+--+--+--+
 |  11 | test | 8c413100-8b68-49c3-b81c-372c3ba8f998 | test1centos  |
 +-+--+--+--+
 1 row in set (0.00 sec)
 2. did not create any mapping for this OS to hypervisor.
 mysql select hypervisor_type ,guest_os_name,hypervisor_version from 
 guest_os_hypervisor where guest_os_name=test1centos;
 Empty set (0.00 sec)
 3. Registered the template using the above created OS type.
 4. Now deploy a VM using the template.
 Observation:
 Observed NPE in Ms logs and deploy VM is failing.
 2014-05-20 17:08:53,747 DEBUG [c.c.n.NetworkModelImpl] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Service SecurityGroup is 
 not supported in the network id=206
 2014-05-20 17:08:53,749 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Checking if we need to 
 prepare 1 volumes for VM[User|i-2-13-VM]
 2014-05-20 17:08:53,750 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) No need to recreate the 
 volume: Vol[13|vm=13|ROOT], since it already has a pool assigned: 1, adding 
 disk to VM
 2014-05-20 17:08:53,773 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-23:job-61/job-63 ctx-0477ee48) Failed to start instance 
 VM[User|i-2-13-VM]
 java.lang.NullPointerException
 at com.cloud.hypervisor.XenServerGuru.implement(XenServerGuru.java:96)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at

[jira] [Created] (CLOUDSTACK-6724) Generate only alert message in MS for an iteration in router vm

2014-05-20 Thread prashant kumar mishra (JIRA)

prashant kumar mishra created CLOUDSTACK-6724:
-

 Summary: Generate only alert message in MS for an iteration in 
router vm 
 Key: CLOUDSTACK-6724
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6724
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.4.0
Reporter: prashant kumar mishra
 Fix For: 4.4.0


Monitor script will try to start a process if it is not in running state, For 
each iteration  it will try N times(depend on config value in script) ,  for 
each try we are writing logs but after iteration if process dint come up  alert 
message is getting generated in logs , and we are sending each info in log to 
MS alerts ideally we should summarize log for each iteration and then send it 
to MS

currently in CS
=
alert is getting generated for each try  

Requested
==
-we can summarize the  alert message for each iteration .
Like N tires but not able to restart xyz services
--if service get started in some trial we can just say
service get started after N trial




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

[jira] [Updated] (CLOUDSTACK-6724) Generate only alert message in MS for an iteration in router vm

2014-05-20 Thread prashant kumar mishra (JIRA)


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

prashant kumar mishra updated CLOUDSTACK-6724:
--

Description: 
Monitor script will try to start a process if it is not in running state, For 
each iteration  it will try N times(depend on config value in script) ,  for 
each try we are writing logs but after iteration if process dint come up  alert 
message is getting generated in logs , and we are sending each info in log to 
MS alerts ideally we should summarize log for each iteration and then send it 
to MS

currently in CS
=
alert is getting generated for each try  i.e multiple alerts per iteration 

Requested
==
-we can summarize the  alert message for each iteration .Like N tires but not 
able to restart xyz services
--if service get started in some trial we can just say service  started after 
N trial


  was:
Monitor script will try to start a process if it is not in running state, For 
each iteration  it will try N times(depend on config value in script) ,  for 
each try we are writing logs but after iteration if process dint come up  alert 
message is getting generated in logs , and we are sending each info in log to 
MS alerts ideally we should summarize log for each iteration and then send it 
to MS

currently in CS
=
alert is getting generated for each try  

Requested
==
-we can summarize the  alert message for each iteration .
Like N tires but not able to restart xyz services
--if service get started in some trial we can just say
service get started after N trial



 Generate only alert message in MS for an iteration in router vm 
 

 Key: CLOUDSTACK-6724
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6724
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.4.0
Reporter: prashant kumar mishra
 Fix For: 4.4.0


 Monitor script will try to start a process if it is not in running state, For 
 each iteration  it will try N times(depend on config value in script) ,  for 
 each try we are writing logs but after iteration if process dint come up  
 alert message is getting generated in logs , and we are sending each info in 
 log to MS alerts ideally we should summarize log for each iteration and then 
 send it to MS
 currently in CS
 =
 alert is getting generated for each try  i.e multiple alerts per iteration 
 Requested
 ==
 -we can summarize the  alert message for each iteration .Like N tires but 
 not able to restart xyz services
 --if service get started in some trial we can just say service  started 
 after N trial



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

[jira] [Created] (CLOUDSTACK-6725) [OVS][UI] vm deployment wizard does not show all available zones in a region while deploying vm in a Regionlevel vpc

2014-05-20 Thread ASF subversion and git services (JIRA)

Sanjeev N created CLOUDSTACK-6725:
-

 Summary: [OVS][UI] vm deployment wizard does not show all 
available zones in a region while deploying vm in a Regionlevel vpc 
 Key: CLOUDSTACK-6725
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6725
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.4.0
 Environment: Latest build from 4.4 with commit 
e6961fd21bb6d793302c234d0f409f66dc498072
Reporter: Sanjeev N
Assignee: Gabor Apati-Nagy
Priority: Critical
 Fix For: 4.4.0


[OVS][UI] vm deployment wizard does not show all available zones in a region 
while deploying vm in a Regionlevel vpc 

Steps to reproduce:

1.Bring up CS with two advanced zones using xen clusters
2.Create physical networks with GRE isolation in both the zones
3.Create Regionlevel vpc with Connectivity Service and OVS as the provider
4.Create a vpc network with StretchedL2Subnet in the vpc as a tier.
5.From UI navigate to Home-Regions- Local- VPC-RegionVPC-T1Stretched- 
Virtual Machines
6.Deploy virtual machine from the above tier
7.VM deployment wizard should show all the zones in zone selection drop down 
list

Result:
==
But UI only shows the zone in which the tier(StretchedL2Subnet network) is 
created.



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

[jira] [Commented] (CLOUDSTACK-6720) Async job events are not published on event bus


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

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

Commit 850e068a56382ea4f8c898d3307c8ce8bec6e9c5 in cloudstack's branch 
refs/heads/4.4 from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=850e068 ]

CLOUDSTACK-6720: Async job events are not published on event bus

fix ensures publishOnEventBus() is called on submit, update, complete
phase of job procesing


 Async job events are not published on event bus
 ---

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


 Async job events are not published on event bus after underlying mechanism to 
 publish the events is changed to use message bus.
 publishOnEventBus is not called in AsyncJobManagerImpl.java after submit, 
 update, complete phases of async job.



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

[jira] [Commented] (CLOUDSTACK-6721) VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment

2014-05-20 Thread ASF subversion and git services (JIRA)


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

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

Commit 019ac691f00e67b055961aef0584d7148007c608 in cloudstack's branch 
refs/heads/4.4 from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=019ac69 ]

CLOUDSTACK-6721: VolumeApiServiceImpl is sending wrong type for
updateAsyncJobAttachment

fix sends 'Volume' instead of 'volume'


 VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment
 ---

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


 VolumeApiServiceImpl is sending wrong type for updateAsyncJobAttachment. Its 
 sending lower case 'volume' instead of 'Volume' resulting in instance type 
 matching logic failure in APIDB utils



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

[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM

2014-05-20 Thread Sam Schmit (JIRA)


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

Sam Schmit commented on CLOUDSTACK-6631:


What storage backend are you using?  Are you using tagging for the disks?

Our 4.2.1 environment is using local shared storage, and it's tagged primary 
and premium.

 unable to attach new Volume to VM
 -

 Key: CLOUDSTACK-6631
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.2.1
 Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito

 1. I added new volume.
 2. I tried to attach the volume to a VM on UI.
 3. It failed and the following log appeared.
 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet] 
 (http-6443-exec-116:null) ===START===  133.xx.xxx.xxx -- GET  
 command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (http-6443-exec-116:null) submit async job-4916 = [ 
 dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId: 
 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543, 
 cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, 
 cmdOriginator: null, cmdInfo: 
 {response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for 
 job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet] 
 (http-6443-exec-116:null) ===END===  133.xx.xxx.xxx -- GET  
 command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
 to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to 
 Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
 DomainChecker_EnhancerByCloudStack_9b413459
 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
 to VM[User|TEST-A2-VM01] granted to 
 Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
 DomainChecker_EnhancerByCloudStack_9b413459
 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 LocalStoragePoolAllocator trying to find storage pool to fit the vm
 2014-05-12 11:29:47,212 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 ClusterScopeStoragePoolAllocator looking for storage pool
 2014-05-12 11:29:47,212 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Looking for pools in dc: 1  pod:1  cluster:null having tags:[MPI]
 2014-05-12 11:29:47,216 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No 
 storage pools available for shared volume allocation, returning
 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
 com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id, 
 SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM 
 `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id = 
 vol.pool_id WHERE pool.data_center_id = ?  AND pool.pod_id = ? AND 
 pool.cluster_id = ?  GROUP BY pool.id ORDER BY 2 ASC
 at 
 com.cloud.storage.dao.VolumeDaoImpl.listPoolIdsByVolumeCount(VolumeDaoImpl.java:480)
 at

[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM

2014-05-20 Thread Sam Schmit (JIRA)


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

Sam Schmit commented on CLOUDSTACK-6631:


A dump of the management log for the volume creation would also help.

 unable to attach new Volume to VM
 -

 Key: CLOUDSTACK-6631
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.2.1
 Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito

 1. I added new volume.
 2. I tried to attach the volume to a VM on UI.
 3. It failed and the following log appeared.
 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet] 
 (http-6443-exec-116:null) ===START===  133.xx.xxx.xxx -- GET  
 command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (http-6443-exec-116:null) submit async job-4916 = [ 
 dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId: 
 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543, 
 cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, 
 cmdOriginator: null, cmdInfo: 
 {response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for 
 job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet] 
 (http-6443-exec-116:null) ===END===  133.xx.xxx.xxx -- GET  
 command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
 to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to 
 Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
 DomainChecker_EnhancerByCloudStack_9b413459
 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
 to VM[User|TEST-A2-VM01] granted to 
 Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
 DomainChecker_EnhancerByCloudStack_9b413459
 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 LocalStoragePoolAllocator trying to find storage pool to fit the vm
 2014-05-12 11:29:47,212 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 ClusterScopeStoragePoolAllocator looking for storage pool
 2014-05-12 11:29:47,212 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Looking for pools in dc: 1  pod:1  cluster:null having tags:[MPI]
 2014-05-12 11:29:47,216 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No 
 storage pools available for shared volume allocation, returning
 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
 com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id, 
 SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM 
 `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id = 
 vol.pool_id WHERE pool.data_center_id = ?  AND pool.pod_id = ? AND 
 pool.cluster_id = ?  GROUP BY pool.id ORDER BY 2 ASC
 at 
 com.cloud.storage.dao.VolumeDaoImpl.listPoolIdsByVolumeCount(VolumeDaoImpl.java:480)
 at

[jira] [Updated] (CLOUDSTACK-6547) [Automation] Failed to download volume in Xen with error Failed to copy the volume from pri stor pool to sec stor pool


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

Daan Hoogland updated CLOUDSTACK-6547:
--

Priority: Critical  (was: Blocker)

 [Automation] Failed to download volume in Xen with error Failed to copy the 
 volume from pri stor pool to sec stor pool
 

 Key: CLOUDSTACK-6547
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6547
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes, XenServer
Affects Versions: 4.4.0
 Environment: Branch 4.4-forward
 env xen 6.2
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.rar


 Steps to reproduce 
 1) Create advanced zone in xen 
 2) Deploy a VM 
 3) Stoped the vm and download the root volume 
 Result
 Failed to download root volume with below error 
 2014-05-01 04:40:03,160 WARN  [o.a.c.s.d.ObjectInDataStoreManagerImpl] 
 (API-Job-Executor-38:job-490 ctx-4880d846) Unsupported data object (VO
 LUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@2f9161ed), 
 no need to delete from object in store ref table
 2014-05-01 04:40:03,162 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-5:job-488/job-489 ctx-46360720) Execute VM work job: 
 com.cloud
 .vm.VmWorkStart{dcId:1,podId:1,clusterId:1,hostId:1,rawParams:{VmPassword:rO0ABXQADnNhdmVkX3Bhc3N3b3Jk},userId:2,accountId:2,vmId:70,handlerName:VirtualMachineManagerImpl}
 2014-05-01 04:40:03,189 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-38:job-490) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd
 com.cloud.utils.exception.CloudRuntimeException: Failed to copy the volume 
 from the source primary storage pool to secondary storage.
 at 
 com.cloud.storage.VolumeApiServiceImpl.extractVolume(VolumeApiServiceImpl.java:1897)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 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 com.sun.proxy.$Proxy181.extractVolume(Unknown Source)
 at 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd.execute(ExtractVolumeCmd.java:137)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:119)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:452)
 at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
 at java.util.concurrent.FutureTask.run(Unknown Source)

[jira] [Commented] (CLOUDSTACK-6547) [Automation] Failed to download volume in Xen with error Failed to copy the volume from pri stor pool to sec stor pool


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

Daan Hoogland commented on CLOUDSTACK-6547:
---

so changing the prio down from blocker

 [Automation] Failed to download volume in Xen with error Failed to copy the 
 volume from pri stor pool to sec stor pool
 

 Key: CLOUDSTACK-6547
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6547
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes, XenServer
Affects Versions: 4.4.0
 Environment: Branch 4.4-forward
 env xen 6.2
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.rar


 Steps to reproduce 
 1) Create advanced zone in xen 
 2) Deploy a VM 
 3) Stoped the vm and download the root volume 
 Result
 Failed to download root volume with below error 
 2014-05-01 04:40:03,160 WARN  [o.a.c.s.d.ObjectInDataStoreManagerImpl] 
 (API-Job-Executor-38:job-490 ctx-4880d846) Unsupported data object (VO
 LUME, org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@2f9161ed), 
 no need to delete from object in store ref table
 2014-05-01 04:40:03,162 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-5:job-488/job-489 ctx-46360720) Execute VM work job: 
 com.cloud
 .vm.VmWorkStart{dcId:1,podId:1,clusterId:1,hostId:1,rawParams:{VmPassword:rO0ABXQADnNhdmVkX3Bhc3N3b3Jk},userId:2,accountId:2,vmId:70,handlerName:VirtualMachineManagerImpl}
 2014-05-01 04:40:03,189 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-38:job-490) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd
 com.cloud.utils.exception.CloudRuntimeException: Failed to copy the volume 
 from the source primary storage pool to secondary storage.
 at 
 com.cloud.storage.VolumeApiServiceImpl.extractVolume(VolumeApiServiceImpl.java:1897)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 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 com.sun.proxy.$Proxy181.extractVolume(Unknown Source)
 at 
 org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd.execute(ExtractVolumeCmd.java:137)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:119)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:452)
 at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

[jira] [Commented] (CLOUDSTACK-6602) [UI] createNetworkACL API action param value passed incorrectly


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

Daan Hoogland commented on CLOUDSTACK-6602:
---

this sounds like a regression to me, please make sure it gets fixed in master 
as well

 [UI] createNetworkACL API action param value passed incorrectly
 ---

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


 createNetworkACLresponse=jsonsessionkey=9PnsnXugAKpfi24BgcTNguWYMt0%3Dnumber=1cidrlist=0.0.0.0%2F0action=label.allowprotocol=tcpstartport=22endport=22traffictype=Ingressaclid=f3022110-80fc-4f77-943c-33f7103a6aa3_=1399524604770
 The action parameter from UI is passed incorrectly 'label.allow'. It supposed 
 to 'allow' or 'deny'.



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

[jira] [Commented] (CLOUDSTACK-6716) /usr has been sized to small and ends up being 100% full on SSVM and CVM

2014-05-20 Thread Joris van Lieshout (JIRA)


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

Joris van Lieshout commented on CLOUDSTACK-6716:


Created review request https://reviews.apache.org/r/21696/ 

 /usr has been sized to small and ends up being 100% full on SSVM and CVM
 

 Key: CLOUDSTACK-6716
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6716
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: Future, 4.3.0, 4.4.0
Reporter: Joris van Lieshout

 The systemvmtemplate for 4.3 and 4.4 has a too small /usr volume and ends up 
 100% full on Secondary Storage VMs and Console VMs.
 root@v-xxx-VM:~# df -h
 Filesystem  Size  Used Avail Use% 
 Mounted on
 rootfs  276M  144M  118M  55% 
 /
 udev 10M 0   10M   0% 
 /dev
 tmpfs   100M  156K  100M   1% 
 /run
 /dev/disk/by-uuid/0721ecee-214a-4143-8d88-a4075cc2cd89  276M  144M  118M  55% 
 /
 tmpfs   5.0M 0  5.0M   0% 
 /run/lock
 tmpfs   314M 0  314M   0% 
 /run/shm
 /dev/xvda1   45M   22M   21M  51% 
 /boot
 /dev/xvda6   98M  5.6M   88M   6% 
 /home
 /dev/xvda8  368M   11M  339M   3% 
 /opt
 /dev/xvda10  63M  5.3M   55M   9% 
 /tmp
 /dev/xvda7  610M  584M 0 100% 
 /usr
 /dev/xvda9  415M  316M   78M  81% 
 /var



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

[jira] [Created] (CLOUDSTACK-6726) [Automation] test_network.py, testcase failing while calling listportforwardingrules API

2014-05-20 Thread ASF subversion and git services (JIRA)

Rayees Namathponnan created CLOUDSTACK-6726:
---

 Summary: [Automation] test_network.py, testcase failing while 
calling listportforwardingrules API
 Key: CLOUDSTACK-6726
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6726
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.4.0


Below test case failing with latets runs

integration.smoke.test_network.TestPortForwarding.test_01_port_fwd_on_src_nat


Test case calling list pf rule api after deleting PF rule, CS return error 
message Unable to execute API command listportforwardingrules due to invalid 
value. Invalid parameter id value=ff53386f-c418-4f85-b006-df7761erere due to 
incorrect long value format, or entity does not exist or due to incorrect 
parameter annotation for the field in api cmd class.

This is expected message, we should handle this in framework


Error Message

Execute cmd: listportforwardingrules failed, due to: errorCode: 431, 
errorText:Unable to execute API command listportforwardingrules due to invalid 
value. Invalid parameter id value=260b53c4-946c-48a4-940a-228d1f243d23 due to 
incorrect long value format, or entity does not exist or due to incorrect 
parameter annotation for the field in api cmd class.
  begin captured stdout  -
=== TestName: test_01_port_fwd_on_src_nat | Status : EXCEPTION ===


-  end captured stdout  --
  begin captured logging  
test_delete_account (integration.smoke.test_network.TestDeleteAccount): DEBUG: 
Payload: {'apiKey': 
u'1SilesOhwWJLYwInJVa_uNRle4rmNP93ImbGQuJznbIx0tjzji8CP8lK6O1MQSzCTJ2Mir_1lL2SSuCdoMqVTQ',
 'command': 'listDomains', 'signature': '8ilY8sNNI9ov84SSMCYm0rwKw/Q=', 
'response': 'json'}
test_delete_account (integration.smoke.test_network.TestDeleteAccount): DEBUG: 
Sending GET Cmd : listDomains===



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

[jira] [Commented] (CLOUDSTACK-778) user provided hostname to be specified in vCenter instead of CloudStack generated name

2014-05-20 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti commented on CLOUDSTACK-778:
-

Can someone respond to this after checking the code. Looks like this is 
supported only on VMWare. 

 user provided hostname to be specified in vCenter instead of CloudStack 
 generated name
 --

 Key: CLOUDSTACK-778
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-778
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: haroon abdelrahman
Assignee: Venkata Siva Vijayendra Bhamidipati
 Fix For: 4.2.0


 Release Planning:
 Dev List discussion: unknown
 Functional Spec: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+user+provided+hostname%2C+internal+VM+name+on+hypervisor+for+guest+VMs
 Feature Branch: unknown



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

[jira] [Commented] (CLOUDSTACK-6708) [Automation]: Few suites were failing on simulator run


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

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

Commit c7f5077ab18031e5601eb04f1ff7010b214861fe in cloudstack's branch 
refs/heads/4.4-forward from santhosh
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7f5077 ]

Fixed Regression issues mentioned under CLOUDSTACK-6708

Signed-off-by: santhosh santhosh.eduku...@gmail.com


 [Automation]: Few suites were failing on simulator run
 --

 Key: CLOUDSTACK-6708
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6708
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Santhosh Kumar Edukulla
Assignee: Santhosh Kumar Edukulla

 integration.smoke.test_deploy_vm.TestDeployVMStartFailure.test_deploy_vm_start_failure
 integration.smoke.test_hosts.TestHosts.test_01_clusters
 integration.smoke.test_network.TestDeleteAccount.test_delete_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestReleaseIP.test_releaseIP
 integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm
 integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_09_expunge_vm



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

[jira] [Updated] (CLOUDSTACK-6708) [Automation]: Few suites were failing on simulator run


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

Rayees Namathponnan updated CLOUDSTACK-6708:


Issue Type: Test  (was: Bug)

 [Automation]: Few suites were failing on simulator run
 --

 Key: CLOUDSTACK-6708
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6708
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Reporter: Santhosh Kumar Edukulla
Assignee: Santhosh Kumar Edukulla

 integration.smoke.test_deploy_vm.TestDeployVMStartFailure.test_deploy_vm_start_failure
 integration.smoke.test_hosts.TestHosts.test_01_clusters
 integration.smoke.test_network.TestDeleteAccount.test_delete_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestReleaseIP.test_releaseIP
 integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_08_migrate_vm
 integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_09_expunge_vm



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

[jira] [Created] (CLOUDSTACK-6727) Deployment of Virtual Machine is failing on Xenserver host

Syed Mohtashim Ahmad created CLOUDSTACK-6727:


 Summary: Deployment of Virtual Machine is failing on Xenserver host
 Key: CLOUDSTACK-6727
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6727
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: DevCloud
Reporter: Syed Mohtashim Ahmad
Priority: Critical


{noformat}
Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
errorText:Unable to find network by id 206
  begin captured stdout  -
=== TestName: test_nic_secondaryip_add_remove | Status : EXCEPTION ===


-  end captured stdout  --
  begin captured logging  
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
{'signature': 'CVZAuHBDhvRBjxJXCQeTZxXyE0k=', 'apiKey': 
u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
 'command': 'deleteAccount', 'id': u'f4389b5a-c880-4107-8dcf-1e2881d86c75', 
'response': 'json'}
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
GET Cmd : deleteAccount===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.80.13
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?signature=CVZAuHBDhvRBjxJXCQeTZxXyE0k%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=deleteAccountid=f4389b5a-c880-4107-8dcf-1e2881d86c75response=json
 HTTP/1.1 200 78
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === Jobid: 
4fed98d8-e929-4853-b8ba-4364f4dd00e7 Started ===
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
{'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.80.13
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
 HTTP/1.1 200 343
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
{jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 0, jobid : 
u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, accountid : 
u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === 
JobId:4fed98d8-e929-4853-b8ba-4364f4dd00e7 is Still Processing, Will TimeOut 
in:3595 
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
{'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.80.13
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
 HTTP/1.1 200 397
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
{jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 1, jobid : 
u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, jobresulttype : 
u'object', jobresult : {success : True}, accountid : 
u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: 
===Jobid:4fed98d8-e929-4853-b8ba-4364f4dd00e7 ; StartTime:Tue May 20 12:07:43 
2014 ; EndTime:Tue May 20 12:07:48 2014 ; TotalTime:-5===
test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
{jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid :

[jira] [Updated] (CLOUDSTACK-6727) Deployment of Virtual Machine is failing on Xenserver host


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

Syed Mohtashim Ahmad updated CLOUDSTACK-6727:
-

Fix Version/s: 4.4.0

 Deployment of Virtual Machine is failing on Xenserver host
 --

 Key: CLOUDSTACK-6727
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6727
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: Syed Mohtashim Ahmad
Priority: Critical
 Fix For: 4.4.0


 {noformat}
 Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
 errorText:Unable to find network by id 206
   begin captured stdout  -
 === TestName: test_nic_secondaryip_add_remove | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'CVZAuHBDhvRBjxJXCQeTZxXyE0k=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'deleteAccount', 'id': u'f4389b5a-c880-4107-8dcf-1e2881d86c75', 
 'response': 'json'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : deleteAccount===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=CVZAuHBDhvRBjxJXCQeTZxXyE0k%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=deleteAccountid=f4389b5a-c880-4107-8dcf-1e2881d86c75response=json
  HTTP/1.1 200 78
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === Jobid: 
 4fed98d8-e929-4853-b8ba-4364f4dd00e7 Started ===
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 343
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 0, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, accountid : 
 u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === 
 JobId:4fed98d8-e929-4853-b8ba-4364f4dd00e7 is Still Processing, Will TimeOut 
 in:3595 
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 397
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 1, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, jobresulttype : 
 u'object', jobresult : {success : True}, accountid : 
 u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: 
 ===Jobid:4fed98d8-e929-4853-b8ba-4364f4dd00e7 ; StartTime:Tue May 20 12:07:43 
 2014 ;

[jira] [Updated] (CLOUDSTACK-6727) [Automation] Deployment of Virtual Machine is failing on Xenserver host causing many BVT test cases to fail


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

Syed Mohtashim Ahmad updated CLOUDSTACK-6727:
-

Summary: [Automation] Deployment of Virtual Machine is failing on Xenserver 
host causing many BVT test cases to fail  (was: Deployment of Virtual Machine 
is failing on Xenserver host)

 [Automation] Deployment of Virtual Machine is failing on Xenserver host 
 causing many BVT test cases to fail
 ---

 Key: CLOUDSTACK-6727
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6727
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: Syed Mohtashim Ahmad
Priority: Critical
 Fix For: 4.4.0


 {noformat}
 Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
 errorText:Unable to find network by id 206
   begin captured stdout  -
 === TestName: test_nic_secondaryip_add_remove | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'CVZAuHBDhvRBjxJXCQeTZxXyE0k=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'deleteAccount', 'id': u'f4389b5a-c880-4107-8dcf-1e2881d86c75', 
 'response': 'json'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : deleteAccount===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=CVZAuHBDhvRBjxJXCQeTZxXyE0k%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=deleteAccountid=f4389b5a-c880-4107-8dcf-1e2881d86c75response=json
  HTTP/1.1 200 78
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === Jobid: 
 4fed98d8-e929-4853-b8ba-4364f4dd00e7 Started ===
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 343
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 0, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, accountid : 
 u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === 
 JobId:4fed98d8-e929-4853-b8ba-4364f4dd00e7 is Still Processing, Will TimeOut 
 in:3595 
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 397
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 1, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0,

[jira] [Updated] (CLOUDSTACK-6727) [Automation] Deployment of Virtual Machine is failing on Xenserver host causing many BVT test cases to fail

2014-05-20 Thread ASF subversion and git services (JIRA)


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

Syed Mohtashim Ahmad updated CLOUDSTACK-6727:
-

Attachment: management-server.zip

 [Automation] Deployment of Virtual Machine is failing on Xenserver host 
 causing many BVT test cases to fail
 ---

 Key: CLOUDSTACK-6727
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6727
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: Syed Mohtashim Ahmad
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.zip


 {noformat}
 There are many test cases failing one of them is 
 test_nic_secondaryip_add_remove test case in test_multipleips_per_nic.py
 Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
 errorText:Unable to find network by id 206
   begin captured stdout  -
 === TestName: test_nic_secondaryip_add_remove | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'CVZAuHBDhvRBjxJXCQeTZxXyE0k=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'deleteAccount', 'id': u'f4389b5a-c880-4107-8dcf-1e2881d86c75', 
 'response': 'json'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : deleteAccount===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=CVZAuHBDhvRBjxJXCQeTZxXyE0k%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=deleteAccountid=f4389b5a-c880-4107-8dcf-1e2881d86c75response=json
  HTTP/1.1 200 78
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === Jobid: 
 4fed98d8-e929-4853-b8ba-4364f4dd00e7 Started ===
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 343
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 0, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, accountid : 
 u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === 
 JobId:4fed98d8-e929-4853-b8ba-4364f4dd00e7 is Still Processing, Will TimeOut 
 in:3595 
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 397
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 1, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7',

[jira] [Created] (CLOUDSTACK-6729) UI - create compute offering/create disk offering - determine whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's value

2014-05-20 Thread Jessica Wang (JIRA)

Jessica Wang created CLOUDSTACK-6729:


 Summary: UI - create compute offering/create disk offering - 
determine whether to pass certain data to API comamnd upon isCustomized 
checkbox/isPublic checkbox's value
 Key: CLOUDSTACK-6729
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6729
 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






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

[jira] [Commented] (CLOUDSTACK-6729) UI - create compute offering/create disk offering - determine whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's value


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

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

Commit 22f503aa2b0b866bd10c41b8f886984451730c40 in cloudstack's branch 
refs/heads/4.4-forward from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=22f503a ]

CLOUDSTACK-6729: UI - create compute offering/create disk offering - determine 
whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic 
checkbox's value.


 UI - create compute offering/create disk offering - determine whether to pass 
 certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's 
 value
 --

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





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

[jira] [Closed] (CLOUDSTACK-6729) UI - create compute offering/create disk offering - determine whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's value

2014-05-20 Thread Jessica Wang (JIRA)


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

Jessica Wang closed CLOUDSTACK-6729.



 UI - create compute offering/create disk offering - determine whether to pass 
 certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's 
 value
 --

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





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

[jira] [Resolved] (CLOUDSTACK-6729) UI - create compute offering/create disk offering - determine whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's value

2014-05-20 Thread Jessica Wang (JIRA)


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

Jessica Wang resolved CLOUDSTACK-6729.
--

Resolution: Fixed

 UI - create compute offering/create disk offering - determine whether to pass 
 certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's 
 value
 --

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





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

[jira] [Commented] (CLOUDSTACK-6729) UI - create compute offering/create disk offering - determine whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's value

2014-05-20 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-6729: UI - create compute offering/create disk offering - determine 
whether to pass certain data to API comamnd upon isCustomized checkbox/isPublic 
checkbox's value.


 UI - create compute offering/create disk offering - determine whether to pass 
 certain data to API comamnd upon isCustomized checkbox/isPublic checkbox's 
 value
 --

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





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

[jira] [Created] (CLOUDSTACK-6730) [Automation] test_egress_fw_rules test case failing while applying FW rule

Rayees Namathponnan created CLOUDSTACK-6730:
---

 Summary: [Automation] test_egress_fw_rules test case failing while 
applying FW rule 
 Key: CLOUDSTACK-6730
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6730
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.4.0


Test case 
integration.component.test_egress_fw_rules.TestEgressFWRules.test_07_1_egress_fr7
 failing with latest run.

This test case performing below steps 

 658 # Validate the following:
 659 # 1. deploy VM using network offering with egress policy true.
 660 # 2. create egress rule without specific end port.
 661 # 3. login to VM.
 662 # 4. access to public network for tcp port 80 is blocked.

SetFirewallRulesCommand failing with error No chain/target/match by that 
name.\niptables: No chain/target/match by that

2014-05-19 21:52:27,304 DEBUG [c.c.a.t.Request] (API-Job-Executor-99:job-7298 
ctx-93fb812a) Seq 2-453737662457584256: Executing:  { Cmd , MgmtId: 90928106758
026, via: 2(10.223.250.131), Ver: v1, Flags: 11, 
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:562,srcIp:,protocol:tcp,
srcPortRange:[80,80],revoked:false,alreadyAdded:false,sourceCidrList:[10.1.1.0/24],purpose:Firewall,trafficType:Egress,defaultEgressPolicy
:true}],accessDetails:{router.guest.ip:10.1.1.13,firewall.egress.default:true,zone.network.type:Advanced,router.ip:10.223.250.182,router.
name:r-1086-TestVM},wait:0}}] }
2014-05-19 21:52:27,304 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Executing request
2014-05-19 21:52:27,304 DEBUG [c.c.h.v.r.VmwareResource] 
(DirectAgent-120:ctx-15d72251 10.223.250.131) Use router's private IP for SSH 
control. IP : 10.223.2
50.182
2014-05-19 21:52:27,304 DEBUG [c.c.h.v.r.VmwareResource] 
(DirectAgent-120:ctx-15d72251 10.223.250.131) Run command on VR: 
10.223.250.182, script: firewall_eg
ress.sh with args:  -F -E -P 1 -a :tcp:80:80:10.1.1.0/24:,
2014-05-19 21:52:27,759 DEBUG [c.c.h.v.r.VmwareResource] 
(DirectAgent-120:ctx-15d72251 10.223.250.131) firewall_egress.sh execution 
result: true
2014-05-19 21:52:27,759 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Response Received:
2014-05-19 21:52:27,759 DEBUG [c.c.a.t.Request] (DirectAgent-120:ctx-15d72251) 
Seq 2-453737662457584256: Processing:  { Ans: , MgmtId: 90928106758026, via: 2
, Ver: v1, Flags: 0, 
[{com.cloud.agent.api.Answer:{result:true,details:iptables v1.4.14: 
Couldn't load target `_FW_EGRESS_RULES':No such file or direc
tory\n\nTry `iptables -h' or 'iptables --help' for more information.\niptables: 
No chain/target/match by that name.\niptables: No chain/target/match by that
name.\n,wait:0}}] }




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

[jira] [Commented] (CLOUDSTACK-6730) [Automation] test_egress_fw_rules test case failing while applying FW rule


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

Rayees Namathponnan commented on CLOUDSTACK-6730:
-

Logs available at https://citrix.sharefile.com/d/s5109d09f2f043c29

 [Automation] test_egress_fw_rules test case failing while applying FW rule 
 ---

 Key: CLOUDSTACK-6730
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6730
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.4.0


 Test case 
 integration.component.test_egress_fw_rules.TestEgressFWRules.test_07_1_egress_fr7
  failing with latest run.
 This test case performing below steps 
  658 # Validate the following:
  659 # 1. deploy VM using network offering with egress policy true.
  660 # 2. create egress rule without specific end port.
  661 # 3. login to VM.
  662 # 4. access to public network for tcp port 80 is blocked.
 SetFirewallRulesCommand failing with error No chain/target/match by that 
 name.\niptables: No chain/target/match by that
 2014-05-19 21:52:27,304 DEBUG [c.c.a.t.Request] (API-Job-Executor-99:job-7298 
 ctx-93fb812a) Seq 2-453737662457584256: Executing:  { Cmd , MgmtId: 
 90928106758
 026, via: 2(10.223.250.131), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:562,srcIp:,protocol:tcp,
 srcPortRange:[80,80],revoked:false,alreadyAdded:false,sourceCidrList:[10.1.1.0/24],purpose:Firewall,trafficType:Egress,defaultEgressPolicy
 :true}],accessDetails:{router.guest.ip:10.1.1.13,firewall.egress.default:true,zone.network.type:Advanced,router.ip:10.223.250.182,router.
 name:r-1086-TestVM},wait:0}}] }
 2014-05-19 21:52:27,304 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Executing request
 2014-05-19 21:52:27,304 DEBUG [c.c.h.v.r.VmwareResource] 
 (DirectAgent-120:ctx-15d72251 10.223.250.131) Use router's private IP for SSH 
 control. IP : 10.223.2
 50.182
 2014-05-19 21:52:27,304 DEBUG [c.c.h.v.r.VmwareResource] 
 (DirectAgent-120:ctx-15d72251 10.223.250.131) Run command on VR: 
 10.223.250.182, script: firewall_eg
 ress.sh with args:  -F -E -P 1 -a :tcp:80:80:10.1.1.0/24:,
 2014-05-19 21:52:27,759 DEBUG [c.c.h.v.r.VmwareResource] 
 (DirectAgent-120:ctx-15d72251 10.223.250.131) firewall_egress.sh execution 
 result: true
 2014-05-19 21:52:27,759 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Response Received:
 2014-05-19 21:52:27,759 DEBUG [c.c.a.t.Request] 
 (DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Processing:  { Ans: 
 , MgmtId: 90928106758026, via: 2
 , Ver: v1, Flags: 0, 
 [{com.cloud.agent.api.Answer:{result:true,details:iptables v1.4.14: 
 Couldn't load target `_FW_EGRESS_RULES':No such file or direc
 tory\n\nTry `iptables -h' or 'iptables --help' for more 
 information.\niptables: No chain/target/match by that name.\niptables: No 
 chain/target/match by that
 name.\n,wait:0}}] }



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

[jira] [Closed] (CLOUDSTACK-6688) [Automation] SSVM test cases failing in vmware


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

Rayees Namathponnan closed CLOUDSTACK-6688.
---

Resolution: Fixed

need to pass hypervisor type while running tests

 [Automation] SSVM test cases failing in vmware 
 ---

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


 Below test cases failing in vmware
 integration.smoke.test_ssvm.TestSSVMs.test_03_ssvm_internals  0.477   6
 integration.smoke.test_ssvm.TestSSVMs.test_04_cpvm_internals  0.495   6
 integration.smoke.test_ssvm.TestSSVMs.test_05_stop_ssvm   121.115 6
 integration.smoke.test_ssvm.TestSSVMs.test_06_stop_cpvm   111.028 6
 integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm 95.884  6
 integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm 95.813  6
 integration.smoke.test_ssvm.TestSSVMs.test_09_destroy_ssvm211.072 6
 integration.smoke.test_ssvm.TestSSVMs.test_10_destroy_cpvm211.116 6
 Test cases failing with error Warning: Identity file //.ssh/id_rsa.cloud not 
 accessible: No such file or directory.', u'ssh: Could not resolve hostname 
 None: Name or service not known']}
 This issue observed only in vmware 
 shClient: DEBUG: ===SSH to Host 10.223.250.130 port : 22 SUCCESSFUL===
 paramiko.transport: DEBUG: [chan 1] Max packet in: 34816 bytes
 paramiko.transport: DEBUG: [chan 1] Max packet out: 32768 bytes
 paramiko.transport: INFO: Secsh channel 1 opened.
 paramiko.transport: DEBUG: [chan 1] Sesch channel 1 request ok
 sshClient: DEBUG: {Cmd: ssh -i ~/.ssh/id_rsa.cloud -ostricthostkeychecking=no 
 -oUserKnownHostsFile=/dev/null -p 3922 None 
 /usr/local/cloud/systemvm/ssvm-check.sh |grep -e ERROR -e WARNING -e FAIL via 
 Host: 10.223.250.130} {returns: [u'Warning: Identity file //.ssh/id_rsa.cloud 
 not accessible: No such file or directory.', u'ssh: Could not resolve 
 hostname None: Name or service not known']}
 paramiko.transport: DEBUG: [chan 1] EOF received (1)
 test_03_ssvm_internals (integration.smoke.test_ssvm.TestSSVMs): DEBUG: SSVM 
 script output: [u'Warning: Identity file //.ssh/id_rsa.cloud not accessible: 
 No such file or directory.', u'ssh: Could not resolve hostname None: Name or 
 service not known']
 test_03_ssvm_internals (integration.smoke.test_ssvm.TestSSVMs): CRITICAL: 
 FAILED: test_03_ssvm_internals: ['Traceback (most recent call last):\n', '  
 File /usr/local/lib/python2.7/unittest/case.py, line 318, in run\n
 testMethod()\n', '  File 
 /data/Repo2/qa/cloudstack/test/integration/smoke/test_ssvm.py, line 352, in 
 test_03_ssvm_internals\nCheck for Errors in tests\n', '  File 
 /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual\n
 assertion_func(first, second, msg=msg)\n', '  File 
 /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual\n  
   raise self.failureException(msg)\n', 'AssertionError: Check for Errors in 
 tests\n']
 -  end captured logging  -
 Stacktrace
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File /data/Repo2/qa/cloudstack/test/integration/smoke/test_ssvm.py, line 
 352, in test_03_ssvm_internals
 Check for Errors in tests
   File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 487, in 
 _baseAssertEqual
 raise self.failureException(msg)
 'Check for Errors in tests\n  begin captured stdout  
 -\n=== TestName: test_03_ssvm_internals | Status : FAILED 
 ===\n\n\n-  end captured stdout  
 --\n  begin captured logging  
 \ntest_03_ssvm_internals 



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

[jira] [Updated] (CLOUDSTACK-6594) [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists


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

Rayees Namathponnan updated CLOUDSTACK-6594:


Priority: Critical  (was: Major)

 [Automation] Observed many DB Exception while starting MS Can't DROP 
 'last_sent'; check that column/key exists
 

 Key: CLOUDSTACK-6594
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594
 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: RHEL 6.3,
 Build - 4.4-forward,
 Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513
Reporter: Rayees Namathponnan
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.4.0

 Attachments: CLOUDSTACK-6594.rar, management-server.log


 Below exception observed while staring MS 
 INFO  [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module 
 context [system] from URL 
 [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml]
 INFO  [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability 
 enabled? Ans : false
 INFO  [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352
 INFO  [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352
 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system 
 integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e
 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for 
 database upgrade.
 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code 
 Version = 4.4.0-SNAPSHOT
 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be 
 performed from 4.0.0 to 4.4.0-SNAPSHOT
 WARN  [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when 
 trying to drop key last_sent on table alert
 com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 
 'last_sent'; check that column/key exists
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
 at com.mysql.jdbc.Util.getInstance(Util.java:386)
 at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529)
 at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990)
 at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151)
 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625)
 at 
 com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318)
 at 
 org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
 at 
 org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
 at 
 com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37)
 at 
 com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28)
 at 
 com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543)
 at 
 com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98)
 at 
 com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310)
 at 
 com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432)
 at 
 org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
 at 
 org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)
 at 
 org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167)
 at 
 org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)

[jira] [Updated] (CLOUDSTACK-6594) Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists


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

Rayees Namathponnan updated CLOUDSTACK-6594:


Summary: Observed many DB Exception while starting MS Can't DROP 
'last_sent'; check that column/key exists  (was: [Automation] Observed many DB 
Exception while starting MS Can't DROP 'last_sent'; check that column/key 
exists)

 Observed many DB Exception while starting MS Can't DROP 'last_sent'; check 
 that column/key exists
 ---

 Key: CLOUDSTACK-6594
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594
 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: RHEL 6.3,
 Build - 4.4-forward,
 Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513
Reporter: Rayees Namathponnan
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.4.0

 Attachments: CLOUDSTACK-6594.rar, management-server.log


 Below exception observed while staring MS 
 INFO  [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module 
 context [system] from URL 
 [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml]
 INFO  [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability 
 enabled? Ans : false
 INFO  [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352
 INFO  [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352
 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system 
 integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e
 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for 
 database upgrade.
 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code 
 Version = 4.4.0-SNAPSHOT
 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be 
 performed from 4.0.0 to 4.4.0-SNAPSHOT
 WARN  [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when 
 trying to drop key last_sent on table alert
 com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 
 'last_sent'; check that column/key exists
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
 Method)
 at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
 at com.mysql.jdbc.Util.getInstance(Util.java:386)
 at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529)
 at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990)
 at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151)
 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625)
 at 
 com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333)
 at 
 com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318)
 at 
 org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
 at 
 org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
 at 
 com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37)
 at 
 com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28)
 at 
 com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543)
 at 
 com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98)
 at 
 com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310)
 at 
 com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432)
 at 
 org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
 at 
 org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)
 at

[jira] [Commented] (CLOUDSTACK-4568) Need to add this to the release note of 4.2

2014-05-20 Thread Pierre-Luc Dion (JIRA)

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

Pierre-Luc Dion commented on CLOUDSTACK-4568:
-

This text could be added to 4.4 release-notes in the upgrade section of
4.1,4.0, 3.x and 2.2.14.

{code}
Settings Changes

After upgrading to 4.2 and later, Settings ``mem.overporvisioning.factor`` and
``cpu.overporvisioning.factor`` are now at the cluster level and be set to 1
which is the default.

If Global Settings ``mem.overporvisioning.factor`` and
``cpu.overporvisioning.factor`` have been changed prior the upgrade to 4.2 and
later, the upgrade process will be reset them to 1. Values can be changed by
editing clusters settings.

All clusters created after the upgrade will get created with the Global
Settings values for ``mem.overporvisioning.factor`` and
``cpu.overporvisioning.factor``.
{code}

Please let me know if the text make sense. I will add this the the RN.

Need to add this to the release note of 4.2
---

Key: CLOUDSTACK-4568
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4568
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Doc
Affects Versions: 4.2.0
Reporter: Bharat Kumar
Assignee: Radhika Nair
Labels: releasenotes
Fix For: 4.4.0

After upgrade to 4.2 the mem.overporvisioning.factor and
cpu.overporvisioning.factor will be set to one that is the default value and
are at cluster level now.
In case if some one prior to the 4.2 was usign mem.overporvisioning.factor
and cpu.overporvisioning.factor after the upgrade these will be reset to one
and can be changed by editing the cluster settings.
All the clusters created after the upgrade will get created with the values
overcomit values specified at the global config by default.

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

[jira] [Commented] (CLOUDSTACK-5043) [DOC] Page number missing and words truncated in PDFs since 4.1.1

2014-05-20 Thread Pierre-Luc Dion (JIRA)


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

Pierre-Luc Dion commented on CLOUDSTACK-5043:
-

Does this issue is still valide since documentation have been moved to 
readthedoc.org in reStructuredText format ?

 [DOC] Page number missing and words truncated in PDFs since 4.1.1
 -

 Key: CLOUDSTACK-5043
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5043
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.1.1, 4.2.0
Reporter: Ryan Lei
Assignee: Jessica Tomechak
 Fix For: 4.4.0


 From mailing list:
 [~ryanleitaiwan] says:
 Ever since ACS 4.1.1, the PDFs downloaded from the doc website no longer have 
 a page number at the bottom-left or bottom-right corner of a page.
 This may make the printed version hard to navigate through the pages!
 Also, many words, tables, and figures get truncated when they appear at the 
 bottom of the page.
 Has anything happened to Publican since the 4.1.0 release?
 [~sebgoa] says:
 I don't know what's wrong with it, but you are right it's totally messed up.
 I believe there was a move to publican 3.0.0 that might have caused it.
 
 If this can be fixed, please consider updating the already exported PDFs for 
 4.1.1 and 4.2.0.



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

[jira] [Updated] (CLOUDSTACK-6727) [Automation] Deployment of Virtual Machine is failing on Xenserver host causing many BVT test cases to fail


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

Abhinandan Prateek updated CLOUDSTACK-6727:
---

Assignee: edison su

 [Automation] Deployment of Virtual Machine is failing on Xenserver host 
 causing many BVT test cases to fail
 ---

 Key: CLOUDSTACK-6727
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6727
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: DevCloud
Reporter: Syed Mohtashim Ahmad
Assignee: edison su
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.zip


 {noformat}
 There are many test cases failing one of them is 
 test_nic_secondaryip_add_remove test case in test_multipleips_per_nic.py
 Management server logs are also attached
 Execute cmd: deployvirtualmachine failed, due to: errorCode: 431, 
 errorText:Unable to find network by id 206
   begin captured stdout  -
 === TestName: test_nic_secondaryip_add_remove | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'CVZAuHBDhvRBjxJXCQeTZxXyE0k=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'deleteAccount', 'id': u'f4389b5a-c880-4107-8dcf-1e2881d86c75', 
 'response': 'json'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : deleteAccount===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=CVZAuHBDhvRBjxJXCQeTZxXyE0k%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=deleteAccountid=f4389b5a-c880-4107-8dcf-1e2881d86c75response=json
  HTTP/1.1 200 78
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === Jobid: 
 4fed98d8-e929-4853-b8ba-4364f4dd00e7 Started ===
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 343
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus : 0, jobid : 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7', jobresultcode : 0, accountid : 
 u'eea1474c-e011-11e3-a4b4-9e7c113c3a29'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: === 
 JobId:4fed98d8-e929-4853-b8ba-4364f4dd00e7 is Still Processing, Will TimeOut 
 in:3595 
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Payload: 
 {'signature': 'oUrKKe/zdGFzDPbcRzqnHwyTE28=', 'apiKey': 
 u'1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TA',
  'command': 'queryAsyncJobResult', 'response': 'json', 'jobid': 
 u'4fed98d8-e929-4853-b8ba-4364f4dd00e7'}
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Sending 
 GET Cmd : queryAsyncJobResult===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.80.13
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?signature=oUrKKe%2FzdGFzDPbcRzqnHwyTE28%3DapiKey=1icw25VMYy1cFaf2Y92-X49fBWabij_OBk70QARr_a0h6dMxQkXN16Fzb3EcbUHLLbEujC6YnXpnApiRtVB7TAcommand=queryAsyncJobResultresponse=jsonjobid=4fed98d8-e929-4853-b8ba-4364f4dd00e7
  HTTP/1.1 200 397
 test_06_copy_iso (integration.smoke.test_iso.TestISO): DEBUG: Response : 
 {jobprocstatus : 0, created : u'2014-05-20T12:07:47+', cmd : 
 u'org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd', userid : 
 u'eea15962-e011-11e3-a4b4-9e7c113c3a29', jobstatus :

[jira] [Updated] (CLOUDSTACK-6616) systemvm template build failed since install dialog prevents automation


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

Abhinandan Prateek updated CLOUDSTACK-6616:
---

Assignee: Abhinandan Prateek

 systemvm template build failed since install dialog prevents automation
 ---

 Key: CLOUDSTACK-6616
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6616
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: Future
Reporter: Yoshikazu Nojima
Assignee: Abhinandan Prateek
Priority: Blocker
  Labels: systemvm
 Fix For: 4.4.0


 log:
 =
 Executing command: ./base.sh
 0% [Working]
 
 Hit http://http.us.debian.org wheezy Release.gpg
 
 20% [Waiting for headers] [Waiting for headers]

 Hit http://security.debian.org wheezy/updates Release.gpg

 33% [Waiting for headers]
  
 Hit http://http.us.debian.org wheezy-updates Release.gpg
 43% [Waiting for headers]
  
 Hit http://security.debian.org wheezy/updates Release
 43% [Waiting for headers]
  
 Hit http://http.us.debian.org wheezy Release
  
 43% [Working]
  
 43% [Release gpgv 102 kB] [Waiting for headers]

 40% [Waiting for headers]
  
 40% [Release gpgv 168 kB] [Waiting for headers] [Waiting for headers]
  
 38% [Waiting for headers] [Waiting for headers]

 Hit http://http.us.debian.org wheezy-updates Release

 38% [Waiting for headers]
  
 38% [Release gpgv 124 kB] [Waiting for headers] [Waiting for headers]
  
 38% [Waiting for headers] [Waiting for headers]

 Hit http://security.debian.org wheezy/updates/main Sources

 44% [Waiting for headers]
  
 Hit http://http.us.debian.org wheezy/main Sources
  
 50% [Waiting for headers] [Waiting for headers]

 Hit http://http.us.debian.org wheezy/main amd64 Packages

 Hit http://security.debian.org wheezy/updates/main amd64 Packages
 62% [Waiting for headers] [Waiting for headers]

 Hit http://http.us.debian.org wheezy/main Translation-en
 69% [Waiting for headers] [Waiting for headers]

 Hit http://security.debian.org wheezy/updates/main Translation-en

 75% [Waiting for headers]
  
 Hit http://http.us.debian.org wheezy-updates/main Sources
 81% [Waiting for headers]
  
 Hit http://http.us.debian.org wheezy-updates/main amd64 Packages/DiffIndex
 88% [Waiting for headers]
  
 Hit http://http.us.debian.org wheezy-updates/main Translation-en/DiffIndex
  
 94% [Working]
  
 Reading package lists... 0%
 Reading package lists... 0%
 Reading package lists... 1%
 Reading package lists... 32%
 Reading package lists... 58%
 Reading package lists... 58%
 Reading package lists... 59%
 Reading package lists... 96%
 Reading package lists... 96%
 Reading package lists... 98%
 Reading package lists... 98%
 Reading package lists... 99%
 Reading package lists... 99%
 Reading package lists... 99%
 Reading package lists... 99%
 Reading package lists... 99%
 Reading package lists... 99%
 Reading package lists... Done
 Reading package lists... 0%
 Reading package lists... 100%
 Reading package lists... Done
 Building dependency tree... 0%
 Building dependency tree... 0%
 Building dependency tree... 50%
 Building dependency tree... 50%
 Building dependency tree   
 Reading state information... 0%
 Reading state information... 1%
 Reading state information... Done
 The following extra packages will be installed:
   ca-certificates libcurl3 libldap-2.4-2 librtmp0 libsasl2-2 libsasl2-modules
   libssh2-1 libssl1.0.0 openssl
 Suggested packages:
   libsasl2-modules-otp libsasl2-modules-ldap libsasl2-modules-sql
   libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-heimdal zip
 The following NEW packages will be installed:
   ca-certificates curl

[jira] [Updated] (CLOUDSTACK-6710) [Automation] VM snapshot failing with NPE in vmware


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

Abhinandan Prateek updated CLOUDSTACK-6710:
---

Assignee: Likitha Shetty

 [Automation] VM snapshot failing with NPE in vmware
 ---

 Key: CLOUDSTACK-6710
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6710
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
 Environment: Vmware 5.0
 4.4-forward 
Reporter: Rayees Namathponnan
Assignee: Likitha Shetty
Priority: Blocker
 Fix For: 4.4.0

 Attachments: management-server.rar


 Execute BVT 
 integration.smoke.test_vm_snapshots.TestVmSnapshot.test_01_create_vm_snapshots
 This test case creating VM snapshot in VMware; this is failing with below NPE 
 2014-05-19 13:12:00,378 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-130:job-390/job-391) Run VM work job: 
 com.cloud.vm.snapshot.VmWorkCreateVMSn
 apshot for VM 62, job origin: 390
 2014-05-19 13:12:00,384 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-130:job-390/job-391 ctx-538be870) Execute VM work job: 
 com.cloud.vm.snapsh
 ot.VmWorkCreateVMSnapshot{vmSnapshotId:1,quiesceVm:false,userId:2,accountId:2,vmId:62,handlerName:VMSnapshotManagerImpl}
 2014-05-19 13:12:00,517 DEBUG [c.c.v.s.VMSnapshotManagerImpl] 
 (Work-Job-Executor-130:job-390/job-391 ctx-538be870) Failed to create vm 
 snapshot: 1
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.vmsnapshot.DefaultVMSnapshotStrategy.takeVMSnapshot(DefaultVMSnapshotStrategy.java:139)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.orchestrateCreateVMSnapshot(VMSnapshotManagerImpl.java:422)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.orchestrateCreateVMSnapshot(VMSnapshotManagerImpl.java:1048)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.handleVmWorkJob(VMSnapshotManagerImpl.java:1072)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 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.$Proxy182.handleVmWorkJob(Unknown Source)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at

[jira] [Updated] (CLOUDSTACK-6730) [Automation] test_egress_fw_rules test case failing while applying FW rule


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

Abhinandan Prateek updated CLOUDSTACK-6730:
---

Assignee: Jayapal Reddy

 [Automation] test_egress_fw_rules test case failing while applying FW rule 
 ---

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


 Test case 
 integration.component.test_egress_fw_rules.TestEgressFWRules.test_07_1_egress_fr7
  failing with latest run.
 This test case performing below steps 
  658 # Validate the following:
  659 # 1. deploy VM using network offering with egress policy true.
  660 # 2. create egress rule without specific end port.
  661 # 3. login to VM.
  662 # 4. access to public network for tcp port 80 is blocked.
 SetFirewallRulesCommand failing with error No chain/target/match by that 
 name.\niptables: No chain/target/match by that
 2014-05-19 21:52:27,304 DEBUG [c.c.a.t.Request] (API-Job-Executor-99:job-7298 
 ctx-93fb812a) Seq 2-453737662457584256: Executing:  { Cmd , MgmtId: 
 90928106758
 026, via: 2(10.223.250.131), Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:562,srcIp:,protocol:tcp,
 srcPortRange:[80,80],revoked:false,alreadyAdded:false,sourceCidrList:[10.1.1.0/24],purpose:Firewall,trafficType:Egress,defaultEgressPolicy
 :true}],accessDetails:{router.guest.ip:10.1.1.13,firewall.egress.default:true,zone.network.type:Advanced,router.ip:10.223.250.182,router.
 name:r-1086-TestVM},wait:0}}] }
 2014-05-19 21:52:27,304 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Executing request
 2014-05-19 21:52:27,304 DEBUG [c.c.h.v.r.VmwareResource] 
 (DirectAgent-120:ctx-15d72251 10.223.250.131) Use router's private IP for SSH 
 control. IP : 10.223.2
 50.182
 2014-05-19 21:52:27,304 DEBUG [c.c.h.v.r.VmwareResource] 
 (DirectAgent-120:ctx-15d72251 10.223.250.131) Run command on VR: 
 10.223.250.182, script: firewall_eg
 ress.sh with args:  -F -E -P 1 -a :tcp:80:80:10.1.1.0/24:,
 2014-05-19 21:52:27,759 DEBUG [c.c.h.v.r.VmwareResource] 
 (DirectAgent-120:ctx-15d72251 10.223.250.131) firewall_egress.sh execution 
 result: true
 2014-05-19 21:52:27,759 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Response Received:
 2014-05-19 21:52:27,759 DEBUG [c.c.a.t.Request] 
 (DirectAgent-120:ctx-15d72251) Seq 2-453737662457584256: Processing:  { Ans: 
 , MgmtId: 90928106758026, via: 2
 , Ver: v1, Flags: 0, 
 [{com.cloud.agent.api.Answer:{result:true,details:iptables v1.4.14: 
 Couldn't load target `_FW_EGRESS_RULES':No such file or direc
 tory\n\nTry `iptables -h' or 'iptables --help' for more 
 information.\niptables: No chain/target/match by that name.\niptables: No 
 chain/target/match by that
 name.\n,wait:0}}] }



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

[jira] [Created] (CLOUDSTACK-6731) [OVS] Adding a network with StretchedL2Subnet should not be allowed in a zone level vpc

Sanjeev N created CLOUDSTACK-6731:
-

 Summary: [OVS] Adding a network with StretchedL2Subnet should not 
be allowed in a zone level vpc
 Key: CLOUDSTACK-6731
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6731
 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
 Fix For: 4.4.0


[OVS] Adding a network with StretchedL2Subnet should not be allowed in a zone 
level vpc

Steps to Reproduce:
=
1.Bring up CS in advanced zone with Xen Cluster
2.Create physical networks with GRE isolation 
3.Create vpc with Connectivity Service and OVS as the service provider but 
without RegionLevel Support(Zone level VPC)
4.Create isolated network offering for vpc with VirtuanNetworking service and 
OVS as the service provider and with StretchedL2Subnet Capability
5.Create tier with above network offering inside the vpc created at step3

Expected Result:
==
Since vpc is not region level adding a tier with stretchedL2subnet capability 
shall not be allowed.

Actual Result:
===
Adding  tier with stretchedL2subnet capability to Zone level vpc was successful.

Following are the vpc offering, vpc and network details from cloud DB:
mysql select * from vpc where id=4\G;
*** 1. row ***
 id: 4
   uuid: d68262ba-b2d6-442e-860c-66e936e9f54b
   name: Vpc_Ovs
   display_text: Vpc_Ovs
   cidr: 10.20.0.0/16
vpc_offering_id: 7
zone_id: 1
  state: Enabled
  domain_id: 1
 account_id: 2
 network_domain: cloud.internal
removed: NULL
created: 2014-05-21 09:57:48
   restart_required: 0
display: 1
uses_distributed_router: 0
   region_level_vpc: 0
1 row in set (0.00 sec)


mysql select * from vpc_offerings where id=7\G;
*** 1. row ***
 id: 7
   uuid: 57f06be5-d6fa-4e52-8dde-b876030f8f36
unique_name: Vpc_Ovs
   name: Vpc_Ovs
   display_text: Vpc_Ovs
  state: Enabled
default: 0
removed: NULL
created: 2014-05-21 09:57:02
service_offering_id: NULL
supports_distributed_router: 0
  supports_region_level_vpc: 0
1 row in set (0.00 sec)
mysql select * from networks where id=221\G;
*** 1. row ***
   id: 221
 name: test
 uuid: 979f25a8-3881-44ae-9404-27ee2bb89af5
 display_text: test
 traffic_type: Guest
broadcast_domain_type: Vswitch
broadcast_uri: NULL
  gateway: 10.20.2.1
 cidr: 10.20.2.0/24
 mode: Dhcp
  network_offering_id: 19
  physical_network_id: 200
   data_center_id: 1
guru_name: OvsGuestNetworkGuru
state: Allocated
  related: 221
domain_id: 1
   account_id: 2
 dns1: NULL
 dns2: NULL
guru_data: NULL
   set_fields: 0
 acl_type: Account
   network_domain: cloud.internal
   reservation_id: NULL
   guest_type: Isolated
 restart_required: 0
  created: 2014-05-21 10:03:45
  removed: NULL
specify_ip_ranges: 0
   vpc_id: 4
  ip6_gateway: NULL
 ip6_cidr: NULL
 network_cidr: NULL
  display_network: 1
   network_acl_id: 2
  streched_l2: 1
1 row in set (0.00 sec)




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

[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM

2014-05-20 Thread Kazuhiro Ito (JIRA)


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

Kazuhiro Ito commented on CLOUDSTACK-6631:
--

What storage backend are you using? 
Shared mount point(GPFS) for primary of two zones
NFS for primary of one zone and secondary of three zones

Are you using tagging for the disks?
Yes.
But when I don't use tagging for the disks, the same result.


 unable to attach new Volume to VM
 -

 Key: CLOUDSTACK-6631
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.2.1
 Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito

 1. I added new volume.
 2. I tried to attach the volume to a VM on UI.
 3. It failed and the following log appeared.
 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet] 
 (http-6443-exec-116:null) ===START===  133.xx.xxx.xxx -- GET  
 command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (http-6443-exec-116:null) submit async job-4916 = [ 
 dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId: 
 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543, 
 cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, 
 cmdOriginator: null, cmdInfo: 
 {response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for 
 job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet] 
 (http-6443-exec-116:null) ===END===  133.xx.xxx.xxx -- GET  
 command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
 to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to 
 Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
 DomainChecker_EnhancerByCloudStack_9b413459
 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
 to VM[User|TEST-A2-VM01] granted to 
 Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
 DomainChecker_EnhancerByCloudStack_9b413459
 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 LocalStoragePoolAllocator trying to find storage pool to fit the vm
 2014-05-12 11:29:47,212 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 ClusterScopeStoragePoolAllocator looking for storage pool
 2014-05-12 11:29:47,212 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Looking for pools in dc: 1  pod:1  cluster:null having tags:[MPI]
 2014-05-12 11:29:47,216 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No 
 storage pools available for shared volume allocation, returning
 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
 com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id, 
 SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM 
 `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id = 
 vol.pool_id WHERE pool.data_center_id = ?  AND pool.pod_id = ? AND 
 pool.cluster_id = ?  GROUP BY pool.id ORDER BY 2 ASC
 at

[jira] [Created] (CLOUDSTACK-6732) [OVS][UI] Network Service Providers page displays two ovs providers