OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] RE: Enhancements to the TOSCA data filtering abilities


p.s. I wonder if we can devise a way of evaluating complex property valuesâ

 

 

From: Chris Lauwers <lauwers@ubicity.com>
Date: Friday, December 14, 2018 at 2:46 PM
To: "Vul, Alex" <alex.vul@intel.com>, "Katzman, Anatoly" <anatoly.katzman@intl.att.com>, Matej Artac <matej.artac@xlab.si>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] RE: Enhancements to the TOSCA data filtering abilities

 

Yes, apologies. I was just trying to highlight the proposed syntax changes.

 

By the way, these examples come straight out of the SOL001 spec. Will ONAP not use those data types? Could you point me to the ONAP wiki page that has your alternative proposal? Iâll try to construct an example based on that.

 

Thanks,

 

Chris

 

From: Vul, Alex <alex.vul@intel.com>
Sent: Friday, December 14, 2018 2:44 PM
To: Chris Lauwers <lauwers@ubicity.com>; Katzman, Anatoly <anatoly.katzman@intl.att.com>; Matej Artac <matej.artac@xlab.si>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] RE: Enhancements to the TOSCA data filtering abilities

 

Chris, Matej,

 

As I mentioned in the TOSCA TC meeting, please donât use cpu pinning as an example. Intel is looking to use a different approach for EPA attributes that is similar to what we have been doing in ETSI, i.e. using opaque strings and secondary orchestration functions to process EPA parameter.  Perhaps we need to have a more in-depth conversation about thisâ

 

Kind regards,

 

Alex

 

 

From: <tosca@lists.oasis-open.org> on behalf of Chris Lauwers <lauwers@ubicity.com>
Date: Friday, December 14, 2018 at 2:25 PM
To: "Katzman, Anatoly" <anatoly.katzman@intl.att.com>, Matej Artac <matej.artac@xlab.si>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, Chris Lauwers <lauwers@ubicity.com>
Subject: RE: [tosca] RE: Enhancements to the TOSCA data filtering abilities

 

Hi Matej,

 

I believe you may be mis-interpreting Anatolyâs proposal. Heâs not proposing to apply the same constraint to multiple properties at the same time by grouping those properties in a list. Instead, heâs proposing a ânavigationâ syntax to allow you to âdrill-downâ into specific sub-properties of complex data type. In Anatolyâs example:

 

  • virtual_cpu_pinning is a property of the VirtualCPU data type
  • virtual_cpu_pinning has a complex data type VirtualCpuPinning. One of its properties is called âcpu_pinning_policyâ
  • The VirtualCpuWithStaticPinning data type derives from the VirtualCPU data type. The only difference between   VirtualCpuWithStaticPinning and VirtualCPU is that the   VirtualCpuWithStaticPinning type wants to set the cpu_pinning_policy to âstaticâ. With current TOSCA syntax, there is no mechanism to do this.

 

(actually, there is a mechanism, but itâs somewhat convoluted:

 

  • First, create a new data type called VirtualCpuStaticPinning data type that derives from VirtualCpuPinning and that constraints the cpu_pinning_policy attribute to equal âstaticâ at all times.
  • Then create the new VirtualCpuWithStaticPinning data type that derives from VirtualCPU and that constraints the virual_cpu_pinning property to have the (derived) type VirtualCpuStaticPinning.

 

This approach requires changes in two places and would be less readable. It gets even more convoluted if you go more than one level down in complex data types).

 

As Anatoly correctly points out, we already have (loosely) define navigation syntax in TOSCA. It would be well worth formalizing this better (Xpath for TOSCA? ToscaPath?)

 

Chris

 

 

From: Katzman, Anatoly <anatoly.katzman@intl.att.com>
Sent: Thursday, December 13, 2018 8:56 AM
To: Matej ArtaÄ <matej.artac@xlab.si>; Chris Lauwers <lauwers@ubicity.com>; 'Calin Curescu' <calin.curescu@ericsson.com>; NOSHPITZ, CLAUDE <cn5542@att.com>; alex.vul@intel.com; 'Arturo Martin De Nicolas' <arturo.martin-de-nicolas@ericsson.com>; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; 'Steve Baillargeon' <steve.baillargeon@ericsson.com>; thinh.nguyenphu@nokia.com; dmytro.gassanov@netcracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] RE: Enhancements to the TOSCA data filtering abilities

 

Hi Matej,

 

This list-alike thing is not just a shorthand notation that comes to replace an already existing but unfortunately verbose construct. It introduces a totally new functionality. It says âgiven a value of a complex type, please use this path to navigate to a selected part of the value, and apply the validation to that part onlyâ. Today there is no way to do this. In my example, properties âvirtual_cpu_pinningâ and âcpu_pinning_policyâ are not at same level.  âcpu_pinning_policyâ is a sub-property of âvirtual_cpu_pinningâ.

 

Whatever headache the orchestrators may have with it, this is an already familiar headache. Functions get_property, get_attribute, etc use a similar construct to specify their arguments.

 

On a separate note, I would advise against using YAML anchors and aliases in TOSCA templates. These are low-level creatures that can replace almost everything with anything, they can get resolved on a pre-parsing phase, and potentially, this resolution may result in a document that is valid YAML yet invalid TOSCA. The TOSCA dsl_definition mechanism is a bit safer, but it is for creating TOSCA extensions, while we want this navigation ability to become part of the TOSCA core.

 

BR,

 

Anatoly

 

From: Matej ArtaÄ <matej.artac@xlab.si>
Sent: Wednesday, December 12, 2018 9:45 AM
To: 'Chris Lauwers' <lauwers@ubicity.com>; Katzman, Anatoly <anatoly.katzman@intl.att.com>; 'Calin Curescu' <calin.curescu@ericsson.com>; NOSHPITZ, CLAUDE <cn5542@att.com>; alex.vul@intel.com; 'Arturo Martin De Nicolas' <arturo.martin-de-nicolas@ericsson.com>; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; 'Steve Baillargeon' <steve.baillargeon@ericsson.com>; thinh.nguyenphu@nokia.com; dmytro.gassanov@netcracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
Cc: tosca@lists.oasis-open.org
Subject: RE: [tosca] RE: Enhancements to the TOSCA data filtering abilities

 

Hello all,

 

If I may, Iâd just like to voice my opinion about the proposal of using a list in the YAML key to shorten the definitions in this example:

 

data_types:

  VirtualCpuWithStaticPinning:

    derived_from: tosca.datatypes.nfv.VirtualCpu

    properties:

      [virtual_cpu_pinning, cpu_pinning_policy]:

        constraints:

          - equal: static

 

While this approach seems to simplify matters from the userâs perspective, it will create major headaches to the orchestrator implementors. Also, YAML also has support for anchors that does away with the issue of repetition, so the following will work in any existing orchestrator, according to existing standard, and will do the trick:

 

data_types:

  VirtualCpuWithStaticPinning:

    derived_from: tosca.datatypes.nfv.VirtualCpu

    properties:

      virtual_cpu_pinning: &static_constraints

        constraints:

          - equal: static

       cpu_pinning_policy: *static_constraints

 

Additionally, for this specific case, TOSCA also provides a dsl_definitions mechanism:

 

dsl_definitions:

  - &static_constraints

    constraints:

      - equal: static

 

data_types:

  VirtualCpuWithStaticPinning:

    derived_from: tosca.datatypes.nfv.VirtualCpu

    properties:

      virtual_cpu_pinning: *static_constraints

      cpu_pinning_policy: *static_constraints

 

Best regards,

Matej

 

 

Matej ArtaÄ, PhD / Project Manager / +386 1 244 77 53
XLAB d.o.o. / Pot za Brdom 100 / SI - 1000 Ljubljana / Slovenia
tel.+386 1 244 77 50 / info@xlab.si / www.xlab.si

Project Manager, Platform and System Orchestration
Member, OASIS TOSCA Standard Technical Committee

Google Drive / Linkedin / Twitter

 

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Chris Lauwers
Sent: Wednesday, December 12, 2018 3:26 AM
To: Katzman, Anatoly <ak435s@intl.att.com>; Calin Curescu <calin.curescu@ericsson.com>; NOSHPITZ, CLAUDE <cn5542@att.com>; alex.vul@intel.com; Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; Steve Baillargeon <steve.baillargeon@ericsson.com>; thinh.nguyenphu@nokia.com; dmytro.gassanov@netcracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
Cc: tosca@lists.oasis-open.org
Subject: [tosca] 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 <ak435s@intl.att.com>
Sent: Sunday, September 23, 2018 6:20 AM
To: Calin Curescu <calin.curescu@ericsson.com>; Chris Lauwers <lauwers@ubicity.com>; NOSHPITZ, CLAUDE <cn5542@att.com>; alex.vul@intel.com; Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; Steve Baillargeon <steve.baillargeon@ericsson.com>; thinh.nguyenphu@nokia.com; dmytro.gassanov@NetCracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
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:

  1. 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)
  2. 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 <calin.curescu@ericsson.com>
Sent: Wednesday, September 19, 2018 9:56 AM
To: Katzman, Anatoly <ak435s@intl.att.com>; Chris Lauwers <lauwers@ubicity.com>; NOSHPITZ, CLAUDE <cn5542@att.com>; alex.vul@intel.com; Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; Steve Baillargeon <steve.baillargeon@ericsson.com>; thinh.nguyenphu@nokia.com; dmytro.gassanov@NetCracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
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 <lauwers@ubicity.com>
Date: Monday, 3 September 2018 at 06:26
To: "KATZMAN, ANATOLY" <ak435s@intl.att.com>, "NOSHPITZ, CLAUDE" <cn5542@att.com>, "alex.vul@intel.com" <alex.vul@intel.com>, Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>, Calin Curescu <calin.curescu@ericsson.com>, "lishitao@huawei.com" <lishitao@huawei.com>, "ljlamers@vmware.com" <ljlamers@vmware.com>, "mrutkows@us.ibm.com" <mrutkows@us.ibm.com>, "Paul.Lipton@ca.com" <Paul.Lipton@ca.com>, "priya.g@netcracker.com" <priya.g@netcracker.com>, Steve Baillargeon <steve.baillargeon@ericsson.com>, "thinh.nguyenphu@nokia.com" <thinh.nguyenphu@nokia.com>, "dmytro.gassanov@NetCracker.com" <dmytro.gassanov@netcracker.com>, "don.deel@netapp.com" <don.deel@netapp.com>, "dpalma@vnomic.com" <dpalma@vnomic.com>, "SHADMI, DAVID" <ds200p@att.com>, "hsurti@cisco.com" <hsurti@cisco.com>, "ifat.afek@alcatel-lucent.com" <ifat.afek@alcatel-lucent.com>, "JDurand@us.fujitsu.com" <JDurand@us.fujitsu.com>, "jeremy@gigaspaces.com" <jeremy@gigaspaces.com>, "jim.hunter@ca.com" <jim.hunter@ca.com>, "jpackett@us.ibm.com" <jpackett@us.ibm.com>, "kraman@redhat.com" <kraman@redhat.com>, "luca.gioppo@csi.it" <luca.gioppo@csi.it>, "rpenta@redhat.com" <rpenta@redhat.com>, "xavier.degenne@fastconnect.fr" <xavier.degenne@fastconnect.fr>, "zhao.huabing@zte.com.cn" <zhao.huabing@zte.com.cn>
Cc: Chris Lauwers <lauwers@ubicity.com>
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 <ak435s@intl.att.com>
Sent: Sunday, September 02, 2018 10:31 AM
To: NOSHPITZ, CLAUDE <cn5542@att.com>; alex.vul@intel.com; arturo.martin-de-nicolas@ericsson.com; calin.curescu@ericsson.com; Chris Lauwers <lauwers@ubicity.com>; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; steve.baillargeon@ericsson.com; thinh.nguyenphu@nokia.com; dmytro.gassanov@NetCracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
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 <ak435s@intl.att.com>; alex.vul@intel.com; arturo.martin-de-nicolas@ericsson.com; calin.curescu@ericsson.com; NOSHPITZ, CLAUDE <cn5542@att.com>; lauwers@ubicity.com; lishitao@huawei.com; ljlamers@vmware.com; mrutkows@us.ibm.com; Paul.Lipton@ca.com; priya.g@netcracker.com; steve.baillargeon@ericsson.com; thinh.nguyenphu@nokia.com; dmytro.gassanov@NetCracker.com; don.deel@netapp.com; dpalma@vnomic.com; SHADMI, DAVID <ds200p@att.com>; hsurti@cisco.com; ifat.afek@alcatel-lucent.com; JDurand@us.fujitsu.com; jeremy@gigaspaces.com; jim.hunter@ca.com; jpackett@us.ibm.com; kraman@redhat.com; luca.gioppo@csi.it; rpenta@redhat.com; xavier.degenne@fastconnect.fr; zhao.huabing@zte.com.cn
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]