refined Compute adoption procedure #529
Conversation
| ** Default cell is renamed to `cell1` (in a multi-cell setup, it should become indexed as the last cell instead). | ||
| ** RabbitMQ transport URL no longer uses `guest`. | ||
| * The cell1 `nova` database and username become `nova_cell1`. | ||
| * The default cell is renamed to `cell1`. In a multi-cell setup, it should become indexed as the last cell instead. |
There was a problem hiding this comment.
@SeanMooney I’m not sure if we need to say “In a multi-cell setup, it should become indexed as the last cell instead.” This procedure is focused on a single cell configuration, so I suggest staying focused on that.
There was a problem hiding this comment.
that is debatable.
the Bogdan is currently working on the support for multiple compute cells
we are generally trying to remove the single cell and multi-cell disticiton form all of our docs
on of the open questions we are currently resolving is if we can have a common adoption procedure or not.
all OpenStack deployments have at least 2 cells
cell-0 which is reserved for instance that could not be scheduled to any host and some other internal nova usage and a compute cell typically called "cell-1" or sometimes "default"
when i refer to a comptue cell i mean a cell other then cell-0
or endgoal is to have one procedure for both cases since we will no longer be maintaining a difference in our docs for a cloud that only has 2 cells (cell-0 and either cell-1 or default) and a cloud that has more the two cells.
There was a problem hiding this comment.
I have discovered a regression in docs, which makes it disconnected from tests, see #490 (comment) (https://issues.redhat.com/browse/OSPRH-8656)
There was a problem hiding this comment.
regarding the multi-cell work in progress, I can make it rebasing on top of this, hopefully. Ideally though I agree this should be blocked on finishing the multi-cell guide in the PR that Sean has linked.
However, if this need to proceed now, feel free to just omit any confusing sections and statements related to multi-cell arch, as it was in flux by the time of writing, and still it is
There was a problem hiding this comment.
@bogdando This procedure is intended to be published in the adoption guide async after GA. It will likely be published before Feature Release 1, when the multi-cell feature is finished.
I'm inclined to do as you suggested: Remove any statements related to multi-cell and then merge. Let me know if anything else should be done.
There was a problem hiding this comment.
+1, i think this PR contains a bunch of refinements that are unrelated to the multi-cell situation? So ideally we wouln't prevent this from landing altogether.
There was a problem hiding this comment.
FYI @SeanMooney @bogdando @jistr : I hid/removed all multi-cell references. Let me know if I missed anything, or if you have additional comments on this procedure in general. Thank you!
There was a problem hiding this comment.
This guide refactoring should be done after fixing a regression discovered here #490 (comment)
klgill
force-pushed
the
Docs-Refine-Compute_Adoption
branch
from
b36713f
to
676fb8a
Compare
klgill
force-pushed
the
Docs-Refine-Compute_Adoption
branch
from
6bd5800
to
c2da16f
Compare
|
Build failed (check pipeline). Post https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/b1acc1ef0df84e6fa5fcdc8cb25e9b73 ❌ adoption-docs-preview POST_FAILURE in 1m 24s |
|
recheck |
https://issues.redhat.com/browse/RHOSPDOC-1719