This will ultimately be:
downloads.gridcentriclabs.com/packages/cobaltclient/cobaltclient

Is that how we're going to roll? Despite the fact that the client no longer has the same versioning scheme (essex, folsom, grizzly, etc.) I think we will likely need to adopt a versioning scheme that matches the novaclient versioning.

Seems like they've gone to 2.X: https://github.com/openstack/python-novaclient/tree/2.13.0

So one way to do it would be to have downloads.gridcentriclabs.com/packages/cobaltclient/v2 (or something similar) for when they end up at 3.X and we'll have both v2 and v3. But users don't currently select a branch like that. Ugh. 

The best thing to do is probably to have essex, folsom, grizzly, etc. and just ensure that the correct version is associated with the OS distro. We can maintain one branch of cobaltclient, and just ship the version that corresponds to the OS distribution. That would align with how packages shipped out for Cloud Archive et al. (users just select an OS version and get the client, they would probably want similar behaviour from our stuff). That would make the above:

     "#{node["vms"]["repo"]["client_key"]}/#{node["vms"]["os-version"]}/" +