[openstack-dev] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

Sean Dague sean at dague.net
Fri Apr 1 14:39:44 UTC 2016

On 04/01/2016 10:35 AM, Monty Taylor wrote:
> On 04/01/2016 09:16 AM, Sean Dague wrote:
>> On 04/01/2016 10:08 AM, Monty Taylor wrote:
>>> On 04/01/2016 08:45 AM, Sean Dague wrote:
>>>> The glance v2 work is currently blocked as there is no active spec,
>>>> would be great if someone from the glance team could get that rolling
>>>> again.
>>>> I started digging back through the patches in detail to figure out if
>>>> there are some infrastructure bits we could get in early regardless.
>>>> #1 - new methods for glance xenserver plugin
>>>> Let's take a simplified approach on this patch -
>>>> https://review.openstack.org/#/c/266933 and only change the
>>>> xenapi/etc/xapi.d/plugins/ content in the following ways.
>>>> - add upload/download_vhd_glance2 methods. Don't add an api parameter.
>>>> Add these methods mostly via copy/paste as we're optimizing for
>>>> deleting
>>>> v1 not for fixing v1.
>>>> That will put some infrastructure in place so we can just call the v2
>>>> actions based on decision from higher up the stack.
>>>> #2 - move discover major version back to glanceclient -
>>>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108
>>>> I don't understand why this was ever in nova. This really should be
>>>> glanceclient.discover... something. It uses internal methods from
>>>> glanceclient and internal structures of the content returned.
>>> FWIW, I use:
>>> from glanceclient.common import utils as glance_utils
>>> endpoint, detected_version = glance_utils.strip_version(endpoint)
>>> To part of trying to figure this out as a consumer. Of course, that's
>>> partially because like most of the openstack clients, there is no
>>> exposed API for querying versions, since you have to tell the
>>> constructor what major version you want to construct.
>> You can do that because you are using service catalogue entries for
>> glance. We're not there yet (and the path to get there is... odd for a
>> bunch of reasons).
>> The information that nova has is the config option api_servers -
>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25
>> Which are unversioned endpoints.
> That just makes me want to cry.
>>>> Catching, if desired, should also be on the glanceclient side.
>>>> glanceclient.reset_version() could exist to clear any caching.
>>>> #3 - Ideally we'd also have a
>>>> client = glanceclient.AutoClient(endpoint, ... ) which basically does
>>>> glanceclient.discover and returns us the right client automatically.
>>>> client.version provides access to the version information if you
>>>> need to
>>>> figure out what version of a client you have.
>>> You should just do:
>>> import os_client_config
>>> client = os_client_config.legacy_client('image') since all of that work
>>> is pretty much already done.
>>> If glanceclient grows the ability to be used without a priori knowledge
>>> of the version, I'll certainly start to use it  there.
>> That assumes credentials locally, right? Nova is building glance clients
>> with the context it received the request in as -
>> https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85
>> - so this is happening as the same user as initiated the Nova API call.
> Yah- that totally works - keystoneauth has a token plugin which takes
> these parameters. Also, all of the constructors can take endpoint
> overrides and doing so will skip the catalog.
> So perhaps an initial step towards getting to be able to use the catalog
> to find the endpoint would be to start using the API in such a way that
> takes either an auth_url or an image_endpoint.

I guess I don't see how those would all connect together, as
os-client-config requires clouds.yaml which isn't a part of how we
deploy servers (unless I'm missing something). If you want to propose a
patch to Nova demonstrating how this would all work, that might make it


Sean Dague

More information about the OpenStack-dev mailing list