[openstack-dev] [TripleO] Installing from packages in tripleo-image-elements
Fox, Kevin M
Kevin.Fox at pnnl.gov
Wed Jan 8 17:22:15 UTC 2014
Let me give you a more concrete example, since you still think one size fits all here.
I am using OpenStack on my home server now. In the past, I had one machine with lots of services on it. At times, I would update one service and during the update process, a different service would break.
Last round of hardware purchasing got me an 8 core desktop processor with 16 gigs of ram. Enough to give every service I have its own processor and 2 gigs of ram. So, I decided to run OpenStack on the server to manage the service vm's.
The base server shares out my shared data with nfs, the vm's then re-export it in various ways like samba, dlna to my ps3, etc.
Now, I could create a golden image for each service type with everything all setup and good to go. And infrastructure to constantly build updated ones.
But in this case, grabbing Fedora cloud image or Ubuntu cloud image, and starting up the service with heat and a couple of line cloud init telling it to install just the package for the one service I need saves a ton of effort and space. The complexity is totally on the distro folks and not me. Very simple to maintain.
I can get almost the stability of the golden image simply by pausing the working service vm, spawning a new one, and only if its sane, switch to it and delete the old. In fact, Heat is working towards (if not already done) having Heat itself do this process for you.
I'm all for golden images as a tool. We use them a lot. Like all tools though, there isn't one "works for all cases best" tool.
I hope this use case helps.
From: Clint Byrum [clint at fewbar.com]
Sent: Wednesday, January 08, 2014 8:36 AM
Subject: Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements
Excerpts from Derek Higgins's message of 2014-01-08 02:11:09 -0800:
> On 08/01/14 05:07, Clint Byrum wrote:
> > Excerpts from Fox, Kevin M's message of 2014-01-07 16:27:35 -0800:
> >> Another piece to the conversation I think is update philosophy. If
> >> you are always going to require a new image and no customization after
> >> build ever, ever, the messiness that source usually cause in the file
> >> system image really doesn't matter. The package system allows you to
> >> easily update, add, and remove packages bits at runtime cleanly. In
> >> our experimenting with OpenStack, its becoming hard to determine
> >> which philosophy is better. Golden Images for some things make a lot
> >> of sense. For other random services, the maintenance of the Golden
> >> Image seems to be too much to bother with and just installing a few
> >> packages after image start is preferable. I think both approaches are
> >> valuable. This may not directly relate to what is best for Triple-O
> >> elements, but since we are talking philosophy anyway...
> > The golden image approach should be identical to the package approach if
> > you are doing any kind of testing work-flow.
> > "Just install a few packages" is how you end up with, as Robert said,
> > "snowflakes". The approach we're taking with diskimage-builder should
> > result in that image building extremely rapidly, even if you compiled
> > those things from source.
> This is the part of your argument I don't understand, creating images
> with packages is no more likely to result in snowflakes then creating
> images from sources in git.
> You would build an image using packages and at the end of the build
> process you can lock the package versions. Regardless of how the image
> is built you can consider it a golden image. This image is then deployed
> to your hosts and not changed.
> We would still be using diskimage-builder the main difference to the
> whole process is we would end up with a image that has more packages
> installed and no virtual envs.
I'm not saying building images from packages will encourage
snowflakes. I'm saying installing and updating on systems using packages
encourages snowflakes. Kevin was suggesting that the image workflow
wouldn't fit for everything, and thus was opening up the "just install
a few packages on a system" can of worms. I'm saying to Kevin, don't
do that, just make your image work-flow tighter, and suggesting it is
worth it to do that to avoid having snowflakes.
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev