[jira] [Commented] (CLOUDSTACK-9648) Checkstyle module version fails to update by build_asf.sh

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714378#comment-15714378
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9648:


GitHub user rhtyd opened a pull request:

https://github.com/apache/cloudstack/pull/1808

CLOUDSTACK-9648: Fix release script to update checkstyle pom

This fixes build_asf.sh release script to update checkstyle pom.xml with the
provided new version.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack 
fix-release-script-checkstyle

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1808.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1808


commit 77d2984494aa5fb32662c990503ae4f251fc4c6f
Author: Rohit Yadav 
Date:   2016-12-02T07:53:41Z

CLOUDSTACK-9648: Fix release script to update checkstyle pom

This fixes build_asf.sh release script to update checkstyle pom.xml with the
provided new version.

Signed-off-by: Rohit Yadav 




> Checkstyle module version fails to update by build_asf.sh
> -
>
> Key: CLOUDSTACK-9648
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9648
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> As reported on users@, the build_asf.sh fails to update checkstyle module's 
> pom.xml that fails builds when build from source tarballs.



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

[jira] [Created] (CLOUDSTACK-9648) Checkstyle module version fails to update by build_asf.sh

[Rohit Yadav (JIRA)]

Rohit Yadav created CLOUDSTACK-9648:
---

 Summary: Checkstyle module version fails to update by build_asf.sh
 Key: CLOUDSTACK-9648
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9648
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rohit Yadav
Assignee: Rohit Yadav
 Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0


As reported on users@, the build_asf.sh fails to update checkstyle module's 
pom.xml that fails builds when build from source tarballs.



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

[jira] [Created] (CLOUDSTACK-9647) NIC adapter type becomes e1000 , even after changing the global parameter "vmware.systemvm.nic.device.type" to vmxnet3 for VPC VR

[Sudhansu Sahu (JIRA)]

Sudhansu Sahu created CLOUDSTACK-9647:
-

 Summary: NIC adapter type becomes e1000 , even after changing the 
global parameter "vmware.systemvm.nic.device.type" to vmxnet3 for VPC VR
 Key: CLOUDSTACK-9647
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9647
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, VMware
Affects Versions: 4.9.0
Reporter: Sudhansu Sahu
Assignee: Sudhansu Sahu


ISSUE
=
NIC adapter type becomes e1000 , even after changing the global parameter 
"vmware.systemvm.nic.device.type" to vmxnet3.

Description
=

Repro steps:-

-> Set global parameter "vmware.systemvm.nic.device.type" to vmxnet3.
-> Created a VPC network and deployed a VM using the same network.
-> Checked the router details and found that for private network , it was 
showing nic adapter type as VMXNET3 and for other networks (public and guest) 
it was showing as E1000.
-> Rebooted the VPC network and checked it again, it was same as earlier.


/vmfs/volumes/94ec1ec2-0df8514b/r-2784-VM # grep virtualDev r-2784-VM.vmx
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.virtualDev = "pcieRootPort"
scsi0.virtualDev = "lsilogic"
ethernet0.virtualDev = "vmxnet3"
ethernet1.virtualDev = "e1000"
ethernet2.virtualDev = "vmxnet3"
ethernet3.virtualDev = "vmxnet3"



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

[jira] [Commented] (CLOUDSTACK-9644) Add bits field to template response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714345#comment-15714345
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9644:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Add bits field to template response
> ---
>
> Key: CLOUDSTACK-9644
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9644
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the list templates command to return the size of the template in bits.
> See: https://github.com/apache/cloudstack/pull/1622



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

[jira] [Commented] (CLOUDSTACK-9644) Add bits field to template response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714342#comment-15714342
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9644:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
@blueorangutan test


> Add bits field to template response
> ---
>
> Key: CLOUDSTACK-9644
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9644
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the list templates command to return the size of the template in bits.
> See: https://github.com/apache/cloudstack/pull/1622



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

[jira] [Commented] (CLOUDSTACK-9644) Add bits field to template response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714333#comment-15714333
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9644:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-303


> Add bits field to template response
> ---
>
> Key: CLOUDSTACK-9644
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9644
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the list templates command to return the size of the template in bits.
> See: https://github.com/apache/cloudstack/pull/1622



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714300#comment-15714300
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9633:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1807
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714298#comment-15714298
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9633:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1807
  
Pinging for review -- @jburwell @abhinandanprateek @borisstoyanov 
@blueorangutan package


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714297#comment-15714297
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9633:


GitHub user rhtyd opened a pull request:

https://github.com/apache/cloudstack/pull/1807

CLOUDSTACK-9633: Revert addition of `vhd` extention to snapshots

This reverts commit f1fd325c085cd61336ac616ba76e2c1f3f916cd1 and changes
introduced in commit f46651e6721106941deeb6b5e6bf51d7e9efc61c that changed 
the
snapshot file name to include a `vhd` extension.

With this change, CloudStack users should not hit upgrade issues.

Reference: 
https://github.com/apache/cloudstack/pull/1600#pullrequestreview-10955963

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack xen-vhd-extension-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1807.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1807


commit 2f24ebb7773653de9e389ca6637c47530e7eba46
Author: Rohit Yadav 
Date:   2016-12-02T07:14:16Z

CLOUDSTACK-9633: Revert addition of `vhd` extention to snapshots

This reverts commit f1fd325c085cd61336ac616ba76e2c1f3f916cd1 and changes
introduced in commit f46651e6721106941deeb6b5e6bf51d7e9efc61c that changed 
the
snapshot file name to include a `vhd` extension.

With this change, CloudStack users should not hit upgrade issues.

Signed-off-by: Rohit Yadav 




> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Assigned] (CLOUDSTACK-9646) [Usage] No usage is generated for uploaded templates/volumes from local

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi reassigned CLOUDSTACK-9646:
---

Assignee: Rajani Karuturi

> [Usage] No usage is generated for uploaded templates/volumes from local
> ---
>
> Key: CLOUDSTACK-9646
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9646
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>Priority: Critical
>
> Repro steps:
> 1. Upload a template from local 
> 2. Upload a volume from local
> Bug:
> notice no usage events and eventually no usage is generated for uploaded 
> template and volume 



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

[jira] [Updated] (CLOUDSTACK-9646) [Usage] No usage is generated for uploaded templates/volumes from local

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi updated CLOUDSTACK-9646:

Description: 
Repro steps:
1. Upload a template from local 
2. Upload a volume from local

Bug:
notice no usage events and eventually no usage is generated for uploaded 
template and volume 

  was:
Repro stesp:
1. Upload a template from local 
2. Upload a volume from local

Bug:
notice no usage events and eventually no usage is generated for uploaded 
template and volume 


> [Usage] No usage is generated for uploaded templates/volumes from local
> ---
>
> Key: CLOUDSTACK-9646
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9646
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rajani Karuturi
>Priority: Critical
>
> Repro steps:
> 1. Upload a template from local 
> 2. Upload a volume from local
> Bug:
> notice no usage events and eventually no usage is generated for uploaded 
> template and volume 



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

[jira] [Created] (CLOUDSTACK-9646) [Usage] No usage is generated for uploaded templates/volumes from local

[Rajani Karuturi (JIRA)]

Rajani Karuturi created CLOUDSTACK-9646:
---

 Summary: [Usage] No usage is generated for uploaded 
templates/volumes from local
 Key: CLOUDSTACK-9646
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9646
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rajani Karuturi
Priority: Critical


Repro stesp:
1. Upload a template from local 
2. Upload a volume from local

Bug:
notice no usage events and eventually no usage is generated for uploaded 
template and volume 



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

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714284#comment-15714284
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Test lgtm, @murali-reddy are we good on this PR? I'm seeing some failures 
though not sure if they related to your changes. /cc @jburwell 
@abhinandanprateek 


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



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

[jira] [Commented] (CLOUDSTACK-9597) Incorrect updateResourceCount()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714274#comment-15714274
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9597:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1764
  
Thanks @marcaurele 
@blueorangutan package


> Incorrect updateResourceCount()
> ---
>
> Key: CLOUDSTACK-9597
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9597
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> h3. Currently
> On management server startup, the {{ConfigurationServerImpl}} does a check on 
> the resource type * resource count versus number of accounts & domains to see 
> if all accounts and domains have a resource count set for each resource type. 
> The list of accounts and domains are fetched excluding the removed ones. But 
> the number of resourceCount by account and domain takes all of them, leading 
> to an incorrect math check.
> The API command {{updateResourceCount}} can crash with an incorrect SQL query.
> I discovered the problem while adding a new {{ResourceType}}.
> h3. Changes
> Fetch the number of resourceCount by domain and account excluding the removed 
> ones.



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

[jira] [Commented] (CLOUDSTACK-9597) Incorrect updateResourceCount()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714271#comment-15714271
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9597:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1764
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Incorrect updateResourceCount()
> ---
>
> Key: CLOUDSTACK-9597
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9597
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> h3. Currently
> On management server startup, the {{ConfigurationServerImpl}} does a check on 
> the resource type * resource count versus number of accounts & domains to see 
> if all accounts and domains have a resource count set for each resource type. 
> The list of accounts and domains are fetched excluding the removed ones. But 
> the number of resourceCount by account and domain takes all of them, leading 
> to an incorrect math check.
> The API command {{updateResourceCount}} can crash with an incorrect SQL query.
> I discovered the problem while adding a new {{ResourceType}}.
> h3. Changes
> Fetch the number of resourceCount by domain and account excluding the removed 
> ones.



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

[jira] [Commented] (CLOUDSTACK-9639) Unable to create shared network with vLan isolation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714223#comment-15714223
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9639:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1804
  
@nitin-maharana  this looks useful, can you change the base branch for the 
PR to 4.9, rebase your PR branch against 4.9? Can you add a marvin test for 
this?


> Unable to create shared network with vLan isolation
> ---
>
> Key: CLOUDSTACK-9639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9639
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Create shared network fails with error While creating a shared network it 
> fails to create with Error "The new IP range you have specified has 
> overlapped with the guest network in the zone: XYZ. Please specify a 
> different gateway/netmask"
> Steps to Reproduce:
> ===
> Create an isolated network with a subnet eg: 10.1.1.0.24
> Create a shared network with the same subnet but different VLAN, we should 
> observe this issue.
> EXPECTED BEHAVIOR 
> ===
> It shouldn't restrict the creation of guest network's with same subnet as 
> long as they are segmented by VLAN.
> ACTUAL BEHAVIOR 
> 
> It doesn't allow the creation of shared guest networks if there is any 
> isolated guest network using the same subnet although it allows using the 
> same subnet in multiple shared networks.



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

[jira] [Commented] (CLOUDSTACK-9637) Template create from snapshot does not populate vm_template_details

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714220#comment-15714220
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9637:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1805
  
Nice fix, @sudhansu7 this looks useful, can you change the base branch for 
the PR to 4.9, rebase your PR branch against 4.9?


> Template create from snapshot does not populate vm_template_details
> ---
>
> Key: CLOUDSTACK-9637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9637
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.8.0
> Environment:  VMware ESX , CS 4.8.0
>Reporter: Sudhansu Sahu
>Assignee: Sudhansu Sahu
>
> ISSUE
> 
> Template create from snapshot does not populate vm_template_details
> TROUBLESHOOTING
> ==
> {noformat}
> mysql> select id,name,uuid,instance_name,vm_template_id from vm_instance 
> where uuid='453313f5-ef97-461a-94f5-0838617fe826'
> -> ;
> ++---+--+---++
> | id | name  | uuid | instance_name | 
> vm_template_id |
> ++---+--+---++
> |  9 | vm001 | 453313f5-ef97-461a-94f5-0838617fe826 | i-2-9-VM  | 
>202 |
> ++---+--+---++
> 1 row in set (0.00 sec)
> mysql> select id,name,source_template_id from vm_template where id=202; 
> +-+++
> | id  | name   | source_template_id |
> +-+++
> | 202 | Debian |   NULL |
> +-+++
> 1 row in set (0.00 sec)
> mysql> select * from vm_template_details where template_id=202; 
> ++-++---+-+
> | id | template_id | name   | value | display |
> ++-++---+-+
> |  1 | 202 | keyboard   | us|   1 |
> |  2 | 202 | nicAdapter | E1000 |   1 |
> |  3 | 202 | rootDiskController | scsi  |   1 |
> ++-++---+-+
> 3 rows in set (0.00 sec)
> mysql> select id,name,source_template_id from vm_template where 
> source_template_id=202;
> +-+++
> | id  | name   | source_template_id |
> +-+++
> | 203 | derived-debian |202 |
> +-+++
> 1 row in set (0.00 sec)
> mysql> select * from vm_template_details where template_id=203;
> Empty set (0.00 sec)
> {noformat}
> REPRO STEPS
> ==
> 1. Register a template A and specify property:
> Root disk controller: scsi
> NIC adapter type: E1000
> Keyboard type: us
> 2. Create a vm instance from template A
> 3. Take volume snapshot for vm instance
> 4. Delete VM instance
> 5. Switch to "Storage->Snapshots", convert snapshot to a template B
> 6. Observe template B does not inherit property from template A, the table 
> vm_template_details is empty
> EXPECTED BEHAVIOR
> ==
> Template should inherit property from source template
>  
> ACTUAL BEHAVIOR
> ==
> Detail template property lost



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714186#comment-15714186
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9633:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1800


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714181#comment-15714181
 ] 

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

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

CLOUDSTACK-9633:test_snapshot is failing due to incorrect string construction 
in utils.py

Signed-off-by: Rohit Yadav 


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714183#comment-15714183
 ] 

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

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

Merge pull request #1800 from shapeblue/4.8-marvin-fix-for-snapshots-xenserver

CLOUDSTACK-9633:test_snapshot is failing due to incorrect string construction 
in utils.py

* pr/1800:
  CLOUDSTACK-9633:test_snapshot is failing due to incorrect string construction 
in utils.py

Signed-off-by: Rohit Yadav 


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714182#comment-15714182
 ] 

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

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

Merge pull request #1800 from shapeblue/4.8-marvin-fix-for-snapshots-xenserver

CLOUDSTACK-9633:test_snapshot is failing due to incorrect string construction 
in utils.py

* pr/1800:
  CLOUDSTACK-9633:test_snapshot is failing due to incorrect string construction 
in utils.py

Signed-off-by: Rohit Yadav 


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714176#comment-15714176
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9633:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1800
  
Thanks @syed I'll go ahead and merge this, as the changes confirm. I'm okay 
that moving (4.10+) fwd we've `.vhd` extension in snapshot files.


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-9630) Cannot use listNics API as advertised

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714150#comment-15714150
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9630:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1797
  
@sudhansu7 could you please either add or update an existing a Marvin test 
case to verify this change?

Also, this change seems like it would be useful for LTS users.  Could you 
please change the base branch to 4.9?


> Cannot use listNics API as advertised
> -
>
> Key: CLOUDSTACK-9630
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9630
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sudhansu Sahu
>
> listNics API for a VM, "type" was not returned within API response. 
> EXPECTED BEHAVIOR
> ==
> The listNics API response return type of NIC (type), as specified in 
> https://cloudstack.apache.org/api/apidocs-4.8/user/listNics.html
>  
> ACTUAL BEHAVIOR
> ==
> The listNics API response does not return type of NIC.
> (local)  > list nics virtualmachineid=a69edaf5-8f21-41ff-8c05-263dc4bd5354 
> count = 1
> nic:
> id = 211e0d46-6b94-4425-99f7-e8e9efea2472
> deviceid = 0
> gateway = 10.1.1.1
> ipaddress = 10.1.1.45
> isdefault = True
> macaddress = 02:00:06:f6:00:01
> netmask = 255.255.255.0
> networkid = c08fddf1-fd77-4810-a062-ea9d03c5c7e6
> virtualmachineid = a69edaf5-8f21-41ff-8c05-263dc4bd5354
>  
>  



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714144#comment-15714144
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
Tests look good so far, I'm waiting for a vmware specific test run to 
complete. Some failures in kvm, xen are known intermittent failures.


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714138#comment-15714138
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@murali-reddy can you have a look at why private_gw failed again for vmware?


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714133#comment-15714133
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user jburwell commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/873#discussion_r90589240
  
--- Diff: server/src/com/cloud/storage/StorageManagerImpl.java ---
@@ -1746,10 +1747,10 @@ public boolean 
storagePoolHasEnoughSpace(List volumes, StoragePool pool,
 allocatedSizeWithTemplate = 
_capacityMgr.getAllocatedPoolCapacity(poolVO, tmpl);
 }
 }
-
-if (volumeVO.getState() != Volume.State.Ready) {
-totalAskingSize += 
getDataObjectSizeIncludingHypervisorSnapshotReserve(volumeVO, pool);
-
+// A ready state volume is already allocated in a pool. so the 
asking size is zero for it.
+// In case the volume is moving across pools or is not ready 
yet, the asking size has to be computed
+s_logger.debug("pool id for the volume with id: " + 
volumeVO.getId() + " is: " + volumeVO.getPoolId());
--- End diff --

Please wrap this `DEBUG` log in an `if (s_logger.isDebugEnabled)` check to 
prevent unnecessary/expensive string concatenation when `DEBUG` logging is not 
enabled.

Minor nit: grammatically, the `:` character after `is` is unnecessary.


> Allocated percentage of storage can go beyond 100%
> --
>
> Key: CLOUDSTACK-8896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope 
> primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another 
> cluster, the volume is moved to the new cluster and the asking size is zero 
> at this time.
> you can observe logs like below with asking size 0 in the management server 
> logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] 
> (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) 
> (logid:a0a97129) Checking pool: 1 for volume allocation 
> [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 
> 24096276480, askingSize : 0, allocated disable threshold: 0.85



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714134#comment-15714134
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user jburwell commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/873#discussion_r90589284
  
--- Diff: server/src/com/cloud/storage/StorageManagerImpl.java ---
@@ -1719,6 +1719,7 @@ public boolean storagePoolHasEnoughSpace(List 
volumes, StoragePool pool,
 }
 
 // allocated space includes templates
+s_logger.debug("Destination pool id: " + pool.getId());
--- End diff --

Please wrap this `DEBUG` log in an `if (s_logger.isDebugEnabled)` check to 
prevent unnecessary/expensive string concatenation when `DEBUG` logging is not 
enabled.  Also, please add context to message to explain what operation is 
being performed for the destination pool.


> Allocated percentage of storage can go beyond 100%
> --
>
> Key: CLOUDSTACK-8896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope 
> primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another 
> cluster, the volume is moved to the new cluster and the asking size is zero 
> at this time.
> you can observe logs like below with asking size 0 in the management server 
> logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] 
> (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) 
> (logid:a0a97129) Checking pool: 1 for volume allocation 
> [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 
> 24096276480, askingSize : 0, allocated disable threshold: 0.85



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714122#comment-15714122
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/873
  
Test LGTM.


> Allocated percentage of storage can go beyond 100%
> --
>
> Key: CLOUDSTACK-8896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope 
> primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another 
> cluster, the volume is moved to the new cluster and the asking size is zero 
> at this time.
> you can observe logs like below with asking size 0 in the management server 
> logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] 
> (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) 
> (logid:a0a97129) Checking pool: 1 for volume allocation 
> [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 
> 24096276480, askingSize : 0, allocated disable threshold: 0.85



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714113#comment-15714113
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1257
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714110#comment-15714110
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1257
  
@sureshanaparti sorry, this is a restricted command to avoid resource abuse 
issues.
@blueorangutan package


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-9643) Add OS info to list snapshots response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714106#comment-15714106
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9643:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1618
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Add OS info to list snapshots response
> --
>
> Key: CLOUDSTACK-9643
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9643
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Add OS info to list snapshots response. See 
> https://github.com/apache/cloudstack/pull/1618



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

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714107#comment-15714107
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1579
  
Travis is failing due to an env issue in their VMs, I'm investigating it 
with #1806 


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for regular user in a shared 
> network with scope=account ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for a domain admin users in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for other users in a shared 
> network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for admin user in a domain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status 
> : SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able 

[jira] [Commented] (CLOUDSTACK-9643) Add OS info to list snapshots response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714103#comment-15714103
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9643:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1618
  
Thanks @ProjectMoon 
@blueorangutan package


> Add OS info to list snapshots response
> --
>
> Key: CLOUDSTACK-9643
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9643
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Add OS info to list snapshots response. See 
> https://github.com/apache/cloudstack/pull/1618



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

[jira] [Commented] (CLOUDSTACK-9644) Add bits field to template response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714101#comment-15714101
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9644:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Add bits field to template response
> ---
>
> Key: CLOUDSTACK-9644
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9644
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the list templates command to return the size of the template in bits.
> See: https://github.com/apache/cloudstack/pull/1622



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

[jira] [Commented] (CLOUDSTACK-9644) Add bits field to template response

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714100#comment-15714100
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9644:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1622
  
Thanks @ProjectMoon 
@blueorangutan package


> Add bits field to template response
> ---
>
> Key: CLOUDSTACK-9644
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9644
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the list templates command to return the size of the template in bits.
> See: https://github.com/apache/cloudstack/pull/1622



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

[jira] [Commented] (CLOUDSTACK-9645) Add support for not restarting the management server after setup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714102#comment-15714102
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9645:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1566
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Add support for not restarting the management server after setup
> 
>
> Key: CLOUDSTACK-9645
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9645
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the cloudstack-setup-management script to allow the ability to NOT 
> restart the management server. Helps with systemd. This has been implemented 
> already, but there was a bug with it where it would not properly respect the 
> option.



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

[jira] [Commented] (CLOUDSTACK-9645) Add support for not restarting the management server after setup

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714098#comment-15714098
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9645:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1566
  
LGTM. Thanks @ProjectMoon 
@blueorangutan package


> Add support for not restarting the management server after setup
> 
>
> Key: CLOUDSTACK-9645
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9645
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Jeff Hair
> Fix For: 4.10.0.0
>
>
> Enhance the cloudstack-setup-management script to allow the ability to NOT 
> restart the management server. Helps with systemd. This has been implemented 
> already, but there was a bug with it where it would not properly respect the 
> option.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714087#comment-15714087
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user rhtyd closed the pull request at:

https://github.com/apache/cloudstack/pull/1799


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714088#comment-15714088
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


GitHub user rhtyd reopened a pull request:

https://github.com/apache/cloudstack/pull/1799

CLOUDSTACK-9632: Upgrade bouncy castle to version 1.55

- Upgrades Maven dependency version to v1.55
- Fixes bountycastle usages and issues
- Adds timeout to jetty/annotation scanning
- Picks up PR #1510 by Daan

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack bcprov-upgrade

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1799.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1799


commit 81fb8af81f3e4731f9423d1cd806323068795ce3
Author: Rohit Yadav 
Date:   2016-11-30T09:31:28Z

CLOUDSTACK-9632: Upgrade bouncy castle to version 1.55

- Upgrades Maven dependency version to v1.55
- Fixes bountycastle usages and issues
- Adds timeout to jetty/annotation scanning
- Fixes servlet issue, uses servlet 3.1.0
- Picks up PR #1510 by Daan

Signed-off-by: Rohit Yadav 




> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714073#comment-15714073
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714071#comment-15714071
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714070#comment-15714070
 ] 

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

Commit 309da6a57f202322b71dca98b5695dfb278447a8 in cloudstack's branch 
refs/heads/master from [~sureshkumar.anaparti]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=309da6a ]

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714072#comment-15714072
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714074#comment-15714074
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714060#comment-15714060
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8854:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/828


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714057#comment-15714057
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714055#comment-15714055
 ] 

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

Commit 309da6a57f202322b71dca98b5695dfb278447a8 in cloudstack's branch 
refs/heads/4.9 from [~sureshkumar.anaparti]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=309da6a ]

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714058#comment-15714058
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714059#comment-15714059
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714056#comment-15714056
 ] 

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

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

Merge pull request #828 from sureshanaparti/CLOUDSTACK-8854

CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisorsCLOUDSTACK-8854: Apple Mac OS/X VM get created without USB 
controller in ESXi hypervisors

Problem Description: CloudStack doesnt add a USB controller to the Apple Mac OS 
X VMs created in ESXi hypervisors. But, vSphere Client, by default, adds a USB 
Controller to the Mac OS VMs. Mac OS X machines require USB Controller for USB 
mouse and keyboard access.

Root Cause: The Guest OS details are specified in the Virtual Machine 
Configuration Spec for creating the VM (using the SDK API) in the EXSi 
hypervisor. No USB Controller is added to the Virtual Machine Configuration 
Spec. As the guest OS Identification details are specified in the VM 
Configuration Spec, It is assumed that the Create VM SDK API would create the 
defaults in the VM same as vSphere Client. But, as per the observation, USB 
Controller is not added to the Guest OS - Mac OS VM created through the SDK API.

Resolution: When the Guest OS is Apple Mac OS, Add the USB Controller 
(EHCI+UHCI - Mac supported) to the Virtual Machine Configuration Spec before 
Creating or Starting the VM. For any existing Mac OS VMs, Stop and Start to add 
the USB Controller. For new VMs with Mac OS, USB Controller is added 
automatically.

* pr/828:
  CLOUDSTACK-8854: Apple Mac OS/X VM get created without USB controller in ESXi 
hypervisors

Signed-off-by: Rohit Yadav 


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714050#comment-15714050
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8854:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/828
  
I looked at the failure, all of them are environment related or known 
intermittent failures. I'll proceed with merging this. LGTM.


> Apple Mac OS/X VM get created without USB controller in ESXi hypervisors
> 
>
> Key: CLOUDSTACK-8854
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8854
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: Future
>
>
> ISSUE
> ==
> Apple Mac OS/X VM get created without USB controller. For mouse/keyboard to 
> function in CS Console window VM has to have USB controller. It seems CS 
> doesn't use the same procedure as native vSphere client because natively when 
> OS is specified as OS/X vSphere always adds USB controller to empty VM shell.
> EXPECTED BEHAVIOR
> ==
> USB device added to VM when created on CS
> ACTUAL BEHAVIOR
> ==
> No USB device added



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713990#comment-15713990
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
Trillian test result (tid-537)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 34106 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1802-t537-vmware-55u3.zip
Test completed. 37 look ok, 6 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_02_VPC_default_routes | `Failure` | 239.44 | test_vpc_router_nics.py
test_01_vpc_site2site_vpn | `Error` | 472.66 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | `Error` | 730.42 | test_vpc_vpn.py
test_06_download_detached_volume | `Error` | 60.74 | test_volumes.py
ContextSuite context=TestVMLifeCycle>:setup | `Error` | 0.00 | 
test_vm_life_cycle.py
ContextSuite context=TestDeployVM>:setup | `Error` | 0.00 | 
test_vm_life_cycle.py
test_01_create_template | `Error` | 20.37 | test_templates.py
ContextSuite context=TestTemplates>:setup | `Error` | 661.65 | 
test_templates.py
test_02_vpc_privategw_static_routes | `Error` | 651.29 | 
test_privategw_acl.py
test_01_vpc_remote_access_vpn | Success | 162.65 | test_vpc_vpn.py
test_01_VPC_nics_after_destroy | Success | 656.49 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 637.34 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1584.72 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 699.14 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 602.84 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1247.36 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 31.10 | test_volumes.py
test_05_detach_volume | Success | 105.30 | test_volumes.py
test_04_delete_attached_volume | Success | 15.36 | test_volumes.py
test_03_download_attached_volume | Success | 25.68 | test_volumes.py
test_02_attach_volume | Success | 58.90 | test_volumes.py
test_01_create_volume | Success | 533.23 | test_volumes.py
test_03_delete_vm_snapshots | Success | 280.35 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 199.43 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 192.04 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 167.06 | test_vm_snapshots.py
test_CreateTemplateWithDuplicateName | Success | 394.67 | test_templates.py
test_10_destroy_cpvm | Success | 272.35 | test_ssvm.py
test_09_destroy_ssvm | Success | 264.42 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.76 | test_ssvm.py
test_07_reboot_ssvm | Success | 189.79 | test_ssvm.py
test_06_stop_cpvm | Success | 208.01 | test_ssvm.py
test_05_stop_ssvm | Success | 209.91 | test_ssvm.py
test_04_cpvm_internals | Success | 1.63 | test_ssvm.py
test_03_ssvm_internals | Success | 3.90 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.16 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.18 | test_ssvm.py
test_01_snapshot_root_disk | Success | 71.80 | test_snapshots.py
test_04_change_offering_small | Success | 97.43 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py
test_01_create_service_offering | Success | 0.18 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.20 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.20 | test_secondary_storage.py
test_09_reboot_router | Success | 171.58 | test_routers.py
test_08_start_router | Success | 136.60 | test_routers.py
test_07_stop_router | Success | 25.49 | test_routers.py
test_06_router_advanced | Success | 0.06 | test_routers.py
test_05_router_basic | Success | 0.07 | test_routers.py
test_04_restart_network_wo_cleanup | Success | 5.87 | test_routers.py
test_03_restart_network_cleanup | Success | 181.87 | test_routers.py
test_02_router_internal_adv | Success | 1.09 | test_routers.py
test_01_router_internal_basic | Success | 0.60 | test_routers.py
test_router_dhcphosts | Success | 154.99 | test_router_dhcphosts.py
test_router_dhcp_opts | Success | 22.46 | test_router_dhcphosts.py
test_01_updatevolumedetail | Success | 5.12 | test_resource_detail.py
test_01_reset_vm_on_reboot | Success | 35.51 | test_reset_vm_on_reboot.py
test_createRegion | Success | 0.11 | test_regions.py
test_create_pvlan_network | Success | 5.47 | test_pvlan.py

[jira] [Commented] (CLOUDSTACK-9639) Unable to create shared network with vLan isolation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713962#comment-15713962
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9639:


Github user nitin-maharana commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1804#discussion_r90584766
  
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
---
@@ -3092,8 +3092,12 @@ public Vlan createVlanAndPublicIpRange(final long 
zoneId, final long networkId,
 final String guestNetworkCidr = zone.getGuestNetworkCidr();
 if (guestNetworkCidr != null) {
 if (NetUtils.isNetworksOverlap(newCidr, guestNetworkCidr)) 
{
-throw new InvalidParameterValueException("The new IP 
range you have specified has  overlapped with the guest network in zone: " + 
zone.getName()
-+ ". Please specify a different 
gateway/netmask.");
+// when adding shared network with same cidr of zone 
guest cidr,
+// if the specified vlan is not present in zone, 
physical network, allow to create the network as the isolation is based on VLAN.
+if (_zoneDao.findVnet(zoneId, physicalNetworkId, 
vlanId).size() > 0) {
--- End diff --

@jburwell : Thanks for your suggestion. I will consider this change. The 
effect would be same if we put all the conditions with && operator.


> Unable to create shared network with vLan isolation
> ---
>
> Key: CLOUDSTACK-9639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9639
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Create shared network fails with error While creating a shared network it 
> fails to create with Error "The new IP range you have specified has 
> overlapped with the guest network in the zone: XYZ. Please specify a 
> different gateway/netmask"
> Steps to Reproduce:
> ===
> Create an isolated network with a subnet eg: 10.1.1.0.24
> Create a shared network with the same subnet but different VLAN, we should 
> observe this issue.
> EXPECTED BEHAVIOR 
> ===
> It shouldn't restrict the creation of guest network's with same subnet as 
> long as they are segmented by VLAN.
> ACTUAL BEHAVIOR 
> 
> It doesn't allow the creation of shared guest networks if there is any 
> isolated guest network using the same subnet although it allows using the 
> same subnet in multiple shared networks.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713777#comment-15713777
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
Trillian test result (tid-534)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 26155 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1799-t534-kvm-centos7.zip
Test completed. 46 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 379.95 
| test_vpc_redundant.py
test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 173.70 | 
test_privategw_acl.py
test_02_vpc_privategw_static_routes | `Failure` | 154.11 | 
test_privategw_acl.py
test_01_vpc_site2site_vpn | Success | 170.07 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 66.22 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 256.30 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 277.63 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 556.61 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 517.70 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1453.95 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 565.63 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 671.02 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.66 | test_volumes.py
test_08_resize_volume | Success | 15.47 | test_volumes.py
test_07_resize_fail | Success | 20.52 | test_volumes.py
test_06_download_detached_volume | Success | 15.32 | test_volumes.py
test_05_detach_volume | Success | 100.29 | test_volumes.py
test_04_delete_attached_volume | Success | 10.24 | test_volumes.py
test_03_download_attached_volume | Success | 15.44 | test_volumes.py
test_02_attach_volume | Success | 44.43 | test_volumes.py
test_01_create_volume | Success | 711.72 | test_volumes.py
test_deploy_vm_multiple | Success | 278.16 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.72 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.20 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 41.09 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.89 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.92 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.18 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.34 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 60.64 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.06 | test_templates.py
test_04_extract_template | Success | 5.32 | test_templates.py
test_03_delete_template | Success | 5.16 | test_templates.py
test_02_edit_template | Success | 90.16 | test_templates.py
test_01_create_template | Success | 40.66 | test_templates.py
test_10_destroy_cpvm | Success | 166.76 | test_ssvm.py
test_09_destroy_ssvm | Success | 193.79 | test_ssvm.py
test_08_reboot_cpvm | Success | 131.66 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.69 | test_ssvm.py
test_06_stop_cpvm | Success | 131.87 | test_ssvm.py
test_05_stop_ssvm | Success | 134.66 | test_ssvm.py
test_04_cpvm_internals | Success | 1.25 | test_ssvm.py
test_03_ssvm_internals | Success | 3.49 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.15 | test_ssvm.py
test_01_snapshot_root_disk | Success | 16.40 | test_snapshots.py
test_04_change_offering_small | Success | 239.96 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.07 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.10 | test_service_offerings.py
test_01_create_service_offering | Success | 0.14 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.15 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.23 | test_secondary_storage.py
test_09_reboot_router | Success | 40.35 | test_routers.py
test_08_start_router | Success | 30.33 | test_routers.py
test_07_stop_router | Success | 10.22 | test_routers.py
test_06_router_advanced | Success | 0.06 | 

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713750#comment-15713750
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
Trillian test result (tid-536)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 25203 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1802-t536-kvm-centos7.zip
Test completed. 42 look ok, 1 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_05_rvpc_multi_tiers | `Failure` | 346.18 | test_vpc_redundant.py
test_05_rvpc_multi_tiers | `Error` | 628.85 | test_vpc_redundant.py
test_01_vpc_site2site_vpn | Success | 156.23 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 71.39 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 297.05 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 307.10 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 528.13 | test_vpc_router_nics.py
test_04_rvpc_network_garbage_collector_nics | Success | 1319.90 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 546.18 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 752.71 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1259.18 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.64 | test_volumes.py
test_08_resize_volume | Success | 15.58 | test_volumes.py
test_07_resize_fail | Success | 20.59 | test_volumes.py
test_06_download_detached_volume | Success | 15.43 | test_volumes.py
test_05_detach_volume | Success | 100.25 | test_volumes.py
test_04_delete_attached_volume | Success | 10.25 | test_volumes.py
test_03_download_attached_volume | Success | 15.38 | test_volumes.py
test_02_attach_volume | Success | 44.53 | test_volumes.py
test_01_create_volume | Success | 740.87 | test_volumes.py
test_deploy_vm_multiple | Success | 270.33 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.04 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.04 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 27.44 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.16 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 36.52 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.23 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 126.21 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 126.08 | test_vm_life_cycle.py
test_02_start_vm | Success | 5.13 | test_vm_life_cycle.py
test_01_stop_vm | Success | 35.32 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 70.75 | test_templates.py
test_08_list_system_templates | Success | 0.07 | test_templates.py
test_07_list_public_templates | Success | 0.07 | test_templates.py
test_05_template_permissions | Success | 0.09 | test_templates.py
test_04_extract_template | Success | 5.21 | test_templates.py
test_03_delete_template | Success | 5.10 | test_templates.py
test_02_edit_template | Success | 90.18 | test_templates.py
test_01_create_template | Success | 65.77 | test_templates.py
test_10_destroy_cpvm | Success | 193.14 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.36 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.71 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.78 | test_ssvm.py
test_06_stop_cpvm | Success | 131.62 | test_ssvm.py
test_05_stop_ssvm | Success | 133.91 | test_ssvm.py
test_04_cpvm_internals | Success | 1.01 | test_ssvm.py
test_03_ssvm_internals | Success | 3.44 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.20 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py
test_01_snapshot_root_disk | Success | 12.43 | test_snapshots.py
test_04_change_offering_small | Success | 209.85 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.09 | test_service_offerings.py
test_01_create_service_offering | Success | 0.14 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.24 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.29 | test_secondary_storage.py
test_09_reboot_router | Success | 35.32 | test_routers.py
test_08_start_router | Success | 25.30 | test_routers.py
test_07_stop_router | Success | 10.18 | test_routers.py
test_06_router_advanced | Success | 0.05 | test_routers.py
test_05_router_basic | Success | 0.04 | test_routers.py
test_04_restart_network_wo_cleanup 

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713711#comment-15713711
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Trillian test result (tid-532)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 35829 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1659-t532-vmware-55u3.zip
Test completed. 44 look ok, 4 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_redundant_vpc_site2site_vpn | `Failure` | 475.07 | test_vpc_vpn.py
test_04_rvpc_privategw_static_routes | `Failure` | 982.62 | 
test_privategw_acl.py
test_04_rvpc_internallb_haproxy_stats_on_all_interfaces | `Failure` | 
216.66 | test_internal_lb.py
test_02_internallb_roundrobin_1RVPC_3VM_HTTP_port80 | `Failure` | 126.29 | 
test_internal_lb.py
test_01_vpc_site2site_vpn | `Error` | 543.04 | test_vpc_vpn.py
test_05_rvpc_multi_tiers | `Error` | 132.69 | test_vpc_redundant.py
test_01_vpc_remote_access_vpn | Success | 177.06 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 340.74 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 814.99 | test_vpc_router_nics.py
test_04_rvpc_network_garbage_collector_nics | Success | 1554.98 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 725.91 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 727.82 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1509.99 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 31.12 | test_volumes.py
test_06_download_detached_volume | Success | 95.77 | test_volumes.py
test_05_detach_volume | Success | 105.30 | test_volumes.py
test_04_delete_attached_volume | Success | 15.25 | test_volumes.py
test_03_download_attached_volume | Success | 25.46 | test_volumes.py
test_02_attach_volume | Success | 63.85 | test_volumes.py
test_01_create_volume | Success | 549.55 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.17 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 200.26 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 368.24 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 159.06 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 309.06 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.86 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 86.36 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.11 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.15 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.15 | test_vm_life_cycle.py
test_02_start_vm | Success | 25.28 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.15 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 287.25 | test_templates.py
test_08_list_system_templates | Success | 0.04 | test_templates.py
test_07_list_public_templates | Success | 0.05 | test_templates.py
test_05_template_permissions | Success | 0.07 | test_templates.py
test_04_extract_template | Success | 15.27 | test_templates.py
test_03_delete_template | Success | 5.12 | test_templates.py
test_02_edit_template | Success | 90.15 | test_templates.py
test_01_create_template | Success | 141.01 | test_templates.py
test_10_destroy_cpvm | Success | 322.22 | test_ssvm.py
test_09_destroy_ssvm | Success | 274.20 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.75 | test_ssvm.py
test_07_reboot_ssvm | Success | 158.57 | test_ssvm.py
test_06_stop_cpvm | Success | 201.97 | test_ssvm.py
test_05_stop_ssvm | Success | 178.60 | test_ssvm.py
test_04_cpvm_internals | Success | 1.36 | test_ssvm.py
test_03_ssvm_internals | Success | 3.40 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.22 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py
test_01_snapshot_root_disk | Success | 71.72 | test_snapshots.py
test_04_change_offering_small | Success | 122.06 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py
test_01_create_service_offering | Success | 0.13 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713704#comment-15713704
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Trillian test result (tid-533)
Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 7
Total time taken: 35604 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1659-t533-xenserver-65sp1.zip
Test completed. 46 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_05_rvpc_multi_tiers | `Failure` | 618.66 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | `Failure` | 1390.72 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 669.12 
| test_vpc_redundant.py
test_04_rvpc_privategw_static_routes | `Failure` | 883.45 | 
test_privategw_acl.py
test_01_vpc_site2site_vpn | Success | 396.07 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 156.21 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 687.83 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 484.63 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 702.60 | test_vpc_router_nics.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 993.18 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 1097.71 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.61 | test_volumes.py
test_08_resize_volume | Success | 90.70 | test_volumes.py
test_07_resize_fail | Success | 100.72 | test_volumes.py
test_06_download_detached_volume | Success | 20.26 | test_volumes.py
test_05_detach_volume | Success | 100.24 | test_volumes.py
test_04_delete_attached_volume | Success | 10.19 | test_volumes.py
test_03_download_attached_volume | Success | 15.20 | test_volumes.py
test_02_attach_volume | Success | 10.77 | test_volumes.py
test_01_create_volume | Success | 388.38 | test_volumes.py
test_03_delete_vm_snapshots | Success | 280.20 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 186.32 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 105.88 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 247.51 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 41.73 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.13 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 75.91 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.09 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.12 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 20.17 | test_vm_life_cycle.py
test_02_start_vm | Success | 30.23 | test_vm_life_cycle.py
test_01_stop_vm | Success | 35.22 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 162.03 | test_templates.py
test_08_list_system_templates | Success | 0.02 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.04 | test_templates.py
test_04_extract_template | Success | 5.47 | test_templates.py
test_03_delete_template | Success | 5.10 | test_templates.py
test_02_edit_template | Success | 90.13 | test_templates.py
test_01_create_template | Success | 85.63 | test_templates.py
test_10_destroy_cpvm | Success | 261.56 | test_ssvm.py
test_09_destroy_ssvm | Success | 259.12 | test_ssvm.py
test_08_reboot_cpvm | Success | 161.57 | test_ssvm.py
test_07_reboot_ssvm | Success | 143.90 | test_ssvm.py
test_06_stop_cpvm | Success | 171.81 | test_ssvm.py
test_05_stop_ssvm | Success | 199.34 | test_ssvm.py
test_04_cpvm_internals | Success | 1.13 | test_ssvm.py
test_03_ssvm_internals | Success | 3.56 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.09 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.09 | test_ssvm.py
test_01_snapshot_root_disk | Success | 31.33 | test_snapshots.py
test_04_change_offering_small | Success | 121.07 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.04 | test_service_offerings.py
test_01_create_service_offering | Success | 0.06 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.10 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.13 | test_secondary_storage.py
test_01_scale_vm | Success | 5.13 | test_scale_vm.py
test_09_reboot_router | Success 

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713094#comment-15713094
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
Trillian test result (tid-525)
Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 6
Total time taken: 34869 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1799-t525-xenserver-65sp1.zip
Test completed. 46 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_network_garbage_collector_nics | `Failure` | 1458.32 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 621.42 
| test_vpc_redundant.py
test_01_vpc_site2site_vpn | `Error` | 910.77 | test_vpc_vpn.py
test_05_rvpc_multi_tiers | `Error` | 87.08 | test_vpc_redundant.py
test_01_vpc_remote_access_vpn | Success | 178.02 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 640.99 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 478.60 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 614.90 | test_vpc_router_nics.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 1003.67 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 1061.20 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 21.11 | test_volumes.py
test_08_resize_volume | Success | 116.48 | test_volumes.py
test_07_resize_fail | Success | 121.76 | test_volumes.py
test_06_download_detached_volume | Success | 35.62 | test_volumes.py
test_05_detach_volume | Success | 105.43 | test_volumes.py
test_04_delete_attached_volume | Success | 15.44 | test_volumes.py
test_03_download_attached_volume | Success | 20.70 | test_volumes.py
test_02_attach_volume | Success | 21.13 | test_volumes.py
test_01_create_volume | Success | 438.17 | test_volumes.py
test_03_delete_vm_snapshots | Success | 280.37 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 222.04 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 101.38 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 319.05 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 27.16 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.21 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 67.59 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.23 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 15.71 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 20.33 | test_vm_life_cycle.py
test_02_start_vm | Success | 25.37 | test_vm_life_cycle.py
test_01_stop_vm | Success | 30.73 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 136.27 | test_templates.py
test_08_list_system_templates | Success | 0.04 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.07 | test_templates.py
test_04_extract_template | Success | 5.21 | test_templates.py
test_03_delete_template | Success | 5.14 | test_templates.py
test_02_edit_template | Success | 90.20 | test_templates.py
test_01_create_template | Success | 65.80 | test_templates.py
test_10_destroy_cpvm | Success | 196.78 | test_ssvm.py
test_09_destroy_ssvm | Success | 229.46 | test_ssvm.py
test_08_reboot_cpvm | Success | 121.83 | test_ssvm.py
test_07_reboot_ssvm | Success | 154.08 | test_ssvm.py
test_06_stop_cpvm | Success | 166.87 | test_ssvm.py
test_05_stop_ssvm | Success | 169.08 | test_ssvm.py
test_04_cpvm_internals | Success | 1.12 | test_ssvm.py
test_03_ssvm_internals | Success | 3.48 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.17 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.15 | test_ssvm.py
test_01_snapshot_root_disk | Success | 31.68 | test_snapshots.py
test_04_change_offering_small | Success | 96.22 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.05 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.10 | test_service_offerings.py
test_01_create_service_offering | Success | 0.10 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.48 | test_secondary_storage.py
test_01_scale_vm | Success | 5.28 | test_scale_vm.py
test_09_reboot_router | Success | 65.57 | test_routers.py
test_08_start_router | Success | 50.51 | test_routers.py
   

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713093#comment-15713093
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-302


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713055#comment-15713055
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1257
  
@blueorangutan test centos6 vmware-55u3


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713053#comment-15713053
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1257
  
Addressed all the changes suggested and rebased against latest master.
- Used CollectionUtils.isEmpty() as suggested.


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15713008#comment-15713008
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user sureshanaparti commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1257#discussion_r90532049
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
 ---
@@ -138,6 +142,8 @@
 @Inject
 private NetworkModel _netMgr;
 @Inject
+private HostDao _hostDao;
--- End diff --

@rodrigo93 This fix was part of the jira CLOUDSTACK-9175. Maintained the 
same conventions as in this class. The underscore "_" is prepended to all the 
member variables of the class.


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712952#comment-15712952
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1248
  
This PR is no longer valid since #1257 replaces this. Closing...


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712953#comment-15712953
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user sureshanaparti closed the pull request at:

https://github.com/apache/cloudstack/pull/1248


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



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

[jira] [Commented] (CLOUDSTACK-8854) Apple Mac OS/X VM get created without USB controller in ESXi hypervisors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712894#comment-15712894
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8854:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/828
  
Trillian test result (tid-520)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 6
Total time taken: 38128 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr828-t520-vmware-55u3.zip
Test completed. 45 look ok, 4 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 298.90 | 
test_privategw_acl.py
test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 371.24 | 
test_privategw_acl.py
test_02_vpc_privategw_static_routes | `Failure` | 376.41 | 
test_privategw_acl.py
test_isolate_network_password_server | `Failure` | 70.23 | 
test_password_server.py
test_01_vpc_site2site_vpn | `Error` | 534.15 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | `Error` | 759.89 | test_vpc_vpn.py
test_02_redundant_VPC_default_routes | `Error` | 127.73 | 
test_vpc_redundant.py
test_01_vpc_remote_access_vpn | Success | 207.34 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 382.36 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 759.86 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 726.30 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1612.85 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 772.88 | test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1527.91 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 30.97 | test_volumes.py
test_06_download_detached_volume | Success | 60.91 | test_volumes.py
test_05_detach_volume | Success | 100.31 | test_volumes.py
test_04_delete_attached_volume | Success | 20.29 | test_volumes.py
test_03_download_attached_volume | Success | 25.44 | test_volumes.py
test_02_attach_volume | Success | 64.27 | test_volumes.py
test_01_create_volume | Success | 522.40 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.25 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 229.30 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 151.42 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 161.70 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 274.10 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.94 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.19 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 76.48 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.17 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.16 | test_vm_life_cycle.py
test_02_start_vm | Success | 20.27 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.16 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 372.73 | test_templates.py
test_08_list_system_templates | Success | 0.04 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.06 | test_templates.py
test_04_extract_template | Success | 15.27 | test_templates.py
test_03_delete_template | Success | 5.14 | test_templates.py
test_02_edit_template | Success | 90.17 | test_templates.py
test_01_create_template | Success | 287.74 | test_templates.py
test_10_destroy_cpvm | Success | 267.25 | test_ssvm.py
test_09_destroy_ssvm | Success | 239.41 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.82 | test_ssvm.py
test_07_reboot_ssvm | Success | 188.99 | test_ssvm.py
test_06_stop_cpvm | Success | 202.25 | test_ssvm.py
test_05_stop_ssvm | Success | 169.08 | test_ssvm.py
test_04_cpvm_internals | Success | 1.38 | test_ssvm.py
test_03_ssvm_internals | Success | 3.78 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.15 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py
test_01_snapshot_root_disk | Success | 36.61 | test_snapshots.py
test_04_change_offering_small | Success | 127.21 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.09 | test_service_offerings.py
test_01_create_service_offering | Success | 0.12 | test_service_offerings.py
test_02_sys_template_ready | 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712860#comment-15712860
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user sgoeminn commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1579#discussion_r90520113
  
--- Diff: 
plugins/network-elements/nuage-vsp/src/com/cloud/network/resource/NuageVspResourceConfiguration.java
 ---
@@ -0,0 +1,310 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.network.resource;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import javax.naming.ConfigurationException;
+
+import net.nuage.vsp.acs.client.api.model.NuageVspUser;
+import net.nuage.vsp.acs.client.api.model.VspHost;
+import net.nuage.vsp.acs.client.common.NuageVspApiVersion;
+
+import org.apache.commons.lang.builder.ToStringBuilder;
+
+import com.cloud.util.NuageVspUtil;
+
+public class NuageVspResourceConfiguration {
--- End diff --

It's conceptual far more clear with the current class. Furthermore, this 
class is not only a wrapper around a Map but also contains a Builder.


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> 

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712819#comment-15712819
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
Coupled with @rhtyd's explanation, we can merge this PR if the current 
blueorganutan run comes up clean.


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712797#comment-15712797
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/873
  
@abhinandanprateek @murali-reddy @jburwell this may be useful for 4.9/lts, 
would you like to review?


> Allocated percentage of storage can go beyond 100%
> --
>
> Key: CLOUDSTACK-8896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope 
> primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another 
> cluster, the volume is moved to the new cluster and the asking size is zero 
> at this time.
> you can observe logs like below with asking size 0 in the management server 
> logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] 
> (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) 
> (logid:a0a97129) Checking pool: 1 for volume allocation 
> [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 
> 24096276480, askingSize : 0, allocated disable threshold: 0.85



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712761#comment-15712761
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@murali-reddy @rhtyd can you investigate the Travis failures?


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712793#comment-15712793
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/873
  
LGTM. Travis failure was due to an intermittent issue with oobm test, which 
has been fixed now.


> Allocated percentage of storage can go beyond 100%
> --
>
> Key: CLOUDSTACK-8896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope 
> primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another 
> cluster, the volume is moved to the new cluster and the asking size is zero 
> at this time.
> you can observe logs like below with asking size 0 in the management server 
> logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] 
> (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) 
> (logid:a0a97129) Checking pool: 1 for volume allocation 
> [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 
> 24096276480, askingSize : 0, allocated disable threshold: 0.85



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712762#comment-15712762
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@blueorangutan test matrix


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712789#comment-15712789
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@jburwell the issue was with an intermittent test that sometimes fail when 
clocks get skewed in virtualized environment: `  
HypervisorUtilsTest.checkVolumeFileForActivityTest:68 Didn't block long enough, 
expected at least 2000 and got 1003`. I'll try to fix this in a separate PR.

Since, changes are all in integration test specific code. We can merge this 
once it passes, based on the last runs, the failure with private gw is not seen.


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712766#comment-15712766
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712768#comment-15712768
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@jburwell a Trillian-Jenkins matrix job (centos6 mgmt + xs65sp1, centos7 
mgmt + vmware55u3, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712764#comment-15712764
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
@blueorangutan test


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712759#comment-15712759
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-301


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712733#comment-15712733
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user sgoeminn commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1579#discussion_r90510869
  
--- Diff: 
plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/manager/UpdateNuageVspDeviceCommand.java
 ---
@@ -0,0 +1,43 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.agent.api.manager;
+
+import com.cloud.agent.api.Command;
+import com.cloud.network.resource.NuageVspResourceConfiguration;
+
+public class UpdateNuageVspDeviceCommand extends Command {
--- End diff --

We added it.


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for regular user in a shared 
> network with scope=account ... === 

[jira] [Commented] (CLOUDSTACK-9637) Template create from snapshot does not populate vm_template_details

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712728#comment-15712728
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9637:


GitHub user sudhansu7 opened a pull request:

https://github.com/apache/cloudstack/pull/1805

CLOUDSTACK-9637: Template create from snapshot does not populate vm_t…


**ISSUE**

Template create from snapshot does not populate vm_template_details

**REPRO STEPS**
==
1. Register a template A and specify property:
Root disk controller: scsi
NIC adapter type: E1000
Keyboard type: us

2. Create a vm instance from template A

3. Take volume snapshot for vm instance

4. Delete VM instance

5. Switch to "Storage->Snapshots", convert snapshot to a template B

6. Observe template B does not inherit property from template A, the table 
vm_template_details is empty


**SOLUTION**: Retrieve and add source template details to VMTemplateVO.

`Before Fix:

mysql> select id,name,source_template_id from vm_template where id=202; 
+-+++
| id  | name   | source_template_id |
+-+++
| 202 | Debian |   NULL |
+-+++
1 row in set (0.00 sec)

mysql> select * from vm_template_details where template_id=202; 
++-++---+-+
| id | template_id | name   | value | display |
++-++---+-+
|  1 | 202 | keyboard   | us|   1 |
|  2 | 202 | nicAdapter | E1000 |   1 |
|  3 | 202 | rootDiskController | scsi  |   1 |
++-++---+-+
3 rows in set (0.00 sec)

mysql> select id,name,source_template_id from vm_template where 
source_template_id=202;
+-+++
| id  | name   | source_template_id |
+-+++
| 203 | derived-debian |202 |
+-+++
1 row in set (0.00 sec)

mysql> select * from vm_template_details where template_id=203;
Empty set (0.00 sec)


After Fix:

mysql> select id,name,source_template_id from vm_template where 
source_template_id=202;
+-+--++
| id  | name | source_template_id |
+-+--++
| 203 | derived-debian   |202 |
| 204 | debian-derived-after-fix |202 |
+-+--++
2 rows in set (0.00 sec)

mysql> select * from vm_template_details where template_id=204;
++-++---+-+
| id | template_id | name   | value | display |
++-++---+-+
|  4 | 204 | keyboard   | us|   1 |
|  5 | 204 | nicAdapter | E1000 |   1 |
|  6 | 204 | rootDiskController | scsi  |   1 |
++-++---+-+
3 rows in set (0.00 sec)`

**Marvin Test :** test_template_from_snapshot_with_template_details.py

**Result:**
test_01_create_template_snampshot 
(integration.component.test_template_from_snapshot_with_template_details.TestCreateTemplate)
 ... === TestName: test_01_create_template_snampshot | Status : SUCCESS ===
ok

--
Ran 1 test in 864.523s

OK

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sudhansu7/cloudstack CLOUDSTACK-9637

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1805.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1805


commit 9da5a6afe30838ddc82847d15a9bebf4cb4bcb7f
Author: Sudhansu 
Date:   2016-12-01T18:38:12Z

CLOUDSTACK-9637: Template create from snapshot does not populate 
vm_template_details

Summary: Retrieve and add source template details to VMTemplateVO.




> Template create from snapshot does not populate vm_template_details
> ---
>
> Key: CLOUDSTACK-9637
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9637
> Project: 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712729#comment-15712729
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user sgoeminn commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1579#discussion_r90510701
  
--- Diff: 
plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/manager/CleanUpDomainCommand.java
 ---
@@ -0,0 +1,63 @@
+//
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements.  See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership.  The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License.  You may obtain a copy of the License at
+//
+//   http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied.  See the License for the
+// specific language governing permissions and limitations
+// under the License.
+//
+
+package com.cloud.agent.api.manager;
+
+import com.cloud.agent.api.Command;
+import net.nuage.vsp.acs.client.api.model.VspDomainCleanUp;
+
+public class CleanUpDomainCommand extends Command {
+
+private final VspDomainCleanUp _domainCleanUp;
+
+public CleanUpDomainCommand(VspDomainCleanUp domainCleanUp) {
--- End diff --

We added a null check (Preconditions.checkNotNull(domainCleanUp);).


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712725#comment-15712725
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user sgoeminn commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1579#discussion_r90510516
  
--- Diff: 
plugins/network-elements/nuage-vsp/src/com/cloud/network/element/NuageVspElement.java
 ---
@@ -387,41 +400,39 @@ public boolean canEnableIndividualServices() {
 
 @Override
 public boolean destroy(Network network, ReservationContext context) 
throws ConcurrentOperationException, ResourceUnavailableException {
-if (!canHandle(network, Service.Connectivity)) {
-return false;
-}
-
-return true;
+return canHandle(network, Service.Connectivity);
 }
 
 @Override
 public boolean verifyServicesCombination(Set services) {
-// This element can only function in a NuageVsp based
-// SDN network, so Connectivity needs to be present here
-if (!services.contains(Service.Connectivity)) {
-s_logger.warn("Unable to support services combination without 
Connectivity service provided by Nuage VSP.");
-return false;
+final Sets.SetView missingServices = 
Sets.difference(REQUIRED_SERVICES, services);
+final Sets.SetView unsupportedServices = 
Sets.intersection(UNSUPPORTED_SERVICES, services);
+final Sets.SetView wantedServices = 
Sets.intersection(NUAGE_ONLY_SERVICES, new HashSet<>());
+
+if (!missingServices.isEmpty()) {
+throw new UnsupportedServiceException("Provider " + 
Provider.NuageVsp + " requires services: " + missingServices);
 }
 
-if (!services.contains(Service.SourceNat)) {
-s_logger.warn("Unable to support services combination without 
SourceNat service provided by Nuage VSP.");
+if (!unsupportedServices.isEmpty()) {
+// NuageVsp doesn't implement any of these services.
+// So if these services are requested, we can't handle it.
+s_logger.debug("Unable to support services combination. The 
services " + unsupportedServices + " are not supported by Nuage VSP.");
--- End diff --

It's a user action that can cause this logging. We don't want this message 
to show up as a warning in the server logs, because for example it would be 
troublesome for system admins who get notified of each warning.


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712715#comment-15712715
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user sgoeminn commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1579#discussion_r90509963
  
--- Diff: 
plugins/network-elements/nuage-vsp/src/com/cloud/network/element/NuageVspElement.java
 ---
@@ -387,41 +400,39 @@ public boolean canEnableIndividualServices() {
 
 @Override
 public boolean destroy(Network network, ReservationContext context) 
throws ConcurrentOperationException, ResourceUnavailableException {
-if (!canHandle(network, Service.Connectivity)) {
-return false;
-}
-
-return true;
+return canHandle(network, Service.Connectivity);
 }
 
 @Override
 public boolean verifyServicesCombination(Set services) {
--- End diff --

We added a Preconditions.checkNotNull check on services.


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for regular user in a shared 
> network with scope=account ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for a domain admin users in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is 

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712705#comment-15712705
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-300


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712685#comment-15712685
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
Thanks @jburwell I'll get this re-tested against both Travis and Trillian.


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712669#comment-15712669
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712666#comment-15712666
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


GitHub user rhtyd reopened a pull request:

https://github.com/apache/cloudstack/pull/1799

CLOUDSTACK-9632: Upgrade bouncy castle to version 1.55

- Upgrades Maven dependency version to v1.55
- Fixes bountycastle usages and issues
- Adds timeout to jetty/annotation scanning
- Picks up PR #1510 by Daan

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack bcprov-upgrade

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1799.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1799


commit 056f6e6b5e77ad0d6fa9fc98e8795f845b2c5bb0
Author: Rohit Yadav 
Date:   2016-11-30T09:31:28Z

CLOUDSTACK-9632: Upgrade bouncy castle to version 1.55

- Upgrades Maven dependency version to v1.55
- Fixes bountycastle usages and issues
- Adds timeout to jetty/annotation scanning
- Picks up PR #1510 by Daan

Signed-off-by: Rohit Yadav 




> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712668#comment-15712668
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
@blueorangutan package


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712665#comment-15712665
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user rhtyd closed the pull request at:

https://github.com/apache/cloudstack/pull/1799


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712460#comment-15712460
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
Packaging result: ✔centos6 ✖centos7 ✖debian. JID-299


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9618) Load Balancer configuration page does not have "Source" method in the drop down list

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712456#comment-15712456
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9618:


Github user jburwell commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1786#discussion_r90487461
  
--- Diff: 
plugins/network-elements/netscaler/src/com/cloud/network/element/NetscalerElement.java
 ---
@@ -260,7 +264,7 @@ public boolean applyLBRules(Network config, 
List rules) throw
 Map lbCapabilities = new HashMap();
 
 // Specifies that the RoundRobin and Leastconn algorithms are 
supported for load balancing rules
-lbCapabilities.put(Capability.SupportedLBAlgorithms, 
"roundrobin,leastconn");
+lbCapabilities.put(Capability.SupportedLBAlgorithms, 
"roundrobin,leastconn,source");
--- End diff --

The list of strings declared on this line must be sync with the list used 
to validate the algorithm on line 237.  Therefore, please consider extracting 
this list to a constant `ImmutableSet`, `SUPPORTED_ALGORITHMS` in order 
to ensure cohesion between declaration and validation.  With this change, the 
validateLBRule can be re-implemented as follows:

```java
public boolean validateLBRule(Network network, LoadBalancingRule rule) {
Preconditions.checkArgument(network != null, "validateLBRule requires a 
non-null network");
Preconditions.checkArgument(rule != null, "validateLBRule requires a 
non-null rule");

return (canHandle(network, Service.Lb)) : 
SUPPORTED_ALGORITHMS.contains(rule.getAlgorithm()) : true;
}
```

This line can be re-implemented as follows:

```java
lbCapabilities.put(Capability.SupportedLBAlgorithms, 
Joiner.on(",").join(SUPPORTED_ALGORITHMS));
```


> Load Balancer configuration page does not have "Source" method in the drop 
> down list
> 
>
> Key: CLOUDSTACK-9618
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9618
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> If we create an isolated network with NetScaler published service offering 
> for Load balancing service, then the load balancing configuration UI does not 
> show "Source" as one of the supported LB methods in the drop down list. It 
> only shows "Round-Robin" and "LeastConnection" methods in the list. Howerver, 
> It successfully creates LB rule with "Source" as the LB method using API.



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

[jira] [Commented] (CLOUDSTACK-9633) test_snapshot is failing due to incorrect string construction in utils.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712423#comment-15712423
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9633:


Github user mike-tutkowski commented on the issue:

https://github.com/apache/cloudstack/pull/1800
  
Thanks, @rhtyd I've been trying to get test_snapshots.py to fail in my 
environment, but haven't been able to.

I'll let @syed answer your question, Rohit, since that is a change he put 
in.

If we do need/want to change that, let's do it in #1749 as I have that PR 
open to fix a couple issues I found with regards to snapshots on managed 
storage (specifically with regards to storing them on secondary storage, if 
that option is passed into the command).


> test_snapshot is failing due to incorrect string construction in utils.py
> -
>
> Key: CLOUDSTACK-9633
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9633
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.10.0.0
> Environment: https://github.com/apache/cloudstack/pull/1800
>Reporter: Boris Stoyanov
> Fix For: 4.10.0.0
>
>
> When searching for the snapshot vhd on the nfs storage it adds 
> ([name].vhd.vhd) I've removed the extension for xenserver and it passed. 



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

[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712419#comment-15712419
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/873
  
Trillian test result (tid-519)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 27196 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr873-t519-kvm-centos7.zip
Test completed. 46 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_02_redundant_VPC_default_routes | `Failure` | 870.17 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 379.81 
| test_vpc_redundant.py
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | `Failure` | 245.11 | 
test_internal_lb.py
ContextSuite context=TestVPCRedundancy>:teardown | `Error` | 535.18 | 
test_vpc_redundant.py
test_01_vpc_site2site_vpn | Success | 165.81 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 81.27 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 341.36 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 323.55 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 608.23 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 530.07 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1421.98 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 575.32 | test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.60 | test_volumes.py
test_08_resize_volume | Success | 15.36 | test_volumes.py
test_07_resize_fail | Success | 20.47 | test_volumes.py
test_06_download_detached_volume | Success | 15.37 | test_volumes.py
test_05_detach_volume | Success | 100.29 | test_volumes.py
test_04_delete_attached_volume | Success | 10.19 | test_volumes.py
test_03_download_attached_volume | Success | 15.28 | test_volumes.py
test_02_attach_volume | Success | 73.73 | test_volumes.py
test_01_create_volume | Success | 712.51 | test_volumes.py
test_deploy_vm_multiple | Success | 248.44 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.80 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.24 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 40.93 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.12 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.78 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.81 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.17 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.33 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 100.86 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.07 | test_templates.py
test_04_extract_template | Success | 5.17 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.18 | test_templates.py
test_01_create_template | Success | 40.54 | test_templates.py
test_10_destroy_cpvm | Success | 161.54 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.64 | test_ssvm.py
test_08_reboot_cpvm | Success | 131.60 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.63 | test_ssvm.py
test_06_stop_cpvm | Success | 161.76 | test_ssvm.py
test_05_stop_ssvm | Success | 139.47 | test_ssvm.py
test_04_cpvm_internals | Success | 1.17 | test_ssvm.py
test_03_ssvm_internals | Success | 3.45 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.14 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py
test_01_snapshot_root_disk | Success | 16.35 | test_snapshots.py
test_04_change_offering_small | Success | 246.70 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py
test_01_create_service_offering | Success | 0.10 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.13 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py
test_09_reboot_router | Success | 35.30 | test_routers.py
test_08_start_router | Success | 35.30 | test_routers.py
test_07_stop_router | Success | 10.19 | test_routers.py
test_06_router_advanced | 

[jira] [Commented] (CLOUDSTACK-9603) 'concurrent.snapshots.threshold.perhost' does not validate value given

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712407#comment-15712407
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9603:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1776
  
@priyankparihar could you please provide further explanation as to how this 
fix addresses the issue of `concurrent.snapshots.threshold.perhost` not being 
validated?

Also, is there an existing Marvin test case and/or unit test that verifies 
this fix?  If not, could you please add one?


> 'concurrent.snapshots.threshold.perhost' does not validate value given
> --
>
> Key: CLOUDSTACK-9603
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9603
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>Priority: Minor
>
> concurrent.snapshots.threshold.perhost this setting at global and cluster 
> level should accept only integer values. It is accepting string values as 
> well which should be rejected.



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712400#comment-15712400
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@murali-reddy a Jenkins job has been kicked to build packages. I'll keep 
you posted as I make progress.


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712398#comment-15712398
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@blueorangutan package


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9639) Unable to create shared network with vLan isolation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712335#comment-15712335
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9639:


Github user jburwell commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1804#discussion_r90476049
  
--- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java 
---
@@ -3092,8 +3092,12 @@ public Vlan createVlanAndPublicIpRange(final long 
zoneId, final long networkId,
 final String guestNetworkCidr = zone.getGuestNetworkCidr();
 if (guestNetworkCidr != null) {
 if (NetUtils.isNetworksOverlap(newCidr, guestNetworkCidr)) 
{
-throw new InvalidParameterValueException("The new IP 
range you have specified has  overlapped with the guest network in zone: " + 
zone.getName()
-+ ". Please specify a different 
gateway/netmask.");
+// when adding shared network with same cidr of zone 
guest cidr,
+// if the specified vlan is not present in zone, 
physical network, allow to create the network as the isolation is based on VLAN.
+if (_zoneDao.findVnet(zoneId, physicalNetworkId, 
vlanId).size() > 0) {
--- End diff --

Please consider using `isEmpty` rather than a size check to determine 
whether or not a list contains elements.  It is more idiomatic/clear, but less 
error prone.  Also, why isn't this `if` condition combined with the previous 
`if` block and an `&&` operator.


> Unable to create shared network with vLan isolation
> ---
>
> Key: CLOUDSTACK-9639
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9639
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Create shared network fails with error While creating a shared network it 
> fails to create with Error "The new IP range you have specified has 
> overlapped with the guest network in the zone: XYZ. Please specify a 
> different gateway/netmask"
> Steps to Reproduce:
> ===
> Create an isolated network with a subnet eg: 10.1.1.0.24
> Create a shared network with the same subnet but different VLAN, we should 
> observe this issue.
> EXPECTED BEHAVIOR 
> ===
> It shouldn't restrict the creation of guest network's with same subnet as 
> long as they are segmented by VLAN.
> ACTUAL BEHAVIOR 
> 
> It doesn't allow the creation of shared guest networks if there is any 
> isolated guest network using the same subnet although it allows using the 
> same subnet in multiple shared networks.



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

[jira] [Commented] (CLOUDSTACK-9607) Preventing template deletion when template is in use.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712395#comment-15712395
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9607:


Github user jburwell commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1773#discussion_r90481980
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/template/DeleteTemplateCmd.java 
---
@@ -52,6 +52,9 @@
 @Parameter(name = ApiConstants.ZONE_ID, type = CommandType.UUID, 
entityType = ZoneResponse.class, description = "the ID of zone of the template")
 private Long zoneId;
 
+@Parameter(name = ApiConstants.FORCED, type = CommandType.BOOLEAN, 
required = false, description = "Force delete a template.")
--- End diff --

Please add `since` to this annotation to indicate that this parameter is 
available in 4.9+.


> Preventing template deletion when template is in use.
> -
>
> Key: CLOUDSTACK-9607
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9607
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Consider this scenario:
> 1. User launches a VM from Template and keep it running
> 2. Admin logins and deleted that template [CloudPlatform does not check 
> existing / running VM etc. while the deletion is done]
> 3. User resets the VM
> 4. CloudPlatform fails to star the VM as it cannot find the corresponding 
> template.
> It throws error as 
> java.lang.RuntimeException: Job failed due to exception Resource [Host:11] is 
> unreachable: Host 11: Unable to start instance due to can't find ready 
> template: 209 for data center 1
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:113)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495)
> Client is requesting better handing of this scenario. We need to check 
> existing / running VM's when the template is deleted and warn admin about the 
> possible issue that may occur.
> REPRO STEPS
> ==
> 1. Launches a VM from Template and keep it running
> 2. Now delete that template 
> 3. Reset the VM
> 4. CloudPlatform fails to star the VM as it cannot find the corresponding 
> template.
> EXPECTED BEHAVIOR
> ==
> Cloud platform should throw some warning message while the template is 
> deleted if that template is being used by existing / running VM's
> ACTUAL BEHAVIOR
> ==
> Cloud platform does not throw as waring etc.



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

[jira] [Commented] (CLOUDSTACK-9607) Preventing template deletion when template is in use.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712394#comment-15712394
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9607:


Github user jburwell commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1773#discussion_r90480678
  
--- Diff: server/src/com/cloud/template/TemplateManagerImpl.java ---
@@ -1176,6 +1176,23 @@ public boolean deleteTemplate(DeleteTemplateCmd cmd) 
{
 throw new InvalidParameterValueException("unable to find 
template with id " + templateId);
 }
 
+List vmInstanceVOList;
+if(cmd.getZoneId() != null) {
+vmInstanceVOList = 
_vmInstanceDao.listNonExpungedByZoneAndTemplate(cmd.getZoneId(), templateId);
+}
+else {
+vmInstanceVOList = 
_vmInstanceDao.listNonExpungedByTemplate(templateId);
+}
+if(!cmd.isForced() && 
CollectionUtils.isNotEmpty(vmInstanceVOList)) {
+StringBuilder s  = new StringBuilder("Unable to delete 
template with id: " + templateId + " because some VM instances are using it. ");
+for (VMInstanceVO elm : vmInstanceVOList) {
+s.append(elm.getInstanceName() + ", ");
+}
+
+s_logger.warn(s.substring(0,s.length()-2));
+throw new 
InvalidParameterValueException(s.substring(0,s.length()-2));
--- End diff --

Lines 1187-1193 should replaced with the following to be DRY and improve 
clarity:
```java
final String message = String.format("Unable to delete template with id: 
%1$s because VM instances: [%2$s] are using it.",  templateId, 
Joiner.on(",").join(vmInstanceVOList));
s_logger.warn(message);
throw new InvalidParameterValueException(message);
```


> Preventing template deletion when template is in use.
> -
>
> Key: CLOUDSTACK-9607
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9607
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Consider this scenario:
> 1. User launches a VM from Template and keep it running
> 2. Admin logins and deleted that template [CloudPlatform does not check 
> existing / running VM etc. while the deletion is done]
> 3. User resets the VM
> 4. CloudPlatform fails to star the VM as it cannot find the corresponding 
> template.
> It throws error as 
> java.lang.RuntimeException: Job failed due to exception Resource [Host:11] is 
> unreachable: Host 11: Unable to start instance due to can't find ready 
> template: 209 for data center 1
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:113)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495)
> Client is requesting better handing of this scenario. We need to check 
> existing / running VM's when the template is deleted and warn admin about the 
> possible issue that may occur.
> REPRO STEPS
> ==
> 1. Launches a VM from Template and keep it running
> 2. Now delete that template 
> 3. Reset the VM
> 4. CloudPlatform fails to star the VM as it cannot find the corresponding 
> template.
> EXPECTED BEHAVIOR
> ==
> Cloud platform should throw some warning message while the template is 
> deleted if that template is being used by existing / running VM's
> ACTUAL BEHAVIOR
> ==
> Cloud platform does not throw as waring etc.



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712388#comment-15712388
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@murali-reddy agreed that it is extremely unlikely that the code change 
impacts that test case.  However, we know that a failure to cleanup between 
tests can cause failures when they are run together.  Therefore, I would like 
to see this fix passing with #1801 to ensure we don't have one of those 
transitive issues.


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9635) fix test_privategw_acl.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712384#comment-15712384
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9635:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1802
  
@jburwell This PR is not rebased to fix from #1801. This PR is confined to 
test_privategw_acl.py, so no scope of any regression out side of it.


> fix test_privategw_acl.py
> -
>
> Key: CLOUDSTACK-9635
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9635
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.2.0
>
>
> Marvin test cases in test suite test_privategw_acl.py fail intermittently 
> with error 'createprivategateway failed, due to: errorCode: 431, 
> errorText:Network with vlan vlan://549 already exists in zone 1'
> Test cases use a VLAN from the zone VLAN range, to create VPC private 
> gateway. But the VPC private gateway implementation does not book keep the 
> info on op_dc_vent_alloc. So when test case create network they end up using 
> same VLAN, resulting failure of createVpcPrivateGateway



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

[jira] [Commented] (CLOUDSTACK-9632) Upgrade bountycastle to 1.55+

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15712345#comment-15712345
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9632:


Github user jburwell commented on the issue:

https://github.com/apache/cloudstack/pull/1799
  
@rhtyd the Travis build failed due a timeout on one of the workers.  Could 
you please do a force push to trigger a new build?


> Upgrade bountycastle to 1.55+
> -
>
> Key: CLOUDSTACK-9632
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9632
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> Upgrade bountycastle library to latest versions.



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