[WIP] Multi-cell adoption #517

bogdando · 2024-07-03T10:52:26Z

Keep renaming 'default' cell consistent for single and multi cells:

Default becomes cellX (or it can be imported as is, for a multi-cell case only)
cell1 becomes mapped to openstack-cell1 osdp node set
cell2 becomes mapped to openstack-cell2 osdp node set, etc.
cellX (X=3 here) becomes mapped to openstack-cell3.
Alternatively, default cell retains its name for the openstack-default osdpns mapping

Evaluate podified MariaDB passwords for cells from osp-secret
to align the tests with documented commands. Remove no longer
needed podified DB password variable.

Make ansible and shell variables compute cells aware.
Split edpm nodes into compute cells by 1:1 mapping it as
dataplane nodesets.

Separate vars and secrets YAML values for the source and edpm
nodes to not confuse its different naming schemes for cells
in OSP/TripleO and RHOSO. This also allows adoption of the source
tripleo nodes into different EDPM nodes with another IPs but the
same FQDNs (those must remain unchanged as a strict requirement).

Remove edpm_computes vars no longer used after moving stopping
control-plane tripleo services into edpm-ansible

Remove cached fact for pulled OSP configuration as it can no longer
be generated in a multi-cell setup, where related shell variables
become bash arrays.
Depends-On: openstack-k8s-operators/install_yamls#826

JIRA OSPRH-6548

bogdando · 2024-07-08T12:59:49Z

The recent revision gives an overview to the approach taken, PTAL.
As long as we need to maintain the docs-as-code here, I'm afraid there would be no a cleaner solution than that.
For the ci-framework and rdo-jobs side of things, which should template all that in, I have WIP as well...
@jistr @SeanMooney

bogdando · 2024-07-08T13:00:53Z

docs_dev/assemblies/development_environment.adoc

+
+For that, you can also adjust as needed and use the following commands
+(instead of an example `rhos-release` commands, use a tool of your choice):
+


we could stop just by listing requirements, however, I prefer to give developers a more insight into examples

bogdando · 2024-07-08T13:03:02Z

docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc

@@ -26,6 +26,7 @@ here this time).
 ----
 PODIFIED_MARIADB_IP=$(oc get svc --selector "mariadb/name=openstack" -ojsonpath='{.items[0].spec.clusterIP}')
 PODIFIED_CELL1_MARIADB_IP=$(oc get svc --selector "mariadb/name=openstack-cell1" -ojsonpath='{.items[0].spec.clusterIP}')
+PODIFIED_CELL2_MARIADB_IP=$(oc get svc --selector "mariadb/name=openstack-cell1" -ojsonpath='{.items[0].spec.clusterIP}')


I'll figure a better solution for that

bogdando · 2024-07-08T13:03:51Z

docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc

+# ...
+
+# Replace with all members data for each MariaDB Galera cluster in the overcloud and additional cell stacks
+declare -A SOURCE_GALERA_MEMBERS_DEFAULT


this is a bit clumsy, but we don't really want to deal with nested dictionaries in bash, do we?

bogdando · 2024-07-08T13:06:46Z

docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc

@@ -50,42 +73,52 @@ export PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS=$(oc run mariadb-client
    'select uuid,name,transport_url,database_connection,disabled from cell_mappings;')
 echo "$PULL_OPENSTACK_CONFIGURATION_NOVADB_MAPPED_CELLS"
 ----
+
+Repeat the steps for additional compute cells by substituting `SOURCE_MARIADB_IP` and `SOURCE_DB_ROOT_PASSWORD`.


those "Repeat..." are going to be iterated instead, likely

bogdando · 2024-07-08T13:07:50Z

docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc

    "select host from nova.services where services.binary='nova-compute';")
 echo "$PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES"
 ----

-. Get the list of mapped the {compute_service} cells:
+. Get the list of mapped the {compute_service} cells, from any overcloud or compute cell controller host:


@SeanMooney from any of them, as I've noticed they all contain the same data

softwarefactory-project-zuul · 2024-07-08T13:09:34Z

This change depends on a change that failed to merge.

Change openstack-k8s-operators/install_yamls#826 is needed.

bogdando · 2024-07-08T13:10:17Z

docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc

 +
 ----
-export PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS=$($CONTROLLER1_SSH sudo podman exec -it nova_api nova-manage cell_v2 list_cells)
+export PULL_OPENSTACK_CONFIGURATION_NOVAMANAGE_CELL_MAPPINGS=$($CONTROLLER1_SSH sudo podman exec -it nova_conductor nova-manage cell_v2 list_cells)


note: there is no nova_api on cell controllers

bogdando · 2024-07-08T13:14:53Z

tests/vars.sample.yaml

-# EDPM node IP
-edpm_node_ip: 192.168.122.100 #CUSTOMIZE_THIS
+# EDPM node IPs, for each cell on the destination cloud
+edpm_node_ip:


@fao89 @marios an example of mapping cell computes into its own osdpns, FYI

softwarefactory-project-zuul · 2024-07-10T12:06:14Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/data-plane-adoption for 517,18b084c576712d289411bfab3a4bfee4b60a3fbf

softwarefactory-project-zuul · 2024-07-10T13:38:54Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/data-plane-adoption for 517,4687df731d7a30007950c91ac21ee931ebfebf8c

bogdando · 2024-07-11T11:54:06Z

Based on feedback from @SeanMooney, we should not shift cells names as I proposed here. We want it instead like this:

A single-cell adoption (only default cell exists): rename default to cell1,
A multi-cell ( default, cell1, etc. exist) - omit importing the default as there is no compute hosts supported to be there for a multi-cell OSP, hence nothing to adopt from it.
Or, a multi-cell ( default, cell1, etc. exist) - omit renaming the default cell, and import as is
Or, a multi-cell ( default, cell1, etc. exist) - rename default cell to the highest cell number + 1:

default -> cell4
cell1 -> cell1
cell2 -> cell2
cell3 -> cell3

Implementing either of these is quite challenging given the local requirement to maintain code in tests in the same form as it is documented (meaning shell commands). This sofisticated logic will bring in even more loops and arrays handling into already overcomplicated code proposed in this PR draft.

@jistr @gibizer looking for your ideas on that

gibizer · 2024-07-11T12:19:05Z

Based on feedback from @SeanMooney, we should not shift cells names as I proposed here. We want it instead like this:

A single-cell adoption (only default cell exists): rename default to cell1,

A multi-cell ( default, cell1, etc. exist) - omit importing the default as there is no compute hosts supported to be there for a multi-cell OSP, hence nothing to adopt from it.

Or, a multi-cell ( default, cell1, etc. exist) - omit renaming the default cell, and import as is

Or, a multi-cell ( default, cell1, etc. exist) - rename default cell to the highest cell number + 1:
default -> cell4
cell1 -> cell1
cell2 -> cell2
cell3 -> cell3
Implementing either of these is quite challenging given the local requirement to maintain code in tests in the same form as it is documented (meaning shell commands). This sofisticated logic will bring in even more loops and arrays handling into already overcomplicated code proposed in this PR draft.

@jistr @gibizer looking for your ideas on that

As nova-operator allows a cell to be named "default" the simplest solution would be your second proposal. Just import the cells as is. This has the benefit also that it will work even if a given customer wrongly attached computes to the default cell.
After GA nova-operator will get the ability to delete cells. So that feature can be used later to delete the "default" cell and therefore get the deployment structurally the same as a greenfield 18 deployment.

bogdando · 2024-07-11T12:26:43Z

I tend now to implement the last choice: for a multi-cell ( default, cell1, etc. exist) - rename default cell to the highest cell number + 1. This keeps it consistent for single cell and multicell...

/update: See the combined option which allows both renaming or importing as is

softwarefactory-project-zuul · 2024-07-11T12:32:39Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/data-plane-adoption for 517,9541ce7f013b9b35b2cbd681cb30259da1a85157

softwarefactory-project-zuul · 2024-07-11T13:11:14Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/data-plane-adoption for 517,54d110489b8215e014580b8b77b05ce107fd1e04

softwarefactory-project-zuul · 2024-07-11T13:26:17Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/data-plane-adoption for 517,9954245ae2addd169cc80deab137024b7046f30e

softwarefactory-project-zuul · 2024-07-12T13:48:32Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Unable to update github.com/openstack-k8s-operators/install_yamls

Keep renaming 'default' cell consistent for single and multi cells: * Default becomes cellX (or it can be imported as is, for a multi-cell case only) * cell1 becomes mapped to openstack-cell1 osdp node set * cell2 becomes mapped to openstack-cell2 osdp node set, etc. * cellX (X=3 here) becomes mapped to openstack-cell3. Alternatively, default cell retains its name for the openstack-default osdpns mapping Evaluate podified MariaDB passwords for cells from osp-secret to align the tests with documented commands. Remove no longer needed podified DB password variable. Make ansible and shell variables compute cells aware. Split edpm nodes into compute cells by 1:1 mapping it as dataplane nodesets. Separate vars and secrets YAML values for the source and edpm nodes to not confuse its different naming schemes for cells in OSP/TripleO and RHOSO. This also allows adoption of the source tripleo nodes into different EDPM nodes with another IPs but the same FQDNs (those must remain unchanged as a strict requirement). Remove edpm_computes vars no longer used after moving stopping control-plane tripleo services into edpm-ansible Remove cached fact for pulled OSP configuration as it can no longer be generated in a multi-cell setup, where related shell variables become bash arrays. Signed-off-by: Bohdan Dobrelia <bdobreli@redhat.com>

softwarefactory-project-zuul · 2024-07-15T13:37:18Z

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Error merging github.com/openstack-k8s-operators/data-plane-adoption for 517,b946bca930ed67ffe94465e36e742abd9ba55d95

bogdando added the do-not-merge/hold label Jul 3, 2024

bogdando changed the title ~~Multi-cell adoption~~ [WIP] Multi-cell adoption Jul 3, 2024

bogdando force-pushed the multi-cell branch from 0b11b12 to cae15a5 Compare July 8, 2024 12:58

bogdando commented Jul 8, 2024

View reviewed changes

bogdando force-pushed the multi-cell branch from cae15a5 to 18b084c Compare July 10, 2024 12:06

bogdando force-pushed the multi-cell branch from 18b084c to 4687df7 Compare July 10, 2024 13:38

bogdando force-pushed the multi-cell branch from 4687df7 to 9541ce7 Compare July 11, 2024 12:32

bogdando force-pushed the multi-cell branch from 9541ce7 to 54d1104 Compare July 11, 2024 13:11

bogdando force-pushed the multi-cell branch from 54d1104 to 9954245 Compare July 11, 2024 13:26

bogdando force-pushed the multi-cell branch from 9954245 to 1f42de7 Compare July 12, 2024 13:47

SeanMooney mentioned this pull request Jul 12, 2024

refined Compute adoption procedure #529

Open

bogdando force-pushed the multi-cell branch from 1f42de7 to b946bca Compare July 15, 2024 13:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Multi-cell adoption #517

[WIP] Multi-cell adoption #517

bogdando commented Jul 3, 2024 •

edited

Loading

bogdando commented Jul 8, 2024

bogdando Jul 8, 2024

bogdando Jul 8, 2024

bogdando Jul 8, 2024

bogdando Jul 8, 2024

bogdando Jul 8, 2024

softwarefactory-project-zuul bot commented Jul 8, 2024

bogdando Jul 8, 2024

bogdando Jul 8, 2024

softwarefactory-project-zuul bot commented Jul 10, 2024

softwarefactory-project-zuul bot commented Jul 10, 2024

bogdando commented Jul 11, 2024

gibizer commented Jul 11, 2024

bogdando commented Jul 11, 2024 •

edited

Loading

softwarefactory-project-zuul bot commented Jul 11, 2024

softwarefactory-project-zuul bot commented Jul 11, 2024

softwarefactory-project-zuul bot commented Jul 11, 2024

softwarefactory-project-zuul bot commented Jul 12, 2024

softwarefactory-project-zuul bot commented Jul 15, 2024


		For that, you can also adjust as needed and use the following commands
		(instead of an example `rhos-release` commands, use a tool of your choice):

[WIP] Multi-cell adoption #517

Are you sure you want to change the base?

[WIP] Multi-cell adoption #517

Conversation

bogdando commented Jul 3, 2024 • edited Loading

bogdando commented Jul 8, 2024

bogdando Jul 8, 2024

Choose a reason for hiding this comment

bogdando Jul 8, 2024

Choose a reason for hiding this comment

bogdando Jul 8, 2024

Choose a reason for hiding this comment

bogdando Jul 8, 2024

Choose a reason for hiding this comment

bogdando Jul 8, 2024

Choose a reason for hiding this comment

softwarefactory-project-zuul bot commented Jul 8, 2024

bogdando Jul 8, 2024

Choose a reason for hiding this comment

bogdando Jul 8, 2024

Choose a reason for hiding this comment

softwarefactory-project-zuul bot commented Jul 10, 2024

softwarefactory-project-zuul bot commented Jul 10, 2024

bogdando commented Jul 11, 2024

gibizer commented Jul 11, 2024

bogdando commented Jul 11, 2024 • edited Loading

softwarefactory-project-zuul bot commented Jul 11, 2024

softwarefactory-project-zuul bot commented Jul 11, 2024

softwarefactory-project-zuul bot commented Jul 11, 2024

softwarefactory-project-zuul bot commented Jul 12, 2024

softwarefactory-project-zuul bot commented Jul 15, 2024

bogdando commented Jul 3, 2024 •

edited

Loading

bogdando commented Jul 11, 2024 •

edited

Loading