<div dir="ltr">Hi,<div><br></div><div>regarding #1: there are actually 4 methods there that are not used anywhere in ironic, which are to list images and create/update/delete an image in Glance.</div><div>The question is do we consider those classes to be a part of public ironic Python API? Are we safe to remove them right away? Or should we go a standard deprecation process on those - log runtime warnings when they are used in Pike (unfortunately it seems it won't be possible to issue a single warning on conductor start) and remove in Queens?</div><div><br></div><div>I'd also like to add a question #4:</div><div><br></div><div>In the image-related code we have special handling of "glance://" URL scheme. Is anyone using that still? Do we really have to support it or can we deprecate it as a recognized URL scheme for image_source?</div><div><br></div><div>Cheers,</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, May 23, 2017 at 7:11 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/23/2017 05:52 PM, Pavlo Shchelokovskyy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I've started to dig through the part of Ironic code that deals with glance and I am confused by some things:<br>
<br>
1) Glance image service classes have methods to create, update and delete images. What's the use case behind them? Is ironic supposed to actively manage images? Besides, these do not seem to be used anywhere else in ironic code.<br>
</blockquote>
<br></span>
Yeah, I don't think we upload anything to glance. We may upload stuff to Swift though, but that's another story.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Some parts of code (and quite a handful of options in [glance] config section) AFAIU target a situation when both ironic and glance are deployed standalone with possibly multiple glance API services so there is no keystone catalog to discover the (load-balanced) glance endpoint from. We even have our own round-robin implementation for those multiple glance hosts o_0<br>
<br>
3) Glance's direct_url handling - AFAIU this will work iff there is a single conductor service and single glance registry service configured with simple file backend deployed on the same host (with appropriate file access permissions between ironic and glance), and glance is configured to actually provide direct_url for the image - very much a DevStack (though with non-standard settings).<br>
<br>
Do we actually have to support such narrow deployment scenarios as in 2) and 3)? While for 2) we probably should continue support standalone Glance, keeping implementations for our own round-robin load-balancing and retries seems out of ironic scope.<br>
</blockquote>
<br></span>
Yeah, I'd expect people to deploy HA proxy or something similar for load-balancing. Not sure what you mean by retries though.<br>
<br>
Number 3, I suspect, is for simple all-in-one deployments. I don't remember the whole background, so I can't comment more.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Most of those do seem to be a legacy code crust from nova-baremetal era, but I might be missing something. I'm eager to hear your comments.<br>
</blockquote>
<br></span>
#1 and #2 probably. I'm fine with getting rid of them.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
Cheers,<br>
<br>
Dr. Pavlo Shchelokovskyy<br>
Senior Software Engineer<br>
Mirantis Inc<br>
<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br></span>
<<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a>><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br></div></div>