Hi Mark, I do not propose to remove handling of plain http image references altogether, just remove the code pieces in glance service utils that pretend to support such refs *for glance images*.
This code is never reached exactly due to plain http links being recognized as such from the very begining, and thus they will use a different 'image service' (HttpImageService) that has no notion of glance api, its required auth etc. Cheers, On Fri, Aug 11, 2017 at 11:59 AM, Mark Goddard <m...@stackhpc.com> wrote: > Hi Pavlo, > > #3 is used in Bifrost, where there is no Glance service but the default > driver is agent_ipmitool. The images are served by the local nginx service. > For example, taken from one ironic node: > > 'image_source': u'http://10.41.253.100:8080/deployment_image.qcow2' > > Mark > > On 10 August 2017 at 08:20, Pavlo Shchelokovskyy < > pshchelokovs...@mirantis.com> wrote: > >> HI Dmitry, >> >> On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur <dtant...@redhat.com> >> wrote: >> >>> Hi! >>> >>> Thanks for raising this. >>> >>> On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote: >>> >>>> Hi all, >>>> >>>> currently our GlanceImageService seems to support several ways of >>>> defining a reference to glance image: >>>> >>>> 1) simple image UUID [0] >>>> 2) image UUID prefixed with 'glance://' protocol [1] (well, actually >>>> anything starting with 'glance://' and ending with '/<uuid>') >>>> 3) full REST path to the image (as in >>>> http://<glance-api>/v2/images/<image-uuid>), >>>> also used to extract the glance API address [2] >>>> >>>> Support for #3 must surely be removed, as we are moving to API endpoint >>>> discovery from keystone catalog. >>>> Besides I am pretty sure this code path can not actually be reached >>>> currently, as the 'is_glance_image' will ignore such image refs and return >>>> False for those [3], and 'get_image_service' would also not return the >>>> GlanceImageService instance for such image refs [4]. >>>> Hence the question - if it is unusable anyway now, should we execute >>>> the standard deprecation process when removing support for it or just >>>> remove right away? >>>> >>> >>> If unsure, always use the standard process ;) Unless somebody is ready >>> to set up DevStack, and try it out, and prove that it's completely and >>> hopelessly broken. >> >> >> Did just that [0] - hacked up our tempest configuration so that the >> 'http' url for whole disk image used for *HttpLink standalone tests leads >> to <glance-endpoint>/v2/images/<uuid> [1]. >> As I kind of expected, both *HttpLink standalone tests failed, right on >> validating of the deploy interface when trying to do a HEAD on that URL >> instead of 'glance image show', receiving 401 [2]. >> On a side note, it seems our logging is insufficient in this parts, as I >> could not find any relevant logs in ironic-conductor even at debug level, >> all that's there are final RPC processing error logs from api. >> >> So I am quite confident that this code paths [3] in service_utils is a >> dead end indeed :-/ >> >> [0] https://review.openstack.org/#/c/492184/ >> [1] http://logs.openstack.org/84/492184/1/check/gate-ironic- >> dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz >> [2] http://logs.openstack.org/84/492184/1/check/gate-ironic- >> dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz >> [3] https://github.com/openstack/ironic/blob/7e6ce7e78c4378f >> 2f86d085df61a26507a410738/ironic/common/glance_service/ >> service_utils.py#L159-L166 >> >> >>> >>> >>>> As for the #1 and #2 I do not see any big difference between those, and >>>> proposed deprecating and eventually removing support for #2 ('glance://' >>>> scheme) as part of [5]. Two people in review already raised a concern about >>>> removing such support. >>>> >>> >>> To be honest, I like glance://<uuid> more, as it makes it obvious where >>> the image is coming from vs http://. I don't mind removing it too much, >>> but I guess supporting it is not a lot of code, right? >>> >> >> That's not too much burden indeed, as long as we actually do only that - >> as I said, right now it is more like "glance://<anything>/uuid" >> >> >>> >>>> Thus I'd like to ask a broader audience - do we need support for glance >>>> image references in 'glance://*<UUID>' form? Is it actually used somewhere? >>>> What are the benefits of having it besides simple UUID? >>>> >>>> [0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c >>>> ommon/glance_service/service_utils.py#n149 >>>> [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c >>>> ommon/glance_service/service_utils.py#n155 >>>> [2] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c >>>> ommon/glance_service/service_utils.py#n160 >>>> [3] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c >>>> ommon/glance_service/service_utils.py#n208 >>>> [4] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c >>>> ommon/image_service.py#n267 >>>> [5] https://review.openstack.org/#/c/467728 >>>> >>>> Cheers, >>>> >>>> -- >>>> Dr. Pavlo Shchelokovskyy >>>> Senior Software Engineer >>>> Mirantis Inc >>>> www.mirantis.com <http://www.mirantis.com> >>>> >>>> >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.op >>>> enstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Dr. Pavlo Shchelokovskyy >> Senior Software Engineer >> Mirantis Inc >> www.mirantis.com >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev