Open Stack

Adding [dib] to the subject line.

-amrith

> -----Original Message-----
> From: Amrith Kumar [mailto:amrith at tesora.com]
> Sent: Wednesday, May 04, 2016 11:05 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [trove][sahara][infra][Octavia][manila]
> discussion of image building in Trove
> 
> I'm emailing the ML on the subject of a review ongoing in the Trove
> project regarding image building[1].
> 
> TL;DR
> 
> One of the most frequent questions that new users of Trove ask is how and
> where to get guest images with which to experiment with Trove, and how to
> build these images for themselves. While documentation about this exists
> in multiple places (including [2], [3]) this is still something that can
> do with some improvement.
> 
> Trove currently uses diskimage-builder for building images used in testing
> the product and these can serve as a good basis for anyone wishing to
> build an image for their own use of Trove. The review [1] makes the
> argument for the libguestfs based approach to building images and
> advocates that Trove should use this instead of diskimage-builder.
> 
> I believe that a broader discussion of this is required and I appreciate
> Greg Haynes' proposal at the design summit to have this discussion on the
> ML. I took the action item to bring this discussion to the ML.
> 
> Details follow ...
> 
> Before going further, I will state my views on these matters.
> 
> 1. It is important for the Trove project to do things quickly to make it
> easier for end users who wish to use Trove and who wish to build their own
> images. I am not concerned what tool or tools a person will use to build
> these images.
> 
> 2. If we provide multiple alternatives to image building as part of the
> Trove project, we should make sure that images built with all sets of
> tools are equivalent and usable interchangeably. Failing to do this will
> make it harder for users to use Trove because we will be providing them
> with a false choice (i.e. the alternatives aren't really alternatives).
> This is harder than it sounds given the combination of tools, operating
> systems, and the source(s) from which you can get database software.
> 
> 3. Trove already has elements for all supported databases using DIB in the
> trove-integration project but these elements are not packaged for customer
> use. Making them usable by customers is a relatively small effort
> including providing a wrapper script (derived from redstack[4]) and
> providing an element to install the guest agent software from a fixed
> location in addition to the development and testing version that is better
> suited to Trove development [5] and [6].
> 
> 4. My comments on various patch sets in the review[1].
> 
> I agree with Monty and Greg Haynes that we should understand the
> deficiencies if any in DIB, and if it is in fact the case that they are
> "intractable/unsolvable", we should switch toolchains. This discussion
> should include issues faced by the Trove team as well as other teams that
> may have faced problems with DIB (such as the sahara team who described
> some of them in the past).
> 
> Thanks,
> 
> -amrith
> 
> 
> [1] https://review.openstack.org/#/c/295274/
> [2]
> http://docs.openstack.org/developer/trove/dev/building_guest_images.html
> [3] https://git.openstack.org/cgit/openstack/diskimage-
> builder/tree/README.rst#writing-an-element
> [4] http://git.openstack.org/cgit/openstack/trove-
> integration/tree/scripts/redstack
> [5] http://git.openstack.org/cgit/openstack/trove-
> integration/tree/scripts/files/trove-guest.systemd.conf
> [6] http://git.openstack.org/cgit/openstack/trove-
> integration/tree/scripts/files/trove-guest.upstart.conf
> 
> __________________________________________________________________________
> 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