<div dir="ltr"><div><div><div><div><br></div>I haven't look at the review proposed yet one week ago, but some time ago, we needed something similar for Ironic (nova, ironic and cinder share almost the same code for the glance driver), but didn't make it. <br>
</div><br>In case someone wants to take a look: <a href="https://review.openstack.org/#/c/33327/">https://review.openstack.org/#/c/33327/</a><br><br></div>I'll take a look to the bp and the solutions proposed to see if something can be reused.<br>
<br></div>Ghe Rivero<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 1:19 PM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Going back to Joe's comment:<br>
<div class="im">> Can both of these cases be covered by configuring the keystone catalog?<br>
</div>+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>
From: "Russell Bryant" <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
<div class="im">> On 10/17/2013 03:12 PM, Eddie Sheffield wrote:<br>
</div><div class="im">>> Might I propose a compromise?<br>
>><br>
>> 1) For the VERY short term, keep the config value and get the change otherwise 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 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>
</div>+1<br>
<div class="im"><br>
> Can we just do this all at once?  Adding this to glanceclient doesn't<br>
> seem like a huge task.<br>
<br>
</div>I worry about us never getting the full solution, but it seems to have<br>
got complicated.<br>
<div class="im"><br>
On 28 October 2013 15:13, Eddie Sheffield <<a href="mailto:eddie.sheffield@rackspace.com">eddie.sheffield@rackspace.com</a>> wrote:<br>
> So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing "sees" the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is 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, cycling through the servers at a higher level, choosing the appropriate driver 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 every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well.<br>

><br>
> Thoughts?<br>
<br>
</div>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>
<span class="HOEnZb"><font color="#888888"><br>
John<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Pinky: "Gee, Brain, what do you want to do tonight?"<br>The Brain: "The same thing we do every night, Pinky—try to take over the world!"<br>
<br> .''`.  Pienso, Luego Incordio  <br>: :' : <br>`. `'  <br>  `-    <a href="http://www.debian.org" target="_blank">www.debian.org</a>    <a href="http://www.openstack.com" target="_blank">www.openstack.com</a><br>
<br>GPG Key: 26F020F7<br>GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
</div>