[jira] [Commented] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9221:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1325#issuecomment-170477896
  
LGTM


> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



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

[jira] [Commented] (CLOUDSTACK-9180) Optimize concurrent VM deployment operation on same network

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9180:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/1251#issuecomment-170488605
  
@pedro-martins By java doc are you referring to adding some comments for 
isRouterDeployed()? Note that this is a private method.
If you look at the unit tests I have added, isRouterDeployed() is getting 
invoked in them. The function invocation count verification ensures that the 
method is called.


> Optimize concurrent VM deployment operation on same network
> ---
>
> Key: CLOUDSTACK-9180
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9180
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.7.0
>
>
> During VM deployment a check is performed to see if VR exists or not. If not 
> it is created - first an entry is allocated in DB for VR and then it is 
> deployed. The allocation logic is placed in a lock (based on network id) so 
> that only one thread does the allocation. But the locking is implemented in a 
> way such that all threads wait on that lock even when VR is already 
> allocated. The correct approach would be to check if VR is allocated or not 
> and acquire lock only when needed.
> This issue is more frequently seen when concurrently deploying VMs in basic 
> zone as all threads try to acquire lock using the same network id. In 
> advanced zone operations are spread across multiple networks and so less 
> frequent.
> Refer to findOrDeployVirtualRouter() in RouterDeploymentDefinition.java.



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

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9154:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1277#issuecomment-170508275
  
Hi @koushik-das 

Your questions were rhetorical and hence not valid because I did not 
disagree with you in terms of refactor. I asked you to help testing, which you 
partially did. But not having a test environment and relying on a simulator for 
everything seems a bit naive for me. You might remember that we had many 
problems when people did LGTM PRs based on the Travis results, which are not 
reliable.

As I wrote on Saturday, I was going to test again - with the changes - and 
post the result, which I did. I will now retest in a clean DC without the 
commit - GC related -  and post the results. We all expect it to pass, of 
course. But if it doesn't we need to find out why the "agnostic" nature of the 
implementation is broken.

We could talk for hours and disagree only on things being agnostic within 
ACS. I have a few cases in my sleeve. But let's not start again.

Don't give up and say it's useless. At the end we will learn something 
anyway, even from rants on github.

By the way, the ```smoke/test_routers.py``` tests were executed by 
@remibergsma as well.

Cheers,
Wilder


> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 

[jira] [Commented] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9221:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/1325#issuecomment-170458897
  
LGTM


> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



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

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9154:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/1277#issuecomment-170483420
  
@wilderrodrigues My questions and comments are very valid. If you don't see 
any value in them too bad. Looks like you don't want to understand the point I 
am trying to make. Here is some more data if you are really interested. I also 
don't have time for the useless comments you are making.

There is a set of VR tests which validates network gc (check out 
test/integration/component/test_routers.py). I ran it on latest master (without 
any PRs) using a simulator setup and it worked as expected.

nosetests-2.7 --with-marvin --marvin-config=setup/dev/advanced.cfg   
--with-xunit  --xunit-file=out.xml  
test/integration/component/test_routers.py:TestRouterServices -a 
tags=advanced,required_hardware=false  --zone=Sandbox-simulator  
--hypervisor=simulator

Test advanced zone router services ... === TestName: 
test_01_AdvancedZoneRouterServices | Status : SUCCESS ===
ok
Test network garbage collection ... === TestName: 
test_02_NetworkGarbageCollection | Status : SUCCESS ===
ok
Test router start on VM deploy ... === TestName: 
test_03_RouterStartOnVmDeploy | Status : SUCCESS ===
ok

--
Ran 3 tests in 150.061s

OK




> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": 

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9220:


Github user borisroman commented on the pull request:

https://github.com/apache/cloudstack/pull/1327#issuecomment-170505131
  
It's sorted! LGTM

![screen shot 2016-01-11 at 11 45 
06](https://cloud.githubusercontent.com/assets/5996146/12231567/d518d86e-b858-11e5-979e-fbdb3035a3f6.png)



> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9132:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1319#issuecomment-170825451
  
@mike-tutkowski : Yes, we decided to make random name as a preferred 
solution. You can refer the detail conversation on this PR #1273 . Thanks for 
reviewing. 


> API createVolume takes empty string for name parameter
> --
>
> Key: CLOUDSTACK-9132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9132
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nitin Kumar Maharana
>
> Steps to Reproduce:
> 
> Create a volume using createVolume API where parameter name is empty.
> It creates a volume with empty name.
> But the name parameter is mandatory.(Issue)
> Expected Behaviour:
> 
> It shouldn't create a volume with an empty name. Error should be returned.



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

[jira] [Created] (CLOUDSTACK-9224) XenServer local storage added multiple times

[Mike Tutkowski (JIRA)]

Mike Tutkowski created CLOUDSTACK-9224:
--

 Summary: XenServer local storage added multiple times
 Key: CLOUDSTACK-9224
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9224
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2, 4.8.0, 4.7.1, 4.7.2
 Environment: XenServer 6.5

Ubuntu 12.04
Reporter: Mike Tutkowski
 Fix For: 4.8.0


>From an e-mail I sent to dev@ on January 8, 2016:

Hi,

Has anyone noticed the following issue?

I create a zone where I use local storage to house my system VMs.

After the system VMs are all started, I sometimes (but rarely) notice that the 
local SR that was used to retrieve the system template remains (as opposed to 
going away once the system VMs have been kicked off).

It doesn't seem to be a big deal until I happen to re-start my management 
server.

At that point, CloudStack sees this local storage that should have gone away, 
but didn't as new local primary storage and adds it as such.

If I go to Infrastructure and Primary Storage, I can see I now have a second 
local primary storage for one of my XenServer hosts.

Has anyone seen this issue before?

What I've done at this point is simply remove the new primary storage from the 
DB, but I can't (easily) seem to get rid of the extraneous SR.

Thanks!



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

[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9132:


Github user mike-tutkowski commented on the pull request:

https://github.com/apache/cloudstack/pull/1319#issuecomment-170804399
  
Just curious. If this is the expected behavior (mentioned above):

It shouldn't create a volume with an empty name. Error should be returned.

Then it doesn't sound like this PR solves that issue as it generates a 
random name.

Did we decide at some point that a random name was the preferred solution?

Thanks!


> API createVolume takes empty string for name parameter
> --
>
> Key: CLOUDSTACK-9132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9132
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nitin Kumar Maharana
>
> Steps to Reproduce:
> 
> Create a volume using createVolume API where parameter name is empty.
> It creates a volume with empty name.
> But the name parameter is mandatory.(Issue)
> Expected Behaviour:
> 
> It shouldn't create a volume with an empty name. Error should be returned.



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

[jira] [Commented] (CLOUDSTACK-9192) UpdateVpnCustomerGateway is failing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9192:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1300#issuecomment-170801305
  
@kishankavala @koushik-das : Can you please review this. Thanks.


> UpdateVpnCustomerGateway is failing
> ---
>
> Key: CLOUDSTACK-9192
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9192
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Reproducible Steps:
> 
> 1.Create a customer gateway for a VPC.
> 2.Edit it using UI(API call is UpdateVpnCustomerGateway).
> 3.When we try to update the customer vpn gateway with connection state is not 
> in "Error", we see the API error but that won't be reflected to the user in 
> UI.



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

[jira] [Commented] (CLOUDSTACK-9132) API createVolume takes empty string for name parameter

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9132:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/1319#issuecomment-170801193
  
@remibergsma : Any updates on this. Thanks


> API createVolume takes empty string for name parameter
> --
>
> Key: CLOUDSTACK-9132
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9132
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nitin Kumar Maharana
>
> Steps to Reproduce:
> 
> Create a volume using createVolume API where parameter name is empty.
> It creates a volume with empty name.
> But the name parameter is mandatory.(Issue)
> Expected Behaviour:
> 
> It shouldn't create a volume with an empty name. Error should be returned.



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

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9154:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1277#issuecomment-170558660
  
@DaanHoogland @remibergsma @koushik-das 

It worked here without the commit mentioned by @koushik-das .

```
[root@cs1 integration]# less 
/tmp//MarvinLogs/test_vpc_redundant_ABA7FW/results.txt 
Create a redundant VPC with two networks with two VMs in each network ... 
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : 
SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network and 
check default routes ... === TestName: test_02_redundant_VPC_default_routes | 
Status : SUCCESS ===
ok
Create a redundant VPC with two networks with two VMs in each network ... 
=== TestName: 
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Status : 
SUCCESS ===
ok
Create a redundant VPC with 1 Tier, 1 VM, 1 ACL, 1 PF and test Network GC 
Nics ... === TestName: test_04_rvpc_network_garbage_collector_nics | Status : 
SUCCESS ===
ok
Create a redundant VPC with 1 Tier, 1 VM, 1 ACL, 1 PF and test Network GC 
Nics ... === TestName: test_05_rvpc_multi_tiers | Status : SUCCESS ===
ok

--
Ran 5 tests in 6109.473s

OK
/tmp//MarvinLogs/test_vpc_redundant_ABA7FW/results.txt (END)
```

If you think it should be added, I will push the PR without the commit 
21da4cf518fb0d6858d6ce07ab1ead156345995a

Cheers,
Wilder


> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": 

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9154:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/1277#issuecomment-170520102
  
@wilderrodrigues My questions were not in the context of refactor at all. 
The reason for asking the questions was to highlight the point that for testing 
config parameters you don't need real hardware to test. And based on that the 
testing I did was sufficient to verify the specific commit. So you see the 
questions were not rhetorical at all. Based on your comments it looks like you 
never understood what I was trying to say.

About testing with real hardware, it is only needed when you want to verify 
something by actually accessing the VM OR some HV specific scenario needs to be 
tested. For e.g. ssh to VM for validating certain properties of the VM OR 
verifying if some n/w rules etc. are programmed properly in VR. Anything else 
can be run in both real hardware as well as simulator.





> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
>  

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9154:


Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/1277#issuecomment-170535918
  
Let's all move on, @koushik-das. If we don't, we will be talking about this 
for weeks. We have been saying the same thing all the time. I got your points 
and if I could not make it clear, sorry: I could not put more time on writing 
comments here to make it clearer.

The scheduler code is pure Java, it will work even with Unit Tests - not 
even a running management server is needed. Unfortunately, it's been 20 das 
since I create the PR. So, I can't remember what went wrong, that's why I'm 
retesting without the commit. Last time I did, on Saturday, could even be 
something in my environment: that's why I'm doing again in a clean DC.

All the time we wasted typing here could have been used to test the changes 
with[out] the commit you reviewed. Testing against hardware, with the proper 
integration tests. I know when real hardware is needed. However, we don't trust 
the simulator.

If the test passes, do you - representing the community - want my 
contribution or not? If you don't, I will just close the PR because I don't 
want to keep writing here every 20 minutes.

Perhaps saying your questions were rhetorical was not right, but way better 
than using other words. 

Cheers,
Wilder


> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
>  

[jira] [Commented] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9154:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1277#issuecomment-170542781
  
I got two failures. egress and an exception VPC_nics_after_destroy. No time 
to investigate today.

[1277.vpc.results.txt](https://github.com/apache/cloudstack/files/85753/1277.vpc.results.txt)

[1277.network.results.txt](https://github.com/apache/cloudstack/files/85752/1277.network.results.txt)



> rVPC doesn't recover from cleaning up of network garbage collector
> --
>
> Key: CLOUDSTACK-9154
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9154
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.6.0, 4.7.0, 4.6.1, 4.6.2
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time the network garbage collector will come and tear down the 
> network since there are no more VMs
> - keepalived will enter FAULT state because of missing eth2 nic (which was 
> first network tier)
> - all is left is ethic (link local) and lo0
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master
> - the nics are screwed up after this:
> ```
> root@r-1021-VM:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:92 brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.146/16 brd 169.254.255.255 scope global eth0
> 5: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:18:34:00:05 brd ff:ff:ff:ff:ff:ff
> inet x.y.238.24/24 brd x.y.238.255 scope global eth1
> inet 10.0.0.51/24 brd 10.0.0.255 scope global eth1
> inet 10.0.0.1/24 brd 10.0.0.255 scope global secondary eth1
> 6: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:d5:4e:00:00:1d brd ff:ff:ff:ff:ff:ff
> inet x.y.238.25/24 brd x.y.238.255 scope global eth2
> inet 10.0.0.1/24 brd 10.0.0.255 scope global eth2
> root@r-1021-VM:~#
> ```
> Public and tier ip addresses are mixed up.
> /etc/cloudstack/ips.json has the wrong info:
> ```
> { 
>   
>  [44/959]
> "eth0": [
> {
> "add": true,
> "broadcast": "169.254.255.255",
> "cidr": "169.254.2.146/16",
> "device": "eth0",
> "gateway": "None",
> "netmask": "255.255.0.0",
> "network": "169.254.0.0/16",
> "nic_dev_id": "0",
> "nw_type": "control",
> "one_to_one_nat": false,
> "public_ip": "169.254.2.146",
> "size": "16",
> "source_nat": false
> }
> ],
> "eth1": [
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.24/24",
> "device": "eth1",
> "first_i_p": true,
> "gateway": "x.y.238.1",
> "netmask": "255.255.255.0",
> "network": "x.y.238.0/24",
> "new_nic": false,
> "nic_dev_id": 1,
> "nw_type": "public",
> "one_to_one_nat": false,
> "public_ip": "x.y.238.24",
> "size": "24",
> "source_nat": true,
> "vif_mac_address": "06:fc:da:00:00:1c"
> },
> {
> "add": true,
> "broadcast": "10.0.0.255",
> "cidr": "10.0.0.51/24",
> "device": "eth1",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "1",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.51",
> "size": "24",
> "source_nat": false
> }
> ],
> "eth2": [
> {
> "add": false,
> "broadcast": "10.0.0.255",
> 

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

Commit 4b974c599ba7626ca2494609275976721dfd6c36 in cloudstack's branch 
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4b974c5 ]

Merge pull request #1327 from remibergsma/47_sort_domain_list_ui

CLOUDSTACK-9220 Sort list of domains on Domain tab in UIThe list of domains was 
unsorted and that annoyed me so I sorted it :-)

* pr/1327:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI

Signed-off-by: Remi Bergsma 


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9220:


Github user asfgit closed the pull request at:

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


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

Commit 4b974c599ba7626ca2494609275976721dfd6c36 in cloudstack's branch 
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4b974c5 ]

Merge pull request #1327 from remibergsma/47_sort_domain_list_ui

CLOUDSTACK-9220 Sort list of domains on Domain tab in UIThe list of domains was 
unsorted and that annoyed me so I sorted it :-)

* pr/1327:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI

Signed-off-by: Remi Bergsma 


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

Commit 93bbc1afb7986282d6f6ded7ecd373e558f519cc in cloudstack's branch 
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=93bbc1a ]

CLOUDSTACK-9220 Sort list of domains on Domain tab in UI


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

Commit 94c0dc5dfec1d8b20afcbc1e652eb7c9350b4946 in cloudstack's branch 
refs/heads/master from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=94c0dc5 ]

CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.

   - The router code no longer deals with parsing the ALC list again. It's not 
necessary if it's sent in the proper way.


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

Commit 61f3706255b5a658e77014fe7f20acab2707219a in cloudstack's branch 
refs/heads/master from [~wilder.rodrigues]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=61f3706 ]

CLOUDSTACK-9213 - Formatting the code


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1311 from ekholabs/fix/4.7-acl-cidrs-CLOUDSTACK-9213

CLOUDSTACK-9213 - As a user I want to be able to use multiple ip's/cidrs in an 
ACLThis PR fixes a problem with iptables when creating ACL items using a comma 
separated value list of CIDRs. Please refer to the details in the Jira issue.

* pr/1311:
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code

Signed-off-by: Remi Bergsma 


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-8966) listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and CAPACITY_TYPE_CPU

[ASF subversion and git services (JIRA)]

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

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

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

Fix mariadb related listCapacity bug (CLOUDSTACK-8966)

type bigint(20) with type  varchar does not work well on MariaDB
So forcing it to type decimal


> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU
> -
>
> Key: CLOUDSTACK-8966
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8966
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Cloudmonkey, UI
>Affects Versions: 4.3.1, 4.5.1, 4.5.2
> Environment: CloudStack 4.5.1 
> MariaDB 10.0 and 10.1
>Reporter: Francois Scheurer
>
> Dear CloudStack Contributors,
> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU when MariaDB is used instead of MySQL.
> More specifically,
> capacityused is correct.
> capacitytotal is incorrect (null).
> Example:
> (man02-test-admin)  > list capacity type=0 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 16106127360
> percentused = 0
> type = 0
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > list capacity type=1 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 24500
> percentused = 0
> type = 1
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > 
> Analysis:
> The issue is caused by an SQL Query that provide inconsistent result between 
> MySQL and MariaDB.
> cf.  
> http://fossies.org/dox/apache-cloudstack-4.5.2-src/CapacityDaoImpl_8java_source.html#l00418
> MariaDB [cloud]> --not working:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * (select value from cloud.cluster_details 
> where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id),
> -> capacity.capacity_type,
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 
> sum(capacity.used_capacity): 16106127360
>   
> 
> sum(capacity.reserved_capacity): 0
> sum(total_capacity) * (select value from cloud.cluster_details where 
> cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id): NULL
>   
>   
> capacity_type: 0
>   
>  
> data_center_id: 2
>   
>   
>pod_id: 1
>   
>  
> cluster_id: 1
> Possible fixes:
> MariaDB [cloud]> -- working, using a CAST:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * CAST((select value from 
> cloud.cluster_details where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id) AS DECIMAL(10,4)), 
> -> capacity.capacity_type, 
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
>   
>  sum(capacity.used_capacity): 16106127360
>   
>  

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1311 from ekholabs/fix/4.7-acl-cidrs-CLOUDSTACK-9213

CLOUDSTACK-9213 - As a user I want to be able to use multiple ip's/cidrs in an 
ACLThis PR fixes a problem with iptables when creating ACL items using a comma 
separated value list of CIDRs. Please refer to the details in the Jira issue.

* pr/1311:
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code

Signed-off-by: Remi Bergsma 


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1325 from remibergsma/vpc_ui_fix_47

CLOUDSTACK-9221 Allow admin to see user VMs on port forwarding pageOn commit 
a902443708ee10acb9f68fff74af346a6a9fb370 the 'listAll=true' is removed. On some 
places the domainid and accountid are added but not on these. I added them now.

It's either doing this, or readding listAll is true. I've seeing other folks 
doing that so let's see what performs best.

* pr/1325:
  Admin cannot see VMs on port forwarding page

Signed-off-by: Remi Bergsma 


> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



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

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

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

CLOUDSTACK-9220 Sort list of domains on Domain tab in UI


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-8966) listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and CAPACITY_TYPE_CPU

[ASF subversion and git services (JIRA)]

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

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

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

Merge release branch 4.7 to master

* 4.7:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI
  Admin cannot see VMs on port forwarding page
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code


> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU
> -
>
> Key: CLOUDSTACK-8966
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8966
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Cloudmonkey, UI
>Affects Versions: 4.3.1, 4.5.1, 4.5.2
> Environment: CloudStack 4.5.1 
> MariaDB 10.0 and 10.1
>Reporter: Francois Scheurer
>
> Dear CloudStack Contributors,
> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU when MariaDB is used instead of MySQL.
> More specifically,
> capacityused is correct.
> capacitytotal is incorrect (null).
> Example:
> (man02-test-admin)  > list capacity type=0 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 16106127360
> percentused = 0
> type = 0
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > list capacity type=1 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 24500
> percentused = 0
> type = 1
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > 
> Analysis:
> The issue is caused by an SQL Query that provide inconsistent result between 
> MySQL and MariaDB.
> cf.  
> http://fossies.org/dox/apache-cloudstack-4.5.2-src/CapacityDaoImpl_8java_source.html#l00418
> MariaDB [cloud]> --not working:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * (select value from cloud.cluster_details 
> where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id),
> -> capacity.capacity_type,
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 
> sum(capacity.used_capacity): 16106127360
>   
> 
> sum(capacity.reserved_capacity): 0
> sum(total_capacity) * (select value from cloud.cluster_details where 
> cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id): NULL
>   
>   
> capacity_type: 0
>   
>  
> data_center_id: 2
>   
>   
>pod_id: 1
>   
>  
> cluster_id: 1
> Possible fixes:
> MariaDB [cloud]> -- working, using a CAST:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * CAST((select value from 
> cloud.cluster_details where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id) AS DECIMAL(10,4)), 
> -> capacity.capacity_type, 
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
>   

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

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

Merge release branch 4.7 to master

* 4.7:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI
  Admin cannot see VMs on port forwarding page
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-8966) listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and CAPACITY_TYPE_CPU

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1314 from lttmtins/4.7-CLOUDSTACK-8966

Fix mariadb related listCapacity bug (CLOUDSTACK-8966)type bigint(20) with type 
 varchar does not work well on MariaDB
So forcing it to type decimal

* pr/1314:
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)

Signed-off-by: Remi Bergsma 


> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU
> -
>
> Key: CLOUDSTACK-8966
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8966
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Cloudmonkey, UI
>Affects Versions: 4.3.1, 4.5.1, 4.5.2
> Environment: CloudStack 4.5.1 
> MariaDB 10.0 and 10.1
>Reporter: Francois Scheurer
>
> Dear CloudStack Contributors,
> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU when MariaDB is used instead of MySQL.
> More specifically,
> capacityused is correct.
> capacitytotal is incorrect (null).
> Example:
> (man02-test-admin)  > list capacity type=0 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 16106127360
> percentused = 0
> type = 0
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > list capacity type=1 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 24500
> percentused = 0
> type = 1
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > 
> Analysis:
> The issue is caused by an SQL Query that provide inconsistent result between 
> MySQL and MariaDB.
> cf.  
> http://fossies.org/dox/apache-cloudstack-4.5.2-src/CapacityDaoImpl_8java_source.html#l00418
> MariaDB [cloud]> --not working:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * (select value from cloud.cluster_details 
> where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id),
> -> capacity.capacity_type,
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 
> sum(capacity.used_capacity): 16106127360
>   
> 
> sum(capacity.reserved_capacity): 0
> sum(total_capacity) * (select value from cloud.cluster_details where 
> cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id): NULL
>   
>   
> capacity_type: 0
>   
>  
> data_center_id: 2
>   
>   
>pod_id: 1
>   
>  
> cluster_id: 1
> Possible fixes:
> MariaDB [cloud]> -- working, using a CAST:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * CAST((select value from 
> cloud.cluster_details where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id) AS DECIMAL(10,4)), 
> -> capacity.capacity_type, 
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1327 from remibergsma/47_sort_domain_list_ui

CLOUDSTACK-9220 Sort list of domains on Domain tab in UIThe list of domains was 
unsorted and that annoyed me so I sorted it :-)

* pr/1327:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI

Signed-off-by: Remi Bergsma 


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1311 from ekholabs/fix/4.7-acl-cidrs-CLOUDSTACK-9213

CLOUDSTACK-9213 - As a user I want to be able to use multiple ip's/cidrs in an 
ACLThis PR fixes a problem with iptables when creating ACL items using a comma 
separated value list of CIDRs. Please refer to the details in the Jira issue.

* pr/1311:
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code

Signed-off-by: Remi Bergsma 


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1311 from ekholabs/fix/4.7-acl-cidrs-CLOUDSTACK-9213

CLOUDSTACK-9213 - As a user I want to be able to use multiple ip's/cidrs in an 
ACLThis PR fixes a problem with iptables when creating ACL items using a comma 
separated value list of CIDRs. Please refer to the details in the Jira issue.

* pr/1311:
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code

Signed-off-by: Remi Bergsma 


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-8966) listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and CAPACITY_TYPE_CPU

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1314 from lttmtins/4.7-CLOUDSTACK-8966

Fix mariadb related listCapacity bug (CLOUDSTACK-8966)type bigint(20) with type 
 varchar does not work well on MariaDB
So forcing it to type decimal

* pr/1314:
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)

Signed-off-by: Remi Bergsma 


> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU
> -
>
> Key: CLOUDSTACK-8966
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8966
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Cloudmonkey, UI
>Affects Versions: 4.3.1, 4.5.1, 4.5.2
> Environment: CloudStack 4.5.1 
> MariaDB 10.0 and 10.1
>Reporter: Francois Scheurer
>
> Dear CloudStack Contributors,
> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU when MariaDB is used instead of MySQL.
> More specifically,
> capacityused is correct.
> capacitytotal is incorrect (null).
> Example:
> (man02-test-admin)  > list capacity type=0 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 16106127360
> percentused = 0
> type = 0
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > list capacity type=1 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 24500
> percentused = 0
> type = 1
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > 
> Analysis:
> The issue is caused by an SQL Query that provide inconsistent result between 
> MySQL and MariaDB.
> cf.  
> http://fossies.org/dox/apache-cloudstack-4.5.2-src/CapacityDaoImpl_8java_source.html#l00418
> MariaDB [cloud]> --not working:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * (select value from cloud.cluster_details 
> where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id),
> -> capacity.capacity_type,
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 
> sum(capacity.used_capacity): 16106127360
>   
> 
> sum(capacity.reserved_capacity): 0
> sum(total_capacity) * (select value from cloud.cluster_details where 
> cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id): NULL
>   
>   
> capacity_type: 0
>   
>  
> data_center_id: 2
>   
>   
>pod_id: 1
>   
>  
> cluster_id: 1
> Possible fixes:
> MariaDB [cloud]> -- working, using a CAST:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * CAST((select value from 
> cloud.cluster_details where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id) AS DECIMAL(10,4)), 
> -> capacity.capacity_type, 
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

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

Merge release branch 4.7 to master

* 4.7:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI
  Admin cannot see VMs on port forwarding page
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-9220) List of domains in Domain tab in UI is not sorted

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1327 from remibergsma/47_sort_domain_list_ui

CLOUDSTACK-9220 Sort list of domains on Domain tab in UIThe list of domains was 
unsorted and that annoyed me so I sorted it :-)

* pr/1327:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI

Signed-off-by: Remi Bergsma 


> List of domains in Domain tab in UI is not sorted
> -
>
> Key: CLOUDSTACK-9220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9220
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> The list of domains in the UI is not sorted which is unhandy when there are 
> large amounts.



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

[jira] [Commented] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[ASF subversion and git services (JIRA)]

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

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

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

Merge release branch 4.7 to master

* 4.7:
  CLOUDSTACK-9220 Sort list of domains on Domain tab in UI
  Admin cannot see VMs on port forwarding page
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)
  CLOUDSTACK-9213 - Split the ACL rules using comma instead of dash.
  CLOUDSTACK-9213 - Formatting the code


> As a user I want to be able to use multiple ip's/cidrs in an ACL
> 
>
> Key: CLOUDSTACK-9213
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9213
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0, 4.7.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.2
>
>
> If you add multiple cidrs, separated by comma when adding acl item, this 
> doesn't work. Used to work in 4.4 and supported by iptables. 
> This is an supported command, but CloudStack sends it in the wrong way:
> Example:
>  "eth3": {
> "device": "eth3",
> "egress_rules": [
> {
> "allowed": true,
> "cidr": "0.0.0.0/0",
> "first_port": 53,
> "last_port": 53,
> "type": "tcp"
> },
> {
> "allowed": true,
> "cidr": 
> "10.136.70.0/26-10.136.128.128/26-10.136.10.128/26-10.136.3.0/26-10.137.69.0/24-10.136.196.64/26-10.136.224.0/24-10.136.128.64/26-10.136.66.0/26-10.136.5.64/26-10.136.128.0/26-10.137.128.0/24-10.136.69.64/26-10.136.96.0/
> 24-10.136.132.0/26-10.136.75.64/26-10.136.4.0/26-10.136.12.64/26-10.136.10.0/26-10.136.1.0/26-10.136.9.128/26-10.136.226.0/24-10.136.196.0/26-10.136.11.64/26-10.136.32.0/24-10.136.75.0/26-10.136.161.0/24-10.136.98.0/24-10.136.65.128/26-10.136.7
> 2.0/26-10.136.72.128/26-10.136.68.0/26-10.136.65.192/26-10.137.4.0/24-10.136.6.64/26-10.136.67.0/26-10.136.133.64/26-10.136.2.64/26-10.136.102.0/24-10.136.9.64/26-10.136.225.0/24-10.136.101.0/24-10.137.68.0/24-10.136.2.0/26-10.136.5.0/26-10.136
> .11.0/26-10.136.65.64/26-10.137.129.0/24-10.135.6.0/26-10.136.129.0/26-10.136.133.0/26-10.136.72.64/26-10.136.97.0/24-10.136.33.0/24-10.136.64.128/26-10.136.197.0/26-10.136.66.64/26-10.136.160.0/24-10.136.74.0/26-10.136.196.128/26-10.136.64.0/2
> 6-10.136.1.192/26-10.136.192.64/26-10.137.5.0/24-10.135.2.0/26-10.136.130.64/26-10.136.12.0/26-10.136.1.128/26-10.136.132.128/26-10.136.1.64/26-10.136.64.192/26-10.136.73.0/26-10.136.69.0/26-10.136.34.0/24-10.136.73.128/26-10.136.100.0/24-10.13
> 6.38.0/24-10.135.3.0/26-10.136.65.0/26-10.136.10.64/26-10.136.6.0/26-10.136.131.0/26-10.136.194.64/26-10.136.67.64/26-10.136.7.0/26-10.137.0.0/24-10.136.193.64/26-10.136.197.64/26-10.136.9.0/26-10.136.162.0/24-10.136.4.64/26-10.136.195.0/26-10.
> 136.129.64/26-10.136.36.0/24-10.137.192.0/24-10.136.192.0/26-10.136.68.64/26-10.136.71.0/26-10.137.64.0/24-10.136.74.64/26-10.136.130.0/26-10.135.5.0/26-10.136.132.64/26-10.136.2.192/26-10.136.194.0/26-10.136.128.192/26-10.137.1.0/24-10.136.192
> .128/26-10.136.3.64/26-10.136.8.0/26-10.137.65.0/24-10.136.64.64/26-10.136.192.192/26-10.136.193.0/26-10.137.193.0/24-10.136.2.128/26-10.136.73.64/26-10.136.37.0/24",
> "first_port": 135,
> "last_port": 135,
> "type": "tcp"
> },
> This generates broken iptables commands:
> iptables -t filter -I ACL_INBOUND_eth3 4 -p tcp -s 
> 195.66.90.59/32-195.66.90.65/32 -m tcp --dport 3389 -j ACCEPT
> The '-' should be a comma.



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

[jira] [Commented] (CLOUDSTACK-8966) listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and CAPACITY_TYPE_CPU

[ASF subversion and git services (JIRA)]

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

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

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

Merge pull request #1314 from lttmtins/4.7-CLOUDSTACK-8966

Fix mariadb related listCapacity bug (CLOUDSTACK-8966)type bigint(20) with type 
 varchar does not work well on MariaDB
So forcing it to type decimal

* pr/1314:
  Fix mariadb related listCapacity bug (CLOUDSTACK-8966)

Signed-off-by: Remi Bergsma 


> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU
> -
>
> Key: CLOUDSTACK-8966
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8966
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Cloudmonkey, UI
>Affects Versions: 4.3.1, 4.5.1, 4.5.2
> Environment: CloudStack 4.5.1 
> MariaDB 10.0 and 10.1
>Reporter: Francois Scheurer
>
> Dear CloudStack Contributors,
> listCapacity produces wrong result for CAPACITY_TYPE_MEMORY and 
> CAPACITY_TYPE_CPU when MariaDB is used instead of MySQL.
> More specifically,
> capacityused is correct.
> capacitytotal is incorrect (null).
> Example:
> (man02-test-admin)  > list capacity type=0 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 16106127360
> percentused = 0
> type = 0
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > list capacity type=1 listall=true 
> count = 1
> capacity:
> capacitytotal = 0
> capacityused = 24500
> percentused = 0
> type = 1
> zoneid = e683eeaa-92c9-4651-91b9-165939f9000c
> zonename = ZH-EP-Z00
> (man02-test-admin)  > 
> Analysis:
> The issue is caused by an SQL Query that provide inconsistent result between 
> MySQL and MariaDB.
> cf.  
> http://fossies.org/dox/apache-cloudstack-4.5.2-src/CapacityDaoImpl_8java_source.html#l00418
> MariaDB [cloud]> --not working:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * (select value from cloud.cluster_details 
> where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id),
> -> capacity.capacity_type,
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 
> sum(capacity.used_capacity): 16106127360
>   
> 
> sum(capacity.reserved_capacity): 0
> sum(total_capacity) * (select value from cloud.cluster_details where 
> cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id): NULL
>   
>   
> capacity_type: 0
>   
>  
> data_center_id: 2
>   
>   
>pod_id: 1
>   
>  
> cluster_id: 1
> Possible fixes:
> MariaDB [cloud]> -- working, using a CAST:
> MariaDB [cloud]> SELECT sum(capacity.used_capacity), 
> -> sum(capacity.reserved_capacity), 
> -> sum(total_capacity) * CAST((select value from 
> cloud.cluster_details where cluster_details.name='memoryOvercommitRatio' AND 
> cluster_details.cluster_id=capacity.cluster_id) AS DECIMAL(10,4)), 
> -> capacity.capacity_type, 
> -> capacity.data_center_id, 
> -> pod_id, 
> -> cluster_id 
> -> FROM cloud.op_host_capacity capacity WHERE capacity_type=0 \G
> *** 1. row ***
>   
> 

[jira] [Commented] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[ASF subversion and git services (JIRA)]

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

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

Commit 80703ca33c07ef57d80acf816d6db0af803dcb45 in cloudstack's branch 
refs/heads/4.7 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=80703ca ]

Merge pull request #1325 from remibergsma/vpc_ui_fix_47

CLOUDSTACK-9221 Allow admin to see user VMs on port forwarding pageOn commit 
a902443708ee10acb9f68fff74af346a6a9fb370 the 'listAll=true' is removed. On some 
places the domainid and accountid are added but not on these. I added them now.

It's either doing this, or readding listAll is true. I've seeing other folks 
doing that so let's see what performs best.

* pr/1325:
  Admin cannot see VMs on port forwarding page

Signed-off-by: Remi Bergsma 


> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



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

[jira] [Commented] (CLOUDSTACK-9221) Admin cannot see VMs on port forwarding page

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9221:


Github user asfgit closed the pull request at:

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


> Admin cannot see VMs on port forwarding page
> 
>
> Key: CLOUDSTACK-9221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9221
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
> Fix For: 4.7.1
>
>
> When you go to the UI as root admin and go to a VPC of a user, you can see 
> lots of options. However, when you select an IP and want to configure port 
> forwarding, the list of VMs shows ERROR (due to missing parameters). These 
> need to be added.



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

[jira] [Commented] (CLOUDSTACK-9180) Optimize concurrent VM deployment operation on same network

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9180:


Github user pedro-martins commented on the pull request:

https://github.com/apache/cloudstack/pull/1251#issuecomment-170636370
  
A javadoc is a notation above the method declaration that describes what 
the method do.
javadoc with examples :)  
http://www.oracle.com/technetwork/articles/java/index-137868.html

I saw that you create a test for the deployVirtualRouter that uses the 
isRouterDeployed(), but if this test don't pass, will be difficult to analyse 
if the test don't pass because the isRouterDeployed method or another problem.  
:) 

Ty. 


> Optimize concurrent VM deployment operation on same network
> ---
>
> Key: CLOUDSTACK-9180
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9180
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.7.0
>
>
> During VM deployment a check is performed to see if VR exists or not. If not 
> it is created - first an entry is allocated in DB for VR and then it is 
> deployed. The allocation logic is placed in a lock (based on network id) so 
> that only one thread does the allocation. But the locking is implemented in a 
> way such that all threads wait on that lock even when VR is already 
> allocated. The correct approach would be to check if VR is allocated or not 
> and acquire lock only when needed.
> This issue is more frequently seen when concurrently deploying VMs in basic 
> zone as all threads try to acquire lock using the same network id. In 
> advanced zone operations are spread across multiple networks and so less 
> frequent.
> Refer to findOrDeployVirtualRouter() in RouterDeploymentDefinition.java.



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

[jira] [Created] (CLOUDSTACK-9223) UNMAP XenServer Primary Storage prior to snapshot

[Tim Mackey (JIRA)]

Tim Mackey created CLOUDSTACK-9223:
--

 Summary: UNMAP XenServer Primary Storage prior to snapshot
 Key: CLOUDSTACK-9223
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9223
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Reporter: Tim Mackey


For Syed Mushtaq:

So I was looking around the Swift/S3 integration of SolidFire and did a bunch 
of tests. When I backup a snpashot to Swift, SolidFire uploads the whole 
volume's data instead of just the diff. Also since the SolidFire is unaware of 
any changes that are happening on he FS inside the LUN, it always uploads the 
total number of blocks allocated (instead of actual used space). For example: 
if you have a 100 GB volume, you create a 100 GB file on it. This makes 
SolidFire allocate blocks whose size totals 100GB. Now delete that file so the 
usage in the filesystem is back to 0. However, SolidFire didn't know about that 
deletion so it still keeps 100GB worth of blocks allocated to the volume. Now 
if I take a snapshot and invoke the upload to Swift. SolidFire copies 100GB 
(despite the fact that there is no file currently in the FS). Infact, all 
future snapshots will also copy 100GB worth of data. 



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

[jira] [Created] (CLOUDSTACK-9222) cloud.log is filling up disk space

[Remi Bergsma (JIRA)]

Remi Bergsma created CLOUDSTACK-9222:


 Summary: cloud.log is filling up disk space
 Key: CLOUDSTACK-9222
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9222
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.7.0
Reporter: Remi Bergsma
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.7.1


Delay Compress results in more space usage than needed. Since we have copy 
truncate we don't need it.



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

[jira] [Commented] (CLOUDSTACK-9222) cloud.log is filling up disk space

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9222:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1329#issuecomment-170675145
  
Ping @borisroman @michaelandersen


> cloud.log is filling up disk space
> --
>
> Key: CLOUDSTACK-9222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Delay Compress results in more space usage than needed. Since we have copy 
> truncate we don't need it.



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

[jira] [Commented] (CLOUDSTACK-9222) cloud.log is filling up disk space

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9222:


GitHub user remibergsma opened a pull request:

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

CLOUDSTACK-9222 Prevent cloud.log.1 filling up the disk

Delay Compress results in more space usage than needed. Since we have copy 
truncate we don't need it.

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

$ git pull https://github.com/remibergsma/cloudstack delay_compress_fix

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

https://github.com/apache/cloudstack/pull/1329.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 #1329


commit 867be4145db382d67945a3b1ff05c2a4816b0e64
Author: Remi Bergsma 
Date:   2016-01-11T20:09:08Z

CLOUDSTACK-9222 Prevent cloud.log.1 filling up the disk

Delay Compress results in more space usage than needed. Since we have copy 
truncate we don't need it.




> cloud.log is filling up disk space
> --
>
> Key: CLOUDSTACK-9222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.7.0
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.1
>
>
> Delay Compress results in more space usage than needed. Since we have copy 
> truncate we don't need it.



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