Removing kind-voltha and addressing some other comments
Change-Id: I11e7aa9b9c6c703cf30eeaf1764a067ca7c70243
diff --git a/.gitignore b/.gitignore
index c0fb2d1..e65eff4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,11 +13,12 @@
voltha-openolt-adapter
voltha-openonu-adapter
voltha-openonu-adapter-go
-kind-voltha
+voltha-helm-charts
voltha-protos
voltha-system-tests
voltctl
cord-tester
+device-management-interface
# IDEs
.idea
diff --git a/Makefile b/Makefile
index a521984..b9f8ce4 100644
--- a/Makefile
+++ b/Makefile
@@ -11,7 +11,7 @@
# Other repos with documentation to include.
# edit the `git_refs` file with the commit/tag/branch that you want to use
-OTHER_REPO_DOCS ?= bbsim cord-tester ofagent-go openolt voltctl voltha-openolt-adapter voltha-openonu-adapter voltha-openonu-adapter-go voltha-protos voltha-system-tests kind-voltha device-management-interface
+OTHER_REPO_DOCS ?= bbsim cord-tester ofagent-go openolt voltctl voltha-openolt-adapter voltha-openonu-adapter voltha-openonu-adapter-go voltha-protos voltha-system-tests device-management-interface voltha-helm-charts
# Static docs, built by other means (usually robot framework)
STATIC_DOCS := _static/voltha-system-tests _static/cord-tester
diff --git a/git_refs b/git_refs
index 0063114..f9840b5 100644
--- a/git_refs
+++ b/git_refs
@@ -23,5 +23,5 @@
voltha-openonu-adapter-go / master
voltha-protos / master
voltha-system-tests / master
-kind-voltha / master
device-management-interface / master
+voltha-helm-charts / master
diff --git a/index.rst b/index.rst
index 646f320..b8d8d75 100644
--- a/index.rst
+++ b/index.rst
@@ -38,8 +38,6 @@
- :doc:`./overview/architecture_overview`
- :doc:`./overview/deployment_environment`
-- :doc:`./overview/workflows`
-- :doc:`./overview/quickstart`
- :doc:`./overview/troubleshooting`
Community
@@ -58,11 +56,10 @@
overview/architecture_overview.rst
overview/deployment_environment.rst
+ Deploy VOLTHA <voltha-helm-charts/README.md>
overview/workflows.rst
- overview/quickstart.rst
overview/operate.rst
overview/troubleshooting.rst
- readme
.. toctree::
:maxdepth: 1
@@ -76,7 +73,6 @@
Openolt Agent <openolt/README.md>
VOLTHA CLI <voltctl/README.md>
VOLTHA Protos <voltha-protos/README.md>
- Kind-voltha <kind-voltha/README.md>
.. toctree::
:maxdepth: 1
diff --git a/logging/centralised_log_analysis.rst b/logging/centralised_log_analysis.rst
index 9d45dec..5c1e94d 100644
--- a/logging/centralised_log_analysis.rst
+++ b/logging/centralised_log_analysis.rst
@@ -7,25 +7,19 @@
Operators should be able to view logs from all the VOLTHA components as
well as from whitebox OLT devices in a single stream.
-Solution Approach For Voltha Ecosystem
+Solution Approach For VOLTHA Ecosystem
--------------------------------------
The solution we have chosen EFK (elasticsearch, kibana and
fluentd-elasticsearch) setup for voltha enables the Operator to push
logs from all VOLTHA components.
-Kind-Voltha script enables Operator to setup EFK with minimal
-configuration.The configuration set for EFK in minimal-values.yaml or
-full-values.yaml start efk stack with a single node elasticsearch and
+To deploy VOLTHA with the EFK stack follow
+`these instructions <../voltha-helm-charts#enable-log-correlation-in-voltha-optional>`_.
+
+This will deploy Efk stack with a single node elasticsearch and
kibana instance will be deployed and a fluentd-elasticsearch pod will be
-deployed on each node that allows workloads to be scheduled.If you have
-the prerequisites installed, just execute
-
-.. code:: bash
-
- $ DEPLOY\_K8S=y WITH\_BBSIM=y WITH\_EFK=y ./voltha up
-
-and the minimal cluster with efk should start.
+deployed on each node that allows workloads to be scheduled.
The number of deployed Pods will be dependent on the value of Deployment
Type and SCHEDULE\_ON\_CONTROL\_NODES flag as shown in the below table.
@@ -34,9 +28,6 @@
:width: 6.50000in
:height: 1.50000in
-To remove voltha efk use DEPLOY\_K8S=y ./voltha down or, to avoid
-removing the k8s cluster DEPLOY\_K8S=n WITH\_EFK=y ./voltha down
-
**To start using Kibana, In your browser ,navigate to
http://<k8s\_node\_ip>:<exposed\_port>.** Then you can search for events
in the *Discover* section.
diff --git a/overview/deployment_environment.rst b/overview/deployment_environment.rst
index 45f3b9a..9f4815b 100644
--- a/overview/deployment_environment.rst
+++ b/overview/deployment_environment.rst
@@ -12,8 +12,8 @@
Regardless of the chosen environment the deployment process is the same,
more on this later, and the installation can be managed in the same way.
-Managing a VOLTHA deployment
-----------------------------
+VOLTHA deployment
+-----------------
VOLTHA components on top of ``kubernetes`` are managed via ``helm`` charts.
For more information about ``helm`` please refer to the `Official Documentation
@@ -49,8 +49,7 @@
You can read more about VOLTHA deployments in:
- :doc:`lab_setup`
-- :doc:`pod_physical`
-- :doc:`dev_virtual`
+- `Deployment with HELM <./../voltha-helm-charts/README.md>`_
.. toctree::
:maxdepth: 1
@@ -58,12 +57,4 @@
:glob:
./lab_setup.rst
- ./pod_physical.rst
- ./dev_virtual.rst
- ./multi-stack.rst
-
-Tooling
--------
-
-To simplify the installation of VOLTHA we provided a tool called ``kind-voltha``.
-You can read more on :doc:`kind-voltha <../kind-voltha/README>` in its own documentation.
+ Deploy VOLTHA <./../voltha-helm-charts/README.md>
diff --git a/overview/dev_virtual.rst b/overview/dev_virtual.rst
deleted file mode 100644
index 586b160..0000000
--- a/overview/dev_virtual.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-.. _dev_virtual:
-
-Developing code with a virtual VOLTHA POD
-=========================================
-
-A guide to install a virtual POD. A virtual pod is generally used to gain familiarity with the
-environment or for development and testing purposes.
-
-How is it different from a Physical deployment?
------------------------------------------------
-
-The main difference is in the ``kubernetes`` cluster itself.
-In a Physical deployment we assume that the ``kubernetes`` cluster is installed
-on 3 (or mode) physical nodes.
-When installing a ``virtual`` cluster we refer to a ``kind`` (``kubernetes-in-docker``)
-cluster.
-
-Another common difference is that a Physical deployment is generally associated
-with one or more physical OLTs while a Virtual deployment normally emulates the
-PON network using :doc:`BBSim <../bbsim/docs/source/index>`.
-
-.. figure:: ../_static/voltha_cluster_virtual.png
- :alt: VOLTHA Component Diagram
- :width: 100%
-
- VOLTHA Kubernetes kind deployment
-
-Note that is anyway possible to connect a physical OLT to a virtual cluster, as
-long as the OLT is reachable from the ``kind`` host machine. If you need to control
-your OLT "in-band" then it's not advised to connect it to a virtual cluster.
-
-Quickstart
-----------
-
-Requires:
-
-- ``docker`` and ``go`` installed on your machine
-- `kind-voltha <https://gerrit.opencord.org/gitweb?p=kind-voltha.git>`_ cloned
- on your machine
-
-.. code:: bash
-
- TYPE=minimal WITH_RADIUS=y CONFIG_SADIS=y WITH_BBSIM=y ./voltha up
-
-For more information you can visit the :doc:`kind-voltha page <../kind-voltha/README>`.
-
-Developing changes on a virtual pod
------------------------------------
-
-We assume you already have downloaded the git repository you want to modify and
-your IDE is correctly set up.
-
-In this tutorial we are going to use ``voltha-go`` as an example.
-
-Make the required changes in the ``voltha-go`` repository (the process
-is the same for all the VOLTHA repositories) to the code and build the
-docker images and push them on your private dockerhub account:
-
-.. code:: bash
-
- $ DOCKER_REGISTRY="matteoscandolo/" DOCKER_TAG="dev" make docker-build
-
-Then push them to your docker hub account:
-
-.. code:: bash
-
- $ DOCKER_REGISTRY="matteoscandolo/" DOCKER_TAG="dev" make docker-push
-
-Deploy your changes on kind-voltha
-----------------------------------
-
-Create a copy of the `minimal-values.yaml` file:
-
-.. code:: bash
-
- $ cp minimal-values.yaml dev-values.yaml
-
-And edit that file so that it contains the appropriate values for the images you want to try,
-for example uncomment and change these two lines (mind the indentation):
-
-.. code:: yaml
-
- images:
- ro_core:
- repository: matteoscandolo/voltha-ro-core
- tag: dev
- rw_core:
- repository: matteoscandolo/voltha-rw-core
- tag: dev
-
-Then redeploy `kind-voltha` using that the edited value file:
-
-.. code:: bash
-
- $ DEPLOY_K8S=no ./voltha down && DEPLOY_K8S=no EXTRA_HELM_FLAGS="-f dev-values.yaml" ./voltha up
diff --git a/overview/lab_setup.rst b/overview/lab_setup.rst
index d0fb41b..8c11c70 100644
--- a/overview/lab_setup.rst
+++ b/overview/lab_setup.rst
@@ -11,7 +11,9 @@
- The ``RG`` can be emulated by an ``lxc`` container (from now on ``client``)
- The ``BNG`` can be emulated by a Linux server
-- The ``AggSwitch`` is optional in a VOLTHA deployment.
+- The ``AggSwitch`` is mandatory if control of the OLT is done with ``in-band`` mode, while
+ optional if the OLT is controlled out of band, in this case the NNI port of the OLT will go directly
+ into the emulated BNG linux server NIC card.
.. figure:: ../_static/voltha_lab_setup.png
:alt: VOLTHA Lab Setup
@@ -196,3 +198,17 @@
option routers 10.11.2.254;
option domain-name-servers 8.8.8.8;
}
+
+Configuration for in-band OLT control
+-------------------------------------
+
+If OLT is being used in in-band connectivity mode, the
+`document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
+details the configuration aspects in ONOS and the aggregation switch to
+trunk/switch in-band packets from the OLT to BNG or Voltha.
+
+In-band OLT software upgrade
+-------------------------------------
+If OLT with openolt agent is being used in in-band connectivity mode we provide the capability
+to execute SW updates of the image present on the device, the
+`README <https://github.com/opencord/openolt/tree/master/olt-sw-upgrade>`_ provides the required details.
diff --git a/overview/multi-stack.rst b/overview/multi-stack.rst
deleted file mode 100644
index 3ce4c3d..0000000
--- a/overview/multi-stack.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-Deploy multiple VOLTHA stacks on a Kubernetes cluster
-=====================================================
-
-VOLTHA is designed so that multiple stacks can work together sharing the same infrastructure.
-You can read more about VOLTHA Stacks in this `document <https://docs.google.com/document/d/1Szo7vMS7M96O4Vsm1NpDYd3zckk9g0HLMck6eldwmcI/edit?usp=sharing>`_.
-
-This guide assumes you have a ``kubernetes`` cluster already up and running.
-We also assume you have familiarity with the `kind-voltha <../kind-voltha/README.html>`_. tool.
-
-Deploy the common infrastructure
---------------------------------
-
-When we refer to `infrastructure` components in VOLTHA, we are referring to:
-
-- ``Kafka``
-- ``ETCD``
-- ``ONOS``
-- ``RADIUS Server`` (optional)
-- ``Sadis Server`` (optional)
-
-*Note that these components can be deployed on ``kubernetes`` via ``kind-voltha`` or can be completely independent.*
-
-.. code:: bash
-
- NAME=infra INFRA_NS=infra JUST_INFRA=y ./voltha up
-
-Note that this command will output configurations that you'll need to deploy your ``VOLTHA`` stack:
-
-.. code:: bash
-
- To configure your VOLTHA stack to use this infrastructure please export these variables:
- export INFRA_NS=infra
- export WITH_ETCD=etcd.infra.svc:2379
- export WITH_KAFKA=kafka.infra.svc:9092
- export WITH_ONOS=onos-onos-classic-hs.infra.svc:6653
-
- Or use:
-
- INFRA_NS=infra WITH_ETCD=etcd.infra.svc:2379 WITH_KAFKA=kafka.infra.svc:9092 WITH_ONOS=onos-onos-classic-hs.infra.svc:6653 ./voltha up
-
- If you are deploying mutltiple VOLTHA stack, also remember to configure a different NAME, NAMESPACE and BBSIM_BASE_INDEX for each stack:
- export NAME=voltha1
- export VOLTHA_NS=voltha1
- export ADAPTER_NS=voltha1
- export BBSIM_NS=voltha1
- export BBSIM_BASE_INDEX=1
-
- Or use:
-
- INFRA_NS=infra WITH_ETCD=etcd.infra.svc:2379 WITH_KAFKA=kafka.infra.svc:9092 WITH_ONOS=onos-onos-classic-hs.infra.svc:6653 NAME=voltha1 VOLTHA_NS=voltha1 ADAPTER_NS=voltha1 BBSIM_NS=voltha1 BBSIM_BASE_INDEX=1 ./voltha up
-
-Deploy a VOLTHA stack
----------------------
-
-Once the ``infrastructure`` is set up you can deploy a ``VOLTHA`` stack using this command:
-
-.. code:: bash
-
- NAME=voltha1 VOLTHA_NS=voltha1 ADAPTER_NS=voltha1 BBSIM_NS=voltha1 BBSIM_BASE_INDEX=1 ./voltha up
-
-NOTE that this command assumes you have exported the variables printed at the end of the ``infra`` deployment.
-In particular the required variables are:
-
-- ``INFRA_NS=infra`` (optional) only required if you installed the infrastructure using ``kind-voltha``
-- ``WITH_ETCD=etcd.infra.svc:2379`` the ETCD address
-- ``WITH_KAFKA=kafka.infra.svc:9092`` the KAFKA address
-- ``WITH_ONOS=onos-onos-classic-hs.infra.svc:6653`` the ONOS address
-
-Deploying multiple VOLTHA stacks
-********************************
-
-When you deploy a second ``VOLTHA`` stack there are some information that you need to customize in order to keep the
-two stacks independent:
-
-- ``NAME`` - the name of the stack, is used in log and configuration files and to customize the KAFKA topics each stack
- is listening on
-- ``VOLTHA_NS, ADAPTER_NS, BBSIM_NS`` - are used to configure in which namespace the components are installed
-- ``BBSIM_BASE_INDEX`` - is used to guarantee that different ``BBSim`` instances won't have the same ID (have to be
- unique across all the stacks)
-
-Operate a VOLTHA stack
-----------------------
-
-Once the installation completes a ``voltctl`` config file is generated for each cluster, in the format:
-
-.. code:: bash
-
- VOLTCONFIG="~/.volt/config-<$NAME>"
-
-In order to use multiple stacks via the same ``voltcl`` tools we **strongly** suggest to **always** specify
-the appropriate configuration with the ``-c`` flag, for example:
-
-.. code:: bash
-
- voltctl -c ~/.volt/config-voltha1 adapter list
diff --git a/overview/operate.rst b/overview/operate.rst
index bbc5619..68231c3 100644
--- a/overview/operate.rst
+++ b/overview/operate.rst
@@ -50,7 +50,7 @@
Authentication
--------------
-If the use-case you installed (e.g. AT&T) expects EAPOL based authentication you want to make
+If the worflow you installed (e.g. AT&T) expects EAPOL based authentication you want to make
sure that is working. Visit :ref:`workflows` for more information.
In a **Physical POD** you need to trigger authentication on your client
@@ -75,7 +75,7 @@
*Note that, depending on the workflow, authentication is not a requirement of subscriber provisioning*
The process referred to as ``Subscriber provisioning`` causes traffic flows to be created in ONOS and
- data plane path to be configured in the device, enabling different services on a specific UNI port.
+data plane path to be configured in the device, enabling different services on a specific UNI port.
In order to provision a subscriber you need to identify it. In ONOS a subscriber
is viewed as an enabled port (UNI) on the logical switch that VOLTHA exposes, for example:
@@ -140,7 +140,7 @@
DHCP Allocation
---------------
-If the use-case you installed expect DHCP to be handled by ONOS it's time to check
+If the worflow you installed expect DHCP to be handled by ONOS it's time to check
that an IP has correctly been allocated to the subscriber.
In a **Physical POD** you need to trigger a DHCP request on your client
diff --git a/overview/pod_physical.rst b/overview/pod_physical.rst
deleted file mode 100644
index 91be3a6..0000000
--- a/overview/pod_physical.rst
+++ /dev/null
@@ -1,56 +0,0 @@
-.. _pod_physical:
-
-Deploy a physical VOLTHA POD
-============================
-
-This document assumes you POD is already correctly cabled, if not you can
-refer to :ref:`lab_setup`
-
-Requires:
-
-- a physical kubernetes cluster
-- `kind-voltha <https://gerrit.opencord.org/gitweb?p=kind-voltha.git>`_ cloned
- on your machine
-
-
-Enter the ``kind-voltha`` directory and execute this command (``kubectl`` must
-be installed and pointing to your cluster):
-
-.. code:: bash
-
- DEPLOY_K8S=no WITH_RADIUS=y CONFIG_SADIS=y SADIS_CFG="my-sadis-cfg.json" ./voltha up
-
-*``my-sadis-cfg.json`` is a reference to your own ``sadis`` configuration.
-This is needed to specify the appropriate values for your devices and subsribers*
-
-If you already have a ``radius`` server that you want to use, change the flag to ``WITH_RADIUS=n``
-and `configure ONOS accordingly <https://github.com/opencord/aaa>`_.
-
-For more information please check :doc:`kind-voltha page <../kind-voltha/README>`.
-
-After the deployment please refer to :ref:`operate` .
-
-HA Cluster
-----------
-
-To deploy ONOS in a multi instance environment for redundancy, High avaliablity and scale, you can add
-`NUM_OF_ONOS=3 NUM_OF_ATOMIX=3` to any of the workflow command. You can pick the number of instances onf ONOS
-and ATOMIX independently. As a good suggestion is 3 or 5.
-
-If you are planning to support a big number of ONU we suggest to horizontally scale
-the ``openonu-adapater``, you can do so by setting the ``NUM_OF_OPENONU`` variable.
-Generally speaking a single ``openonu-adapter`` instance can support up to 200 ONU devices.
-
-As an example for the ATT workflow:
-
-.. code:: bash
-
- WITH_RADIUS=y CONFIG_SADIS=y SADIS_CFG="my-sadis-cfg.json" NUM_OF_ONOS=3 NUM_OF_ATOMIX=3 NUM_OF_OPENONU=8 ./voltha up
-
-Configuration for in-band OLT control
--------------------------------------
-
-If OLT is being used in in-band connectivity mode, the following
-`document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
-details the configuration aspects in ONOS and the aggregation switch to
-trunk/switch in-band packets from the OLT to BNG or Voltha.
diff --git a/overview/quickstart.rst b/overview/quickstart.rst
deleted file mode 100644
index e043b79..0000000
--- a/overview/quickstart.rst
+++ /dev/null
@@ -1,75 +0,0 @@
-.. _quickstart:
-
-Quickstart
-==========
-
-This page contains a set of one liner useful to setup different VOLTHA use-cases on
-a Virtual pod emulating the PON through :doc:`BBSim <../bbsim/docs/source/index>`.
-
-For more information on how to setup a :doc:`physical POD <./pod_physical>` or
-use a :doc:`Virtual POD <./dev_virtual>` for development
-refer to the respective guides.
-
-Common setup
-------------
-
-In order to install VOLTHA you need to have ``golang`` and ``docker`` installed.
-
-.. code:: bash
-
- export KINDVOLTHADIR=~/kind-voltha
- mkdir $KINDVOLTHADIR
- cd $KINDVOLTHADIR
- curl -sSL https://raw.githubusercontent.com/opencord/kind-voltha/master/voltha --output ./voltha
- chmod +x ./voltha
-
-Now select the use-case you want to deploy:
-
-ATT Workflow
-------------
-
-The ATT Workflow expects EAPOL based authentication and DHCP to be handled within
-the VOLTHA POD.
-
-.. code:: bash
-
- cd $KINDVOLTHADIR
- WITH_BBSIM="yes" WITH_EAPOL="yes" WITH_DHCP="yes" WITH_RADIUS="yes" CONFIG_SADIS="bbsim" ./voltha up
-
-DT Workflow
-------------
-
-The DT workflow does not require EAPOL based authentication or DHCP packet handling
-in the VOLTHA POD.
-
-.. code:: bash
-
- cd $KINDVOLTHADIR
- WITH_BBSIM="yes" WITH_EAPOL="no" WITH_DHCP="no" CONFIG_SADIS="bbsim" BBSIM_CFG="configs/bbsim-sadis-dt.yaml" ./voltha up
-
-TT Workflow
-------------
-
-The TT workflow does not require EAPOL based authentication but expects DHCP packets
-for multiple services to be handled within the POD.
-
-.. code:: bash
-
- cd $KINDVOLTHADIR
- WITH_BBSIM="yes" WITH_EAPOL="no" WITH_DHCP="yes" CONFIG_SADIS="bbsim" BBSIM_CFG="configs/bbsim-sadis-tt.yaml" ./voltha up
-
-Post deploy actions
--------------------
-
-Once the deployment completed, make sure to export the required ``environment``
-variables as ``kind-voltha`` outputs:
-
-.. code:: bash
-
- export KUBECONFIG="/Users/teone/.kube/kind-config-voltha-minimal"
- export VOLTCONFIG="/Users/teone/.volt/config-minimal"
- export PATH=/Users/teone/kind-voltha/bin:$PATH
-
-Once you have the POD up and running you can refer to the :doc:`./operate` guide.
-
-For more information please check :doc:`kind-voltha page <../kind-voltha/README>`.
diff --git a/overview/workflows.rst b/overview/workflows.rst
index 25bb7e6..fb550e2 100644
--- a/overview/workflows.rst
+++ b/overview/workflows.rst
@@ -5,27 +5,25 @@
``Workflow`` is a term that spilled from the SEBA Reference Design (RD) into VOLTHA.
-In SEBA a workflow is defined as the set of operations that control the lifecycle
-of a subscriber, authentication logic, customer tag management etc... Such workflow is operator specific.
+In SEBA a workflow is a collection of subscriber management items like identification, location,
+and bandwidth profile. In addition each workflows maps to a service type which translates to a technology profile,
+and an operator desired flow of operations (i.e state-machine).
+The workflow is implemented by a selection of ONOS apps, XOS services (in SEBA)
+and a set of configurations (sadis, etcd, netcfg). Those apps paired with the configuration specified by the
+workflow (e.g. need EAPOL) in turn create low level flows, groups, meters, schedulers, queues etc.
+A workflow is then triggered by a particular set of APIs, for example the request to add a subscriber.
-A full description of the workflows can be `found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_.
+A full description of the different operator's workflows can be
+`found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_.
A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator).
-Given that NEM is not available in a plain VOLTHA deployment the definition
-of workflow is a subset of the SEBA one, and comprises:
+Given that NEM is not available in a plain VOLTHA deployment the user has to ensure proper config in the right places,
+and then triggering of api's themselves.
-- Customer tags allocation
-- Technology profile
-- Bandwidth profile
-- Flow management (EAPOL/DHCP/Data path)
-- Group management
+To deploy a specific workflow follow the steps in the voltha-helm-charts
+`README <./../voltha-helm-charts/README.md#deploying-a-different-workflow>`_.
-The `workflows` are often referred to as `use-cases` and the two words are interchangeable
-in the VOLTHA environment.
-
-To deploy a specific workflow through ``kind-voltha`` please visit :ref:`quickstart`.
-
-How is the workflow defined in VOLTHA?
+What does the workflow entail in VOLTHA?
----------------------------------------
Customer tag allocation