[jira] [Commented] (CLOUDSTACK-10382) [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504284#comment-16504284 ] ASF subversion and git services commented on CLOUDSTACK-10382: -- Commit 3af54ec1a8313c51c0faf98bf41e99450a3d0079 in cloudstack's branch refs/heads/master from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=3af54ec ] CLOUDSTACK-10382: Fix cloud-get-vm-data-configdrive.in (#2688) > [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect > --- > > Key: CLOUDSTACK-10382 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10382 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Frank Maximus >Assignee: Frank Maximus >Priority: Major > > * As config iso is built using RockRidge/Juliet, dashes aren't replaced > anymore. > Script is still referring to the files using underscores. > * BLOCK_DEVICE is still looked up using config i.s.o. config-2 > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10382) [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504274#comment-16504274 ] ASF subversion and git services commented on CLOUDSTACK-10382: -- Commit 3af54ec1a8313c51c0faf98bf41e99450a3d0079 in cloudstack's branch refs/heads/4.11 from [~fmaximus] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=3af54ec ] CLOUDSTACK-10382: Fix cloud-get-vm-data-configdrive.in (#2688) > [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect > --- > > Key: CLOUDSTACK-10382 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10382 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Frank Maximus >Assignee: Frank Maximus >Priority: Major > > * As config iso is built using RockRidge/Juliet, dashes aren't replaced > anymore. > Script is still referring to the files using underscores. > * BLOCK_DEVICE is still looked up using config i.s.o. config-2 > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10382) [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504273#comment-16504273
]
ASF GitHub Bot commented on CLOUDSTACK-10382:
-
rhtyd closed pull request #2688: CLOUDSTACK-10382: Fix
cloud-get-vm-data-configdrive.in
URL: https://github.com/apache/cloudstack/pull/2688
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/setup/bindir/cloud-get-vm-data-configdrive.in
b/setup/bindir/cloud-get-vm-data-configdrive.in
index 946ec3b1cdf..c6b70be321b 100644
--- a/setup/bindir/cloud-get-vm-data-configdrive.in
+++ b/setup/bindir/cloud-get-vm-data-configdrive.in
@@ -21,23 +21,28 @@ mountdir=$(mktemp -d)
filepath=$mountdir/cloudstack
user_data=$filepath/userdata/user_data.txt
-availability_zone=$filepath/metadata/availability_zone.txt
-cloud_identifier=$filepath/metadata/cloud_identifier.txt
-instance_id=$filepath/metadata/instance_id.txt
-local_hostname=$filepath/metadata/local_hostname.txt
-service_offering=$filepath/metadata/service_offering.txt
-vm_id=$filepath/metadata/vm_id.txt
-public_key=$filepath/metadata/public_keys.txt
vm_password=$filepath/password/vm_password.txt
+declare -A metadata=(
+["availability-zone"]=$filepath/metadata/availability-zone.txt
+["cloud-identifier"]=$filepath/metadata/cloud-identifier.txt
+["instance-id"]=$filepath/metadata/instance-id.txt
+["local-hostname"]=$filepath/metadata/local-hostname.txt
+["local-ipv4"]=$filepath/metadata/local-ipv4.txt
+["public-ipv4"]=$filepath/metadata/public-ipv4.txt
+["service-offering"]=$filepath/metadata/service-offering.txt
+["vm-id"]=$filepath/metadata/vm-id.txt
+["public-key"]=$filepath/metadata/public-keys.txt
+)
# If lable name is other than config, please change the below line as required
DefaultDisk=/dev/disk/by-label/config-2
function usage
{
+keys=${!metadata[@]}
echo -e "USAGE: cloud-get-vm-data -options"
echo -e " where options include:"
-echo -e "\\t-m | --metadata [availability-zone | cloud-identifier |
instance-id | local-hostname | service-offering | vm-id | public-key]
\\n\\t\\tprint vm metadata"
+echo -e "\\t-m | --metadata [${keys// / | }] \\n\\t\\tprint vm metadata"
echo -e "\\t-p | --password \\n\\t\\tprint vm password"
echo -e "\\t-u | --userdata \\n\\t\\tprint vm userdata"
}
@@ -52,7 +57,7 @@ function prepare_mount
if [ -e $DefaultDisk ]; then
Disk=$DefaultDisk
else
-BLOCK_DEVICE=$(blkid -t LABEL='config' /dev/hd? /dev/sd? /dev/xvd? -o
device)
+BLOCK_DEVICE=$(blkid -t LABEL='config-2' /dev/sr? /dev/hd? /dev/sd?
/dev/xvd? -o device)
if [ -n $BLOCK_DEVICE ]; then
Disk=$BLOCK_DEVICE
else
@@ -81,34 +86,21 @@ case $1 in
;;
-m | --metadata ) shift
if [ "$1" != "" ]; then
-case $1 in
-availability-zone ) echo -n "availability
zone: "; filename=$availability_zone
-;;
-cloud-identifier ) echo -n "cloud identifier:
"; filename=$cloud_identifier
-;;
-instance-id ) echo -n "instance-id: ";
filename=$instance_id
-;;
-local-hostname )echo -n "local-hostname:
"; filename=$local_hostname
-;;
-service-offering ) echo -n "service-offering:
"; filename=$service_offering
-;;
-vm-id ) echo -n "vm-id: ";
filename=$vm_id
-;;
-public-key ) echo -n "public-key: ";
filename=$public_key
-;;
-* ) usage
-remove_mount
-exit 1
-esac
+if [ -n "${metadata[$1]}" ]; then
+echo -n "$1: "
+filename=${metadata[$1]}
+else
+usage
+remove_mount
+exit 1
+fi
else
echo -e "METADATA\\n"
-
[jira] [Commented] (CLOUDSTACK-10382) [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504272#comment-16504272 ] ASF GitHub Bot commented on CLOUDSTACK-10382: - rhtyd commented on issue #2688: CLOUDSTACK-10382: Fix cloud-get-vm-data-configdrive.in URL: https://github.com/apache/cloudstack/pull/2688#issuecomment-395300597 LGTM, tested the script on a config drive + L2:  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 > [ConfigDrive] cloud-get-vm-data-configdrive.in is incorrect > --- > > Key: CLOUDSTACK-10382 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10382 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Frank Maximus >Assignee: Frank Maximus >Priority: Major > > * As config iso is built using RockRidge/Juliet, dashes aren't replaced > anymore. > Script is still referring to the files using underscores. > * BLOCK_DEVICE is still looked up using config i.s.o. config-2 > * -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (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:all-tabpanel ] Raf Smeets closed CLOUDSTACK-10377. --- > 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] [Resolved] (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:all-tabpanel ] Raf Smeets resolved CLOUDSTACK-10377. - Resolution: Fixed Merged in 4.11 > 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-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16502998#comment-16502998
]
ASF GitHub Bot commented on CLOUDSTACK-10199:
-
fmaximus commented on a change in pull request #2595: CLOUDSTACK-10199: Support
requesting a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#discussion_r193334887
##
File path:
engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
##
@@ -869,6 +871,76 @@ public void saveExtraDhcpOptions(final String
networkUuid, final Long nicId, fin
return new Pair(vmNic, Integer.valueOf(deviceId));
}
+/**
+ * If the requested IPv4 address from the NicProfile was configured then
it configures the IPv4 address, Netmask and Gateway to deploy the VM with the
requested IP.
+ */
+protected void configureNicProfileBasedOnRequestedIp(NicProfile
requestedNicProfile, NicProfile nicProfile, Network network) {
+if (requestedNicProfile == null) {
+return;
+}
+String requestedIpv4Address = requestedNicProfile.getRequestedIPv4();
+if (requestedIpv4Address == null) {
+return;
+}
+if (!NetUtils.isValidIp4(requestedIpv4Address)) {
+throw new InvalidParameterValueException(String.format("The
requested [IPv4 address='%s'] is not a valid IP address",
requestedIpv4Address));
+}
+
+VlanVO vlanVo = _vlanDao.findByNetworkIdAndIpv4(network.getId(),
requestedIpv4Address);
+if (vlanVo == null) {
+throw new InvalidParameterValueException(String.format("Trying to
configure a Nic with the requested [IPv4='%s'] but cannot find a Vlan for the
[network id='%s']",
+requestedIpv4Address, network.getId()));
+}
+
+String ipv4Gateway = vlanVo.getVlanGateway();
+String ipv4Netmask = vlanVo.getVlanNetmask();
+
+if (!NetUtils.isValidIp4(ipv4Gateway)) {
+throw new InvalidParameterValueException(String.format("The
[IPv4Gateway='%s'] from [VlanId='%s'] is not valid", ipv4Gateway,
vlanVo.getId()));
+}
+if (!NetUtils.isValidIp4Netmask(ipv4Netmask)) {
+throw new InvalidParameterValueException(String.format("The
[IPv4Netmask='%s'] from [VlanId='%s'] is not valid", ipv4Netmask,
vlanVo.getId()));
+}
+
+acquireLockAndCheckIfIpv4IsFree(network, requestedIpv4Address);
+
+nicProfile.setIPv4Address(requestedIpv4Address);
+nicProfile.setIPv4Gateway(ipv4Gateway);
+nicProfile.setIPv4Netmask(ipv4Netmask);
+
+if (nicProfile.getMacAddress() == null) {
+try {
+String macAddress =
_networkModel.getNextAvailableMacAddressInNetwork(network.getId());
+nicProfile.setMacAddress(macAddress);
+} catch (InsufficientAddressCapacityException e) {
+throw new CloudRuntimeException(String.format("Cannot get next
available mac address in [network id='%s']", network.getId()), e);
+}
+}
+}
+
+/**
+ * Acquires lock of in table "user_ip_address" and checks if the
requested IPv4 address is Free.
+ */
+protected void acquireLockAndCheckIfIpv4IsFree(Network network, String
requestedIpv4Address) {
Review comment:
Will this check work for requested IP addresses in case of Advanced
networking?
I believe if the network is of type Guest, then you won't be able to find an
IPAddressVO.
So the method should only be called if the network is public or shared.
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
> Support requesting a specific IPv4 address in Basic Networking during
> Instance creation
> ---
>
> Key: CLOUDSTACK-10199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10199
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
> Environment: CloudStack 4.10
>Reporter: Wido den Hollander
>Priority: Major
> Labels: basic-networking
>
> DirectPodBasedNetworkGuru does not support requesting a custom IP-Address
> while creating a new NIC/Instance.
> {quote}
> Error 530: Does not support custom ip allocation at this time:
> NicProfile[0-0-null-null-null
> {
> "cserrorcode": 4250,
> "errorcode": 530,
> "errortext": "Does not support custom ip allocation at this time:
[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=16502899#comment-16502899 ] ASF subversion and git services commented on CLOUDSTACK-10377: -- Commit 8798014ca8ce921bcaec747291c36fbbd1ab6b7e in cloudstack's branch refs/heads/master 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 > --- > > 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=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 > --- > > 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=16502880#comment-16502880
]
ASF GitHub Bot commented on CLOUDSTACK-10377:
-
rhtyd closed pull request #2672: CLOUDSTACK-10377: Fix Network restart for Nuage
URL: https://github.com/apache/cloudstack/pull/2672
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/api/src/com/cloud/vm/VirtualMachineProfile.java
b/api/src/com/cloud/vm/VirtualMachineProfile.java
index ed02dcb9c67..977e27eb14f 100644
--- a/api/src/com/cloud/vm/VirtualMachineProfile.java
+++ b/api/src/com/cloud/vm/VirtualMachineProfile.java
@@ -56,6 +56,7 @@
public static final Param VmSshPubKey = new Param("VmSshPubKey");
public static final Param ControlNic = new Param("ControlNic");
public static final Param ReProgramGuestNetworks = new
Param("RestartNetwork");
+public static final Param RollingRestart = new Param("RollingRestart");
public static final Param PxeSeverType = new Param("PxeSeverType");
public static final Param HaTag = new Param("HaTag");
public static final Param HaOperation = new Param("HaOperation");
@@ -173,4 +174,6 @@ public boolean equals(Object obj) {
Float getMemoryOvercommitRatio();
+boolean isRollingRestart();
+
}
diff --git
a/engine/components-api/src/com/cloud/vm/VirtualMachineProfileImpl.java
b/engine/components-api/src/com/cloud/vm/VirtualMachineProfileImpl.java
index 0afca735a13..4d03396c1cb 100644
--- a/engine/components-api/src/com/cloud/vm/VirtualMachineProfileImpl.java
+++ b/engine/components-api/src/com/cloud/vm/VirtualMachineProfileImpl.java
@@ -263,6 +263,11 @@ public Float getMemoryOvercommitRatio() {
return memoryOvercommitRatio;
}
+@Override
+public boolean isRollingRestart() {
+return
Boolean.TRUE.equals(getParameter(VirtualMachineProfile.Param.RollingRestart));
+}
+
@Override
public List getVmData() {
return vmData;
diff --git
a/plugins/network-elements/nuage-vsp/src/com/cloud/network/element/NuageVspElement.java
b/plugins/network-elements/nuage-vsp/src/com/cloud/network/element/NuageVspElement.java
index d5496b0157a..48c3d88d0d0 100644
---
a/plugins/network-elements/nuage-vsp/src/com/cloud/network/element/NuageVspElement.java
+++
b/plugins/network-elements/nuage-vsp/src/com/cloud/network/element/NuageVspElement.java
@@ -54,6 +54,7 @@
import com.cloud.agent.AgentManager;
import com.cloud.agent.api.Answer;
+import com.cloud.agent.api.Command;
import com.cloud.agent.api.StartupCommand;
import com.cloud.agent.api.StartupVspCommand;
import com.cloud.agent.api.element.ApplyAclRuleVspCommand;
@@ -289,14 +290,41 @@ public boolean implement(Network network, NetworkOffering
offering, DeployDestin
VspDhcpDomainOption vspDhcpOptions =
_nuageVspEntityBuilder.buildNetworkDhcpOption(network, offering);
HostVO nuageVspHost =
_nuageVspManager.getNuageVspHost(network.getPhysicalNetworkId());
ImplementVspCommand cmd = new ImplementVspCommand(vspNetwork,
ingressFirewallRules, egressFirewallRules, floatingIpUuids, vspDhcpOptions);
+send(cmd, network);
+
+return true;
+}
+
+private void send(Command cmd, Network network)
+throws ResourceUnavailableException {
+send(cmd, network.getPhysicalNetworkId(), Network.class, network);
+}
+
+private void send(Command cmd, Vpc vpc)
+throws ResourceUnavailableException {
+send(cmd, getPhysicalNetworkId(vpc.getZoneId()), Vpc.class, vpc);
+}
+
+
+private void send(Command cmd, long
physicalNetworkId, Class resourceClass,
+R resource)
+throws ResourceUnavailableException {
+HostVO nuageVspHost =
_nuageVspManager.getNuageVspHost(physicalNetworkId);
Answer answer = _agentMgr.easySend(nuageVspHost.getId(), cmd);
-if (answer == null || !answer.getResult()) {
-s_logger.error("ImplementVspCommand for network " +
network.getUuid() + " failed on Nuage VSD " +
nuageVspHost.getDetail("hostname"));
-if ((null != answer) && (null != answer.getDetails())) {
-throw new ResourceUnavailableException(answer.getDetails(),
Network.class, network.getId());
+if (isFailure(answer)) {
+s_logger.error(cmd.getClass().getName() + " for " +
resourceClass.getName() + " " + resource.getId() + " failed on Nuage VSD " +
nuageVspHost.getDetail("hostname"));
+if (hasFailureDetails(answer)) {
+throw new ResourceUnavailableException(answer.getDetails(),
resourceClass, resource.getId());
}
}
-
[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=16502877#comment-16502877 ] ASF GitHub Bot commented on CLOUDSTACK-10377: - rhtyd commented on issue #2672: CLOUDSTACK-10377: Fix Network restart for Nuage URL: https://github.com/apache/cloudstack/pull/2672#issuecomment-394958866 LGTM, based on code reviews and results I'm okay to merge this as well 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)
