Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should vmOpsTool execute networkDiscovery by vm name? #66

Closed
nphmuller opened this issue Jun 21, 2016 · 3 comments
Closed

Should vmOpsTool execute networkDiscovery by vm name? #66

nphmuller opened this issue Jun 21, 2016 · 3 comments

Comments

@nphmuller
Copy link
Contributor

In vmOpsTool:VMWareImpl.java many methods run the waitForVMToBeDeployReady method. This method finally checks if the vm is fully up, by trying to resolve the dns name and/or netbios name.

I however don't really understand how this would work, since it tries to resolve both by vm name. Is it really that common for the vm name to be the dns and/or netbios name? Because when it isn't, the method keeps polling for the max build time (about 20~30 minutes in my case).

This really doesn't seem optimal to me. But it can be solved in one of the following way's:
-Add a checkbox to the task ui, which indicates if the task should wait for the vm to be deploy ready (or at least network discovered). This makes the waiting optional.
-Added a textfield for the dnsname/netbiosname/ip-address, which is used to poll if the vm is up.

What do you think of the proposed solutions? Do you have any better solutions?
I'm willing to implement the solution and create a PR. Can't promise when, though.

@mvvsubbu
Copy link
Member

there is a parameter in UI saying WaitTime, you can set that to zero so that it will not wait for this step.

@nphmuller
Copy link
Contributor Author

Ah, that's more than good enough for me. Closing this issue.

@mvvsubbu
Copy link
Member

Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants