.. code-block:: bash
- kubectl get pods | grep policy
-
- brmsgw ClusterIP 10.43.77.177 <none> 9989/TCP 5d15h app=brmsgw,release=dev-policy
- drools ClusterIP 10.43.167.154 <none> 6969/TCP,9696/TCP 5d15h app=drools,release=dev-policy
- nexus ClusterIP 10.43.239.92 <none> 8081/TCP 5d15h app=nexus,release=dev-policy
- pap NodePort 10.43.207.229 <none> 8443:30219/TCP,9091:30218/TCP 5d15h app=pap,release=dev-policy
- pdp ClusterIP None <none> 8081/TCP 5d15h app=pdp,release=dev-policy
- policy-apex-pdp ClusterIP 10.43.226.0 <none> 6969/TCP 5d15h app=policy-apex-pdp,release=dev-policy
- policy-api ClusterIP 10.43.102.56 <none> 6969/TCP 5d15h app=policy-api,release=dev-policy
- policy-distribution ClusterIP 10.43.4.211 <none> 6969/TCP 5d15h app=policy-distribution,release=dev-policy
- policy-pap ClusterIP 10.43.175.164 <none> 6969/TCP 5d15h app=policy-pap,release=dev-policy
- policy-xacml-pdp ClusterIP 10.43.181.208 <none> 6969/TCP 5d15h app=policy-xacml-pdp,release=dev-policy
- policydb ClusterIP 10.43.93.233 <none> 3306/TCP 5d15h app=policydb,release=dev-policy
-
-Some of these pods are shared between the legacy components and the latest framework components, while others are not.
-
-.. csv-table::
- :header: "Policy Pod", "Latest Framework", "Legacy"
- :widths: 15,10,10
-
- "brmsgw", "", "yes"
- "drools", "yes", "yes"
- "nexus", "yes", "yes"
- "pap", "", "yes"
- "pdp", "", "yes"
- "policy-apex-pdp", "yes", ""
- "policy-api", "yes", ""
- "policy-distribution", "yes", "yes"
- "policy-pap", "yes", ""
- "policy-xacml-pdp", "yes", ""
- "policydb", "yes", "yes"
+ kubectl get pods -n onap | grep dev-policy
+
+ dev-policy-59684c7b9c-5gd6r 2/2 Running 0 8m41s
+ dev-policy-apex-pdp-0 1/1 Running 0 8m41s
+ dev-policy-api-56f55f59c5-nl5cg 1/1 Running 0 8m41s
+ dev-policy-distribution-54cc59b8bd-jkg5d 1/1 Running 0 8m41s
+ dev-policy-mariadb-0 1/1 Running 0 8m41s
+ dev-policy-xacml-pdp-765c7d58b5-l6pr7 1/1 Running 0 8m41s
+
+.. note::
+ To get a listing of the Policy services, run this command:
+ kubectl get svc -n onap | grep policy
Accessing Policy Containers
***************************
kubectl -n onap exec -it dev-policy-policy-xacml-pdp-584844b8cf-9zptx bash
+.. _install-upgrade-policy-label:
+
Installing or Upgrading Policy
******************************
The assumption is you have cloned the charts from the OOM repository into a local directory.
From your local copy, edit any of the values.yaml files in the policy tree to make desired changes.
+The policy schema will be installed automatically as part of the database configuration using ``db-migrator``.
+By default the policy schema is upgraded to the latest version.
+For more information on how to change the ``db-migrator`` setup please see
+:ref:`Using Policy DB Migrator <policy-db-migrator-label>`.
+
**Step 2** Build the charts
.. code-block:: bash
make policy
- make onap
+ make SKIP_LINT=TRUE onap
+
+.. note::
+ SKIP_LINT is only to reduce the "make" time
**Step 3** Undeploy Policy
After undeploying policy, loop on monitoring the policy pods until they go away.
.. code-block:: bash
- helm del --purge dev-policy
- kubectl get pods -n onap
+ helm undeploy dev-policy
+ kubectl get pods -n onap | grep dev-policy
-**Step 4** Delete NFS persisted data for Policy
+
+**Step 4** Re-Deploy Policy pods
+
+After deploying policy, loop on monitoring the policy pods until they come up.
.. code-block:: bash
- rm -fr /dockerdata-nfs/dev-policy
+ helm deploy dev-policy local/onap --namespace onap
+ kubectl get pods -n onap | grep dev-policy
-**Step 5** Make sure there is no orphan policy database persistent volume or claim.
+.. note::
+ If you want to purge the existing data and start with a clean install,
+ please follow these steps after undeploying:
-First, find if there is an orphan database PV or PVC with the following commands:
+ **Step 1** Delete NFS persisted data for Policy
-.. code-block:: bash
+ .. code-block:: bash
- kubectl get pvc -n onap | grep policy
- kubectl get pv -n onap | grep policy
+ rm -fr /dockerdata-nfs/dev/policy
-If there are any orphan resources, delete them with
+ **Step 2** Make sure there is no orphan policy database persistent volume or claim.
-.. code-block:: bash
+ First, find if there is an orphan database PV or PVC with the following commands:
- kubectl delete pvc <orphan-policy-mariadb-resource>
- kubectl delete pv <orphan-policy-mariadb-resource>
+ .. code-block:: bash
-**Step 6** Re-Deploy Policy pods
+ kubectl get pvc -n onap | grep policy
+ kubectl get pv -n onap | grep policy
-After deploying policy, loop on monitoring the policy pods until they come up.
+ If there are any orphan resources, delete them with
-.. code-block:: bash
+ .. code-block:: bash
+
+ kubectl delete pvc <orphan-policy-mariadb-resource>
+ kubectl delete pv <orphan-policy-mariadb-resource>
- helm deploy dev-policy local/onap --namespace onap
- kubectl get pods -n onap
Restarting a faulty component
*****************************
kubectl -n onap expose service policy-api --port=7171 --target-port=6969 --name=api-public --type=NodePort
Overriding certificate stores
-*******************************
+*****************************
Policy components package default key and trust stores that support https based communication with other
AAF-enabled ONAP components. Each store can be overridden at installation.
This procedure is applicable to an installation that requires either AAF or non-AAF derived certificates.
The reader is refered to the AAF documentation when new AAF-compliant keystores are desired:
-* `AAF automated configuration and Certificates <https://docs.onap.org/en/latest/submodules/aaf/authz.git/docs/sections/configuration/AAF_4.1_config.html#typical-onap-entity-info-in-aaf>`_.
+* `AAF automated configuration and Certificates <https://wiki.onap.org/display/DW/Application+Authorization+Framework+%28AAF%29+Documentation>`_.
* `AAF Certificate Management for Dummies <https://wiki.onap.org/display/DW/AAF+Certificate+Management+for+Dummies>`_.
* `Instructional Videos <https://wiki.onap.org/display/DW/Instructional+Videos>`_.
-After these changes, follow the procedures in the :ref:`Installing or Upgrading Policy` section to make usage of
+After these changes, follow the procedures in the :ref:`install-upgrade-policy-label` section to make usage of
the new stores effective.
Additional PDP-D Customizations
Credentials and other configuration parameters can be set as values
when deploying the policy (drools) subchart. Please refer to
-`PDP-D Default Values <https://git.onap.org/oom/tree/kubernetes/policy/charts/drools/values.yaml>`_
+`PDP-D Default Values <https://git.onap.org/oom/tree/kubernetes/policy/components/policy-drools-pdp/values.yaml>`_
for the current default values. It is strongly recommended that sensitive
information is secured appropriately before using in production.
Additional customization can be applied to the PDP-D. Custom configuration goes under the
"resources" directory of the drools subchart (oom/kubernetes/policy/charts/drools/resources).
This requires rebuilding the policy subchart
-(see section :ref:`Installing or Upgrading Policy`).
+(see section :ref:`install-upgrade-policy-label`).
Configuration is done by adding or modifying configmaps and/or secrets.
Configmaps are placed under "drools/resources/configmaps", and
To *override the PDP-D keystore or trustore*, add a suitable replacement(s) under
"drools/resources/secrets". Modify the drools chart values.yaml with
new credentials, and follow the procedures described at
-:ref:`Installing or Upgrading Policy` to redeploy the chart.
+:ref:`install-upgrade-policy-label` to redeploy the chart.
To *disable https* for the DMaaP configuration topic, add a copy of
`engine.properties <https://git.onap.org/policy/drools-pdp/tree/policy-management/src/main/server/config/engine.properties>`_
Code Review / policy / parent.git / blobdiff