[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
|
Hi Luc, Yes, I understand your rationale. We should find a way to support in so it doesn’t break typing and/or scoping issues. Let’s talk on Wednesday. Chris From: BOUTIER, LUC [mailto:luc.boutier@fastconnect.fr]
I don’t say that there is syntax issue in the spec but I think that there is a usability issue. What I want as a user (at least some users want) is to be able to write a type once and have it reusable as is in multiple templates. Note that in the spec you can in type define an implementation artifact for an operation
so that really goes into this direction. However, you cannot give parameters to this script even if actually you just want to get the value of a property of the node type. This means that every single person that reuse your node will have to write in it’s own template all the get_property which in my opinion is painful when not required at all. Our current customers find it very nice to be able to have not only pre-packaged templates but also ready to use types that they can leverage in template with a minimal thing to do and write (and share with users that
may have less knowledge). In alien4cloud implementation, People can write types in that way, have a catalog of reusable types and let some other users write their own templates using them easily. To use an analogy not being able to set get_property at the type level sounds to me like saying that you can write a class with fields but you cannot access the fields in the operations, you have to expose them as operations
parameters and then it’s the person that will write the code that use your library that will have to write calls like: Foo foo = new Foo(); foo.bar(foo.getMyFooProp1(), foo.getMyFooProp2()). Note that exposing as input of the interface at type level also allow
the template writer to make mistake when we need the same property to be used for inputs of multiple operations. On the other end in the context of interface type (and not node type) it is indeed not valid to specify inputs assignments as there is (on this element) not any knowledge of a potential node type therefore properties
and so on that may be accessible. I guess that some of the confusion gets from this feature (definition interface types). I don’t say that we have to re-write all the spec, just that we need to find a way to fix/add something to allow the usage of inputs assignment in the context of node types/relationship types while still preventing it
in the context of interface type. Maybe we can use the next interop call to try to figure out how we could resolve this issue. I will schedule one this Wednesday so we can discuss both this specific issue and the test template in a more generic way. Cheers, Luc From: Chris Lauwers <lauwers@ubicity.com> 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]