starlingx
/
docs
Code Issues Proposed changes

Platform Admin Network Introduction (ds8) 

Story:2010319
Task: 48175

Change-Id: I30376691803f1b2fe853b19ab7a2bdf4358c2d5f
Signed-off-by: Ngairangbam Mili <ngairangbam.mili@windriver.com>
This commit is contained in:
Ngairangbam Mili 2023-07-12 05:47:59 +00:00
parent b243296086
commit 53a97040a1
9 changed files with 375 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/source/deploy/kubernetes/common-components.rst
View File

@ -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

55
doc/source/dist_cloud/kubernetes/distributed-cloud-architecture.rst
View File

@ -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
|prod-dc| system. You can select RegionOne or System Controller regions from 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
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
each subcloud is on a separate L3 subnet, the management and PXE boot L2
networks are local to the subclouds and not connected via L2 to the Central
Cloud; they are only connected via L3 routing.
Subclouds are connected to the system controller over L3 Networks. They are
connected via the |OAM| Network by either the management network or the admin
network.
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|.

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

@ -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

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

@ -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/subcloud-deploy-config.yaml \
--deploy-config /home/sysadmin/subcloud1-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
installation, and only required if the ``--install- values`` parameter is
The ``--deploy-config`` option must reference the deployment configuration
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

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

@ -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
Controller management subnet, and between the subcloud |OAM| subnet and
the System Controller subnet.
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.
.. 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
subcloud bootstrapping and deployment by using the deploy status field of
#. At the Central Cloud / system controller, monitor the progress of the
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).

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

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

66
doc/source/dist_cloud/kubernetes/rehoming-a-subcloud.rst
View File

@ -7,10 +7,10 @@
Rehome a Subcloud
=================
When the System Controller needs to be reinstalled, or when the subclouds from
multiple System Controllers are being consolidated into a single System
Controller, you can add already deployed subclouds to a different System
Controller using the rehoming playbook.
When you need to reinstall the system controller, or when the subclouds from
multiple system controllers are being consolidated into a single system
controller, you can add already deployed subclouds to a different system
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`
command post subcloud rehoming.
system controller using the :command:`dcmanager subcloud update --install-values`
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
is in-sync with the System Controller.
#. The new system controller will audit the subcloud and determine whether it
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

231
doc/source/dist_cloud/kubernetes/update-a-subcloud-network-parameters-b76377641da4.rst Normal file
View File

@ -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>

1
doc/source/shared/abbrevs.txt
View File

@ -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)`