Open Stack

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
> Tuskar?
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
> done.
>
> 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