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

Dmitry Tantsur dtantsur at redhat.com
Tue May 23 16:11:23 UTC 2017


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
> <http://www.mirantis.com>
> 
> 
> __________________________________________________________________________
> 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
> 




More information about the OpenStack-dev mailing list