It would be useful to be able to configure the backend with plugin(s) capable of generating non-default artifacts from the SDC model.

The proposed solution is to add a context file to the jetty configuration that will add a plugins folder to the class path. Plugin jars can be added to the folder at deployment time (e.g. by a helm chart) and will be added to the class path by jetty.

This would allow deployments where some customization of the generated artifacts can be supported whilst not having any impact on the default deployment or any deployment where such customization is not desired.

Motivation:

SDC supports the generation of csars that can be consumed by other ONAP components such as SO for service orchestration. The logic of how the csars (and the artifacts within them) are generated is hardcoded in SDC. It would be useful in some scenarios to be able to generate additional artifacts from the SDC model. An example of this could be the generation of an ETSI SOL007 NS package that could be included in the service csar.

Some operators may not want an ETSI SOl007 package to be generated and included in the service csar, whereas other operators may wish to use an ETSI SOL007 package for service orchestration (there are proposals for Guilin to support ETSI SOL007 orchestration in SO). Therefore we are proposing a plugin mechanism, whereby the code for generating for example the ETSI SOL007 package can be isolated from the SDC code and only deployed where desired via helm charts.

Even for artifacts that are generally desirable, the mechanism gives a method of separating the generation of the artifact from the main body of the SDC code, rather than having potentially increasingly complex code if more artifacts are required. 

Solution:

An interface can be created in catalog-be that is to be implemented by plugins that will generate artifacts. Implementations of the interface can be injected into CsarUtils using standard springframework injection. When the csar is being generated in CsarUtils, the injected plugins will be invoked and the artifacts they return included in the generated csar. Where there are no plugins injected then the generated csar will be exactly the same as today.

In order for the plugins to be in injected into CsarUtils they must be available for discovery by spring. There are two parts to this:

1. The plugins must be in a package that is scanned by spring.

2. The plugins must be on the classpath.

In order to achieve 1 above, the package "org.openecomp.sdc.be.plugins" can be added to the ComponentScan in CatalogBESpringConfig.java.

In order to achieve 2 above, the following is proposed:

Jetty supports the addition of extra entries on the classpath via configuration of the WebAppContext class. This can be achieved by setting "extraClasspath" in a context confguration file to be the location of a directory. All jars included in that directory will be added to the classpath. It is proposed to add the directory "/var/lib/jetty/plugins" to the jetty classpath via this mechanism. By default, this directory will be empty and no plugins will be loaded. The base jetty image currently used by catalog-db is jetty:9.4-jre8-alpine, this does not support the "extraClasspath" configuration, however stepping the version to jetty:9.4.18-jre8-alpine will allow this mechanism to be used.

In order to create a plugin, the interface defined in catalog-be must be implemented by a class in package "org.openecomp.sdc.be.plugins" . This implementation does not need to be in the SDC repo, there may be cases where a plugin is generally desirable which can be implemented in an SDC repo and there may be cases where a plugin is of only niche interest and can be implemented elsewhere.

The helm charts in OOM can be used as is for SDC deployment where no plugins are desired. However in deployments where a plugin is desired, a helm chart can be written to add an init container that will copy a jar(s) from a docker image containing the plugin jar(s) to a volume. This volume can then be mounted to "/var/lib/jetty/plugins"  in sdc-backend, thus making the plugins available for injection into CsarUtils.