[openstack-dev] [TripleO] Installing from packages in tripleo-image-elements

Derek Higgins derekh at redhat.com
Wed Jan 8 10:11:09 UTC 2014


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.

> 
> What I'm suggesting is that you still need to test everything every
> change you make, so you should just use the same work flow for
> everything.
> 
>> Again though, I think if you wish to make the argument that packages
>> are undesirable, then ALL packages are probably undesirable for the same
>> reasons. Right? Why not make elements for all dependencies, instead
>> of using distro packages to get you 90% of the way there and then
>> using source just for OpenStack bits. If you always want the newest,
>> latest greatest Neutron, don't you want the newest VSwitch too? I'd
>> argue though there is a point of diminishing returns with source that
>> packages fill. Then the argument is where is the point. Some folks think
>> the point is all the way over to "just use packages for everything".
>>
> 
> I've already stated that the distro is great for utilities, libraries,
> drivers, kernels, etc. These are platform things, not application
> things. OpenVSwitch _is_ part of the application, and I would entertain
> building it for images if we found ourselves in need of hyper-advanced
> features.
> 
> What I've bee suggesting is that if I'm going to do the work to get
> "latest OpenVSwitch", if I do it in a source->image way, I don't have to
> repeat it for every distribution's packaging tool chain.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list