[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Groups - TOSCA_Conformance_document_draft02.docx uploaded
|
Thanks Luc: (Sorry I wanted to send that long email just to the interop SC, but I just realized I am not a member – yet – so in the process of getting approved…) I suggest we focus on 2 types of implementations: (a)
Service template (b)
Orchestrator Then we’d need to spell out all the test conditions (i.e. test assertions) we want for each category. For (a), that would ideally be expressed with a schema – or a grammar. I see snippets of grammar in the spec, so we’d need to aggregate all of these in a single
grammar. Ideally this grammar *representation* is standard – not specific to TOSCA - or understood by some tooling, e.g. for YAML? For (b), the overall definition of conformance would involve test assertions that verify that the orchestrator is behaving as expected. The conformance clause
for Orchestrator gives an outline of what needs be checked. For example it says: (c)
It [Orchestrator implementation]
can understand and process the functions defined in section 4 “TOSCA functions” according to their rules and semantics. So for example we have predefined functions like: get_property or get_input:
For these we need to define some tests that verify that the orchestrator understands their syntax but also their semantics. A test assertion (TA) could be like (informal): -
“IF the orchestrator is given a template that uses “get_input” in an property definition, referring to a locally defined input variable XYZ, THEN
it returns the value of this variable when returning the value of this property.” A more formal representation of test assertions can be found at
http://docs.oasis-open.org/tag/guidelines/v1.0/cn02/guidelines-v1.0-cn02.pdf . Notice that the test assertion defines a specific context of verification – here, when “get_input” is used in a property definition (there could be several
test assertions for the same feature under different contexts: e.g. here “get_input” could also be verified when used within a capability, or an interface.)
Then the test assertion statement must be easily observable: “returning the value of this property” can be checked with get_property (itself to be the object
of another test assertion(s)). Another set of test assertions would verify reserved function keywords like SELF, SOURCE, TARGET... Another set of test assertions would verify that the “constraint” clause is understood (in_range, valid_values,…). We’d need test assertions that verify that
each one of these types of constraints is understood by the orchestrator, e.g. when providing some inputs for a template. Etc. So we cannot probably address ALL orchestration features under ALL contexts of use, but a reasonable subset need be covered (the most common). Now, when it comes to the actual executable tests that implement these test assertions, there could be various ways to implement each TA, and that would typically
involve an actual, complete sample TOSCA template definition that the orchestrators under test is supposed to understand and be able to process. Ideally such a test template would be reusable across orchestrators so that the test suite itself can be reused
fairly well (can we assume some templates can/should be understood by ANY orchestrator? Or at least by some category of orchestrators) – but that is another question.
In any case, such TOSCA template definition(s) would be part of an actual test suite derived from these test assertions, but not part of the test assertions
themselves which should try to make abstraction of such detailed material. Still, remains the question of the verifiability of our set of TAs. So some immediate questions I see we need to answer before or when writing TAs is:
-
Which of these test assertions (for orchestrators) can we write so that they do not need to assume access to an instance to be verified? (e.g. a function
like get_attribute will need an instance, I guess.) -
When access to an instance is needed, how can we make it “non-orchestrator specific”? Typically, that is where an (standardized) instance model would
help make abstraction of specific ways to access an instance. Would help at least express the TA in a “standard” way, then once instance model is implemented, would help test suites to be portable. Best, -jacques From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Luc Boutier
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]