Open Stack

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

Agreed!

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
test/dev.

<snip>

> > - 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. :)