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

Flavio Percoco flavio at redhat.com
Sat Apr 16 17:33:17 UTC 2016


On 15/04/16 11:42 -0400, Nikhil Komawar wrote:
>comment inline
>
>On 4/15/16 11:08 AM, Sean Dague wrote:
>> On 04/15/2016 10:42 AM, Jay Pipes wrote:
>>> On 04/01/2016 06:45 AM, Sean Dague wrote:
>>>> #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.
>>>>
>>>> Catching, if desired, should also be on the glanceclient side.
>>>> glanceclient.reset_version() could exist to clear any caching.
>>> This is exactly what I said in the original review in Mitaka :(
>>>
>>> https://review.openstack.org/#/c/222150/
>>>
>>> Note that on PS10 I wrote:
>>>
>>> This code belongs in glanceclient, not Nova, IMHO...
>>>
>>> Line 169: Most of the above code should actually be in the
>>> python-glanceclient package, not here. The Nova code should be able to
>>> call glanceclient with a URI and get the latest supported Glance API
>>> version.
>>>
>>> and then later I said:
>>>
>>> To be a little clearer... the Nova code should be able to do something
>>> like this:
>>>
>>>  glance_uris = CONF.glance_api_servers
>>>  glance_uri_version_map = {glance_uri: glanceclient.get_latest_version(uri)
>>>             for uri in glance_uris}
>>>
>>> So... pretty much in line with what you say above.
>>>
>>> Flavio then responded to me:
>>>
>>> "While I agree with you, I believe we should let this in "for now"
>>> whilst it's added to glanceclient. One of the things that blocked the
>>> previous work during the Kilo cycle were things being added to
>>> glanceclient and the fact that they weren't available right away.
>>>
>>> Can we agree on removing this code as soon as there's a glanceclient
>>> release with it? Happy to have a bug filed against glanceclient. The
>>> glance team will take care of this."
>>>
>>> and I wrote:
>>>
>>> "OK, if you promise to remove some of this code when glanceclient gets
>>> this functionality, then I suppose I'm good with this going in Nova for
>>> now."
>>>
>>> So, there's your answer to "why this was ever in Nova".
>> My expectation is that the turn around time on something like this would
>> have been weeks, not months. I feel like the delays getting things into
>> glanceclient makes me a pretty firm -2 on "let's just hack it into Nova
>> for now". Because for now seems to equal for ever. :(
>
>Sure, let's avoid more delay.
>
>> Honestly, staring at all this again this morning I think that version
>> discovery in Nova is probably just complexity we don't need. Especially
>> because it tends to lead to code that goes and leans on version
>> discovery at weird deep layers, and it turns out you are using v1 for a
>> piece of a flow and v2 for a different piece.
>
>I can figure out a way to get this done in glanceclient soon-ish.

FWIW, We had figure out a way to do *ALL* this in glanceclient during Mitaka but
then nova patches were blocked and the plans we had agreed on were changed.
Therefore, The glance team decided to dedicate resources on other priorities
that were actually going to make it.

So, forgive me if I jump in with a defensive tone but I disagree with the
feeling this would've taken forever. The Glance team was already acting towards
this but then *Nova* happened.

>> I've proposed new addendum to the spec to just make this a config, with
>> a flow of how we'd get rid of it - https://review.openstack.org/#/c/306447/
>
>Having said all of the above, I'm good with your proposal so as to keep
>the current traction on the work. (Guessing that was the reason to delay
>glanceclient work before)
>

I'm happy to see this moving forward. TBH, anything that would let glance (and
Nova) move on from Glance's v1 is fine.

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160416/eea9c084/attachment.pgp>


More information about the OpenStack-dev mailing list