tliron / puccini

Cloud topology management and deployment tools based on TOSCA
https://puccini.cloud
Apache License 2.0
88 stars 20 forks source link

issues on trigger definition condition #66

Closed philippemerle closed 3 years ago

philippemerle commented 3 years ago

The following template:

tosca_definitions_version: tosca_simple_yaml_1_3
topology_template:
  node_templates:
    node:
      type: tosca.nodes.Root # or any node type
  policies:
    - policy:
        type: tosca.policies.Root # or any policy type
        targets: [ node ]
        triggers:
          t1:
            event: event.type1
            condition:
              and:
                - state:
                    - equal: started
            action: []
          t2:
            event: event.type2
            condition:
              or:
                - state:
                    - equal: started
            action: []
          t3:
            event: event.type3
            condition:
              not:
                - state:
                    - equal: started
            action: []
          t4:
            event: event.type4
            condition:
              state:
                - equal: started
            action: []

is not supported by puccini 0.18.0:

$ puccini-tosca compile triggers_condition.yaml 
PROBLEMS (4)
  file:....../triggers_condition.yaml
    @14,15 topology_template.policies{0}.triggers["t1"].condition.and: unsupported field
    @21,15 topology_template.policies{0}.triggers["t2"].condition.or: unsupported field
    @28,15 topology_template.policies{0}.triggers["t3"].condition.not: unsupported field
    @35,15 topology_template.policies{0}.triggers["t4"].condition.state: unsupported field
$

These four condition clause definitions should be supported, shouldn't them?

tliron commented 3 years ago

Condition clauses are a big TODO! I will work on implementing them.

tliron commented 3 years ago

For now I have implemented proper parsing and validation, but normalization remains a TODO.

This is somewhat challenging because the attribute name ... well, there's no way of validating that the target nodes actually have that attribute until runtime.

philippemerle commented 3 years ago

Thank you Tal.

This is somewhat challenging because the attribute name ... well, there's no way of validating that the target nodes actually have that attribute until runtime.

I think you could validate at compile time as 'state' is a declared attribute of the 'tosca.nodes.Root' type and its type is string compatible with the 'started' constant string passed to 'equal'.

tliron commented 3 years ago

But what if you don't use a node that derives from root? And what if you include nodes as your policy targets that derive from various hierarchies? The validation check would have to be done for each node type independently.

But I'm not sure it needs be validated. You could consider any node that doesn't have the attribute to immediately fail the condition. That seems reasonable to me and more flexible because it exactly allows the trigger to be filtered in this way. Remember that we are dealing with attribute assertions here, so it's only at runtime that they can be asserted anyway.

The spec is unclear about this. It's up to us to interpret its spirit.