From 1319d485cedb348c67918dd58e07bdf91bb76092 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Elvira=20Garc=C3=ADa?= Date: Wed, 18 Dec 2024 17:32:24 +0100 Subject: [PATCH] Add IPv6 adoption documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This includes steps on how to deploy an environment for adoption and guides to use ipv6. Resolves: #OSPRH-4223 Signed-off-by: Elvira García --- .../assemblies/development_environment.adoc | 242 ++++++++++++++++++ ...ge-service-with-block-storage-backend.adoc | 4 + ...pting-image-service-with-ceph-backend.adoc | 4 + ...opting-image-service-with-nfs-backend.adoc | 4 + ...e-service-with-object-storage-backend.adoc | 4 + .../proc_adopting-key-manager-service.adoc | 4 + ...oc_adopting-the-block-storage-service.adoc | 4 + .../proc_adopting-the-compute-service.adoc | 4 + .../proc_adopting-the-networking-service.adoc | 4 + ...c_adopting-the-object-storage-service.adoc | 4 + .../proc_adopting-the-placement-service.adoc | 4 + .../proc_configuring-a-ceph-backend.adoc | 4 + .../proc_deploying-backend-services.adoc | 16 ++ ...ng-file-systems-service-control-plane.adoc | 4 + ...g-the-bare-metal-provisioning-service.adoc | 6 +- ...rating-databases-to-mariadb-instances.adoc | 1 + ...pology-specific-service-configuration.adoc | 20 ++ .../modules/proc_using-new-subnet-ranges.adoc | 3 + 18 files changed, 335 insertions(+), 1 deletion(-) diff --git a/docs_dev/assemblies/development_environment.adoc b/docs_dev/assemblies/development_environment.adoc index 89b1fdd71..27e5f5001 100644 --- a/docs_dev/assemblies/development_environment.adoc +++ b/docs_dev/assemblies/development_environment.adoc @@ -39,6 +39,12 @@ make download_tools == Deploying CRC +[WARNING] +If you want to deploy using IPv6, our current way of deploying a +lightweight OCP environment is with Single Node Openshift (SNO) instead of CRC. +See section at the bottom of the page for IPv6 development environment +deployment. + === CRC environment for virtual workloads [,bash] @@ -580,3 +586,239 @@ https://openstack-k8s-operators.github.io/data-plane-adoption/user/#adopting-the may now follow other Data Plane Adoption procedures described in the https://openstack-k8s-operators.github.io/data-plane-adoption[documentation]. The same pattern can be applied to other services. + +== Deploying an IPv6 environment + +In order to perform an adoption with IPv6, we will need an Openshift node (SNO +instead of CRC in this case), an IPv6 control plane Openstack environment, and +some extra settings we will see through this section. + +=== IPv6 Lab + +As a prerrequisite, make sure you have `systemd-resolved` configured for DNS +resolution. + +[,bash] +---- +dnf install -y systemd-resolved +systemctl enable --now systemd-resolved +ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf +---- + +We should also have Virtualization Tools installed (`libvirt` and `qemu`), and +the username you are going to use added to the `libvirt` and `qemu` group. + +[,bash] +---- +sudo usermod -a -G libvirt,qemu +---- + +Furthermore, you should have an RSA key generated to use as identification to +access your SNO. + +If you did not have libvirt installed, there is a chance that you don't have a +default pool defined in libvirt. If that is the case, you can define it with +the following commands + +[,bash] +---- +cat > /tmp/default-pool.xml < + default + + /var/lib/libvirt/images + + 0711 + 0 + 0 + + + + +EOF +sudo virsh pool-define default-pool.xml +sudo virsh pool-start default +---- + +Once all the prerrequisites are present, you can go ahead and use the `install_yamls` +repository to install the IPv6Lab from the `devsetup` folder. Steps are taken from the +https://github.com/openstack-k8s-operators/install_yamls/tree/main/devsetup[install_yamls devsetup README]: + +[,bash] +---- +cd /devsetup +export NETWORK_ISOLATION_NET_NAME=net-iso +export NETWORK_ISOLATION_IPV4=false +export NETWORK_ISOLATION_IPV6=true +export NETWORK_ISOLATION_INSTANCE_NAME=sno +export NETWORK_ISOLATION_IP_ADDRESS=fd00:aaaa::10 +export NNCP_INTERFACE=enp7s0 + +make ipv6_lab # Set up the needed networking setup (NAT64 bridge) + +make network_isolation_bridge # Create the network-isolation network + +make attach_default_interface # Attach the network-isolation bridge to SNO +---- + +To be able to access the SNO lab you need to source the SNO environment. After that you will be able to use `oc` commands: + +[,bash] +---- +source /home//.ipv6lab/sno_env +oc login -u admin -p 12345678 https://api.sno.lab.example.com:6443 +---- +You can also ssh the SNO for debugging purposes: +[,bash] +---- +ssh -i ~/.ssh/id_rsa core@fd00:aaaa::10 +---- + +=== Deploying TripleO Standalone with IPv6 + +[WARNING] +There is still no official setup, but in this https://github.com/karelyatin/install_yamls/commit/8151634183fe1302383a98e0e9f0779b68232ad6[fork of install_yamls] +there is a commit that can be used in order to deploy it successfully. + +The steps to deploy would be (assuming you are using https://github.com/karelyatin/install_yamls/commit/8151634183fe1302383a98e0e9f0779b68232ad6[this commit]): + +[,bash] +---- +sudo chmod 777 /var/lib/libvirt/images #This might be needed to download the images +cat > /tmp/additional_nets.json < mtu 1500 qdisc noqueue state UP group default qlen 1000 + link/ether 52:54:00:f9:af:e4 brd ff:ff:ff:ff:ff:ff + inet 192.168.122.3/24 scope global net-iso + valid_lft forever preferred_lft forever + inet6 fd00:aaaa::1/64 scope global + valid_lft forever preferred_lft forever + inet6 fe80::5054:ff:fef9:afe4/64 scope link + valid_lft forever preferred_lft forever + +ip route +# Output + +192.168.122.0/24 dev net-iso proto kernel scope link src 192.168.122.3 +---- + +On the standalone: +[,bash] +---- +ip a show br-ctlplane +# Output +5: br-ctlplane: mtu 1500 qdisc noqueue state UNKNOWN g +roup default qlen 1000 + link/ether 52:54:00:46:72:c6 brd ff:ff:ff:ff:ff:ff + inet 192.168.122.4/24 scope global br-ctlplane + valid_lft forever preferred_lft forever + inet6 fd00:aaaa::99/128 scope global + valid_lft forever preferred_lft forever + inet6 fd00:aaaa::100/64 scope global + valid_lft forever preferred_lft forever + inet6 fe80::5054:ff:fe46:72c6/64 scope link + valid_lft forever preferred_lft forever + +ip route +# Output +192.168.122.0/24 dev br-ctlplane proto kernel scope link src 192.168.122.4 +---- + +=== Further steps + +From here, the steps should be similar to the IPv4 adoption. Note that every +command that requires access to the standalone VM via SSH (i.e. when creating a workload) should be done using +a different address: + +[,bash] +---- +OS_CLOUD_IP=fd00:aaaa::100 +---- + +And, when installing operators, use: +[,bash] +---- +scp -6 -i ~/install_yamls/out/edpm/ansibleee-ssh-key-id_rsa root@[fd00:aaaa::100]:/root/tripleo-standalone-passwords.yaml ~/ +---- diff --git a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc index 7ae9fe243..11025667d 100644 --- a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc +++ b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc @@ -33,6 +33,10 @@ spec . Create a new file, for example `glance_cinder.patch`, and include the following content: + +[NOTE] +If you are using IPv6, remember to change the load balancer IP to one that is correct in your environment. + +E.g: `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80` ++ ---- spec: glance: diff --git a/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc index 5a942ce4e..3086c64bd 100644 --- a/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc +++ b/docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc @@ -11,6 +11,10 @@ Adopt the {image_service_first_ref} that you deployed with a {Ceph} back end. Us the `openstack` namespace and that the `extraMounts` property of the `OpenStackControlPlane` custom resource (CR) is configured properly. For more information, see xref:configuring-a-ceph-backend_migrating-databases[Configuring a Ceph back end]. + +[NOTE] +If you are using IPv6, remember to change the load balancer IP to one that is correct in your environment. + +E.g: `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80` ++ ---- $ cat << EOF > glance_patch.yaml spec: diff --git a/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc index 7b35b5346..846f50d28 100644 --- a/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc +++ b/docs_user/modules/proc_adopting-image-service-with-nfs-backend.adoc @@ -62,6 +62,10 @@ tenant true false ["172.19.0.80-172.19.0.90"] . Adopt the {image_service} and create a new `default` `GlanceAPI` instance that is connected with the existing NFS share: + +[NOTE] +If you are using IPv6, remember to change the load balancer IP to one that is correct in your environment. + +E.g: `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80` ++ ---- $ cat << EOF > glance_nfs_patch.yaml diff --git a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc index 3efc63261..03c22eb48 100644 --- a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc +++ b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc @@ -31,6 +31,10 @@ spec . Create a new file, for example, `glance_swift.patch`, and include the following content: + +[NOTE] +If you are using IPv6, remember to change the load balancer IP to one that is correct in your environment. + +E.g: `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80` ++ ---- spec: glance: diff --git a/docs_user/modules/proc_adopting-key-manager-service.adoc b/docs_user/modules/proc_adopting-key-manager-service.adoc index d9ba59b08..fedac3a06 100644 --- a/docs_user/modules/proc_adopting-key-manager-service.adoc +++ b/docs_user/modules/proc_adopting-key-manager-service.adoc @@ -22,6 +22,10 @@ $ oc set data secret/osp-secret "BarbicanSimpleCryptoKEK=$($CONTROLLER1_SSH "pyt . Patch the `OpenStackControlPlane` CR to deploy the {key_manager}: + +[NOTE] +If you are using IPv6, remember to change the load balancer IP to one that is correct in your environment. + +E.g: `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80` ++ ---- $ oc patch openstackcontrolplane openstack --type=merge --patch ' spec: diff --git a/docs_user/modules/proc_adopting-the-block-storage-service.adoc b/docs_user/modules/proc_adopting-the-block-storage-service.adoc index bf2f00db8..d71734bcc 100644 --- a/docs_user/modules/proc_adopting-the-block-storage-service.adoc +++ b/docs_user/modules/proc_adopting-the-block-storage-service.adoc @@ -31,6 +31,10 @@ $ oc patch openstackcontrolplane openstack --type=merge --patch-file= ~/manila.patch diff --git a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc index 872e6af91..b0f7d94bd 100644 --- a/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc +++ b/docs_user/modules/proc_deploying-the-bare-metal-provisioning-service.adoc @@ -34,7 +34,11 @@ $ alias openstack="oc exec -t openstackclient -- openstack" . Patch the `OpenStackControlPlane` custom resource (CR) to deploy the {bare_metal}: + -[source,yaml] +[NOTE] +If you are using IPv6, remember to change the load balancer IP to one that is correct in your environment. + +E.g: `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80` ++ +[source,bash] ---- $ oc patch openstackcontrolplane openstack -n openstack --type=merge --patch ' spec: diff --git a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc index d61f5a053..210457559 100644 --- a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc +++ b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc @@ -40,6 +40,7 @@ endif::[] # Replace with your environment's MariaDB Galera cluster VIP and backend IPs: SOURCE_MARIADB_IP=172.17.0.2 declare -A SOURCE_GALERA_MEMBERS +# If using IPv6, don't declare addresses within brackets SOURCE_GALERA_MEMBERS=( ["standalone.localdomain"]=172.17.0.100 # ... diff --git a/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc b/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc index 1ca8ddb48..0677dea2d 100644 --- a/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc +++ b/docs_user/modules/proc_retrieving-topology-specific-service-configuration.adoc @@ -11,6 +11,8 @@ Before you migrate your databases to the {rhos_long} control plane, retrieve the .Prerequisites * Define the following shell variables. Replace the example values with values that are correct for your environment: +[NOTE] +If you need to use IPv6, declare `SOURCE_MARIADB_IP` *without* brackets (e.g. `SOURCE_MARIADB_IP=fd00:bbbb::2`) + ---- ifeval::["{build}" != "downstream"] @@ -40,6 +42,13 @@ $ grep -rI 'listen mysql' -A10 /var/lib/config-data/puppet-generated/ | grep bin .Procedure +. Make sure you are on the `openstack` namespace. ++ +---- +oc project openstack +---- ++ + . Export the shell variables for the following outputs and test the connection to the {OpenStackShort} database: + ---- @@ -50,6 +59,17 @@ echo "$PULL_OPENSTACK_CONFIGURATION_DATABASES" + [NOTE] The `nova`, `nova_api`, and `nova_cell0` databases are included in the same database host. ++ +[WARNING] +==== +In case that this command fail, it may be due to the fact that the MariaDB container needs a bit more time. If that happens, you can use a sleep: + +---- +export PULL_OPENSTACK_CONFIGURATION_DATABASES=$(oc run mariadb-client ${MARIADB_CLIENT_ANNOTATIONS} -q --image ${MARIADB_IMAGE} -i --rm --restart=Never -- \ + bash -c 'sleep 5 && mysql -rsh '$SOURCE_MARIADB_IP' -uroot -p'$SOURCE_DB_ROOT_PASSWORD' -e "SHOW databases;"') +---- +==== + . Run `mysqlcheck` on the {OpenStackShort} database to check for inaccuracies: + diff --git a/docs_user/modules/proc_using-new-subnet-ranges.adoc b/docs_user/modules/proc_using-new-subnet-ranges.adoc index 8675ecf3d..3364539a0 100644 --- a/docs_user/modules/proc_using-new-subnet-ranges.adoc +++ b/docs_user/modules/proc_using-new-subnet-ranges.adoc @@ -2,6 +2,9 @@ = Configuring new subnet ranges +[NOTE] +If you are using IPv6, you can most likely reuse existing subnet ranges, which you can check in the section <>. + You can define new IP ranges for control plane services that belong to a different subnet that is not used in the existing cluster. Then you configure link local IP routing between the existing and new subnets to enable existing and new service deployments to communicate. This involves using the {OpenStackPreviousInstaller} mechanism on a pre-adopted cluster to configure additional link local routes. This enables the data plane deployment to reach out to {rhos_prev_long} ({OpenStackShort}) nodes by using the existing subnet addresses. You can use new subnet ranges with any existing subnet configuration, and when the existing cluster subnet ranges do not have enough free IP addresses for the new control plane services. You must size the new subnet appropriately to accommodate the new control