[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Enhancements to the TOSCA data filtering abilities
Hi, I agree that we should use
condition clauses in the node_filter instead of constraint clauses. This will allow us to put an âorâ or a ânotâ in front of several attributes.
Moreover, by using the âdirect assertion definitionâ when specifying it, the condition clause becomes undistinguishable from a constraint clause. Which means that all the existing specifications
stay valid. We just add the possibility to put an âandâ âorâ or ânotâ before several properties/attributes, from now on.
Also within the constraint clause it is useful to have âorâ and ânotâ to be able to express better constraints. This is simple, just by adding the âandâ, âorâ, and ânotâ to the constraints keyword
tables. Again, this will extend the constraint clause, with all that is already written staying valid. The only thing that we still cannot do within a node_filter is to have an âorâ between normal properties and properties within a capability definition. But this is a small price to pay for backwards
compatibility. The changes in the document should be immediate and straightforward. I could help to write it. BR, /Calin From: Chris Lauwers <lauwers@ubicity.com> By the way, as I think about this more, it seems to me that there is no reason why node filters should use condition clauses (rather than constraint clauses). For example, if I wanted a node filter that says:
âI want a Ubuntu host with 8G of memory or a CentOS host with 4G of memoryâ. I donât think I can express that using just constraint clauses (even when we add Boolean operators to constraints) since we need constraints that combine multiple properties. Using
condition clauses in node filters would solve this problem. Thanks, Chris From: Katzman, Anatoly <ak435s@intl.att.com>
Hi Calin, Thank you for the feedback, really encouraging. Regarding the new self-reflecting attributes â I think it is a good addition and that it deserves a separate proposal and a separate discussion thread
😊 On the sub-property targeting syntax, âmapâ vs âlistâ: The map option crossed my mind when I was working on the proposal, but I have intentionally chosen the list, and this is why:
I was also going to propose changes in the data type definition syntax to allow laconic refinement of deeply buried sub-properties:
Well, we have a lot to discuss. Looking forward to our future meetings, Anatoly From: Calin Curescu <calin.curescu@ericsson.com>
Hi Anatoly, I fully
support your proposed changes. I have a suggestion for the format of proposal #3 syntax. Instead of: Node_templates: function_01: type: MyFunction requirements: - compute: node_filter: capabilities: - tosca.capabilities.nfv.VirtualCompute: properties:
[virtual_cpu, virtual_cpu_pinning, cpu_pinning_policy]:
- equal: static I would propose: Node_templates: function_01: type: MyFunction requirements: - compute: node_filter: capabilities: - tosca.capabilities.nfv.VirtualCompute: properties:
virtual_cpu:
virtual_cpu_pinning: cpu_pinning_policy:
- equal: static That would be the same hierarchy, but when (and only when) descending through datatypes we would have the option to omit the âproperties:â keyname in the hierarchy to make the structure more readable.
NOTE also that the same hierarchy as above could be used in the refinement proposal of Chris, when we want
to refine a property deeply buried in another set of complex properties. I would also propose
to extend the self-reflecting attributes of TOSCA node and relationship template to contain:
BR, /Calin From: Chris Lauwers <lauwers@ubicity.com> We obviously need to discuss the specifics in detail, but in general I fully support these types of enhancements as proposed by Anatoly.
Chris From: Katzman, Anatoly <ak435s@intl.att.com>
Claude, all, In addition to these topics, I would also like to submit for discussion on the WG forum a set of enhancements to the existing TOSCA syntax for conditions and constraints. The attached document
contains the details. The document is probably far from perfect, but I believe that even in its current form it makes a good basis for the further discussion. Of course, it is up to the forum to decide on the priority of this new topic in our backlog. Regards, Anatoly From: NOSHPITZ, CLAUDE
TOSCA Simple Profile for YAML Discussion topics for 2018-08-28:
If time allows, otherwise for future meetings:
Thanks. --Claude |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]