Open Stack

Excerpts from Jiří Stránský's message of 2014-01-13 07:45:53 -0800:
> On 13.1.2014 11:43, 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).
> 
> Hmm i'm not sure i understand - what do you think by "best fit" here? 
> E.g. i have 32 GB RAM profile and 256 GB RAM profile in the compute role 
> (and i have unused machines available for both profiles), and i increase 
> compute node count by 2. What do i best-fit against?
> 

Currently nova-baremetal enforces an _exact_ match scheduler. So if we
have two nodes, 32G and 256G, and we try to create two servers in Nova
with the flavor that has 32G defined for RAM, Nova will fail to deploy
our second server.

> (Alternatively, if we want to support scaling a role using just one 
> spinner, even though the role has more profiles, maybe we could pick the 
> "largest" profile with unused nodes available?)
> 
> >
> > 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.
> 
> +1. I think we'll want the first approach to be at least possible (maybe 
> not default). As a cloud operator, when i want deploy 2 more compute 
> nodes, i imagine there are situations when i do care whether i'll get 
> additional 64 GB or additional 512 GB capacity.
> 

I believe Ironic will eventually have a different scheduler available
which may help with this. However, until then we just have to have a
flavor definition for every flavor of hardware that we want to address
differently. Note that the GB in the baremetal nodes pool is just a
number. One can certainly _say_ a box has 32G when it has 512G, and it
will go into the same pool.