Interface Notifications

[anfss]

Hi,

Interface notifications are not working for me.
Can anyone share an example with notifications?

Thank you

[anzoman]

Hi, thanks for starting this discussion.

Currently we don't have any solid example with interface notifications. This is mostly because TOSCA is not describing this part in detail and gives just one small example, so we did not find any real use case for that. This means that xOpera doesn't do anything but just parse the interface notifications. We tried to use the interface notifications to allow scaling but we rather proceeded with with TOSCA triggers and policies.

If you have any good example on how these notifications could be used you're welcome to explain it here and we can see if this is something that can be implemented within xOpera.

[anzoman]

Many thanks for your view on this feature! @cankarm, @sstanovnik, @dradX, @alexmaslenn do you have something to add here or did you ever try to understand or use these TOSCA notifications?

[cankarm]

Thanks for initiating the discussion trying to clarify TOSCA standard ideas and features.

I never looked closely at the notifications and I would have the same questions as you, @anfss, regarding how to make the implementation part. For me, it is not clear if this would define a concrete monitoring agent(notification agent), that sends the notification to the orchestrator, or, maybe only the "receiving point and handling" for the notification at the orchestrator.

Regarding the trigger.... I guess it has the implementation part? There you can define, how to set up a new node?

[anfss]

So, this means that the orchestrator doesn't try to instantiate new nodes (node templates) that become possible when the requirements become valid with new data that is introduced by external services (for example through notifications outputs).
The only way to have the installation of new services will be to imperatively execute scripts that make their configuration and execution, without this being reflected in the set of node templates managed by the orchestrator.

[anzoman]

Yes @anfss, the instantiation of new nodes (e.g. new VMs) at runtime along with TOSCA triggers is currently possible mostly through trigger operations (i.e., Ansible playbooks). We did not focus so much on deploying new nodes through TOSCA during runtime because the standard does not provide much examples on that.

So, basically when you run opera notify CLI command the operations from triggers are invoked and there you can for instance perform various scaling actions. There is also another way - since TOSCA service templates specify a set of nodes that need to be instantiated at service deployment time, we have opera update CLI command, which lets you redeploy your service template based on the discovered changes in the template and in the instances. So, this brings a possibility to instantiate new nodes on TOSCA level. Please also check our docs and examples and feel free to reach out again if you have any additional questions or suggestions.

[anfss]

Thank you. The "opera update" CLI command can be the solution for my problem.
Please consider to include notifications in a next version, it would be appreciated.
Once again, thank you very much.