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@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