Open Stack

On 2014/13/01 13:15, Ladislav Smola wrote:
>> The usage of roles is new metric which doesn't exist. It is the most
>> consumed HW resource (which means if CPU is consumed by 60 % and RAM
>> or disk are less, then the role usage is 60 %). It would be great to
>> have such a metric from Ceilometer. However, I don't know how much
>> support they will give us. We can get partial metrics (CPU, RAM, Disk)
>> from Ceilometer, but the final Role usage is questionable.
>
> We will be able to get 3 meters avg. in one query, so we should be able
> to easily determine which metrics we want to show. As I am thinking
> about it, I would like to show what metric we are showing anyway. Cause
> naming 'capacity' as max(CPU, RAM, Disk) might be confusing.
Those 3 meters are correct. And exposing those 3 metrics at one overview 
page for quick glance is overwhelming for user. Important for him is to 
see, how much resources is left for my deployment/role. Showing them 3 
graphs instead of one is too much information if I don't want to look at 
detailed data.

That's why I think that 'role capacity' is important to show. And not 
just actual consumption but also historical data.

>>> - 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 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.
>>
>
> Hmm, I would rather see preview page, because it's quite dangerous
> operation. Though that's future talking.
Well - yes. But what we are talking at the moment is Icehouse timeframe 
and we don't have anything where to store the information about changes 
at the moment. And it would be pretty expensive operation. So that's why 
I said - focus on allow changes, apply immediately. Of course, the 
direction should go the way of preview all the changes and apply all 
together.


> "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" this should not
> be ever possible. All nodes under the Role has to be the same.
That is incorrect. Nodes can be heterogeneous. You can have multiple 
node profiles, you can have higher hw spec then spec of the node profile 
(flavor), so that node can be chosen as well, etc.

>
> I believe Jay was asking about the preview page. So if it won't be
> immediately updated, you would store what you want to update. Then you
> could even see it all summarized on a preview page before you hit 'update'.
Nope, I believe it was about keeping nodes with different settings in. I 
hope I answered the question before.


>> Related question is - when send heat change, are the nodes immediately
>> ready for use once each node is provisioned? Or... when node is
>> provisioned, it waits for the heat template to get finished and then
>> they all get to operation together?
>>
>
> I would say that it depends on node. E.g. once compute node is
> registered to overcloud nova scheduler, you can start to use it. So it
> should be similar for others. This applies only for stack-update.
I am asking in general. When I am doing my first deployment, are the 
nodes coming up being ready one by one or all at the same time once the 
process is finished?

When doing heat template change and changing number of nodes, are the 
nodes coming up one by one when they are ready? Or do they appear ready 
only after stack-update is finished?

(talking about all roles, not just compute)

-- Jarda