Never mind, I already got an answer from the spec =)
On Wed, Nov 22, 2017 at 6:29 PM, Tal Liron wrote:
> Less cumbersome, sure. But it also breaks the object-oriented contract.
>
> Imagine this situation: a third party develops a powerful node type (let's
> say: a virtual
Less cumbersome, sure. But it also breaks the object-oriented contract.
Imagine this situation: a third party develops a powerful node type (let's
say: a virtual router) with many well-defined and polished operations on
custom interfaces (with their own types), custom workflows for various
I think keeping the ability to accept ad-hoc inputs (at least for now) is a
good idea =). This will (among other thing) make the job of writing custom
service template less cumbersome. Just mentioning again that this is the
place I see a possible justification for ad-hoc 'additions', as we don't
Thanks for keeping the discussion going, Avia.
Yeah, I do not think that my interpretation is rock solid at all and it's
definitely forced. It's not hard to find examples in the spec that
contradict my interpretation, but also there are others that contradict the
opposite. I think we can all
I know this is an old thread, but since this is an important issue (and
I'm doing a review of old and interesting mails), I thought I'll take a
shot at a reply.
I'm not relying on one example in the spec. actually, we can see that
inputs are defined under the normative "Standard" and
The single sentence you mention in the 3.5.13.3 is the only place that
*might* be implying that ad hoc, type-less input assignments are allowed,
but I actually think it could have a different reading. What i meant is:
"...that do not necessarily have a property definition defined in its
In contrary to most of the TOSCA entities, TOSCA does not differentiate
between 'definition' and 'assignment' in the context of operations. There
are only "operation definitions" [3.5.13]. Logically, there is a partial
differentiation [3.5.13.1], where inputs in node type operations are
expected
Feel free to change the wiki, Ran, to whatever name you find appropriate.
I think what Avia discovered is not new to us and actually doesn't solve
the problem, unfortunately. Let me go over what is clearly allowed and not
allowed in TOSCA, confusing because there are a few levels of inheritance
Avia's mentioned at one point that we might have misunderstood the spec at
this section, and that in fact it can be possible to pass arbitrary inputs
into operations regardless of the interface definition - which would mean
this notion of "configuration" might be unnecessary.
Also, note that the
Yes:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Configuration
On Fri, Sep 8, 2017 at 4:45 PM, DeWayne Filppi wrote:
> I see in the examples a list of dependencies for scripts in operations, for
> example:
>
> implementation:
>
10 matches
Mail list logo