[GitHub] cloudstack pull request #1861: CLOUDSTACK-9698 Make hardcorded wait timeout ...

[sateesh-chodapuneedi]

Github user sateesh-chodapuneedi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1861#discussion_r94216180
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 ---
@@ -230,6 +230,7 @@
 import com.cloud.hypervisor.guru.VMwareGuru;
 import com.cloud.hypervisor.vmware.manager.VmwareHostService;
 import com.cloud.hypervisor.vmware.manager.VmwareManager;
+import com.cloud.hypervisor.vmware.manager.VmwareManagerImpl;
--- End diff --

Yes, moved the parameter to VmwareManager itself.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request #1861: CLOUDSTACK-9698 Make hardcorded wait timeout ...

[sateesh-chodapuneedi]

Github user sateesh-chodapuneedi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1861#discussion_r94216151
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
 ---
@@ -123,12 +125,14 @@
 import com.cloud.utils.ssh.SshHelper;
 import com.cloud.vm.DomainRouterVO;
 
-public class VmwareManagerImpl extends ManagerBase implements 
VmwareManager, VmwareStorageMount, Listener, VmwareDatacenterService {
+public class VmwareManagerImpl extends ManagerBase implements 
VmwareManager, VmwareStorageMount, Listener, VmwareDatacenterService, 
Configurable {
 private static final Logger s_logger = 
Logger.getLogger(VmwareManagerImpl.class);
 
 private static final int STARTUP_DELAY = 6; // 60 
seconds
 private static final long DEFAULT_HOST_SCAN_INTERVAL = 60; // 
every 10 minutes
 
+public static final ConfigKey s_vmwareNicHotplugWaitTimeout = 
new ConfigKey("Advanced", Long.class, "vmware.nic.hotplug.wait.timeout", 
"2",
--- End diff --

Yes, preivously it was intended, as this is just timeout value in cases 
that need more time for hotplug device detection and doesn't introduce delay in 
regular scenarios.

But left it as 15000, just keep the default behavior intact. If require 
admin may modify the configuration parameter per their environment's 
requirements. Pushed the updated code change.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request #1861: CLOUDSTACK-9698 Make hardcorded wait timeout ...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1861#discussion_r94206618
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 ---
@@ -230,6 +230,7 @@
 import com.cloud.hypervisor.guru.VMwareGuru;
 import com.cloud.hypervisor.vmware.manager.VmwareHostService;
 import com.cloud.hypervisor.vmware.manager.VmwareManager;
+import com.cloud.hypervisor.vmware.manager.VmwareManagerImpl;
--- End diff --

Better to define the config parameter in VmwareManager itself.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request #1861: CLOUDSTACK-9698 Make hardcorded wait timeout ...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1861#discussion_r94206556
  
--- Diff: 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
 ---
@@ -123,12 +125,14 @@
 import com.cloud.utils.ssh.SshHelper;
 import com.cloud.vm.DomainRouterVO;
 
-public class VmwareManagerImpl extends ManagerBase implements 
VmwareManager, VmwareStorageMount, Listener, VmwareDatacenterService {
+public class VmwareManagerImpl extends ManagerBase implements 
VmwareManager, VmwareStorageMount, Listener, VmwareDatacenterService, 
Configurable {
 private static final Logger s_logger = 
Logger.getLogger(VmwareManagerImpl.class);
 
 private static final int STARTUP_DELAY = 6; // 60 
seconds
 private static final long DEFAULT_HOST_SCAN_INTERVAL = 60; // 
every 10 minutes
 
+public static final ConfigKey s_vmwareNicHotplugWaitTimeout = 
new ConfigKey("Advanced", Long.class, "vmware.nic.hotplug.wait.timeout", 
"2",
--- End diff --

Earlier the hardcoded wait was 15000 ms, now you have made the default as 
2 ms. Is this intended?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request #1861: CLOUDSTACK-9698 Make hardcorded wait timeout ...

[sateesh-chodapuneedi]

GitHub user sateesh-chodapuneedi opened a pull request:

https://github.com/apache/cloudstack/pull/1861

CLOUDSTACK-9698 Make hardcorded wait timeout for NIC adapter hotplug as 
configurable

Jira
===
CLOUDSTACK-9698 Make hardcoded wait timeout for NIC adapter hotplug as 
configurable

Description
=
Currently ACS waits for 15 seconds (hard coded) for hot-plugged NIC in VR 
to get detected by guest OS.
The time taken to detect hot plugged NIC in guest OS depends on type of NIC 
adapter like (E1000, VMXNET3, E1000e etc.)
and guest OS itself. In uncommon scenarios the NIC detection may take 
longer time than 15 seconds,
in such cases NIC hotplug would be treated as failure which results in VPC 
tier configuration failure.
Alternatively making the wait timeout for NIC adapter hotplug as 
configurable will be helpful for admins in such scenarios.

Also in future if VMware introduces new NIC adapter types which may take 
time to get detected by guest OS, it is good to have flexibility of
configuring the wait timeout as fallback mechanism in such scenarios.

Fix
===
Introduce new configuration parameter (via ConfigKey) 
"vmware.nic.hotplug.wait.timeout" which is "Wait timeout (milli seconds) for 
hot plugged NIC of VM to be detected by guest OS." as fallback instead of hard 
coded timeout, to ensure flexibility for admins given the listed scenarios 
above.

Signed-off-by: Sateesh Chodapuneedi 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sateesh-chodapuneedi/cloudstack 
pr-cloudstack-9698

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1861.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1861


commit 2ea7aadbac386f4d3a0e0062e1042e4266c24e91
Author: Sateesh Chodapuneedi 
Date:   2016-12-23T00:51:04Z

CLOUDSTACK-9698 Make the wait timeout for NIC adapter hotplug as 
configurable

Currently ACS waits for 15 seconds (hard coded) for hot-plugged NIC in VR 
to get detected by guest OS.
The time taken to detect hot plugged NIC in guest OS depends on type of NIC 
adapter like (E1000, VMXNET3, E1000e etc.)
and guest OS itself. In uncommon scenarios the NIC detection may take 
longer time than 15 seconds,
in such cases NIC hotplug would be treated as failure which results in VPC 
tier configuration failure.
Alternatively making the wait timeout for NIC adapter hotplug as 
configurable will be helpful for admins in such scenarios.

Also in future if VMware introduces new NIC adapter types which may take 
time to get detected by guest OS, it is good to have flexibility of
configuring the wait timeout as fallback mechanism in such scenarios.

Signed-off-by: Sateesh Chodapuneedi 




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---