[openstack-dev] [ironic] why is glance image service code so complex?
pshchelokovskyy at mirantis.com
Tue May 23 15:52:51 UTC 2017
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
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
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.
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.
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev