[openstack-dev] [trove][sahara][infra][Octavia][manila] discussion of image building in Trove

Gregory Haynes greg at greghaynes.net
Wed May 4 19:52:22 UTC 2016


On Wed, May 4, 2016, at 10:33 AM, Peter MacKinnon wrote:
> 
> Well, certainly one downside in the case of Trove (and probably 
> elsewhere) with DIB is the src tree matrix of datastore-by-distro 
> elements required to support various guest image combinations, leading 
> to a proliferation of directories and files. We feel this can be greatly 
> simplified using a libguestfs approach using a minimal set of bash and 
> directly applicable data files (e.g., systemd unit files, conf files, 
> etc.).
> 

I am confused by this, so maybe I am just misunderstanding. Are you
saying that DIB requires you to support more distro combinations? What
combination of distros you support is entirely up to trove as a
downstream and has absolutely nothing to do with the image build tool,
or maybe you mean something else?

> >
> > What seemed very apparent to me in the summit session is that there are
> > a set of issues for Trove relating to image building, mostly relating to
> > reliability and ease of use. There was no one who even mentioned let
> > alone strongly cared about the issues which actually differentiate the
> > existing DIB build process from libguestfs (which is isolation). If that
> > has changed for some reason, then my recommendation would be to use a
> > tool like virt-dib which will allow for a single image building code
> > base while solving all the raised issues in the spec. I suspect when
> > this is tried out the downsides to booting a VM will highly outweigh the
> > benefits for almost all users (especially in trove's gate),
> 
> Anecdotally, it takes the same amount of time for a CentOS7 MySQL build 
> (~ 7 minutes) with either toolchain.
> 

I suspect this is actually "about the same amount of time with hardware
virtualization", which the gate does not have. Otherwise, awesome - lets
just use virt-dib / a libguestfs backend for DIB then.

> > but if the
> > libguestfs docs are to be believed this should be trivial to try out.
> 
> Not quite sure what you mean by "to be believed"?
> 

Just that it seems trivial to try out and there's no downsides
mentioned.

> 
> The various image building frameworks have been noted here 
> http://docs.openstack.org/image-guide/create-images-automatically.html 
> including libguestfs. So it's not like it is an unknown quantity. In the 
> interest of innovation I'm not sure I understand the hearty reluctance 
> to explore this path. We are proposing simply another Trove repo with an 
> alternate (and recognized) image build method. This is not displacing 
> any established tool for Trove; such a tool doesn't exist today. The 
> elements in trove-integration don't really count since they are largely 
> developed for Ubuntu only, inject Trove guestagent src from git only, 
> and, beyond MySQL 5.6, are not tested by the gate.
> 

The reluctance is that, as you say, the existing set of scripts have
deficiencies that need to be fixed. Rather than fix them, we are going
to put effort in to rewriting them to use another tool which does not
help the existing deficiencies. Distro support is still just as much of
a trove issue as it is now - its up to the trove scripts to support the
various distros. It seems a lot more reasonable to fix the problems in
the scripts rather than rewrite to use another tool given that the
problems mentioned have nothing to do with the image building tool.



More information about the OpenStack-dev mailing list