RE: [tosca] key_schema in TOSCA 1.3?

Hi Tal,

Yes, it would be nice to have a generic test suite. We had a âtestâ ad-hoc group a couple of years ago. They delivered some very simple scripts (in https://github.com/oasis-open/tosca-test-assertions) but I donât believe these have been kept up-to-date.

I find that the biggest challenge is to create ânegativeâ test cases (i.e. TOSCA files with specific errors that the TOSCA parser/validator is expected to flag). Itâs challenging to automate such tests without standardizing output formats.

Chris

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Tal Liron
Sent: Wednesday, September 18, 2019 10:42 AM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] key_schema in TOSCA 1.3?

In implementing this feature I've come across an interesting case. Even if the map key has to be a string value, it could potentially be a function call. E.g.:

node_types:

MyNode:

properties:

type: map

entry_schema: string

topology_template:

node_templates:

my_node:

type: MyNode

properties:

key1: value1

{ concat: [ key, '2' ] }: value2

This is an effect of us treating map keys as constrainable values and not just strings. I don't see anything particularly wrong with this example, because it is consistent with the rest of TOSCA. However, do take note of this case if you are implementing a TOSCA parser! It means you need to allow for keys to be complex types in the parsing phase, even if they are finally evaluated as strings. This whole feature is quite tricky to implement. For example, you need to store the key constraints somewhere and make sure to apply them to all keys after evaluating them.

Perhaps one day we can have a generic test suite for TOSCA parsers that would include all such edge cases. I attempted to build something like that when working on the ARIA project, but it didn't get that far.

On Wed, Sep 18, 2019 at 4:20 AM Calin Curescu <calin.curescu@ericsson.com> wrote:

Hi,

I think this is a well-known usage of how to do pair definition in a list, so we donât need to have it in the spec.

BR,

/C

From: <tosca@lists.oasis-open.org> on behalf of Tal Liron <tliron@redhat.com>
Date: Tuesday, 17 September 2019 at 19:33
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] key_schema in TOSCA 1.3?

Thanks everybody for the discussion and quick decision!

As an addendum, I'll just point out there is a workaround for cases where you need to send a map with arbitrary keys to an external system. Just use a list of entries:

data_types:

MyEntry:

    Key: MyKeyType

    Value: MyValueType

node_types:

MyNode:

    properties:

      my_fake_map:

        type: list

        entry_schema: MyEntry

The one caveat is that TOSCA would not be able to verify the uniqueness of keys, but at least there is a functional solution.

Is it worth pointing this out in the spec to preempt questions about the key_schema limitation?

On Mon, Sep 16, 2019 at 4:15 PM Chris Lauwers <lauwers@ubicity.com> wrote:

As a compromise, perhaps we can restrict key_schema to only allow scalar types (or types that derive from scalar types).

Chris

From: Tal Liron [mailto:tliron@redhat.com]
Sent: Monday, September 16, 2019 10:09 AM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] key_schema in TOSCA 1.3?

I would like to ask the group to reconsider the new "key_schema" feature.

While it's true that complex keys are supported in YAML, hashtables with complex keys are not widely supported across programming languages, data formats (JSON), databases (relational, graph), memory caches, etc.

In working to implement this feature in Puccini I am hitting many problems that would require adding workarounds with considerable complexity, in particular in its interfaces with the orchestration systems it supports.

My guess is that it was added to provide some grammatical completeness, but I would like to re-discuss its practicality and necessity. Can we add this to the meeting agenda?

tosca message