[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: “minimal conformance level” for TOSCA template parsing
Thanks a lot for the input ! Better to see that now than later
J > I’ll propose an updated version of the basic template and will create a pull request (likely on Friday). Perfect. Thanks, -jacques From: Chris Lauwers [mailto: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]