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

Jay Dobies jason.dobies at redhat.com
Fri Jan 17 15:31:03 UTC 2014

On 01/17/2014 03:28 AM, marios at redhat.com wrote:
> On 16/01/14 00:28, Clint Byrum wrote:
>> 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!
> +1 ...
> review  /#/c/52045/ is about generating the overcloud template using
> merge.py **. Having recently picked this up again and following latest
> wireframes and UI design, it seems like most of current Tuskar code is
> going away. After initial panick I saw Jay has actually already started
> that with /#/c/66062/
> Jay: I think at some point (asap) my /#/c/52045/ will be rebased on your
>   /#/c/66062/. Currently my code creates templates from the Tuskar
> representations, i.e. ResourceClasses. For now I will assume that I'll
> be getting something along the lines of:
> {
> 'resource_categories': { 'controller': 1, 'compute': 4, 'object': 1,
> 'block' 2}
> }
> i.e. just resource categories and number of instances for each (plus any
> other user supplied config/auth info). Will there be controllers (do we
> need them, apart from a way to create, update, delete)? Let's talk some
> more on irc later. I'll update the commit message on my review to point
> to yours for now,
> thanks! marios
> ** merge.py is going to be binned but it is the best thing we've got
> _today_ and within the Icehouse timeframe.

My stuff got merged in today. You should be able to use db's api.py to 
grab everything you need. Ping me (jdob) if you have any questions on it 
or need some different queries.

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

More information about the OpenStack-dev mailing list