First, remove the "policies" section in the topology template and remove the "targets" keyword from policies. Instead, the reference will happen in the other direction, from node templates via the addition of an optional "policies" keyword, which is a list of policy assignments to be applied in order. This works a bit like the "artifacts" keyword for node templates -- something that is attached to the node template but does not have to be declared at the type. (Also, like artifacts, they could also be assigned at the node type, in which case they act as defaults to be added to all node templates of that type.)Â I think this is simpler and more understandable than what we have now, which is multiple ways to group nodes together and requiring filters for policy triggers. This way we attach policies to where they need to be.
So what are groups for? They are purely organizational and time-saving, a way to avoid replication. The idea is that groups will have some of the same keywords as node templates, with the understanding that they will apply to all the node templates in the group.
With this new understanding, we can remove the group type. Groups in turn will have no "type", "properties", nor "attributes" keywords. All they have is: "metadata", "description", "node_templates" (instead of "members") with no restrictions on what nodes can be added. And, relevant to this discussion, there is a "policies" keyword to be applied to all nodes in the group. If a node also has its own policies, those will be applied before those of the group (they are higher priority). We can also add an "artifacts" keyword as a way to attach the same artifact to all nodes. (And there can also be a "directives" keyword, again applied to all member node templates. Although I really want to see this keyword disappear!)
Groups should not have attributes, for the same reason they don't have interfaces. They are not real-world resources. Still, is it possible to add properties to a group as a logical entity, as in TOSCA 1.3? Well, yes, by attaching a policy to it. So we are not losing that ability, but rather clarifying what is meant by adding properties to groups.
As for how to handle group metadata, it's as always up the implementation. If the implementation wants to apply that metadata to all node templates in the group or store it independently and treat the group as a logical entity, that should not be our business.
Note the renaming of "members" to "node_templates". This is to avoid namespace ambiguities. There would also be a "groups" keyword to allow a group to include other groups. There is no problem with that in this new understanding, as in the end a group is just a bunch of node templates and not a real-world resource.
Here's an example to illustrate how it all works together:
topology_template:
 node_templates:
ÂÂÂ app:
ÂÂÂÂÂ type: MyApplication
ÂÂÂÂÂ policies:
ÂÂÂÂÂ - fail-fast:
 Â Â type: Tolerance
 Â Â properties:
 Â Â downtimeAllowance: 5 s
 Â Â downtimeWarning: 3 s
ÂÂÂ server:
ÂÂÂÂÂ type: VirtualMachine
ÂÂÂ db:
ÂÂÂÂÂ type: AbstractDatabase
ÂÂÂÂÂ policies:
ÂÂÂÂÂ - substitution:
ÂÂÂÂÂÂÂÂÂ type: Substitution
ÂÂÂÂÂÂÂÂÂ properties:
ÂÂÂÂÂÂÂÂÂÂÂ options: [ MariaDB, MySQL ]
ÂÂÂÂÂÂÂÂÂÂÂ cluster: false
 groups:
ÂÂÂ hosts:
ÂÂÂÂÂ metadata:
ÂÂÂÂÂÂÂ my-orchestrator.instantiate: 'true'
ÂÂÂÂÂ node_templates: [ server, db ]
ÂÂÂÂÂ policies:
ÂÂÂÂÂ - high-availability:
 Â Â type: Redundancy
 Â Â properties:
 Â Â redundantNodes: 2
 Â Â loadBalancer: RoundRobin
 Â - geo-redundancy: Â Â type: MultiSite
ÂÂÂ Â Â Â properties:
ÂÂÂÂÂÂÂÂÂÂÂ sites: [ Boston-123, Shanghai-456 ]
The question remains as to what to do with policy triggers. In my view, there is no benefit in having grammar for this, as it is entirely domain specific, moreover it is often dependent on the runtime environment rather than a design consideration. E.g. in the example above "fail-fast" will be applied when the downtime is higher than 5 seconds, while the other policies do not have specific "triggers". Creating a grammar for this will never satisfy all real world requirements, while on the other hand would need to be very complex in order to try to satisfy just some of those requirements. (This is the same criticism I have for workflows, which I would also like to see removed from TOSCA.)
That said, if other folk insist on having policy triggers, they could be added to the policy assignment as the keyword "when". From the example above, using some pseduo-grammar:
ÂÂÂÂÂ - fail-fast:
 Â Â type: Tolerance
ÂÂÂÂÂÂÂÂÂ when:
ÂÂÂÂÂÂÂÂÂ - "downtime" attribute is greater than 5 s
There is pseudo-grammar here because I have no idea how we can create grammar that would properly express all conditions, and I am not sure it is smart to have to model all runtime attributes, which might actually not be known by the designer (orchestration-implementation-spoecific).