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: “minimal conformance level” for TOSCA template parsing


There is nothing wrong with the spec. It is very clear about the fact that you cannot assign a value to a property/attribute/capability/interface that hasn’t been declared/defined somewhere in a type definition first. There is a very clear distinction in the spec between declaration/definition on the one hand, and assignment on the other hand. Earlier versions of the spec were completely confused about this, and as a result were un-implementable. Matt spent several months correcting this and I would be (extremely) opposed to going back to the earlier confusion. Without a clear distinction between definition and assignment, we lose all ability to validate.

 

I see two simple solutions, neither of which would require us to change any fundamental assumptions in the spec:

 

  1. Turn the interface operation inputs into compliant property definitions (i.e. with a ‘type’ keyword) and then move the input assignments (for example the “VERSION: { get_property: [SELF, component_version] }” statement) into the node template. This would require a change to your template only.
  2. Allow a property declaration to assign a fixed value to the property being defined, very much the same way we allow a default value to be assigned. We could use the ‘value’ keyname for this. There is precedent for this, since we already allow derived classes to assign fixed values to properties defined in base classes. This would require a small change to the spec, and a corresponding small change to the template.

 

I would be OK with either.

 

Thanks,

 

Chris

 

 

From: BOUTIER, LUC [mailto:luc.boutier@fastconnect.fr]
Sent: Thursday, May 11, 2017 2:49 PM
To: Chris Lauwers <lauwers@ubicity.com>; JDurand@us.fujitsu.com; tosca@lists.oasis-open.org
Subject: Re: [tosca] RE: “minimal conformance level” for TOSCA template parsing

 

Hi Chris,

 

I guess the spec is just not valid/usable in current state then. The goal of a node type (in my opinion) is to provide a reusable entity, it allows to define properties and scripts in interfaces. Not being able to reference properties in these scripts is, in my opinion, a very bad thing as it removes all reusability mean in the node type.

 

So, while your comment is true this sounds more to me as a glitch in the spec that we should discuss/ fix.

 

Luc

 

From: <tosca@lists.oasis-open.org> on behalf of Chris Lauwers <lauwers@ubicity.com>
Date: Thursday, 11 May 2017 at 22:44
To: "JDurand@us.fujitsu.com" <JDurand@us.fujitsu.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: [tosca] RE: “minimal conformance level” for TOSCA template parsing

 

Hi Jacques,

 

As we discussed briefly in the TC meeting this morning, I think that the basic_template.yml file as currently written contains invalid TOSCA. I’m attaching a file that contains the output of my parser/validator (https://ubicity.com/validator.html).

 

You can ignore the various “not found” messages in the error file. My validator will flag an error if it is unable to locate artifact files, either in the CSAR file being validator or in a specified repository.

 

The main issue is with the various inputs specified for interfaces in the custom type definitions (e.g. tosca.nodes.samples.basic.SampleSourceNode). Inputs specified in interfaces in type definitions are “input definitions” that must specify the type of the input as well as any constraints. These input definitions then allow the orchestrator to validate whether any input values provided at orchestration time are valid for the types specified in these input definitions.

 

The syntax used in the template instead is an “input assignment” syntax, which is the appropriate syntax for specifying interface inputs in node templates, but not in node types.

 

I’ll propose an updated version of the basic template and will create a pull request (likely on Friday).

 

Thanks,

 

Chris

 

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of JDurand@us.fujitsu.com
Sent: Wednesday, May 10, 2017 7:14 PM
To: tosca@lists.oasis-open.org
Subject: [tosca] “minimal conformance level” for TOSCA template parsing

 

All:

 

Here is the link for the “minimal conformance level” for TOSCA template parsing:

https://github.com/oasis-open/tosca-test-assertions/blob/master/Samples/basic-template/basic-template.yml

 

We appreciate some comments on it.

 

Although this is just for a Parser implementation, it is desirable that the minimal level also matches the minimal conformance level for an Orchestrator implementation (to come later). To keep in mind.

 

The minimal template is also the starting point to test parser error generation.

 

Introduction of errors in the template will be indicated by “error annotations” (YAML comments that will refer to Test Assertions).

 

Errors annotations can be of following types:

 

## errortest-substitution: <test assertion>

## errortest-removal: <test assertion>

## errortest-duplication: <test assertion>

## errortest-insertion: <test assertion>

 

These mean that the following element or line in the template definition, after some interpretation (manual or automatic)  will be affected  to create an error (substituted, or removed, or duplicated, etc.) .

The error annotation also refers to the test assertion that required raising an error.

 

See example below:

 

capability_types:

## errortest-duplication: TA-ERR-definition-duplication

  tosca.capabilities.samples.basic.SampleEndpoint:

    derived_from: tosca.capabilities.Endpoint

    description: A sample endpoint used to connect to compatible sample nodes

 

Means that the template will be altered - after some interpretation – so that it duplicates the “tosca.capabilities.samples.basic.SampleEndpoint:” definition following the annotation. The test assertion that requires to raise an error in such a case is derived from section 3.1.3:

 

Id: TA-ERR-definition-duplication

NormativeSource: Section 3.1.3

Var: defsection in { Repositories, Data Types, Node Types, Relationship Types, Capability Types, Artifact Types, Interface Types }

Prerequisite:

Description: Parsing a document with twice the first definition  under  defsection MUST fail.

Target: a tosca template that defines twice the first definition  under  defsection

Predicate: When parsing the Target, a duplication error is raised.

Prescription level: mandatory

Conformance target: Parser-Validator

 

A complete annotation of the minimal template, for all possible error generations, is in progress.

But the most important for now, is a consensus on that minimal conformance template.

 

Thanks,

Jacques D. and Luc B.

 

 


This e-mail and any attached files are only for the use of its intended recipient(s). Its contents are confidential and may be privileged. Fujitsu does not guarantee that this e-mail has not been intercepted and amended or that it is virus free. If you have received this e-mail and are not the intended recipient, please contact the sender by e-mail and destroy all copies of this e-mail and any attachments. / Le présent courriel, ainsi que ses pièces jointes, ne peut être utilisé que par le ou les destinataires auxquels il a été transmis. Les renseignements qu'il contient sont confidentiels, voire même protégés. Fujitsu ne peut garantir que ce courriel n'a pas été intercepté ou modifié, ou qu'il ne contient aucun virus. Si vous avez reçu ce courriel sans en être le destinataire prévu, veuillez communiquer par courriel avec son expéditeur et en détruire toutes les copies et pièces jointes.


ATOS WARNING !
This message contains attachments that could potentially harm your computer.
Please make sure you open ONLY attachments from senders you know, trust and is in an e-mail that you are expecting.

AVERTISSEMENT ATOS !
Ce message contient des pièces jointes qui peuvent potentiellement endommager votre ordinateur.
Merci de vous assurer que vous ouvrez uniquement les pièces jointes provenant d’emails que vous attendez et dont vous connaissez les expéditeurs et leur faites confiance.

AVISO DE ATOS !
Este mensaje contiene datos adjuntos que pudiera ser que dañaran su ordenador.
Asegúrese de abrir SOLO datos adjuntos enviados desde remitentes de confianza y que procedan de un correo esperado.

ATOS WARNUNG !
Diese E-Mail enthält Anlagen, welche möglicherweise ihren Computer beschädigen könnten.
Bitte beachten Sie, daß Sie NUR Anlagen öffnen, von einem Absender den Sie kennen, vertrauen und vom dem Sie vor allem auch E-Mails mit Anlagen erwarten.



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