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
