[jira] [Commented] (CLOUDSTACK-9287) As an User I want to use Private Gateways with Redundant VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-9287:
--

Hi,



I'm currently on holidays. I will be back at the office on the 10 of August.



Cheers,

Wilder


> As an User I want to use Private Gateways with Redundant VPCs
> -
>
> Key: CLOUDSTACK-9287
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9287
> 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.8.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.10.0
>
>
> Currently we cannot:
> 1. Delete the gateway from a rVPC
> 2. Restart a rVPC that has a private gateway configured
> 3. Have redundancy with private gateway on a rVPC: once master dies the pvt 
> gw is not properly configured in the new master router



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

[jira] [Created] (CLOUDSTACK-9287) As an User I want to use Private Gateways with Redundant VPCs

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9287:


 Summary: As an User I want to use Private Gateways with Redundant 
VPCs
 Key: CLOUDSTACK-9287
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9287
 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.8.0
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
Priority: Critical
 Fix For: 4.9.0


Currently we cannot:

1. Delete the gateway from a rVPC
2. Restart a rVPC that has a private gateway configured
3. Have redundancy with private gateway on a rVPC: once master dies the pvt gw 
is not properly configured in the new master router



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

[jira] [Closed] (CLOUDSTACK-9246) As a Developer I want a more reliable RVR/rVPC tests

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues closed CLOUDSTACK-9246.

Resolution: Won't Fix

The problem I was facing was related to an environment issue. So, the tests do 
not need longer timeouts.

> As a Developer I want a more reliable RVR/rVPC tests 
> -
>
> Key: CLOUDSTACK-9246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9246
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> When running the smoke/test_routers_network_ops.py, sometimes the RVR tests 
> fail due to timeout issues. The current tests have a timeout of 1 second for 
> the wget command, which seems to be not enough.
> The same happens to smoke/test_vpc_redundant -> 
> test_04_rvpc_network_garbage_collector_nics. The GC thread runs and send the 
> command to clean up the guest network, however the command gets queued and 
> takes some time to be executed. The test timeout has to be increased in order 
> to cope with that.



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

[jira] [Updated] (CLOUDSTACK-9246) As a Developer I want a more reliable RVR/rVPC tests

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9246:
-
Summary: As a Developer I want a more reliable RVR/rVPC tests   (was: As a 
Developer I want a more reliable RVR in/egress tests )

> As a Developer I want a more reliable RVR/rVPC tests 
> -
>
> Key: CLOUDSTACK-9246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9246
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> When running the smoke/test_routers_network_ops.py, sometimes the RVR tests 
> fail due to timeout issues. The current tests have a timeout of 1 second for 
> the wget command, which seems to be not enough.



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

[jira] [Updated] (CLOUDSTACK-9246) As a Developer I want a more reliable RVR/rVPC tests

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9246:
-
Description: 
When running the smoke/test_routers_network_ops.py, sometimes the RVR tests 
fail due to timeout issues. The current tests have a timeout of 1 second for 
the wget command, which seems to be not enough.

The same happens to smoke/test_vpc_redundant -> 
test_04_rvpc_network_garbage_collector_nics. The GC thread runs and send the 
command to clean up the guest network, however the command gets queued and 
takes some time to be executed. The test timeout has to be increased in order 
to cope with that.

  was:When running the smoke/test_routers_network_ops.py, sometimes the RVR 
tests fail due to timeout issues. The current tests have a timeout of 1 second 
for the wget command, which seems to be not enough.


> As a Developer I want a more reliable RVR/rVPC tests 
> -
>
> Key: CLOUDSTACK-9246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9246
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> When running the smoke/test_routers_network_ops.py, sometimes the RVR tests 
> fail due to timeout issues. The current tests have a timeout of 1 second for 
> the wget command, which seems to be not enough.
> The same happens to smoke/test_vpc_redundant -> 
> test_04_rvpc_network_garbage_collector_nics. The GC thread runs and send the 
> command to clean up the guest network, however the command gets queued and 
> takes some time to be executed. The test timeout has to be increased in order 
> to cope with that.



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

[jira] [Created] (CLOUDSTACK-9245) As an User I want to be able to delete non-attached ACL lists that contain items

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9245:


 Summary: As an User I want to be able to delete non-attached ACL 
lists that contain items
 Key: CLOUDSTACK-9245
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9245
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VPC
Affects Versions: 4.6.0, 4.5.0, 4.7.0
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
 Fix For: 4.7.1


Create a VPC, add a network, create an ACL, add items to the ACL, attached the 
ACL to the network.

Trying to delete it should fail, and it actually does. That's expected.

Now detach the ACL from the network, delete the network, try to delete the ACL. 
It fails because the ACL contains item.

If we delete the VPC, the ACL is also deleted. We want to simply delete the ACL 
and its items in one go.



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

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reopened CLOUDSTACK-9154:
--

Wrong issue. This was actually a problem and has been fixed

> 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
>

[jira] [Closed] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues closed CLOUDSTACK-9188.

Resolution: Not A Problem

The GC interval was being loaded correctly. When I executed the tests without 
these changes, the test broken. Later I found out it was environment related.

> NetworkGarbageCollector is not using gc.interval and gc.wait from settings
> --
>
> Key: CLOUDSTACK-9188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.7.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.1
>
>
> The settings are bing used from local object and not retrieving what has been 
> saved in the DB.
> From lines  to 3336:
> public static final ConfigKey NetworkGcWait = new 
> ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600",
> "Time (in seconds) to wait before shutting down a network that's 
> not in used", false, Scope.Global, null);
> public static final ConfigKey NetworkGcInterval = new 
> ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600",
> "Seconds to wait before checking for networks to shutdown", true, 
> Scope.Global, null);



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

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9154.
--
Resolution: Fixed

merged

> 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
>

[jira] [Resolved] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9187.
--
Resolution: Fixed

merged

> rVPC routers in Master/Master due to concurrency problem when writing the 
> keepalivd.conf
> 
>
> Key: CLOUDSTACK-9187
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
> 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
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth3
> virtual_router_id 51
> ```
> and this is r-518-VM:
> cat /etc/keepalived/keepalived.conf
> ```
> vrrp_instance inside_network {
> state EQUAL
> interface eth4
> virtual_router_id 51
> nopreempt
> ```



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

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues closed CLOUDSTACK-9154.

Resolution: Not A Problem

The GC interval was being loaded correctly. When I executed the tests without 
these changes, the test broken. Later I found out it was environment related.

> 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> 

[jira] [Created] (CLOUDSTACK-9246) As a Developer I want a more reliable RVR in/egress tests

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9246:


 Summary: As a Developer I want a more reliable RVR in/egress tests 
 Key: CLOUDSTACK-9246
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9246
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


When running the smoke/test_routers_network_ops.py, sometimes the RVR tests 
fail due to timeout issues. The current tests have a timeout of 1 second for 
the wget command, which seems to be not enough.



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

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9213.
--
Resolution: Fixed

merged

> 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] [Created] (CLOUDSTACK-9213) As a user I want to be able to use multiple ip's/cidrs in an ACL

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9213:


 Summary: 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] [Updated] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network garbage collector

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9154:
-
Fix Version/s: 4.7.1

> 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
> 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
> "broadcast": "x.y.238.255",
> 

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9154:
-
Affects Version/s: 4.6.2
   4.6.1
   4.7.0
   4.6.0

> 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
> 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
>

[jira] [Updated] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9188:
-
Fix Version/s: 4.7.1

> NetworkGarbageCollector is not using gc.interval and gc.wait from settings
> --
>
> Key: CLOUDSTACK-9188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.7.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.1
>
>
> The settings are bing used from local object and not retrieving what has been 
> saved in the DB.
> From lines  to 3336:
> public static final ConfigKey NetworkGcWait = new 
> ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600",
> "Time (in seconds) to wait before shutting down a network that's 
> not in used", false, Scope.Global, null);
> public static final ConfigKey NetworkGcInterval = new 
> ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600",
> "Seconds to wait before checking for networks to shutdown", true, 
> Scope.Global, null);



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

[jira] [Created] (CLOUDSTACK-9189) rVPC ACL doesn't recover after cleaning up through the NetworkGarbageCollector

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9189:


 Summary: rVPC ACL doesn't recover after cleaning up through the 
NetworkGarbageCollector
 Key: CLOUDSTACK-9189
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9189
 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
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
Priority: Critical
 Fix For: 4.7.1


In order to reproduce this bug quicker is better to change the 
network.gc.interval and gc.wait from 600 seconds to 10 seconds via Global 
Settings and restart your management server.

- deploy a rVPC
- deploy VM in it
- make port forwarding (2nd ip, firewall and such)
- confirm it works
- stop the vm
- after some time (20 seconds * 3 - approximately) the network garbage 
collector will come and tear down the network since there are no more VMs
- all the nics will be fine and the guest nic will be gone. The routers should 
be on BACKUP/BACKUP
- then start the vm again
- the nics get plugged again and keepalived will decide on a new master.
- try to SSH into the VM via the public IP. It will fail

The only way to get it working afain is:

- Replace the network ACL - for example, default allow all
- Try to SSH again and it works fine
- Replace back to your original ACL
- Try to SSH again and it works fine



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

[jira] [Updated] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9188:
-
Affects Version/s: 4.7.0

> NetworkGarbageCollector is not using gc.interval and gc.wait from settings
> --
>
> Key: CLOUDSTACK-9188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.7.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> The settings are bing used from local object and not retrieving what has been 
> saved in the DB.
> From lines  to 3336:
> public static final ConfigKey NetworkGcWait = new 
> ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600",
> "Time (in seconds) to wait before shutting down a network that's 
> not in used", false, Scope.Global, null);
> public static final ConfigKey NetworkGcInterval = new 
> ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600",
> "Seconds to wait before checking for networks to shutdown", true, 
> Scope.Global, null);



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

[jira] [Updated] (CLOUDSTACK-9189) rVPC ACL doesn't recover after cleaning up through the NetworkGarbageCollector

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9189:
-
Affects Version/s: (was: 4.6.2)
   (was: 4.6.1)
   (was: 4.6.0)

> rVPC ACL doesn't recover after cleaning up through the NetworkGarbageCollector
> --
>
> Key: CLOUDSTACK-9189
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9189
> 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: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.7.1
>
>
> In order to reproduce this bug quicker is better to change the 
> network.gc.interval and gc.wait from 600 seconds to 10 seconds via Global 
> Settings and restart your management server.
> - deploy a rVPC
> - deploy VM in it
> - make port forwarding (2nd ip, firewall and such)
> - confirm it works
> - stop the vm
> - after some time (20 seconds * 3 - approximately) the network garbage 
> collector will come and tear down the network since there are no more VMs
> - all the nics will be fine and the guest nic will be gone. The routers 
> should be on BACKUP/BACKUP
> - then start the vm again
> - the nics get plugged again and keepalived will decide on a new master.
> - try to SSH into the VM via the public IP. It will fail
> The only way to get it working afain is:
> - Replace the network ACL - for example, default allow all
> - Try to SSH again and it works fine
> - Replace back to your original ACL
> - Try to SSH again and it works fine



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

[jira] [Created] (CLOUDSTACK-9187) rVPC routers in Master/Master due to concurrency problem when writing the keepalivd.conf

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9187:


 Summary: rVPC routers in Master/Master due to concurrency problem 
when writing the keepalivd.conf
 Key: CLOUDSTACK-9187
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9187
 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
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
Priority: Critical
 Fix For: 4.7.1


cat /etc/keepalived/keepalived.conf
```
vrrp_instance inside_network {
state EQUAL
interface eth3
virtual_router_id 51
```

and this is r-518-VM:
cat /etc/keepalived/keepalived.conf
```
vrrp_instance inside_network {
state EQUAL
interface eth4
virtual_router_id 51
nopreempt
```



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

[jira] [Created] (CLOUDSTACK-9188) NetworkGarbageCollector is not using gc.interval and gc.wait from settings

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9188:


 Summary: NetworkGarbageCollector is not using gc.interval and 
gc.wait from settings
 Key: CLOUDSTACK-9188
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9188
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


The settings are bing used from local object and not retrieving what has been 
saved in the DB.

>From lines  to 3336:

public static final ConfigKey NetworkGcWait = new 
ConfigKey(Integer.class, "network.gc.wait", "Advanced", "600",
"Time (in seconds) to wait before shutting down a network that's 
not in used", false, Scope.Global, null);
public static final ConfigKey NetworkGcInterval = new 
ConfigKey(Integer.class, "network.gc.interval", "Advanced", "600",
"Seconds to wait before checking for networks to shutdown", true, 
Scope.Global, null);



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

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9154:
-
Summary: rVPC doesn't recover from cleaning up of network garbage collector 
 (was: rVPC doesn't recover from cleaning up of network scavenger)

> 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
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>
> - 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 scavenger 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
> 

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9154:
-
Description: 
- 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",
"cidr": "10.0.0.173/24",
"device": "eth2",
"gateway": "10.0.0.1",
"netmask": "255.255.255.0",
"network": "10.0.0.0/24",
"nic_dev_id": "2",
"nw_type": "guest",
"one_to_one_nat": false,
"public_ip": "10.0.0.173",
"size": "24",
"source_nat": false
},
{
"add": true,
"broadcast": "x.y.238.255",
"cidr": "x.y.238.25/24",
"device": "eth2",
"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": 2,
"nw_type": "public",
"one_to_one_nat": false,
"public_ip": "x.y.238.25",
"size": "24",
"source_nat": true,
"vif_mac_address": "06:d5:4e:00:00:1d"
}
],
"id": "ips"
```

Pinging [~wilder.rodrigues]

  was:
- 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 scavenger 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 

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

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-9154:
--

Have you tried restart the VPC with cleanup option ticked?

Looking into it, but just wondering if stopping the VM is necessary.

> 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
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>
> - 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
>  

[jira] [Updated] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9155:
-
Affects Version/s: (was: 4.6.2)

> Log rotate of cloud.log doesn't work properly
> -
>
> Key: CLOUDSTACK-9155
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
> 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
>Reporter: Remi Bergsma
>Priority: Critical
>
> Many processes log into the cloud.log file. When log rotate is called, many 
> of them keep logging to the old inode and fill up the disk like that.
> These have cloud.log open:
> ```
> root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
> apache2
> conntrack
> keepalive
> logger
> passwd_se
> _plutoloa
> _plutorun
> python
> xl2tpd
> ```
> Current log rotate config:
> ```
> /var/log/cloud.log {
> rotate 4
> daily
> size 10M
> missingok
> notifempty
> compress
> delaycompress
> }
> ```
> After log rotate this happens:
> ```
> root@r-996-VM:/etc# lsof | grep cloud.log.1
> _plutorun   767  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> logger  768  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutorun   772  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutoloa   773  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> xl2tpd  843  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  854  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  863  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  871  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> ```



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

[jira] [Assigned] (CLOUDSTACK-9154) rVPC doesn't recover from cleaning up of network scavenger

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-9154:


Assignee: Wilder Rodrigues

> rVPC doesn't recover from cleaning up of network scavenger
> --
>
> 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
> Environment: ACS 4.7
>Reporter: Remi Bergsma
>Assignee: Wilder Rodrigues
>
> - 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 scavenger 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",
> "cidr": "10.0.0.173/24",
> "device": "eth2",
> "gateway": "10.0.0.1",
> "netmask": "255.255.255.0",
> "network": "10.0.0.0/24",
> "nic_dev_id": "2",
> "nw_type": "guest",
> "one_to_one_nat": false,
> "public_ip": "10.0.0.173",
> "size": "24",
> "source_nat": false
> },
> {
> "add": true,
> "broadcast": "x.y.238.255",
> "cidr": "x.y.238.25/24",
> "device": "eth2",
> "first_i_p": 

[jira] [Updated] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9155:
-
Assignee: Remi Bergsma

> Log rotate of cloud.log doesn't work properly
> -
>
> Key: CLOUDSTACK-9155
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
> 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
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0, 4.6.2
>
>
> Many processes log into the cloud.log file. When log rotate is called, many 
> of them keep logging to the old inode and fill up the disk like that.
> These have cloud.log open:
> ```
> root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
> apache2
> conntrack
> keepalive
> logger
> passwd_se
> _plutoloa
> _plutorun
> python
> xl2tpd
> ```
> Current log rotate config:
> ```
> /var/log/cloud.log {
> rotate 4
> daily
> size 10M
> missingok
> notifempty
> compress
> delaycompress
> }
> ```
> After log rotate this happens:
> ```
> root@r-996-VM:/etc# lsof | grep cloud.log.1
> _plutorun   767  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> logger  768  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutorun   772  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutoloa   773  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> xl2tpd  843  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  854  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  863  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  871  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> ```



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

[jira] [Updated] (CLOUDSTACK-9155) Log rotate of cloud.log doesn't work properly

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9155:
-
Fix Version/s: 4.6.2
   4.7.0

> Log rotate of cloud.log doesn't work properly
> -
>
> Key: CLOUDSTACK-9155
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9155
> 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
>Reporter: Remi Bergsma
>Priority: Critical
> Fix For: 4.7.0, 4.6.2
>
>
> Many processes log into the cloud.log file. When log rotate is called, many 
> of them keep logging to the old inode and fill up the disk like that.
> These have cloud.log open:
> ```
> root@r-1023-VM:~# lsof| grep cloud | awk {'print $1'} | sort -u
> apache2
> conntrack
> keepalive
> logger
> passwd_se
> _plutoloa
> _plutorun
> python
> xl2tpd
> ```
> Current log rotate config:
> ```
> /var/log/cloud.log {
> rotate 4
> daily
> size 10M
> missingok
> notifempty
> compress
> delaycompress
> }
> ```
> After log rotate this happens:
> ```
> root@r-996-VM:/etc# lsof | grep cloud.log.1
> _plutorun   767  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> logger  768  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutorun   772  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> _plutoloa   773  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> xl2tpd  843  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  854  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   860  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  863  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root1w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root2w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> passwd_se   869  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> python  871  root3w  REG 202,10 26054919  
>71 /var/log/cloud.log.1
> ```



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

[jira] [Resolved] (CLOUDSTACK-4374) As a Developer I want to have HA enabled for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-4374.
--
Resolution: Fixed

Done, tested and merged!

> As a Developer I want to have HA enabled for routers that are part or a 
> redundant network or VPC
> 
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Resolved] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9138.
--
Resolution: Fixed

fixed, tested and merged.

> As a Developer I want the createVpcOffering to allow multiple provider per 
> service
> --
>
> Key: CLOUDSTACK-9138
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The default offerings already have multiple providers per service (e.g. Lb 
> with VpcRouterProvider and InternalLbVm)
> It's very important that we can do the same from a developer/user point of 
> view.



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

[jira] [Resolved] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9135.
--
Resolution: Fixed

fixed, tested and merged.

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The current test covers only single VPCs, we have to extend it.



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

[jira] [Created] (CLOUDSTACK-9151) As a Developer I want the VRID to be set within the limits of KeepaliveD

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9151:


 Summary: As a Developer I want the VRID to be set within the 
limits of KeepaliveD
 Key: CLOUDSTACK-9151
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9151
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VPC, Virtual Router
Affects Versions: 4.6.0, 4.6.1
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
Priority: Blocker
 Fix For: 4.7.0, 4.6.2


Dec 12 14:36:10 r-996-VM Keepalived_vrrp[28477]: VRRP Error : VRID not valid !
Dec 12 14:36:10 r-996-VM Keepalived_vrrp[28477]:  must be between 1 
& 255. reconfigure !

​[3:38] 
inside the /etc/keepalived/keepalived.conf

​[3:38] 
vrrp_instance inside_network {
  state EQUAL
  interface eth4
  virtual_router_id 459

​[3:43]


The current code uses the VPC ID as VRID, but it doesn't have to be unique per 
VPC, but for NIC. So, we can simply use 51, as the KeepaliveD suggests.

# arbitary unique number 0..255 # used to differentiate multiple instances of 
vrrpd # running on the same NIC (and hence same socket). virtual_router_id 51



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

[jira] [Updated] (CLOUDSTACK-4374) As a Developer I want to have HA enabled for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Summary: As a Developer I want to have HA enabled for routers that are part 
or a redundant network or VPC  (was: Enable HA for routers that are part or a 
redundant network or VPC)

> As a Developer I want to have HA enabled for routers that are part or a 
> redundant network or VPC
> 
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Fix Version/s: (was: 4.6.2)

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Updated] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9138:
-
Fix Version/s: (was: 4.6.2)

> As a Developer I want the createVpcOffering to allow multiple provider per 
> service
> --
>
> Key: CLOUDSTACK-9138
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The default offerings already have multiple providers per service (e.g. Lb 
> with VpcRouterProvider and InternalLbVm)
> It's very important that we can do the same from a developer/user point of 
> view.



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

[jira] [Resolved] (CLOUDSTACK-9067) As I developer I want to remove all the unused router-shell scripts from ACS

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9067.
--
Resolution: Fixed

PR merged

> As I developer I want to remove all the unused router-shell scripts from ACS
> 
>
> Key: CLOUDSTACK-9067
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9067
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




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

[jira] [Resolved] (CLOUDSTACK-9118) As a Developer I want the checkrouter.sh script to report the right information about RVR routers state

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9118.
--
Resolution: Fixed

PR merged.

> As a Developer I want the checkrouter.sh script to report the right 
> information about RVR routers state
> ---
>
> Key: CLOUDSTACK-9118
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9118
> 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.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> The routers are working properly, as BACK and MASTER, but the checkrouter.sh 
> script is not working properly and show both router as MASTER.
> The script is working fine for rVPC routers.



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

[jira] [Resolved] (CLOUDSTACK-8822) Replace Runnable by Callable in the com.cloud.utils.nio.Task class.

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-8822.
--
Resolution: Fixed

PR merged.

> Replace Runnable by Callable in the com.cloud.utils.nio.Task class.
> ---
>
> Key: CLOUDSTACK-8822
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8822
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.6.1
>
>
> The current implementation of the Task abstract class swallows all the 
> exceptions - everything extending Throwable - with only a WARN message.
> The best way to do that is by implementing Callable, which returns a value 
> and also has a "throws Exception" in the call(0 method signature.
> This work will be structural, changing the hierarchy of Task and also its 
> subclasses.



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

[jira] [Resolved] (CLOUDSTACK-9120) As a Developer I want the new component tests to be moved into the smoke directory

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9120.
--
Resolution: Fixed

PR merged.

> As a Developer I want the new component tests to be moved into the smoke 
> directory
> --
>
> Key: CLOUDSTACK-9120
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9120
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Minor
>
> The following tests...
> component/test_routers_network_ops.py
> component/test_vpc_redundant.py
> component/test_router_dhcphosts.py
> component/test_routers_iptables_default_policy
> component/test_vpc_router_nics
> ... should be moved into the smoke directory due to their nature.



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

[jira] [Updated] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9123:
-
Fix Version/s: 4.6.2
   4.7.0

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




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

[jira] [Commented] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-4374:
--

I will fix this.

Redundant Routers is not the same as Haigh Available. What makes a network 
redundant is having 2 routers that are managed by a third part application, for 
instance keepalived. Having a router HA is actually saying that the given 
router will be controlled by the  High Availability monitor. Hence fix any 
problem we might face.

To sum it up: high availability and redundancy are 2 different things, 
conceptually.

Cheers,
Wilder

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Updated] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9135:
-
Fix Version/s: (was: 4.6.2)

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The current test covers only single VPCs, we have to extend it.



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

[jira] [Updated] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9135:
-
Fix Version/s: 4.6.2
   4.7.0

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The current test covers only single VPCs, we have to extend it.



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

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Summary: Enable HA for routers that are part or a redundant network or VPC  
(was: No HA for redundant routers)

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Assigned] (CLOUDSTACK-4374) No HA for redundant routers

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-4374:


Assignee: Wilder Rodrigues

> No HA for redundant routers
> ---
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Affects Version/s: 4.6.1
   4.4.0
   4.5.0
   4.6.0

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Updated] (CLOUDSTACK-4374) Enable HA for routers that are part or a redundant network or VPC

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-4374:
-
Fix Version/s: 4.6.2
   4.7.0

> Enable HA for routers that are part or a redundant network or VPC
> -
>
> Key: CLOUDSTACK-4374
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4374
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.1.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1
>Reporter: Roeland Kuipers
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> We provide redundant routers with HA functionality through a special service 
> offering.
> However these router pairs are provisioned with ha_enabled=0, so when one or 
> both of them fail they will never be restarted by CS. 
> 2013-08-16 15:51:16,101 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
> (HA-Worker-0:work-4335) VM is not HA enabled so we're done.
> This is currently hardcoded in VirtualNetworkApplianceManagerImpl.java @ 1633
>boolean offerHA = routerOffering.getOfferHA();
> /* We don't provide HA to redundant router VMs, admin should 
> own it all, and redundant router themselves are HA */
> if (isRedundant) {
> offerHA = false;
> }
> We like redundancy and like to have HA on our redundant routers. We like to 
> configure this ourselves through service offerings and do not like being helt 
> hostage by these lines of codes:) We do like to own it all in our admin role 
> :)
> Besides this, this is also very counter-intuitive as we were expecting HA on 
> our redundant routers, since it was configured on their service offering.
> So can we get rid of these lines of code? And have this controlled through 
> service offerings as it should IMHO.? Unless this has negative impact which 
> we are not aware off?
> Cheers & Thanks,
> Roeland
> Details of the original commit which injected this code:
> Commit: a269b089ae38d0d04db2fa0f4c8e839480476ddc [a269b08]
> Parents: a2cc66ce41
> Author: Sheng Yang 
> Date: 17 december 2011 03:52:59 CET
> Commit Date: 19 december 2011 22:29:48 CET
> bug 12608: NaaS: Don't shutdown elements if cleanup=false
> We can use the restartNetwork mechanism to recover the disconnected redundant
> router.
> Also disable HA for redundant router. Admin would take responsibilty to 
> recover
> the failure router, because redundant routers themselves are one layer HA.
> status 12608: resolved fixed



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

[jira] [Resolved] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9123.
--
Resolution: Fixed

done and merged!

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




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

[jira] [Updated] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9123:
-
Affects Version/s: 4.6.1
   4.6.0

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>




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

[jira] [Updated] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9135:
-
Affects Version/s: 4.6.1
   4.6.0

> As a Developer I want the test_internal_lb.py to test Redundant VPCs
> 
>
> Key: CLOUDSTACK-9135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0, 4.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> The current test covers only single VPCs, we have to extend it.



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

[jira] [Created] (CLOUDSTACK-9135) As a Developer I want the test_internal_lb.py to test Redundant VPCs

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9135:


 Summary: As a Developer I want the test_internal_lb.py to test 
Redundant VPCs
 Key: CLOUDSTACK-9135
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9135
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


The current test covers only single VPCs, we have to extend it.



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

[jira] [Created] (CLOUDSTACK-9138) As a Developer I want the createVpcOffering to allow multiple provider per service

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9138:


 Summary: As a Developer I want the createVpcOffering to allow 
multiple provider per service
 Key: CLOUDSTACK-9138
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9138
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.6.1
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
 Fix For: 4.7.0, 4.6.2


The default offerings already have multiple providers per service (e.g. Lb with 
VpcRouterProvider and InternalLbVm)

It's very important that we can do the same from a developer/user point of view.



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

[jira] [Updated] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9123:
-
Summary: As a Developer I want the test_internal_lb.py to work with 
multiple hypervisors  (was: As a Developer I want the test_internal_lb.py to 
work with multiple hypervisors and rVPCs)

> As a Developer I want the test_internal_lb.py to work with multiple 
> hypervisors
> ---
>
> Key: CLOUDSTACK-9123
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




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

[jira] [Resolved] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9106.
--
Resolution: Fixed

PR merged.

> As a Developer I want the Redundant VPC private gateway feature fixed
> -
>
> Key: CLOUDSTACK-9106
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106
> 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
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> Bug in BasicNetworkTopology.applyRules() method.



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

[jira] [Created] (CLOUDSTACK-9120) As a Developer I want the new component tests to be moved into the smoke directory

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9120:


 Summary: As a Developer I want the new component tests to be moved 
into the smoke directory
 Key: CLOUDSTACK-9120
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9120
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
Priority: Minor


The following tests...

component/test_routers_network_ops.py
component/test_vpc_redundant.py
component/test_router_dhcphosts.py
component/test_routers_iptables_default_policy
component/test_vpc_router_nics

... should be moved into the smoke directory due to their nature.



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

[jira] [Updated] (CLOUDSTACK-9118) As a Developer I want the checkrouter.sh script to report the right information about RVR routers state

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9118:
-
Fix Version/s: 4.6.2

> As a Developer I want the checkrouter.sh script to report the right 
> information about RVR routers state
> ---
>
> Key: CLOUDSTACK-9118
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9118
> 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.6.1
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0, 4.6.2
>
>
> The routers are working properly, as BACK and MASTER, but the checkrouter.sh 
> script is not working properly and show both router as MASTER.
> The script is working fine for rVPC routers.



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

[jira] [Created] (CLOUDSTACK-9123) As a Developer I want the test_internal_lb.py to work with multiple hypervisors and rVPCs

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9123:


 Summary: As a Developer I want the test_internal_lb.py to work 
with multiple hypervisors and rVPCs
 Key: CLOUDSTACK-9123
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9123
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues






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

[jira] [Created] (CLOUDSTACK-9118) As a Developer I want the checkrouter.sh script to report the right information about RVR routers state

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9118:


 Summary: As a Developer I want the checkrouter.sh script to report 
the right information about RVR routers state
 Key: CLOUDSTACK-9118
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9118
 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.6.1
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
 Fix For: 4.7.0


The routers are working properly, as BACK and MASTER, but the checkrouter.sh 
script is not working properly and show both router as MASTER.

The script is working fine for rVPC routers.



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

[jira] [Created] (CLOUDSTACK-9106) As a Developer I want the Redundant VPC private gateway feature fixed

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9106:


 Summary: As a Developer I want the Redundant VPC private gateway 
feature fixed
 Key: CLOUDSTACK-9106
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9106
 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
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
 Fix For: 4.7.0


Bug in BasicNetworkTopology.applyRules() method.



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

[jira] [Resolved] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9075.
--
Resolution: Fixed

Merged!

> As a Developer I want the Private GW feature fixed on single VPCs
> -
>
> Key: CLOUDSTACK-9075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The Private GW feature is broken since the VR refactor. it should be fixed 
> for single VPCs and more tests should be included in order to cover it as a 
> whole.
> 1. Test Private GW ACL replace
> - existing tests
> 2. Test Private GW connectivity through 2 VPCs
>- New test
> The new test should perform the following steps:
> 1. Create 2 VPCs
> 2. Create 2 Tiers - 1 per VPC
> 3. Deploy 2 VMs - 1 per Tier
> 4. Acquire 2 pub IPs - 1 per VPC
> 5. Create 2 PF rules - 1 per pub IP
> 6. Create 2 ACLs + rules - 1 per VPC
> 7. Assign new ACLs to Tiers
> 8. Create 2 Private GWs - 1 per VPC
> 9. Replace the Pvt GWs ACLs
> 10. Create 2 Static routes - 1 per Pvt GW
> 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2)
> Please note that the Private GWs have to be in the same VLAN.



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

[jira] [Updated] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9075:
-
Affects Version/s: 4.6.0
Fix Version/s: 4.7.0
  Description: 
The Private GW feature is broken since the VR refactor. it should be fixed for 
single VPCs and more tests should be included in order to cover it as a whole.

1. Test Private GW ACL replace
- existing tests
2. Test Private GW connectivity through 2 VPCs
   - New test

The new test should perform the following steps:

1. Create 2 VPCs
2. Create 2 Tiers - 1 per VPC
3. Deploy 2 VMs - 1 per Tier
4. Acquire 2 pub IPs - 1 per VPC
5. Create 2 PF rules - 1 per pub IP
6. Create 2 ACLs + rules - 1 per VPC
7. Assign new ACLs to Tiers
8. Create 2 Private GWs - 1 per VPC
9. Replace the Pvt GWs ACLs
10. Create 2 Static routes - 1 per Pvt GW
11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2)

Please note that the Private GWs have to be in the same VLAN.

> As a Developer I want the Private GW feature fixed on single VPCs
> -
>
> Key: CLOUDSTACK-9075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.7.0
>
>
> The Private GW feature is broken since the VR refactor. it should be fixed 
> for single VPCs and more tests should be included in order to cover it as a 
> whole.
> 1. Test Private GW ACL replace
> - existing tests
> 2. Test Private GW connectivity through 2 VPCs
>- New test
> The new test should perform the following steps:
> 1. Create 2 VPCs
> 2. Create 2 Tiers - 1 per VPC
> 3. Deploy 2 VMs - 1 per Tier
> 4. Acquire 2 pub IPs - 1 per VPC
> 5. Create 2 PF rules - 1 per pub IP
> 6. Create 2 ACLs + rules - 1 per VPC
> 7. Assign new ACLs to Tiers
> 8. Create 2 Private GWs - 1 per VPC
> 9. Replace the Pvt GWs ACLs
> 10. Create 2 Static routes - 1 per Pvt GW
> 11. SSH into VM1 (VPC1) and from there ping VM2 (VPC2)
> Please note that the Private GWs have to be in the same VLAN.



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

[jira] [Updated] (CLOUDSTACK-9075) As a Developer I want the Private GW feature fixed on single VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9075:
-
Summary: As a Developer I want the Private GW feature fixed on single VPCs  
(was: As a Developer I want to have Private GW tests also covering Redundant 
VPCs )

> As a Developer I want the Private GW feature fixed on single VPCs
> -
>
> Key: CLOUDSTACK-9075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




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

[jira] [Updated] (CLOUDSTACK-9075) As a Developer I want to have Private GW tests also covering Redundant VPCs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9075:
-
Issue Type: Bug  (was: Test)

> As a Developer I want to have Private GW tests also covering Redundant VPCs 
> 
>
> Key: CLOUDSTACK-9075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>




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

[jira] [Created] (CLOUDSTACK-9075) As a Developer I want to have Private GW tests also covering Redundant VPCs

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9075:


 Summary: As a Developer I want to have Private GW tests also 
covering Redundant VPCs 
 Key: CLOUDSTACK-9075
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9075
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues






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

[jira] [Created] (CLOUDSTACK-9067) As I developer I want to remove all the unused router-shell scripts from ACS

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9067:


 Summary: As I developer I want to remove all the unused 
router-shell scripts from ACS
 Key: CLOUDSTACK-9067
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9067
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues






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

[jira] [Updated] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9015:
-
Fix Version/s: 4.6.1

> Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
> --
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.1
>
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Updated] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9015:
-
Summary: Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER 
& MASTER  (was: Redundant VPC Virtual Router's state is BACKUP & BACKUP)

> Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
> --
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Created] (CLOUDSTACK-9046) Fix upgrade path from 4.4 and 4.5 to 4.6

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9046:


 Summary: Fix upgrade path from 4.4 and 4.5 to 4.6
 Key: CLOUDSTACK-9046
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Upgrade
Affects Versions: 4.6.0
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
Priority: Blocker
 Fix For: 4.6.0


The code in the Upgrade442to450.java is not generic, as the name suggests, and 
simply configures the whole SystemVM and all the existing Domain VMs to use the 
SystemVM-4.5.0 that was registered. It means that after the upgrade all the 
routers were marked okay, but they were using the old stuff, from 4.5.0. The 
attempt to deploy a new VM was also failing with the following error (on the 
host):


2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-4:null) Exit value is 1
2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-4:null) Traceback (most recent call last):  File 
"/opt/cloud/bin/update_con
fig.py", line 20, in from merge import QueueFile  File 
"/opt/cloud/bin/merge.py", line 23, in import cs_ip  File 
"/opt/cloud/bin/cs_ip.py", lin
e 19, in from netaddr import *ImportError: No module named netaddr

Why that? Because the KVM host has the new systemvm.iso, which contains all the 
new python stuff, but the systemvm template, which installs the Guest OS 
(Debian) is old and does not contain the modules we now need.



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

[jira] [Commented] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-9035:
--

Changed the issue to Critical until We actually know if there is a way to reset 
the passwd on the backup router or not.

Cheers,
Wilder

> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> 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
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



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

[jira] [Assigned] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-9035:


Assignee: Wilder Rodrigues

> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> 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
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



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

[jira] [Updated] (CLOUDSTACK-9035) Password file is stored only with Master when we Reset Password on the VM.

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-9035:
-
Priority: Critical  (was: Blocker)

> Password file is stored only with Master when we Reset Password on the VM.
> --
>
> Key: CLOUDSTACK-9035
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9035
> 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
>Reporter: Bharat Kumar
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> we send the save password command to both the VRs in a rvr enabled network, 
> But the password gets saved only in the master VR. This happens because the 
> password server is not running in the backup. 
> Because of this if someone resets the password of a VM and starts it when the 
> backup becomes master. Then the password of the user VM will not change, 
> because the save password command was not successful.



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

[jira] [Resolved] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-8925.
--
Resolution: Fixed

merged

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Assigned] (CLOUDSTACK-9027) In the default egress allow network with existing egress rules to block traffic, restarting the network breaks the egress rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-9027:


Assignee: Wilder Rodrigues

> In the default egress allow network with existing egress rules to block 
> traffic, restarting the network breaks the egress rules
> ---
>
> Key: CLOUDSTACK-9027
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9027
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Rajani Karuturi
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> This is found while testing PR #1023 
> https://github.com/apache/cloudstack/pull/1023#issuecomment-153605360
> In the default egress allow network, it has an existing egress rule(created 
> earlier from egress tab on network page) to block port 22 and restarting it 
> created a new router without egress chain on the VR.
> when I deleted the rule(from the egress tab on network page) and restarted 
> network, it created new router with egress chain properly configured in the 
> iptables.
> to clear the confusion, I was able to reproduce it with the following steps
> 1. create a new network with default egress allow (network name: 
> egress2_allow)
> 2. launch a vm in the network.
> 3. check that VR came up and running
> 4. ssh to VR and check the iptables.
> 5. verified that iptables FW_EGRESS_RULES chain is present and configured 
> properly.
> 6. test outgoing traffic from user vm created in this network. (ssh and ping 
> were working fine)
> 7. create a egress rule to block port 22 (from the egress rules tab on 
> networks page in UI)
> 8. verified that iptables drop rule is added in FW_EGRESS_RULES chain on VR
> 9. verified that ssh from user vm doesnt work
> 10. restart network and wait till a new VR is created and running
> 11. observe that FW_EGRESS_RULES chain is missing in the iptables on the new 
> VR
> 12. also, ping google.com and ssh doesnt work from user vm



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

[jira] [Created] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9021:


 Summary: test_ssvm is failing due to wrong interface check on 
VMware and HyperV
 Key: CLOUDSTACK-9021
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Affects Versions: 4.6.0
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


In case of VMWare and Hyper-v , linc local is on eth1. So the command in
all the failed tests to verify link local IP should be modified.
"cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
sed \"s/\=/ /g\" | awk '{print $2}'",.

It is using eth0ip. However, it should be eth1ip.



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

[jira] [Resolved] (CLOUDSTACK-9021) test_ssvm is failing due to wrong interface check on VMware and HyperV

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9021.
--
Resolution: Fixed

merged

> test_ssvm is failing due to wrong interface check on VMware and HyperV
> --
>
> Key: CLOUDSTACK-9021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9021
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> In case of VMWare and Hyper-v , linc local is on eth1. So the command in
> all the failed tests to verify link local IP should be modified.
> "cat /var/cache/cloud/cmdline | xargs | sed \"s/ /\\n/g\" | grep eth0ip= |
> sed \"s/\=/ /g\" | awk '{print $2}'",.
> It is using eth0ip. However, it should be eth1ip.



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

[jira] [Comment Edited] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues edited comment on CLOUDSTACK-8925 at 11/2/15 2:00 PM:
---

Hi [~rajanik],

Just deployed 2 VMs, with default egrees false/true. Both the routers have the 
same setup as you said. And in the case of logging messages, got the same:

Router 1:

2015-11-02 13:37:53,105  configure.py add_rule:143 Current ACL IP direction is 
==> egress
2015-11-02 13:37:53,105  configure.py add_rule:163 EGRESS rule configured for 
protocol ==> all, action ==> ACCEPT

Router 2:

2015-11-02 13:39:59,396  configure.py add_rule:143 Current ACL IP direction is 
==> egress
2015-11-02 13:39:59,396  configure.py add_rule:163 EGRESS rule configured for 
protocol ==> all, action ==> ACCEPT

But looking on vmops.log I got:

2015-11-02 13:35:17,724 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-10:ctx-4c95d65e job-33/job-34 ctx-28b12bea) Egress policy 
for the Network
 207 is already defined as Deny. So, no need to default the rule to Allow. 

Will continue investigating.

Cheers,
Wilder


was (Author: wilder.rodrigues):
Hi [~rajanik],

Just deployed 2 VMs, with default egrees false/true. Both the routers have the 
same setup as you said. And in the case of logging messages, got the same:

Router 1:

2015-11-02 13:37:53,105  configure.py add_rule:143 Current ACL IP direction is 
==> egress
2015-11-02 13:37:53,105  configure.py add_rule:163 EGRESS rule configured for 
protocol ==> all, action ==> ACCEPT

Router 2:

2015-11-02 13:39:59,396  configure.py add_rule:143 Current ACL IP direction is 
==> egress
2015-11-02 13:39:59,396  configure.py add_rule:163 EGRESS rule configured for 
protocol ==> all, action ==> ACCEPT

Will apply a fix.

Cheers,
Wilder

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8925:
--

In case we need the state NEW, I added that:

Chain FW_OUTBOUND (1 references)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere state 
RELATED,ESTABLISHED
FW_EGRESS_RULES  all  --  anywhere anywhere state 
NEW,RELATED,ESTABLISHED

Cheers,
Wilder

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8925:
--

Enough said:

VM 1 default egress ALLOW:

# telnet ekholabs.org 80
GET
It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet.

Connection closed by foreign host
# ip addr
1: lo:  mtu 65536 qdisc noqueue 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 02:00:1b:d4:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.161/24 brd 10.1.1.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::1bff:fed4:2/64 scope link 
   valid_lft forever preferred_lft forever
# 

VM 2 default egress DENY:

# telnet ekholabs.org 80
GET
It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet.

Connection closed by foreign host
# ip addr
1: lo:  mtu 65536 qdisc noqueue 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 02:00:48:ac:00:01 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.180/24 brd 10.1.1.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::48ff:feac:1/64 scope link 
   valid_lft forever preferred_lft forever
# 

Time to fix thi!

Cheers,
Wilder

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8925:
--

Hi [~rajanik]

If you create a VM under that network, can the VM talk to the outside world? I 
see the rule clearly, but last time I tried to go outside from a VM in a 
network with default egress to DENY, I had to add an egress rule allowing 
traffic.

I'm deploying a DC to have a look into it.

Cheers,
Wilder

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Comment Edited] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues edited comment on CLOUDSTACK-9015 at 11/3/15 7:58 AM:
---

Hi [~giraffeforestg],

I know how to make it work with workarounds as well: just restarting keepalived 
in one of the routers and it will be fine.

What I found out is that keepalived is being started before the interfaces are 
configured, that’s why there is no advertisement and the thing simply doesn’t 
work. if we start it after the interfaces are fine, it works.

In addition, it works fine with a stop/start, instead of a reboot. there is a 
step that the router does differently when rebooting. And I'm 100% sure it 
works and won't even look at the stop/start case because the 
component/test_vpc_redundant.py already does it. That test has been executed at 
leat 50 times with all the PRs that have been merged in the last month.

Probably the default allow not being used means that keepalived starts, but 
since there is no outgoing traffic, its state gets right. When there is 
outgoing traffic, it breaks because the interfaces are not configured, on both 
sides!

I will try a fix when get to the office. On the "_redundant_on" code, I will 
wait for the interface to become available. Will give it a try and will let you 
know.

Thanks for your reports!

Cheers,
Wilder


was (Author: wilder.rodrigues):
Hi [~giraffeforestg],

I know how to make it work with workarounds as well: just restarting keepalived 
in one of the routers and it will be fine.

What I found out is that keepalived is being started before the interfaces are 
configured, that’s why there is no advertisement and the thing simply doesn’t 
work. if we start it after the interfaces are fine, it works.

In addition, it works fine with a stop/start, instead of a reboot. there is a 
step that the router does differently when rebooting. And I'm 100% sure it 
works and won't even look at the stop/start case because the 
component/test_vpc_redundant.py already does it. That test has been executed at 
leat 50 times with all the PRs that have been merged in the last month.

Probably the default allow not being used means that keepalived starts, but 
since there is no outgoing traffic, its state gets right. When there is 
outgoing traffic, it breaks because the interfaces are not configured, on both 
sides!

I will try a fix when get to the office. On the "set_redundant_on" code, I will 
wait for the interface to become available. Will give it a try and will let you 
know.

Thanks for your reports!

Cheers,
Wilder

> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> 

[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-9015:
--

Hi [~giraffeforestg],

I know how to make it work with workarounds as well: just restarting keepalived 
in one of the routers and it will be fine.

What I found out is that keepalived is being started before the interfaces are 
configured, that’s why there is no advertisement and the thing simply doesn’t 
work. if we start it after the interfaces are fine, it works.

In addition, it works fine with a stop/start, instead of a reboot. there is a 
step that the router does differently when rebooting. And I'm 100% sure it 
works and won't even look at the stop/start case because the 
component/test_vpc_redundant.py already does it. That test has been executed at 
leat 50 times with all the PRs that have been merged in the last month.

Probably the default allow not being used means that keepalived starts, but 
since there is no outgoing traffic, its state gets right. When there is 
outgoing traffic, it breaks because the interfaces are not configured, on both 
sides!

I will try a fix when get to the office. On the "set_redundant_on" code, I will 
wait for the interface to become available. Will give it a try and will let you 
know.

Thanks for your reports!

Cheers,
Wilder

> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Created] (CLOUDSTACK-9018) Egress rule with 0.0.0.0/0 - all (protocol) doesn't get removed from the VR

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9018:


 Summary: Egress rule with 0.0.0.0/0 - all (protocol) doesn't get 
removed from the VR
 Key: CLOUDSTACK-9018
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9018
 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
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


Steps:

1. Deploy a virtual machine on an isolated network with default egress DENY
2. Add egress rules: 0.0.0.0/0 - protocol ALL
3. Check the router

Chain FW_EGRESS_RULES (1 references)
target prot opt source   destination 
ACCEPT all  --  anywhere anywhere
DROP   all  --  anywhere anywhere   

4. Delete the egress rules and check the router again
5. The result is the same: the rule is still there.
6. Try adding the same rule again: 0.0.0.0/0 - protocol ALL
7. Check the router:

Chain FW_EGRESS_RULES (1 references)
target prot opt source   destination   
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere
DROP   all  --  anywhere anywhere   

But if I add something like:

0.0.0.0/0-   tcp-   80   -   80

It works fine! I can remove and add again and the routers remains configured 
properly.



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

[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-9015:
--

This only happens with Rebooting the routers. If we do the same, but using 
stop/start instead, it works fine. I tried several times.

In case we reboot both routers, as explained in the steps above, only a 
"service keepalived restart" will fix it.

root@r-3-VM:~# service keepalived restart
[ ok ] Restarting keepalived keepalived
root@r-3-VM:~# ip addr
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:e3 brd ff:ff:ff:ff:ff:ff
inet 169.254.2.227/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:b1:36:00:00:2b brd ff:ff:ff:ff:ff:ff
inet 192.168.23.53/24 brd 192.168.23.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:5f:9b:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.51/26 brd 10.0.1.63 scope global eth2
inet 10.0.1.1/26 brd 10.0.1.63 scope global secondary eth2
root@r-3-VM:~# 


> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8925:
--

Hi [~rajanik],

Just deployed 2 VMs, with default egrees false/true. Both the routers have the 
same setup as you said. And in the case of logging messages, got the same:

Router 1:

2015-11-02 13:37:53,105  configure.py add_rule:143 Current ACL IP direction is 
==> egress
2015-11-02 13:37:53,105  configure.py add_rule:163 EGRESS rule configured for 
protocol ==> all, action ==> ACCEPT

Router 2:

2015-11-02 13:39:59,396  configure.py add_rule:143 Current ACL IP direction is 
==> egress
2015-11-02 13:39:59,396  configure.py add_rule:163 EGRESS rule configured for 
protocol ==> all, action ==> ACCEPT

Will apply a fix.

Cheers,
Wilder

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Assigned] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-9015:


Assignee: Wilder Rodrigues

> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Assigned] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-8925:


Assignee: Wilder Rodrigues

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Commented] (CLOUDSTACK-8925) Default allow for Egress rules is not being configured properly in VR iptables rules

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8925:
--

I will have a look on Monday.

> Default allow for Egress rules is not being configured properly in VR 
> iptables rules
> 
>
> Key: CLOUDSTACK-8925
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8925
> 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
>Reporter: Pavan Kumar Bandarupally
>Assignee: Wilder Rodrigues
>Priority: Critical
> Fix For: 4.6.0
>
>
> When we create a network with Egress rules set to default allow, the rules 
> created in FW_OUTBOUND table should have a reference to FW_EGRESS_RULES chain 
> which has a rule to accept NEW packets from the guest instances. Without that 
> rule only RELATED , ESTABLISHED rule in FW_OUTBOUND chain will result in Drop 
> of packets.
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
>  pkts bytes target prot opt in out source   
> destination
>44  2832 NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT all  --  eth0   eth10.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state NEW
> 4   336 ACCEPT all  --  eth2   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
> 0 0 ACCEPT all  --  eth0   eth00.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED
>40  2496 FW_OUTBOUND  all  --  eth0   eth20.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 20 packets, 1888 bytes)
>  pkts bytes target prot opt in out source   
> destination
>  2498  369K NETWORK_STATS  all  --  *  *   0.0.0.0/0
> 0.0.0.0/0
> Chain FIREWALL_EGRESS_RULES (0 references)
>  pkts bytes target prot opt in out source   
> destination
> Chain FW_OUTBOUND (1 references)
>  pkts bytes target prot opt in out source   
> destination
> 3   252 ACCEPT all  --  *  *   0.0.0.0/00.0.0.0/0 
>state RELATED,ESTABLISHED



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

[jira] [Resolved] (CLOUDSTACK-9007) Write test to check that the /etc/dhcphosts.txt doesn't contain duplicate IPs

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-9007.
--
Resolution: Fixed

Fixed, tested and merged!

> Write test to check that the /etc/dhcphosts.txt doesn't contain duplicate IPs
> -
>
> Key: CLOUDSTACK-9007
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9007
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
> Fix For: 4.6.0
>
>




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

[jira] [Created] (CLOUDSTACK-9007) Write test to check that the /etc/dhcphosts.txt doesn't contain duplicate IPs

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-9007:


 Summary: Write test to check that the /etc/dhcphosts.txt doesn't 
contain duplicate IPs
 Key: CLOUDSTACK-9007
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9007
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues
 Fix For: 4.6.0






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

[jira] [Commented] (CLOUDSTACK-8957) VR password server broken

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8957:
--

Hi [~nuxro],

The file in cache is no longer empty:

10.1.1.85=saved_password
/var/cache/cloud/passwords-10.1.1.1 (END)

I will now write the Marvin tests to cover that and will let you know once a PR 
is created.

Cheers,
Wilder

> VR password server broken
> -
>
> Key: CLOUDSTACK-8957
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8957
> 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
> Environment: ACS 4.6.0 snapshot, CentOS6 HVs and mgmt
>Reporter: Nux
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> Hello,
> When deploying instances from password enabled templates, the instances do 
> not get the generated passwords.
> The VR logs show something like this:
> 'Oct 15 17:12:27 r-4-VM passwd_server_ip.py: serve_password: requested 
> password not found for 10.1.1.33'
> In /var/cache/cloud the "passwords-10.1.1.1" is empty, but "passwords" is 
> not, I can see the passwords there.
> Symlinking "passwords-10.1.1.1" to "passwords" and restarting the 
> passwd_server_ip script gets the feature working again, though I am not sure 
> how correct this approach is.
>  



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

[jira] [Commented] (CLOUDSTACK-8957) VR password server broken

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues commented on CLOUDSTACK-8957:
--

[~nuxro] [~bhaisaab] [~remibergsma]

Is there any integration test that covers this? I'm about to start testing a 
fix. But, except for looking into the logs, how can I be certain it has been 
fixed

Cheers,
Wilder

> VR password server broken
> -
>
> Key: CLOUDSTACK-8957
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8957
> 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
> Environment: ACS 4.6.0 snapshot, CentOS6 HVs and mgmt
>Reporter: Nux
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> Hello,
> When deploying instances from password enabled templates, the instances do 
> not get the generated passwords.
> The VR logs show something like this:
> 'Oct 15 17:12:27 r-4-VM passwd_server_ip.py: serve_password: requested 
> password not found for 10.1.1.33'
> In /var/cache/cloud the "passwords-10.1.1.1" is empty, but "passwords" is 
> not, I can see the passwords there.
> Symlinking "passwords-10.1.1.1" to "passwords" and restarting the 
> passwd_server_ip script gets the feature working again, though I am not sure 
> how correct this approach is.
>  



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

[jira] [Assigned] (CLOUDSTACK-8957) VR password server broken

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues reassigned CLOUDSTACK-8957:


Assignee: Wilder Rodrigues

> VR password server broken
> -
>
> Key: CLOUDSTACK-8957
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8957
> 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
> Environment: ACS 4.6.0 snapshot, CentOS6 HVs and mgmt
>Reporter: Nux
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> Hello,
> When deploying instances from password enabled templates, the instances do 
> not get the generated passwords.
> The VR logs show something like this:
> 'Oct 15 17:12:27 r-4-VM passwd_server_ip.py: serve_password: requested 
> password not found for 10.1.1.33'
> In /var/cache/cloud the "passwords-10.1.1.1" is empty, but "passwords" is 
> not, I can see the passwords there.
> Symlinking "passwords-10.1.1.1" to "passwords" and restarting the 
> passwd_server_ip script gets the feature working again, though I am not sure 
> how correct this approach is.
>  



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

[jira] [Updated] (CLOUDSTACK-8991) IP address is not removed from VR even after disabling static NAT

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-8991:
-
Priority: Blocker  (was: Critical)

> IP address is not removed from VR even after disabling static NAT
> -
>
> Key: CLOUDSTACK-8991
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8991
> 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
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> Test for port forwarding on source NAT ... === TestName: 
> test_01_port_fwd_on_src_nat | Status : SUCCESS ===
> ok
> Test for port forwarding on non source NAT ... === TestName: 
> test_02_port_fwd_on_non_src_nat | Status : SUCCESS ===
> ok
> Test for reboot router ... === TestName: test_reboot_router | Status : 
> SUCCESS ===
> ok
> Test for Router rules for network rules on acquired public IP ... === 
> TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : 
> FAILED ===
> FAIL
> Test for Router rules for network rules on acquired public IP ... === 
> TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : FAILED 
> ===
> FAIL
> Test for Router rules for network rules on acquired public IP ... === 
> TestName: test_network_rules_acquired_public_ip_3_Load_Balancer_Rule | Status 
> : FAILED ===
> FAIL
> ==
> FAIL: Test for Router rules for network rules on acquired public IP
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ddt.py", line 146, in wrapper
> return func(self, *args, **kwargs)
>   File "/data/git/cs1/cloudstack/test/integration/smoke/test_network.py", 
> line 1248, in test_network_rules_acquired_public_ip
> not removed from VR even after disabling statin NAT")
> AssertionError: IP address isnot removed from VR even after 
> disabling statin NAT



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

[jira] [Updated] (CLOUDSTACK-8935) Cannot remove [r]VPC networks due to RTNETLINK error

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-8935:
-
Summary: Cannot remove [r]VPC networks due to RTNETLINK error  (was: Cannot 
remove rVPC networks due to RTNETLINK error)

> Cannot remove [r]VPC networks due to RTNETLINK error
> 
>
> Key: CLOUDSTACK-8935
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8935
> 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
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Sometimes, when trying to remove a network of a rVPC, I get the following 
> error in the router logs:
> 2015-10-06 08:28:59,929 DEBUG [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-4:null) RTNETLINK answers: File existsRTNETLINK 
> answers: File exists[WARN] update_config.py :: Reconfiguring guest netwo
> rk...[INFO] update_config.py :: Processing Guest Network.[INFO] Processing 
> JSON file guest_network.jsonTraceback (most recent call last):  File 
> "/opt/cloud/bin/update_config.py", line 131, in process_
> file()  File "/opt/cloud/bin/update_config.py", line 54, in process_file
> finish_config()  File "/opt/cloud/bin/update_config.py", line 44, in 
> finish_configreturncode = configure.main([])  File "/opt/cloud/
> bin/configure.py", line 888, in maindhcp.process()  File 
> "/opt/cloud/bin/cs/CsDhcp.py", line 47, in processself.configure_server() 
>  File "/opt/cloud/bin/cs/CsDhcp.py", line 71, in configure_serverline
>  = "dhcp-option=tag:interface-%s,6,%s" % (device, 
> ','.join(gn.get_dns()))TypeError: sequence item 0: expected string, NoneType 
> found
> A way to work this around is:
> 1. Stop and destroy the router(s)
> 2. Remove the network



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

[jira] [Updated] (CLOUDSTACK-8935) Cannot remove rVPC networks due to RTNETLINK error

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues updated CLOUDSTACK-8935:
-
Summary: Cannot remove rVPC networks due to RTNETLINK error  (was: Cannot 
remove VPC networks due to RTNETLINK error)

> Cannot remove rVPC networks due to RTNETLINK error
> --
>
> Key: CLOUDSTACK-8935
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8935
> 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
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Sometimes, when trying to remove a network of a rVPC, I get the following 
> error in the router logs:
> 2015-10-06 08:28:59,929 DEBUG [kvm.resource.LibvirtComputingResource] 
> (agentRequest-Handler-4:null) RTNETLINK answers: File existsRTNETLINK 
> answers: File exists[WARN] update_config.py :: Reconfiguring guest netwo
> rk...[INFO] update_config.py :: Processing Guest Network.[INFO] Processing 
> JSON file guest_network.jsonTraceback (most recent call last):  File 
> "/opt/cloud/bin/update_config.py", line 131, in process_
> file()  File "/opt/cloud/bin/update_config.py", line 54, in process_file
> finish_config()  File "/opt/cloud/bin/update_config.py", line 44, in 
> finish_configreturncode = configure.main([])  File "/opt/cloud/
> bin/configure.py", line 888, in maindhcp.process()  File 
> "/opt/cloud/bin/cs/CsDhcp.py", line 47, in processself.configure_server() 
>  File "/opt/cloud/bin/cs/CsDhcp.py", line 71, in configure_serverline
>  = "dhcp-option=tag:interface-%s,6,%s" % (device, 
> ','.join(gn.get_dns()))TypeError: sequence item 0: expected string, NoneType 
> found
> A way to work this around is:
> 1. Stop and destroy the router(s)
> 2. Remove the network



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

[jira] [Resolved] (CLOUDSTACK-8697) Assign VPC Internal LB rule to a VM fails

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-8697.
--
Resolution: Fixed

Merged!

PR 933

> Assign VPC Internal LB rule to a VM fails
> -
>
> Key: CLOUDSTACK-8697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8697
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.4.4, 4.6.0
>Reporter: Pavan Kumar Bandarupally
>Assignee: Michael Andersen
>Priority: Blocker
> Attachments: MS Log.rar, MSLog.rar
>
>
> Assigning an internal LB rule to a VM inside VPC network fails. Seems to be a 
> configuration issue.
> 
> 2015-07-31 21:13:49,059 ERROR [c.c.u.s.SshHelper] 
> (DirectAgent-345:ctx-2bdddfcc) SSH execution of command 
> /opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.171 
> load_balancer.json has an error status code in return. result output:
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.r.v.VirtualRoutingResource] 
> (DirectAgent-345:ctx-2bdddfcc) Processing ScriptConfigItem, executing 
> update_config.py load_balancer.json took 6656ms
> 2015-07-31 21:13:49,062 WARN  [c.c.a.r.v.VirtualRoutingResource] 
> (DirectAgent-345:ctx-2bdddfcc) Expected 1 answers while executing 
> LoadBalancerConfigCommand but received 2
> 2015-07-31 21:13:49,062 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Response Received:
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request] 
> (DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Processing:  { Ans: 
> , MgmtId: 6702933999656, via: 7, Ver: v1, Flags: 0, 
> [{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - failed: 
> ","null - failed: "],"result":false,"wait":0}}] }
> 2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request] 
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) Seq 
> 7-4435764157983228083: Received:  { Ans: , MgmtId: 6702933999656, via: 7, 
> Ver: v1, Flags: 0, { GroupAnswer } }
> 2015-07-31 21:13:49,133 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] 
> (API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) LB Rollback rule id: 6 
>  while attaching VM: [29]



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

[jira] [Resolved] (CLOUDSTACK-8971) Remove hardcoded configuration from test_privategw_acl

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-8971.
--
Resolution: Fixed

Merged!

> Remove hardcoded configuration from test_privategw_acl
> --
>
> Key: CLOUDSTACK-8971
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8971
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>
> The current test_privategw_acl.py has come hardcoded configuration that makes 
> it not very reliable:
> * self.networkOfferingId = 11
> * self.zoneId = 1
> * self.serviceOfferingId = 1
> * self.templateId = 5
> The current test does not clean up the resources created. This has to be 
> added as well.



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

[jira] [Resolved] (CLOUDSTACK-8952) The redundant routers are facing a race condition due to several KeepaliveD/ConntrackD restarts

[Wilder Rodrigues (JIRA)]

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

Wilder Rodrigues resolved CLOUDSTACK-8952.
--
Resolution: Fixed

Fixed, tested and merged!

> The redundant routers are facing a race condition due to several 
> KeepaliveD/ConntrackD restarts
> ---
>
> Key: CLOUDSTACK-8952
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8952
> 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
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> In the CsRedundant.py we have a line doing:
> proc = CsProcess(['/usr/sbin/keepalived', '--vrrp'])
> However, the CsProcess cannot find a process with the string search "--vrrp", 
> which makes it always return false and restart keepalived.
> Due to the restart, the routers start a race condition to become master, 
> which makes network features unavailable.



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

[jira] [Created] (CLOUDSTACK-8971) Remove hardcoded configuration from test_privategw_acl

[Wilder Rodrigues (JIRA)]

Wilder Rodrigues created CLOUDSTACK-8971:


 Summary: Remove hardcoded configuration from test_privategw_acl
 Key: CLOUDSTACK-8971
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8971
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Reporter: Wilder Rodrigues
Assignee: Wilder Rodrigues


The current test_privategw_acl.py has come hardcoded configuration that makes 
it not very reliable:

* self.networkOfferingId = 11
* self.zoneId = 1
* self.serviceOfferingId = 1
* self.templateId = 5




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