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.

Thanks,
Kevin

________________________________________
From: Clint Byrum [cl...@fewbar.com]
Sent: Wednesday, January 08, 2014 8:36 AM
To: openstack-dev
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to