<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 11:55 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 04/05/16 15:05 +0000, Amrith Kumar wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm emailing the ML on the subject of a review ongoing in the Trove project regarding image building[1].<br>
<br>
TL;DR<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></span>
At the summit we discussed the possibility of providing an implementation that<br>
would allow for both DIB and libguestfs to be used but to give priority to DIB.<br>
Since there's no real intention of just switching tools at this point, I believe<br>
it'd be good to amend the spec so that it doesn't mention libguestfs should be<br>
used instead of DiB.<br>
<br>
The goal at this stage is to provide both and help these move forward.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
<br>
Details follow ...<br>
<br>
Before going further, I will state my views on these matters.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></span>
Maintaining both in the long run will be harder especially because, as you<br>
mentioned, the output must be usable interchangeably. However, I think we're at<br>
a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and<br>
some other folks that it'd be beneficial for us to have this discussion and to<br>
also experiment/test other options.<br>
<br>
The Sahara team seems to be going in a direction that differs with the one used<br>
by the infra team and the one we're headed to (although they overlap in some<br>
areas).<span class=""><br></span></blockquote><div><br></div><div>Sahara has support for several image generation-related cases:<br></div><div>1) Packing an image pre-cluster spawn in Nova.<br></div><div>2) Building clusters from a "clean" OS image post-Nova spawn, by downloading and installing Hadoop/Spark/Storm/WhatHaveYou.<br></div><div>3) Validating images after Nova spawn (to ensure that they're up to spec for the plugin in question.)<br><br></div><div>Because of this, we are pulling image generation logic into the plugins themselves, from a monolithic sahara-image-elements repository. This will aid us in our eventual hope to pull plugins out of the Sahara tree entirely; more immediately, it will allow us to define logic for all of these cases in one place, written eventually in Python. In our Sahara session at summit, which was also attended by several members of the Ironic team (thanks all), we discussed our current plan to use libguestfs rather than DIB as our toolchain; our intent to define a linear, idempotent set of steps to pack images for any plugin lends itself much more neatly to libguestfs' API than to DIB's.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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].<br>
<br>
4. My comments on various patch sets in the review[1].<br>
<br>
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).<br></blockquote></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
<br></span>
++<br>
<br>
Agreed with the above. I'm think collaboration should be the preferred way. I<br>
don't think I've enough technical insight on this topic to provide a detailed<br>
list of things that are good/bad on either of these tools but I wanted to<br>
mention that I believe providing support for both in the short run is good for<br>
us and it helps to make a better decision on what tool works best for the project.<br>
<br>
There's someone willing to do the job and spend sometime doing the research.<br>
This same person will provide feedback in addition to the one already provided<br>
in [1].<br>
<br></blockquote><div><br><div></div>Beyond that, the Sahara team has certainly seen
profound difficulty in the field when customers attempt to generate
their own images, and even for Sahara cores, building images is
occasionally quite harrowing. These issues are seldom based on real
issues in the scripts themselves, but are frequently the result of bleed
between the host and guest; when these issues occur for a customer,
they become extremely difficult to diagnose remotely. Still, it's
entirely possible that DIB has answers to these problems, and it'd be a universal good to identify real flaws in DIB, or just to educate the uninitiated into how DIB can be made to work more cleanly if the features are already there (which they may well be; far be it from me to claim exhaustive mastery of DIB.) The technical reasons we like libguestfs over DIB are:<br><br></div><div>1) Libguestfs manipulates images in a clean helper VM created by libguestfs in a predictable way. As such, no mounts are made on the host, no scripts can affect the host system, and no variables on the host system are likely to affect the image packing process. See <a href="http://libguestfs.org/guestfs-security.1.html">http://libguestfs.org/guestfs-security.1.html</a> for information on libguestfs security.<br></div><div>2) In-place image manipulation means that relatively minor changes to images (package installs, conf declaration, etc.) can occur swiftly, and subsequent changes can occur without uncompressing and recompressing an entire image.<br></div><div>3) DIB scripts' configuration settings, passed in freeform environment variables, can be difficult to understand and document for new users. Libguestfs' API demands more formal parameter passing, reducing the likelihood of accidental misconfiguration.<br><br></div><div>I'm heartened that we're having this discussion: user-facing image packing tools are a critical part of any application-tier provisioning service, and cleaning our upstream image gen processes will be even more crucial as these projects mature and their support matrices grow.<br><br></div><div>Cheers,<br></div><div>-Egafford <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Sorry for not providing much technical details now but I did want to share the<br>
above. Thanks for starting this thread, I believe this discussion in the ML will<br>
be beneficial.<br>
<br>
Flavio<div class=""><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks,<br>
<br>
-amrith<br>
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/295274/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/295274/</a><br>
[2] <a href="http://docs.openstack.org/developer/trove/dev/building_guest_images.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/trove/dev/building_guest_images.html</a><br>
[3] <a href="https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.rst#writing-an-element</a><br>
[4] <a href="http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/redstack" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/redstack</a><br>
[5] <a href="http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.systemd.conf" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.systemd.conf</a><br>
[6] <a href="http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.upstart.conf" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/trove-integration/tree/scripts/files/trove-guest.upstart.conf</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br></div></div><span class=""><font color="#888888">
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>