Re: operation dependencies

2017-11-23 Thread Avia Efrat
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

Re: operation dependencies

2017-11-22 Thread Tal Liron
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

Re: operation dependencies

2017-11-22 Thread Avia Efrat
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

Re: operation dependencies

2017-11-09 Thread Tal Liron
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

Re: operation dependencies

2017-11-04 Thread Avia Efrat
​​​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

Re: operation dependencies

2017-09-11 Thread Tal Liron
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

Re: operation dependencies

2017-09-11 Thread Avia Efrat
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

Re: operation dependencies

2017-09-11 Thread Tal Liron
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

Re: operation dependencies

2017-09-10 Thread Ran Ziv
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

Re: operation dependencies

2017-09-08 Thread Tal Liron
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: >