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

Jay Dobies jason.dobies at redhat.com
Mon Jan 13 15:46:21 UTC 2014

On 01/13/2014 05:43 AM, Jaromir Coufal wrote:
> On 2014/10/01 21:17, Jay Dobies wrote:
>> Another question:
>> - A Role (sounds like we're moving away from that so I'll call it
>> Resource Category) can have multiple Node Profiles defined (assuming I'm
>> interpretting the + and the tabs in the Create a Role wireframe
>> correctly). But I don't see anywhere where a profile is selected when
>> scaling the Resource Category. Is the idea behind the profiles that you
>> can select how much power you want to provide in addition to how many
>> nodes?
> Yes, that is correct, Jay. I mentioned that in walkthrough and in
> wireframes with the note "More views needed (for deploying, scaling,
> managing roles)".
> I would say there might be two approaches - one is to specify which node
> profile you want to scale in order to select how much power you want to
> add.
> The other approach is just to scale the number of nodes in a role and
> let system decide the best match (which node profile is chosen will be
> decided on the best fit, probably).
> I lean towards the first approach, where you specify what role and which
> node profile you want to use for scaling. However this is just
> introduction of the idea and I believe we can get answers until we get
> to that step.
> Any preferences for one of above mentioned approaches?

I lean towards the former as well. See the Domain Model Locations thread 
and Jay Pipes' response for an admin's use case that backs it up.

A few weeks ago, there was the giant thread that turned into manual v. 
automatic allocation[1]. The conversation used as an example a system 
that was heavily geared towards disk IO being specifically used for the 
storage-related roles.

Where I'm going with this is that I'm not sure it'll be enough to simply 
use some values for a node profile. I think we're going to need some way 
of identifying nodes as having a particular set of characteristics 
(totally running out of words here) and then saying that the new 
allocation should come from that type of node.

That's a long way of saying that I think an explicit step to say more 
about what we're adding is not only necessary, but potentially 
invalidates some of the wireframes as they exist today. I think over 
time, that is going to be much more complex than incrementing some numbers.

Don't get me wrong. I fully appreciate that we're still very early on 
and scoped to Icehouse for now. Need to start somewhere :)


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