[jira] [Commented] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11&master

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

fmaximus opened a new pull request #2672: CLOUDSTACK-10377: Fix Network restart for Nuage
URL: https://github.com/apache/cloudstack/pull/2672
 
 
   ## Description
   <!--- Describe your changes in detail -->
   Changes in PR #2508 have caused network restart to fail in a Nuage setup,
   as the new VR takes the same IP as the old one, and the old VR is still running.
   Nuage doesn't support multiple VM's having the same IP.
   We delay provisioning the interfaces in VSD until the old VR interface is released.
   
   <!-- For new features, provide link to FS, dev ML discussion etc. -->
   <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. -->
   
   ## Types of changes
   <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
   - [ ] Breaking change (fix or feature that would cause existing functionality to change)
   - [ ] New feature (non-breaking change which adds functionality)
   - [x] Bug fix (non-breaking change which fixes an issue)
   - [ ] Enhancement (improves an existing feature and functionality)
   - [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
   
   ## Screenshots (if appropriate):
   
   ## How Has This Been Tested?
   
   <!-- Please describe in detail how you tested your changes. -->
   <!-- Include details of your testing environment, and the tests you ran to -->
   <!-- see how your change affects other areas of the code, etc. -->
   
   ## Checklist:
   <!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
   <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
   - [x] I have read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md) document.
   - [x] My code follows the code style of this project.
   - [ ] My change requires a change to the documentation.
   - [ ] I have updated the documentation accordingly.
   Testing
   - [x] I have added tests to cover my changes.
   - [x] All relevant new and existing integration tests have passed.
   - [x] A full integration testsuite with all test that can run on my environment has passed.
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11&master
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-10377
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10377
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.12, 4.11.1.0
>         Environment: ACS 4.11 or master with Nuage VSP 5.2.x
>            Reporter: Raf Smeets
>            Priority: Major
>
> Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11&master
> In Nuage Networks QA regression cycle, cloudstackExpress is failing for master & 4.11 in expressrestartNetworksWithCleanup test.
>  The error is Unable to create a deployment.
>  Issue is caused by fixing https://issues.apache.org/jira/browse/CLOUDSTACK-9114
>   
>  Reason is that for non-redundant routers, a strategy was implemented where first a new VR is deployed, then old VR is powered-off/destroyed, and the new VR is again re-programmed. With this strategy, two identical VRs may be up for a brief moment (few seconds) where both can serve traffic, however the new VR performs arp-ping on its interfaces to update neighbours. After the old VR is removed, the new VR is re-programmed which among many things performs another arpping. The theoretical downtime is therefore limited by the arp-cache refresh which can be up to 30 seconds. In my experiments, against various VMware, KVM and XenServer versions I found that the downtime was indeed less than 30s, usually between 5-20 seconds. Compared to older ACS versions, especially in cases where VRs deployment require full volume copy (like in VMware) a 10x-12x improvement was seen.BUT NUAGE PLUGIN FAILS AS IP ADDRESS IS ALREADY IN USE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)