Open Stack

On 04/01/2016 09:39 AM, Sean Dague wrote:
> 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
> clearer.

AH. I understand the misunderstanding. occ doesn't require a clouds.yaml 
- that's just usually the most convenient way to express config in a 
context where you either have complex settings or multiple clouds.

All of the things you can do can also be done directly by parameters to 
the config constructor.

But I agree - the easiest way to take next step would be a patch - I'll 
cook one up and we can talk about it. It may be a terrible idea ... it 
just sounds so much like the problems overlap and solving them the first 
time really sucked, so I'd hate to watch someone else have to solve them 
again. I think I stabbed one of my eyes out the first time.

Monty