Open Stack

On 07/12/2013 10:36 AM, Jonathan Proulx wrote:
> HI All,
>
> I'm on the verge of rearchitecting my openstack world, in parallel with
> my update to Grizzly (on Ubuntu 12.04 and kvm).
>
> What I *want* is a few sets of compute nodes with different scheduling
> and quotas, I *think* cells are the right concept to apply here.
>
> I need one set of nodes to schedule with a 1:1 physical:virtual ratio,
> an other using an over committed ratio (I'm thinking 8:1 in my
> environment) and in a perfect world a third that does bare metal
> provisioning both for TripleO purposes and for providing other baremetal
> systems directly to my user base.  Each would need it's own set of quotas.

It is that last requirement -- having separate quotas -- that makes both 
cells and host aggregates inappropriate here. Neither cells nor host 
aggregates allow you to manage quotas separate from the tenant's compute 
quotas.

> Leaving a side the OpenStack-on-OpenStack complexities for now (along
> with my abiding desire for a pony), does this model map well to the
> "cells" concept?

Actually, I believe the Host Aggregate concept is more inline with what 
you need. Cells are more about scaling the message queue and database 
infrastructure layers and allowing a more hierarchical scheduling 
algorithm that enables upper-level schedulers to defer scheduling 
decisions to the lower, cell-level schedulers.

 >  Can different cells have different hypervisors (I
> presume they can since they are independent novas other than api services)?

I believe they can, but I think host aggregates are more special-purpose 
than cells in this regard. Host aggregates along with the host aggregate 
instance type specs scheduler filter would allow you to direct certain 
flavors to certain host aggregates.

> Also it seems only the random scheduler is implemented at the cell
> level, according to the docs anyway,.  Can I pin flavors to a specific
> cell a-la host aggregates, or use host-aggregates in the cells to
> similar effect, or can I use "hints" or similar on instance creation to
> choose a cell?  Or should I start looking at poaching the filter scheduler
>
> Or I'm I looking in completely the wrong direction?

I think host aggregates is the way to go here, not cells, unless you are 
trying to solve scaling issues (doesn't sound like that's the case). But 
in either case, you will need to give up on the separate quota 
requirement -- either that, or create an entirely separate deployment 
zone for each of your "types" of nodes. That will give you per-type 
quotas (because each deployment zone would have a separate nova database 
and associated quota data set. But at that point, I'll welcome you to 
the wonderful world of shared identity and image databases :)

Best,
-jay

> It all looked so nice on the white board but I'm getting a bit nervous
> actually implementing it.
>
> Thanks,
> -Jon
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>