Interop SC
02/03/2016
Agenda
• Jacques feedbacks
• Contribution process improvements proposal
2
Jacques feedbacks
• Suggestion to focus on 2 types of implementations
• Service template
• Orchestrator
3
Jacques feedbacks
• Service template assertions
• 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?
• Orchestrator
• 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.
4
Contribution process improvements proposal
• Current issues
• We need more people to help and contribute
• We should try to help TOSCA implementers (developers) to be efficient for
validating theirs implementations and leverage our work
• We need to be compliant with OASIS and keep the standard track and
requirements
• Validation through Interop SC
• Certification document with test assertions
5
Contribution process improvements proposal
1. Fork the tosca-compliance-tests repository
GITHub Repository
Not officially recognized
as standard
Contributor Forked
Repository
Pull-Request
Test Assertion and
archives/features
2. Submit a Single Test Assertion through a pull-request
4. Accept the pull-request
3. Validate the pull-requests in the Interop SC meeting
- Validation of the test assertion
- Validation of the scenario and archive
Interop SC
Conformance
Document
4. Add test assertions to the conformance document
6
Github repository
• README.MD will explicitly state that all content in the repository is
not officially recognized by the TC
• LICENSE should follow the guidelines of OASIS for repository (to be
checked but I think this is Apache 2 ?)
• Repository doesn’t have to be hosted by OASIS from day one if we are
not ready
• Will be like an OpenSource project around TOSCA
7
Contribution process improvements proposal
• Pull-Request content:
• A test-assertion as a comment of the pull-request. The test-assertion will be
included in the conformance document
TA id: 1-tosca_definitions_version-1
Normative Source: 3.1.2 TOSCA Namespacing in TOSCA Service Templates
Target: Parser-Validator
Predicate: TOSCA Service Templates MUST always have, as the first line of YAML, the keyword “tosca_definitions_version” with an associated TOSCA
Namespace Alias value
Prescription Level: mandatory
Tags:
gherkin: http://github.com/tosca-conformance-tests/1-tosca_definitions_version/parse-tosca-definition.feature
8
Contribution process improvements proposal
• Pull-Request content:
• A Gherkin feature file
Feature: Tosca definition version MUST be specified and valid
Scenario: Parsing a document with valid tosca definition version MUST succeed
When I parse the tosca service template "archives/valid-tosca-version.yml”
Then the parsing MUST be successful
Scenario: Parsing a document with and invalid tosca definition version MUST fail
When I parse the tosca service template "archives/invalid-tosca-version.yml”
Then the parsing MUST fail and SHOULD display an error message matching the cause(s):
| severity | cause | | ERROR | tosca_definitions_version is not supported by the parser |
Scenario: Parsing a document without tosca definition version MUST fail
When I parse the tosca service template "archives/missing-tosca-version.yml”
Then the parsing MUST fail and SHOULD display an error message matching the cause(s):
| severity | cause | | ERROR | tosca_definitions_version is required |
Scenario: Parsing a document where tosca definition is not the first line version MUST fail
When I parse the tosca service template "archives/first-line-not-tosca-version.yml”
Then the parsing MUST fail and SHOULD display an error message matching the cause(s):
| severity | cause | | ERROR | tosca_definitions_version is required and MUST be first line of the TOSCA document. |
9
Contribution process improvements proposal
• Why Gherkin
• Functional language
• Popular amongst developers
• Implementation in many languages
•
•
•
•
Python
Java
Ruby
Etc.
10
Contribution process improvements proposal
• Pull-Request content:
• The tosca service templates and archive files relative to the feature
11