[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