Improve rvmc debug logging (r9, dsMR3)
- resolve merge conflict - add RVMC abbrev Story: 2010144 Task: 49603 Change-Id: If8ef1614b812f1f7fdab2036a998a7960c7279d3 Signed-off-by: Ron Stone <ronald.stone@windriver.com>
This commit is contained in:
Ron Stone
parent
6276abb99e
commit
04ea9caa03
|
|
@ -45,8 +45,6 @@ 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
|
||||
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
|
||||
|
|
@ -122,6 +120,56 @@ subcloud, the subcloud installation has these phases:
|
|||
files that are referenced in the ``subcloud-bootstrap-values.yaml`` file must exist
|
||||
on both controllers (for example, ``/home/sysadmin/docker-registry-ca-cert.pem``).
|
||||
|
||||
|
||||
Controlling the RVMC debug level and automatic serial console log capture
|
||||
=========================================================================
|
||||
|
||||
The optional parameter, ``rvmc_debug_level``, in the subcloud install_values
|
||||
YAML file, controls the generation of debug logs during |RVMC| installation,
|
||||
which are then stored in the ansible log files for each subcloud.
|
||||
|
||||
**Valid rvmc_debug_levels**
|
||||
|
||||
The available ``rvmc_debug_level`` values control the log content as follows.
|
||||
|
||||
Note that the log levels increase in verbosity as they increase:
|
||||
|
||||
0: Debug logging is disabled (normal log content)
|
||||
|
||||
1: Logs operations of each remote install stage, such as RedFish session
|
||||
open/close, eject/insert image, power on/off host, and more. If the
|
||||
install_type matches a serial console, then the full serial console log output
|
||||
is also captured automatically.
|
||||
|
||||
2: Logs HTTP request type and URL with corresponding response status.
|
||||
|
||||
3: Logs HTTP request headers and payloads, along with Redfish action tracing
|
||||
logs.
|
||||
|
||||
4: Outputs JSON of all command responses.
|
||||
|
||||
**Automatic Serial Console capture (for ``rvmc_debug_level`` > 1)**
|
||||
|
||||
When the ``rvmc_debug_level`` is enabled (``rvmc_debug_level`` > 0), the full serial
|
||||
console output can be automatically captured, provided the serial console is
|
||||
configured in the 'install_type' install value.
|
||||
|
||||
.. note:: Capturing graphical console output is not supported.
|
||||
|
||||
The ``install_type`` in the subcloud install_values YAML file must correspond
|
||||
to one of the serial console types:
|
||||
|
||||
0: Standard Controller, Serial Console
|
||||
|
||||
2: AIO, Serial Console
|
||||
|
||||
4: AIO Low-latency, Serial Console
|
||||
|
||||
The captured serial console log files are found in the same directory as the
|
||||
subcloud ansible log files: ``/var/log/dcmanager/ansible``, and named as
|
||||
``<subcloud name>_serial_console.log``.
|
||||
|
||||
|
||||
.. Greg updates required for -High Security Vulnerability Document Updates
|
||||
|
||||
.. rubric:: |proc|
|
||||
|
|
@ -140,16 +188,16 @@ subcloud, the subcloud installation has these phases:
|
|||
.. note::
|
||||
|
||||
The servers require connectivity to a gateway router that provides IP
|
||||
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.
|
||||
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-using-redfish-platform-management-service.rest
|
||||
:start-after: begin-ref-1
|
||||
:end-before: end-ref-1
|
||||
|
||||
#. Create the ``subcloud-install-values.yaml`` file and use the content to pass the file
|
||||
into the :command:`dcmanager subcloud add` command, using the
|
||||
#. Create the ``subcloud-install-values.yaml`` file and use the content to
|
||||
pass the file into the :command:`dcmanager subcloud add` command, using the
|
||||
``--install-values`` command option.
|
||||
|
||||
.. note::
|
||||
|
|
@ -248,8 +296,9 @@ subcloud, the subcloud installation has these phases:
|
|||
persistent disk space is required, the partition can be increased in the next
|
||||
subcloud reinstall using the following commands:
|
||||
|
||||
- To increase ``/opt/platform-backup`` to 40GB, add the **persistent_size: 40000**
|
||||
parameter to the ``subcloud-install-values.yaml`` file.
|
||||
- To increase ``/opt/platform-backup`` to 40GB, add the
|
||||
**persistent_size: 40000** parameter to the
|
||||
``subcloud-install-values.yaml`` file.
|
||||
|
||||
- Use the :command:`dcmanager subcloud update` command to save the
|
||||
configuration change for the next subcloud reinstall.
|
||||
|
|
@ -258,9 +307,9 @@ subcloud, the subcloud installation has these phases:
|
|||
|
||||
~(keystone_admin)]$ dcmanager subcloud update --install-values <subcloud-install-values.yaml> <subcloud-name>
|
||||
|
||||
For a new subcloud deployment, use the :command:`dcmanager subcloud add`
|
||||
command with the ``subcloud-install-values.yaml`` file containing the desired
|
||||
``persistent_size`` value.
|
||||
For a new subcloud deployment, use the :command:`dcmanager subcloud
|
||||
add` command with the ``subcloud-install-values.yaml`` file containing
|
||||
the desired ``persistent_size`` value.
|
||||
|
||||
#. At the system controller, create a
|
||||
``/home/sysadmin/subcloud-bootstrap-values.yaml`` overrides file for the
|
||||
|
|
@ -440,8 +489,8 @@ subcloud, the subcloud installation has these phases:
|
|||
|
||||
|
||||
#. If ``deploy_status`` shows an installation, bootstrap or deployment failure
|
||||
state, you can use the ``dcmanager subcloud errors`` command in order to get
|
||||
more detailed information about failure.
|
||||
state, you can use the ``dcmanager subcloud errors`` command in order to
|
||||
get more detailed information about failure.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -517,11 +566,12 @@ subcloud, the subcloud installation has these phases:
|
|||
|
||||
- Add static route for nodes in subcloud to access openldap service.
|
||||
|
||||
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
|
||||
nodes. This applies to controller nodes, worker nodes and storage nodes (nodes
|
||||
that have sssd running).
|
||||
In a Distributed Cloud 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 nodes. This applies to
|
||||
controller nodes, worker nodes and storage nodes (nodes that have sssd
|
||||
running).
|
||||
|
||||
The static route can be added on each of the nodes in the subcloud using system
|
||||
CLI.
|
||||
|
|
@ -531,14 +581,14 @@ subcloud, the subcloud installation has these phases:
|
|||
|
||||
.. code-block:: none
|
||||
|
||||
system host-route-add controller-0 mgmt0 <Central Cloud mgmt subnet> 64 <Gateway IP address>
|
||||
system host-route-add compute-0 mgmt0 <Central Cloud mgmt subnet> 64 <Gateway IP address>
|
||||
[sysadmin@controller-0 ~(keystone_admin)]$ system host-route-add controller-0 mgmt0 <Central Cloud mgmt subnet> 64 <Gateway IP address>
|
||||
[sysadmin@controller-0 ~(keystone_admin)]$ system host-route-add compute-0 mgmt0 <Central Cloud mgmt subnet> 64 <Gateway IP address>
|
||||
|
||||
The static route can also be added using Deployment Manager by adding the route
|
||||
in its configuration file.
|
||||
The static route can also be added using Deployment Manager by adding the
|
||||
route in its configuration file.
|
||||
|
||||
The following examples show adding the route configuration in controller and
|
||||
worker host profiles of the deployment manager's configuration file:
|
||||
The following examples show adding the route configuration in controller
|
||||
and worker host profiles of the deployment manager's configuration file:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
|
|||
|
|
@ -152,6 +152,7 @@
|
|||
.. |RCAs| replace:: :abbr:`RCAs (Root Certificate Authorities)`
|
||||
.. |RPC| replace:: :abbr:`RPC (Remote Procedure Call)`
|
||||
.. |RST| replace:: :abbr:`rST (reStructuredText)`
|
||||
.. |RVMC| replace:: :abbr:`RVMC (Redfish Virtual Media Controller)`
|
||||
.. |SAN| replace:: :abbr:`SAN (Subject Alternative Name)`
|
||||
.. |SANs| replace:: :abbr:`SANs (Subject Alternative Names)`
|
||||
.. |SAS| replace:: :abbr:`SAS (Serial Attached SCSI)`
|
||||
|
|
|
|||
Loading…
Reference in New Issue