Platform Admin Network Introduction (ds8)

Story:2010319
Task: 48175

Change-Id: I30376691803f1b2fe853b19ab7a2bdf4358c2d5f
Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>

doc/source/deploy/kubernetes/common-components.rst

@@ -63,6 +63,14 @@ A number of components are common to most |prod| deployment configurations.
 
     This is typically a 10GE network.
 
+**Admin Network (Controller Nodes)**
+    The admin network is an optional network that is used to monitor and
+    control internal |prod-long| between the subclouds and system controllers
+    in a |prod-dc| environment. This function is performed by the management
+    network in the absence of an admin network. However, the admin network is
+    more easily reconfigured to handle subnet and IP address network
+    parameter changes.
+
 **Cluster Host Network (All Nodes)**
     The cluster host network is used for Kubernetes management and control, as
     well as private container networking. The |CNI| service, Calico, provides

doc/source/dist_cloud/kubernetes/distributed-cloud-architecture.rst

@@ -9,14 +9,14 @@ A |prod-dc| system consists of a Central Cloud and one or more subclouds
 connected to the Central Cloud over L3 networks.
 
 The Central Cloud has two regions: RegionOne, used to manage the nodes in the
-Central Cloud, and System Controller, used to manage the subclouds in the
+Central Cloud, and system controller, used to manage the subclouds in the
-|prod-dc| system. You can select RegionOne or System Controller regions from the
+|prod-dc| system. You can select RegionOne or system controller regions from the
 Horizon Web interface or by setting the <OS_REGION_NAME> environment variable
 if using the CLI.
 
 **Central Cloud**
     The Central Cloud provides a RegionOne region for managing the physical
-    platform of the Central Cloud and the System Controller region for managing
+    platform of the Central Cloud and the system controller region for managing
     and orchestrating over the subclouds.
 
     The Central Cloud does not support worker hosts. All worker functions are
@@ -27,19 +27,19 @@ if using the CLI.
     Central Cloud's physical platform.
 
 **System Controller**
-    The System Controller access mode, or region, for managing subclouds is
+    The system controller access mode, or region, for managing subclouds is
     System Controller.
 
-    You can use the System Controller to add subclouds, synchronize select
+    You can use the system controller to add subclouds, synchronize select
     configuration data across all subclouds and monitor subcloud operations and
     alarms. You can also access the individual subclouds through the single
     central Horizon interface at the Central Cloud to perform subcloud-specific
     operations such as configuring and managing the subclouds' host nodes and
     containers. System software updates for the subclouds are also centrally
-    managed and applied from the System Controller.
+    managed and applied from the system controller.
 
     DNS and other select configuration settings are centrally managed at the
-    System Controller and pushed to the subclouds in parallel to maintain
+    system controller and pushed to the subclouds in parallel to maintain
     synchronization across the |prod-dc|.
 
 **Subclouds**
@@ -47,7 +47,7 @@ if using the CLI.
     Any type of |prod| deployment configuration, i.e. simplex, duplex or
     standard with or without storage nodes, can be used for a subcloud.
 
-    Alarms raised at the subclouds are sent to the System Controller for
+    Alarms raised at the subclouds are sent to the system controller for
     central reporting.
 
     .. note::
@@ -59,31 +59,46 @@ if using the CLI.
         allows the subcloud to improve service performance since authentication
         is localized within the subcloud.
 
-
-
     Each subcloud can be in a Managed or Unmanaged state.
 
     **Managed**
         When a subcloud is in the Managed state, it is updated (synchronized)
-        immediately with configuration changes made at the System Controller.
+        immediately with configuration changes made at the system controller.
         This is the normal operating state. Updates may be delayed slightly
         depending on network conditions.
 
     **Unmanaged**
         When the subcloud is in an Unmanaged state, configuration changes are
-        queued at the System Controller. They are sent to the subcloud when the
+        queued at the system controller. They are sent to the subcloud when the
         subcloud is returned to a Managed state. The Unmanaged state is used to
         disconnect the subcloud from synchronization operations for local
         maintenance. Alarms generated by the subcloud are still sent to the
-        System Controller.
+        system controller.
 
 **Networks**
-    Subclouds are connected to the System Controller over L3 networks. Because
+    Subclouds are connected to the system controller over L3 Networks. They are
-    each subcloud is on a separate L3 subnet, the management and PXE boot L2
+    connected via the |OAM| Network by either the management network or the admin
-    networks are local to the subclouds and not connected via L2 to the Central
+    network.
-    Cloud; they are only connected via L3 routing.
 
-    The settings required to connect a subcloud to the System Controller are
+    .. note::
+
+        The parameters of the management network cannot be changed after the
+        initial subcloud bootstrap operation. On subclouds, an optional admin
+        network can be used on the subcloud to facilitate network subnetting
+        changes after bootstrapping the system. In this case, the admin network
+        handles traffic between the subcloud and the L3 router. In this
+        configuration, the management network still exists on the subcloud but
+        it is used only for private communication with other hosts in the
+        subcloud. The system controller, which does not have an admin network,
+        continues to use the management network.
+
+        The |PXE| Boot network of the subcloud, if present, is also local to the
+        subcloud.
+    
+    To update subcloud network parameters, see :ref:`Update a Subcloud
+    Network Parameters <update-a-subcloud-network-parameters-b76377641da4>`.
+
+    The settings required to connect a subcloud to the system controller are
     specified when a subcloud is defined. For more information, see
     :ref:`Installing a Subcloud Without Redfish Platform Management Service
     <installing-a-subcloud-without-redfish-platform-management-service>`.
@@ -91,9 +106,9 @@ if using the CLI.
     No additional platform configuration is required to establish network
     communications. However, third-party routers are required to complete the
     L3 connections. The routers must be configured independently according to
-    OEM instructions.
+    |OEM| instructions.
 
-    All messaging between System Controllers and Subclouds uses the **admin**
+    All messaging between system controllers and subclouds uses the **admin**
     REST API service endpoints which, in this distributed cloud environment,
     are all configured for secure HTTPS. Certificates for these HTTPS
     connections are managed internally by |prod|.

doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst

@@ -60,6 +60,7 @@ Operation
     rehoming-a-subcloud
     prestage-a-subcloud-using-dcmanager-df756866163f
     add-a-horizon-keystone-user-to-distributed-cloud-29655b0f0eb9
+    update-a-subcloud-network-parameters-b76377641da4
 
 --------------------------------------------------------------------
 Prestage Orchestration for Distributed Cloud Subclouds using the CLI

doc/source/dist_cloud/kubernetes/installing-a-subcloud-using-redfish-platform-management-service.rst

@@ -45,12 +45,12 @@ subcloud, the subcloud installation has these phases:
 
 .. _installing-a-subcloud-using-redfish-platform-management-service-ul-g5j-3f3-qjb:
 
--   The docker **rvmc** image needs to be added to the System Controller
+-   The docker **rvmc** image needs to be added to the system controller
     bootstrap override file, docker.io/starlingx/rvmc:|v_starlingx-rvmc|.
 
 -   A new system CLI option ``--active`` is added to the
     :command:`load-import` command to allow the import into the
-    System Controller ``/opt/dc-vault/loads``. The purpose of this is to allow
+    system controller ``/opt/dc-vault/loads``. The purpose of this is to allow
     Redfish install of subclouds referencing a single full copy of the
     ``bootimage.iso`` at ``/opt/dc-vault/loads``. (Previously, the full
     ``bootimage.iso`` was duplicated for each :command:`subcloud add`
@@ -122,16 +122,16 @@ subcloud, the subcloud installation has these phases:
 
        Do not power off the servers. The host portion of the server can be
        powered off, but the |BMC| portion of the server must be powered and
-       accessible from the System Controller.
+       accessible from the system controller.
 
        There is no need to wipe the disks.
 
     .. note::
 
        The servers require connectivity to a gateway router that provides IP
-       routing between the subcloud management subnet and the System Controller
+       routing between the subcloud management or admin subnet and the system controller
        management subnet, and between the subcloud |OAM| subnet and the
-       System Controller subnet.
+       system controller subnet.
 
     .. include:: /_includes/installing-a-subcloud-using-redfish-platform-management-service.rest
        :start-after: begin-ref-1
@@ -251,7 +251,7 @@ subcloud, the subcloud installation has these phases:
         command with the ``subcloud-install-values.yaml`` file containing the desired
         ``persistent_size`` value.
 
-#.  At the System Controller, create a
+#.  At the system controller, create a
     ``/home/sysadmin/subcloud-bootstrap-values.yaml`` overrides file for the
     subcloud.
 
@@ -305,6 +305,23 @@ subcloud, the subcloud installation has these phases:
 
         $ keyring get sysinv services
 
+    In the above example, if the admin network is used for communication
+    between the subcloud and system controller, then the
+    ``management_gateway_address`` parameter should be replaced with admin
+    subnet information.
+
+    For example:
+
+    .. code-block:: none
+
+        management_subnet: 192.168.101.0/24
+        management_start_address: 192.168.101.2
+        management_end_address: 192.168.101.50
+        admin_subnet: 192.168.102.0/24
+        admin_start_address: 192.168.102.2
+        admin_end_address: 192.168.102.50
+        admin_gateway_address: 192.168.102.1
+
     This configuration will install container images from the local registry on
     your central cloud. The Central Cloud's local registry's HTTPS Certificate
     must have the Central Cloud's |OAM| IP, **registry.local** and
@@ -338,11 +355,6 @@ subcloud, the subcloud installation has these phases:
        :start-after: begin-subcloud-1
        :end-before: end-subcloud-1
 
-
-
-
-
-
 #.  Add the subcloud using dcmanager.
 
     When calling the :command:`subcloud add` command, specify the install
@@ -352,10 +364,10 @@ subcloud, the subcloud installation has these phases:
 
        ~(keystone_admin)]$ dcmanager subcloud add \
        --bootstrap-address <oam_ip_address_of_subclouds_controller-0> \
-       --bootstrap-values /home/sysadmin/subcloud-bootstrap-values.yaml \
+       --bootstrap-values /home/sysadmin/subcloud1-bootstrap-values.yaml \
        --sysadmin-password <sysadmin_password> \
-       --install-values /home/sysadmin/subcloud-install-values.yaml \
+       --deploy-config /home/sysadmin/subcloud1-deploy-config.yaml \
-       --deploy-config /home/sysadmin/subcloud-deploy-config.yaml \
+       --install-values /home/sysadmin/install-values.yaml \
        --bmc-password <bmc_password>
 
     If the ``--sysadmin-password`` is not specified, you are prompted to
@@ -366,11 +378,20 @@ subcloud, the subcloud installation has these phases:
 
        Enter the sysadmin password for the subcloud:
 
-    (Optional) The ``--bmc-password <password>`` is used for subcloud
+    The ``--deploy-config`` option must reference the deployment configuration
-    installation, and only required if the ``--install- values`` parameter is
+    file mentioned above. In the deployment configurations, static routes from
+    the management or admin interface of a subcloud to the system controller's
+    management subnet must be explicitly listed. This ensures that the subcloud
+    comes online after deployment. If the admin network is used for
+    communication between the system controller and subcloud, the deployment
+    configuration file must include both an admin network type and a management
+    network type interface.
+
+    (Optional) The ``--bmc-password <password>`` option is used for subcloud
+    installation, and only required if the ``--install- values`` option is
     specified.
 
-    If the ``--bmc-password <password>`` is omitted and the
+    If the ``--bmc-password <password>`` option is omitted and the
     ``--install-values`` option is specified the system administrator will be
     prompted to enter it, following the :command:`dcmanager subcloud add`
     command. This option is ignored if the ``--install-values`` option is not

doc/source/dist_cloud/kubernetes/installing-a-subcloud-without-redfish-platform-management-service.rst

@@ -38,9 +38,9 @@ subcloud, the subcloud installation process has two phases:
 
     After a successful remote installation of a subcloud in a Distributed Cloud
     system, a subsequent remote reinstallation fails because of an existing ssh
-    key entry in the ``/root/.ssh/known_hosts`` on the System Controller. In this
+    key entry in the ``/root/.ssh/known_hosts`` on the system controller. In this
     case, delete the host key entry, if present, from ``/root/.ssh/known_hosts``
-    on the System Controller before doing reinstallations.
+    on the system controller before doing reinstallations.
 
 .. rubric:: |prereq|
 
@@ -67,9 +67,9 @@ subcloud, the subcloud installation process has two phases:
     .. note::
 
         The servers require connectivity to a gateway router that provides IP
-        routing between the subcloud management subnet and the System
+        routing between the subcloud management or admin subnet and the system
-        Controller management subnet, and between the subcloud |OAM| subnet and
+        controller management subnet, and between the subcloud |OAM| subnet and
-        the System Controller subnet.
+        the system controller subnet.
 
     .. include:: /_includes/installing-a-subcloud-without-redfish-platform-management-service.rest
        :start-after: begin-ref-1
@@ -164,7 +164,7 @@ subcloud, the subcloud installation process has two phases:
 #.  Log in to the subcloud's controller-0 and ping the Central Cloud's floating
     |OAM| IP Address.
 
-#.  At the System Controller, create a
+#.  At the system controller, create a
     ``/home/sysadmin/subcloud1-bootstrap-values.yaml`` overrides file for the
     subcloud.
 
@@ -219,6 +219,23 @@ subcloud, the subcloud installation process has two phases:
 
         $ keyring get sysinv services
 
+    In the above example, if the admin network is used for communication
+    between the subcloud and system controller, then the
+    ``management_gateway_address`` parameter should be replaced with admin
+    subnet information.
+    
+    For example:
+
+    .. code-block:: none
+
+        management_subnet: 192.168.101.0/24
+        management_start_address: 192.168.101.2
+        management_end_address: 192.168.101.50
+        admin_subnet: 192.168.102.0/24
+        admin_start_address: 192.168.102.2
+        admin_end_address: 192.168.102.50
+        admin_gateway_address: 192.168.102.1
+
     This configuration uses the local registry on your central cloud. If you
     prefer to use the default external registries, make the following
     substitutions for the ``docker_registries`` and
@@ -255,8 +272,8 @@ subcloud, the subcloud installation process has two phases:
        :start-after: begin-prepare-files-to-copy-deployment-config
        :end-before: end-prepare-files-to-copy-deployment-config
 
-#.  At the Central Cloud / System Controller, monitor the progress of the
+#.  At the Central Cloud / system controller, monitor the progress of the
-    subcloud bootstrapping and deployment by using the deploy status field of
+    subcloud bootstraping and deployment by using the deploy status field of
     the :command:`dcmanager subcloud list` command.
 
     .. include:: /shared/_includes/installing-a-subcloud.rest
@@ -318,7 +335,7 @@ subcloud, the subcloud installation process has two phases:
 
     In DC system, openldap service is running on Central Cloud. In order for the nodes
     in the subclouds to access openldap service, such as ssh to the nodes as openldap
-    users, a static route to the System Controller is required to be added in these
+    users, a static route to the system controller is required to be added in these
     nodes. This applies to controller nodes, worker nodes and storage nodes (nodes
     that have sssd running).
 

doc/source/dist_cloud/kubernetes/installing-and-provisioning-a-subcloud.rst

@@ -15,8 +15,8 @@ Platform Management Service.
 
 .. note::
 
-    Each subcloud must be on a separate management subnet (different from the
+    Each subcloud must be on a separate management or admin subnet (different from the
-    System Controller and from any other subclouds).
+    system controller and from any other subclouds).
 
 
 .. _installing-and-provisioning-a-subcloud-section-orn-jkf-t4b:

doc/source/dist_cloud/kubernetes/rehoming-a-subcloud.rst

@@ -7,10 +7,10 @@
 Rehome a Subcloud
 =================
 
-When the System Controller needs to be reinstalled, or when the subclouds from
+When you need to reinstall the system controller, or when the subclouds from
-multiple System Controllers are being consolidated into a single System
+multiple system controllers are being consolidated into a single system
-Controller, you can add already deployed subclouds to a different System
+controller, you can add already deployed subclouds to a different system
-Controller using the rehoming playbook.
+controller using the rehoming playbook.
 
 .. note::
 
@@ -19,7 +19,7 @@ Controller using the rehoming playbook.
 
 .. note::
 
-    The system time should be accurately configured on the System Controllers
+    The system time should be accurately configured on the system controllers
     and the subcloud's controllers before rehoming the subcloud.
 
 .. warning::
@@ -30,47 +30,47 @@ Controller using the rehoming playbook.
     
 Use the following procedure to enable subcloud rehoming and to update the new
 subcloud configuration (networking parameters, passwords, etc.) to be
-compatible with the new System Controller.
+compatible with the new system controller.
 
 .. rubric:: |context|
 
 There are six phases for Rehoming a subcloud:
 
 
-#.  Unmanage the subcloud from the previous System Controller.
+#.  Unmanage the subcloud from the previous system controller.
 
     .. note::
 
-        You can skip this step if the previous System Controller is no longer
+        You can skip this step if the previous system controller is no longer
         running or is unable to connect to the subcloud.
 
 #.  Update the admin password on the subcloud to match the new System
     Controller, if required.
 
 #.  Run the :command:`subcloud add` command with the ``--migrate`` option on
-    the new System Controller. This will update the System Controller and
+    the new system controller. This will update the system controller and
     connect to the subcloud to update the appropriate configuration parameters.
 
 #.  Use the :command:`dcmanager subcloud list` command to check the status
     of the subcloud, ensure the subcloud is online and complete before managing
     the subcloud.
 
-#.  Delete the subcloud from the previous System Controller after the subcloud
+#.  Delete the subcloud from the previous system controller after the subcloud
     is offline.
 
     .. note::
 
-        You can skip this phase if the previous System Controller is no longer
+        You can skip this phase if the previous system controller is no longer
         running or is unable to connect to the subcloud.
 
-#.  On the new System Controller, set the subcloud to "managed" and wait for it
+#.  On the new system controller, set the subcloud to "managed" and wait for it
     to sync.
 
 .. rubric:: |prereq|
 
--   Ensure that the subcloud management subnet, oam_floating_address,
+-   Ensure that the subcloud management or admin subnet, oam_floating_address,
     oam_node_0_address and oam_node_1_address (if applicable) does not overlap
-    addresses already being used by the new System Controller or any of its
+    addresses already being used by the new system controller or any of its
     subclouds.
 
 -   Ensure that the subcloud has been backed up, in case something goes wrong
@@ -95,37 +95,37 @@ There are six phases for Rehoming a subcloud:
     config (|NTP| or |PTP|).
 
 -   Transfer the yaml file that was used to bootstrap the subcloud prior to
-    rehoming, to the new System Controller. This data is required for rehoming.
+    rehoming, to the new system controller. This data is required for rehoming.
 
 -   If the subcloud can be remotely installed via Redfish Virtual Media service,
     transfer the yaml file that contains the install data for this subcloud,
-    and use this install data in the new System Controller, via the
+    and use this install data in the new system controller, via the
     ``--install-values`` option, when running the remote subcloud reinstall,
     upgrade or restore commands.
 
 
 .. note::
 
-    These prerequisites apply if the old System Controller is still available.
+    These prerequisites apply if the old system controller is still available.
 
 .. rubric:: |proc|
 
-#.  If the previous System Controller is running, use the following command to
+#.  If the previous system controller is running, use the following command to
     ensure that it does not try to change subcloud configuration while you are
-    modifying it to be compatible with the new System Controller.
+    modifying it to be compatible with the new system controller.
 
     .. code-block:: none
 
         ~(keystone_admin)]$ dcmanager subcloud unmanage <subcloud_name>
 
 #.  Ensure that the subcloud's bootstrap values file is available on the new
-    System Controller. If required, in the subcloud's bootstrap values file
+    system controller. If required, in the subcloud's bootstrap values file
     update the ``systemcontroller_gateway_address`` entry to point to the
-    appropriate network gateway for the new System Controller to communicate
+    appropriate network gateway for the new system controller to communicate
     with the subcloud.
 
 #.  If the admin password of the subcloud does not match the admin password of
-    the new System Controller, use the following command to change the subcloud
+    the new system controller, use the following command to change the subcloud
     admin password. This step is done on the subcloud that is being migrated.
 
     .. code-block:: none
@@ -150,7 +150,7 @@ There are six phases for Rehoming a subcloud:
     out-of-date" alarm, a lock/unlock is required to clear that alarm on the node
     before the next step.
 
-#.  On the new System Controller, use the following command to start the
+#.  On the new system controller, use the following command to start the
     rehoming process.
 
     .. code-block:: none
@@ -161,7 +161,7 @@ There are six phases for Rehoming a subcloud:
 
         You will need to update the ``systemcontroller_gateway_address``
         variable in the bootstrap values file before you perform the migration.
-        This field is the gateway address to the new System Controller.
+        This field is the gateway address to the new system controller.
 
     The subcloud deploy status will change to "pre-rehome" and if the
     preliminary steps complete successfully it will change to "rehoming".
@@ -174,19 +174,19 @@ There are six phases for Rehoming a subcloud:
 
         The ``--install-values`` parameter is optional and is not mandatory
         for subcloud rehoming. However, you can opt to save these values on the
-        new System Controller as part of the rehoming process so that future
+        new system controller as part of the rehoming process so that future
         operations that involve remote reinstallation of the subcloud (e.g.
         reinstall, upgrade, restore) can be performed for the rehomed subcloud.
 
         The subcloud install values can also be added to or updated on the new
-        System Controller using the :command:`dcmanager subcloud update --install-values`
+        system controller using the :command:`dcmanager subcloud update --install-values`
-        command post subcloud rehoming.
+        command after rehoming the subcloud.
 
         **Delete the "image:" line from the install-values file, if it exists, so
-        that the image is correctly located based on the new System Controller
+        that the image is correctly located based on the new system controller
         configuration**.
 
-#.  If the previous System Controller is still running, delete the subcloud
+#.  If the previous system controller is still running, delete the subcloud
     after it goes offline, using the following command.
 
     .. code-block:: none
@@ -208,14 +208,14 @@ There are six phases for Rehoming a subcloud:
         +----+-----------+------------+--------------+---------------+---------+
 
 #.  Use the following command to "manage" the subcloud. This is executed on the
-    System Controller.
+    system controller.
 
     .. code-block:: none
 
         ~(keystone_admin)]$ dcmanager subcloud manage <subcloud-name>
 
-#.  The new System Controller will audit the subcloud and determine whether it
+#.  The new system controller will audit the subcloud and determine whether it
-    is in-sync with the System Controller.
+    is in-sync with the system controller.
 
 .. only:: partner
 
@@ -230,7 +230,7 @@ If the subcloud rehoming process begins successfully, (status changes to
 successfully, then manual error recovery is required.
 
 The first stage of error recovery is to delete the subcloud from
-the new System Controller and re-attempt rehoming using the following commands:
+the new system controller and re-attempt rehoming using the following commands:
 
 .. code-block:: none
 

doc/source/dist_cloud/kubernetes/update-a-subcloud-network-parameters-b76377641da4.rst

@@ -0,0 +1,231 @@
+.. _update-a-subcloud-network-parameters-b76377641da4:
+
+==================================
+Manage Subcloud Network Parameters
+==================================
+
+Use the following procedures to manage an optional admin network on a subcloud
+for IP connectivity to the system controller management network where the IP
+addresses of the admin network can be changed.
+
+.. rubric:: |prereq|
+
+-   Ensure that the subcloud admin subnet does not overlap addresses already
+    being used by the system controller or any of its subclouds.
+
+-   Ensure that the subcloud has been backed up, in case a subcloud system
+    recovery is required.
+
+-   Ensure that the system time between system controllers and the
+    subclouds are synchronized.
+
+    .. code-block:: none
+
+        ~(keystone_admin)]$ date -u
+
+    If the time is not correct either on the system controllers or the subclouds,
+    check the ``clock_synchronization`` configuration on the system.
+
+    .. code-block:: none
+
+        ~(keystone_admin)]$ system host-show controller-0
+
+    Check the |NTP| server configuration or |PTP| server configuration sections
+    to correct the system time based on the system's ``clock_synchronization``
+    configuration (|NTP| or |PTP|).
+
+---------------------------------
+Add an admin interface or network
+---------------------------------
+
+.. rubric:: |context|
+
+This task is required only if an admin network/interface does not exist on the
+system, either via this procedure or at bootstrap time. The procedure is
+performed only on the subcloud.
+
+.. rubric:: |proc|   
+
+#. For all the controller hosts of a subcloud, add the new admin interface as
+   follows: 
+
+   #. Lock the host.
+
+      .. code-block:: none
+
+          ~(keystone_admin)]$ system host-lock <controller-host>
+    
+   #. Add a new platform interface.
+
+      .. code-block:: none
+
+          ~(keystone_admin)]$ system host-if-modify <host> <admin-interface> -c platform
+
+      For example:
+   
+      .. code-block:: none
+
+          ~(keystone_admin)]$ system host-if-modify <controller-host> enp0s9 -c platform
+
+      .. note::
+
+          To see all the available interfaces, use the :command:`system host-if-list -a <host>` command.
+
+   #. Unlock the host.
+
+      .. code-block:: none
+
+          ~(keystone_admin)]$ system host-unlock <host>
+        
+#. Create an admin network address pool.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system addrpool-add --floating-address <floating-address> --controller0-address <controller0-address> --controller1-address <controller1-address> --gateway-address <gateway-address> <address-pool-name> <subnet> <prefix length>
+
+   For example:
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system addrpool-add --floating-address 192.168.102.2 --controller0-address 192.168.102.3 --controller1-address 192.168.102.4 --gateway-address 192.168.102.1 admin 192.168.102.0 24
+
+#. Create the admin network with the dynamic field set to false.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system network-add <network-name> admin false <admin-address-pool-uuid>
+
+   For example:
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system network-add admin admin false $(system addrpool-list | grep admin | awk '{print $2}')
+
+#. Assign the admin network to the admin interface.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system interface-network-assign <controller-host> <interface-name> <network-name>
+
+   For example:
+
+   .. code-block:: none
+    
+       ~(keystone_admin)]$ system interface-network-assign <controller-host> enp0s9 admin
+
+--------------------------------------------------
+Change the network parameters of the admin network
+--------------------------------------------------
+
+.. rubric:: |context|
+
+This task is required only if the parameters of an admin network need to be
+changed, for example, to align with a new external network configuration. The
+procedure is performed only on the subcloud.
+
+.. rubric:: |proc|
+
+#. Delete the admin address pool.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system addrpool-delete <admin-address-pool-uuid>
+
+   .. note::
+
+       This will automatically delete the admin network and unassign it from the
+       admin interface.
+
+#. Create a new admin network address pool.
+
+   For example:
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system addrpool-add --floating-address 192.168.103.2 --controller0-address 192.168.103.3 --controller1-address 192.168.103.4 --gateway-address 192.168.103.1 admin 192.168.103.0 24
+
+#. Create a new admin network.
+
+   For example:
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system network-add admin admin false <admin-address-pool-uuid>
+
+#. Assign the new admin network to the admin interface.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ system interface-network-assign controller-0 enp0s9 admin
+
+#. On the system controller, perform the following:
+   
+   #. Unmanage the subcloud.
+
+      .. code-block:: none
+
+        ~(keystone_admin)]$ dcmanager subcloud unmanage <subcloud-name>
+
+   #. Update the subcloud with the new subnet parameters.
+
+      For example:
+
+      .. code-block:: none
+
+          ~(keystone_admin)]$ dcmanager subcloud update --management-subnet 192.168.103.0/24 --management-gateway-ip 192.168.103.1 --management-start-ip 192.168.103.2 --management-end-ip 192.168.103.5 --bootstrap-address 10.10.10.12 subcloud1
+
+      .. note::
+
+          The subcloud will go offline for a short period.
+
+   #. Manage the subcloud.
+
+      .. code-block:: none
+
+          ~(keystone_admin)]$ dcmanager subcloud manage <subcloud-name>
+
+-------------------------------------
+Switch back to the management network
+-------------------------------------
+
+.. rubric:: |context|
+
+This task is required only if an operator wants to switch back to the subcloud
+management network. This procedure can also be used to switch the subcloud back
+to an already existing admin network.
+
+.. rubric:: |proc|  
+
+#. Unmanage the subcloud.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ dcmanager subcloud unmanage <subcloud-name>
+
+#. Update the subcloud with the existing network parameters of the subcloud
+   management network.
+
+   For example:
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ dcmanager subcloud update --management-subnet 192.168.104.0/24 --management-gateway-ip 192.168.104.1 --management-start-ip 192.168.104.2 --management-end-ip 192.168.104.5 --bootstrap-address 10.10.10.12 <subcloud-name>
+
+   .. note::
+
+       Obtain the existing management network parameters on the subcloud using
+       the :command:`system addrpool-show <management network uuid>` command.
+
+   .. note::
+
+       The subcloud will go offline for a short period.
+
+#. Manage the subcloud.
+
+   .. code-block:: none
+
+       ~(keystone_admin)]$ dcmanager subcloud manage <subcloud-name>
+        
+
+
+

doc/source/shared/abbrevs.txt

@@ -98,6 +98,7 @@
 .. |NUMA| replace:: :abbr:`NUMA (Non-Uniform Memory Access)`
 .. |NVMe| replace:: :abbr:`NVMe (Non-Volatile Memory express)`
 .. |OAM| replace:: :abbr:`OAM (Operations, administration and management)`
+.. |OEM| replace:: :abbr:`OEM (Original Equipment Manufacturer)`
 .. |OC| replace:: :abbr:`OC (Ordinary Clock)`
 .. |OID| replace:: :abbr:`OID (Object Identifier)`
 .. |OIDC| replace:: :abbr:`OIDC (OpenID Connect)`