Open Stack

>> I don't necessarily disagree with this assertion, but what this could
>> lead to is a proliferation of a bunch of very similar images.  Templatizing
>> some of the attributes (e.g., this package is enabled, that one isn't)
>> can reduce the potential explosion of images stored in glance.  If that's
>> a concern, then it needs to be addressed.  Note that this is true whether
>> tuskar does/helps with the image building or not.
>>
> We have quite a proliferation of services already:
>
> http://docs.openstack.org/training-guides/content/figures/5/figures/image31.jpg
>
> Realistically, the number of individual services on that diagram (I
> rapidly counted 39.. I bet I'm off) are the maximum number of image
> contents we should ever have in a given deployment. Well plus heat which
> is two more. And maybe Trove.. and Designate.. Ok so lets say "50".
>
> Of course, users might recombine every service with every other service
> over the life-cycle of their deployment, but realistically, that might
> lead to _100_ individual image definitions in service at one time while
> new topologies are being rolled out.
>
> I'm o-k with that kind of proliferation. It is measurable and
> controllable. Also it is crazy. Realistically we're going to see maybe
> 10 definitions.. controllers.. computes.. blocks.. swifts.. and some
> supporting things.
>
> The positive trade there is that we don't have to wonder how a box has
> changed since it was deployed. It is always running all of the software
> we deployed to it, with the config we defined now, or it is in an
> error state.

+1 to this last point. Customizing services outside of the image is 
going to complicate knowing what is running on each node. It's much 
easier to know the node was provisioned with image X and then knowing 
what's in X.

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