Introduction
Currently policy-participant dons not support more than one instance of the same composition definition due the policy type and policy saved into service templatethe composition definition. For same reason there are specific implementations that involves ACM-runtime and intermediary to support policy-participant:
- At deployment action ACM-Runtime fetches policy type and policy from service template and add them into the deploy message
- Intermediary saves in memory policy type and policy from deploy message to be available in any in subsequent instance actions
Backward compatibility
policy-participant is not into the EIC deployment, so dons not be necessarily backward compatibility. What have to be :
- The deploy message from ACM-r to participants has to be as before: the toscaServiceTemplateFragment field could contain an empty ToscaServiceTemplate object;
- The InstanceElementDto record has to be as before: toscaServiceTemplateFragment field will be not used, but the old constructor contains this filed, so that constructor cannot be deleted;
Service template and instance
...
- In "policy/docker" insert the policy type and policy into the instance. That submit will be backward compatible
- Make the policy-participant changes in ACM. That submit will work due the changes done before
- In "policy/docker" remove the policy type and policy from the service template. That submit will be OK due the policy-participant updated
Regression test
Replace service template and instance:
...
Before the policy-participant changes it needs some changes in regression tests:
- Use http-participant and sim-participantadd 8.0.0 functionality
- Update service template and instance accordingly with the point before