Clearwater IMS Example

[Tal Liron]

Hi everyone,

Happy to say that the Clearwater IMS example is now available on git
master. I know there's been a lot of interest in testing this, and we would
love feedback. Here are instructions:

https://cwiki.apache.org/confluence/display/ARIATOSCA/Clearwater+IMS

Note that work is not complete yet. For now, we only support a single host
("all in one") and you must provision it yourself. To track progress on the
fuller example, see: https://issues.apache.org/jira/browse/ARIA-351

Re: operation dependencies

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

Re: operation dependencies

[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 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  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  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  wrote:
> >
> > > 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:
> > > >   primary: scripts/configure.sh
> > > >   

Re: Support for TOSCA Simple Profile NFV 1.0

[Tal Liron]

I will add that if you absolutely need this change for your own testing,
you do not have to use ARIA's built-in NFV CSD04 Profile. You can copy the
files, change them locally, and use a regular "import" for them. (Just make
sure to set "tosca_definitions_version" to "tosca_simple_yaml_1_0"). If
indeed you are sure that our implementation of CSD04 must be broken
(because the spec itself is broken, no fault of ours), then feel free to
create a PR to fix it!

On Mon, Sep 11, 2017 at 9:43 AM, Avia Efrat  wrote:

> We indeed removed tosca.capabilities.nfv.VirtualStorage requirement from
> the VDU.Compute node since this capability is not defined in csd04, but is
> just mentioned by name.
>
> The VirtualLinkable capability was in csd03, but removed from the TOSCA
> spec in csd04. It seems as a leftover from csd03 that the authors didn't
> properly removed all of its mentions. Regarding the reasoning behind this
> decision, see the last paragraph of the email.
>
> tosca.relationships.nfv.VirtualLinksTo was in csd03, but removed in csd04.
> tosca.relationships.nfv.VDU.AttachedTo wasn't even in csd03.
>
> One might wonder (and indeed you wondered) how to deal with all the missing
> parts and inconsistencies throughout the TOSCA NFV specification. The
> answer, simply put, is that this is a work in progress, still on a draft
> level. A lot of effort is invested currently in TOSCA around the questions
> of creating a NFV profile that combines 'naturally' with the simple TOSCA
> profile. This is quite an intricate task to be honest. You can try to
> contact the authors of the NFV profile for questions and possible
> participation.
>
>
> On Mon, Sep 11, 2017 at 4:35 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > HI Avia,
> >
> >
> >
> > I had to post these questions but it took sometime for me.
> >
> >
> >
> > With the csd04, I could not see the below capabilities in the spec
> >
> >
> >
> > - tosca.capabilities.nfv.VirtualStorage
> >
> > - tosca.capabilities.nfv.VirtualLinkable
> >
> >
> >
> > I think since the capability " tosca.capabilities.nfv.VirtualStorage" is
> > missing, you had removed the requirement for "virtual_storage" for a
> > VDU.Compute node.
> >
> > Capability "tosca.capabilities.nfv.VirtualLinkable" is one of the
> > requirement "virtual_link" for the node type VduCpd. I see this
> requirement
> > is commented in the node type. Is this a common understanding that the
> > VduCpd wont have a requirement on a virtual link ? I believe a VduCpd has
> > requirement on both Compute and Virtual link as mentioned in the spec.
> >
> >
> >
> >
> >
> > Also these 2 relationships are missing too from the spec
> >
> >
> >
> > - tosca.relationships.nfv.VirtualLinksTo ( Relationship
> > of VduCpd with a virtual link )
> >
> > - tosca.relationships.nfv.VDU.AttachedTo ( Relantionship
> > required for virtual storage with compute node)
> >
> >
> >
> >
> >
> > How to address the missing parts from the spec ?
> >
> >
> >
> > Regards,
> >
> > DJ
> >
> >
> >
> > -Original Message-
> > From: Avia Efrat [mailto:a...@gigaspaces.com]
> > Sent: Tuesday, June 13, 2017 2:59 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Support for TOSCA Simple Profile NFV 1.0
> >
> >
> >
> > Hi DJ,
> >
> >
> >
> > Just updating that the pull request was merged.
> >
> >
> >
> > Note that there are some inconsistencies in csd04, so if you have any
> > questions regarding our reasoning in resolving them, feel encouraged to
> ask.
> >
> >
> >
> > On Wed, Jun 7, 2017 at 10:09 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> >
> > > wrote:
> >
> >
> >
> > > Thanks for the update Avia.
> >
> > >
> >
> > > Regards,
> >
> > > DJ
> >
> > >
> >
> > > -Original Message-
> >
> > > From: Avia Efrat [mailto:a...@gigaspaces.com]
> >
> > > Sent: Wednesday, June 07, 2017 3:03 AM
> >
> > > To: dev@ariatosca.incubator.apache.org > ariatosca.incubator.apache.org>
> >
> > > Subject: Re: Support for TOSCA Simple Profile NFV 1.0
> >
> > >
> >
> > > Hi DJ,
> >
> > >
> >
> > > I've created a pull request for the issue that Tal opened:
> >
> > > https://github.com/apache/incubator-ariatosca/pull/147
> >
> > > I expect it to be merged on Thursday/Friday.
> >
> > >
> >
> > > On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron  > @gigaspaces.com>> wrote:
> >
> > >
> >
> > > > Thanks DJ, I opened a new JIRA issue for this if you want to track
> it:
> >
> > > >
> >
> > > > https://issues.apache.org/jira/browse/ARIA-275
> >
> > > >
> >
> > > > It shouldn't be too hard to do, just some busy work in YAML. Anyone
> >
> > > > on the mailing list want to tackle this?
> >
> > > >
> >
> > > > On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran <
> >
> > > > d.jayachand...@ericsson.com>
> >
> > > > wrote:
> >
> > > >
> >
> > > > > Hi,
> >
> > > > >
> >
> > > > > I hope ARIA currently 

Re: Use & impact of role/host attribute in ARIA

[Tal Liron]

I agree with you, DJ.

Until now, I think we wanted to make sure that the defaults would make
sense for most uses, but indeed I agree that

I suggest that we add another configuration parameter, "remote" (boolean)
to enforce this. If "remote" is not specified, we will use the heuristic.
If it is, we will do what the "remote" value says.

So it would look something like this:

topology_template:
  node_templates:
loadbalancer_host:
  type: openstack.Instance
  interfaces:
Standard:
  configure:
implementation:
  primary: scripts/configure.sh
  dependencies:
- remote > false

What do you think? If it makes sense to you, I can create a JIRA for it.
And you could do the PR. :)

On Mon, Sep 11, 2017 at 12:59 AM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi,
>
> The Compute node can still be "host"  but it does not mean it has to
> remote always ? If we can want execution-plugin to handle remote host,
> Some-other parameter should decide if it’s a remote host or not.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Monday, September 11, 2017 11:23 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Use & impact of role/host attribute in ARIA
>
> Hi Tal,
>
> I don’t follow how can we decide all the Compute nodes as "hosted". I can
> still have a local compute node and I want the executor plugin to run my
> scripts locally.
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, September 07, 2017 9:22 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> Really, the only important one is "host" role. For the TOSCA get_property
> and get_attribute functions there is support for a keyword called "HOST",
> which explicitly follows the path of outbound relationships to Container
> capabilities (there might be several) to the final Compute node. So
> Container and Compute play special roles in TOSCA.
>
> A related role is "feature" which exists for the tosca.capabilities.Node
> (note: for the capability type, not the node type!). This is followed for
> *inbound* relationships to find the "HOST". This is that nodes that have
> relationships to the "feature" capability of any other node (it is declared
> in tosca.nodes.Root) would be able to find their host.
>
> There are a few other roles for ARIA-specific extensions: plugins,
> workflows, and scaling policies.
>
> We could have solved this by looking for hardcoded type names, but as I
> said it seemed like a bad idea to me. As the TOSCA spec changes, these
> names might change or their might be other ways to reach hosts. The "role"
> keeps things generic and untied to the spec.
>
>
> On Thu, Sep 7, 2017 at 3:06 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > How do we conclude certain normative types play "special roles" ? I
> > will wait for Ran to explain on the remove execution part.
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Wednesday, September 06, 2017 7:05 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Use & impact of role/host attribute in ARIA
> >
> > First of all, "role" is an extension and is only used internally. It
> > is indeed not defined by TOSCA and you shouldn't be using it yourself.
> >
> > The reason "role" exists is to avoid hardcoding functionality to type
> > names. Certain normative types play special roles in TOSCA: certain
> > relationships are special, as are certain capabilities, data types,
> > etc. In order to avoid having ARIA look for a specific type name, it
> > checks the "role" extension. Internally, "role" is inherited (and can
> > be overridden), so that anything that inherits from
> > tosca.nodes.Compute, for example, would also have the "host" role.
> > (For past versions of the NFV Profile, we likely had the VDU type as
> > having "host" role, even though it did not inherit from
> tosca.nodes.Compute).
> >
> > Then execution plug tries to find out if the operation is hosted
> > remotely by seeing if the node is hosted: either a host itself, or has
> > a relationship to a node that is hosted. I'll leave it to Ran to
> > explain why this needs to be the case. :)
> >
> >
> >
> > On Wed, Sep 6, 2017 at 6:27 AM, Ran Ziv  wrote:
> >
> > > (I'll let Tal take this one :P)
> > >
> > > On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran <
> > > d.jayachand...@ericsson.com>
> > > wrote:
> > >
> > > > Yes, I can see that Ran. So that was my question , why was role
> > > > being added to the types ?
> > > > TOSCA spec does not say about a parameter called role. I feel this
> > > > is not aligned with TOSCA spec.
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > > > -Original Message-
> > > > From: Ran Ziv 

Substitution Mappings Property Mappings in TOSCA v1.2

[Avia Efrat]

I'm not sure I see a use case of the new properties field that is newly
defined under substitution_mappings in v1.2.

The description is:

"A property mapping allows to map the property of a substituted node type
to a property definition or value (mapped as a constant value property
definition) within the topology template.

A property mapping may refer to an input of the topology, to the property
of a node template in the topology or be assigned to a constant value."


So, as it seems, it allows to assign values, within the substitution
template, to properties defined in the substitution type.

In v1.0 and v1.1, the only use of substitution type properties was in the
top-level template, where the properties (that were defined in the
substitution node type) were assigned values. These values were passed as
inputs during the instantiation of the substituting template.


The only usage of these properties was during the substituting template
instantiating. These properties weren't 'real' in the sense of regular node
properties. The substitutable node isn't a real node in the sense that it
is not instantiated in itself, but only the nodes that it represents.


TOSCA v1.2 introduced the notion of property mapping in substitution
mappings, similar to the notions of capability and requirement mappings in
v1.0.


But, why should we use this property mapping ability, if the only thing
substitution_mappings properties are used for is a medium to transfer input
values?

Re: operation dependencies

[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
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  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  wrote:
>
> > 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:
> > >   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?
> > >
> >
>

Re: Support for TOSCA Simple Profile NFV 1.0

[Avia Efrat]

We indeed removed tosca.capabilities.nfv.VirtualStorage requirement from
the VDU.Compute node since this capability is not defined in csd04, but is
just mentioned by name.

The VirtualLinkable capability was in csd03, but removed from the TOSCA
spec in csd04. It seems as a leftover from csd03 that the authors didn't
properly removed all of its mentions. Regarding the reasoning behind this
decision, see the last paragraph of the email.

tosca.relationships.nfv.VirtualLinksTo was in csd03, but removed in csd04.
tosca.relationships.nfv.VDU.AttachedTo wasn't even in csd03.

One might wonder (and indeed you wondered) how to deal with all the missing
parts and inconsistencies throughout the TOSCA NFV specification. The
answer, simply put, is that this is a work in progress, still on a draft
level. A lot of effort is invested currently in TOSCA around the questions
of creating a NFV profile that combines 'naturally' with the simple TOSCA
profile. This is quite an intricate task to be honest. You can try to
contact the authors of the NFV profile for questions and possible
participation.


On Mon, Sep 11, 2017 at 4:35 PM, D Jayachandran  wrote:

> HI Avia,
>
>
>
> I had to post these questions but it took sometime for me.
>
>
>
> With the csd04, I could not see the below capabilities in the spec
>
>
>
> - tosca.capabilities.nfv.VirtualStorage
>
> - tosca.capabilities.nfv.VirtualLinkable
>
>
>
> I think since the capability " tosca.capabilities.nfv.VirtualStorage" is
> missing, you had removed the requirement for "virtual_storage" for a
> VDU.Compute node.
>
> Capability "tosca.capabilities.nfv.VirtualLinkable" is one of the
> requirement "virtual_link" for the node type VduCpd. I see this requirement
> is commented in the node type. Is this a common understanding that the
> VduCpd wont have a requirement on a virtual link ? I believe a VduCpd has
> requirement on both Compute and Virtual link as mentioned in the spec.
>
>
>
>
>
> Also these 2 relationships are missing too from the spec
>
>
>
> - tosca.relationships.nfv.VirtualLinksTo ( Relationship
> of VduCpd with a virtual link )
>
> - tosca.relationships.nfv.VDU.AttachedTo ( Relantionship
> required for virtual storage with compute node)
>
>
>
>
>
> How to address the missing parts from the spec ?
>
>
>
> Regards,
>
> DJ
>
>
>
> -Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Tuesday, June 13, 2017 2:59 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for TOSCA Simple Profile NFV 1.0
>
>
>
> Hi DJ,
>
>
>
> Just updating that the pull request was merged.
>
>
>
> Note that there are some inconsistencies in csd04, so if you have any
> questions regarding our reasoning in resolving them, feel encouraged to ask.
>
>
>
> On Wed, Jun 7, 2017 at 10:09 AM, D Jayachandran <
> d.jayachand...@ericsson.com
>
> > wrote:
>
>
>
> > Thanks for the update Avia.
>
> >
>
> > Regards,
>
> > DJ
>
> >
>
> > -Original Message-
>
> > From: Avia Efrat [mailto:a...@gigaspaces.com]
>
> > Sent: Wednesday, June 07, 2017 3:03 AM
>
> > To: dev@ariatosca.incubator.apache.org ariatosca.incubator.apache.org>
>
> > Subject: Re: Support for TOSCA Simple Profile NFV 1.0
>
> >
>
> > Hi DJ,
>
> >
>
> > I've created a pull request for the issue that Tal opened:
>
> > https://github.com/apache/incubator-ariatosca/pull/147
>
> > I expect it to be merged on Thursday/Friday.
>
> >
>
> > On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron  @gigaspaces.com>> wrote:
>
> >
>
> > > Thanks DJ, I opened a new JIRA issue for this if you want to track it:
>
> > >
>
> > > https://issues.apache.org/jira/browse/ARIA-275
>
> > >
>
> > > It shouldn't be too hard to do, just some busy work in YAML. Anyone
>
> > > on the mailing list want to tackle this?
>
> > >
>
> > > On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran <
>
> > > d.jayachand...@ericsson.com>
>
> > > wrote:
>
> > >
>
> > > > Hi,
>
> > > >
>
> > > > I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft
> 03.
>
> > > > The Latest available TOSCA NFV profile is Simple profile NFV 1.0
>
> > > > draft
>
> > > 04,
>
> > > > released on 11 May 2017.
>
> > > >
>
> > > > Could you kindly confirm the current level of support from ARIA
>
> > > > for NFV profiles and do you have any timelines to support draft 04 ?
>
> > > >
>
> > > >
>
> > > > Regards,
>
> > > > DJ
>
> > > >
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > > Tal Liron
>
> > > Senior Engineer
>
> > > t...@gigaspaces.com | +1 (773) 828-9339
> Cloudify |
>
> > > http://getcloudify.org
>
> > > 
> > > medium=email_campaign=general_signature>
>
> > >
>
> > > 
>
> > > 
>
> > >