This repository has been archived by the owner on Dec 8, 2020. It is now read-only.
Keep HTTP connection and cache some responses #55
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
* upstream/develop: also show vapp to vm rules fix cygdrive path for rsync cache return value of get_vapp_edge_public_ip added optional vapp_prefix to name the vapp removed set_edge_gateway_rules, no longer needed add_edge_gateway_rules for DNAT rule per port removed edge_gateway_rules code from power_on better variable names show also HTTP method in debug log also check used ports in edge gateway removed duplication function poweron_vm corrected integer type in Set removed get_vapp_port_forwarding_external_ports fixed duplicate port forwarding retrieve vapp_edge_public_ip after power_on Introducing Fix for Issue frapposelli#33 - Changed action_start, action_boot and action_up order of operations. always call InventoryCheck in action_up
* upstream/develop: (32 commits) Fixes frapposelli#54 - Added vShield Edge Gateway name Fixes frapposelli#54 - Added vagrant vcloud --redeploy-edge-gw Fixes frapposelli#45 - vCloud Auth token issue Fixes frapposelli#53 - Restructure vagrant vcloud-status to vagrant vcloud <namespace> Fixes frapposelli#52 - Missed autoload Fixes frapposelli#52 - Block Ability to ssh into halted/suspended VMs Fixes frapposelli#47 - Shell provisioner error Finally fixed API Version checker to work as expected version bump. Keep waiting on task if it is in 'queued' or 'preRunning' status Update README.md Version bump Modularized the destroy part to fix issue frapposelli#43 - Split poweroff.rb into poweroff_vapp.rb and poweroff_vm.rb. - Split destroy.rb into destroy_vapp.rb and destroy_vm.rb. - Added is_last_vm.rb to check if vApp has a single VM remaining. also show vapp to vm rules fix cygdrive path for rsync cache return value of get_vapp_edge_public_ip added optional vapp_prefix to name the vapp removed set_edge_gateway_rules, no longer needed add_edge_gateway_rules for DNAT rule per port removed edge_gateway_rules code from power_on ...
|
Hi @StefanScherer, Thanks for the PR ! I need to look into that, any performance improvement is good, but I must do quite some testing to be sure this is harmless, especially with a REST API where objects can change during 2 calls, (Edge Gateway for example, if you have concurrent vagrant deployments) for non common/shared objects, that might be a good performance improvement ! Flagged it as enhancement, but probably will not make it for 0.3.2 |
|
You're right. With this change there is a problem uploading VM's The last GET then will be cached but the debug log shows what will go wrong: So I have to remove some of the flags in function that always need up-to-date responses. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
I have traced what's going on while a
vagrant statuscall with a vApp containing four VMs.Both in Vagrant 1.5.x and Vagrant 1.6.2 have been tested.
I wondered why the code loses the env with the 'persisted' vCloud connection in the env hash. Digging down into other plugins and the vagrant code looking at the BatchAction (with and without parallel mode) I come to the point that this seems the way vagrant works these days.
Each action is for a single machine and therefore we 'loose' the connection object.
In parallel mode only each action is called in another thread, but also has to connect to the server (seems that azure and aws plugins are doing this, haven't tested).
So I come up to this approach. After the first connect, we store the connection object in another global variable that lives longer than the env hashes per action.
I have removed the DisconnectVCloud calls, I don't think we need this, only at exit of the vagrant call.
As we don't can use the parallel mode as it is given, I don't think there is a threading problem with this global variable.
Back to my observations:
A
vagrant statuswith four VMs causes the following requests:With my VPN connection this takes about 14 seconds to retrieve the status of the four boxes - quite long (some latencies per request sum up).
Each POST is a login, each GET retrieves the whole vApp information, so we have all informations for all VMs after the first GET request.
All other requests just respond the same as we do not modify anything in the meantime.
So I gave the send_request another flag
cacheablewhere the most of the GET request will be cached until another method than GET will be used or a task is scheduled and we do a task status GET. All cached data will be thrown away if that happens. This should work quite well, I will test this with further situations.After the two changes (keep connection + cache responses) the
vagrant statusof the same vApp looks like this:And only takes about 4 seconds via my VPN. I will try in intranet today, that should be quite faster then. And then the status is fast regardless the number of VMs created in the vApp.