[openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

Ladislav Smola lsmola at redhat.com
Mon Jan 13 12:15:34 UTC 2014


some answers inline:

On 01/13/2014 10:47 AM, Jaromir Coufal wrote:
> 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.

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.

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

Hmm, I would rather see preview page, because it's quite dangerous 
operation. Though that's future talking.

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

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

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

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.

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