[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:
I would be OK with either. Thanks, Chris From: BOUTIER, LUC [mailto:luc.boutier@fastconnect.fr]
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> 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 All: Here is the link for the “minimal conformance level” for TOSCA template parsing: 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:
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]