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

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

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

Merge pull request #1577 from nlivens/CLOUDSTACK-9321

CLOUDSTACK-9321 : Multiple Internal LB rules (more than one Internal LB rule 
with same source IP address) are not getting resolved in the corresponding 
InternalLbVm instance's haproxy.cfg fileMultiple Internal LB rules (more than 
one Internal LB rule with same source IP address) are not getting resolved in 
the corresponding InternalLbVm instance's haproxy.cfg file. Moreover, each time 
a new Internal LB rule is added to the corresponding InternalLbVm instance, it 
replaces the existing one. Thus, traffic corresponding to these un-resolved 
(old) Internal LB rules are getting dropped by the InternalLbVm instance.

PR contents:
1) Fix for this bug.
2) Marvin test coverage for Internal LB feature on master with native ACS setup 
(component directory) including validations for this bug fix.
3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
directory) to validate this bug fix.
4) PEP8 & PyFlakes compliance with the added Marvin test code.

* pr/1577:
  CLOUDSTACK-9321 : Multiple Internal LB rules (more than one Internal LB rule 
with same source IP address) are not getting resolved in the corresponding 
InternalLbVm instance's haproxy.cfg file

Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com>


> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9321
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Management Server, Network Controller
>            Reporter: Mani Prashanth Varma Manthena
>            Assignee: Nick Livens
>            Priority: Critical
>             Fix For: 4.9.1.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is 
> added to the corresponding InternalLbVm instance, it replaces the existing 
> one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules 
> are getting dropped by the InternalLbVm instance.
> PR contents:
> 1) Fix for this bug.
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> 4) PEP8 & PyFlakes compliance with the added Marvin test code.
> Added Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pyflakes 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) 
> functionality.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_lbrules.py
> Test results:
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... 
> === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS ===
> ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual 
> networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 214 : Delete few(not all) LB rules for a single virtual network 
> of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS 
> ===
> ok
> Test Delete few(not all) LB rules for a single virtual network of ... === 
> TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS 
> ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that belongs to 
> a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | 
> Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that does not 
> belong to any VPC. ... === TestName: 
> test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS ===
> ok
> Test case no 217 and 236: User should not be allowed to create a LB rule for 
> a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP 
> | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> already has a PF rule. ... === TestName: 
> test_13_VPC_LBRuleCreateFailForPFSourceNATIP | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> already has a Static Nat rule. ... === TestName: 
> test_14_VPC_LBRuleCreateFailForStaticNatRule | Status : SUCCESS ===
> ok
> Test release Ip address that has a LB rule assigned to it. ... === TestName: 
> test_15_VPC_ReleaseIPForLBRuleCreated | Status : SUCCESS ===
> ok
> Ran 15 tests in 8586.639s
> OK
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_internal_lbrules.py
> Test results:
> Test VPC Network Internal LB functionality with different combinations of 
> Internal LB rules ... === TestName: test_01_internallb_rules | Status : 
> SUCCESS ===
> ok
> Test VPC Network Internal LB functionality by performing (wget) traffic tests 
> within a VPC ... === TestName: test_02_internallb_rules_traffic | Status : 
> SUCCESS ===
> ok
> Test VPC Network Internal LB functionality with restarts of VPC network 
> components by performing (wget) ... === TestName: 
> test_03_internallb_rules_vpc_network_restarts_traffic | Status : SUCCESS ===
> ok
> Test VPC Network Internal LB functionality with InternalLbVm appliance 
> operations by performing (wget) ... === TestName: 
> test_04_internallb_appliance_operations_traffic | Status : SUCCESS ===
> ok
> Ran 4 tests in 6729.698s
> OK
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py
> Test results:
> Test Nuage VSP VPC Offering with different combinations of LB service 
> providers ... === TestName: test_01_nuage_internallb_vpc_Offering | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP VPC Network Offering with and without Internal LB service ... 
> === TestName: test_02_nuage_internallb_vpc_network_offering | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP VPC Networks with and without Internal LB service ... === 
> TestName: test_03_nuage_internallb_vpc_networks | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC Internal LB functionality with different combinations of 
> Internal LB rules ... === TestName: test_04_nuage_internallb_rules | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP VPC Internal LB functionality by performing (wget) traffic 
> tests within a VPC ... === TestName: test_05_nuage_internallb_traffic | 
> Status : SUCCESS ===
> ok
> Test Nuage VSP VPC Internal LB functionality with different LB algorithms by 
> performing (wget) traffic tests ... === TestName: 
> test_06_nuage_internallb_algorithms_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC Internal LB functionality with restarts of VPC network 
> components by performing (wget) ... === TestName: 
> test_07_nuage_internallb_vpc_network_restarts_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC Internal LB functionality with InternalLbVm appliance 
> operations by performing (wget) ... === TestName: 
> test_08_nuage_internallb_appliance_operations_traffic | Status : SUCCESS ===
> ok
> Ran 8 tests in 7325.865s
> OK



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

Reply via email to