[openstack-dev] [TripleO][Tuskar] Editing Nodes

Clint Byrum clint at fewbar.com
Wed Jan 15 22:28:37 UTC 2014

Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800:
> I'll start by laying out how I see editing or updating nodes working
> in TripleO without Tuskar:
> To do my initial deployment:
> 1.  I build a set of images for my deployment for different roles. The
> images are different based on their role, and only contain the needed
> software components to accomplish the role they intend to be deployed.
> 2.  I load the images into glance
> 3.  I create the Heat template for my deployment, likely from
> fragments that are already avaiable. Set quantities, indicate which
> images (via image uuid) are for which resources in heat.
> 4.  heat stack-create with my template to do the deployment
> To update my deployment:
> 1.  If I need to edit a role (or create a new one), I create a new image.
> 2.  I load the new image(s) into glance
> 3.  I edit my Heat template, update any quantities, update any image uuids, etc.
> 4.  heat stack-update my deployment
> In both cases above, I see the role of Tuskar being around steps 3 and 4.


Steps 1 and 2 are really CI's responsibility in a CD cloud. The end of
the testing phase is "new images in glance!" For a stable release cloud,
a tool for pulling new released images from elsewhere into Glance would
be really useful, but worst case an admin downloads the new images and
loads them manually.

> I may be misinterpreting, but let me say that I don't think Tuskar
> should be building images. There's been a fair amount of discussion
> around a Nova native image building service [1][2]. I'm actually not
> sure what the status/concensus on that is, but maybe longer term,
> Tuskar might call an API to kick off an image build.

Tuskar should just deploy what it has available. I definitely could
see value in having an image updating service separate from Tuskar,
but I think there are many different answers for "how do images arrive
in Glance?".

> Ok, so given that frame of reference, I'll reply inline:
> On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies <jason.dobies at redhat.com> wrote:
> > I'm pulling this particular discussion point out of the Wireframes thread so
> > it doesn't get lost in the replies.
> >
> > = Background =
> >
> > It started with my first bulletpoint:
> >
> > - When a role is edited, if it has existing nodes deployed with the old
> > version, are the automatically/immediately updated? If not, how do we
> > reflect that there's a difference between how the role is currently
> > configured and the nodes that were previously created from it?
> I would think Roles need to be versioned, and the deployed version
> recorded as Heat metadata/attribute. When you make a change to a Role,
> it's a new version. That way you could easily see what's been
> deployed, and if there's a newer version of the Role to deploy.

Could Tuskar version the whole deployment, but only when you want to
"make it so" ? If it gets too granular, it becomes pervasive to try and
keep track of or to roll back. I think that would work well with a goal
I've always hoped Tuskar would work toward which would be to mostly just
maintain deployment as a Heat stack that nests the real stack with the
parameters realized. With Glance growing Heat template storage capability,
you could just store these versions in Glance.

> > Replies:
> I know you quoted the below, but I'll reply here since we're in a new thread.
> > "I would expect any Role change to be applied immediately. If there is some
> > change where I want to keep older nodes how they are set up and apply new
> > settings only to new added nodes, I would create new Role then."
> -1 to applying immediately.
> When you edit a Role, it gets a new version. But nodes that are
> deployed with the older version are not automatically updated.
> > "We will have to store image metadata in tuskar probably, that would map to
> > glance, once the image is generated. I would say we need to store the list
> > of the elements and probably the commit hashes (because elements can
> > change). Also it should be versioned, as the images in glance will be also
> > versioned.
> I'm not sure why this image metadata would be in Tuskar. I definitely
> like the idea of knowing the versions/commit hashes of the software
> components in your images, but that should probably be in Glance.

Glance is also growing more capabilities to store metadata and be
searchable. Tuskar doesn't need to reinvent this any more than Murano
or Heat do.

> > We can't probably store it in the Glance, cause we will first store the
> > metadata, then generate image. Right?
> I'm not sure I follow this point. But, mainly, I don't think Tuskar
> should be automatically generating images.
> > Then we could see whether image was created from the metadata and whether
> > that image was used in the heat-template. With versions we could also see
> > what has changed.
> We'll be able to tell what image was used in the heat template, and
> thus the deployment,  based on it's UUID.
> I love the idea of seeing differences between images, especially
> installed software versions, but I'm not sure that belongs in Tuskar.
> That sort of utility functionality seems like it could apply to any
> image you might want to launch in OpenStack, not just to do a
> deployment.  So, I think it makes sense to have that as Glance
> metadata or in Glance somehow. For instance, if I wanted to launch an
> image that had a specific version of apache, it'd be nice to be able
> to see that when I'm choosing an image to launch.
> > But there was also idea that there will be some generic image, containing
> > all services, we would just configure which services to start. In that case
> > we would need to version also this.
> -1 to this.  I think we should stick with specialized images per role.
> I replied on the wireframes thread, but I don't see how
> enabling/disabling services in a prebuilt image should work. Plus, I
> don't really think it fits with the TripleO model of having an image
> created based on it's specific "role" (I hate to use that term and
> muddy the water....i mean in the generic sense here).

A generic image just requires more state management and configuration.
That seems like a net loss in efficiency, as both of those things move
failure modes into production instead of keeping them firmly rooted in


> > - For the comment on a generic image with service configuration, the first
> > thing that came to mind was the thread on creating images from packages [1].
> > It's not the exact same problem, but see Clint Byrum's comments in there
> > about drift. My gut feeling is that having specific images for each res-cat
> > will be easier to manage than trying to edit what services are running on a
> > node.
> +1.

Perhaps obviously, +1 as well. :)

More information about the OpenStack-dev mailing list