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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
