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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
