Merge pull request #26 from opennetworkinglab/maintenance

clarification

conf.py

@@ -281,7 +281,6 @@ def get_version():
 intersphinx_mapping = {
     'ansible': ('https://docs.ansible.com/ansible/latest', None),
     'sphinx': ('https://www.sphinx-doc.org/en/master', None),
-    'trellis': ('https://docs.trellisfabric.org/master', None),
     'sdcore': ('https://docs.sd-core.opennetworking.org/master', None),
     'sdran': ('https://docs.sd-ran.org/master', None),
     'sysapproach5g': ('https://5g.systemsapproach.org/', None),

onramp/blueprints.rst

@@ -485,8 +485,11 @@ OAI 5G RAN
 ~~~~~~~~~~~~~~~~~~~~
 
 Aether can be configured to work with the open source gNB from OAI.
-The blueprint runs in either simulation mode or with physical UEs
-connecting wirelessly to a USRP software-defined radio.
+The blueprint runs in either simulation mode or with a USRP
+software-defined radio connecting wirelessly to one or more
+off-the-shelf UEs. (OAI also supports USRP-based UEs, but this
+blueprint does not currently support that option; you need to deploy
+such a UE separately.)
 
 The following assumes familiarity with the OAI 5G RAN stack, but it is
 **not** necessary to separately install the OAI stack. OnRamp installs

onramp/scale.rst

@@ -21,7 +21,7 @@ server is to play. We'll introduce additional host groups in later
 sections, but for starters, there are two aspects of our deployment
 that scale independently. One is Aether proper: a Kubernetes cluster
 running the set of microservices that implement SD-Core and AMP (and
-optionally, other edge apps); this corresponds to a combination of the
+optionally, other edge apps). This corresponds to a combination of the
 ``master_nodes`` and ``worker_nodes`` groups. The second is gNBsim:
 the emulated RAN that generates traffic directed at the Aether
 cluster, corresponding to the ``gnbsim_nodes`` host group.
@@ -91,26 +91,27 @@ connect that node to one or more physical gNBs.
 Allocating CPU Cores
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Kubernetes provides a mechanism for allocating CPU cores to specific
-pods. OnRamp manages this capability in two steps.
+Kubernetes supports allocating CPU cores to specific pods. OnRamp
+manages this capability in two steps.
 
 First, directory ``deps/k8s/roles/rke2/templates`` contains two files
 used to configure a Kubernetes deployment. These files are referenced
 in ``vars/main.yml`` as variables
 ``k8s.rke2.config.params_file.master`` and
-``k8s.rke2.config.params_file.worker``; edit these variables should
-you elect to substitute different files. Uncomment the block
-labeled *"Param's for Exclusive CPU"* in both files to enable the
-allocation feature. You need to reinstall Kubernetes for these changes
-to take effect.
+``k8s.rke2.config.params_file.worker``. Either edit these variables to
+substitute different files that you have defined to your
+specification, or uncomment the block labeled *"Param's for Exclusive
+CPU"* in the two default files. Doing the latter enables the
+allocation feature; you also need to reinstall Kubernetes for these
+changes to take effect.
 
 Second, edit the values override file for whatever service is to be
 granted an exclusive CPU core. A typical example is to allocate a core
 to the UPF, which can be done by editing the ``omec-user-plane``
 section of ``deps/5gc/roles/core/templates/sdcore-5g-values.yaml``,
-changing variable ``resources.enabled`` from ``false`` to
-``true``. Similar variables exist for other SD-Core pods. You need to
-reinstall the 5G Core for this change to take effect.
+changing variable ``resources.enabled`` to ``true``. Similar variables
+exist for other SD-Core pods. You need to reinstall the 5G Core for
+this change to take effect.
 
 
 Other Options

onramp/start.rst

@@ -121,10 +121,11 @@ four things to note:
    you will not need to modify the latter. Note that the ``vars``
    directory contains several variants of ``main.yml``, where we think
    of each as specifying a *blueprint* for a different configuration
-   of Aether. The default ``main.yml`` (which is the same as
-   ``main-quickstart.yml``) gives the blueprint for the Quick Start
-   deployment described in this section; we'll substitute the other
-   blueprints in later sections.
+   of Aether. The default ``main.yml`` (which is equivalent to
+   ``main-quickstart.yml``, except with non-default settings commented
+   out) gives the blueprint for the Quick Start deployment described
+   in this section. We'll substitute the other blueprints in later
+   sections.
 
 4. File ``hosts.ini`` (host inventory) is Ansible's way of specifying
    the set of servers (physical or virtual) that Ansible targets with