...

• values (example "description", "metadata", ...)
• data structure (example Create or Delete of a ToscaEntity, or Update a reference as "type", "type_version" or "host_namespace")

Open questions about participants

• Case scenario: we have two custom service template, a common service template and two automation composition. participant-policy creates and deletes policies and policy types connecting to policy-api.
  • Could we have that scenario?
  • Should participant-policy receive a full service template (custom and common service template)?
  • Should participant policy collect all policies and policy types by GET policy-api, to know if them are already created?
  • How participant policy know if can delete a policy and policy type if it could be used to other automation composition?
• Case scenario: we have two custom service template. A participant is defined in only one of them.
  • Could we have that scenario?
  • Should participant receive only the custom service template related? (A table to save relations between service templates and participants)

Proposals

Proposals

• We could consider Service templates references to each other as a DAG ( directed acyclic graph), where Service templates are nodes, and a references as edges. Cyclic references are not allowed.
• Should be available a functionality to load a full version of the service template that contains own tosca entities and also all tosca entities referenced from other service templates (this functionality in for validation or business logic purpose and will be not visible to the end user)
• A service template cannot be deleted if there are references to it
• Any Tosca Entity in a common service template cannot be deleted if there are references to that service template
• Any Tosca Entity in a common service template cannot change "host_namespace", "type" and "type_version" if there are references to that service template
• Any Tosca Entity in a common service template cannot change values if there are automation compositions referenced to that service template (and references to that service template?)
• A Tosca Entity cannot be add in a common service template if there are automation compositions referenced to that service template
• Functionality as create, update and delete of a ToscaEntity in a service template should be validated and restricted to the service template itself. (Example: update property values of a service template should never update property values from other service templates referenced)
• To reduce the complexity, could be useful to save additional information about the service template:
  • A
• We could consider Service templates references to each other as a DAG ( directed acyclic graph), where Service templates are nodes, and a references as edges. Cyclic references are not allowed.
• Should be available a functionality to load a
  • full version of the service template that contains own tosca entities and also all tosca entities referenced from other service templates
  (this functionality in for validation or business logic purpose and will be not visible to the end user)
• A service template cannot be deleted if there are references to it
• Any Tosca Entity in a common service template cannot be deleted if there are references to that service template
• Any Tosca Entity in a common service template cannot change "host_namespace", "type" and "type_version" if there are references to that service template
• Any Tosca Entity in a common service template cannot change values if there are automation compositions referenced to that service template (and references to that service template?)
• A Tosca Entity cannot be add in a common service template if there are automation compositions referenced to that service template
• Functionality as create, update and delete of a ToscaEntity in a service template should be validated and restricted to the service template itself. (Example: update property values of a service template should never update property values from other service templates referenced)
• To reduce the complexity, could be useful to save additional information about the service template:
  • A full version of the service template that contains own tosca entities and also all tosca entities referenced from other service templates. it will be used in read-only for business logic purpose
  • A table to save relations between service templates
  • A table to save relations between service templates and automation compositions (with all service templates referenced)

Conclusion

• • . it will be used in read-only for business logic purpose
  • A table to save relations between service templates
  • A table to save relations between service templates and automation compositions (with all service templates referenced)

Conclusion

• Move to document storage does not change the functionality of the application. Example if clampacm move to document storage, and policyadmin not yet, those applications will continue to work fine.
• Enable namespace and enable to handle more than one service template, impacts functionalities and applications dependency. Example if clampacm has namespace enabled, and policyadmin not yet, due the dependency, they could have some issues.

• Document storage Optional?: using SpringBoot profiles and interfaces it could be possible to have a double implementation and run only one, (based on parameter in properties file), but it does not make sense due the second point.

  Work in progress