ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tal Liron <...@cloudify.co>
Subject Re: operation dependencies
Date Mon, 11 Sep 2017 17:01:55 GMT
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
corresponding *interface* type." I think what is implied is what I mention
in level #2: a node template could have assignments that are not in the
interface type, *but obviously they have to be defined in the node type*.
Obvious, I say, because they have to be defined somewhere: an undefined
property assignment makes little sense in TOSCA. So let me rewrite that
sentence with more clarity, without (I think) changing its original meaning:

"Template authors MAY provide property assignments on operation inputs on
templates that do not necessarily have a property definition defined in its
corresponding interface type by adding an input definition to the node
type."

To be more honest here: when I say "I think what is implied" I have to
wonder if the author was completely clear on what was implied. Like many
parts of spec, there's a lot of theory that clashes in practice. We are
confused, but it could be that the author was confused as well. By
implementing the spec we have a responsibility to pin down what's fuzzy.

The "partial" differentiation as you call it in 3.5.13.1 is what I meant:
in some places you use property definitions, in other assignments. The
language is very clear that you use definitions with types and assignments
with templates. They didn't explicitly have an "operation assignment"
grammar, but it's clear that there are two different grammars. When I say
"operation assignment", it's a shorthand for the kind of operation
definition that you find in templates which uses property assignments. This
is consistent with everything else in TOSCA.

And indeed this is exactly what we see example 2.14.2, too, where we see
property assignments. But this example snippet doesn't prove much of
anything, because we don't see the node type defined, just used here.
The "wp_db_port"
input could/should be declared there. The fact that ARIA accepts this has
always been very problematic to me: we here have an input that is untyped.
I consider this a bug. As we discussed, this particular example *might*
make a bit of sense because we are using an intrinsic function, which could
carry the type with it... but nowhere in the spec is any mechanism like
that explained. Many of the examples in the TOSCA spec are wrong or
incomplete, too, so I wouldn't be shocked if this one is wrong as well.

Anyway, none of this addresses the core issue in my opinion, which I keep
returning to: these kinds of parameters we add here -- SSH user, password,
etc. -- are meant as *directives to our execution plugin*, conceptually
very different from operation inputs. Mixing them together is confusing
(what do you do with name overlaps?) as well as a major security concern.
These two kinds of values simply should not be mixed together. Indeed, in
TOSCA 1.2 they might end up being artifact properties.


On Mon, Sep 11, 2017 at 11:25 AM, Avia Efrat <avia@cloudify.co> wrote:

> 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 to be property definitions, and inputs in node template operation
> are expected to be property assignments (which are actual value
> assignments). Both of these options are listed under "operation
> definition".
>
> Under [3.5.13.3] it is explicitly stated that
> "Template authors MAY provide property *assignments* on operation inputs on
> *templates* that do not necessarily have a property definition defined in
> its corresponding type." (my emphasis)
>
> That is, from this paragraph, I think that it is clear that you can define
> operation inputs in node templates (level #3) without them being defined in
> the node template's type. In fact, [2.14.2] is an example of doing just
> that. And out parser treats such a syntax as valid, see:
> https://github.com/apache/incubator-ariatosca/blob/
> master/tests/parser/test_tosca_simple_v1_0/test_end2end.py#L73
>
> Me thinking it was a good idea to construct TOSCA that way is another thing
> =)
>
> On Mon, Sep 11, 2017 at 6:35 PM, Tal Liron <tal@cloudify.co> wrote:
>
> > 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
> > here.
> >
> > 1. Interface types. Obviously, you are allowed to inherit an interface
> type
> > and add or override inputs. (ARIA insists that overridden input types be
> > derived from what it is they are overriding, too, to keep the OO contract
> > intact.)
> >
> > 2. Node types. In the "interfaces" section you can define several
> > interfaces of various types. Here, again, TOSCA lets you add/override
> > inputs. Though note here that the line of inheritance is quite complex:
> you
> > can override inputs from the interface type, but *also* from the parent
> > node type. (ARIA here has to do some work to make sure that you are doing
> > it all OK and not breaking the OO contract, it's a rather complex part of
> > the parser code.)
> >
> > I think the above is what Avia discovered. However, the third level is
> > locked to us:
> >
> > 3. Node templates. Unfortunately, here we can not add inputs ad hoc. The
> > "interfaces" section here is not the same DSL format as those above: it
> is
> > operation *assignments* rather than operation *definitions*. When you
> > assign input values here, they are validated against the defined types.
> It
> > would make no sense in TOSCA to just assign values without a type.
> >
> > So, because we can't add inputs at level #3, we still have a problem: we
> > would have to derive new node types for every type of execution. SSH
> would
> > require its own node types, Juju would require its own node types, Puppet
> > would require its own node types, etc. And that's for *all* your node
> > types. This seems extremely un-scalable.
> >
> > But also, as I try to explain in the wiki page, I insist that these kinds
> > of configuration parameters are essentially not the same as operation
> > inputs. They are not meant to be used by the operation itself (script,
> > charm, recipe, etc.), rather by the mechanism that executes the operation
> > (SSH, Juju, Puppet, etc.). Especially I point out the security hole: you
> > don't want an SSH password exposed and sent over the wire to the script
> > itself. It is simply not an input.
> >
> > By the way, it seems that there's some acknowledgement by other folk in
> > OASIS about this gap in TOSCA, and there's an interest to use artifact
> > types in TOSCA 1.2 as a way to solve this problem. I don't think it's a
> bit
> > awkward, but at least there will be a standard solution.
> >
> >
> > On Sun, Sep 10, 2017 at 2:13 AM, Ran Ziv <ran@cloudify.co> wrote:
> >
> > > 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 doc page is talking about "executors", which is
> > > confusing as that's a different concept in ARIA (see the base executor
> > > class); Supposedly up until now we've simply called these "operation
> > > plugins".
> > >
> > >
> > > On Sat, Sep 9, 2017 at 1:43 AM, Tal Liron <tal@cloudify.co> wrote:
> > >
> > > > Yes:
> > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > > Execution+Configuration
> > > >
> > > > On Fri, Sep 8, 2017 at 4:45 PM, DeWayne Filppi <dewayne@cloudify.co>
> > > > wrote:
> > > >
> > > > > I see in the examples a list of dependencies for scripts in
> > operations,
> > > > for
> > > > > example:
> > > > >
> > > > >             implementation:
> > > > >               primary: scripts/configure.sh
> > > > >               dependencies:
> > > > >                 - "ssh.user > { get_input: ssh_username }"
> > > > >                 - "ssh.key_filename > { get_input: private_key_path
> > }"
> > > > >                 - "ssh.address > { get_attribute: [ virtual_ip,
> > > > > floating_ip_address ] }"
> > > > >
> > > > > The spec seems to indicate that the dependency list is for
> resources
> > > that
> > > > > need to be made available so the main script can be run.  Clearly
> > that
> > > > > isn't the case in the example.  Is this '>' syntax documented
> > anywhere?
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message