[jira] [Commented] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487029#comment-16487029 ] ASF GitHub Bot commented on CLOUDSTACK-10375: - fmaximus opened a new pull request #2667: CLOUDSTACK-10375: Don't create DefaultNuageVspSharedNetworkOfferingWithSGService URL: https://github.com/apache/cloudstack/pull/2667 ## Description Nuage Plugin currently creates a Network Offering on startup. We stop creating this as it is unused. ## Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [x] Cleanup (Code refactoring and cleanup, that may add test cases) ## Screenshots (if appropriate): ## How Has This Been Tested? Ran regression test on a Nuage KVM setup. ## Checklist: - [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 - [ ] 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: us...@infra.apache.org > Do not create DefaultNuageVspSharedNetworkOfferingWithSGService > --- > > Key: CLOUDSTACK-10375 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: ACS 4.11 + Nuage >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Minor > > NuageVsp plugin is creating a network offering called > DefaultNuageVspSharedNetworkOfferingWithSGService. > This offering is unsupported, so do not create it anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
issues@cloudstack.apache.org
Raf Smeets created CLOUDSTACK-10377: --- Summary: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since 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 Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since 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)
issues@cloudstack.apache.org
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10377: Description: 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. was: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since 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. > 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#760
issues@cloudstack.apache.org
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets updated CLOUDSTACK-10377: Summary: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11&master (was: Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for Since fix for CLOUDSTACK-9114 in ACS 4.11&master) > 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 Since 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)
[jira] [Commented] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487301#comment-16487301 ] ASF GitHub Bot commented on CLOUDSTACK-10375: - borisstoyanov commented on issue #2667: CLOUDSTACK-10375: Don't create DefaultNuageVspSharedNetworkOfferingWithSGService URL: https://github.com/apache/cloudstack/pull/2667#issuecomment-391359378 This one has enough LGTM I think we can merge since it does not make sense to run smoketests 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 > Do not create DefaultNuageVspSharedNetworkOfferingWithSGService > --- > > Key: CLOUDSTACK-10375 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: ACS 4.11 + Nuage >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Minor > > NuageVsp plugin is creating a network offering called > DefaultNuageVspSharedNetworkOfferingWithSGService. > This offering is unsupported, so do not create it anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487324#comment-16487324 ] ASF GitHub Bot commented on CLOUDSTACK-10375: - DaanHoogland closed pull request #2667: CLOUDSTACK-10375: Don't create DefaultNuageVspSharedNetworkOfferingWithSGService URL: https://github.com/apache/cloudstack/pull/2667 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManager.java b/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManager.java index 803063060f7..1fe9b40170f 100644 --- a/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManager.java +++ b/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManager.java @@ -46,8 +46,6 @@ public interface NuageVspManager extends PluggableService { -String nuageVspSharedNetworkOfferingWithSGServiceName = "DefaultNuageVspSharedNetworkOfferingWithSGService"; - String nuageVPCOfferingName = "Nuage VSP VPC Offering"; String nuageVPCOfferingDisplayText = "Nuage VSP VPC Offering"; diff --git a/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManagerImpl.java b/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManagerImpl.java index 0a3a966cb78..d5f9acba702 100644 --- a/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManagerImpl.java +++ b/plugins/network-elements/nuage-vsp/src/com/cloud/network/manager/NuageVspManagerImpl.java @@ -19,14 +19,27 @@ package com.cloud.network.manager; -import com.google.common.base.MoreObjects; -import com.google.common.base.Strings; -import com.google.common.collect.HashMultimap; -import com.google.common.collect.ImmutableMultimap; -import com.google.common.collect.ImmutableSet; -import com.google.common.collect.Lists; -import com.google.common.collect.Maps; -import com.google.common.collect.Multimap; +import static com.cloud.agent.api.sync.SyncNuageVspCmsIdCommand.SyncType; + +import java.net.URI; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Comparator; +import java.util.HashSet; +import java.util.Iterator; +import java.util.LinkedList; +import java.util.List; +import java.util.Map; +import java.util.Optional; +import java.util.Set; +import java.util.TreeSet; +import java.util.UUID; +import java.util.stream.Collectors; + +import javax.annotation.Nonnull; +import javax.inject.Inject; +import javax.naming.ConfigurationException; + import net.nuage.vsp.acs.client.api.NuageVspPluginClientLoader; import net.nuage.vsp.acs.client.api.model.VspApiDefaults; import net.nuage.vsp.acs.client.api.model.VspDomain; @@ -37,6 +50,20 @@ import net.nuage.vsp.acs.client.common.NuageVspConstants; import net.nuage.vsp.acs.client.common.model.Pair; import net.nuage.vsp.acs.client.exception.NuageVspException; + +import org.apache.commons.collections.CollectionUtils; +import org.apache.commons.lang3.StringUtils; +import org.apache.log4j.Logger; + +import com.google.common.base.MoreObjects; +import com.google.common.base.Strings; +import com.google.common.collect.HashMultimap; +import com.google.common.collect.ImmutableMultimap; +import com.google.common.collect.ImmutableSet; +import com.google.common.collect.Lists; +import com.google.common.collect.Maps; +import com.google.common.collect.Multimap; + import org.apache.cloudstack.api.ResponseGenerator; import org.apache.cloudstack.context.CallContext; import org.apache.cloudstack.framework.config.ConfigKey; @@ -47,28 +74,6 @@ import org.apache.cloudstack.network.ExternalNetworkDeviceManager; import org.apache.cloudstack.resourcedetail.VpcDetailVO; import org.apache.cloudstack.resourcedetail.dao.VpcDetailsDao; -import org.apache.commons.collections.CollectionUtils; -import org.apache.commons.lang3.StringUtils; -import org.apache.log4j.Logger; - -import javax.annotation.Nonnull; -import javax.inject.Inject; -import javax.naming.ConfigurationException; -import java.net.URI; -import java.util.ArrayList; -import java.util.Arrays; -import java.util.Comparator; -import java.util.HashMap; -import java.util.HashSet; -import java.util.Iterator; -import java.util.LinkedList; -import java.util.List; -import java.util.Map; -import java.util.Optional; -import java.util.Set; -import java.util.TreeSet; -import java.util.UUID; -import java.util.stream.Collectors; import com.cloud.agent.AgentManager; import com.cloud.agent.Listener; @@ -142,9 +147,6 @@ import com.cloud.network.vpc.dao.VpcDao; import com.cloud.network.vpc.dao.VpcOfferingDao; import com.cloud.network.vpc.dao.VpcO
[jira] [Commented] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487325#comment-16487325 ] ASF subversion and git services commented on CLOUDSTACK-10375: -- Commit 5221778aa4e74d3531995987907d8ce20d22a9ce in cloudstack's branch refs/heads/4.11 from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=5221778 ] CLOUDSTACK-10375: Don't create DefaultNuageVspSharedNetworkOfferingWithSGService (#2667) > Do not create DefaultNuageVspSharedNetworkOfferingWithSGService > --- > > Key: CLOUDSTACK-10375 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: ACS 4.11 + Nuage >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Minor > > NuageVsp plugin is creating a network offering called > DefaultNuageVspSharedNetworkOfferingWithSGService. > This offering is unsupported, so do not create it anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487441#comment-16487441 ] ASF subversion and git services commented on CLOUDSTACK-10375: -- Commit 5221778aa4e74d3531995987907d8ce20d22a9ce in cloudstack's branch refs/heads/master from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=5221778 ] CLOUDSTACK-10375: Don't create DefaultNuageVspSharedNetworkOfferingWithSGService (#2667) > Do not create DefaultNuageVspSharedNetworkOfferingWithSGService > --- > > Key: CLOUDSTACK-10375 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.11.0.0 > Environment: ACS 4.11 + Nuage >Reporter: Raf Smeets >Assignee: Frank Maximus >Priority: Minor > > NuageVsp plugin is creating a network offering called > DefaultNuageVspSharedNetworkOfferingWithSGService. > This offering is unsupported, so do not create it anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)