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

Jaromir Coufal jcoufal at redhat.com
Thu Jan 16 10:59:18 UTC 2014


On 2014/15/01 22:33, Jay Dobies wrote:
> On 01/15/2014 08:07 AM, James Slagle wrote:
[snip]

>> 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.
>
> I didn't mean to imply that Tuskar would be building images, just
> kicking them off.
Definitely not at the moment.

> As for whether or not it should, that's an interesting question. You and
> I are both on the same page on not having a generic image and having the
> services be configured outside of that, so I'll ignore that idea for now.
>
> I've always thought of Tuskar as providing the user with everything
> they'd need. My gut reaction is that I don't like the idea of saying
> they have to go through a separate step of creating the image and then
> configuring the resource category in Tuskar and attaching the image to it.
>
> That said, I suspect my gut is wrong, or at very least not in line with
> the OpenStack way of thinking.
Well, I think you are right. We should be able to provide as much as 
possible. I don't think that Tuskar has to do everything. Image builder 
would be amazing feature. And I don't think it has to be Tuskar-UI 
business. There can be UI separate from Tuskar, which is part of Horizon 
umbrella, dealing only with building images. I think it has enough 
reasons to become a separate project in the future.

>> 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.
>
> +1, the more I've been thinking about this, the more I like it. We can't
> assume changes will be immediately applied to all provisioned instances,
> so we need some sort of record of what an instance was actually built
> against.
Does it need to be new version of the whole Resource Category? The image 
information might be part of the node. And we can only display in the UI 
that certain amount of nodes are running based on different image than 
is actually available.

= Regarding immediate changes =
For me, Resource Category is indicating some role of the node. It is 
given by certain behavior and I expect all the nodes behave the same way.

If I change some settings of the role which change the behavior (set of 
services, config), I would expect all nodes behave the same way - new 
nodes as well as old ones - so it indicates the immediate change for me. 
Otherwise, if I expect old nodes to behave one way and new nodes to 
behave differently, I need to create another role.

On the other hand, if I only update image OS, packages, or whatever, but 
the behavior of the node remains the same (same set of services, same 
configuration), I do expect to have those nodes with old image working 
along with nodes containing new image and apply the upgrade when I want to.

[snip]

>>> 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).
It was not agreed which way to go. I agree that first step should be to 
have specific images and don't deal with enabling/disabling services. 
It's outside the Icehouse timeframe, but for future direction, I am 
removing the enable/disable functionality from wireframes.

[snip]

>>> If the image is immediately created, what happens if the user tries to
>>> change the resource category counts while it's still being generated?
>>> That
>>> question applies both if we automatically update existing nodes as
>>> well as
>>> if we don't and the user is just quick moving around the UI.
This should never happen. Once heat stack is updating, you shouldn't be 
able to apply for other change.

>>> What do we do with old images from previous configurations of the
>>> resource
>>> category? If we don't clean them up, they can grow out of hand. If we
>>> automatically delete them when the new one is generated, what happens if
>>> there is an existing deployment in process and the image is deleted
>>> while it
>>> runs?
>>
>> Both these points are not as relevant given my earlier statement.
>> But, if I turn out to be wrong about that :), then I'd say that we
>> don't want to clean up old images automatically.  I don't like
>> surprises, even if I can configure how many old images to keep.  I
>> think that deleting should require manual intervention.
>
> It should be easy enough for us to resolve which resource categories
> (and their versions) have instances deployed against them and providing
> a UI for the user to clean up.
So, there is planned whole section called 'Image Management', where user 
will be able to manage images which are stored in Glance.

I think it is safe to say that we can immediately remove the association 
of image <> resource category (you just need to keep the image 
information on node level, what image was deployed). The image 
information at resource category level is relevant only for newly 
deployed nodes (to say what image is going to be provisioned), right?


>> Is resource category the same as role?  Sorry :), I probably need to
>> go back and re-read the terminology thread. If so, I think versioning
>> them in the Tuskar db makes sense. That way you know what's been
>> deployed and what hasn't, as well as any differences.
Yes, it is the same thing (Role == Resource Category). Huge confusion 
about terminology lately :)

Thanks guys
-- Jarda



More information about the OpenStack-dev mailing list