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

Nikhil Komawar nik.komawar at gmail.com
Mon Apr 18 16:48:06 UTC 2016



On 4/16/16 1:33 PM, Flavio Percoco wrote:
> 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.
>

Thanks for the clarification Flavio. I guess now we can move on with the
alternate plan proposed and keep the momentum on deprecating Glance v1
intact. I'm hoping that the cross track (nova-glance) summit session
(Thanks Matt!!!!) will help relieve from some of such issues and
perspective gaps that different people have.

>>> 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
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160418/42f79b91/attachment.html>


More information about the OpenStack-dev mailing list