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

Monty Taylor mordred at inaugust.com
Fri Apr 1 14:35:02 UTC 2016


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.

> The on-behalf-of needs here make this a bit more complicated.





More information about the OpenStack-dev mailing list