<font size=2 face="sans-serif">Hi all,</font>
<br>
<br><font size=2 face="sans-serif">I see you are discussing that enabling
glance API in Nova using Keystone catalog. I think there is one topic related
to it that needs to be mentioned here. Hope we can take consideration.
Current, Nova use config value "glance_api_servers" to talk to
Glance, but there is one limitation using this configure that glance_api_servers
has hard coded Glance API format, we can not configure arbitrary url using
this configure, I have created a blueprint to track it. You can get more
information</font><a href="https://blueprints.launchpad.net/nova/+spec/nova-enable-glance-arbitrary-url"><font size=2 color=blue face="sans-serif">https://blueprints.launchpad.net/nova/+spec/nova-enable-glance-arbitrary-url</font></a>
<br>
<br><font size=2 face="sans-serif">The related bug is </font><a href="https://bugs.launchpad.net/nova/+bug/1220131"><font size=2 color=blue face="sans-serif">https://bugs.launchpad.net/nova/+bug/1220131</font></a>
<br>
<br><font size=3>On Nov 1, 2013 6:46 PM, "John Garbutt" <</font><a href=mailto:john@johngarbutt.com><font size=3 color=blue><u>john@johngarbutt.com</u></font></a><font size=3>>
wrote:<br>
><br>
> On 29 October 2013 16:11, Eddie Sheffield <</font><a href=mailto:eddie.sheffield@rackspace.com><font size=3 color=blue><u>eddie.sheffield@rackspace.com</u></font></a><font size=3>>
wrote:<br>
> ><br>
> > "John Garbutt" <</font><a href=mailto:john@johngarbutt.com><font size=3 color=blue><u>john@johngarbutt.com</u></font></a><font size=3>>
said:<br>
> ><br>
> >> Going back to Joe's comment:<br>
> >>> Can both of these cases be covered by configuring the
keystone catalog?<br>
> >> +1<br>
> >><br>
> >> If both v1 and v2 are present, pick v2, otherwise just pick
what is in<br>
> >> the catalogue. That seems cool. Not quite sure how the multiple
glance<br>
> >> endpoints works in the keystone catalog, but should work
I assume.<br>
> >><br>
> >> We hard code nova right now, and so we probably want to keep
that route too?<br>
> ><br>
> > Nova doesn't use the catalog from Keystone when talking to Glance.
There is a config value "glance_api_servers" which defines a
list of Glance servers that gets randomized and cycled through. I assume
that's what you're referring to with "we hard code nova." But
currently there's nowhere in this path (internal nova to glance) where
the keystone catalog is available.<br>
><br>
> Yes. I was not very clear. I am proposing we change that. We could
try<br>
> shoehorn the multiple glance nodes in the keystone catalog, then cache<br>
> that in the context, but maybe that doesn't make sense. This is a<br>
> separate change really.</font>
<p><font size=3>FYI:  We cache the cinder endpoints from keystone
catalog in the context already. So doing something like that with glance
won't be without president.</font>
<p><font size=3>><br>
> But clearly, we can't drop the direct configuration of glance servers<br>
> for some time either.<br>
><br>
> > I think some of the confusion may be that Glanceclient at the
programmatic client level doesn't talk to keystone. That happens happens
higher in the CLI level which doesn't come into play here.<br>
> ><br>
> >> From: "Russell Bryant" <</font><a href=mailto:rbryant@redhat.com><font size=3 color=blue><u>rbryant@redhat.com</u></font></a><font size=3>><br>
> >>> On 10/17/2013 03:12 PM, Eddie Sheffield wrote:<br>
> >>>> Might I propose a compromise?<br>
> >>>><br>
> >>>> 1) For the VERY short term, keep the config value
and get the change otherwise<br>
> >>>> reviewed and hopefully accepted.<br>
> >>>><br>
> >>>> 2) Immediately file two blueprints:<br>
> >>>>    - python-glanceclient - expose a way
to discover available versions<br>
> >>>>    - nova - depends on the glanceclient
bp and allowing autodiscovery of glance<br>
> >>>> version<br>
> >>>>             and making
the config value optional (tho not deprecated / removed)<br>
> >>><br>
> >>> Supporting both seems reasonable.  At least then
*most* people don't<br>
> >>> need to worry about it and it "just works",
but the override is there if<br>
> >>> necessary, since multiple people seem to be expressing
a desire to have<br>
> >>> it available.<br>
> >><br>
> >> +1<br>
> >><br>
> >>> Can we just do this all at once?  Adding this to
glanceclient doesn't<br>
> >>> seem like a huge task.<br>
> >><br>
> >> I worry about us never getting the full solution, but it
seems to have<br>
> >> got complicated.<br>
> ><br>
> > The glanceclient side is done, as far as allowing access to the
list of available API versions on a given server. It's getting Nova to
use this info that's a bit sticky.<br>
><br>
> Hmm, OK. Could we not just cache the detected version, to reduce the<br>
> impact of that decision.<br>
><br>
> >> On 28 October 2013 15:13, Eddie Sheffield <</font><a href=mailto:eddie.sheffield@rackspace.com><font size=3 color=blue><u>eddie.sheffield@rackspace.com</u></font></a><font size=3>>
wrote:<br>
> >>> So...I've been working on this some more and hit a bit
of a snag. The<br>
> >>> Glanceclient change was easy, but I see now that doing
this in nova will require<br>
> >>> a pretty huge change in the way things work. Currently,
the API version is<br>
> >>> grabbed from the config value, the appropriate driver
is instantiated, and calls<br>
> >>> go through that. The problem comes in that the actually
glance server isn't<br>
> >>> communicated with until very late in the process. Nothing
"sees" the servers at<br>
> >>> the level where the driver is determined. Also there
isn't a single glance server<br>
> >>> but a list of them, and in the even of certain communication
failures the list is<br>
> >>> cycled through until success or a number of retries has
passed.<br>
> >>><br>
> >>> So to change this to auto configuring will require turning
this upside down,<br>
> >>> cycling through the servers at a higher level, choosing
the appropriate driver<br>
> >>> for that server, and handling retries at that same level.<br>
> >>><br>
> >>> Doable, but a much larger task than I first was thinking.<br>
> >>><br>
> >>> Also, I don't really want the added overhead of getting
the api versions before<br>
> >>> every call, so I'm thinking that going through the list
of servers at startup and<br>
> >>> discovering the versions then and caching that somehow
would be helpful as well.<br>
> >>><br>
> >>> Thoughts?<br>
> >><br>
> >> I do worry about that overhead. But with Joe's comment, does
it not<br>
> >> just boil down to caching the keystone catalog in the context?<br>
> >><br>
> >> I am not a fan of all the specific talk to glance code we
have in<br>
> >> nova, moving more of that into glanceclient can only be a
good thing.<br>
> >> For the XenServer itegration, for efficiency reasons, we
need glance<br>
> >> to talk from dom0, so it has dom0 making the final HTTP call.
So we<br>
> >> would need a way of extracting that info from the glance
client. But<br>
> >> that seems better than having that code in nova.<br>
> ><br>
> > I know in Glance we've largely taken the view that the client
should be as thin and lightweight as possible so users of the client can
make use of it however they best see fit. There was an earlier patch that
would have moved the whole image service layer into glanceclient that was
rejected. So I think there is a division in philosophies here as well<br>
><br>
> Hmm, I would be a fan of supporting both use cases, "nova style"
and<br>
> more complex. Just seems better for glance to own as much as possible<br>
> of the glance client-like code. But I am a nova guy, I would say that!<br>
> Anyway, that's a different conversation.<br>
><br>
> John<br>
></font>
<br>
<br>
<br><font size=2 face="sans-serif">Thanks & Best Regards,<br>
Yang Yu</font>