Open Stack

On Fri, 13 Jan 2017 14:04:27 -0700, Alex Schultz wrote:
> Just from the puppet standpoint, it's much easier to create the cell
> and populate it after the fact and run some command to sync stuff
> after the nodes have been added.  This also would be easier to consume
> for scale up/scale down actions.  I'm pretty sure that's also the case
> if you're going to implement this in ansible or some other workflow
> tooling.  I think this is a cleaner path than having to preplan your
> computes, install them and then setup your cell.

Agreed this is the reasonable way for scale up/scale down to occur 
during deployment. The usual expectation for scale up/scale down is on a 
live system, so the compute hosts would be registered at the time you 
are creating cells (and the existing commands support this). But, we 
have a gap for the fresh install case and the scale up during deploy 
case. For others tuned in to this, there's a patch up [1] for a command 
that can create an empty cell, and the operator can add hosts to it at a 
later time. The expected use of the commands would be: at setup time, 
run 'map_cell0' to create cell0 for storage of instances that fail to 
schedule and 'create_cell' to create an empty cell intended for compute 
hosts. Then later after compute hosts are up and running, 
'discover_hosts' to associate hosts with a given cell.

> Thanks. We don't have to necessarily fix simple_cell_setup if it's
> working the way it's supposed to.  It seems that we're missing pieces
> and the knowledge around when we're supposed to run.  What made this
> worse was it seems that nova works without any cell v2 items on the
> fresh install but the upgrade has it as a hard requirement.

I think the current consensus is to leave 'simple_cell_setup' alone 
since it means "set up all the things" and if it can't, it should return 
1. Instead we'll add 'create_cell' to allow each piece to be run 
deliberately at the appropriate stages of a deployment. The 
'simple_cell_setup' was intended to be a lightweight way for people to 
setup things during an upgrade of an existing non-cells-v1 deployment.

> That seems
> like it should be made consistent and clearer for the end user to
> understand why something is failing. But I would say that anything
> that is going to be a hard requirement as part of an upgrade, it
> really should be documented prior to when it's made a hard
> requirement.  Just to share, I'd also like to point to
> https://review.openstack.org/#/c/267153/ which I was only made aware
> of today.  It seems like the start of the documentation that we needed
> around this process but hasn't been merged yet.  I would personally
> like to see that completed and merged prior to any new hard
> requirements get merged in.

I agree. I think the thought was that the release notes covered the 
upgrade requirement, but it's clear there wasn't enough info there. 
What's really needed is a small manual that describes each command and 
its use case, along with how-to steps for each common deployment 
scenario. We'll be working on writing that.

-melanie

[1] https://review.openstack.org/#/c/332713/