Content Comparison

...

...

"application/vnd.onap.drools+text" refers to native drools drl text contents. When drools authors use this Content-Type in POST call, they only need to provide drl text contents into its payload. One payload example is shown as below:

package org.onap.policy.controlloop.ran;

import org.onap.policy.controlloop.ran.event.SampleMsEvent;
import org.onap.policy.controlloop.ran.Enodeb;
import org.slf4j.LoggerFactory;
import org.slf4j.Logger;

declare Params
  closedLoopControlName: String
end

rule "SETUP"
  when
  then
    Logger logger = LoggerFactory.getLogger(drools.getRule().getPackage());
    logger.info("{}: {}", params.getClosedLoopControlName(), drools.getRule().getName());
  
    Params params = new Params();
    params.setClosedLoopControlName("example-name");
    insert(params);
end

rule "EVENT"
  when
    $params : Params( $clName : getClosedLoopControlName() )
    $event : SampleMsEvent( closedLoopControlName == $clName )
  then
    Logger logger = LoggerFactory.getLogger(drools.getRule().getPackage());
    logger.info("{}: {}", params.getClosedLoopControlName(), drools.getRule().getName());

    Enodeb enb = new Enodeb($event);
    enb.reboot();
    retract($event);
end

One limitation of "application/vnd.onap.drools+text" Content-Type is, the payload only contains native drl contents without other dependency information (i.e. dependency artifacts) also required to load into drools memory to support execution of the native rules. In aforementioned example, "SampleMsEvent", "Enodeb" and "Logger" are from other dependency artifacts. When Drools PDP-D receives this set of native rules deployed from PAP, it does not know how many dependencies to load into memory along with the rule itself to support the rule execution. If the deployed rules cannot be executed due to missing dependencies, PAP policy deployment API should return 400 Bad Request.

To bridge the gap, one solution is to use "application/vnd.onap.drools+text" Content-Type only when there is modification to the rules (i.e. updating the rules) and the new updates will not introduce new dependency. Given a set of rules are already running in PDP-D and all required dependencies are loaded as well, now we have new requirement that means to change a logic in one rule, e.g. changing to reset enodeb other than reboot. All I want to modify is line #34 in above example, changing enb.reboot() to enb.reset() given both reboot() and reset() are supported in org.onap.policy.controlloop.ran.Enodeb dependency model. In this case, I can call the PUT call and use "application/vnd.onap.drools+text" Content-Type to update the rules.

Now the question is, how to bring in the new set of rules for a new application which has never run before in PDP-D? The second Content-Type "application/vnd.onap.drools.mvn+xml" is designed for this purpose. When policy author calls the POST call and use "application/vnd.onap.drools.mvn+xml" Content-Type, what they need to provide in the payload are, Maven XML dependency specification for a java artifact that contains new drl rules. Policy author needs to make sure that specified java artifact in this payload is already deployed to nexus repo used by runtime PDP-D engine before calling the POST API. Otherwise, this POST API should return 400 Bad Request if specified artifact is missing in nexus. 

To be discuss, where should we put this artifact existence check, in API or PAP ???

One example payload with "application/vnd.onap.drools.mvn+xml" Content-Type is shown as below, reusing aforementioned rule example.

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>

  <dependencies>
    <dependency>
      <groupId>org.onap.policy.controlloop</groupId>
      <artifactId>policy-ran-optimization</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>
  </dependencies>

</project>

2.2 PDP-X Content-Types

pam

...