In the current implementation, ACM supports multi-participant with same supported element Type but different participantId, so they need different properties file.
...
Participant replicas can be a kubernetes StatefulSets that consume different properties file with unique consumer groups and unique UUIDs/replica (participants with same UUIDs have different replica number).
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 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 as before any composition definition in prime time to specific participant based of supported element definition type. All participant will receive the same messages and store same data, so all participants are synchronized with ACM-R. Into all messages from ACM-R to participants will be present the replica number to indicate what participant will do the job (like prime or deploy).
Changes in Participant:
- Register, Status and Unregister message have to contain the replica number
- store data from messages from ACM-R if the participantId is matching and enable the actions only if the participantId and replica number are matching with the message
- store data (outProperties, and action completed) from messages from participants with same participantId and different replica
Changes in ACM-R:
- Save the replica numbers available
- Random replica into any message to participants
Changes in docker/Kubernetes environment
- implement StatefulSets
Solution 3: Replicas and Database support - no cache
...
- 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:
...