cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (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
Date Mon, 21 Nov 2016 18:18:58 GMT

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

ASF GitHub Bot commented on CLOUDSTACK-9321:
--------------------------------------------

Github user prashanthvarma commented on the issue:

    https://github.com/apache/cloudstack/pull/1577
  
    @rhtyd @jburwell I have briefly investigated the above failed tests "test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL"
and "test_oobm_enabledisable_across_clusterzones", here are my findings:
    
    1) "test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL " fails during establishment
of SSH connection to the VM via its public IP (SSH connection failed to setup, timeout error).
Moreover, this test passed in the previous blueorangutan run (refer my previous comment on
investigations of the previous blueorangutan run).
    
    2) "test_oobm_enabledisable_across_clusterzones" failure looks like a test environment
(i.e. host hardware issue). Moreover, this test passed in the previous blueorangutan run (refer
my previous comment on investigations of the previous blueorangutan run).
    
    Here is the error from the logs:
    errorcode : 530, errortext : u'Out-of-band Management action (STATUS) on host (d2049cf2-47ba-4a81-8e72-d01c1dc77dd0)
failed with error: > Error: no response from RAKP 1 message\nError: Unable to establish
IPMI v2 / RMCP+ session\nRunning Get PICMG Properties my_addr 0x20, transit 0, target 0x20\nNo
Response from Get PICMG Properties\nNo PICMG Extenstion discovered\nUnable to get Chassis
Power Status\n'}
    
    IMHO, the above failing tests are most likely due to test environment issues, and has
nothing to do with the code changes in this PR.


> 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)

Mime
View raw message