You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs_user/assemblies/assembly_adopting-the-image-service.adoc
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ To complete the {image_service} adoption, ensure that your environment meets the
21
21
* You have a Single Node OpenShift or OpenShift Local that is running in the {rhocp_long} cluster.
22
22
* Optional: You can reach an internal/external `Ceph` cluster by both `crc` and {OpenStackPreviousInstaller}.
23
23
24
-
If you have image quotas in {OpenStackShort} {rhos_prev_ver}, these quotas are transferred to {rhos_long} {rhos_curr_ver} because the image quota system in {rhos_curr_ver} is disabled by default. For more information about enabling image quotas in {rhos_curr_ver}, see link:{defaultURL}/customizing_persistent_storage/assembly_glance-customizing-the-image-service_customizing-cinder#assembly_glance-configuring-quotas_configuring-glance[Configuring image quotas] in _Customizing persistent storage_. If you enable image quotas in {rhos_acro} {rhos_curr_ver}, the new quotas replace the legacy quotas from {OpenStackShort} {rhos_prev_ver}.
24
+
If you have image quotas in {OpenStackShort} {rhos_prev_ver}, these quotas are transferred to {rhos_long} {rhos_curr_ver} because the image quota system in {rhos_curr_ver} is disabled by default. If you enable image quotas in {rhos_acro} {rhos_curr_ver}, the new quotas replace the legacy quotas from {OpenStackShort} {rhos_prev_ver}.
Before you begin replicating your existing VLAN and IPAM configuration in the {rhos_long} environment, you must have the following IP address allocations for the new control plane services:
12
12
13
-
* 1 IP address for each isolated network on each {rhocp_long} worker node. You configure these IP addresses in the `NodeNetworkConfigurationPolicy` custom resources (CRs) for the {OpenShiftShort} worker nodes. For more information, see xref:configuring-openshift-worker-nodes_isolated-networks[Configuring {OpenShiftShort} worker nodes].
14
-
* 1 IP range for each isolated network for the data plane nodes. You configure these ranges in the `NetConfig` CRs for the data plane nodes. For more information, see xref:configuring-data-plane-nodes_isolated-networks[Configuring data plane nodes].
13
+
* 1 IP address for each isolated network on each {rhocp_long} worker node. You configure these IP addresses in the `NodeNetworkConfigurationPolicy` custom resources (CRs) for the {OpenShiftShort} worker nodes.
14
+
* 1 IP range for each isolated network for the data plane nodes. You configure these ranges in the `NetConfig` CRs for the data plane nodes.
15
15
* 1 IP range for each isolated network for control plane services. These ranges
16
-
enable pod connectivity for isolated networks in the `NetworkAttachmentDefinition` CRs. For more information, see xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services].
17
-
* 1 IP range for each isolated network for load balancer IP addresses. These IP ranges define load balancer IP addresses for MetalLB in the `IPAddressPool` CRs. For more information, see xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services].
16
+
enable pod connectivity for isolated networks in the `NetworkAttachmentDefinition` CRs.
17
+
* 1 IP range for each isolated network for load balancer IP addresses. These IP ranges define load balancer IP addresses for MetalLB in the `IPAddressPool` CRs.
18
18
19
19
[NOTE]
20
20
The exact list and configuration of isolated networks in the following procedures should reflect the actual {rhos_prev_long} environment. The number of isolated networks might differ from the examples used in the procedures. The IPAM scheme might also differ. Only the parts of the configuration that are relevant to configuring networks are shown. The values that are used in the following procedures are examples. Use values that are specific to your configuration.
Copy file name to clipboardExpand all lines: docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc
+10-9Lines changed: 10 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,22 +20,23 @@ Perform the following tasks to incorporate the existing network configuration:
20
20
21
21
When configuring nodes and services, the general approach is as follows:
22
22
23
-
* For IPAM, you can either reuse subnet ranges from the existing deployment or, if there is a shortage of free IP addresses in existing subnets, define new ranges for the new control plane services. If you define new ranges, you configure IP routing between the old and new ranges. For more information, see xref:planning-your-ipam-configuration_configuring-network[Planning your IPAM configuration].
24
-
ifeval::["{build_variant}" == "ospdo"]
25
-
For more information about creating networks for a director Operator environment, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_creating-an-overcloud-network-with-the-openstacknetconfig-CRD_OSPdO-networks[Creating networks with director Operator] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_.
26
-
endif::[]
23
+
* For IPAM, you can either reuse subnet ranges from the existing deployment or, if there is a shortage of free IP addresses in existing subnets, define new ranges for the new control plane services. If you define new ranges, you configure IP routing between the old and new ranges.
27
24
* For VLAN tags, always reuse the configuration from the existing deployment.
28
25
29
-
[NOTE]
30
-
For more information about the network architecture and configuration, see
31
-
link:{deploying-rhoso}/assembly_preparing-rhoso-networks[Preparing networks for Red Hat OpenStack Services on OpenShift] in _{deploying-rhoso-t}_ and link:{defaultOCPURL}/networking/about-networking[About networking] in _Networking_.
* xref:planning-your-ipam-configuration_configuring-network[Planning your IPAM configuration]
35
+
ifeval::["{build_variant}" == "ospdo"]
36
+
* link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_creating-an-overcloud-network-with-the-openstacknetconfig-CRD_OSPdO-networks[Creating networks with director Operator].
37
+
endif::[]
38
+
* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_red_hat_openstack_services_on_openshift/assembly_preparing-rhoso-networks_preparing[Preparing networks for Red Hat OpenStack Services on OpenShift]
Copy file name to clipboardExpand all lines: docs_user/assemblies/assembly_migrating-ceph-cluster.adoc
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,9 @@ Ganesha. To migrate your {CephCluster} cluster, you must decommission the
29
29
Controller nodes and move the {Ceph} daemons to a set of target nodes that are
30
30
already part of the {CephCluster} cluster.
31
31
32
-
Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites].
32
+
== Prerequisites
33
+
34
+
* Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see "{Ceph} prerequisites" in the Adoption overview chapter.
Copy file name to clipboardExpand all lines: docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,10 +20,16 @@ Ceph Manager. With {OpenStackPreviousInstaller}-deployed {Ceph}, the {Ceph} Dash
20
20
The {Ceph} Dashboard containers are included through `tripleo-container-image-prepare` parameters, and high availability (HA) relies
21
21
on `HAProxy` and `Pacemaker` to be deployed on the {rhos_prev_long} ({OpenStackShort}) environment. For an external {CephCluster} cluster, HA is not supported.
22
22
23
-
You migrate and relocate the Ceph Monitoring components to free Controller nodes. Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites].
23
+
== Prerequisites
24
+
You migrate and relocate the Ceph Monitoring components to free Controller nodes. Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see "{Ceph} prerequisites" in the "Adoption overview" chapter.
Copy file name to clipboardExpand all lines: docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,11 +14,16 @@ included in the {rhos_prev_long} control plane into the existing external Red
14
14
Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include
15
15
the Compute nodes for an HCI environment or dedicated storage nodes.
16
16
17
-
Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites].
17
+
== Prerequisites
18
+
Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter.
For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, you must migrate the Ceph Object Gateway (RGW) daemons that are included in the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
12
12
13
-
Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites].
13
+
== Prerequisites
14
+
15
+
Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter.
If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long_noacro} nodes.
12
12
13
-
If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see xref:ceph-migration_adopt-control-plane[Migrate the {Ceph} cluster]. If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in xref:deploying-a-ceph-ingress-daemon_migrating-ceph-rgw[Deploying a Ceph ingress daemon] and xref:updating-the-object-storage-endpoints_migrating-ceph-rgw[Create or update the Object Storage service endpoints].
13
+
If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see "Migrating the {Ceph} cluster". If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in "Deploying a Ceph ingress daemon" and "Create or update the Object Storage service endpoints".
14
14
15
15
The data migration happens replica by replica. For example, if you have 3 replicas, move them one at a time to ensure that the other 2 replicas are still operational, which enables you to continue to use the {object_storage} during the migration.
Copy file name to clipboardExpand all lines: docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,13 +45,17 @@ to be deployed, their replica numbers, and the number of {OpenShiftShort} worker
45
45
46
46
Additional IP addresses might be required in future {OpenStackShort} releases, so you must plan for some extra capacity for each of the allocation pools that are used in the new environment.
47
47
48
-
After you determine the required IP pool size for the new deployment, you can choose to define new IP address ranges or reuse your existing IP address ranges. Regardless of the scenario, the VLAN tags in the existing deployment are reused in the new deployment. Ensure that the VLAN tags are properly retained in the new configuration. For more information, see xref:configuring-isolated-networks_configuring-network[Configuring isolated networks].
48
+
After you determine the required IP pool size for the new deployment, you can choose to define new IP address ranges or reuse your existing IP address ranges. Regardless of the scenario, the VLAN tags in the existing deployment are reused in the new deployment. Ensure that the VLAN tags are properly retained in the new configuration.
0 commit comments