Cells: Aggregate support for Cells

Design it in similar fashion to instances and cells.

Aggregates belong to a cell but also need to be at the API level.

cell_name field added to aggregate model. Also add uuid to make it easier to sync between cells.

----- 8< -----
(matiu says)

There's a commit up for this already: https://review.openstack.org/#/c/25813/

It takes the approach of having an aggregate live inside a cell, and uses the cell @ syntax to specify the name of the aggregate, eg. spares@cell1 - gpus@cell2

I would welcome input, and be happy to change the commit to make it more acceptable to the community.

I think for host aggregates, it's probably better to have it all in the cell DB (similar to how services api is) rather than have a duplicated table in the DB (similar to instances). The reasons being:

 * There's likely unnoticeable speed loss by having a query talk to a cell:
   * The aggregate api would only need to do one request to get the whole list of hosts back
 * It's a lot less work and less code (the patch is already done)
 * I'd like to say something wise about DB duplication here, but I don't have anything ;)

----- 8< -----
(sorrison says)

Yeah I agree with you, would be interested in what Chris thinks about it?

One thing I want to be able to do is have the top level api aware of the aggregates so it can make scheduling decisions. Basically I want to be able to have a cell broadcast it's available availability_zones and then the cells scheduler be able to use that information when scheduling instances.
Maybe it could be done with capabilities though I'm thinking. Eg a cell could dynamically send up it's AZs in a capability.

Any ideas?

----- 8< -----
(matiu says)

The capabilities come from the cell's config file. However the capacities are generated on the fly from the cell's DB.

We could inject the AZs into capacities.

My only concern would be if there were a lot of AZs. There comes a point when you want to have data in the DB, rather than be pushing it around insed of rabbit.

I don't know how AZs are used, I can't imagine anyone having more than like 10 in a cell, but I guess it's possible.

There's the new cells weight and filters schedulers coming soon: https://review.openstack.org/#/c/16221/

So with that, one would first weigh and filter on the cell level. then again on the host level.

I imagine the final product would be, to make a cell level weight or filter, that asks the cells about AZs and caches the result maybe.

I really don't want to see the overhead of maintaining two copies of the table in both cells, if we can avoid it.

How about:

 * Let the existing patch through (with all data in the child cell)
 * Add a cell filter/weight that requests (and caches) AZ info from the child cell (and depends on comstud's patch)

So then if you care about filtering on AZs in the top level cell, you can install the cell level filter.

Gerrit topic: https://review.openstack.org/#q,topic:bp/cells-aggregate-support,n,z

Addressed by: https://review.openstack.org/25813
    Makes the host aggregate functionality work with cells

----- 8< -----
 Hi Mahesh, Russell, I have a patch for this working with master, can push it up unless you're working on it?

Cheers,
Sam

----- 8< -----
Hello Sam, I have assigned the BP to you, please push your patch for review.

Thanks,
Mahesh

Addressed by: https://review.openstack.org/59101
    Makes the host aggregate functionality work with cells

Apologies, this missed the deadline for Feature Freeze. Please rebase patches as soon as Juno opens, and we will try to get this in during that period. --johnthetubaguy (5th March 2014)

Unapproved - please re-submit via nova-spec --johnthetubagy (20th March 2014)