Hi Jay,

thanks for your questions, they are great. I am going to answer inline:

On 2014/10/01 17:18, Jay Dobies wrote:
Thanks for recording this. A few questions:

- I'm guessing the capacity metrics will come from Ceilometer. Will
Ceilometer provide the averages for the role or is that calculated by
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.

- When on the change deployments screen, after making a change but not
yet applying it, how are the projected capacity changes calculated?
At the moment, I am working with one time change. Which means - it appears in modal window, and if I don't apply the change, it will get canceled. So we don't have to store 'change' values anyhow. At least for now.

- For editing a role, does it make a new image with the changes to what
services are deployed each time it's saved?
So, there are two things - one thing is provisioning image. We are not dealing with image builder at the moment. So the image already contains services which we should be able to discover (what OpenStack services are included there). And then you go to service tab and enable/disable which services are provided within a role + their configuration.

I would expect, that each time I change some Role settings, it gets applied (which might mean re-provisioning nodes if needed). However, I think it is only the case when you change provisioning image.

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

- I don't see any indication that the role scaling process is taking
place. That's a potentially medium/long running operation, we should
have some sort of way to inform the user it's running and if any errors
took place.
That's correct, I didn't provide that view yet. I was more focusing on views with settings and cofnig then the flow. But I will add this view as well. I completely agree it is needed.

That last point is a bit of a concern for me. I like the simplicity of
what the UI presents, but the nature of what we're doing doesn't really
fit with that. I can click the count button to add 20 nodes in a few
seconds, but the execution of that is a long running, asynchronous
operation. We have no means of reflecting that it's running, nor finding
any feedback on it as it runs or completes.
As I mentioned above, yeah, you are right here. I will reflect that.

Related question. If I have 20 instances and I press the button to scale
it out to 50, if I immediately return to the My Deployment screen what
do I see? 20, 50, or the current count as they are stood up?
I'll try to send the screen soon.

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?

It could all be written off as a future feature, but I think we should
at least start to account for it in the wireframes. The initial user
experience could be off putting if it's hard to discern the difference
between what I told the UI to do and when it's actually finished being

It's also likely to influence the ultimate design as we figure out who
keeps track of the running operations and their results (for both simple
display purposes to the user and auditing reasons).

One more time, thanks a lot for all the question Jay, they help to clarify lot of details in the background.

-- Jarda

OpenStack-dev mailing list

Reply via email to