Open Stack

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.