[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502881#comment-16502881 ]
ASF subversion and git services commented on CLOUDSTACK-10377: -------------------------------------------------------------- Commit 8798014ca8ce921bcaec747291c36fbbd1ab6b7e in cloudstack's branch refs/heads/4.11 from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=8798014 ] CLOUDSTACK-10377: Fix Network restart for Nuage (#2672) 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. > 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 > Assignee: Frank Maximus > 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)