Adding [dib] to the subject line. -amrith
> -----Original Message----- > From: Amrith Kumar [mailto:amr...@tesora.com] > Sent: Wednesday, May 04, 2016 11:05 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev