Gitiles
Code Review Sign In
gerrit.nordix.org / onap / dcaegen2 / platform / policy-handler / f2d7bef13705812c1bf147c2fb65162fbf385c6b
commitf2d7bef13705812c1bf147c2fb65162fbf385c6b[log] [tgz]
authorAlex Shatov <alexs@att.com>Thu May 10 09:23:16 2018 -0400
committerAlex Shatov <alexs@att.com>Thu May 10 09:23:16 2018 -0400
treee6efb8e25287576a48952942aacdb3cf84a825ff
parent50bed534083c96cbf1f8fa4e220cb2b00dff9621 [diff]
2.4.3 policy-handler - try-catch top Exceptions

- added try-except for top level Exception into all threads
  of policy-handler to avoid losing the thread and tracking
  the unexpected crashes
- rediscover the deployment-handler if not found before
  and after each catchup
- refactored audit - separated metrics from audit
- added more stats and runtime info to healthcheck
  = gc counts and garbage info if any detected
  = memory usage - to detect the potential memory leaks
  = request_id to all stats
  = stats of active requests
- avoid reallocating the whole Queue of policy-updates after catchup
  = clear of the internal queue under proper lock

Change-Id: I3fabcaac70419a68bd070ff7d591a75942f37663
Signed-off-by: Alex Shatov <alexs@att.com>
Issue-ID: DCAEGEN2-483
16 files changed
tree: e6efb8e25287576a48952942aacdb3cf84a825ff
  1. etc/
  2. etc_customize/
  3. etc_upload/
  4. policyhandler/
  5. tests/
  6. .coveragerc
  7. .gitignore
  8. .gitreview
  9. Dockerfile
  10. LICENSE.txt
  11. MANIFEST.in
  12. mvn-phase-script.sh
  13. pom.xml
  14. README.md
  15. requirements.txt
  16. run_policy.sh
  17. setup.py
  18. tox-local.ini
  19. tox.ini
  20. 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
    - `"scope_prefixes" : ["DCAE.Config_"]` - the list of policy-scope-class values
    - `"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(Customizer, self).__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(Customizer, self).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