Re: get_artifact function usage

[Tal Liron]

Sorry, I forgot to answer this. The answer is not good: sadly, there is no
solid support for artifacts in ARIA right now beyond parsing. This function
is currently a no-op.

Rather than just implement this function, I think it should be tackled as
part of comprehensive support for artifacts: validation, downloading,
copying, and verification. I think we have a JIRA for it somewhere but I
can't seem to find it.

On Mon, Sep 18, 2017 at 10:51 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi,
>
> Do we have any comments on this ?
>
> Regards,
> DJ
>
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Thursday, September 14, 2017 4:20 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Vaishnavi K.R ; Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com>; Rajesh Malaialagusamy <
> r.malaialagus...@globallogic.com>
> Subject: get_artifact function usage
>
> Hi,
>
> We were looking at "get_artifact" function usage in the service template.
> It seems we don't have an implementation for it currently.
> The get_artifact function has the below grammer as per the spec.
>
> get_artifact: [ , , ,
>  ]
>
> We have few clarifications and questions over this.
>
> Do we need to use the get_artifact function only for input value
> assignment within a specific operation ?
>
> We have 3 options before as per the grammer
>
>   1.  Retrieving artifact without specified location - without (location)
>   2.  Retrieving artifact as a local path - with location as LOCAL_FILE
>   3.  Retrieving artifact in a specified location - with location as user
> given path How does the orchestrator need to handle these 3 options With
> 1st option as per the example , it seems the orchestrator should host the
> provided artifact in a local path of remote URL and assign that URL to
> input variable.
> With 2nd option the orchestrator should store the artifacts in a local
> path (orchestrator provided ) and have that path assigned to the input
> variable With 3rd option the orchestrator should store the artifacts in a
> local path(user provided) and have that path assigned to the input variable
> With these 3 options we also have an option to remove the artifact after
> the operation execution.
> So the questions is when should the get_artifact be resolved ? Is it
> during the parsing or during the execution ?
>
> Regards,
> DJ
>
>

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

[Tal Liron]

Feel free to take over the JIRA issue. :)

On Mon, Sep 18, 2017 at 10:50 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Tal,
>
> This seems to be a better option and we can contribute for it.
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Monday, September 11, 2017 9:26 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> 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 

RE: get_artifact function usage

[D Jayachandran]

Hi,

Do we have any comments on this ?

Regards,
DJ

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Thursday, September 14, 2017 4:20 PM
To: dev@ariatosca.incubator.apache.org
Cc: Vaishnavi K.R ; Vaishali Krishnamurthy 
; Rajesh Malaialagusamy 

Subject: get_artifact function usage

Hi,

We were looking at "get_artifact" function usage in the service template. It 
seems we don't have an implementation for it currently.
The get_artifact function has the below grammer as per the spec.

get_artifact: [ , , ,  ]

We have few clarifications and questions over this.

Do we need to use the get_artifact function only for input value assignment 
within a specific operation ?

We have 3 options before as per the grammer

  1.  Retrieving artifact without specified location - without (location)
  2.  Retrieving artifact as a local path - with location as LOCAL_FILE
  3.  Retrieving artifact in a specified location - with location as user given 
path How does the orchestrator need to handle these 3 options With 1st option 
as per the example , it seems the orchestrator should host the provided 
artifact in a local path of remote URL and assign that URL to input variable.
With 2nd option the orchestrator should store the artifacts in a local path 
(orchestrator provided ) and have that path assigned to the input variable With 
3rd option the orchestrator should store the artifacts in a local path(user 
provided) and have that path assigned to the input variable With these 3 
options we also have an option to remove the artifact after the operation 
execution.
So the questions is when should the get_artifact be resolved ? Is it during the 
parsing or during the execution ?

Regards,
DJ

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

[D Jayachandran]

Hi Tal,

This seems to be a better option and we can contribute for it.


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, September 11, 2017 9:26 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA

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

Re: Property type 'null' validation issue

[Ran Ziv]

This does sound like a bug, and I am not familiar with a JIRA ticket for
it. Feel free to create one.


On Mon, Sep 18, 2017 at 8:13 AM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried using the 'null' property type as mentioned in the TOSCA simple
> YAML 1.0 specification. I get the validation issue saying that the datatype
> specified in the service template is an unknown datatype.
>
>
> I just surfed through the code and found that 'null' is considered as one
> of the primitive datatypes. But when it is validated if its a primitive
> datatype, a class object of Null() is passed as a value. The validation
> fails as it expects a string value of 'null'.
>
>
> Is this a known issue? Do we have a JIRA item opened for this?
>
>
>
>
> Thanks,
>
> /Vaish
>

Re: Unique identification of an instance element across services

[Ran Ziv]

The service name is optional - it may be auto-generated according to the
service-template name.

The service-template name can also be made optional (see this jira issue:
https://issues.apache.org/jira/browse/ARIA-221 ).


Regarding the scenario of non-CLI interaction - for any non-human usage,
IDs should be used, as they're guaranteed to be unique. I don't see why
UUIDs are necessary in this case.


On Mon, Sep 18, 2017 at 9:22 AM, Vaishnavi K.R 
wrote:

> Hi All,
>
>
> In addition to the node instance name, I am concerned about the service
> template name and the service instance names. In a wider perspective, there
> is high chance for these names to be the same.
>
>
> And as I have already mentioned in previous discussion, its an overhead
> for an user to change the name again and again when he encounters the
> 'already exist' error.
>
>
> And also when ARIA is used as a TOSCA Orchestration service provider,
> manual interaction via CLI won't happen. All operations could be performed
> over the HTTP calls. In such scenerio, it would be great and very much
> useful, if elements are queried or identified using the UUID.
>
>
> So I see the uniqueness should prevail across the elements like service
> templates, service instances and node instances.
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Ran Ziv 
> Sent: Saturday, September 16, 2017 12:12:22 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Unique identification of an instance element across services
>
> I can't seem to be able to access our JIRA at the moment, but generally
> speaking, the CLI currently supports "static completion" only, i.e. it
> auto-completes CLI commands but not object names.
> We tried implementing dynamic completion (e.g. tab on "-s" would
> auto-complete service names from the storage), but we ran into some issues
> with the underlying Click framework.
> I'm not sure if an issue for trying to implement this further is currently
> open on our JIRA.
>
> Regarding a "partial hash" concept, I don't really find this to be useful
> in this case. IMO, as Tal's mentioned, the cases when you need to actually
> use these auto-generated long names are rare, and when that happens,
> dynamic completion can take care of it well, if we can get it done.
>
>
>
> On Fri, Sep 15, 2017 at 9:04 PM, Thomas Nadeau 
> wrote:
>
> >
> > > On Sep 15, 2017, at 1:53 PM, Tal Liron  wrote:
> > >
> > > When do you actually have to ender node names? Probably only in "aria
> > nodes
> > > show". And in those cases you would be copy-pasting from a list. We
> could
> > > also improve our CLI completion code to properly complete node IDs.
> >
> > That sounds like a very useful enhancement.  Do we have a Jira
> for
> > this yet? *)
> >
> > > I think the serial numbers are more confusing than helpful. Let's say
> you
> > > currently have 20 difference services running, and they are of various
> > > different service templates. But let's say a few service templates have
> > > node templates with the same name, "database". You could potentially
> > > "database_1" in the list and "database_2", but each one of these nodes
> > > would be of a different node template of a different service template.
> > The
> > > serial number gives the false sense that these two nodes are somehow
> > > together. Anyway, we discussed this in much detail already: we all
> agree
> > > that the serial system is totally broken if you're using more than ARIA
> > > install, or even if a few different ARIA users are using the same cloud
> > > accounts (each ARIA install could create its own "database_1" -- what
> if
> > > you have two hosts with that same DNS name?).
> >
> > I was just going to say the point you made above about DNS name
> > overlap.
> > It sounds like we need to sit down and re-visit the serial number
> > management?
> >
> > —Tom
> >
> >
> > >
> > >
> > > On Fri, Sep 15, 2017 at 12:35 PM, DeWayne Filppi 
> > > wrote:
> > >
> > >> I get the feeling that you are more gifted typist than most.  Or are
> you
> > >> saying nobody will ever be required to type in one those IDs?
> > >>
> > >> On Fri, Sep 15, 2017 at 9:27 AM, Tal Liron  wrote:
> > >>
> > >>> Before we allow users to configure this, we have another JIRA to
> > resolve:
> > >>> actually, we don't have a mechanism for storing configuration yet!
> Here
> > >> is
> > >>> the open JIRA:
> > >>>
> > >>> https://issues.apache.org/jira/browse/ARIA-229
> > >>>
> > >>> As for what to configure in this case, our practice until now was
> that
> > >> the
> > >>> UUID would be added as an underscored postfix of the object's name.
> So
> > if
> > >>> you have a node template named "database" then node instances could
> be,
> > >>> assuming longest form of UUID (alphanumeric, 36 characters):
> > >>>
> > >>> database_2d79fd86-0877-49ca-81d8-cd2dc9f7b0e2

Re: Unique identification of an instance element across services

[Vaishnavi K . R]

Hi All,


In addition to the node instance name, I am concerned about the service 
template name and the service instance names. In a wider perspective, there is 
high chance for these names to be the same.


And as I have already mentioned in previous discussion, its an overhead for an 
user to change the name again and again when he encounters the 'already exist' 
error.


And also when ARIA is used as a TOSCA Orchestration service provider, manual 
interaction via CLI won't happen. All operations could be performed over the 
HTTP calls. In such scenerio, it would be great and very much useful, if 
elements are queried or identified using the UUID.


So I see the uniqueness should prevail across the elements like service 
templates, service instances and node instances.


Thanks,

/Vaish


From: Ran Ziv 
Sent: Saturday, September 16, 2017 12:12:22 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Unique identification of an instance element across services

I can't seem to be able to access our JIRA at the moment, but generally
speaking, the CLI currently supports "static completion" only, i.e. it
auto-completes CLI commands but not object names.
We tried implementing dynamic completion (e.g. tab on "-s" would
auto-complete service names from the storage), but we ran into some issues
with the underlying Click framework.
I'm not sure if an issue for trying to implement this further is currently
open on our JIRA.

Regarding a "partial hash" concept, I don't really find this to be useful
in this case. IMO, as Tal's mentioned, the cases when you need to actually
use these auto-generated long names are rare, and when that happens,
dynamic completion can take care of it well, if we can get it done.



On Fri, Sep 15, 2017 at 9:04 PM, Thomas Nadeau 
wrote:

>
> > On Sep 15, 2017, at 1:53 PM, Tal Liron  wrote:
> >
> > When do you actually have to ender node names? Probably only in "aria
> nodes
> > show". And in those cases you would be copy-pasting from a list. We could
> > also improve our CLI completion code to properly complete node IDs.
>
> That sounds like a very useful enhancement.  Do we have a Jira for
> this yet? *)
>
> > I think the serial numbers are more confusing than helpful. Let's say you
> > currently have 20 difference services running, and they are of various
> > different service templates. But let's say a few service templates have
> > node templates with the same name, "database". You could potentially
> > "database_1" in the list and "database_2", but each one of these nodes
> > would be of a different node template of a different service template.
> The
> > serial number gives the false sense that these two nodes are somehow
> > together. Anyway, we discussed this in much detail already: we all agree
> > that the serial system is totally broken if you're using more than ARIA
> > install, or even if a few different ARIA users are using the same cloud
> > accounts (each ARIA install could create its own "database_1" -- what if
> > you have two hosts with that same DNS name?).
>
> I was just going to say the point you made above about DNS name
> overlap.
> It sounds like we need to sit down and re-visit the serial number
> management?
>
> —Tom
>
>
> >
> >
> > On Fri, Sep 15, 2017 at 12:35 PM, DeWayne Filppi 
> > wrote:
> >
> >> I get the feeling that you are more gifted typist than most.  Or are you
> >> saying nobody will ever be required to type in one those IDs?
> >>
> >> On Fri, Sep 15, 2017 at 9:27 AM, Tal Liron  wrote:
> >>
> >>> Before we allow users to configure this, we have another JIRA to
> resolve:
> >>> actually, we don't have a mechanism for storing configuration yet! Here
> >> is
> >>> the open JIRA:
> >>>
> >>> https://issues.apache.org/jira/browse/ARIA-229
> >>>
> >>> As for what to configure in this case, our practice until now was that
> >> the
> >>> UUID would be added as an underscored postfix of the object's name. So
> if
> >>> you have a node template named "database" then node instances could be,
> >>> assuming longest form of UUID (alphanumeric, 36 characters):
> >>>
> >>> database_2d79fd86-0877-49ca-81d8-cd2dc9f7b0e2
> >>> database_2819972e-3b07-4923-be94-43e95985155f
> >>> database_45b9faf5-8bf4-482a-a570-d1c058270424
> >>>
> >>> This guarantees names that are universally unique and yet still
> >> meaningful:
> >>> you would be able to tell at a glance what kind of node this is: a
> >>> database. Note that we also have a mechanism in place to warn you if
> the
> >>> final name is more than 63 characters, because such names can't be used
> >> as
> >>> DNS hostnames (a common usage for node names in the cloud). This should
> >>> also be configurable.
> >>>
> >>> I don't see why this needs to be abstracted from the user. If you are
> >> using
> >>> the CLI and see the list of nodes, you can refer to the node