Associated JIRA: POLICY-3754 - Getting issue details... STATUS
Focus is mainly given to PAP and API components here.
Spring boot related versions are specified in the policy-parent repository. The current versions specified are:
<version.springboot>2.5.0</version.springboot>
<version.springfox>3.0.0</version.springfox>
<version.io.micrometer>1.7.3</version.io.micrometer>
These are currently used by policy-clamp component only, which will be used by other policy components going forward.
As per the CLM report of policy clamp, spring-boot-starter-web dependency is causing security vulnerability. But, all versions seems to be affected.
So, upgrading to a different version will not solve the security vulnerability at this point.
Spring boot version can still be upgraded to the latest version, i.e. from 2.5.0 to 2.5.6.
List of common dependencies already in the PAP repository vs the one's that will be brought by spring boot are noted here: 
CommonDependencies.txt
With the migration to Spring Boot, most of the key metrics such as success/failure rates, counters etc. will be exposed by the application out of the box.
Investigation around handling DB interactions:
Policy Framework currently uses eclipselink. On using spring boot with hibernate, there are a lot of differences especially with table names, joined table names, column names in joined tables etc. It was identified that this problem can be solved in 3 ways:
- Update/Fix all the existing Entity classes by making use of the proper annotations to specify the names.
- Make use of eclipselink instead of hibernate with spring boot. Analyzed and tested the impacts of this, and there are huge performance impacts. The query time is drastically increased when going this route. So this is best to be avoided, and use spring boot -hibernate combo only.
- Use custom naming strategy and use it in the spring boot application - which seems to the easiest and best approach for solving the naming problem.
3rd approach mentioned above makes the migration possible without making any change to the existing schema.
Future work
Even the spring boot & hibernate combination cannot solve the current issues with Tosca handling. This has more to do with how they are structured in the database. Investigation was done around usage of document databases for Tosca handling.
Usage of spring boot and MongoDB seems to be much cleaner and viable option for solving the db related problems. MongoDB is used in ONAP by other projects as well. The policyadmin db can be easily moved to MongoDB once the spring boot migration is done.
This could also help with the requirement for having separate databases for PDPs running in different tenants.
Changes expected for migrating policyadmin db from MariaDB to MongoDB in the PAP and API projects (After spring boot migration):
- Changes in service and repository classes + updating mongodb dependency in pom.xml.
- Remove all JpaXXX classes from the models.
- Any other changes related to OOM, CSITs and db-migrator
Document databases are better suited for storing data without a particular schema, hence they are a better choice for the persistence of runtime states in PDP engines as well.