Skip to end of metadata
Go to start of metadata

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

# Example Output from curl http -a '{user}:{password}' :8443/healthcheck
HTTP/1.1 200 OK
Content-Length: XXX
Content-Type: application/json
Date: Tue, 17 Apr 2018 10:51:14 GMT
Server: Jetty(9.3.20.v20170531)
{ 
         "code":200,
         "healthy":true,
         "message":"alive",
         "name":"Policy SSD",
         "url":"self"
}

Statistics shall be kept to keep track of Service Distribution notifications and subsequent artifact downloads that occur during a Service Distribution.

# Example Output from curl http -a '{user}:{password}' :8443/statistics
HTTP/1.1 200 OK
Content-Length: XXX
Content-Type: application/json
Date: Tue, 17 Apr 2018 10:51:14 GMT
Server: Jetty(9.3.20.v20170531)
{ 
         "code":200,
         "distributions":10,
         "distribution_complete_ok":8,
         "distribution_complete_fail":2,
         "downloads":15,
         "downloads_ok"; 10,
         "downloads_error": 5
}


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:

function

Value Tobe set in Policy

Comment from Lando, Michael

String getAsdcAddress()

Sdcip


List<String> getMsgBusAddress()

DMAAP address?

 Yes

String getUser()

SDC-1480

 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.

String getPassword()

SDC-1480

 Same as above.

int getPollingInterval()

20


int getPollingTimeout()

30


List<String> getRelevantArtifactTypes()

TOSCA_CSAR

 yes

String getConsumerGroup();


 policy-group

String getEnvironmentName();

TEST

 This is the env name you are running in used for auditing from which env the client is connecting

String getKeyStorePath();

Null


String getKeyStorePassword();

Null


boolean activateServerTLSAuth()

False


boolean isFilterInEmptyResources()

True


Boolean isUseHttpsWithDmaap()

False




Use of Policy API

The current existing Policy API as documented in the readthedocs:

http://onap.readthedocs.io/en/beijing/submodules/policy/engine.git/docs/platform/offeredapis.html

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:

  1. 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.
  2. 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.

Class Diagrams

Reception, Forwarding and Model Components 

  • No labels

8 Comments

  1. is it implemented in R1? how about R2? 

    1. No neither R1 or R2 - no resources. Most likely R3

      1. Pamela Dragosh If you are still looking for resources, I am ready to take up this task. Need some more information on this.

        1. Bharath - sure we have an Epic for Casablanca for this work and a few User Stories to start. It would be good to review SDC's SDK and API to understand how it works.

          POLICY-701 - Getting issue details... STATUS

          The repository has been setup, but there won't be any Jenkins Jobs available for another week until we get done with Beijing. So I will not accept code quite yet. But filling this wiki out with flow diagrams could be a good start.

          1. Sure Pamela Dragosh, I will look into SDC's SDK and API. And then will update the wiki with my understanding.

            1. Bharath Thiruveedula - are you still available to help build this functionality? We are planning Casablanca and could use the help? Please let me know, thanks! Pam

              1. Pamela Dragosh, yes I am still available to work on this. I have gone through the document you shared. I have few questions on how sdc artifacts are being converted to policies. If you have any plan/document can you share or will discuss in next weekly meeting

          2. in the POLICY-701, the whole work about integrate with Policy is not details. like implement Configuration, Callback, capture artifact type, unit test, download resource or service CSAR, tosca parse etc.  i'm wondering if we could refer to another comp like SO/AAI , since they are currently the SDC client and should have a similar common work list about integration with SDC.  does it make sense?


            i can't find the work list in JIRA SO/AAI,  suspect the reason is that these tasks have been done before they are open sourced.