Re: [openstack-dev] [ironic] why is glance image service code so complex?

2017-05-24 Thread Pavlo Shchelokovskyy 
Hi,

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.
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?

I'd also like to add a question #4:

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?

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, May 23, 2017 at 7:11 PM, Dmitry Tantsur  wrote:

> On 05/23/2017 05:52 PM, Pavlo Shchelokovskyy wrote:
>
>> Hi all,
>>
>> I've started to dig through the part of Ironic code that deals with
>> glance and I am confused by some things:
>>
>> 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.
>>
>
> Yeah, I don't think we upload anything to glance. We may upload stuff to
> Swift though, but that's another story.
>
>
>> 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
>>
>> 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).
>>
>> 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.
>>
>
> Yeah, I'd expect people to deploy HA proxy or something similar for
> load-balancing. Not sure what you mean by retries though.
>
> Number 3, I suspect, is for simple all-in-one deployments. I don't
> remember the whole background, so I can't comment more.
>
>
>> 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.
>>
>
> #1 and #2 probably. I'm fine with getting rid of them.
>
>
>> Cheers,
>>
>> 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
>
__
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

Re: [openstack-dev] [ironic] why is glance image service code so complex?

2017-05-23 Thread Dmitry Tantsur 

On 05/23/2017 05:52 PM, Pavlo Shchelokovskyy wrote:

Hi all,

I've started to dig through the part of Ironic code that deals with glance and I 
am confused by some things:


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.


Yeah, I don't think we upload anything to glance. We may upload stuff to Swift 
though, but that's another story.




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


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).


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.


Yeah, I'd expect people to deploy HA proxy or something similar for 
load-balancing. Not sure what you mean by retries though.


Number 3, I suspect, is for simple all-in-one deployments. I don't remember the 
whole background, so I can't comment more.




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.


#1 and #2 probably. I'm fine with getting rid of them.



Cheers,

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




__
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