@vm_helper.ip is this global structure, which gets set to the current… #41
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… IP building - which actually worked out okay by accident until wait_for_ipv4, but now with the extra delay in the system, machine_batch builds will get an IP wrong around 30% of the time when provisioning new machines (it works when doing the chef run on already up machines because the timing is different...) replace this with the actual eventual location of the bootstrap, machine_spec.location['ipaddress'] Signed-off-by: Jaymz Julian <[email protected]>
Signed-off-by: Jaymz Julian <[email protected]>
Signed-off-by: Jaymz Julian <[email protected]>
|
Oh wow, this is great. I'll give this a test tomorrow and if all goes to plan release it tomorrow too! Thanks! 🤘 |
|
why, IP wrong around 30%? |
|
@jcalonsoh The nature of it is a thread race condition - If you're machine_batch'ing 10 machines, the flow goes like this: parallel_foreach(machines) What was happening, is that the time between set ip in global structure the first time, and the use of it, was small enough that this would work. By accident, not design, but it would work. What was happening now with a large enough number of machines, is that you'd get a situation where (using two machines as an example) thread 1: set ip for machine 1 so machine #1 never gets bootstrapped, and machine #2 gets bootstrapped for both machine1 and machine2, and whichever chef client wins that race wins. |
|
Ok, so testing, it seems this hasn't broken The problem is that provisioning is still hit and miss with the Windows side. I think it might be my environment, but i'll continue testing. |
|
Ok, so Creating windows is working fine now. It was some environmental issue on my side. Though, it seems destroy isn't working: Can you verify that the delete command works on your side too? |
|
I just finished my daily integration test with this driver, which both created and destroyed around 150 machines, so it seems to do both for linux. I don't have any windows to test though :(. |
|
Aww man, I was just hoping for another validation. Maybe someone can step up and verify windows too? As I said create works, which is awesome, but delete didn't work for me (for windows). If we don't hear anything by Wednesdayish, I'll go ahead and merge with a note about possible known issues. |
|
I'll try and get a windows setup working and test this tomorrow... just need to work out how to do that :). |
|
With some investigation, I think is due to the I'll go ahead and wait for you to confirm this, then I'll merge and I'll open an issue mentioning what i think is going on. Thanks for the PR! |
|
I suspect something is wrong also, but changes got applied only on I thinks it's between chef-provisioning and cheffish, I go foward for the change but also investigate |
|
Just seeing this thread, I might be able to test with windows machine... (but only tk+kitchen-Dsc+pester) |
|
@gaelcolas awesome, thanks for that. I've opened up #44 to help give good examples. Ideally, I'll push some up today, and if you could a 6 concurrent example would be amazing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@vm_helper.ip is this global structure, which gets set to the current IP building - which actually worked out okay by accident until wait_for_ipv4, but now with the extra delay in the system, machine_batch builds will get an IP wrong around 30% of the time when provisioning new machines (it works when doing the chef run on already up machines because the timing is different...)
replace this with the actual eventual location of the bootstrap, machine_spec.location['ipaddress']
This could almost certainly use testing by someone other than myself - in particular, i've only built linux machines with it!