diff --git a/developer/roc.rst b/developer/roc.rst index ed5822a..09125aa 100644 --- a/developer/roc.rst +++ b/developer/roc.rst @@ -5,6 +5,10 @@ ROC Development =============== +.. warning:: ROC is being archived and is no longer part of the OnRamp + install/uninstall workflow. This page is retained for historical + reference only and no longer reflects a supported configuration. + ROC implements Aether's runtime control API. It is implemented on top of `µONOS `_, a microservice-based redesign of the ONOS SDN Controller. Of particular note, ROC generates diff --git a/intro.rst b/intro.rst index af7b1a3..7836bde 100644 --- a/intro.rst +++ b/intro.rst @@ -32,11 +32,12 @@ radios. Other Aether guides available on this site include: -* :doc:`Developing for Aether `: Learn how to +* :doc:`Developing for Aether `: Learn how to contribute back to Aether. -* :doc:`Runtime Operations `: Learn how - to operate Aether's 5G connectivity service. +* :doc:`Runtime Operations `: Historical documentation + of the now-archived ROC GUI for operating Aether's 5G connectivity + service. Note that Aether was originally deployed as a centrally-managed cloud service with a dedicated ops team. The expectation was that @@ -62,9 +63,10 @@ available at: * :doc:`SD-Core Documentation ` * :doc:`SD-RAN Documentation ` -A third component, *ROC (Runtime Operational Control)*, is part of the -Aether Management Plane. This Guide documents how operators use ROC to -control Aether (see the NAV bar). ROC builds on µONOS (specifically +A third component, *ROC (Runtime Operational Control)*, was part of the +Aether Management Plane, historically used to control Aether's runtime +connectivity configuration (see the NAV bar). ROC is being archived and +is no longer installed by OnRamp; ROC built on µONOS (specifically the ``onos-config`` microservice), with additional documentation for developers available at: diff --git a/onramp/blueprints.rst b/onramp/blueprints.rst index 2fe2bcf..f5716be 100644 --- a/onramp/blueprints.rst +++ b/onramp/blueprints.rst @@ -58,9 +58,9 @@ Multiple UPFs The base version of SD-Core includes a single UPF, running in the same Kubernetes namespace as the Core's control plane. This blueprint adds the ability to bring up multiple UPFs (each in a different namespace), -and uses ROC to establish the *UPF-to-Slice-to-Device* bindings -required to activate end-to-end user traffic. The resulting deployment -is then verified using gNBsim. +requiring the *UPF-to-Slice-to-Device* bindings to be established +manually via the SD-Core webui to activate end-to-end user traffic. +The resulting deployment is then verified using gNBsim. The Multi-UPF blueprint includes the following: @@ -74,18 +74,11 @@ The Multi-UPF blueprint includes the following: in the same server, may also work, but is not actively maintained.) * New make targets, ``5gc-upf-install`` and ``5gc-upf-uninstall``, to - be executed after the standard SD-Core installation. The blueprint - also reuses the ``amp-roc-load`` target to activate new slices in ROC. + be executed after the standard SD-Core installation. * New Ansible role (``upf``) added to ``deps/5gc``, including a new UPF-specific template (``upf-5g-values.yaml``). -* New models file (``roc-5g-models-upf2.json``) added to the - ``roc-load`` role in ``deps/amp``. This models file is applied as a - patch *on top of* the base set of ROC models. (Since this blueprint - is demonstrated using gNBsim, the assumed base models are given by - ``roc-5g-models.json``.) - * The OnRamp integration test suite validates the Multi-UPF blueprint. @@ -103,13 +96,12 @@ You can also optionally install the monitoring subsystem. .. code-block:: $ make k8s-install - $ make amp-roc-install - $ make amp-roc-load $ make 5gc-install $ make gnbsim-install -Note that because ``main.yml`` sets ``core.standalone: "false"``, any -models loaded into ROC are automatically applied to SD-Core. +Note that because ``main.yml`` sets ``core.standalone: "false"``, the +Device Groups and Slices bound to SD-Core must be entered manually via +the SD-Core webui rather than being provisioned automatically by simapp. At this point you are ready to bring up additional UPFs and bind them to specific slices and devices. An example configuration that brings @@ -155,25 +147,11 @@ type: At this point the new UPF(s) will be running in their own namespaces (you can verify this using ``kubectl get pods --all-namespaces``), but no traffic will be directed to them until UEs are assigned to their IP -address pool. Doing so requires loading the appropriate bindings into -ROC, which you can do by editing the ``roc_models`` line in ``amp`` -section of ``vars/main.yml``. Comment out the original models file -already loaded into ROC, and uncomment the new patch that is to be -applied: - -.. code-block:: +address pool. Doing so requires manually configuring a second Device +Group, Slice, and UPF binding via the SD-Core webui so that the new IP +address pool is associated with the second UPF. - amp: - # roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models.json" - roc_models: "deps/amp/roles/roc-load/templates/roc-5g-models-upf2.json" - -Then run the following to load the patch: - -.. code-block:: - - $ make amp-roc-load - -At this point you can bring up the Aether GUI and see that a second +At this point you can bring up the SD-Core webui and see that a second slice and a second device group have been mapped onto the second UPF. Now you are ready to run traffic through both UPFs, which because the @@ -388,22 +366,15 @@ differences from the 5G case: ``values_file: "deps/4gc/roles/core/templates/radio-4g-values.yaml"`` * The ``amp`` section of ``vars/main.yml`` specifies that 4G-specific - models and dashboards get loaded into the ROC and Monitoring - services, respectively: - - ``roc_models: "deps/amp/roles/roc-load/templates/roc-4g-models.json"`` + dashboards get loaded into the Monitoring service: ``monitor_dashboard: "deps/amp/roles/monitor-load/templates/4g-monitor"`` -* You need to edit two files with details for the 4G SIM cards you - use. One is the 4G-specific values file used to configure SD-Core: +* You need to edit the 4G-specific values file used to configure + SD-Core with details for the 4G SIM cards you use: ``deps/4gc/roles/core/templates/radio-4g-values.yaml`` - The other is the 4G-specific Models file used to bootstrap ROC: - - ``deps/amp/roles/roc-load/templates/radio-4g-models.json`` - * There are 4G-specific Make targets for SD-Core (e.g., ``make aether-4gc-install`` and ``make aether-4gc-uninstall``), but the Make targets for AMP (e.g., ``make aether-amp-install`` and ``make diff --git a/onramp/devel.rst b/onramp/devel.rst index 53d0a62..7ea2057 100644 --- a/onramp/devel.rst +++ b/onramp/devel.rst @@ -15,7 +15,8 @@ are referred to documentation for the respective subsystems: * To develop SD-RAN, see the :doc:`SD-RAN Guide `. -* To develop the ROC-based API, see :doc:`ROC Development `. +* ROC is being archived; see :doc:`ROC Development ` + for historical background on the runtime control API. * To develop Monitoring Dashboards, see :doc:`Monitoring Development `. @@ -200,18 +201,12 @@ primarily take care of bookkeeping; automating bookkeeping tasks Finally, keep in mind that in using SD-Core to illustrate how to build a customized modify-and-test loop, this section doesn't address some -of the peculiarities of the other components. As one example, ROC has -prerequisites that have to be installed before the ROC itself. These -prereqs are identified in the ROC installation playbook, and include -``onos-operator``, which in turn depends on ``atomix``. - -As another example, the ROC and monitoring services allow you to -program new features by loading alternative "specifications" into the -running pods (in addition to installing new container images). This -approach is described in the :doc:`ROC Development ` -and :doc:`Monitoring Development ` sections, -respectively, and implemented by the ``roc-load`` and ``monitor-load`` -roles found in ``deps/amp/roles``. +of the peculiarities of the other components. For example, the +monitoring service allows you to program new features by loading +alternative "specifications" into the running pods (in addition to +installing new container images). This approach is described in the +:doc:`Monitoring Development ` section, and +implemented by the ``monitor-load`` role found in ``deps/amp/roles``. diff --git a/onramp/gnb.rst b/onramp/gnb.rst index 4c6b39d..cdc59ce 100644 --- a/onramp/gnb.rst +++ b/onramp/gnb.rst @@ -72,7 +72,7 @@ using. .. code-block:: core: - standalone: true # set to false to place under control of ROC + standalone: true # set to false to manage device groups/slices manually via the SD-Core webui data_iface: ens18 values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml" ran_subnet: "" # set to empty string to get subnet from 'data_iface' @@ -197,9 +197,8 @@ Aether supports multiple *Device Groups* and *Slices*, but the data entered here is purposely minimal; it's just enough to bring up and debug the installation. Over the lifetime of a running system, information about *Device Groups* and *Slices* (and the other -abstractions they build upon) should be entered via the ROC, as -described in the :doc:`Runtime Control ` section. When -you get to that point, Ansible variable ``standalone`` in +abstractions they build upon) can instead be entered via the SD-Core +webui. When you get to that point, Ansible variable ``standalone`` in ``vars/main.yml`` (which corresponds to the override value assigned to ``provision-network-slice`` in ``sdcore-5g-values.yaml``) should be set to ``false``. Doing so causes the ``device-groups`` and diff --git a/onramp/inspect.rst b/onramp/inspect.rst index 3204ee8..ddbad03 100644 --- a/onramp/inspect.rst +++ b/onramp/inspect.rst @@ -13,67 +13,24 @@ tool to trace the flow of packets into and out of SD-Core. Install AMP ~~~~~~~~~~~~~~~ -The Aether Management Platform (AMP) is implemented by two Kubernetes -applications: *Runtime Operational Control (ROC)* and a *Monitoring -Service*.\ [#]_ AMP can be deployed on the same cluster as SD-Core by -executing the following Make target: +The Aether Management Platform (AMP) provides a *Monitoring +Service* with Dashboards showing different aspects of Aether's +runtime behavior. AMP can be deployed on the same cluster as SD-Core +by executing the following Make target: .. code-block:: $ make aether-amp-install -Once complete, ``kubectl`` will show the ``aether-roc`` and -``cattle-monitoring-system`` namespaces running in support of these -two services, respectively, plus new ``atomix`` pods in the -``kube-system`` namespace. Atomix is the scalable key-value store -that keeps the ROC data model persistent. +Once complete, ``kubectl`` will show the ``cattle-monitoring-system`` +namespace running in support of this service. -.. [#] Note that what the implementation calls ROC, `Chapter 6 - `__ refers to - generically as *Service Orchestration*. - -You can access the dashboards for the two subsystems, -respectively, at +You can access the Monitoring dashboard at .. code-block:: - http://:31194 http://:30950 -The programmatic API underlying the Control Dashboard, which was -introduced in `Section 6.4 -`__, can -be accessed at ``http://10.76.28.113:31194/aether-roc-api/`` in our -example deployment (where Aether runs on host ``10.76.28.113``). Note -that if you visit that URL from a browser, OpenAPI will show you -example GET, DELETE, and POST requests. Those examples assume the -prefix ``http://10.76.28.113:31194/aether-roc-api/`` (not just -``http://10.76.28.113:31194``), so for example, to GET the resource -corresponding to ``site-1``, you would need to use the following URL: - -.. code-block:: - - http://10.76.28.113:31194/aether-roc-api/aether/v2.1.x/the-enterprise/site/site-1 - -There is much more to say about the ROC and the Aether API, which we -return to in the :doc:`Runtime Control ` section. For -now, we suggest you simply peruse the Control Dashboard by starting -with the dropdown menu in the upper right corner. For example, -selecting `Devices` will show the set of UEs registered with Aether, -similar to the screenshot in :numref:`Figure %s `. In an -operational setting, these values would be entered into the ROC -through either the GUI or the underlying API. For the Quick Start -scenario we're limiting ourselves to in this section, these values are -loaded from ``deps/amp/5g-roc/templates/roc-5g-models.json``. - -.. _fig-roc: -.. figure:: figures/ROC-Dashboard.png - :width: 700px - :align: center - - Screenshot of the ROC dashboard, showing known *Devices*. The - dropdown menu on the right lists other available pages. - Turning to the Monitoring Dashboard, you will initially see Kubernetes-related performance stats. Select the *5G Dashboard* option to display information reported by SD-Core. Similar to :numref:`Figure @@ -98,18 +55,8 @@ to tear it down: $ make aether-amp-uninstall Finally, while we have been using a single Make target to install -(uninstall) AMP as a whole, there are per-component targets for both -ROC and Monitoring if you are interested in only one or the other. For -ROC: - -.. code-block:: - - $ make amp-roc-install - $ make amp-roc-load - $ ... - $ make amp-roc-uninstall - -and for Monitoring: +(uninstall) AMP as a whole, there is also a per-component target if +you want finer-grained control: .. code-block:: @@ -118,13 +65,11 @@ and for Monitoring: $ ... $ make amp-monitor-uninstall -In both cases, installing the component is a two-step process: first -the microservices that implement the component are instantiated on -Kubernetes and then service-specific data is loaded into the running -containers. For ROC, that data populates the models that define the -API. For Monitoring, that data specifies the dashboard panels. In -general, there are per-component targets for all of the Aether-wide -(``aether-*``) targets; see the Makefile for details. +Installing the Monitoring component is a two-step process: first +the microservices that implement it are instantiated on Kubernetes, +and then dashboard panel data is loaded into the running +containers. In general, there are per-component targets for all of +the Aether-wide (``aether-*``) targets; see the Makefile for details. View Logs ~~~~~~~~~~~~~~~~ diff --git a/onramp/network.rst b/onramp/network.rst index ff0c50b..acfa68e 100644 --- a/onramp/network.rst +++ b/onramp/network.rst @@ -214,7 +214,7 @@ sections, but for a summary, see the :doc:`Quick Reference `. .. code-block:: core: - standalone: true # set to false to place under control of ROC + standalone: true # set to false to manage device groups/slices manually via the SD-Core webui data_iface: ens18 values_file: "deps/5gc/roles/core/templates/sdcore-5g-values.yaml" ran_subnet: "172.20.0.0/16" # set to empty string to get subnet from 'data_iface' diff --git a/onramp/ref.rst b/onramp/ref.rst index e9cc4f7..89d9a21 100644 --- a/onramp/ref.rst +++ b/onramp/ref.rst @@ -87,7 +87,8 @@ the list is not comprehensive. - Overlay subnet connecting Core to RAN when gNBs run in a container; set to empty string ("") when gNBs are directly connected via `core.data_iface`. * - `core.standalone` - `true` - - Core to run standalone, initialized from values file; set to `false` when Core is to be initialized by ROC. + - Core to run standalone with simapp-managed subscribers; set to + `false` to manage device groups/slices via SD-Core webui. * - `core.data_iface` - `ens18` - Network interface used by UPF; same as `gnbsim.data_iface` when co-located on a single server. @@ -184,8 +185,6 @@ substitute custom config files. - Default Path Name * - `amp.monitor_dashboard` - `deps/amp/roles/monitor-load/templates/5g-monitoring/` - * - `amp.roc_models` - - `deps/amp/roles/roc-load/templates/roc-5g-models.json` * - `core.values_file` - `deps/5gc/roles/core/templates/sdcore-5g-values.yaml` * - `gnbsim.servers` @@ -288,9 +287,9 @@ Quick Start Blueprint. * - `aether-gnbsim-run` - Run gNBsim containers; may rerun multiple times without reinstalling. * - `aether-amp-install` - - Installs and initializes both ROC and Monitoring workloads. + - Installs and initializes the Monitoring workload. * - `aether-amp-uninstall` - - Uninstalls both ROC and Monitoring workloads. + - Uninstalls the Monitoring workload. Other blueprints define component-specific targets, as listed in the following table. (The Aether-wide targets can also be used for all @@ -301,12 +300,6 @@ other blueprints.) .. list-table:: :widths: 25 50 - * - `amp-roc-install` - - Install ROC workload. - * - `amp-roc-load` - - Load model values into ROC; assumes ROC already deployed. - * - `amp-roc-uninstall` - - Uninstall ROC workload. * - `amp-monitor-install` - Install Monitor workload. * - `amp-monitor-load` diff --git a/onramp/roc.rst b/onramp/roc.rst index fd890a0..3c4a3d0 100644 --- a/onramp/roc.rst +++ b/onramp/roc.rst @@ -1,6 +1,11 @@ Runtime Control ----------------------------------- +.. warning:: The ROC (Runtime Operational Control) subsystem described in + this section is being archived and is no longer installed, loaded, or + supported by OnRamp (``amp-roc-install``/``amp-roc-load`` targets have + been removed). This page is retained for historical reference only. + Aether defines an API (and associated GUI) for managing connectivity at runtime. This stage brings up that API/GUI, as implemented by the *Runtime Operational Control (ROC)* subsystem, building on the diff --git a/operations/application.rst b/operations/application.rst index d37b53f..1cd1866 100644 --- a/operations/application.rst +++ b/operations/application.rst @@ -7,6 +7,11 @@ Application Management ====================== +.. warning:: This section documents application management via the ROC + web GUI. ROC is being archived and is no longer installed or + supported by OnRamp. This page is retained for historical reference + only. + Aether allows configuration of the application endpoints that a device is allowed to connect to. You can configure not only whether or not an application endpoint is reachable, but also what maximum bitrate and diff --git a/operations/gui.rst b/operations/gui.rst index f75db22..8b7a84c 100644 --- a/operations/gui.rst +++ b/operations/gui.rst @@ -5,6 +5,10 @@ Aether GUI Basics ===================== +.. warning:: This section documents the ROC web GUI. ROC is being + archived and is no longer installed or supported by OnRamp. This + page is retained for historical reference only. + This section documents common aspects and features of the GUI. .. _committing: diff --git a/operations/monitor.rst b/operations/monitor.rst index c7434ee..0f6cd5b 100644 --- a/operations/monitor.rst +++ b/operations/monitor.rst @@ -5,6 +5,10 @@ Built-In Monitoring ==================== +.. warning:: This section documents monitoring built into the ROC web + GUI. ROC is being archived and is no longer installed or supported + by OnRamp. This page is retained for historical reference only. + This section documents features built-in to the GUI for monitoring. .. note:: Although monitoring icons remain visible in the GUI, the diff --git a/operations/slice.rst b/operations/slice.rst index 5b7f315..66b6e0a 100644 --- a/operations/slice.rst +++ b/operations/slice.rst @@ -5,6 +5,10 @@ Slice Management ================ +.. warning:: This section documents slice management via the ROC web + GUI. ROC is being archived and is no longer installed or supported + by OnRamp. This page is retained for historical reference only. + A **Slice** is a unit of network access for a set of UEs with a defined set of QOS parameters. The following properties are important to the definition of a slice: diff --git a/operations/subscriber.rst b/operations/subscriber.rst index 7483573..e61a8f0 100644 --- a/operations/subscriber.rst +++ b/operations/subscriber.rst @@ -7,6 +7,11 @@ Subscriber and Device Management ================================ +.. warning:: This section documents subscriber and device management via + the ROC web GUI. ROC is being archived and is no longer installed or + supported by OnRamp. This page is retained for historical reference + only. + Subscriber management includes workflows associated with provisioning new subscribers, removing existing subscribers, and associating subscribers with slices.