RE: Enhancements to the TOSCA data filtering abilities

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 <>

Sent: Sunday, September 23, 2018 6:20 AM

To: Calin Curescu <>; Chris Lauwers <>; NOSHPITZ, CLAUDE <>; ; Arturo Martin De Nicolas <>; ; ; ;
 ; ; Steve Baillargeon <>; ; ; ; ; SHADMI, DAVID <>; ; ;
 ; ; ; ; ; ; ; ; 

Subject: RE: Enhancements to the TOSCA data filtering abilities

 

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:

The list syntax is consistent with what we already have in functions get_input (4.4.1), get_property (4.4.2) and get_attribute (4.5.1)

The list syntax is much more extendable and more suits my future proposals that I have not yet disclosed. A spoiler: a list item could be extended from what we have now (just a sub-property name or index) to a more advanced selection
 _expression_ with terms like ANY, ALL, MATCH(pattern), etc.

 

I was also going to propose changes in the data type definition syntax to allow laconic refinement of deeply buried sub-properties:

data_types:

  VirtualCpuWithStaticPinning:

    derived_from: tosca.datatypes.nfv.VirtualCpu

    properties:

      [virtual_cpu_pinning, cpu_pinning_policy]:

        constraints:

          - equal: static

 

Well, we have a lot to discuss.

 

Looking forward to our future meetings,

 

Anatoly

 

 

From: Calin Curescu <>

Sent: Wednesday, September 19, 2018 9:56 AM

To: Katzman, Anatoly <>; Chris Lauwers <>; NOSHPITZ, CLAUDE <>;
; Arturo Martin De Nicolas <>;
; 
; ;
; 
; Steve Baillargeon <>;
; 
; ;
; SHADMI, DAVID <>;
; 
; ;
; 
; ;
; 
; ;
;


Subject: RE: Enhancements to the TOSCA data filtering abilities

 

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:

âtosca_typeâ,

for both nodes and relationships

to be able to filter out (in a workflow step) this node if it is of a specific type

âtosca_requirement_nameâ

for relationships

to be able to filter out (in a workflow step) this relationship if it has been created to fulfill a requirement with a specific symbolic name (which is almost always the case)

âtosca_requirement_indexâ

for relationships

only pending to the outcome of discussions if a requirement occurrences should be assigned a specific index

 

 

BR,

/Calin

 

 

 

From: Chris Lauwers <>

Date: Monday, 3 September 2018 at 06:26

To: "KATZMAN, ANATOLY" <>, "NOSHPITZ, CLAUDE" <>, "" <>,
 Arturo Martin De Nicolas <>, Calin Curescu <>, ""
 <>, "" <>, "" <>,
 "" <>, "" <>,
 Steve Baillargeon <>, "" <>, ""
 <>, "" <>, ""
 <>, "SHADMI, DAVID" <>, "" <>, ""
 <>, "" <>, ""
 <>, "" <>, "" <>,
 "" <>, "" <>, ""
 <>, "" <>, ""
 <>

Cc: Chris Lauwers <>

Subject: RE: Agenda for this week's TOSCA Simple Profile meeting

 

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 <>

Sent: Sunday, September 02, 2018 10:31 AM

To: NOSHPITZ, CLAUDE <>;
; 
; 
; Chris Lauwers <>;
; 
; ;
; 
; ;
; 
; ;
; SHADMI, DAVID <>;
; 
; ;
; 
; ;
; 
; ;
;


Subject: RE: Agenda for this week's TOSCA Simple Profile meeting

 

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

Sent: Tuesday, August 28, 2018 6:42 PM

To: Katzman, Anatoly <>;
; 
; 
; NOSHPITZ, CLAUDE <>;
; 
; ;
; 
; ;
;
; 
; ;
; SHADMI, DAVID <>;
; 
; ;
; 
; ;
; 
; ;
;


Subject: Agenda for this week's TOSCA Simple Profile meeting

 

TOSCA Simple Profile for YAML

Discussion topics for 2018-08-28:

 

Thinhâs request to backport get-inputs enhancements from 1.3 to 1.2 for IFA/SOL alignment, or freeze the 1.3 definition for early adoption by ETSI workstreams

Finalize derived-type property semantics (from last week): this should be ok as discussed, letâs check.

Requirements and capabilities types: aligning ETSI-IFA requirements/assumptions with Simple Profile

 

If time allows, otherwise for future meetings:

Policy: events, triggers, and actions

OS Container use case/structure (would this lead to an âevolvingâ normative type for 1.3?)

 

Thanks.

 

--Claude