[openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes
Jaromir Coufal
jcoufal at redhat.com
Mon Jan 13 09:47:36 UTC 2014
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
More information about the OpenStack-dev
mailing list