Open Stack

Hello,

some answers below:

On 01/10/2014 05:18 PM, 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?

Definitely Ceilometer, though right now it can't do this aggregate 
query. Though it is in progress and it 'should land' early I3. Not sure 
if the backup plan should be computing it in the Tuskar.

> - When on the change deployments screen, after making a change but not 
> yet applying it, how are the projected capacity changes calculated?

I believe we wanted to make just simple algorithm, that was considering, 
that adding a new node would would spread the load between the nodes 
equally. Though this depends on how overcloud is set.
It would have to be set the way, that after adding new hardware, 
overcloud would migrate VM's over them equally(which is not always 
achievable).
So I am not really sure about this part.

>
> - For editing a role, does it make a new image with the changes to 
> what services are deployed each time it's saved?

I would say no, image should be created during heat stack update/create, 
right? So we would need to track it has been changed but not yet deployed.

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

We will have to store image metadata in tuskar probably, that would map 
to glance, once the image is generated. I would say we need to store the 
list of the elements and probably the commit hashes (because elements 
can change). Also it should be versioned, as the images in glance will 
be also versioned.
We can't probably store it in the Glance, cause we will first store the 
metadata, then generate image. Right?

Then we could see whether image was created from the metadata and 
whether that image was used in the heat-template. With versions we could 
also see what has changed.

But there was also idea that there will be some generic image, 
containing all services, we would just configure which services to 
start. In that case we would need to version also this.

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


Agree, this is missing. I think right now we are able to show that stack 
is being deployed and how many nodes are already deployed. Page like 
this will be quite important for I.

>
>
> 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).
>
>
> On 01/10/2014 09:58 AM, Jaromir Coufal wrote:
>> Hi everybody,
>>
>> there is first stab of Deployment Management section with future
>> direction (note that it was discussed as a scope for Icehouse).
>>
>> I tried to add functionality in time and break it down to steps. This
>> will help us to focus on one functionality at a time and if we will be
>> in time pressure for Icehouse release, we can cut off last steps.
>>
>> Wireframes:
>> http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-10_tripleo-ui_deployment-management.pdf 
>>
>>
>>
>> Recording of walkthrough:
>> https://www.youtube.com/watch?v=9ROxyc85IyE
>>
>> We sare about to start with first step as soon as possible, so please
>> focus on our initial steps the most (which doesn't mean that we should
>> neglect the direction).
>>
>> Every feedback is very welcome, thanks
>> -- Jarda
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev