Spelling and typo fixes
Based on sphinx spellchecker testing/refinement. Signed-off-by: Ron Stone <ronald.stone@windriver.com> Change-Id: Ibfe9b6d7bc8bf044a7fff0ac7e362e4067b17989
This commit is contained in:
parent
0d1d90eb4b
commit
4868e1c226
@ -89,7 +89,7 @@ on. Both are good places to ask questions, raise issues, and discuss
|
||||
technical topics.
|
||||
|
||||
Please be patient. StarlingX is a global project and the person with
|
||||
the knowledge to help you may be twelve timezones away from you.
|
||||
the knowledge to help you may be twelve time zones away from you.
|
||||
|
||||
****************************
|
||||
Development process overview
|
||||
@ -602,7 +602,7 @@ consult with your sub-project's PL and TL to see if release
|
||||
notes are needed, and follow the
|
||||
`Release Note
|
||||
<https://docs.starlingx.io/contributor/release_note_contribute_guide.html>`_
|
||||
to contibute your changes to the release notes.
|
||||
to contribute your changes to the release notes.
|
||||
|
||||
The documentation changes needed for a code change should be
|
||||
included in the planning phase, working with project's docs team as
|
||||
|
@ -35,7 +35,7 @@ pci-passthrough interface.
|
||||
with an equal or larger |MTU|.
|
||||
|
||||
This is not used by the Kubernetes |SRIOV| plugin. In order to
|
||||
address the |MTU| in Kubernetes, the network attached definiition
|
||||
address the |MTU| in Kubernetes, the network attached definition
|
||||
needs to use the tuning plugin. For more details, see the examples
|
||||
in :ref:`Create Network Attachment Definitions
|
||||
<creating-network-attachment-definitions>`.
|
||||
@ -92,4 +92,4 @@ are required in order to set up project networks.
|
||||
|
||||
.. note::
|
||||
Segmentation ranges are not required in order to attach interfaces and
|
||||
unlock openstack-compute labeled worker nodes.
|
||||
unlock openstack-compute labeled worker nodes.
|
||||
|
@ -44,7 +44,7 @@ See :ref:`technology-preview-reduced-scope-0008a139a4b9` for details.
|
||||
.. rubric:: Debian |prod| General Availability
|
||||
|
||||
|
||||
An upcoming release will make Debian |prod| genrally available for
|
||||
An upcoming release will make Debian |prod| generally available for
|
||||
production deployments.
|
||||
|
||||
This upcoming release will run Debian Bullseye 11.3 or later with
|
||||
|
@ -29,7 +29,7 @@ configure the VM using Edit Settings as follows:
|
||||
|
||||
#. Go to Display and move the "Video memory" slider all the way to the right.
|
||||
Then tick the "Acceleration" checkbox "Enable 3D Acceleration".
|
||||
#. Go to General/Advanced and set "Shared Clipboard" and "Drag'n Drop" to
|
||||
#. Go to General/Advanced and set "Shared Clipboard" and drag-and-drop to
|
||||
Bidirectional.
|
||||
#. Go to User Interface/Devices and select "Devices/Insert Guest Additions CD
|
||||
image" from the drop down. Restart your VM.
|
||||
|
@ -153,7 +153,7 @@ scripting an initial setup.
|
||||
#. Verify that the host has been added successfully.
|
||||
|
||||
Use the :command:`fm alarm-list` command to check if any alarms (major or
|
||||
critical) events have occured. You can also type :command:`fm event-list`
|
||||
critical) events have occurred. You can also type :command:`fm event-list`
|
||||
to see a log of events. For more information on alarms, see :ref:`Fault
|
||||
Management Overview <fault-management-overview>`.
|
||||
|
||||
|
@ -73,7 +73,7 @@ you want to define ``STX_CONFIG_DIR``? Possibly when working on a major
|
||||
change in the lower layer, such as the cutover to a newer OS version. Or
|
||||
perhaps when redefining the set of layers, or the boundary between layers. In
|
||||
these cases it might be very painful to repo sync due to conflicts. It
|
||||
might be desireable to copy ``stx-tools/centos-mirror-tools/config`` outside
|
||||
might be desirable to copy ``stx-tools/centos-mirror-tools/config`` outside
|
||||
of git for a time, and make your changes there. More on the config
|
||||
directory below.
|
||||
|
||||
@ -407,7 +407,7 @@ Using option 'b' (see below) would be safer.
|
||||
Option b) Use an alternative config directory.
|
||||
|
||||
Copy the default config to an alternative directory outside of git,
|
||||
but still visible to the build. In the copyied config, edit the config files,
|
||||
but still visible to the build. In the copied config, edit the config files,
|
||||
replacing the existing 'distro' url's with ``file:///`` urls. Finally
|
||||
instruct the build to use the alternate config. I'll use the
|
||||
environment variable method in the example below. It can also be done
|
||||
@ -479,7 +479,7 @@ Making packaging changes
|
||||
|
||||
**In what layer should I place my new compiled package ?**
|
||||
|
||||
If the package is original content, writen for the StarlingX project, it
|
||||
If the package is original content, written for the StarlingX project, it
|
||||
belongs in the 'flock' layer. Yes, envision a flock of starling, might
|
||||
be corny but that is what we named it. All other content is considered
|
||||
third party and goes in either the 'distro' or 'compiler' layer.
|
||||
|
@ -607,7 +607,7 @@ Reference build overview
|
||||
|
||||
* A server in the regional office performs regular (e.g. daily) automated
|
||||
builds using existing methods. These builds are called *reference builds*.
|
||||
* The builds are timestamped and preserved for some time (i.e. a number of weeks).
|
||||
* The builds are time-stamped and preserved for some time (i.e. a number of weeks).
|
||||
* A build CONTEXT, which is a file produced by ``build-pkgs`` at location
|
||||
``$MY_WORKSPACE/CONTEXT``, is captured. It is a bash script that can cd to
|
||||
each and every Git and check out the SHA that contributed to the build.
|
||||
|
@ -230,7 +230,7 @@ The life cycle of a patch consists of the following states:
|
||||
repository and installed on any host yet.
|
||||
|
||||
* **Partial-Apply**: A patch in the Partial-Apply state means the patching
|
||||
process has been trigged by the :command:`sw-patch apply` command, but the
|
||||
process has been triggered by the :command:`sw-patch apply` command, but the
|
||||
patch has not been installed on all hosts that require it. It may have been
|
||||
installed on some hosts, but not all.
|
||||
|
||||
@ -238,7 +238,7 @@ The life cycle of a patch consists of the following states:
|
||||
hosts that require it.
|
||||
|
||||
* **Partial-Remove**: A patch in the Partial-Remove state means the removing
|
||||
process has been trigged by the :command:`sw-patch remove` command, but the
|
||||
process has been triggered by the :command:`sw-patch remove` command, but the
|
||||
patch has not been removed from all hosts that installed it. It may have been
|
||||
removed from some hosts, but not all.
|
||||
|
||||
|
@ -166,7 +166,7 @@ function correctly.
|
||||
| tcp | 25491 | mgmt | dcorch-patch |allowed(service | NA | Not used between System Controller and Subclouds | | dcorch-patch-api-proxy internal endpoint|
|
||||
| | | | -api-proxy |internal endpoint)| | | | |
|
||||
+----------+-------+---------+------------------+------------------+------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
|
||||
| tcp | 25492 | mgmt | dcorch-patch | allowed(sevice | NA | Not used between System Controller and Subclouds | | dcorch-patch-api-proxy admin endpoint |
|
||||
| tcp | 25492 | mgmt | dcorch-patch | allowed(service | NA | Not used between System Controller and Subclouds | | dcorch-patch-api-proxy admin endpoint |
|
||||
| | | | -api-proxy | admin endpoint) | | | | |
|
||||
+----------+-------+---------+------------------+------------------+------------------+--------------------------------------------------+-------------------------------------+-----------------------------------------+
|
||||
| tcp | 30001-| mgmt | VIM | allowed | allowed | Not used between System Controller and Subclouds | | |
|
||||
|
@ -520,7 +520,7 @@ Look for 'No space left on device' logs on the console, in the
|
||||
|
||||
**Debugging a Rejected Local Install**
|
||||
|
||||
The followimg command is to query Local Install logs:
|
||||
The following command is to query Local Install logs:
|
||||
|
||||
.. code-block::
|
||||
|
||||
|
@ -57,7 +57,7 @@ Alarm Messages - 700s
|
||||
+ +---------------------------------------------------------------------------------------------------------------------+----------+-----------------------------------------------------------------------------------------------------------+
|
||||
| | tenant=<tenant-uuid>.instance=<instance-uuid> |
|
||||
+----------+---------------------------------------------------------------------------------------------------------------------+----------+-----------------------------------------------------------------------------------------------------------+
|
||||
| 700.010 | nstance <instance_name> owned by <tenant_name> has been cold-migrated to host <host_name> waiting for confirmation. | C\* | Confirm or revert cold-migrate of instance. |
|
||||
| 700.010 | Instance <instance_name> owned by <tenant_name> has been cold-migrated to host <host_name> waiting for confirmation.| C\* | Confirm or revert cold-migrate of instance. |
|
||||
+ +---------------------------------------------------------------------------------------------------------------------+----------+-----------------------------------------------------------------------------------------------------------+
|
||||
| | tenant=<tenant-uuid>.instance=<instance-uuid> |
|
||||
+----------+---------------------------------------------------------------------------------------------------------------------+----------+-----------------------------------------------------------------------------------------------------------+
|
||||
|
@ -44,7 +44,7 @@ automatically once the system has been installed.
|
||||
| repository: | | |
|
||||
+--------------------+--------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------+
|
||||
| worker: | The Kubernetes nodeSelector to use for the worker pods. | All nodes. |
|
||||
| nodeSelector: | This is a key/value pair to matchagainst node labels and selectwhich nodes should run the node feature discovery. | Changing the {} to {foo: bar} will result in the worker pods only running on Kubernetes nodes labelled with foo:bar. |
|
||||
| nodeSelector: | This is a key/value pair to match against node labels and select which nodes should run the node feature discovery.| Changing the {} to {foo: bar} will result in the worker pods only running on Kubernetes nodes labelled with foo:bar. |
|
||||
| {} | | |
|
||||
+--------------------+--------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------+
|
||||
| fullnameOverride: | The base name to use for the Kubernetes resources (pods, daemonsets, etc.). | A blank entry here will result in the base name being "node-feature-discovery". |
|
||||
|
@ -20,8 +20,8 @@ Ceph cluster will be containerized and managed by Rook, to improve operation
|
||||
and maintenance efficiency.
|
||||
|
||||
This guide describes a method to migrate the host-based Ceph cluster deployed with
|
||||
StarlingX early releses to the newly containerized Ceph clusters using an upcoming
|
||||
StarlingX release, while maintaining user data in :abbr:`OSDs (Object Store Devices)`.
|
||||
StarlingX early releases to the newly containerized Ceph clusters using an upcoming
|
||||
StarlingX release, while maintaining user data in |OSDs|.
|
||||
|
||||
The migration procedure maintains CEPH OSDs and data on OSDs. Although the procedure
|
||||
does result in hosted applications experiencing several minutes of service outage due
|
||||
@ -556,7 +556,7 @@ Apply rook-ceph application
|
||||
deployment.apps "rook-ceph-mon-a" deleted
|
||||
|
||||
|
||||
#. Apply service rook-ceph-mon-a, and get cluster ip, for examplex, 10.104.152.151.
|
||||
#. Apply service rook-ceph-mon-a, and get cluster ip, for example, 10.104.152.151.
|
||||
|
||||
::
|
||||
|
||||
|
@ -21,7 +21,7 @@ and maintenance efficiency.
|
||||
|
||||
This guide describes a method to migrate the Ceph cluster deployed with StarlingX
|
||||
early releases to the newly containerized Ceph clusters using an upcoming StarlingX
|
||||
release, while maintaining user data in :abbr:`OSDs (Object Store Devices)`.
|
||||
release, while maintaining user data in |OSDs|.
|
||||
|
||||
---------------------
|
||||
Prepare for migration
|
||||
@ -664,7 +664,7 @@ Remove script ceph.sh on all hosts.
|
||||
sudo rm -rf /etc/services.d/worker/ceph.sh
|
||||
sudo rm -rf /etc/services.d/storage/ceph.sh
|
||||
|
||||
Reboot controller-0 and controller-1. And after the controller reboot sucessfully,
|
||||
Reboot controller-0 and controller-1. And after the controller reboot successfully,
|
||||
lock and unlock storage-0 and storage-1, wait for node to be available.
|
||||
|
||||
-----------------------------
|
||||
|
@ -36,7 +36,7 @@ the migration procedures.
|
||||
#. Create configmap to save OSD disk mount path
|
||||
|
||||
Because original ceph osd(s) are deployed with filestore, must create configmap
|
||||
to save osd disk info. Rook will lookup configmap "rook-ceph-osd-<hostname>-config"
|
||||
to save osd disk info. Rook will look up configmap "rook-ceph-osd-<hostname>-config"
|
||||
to get every host's osd info. In this configmap 'osd-dirs: '{"<path>":<osd-id>}''
|
||||
means, osd with this id, mount to this folder <path>/osd<id>.
|
||||
|
||||
@ -74,11 +74,11 @@ the migration procedures.
|
||||
#. Edit pv and pvc provisioner
|
||||
|
||||
For already created pv and pvc in openstack, if |prefix|-openstack
|
||||
application is applied before migration, change the provsioner to
|
||||
application is applied before migration, change the provisioner to
|
||||
kube-system.rbd.csi.ceph.com from rbd/ceph.com, as csi pod will provide csi
|
||||
service to K8s.
|
||||
|
||||
#. Update keyring and conf file on controller-0, controler-1
|
||||
#. Update keyring and conf file on controller-0, controller-1
|
||||
|
||||
For k8s pv, it will use host /etc/ceph/keyring for ceph cluster access,
|
||||
update folder /etc/ceph/ with containerized ceph cluster.
|
||||
|
@ -66,8 +66,8 @@ Kata Containers
|
||||
Kata containers are an optional capability on |prod| that provide a secure
|
||||
container runtime with lightweight virtual machines that feel and perform like
|
||||
containers, but provide stronger workload isolation. For improved performance
|
||||
wrt isolation, Kata containers leverages hardware-enforced isotation with
|
||||
virtualization VT extensions.
|
||||
with relation to isolation, Kata containers leverages hardware-enforced isolation
|
||||
with virtualization VT extensions.
|
||||
|
||||
For more information, see :ref:`starlingx-kubernetes-user-tutorials-overview`.
|
||||
|
||||
@ -89,7 +89,7 @@ The following considerations apply to PodSecurityPolicies (PSPs):
|
||||
|
||||
- are disabled by default
|
||||
|
||||
- can be enable by the System Administor via **system service-parameter-add
|
||||
- can be enable by the System Administrator via **system service-parameter-add
|
||||
kubernetes kube_apiserver admission_plugins=PodSecurityPolicy**
|
||||
|
||||
|prod| provides default PSP and RBAC definitions to simplify initial
|
||||
|
@ -193,10 +193,10 @@ only the Interface sections are modified for |prod-os|.
|
||||
+-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
||||
| Network Ports | \(Typical deployment.\) |
|
||||
| | |
|
||||
| | - Magement and Cluster Host: 2 x 10GE LAG \(shared interface\) |
|
||||
| | - Management and Cluster Host: 2 x 10GE LAG \(shared interface\) |
|
||||
| | |
|
||||
| | .. note:: |
|
||||
| | Magement ports are required for Duplex systems only |
|
||||
| | Management ports are required for Duplex systems only |
|
||||
| | |
|
||||
| | - OAM: 2 x 1GE LAG |
|
||||
| | |
|
||||
|
@ -44,7 +44,7 @@ Each service can use different storage backends.
|
||||
| | | |
|
||||
| | - used for VM boot disk volumes | |
|
||||
| | | |
|
||||
| | - used as aditional disk volumes for VMs booted from images | |
|
||||
| | - used as additional disk volumes for VMs booted from images| |
|
||||
| | | |
|
||||
| | - snapshots and persistent backups for volumes | |
|
||||
+---------+---------------------------------------------------------------+---------------------------------------------------------------+
|
||||
|
@ -42,7 +42,7 @@ The StarlingX 2.0.1 release provides fixes for the following bugs:
|
||||
* `1817936 <https://bugs.launchpad.net/starlingx/+bug//1817936/>`_
|
||||
Periodic message loss seen between VIM and OpenStac REST APIs
|
||||
* `1827246 <https://bugs.launchpad.net/starlingx/+bug//1827246/>`_
|
||||
Access to VM console not working as Horion redirects to
|
||||
Access to VM console not working as Horizon redirects to
|
||||
novncproxy.openstack.svc.cluster.local
|
||||
* `1830736 <https://bugs.launchpad.net/starlingx/+bug//1830736/>`_
|
||||
Ceph osd process was not recovered after lock and unlock on storage
|
||||
|
@ -75,7 +75,7 @@ StoryBoard entries for the features.
|
||||
|
||||
`2006274 <https://storyboard.openstack.org/#!/story/2006274>`_
|
||||
|
||||
* Support for OpenID connet authentication parameters for bootstrap
|
||||
* Support for OpenID connect authentication parameters for bootstrap
|
||||
|
||||
`2006235 <https://storyboard.openstack.org/#!/story/2006235>`_
|
||||
|
||||
|
@ -146,9 +146,9 @@ where, <UUID> is the UUID of the ssl\_ca certtype to be removed.
|
||||
followed by locking and unlocking all controller nodes for the change to
|
||||
take effect.
|
||||
|
||||
-----------------------------------
|
||||
Update/Renew trusted CA certficates
|
||||
-----------------------------------
|
||||
------------------------------------
|
||||
Update/Renew trusted CA certificates
|
||||
------------------------------------
|
||||
|
||||
.. warning::
|
||||
|
||||
|
@ -204,7 +204,7 @@ Configure OIDC Auth Applications
|
||||
|CA| which signed it, respectively. These secrets are created in this
|
||||
example.
|
||||
|
||||
In addition, one can indicate the |WAD| certificate for an ldap server
|
||||
In addition, one can indicate the |WAD| certificate for an |LDAP| server
|
||||
that has https enabled by using the secret ``wad-ca-cert`` as in this
|
||||
example.
|
||||
|
||||
|
@ -10,7 +10,7 @@ HTTPs where x509 certificates are required.
|
||||
|
||||
Etcd certificates in |prod| includes:
|
||||
|
||||
- Etcd Root |CA| certificiate
|
||||
- Etcd Root |CA| certificate
|
||||
- Etcd server certificate
|
||||
- Etcd client certificate
|
||||
- ``kube-apiserver``'s etcd client certificate
|
||||
|
@ -42,7 +42,7 @@ either an uploaded certificate or an auto generated certificate.
|
||||
.. rubric:: |proc|
|
||||
|
||||
Before starting the update, it is highly recommended to backup the existing
|
||||
Kubernetes Root |CA| certficiate and key, i.e. ``/etc/kubernetes/pki/ca.crt``
|
||||
Kubernetes Root |CA| certficate and key, i.e. ``/etc/kubernetes/pki/ca.crt``
|
||||
and ``/etc/kubernetes/pki/ca.key``.
|
||||
|
||||
#. Create the strategy.
|
||||
|
@ -35,12 +35,13 @@ Local |LDAP| user accounts share the following set of attributes:
|
||||
|
||||
- The initial password must be changed immediately upon first login.
|
||||
|
||||
- For complete details on password rules, see :ref:`System Account Password Rules <starlingx-system-accounts-system-account-password-rules>`.
|
||||
- For complete details on password rules, see :ref:`System Account
|
||||
Password Rules <starlingx-system-accounts-system-account-password-rules>`.
|
||||
|
||||
- Login sessions are logged out automatically after about 15 minutes of
|
||||
inactivity.
|
||||
|
||||
- After each unsuccessful login attemt, a 15 second delay is imposed before
|
||||
- After each unsuccessful login attempt, a 15 second delay is imposed before
|
||||
making another attempt. If you attempt to login before 15 seconds the
|
||||
system will display a message such as:
|
||||
|
||||
@ -49,7 +50,7 @@ Local |LDAP| user accounts share the following set of attributes:
|
||||
.. note:: On Debian-based |prod| systems, this delay is 3 seconds.
|
||||
|
||||
- After five consecutive unsuccessful login attempts, further attempts are
|
||||
blocked for about five minutes. On further attemps within 5 minutes, the
|
||||
blocked for about five minutes. On further attempts within 5 minutes, the
|
||||
system will display a message such as:
|
||||
|
||||
``Account locked due to 6 failed logins``
|
||||
|
@ -86,7 +86,7 @@ and ``/etc/kubernetes/pki/ca.key``.
|
||||
|
||||
``--expiry-date``
|
||||
|
||||
Optional argment to specify the expiry date of the new certificate. It has
|
||||
Optional argument to specify the expiry date of the new certificate. It has
|
||||
to be in the "YYYY-MM-DD" format. If not specified, the new certificate
|
||||
will have the same valid period as the existing one (normally 10 years).
|
||||
|
||||
|
@ -204,7 +204,7 @@ namespaces:
|
||||
Pod Security Admission Controller - Usage Example
|
||||
-------------------------------------------------
|
||||
|
||||
This page walks thru a usage example of |PSA| where you will:
|
||||
This page walks through a usage example of |PSA| where you will:
|
||||
|
||||
- Create a namespace for each of the 3 security policies levels: privileged,
|
||||
baseline and restricted.
|
||||
|
@ -32,7 +32,7 @@ The default initial password is **sysadmin**.
|
||||
.. note:: On Debian-based |prod| systems, this delay is 3 seconds.
|
||||
|
||||
- After five consecutive unsuccessful login attempts, further attempts are
|
||||
blocked for about five minutes. On further attemps within 5 minutes, the
|
||||
blocked for about five minutes. On further attempts within 5 minutes, the
|
||||
system will display a message such as:
|
||||
|
||||
``Account locked due to 6 failed logins``
|
||||
|
@ -38,7 +38,7 @@ The following is a list of pools created by |prod-os|, and Rados Gateway applica
|
||||
| | | | | |
|
||||
| | | - used for VM boot disk volumes | | |
|
||||
| | | | | |
|
||||
| | | - used as aditional disk volumes for VMs booted from images | | |
|
||||
| | | - used as additional disk volumes for VMs booted from images| | |
|
||||
| | | | | |
|
||||
| | | - snapshots and persistent backups for volumes | | |
|
||||
+----------------------------------+---------------------+---------------------------------------------------------------+----------+----------------------------------------------------------------------------------------+
|
||||
|
@ -117,6 +117,6 @@ The following example sets ``ExternalSizeMax`` to 3 gigabytes.
|
||||
.. note::
|
||||
|
||||
Configuring a parameter raises the 250.001 *controller-0 Configuration
|
||||
is out-of-date* adarm. A lock/unlock is required to clear it. For more
|
||||
is out-of-date* alarm. A lock/unlock is required to clear it. For more
|
||||
information, see :ref:`locking-a-host-using-the-cli` and
|
||||
:ref:`unlocking-a-host-using-the-cli`.
|
||||
|
@ -40,7 +40,7 @@ ptp4l
|
||||
|
||||
~(keystone_admin)]$ system ptp-instance-add ptp-inst1 ptp4l
|
||||
|
||||
#. Create a |PTP| inteface for the instance.
|
||||
#. Create a |PTP| interface for the instance.
|
||||
|
||||
.. code-block::
|
||||
|
||||
|
@ -156,7 +156,8 @@ To assign a dedicated |VLAN| segment ID you must first enable the Neutron
|
||||
.. note::
|
||||
|
||||
Thr name **test1-st-segement01-mx6fa5eonzrr** has been folded onto
|
||||
two lines in the sample output above for display pruposes.
|
||||
two lines in the sample output above for display purposes.
|
||||
|
||||
#. List subnets.
|
||||
|
||||
.. code-block:: none
|
||||
|
Loading…
Reference in New Issue
Block a user