Open Stack

Excerpts from Walls, Jeffrey Joel (Cloud OS R&D)'s message of 2014-01-15 07:04:48 -0800:
> > -----Original Message-----
> > From: James Slagle [mailto:james.slagle at gmail.com]
> > Sent: Wednesday, January 15, 2014 5:52 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management
> > section - Wireframes
> 
> > This does not seem quite right to me.  I don't think we want to be
> > enabling or disabling different services in images at deployment time.
> > That's one of the reasons that we have the element nature of
> > diskimage-builder, so that you can build an image with the software
> > components you want. Any service that you include in the image build
> > is automatically enabled. If you want that image with a service
> > disabled, you build a new image.
> 
> 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.