RE: [tosca] Datatype definition with an empty base type?

Hi Arturo, Chris, Shitao and Thinh,

on Arturo’s concern (“how can we preclude that in a VNFD service template, any property is replaced by a property of a derived, richer type”), we could propose a “final” keyword---or something equivalent---in the TOSCA grammar for this purpose, e.g.:

tosca.datatypes.nfv.VnfOperationAdditionalParameters:

derived_from: tosca.datatypes.Root

final: false

i.e. for all types with final=true, derivation would be forbidden. Until such a tool gets available in TOSCA, i.e. for the short term in SOL001, we could explicitly define---in normative text---the types that are meant for extension and the ones that are not.

For preventing template authors from messing up derived types completely, it would be worth setting the rules of type extension in the TOSCA specs. E.g.:

A derived type must extend the base type in such a way that it remains substitutable for the base type. More specifically:

New elements (properties, capabilities, requirements, interfaces, operations, inputs, etc) may be introduced with no restriction.
Existing elements may be overridden in an “extend-only” fashion only (recursive rule). E.g.:

i. A string property may not be overridden with an integer property or with a complex property of the same name.

ii. A complex property based on a data type may be overridden with a property of type derived from that data type.

The same applies to capabilities, requirements, interfaces, operations, inputs, etc.

I believe that for introducing VNF-specific constructs on the type level in the VNFD (i.e. modifiable attributes, configurable properties, additional parameters to operations), the best approach is to derive from existing types, because not deriving would make the VNFD even less validatable. I.e. we need to introduce the new constructs at well-defined “extension points”, and the only tool for this to my knowledge is type extension.

Greetings,

Gábor

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Lishitao
Sent: Wednesday, June 27, 2018 3:17 AM
To: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; Chris Lauwers <lauwers@ubicity.com>; Nguyenphu, Thinh (Nokia - US/Irving) <thinh.nguyenphu@nokia.com>
Cc: tosca@lists.oasis-open.org
Subject: [tosca] 答复: [tosca] Datatype definition with an empty base type?

Yes, from TOSCA grammar perspective this should be fine, but as we discussed during SOL#66 Piscataway meeting , it is better to avoid this usage. It will introduce many unexpected influences for standard.

发件人: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] 代表 Arturo Martin De Nicolas
发送时间: 2018年6月27日 0:00
收件人: Chris Lauwers <lauwers@ubicity.com>; Nguyenphu, Thinh (Nokia - US/Irving) <thinh.nguyenphu@nokia.com>
抄送: tosca@lists.oasis-open.org
主题: RE: [tosca] Datatype definition with an empty base type?

Hi Thinh,

No one doubted that it is possible to define an empty base data type and derive other data types from it.

The point is that in the interface type definition in SOL001 we will have properties of this empty data type. But any interface defined in any SOL001 compliant VNFD service template will have those properties not from the base empty type but from the derived type. Is there a way to express that in the schema? Otherwise how can we preclude that in a VNFD service template, any property is replaced by a property of a derived, richer type?

BR,

Arturo

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Chris Lauwers
Sent: Tuesday, June 26, 2018 5:47 PM
To: Nguyenphu, Thinh (Nokia - US/Irving) <thinh.nguyenphu@nokia.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Datatype definition with an empty base type?

Yes, I don’t see any issues with this.

Chris

Sent from my iPhone

On Jun 26, 2018, at 4:40 PM, Nguyenphu, Thinh (Nokia - US/Irving) <thinh.nguyenphu@nokia.com> wrote:

Hello Chris and Claude,

Would it be possible to have a datatype with an empty based type for deriving data type for describing vendor specific parameters. Would it possible to discuss this issue during today YAML call. Sorry for late notice.

Data type definition:

tosca.datatypes.nfv.VnfOperationAdditionalParameters:

derived_from: tosca.datatypes.Root

Example:

...

node_types:

mycompany.nodes.nfv.SunshineDB.1_0.1_0:

    derived_from: tosca.nodes.nfv.VNF

    properties:

      ...

    interfaces:

      Vnflcm:

        type: mycompany.interfaces.nfv.Vnflcm

data_types:

...

mycompany.datatypes.nfv.InstantiateAdditionalParameters:

    derived_from: tosca.datatypes.nfv.VnfOperationAdditionalParameters

    properties:

      parameter_1:

        type: string

        required: true

      parameter_2:

        type: string

        required: false

        default: value_2

interface_types:

mycompany.interfaces.nfv.Vnflcm:

    derived_from: tosca.interfaces.nfv.Vnflcm

    instantiate:

      inputs:

        additional_parameters:

          type: mycompany.datatypes.nfv.InstantiateAdditionalParameters

          required: true

    terminate:

    heal:

topology_template:

..

Thinh Nguyenphu

Nokia Networks

thinh.nguyenphu@nokia.com

+1 817-313-5189

tosca message