Iâm not sure I understand. On the one hand you say you donât want to make any changes to policies, but on the other hand you say youâre uncomfortable with trigger.
I am discussion two features, which I see as separate: "policies" (that have existed since TOSCA 1.0) and "policy triggers" (introduced in TOSCA 1.1).
I think the way "policies" are grammatically defined (without the "policy triggers") is fine. I think adding "policy triggers" (and other kinds of policy engine implementation algorithms) is not fine at all. They are much better implemented as properties in policy types instead of polluting the language with narrowly opinionated requirements.
It's all part of the same effort of separating the Simple Profile from the grammar, which is about allowing TOSCA to be used to model real platforms, not imaginary ones. In this case, I can imagine a vendor of a powerful, innovative policy engine looking at TOSCA 1.3's trigger mechanism and being quite disappointed. They would want users of TOSCA to be able to model the powerful features they offer (which may likely not be based on the Rete algorithm at all, which is 40 years old by now). Could they just ignore the policy triggers feature? Sure, that's what I do. Just like one could also ignore the Simple Profile types. But having this feature in the grammar itself introduces technical debt, bloat, and further confuses the field of TOSCA implementations, which will be picking and choosing which features to support.
I do think that the base "policies" syntax can be improved, though, specifically in relation to groups. Syntactically the two constructs work a bit similarly. I think with my new syntax proposal it's easier to associate policies to nodes (just like artifacts are associated with nodes) and also it makes the group concept clearer and possibly more useful for template design.
Â
However, triggers are actually the one and only thing that is defined by
a policy. Without triggers, there is nothing left in a policy definition.
I've shown a full demo in Turandot in which policies are central to how some subsystems work. In no case did I use TOSCA policy triggers. I actually have more demos for other domains, too. I find policies to be very useful indeed, without triggers.
Policy types have properties, and therein lies the richness of what you can model using TOSCA data types. You can model all the required parameters for the policy engine there, and can even model entire DSLs using data types if that's what you want (though I would imagine having them outside of TOSCA, as their own artifacts, would be better. Let each domain use the language best for it). The power of the policy type feature (without policy triggers) is that policy types are defined separately from node types. Having a separate hierarchy allows you to model these two different domains separately, and indeed import them from different profiles. E.g. you might have a "OpenStack" profile of node types and then a "Drools" profile of policy types and be able to associate the latter with the former, or mix and match with other domains.