.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
-Developer-Guide
+Developer Guide
===============
.. contents::
Tech Stack
----------
-- OpenAPI3
-- Connexion
-- Flask with Gevent serving
-- Python3.7
+The A1 Mediator is implemented in Python, currently version 3.8, and
+depends on these third-party packages and technologies:
-Version bumping
----------------
+- OpenAPI3
+- Connexion
+- Flask with Gevent serving
+- Swagger
+- Prometheus
-This project follows semver. When changes are made, the versions are in:
-1) ``docs/release-notes.rst``
+Version bumping A1
+------------------
-2) ``setup.py``
+This project follows semver. When the version string changes, these
+files must be updated:
-3) ``container-tag.yaml``
+#. ``setup.py``
+#. ``container-tag.yaml``
+#. ``integration_tests/a1mediator/Chart.yaml``
+#. ``docs/release-notes.rst``
+#. ``a1/openapi.yaml`` But note this is an API version, not a software version; there's no need to bump on non-API changes.
+#. And over in the ric-plt/ric-dep repo that contains the A1 Mediator helm chart, files ``values.yaml`` and ``Chart.yaml``.
-4) ``integration_tests/a1mediator/Chart.yaml``
+It's convenient to use the Python utility `bumpversion` to maintain
+the first three items. After setup (``pip install bumpversion``) you
+can change the patch version like this::
-5) ``a1/openapi.yaml`` (this is an API version, not a software version; no need to bump on patch changes)
+ bumpversion --verbose patch
-6) in the ric-plt repo that contains a1 helm chart, ``values.yaml``, ``Chart.yml``
+Or change the minor version like this::
+ bumpversion --verbose minor
-Version bumping rmr
+After the `bumpversion` utility has modified the files, update the
+release notes then commit.
+
+
+Version bumping RMR
-------------------
-As of 2020/02/13, A1 (Dockerfile), Dockerfile-Unit-Test, and all three integration test receivers use a base image from o-ran-sc.
-The rmr version is in that base image.
-When version changes are made in that image, rebuilding those 5 containers in the A1 repo will pick it up (or just A1 itself for prod usage).
-However, there are two items in this repo that must be kept in sync: ``rmr-version.yaml``, which controls what rmr gets installed for unit testing in Jenkins, and ``integration_tests/install_rmr.sh`` which is a useful script for a variety of local testing.
+A1 (Dockerfile), Dockerfile-Unit-Test, and all three integration test
+receivers use an Alpine base image and install RMR from a base builder
+image. Must update and rebuild all 5 containers in the A1 repo (or
+just A1 itself for production usage).
+
+In addition these items in this repo must be kept in sync:
+
+#. ``rmr-version.yaml`` controls what rmr gets installed for unit
+ testing in Jenkins
+#. ``integration_tests/install_rmr.sh`` is a useful script for a
+ variety of local testing.
+
+
+Version bumping Python
+----------------------
+
+If you want to update the version of python; for example this was
+recently done to move from 3.7 to 3.8, update these files:
+
+#. ``Dockerfile``
+#. ``Dockerfile-Unit-Test``
+#. ``tox.ini``
-Version bumping pyrmr
+
+Running A1 Standalone
---------------------
-rmr-python is the python binding to rmr . Installing rmr per the above does not install it.
-Bumping the rmr python version is done via ``setup.py``
-Version bumping python itself
------------------------------
-If you want to update the version of python itself (ie just done from 37 to 38):
+The A1 container can be run standalone, which means using an in-memory mock
+version of SDL and a static route table. The host machine must have the RMR
+library and the environment must define the variable `prometheus_multiproc_dir`
+with a value like /tmp. Alternately, use the following command to run A1 as
+a Docker container, using a route table mounted as a file from this git
+repository and exposing the server's HTTP port on the Docker host::
+
+ docker run -e USE_FAKE_SDL=True -p 10000:10000 -v `pwd`:/opt/route [DOCKER_IMAGE_ID_HERE]
-1) ``Dockerfile``
+Then test the server with an invocation such as this::
-2) ``Dockerfile-Unit-Test``
+ curl localhost:10000/a1-p/healthcheck
-3) ``tox.ini``
Unit Testing
------------
-Note, before this will work, for the first time on the machine running the tests, run ``./install_deps.sh``. This is only needed once on the machine.
-Also, this requires the python packages ``tox`` and ``pytest``.
+
+Running the unit tests requires the python packages ``tox`` and ``pytest``.
+
+The RMR library is also required during unit tests. If running
+directly from tox (outside a Docker container), install RMR using the
+script in the integration_tests directory: ``install_rmr.sh``.
+
+Upon completion, view the test coverage like this:
::
tox
open htmlcov/index.html
-Alternatively, you can run the unit tests in Docker (this is somewhat less nice because you don't get the pretty HTML)
+Alternatively, you can run the unit tests in Docker (this is somewhat
+less nice because you don't get the pretty HTML)
::
- docker build --no-cache -t a1test:latest -f Dockerfile-Unit-Test
+ docker build --no-cache -f Dockerfile-Unit-Test .
+
Integration testing
-------------------
-This tests A1’s external API with three test receivers. This depends on helm+k8s.
-Build all the containers:
+This tests A1’s external API with three test receivers. This requires
+docker, kubernetes and helm.
+
+Build all the images:
::
- docker build -t a1:latest .; cd integration_tests/; docker build -t testreceiver:latest . -f Dockerfile-test-delay-receiver; docker build -t queryreceiver:latest . -f Dockerfile-query-receiver; cd ..
+ docker build -t a1:latest .
+ cd integration_tests/testxappcode
+ docker build -t delayreceiver:latest -f Dockerfile-delay-receiver .
+ docker build -t queryreceiver:latest -f Dockerfile-query-receiver .
+ docker build -t testreceiver:latest -f Dockerfile-test-receiver .
Then, run all the tests from the root (this requires the python packages ``tox``, ``pytest``, and ``tavern``).
tox -c tox-integration.ini
This script:
-1. Deploys 2 helm charts (4 containers) into a local kubernetes installation
-2. Port forwards a pod ClusterIP to localhost
-3. Uses “tavern” to run some tests against the server
-4. Barrages the server with apache bench
-5. Tears everything down
+
+#. Deploys 3 helm charts (5 containers) into a local kubernetes installation
+#. Port forwards a pod ClusterIP to localhost
+#. Uses “tavern” to run some tests against the server
+#. Barrages the server with Apache bench
+#. Tears everything down
Code Review / ric-plt / a1.git / blobdiff