On 04/05/16 09:46 -0700, Clark Boylan wrote:
On Wed, May 4, 2016, at 08:55 AM, Flavio Percoco wrote:On 04/05/16 15:05 +0000, Amrith Kumar wrote: >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.At the summit we discussed the possibility of providing an implementation that would allow for both DIB and libguestfs to be used but to give priority to DIB. Since there's no real intention of just switching tools at this point, I believe it'd be good to amend the spec so that it doesn't mention libguestfs should be used instead of DiB. The goal at this stage is to provide both and help these move forward.I disagree, as someone that has tried and failed in the past to build trove images the goal should be to make that process easy for the user. Maybe we can finally get rid of redstack years after it was supposed to go away.
Well, that's part of what the spec under discussion is going to address. Pulling out the DiB bits out of trove-integration aims to provide a way for users to build their images. The priority is to get this to a state where users can build images easily and then work in parallel on adding support for an alternative. This is what was said in the Trove session last week.
>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. Maintaining both in the long run will be harder especially because, as you mentioned, the output must be usable interchangeably. However, I think we're at a point, based on the comments in [1] made by Pino Toscano, Luigi Toscano and some other folks that it'd be beneficial for us to have this discussion and to also experiment/test other options. The Sahara team seems to be going in a direction that differs with the one used by the infra team and the one we're headed to (although they overlap in some areas).Has Sahara expressed their needs somewhere too? This is the first I am hearing of them having trouble with image builds (I had thought they were using DIB successfully).
I believe Ethan has replied to this in another email.
>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). ++ Agreed with the above. I'm think collaboration should be the preferred way. I don't think I've enough technical insight on this topic to provide a detailed list of things that are good/bad on either of these tools but I wanted to mention that I believe providing support for both in the short run is good for us and it helps to make a better decision on what tool works best for the project. There's someone willing to do the job and spend sometime doing the research. This same person will provide feedback in addition to the one already provided in [1]. Sorry for not providing much technical details now but I did want to share the above. Thanks for starting this thread, I believe this discussion in the ML will be beneficial.This is the problem. We need technical details and we should fix the problems. It is easy to say X is better than Y because. Unfortunately it doing so doesn't address the actual problems in using either X or Y.
I said *I* didn't have the details but I didn't say there *aren't* technical reasons.
The infra team has been using DIB successfully for a while now and it is a very flexible tool. On the flip side Nova disables file injection by default [1] because it created problems and there are better ways of accomplishing this use case (the inject_partition default of -2 remains today). On top of that devstack seems to have decided that nova's file injection should not be configurable and hard sets it off [2]. What are the problems with DIB and how do they prevent trove users from building an image today? On the positive side using DIB it is very flexible. As has been pointed out in the spec review you can bootstrap using tools like yum and debootstrap if you want complete control of your image build from the ground up, but you can also start from previously published images if you don't need that level of control. One recent benefit we have run into is DIB allows us to pick the filesystems we want which starting from existing images with prebaked filesystems does not make easy (/me shakes fist at silly defaults chosen by particular distros). As for security as I understand it using libvirt/qemu on a machine with virt capabilities is not very different from having root? But with DIB you can run DIB within a virtual machine without access to the hypervisor and without nested virt and achieve a high level of isolation. My suggestion would be to fix problems in DIB (at the very least please file bugs and let the appropriate parties know what problems you are having), and see if Trove user needs can be addressed quickly without reinventing wheels. And in the mean time see if the devstack and nova teams have any input based on their experiences which led to turning these sorts of features off.
As I mentioned in my previous reply, I'll let folks with more technical insights on this topic than me to chime in on this points. Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
