[
https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500111#comment-16500111
]
ASF GitHub Bot commented on CLOUDSTACK-10377:
---------------------------------------------
blueorangutan commented on issue #2672: CLOUDSTACK-10377: Fix Network restart
for Nuage
URL: https://github.com/apache/cloudstack/pull/2672#issuecomment-394325866
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been
kicked to run smoke tests
----------------------------------------------------------------
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:
us...@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
> 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)
