Open Stack

> -----Original Message-----
> From: Gregory Haynes [mailto:greg at greghaynes.net]
> Sent: Wednesday, May 04, 2016 3:52 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
> 
> 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?
> 

The approach being proposed by Pete is something that is equally applicable to DIB, I think. I believe that he makes a valid observation and our current element design may in fact be bad.
 
The invocation of DIB[1] is

    ${PATH_DISKIMAGEBUILDER}/bin/disk-image-create -a amd64 -o "${VM}" \
        -x ${QEMU_IMG_OPTIONS} ${DISTRO} ${EXTRA_ELEMENTS} vm heat-cfntools \
        cloud-init-datasources ${DISTRO}-guest ${DISTRO}-${SERVICE_TYPE}

Observe that we include the ${DISTRO} element, and we prefix ${DISTRO} into the name of the guest and the database to get, for example,

	... ubuntu ubuntu-guest ubuntu-mysql

The minimal set of bash and data files could be used instead and we won't have this matrix of datastore-by-distro proliferation that you speak of. That's why I believe that this solution is equally applicable to DIB.

[1] trove-integration/scripts/files/functions_qemu



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