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

Jaromir Coufal jcoufal at redhat.com
Mon Jan 13 10:37:11 UTC 2014


On 2014/10/01 19:02, Dougal Matthews wrote:
> Hi,
>
> Thanks for the wireframes and the walkthrough. Very useful. I've a few
> comments.
>
> - I'd like to echo the comments from the recording about "Role" I think
> the term probably isn't specific enough but I don't have a great
> suggestion. However, this is probably suited better to the other thread.

> - We will have a number of long processes, for example, when a deploy or
> re-size is happening. How do we keep the user informed of the progress
> and errors? I don't see anything in the wireframes, but maybe there is a
> Horizon standard approach I'm less familiar with. For example, I have 50
> compute nodes, then I add 10 but I want to know how many are ready etc.
That's correct, I already replied to Jay Dobies' mail on similar topic. 
I will try to visualize that process as well in wireframes in next days.

> - If I remove some instances, do I as the administrator need to care
> which are removed? Do we need to choose or be informed at the end?
This is great question on which we have long debates. I am convinced 
that I as administrator, do care which nodes I want to free up.

But current TripleO approach is using heat template and there we can 
just specify number of nodes of that specific role. So it means that I 
decrease from 10 to 9 instances and app will take care for us for some 
node to be removed (AFAIK heat removes the last added node).

So what we can do at the moment (until there is some way to specify 
which node to remove) is to inform user, which nodes were removed in the 
end... at least.

In the future, I'd like to enable user to have both ways available - 
just decrease number and let system to decide which nodes are going to 
be removed for him (but at least inform in advance which nodes are the 
chosen ones). Or, let user to choose by himself.

Thanks
-- Jarda



More information about the OpenStack-dev mailing list