-
Notifications
You must be signed in to change notification settings - Fork 2
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
LXD VMs are not really "started" by pylxd until after 10s #12
Comments
Dropped from 0.3.0 milestone due to time constraints. I plan on adding this issue to the 0.4.0 milestone. |
I know that this poor issue has not been getting any love for a while, but I believe that I may have the perfect tool for addressing my connection issues to LXD VMs. Rather the just putting the tests to sleep or coming up with some crazy way to poll the virtual machine for connectivity, I can just use tenacity to retry for like a minute before giving up. Only thing is that I might need to create a context manager for establish the initial RPC connection rather than just wrapping every function inside a tenacity decorator. That remains to be seen however. Once I fix up the code base a bit (i.e. #31), it should be more clear where I can refactor the code. |
As I found out the hard way with
hpc-workshop
, LXD VMs take about 10 to 15 seconds after start to be reachable via the LXD API socket; however, pylxd still considers them started even withinstance.start(wait=True)
. This causes any routine that tries to perform an operation on the started instance to go kaflooey. My current fix for this issue is to play the following 4D chess move:Brilliant? I know. Coming back to reality, the above is not an acceptable solution. A mechanism needs to be added to block the LXD provider until the VM is fully started. Until this is completed, I can not promise support for LXD VMs.
The text was updated successfully, but these errors were encountered: