frapposelli/vagrant-vcloud — pull request #55 by StefanScherer (2014-05-13 07:14:00+00:00)
Title: Keep HTTP connection and cache some responses

I have traced what's going on while a `vagrant status` call 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 status` with four VMs causes the following requests:

```
"SEND POST https://roecloud001/api/sessions"
"SEND GET https://roecloud001/api/vApp/vapp-d23b1a76-8c76-4287-a0da-22c4e719b931"
"SEND GET https://roecloud001/api/vApp/vapp-d23b1a76-8c76-4287-a0da-22c4e719b931"
"SEND POST https://roecloud001/api/sessions"
"SEND GET https://roecloud001/api/vApp/vapp-d23b1a76-8c76-4287-a0da-22c4e719b931"
"SEND POST https://roecloud001/api/sessions"
"SEND GET https://roecloud001/api/vApp/vapp-d23b1a76-8c76-4287-a0da-22c4e719b931"
"SEND POST https://roecloud001/api/sessions"
"SEND GET https://roecloud001/api/vApp/vapp-d23b1a76-8c76-4287-a0da-22c4e719b931"
```

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 `cacheable` where 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 status` of the same vApp looks like this:

```
"SEND POST https://roecloud001/api/sessions"
"SEND GET https://roecloud001/api/vApp/vapp-fdd5c7eb-9432-4c64-9b37-3e4603981d84"
```

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.