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.dob...@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. :) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
