Open Stack

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 <mark at 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 <
> pshchelokovskyy at mirantis.com> wrote:
>
>> HI Dmitry,
>>
>> On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur <dtantsur at 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-request at 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-request at 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-request at 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-request at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170811/60e01476/attachment.html>