Software Base Architecture
The software is a java web application that supports one simple REST API for support Health Check and Statistical information. Upon invocation, the code will be able to spin up a thread that performs the work to respond to SDC Service Distribution notifications. There will be a layer of shared code between the Health Check, Statistics and the implementation of the Service Distribution in order for each to interact.
Health Check and Statistics Information
Statistics shall be kept to keep track of Service Distribution notifications and subsequent artifact downloads that occur during a Service Distribution.
Stopping and Starting the application via Command Line
Starting and stopping the application should mirror the functionality similar to the Drools PDP as documented in Beijing Wiki: Policy Cookbook
SDC class implementation
According to the SDC Project's documentation: SDC Distribution client AID, the client needs to register as a SDC client, and acts as a publisher too then publish the distribution status event.
the policy platform will need to implement several classes that derive from IConfiguration, INotificationCallback, IDistributionStatusMessageBasic, IComponentDoneStatusMessage,
IDistributionStatusMessage, IResourceInstance, IVfModuleData etc.
- register for distribution needs implement IConfiguration and INotificationCallback;
- Get Distribution Notification and analysize the artifact and CSAR needs implement IResourceInstance and IVfModuleData; TBD
- publish Download and Deployment status event needs implements IDistributionStatusMessageBasic, IComponentDoneStatusMessage and IDistributionStatusMessage.
for the IConfiguration, it configures all the necessary settings for a client to interact with SDC, below table is based on Beijing release:
Value Tobe set in Policy
Comment from Lando, Michael
This needs to be defined in sdc and then used in the client to access our secure api’s please open a task for me to create one for you.
Same as above.
This is the env name you are running in used for auditing from which env the client is connecting
Use of Policy API
The current existing Policy API as documented in the readthedocs:
However, that interface will be pluggable in anticipation of the new Policy Lifecycle API which begins implementation in Casablanca and is targeted for Dublin release.
Software Structure Sketch
The diagram above shows a draft sketch of the software for the Policy SDC Service Distribution component. It should be sufficiently detailed to enable commencement of the implementation of the SDC Distribution component in the ONAP Policy Framework.
The component has three packages, the main package of the component, a Policy unmarshaling component, and a policy forwarding component.
The SDCDistributionMain package reads the parameters from the JSON parameter file provided as a command line parameter. Based on the parameters, it sets up Policy unmarshaling and policy forwarding as well as starting life cycle management.
Policy unmarshaling receives policies from SDC and unmarshals them using the policy decoder specified in the parameters. In the case of TOSCA PDP-X decoding, the PolicyDecoderToscaPdpX implementation is used to read the parameters from the TOSCA description and to create a XACML policy. In the cases where a Drools or APEX policy is packaged in the CSAR, other policy decoders are invoked to decode the policy.
Policy forwarding has two implementations, one for working towards the current PAP that is in the Engine component of the Policy Framework, and another for working towards the PAP in the evolved Policy Framework architecture.
Handling Multiple Subscriptions to SDC
There may, of course, be multiple subscriptions to SDC from Policy for different policies. For each subscription, a pair of PolicyUnmarshaling-PolicyForwarding linked instances are required. There are two implementation options here:
- Option 1: Start an instance of the Policy Framework SDC Service Distributor (PF-SSD) for each policy subscription. This is the simplest solution to implement. The configuration for SDC, policy unmarshaling and policy forwarding are passed to the PF-SSD when it starts. The obvious disadvantage of this approach is that it is very heavyweight and inefficient if there are more than a handful of Policy subscriptions to SDC because every subscription will require a separate Docker container to run.
- Option 2 (Recommended Option): A PF-SSD instance can handle multiple subscriptions. The PF-SSD starts a thread and allocates a PolicyUnmarshaling-PolicyForwarding linked instance pair for each Policy subscription to SSD. The initial subscriptions can be configured using a configuration file passed to PF-SSD at startup. Subscriptions can be added and removed to and from PF-SSD at run time over the REST interface. The advantages of this approach is that it is much more efficient than option 1 and it allows subscriptions to be managed at run time on the fly. The disadvantage is that implementation is a little more complex.
Note: It should be possible to have multiple PF-SSD instances but it is likely that a single PF-SSD will be able to handle thousnads of policy subscriptions to SSD and should be sufficient.
Reception, Forwarding and Model Components