Gitiles
Code Review Sign In
gerrit.nordix.org / onap / dcaegen2 / platform / policy-handler / 1c4c6626f2abb24bcb35af581c6e57130f0ccae2
commit1c4c6626f2abb24bcb35af581c6e57130f0ccae2[log] [tgz]
authorAlex Shatov <alexs@att.com>Fri Aug 10 11:03:02 2018 -0400
committerAlex Shatov <alexs@att.com>Fri Aug 10 11:03:02 2018 -0400
tree50685aa2bbb965a6a281eef50e449b48c2e3e87c
parentd7f34d4b71ec4d86547628cda351d20bff4d017f [diff]
4.0.1 fix for removing the non-matching policy

- fixed removing the policy that no longer match the filter
  = sending an empty policy_filter_matches for the policy_id
- cleaner workaround on getting the updated policy
  when policy-engine sent policy-update notification
  before finishing the update on there side
  = using the collection of expected_versions instead
    of min_version_expected
- some minor refactoring on policy_matcher and audit

Change-Id: Ica3cb810378e61d6991c616f88265ff170d32a64
Signed-off-by: Alex Shatov <alexs@att.com>
Issue-ID: DCAEGEN2-492
9 files changed
tree: 50685aa2bbb965a6a281eef50e449b48c2e3e87c
  1. etc/
  2. etc_customize/
  3. etc_upload/
  4. policyhandler/
  5. tests/
  6. .coveragerc
  7. .gitignore
  8. .gitreview
  9. Dockerfile
  10. INFO.yaml
  11. LICENSE.txt
  12. MANIFEST.in
  13. mvn-phase-script.sh
  14. pom.xml
  15. README.md
  16. requirements.txt
  17. run_policy.sh
  18. setup.py
  19. tox-local.ini
  20. tox.ini
  21. version.properties
README.md

policy_handler

web-service for policies to be used by DCAE-Controller

  • GET /policy_latest/<policy-id> -- get the latest policy from policy-engine
  • receives the push notifications from policy-engine through the web-socket, filters and gets the full policy-configs, and delivers that to deploy-handler

manual http API

  • GET /catch_up -- catch up with the latest state of the policy-engine
  • GET /policies_latest -- get all the latest policies in policy-engine through web-service API
  • GET /shutdown -- shutdown the server

installation

virtualenv policy_venv

cd policy_venv

source bin/activate

cd ../policy_handler

pip install -r requirements.txt

preparation to run

cd policy_venv

source bin/activate

cd ../policy_handler

configure

in folder policy_handler:

- `config.json` contains
    - `"policy_engine"` - the http connect info to ONAP **policy-engine**
        - headers.ClientAuth : base64(<mech-id with namespace>:<password>)
        - headers.Authorization : base64(<policy-engine server auth>)
    - `"deploy_handler"` - the http connect info to _policy part_ of the **deploy-handler**
- `policy_engine.properties` contains config info for the client lib of ONAP **policy-engine** that receives push notifications from the ONAP **policy-engine** server
    - CLIENT_ID is the mech-id with the namespace - need to register with policy-engine team thru email
    - CLIENT_KEY is the base64 of the mech-id password - separate passwords for TEST versus PROD

run

in folder policy_handler:

./run_policy.sh

customization per company

etc_customize/ folder

  • company is expected to place any company specific files required to be in the docker image in the folder etc_customize/

  • change the etc_customize/customize.sh script to perform company specific actions during docker image build

  • etc_customize/customize.sh script is expected to be overridden by company to customize docker image build

policyhandler/customize/ folder

contains CustomizeBase and Customize classes

  • CustomizeBase defines the interface and the default=ONAP behavior

  • CustomizeBase is owned by ONAP and should not be changed by the company

  • Customize inherits CustomizeBase

  • policy-handler instantiates Customize to get the customized behavior

  • Customize is owned by the company and should be changed by the company

  • ONAP is not going to change Customize

  • the methods of Customize are expected to be overridden by the company to change the behavior of the policy-handler

  • samples are provided for methods in Customize class as the commented out lines

  • Company is allowed to add more files to customize/ folder if that is required for better structuring of their code as soon as it is invoked by the methods of Customize

here is an example of customizer.py

"""contains the Customizer class with method overrides per company specification"""

from .customizer_base import CustomizerBase

class Customizer(CustomizerBase):
    """
    the Customizer class inherits CustomizerBase that is owned by ONAP

    :Customizer: class is owned by the company that needs to customize the policy-handler

    :override: any method defined in the CustomizerBase class to customize the behavior of the policy-handler
    """
    def __init__(self):
        """class that contains the customization"""
        super().__init__()

    def get_service_url(self, audit, service_name, service):
        """
        returns the service url when called from DiscoveryClient

        this is just a sample code - replace it with the real customization
        """
        service_url = super().get_service_url(audit, service_name, service)
        audit.info("TODO: customization for service_url on {0}".format(service_name))
        return service_url

    def get_deploy_handler_kwargs(self, audit):
        """
        returns the optional dict-kwargs for requests.post to deploy-handler

        this is just a sample code - replace it with the real customization
        """
        kwargs = {"verify": "/usr/local/share/ca-certificates/aafcacert.crt"}
        audit.info("kwargs for requests.post to deploy-handler: {0}".format(json.dumps(kwargs)))
        return kwargs