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:

ÂÂÂÂÂ m:

ÂÂÂÂÂÂÂ type: map

ÂÂÂÂÂÂÂ entry_schema: string

topology_template:

ÂÂÂ node_templates:

ÂÂÂÂÂ my_node:

ÂÂÂÂÂÂÂ type: MyNode

ÂÂÂÂÂÂÂ properties:

ÂÂÂÂÂÂÂÂÂ m:

ÂÂÂÂÂÂÂÂÂÂÂ 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