[jira] [Updated] (CLOUDSTACK-10378) udp port 111 (rpcbind) is exposed in the public interface on SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Sinhoreli updated CLOUDSTACK-10378: - Affects Version/s: 4.11.1.0 4.11.1.1 > udp port 111 (rpcbind) is exposed in the public interface on SSVM > - > > Key: CLOUDSTACK-10378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10378 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.11.0.0, 4.11.1.1, 4.11.1.0 >Reporter: Marco Sinhoreli >Priority: Critical > > The secondary storage VM is exposing the NFS rpcbind udp port (111) to the > internet on the public network interface. It can cause security risks. > Exposing the RPC/portmap udp port 111 service to the internet, everybody can > query this information without having to authenticate. It can be useful to > attackers to know what you have running. Also, the RPC service has a history > of security vulnerabilities. > The recommendable is update the iptables rules on the system VM template to > block the 111 udp port. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10378) udp port 111 (rpcbind) is exposed in the public interface on SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Sinhoreli updated CLOUDSTACK-10378: - Description: The secondary storage VM is exposing the NFS rpcbind udp port (111) to the internet on the public network interface. It can cause security risks. Exposing the RPC/portmap udp port 111 service to the internet, everybody can query this information without having to authenticate. It can be useful to attackers to know what you have running. Also, the RPC service has a history of security vulnerabilities. The recommendable is update the iptables rules on the system VM template to block the 111 udp port. was: The secondary storage VM is exposing the NFS rpcbind udp port (111) to the internet on the public network interface. It can cause security risks. To expose the RPC/portmap udp port 111 service to the internet, everybody can query this information without having to authenticate. It can be useful to attackers to know what you have running. Also, the RPC service has a history of security vulnerabilities. The recommendable is update the iptables rules on the system VM template to block the 111 udp port. > udp port 111 (rpcbind) is exposed in the public interface on SSVM > - > > Key: CLOUDSTACK-10378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10378 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.11.0.0 >Reporter: Marco Sinhoreli >Priority: Critical > > The secondary storage VM is exposing the NFS rpcbind udp port (111) to the > internet on the public network interface. It can cause security risks. > Exposing the RPC/portmap udp port 111 service to the internet, everybody can > query this information without having to authenticate. It can be useful to > attackers to know what you have running. Also, the RPC service has a history > of security vulnerabilities. > The recommendable is update the iptables rules on the system VM template to > block the 111 udp port. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490845#comment-16490845
]
ASF GitHub Bot commented on CLOUDSTACK-8609:
sureshanaparti commented on a change in pull request #2091: CLOUDSTACK-8609:
[VMware] VM is not accessible after migration across clusters
URL: https://github.com/apache/cloudstack/pull/2091#discussion_r190922688
##
File path:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
##
@@ -2954,23 +2967,29 @@ private void
deleteUnregisteredVmFiles(VirtualMachineFileLayoutEx vmFileLayout,
else if (file.getType().equals("config"))
vmFolder = new
DatastoreFile(fileInDatastore.getDatastoreName(), fileInDatastore.getDir());
DatastoreMO dsMo = new DatastoreMO(dcMo.getContext(),
dcMo.findDatastore(fileInDatastore.getDatastoreName()));
-s_logger.debug("Deleting file: " + file.getName());
-dsMo.deleteFile(file.getName(), dcMo.getMor(), true,
VmwareManager.s_vmwareSearchExcludeFolder.value());
+if (skipDatastores == null ||
!skipDatastores.contains(dsMo.getName())) {
+s_logger.debug("Deleting file: " + file.getName());
+dsMo.deleteFile(file.getName(), dcMo.getMor(), true);
+}
}
// Delete files that are present in the VM folder - this will take
care of the VM disks as well.
DatastoreMO vmFolderDsMo = new DatastoreMO(dcMo.getContext(),
dcMo.findDatastore(vmFolder.getDatastoreName()));
String[] files = vmFolderDsMo.listDirContent(vmFolder.getPath());
if (deleteDisks) {
for (String file : files) {
String vmDiskFileFullPath = String.format("%s/%s",
vmFolder.getPath(), file);
-s_logger.debug("Deleting file: " + vmDiskFileFullPath);
-vmFolderDsMo.deleteFile(vmDiskFileFullPath, dcMo.getMor(),
true, VmwareManager.s_vmwareSearchExcludeFolder.value());
+if (skipDatastores == null ||
!skipDatastores.contains(vmFolderDsMo.getName())) {
+s_logger.debug("Deleting file: " + vmDiskFileFullPath);
+vmFolderDsMo.deleteFile(vmDiskFileFullPath,
dcMo.getMor(), true);
+}
}
}
// Delete VM folder
if (deleteDisks || files.length == 0) {
-s_logger.debug("Deleting folder: " + vmFolder.getPath());
-vmFolderDsMo.deleteFolder(vmFolder.getPath(), dcMo.getMor());
+if (skipDatastores == null ||
!skipDatastores.contains(vmFolderDsMo.getName())) {
Review comment:
Will check and update. thanks for the review @DaanHoogland
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
> [VMware] VM is not accessible after a migration across clusters.
>
>
> Key: CLOUDSTACK-8609
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Likitha Shetty
>Assignee: Suresh Kumar Anaparti
>Priority: Major
> Fix For: Future
>
>
> +Steps to reproduce+
> 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one
> zone-wide primary storage spanning the two clusters.
> 2. Deploy a VM (VM1) on one of the hosts (H1).
> 3. Stop VM1.
> 4. Make the host that contains the VM unsuitable for further VM deployments
> - host runs out of capacity (cpu/memory)
> - host has maximum VMs deployed on it
> 5. Start VM1.
> 6. VM will be powered on H2 but will not be accessible because the .vmx and
> other VM files associated with the VM have been deleted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490846#comment-16490846 ] ASF GitHub Bot commented on CLOUDSTACK-8609: sureshanaparti commented on issue #2091: CLOUDSTACK-8609: [VMware] VM is not accessible after migration across clusters URL: https://github.com/apache/cloudstack/pull/2091#issuecomment-392086663 Yes @PaulAngus. I'll address them. Thanks! 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 > [VMware] VM is not accessible after a migration across clusters. > > > Key: CLOUDSTACK-8609 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Likitha Shetty >Assignee: Suresh Kumar Anaparti >Priority: Major > Fix For: Future > > > +Steps to reproduce+ > 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one > zone-wide primary storage spanning the two clusters. > 2. Deploy a VM (VM1) on one of the hosts (H1). > 3. Stop VM1. > 4. Make the host that contains the VM unsuitable for further VM deployments > - host runs out of capacity (cpu/memory) > - host has maximum VMs deployed on it > 5. Start VM1. > 6. VM will be powered on H2 but will not be accessible because the .vmx and > other VM files associated with the VM have been deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490568#comment-16490568 ] ASF GitHub Bot commented on CLOUDSTACK-8609: PaulAngus commented on issue #2091: CLOUDSTACK-8609: [VMware] VM is not accessible after migration across clusters URL: https://github.com/apache/cloudstack/pull/2091#issuecomment-392020530 @sureshanaparti are you still working on this? Could you address the comments please, 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 > [VMware] VM is not accessible after a migration across clusters. > > > Key: CLOUDSTACK-8609 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Likitha Shetty >Assignee: Suresh Kumar Anaparti >Priority: Major > Fix For: Future > > > +Steps to reproduce+ > 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one > zone-wide primary storage spanning the two clusters. > 2. Deploy a VM (VM1) on one of the hosts (H1). > 3. Stop VM1. > 4. Make the host that contains the VM unsuitable for further VM deployments > - host runs out of capacity (cpu/memory) > - host has maximum VMs deployed on it > 5. Start VM1. > 6. VM will be powered on H2 but will not be accessible because the .vmx and > other VM files associated with the VM have been deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490554#comment-16490554
]
ASF GitHub Bot commented on CLOUDSTACK-10377:
-
rafaelweingartner commented on a change in pull request #2672:
CLOUDSTACK-10377: Fix Network restart for Nuage
URL: https://github.com/apache/cloudstack/pull/2672#discussion_r190858629
##
File path:
plugins/network-elements/nuage-vsp/src/com/cloud/network/guru/NuageVspGuestNetworkGuru.java
##
@@ -723,6 +739,32 @@ public void deallocate(Network network, NicProfile nic,
VirtualMachineProfile vm
} else {
super.deallocate(network, nic, vm);
}
+
+if (virtualMachine.getType() == VirtualMachine.Type.DomainRouter) {
Review comment:
Can you extract this blob to a method?
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
> ---
>
> 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
> 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-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490555#comment-16490555
]
ASF GitHub Bot commented on CLOUDSTACK-10377:
-
rafaelweingartner commented on a change in pull request #2672:
CLOUDSTACK-10377: Fix Network restart for Nuage
URL: https://github.com/apache/cloudstack/pull/2672#discussion_r190857810
##
File path:
plugins/network-elements/nuage-vsp/src/com/cloud/network/guru/NuageVspGuestNetworkGuru.java
##
@@ -528,29 +533,35 @@ public void reserve(NicProfile nic, Network network,
VirtualMachineProfile vm, D
nic.setBroadcastUri(network.getBroadcastUri());
nic.setIsolationUri(network.getBroadcastUri());
-//NicProfile does not contain the NIC UUID. We need this
information to set it in the VMInterface and VPort
-//that we create in VSP
-NicVO nicFromDb = _nicDao.findById(nic.getId());
-IPAddressVO staticNatIp =
_ipAddressDao.findByVmIdAndNetworkId(network.getId(), vm.getId());
VspVm vspVm =
_nuageVspEntityBuilder.buildVspVm(vm.getVirtualMachine(), network);
-VspNic vspNic =
_nuageVspEntityBuilder.buildVspNic(nicFromDb.getUuid(), nic);
-VspStaticNat vspStaticNat = null;
-if (staticNatIp != null) {
-VlanVO staticNatVlan =
_vlanDao.findById(staticNatIp.getVlanId());
-vspStaticNat = _nuageVspEntityBuilder.buildVspStaticNat(null,
staticNatIp, staticNatVlan, vspNic);
-}
-boolean defaultHasDns = getDefaultHasDns(networkHasDnsCache,
nicFromDb);
-VspDhcpVMOption dhcpOption =
_nuageVspEntityBuilder.buildVmDhcpOption(nicFromDb, defaultHasDns,
networkHasDns);
-ReserveVmInterfaceVspCommand cmd = new
ReserveVmInterfaceVspCommand(vspNetwork, vspVm, vspNic, vspStaticNat,
dhcpOption);
-Answer answer = _agentMgr.easySend(nuageVspHost.getId(), cmd);
+if
(!Boolean.TRUE.equals(vm.getParameter(VirtualMachineProfile.Param.RollingRestart)))
{
+
+//NicProfile does not contain the NIC UUID. We need this
information to set it in the VMInterface and VPort
+//that we create in VSP
+NicVO nicFromDb = _nicDao.findById(nic.getId());
+IPAddressVO staticNatIp =
_ipAddressDao.findByVmIdAndNetworkId(network.getId(), vm.getId());
+VspNic vspNic =
_nuageVspEntityBuilder.buildVspNic(nicFromDb.getUuid(), nic);
+VspStaticNat vspStaticNat = null;
+if (staticNatIp != null) {
+VlanVO staticNatVlan =
_vlanDao.findById(staticNatIp.getVlanId());
+vspStaticNat =
_nuageVspEntityBuilder.buildVspStaticNat(null, staticNatIp, staticNatVlan,
vspNic);
+}
-if (answer == null || !answer.getResult()) {
-s_logger.error("ReserveVmInterfaceNuageVspCommand failed for
NIC " + nic.getId() + " attached to VM " + vm.getId() + " in network " +
network.getId());
-if ((null != answer) && (null != answer.getDetails())) {
-s_logger.error(answer.getDetails());
+boolean defaultHasDns = getDefaultHasDns(networkHasDnsCache,
nicFromDb);
+VspDhcpVMOption dhcpOption =
_nuageVspEntityBuilder.buildVmDhcpOption(nicFromDb, defaultHasDns,
networkHasDns);
+ReserveVmInterfaceVspCommand cmd = new
ReserveVmInterfaceVspCommand(vspNetwork, vspVm, vspNic, vspStaticNat,
dhcpOption);
+Answer answer = _agentMgr.easySend(nuageVspHost.getId(), cmd);
+
+if (answer == null || !answer.getResult()) {
Review comment:
You can use BooleanUtils here.
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
> ---
>
> 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
> In
[jira] [Commented] (CLOUDSTACK-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490553#comment-16490553
]
ASF GitHub Bot commented on CLOUDSTACK-10377:
-
rafaelweingartner commented on a change in pull request #2672:
CLOUDSTACK-10377: Fix Network restart for Nuage
URL: https://github.com/apache/cloudstack/pull/2672#discussion_r190858465
##
File path:
plugins/network-elements/nuage-vsp/src/com/cloud/network/guru/NuageVspGuestNetworkGuru.java
##
@@ -528,29 +533,35 @@ public void reserve(NicProfile nic, Network network,
VirtualMachineProfile vm, D
nic.setBroadcastUri(network.getBroadcastUri());
nic.setIsolationUri(network.getBroadcastUri());
-//NicProfile does not contain the NIC UUID. We need this
information to set it in the VMInterface and VPort
-//that we create in VSP
-NicVO nicFromDb = _nicDao.findById(nic.getId());
-IPAddressVO staticNatIp =
_ipAddressDao.findByVmIdAndNetworkId(network.getId(), vm.getId());
VspVm vspVm =
_nuageVspEntityBuilder.buildVspVm(vm.getVirtualMachine(), network);
-VspNic vspNic =
_nuageVspEntityBuilder.buildVspNic(nicFromDb.getUuid(), nic);
-VspStaticNat vspStaticNat = null;
-if (staticNatIp != null) {
-VlanVO staticNatVlan =
_vlanDao.findById(staticNatIp.getVlanId());
-vspStaticNat = _nuageVspEntityBuilder.buildVspStaticNat(null,
staticNatIp, staticNatVlan, vspNic);
-}
-boolean defaultHasDns = getDefaultHasDns(networkHasDnsCache,
nicFromDb);
-VspDhcpVMOption dhcpOption =
_nuageVspEntityBuilder.buildVmDhcpOption(nicFromDb, defaultHasDns,
networkHasDns);
-ReserveVmInterfaceVspCommand cmd = new
ReserveVmInterfaceVspCommand(vspNetwork, vspVm, vspNic, vspStaticNat,
dhcpOption);
-Answer answer = _agentMgr.easySend(nuageVspHost.getId(), cmd);
+if
(!Boolean.TRUE.equals(vm.getParameter(VirtualMachineProfile.Param.RollingRestart)))
{
Review comment:
You can use `BooleanUtils` to evaluate
`vm.getParameter(VirtualMachineProfile.Param.RollingRestart))`
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
> ---
>
> 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
> 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-10377) Nuage VSP regression fails in NetworksWithCleanup test since introduction of fix for CLOUDSTACK-9114 in ACS 4.11
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490552#comment-16490552
]
ASF GitHub Bot commented on CLOUDSTACK-10377:
-
rafaelweingartner commented on a change in pull request #2672:
CLOUDSTACK-10377: Fix Network restart for Nuage
URL: https://github.com/apache/cloudstack/pull/2672#discussion_r190858353
##
File path:
plugins/network-elements/nuage-vsp/src/com/cloud/network/guru/NuageVspGuestNetworkGuru.java
##
@@ -528,29 +533,35 @@ public void reserve(NicProfile nic, Network network,
VirtualMachineProfile vm, D
nic.setBroadcastUri(network.getBroadcastUri());
nic.setIsolationUri(network.getBroadcastUri());
-//NicProfile does not contain the NIC UUID. We need this
information to set it in the VMInterface and VPort
-//that we create in VSP
-NicVO nicFromDb = _nicDao.findById(nic.getId());
-IPAddressVO staticNatIp =
_ipAddressDao.findByVmIdAndNetworkId(network.getId(), vm.getId());
VspVm vspVm =
_nuageVspEntityBuilder.buildVspVm(vm.getVirtualMachine(), network);
-VspNic vspNic =
_nuageVspEntityBuilder.buildVspNic(nicFromDb.getUuid(), nic);
-VspStaticNat vspStaticNat = null;
-if (staticNatIp != null) {
-VlanVO staticNatVlan =
_vlanDao.findById(staticNatIp.getVlanId());
-vspStaticNat = _nuageVspEntityBuilder.buildVspStaticNat(null,
staticNatIp, staticNatVlan, vspNic);
-}
-boolean defaultHasDns = getDefaultHasDns(networkHasDnsCache,
nicFromDb);
-VspDhcpVMOption dhcpOption =
_nuageVspEntityBuilder.buildVmDhcpOption(nicFromDb, defaultHasDns,
networkHasDns);
-ReserveVmInterfaceVspCommand cmd = new
ReserveVmInterfaceVspCommand(vspNetwork, vspVm, vspNic, vspStaticNat,
dhcpOption);
-Answer answer = _agentMgr.easySend(nuageVspHost.getId(), cmd);
+if
(!Boolean.TRUE.equals(vm.getParameter(VirtualMachineProfile.Param.RollingRestart)))
{
Review comment:
Would you mind extracting these blocks of code to specific methods and unit
testing them? Some documentation might help as well.
This is a comment to for this PR only: We really need to change our mind set
and start using smaller, concise, well-documented and unit-tested methods. This
in turn can greatly improve our productivity.
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
> ---
>
> 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
> 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] [Closed] (CLOUDSTACK-10375) Do not create DefaultNuageVspSharedNetworkOfferingWithSGService
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10375. --- > 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)
