<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 4/16/16 1:33 PM, Flavio Percoco
wrote:<br>
</div>
<blockquote cite="mid:20160416173317.GL24746@redhat.com" type="cite">On
15/04/16 11:42 -0400, Nikhil Komawar wrote:
<br>
<blockquote type="cite">comment inline
<br>
<br>
On 4/15/16 11:08 AM, Sean Dague wrote:
<br>
<blockquote type="cite">On 04/15/2016 10:42 AM, Jay Pipes wrote:
<br>
<blockquote type="cite">On 04/01/2016 06:45 AM, Sean Dague
wrote:
<br>
<blockquote type="cite">#2 - move discover major version
back to glanceclient -
<br>
<a class="moz-txt-link-freetext" href="https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108">https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108</a>
<br>
<br>
<br>
I don't understand why this was ever in nova. This really
should be
<br>
<br>
glanceclient.discover... something. It uses internal
methods from
<br>
glanceclient and internal structures of the content
returned.
<br>
<br>
Catching, if desired, should also be on the glanceclient
side.
<br>
glanceclient.reset_version() could exist to clear any
caching.
<br>
</blockquote>
This is exactly what I said in the original review in Mitaka
:(
<br>
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/222150/">https://review.openstack.org/#/c/222150/</a>
<br>
<br>
Note that on PS10 I wrote:
<br>
<br>
This code belongs in glanceclient, not Nova, IMHO...
<br>
<br>
Line 169: Most of the above code should actually be in the
<br>
python-glanceclient package, not here. The Nova code should
be able to
<br>
call glanceclient with a URI and get the latest supported
Glance API
<br>
version.
<br>
<br>
and then later I said:
<br>
<br>
To be a little clearer... the Nova code should be able to do
something
<br>
like this:
<br>
<br>
glance_uris = CONF.glance_api_servers
<br>
glance_uri_version_map = {glance_uri:
glanceclient.get_latest_version(uri)
<br>
for uri in glance_uris}
<br>
<br>
So... pretty much in line with what you say above.
<br>
<br>
Flavio then responded to me:
<br>
<br>
"While I agree with you, I believe we should let this in
"for now"
<br>
whilst it's added to glanceclient. One of the things that
blocked the
<br>
previous work during the Kilo cycle were things being added
to
<br>
glanceclient and the fact that they weren't available right
away.
<br>
<br>
Can we agree on removing this code as soon as there's a
glanceclient
<br>
release with it? Happy to have a bug filed against
glanceclient. The
<br>
glance team will take care of this."
<br>
<br>
and I wrote:
<br>
<br>
"OK, if you promise to remove some of this code when
glanceclient gets
<br>
this functionality, then I suppose I'm good with this going
in Nova for
<br>
now."
<br>
<br>
So, there's your answer to "why this was ever in Nova".
<br>
</blockquote>
My expectation is that the turn around time on something like
this would
<br>
have been weeks, not months. I feel like the delays getting
things into
<br>
glanceclient makes me a pretty firm -2 on "let's just hack it
into Nova
<br>
for now". Because for now seems to equal for ever. :(
<br>
</blockquote>
<br>
Sure, let's avoid more delay.
<br>
<br>
<blockquote type="cite">Honestly, staring at all this again this
morning I think that version
<br>
discovery in Nova is probably just complexity we don't need.
Especially
<br>
because it tends to lead to code that goes and leans on
version
<br>
discovery at weird deep layers, and it turns out you are using
v1 for a
<br>
piece of a flow and v2 for a different piece.
<br>
</blockquote>
<br>
I can figure out a way to get this done in glanceclient
soon-ish.
<br>
</blockquote>
<br>
FWIW, We had figure out a way to do *ALL* this in glanceclient
during Mitaka but
<br>
then nova patches were blocked and the plans we had agreed on were
changed.
<br>
Therefore, The glance team decided to dedicate resources on other
priorities
<br>
that were actually going to make it.
<br>
<br>
So, forgive me if I jump in with a defensive tone but I disagree
with the
<br>
feeling this would've taken forever. The Glance team was already
acting towards
<br>
this but then *Nova* happened.
<br>
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:20160416173317.GL24746@redhat.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">I've proposed new addendum to the spec
to just make this a config, with
<br>
a flow of how we'd get rid of it -
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/306447/">https://review.openstack.org/#/c/306447/</a>
<br>
</blockquote>
<br>
Having said all of the above, I'm good with your proposal so as
to keep
<br>
the current traction on the work. (Guessing that was the reason
to delay
<br>
glanceclient work before)
<br>
<br>
</blockquote>
<br>
I'm happy to see this moving forward. TBH, anything that would let
glance (and
<br>
Nova) move on from Glance's v1 is fine.
<br>
<br>
Flavio
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Thanks,
Nikhil</pre>
</body>
</html>