Page Comparison

In the current implementation, ACM supports multi-participant with same supported element Type but different participantId, so they need different properties file.

...

Solution 1: Replicas and Dynamic participantId - still using cache

Changes in Participant intermediary:

• UUID participantId will be generated in memory instead to fetch it in properties file.
• consumerGroup will be generated in memory instead to fetch it in properties file.

...

Participant replicas can be a kubernetes StatefulSets that consume two different properties file with unique UUIDs and unique consumer groups.

The StatefulSet uses the SPRING_CONFIG_NAME environment variable pointing to the spring application properties file unique to each of the participant replica.

Each of the properties file with the names pod-0.yaml, pod-1.yaml is mounted to the volumes. And the SPRING_CONFIG_NAME variable can be set to /path/to/$HOSTNAME.yaml to use the corresponding

properties file. 

By this approach the participant can have multiple replicas with different UUIDs and kafka consumer groups to work with a shared data.

env:
- name: HOSTNAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name

- name: SPRING_CONFIG_NAME
  value: /path/to/${HOSTNAME}.yaml

For example considering the http participant replica, ${HOSTNAME} will be "policy-http-ppnt-0" and "policy-http-ppnt-1" and their 
corresponding properties files with the names "http-ppnt-0.yaml" and "http-ppnt-1.yaml" is volume mounted. 

Note: In a scenario of two participants in replicas (we are calling "policy-http-ppnt-0" and "policy-http-ppnt-1"), ACM-Runtime will assignee randomly any composition definition in prime time to specific participant based of supported element definition type. So we could have a scenario where a composition definition "composition 1.0.0" is assigned to policy-http-ppnt-0 and the instance too; the new composition "composition 1.0.1" is assigned to policy-http-ppnt-1. In that scenario the migration of an instance from "composition 1.0.0" to "composition 1.0.1" wouldn't work, because policy-http-ppnt-0 do not have "composition 1.0.1" assigned.

Issues:

• At migrate time - In that scenario the migration of an instance from "composition 1.0.0" to "composition 1.0.1" wouldn't work, because policy-http-ppnt-0 do not have "composition 1.0.1" assigned. This is a critical issue.

Solution 3: Replicas and Database support - no cache

Changes in Participant intermediary:

• Redesign TimeOut scenario: Participant has the responsibility to stop the thread in execution after a specific time.
• Add client support for database (MariaDB or PostgreSQL).
• Add mock database for Unit Tests.
• Refactor CacheProvider to ParticipantProvider to support insert/update, intermediary-participant with transactions.
• Refactor Intermediary to use insert/update of ParticipantProvider.
• Refactor Participants that are using own HashMap in memory (Policy Participant saves policy and policy type in memory)

Changes in Participant:

• Add @EnableJpaRepositories and @EntityScan in Application:

• 
  

  Code Block
  language java title Application
  @SpringBootApplication @EnableJpaRepositories({ "org.onap.policy.clamp.acm.participant.intermediary.persistence.repository" }) @ComponentScan({ "org.onap.policy.clamp.acm.participant.sim", "org.onap.policy.clamp.acm.participant.intermediary" }) @EntityScan({ "org.onap.policy.clamp.acm.participant.intermediary.persistence.concepts" }) @ConfigurationPropertiesScan("org.onap.policy.clamp.acm.participant.sim.parameters") public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

  
  

• Add db connection in properties file and properties file for tests:

spring:
  security:
    user:
      name: participantUser
      password: zb!XztG34
  mvc:
    converters:
      preferred-json-mapper: gson
  datasource:
    url: jdbc:mariadb://${mariadb.host:localhost}:${mariadb.port:3306}/participantsim
    driverClassName: org.mariadb.jdbc.Driver
    username: policy
    password: P01icY
    hikari:
      connectionTimeout: 30000
      idleTimeout: 600000
      maxLifetime: 1800000
      maximumPoolSize: 10
  jpa:
    hibernate:
      ddl-auto: update
      naming:
        physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
        implicit-strategy: org.onap.policy.common.spring.utils.CustomImplicitNamingStrategy
    properties:
      hibernate:
        format_sql: true

spring:
  datasource:
    url: jdbc:h2:mem:testdb
    driverClassName: org.h2.Driver
    hikari:
      maxLifetime: 1800000
      maximumPoolSize: 3
  jpa:
    hibernate:
      ddl-auto: create
    open-in-view: false

• Unit Tests may need some changes

Changes in docker/Kubernetes environment

...