Re: Issue in the execution context when using Openstack plugin

[DeWayne Filppi]

Have you considered supplying the manager ssh credentials to the locally
executing node?

On Thu, Mar 1, 2018 at 2:39 PM, Pedro Henrique Gomes <
pedrohenriquego...@gmail.com> wrote:

> Hi DeWayne,
>
> Yes, exactly that. Unfortunately I could not create yet a simple template
> with the erroneous behaviour.
> But yes, Openstack plugin seems to force the ssh in all nodes that have
> dependency with nodes that have to be executed via ssh.
>
>
> On Wed, Feb 28, 2018 at 3:02 PM DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > So in other words, the Openstack plugin is irrelevant. What you are
> saying
> > is that somehow the dependency itself causes ssh to be used in a
> > SoftwareComponent type.  If you run a blueprint just with the "prep"
> node,
> > it works fine as expected?
> >
> > DeWayne
> >
> > On Wed, Feb 28, 2018 at 9:09 AM, Pedro Henrique Gomes <
> > pedrohenriquego...@gmail.com> wrote:
> >
> >> Hi Thomas, thank you for your reply.
> >>
> >> The point is that the node that complains about not having the ssh
> >> credentials, has a HOST that should be running locally, not thru ssh.
> >>
> >> The output error that I get is below:
> >>
> >> 13:57:32 | E |
> >> aria.orchestrator.execution_plugin.operations.run_script_with_ssh |
> >> {u'process': {}, u'script_path': u'scripts/prep.sh', u'use_sudo': False,
> >> u'fabric_env': {'password': '', 'key_filename': None, 'user': '', 'key':
> >> None}, u'hide_output': []} | prep_software Standard.create failed
> >> |Traceback (most recent call last):
> >> |  File
> >>
> >> "/tmp/pip-build-7lUI8E/apache-ariatosca/aria/orchestrator/
> workflows/executor/process.py",
> >> line 342, in _main
> >> |  File
> >>
> >> "/home/pedro/aria/env/local/lib/python2.7/site-packages/
> adapters/context_adapter.py",
> >> line 436, in wrapper
> >> |function(ctx=ctx, **operation_inputs)
> >> |  File
> >>
> >> "/home/pedro/aria/env/local/lib/python2.7/site-packages/
> aria/orchestrator/decorators.py",
> >> line 78, in _wrapper
> >> |return func(**func_kwargs)
> >> |  File
> >>
> >> "/home/pedro/aria/env/local/lib/python2.7/site-packages/
> aria/orchestrator/execution_plugin/operations.py",
> >> line 51, in run_script_with_ssh
> >> |**kwargs)
> >> |  File
> >>
> >> "/home/pedro/aria/env/local/lib/python2.7/site-packages/
> aria/orchestrator/execution_plugin/ssh/operations.py",
> >> line 67, in run_script
> >> |**_fabric_env(ctx, fabric_env, warn_only=False)):
> >> |  File
> >>
> >> "/home/pedro/aria/env/local/lib/python2.7/site-packages/
> aria/orchestrator/execution_plugin/ssh/operations.py",
> >> line 157, in _fabric_env
> >> |'Access credentials not supplied '
> >> |  File
> >>
> >> "/home/pedro/aria/env/local/lib/python2.7/site-packages/
> aria/modeling/orchestration.py",
> >> line 446, in abort
> >> |raise TaskAbortException(message)
> >> |TaskAbortException: Access credentials not supplied (you must
> supply
> >> at least one of `key_filename`, `key` or `password`)
> >>
> >> 13:57:33 | I | install | {} | 'install' workflow execution failed
> >>
> >> I can try to provide to you a minimum viable template to execute and get
> >> the same error.
> >> But if you have any idea from this log, please let me know, any tip is
> >> useful.
> >>
> >> Regards
> >>
> >> On Tue, Feb 27, 2018 at 4:35 PM Thomas Nadeau <tnadeaua...@gmail.com>
> >> wrote:
> >>
> >> > It looks like you answered your own question. When you require SSH by
> >> > calling "execute_with_ssh" but do not have it configured, its not
> going
> >> to
> >> > work right? *)
> >> >
> >> > In any event, can you provide more diagnostic info so that we can see
> >> > better where things are failing. I am actually starting to work on
> >> > improving the return error/warning codes now, so its timely.
> >> >
> >> > --Tom
> >> >
> >> >
> >> > On Tue, Feb 27, 2018 at 2:08 PM, Pedro Henrique Gomes <
> >> > pedrohenriquego...@gmail.com> wrote:
> >> >
> >> > > Hello everyone,

Re: Issue in the execution context when using Openstack plugin

[DeWayne Filppi]

t; >
> > > The snippet from the template is below
> > >
> > > prep_server:
> > >   type: ServerType
> > >
> > > prep_software:
> > >   type: tosca.nodes.SoftwareComponent
> > >   requirements:
> > > - host: prep_server
> > > - dependency: vm_1
> > >  interfaces:
> > > Standard:
> > >   create: scripts/prep.sh
> > >
> > > configure_software:
> > >   type: tosca.nodes.SoftwareComponent
> > > requirements:
> > >   - host: vm_1
> > > #- dependency: prep_software
> > > interfaces:
> > >   Standard:
> > > configure:
> > >   implementation:
> > > primary: scripts/configure.sh
> > >   dependencies:
> > > - "ssh.user > ubuntu"
> > > - "ssh.key_filename > ./key.pem"
> > > - "ssh.address > { get_attribute: [ virtual_ip,
> > > floating_ip_address ] }"
> > >
> > > If I have the template above nodes prep_software and configure_software
> > > execute correctly in the desired machine. If the comment above is
> > removed,
> > > both nodes are executed with execute_with_ssh()
> > >
> > >
> > > Hoe someone can help me or provide any direction for this problem
> > >
> > > Thanks
> > >
> > >
> > > --
> > > Pedro Henrique Gomes
> > > www.pedrohenriquegomes.com.br
> > > +1-310-3101429 <(310)%20310-1429>
> > >
> >
> --
> Pedro Henrique Gomes
> www.pedrohenriquegomes.com.br
> +1-310-3101429
>



-- 

<http://cloudify.co/>

*DeWayne Filppi*
Director, Solution Architecture, Cloudify

(714)512-1706 <(714)%20512-1706>| mailto:dfil...@cloudify.co
<dfil...@cloudify.co>| http://cloudify.co

<https://www.linkedin.com/in/dfilppi> <https://twitter.com/dfilppi>
<http://cloudify.co/blog/>

Re: problem using cloudify extension with dev branch

[DeWayne Filppi]

I worked around this by installing the cloudify extention using the
--no-deps argument (to pip).

On Wed, Nov 29, 2017 at 2:32 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> OK.  I guess I didn't provide enough context.  I installed the ARIA-1
> branch of ARIA in order to pick up a bug fix I needed.  When attempting to
> install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
> installed, and it proceeds to remove it.  So, the cloudify extension
> deletes ARIA, apparently because it's looking for a different version of
> it.  The full message:
>
> Installing collected packages: apache-ariatosca, aria-extension-cloudify
> Found existing installation: apache-ariatosca 0.2.0
> Uninstalling apache-ariatosca-0.2.0:
> Successfully uninstalled apache-ariatosca-0.2.0
> Running setup.py develop for apache-ariatosca
> Complete output from command /home/vagrant/venv/bin/python -c "import
> setuptools, tokenize;__file__='/home/vagrant/venv/src/apache-
> ariatosca/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
> running develop
> Checking .pth file support in /home/vagrant/.aria/plugins/
> aria-extension-cloudify-4.1/lib/python2.7/site-packages
> /home/vagrant/venv/bin/python -E -c pass
> TEST FAILED: 
> /home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/lib/python2.7/site-packages
> does NOT support .pth files
> error: bad install directory or PYTHONPATH
> Command "/home/vagrant/venv/bin/python -c "import setuptools,
> tokenize;__file__='/home/vagrant/venv/src/apache-
> ariatosca/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
> Could not install package: aria-extension-cloudify (Command
> "/home/vagrant/venv/bin/python -c "import setuptools,
> tokenize;__file__='/home/vagrant/venv/src/apache-
> ariatosca/setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
> --prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
> with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)
>
>
> On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron <t...@cloudify.co> wrote:
>
>> Sorry, hard to understand exactly what you're trying to do, what's
>> "failing" etc.
>>
>> All I can gather from this is that you are installing something that
>> requires "apache-ariatosca" but that is already installed, so it's
>> removing
>> it in order to upgrade. You stopped the log there.
>>
>> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi <dewa...@cloudify.co>
>> wrote:
>>
>> > I see the following when trying to install the cloudify extension with
>> the
>> > ARIA-1 branch:
>> >
>> > Installing collected packages: apache-ariatosca, aria-extension-cloudify
>> > Found existing installation: apache-ariatosca 0.2.0
>> > Uninstalling apache-ariatosca-0.2.0:
>> >
>> > Then it fails.
>> >
>>
>
>

Re: problem using cloudify extension with dev branch

[DeWayne Filppi]

OK.  I guess I didn't provide enough context.  I installed the ARIA-1
branch of ARIA in order to pick up a bug fix I needed.  When attempting to
install aria-extension-cloudify, it complains that ariatosca 0.2.0 is
installed, and it proceeds to remove it.  So, the cloudify extension
deletes ARIA, apparently because it's looking for a different version of
it.  The full message:

Installing collected packages: apache-ariatosca, aria-extension-cloudify
Found existing installation: apache-ariatosca 0.2.0
Uninstalling apache-ariatosca-0.2.0:
Successfully uninstalled apache-ariatosca-0.2.0
Running setup.py develop for apache-ariatosca
Complete output from command /home/vagrant/venv/bin/python -c "import
setuptools,
tokenize;__file__='/home/vagrant/venv/src/apache-ariatosca/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
--prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1:
running develop
Checking .pth file support in
/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/lib/python2.7/site-packages
/home/vagrant/venv/bin/python -E -c pass
TEST FAILED:
/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1/lib/python2.7/site-packages
does NOT support .pth files
error: bad install directory or PYTHONPATH
Command "/home/vagrant/venv/bin/python -c "import setuptools,
tokenize;__file__='/home/vagrant/venv/src/apache-ariatosca/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
--prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
with error code 1 in /home/vagrant/venv/src/apache-ariatosca/
Could not install package: aria-extension-cloudify (Command
"/home/vagrant/venv/bin/python -c "import setuptools,
tokenize;__file__='/home/vagrant/venv/src/apache-ariatosca/setup.py';f=getattr(tokenize,
'open', open)(__file__);code=f.read().replace('\r\n',
'\n');f.close();exec(compile(code, __file__, 'exec'))" develop --no-deps
--prefix=/home/vagrant/.aria/plugins/aria-extension-cloudify-4.1" failed
with error code 1 in /home/vagrant/venv/src/apache-ariatosca/)


On Wed, Nov 29, 2017 at 11:13 AM, Tal Liron <t...@cloudify.co> wrote:

> Sorry, hard to understand exactly what you're trying to do, what's
> "failing" etc.
>
> All I can gather from this is that you are installing something that
> requires "apache-ariatosca" but that is already installed, so it's removing
> it in order to upgrade. You stopped the log there.
>
> On Wed, Nov 29, 2017 at 1:08 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I see the following when trying to install the cloudify extension with
> the
> > ARIA-1 branch:
> >
> > Installing collected packages: apache-ariatosca, aria-extension-cloudify
> > Found existing installation: apache-ariatosca 0.2.0
> > Uninstalling apache-ariatosca-0.2.0:
> >
> > Then it fails.
> >
>

Re: back to the future

[DeWayne Filppi]

Yeah, well in a big spec like TOSCA, I tend to go for the examples rather
than reading it cover to cover, which actually makes them more important
than the spec in a practical sense.  But maybe that's just me.  On the
other hand, it validates the raison d'etre of ARIA: to discover such issues
with the spec and serve as a feedback mechanism.

On Tue, Nov 28, 2017 at 11:02 AM, Tal Liron <t...@cloudify.co> wrote:

> OK, baseball reference. :)
>
> Well, it's always easy to criticize. :) If we want TOSCA to be better, we
> need to better participate in the process. There is an open JIRA for ARIA
> to consolidate all our errata into a single proposal for OASIS.
>
> On Tue, Nov 28, 2017 at 1:00 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > bush league == amateur hour
> >
> > On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Sorry, I did not understand that last comment about "bush league"!
> > >
> > > But yes, the spec is known to be flimsy and self-contradictory. In the
> > end,
> > > we must make a choice on how to implement things in ARIA, while taking
> > into
> > > account that other TOSCA implementations might interpret the spec
> > > differently. (Even more ideally: provide configuration options for
> ARIA's
> > > parser, so that it could better work with YAML files created for other
> > > TOSCA implementations. We have a few of these configuration options
> > > already.)
> > >
> > > This is exactly why the current PR for ARIA-1 is important: it
> > introduces a
> > > broad test suite for TOSCA syntax and grammar, which obviously follows
> > the
> > > interpretations we made for ARIA. But it can be run on other TOSCA
> > parsers,
> > > too, at least giving us information as to where other parsers differ in
> > > their interpretations of the spec.
> > >
> > > I will say that our rules of thumb has generally been: 1) if a strict
> and
> > > loose interpretation are possible, choose the stricter one, and 2) keep
> > the
> > > "spirit of the spec" in mind: object-orientation and enforcement of the
> > > parent type contract.
> > >
> > > On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Wow.  That is reeeaaally bad and bush
> > > league.
> > > >
> > > > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > "Examples" in the spec routinely break the syntax of the spec... I
> > > think
> > > > > it's best not to trust them.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <
> > dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > I suppose it lets you name interfaces whatever you want, which is
> > > > > confusing
> > > > > > because of other areas of the spec.  Note that there are tons of
> > > > examples
> > > > > > in the spec without the "type" specified.
> > > > > >
> > > > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > I mentioned this to you in the previous thread: the "type"
> field
> > is
> > > > > > > required for interface definitions according to TOSCA syntax.
> So,
> > > > even
> > > > > if
> > > > > > > it's the same as what you are inheriting, you must specify it.
> > > > > > >
> > > > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > > > dewa...@cloudify.co>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Now that the 'subclassing' problem has been resolved,
> > overriding
> > > > > > > interface
> > > > > > > > methods is breaking.  Simple example:
> > > > > > > >
> > > > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > > >
> > > > > > > > imports:
> > > > > > > >
> > > > > > > >   - aria-1.0
> > > > > > > >
> > > > > > > > node_types:
> > > > > > > >
> > > > > > > >   T1:
> > > > > > > > derived_from: tosca.nodes.Root
> > > > > > > > interfaces:
> > > > > > > >   Standard:
> > > > > > > > create:
> > > > > > > >   implementation:
> > > > > > > > primary: i1.sh
> > > > > > > > delete:
> > > > > > > >   implementation:
> > > > > > > > primary: i1.sh
> > > > > > > >
> > > > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > > > >
> > > > > > > > Validation issues:
> > > > > > > >   2: required field "type" in
> > > > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> > > InterfaceDefinition"
> > > > > > does
> > > > > > > > not
> > > > > > > > have a value
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: back to the future

[DeWayne Filppi]

bush league == amateur hour

On Tue, Nov 28, 2017 at 10:49 AM, Tal Liron <t...@cloudify.co> wrote:

> Sorry, I did not understand that last comment about "bush league"!
>
> But yes, the spec is known to be flimsy and self-contradictory. In the end,
> we must make a choice on how to implement things in ARIA, while taking into
> account that other TOSCA implementations might interpret the spec
> differently. (Even more ideally: provide configuration options for ARIA's
> parser, so that it could better work with YAML files created for other
> TOSCA implementations. We have a few of these configuration options
> already.)
>
> This is exactly why the current PR for ARIA-1 is important: it introduces a
> broad test suite for TOSCA syntax and grammar, which obviously follows the
> interpretations we made for ARIA. But it can be run on other TOSCA parsers,
> too, at least giving us information as to where other parsers differ in
> their interpretations of the spec.
>
> I will say that our rules of thumb has generally been: 1) if a strict and
> loose interpretation are possible, choose the stricter one, and 2) keep the
> "spirit of the spec" in mind: object-orientation and enforcement of the
> parent type contract.
>
> On Tue, Nov 28, 2017 at 12:44 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Wow.  That is reeeaaally bad and bush
> league.
> >
> > On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > "Examples" in the spec routinely break the syntax of the spec... I
> think
> > > it's best not to trust them.
> > >
> > > On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > I suppose it lets you name interfaces whatever you want, which is
> > > confusing
> > > > because of other areas of the spec.  Note that there are tons of
> > examples
> > > > in the spec without the "type" specified.
> > > >
> > > > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > I mentioned this to you in the previous thread: the "type" field is
> > > > > required for interface definitions according to TOSCA syntax. So,
> > even
> > > if
> > > > > it's the same as what you are inheriting, you must specify it.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <
> > dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > Now that the 'subclassing' problem has been resolved,  overriding
> > > > > interface
> > > > > > methods is breaking.  Simple example:
> > > > > >
> > > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > >
> > > > > > imports:
> > > > > >
> > > > > >   - aria-1.0
> > > > > >
> > > > > > node_types:
> > > > > >
> > > > > >   T1:
> > > > > > derived_from: tosca.nodes.Root
> > > > > > interfaces:
> > > > > >   Standard:
> > > > > > create:
> > > > > >   implementation:
> > > > > > primary: i1.sh
> > > > > > delete:
> > > > > >   implementation:
> > > > > > primary: i1.sh
> > > > > >
> > > > > > The error, using Aria in the ARIA-1 branch:
> > > > > >
> > > > > > Validation issues:
> > > > > >   2: required field "type" in
> > > > > > "aria_extension_tosca.simple_v1_0.definitions.
> InterfaceDefinition"
> > > > does
> > > > > > not
> > > > > > have a value
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: back to the future

[DeWayne Filppi]

Wow.  That is reeeaaally bad and bush league.

On Tue, Nov 28, 2017 at 10:42 AM, Tal Liron <t...@cloudify.co> wrote:

> "Examples" in the spec routinely break the syntax of the spec... I think
> it's best not to trust them.
>
> On Tue, Nov 28, 2017 at 12:40 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I suppose it lets you name interfaces whatever you want, which is
> confusing
> > because of other areas of the spec.  Note that there are tons of examples
> > in the spec without the "type" specified.
> >
> > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > I mentioned this to you in the previous thread: the "type" field is
> > > required for interface definitions according to TOSCA syntax. So, even
> if
> > > it's the same as what you are inheriting, you must specify it.
> > >
> > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Now that the 'subclassing' problem has been resolved,  overriding
> > > interface
> > > > methods is breaking.  Simple example:
> > > >
> > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > >
> > > > imports:
> > > >
> > > >   - aria-1.0
> > > >
> > > > node_types:
> > > >
> > > >   T1:
> > > > derived_from: tosca.nodes.Root
> > > > interfaces:
> > > >   Standard:
> > > > create:
> > > >   implementation:
> > > > primary: i1.sh
> > > > delete:
> > > >   implementation:
> > > > primary: i1.sh
> > > >
> > > > The error, using Aria in the ARIA-1 branch:
> > > >
> > > > Validation issues:
> > > >   2: required field "type" in
> > > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> > does
> > > > not
> > > > have a value
> > > >
> > >
> >
>

Re: back to the future

[DeWayne Filppi]

Interesting.  Then how does this example from the spec function?:

mysql_database:

  type: Database
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#DEFN_TYPE_NODES_DATABASE>

  properties:

name: { get_input: db_name }

user: { get_input: db_user }

password: { get_input: db_pwd }

port: { get_input: db_port }

  capabilities:

database_endpoint:

  properties:

port: { get_input: db_port }

  requirements:

- host: mysql_dbms

  interfaces:

Standard:

  configure: mysql_database_configure.sh
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#UC_2_MYSQL_DATABASE_CONFIGURE_SH>

On Tue, Nov 28, 2017 at 10:40 AM, Tal Liron <t...@cloudify.co> wrote:

> I agree that ideally it could be inherited from the parent node type if not
> specified. That would indeed be my opinion.
>
> Small quibble: the fact that it's called "Standard" is arbitrary. The
> interface name does *not* have to conform to the interface type, it's just
> what they decided for the normative Root node type. The name does *not*
> contain type information. For example, in your own node type you can
> override the interface named "Standard" to be of a different interface
> type, which does not have "Standard" in its name. (ARIA will insist that
> your overriding type inherits from the Standard node type -- see our other
> discussion about type inheritance.)
>
> On Tue, Nov 28, 2017 at 12:32 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Seems rather ugly.  Do you have an opinion?  If I specify that I'm using
> > the Standard interface, what point is there in the "type" field?
> >
> > On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > I mentioned this to you in the previous thread: the "type" field is
> > > required for interface definitions according to TOSCA syntax. So, even
> if
> > > it's the same as what you are inheriting, you must specify it.
> > >
> > > On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Now that the 'subclassing' problem has been resolved,  overriding
> > > interface
> > > > methods is breaking.  Simple example:
> > > >
> > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > >
> > > > imports:
> > > >
> > > >   - aria-1.0
> > > >
> > > > node_types:
> > > >
> > > >   T1:
> > > > derived_from: tosca.nodes.Root
> > > > interfaces:
> > > >   Standard:
> > > > create:
> > > >   implementation:
> > > > primary: i1.sh
> > > > delete:
> > > >   implementation:
> > > > primary: i1.sh
> > > >
> > > > The error, using Aria in the ARIA-1 branch:
> > > >
> > > > Validation issues:
> > > >   2: required field "type" in
> > > > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition"
> > does
> > > > not
> > > > have a value
> > > >
> > >
> >
>

Re: back to the future

[DeWayne Filppi]

I suppose it lets you name interfaces whatever you want, which is confusing
because of other areas of the spec.  Note that there are tons of examples
in the spec without the "type" specified.

On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:

> I mentioned this to you in the previous thread: the "type" field is
> required for interface definitions according to TOSCA syntax. So, even if
> it's the same as what you are inheriting, you must specify it.
>
> On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Now that the 'subclassing' problem has been resolved,  overriding
> interface
> > methods is breaking.  Simple example:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > imports:
> >
> >   - aria-1.0
> >
> > node_types:
> >
> >   T1:
> > derived_from: tosca.nodes.Root
> > interfaces:
> >   Standard:
> > create:
> >   implementation:
> > primary: i1.sh
> > delete:
> >   implementation:
> > primary: i1.sh
> >
> > The error, using Aria in the ARIA-1 branch:
> >
> > Validation issues:
> >   2: required field "type" in
> > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does
> > not
> > have a value
> >
>

Re: back to the future

[DeWayne Filppi]

Seems rather ugly.  Do you have an opinion?  If I specify that I'm using
the Standard interface, what point is there in the "type" field?

On Tue, Nov 28, 2017 at 10:27 AM, Tal Liron <t...@cloudify.co> wrote:

> I mentioned this to you in the previous thread: the "type" field is
> required for interface definitions according to TOSCA syntax. So, even if
> it's the same as what you are inheriting, you must specify it.
>
> On Tue, Nov 28, 2017 at 12:04 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Now that the 'subclassing' problem has been resolved,  overriding
> interface
> > methods is breaking.  Simple example:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > imports:
> >
> >   - aria-1.0
> >
> > node_types:
> >
> >   T1:
> > derived_from: tosca.nodes.Root
> > interfaces:
> >   Standard:
> > create:
> >   implementation:
> > primary: i1.sh
> > delete:
> >   implementation:
> > primary: i1.sh
> >
> > The error, using Aria in the ARIA-1 branch:
> >
> > Validation issues:
> >   2: required field "type" in
> > "aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does
> > not
> > have a value
> >
>

back to the future

[DeWayne Filppi]

Now that the 'subclassing' problem has been resolved,  overriding interface
methods is breaking.  Simple example:

tosca_definitions_version: tosca_simple_yaml_1_0

imports:

  - aria-1.0

node_types:

  T1:
derived_from: tosca.nodes.Root
interfaces:
  Standard:
create:
  implementation:
primary: i1.sh
delete:
  implementation:
primary: i1.sh

The error, using Aria in the ARIA-1 branch:

Validation issues:
  2: required field "type" in
"aria_extension_tosca.simple_v1_0.definitions.InterfaceDefinition" does not
have a value

Re: TOSCA type inheritance question

[DeWayne Filppi]

Yes, that branch validates it without error.

On Tue, Nov 28, 2017 at 9:20 AM, Tal Liron <t...@cloudify.co> wrote:

> This is a big that is fixed in the ARIA-1 commit, which is waiting to be
> merged.
>
> If you don't mind helping to test, could you try with this branch?
> https://github.com/apache/incubator-ariatosca/tree/ARIA-
> 1-parser-test-suite
>
> On Tue, Nov 28, 2017 at 11:13 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I made a simple example that fails.  Maybe my example is a
> > misinterpretation of what you said:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > imports:
> >
> >   - aria-1.0
> >
> > data_types:
> >
> >   d1:
> > properties:
> >   p1:
> > type: string
> >
> >   d2:
> > derived_from: d1
> > properties:
> >   p2:
> > type: string
> >
> > node_types:
> >
> >   T1:
> > derived_from: tosca.nodes.Root
> > properties:
> >   n1:
> > type: d1
> >
> >
> >   T2:
> > derived_from: T1
> > properties:
> >   n1:
> > type: d2
> >
> >
> > This produces the error:
> >
> >   4: override changes type from "d1" to "d2" for property "n1" in "T2
> >
> > On Tue, Nov 28, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > You are correct that it's not entirely clear from the spec. However, I
> > > always interpret the spirit of the spec to be object-oriented. That
> means
> > > that in ARIA: yes, you can override a property, AS LONG AS the property
> > > type is of compatible with (equal or derived from) the one in the
> parent.
> > > ARIA will check for this and issue a validation error if you break the
> > > parent's contract.
> > >
> > > On Tue, Nov 28, 2017 at 10:56 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > If there is a node type that inherits from another node type, can a
> > > > property in the parent be overridden by the subtype?  I'm having
> > trouble
> > > > getting a straight answer to that basic question from the spec.
> > > >
> > > > DeWayne
> > > >
> > >
> >
>

Re: TOSCA type inheritance question

[DeWayne Filppi]

I made a simple example that fails.  Maybe my example is a
misinterpretation of what you said:

tosca_definitions_version: tosca_simple_yaml_1_0

imports:

  - aria-1.0

data_types:

  d1:
properties:
  p1:
type: string

  d2:
derived_from: d1
properties:
  p2:
type: string

node_types:

  T1:
derived_from: tosca.nodes.Root
properties:
  n1:
type: d1


  T2:
derived_from: T1
properties:
  n1:
type: d2


This produces the error:

  4: override changes type from "d1" to "d2" for property "n1" in "T2

On Tue, Nov 28, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wrote:

> You are correct that it's not entirely clear from the spec. However, I
> always interpret the spirit of the spec to be object-oriented. That means
> that in ARIA: yes, you can override a property, AS LONG AS the property
> type is of compatible with (equal or derived from) the one in the parent.
> ARIA will check for this and issue a validation error if you break the
> parent's contract.
>
> On Tue, Nov 28, 2017 at 10:56 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > If there is a node type that inherits from another node type, can a
> > property in the parent be overridden by the subtype?  I'm having trouble
> > getting a straight answer to that basic question from the spec.
> >
> > DeWayne
> >
>

TOSCA type inheritance question

[DeWayne Filppi]

If there is a node type that inherits from another node type, can a
property in the parent be overridden by the subtype?  I'm having trouble
getting a straight answer to that basic question from the spec.

DeWayne

Re: simple validation error

[DeWayne Filppi]

thx

On Nov 27, 2017 3:43 PM, "Tal Liron" <t...@cloudify.co> wrote:

It is a bug. I created this issue:
https://issues.apache.org/jira/browse/ARIA-411

For now, the workaround is to add a "primary" key under "implementation".

Also note that you must supply the "type" field for the interface
definition. So:

  T1:
derived_from: tosca.nodes.Root
interfaces:
  Standard:
type: tosca.interfaces.node.lifecycle.Standard
create:
  implementation:
primary: i1.sh

On Mon, Nov 27, 2017 at 5:28 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> This should validate, no?
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
>
>   - aria-1.0
>
>
> node_types:
>
>   T1:
> derived_from: tosca.nodes.Root
> interfaces:
>   Standard:
> create:
>   implementation: i1.sh
>
>   T2:
> derived_from: T1
> interfaces:
>   Standard:
> create:
>   implementation: i1.sh
>
>
> The content of 'i1.sh' doesn't matter.  The error is (Aria 0.1.1):
>
> AttributeError: 'LocatableString' object has no attribute 'iteritems'
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/consumption/consumer.py",
> line 70, in consume
> consumer.consume()
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/consumption/validation.py",
> line 30, in consume
> self.context.presentation.presenter._validate(self.context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/presenter.py",
> line 65, in _validate
> self.service_template._validate(context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/
> presentation.py",
> line 193, in _validate
> validate_known_fields(context, self)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/utils.py",
> line 110, in validate_known_fields
> field.validate(presentation, context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/fields.py",
> line 409, in validate
> self.default_validate(presentation, context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/fields.py",
> line 524, in default_validate
> self.validate_value(value, context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> parser/presentation/fields.py",
> line 540, in validate_value
> inner_value._validate(context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/types.py",
> line 655, in _validate
> self._get_interfaces(context)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/utils/caching.py",
> line 84, in __call__
> return_value = self.func(*args, **kwargs)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/types.py",
> line 643, in _get_interfaces
> return FrozenDict(get_inherited_interface_definitions(context, self,
> 'node type'))
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 127, in get_inherited_interface_definitions
> for_presentation=for_presentation)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 435, in merge_interface_definitions
> 'definition')
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 425, in merge_interface_definition
> presentation, type_name)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 392, in merge_raw_operation_definitions
> presentation, type_name)
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria_
> extension_tosca/simple_v1_0/modeling/interfaces.py",
> line 364, in merge_raw_operation_definition
> deepcopy_with_locators(our_operation._raw['implementation']))
>   File
> "/home/vagrant/venv/lib/python2.7/site-packages/aria/
> utils/collections.py",
> line 232, in merge
> for key, value_b in dict_b.iteritems():
> Validation issues:
>   0: 'LocatableString' object has no attribute 'iteritems'
>  AttributeError: 'LocatableString' object has no attribute 'iteritems'
>

simple validation error

[DeWayne Filppi]

This should validate, no?

tosca_definitions_version: tosca_simple_yaml_1_0

imports:

  - aria-1.0


node_types:

  T1:
derived_from: tosca.nodes.Root
interfaces:
  Standard:
create:
  implementation: i1.sh

  T2:
derived_from: T1
interfaces:
  Standard:
create:
  implementation: i1.sh


The content of 'i1.sh' doesn't matter.  The error is (Aria 0.1.1):

AttributeError: 'LocatableString' object has no attribute 'iteritems'
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/consumption/consumer.py",
line 70, in consume
consumer.consume()
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/consumption/validation.py",
line 30, in consume
self.context.presentation.presenter._validate(self.context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/presenter.py",
line 65, in _validate
self.service_template._validate(context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/presentation.py",
line 193, in _validate
validate_known_fields(context, self)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/utils.py",
line 110, in validate_known_fields
field.validate(presentation, context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/fields.py",
line 409, in validate
self.default_validate(presentation, context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/fields.py",
line 524, in default_validate
self.validate_value(value, context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/parser/presentation/fields.py",
line 540, in validate_value
inner_value._validate(context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/types.py",
line 655, in _validate
self._get_interfaces(context)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/utils/caching.py",
line 84, in __call__
return_value = self.func(*args, **kwargs)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/types.py",
line 643, in _get_interfaces
return FrozenDict(get_inherited_interface_definitions(context, self,
'node type'))
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/modeling/interfaces.py",
line 127, in get_inherited_interface_definitions
for_presentation=for_presentation)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/modeling/interfaces.py",
line 435, in merge_interface_definitions
'definition')
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/modeling/interfaces.py",
line 425, in merge_interface_definition
presentation, type_name)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/modeling/interfaces.py",
line 392, in merge_raw_operation_definitions
presentation, type_name)
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria_extension_tosca/simple_v1_0/modeling/interfaces.py",
line 364, in merge_raw_operation_definition
deepcopy_with_locators(our_operation._raw['implementation']))
  File
"/home/vagrant/venv/lib/python2.7/site-packages/aria/utils/collections.py",
line 232, in merge
for key, value_b in dict_b.iteritems():
Validation issues:
  0: 'LocatableString' object has no attribute 'iteritems'
 AttributeError: 'LocatableString' object has no attribute 'iteritems'

Re: What does it take to become an AriaTosca committer?

[DeWayne Filppi]

Yes, but the topic was being a committer.  If you aren't producing code or
docs, what exactly are you "committing"?

On Wed, Nov 22, 2017 at 12:33 PM, Tal Liron <t...@cloudify.co> wrote:

> Remember than anybody can be contributor. Becoming a committer,
> specifically, means having privileges to move the project forward according
> to the agreed-upon roadmap. I personally think there's a lot more to that
> than just being a Python coder, which is why I personally don't necessarily
> value code contributions over others. AriaTosca has implications regarding
> standards bodies and industry reach of TOSCA that go beyond the project's
> mere technical value. I'm in favor of keeping the various aspects of the
> list equally important.
>
> In the end the list is just a set of guidelines. Current committers get to
> vote for accepting new committers, and there can be discussion (on the
> private@ mailing list) regarding individual candidates.
>
> On Wed, Nov 22, 2017 at 1:23 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Looks good.  I'd only say that it's item 1 and/or item 2, plus bonus
> points
> > for things in the rest of the list.  If all you provide is amazing code
> > contributions, that should be sufficient.  Also, if it's an election that
> > should be mentioned.
> >
> > On Wed, Nov 22, 2017 at 8:45 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > I've written up a list of requirements:
> > >
> > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > Becoming+a+Committer
> > >
> > > It's up to the committers to define this list, but would be happy to
> get
> > > feedback from non-committers, too!
> > >
> >
>

Re: What does it take to become an AriaTosca committer?

[DeWayne Filppi]

Looks good.  I'd only say that it's item 1 and/or item 2, plus bonus points
for things in the rest of the list.  If all you provide is amazing code
contributions, that should be sufficient.  Also, if it's an election that
should be mentioned.

On Wed, Nov 22, 2017 at 8:45 AM, Tal Liron  wrote:

> I've written up a list of requirements:
>
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Becoming+a+Committer
>
> It's up to the committers to define this list, but would be happy to get
> feedback from non-committers, too!
>

Re: Attribute and Property Reflection

[DeWayne Filppi]

I meant attribute values differ.  Property values don't differ between
instances.  When I mean allow functions to be values, I mean the return
value only from the TOSCA perspective.

On Thu, Nov 16, 2017 at 3:21 PM, Tal Liron <t...@cloudify.co> wrote:

> Well, you can argue that attributes *vary* per node instance, while
> properties *do not vary* per node instance.
>
> Our discussion about function values is important: if a property value is a
> function, the actual evaluated value might indeed be different per node
> instance.
>
> ARIA actually does keep copies of everything (both properties and
> attributes) for every node instance in the models. We made this blanket
> decision to allow for full flexibility in implementing plugins and
> supporting future versions of TOSCA. While in TOSCA properties are strictly
> read-only at the parser level, it may be possible for plugins to change
> property values. Imagine, for example, a plugin that takes existing Compute
> nodes and upgrades them: many of their properties may change.
>
> It's fine and good for TOSCA to be strict, but we wanted ARIA to underneath
> be as flexible as needed.
>
> On Thu, Nov 16, 2017 at 5:12 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Properties and attributes have no relationship.  I always assumed the
> > reflection was a convenience.  Attributes are per instance, not per node.
> >
> > On Thu, Nov 16, 2017 at 2:54 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > The reason I think this is a bad feature is that TOSCA makes such a
> clear
> > > effort to separate properties from attributes, but then this reflection
> > > features means that basically it's enough to only have properties...
> > >
> > > My proposal for TOSCA 2.0 would be to have *just* properties and to
> allow
> > > some properties to have "mutable: true" if you want then to behave like
> > an
> > > attribute.
> > >
> > > On Thu, Nov 16, 2017 at 3:01 PM, Steve Baillargeon <
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Hi Tal
> > > > I found the magic statement in 3.5.8.1.1
> > > > Yes the reflected attribute name must be the same as the property
> name
> > > for
> > > > the reflection feature.
> > > > Now I understand your second point. Thanks for your patience.
> > > >
> > > > Why do you think it is a bad feature?
> > > > Property is the desired value while reflected attribute is the actual
> > > > value.
> > > > It seems logical to show actual value.
> > > > Or are you saying the actual value will always be the same as the
> > desired
> > > > value and the reflected attribute is useless?
> > > >
> > > > -Steve
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Tal Liron [mailto:t...@cloudify.co]
> > > > Sent: Thursday, November 16, 2017 3:49 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: Attribute and Property Reflection
> > > >
> > > > The reflection feature is mentioned very, very briefly in just that
> one
> > > > sentence in the spec. They is no mention of changing names, so I am
> > > > expecting that the attribute names would be identical to the property
> > > > names. In that case, there would be a conflict if an attribute has
> the
> > > same
> > > > name as a property -- otherwise how would the property be reflected?
> > > That's
> > > > why I'm assuming that for this to work we should not allow an
> attribute
> > > > name to override a property name.
> > > >
> > > > My preferred solution is not to add any custom prefixes in ARIA,
> > because
> > > > they would not be portable
> > > >
> > > > The TOSCA spec has many authors, and it would be hard to track down
> the
> > > > particular one who wrote this sentence... Personally, I think this is
> > an
> > > > awful and unclear feature.
> > > >
> > > > On Thu, Nov 16, 2017 at 2:43 PM, Steve Baillargeon <
> > > > steve.baillarg...@ericsson.com> wrote:
> > > >
> > > > > Back 1 step please.
> > > > > Are you saying that attribute names and property names within a
> Type
> > > > > MUST be different?
> > > > > As far as I know they can be the same e.g.   =
> > > > > 
> > > >

Re: Attribute and Property Reflection

[DeWayne Filppi]

Properties and attributes have no relationship.  I always assumed the
reflection was a convenience.  Attributes are per instance, not per node.

On Thu, Nov 16, 2017 at 2:54 PM, Tal Liron  wrote:

> The reason I think this is a bad feature is that TOSCA makes such a clear
> effort to separate properties from attributes, but then this reflection
> features means that basically it's enough to only have properties...
>
> My proposal for TOSCA 2.0 would be to have *just* properties and to allow
> some properties to have "mutable: true" if you want then to behave like an
> attribute.
>
> On Thu, Nov 16, 2017 at 3:01 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Tal
> > I found the magic statement in 3.5.8.1.1
> > Yes the reflected attribute name must be the same as the property name
> for
> > the reflection feature.
> > Now I understand your second point. Thanks for your patience.
> >
> > Why do you think it is a bad feature?
> > Property is the desired value while reflected attribute is the actual
> > value.
> > It seems logical to show actual value.
> > Or are you saying the actual value will always be the same as the desired
> > value and the reflected attribute is useless?
> >
> > -Steve
> >
> >
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Thursday, November 16, 2017 3:49 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Attribute and Property Reflection
> >
> > The reflection feature is mentioned very, very briefly in just that one
> > sentence in the spec. They is no mention of changing names, so I am
> > expecting that the attribute names would be identical to the property
> > names. In that case, there would be a conflict if an attribute has the
> same
> > name as a property -- otherwise how would the property be reflected?
> That's
> > why I'm assuming that for this to work we should not allow an attribute
> > name to override a property name.
> >
> > My preferred solution is not to add any custom prefixes in ARIA, because
> > they would not be portable
> >
> > The TOSCA spec has many authors, and it would be hard to track down the
> > particular one who wrote this sentence... Personally, I think this is an
> > awful and unclear feature.
> >
> > On Thu, Nov 16, 2017 at 2:43 PM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Back 1 step please.
> > > Are you saying that attribute names and property names within a Type
> > > MUST be different?
> > > As far as I know they can be the same e.g.   =
> > > 
> > >
> > > attributes:
> > >   :
> > > type:string
> > > properties:
> > >   :
> > >   type:string
> > >
> > >
> > > Back to reflection.
> > > I am proposing  = actual_ But I think
> > > it is best if I ask further clarification from YAML Profile authors.
> > > What do you think?
> > > What is your preferred solution?
> > >
> > > -Steve
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Thursday, November 16, 2017 3:15 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Attribute and Property Reflection
> > >
> > > Steve, we cannot change the TOSCA spec, and the spec does not say
> > > anything about naming conventions here.
> > >
> > > I think, though, that an obvious part of this JIRA will be to emit an
> > > error if an attribute name is the same as a property name, because
> > > obviously this would break this feature.
> > >
> > > On Thu, Nov 16, 2017 at 2:12 PM, Steve Baillargeon <
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > I see the following text in the JIRA:
> > > > According to the TOSCA 1.0 spec, property value should be 'exposed',
> > > > with the same name, as attributes.
> > > >
> > > > Does the spec really say to use the same name? As far as I know it
> > > > does not.
> > > > What about using a better reflected attribute naming convention like
> > > > “actual_”?
> > > > Can I add this to the JIRA?
> > > >
> > > > -Steve B
> > > >
> > > > -Original Message-
> > > > From: Tal Liron [mailto:t...@cloudify.co]
> > > > Sent: Thursday, November 16, 2017 2:48 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: Attribute and Property Reflection
> > > >
> > > > Not right now, but there is an open JIRA to support it.
> > > >
> > > > On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon <
> > > > steve.baillarg...@ericsson.com> wrote:
> > > >
> > > > > Hi
> > > > > Does ARIA support "attribute and property reflection" defined in
> > > > 3.5.10.1?
> > > > >
> > > > > Regards
> > > > > Steve B
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Attribute and Property Reflection

[DeWayne Filppi]

My reading suggests no rename was permitted.  'Reflect' seems definitive.

On Thu, Nov 16, 2017 at 12:48 PM, Tal Liron  wrote:

> The reflection feature is mentioned very, very briefly in just that one
> sentence in the spec. They is no mention of changing names, so I am
> expecting that the attribute names would be identical to the property
> names. In that case, there would be a conflict if an attribute has the same
> name as a property -- otherwise how would the property be reflected? That's
> why I'm assuming that for this to work we should not allow an attribute
> name to override a property name.
>
> My preferred solution is not to add any custom prefixes in ARIA, because
> they would not be portable
>
> The TOSCA spec has many authors, and it would be hard to track down the
> particular one who wrote this sentence... Personally, I think this is an
> awful and unclear feature.
>
> On Thu, Nov 16, 2017 at 2:43 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Back 1 step please.
> > Are you saying that attribute names and property names within a Type MUST
> > be different?
> > As far as I know they can be the same e.g.   =
> > 
> >
> > attributes:
> >   :
> > type:string
> > properties:
> >   :
> >   type:string
> >
> >
> > Back to reflection.
> > I am proposing  = actual_
> > But I think it is best if I ask further clarification from YAML Profile
> > authors.
> > What do you think?
> > What is your preferred solution?
> >
> > -Steve
> >
> >
> >
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Thursday, November 16, 2017 3:15 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Attribute and Property Reflection
> >
> > Steve, we cannot change the TOSCA spec, and the spec does not say
> anything
> > about naming conventions here.
> >
> > I think, though, that an obvious part of this JIRA will be to emit an
> > error if an attribute name is the same as a property name, because
> > obviously this would break this feature.
> >
> > On Thu, Nov 16, 2017 at 2:12 PM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > I see the following text in the JIRA:
> > > According to the TOSCA 1.0 spec, property value should be 'exposed',
> > > with the same name, as attributes.
> > >
> > > Does the spec really say to use the same name? As far as I know it
> > > does not.
> > > What about using a better reflected attribute naming convention like
> > > “actual_”?
> > > Can I add this to the JIRA?
> > >
> > > -Steve B
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Thursday, November 16, 2017 2:48 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Attribute and Property Reflection
> > >
> > > Not right now, but there is an open JIRA to support it.
> > >
> > > On Thu, Nov 16, 2017 at 1:42 PM, Steve Baillargeon <
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Hi
> > > > Does ARIA support "attribute and property reflection" defined in
> > > 3.5.10.1?
> > > >
> > > > Regards
> > > > Steve B
> > > >
> > > >
> > >
> >
>

Re: attributes

[DeWayne Filppi]

I'm not sure there is any reason to mention it in TOSCA, but that's OK.  It
also would allow lazy evaluation by node types.  Some rarely used
attributes might cause slow performance in a non-lazy plugin.

On Thu, Nov 16, 2017 at 12:36 PM, Tal Liron <t...@cloudify.co> wrote:

> I do have some ideas for expanding TOSCA to support "operation types" that
> would allow more flexibility exactly for these use cases. My article about
> it might be coming out soon!
>
> On Thu, Nov 16, 2017 at 2:34 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > True, the roots are in functional programming.  In any case, I don't
> think
> > serializing lambdas is going to cut it.  The attribute accessor could be
> > calling the Openstack python libraries.  IMHO, this happens by executing
> > code in the context of the plugin.  The persistent store could have some
> > kind of "reference" (not a real reference of course) that could be
> > recognized as a path to a python package and function.  In any case,
> I'll
> > JIRA it up.
> >
> > DeWayne
> >
> > On Thu, Nov 16, 2017 at 12:28 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Well, this is *kinda* supported in ARIA right now.
> > >
> > > It *is* supported via the Python API: you can create an instance of any
> > > function class (such as GetProperty) and it will be serialized the
> > storage
> > > and evaluated upon retrieval.
> > >
> > > But it is *not* supported via ctx in Bash. If we want to support this,
> we
> > > would also need to find a syntax for doing so (ctx right now would have
> > no
> > > idea if you mean to use a plain string or mean to instantiate a
> > function).
> > >
> > > If you feel this is a useful feature, feel free to open a JIRA for it.
> > > Please describe it in as much detail as possible and perhaps add some
> > > practical use cases for the feature.
> > >
> > > (By the way, I don't see this as an issue of programming languages
> moving
> > > from structs to accessors, but an issue of functional programming.
> > > Functional programming languages treat functions as "first-class
> > citizens",
> > > so that they can be passed around by value. The TOSCA spec has nothing
> to
> > > say about this, but it is something we can support quite easily because
> > we
> > > built ARIA in Python, which does have this functional aspect.)
> > >
> > > On Thu, Nov 16, 2017 at 2:21 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Yes.  Permit a function to be an attribute value.  This would apply
> to
> > > both
> > > > context and intrinsic evaluation.
> > > >
> > > > On Thu, Nov 16, 2017 at 12:18 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > I'm not entirely sure what you are saying here. My guess is that
> you
> > > mean
> > > > > something like this:
> > > > >
> > > > > When setting an attribute value via ctx, you want ARIA to be able
> to
> > > set
> > > > > function values. For example, this is just a regular value:
> > > > >
> > > > > ctx set my_attribute "plain string value"
> > > > >
> > > > > You are saying that we should also support this:
> > > > >
> > > > > ctx set my_attribute "{ get_property: [ SELF, property_name ] }"
> > > > >
> > > > > In which case you expect ARIA to actually evaluate the function
> when
> > > you
> > > > > retrieve the value of my_attribute. Am I understanding you
> correctly?
> > > > >
> > > > >
> > > > > On Thu, Nov 16, 2017 at 1:55 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > What I'm talking about has nothing to do with TOSCA.  It only has
> > to
> > > do
> > > > > > with the orchestrator.  Accessing an attribute has nothing to do
> > with
> > > > > > operations.
> > > > > >
> > > > > > On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > DeWayne, what you asking for might be achievable via the
> > > > > > > "get_operation_output" function. This fu

Re: attributes

[DeWayne Filppi]

True, the roots are in functional programming.  In any case, I don't think
serializing lambdas is going to cut it.  The attribute accessor could be
calling the Openstack python libraries.  IMHO, this happens by executing
code in the context of the plugin.  The persistent store could have some
kind of "reference" (not a real reference of course) that could be
recognized as a path to a python package and function.  In any case,  I'll
JIRA it up.

DeWayne

On Thu, Nov 16, 2017 at 12:28 PM, Tal Liron <t...@cloudify.co> wrote:

> Well, this is *kinda* supported in ARIA right now.
>
> It *is* supported via the Python API: you can create an instance of any
> function class (such as GetProperty) and it will be serialized the storage
> and evaluated upon retrieval.
>
> But it is *not* supported via ctx in Bash. If we want to support this, we
> would also need to find a syntax for doing so (ctx right now would have no
> idea if you mean to use a plain string or mean to instantiate a function).
>
> If you feel this is a useful feature, feel free to open a JIRA for it.
> Please describe it in as much detail as possible and perhaps add some
> practical use cases for the feature.
>
> (By the way, I don't see this as an issue of programming languages moving
> from structs to accessors, but an issue of functional programming.
> Functional programming languages treat functions as "first-class citizens",
> so that they can be passed around by value. The TOSCA spec has nothing to
> say about this, but it is something we can support quite easily because we
> built ARIA in Python, which does have this functional aspect.)
>
> On Thu, Nov 16, 2017 at 2:21 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Yes.  Permit a function to be an attribute value.  This would apply to
> both
> > context and intrinsic evaluation.
> >
> > On Thu, Nov 16, 2017 at 12:18 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > I'm not entirely sure what you are saying here. My guess is that you
> mean
> > > something like this:
> > >
> > > When setting an attribute value via ctx, you want ARIA to be able to
> set
> > > function values. For example, this is just a regular value:
> > >
> > > ctx set my_attribute "plain string value"
> > >
> > > You are saying that we should also support this:
> > >
> > > ctx set my_attribute "{ get_property: [ SELF, property_name ] }"
> > >
> > > In which case you expect ARIA to actually evaluate the function when
> you
> > > retrieve the value of my_attribute. Am I understanding you correctly?
> > >
> > >
> > > On Thu, Nov 16, 2017 at 1:55 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > What I'm talking about has nothing to do with TOSCA.  It only has to
> do
> > > > with the orchestrator.  Accessing an attribute has nothing to do with
> > > > operations.
> > > >
> > > > On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > DeWayne, what you asking for might be achievable via the
> > > > > "get_operation_output" function. This function is not very well
> > defined
> > > > in
> > > > > TOSCA, but it seems that the expectation is that every operation
> can
> > > > return
> > > > > an untyped key-value dict. This has nothing to do with attributes
> per
> > > se,
> > > > > but behind the scenes works quite similarly.
> > > > >
> > > > > But, if you really you want something more dynamic ("call to the
> > cloud"
> > > > as
> > > > > you say), that doesn't exist in TOSCA right now. It could be
> possible
> > > to
> > > > > add such a feature to ARIA, but it would not be portable.
> > > > >
> > > > > Steve, seems that you understand it correctly.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Nov 16, 2017 at 1:25 PM, Steve Baillargeon <
> > > > > steve.baillarg...@ericsson.com> wrote:
> > > > >
> > > > > > Hi
> > > > > > A follow-up question.
> > > > > > I am trying to understand the meaning of "function" here.
> > > > > >
> > > > > > Is the solution as simple as defining an attribute (say of type
> > > > string),
> > > &g

Re: attributes

[DeWayne Filppi]

Yes.  Permit a function to be an attribute value.  This would apply to both
context and intrinsic evaluation.

On Thu, Nov 16, 2017 at 12:18 PM, Tal Liron <t...@cloudify.co> wrote:

> I'm not entirely sure what you are saying here. My guess is that you mean
> something like this:
>
> When setting an attribute value via ctx, you want ARIA to be able to set
> function values. For example, this is just a regular value:
>
> ctx set my_attribute "plain string value"
>
> You are saying that we should also support this:
>
> ctx set my_attribute "{ get_property: [ SELF, property_name ] }"
>
> In which case you expect ARIA to actually evaluate the function when you
> retrieve the value of my_attribute. Am I understanding you correctly?
>
>
> On Thu, Nov 16, 2017 at 1:55 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > What I'm talking about has nothing to do with TOSCA.  It only has to do
> > with the orchestrator.  Accessing an attribute has nothing to do with
> > operations.
> >
> > On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > DeWayne, what you asking for might be achievable via the
> > > "get_operation_output" function. This function is not very well defined
> > in
> > > TOSCA, but it seems that the expectation is that every operation can
> > return
> > > an untyped key-value dict. This has nothing to do with attributes per
> se,
> > > but behind the scenes works quite similarly.
> > >
> > > But, if you really you want something more dynamic ("call to the cloud"
> > as
> > > you say), that doesn't exist in TOSCA right now. It could be possible
> to
> > > add such a feature to ARIA, but it would not be portable.
> > >
> > > Steve, seems that you understand it correctly.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Nov 16, 2017 at 1:25 PM, Steve Baillargeon <
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Hi
> > > > A follow-up question.
> > > > I am trying to understand the meaning of "function" here.
> > > >
> > > > Is the solution as simple as defining an attribute (say of type
> > string),
> > > > skip the attribute assignment in the template and let the plugin
> > decides
> > > > the "value" for the attribute which can be a calculated value or any
> > > > function implemented by the plugin? Yes I agree this is not portable.
> > > > Did I miss something?
> > > >
> > > > -Steve
> > > >
> > > > -Original Message-
> > > > From: Tal Liron [mailto:t...@cloudify.co]
> > > > Sent: Wednesday, November 15, 2017 4:24 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: attributes
> > > >
> > > > Well, this is a bit complex.
> > > >
> > > > Attributes are ostensibly filled during runtime by other systems, for
> > > > example during the install workflow an ip_address would get its real
> > > value.
> > > > It's not really clear how another system would be able to insert a
> > > > function here, but it's not impossible. In ARIA's case, functions are
> > > > implemented as pickled Python classes, so it would be possible to do
> > > this,
> > > > however obviously it would not be portable.
> > > >
> > > > But, you can also give attributes default values. For default values,
> > > > obviously you can use functions.
> > > >
> > > > On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <dewa...@cloudify.co
> >
> > > > wrote:
> > > >
> > > > > General TOSCA question.  Is there anything in the spec that
> requires
> > > > > attributes to be values rather than functions?  IOW, is there
> > anything
> > > > > in there that prevents an orchestrator from representing an
> attribute
> > > > > read as more of a "getter", rather than a database fetch?  I ask
> > > > > because I've run across a case where I'd prefer an attribute
> > reference
> > > > > to return a calculated value.  Seems more flexible if allowed, and
> if
> > > > > not allowed, it should be allowed.
> > > > >
> > > > > DeWayne
> > > > >
> > > >
> > >
> >
>

Re: attributes

[DeWayne Filppi]

What I'm talking about has nothing to do with TOSCA.  It only has to do
with the orchestrator.  Accessing an attribute has nothing to do with
operations.

On Thu, Nov 16, 2017 at 11:46 AM, Tal Liron <t...@cloudify.co> wrote:

> DeWayne, what you asking for might be achievable via the
> "get_operation_output" function. This function is not very well defined in
> TOSCA, but it seems that the expectation is that every operation can return
> an untyped key-value dict. This has nothing to do with attributes per se,
> but behind the scenes works quite similarly.
>
> But, if you really you want something more dynamic ("call to the cloud" as
> you say), that doesn't exist in TOSCA right now. It could be possible to
> add such a feature to ARIA, but it would not be portable.
>
> Steve, seems that you understand it correctly.
>
>
>
>
>
> On Thu, Nov 16, 2017 at 1:25 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > A follow-up question.
> > I am trying to understand the meaning of "function" here.
> >
> > Is the solution as simple as defining an attribute (say of type string),
> > skip the attribute assignment in the template and let the plugin decides
> > the "value" for the attribute which can be a calculated value or any
> > function implemented by the plugin? Yes I agree this is not portable.
> > Did I miss something?
> >
> > -Steve
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Wednesday, November 15, 2017 4:24 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: attributes
> >
> > Well, this is a bit complex.
> >
> > Attributes are ostensibly filled during runtime by other systems, for
> > example during the install workflow an ip_address would get its real
> value.
> > It's not really clear how another system would be able to insert a
> > function here, but it's not impossible. In ARIA's case, functions are
> > implemented as pickled Python classes, so it would be possible to do
> this,
> > however obviously it would not be portable.
> >
> > But, you can also give attributes default values. For default values,
> > obviously you can use functions.
> >
> > On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > General TOSCA question.  Is there anything in the spec that requires
> > > attributes to be values rather than functions?  IOW, is there anything
> > > in there that prevents an orchestrator from representing an attribute
> > > read as more of a "getter", rather than a database fetch?  I ask
> > > because I've run across a case where I'd prefer an attribute reference
> > > to return a calculated value.  Seems more flexible if allowed, and if
> > > not allowed, it should be allowed.
> > >
> > > DeWayne
> > >
> >
>

Re: attributes

[DeWayne Filppi]

I'm relating it to programming languages.   Long ago many languages did
away with 'structs' in favor of accessors (i.e. getters and setters).
 Just trying to make the same basic advance here.  There is nothing in
TOSCA that says an attribute has to equate to a fixed value in memory (that
I've seen).  It is portable, because the plugin is in charge of attributes
for the types it defines.  Basic stuff.

On Thu, Nov 16, 2017 at 11:25 AM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> A follow-up question.
> I am trying to understand the meaning of "function" here.
>
> Is the solution as simple as defining an attribute (say of type string),
> skip the attribute assignment in the template and let the plugin decides
> the "value" for the attribute which can be a calculated value or any
> function implemented by the plugin? Yes I agree this is not portable.
> Did I miss something?
>
> -Steve
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 15, 2017 4:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: attributes
>
> Well, this is a bit complex.
>
> Attributes are ostensibly filled during runtime by other systems, for
> example during the install workflow an ip_address would get its real value.
> It's not really clear how another system would be able to insert a
> function here, but it's not impossible. In ARIA's case, functions are
> implemented as pickled Python classes, so it would be possible to do this,
> however obviously it would not be portable.
>
> But, you can also give attributes default values. For default values,
> obviously you can use functions.
>
> On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > General TOSCA question.  Is there anything in the spec that requires
> > attributes to be values rather than functions?  IOW, is there anything
> > in there that prevents an orchestrator from representing an attribute
> > read as more of a "getter", rather than a database fetch?  I ask
> > because I've run across a case where I'd prefer an attribute reference
> > to return a calculated value.  Seems more flexible if allowed, and if
> > not allowed, it should be allowed.
> >
> > DeWayne
> >
>

Re: attributes

[DeWayne Filppi]

Not exactly what I meant.  Take a plugin that talks to the cloud you
mentioned.  One option is to have the plugin "fill in" the value in the
orchestrator.  Another implementation is to fetch the value on demand.  The
plugin writer provides the function, not the target system.  The following
happens now (for the compute IP address example):

1. install workflow run on template, compute node plugin fetches IP address
and stores it in an attribute.
2. a dependent node grabs the IP attribute and does whatever.  This is
implemented as an ARIA storage fetch.

What I'm suggesting:

1. install workflow run on template, compute node doesn't fetch IP.
2. a dependent node grabs the IP attribute, which results in a call to the
cloud to fetch the value.

IOW, there are never two copies of the state, at least in persistent
storage.  I'm not suggesting this for the ip_address example, but other use
cases would benefit.  Note that the default "getter" for attributes could
simply fetch the value from ARIA storage.

DeWayne

On Wed, Nov 15, 2017 at 1:23 PM, Tal Liron <t...@cloudify.co> wrote:

> Well, this is a bit complex.
>
> Attributes are ostensibly filled during runtime by other systems, for
> example during the install workflow an ip_address would get its real value.
> It's not really clear how another system would be able to insert a function
> here, but it's not impossible. In ARIA's case, functions are implemented as
> pickled Python classes, so it would be possible to do this, however
> obviously it would not be portable.
>
> But, you can also give attributes default values. For default values,
> obviously you can use functions.
>
> On Wed, Nov 15, 2017 at 2:51 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > General TOSCA question.  Is there anything in the spec that requires
> > attributes to be values rather than functions?  IOW, is there anything in
> > there that prevents an orchestrator from representing an attribute read
> as
> > more of a "getter", rather than a database fetch?  I ask because I've run
> > across a case where I'd prefer an attribute reference to return a
> > calculated value.  Seems more flexible if allowed, and if not allowed, it
> > should be allowed.
> >
> > DeWayne
> >
>

attributes

[DeWayne Filppi]

General TOSCA question.  Is there anything in the spec that requires
attributes to be values rather than functions?  IOW, is there anything in
there that prevents an orchestrator from representing an attribute read as
more of a "getter", rather than a database fetch?  I ask because I've run
across a case where I'd prefer an attribute reference to return a
calculated value.  Seems more flexible if allowed, and if not allowed, it
should be allowed.

DeWayne

Re: Attributes

[DeWayne Filppi]

Does Aria permit adhoc attributes created in plugins?

DeWayne

On Nov 14, 2017 3:04 PM, "Tal Liron"  wrote:

Thanks, Steve. It seems that you are looking at the table at 5.8.2.2. The
"required" column here seems poorly named: what they seem to mean is that
when required is "yes" the orchestrator *must* fill in a value. Indeed all
the attributes I mentioned earlier, that ARIA fills in, are marked as
"required"=true.

On Tue, Nov 14, 2017 at 4:58 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> The required column  for attributes is below.
>
> Required = yes à Mandatory to fill in ?
>
> Required = no à Optional to fill in ?
>
>
>
>
>
>
>
>
>

Re: wiki entry for Periodic Blogs/vBlogs Created

[DeWayne Filppi]

Setting aside the knowledge of confluence, who would go looking for a wiki
via an "issue tracker" link?  This seems so obvious to me that there must
be something wrong with me.  I don't care where it is, I'd have just
preferred it "disinterred" rather than hidden.  So if I must be specific,
on the community page right above the dev mailling list line.  Franky, even
the community page isn't the right place.  "Docs" should lead to wiki and
the API docs, perhaps on a pulldown.   But that's more work.

DeWayne

On Mon, Nov 13, 2017 at 2:48 PM, Thomas Nadeau <tnadeaua...@gmail.com>
wrote:

>
> Specifics please! Like where specifically would you like this?  *)
>
> There is a link, but its buried a little. If you click on “Issue
> Tracker” here:
>
> http://ariatosca.incubator.apache.org/community/ <
> http://ariatosca.incubator.apache.org/community/>
>
> I am happy to make functional improvements like this. Just let me
> know where.
>
> —Tom
>
>
> > On Nov 13, 2017, at 5:15 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:
> >
> > Yeah, at least that's where I instinctively look for it.  Then I have to
> > remember to go to github to find the link.  Seems arduous for those of us
> > with poor memories, or anyone approaching Aria for the first time.
> >
> > On Mon, Nov 13, 2017 at 1:40 PM, Thomas Nadeau <tnadeaua...@gmail.com>
> > wrote:
> >
> >>
> >>Specifically here or somewhere else?
> >>
> >> http://ariatosca.incubator.apache.org/community/ <
> >> http://ariatosca.incubator.apache.org/community/>
> >>
> >>
> >>> On Nov 13, 2017, at 4:35 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
> >>>
> >>> It would be nice if there was a link to the wiki on the community page.
> >>>
> >>> On Mon, Nov 13, 2017 at 1:19 PM, Thomas Nadeau <tnadeaua...@gmail.com>
> >>> wrote:
> >>>
> >>>>
> >>>>   Just a heads up that I have created a section on the wiki to
> >>>> store/manage/coordinate amongst ourselves here around
> >>>> future blogs/vblogs. There is a section for planned/scheduled
> >>>> entries, as well as future ones or suggested ones. If you have ideas
> >>>> for these, please go here and add them. Its a dynamic document, so
> >>>> we will update here as we go forward too.
> >>>>
> >>>> https://cwiki.apache.org/confluence/display/ARIATOSCA/
> >>>> Periodic+Blogs+and+Videos <https://cwiki.apache.org/
> >>>> confluence/display/ARIATOSCA/Periodic+Blogs+and+Videos>
> >>>>
> >>>>   Thanks,
> >>>>
> >>>>   —Tom
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: wiki entry for Periodic Blogs/vBlogs Created

[DeWayne Filppi]

Yeah, at least that's where I instinctively look for it.  Then I have to
remember to go to github to find the link.  Seems arduous for those of us
with poor memories, or anyone approaching Aria for the first time.

On Mon, Nov 13, 2017 at 1:40 PM, Thomas Nadeau <tnadeaua...@gmail.com>
wrote:

>
> Specifically here or somewhere else?
>
> http://ariatosca.incubator.apache.org/community/ <
> http://ariatosca.incubator.apache.org/community/>
>
>
> > On Nov 13, 2017, at 4:35 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:
> >
> > It would be nice if there was a link to the wiki on the community page.
> >
> > On Mon, Nov 13, 2017 at 1:19 PM, Thomas Nadeau <tnadeaua...@gmail.com>
> > wrote:
> >
> >>
> >>Just a heads up that I have created a section on the wiki to
> >> store/manage/coordinate amongst ourselves here around
> >> future blogs/vblogs. There is a section for planned/scheduled
> >> entries, as well as future ones or suggested ones. If you have ideas
> >> for these, please go here and add them. Its a dynamic document, so
> >> we will update here as we go forward too.
> >>
> >> https://cwiki.apache.org/confluence/display/ARIATOSCA/
> >> Periodic+Blogs+and+Videos <https://cwiki.apache.org/
> >> confluence/display/ARIATOSCA/Periodic+Blogs+and+Videos>
> >>
> >>Thanks,
> >>
> >>—Tom
> >>
> >>
> >>
> >>
>
>

Re: wiki entry for Periodic Blogs/vBlogs Created

[DeWayne Filppi]

It would be nice if there was a link to the wiki on the community page.

On Mon, Nov 13, 2017 at 1:19 PM, Thomas Nadeau 
wrote:

>
> Just a heads up that I have created a section on the wiki to
> store/manage/coordinate amongst ourselves here around
> future blogs/vblogs. There is a section for planned/scheduled
> entries, as well as future ones or suggested ones. If you have ideas
> for these, please go here and add them. Its a dynamic document, so
> we will update here as we go forward too.
>
> https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Periodic+Blogs+and+Videos  confluence/display/ARIATOSCA/Periodic+Blogs+and+Videos>
>
> Thanks,
>
> —Tom
>
>
>
>

native plugins

[DeWayne Filppi]

As opposed to using Cloudify plugins, is there an example of a native
plugin?  Or should new plugins just be written for Cloudify and adapted.
I'm talking user role plugins, not internal like execution.

DeWayne

Re: decoupling type definitions from CSAR

[DeWayne Filppi]

This is all TOSCA stuff, no?  You can import from a URL in template,
doesn't have to be in the CSAR.

On Fri, Nov 10, 2017 at 3:30 AM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> With the current ARIA, in order to use the type definitions that are user
> defined, it must be imported in the Service Template. The definitions files
> are imported by specifying the relative paths in the 'imports' section.
> These type definition files can rather reside in the localhost running ARIA
> or can be made available by bundling along with the service templates in a
> CSAR. For remote executions, the latter holds good.
>
>
> However if the type definitions are so common and can be used across
> Service Templates, it becomes mandatory to include the same file in
> different CSARs.
>
>
> In order to reuse the type definitions that are common across service
> templates, it would be better to maintain the user defined type definitions
> separately and every service template can use it irrespective of their
> CSARs.
>
>
> This makes the user defined type definitions to be loaded once and the
> service templates could import it.
>
>
> I would like to know your view on this.
>
>
> Thanks,
>
> /Vaish
>

Re: helloworld oddity

[DeWayne Filppi]

Perfect.  Thanks.

On Fri, Nov 3, 2017 at 8:52 AM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> I ran into this issue earlier.
>
> The example you are referrring to is in the master branch of the
> hello_world.yaml https://github.com/apache/incubator-ariatosca/blob/
> master/examples/hello-world/hello-world.yaml
>
>
> You will need to use the example from 0.1.1 tagged branch at
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/examples/hello-world/helloworld.yaml to work with the 0.1.1
> installation of aria
>
> [https://avatars3.githubusercontent.com/u/47359?s=400=4]<
> https://github.com/apache/incubator-ariatosca/blob/0.1.1/examples/hello-
> world/helloworld.yaml>
>
> apache/incubator-ariatosca<https://github.com/apache/
> incubator-ariatosca/blob/0.1.1/examples/hello-world/helloworld.yaml>
> github.com
> incubator-ariatosca - Mirror of Apache incubator
>
>
> [https://avatars3.githubusercontent.com/u/47359?s=400=4]<
> https://github.com/apache/incubator-ariatosca/blob/master/examples/hello-
> world/hello-world.yaml>
>
> apache/incubator-ariatosca<https://github.com/apache/
> incubator-ariatosca/blob/master/examples/hello-world/hello-world.yaml>
> github.com
> incubator-ariatosca - Mirror of Apache incubator
>
>
>
>
> Vish
>
>
> 
> From: DeWayne Filppi <dewa...@cloudify.co>
> Sent: Friday, November 3, 2017 10:17 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: helloworld oddity
>
> In the helloworld.yaml example template there is a node derived from
> tosca:Root.
>
>WebServer:
>derived_from: tosca:Root
>
> This fails validation in 0.1.1.   Am I missing something?
>
> DeWayne
>

helloworld oddity

[DeWayne Filppi]

In the helloworld.yaml example template there is a node derived from
tosca:Root.

   WebServer:
   derived_from: tosca:Root

This fails validation in 0.1.1.   Am I missing something?

DeWayne

Re: Docker Container Release Artifacts

[DeWayne Filppi]

It would be good to have one that doesn't include the REST API.  Something
more official.

On Wed, Oct 25, 2017 at 1:46 PM, Thomas Nadeau 
wrote:

>
> I cannot find any docker container artifacts as part of the
> official releases that
> we are doing. Is there any interest in pushing a container officially as
> part of
> each release (or do they exist somewhere I haven’t found)?
>
> Currently there are a few unofficial ones including the one that
> DeWayne just pushed here:
>
> https://hub.docker.com/r/cloudifyco/aria/  cloudifyco/aria/>
>
> —Tom
>
>

RE: Fortigate VNF template

[DeWayne Filppi]

Hi,

The openstack operations are defined in openstack.yaml.  And yes, you'll
have to use the Cloudify cloud init plugin.  Note that youll have to create
a Tosca version of the types.yaml.

DeWayne



On Oct 11, 2017 4:22 PM, "Steve Baillargeon" <steve.baillarg...@ericsson.com>
wrote:

Hi DeWayne
Thank you for the great example.

Two follow-up questions:

1) I don't see the Standard interface definitions for the Openstack related
nodes in the main service template (except for private_network_subnet). Did
I miss something?

2) Say I want to use cloud-init to inject data (say one remote IP address
and a trusted CA certificate) from a config drive when the VNF is initially
deployed. Should I use/import the Cloudify cloud-init plugin instead?
https://github.com/cloudify-incubator/cloudify-utilities-
plugin/tree/master/cloudify_cloudinit

Regards
Steve B

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
Sent: Wednesday, October 11, 2017 10:08 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Fortigate VNF template

Perfect!

Thx man.

—Tom


> On Oct 11, 2017, at 9:30 AM, DeWayne Filppi <dewa...@cloudify.co> wrote:
>
> I already provided more detail.  I'll see if I can boil it down into a
> focused example.
>
> On Tue, Oct 10, 2017 at 5:02 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> Thanks, Tom. I'm pretty sure there already is just a JIRA... anyway,
>> I edited yours just to remove the other things, because DeWayne is
>> reporting a different issue here.
>>
>> DeWayne, could you you pretty please provide us with something more
>> than "blows a gasket"? What happens exactly and when, and could you
>> please try to isolate it to a minimal case?
>>
>> On Tue, Oct 10, 2017 at 3:24 PM, Thomas Nadeau
>> <tnadeaua...@gmail.com>
>> wrote:
>>
>>>
>>>    I created https://issues.apache.org/jira/browse/ARIA-388 to
>>> capture this.
>>>
>>>—Tom
>>>
>>>
>>>> On Oct 10, 2017, at 4:09 PM, DeWayne Filppi <dewa...@cloudify.co>
>> wrote:
>>>>
>>>> Ok.  The interesting thing is that not only does it allow you to
>>>> have ad-hoc inputs, it also blows a gasket when you try to define them.
>>>>
>>>> On Tue, Oct 10, 2017 at 3:02 PM, Tal Liron <t...@cloudify.co> wrote:
>>>>
>>>>> ARIA right now lets you throw in ad hoc inputs, but I consider
>>>>> this to
>>> be a
>>>>> bug. So yes, I would say you absolutely need to declare your inputs.
>>>>>
>>>>> On Tue, Oct 10, 2017 at 2:46 PM, DeWayne Filppi
>>>>> <dewa...@cloudify.co>
>>>>> wrote:
>>>>>
>>>>>> So you'd agree that it should have required an explicit
>>>>>> definition of
>>> the
>>>>>> inputs?
>>>>>>
>>>>>> On Tue, Oct 10, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:
>>>>>>
>>>>>>> Any help in debugging would be appreciated!
>>>>>>>
>>>>>>> On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <
>> dewa...@cloudify.co>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> For reasons that somewhat mystify me, the template is
>>>>>>>> installing
>> with
>>>>>> no
>>>>>>>> errors now.  I fixed it by removing the inputs definition I had
>>>>>>>> in
>>>>> the
>>>>>>>> terminal.yaml file, which is counter-intuitive.  I used to
>>>>>>>> have, in
>>>>> the
>>>>>>>> node type definition:
>>>>>>>>
>>>>>>>>   interfaces:
>>>>>>>> Standard:
>>>>>>>>   create:
>>>>>>>> implementation: cloudify-utilities-plugin >
>>>>>>>> cloudify_terminal.tasks.run
>>>>>>>> inputs:
>>>>>>>>   calls:
>>>>>>>> type: list
>>>>>>>> entry_schema: call_type
>>>>>>>>
>>>>>>>> I defined the inputs because I thought I had to.  This was the
>> source
>>>>>> of
>>>>>>>> the error I mentioned in another thread (regarding yaml-1.1).
>>>>>>>> In
>> any
>>>>>>> case,
>&

Re: Fortigate VNF template

[DeWayne Filppi]

I already provided more detail.  I'll see if I can boil it down into a
focused example.

On Tue, Oct 10, 2017 at 5:02 PM, Tal Liron <t...@cloudify.co> wrote:

> Thanks, Tom. I'm pretty sure there already is just a JIRA... anyway, I
> edited yours just to remove the other things, because DeWayne is reporting
> a different issue here.
>
> DeWayne, could you you pretty please provide us with something more than
> "blows a gasket"? What happens exactly and when, and could you please try
> to isolate it to a minimal case?
>
> On Tue, Oct 10, 2017 at 3:24 PM, Thomas Nadeau <tnadeaua...@gmail.com>
> wrote:
>
> >
> > I created https://issues.apache.org/jira/browse/ARIA-388 to
> > capture this.
> >
> > —Tom
> >
> >
> > > On Oct 10, 2017, at 4:09 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
> > >
> > > Ok.  The interesting thing is that not only does it allow you to have
> > > ad-hoc inputs, it also blows a gasket when you try to define them.
> > >
> > > On Tue, Oct 10, 2017 at 3:02 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > >> ARIA right now lets you throw in ad hoc inputs, but I consider this to
> > be a
> > >> bug. So yes, I would say you absolutely need to declare your inputs.
> > >>
> > >> On Tue, Oct 10, 2017 at 2:46 PM, DeWayne Filppi <dewa...@cloudify.co>
> > >> wrote:
> > >>
> > >>> So you'd agree that it should have required an explicit definition of
> > the
> > >>> inputs?
> > >>>
> > >>> On Tue, Oct 10, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:
> > >>>
> > >>>> Any help in debugging would be appreciated!
> > >>>>
> > >>>> On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > >>>> wrote:
> > >>>>
> > >>>>> For reasons that somewhat mystify me, the template is installing
> with
> > >>> no
> > >>>>> errors now.  I fixed it by removing the inputs definition I had in
> > >> the
> > >>>>> terminal.yaml file, which is counter-intuitive.  I used to have, in
> > >> the
> > >>>>> node type definition:
> > >>>>>
> > >>>>>interfaces:
> > >>>>>  Standard:
> > >>>>>create:
> > >>>>>  implementation: cloudify-utilities-plugin >
> > >>>>> cloudify_terminal.tasks.run
> > >>>>>  inputs:
> > >>>>>calls:
> > >>>>>  type: list
> > >>>>>  entry_schema: call_type
> > >>>>>
> > >>>>> I defined the inputs because I thought I had to.  This was the
> source
> > >>> of
> > >>>>> the error I mentioned in another thread (regarding yaml-1.1).  In
> any
> > >>>> case,
> > >>>>> by commenting it out, I got no validation errors, and the terminal
> > >>> calls
> > >>>>> are made as expected.  In the node template, I still pass inputs:
> > >>>>>
> > >>>>>  interfaces:
> > >>>>>Standard:
> > >>>>>  create:
> > >>>>>inputs:
> > >>>>>  calls:
> > >>>>>- action: exit
> > >>>>>
> > >>>>> This doesn't seem as though it should be possible.  In any case,
> the
> > >>>> latest
> > >>>>> has been pushed to the repo:
> > >>>>> https://github.com/dfilppi/fortigate-tosca-example
> > >>>>>
> > >>>>> DeWayne
> > >>>>>
> > >>>>> On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <
> > >> dewa...@cloudify.co>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> For those interested, I'm in the process of implementing a TOSCA
> > >>>> template
> > >>>>>> for the initial deployment and configuration of a Fortigate VNF in
> > >>>>>> Openstack.  It uses a couple of borrowed Cloudify plugins: one for
> > >>>>>> Openstack itself (https://github.com/cloudify-
> > >>>> cosmo/cloudify-openstack-
> > >>>>>> plugin), and one for the terminal plugin (part of the Cloudify
> > >>>> incubator
> > >>>>>> "utilities" project (https://github.com/cloudify-
> > >>>>>> incubator/cloudify-utilities-plugin).
> > >>>>>>
> > >>>>>> The basic idea is that a network and router is created with public
> > >>>>> access,
> > >>>>>> and a private network with no direct public access.  In between is
> > >>> the
> > >>>>>> Fortigate firewall VNF that controls access to instances running
> on
> > >>> the
> > >>>>>> private network.  The initial template just sets up the VNF and
> > >>>> networks.
> > >>>>>> The next template (TBD) will deploy a service on the private
> > >> network
> > >>>> and
> > >>>>>> reconfigure the firewall to allow access via port forwarding.
> > >> This
> > >>> is
> > >>>>>> very much a work in progress (the VNF configuration isn't quite
> > >>> working
> > >>>>>> yet):
> > >>>>>>
> > >>>>>> https://github.com/dfilppi/fortigate-tosca-example
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Re: Fortigate VNF template

[DeWayne Filppi]

Ok.  The interesting thing is that not only does it allow you to have
ad-hoc inputs, it also blows a gasket when you try to define them.

On Tue, Oct 10, 2017 at 3:02 PM, Tal Liron <t...@cloudify.co> wrote:

> ARIA right now lets you throw in ad hoc inputs, but I consider this to be a
> bug. So yes, I would say you absolutely need to declare your inputs.
>
> On Tue, Oct 10, 2017 at 2:46 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > So you'd agree that it should have required an explicit definition of the
> > inputs?
> >
> > On Tue, Oct 10, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Any help in debugging would be appreciated!
> > >
> > > On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > For reasons that somewhat mystify me, the template is installing with
> > no
> > > > errors now.  I fixed it by removing the inputs definition I had in
> the
> > > > terminal.yaml file, which is counter-intuitive.  I used to have, in
> the
> > > > node type definition:
> > > >
> > > > interfaces:
> > > >   Standard:
> > > > create:
> > > >   implementation: cloudify-utilities-plugin >
> > > > cloudify_terminal.tasks.run
> > > >   inputs:
> > > > calls:
> > > >   type: list
> > > >   entry_schema: call_type
> > > >
> > > > I defined the inputs because I thought I had to.  This was the source
> > of
> > > > the error I mentioned in another thread (regarding yaml-1.1).  In any
> > > case,
> > > > by commenting it out, I got no validation errors, and the terminal
> > calls
> > > > are made as expected.  In the node template, I still pass inputs:
> > > >
> > > >   interfaces:
> > > >     Standard:
> > > >   create:
> > > > inputs:
> > > >   calls:
> > > > - action: exit
> > > >
> > > > This doesn't seem as though it should be possible.  In any case, the
> > > latest
> > > > has been pushed to the repo:
> > > > https://github.com/dfilppi/fortigate-tosca-example
> > > >
> > > > DeWayne
> > > >
> > > > On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > wrote:
> > > >
> > > > > For those interested, I'm in the process of implementing a TOSCA
> > > template
> > > > > for the initial deployment and configuration of a Fortigate VNF in
> > > > > Openstack.  It uses a couple of borrowed Cloudify plugins: one for
> > > > > Openstack itself (https://github.com/cloudify-
> > > cosmo/cloudify-openstack-
> > > > > plugin), and one for the terminal plugin (part of the Cloudify
> > > incubator
> > > > > "utilities" project (https://github.com/cloudify-
> > > > > incubator/cloudify-utilities-plugin).
> > > > >
> > > > > The basic idea is that a network and router is created with public
> > > > access,
> > > > > and a private network with no direct public access.  In between is
> > the
> > > > > Fortigate firewall VNF that controls access to instances running on
> > the
> > > > > private network.  The initial template just sets up the VNF and
> > > networks.
> > > > > The next template (TBD) will deploy a service on the private
> network
> > > and
> > > > > reconfigure the firewall to allow access via port forwarding.
>  This
> > is
> > > > > very much a work in progress (the VNF configuration isn't quite
> > working
> > > > > yet):
> > > > >
> > > > > https://github.com/dfilppi/fortigate-tosca-example
> > > > >
> > > >
> > >
> >
>

Re: Fortigate VNF template

[DeWayne Filppi]

So you'd agree that it should have required an explicit definition of the
inputs?

On Tue, Oct 10, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:

> Any help in debugging would be appreciated!
>
> On Tue, Oct 10, 2017 at 2:02 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > For reasons that somewhat mystify me, the template is installing with no
> > errors now.  I fixed it by removing the inputs definition I had in the
> > terminal.yaml file, which is counter-intuitive.  I used to have, in the
> > node type definition:
> >
> > interfaces:
> >   Standard:
> > create:
> >   implementation: cloudify-utilities-plugin >
> > cloudify_terminal.tasks.run
> >   inputs:
> > calls:
> >   type: list
> >   entry_schema: call_type
> >
> > I defined the inputs because I thought I had to.  This was the source of
> > the error I mentioned in another thread (regarding yaml-1.1).  In any
> case,
> > by commenting it out, I got no validation errors, and the terminal calls
> > are made as expected.  In the node template, I still pass inputs:
> >
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   calls:
> > - action: exit
> >
> > This doesn't seem as though it should be possible.  In any case, the
> latest
> > has been pushed to the repo:
> > https://github.com/dfilppi/fortigate-tosca-example
> >
> > DeWayne
> >
> > On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > For those interested, I'm in the process of implementing a TOSCA
> template
> > > for the initial deployment and configuration of a Fortigate VNF in
> > > Openstack.  It uses a couple of borrowed Cloudify plugins: one for
> > > Openstack itself (https://github.com/cloudify-
> cosmo/cloudify-openstack-
> > > plugin), and one for the terminal plugin (part of the Cloudify
> incubator
> > > "utilities" project (https://github.com/cloudify-
> > > incubator/cloudify-utilities-plugin).
> > >
> > > The basic idea is that a network and router is created with public
> > access,
> > > and a private network with no direct public access.  In between is the
> > > Fortigate firewall VNF that controls access to instances running on the
> > > private network.  The initial template just sets up the VNF and
> networks.
> > > The next template (TBD) will deploy a service on the private network
> and
> > > reconfigure the firewall to allow access via port forwarding.   This is
> > > very much a work in progress (the VNF configuration isn't quite working
> > > yet):
> > >
> > > https://github.com/dfilppi/fortigate-tosca-example
> > >
> >
>

Re: Fortigate VNF template

[DeWayne Filppi]

For reasons that somewhat mystify me, the template is installing with no
errors now.  I fixed it by removing the inputs definition I had in the
terminal.yaml file, which is counter-intuitive.  I used to have, in the
node type definition:

interfaces:
  Standard:
create:
  implementation: cloudify-utilities-plugin >
cloudify_terminal.tasks.run
  inputs:
calls:
  type: list
  entry_schema: call_type

I defined the inputs because I thought I had to.  This was the source of
the error I mentioned in another thread (regarding yaml-1.1).  In any case,
by commenting it out, I got no validation errors, and the terminal calls
are made as expected.  In the node template, I still pass inputs:

  interfaces:
Standard:
  create:
inputs:
  calls:
- action: exit

This doesn't seem as though it should be possible.  In any case, the latest
has been pushed to the repo:
https://github.com/dfilppi/fortigate-tosca-example

DeWayne

On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <dewa...@cloudify.co>
wrote:

> For those interested, I'm in the process of implementing a TOSCA template
> for the initial deployment and configuration of a Fortigate VNF in
> Openstack.  It uses a couple of borrowed Cloudify plugins: one for
> Openstack itself (https://github.com/cloudify-cosmo/cloudify-openstack-
> plugin), and one for the terminal plugin (part of the Cloudify incubator
> "utilities" project (https://github.com/cloudify-
> incubator/cloudify-utilities-plugin).
>
> The basic idea is that a network and router is created with public access,
> and a private network with no direct public access.  In between is the
> Fortigate firewall VNF that controls access to instances running on the
> private network.  The initial template just sets up the VNF and networks.
> The next template (TBD) will deploy a service on the private network and
> reconfigure the firewall to allow access via port forwarding.   This is
> very much a work in progress (the VNF configuration isn't quite working
> yet):
>
> https://github.com/dfilppi/fortigate-tosca-example
>

Re: stuck executions

[DeWayne Filppi]

Sure.  Can I update a table in the database or something to fix it?

On Tue, Oct 10, 2017 at 11:38 AM, Tal Liron <t...@cloudify.co> wrote:

> That's a good point. I would say there is a bug in "service delete -f".
> Could you open a bug in JIRA?
>
> On Tue, Oct 10, 2017 at 11:35 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I started an execution and then canceled it.  Now when I try to delete
> the
> > service (with -f) it fails to delete because the execution is in
> progress.
> > Any way to clean this up?
> >
> > DeWayne
> >
>

stuck executions

[DeWayne Filppi]

I started an execution and then canceled it.  Now when I try to delete the
service (with -f) it fails to delete because the execution is in progress.
Any way to clean this up?

DeWayne

Re: list of maps

[DeWayne Filppi]

ok good.  that what ive been using.  i know all keys its ok.

On Oct 10, 2017 11:22 AM, "Tal Liron" <t...@cloudify.co> wrote:

> No, sorry, copy-paste error. Correction
>
> data_types:
>   Element:
> properties:
>   a: { type: string, required: false }
>   c: { type: string, required: false }
>   e: { type: string, required: false }
>
> On Tue, Oct 10, 2017 at 11:15 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Really?  Two layers of properties?
> >
> > On Tue, Oct 10, 2017 at 11:10 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > You did not mention any error in this thread.
> > >
> > > The only other option I can think of is to define all the keys
> explicitly
> > > as not required. This means you need to know the possible keys in
> > advance.
> > > Example:
> > >
> > > data_types:
> > >   Element:
> > > properties:
> > >   data:
> > > properties:
> > >       a: { type: string, required: false }
> > >   c: { type: string, required: false }
> > >   e: { type: string, required: false }
> > >
> > > On Tue, Oct 10, 2017 at 11:06 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Doesn't quite do it.  The inability to describe this may be causing
> the
> > > > error I recently mentioned.
> > > >
> > > > I'm looking for:
> > > >
> > > > prop:
> > > >   - a: b
> > > >   - c: d
> > > >
> > > > *not*
> > > >
> > > > prop:
> > > >   - {data: {a:b}}
> > > >   - {data { c:d))
> > > >
> > > > The Cloudify plugin I'm trying to reuse requires the first form.
> > > >
> > > > DeWayne
> > > >
> > > > On Mon, Oct 9, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > It's an interesting problem, and the solution is clumsy due to the
> > odd
> > > > way
> > > > > TOSCA defines entry schema. I see no choice but to add an extra
> > nesting
> > > > > property. Something like this:
> > > > >
> > > > > data_types:
> > > > >   Element:
> > > > > properties:
> > > > >   data:
> > > > > type: map
> > > > > entry_schema: string
> > > > >
> > > > > node_types:
> > > > >   MyNode:
> > > > > properties:
> > > > >   my_property:
> > > > > type: list
> > > > > entry_schema: Element
> > > > >
> > > > > topology_template:
> > > > >   node_templates:
> > > > > my_node:
> > > > >   type: MyNode
> > > > >   properties:
> > > > > my_property:
> > > > >   - {data: {a: b}}
> > > > >   - {data: {c: d}}
> > > > >   - {data: {e: f, g: h, i: j}}
> > > > >
> > > > >
> > > > > On Fri, Oct 6, 2017 at 5:50 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > How would one define a property that was a list of maps, e.g.
> > > > > >
> > > > > > prop:
> > > > > >   -  a: b
> > > > > >   -  c: d
> > > > > >
> > > > > >
> > > > > > -- DeWayne
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: list of maps

[DeWayne Filppi]

Really?  Two layers of properties?

On Tue, Oct 10, 2017 at 11:10 AM, Tal Liron <t...@cloudify.co> wrote:

> You did not mention any error in this thread.
>
> The only other option I can think of is to define all the keys explicitly
> as not required. This means you need to know the possible keys in advance.
> Example:
>
> data_types:
>   Element:
> properties:
>   data:
> properties:
>   a: { type: string, required: false }
>   c: { type: string, required: false }
>   e: { type: string, required: false }
>
> On Tue, Oct 10, 2017 at 11:06 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Doesn't quite do it.  The inability to describe this may be causing the
> > error I recently mentioned.
> >
> > I'm looking for:
> >
> > prop:
> >   - a: b
> >   - c: d
> >
> > *not*
> >
> > prop:
> >   - {data: {a:b}}
> >   - {data { c:d))
> >
> > The Cloudify plugin I'm trying to reuse requires the first form.
> >
> > DeWayne
> >
> > On Mon, Oct 9, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > It's an interesting problem, and the solution is clumsy due to the odd
> > way
> > > TOSCA defines entry schema. I see no choice but to add an extra nesting
> > > property. Something like this:
> > >
> > > data_types:
> > >   Element:
> > > properties:
> > >   data:
> > > type: map
> > > entry_schema: string
> > >
> > > node_types:
> > >   MyNode:
> > > properties:
> > >   my_property:
> > > type: list
> > > entry_schema: Element
> > >
> > > topology_template:
> > >   node_templates:
> > > my_node:
> > >   type: MyNode
> > >   properties:
> > > my_property:
> > >   - {data: {a: b}}
> > >   - {data: {c: d}}
> > >   - {data: {e: f, g: h, i: j}}
> > >
> > >
> > > On Fri, Oct 6, 2017 at 5:50 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > How would one define a property that was a list of maps, e.g.
> > > >
> > > > prop:
> > > >   -  a: b
> > > >   -  c: d
> > > >
> > > >
> > > > -- DeWayne
> > > >
> > >
> >
>

Re: list of maps

[DeWayne Filppi]

Doesn't quite do it.  The inability to describe this may be causing the
error I recently mentioned.

I'm looking for:

prop:
  - a: b
  - c: d

*not*

prop:
  - {data: {a:b}}
  - {data { c:d))

The Cloudify plugin I'm trying to reuse requires the first form.

DeWayne

On Mon, Oct 9, 2017 at 9:00 AM, Tal Liron <t...@cloudify.co> wrote:

> It's an interesting problem, and the solution is clumsy due to the odd way
> TOSCA defines entry schema. I see no choice but to add an extra nesting
> property. Something like this:
>
> data_types:
>   Element:
> properties:
>   data:
> type: map
> entry_schema: string
>
> node_types:
>   MyNode:
> properties:
>   my_property:
> type: list
> entry_schema: Element
>
> topology_template:
>   node_templates:
> my_node:
>   type: MyNode
>   properties:
> my_property:
>   - {data: {a: b}}
>   - {data: {c: d}}
>   - {data: {e: f, g: h, i: j}}
>
>
> On Fri, Oct 6, 2017 at 5:50 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > How would one define a property that was a list of maps, e.g.
> >
> > prop:
> >   -  a: b
> >   -  c: d
> >
> >
> > -- DeWayne
> >
>

Re: Fortigate VNF template

[DeWayne Filppi]

Nope.

On Oct 10, 2017 10:50 AM, "Tal Liron" <t...@cloudify.co> wrote:

> Great! Is there anything stopping you from contributing this to the ARIA
> project when done?
>
> On Tue, Oct 10, 2017 at 10:37 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > For those interested, I'm in the process of implementing a TOSCA template
> > for the initial deployment and configuration of a Fortigate VNF in
> > Openstack.  It uses a couple of borrowed Cloudify plugins: one for
> > Openstack itself (
> > https://github.com/cloudify-cosmo/cloudify-openstack-plugin), and one
> for
> > the terminal plugin (part of the Cloudify incubator "utilities" project (
> > https://github.com/cloudify-incubator/cloudify-utilities-plugin).
> >
> > The basic idea is that a network and router is created with public
> access,
> > and a private network with no direct public access.  In between is the
> > Fortigate firewall VNF that controls access to instances running on the
> > private network.  The initial template just sets up the VNF and networks.
> > The next template (TBD) will deploy a service on the private network and
> > reconfigure the firewall to allow access via port forwarding.   This is
> > very much a work in progress (the VNF configuration isn't quite working
> > yet):
> >
> > https://github.com/dfilppi/fortigate-tosca-example
> >
>

Fortigate VNF template

[DeWayne Filppi]

For those interested, I'm in the process of implementing a TOSCA template
for the initial deployment and configuration of a Fortigate VNF in
Openstack.  It uses a couple of borrowed Cloudify plugins: one for
Openstack itself (
https://github.com/cloudify-cosmo/cloudify-openstack-plugin), and one for
the terminal plugin (part of the Cloudify incubator "utilities" project (
https://github.com/cloudify-incubator/cloudify-utilities-plugin).

The basic idea is that a network and router is created with public access,
and a private network with no direct public access.  In between is the
Fortigate firewall VNF that controls access to instances running on the
private network.  The initial template just sets up the VNF and networks.
The next template (TBD) will deploy a service on the private network and
reconfigure the firewall to allow access via port forwarding.   This is
very much a work in progress (the VNF configuration isn't quite working
yet):

https://github.com/dfilppi/fortigate-tosca-example

strange yaml-1.1 error

[DeWayne Filppi]

In the absence of any context (because reproducing this is very involved),
does the below error ring any bells?  I've seen it before, but don't recall
the fix.  This error pops up during an install workflow.  There seems to be
some kind of YAML problem, but it has already passed the parse/validation.

|  File
"/home/vagrant/incubator-ariatosca/aria/orchestrator/workflows/executor/process.py",
line 339, in _main
|aria.install_aria_extensions()
|  File "/home/vagrant/incubator-ariatosca/aria/__init__.py", line
66, in install_aria_extensions
|extension.init()
|  File "/home/vagrant/incubator-ariatosca/aria/extension.py", line
153, in init
|parser.init()
|  File "/home/vagrant/incubator-ariatosca/aria/extension.py", line
86, in init
|registrar.register(registrating_function)
|  File "/home/vagrant/incubator-ariatosca/aria/extension.py", line
37, in register
|raise RuntimeError('Re-definition of {0} in {1}'.format(key,
function.__name__))
|RuntimeError: Re-definition of yaml-1.1 in specification_url

list of maps

[DeWayne Filppi]

How would one define a property that was a list of maps, e.g.

prop:
  -  a: b
  -  c: d


-- DeWayne

Re: get_attribute not evaluating

[DeWayne Filppi]

0.2.0.   Makes sense.   I thought it odd that inputs could be arbitrary.

On Fri, Oct 6, 2017 at 11:08 AM, Tal Liron <t...@cloudify.co> wrote:

> I didn't want to confuse this issue before (it was about YAML anchors), but
> actually this whole service template should be invalid. This is a known bug
> in ARIA in which it allows this, when it actually shouldn't. Which version
> of ARIA are you using, by the way?
>
> Once this bug is fixed, ARIA should not be allow to add ad-hoc inputs at a
> node template. They are undeclared, un-typed, and thus not coerced behind
> the scenes. ARIA has no idea what to do with the "test" input and how to
> coerce it. Is it a dict? A list? A primitive type? It has no idea, so it
> just sends it as is, of course without any evaluation. (I'll repeat, this
> is a bug: the parser should not accept this at all so it would never get to
> orchestration).
>
> To do this correctly, declare a data type with that structure ("val" as one
> of its properties), then inherit the Standard interface and add an input of
> that data type, and finally inherit a new node type that overrides Standard
> to use that interface. I believe ARIA would then do the right thing.
>
>
>
> On Fri, Oct 6, 2017 at 12:56 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > The plot thickens maybe.  See below:
> >
> > 
> > test.yaml
> > 
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > imports:
> >   - aria-1.0
> >
> > node_types:
> >
> >   type_1:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   att1:
> > type: string
> > default: "a val"
> >
> > topology_template:
> >
> >   node_templates:
> >
> > node0:
> >   type: tosca.nodes.Root
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   test:
> > val: { get_attribute: [ node1, att1 ] }
> > implementation: test.sh
> >
> >   requirements:
> > - dependency: node1
> >
> > node1:
> >   type: type_1
> >
> >
> > ---
> >
> > "test" is delivered as {"val": {"get_attribute": ["node1", "att1"]}} to
> the
> > operation.   So basically, "get_attribute" is only evaluated  if it's not
> > nested.
> >
> > -- DeWayne
> >
> >
> > On Fri, Oct 6, 2017 at 10:02 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > I think this is as expected:
> > >
> > > macro: *macro->macro: { val: { get_attributes: [node1, att1] }
> }
> > >
> > > *macro->macro: { get_attributes: [node1, att1] }
> > >
> > >
> > > On Fri, Oct 6, 2017 at 11:50 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Actually, there is an oddity here.  See the simple template below:
> > > >
> > > > -
> > > > test.yaml
> > > > -
> > > >
> > > > imports:
> > > >   - aria-1.0
> > > >
> > > > node_types:
> > > >
> > > >   type_1:
> > > > derived_from: tosca.nodes.Root
> > > > attributes:
> > > >   att1:
> > > > type: string
> > > > default: "a val"
> > > >
> > > > dsl_definitions:
> > > >   macro: 
> > > > val: { get_attribute: [ node1, att1 ] }
> > > >
> > > > topology_template:
> > > >
> > > >   node_templates:
> > > >
> > > > node0:
> > > >   type: tosca.nodes.Root
> > > >   interfaces:
> > > > Standard:
> > > >   create:
> > > > inputs:
> > > >   macro: *macro
> > > > implementation: test.sh
> > > >
> > > >   requirements:
> > > > - dependency: node1
> > > >
> > > > node1:
> > > >   type: type_1
> > > > ---
> > > > test.sh
> > > > -------
> > > >
> > > > #

Re: get_attribute not evaluating

[DeWayne Filppi]

The plot thickens maybe.  See below:


test.yaml

tosca_definitions_version: tosca_simple_yaml_1_0

imports:
  - aria-1.0

node_types:

  type_1:
derived_from: tosca.nodes.Root
attributes:
  att1:
type: string
default: "a val"

topology_template:

  node_templates:

node0:
  type: tosca.nodes.Root
  interfaces:
Standard:
  create:
inputs:
  test:
val: { get_attribute: [ node1, att1 ] }
implementation: test.sh

  requirements:
- dependency: node1

node1:
  type: type_1


---

"test" is delivered as {"val": {"get_attribute": ["node1", "att1"]}} to the
operation.   So basically, "get_attribute" is only evaluated  if it's not
nested.

-- DeWayne


On Fri, Oct 6, 2017 at 10:02 AM, Tal Liron <t...@cloudify.co> wrote:

> I think this is as expected:
>
> macro: *macro->macro: { val: { get_attributes: [node1, att1] } }
>
> *macro    ->    macro: { get_attributes: [node1, att1] }
>
>
> On Fri, Oct 6, 2017 at 11:50 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Actually, there is an oddity here.  See the simple template below:
> >
> > -
> > test.yaml
> > -
> >
> > imports:
> >   - aria-1.0
> >
> > node_types:
> >
> >   type_1:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   att1:
> > type: string
> > default: "a val"
> >
> > dsl_definitions:
> >   macro: 
> > val: { get_attribute: [ node1, att1 ] }
> >
> > topology_template:
> >
> >   node_templates:
> >
> > node0:
> >   type: tosca.nodes.Root
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   macro: *macro
> > implementation: test.sh
> >
> >   requirements:
> > - dependency: node1
> >
> > node1:
> >   type: type_1
> > ---
> > test.sh
> > ---
> >
> > #!/bin/bash
> >
> > env > /tmp/env
> >
> > ---
> >
> > When running the install workflow on this, the /tmp/env file shows that
> the
> > environment variable "macro" contains the string {"val":
> {"get_attribute":
> > ["node1", "att1"]}}.
> >
> > This seems odd.  On the other hand, if you replace the "macro: *macro"
> line
> > with just '*macro', then the "val" environment variable contains "a val"
> as
> > you would expect.
> >
> > -- DeWayen
> >
> >
> > On Fri, Oct 6, 2017 at 9:22 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Thanks DeWayne, could you explain this in more detail? YAML macros are
> > > handled by the underlying YAML parser, not by the TOSCA parser on top
> of
> > > it, so we would really like to know if there's a bug somewhere. I did
> not
> > > understand from your explanation what works in Cloudify and not in
> ARIA.
> > >
> > > On Fri, Oct 6, 2017 at 10:25 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > For those interested, it appears that the "problem" described before
> > was
> > > > due to the inline macro definition in the "inputs" definition for the
> > > > create operation.  This odd syntax was the result of a translation
> > effort
> > > > from a Cloudify DSL blueprint (which apparently tolerates it).  If I
> > move
> > > > the macro definition up into "dsl_definitions", all appears to be
> well.
> > > >
> > > > -- DeWayne
> > > >
> > > > On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > DeWayne, as usual it's very hard for me to follow up on your
> > questions.
> > > > >
> > > > > Please provide more information. At the very least, what is the
> full
> > > > error
> > > > > you see? (I don't understand what "not evaluating" means.)
> > > > >
> > > > > Also, we need to reproduce this i

Re: get_attribute not evaluating

[DeWayne Filppi]

Perhaps.  It was copied directly from a working Cloudify blueprint, so I
wasn't sure.  Discovered it as part of a porting exercise from Cloudify DSL.

On Fri, Oct 6, 2017 at 10:02 AM, Tal Liron <t...@cloudify.co> wrote:

> I think this is as expected:
>
> macro: *macro->macro: { val: { get_attributes: [node1, att1] } }
>
> *macro->macro: { get_attributes: [node1, att1] }
>
>
> On Fri, Oct 6, 2017 at 11:50 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Actually, there is an oddity here.  See the simple template below:
> >
> > -
> > test.yaml
> > -
> >
> > imports:
> >   - aria-1.0
> >
> > node_types:
> >
> >   type_1:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   att1:
> > type: string
> > default: "a val"
> >
> > dsl_definitions:
> >   macro: 
> > val: { get_attribute: [ node1, att1 ] }
> >
> > topology_template:
> >
> >   node_templates:
> >
> > node0:
> >   type: tosca.nodes.Root
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   macro: *macro
> > implementation: test.sh
> >
> >   requirements:
> > - dependency: node1
> >
> > node1:
> >   type: type_1
> > ---
> > test.sh
> > ---
> >
> > #!/bin/bash
> >
> > env > /tmp/env
> >
> > ---
> >
> > When running the install workflow on this, the /tmp/env file shows that
> the
> > environment variable "macro" contains the string {"val":
> {"get_attribute":
> > ["node1", "att1"]}}.
> >
> > This seems odd.  On the other hand, if you replace the "macro: *macro"
> line
> > with just '*macro', then the "val" environment variable contains "a val"
> as
> > you would expect.
> >
> > -- DeWayen
> >
> >
> > On Fri, Oct 6, 2017 at 9:22 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Thanks DeWayne, could you explain this in more detail? YAML macros are
> > > handled by the underlying YAML parser, not by the TOSCA parser on top
> of
> > > it, so we would really like to know if there's a bug somewhere. I did
> not
> > > understand from your explanation what works in Cloudify and not in
> ARIA.
> > >
> > > On Fri, Oct 6, 2017 at 10:25 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > For those interested, it appears that the "problem" described before
> > was
> > > > due to the inline macro definition in the "inputs" definition for the
> > > > create operation.  This odd syntax was the result of a translation
> > effort
> > > > from a Cloudify DSL blueprint (which apparently tolerates it).  If I
> > move
> > > > the macro definition up into "dsl_definitions", all appears to be
> well.
> > > >
> > > > -- DeWayne
> > > >
> > > > On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > DeWayne, as usual it's very hard for me to follow up on your
> > questions.
> > > > >
> > > > > Please provide more information. At the very least, what is the
> full
> > > > error
> > > > > you see? (I don't understand what "not evaluating" means.)
> > > > >
> > > > > Also, we need to reproduce this in order the help. Either provide
> us
> > > > with a
> > > > > complete example that we can actually run, or -- much better -- a
> > > minimal
> > > > > example that can reproduce just this error.
> > > > >
> > > > > On Thu, Oct 5, 2017 at 6:56 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > I'm attempting evaluate 'get_attribute' in an operation input
> > clause
> > > > like
> > > > > > so:
> > > > > >
> > > > > > fortigate_vnf_baseline_config:
> > > > > >   type: aria.terminal.raw
> > > > > >   interfaces:
> > > > > > Standard:
> > > > > >   create:
> > > > > > inputs:
> > > > > >   terminal_auth: _auth
> > > > > > user: admin
> > > > > > password: ''
> > > > > > ip: { get_attribute: [ fortigate_ip,
> > > > floating_ip_address
> > > > > ]
> > > > > > }
> > > > > >
> > > > > > When I run the install workflow, the code that evaluates "ip"
> sees
> > > the
> > > > > > string literal "{ get_attribute: [ fortigate_ip,
> > floating_ip_address
> > > ]
> > > > > }".
> > > > > >
> > > > > > From the spec it seems this should evaluate fine.   This seems
> > pretty
> > > > > > basic, so it seems unlikely to be a bug.  Perhaps because it's
> in a
> > > > YAML
> > > > > > macro?
> > > > > >
> > > > > > -- DeWayne
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: get_attribute not evaluating

[DeWayne Filppi]

Actually, there is an oddity here.  See the simple template below:

-
test.yaml
-

imports:
  - aria-1.0

node_types:

  type_1:
derived_from: tosca.nodes.Root
attributes:
  att1:
type: string
default: "a val"

dsl_definitions:
  macro: 
val: { get_attribute: [ node1, att1 ] }

topology_template:

  node_templates:

node0:
  type: tosca.nodes.Root
  interfaces:
Standard:
  create:
inputs:
  macro: *macro
implementation: test.sh

  requirements:
- dependency: node1

node1:
  type: type_1
---
test.sh
---

#!/bin/bash

env > /tmp/env

---

When running the install workflow on this, the /tmp/env file shows that the
environment variable "macro" contains the string {"val": {"get_attribute":
["node1", "att1"]}}.

This seems odd.  On the other hand, if you replace the "macro: *macro" line
with just '*macro', then the "val" environment variable contains "a val" as
you would expect.

-- DeWayen


On Fri, Oct 6, 2017 at 9:22 AM, Tal Liron <t...@cloudify.co> wrote:

> Thanks DeWayne, could you explain this in more detail? YAML macros are
> handled by the underlying YAML parser, not by the TOSCA parser on top of
> it, so we would really like to know if there's a bug somewhere. I did not
> understand from your explanation what works in Cloudify and not in ARIA.
>
> On Fri, Oct 6, 2017 at 10:25 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > For those interested, it appears that the "problem" described before was
> > due to the inline macro definition in the "inputs" definition for the
> > create operation.  This odd syntax was the result of a translation effort
> > from a Cloudify DSL blueprint (which apparently tolerates it).  If I move
> > the macro definition up into "dsl_definitions", all appears to be well.
> >
> > -- DeWayne
> >
> > On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > DeWayne, as usual it's very hard for me to follow up on your questions.
> > >
> > > Please provide more information. At the very least, what is the full
> > error
> > > you see? (I don't understand what "not evaluating" means.)
> > >
> > > Also, we need to reproduce this in order the help. Either provide us
> > with a
> > > complete example that we can actually run, or -- much better -- a
> minimal
> > > example that can reproduce just this error.
> > >
> > > On Thu, Oct 5, 2017 at 6:56 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > I'm attempting evaluate 'get_attribute' in an operation input clause
> > like
> > > > so:
> > > >
> > > > fortigate_vnf_baseline_config:
> > > >   type: aria.terminal.raw
> > > >   interfaces:
> > > > Standard:
> > > >   create:
> > > > inputs:
> > > >   terminal_auth: _auth
> > > > user: admin
> > > > password: ''
> > > > ip: { get_attribute: [ fortigate_ip,
> > floating_ip_address
> > > ]
> > > > }
> > > >
> > > > When I run the install workflow, the code that evaluates "ip" sees
> the
> > > > string literal "{ get_attribute: [ fortigate_ip, floating_ip_address
> ]
> > > }".
> > > >
> > > > From the spec it seems this should evaluate fine.   This seems pretty
> > > > basic, so it seems unlikely to be a bug.  Perhaps because it's in a
> > YAML
> > > > macro?
> > > >
> > > > -- DeWayne
> > > >
> > >
> >
>

Re: get_attribute not evaluating

[DeWayne Filppi]

For those interested, it appears that the "problem" described before was
due to the inline macro definition in the "inputs" definition for the
create operation.  This odd syntax was the result of a translation effort
from a Cloudify DSL blueprint (which apparently tolerates it).  If I move
the macro definition up into "dsl_definitions", all appears to be well.

-- DeWayne

On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron <t...@cloudify.co> wrote:

> DeWayne, as usual it's very hard for me to follow up on your questions.
>
> Please provide more information. At the very least, what is the full error
> you see? (I don't understand what "not evaluating" means.)
>
> Also, we need to reproduce this in order the help. Either provide us with a
> complete example that we can actually run, or -- much better -- a minimal
> example that can reproduce just this error.
>
> On Thu, Oct 5, 2017 at 6:56 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I'm attempting evaluate 'get_attribute' in an operation input clause like
> > so:
> >
> > fortigate_vnf_baseline_config:
> >   type: aria.terminal.raw
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   terminal_auth: _auth
> > user: admin
> > password: ''
> > ip: { get_attribute: [ fortigate_ip, floating_ip_address
> ]
> > }
> >
> > When I run the install workflow, the code that evaluates "ip" sees the
> > string literal "{ get_attribute: [ fortigate_ip, floating_ip_address ]
> }".
> >
> > From the spec it seems this should evaluate fine.   This seems pretty
> > basic, so it seems unlikely to be a bug.  Perhaps because it's in a YAML
> > macro?
> >
> > -- DeWayne
> >
>

Re: get_attribute not evaluating

[DeWayne Filppi]

"Not evaluates" means I put a log statement in the python that uses "ip",
and the value is the "get_attribute" string.  I'll try to create a super
simple example.

On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron <t...@cloudify.co> wrote:

> DeWayne, as usual it's very hard for me to follow up on your questions.
>
> Please provide more information. At the very least, what is the full error
> you see? (I don't understand what "not evaluating" means.)
>
> Also, we need to reproduce this in order the help. Either provide us with a
> complete example that we can actually run, or -- much better -- a minimal
> example that can reproduce just this error.
>
> On Thu, Oct 5, 2017 at 6:56 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I'm attempting evaluate 'get_attribute' in an operation input clause like
> > so:
> >
> > fortigate_vnf_baseline_config:
> >   type: aria.terminal.raw
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   terminal_auth: _auth
> > user: admin
> > password: ''
> > ip: { get_attribute: [ fortigate_ip, floating_ip_address
> ]
> > }
> >
> > When I run the install workflow, the code that evaluates "ip" sees the
> > string literal "{ get_attribute: [ fortigate_ip, floating_ip_address ]
> }".
> >
> > From the spec it seems this should evaluate fine.   This seems pretty
> > basic, so it seems unlikely to be a bug.  Perhaps because it's in a YAML
> > macro?
> >
> > -- DeWayne
> >
>

get_attribute not evaluating

[DeWayne Filppi]

I'm attempting evaluate 'get_attribute' in an operation input clause like
so:

fortigate_vnf_baseline_config:
  type: aria.terminal.raw
  interfaces:
Standard:
  create:
inputs:
  terminal_auth: _auth
user: admin
password: ''
ip: { get_attribute: [ fortigate_ip, floating_ip_address ] }

When I run the install workflow, the code that evaluates "ip" sees the
string literal "{ get_attribute: [ fortigate_ip, floating_ip_address ] }".

>From the spec it seems this should evaluate fine.   This seems pretty
basic, so it seems unlikely to be a bug.  Perhaps because it's in a YAML
macro?

-- DeWayne

Re: Renaming the install and uninstall normative workflows

[DeWayne Filppi]

+1

On Tue, Oct 3, 2017 at 10:17 AM, Tal Liron  wrote:

> +1
>
> I don't see any reason why not to. Anybody have another opinion?
>
> On Tue, Oct 3, 2017 at 11:50 AM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > The YAML Profile 1.1 has officially named the normative workflows to be:
> > * deploy: is the workflow used to instantiate and perform the
> > initial deployment of the topology.
> > * undeploy: is the workflow used to remove all instances of a
> > topology.
> > I suggest we rename the current install/uninstall workflows in ARIA with
> > the new names.
> > What do you think?
> > Regards
> > Steve B
> >
> >
>

Re: Unique identification of an instance element across services

[DeWayne Filppi]

ly, 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 <tnad...@lucidvision.com>
> > wrote:
> >
> > >
> > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <t...@cloudify.co> 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 <
> dewa...@cloudify.co>
> > > > 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 <t...@cloudify.co> 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 m

Re: Unique identification of an instance element across services

[DeWayne Filppi]

I was also considering a "partial hash" concept like git.

On Fri, Sep 15, 2017 at 11:04 AM, Thomas Nadeau <tnad...@lucidvision.com>
wrote:

>
> > On Sep 15, 2017, at 1:53 PM, Tal Liron <t...@cloudify.co> 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 <dewa...@cloudify.co>
> > 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 <t...@cloudify.co> 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 you are
> >>> examining with the full name as seen above. I think having a separate
> UI
> >>> name such as "database_1", "database_2', etc., would be confusing.
> >>>
> >>> So, assuming the above, I imagine these kinds of configuration vars:
> >>>
> >>> instance.id_type = 'uuid' | 'alphanumeric' | 'base57' (default?) |
> >> 'serial'
> >>> node.id_max_length = 63
> >>>
> >>> Here are examples of the other types. Alphanumeric (25 characters):
> >>>
> >>> database_t5evps77wp5biqdb1oyw36956
> >>> database_uw5oa530kn9mu73lzjuech02a
> >>> database_nzv3a7umph0g1093abwq6qjd3
> >>>
> >>> And base57 (22 characters):
> >>>
> >>> database_g8KV4qpKep2J2uA473fv6X
> >>> database_M2bLkYsToZ52L3HSy7CCmC
> >>> database_q8se9o5fDDWvT53tnnRiXN
> >>>
> >>> My personal preference for the de

Re: Unique identification of an instance element across services

[DeWayne Filppi]

 multi-tenant scenarios.
> > >
> > > Do you have any update on when UUID will be considered in the roadmap?
> > > If its not too far, we would like to make our contribution to ARIA on
> > UUID.
> > >
> > > Looking forward to your response.
> > >
> > >
> > > Thanks,
> > >
> > > /Vaish
> > >
> > > 
> > > From: Avia Efrat <a...@cloudify.co>
> > > Sent: Sunday, July 30, 2017 10:35:45 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Unique identification of an instance element across
> services
> > >
> > > First, good arguments from both 'sides'.
> > >
> > > I am for at least adding a uuid as an option, as ARIA is intended to be
> > > used at scale as well.
> > > But currently, I am for the simple ids to be used as default (and not
> > > uuids). Like it or not, right now ARIA is more at a 'TOSCA playground'
> > > stage, and I think that's perfectly fine =)
> > > And at this stage, I think simple ids will be better, as they easier to
> > use
> > > via the CLI, but more importantly, don't clog the logs with long
> > > meaningless strings. As ARIA matures, we could switch the default to
> > UUIDs.
> > >
> > > And BTW, as our log format is configurable, there could be other ways
> > than
> > > UUIDs to distinguish between nodes with the 'same id' in a central
> > logging
> > > system, e.g using the user name as another indicator.
> > >
> > > On Thu, Jul 27, 2017 at 10:20 AM, Vaishnavi K.R <
> > > vaishnavi@ericsson.com>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > Thanks for the active discussion.
> > > >
> > > >
> > > > Having UUID at the node instance level will just make the nodes
> unique.
> > > >
> > > > And these names will not be used by the user directly as no
> operations
> > > are
> > > > happening on the node instance name.
> > > >
> > > > But at the service template and the service level, UUID will be of
> > great
> > > > help considering the multi user and multi tenancy situations.
> > > >
> > > >
> > > > So in a large scale perspective, the node names and the service
> > template
> > > > names have high probability of being same.
> > > >
> > > > When these enter into the automated world, it will create more
> problem
> > > > when name conflicts occur and its adds overhead to make changes every
> > > time
> > > > to overcome the conflict.
> > > >
> > > >
> > > > UUID at service template and the service level: will be of much use
> in
> > > the
> > > > above scenario and operations by user on these are less
> > > >
> > > > UUID at node instance level: makes the node much unique and no
> > operation
> > > > happens on it
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > /Vaish
> > > >
> > > > 
> > > > From: Tal Liron <t...@cloudify.co>
> > > > Sent: Wednesday, July 26, 2017 8:48:40 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: Unique identification of an instance element across
> > services
> > > >
> > > > I just don't see users having to deal much with node IDs outside of
> > > simple
> > > > hello-world style tutorials, and I'd hate for the first impressions
> > that
> > > > users get out of ARIA is that it's just a playground for TOSCA. It
> > should
> > > > be ready out-of-the-box for the real world.
> > > >
> > > > On Wed, Jul 26, 2017 at 9:13 AM, DeWayne Filppi <dewa...@cloudify.co
> >
> > > > wrote:
> > > >
> > > > > Such is their strength.  I'm just advocating using them as a last
> > > resort
> > > > > because they are user unfriendly and gigantic.
> > > > >
> > > > > On Tue, Jul 25, 2017 at 12:55 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > Let's consider a mass deployment: thousands of service instances
> of
> > > the
> > > > > > same service template, created by many different users with their
> > own
&

operation dependencies

[DeWayne Filppi]

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

[DeWayne Filppi]

Attached.  Note that I include a modified version of the plugin.yaml for
openstack that Aria uses by default (in the imports dir).  The change of
interest is in the   aria.openstack.datatypes.Server data type.

On Wed, Sep 6, 2017 at 4:03 PM, Tal Liron <t...@cloudify.co> wrote:

> You are allowed to add extra inputs at the node type, beyond what is
> defined in the interface type. You just can't do it at the node template.
>
> The error you get is odd. If you could share your complete work, perhaps we
> can run it and assist you. For me, at least, it's impossible to asses the
> situation without much more information.
>
> On Wed, Sep 6, 2017 at 5:54 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I was afraid you were going to say that.  I added a generic map as the
> > "server" property.  This passes the parse on template load.  When I
> > actually then try to use userdata, the install workflow dies in the aria
> > extension registration process, claiming : RuntimeError: Re-definition of
> > yaml-1.1 in specification_url.  If I don't actually set the userdata
> input
> > parameter, everything runs fine.  What's going on in extension
> registration
> > during the install workflow, that might cause this to happen?
> >
> > On Wed, Sep 6, 2017 at 3:43 PM, Ran Ziv <r...@cloudify.co> wrote:
> >
> > > In TOSCA, properties must have a well-defined schema, and as such it
> > means
> > > that the "server" property's datatype must be defined to have the
> > > "userdata" field for users to be able to use it through there.
> > >
> > > This is also true for operation inputs at this time, although AFAIK the
> > > spec does in fact allow for more freedom when it comes to passing
> > operation
> > > inputs which weren't defined in a schema - but we don't support that at
> > > this time.
> > >
> > >
> > > On Thu, Sep 7, 2017 at 1:08 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Rather than opening a potentially misguided PR, let me ask a simple
> > > > question whos answer may clear things up:  I want to use server
> > > "userdata"
> > > > using the Openstack plugin from ARIA.  The question is "how can I
> make
> > > that
> > > > happen?"
> > > >
> > > > On Wed, Sep 6, 2017 at 1:39 AM, Ran Ziv <r...@cloudify.co> wrote:
> > > >
> > > > > Well then, feel free to create an issue, and either submit the
> > smaller
> > > > fix,
> > > > > or create a PR which goes beyond this as you say :)
> > > > >
> > > > >
> > > > > On Tue, Sep 5, 2017 at 6:52 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > Yes, I believe you've got the idea.  The original "server" arg is
> > > > defined
> > > > > > as a map/dict.  TOSCA of course requires something somewhat more
> > > > > explicit.
> > > > > > I'm working around it by adding the following to Server datatype:
> > > > > >
> > > > > >   aria.openstack.datatypes.Server:
> > > > > > description: >-
> > > > > >   openstack Server args.
> > > > > > properties:
> > > > > >   server:
> > > > > > type: map
> > > > > > required: false
> > > > > > entry_schema:
> > > > > >   type: string
> > > > > >   security_groups:
> > > > > > type: list
> > > > > > entry_schema: string
> > > > > > required: false
> > > > > >   availability_zone:
> > > > > > type: string
> > > > > > required: false
> > > > > >
> > > > > > I have my own copy of the plugin.yaml file that I'm making
> changes
> > to
> > > > so
> > > > > > things will work for me, so this is fine.  I think the PR needs
> to
> > go
> > > > > > beyond this, and ensure that all potential parameters are
> defined (
> > > or
> > > > at
> > > > > > least the parameters that the Openstack plugin recognizes).
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, Sep

Re: openstack plugin

[DeWayne Filppi]

I was afraid you were going to say that.  I added a generic map as the
"server" property.  This passes the parse on template load.  When I
actually then try to use userdata, the install workflow dies in the aria
extension registration process, claiming : RuntimeError: Re-definition of
yaml-1.1 in specification_url.  If I don't actually set the userdata input
parameter, everything runs fine.  What's going on in extension registration
during the install workflow, that might cause this to happen?

On Wed, Sep 6, 2017 at 3:43 PM, Ran Ziv <r...@cloudify.co> wrote:

> In TOSCA, properties must have a well-defined schema, and as such it means
> that the "server" property's datatype must be defined to have the
> "userdata" field for users to be able to use it through there.
>
> This is also true for operation inputs at this time, although AFAIK the
> spec does in fact allow for more freedom when it comes to passing operation
> inputs which weren't defined in a schema - but we don't support that at
> this time.
>
>
> On Thu, Sep 7, 2017 at 1:08 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Rather than opening a potentially misguided PR, let me ask a simple
> > question whos answer may clear things up:  I want to use server
> "userdata"
> > using the Openstack plugin from ARIA.  The question is "how can I make
> that
> > happen?"
> >
> > On Wed, Sep 6, 2017 at 1:39 AM, Ran Ziv <r...@cloudify.co> wrote:
> >
> > > Well then, feel free to create an issue, and either submit the smaller
> > fix,
> > > or create a PR which goes beyond this as you say :)
> > >
> > >
> > > On Tue, Sep 5, 2017 at 6:52 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Yes, I believe you've got the idea.  The original "server" arg is
> > defined
> > > > as a map/dict.  TOSCA of course requires something somewhat more
> > > explicit.
> > > > I'm working around it by adding the following to Server datatype:
> > > >
> > > >   aria.openstack.datatypes.Server:
> > > > description: >-
> > > >   openstack Server args.
> > > > properties:
> > > >   server:
> > > > type: map
> > > > required: false
> > > > entry_schema:
> > > >   type: string
> > > >   security_groups:
> > > > type: list
> > > > entry_schema: string
> > > > required: false
> > > >   availability_zone:
> > > > type: string
> > > > required: false
> > > >
> > > > I have my own copy of the plugin.yaml file that I'm making changes to
> > so
> > > > things will work for me, so this is fine.  I think the PR needs to go
> > > > beyond this, and ensure that all potential parameters are defined (
> or
> > at
> > > > least the parameters that the Openstack plugin recognizes).
> > > >
> > > >
> > > >
> > > > On Sun, Sep 3, 2017 at 12:26 AM, Ran Ziv <r...@cloudify.co> wrote:
> > > >
> > > > > Could you link to the relevant place?
> > > > > Do you mean that in the original plugin.yaml you could set the
> > userdata
> > > > > field (under properties? under the "server" property? args?) but
> only
> > > due
> > > > > to it not having had to be declared explicitly?
> > > > > There's a good chance that if this were possible than it simply got
> > > > omitted
> > > > > during translation by mistake.
> > > > > Feel free to create a PR and add that.
> > > > >
> > > > > As a workaround, I assume you can simply inherit the type.
> > > > >
> > > > >
> > > > > On Sat, Sep 2, 2017 at 7:02 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > The openstack plugin.yaml replacement doesn't permit userdata.
> > > Unlike
> > > > > the
> > > > > > regular plugin.yaml, the args contents are specifically defined,
> > and
> > > > that
> > > > > > definition excludes userdata.  Is this a problem or is there some
> > > kind
> > > > of
> > > > > > workaround?
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: openstack plugin

[DeWayne Filppi]

Rather than opening a potentially misguided PR, let me ask a simple
question whos answer may clear things up:  I want to use server "userdata"
using the Openstack plugin from ARIA.  The question is "how can I make that
happen?"

On Wed, Sep 6, 2017 at 1:39 AM, Ran Ziv <r...@cloudify.co> wrote:

> Well then, feel free to create an issue, and either submit the smaller fix,
> or create a PR which goes beyond this as you say :)
>
>
> On Tue, Sep 5, 2017 at 6:52 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Yes, I believe you've got the idea.  The original "server" arg is defined
> > as a map/dict.  TOSCA of course requires something somewhat more
> explicit.
> > I'm working around it by adding the following to Server datatype:
> >
> >   aria.openstack.datatypes.Server:
> > description: >-
> >   openstack Server args.
> > properties:
> >   server:
> > type: map
> > required: false
> > entry_schema:
> >   type: string
> >   security_groups:
> > type: list
> > entry_schema: string
> > required: false
> >   availability_zone:
> > type: string
> > required: false
> >
> > I have my own copy of the plugin.yaml file that I'm making changes to so
> > things will work for me, so this is fine.  I think the PR needs to go
> > beyond this, and ensure that all potential parameters are defined ( or at
> > least the parameters that the Openstack plugin recognizes).
> >
> >
> >
> > On Sun, Sep 3, 2017 at 12:26 AM, Ran Ziv <r...@cloudify.co> wrote:
> >
> > > Could you link to the relevant place?
> > > Do you mean that in the original plugin.yaml you could set the userdata
> > > field (under properties? under the "server" property? args?) but only
> due
> > > to it not having had to be declared explicitly?
> > > There's a good chance that if this were possible than it simply got
> > omitted
> > > during translation by mistake.
> > > Feel free to create a PR and add that.
> > >
> > > As a workaround, I assume you can simply inherit the type.
> > >
> > >
> > > On Sat, Sep 2, 2017 at 7:02 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > The openstack plugin.yaml replacement doesn't permit userdata.
> Unlike
> > > the
> > > > regular plugin.yaml, the args contents are specifically defined, and
> > that
> > > > definition excludes userdata.  Is this a problem or is there some
> kind
> > of
> > > > workaround?
> > > >
> > >
> >
>

Re: error after adding "userdata" or "user_data" to plugin.yaml

[DeWayne Filppi]

I have no idea if its a bug.  Just seeing if it looked familiar to anyone.
Thought that error message might ring a bell.

On Sep 5, 2017 10:33 PM, "Tal Liron" <t...@cloudify.co> wrote:

> Are you reporting a bug here? It would really help to get a complete
> example with instructions to reproduce.
>
> On Tue, Sep 5, 2017 at 7:07 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > After adding the highlighted content to the ARIA openstack plugin.yaml,
> >
> >   aria.openstack.datatypes.Server:
> > description: >-
> >   openstack Server args.
> > properties:
> >   server:
> > type: map
> > required: false
> > entry_schema:
> >   type: string
> >
> > I get the following error trying to use user_data in a template:
> >
> > RuntimeError: Re-definition of yaml-1.1 in specification_url
> >
> > Usage looks like:
> >
> >   openstack_config: { get_input: openstack_config }
> >   args:
> > server:
> >   user_data: |
> > #!/bin/sh
> > echo TEST > /tmp/out
> >
>

error after adding "userdata" or "user_data" to plugin.yaml

[DeWayne Filppi]

After adding the highlighted content to the ARIA openstack plugin.yaml,

  aria.openstack.datatypes.Server:
description: >-
  openstack Server args.
properties:
  server:
type: map
required: false
entry_schema:
  type: string

I get the following error trying to use user_data in a template:

RuntimeError: Re-definition of yaml-1.1 in specification_url

Usage looks like:

  openstack_config: { get_input: openstack_config }
  args:
server:
  user_data: |
#!/bin/sh
echo TEST > /tmp/out

Re: openstack plugin

[DeWayne Filppi]

Yes, I believe you've got the idea.  The original "server" arg is defined
as a map/dict.  TOSCA of course requires something somewhat more explicit.
I'm working around it by adding the following to Server datatype:

  aria.openstack.datatypes.Server:
description: >-
  openstack Server args.
properties:
  server:
type: map
required: false
entry_schema:
  type: string
  security_groups:
type: list
entry_schema: string
required: false
  availability_zone:
type: string
required: false

I have my own copy of the plugin.yaml file that I'm making changes to so
things will work for me, so this is fine.  I think the PR needs to go
beyond this, and ensure that all potential parameters are defined ( or at
least the parameters that the Openstack plugin recognizes).



On Sun, Sep 3, 2017 at 12:26 AM, Ran Ziv <r...@cloudify.co> wrote:

> Could you link to the relevant place?
> Do you mean that in the original plugin.yaml you could set the userdata
> field (under properties? under the "server" property? args?) but only due
> to it not having had to be declared explicitly?
> There's a good chance that if this were possible than it simply got omitted
> during translation by mistake.
> Feel free to create a PR and add that.
>
> As a workaround, I assume you can simply inherit the type.
>
>
> On Sat, Sep 2, 2017 at 7:02 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > The openstack plugin.yaml replacement doesn't permit userdata.  Unlike
> the
> > regular plugin.yaml, the args contents are specifically defined, and that
> > definition excludes userdata.  Is this a problem or is there some kind of
> > workaround?
> >
>

Re: server create problem

[DeWayne Filppi]

Alas, no change:

04:05:57 | I | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | EXCEPTION: 'Client'
object has no attribute 'images'

Seems unrelated to ARIA.


On Fri, Sep 1, 2017 at 2:28 AM, Ran Ziv <r...@cloudify.co> wrote:

> Shouldn't the Nova client actually have an "images" attribute?
>
> The plugin was tested in its 2.0.1 version, as can be seen on the README
> here:
> https://github.com/cloudify-cosmo/aria-extension-cloudify
>
> Here's the plugin code diff between now (~2.2.0) and then:
> https://github.com/cloudify-cosmo/cloudify-openstack-
> plugin/compare/2.0.1-devel...master
>
> Can't really say I see anything that would cause this, but perhaps you
> should indeed try working with a 2.0.1 wagon.
> If that works let us know and we could possibly amend the plugin adapter if
> needed.
>
>
>
> On Fri, Sep 1, 2017 at 5:41 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I dug down quite a bit, and see that in openstack_plugin_common.__init__
> > in
> > the cosmo_list method of the NovaClientWithSugar class, I wrapped a call
> to
> > getattr with a try:except and see.
> >
> > 02:22:47 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} |
> COSMO_EXCEPTION='Client'
> > object has no attribute 'images'
> >
> > Maybe somebody who wrote this logic can help. Basically, the logic take
> the
> > 'image' property, makes it plural, and then tries to find it in the
> client
> > class.  It doesn't find it and it blows up.  Maybe I've got a bad version
> > of the openstack plugin:  2.2.0
> >
> >
> > On Thu, Aug 31, 2017 at 12:53 AM, Ran Ziv <r...@cloudify.co> wrote:
> >
> > > Is this everything?
> > > It seems like this never reached the actual API call telling Nova to
> > create
> > > a server, but rather failed in the section where image/flavor, keypair,
> > > security groups and nics are configured for the server
> > > ( see
> > > https://github.com/cloudify-cosmo/cloudify-openstack-
> > > plugin/blob/master/nova_plugin/server.py#L282
> > > )
> > >
> > > Unfortunately it seems like the trace from the plugin code hasn't
> reached
> > > the execution logs somehow (possibly something we've missed in the
> plugin
> > > adapter?), so I can't really say what's the exact problem.
> > > It should be fairly simple to debug though - the plugin code should be
> > > extracted inside your ~/.aria/plugins dir, so you can easily debug the
> > > plugin code while it's running and find the real problem as it happens.
> > >
> > >
> > > On Wed, Aug 30, 2017 at 7:28 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > The log:
> > > >
> > > > Starting execution. Press Ctrl+C cancel
> > > > 16:13:43 | I | neutron_plugin.router.create | {u'args':
> OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> > > Standard.create
> > > > started...
> > > > 16:13:44 | I | neutron_plugin.network.create | {u'args':
> OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > > > Standard.create
> > > > started...
> > > > 16:13:44 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > > > Standard.create
> > > > started...
> > > > 16:13:51 | I | neutron_plugin.network.create | {u'args':
> OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > > > Standard.create
> > >

Re: server create problem

[DeWayne Filppi]

I would imagine.  In any case, I'll try 2.0.1.  Another a related front, I
notice that 'aria plugins' provides no way to remove plugins.

On Fri, Sep 1, 2017 at 2:28 AM, Ran Ziv <r...@cloudify.co> wrote:

> Shouldn't the Nova client actually have an "images" attribute?
>
> The plugin was tested in its 2.0.1 version, as can be seen on the README
> here:
> https://github.com/cloudify-cosmo/aria-extension-cloudify
>
> Here's the plugin code diff between now (~2.2.0) and then:
> https://github.com/cloudify-cosmo/cloudify-openstack-
> plugin/compare/2.0.1-devel...master
>
> Can't really say I see anything that would cause this, but perhaps you
> should indeed try working with a 2.0.1 wagon.
> If that works let us know and we could possibly amend the plugin adapter if
> needed.
>
>
>
> On Fri, Sep 1, 2017 at 5:41 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I dug down quite a bit, and see that in openstack_plugin_common.__init__
> > in
> > the cosmo_list method of the NovaClientWithSugar class, I wrapped a call
> to
> > getattr with a try:except and see.
> >
> > 02:22:47 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} |
> COSMO_EXCEPTION='Client'
> > object has no attribute 'images'
> >
> > Maybe somebody who wrote this logic can help. Basically, the logic take
> the
> > 'image' property, makes it plural, and then tries to find it in the
> client
> > class.  It doesn't find it and it blows up.  Maybe I've got a bad version
> > of the openstack plugin:  2.2.0
> >
> >
> > On Thu, Aug 31, 2017 at 12:53 AM, Ran Ziv <r...@cloudify.co> wrote:
> >
> > > Is this everything?
> > > It seems like this never reached the actual API call telling Nova to
> > create
> > > a server, but rather failed in the section where image/flavor, keypair,
> > > security groups and nics are configured for the server
> > > ( see
> > > https://github.com/cloudify-cosmo/cloudify-openstack-
> > > plugin/blob/master/nova_plugin/server.py#L282
> > > )
> > >
> > > Unfortunately it seems like the trace from the plugin code hasn't
> reached
> > > the execution logs somehow (possibly something we've missed in the
> plugin
> > > adapter?), so I can't really say what's the exact problem.
> > > It should be fairly simple to debug though - the plugin code should be
> > > extracted inside your ~/.aria/plugins dir, so you can easily debug the
> > > plugin code while it's running and find the real problem as it happens.
> > >
> > >
> > > On Wed, Aug 30, 2017 at 7:28 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > The log:
> > > >
> > > > Starting execution. Press Ctrl+C cancel
> > > > 16:13:43 | I | neutron_plugin.router.create | {u'args':
> OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> > > Standard.create
> > > > started...
> > > > 16:13:44 | I | neutron_plugin.network.create | {u'args':
> OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > > > Standard.create
> > > > started...
> > > > 16:13:44 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > > > Standard.create
> > > > started...
> > > > 16:13:51 | I | neutron_plugin.network.create | {u'args':
> OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > > > Standard.create
> > > > successful
> > > > 16:13:51 | D | None | {} | network_1 Standard.configure has no
> > > > implementation
> > > > 16:13:51 | D | None 

Re: server create problem

[DeWayne Filppi]

I dug down quite a bit, and see that in openstack_plugin_common.__init__ in
the cosmo_list method of the NovaClientWithSugar class, I wrapped a call to
getattr with a try:except and see.

02:22:47 | I | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | COSMO_EXCEPTION='Client'
object has no attribute 'images'

Maybe somebody who wrote this logic can help. Basically, the logic take the
'image' property, makes it plural, and then tries to find it in the client
class.  It doesn't find it and it blows up.  Maybe I've got a bad version
of the openstack plugin:  2.2.0


On Thu, Aug 31, 2017 at 12:53 AM, Ran Ziv <r...@cloudify.co> wrote:

> Is this everything?
> It seems like this never reached the actual API call telling Nova to create
> a server, but rather failed in the section where image/flavor, keypair,
> security groups and nics are configured for the server
> ( see
> https://github.com/cloudify-cosmo/cloudify-openstack-
> plugin/blob/master/nova_plugin/server.py#L282
> )
>
> Unfortunately it seems like the trace from the plugin code hasn't reached
> the execution logs somehow (possibly something we've missed in the plugin
> adapter?), so I can't really say what's the exact problem.
> It should be fairly simple to debug though - the plugin code should be
> extracted inside your ~/.aria/plugins dir, so you can easily debug the
> plugin code while it's running and find the real problem as it happens.
>
>
> On Wed, Aug 30, 2017 at 7:28 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > The log:
> >
> > Starting execution. Press Ctrl+C cancel
> > 16:13:43 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> Standard.create
> > started...
> > 16:13:44 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > Standard.create
> > started...
> > 16:13:44 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > Standard.create
> > started...
> > 16:13:51 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > Standard.create
> > successful
> > 16:13:51 | D | None | {} | network_1 Standard.configure has no
> > implementation
> > 16:13:51 | D | None | {} | network_1 Standard.start has no implementation
> > 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | Using external
> resource
> > keypair: dfilppi-rs
> > 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > Standard.create
> > successful
> > 16:13:52 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> Standard.create
> > successful
> > 16:13:53 | D | None | {} | router_1 Standard.configure has no
> > implementation
> > 16:13:53 | D | None | {} | keypair_1 Standard.configure has no
> > implementation
> > 16:13:53 | D | None | {} | router_1 Standard.start has no implementation
> > 16:13:54 | D | None | {} | keypair_1 Standard.start has no implementation
> > 16:13:57 | I | neutron_plugin.subnet.create | {u'args':
> > OrderedDict([('cidr', u'172.16.0.0/16'), ('ip_version', 4)]),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > https://rackspace-a

Re: server create problem

[DeWayne Filppi]

22 | D | None | {} | port_1 Standard.configure has no implementation
16:14:22 | D | None | {} | port_1->subnet_1 Configure.post_configure_target
has no implementation
16:14:22 | D | None | {} | port_1->subnet_1 Configure.post_configure_source
has no implementation
16:14:23 | D | None | {} | port_1 Standard.start has no implementation
16:14:23 | D | None | {} | port_1->subnet_1 Configure.add_source has no
implementation
16:14:23 | D | None | {} | port_1->subnet_1 Configure.add_target has no
implementation
16:14:29 | I | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'xxx', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
started...
16:14:32 | D | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'xxx', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | Instance relationship
target instances: [{u'external_name': u'dfilppi-rs', u'tosca_name':
u'keypair', u'state': u'initial', u'tosca_id': 'keypair_1', u'external_id':
u'dfilppi-rs', u'external_type': 'keypair'}, {u'external_name':
u'aria_helloworld_port', u'tosca_name': u'port', u'state': u'initial',
u'fixed_ip_address': u'172.16.0.5', u'tosca_id': 'port_1', u'mac_address':
u'fa:16:3e:76:9b:5f', u'external_id':
u'044a027b-1cdc-441b-b3fa-953818668f02', u'external_type': 'port'}]
16:14:32 | D | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'xxx', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | server.create() server
before transformations: {'meta': {}, 'name': u'aria_helloworld_vm'}
16:14:32 | E | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'xxx', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
failed
|Traceback (most recent call last):
|  File
"/home/vagrant/incubator-ariatosca/aria/orchestrator/workflows/executor/process.py",
line 342, in _main
|task_func(ctx=ctx, **operation_arguments)
|  File
"/home/vagrant/venv/lib/python2.7/site-packages/adapters/context_adapter.py",
line 434, in wrapper
|ctx.task.retry(str(e), retry_interval=e.retry_after)
|  File "/usr/lib64/python2.7/contextlib.py", line 36, in __exit__
|raise RuntimeError("generator didn't stop after throw()")
|RuntimeError: generator didn't stop after throw()


On Wed, Aug 30, 2017 at 4:52 AM, Ran Ziv <r...@cloudify.co> wrote:

> I can't really make sense of this error message.
> Could you copy paste the full execution logs when running with "-vvv"?
>
> The "openstack_config" property/input should have nothing to do with the
> image/flavor assignment - The former only affects the Openstack client
> configuration, while the latter is set for a specific API call.
>
>
>
> On Wed, Aug 30, 2017 at 2:38 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Here's the latest issue.  Got through all the networking config in my
> > template, but the server instance doesn't start.  Not sure if this is an
> > Openstack plugin issue, or Aria..  From the error message, it appears
> that
> > the image id and flavor don't even get into the call.  Note that I had to
> > explicitly set "openstack_config" in the operation inputs:
> >
> > 23:32:42 | E | nova_plugin.server.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
> > failed
> > |Traceback (most recent call last):
> > |  File
> > "/home/vagrant/incubator-ariatosca/aria/orchestrator/
> > workflows/executor/process.py",
> > line 342, in _main
> > |task_func(ctx=ctx, **operation_arguments)
> > |  File
> > "/home/vagrant/venv/lib/python2.7/site-packages/
> > adapters/context_adapter.py",
> > line 434, in wrapper
> > |ctx.task.retry(str(e), retry_interval=e.retry_after)
> > |  File "/usr/lib64/python2.7/contextlib.py", line 36, in
> __exit__
> > |raise RuntimeError("generator didn't stop after throw()")
> > |RuntimeError: generator didn't stop after throw()
> >
> > The node template:
> >
> > vm:
> >   type: aria.openstack.nodes.Server
> >   properties:
> > image: { get_input: image }
> > flavor: { get_input: flavor }
> > create_if_missing: true
> > resource_id: aria_helloworld_vm
> > management_network_name: aria_helloworld_network
> >   requirements:
> > - key_pair: keypair
> > - port: port
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   openstack_config: { get_input: openstack_config }
> >
>

Re: server create problem

[DeWayne Filppi]

I'll post the whole thing.  The diagnosis was just my guess based on the
log output.

On Wed, Aug 30, 2017 at 4:52 AM, Ran Ziv <r...@cloudify.co> wrote:

> I can't really make sense of this error message.
> Could you copy paste the full execution logs when running with "-vvv"?
>
> The "openstack_config" property/input should have nothing to do with the
> image/flavor assignment - The former only affects the Openstack client
> configuration, while the latter is set for a specific API call.
>
>
>
> On Wed, Aug 30, 2017 at 2:38 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Here's the latest issue.  Got through all the networking config in my
> > template, but the server instance doesn't start.  Not sure if this is an
> > Openstack plugin issue, or Aria..  From the error message, it appears
> that
> > the image id and flavor don't even get into the call.  Note that I had to
> > explicitly set "openstack_config" in the operation inputs:
> >
> > 23:32:42 | E | nova_plugin.server.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'xx', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
> > failed
> > |Traceback (most recent call last):
> > |  File
> > "/home/vagrant/incubator-ariatosca/aria/orchestrator/
> > workflows/executor/process.py",
> > line 342, in _main
> > |task_func(ctx=ctx, **operation_arguments)
> > |  File
> > "/home/vagrant/venv/lib/python2.7/site-packages/
> > adapters/context_adapter.py",
> > line 434, in wrapper
> > |ctx.task.retry(str(e), retry_interval=e.retry_after)
> > |  File "/usr/lib64/python2.7/contextlib.py", line 36, in
> __exit__
> > |raise RuntimeError("generator didn't stop after throw()")
> > |RuntimeError: generator didn't stop after throw()
> >
> > The node template:
> >
> > vm:
> >   type: aria.openstack.nodes.Server
> >   properties:
> > image: { get_input: image }
> > flavor: { get_input: flavor }
> > create_if_missing: true
> > resource_id: aria_helloworld_vm
> > management_network_name: aria_helloworld_network
> >   requirements:
> > - key_pair: keypair
> > - port: port
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   openstack_config: { get_input: openstack_config }
> >
>

server create problem

[DeWayne Filppi]

Here's the latest issue.  Got through all the networking config in my
template, but the server instance doesn't start.  Not sure if this is an
Openstack plugin issue, or Aria..  From the error message, it appears that
the image id and flavor don't even get into the call.  Note that I had to
explicitly set "openstack_config" in the operation inputs:

23:32:42 | E | nova_plugin.server.create | {u'args': OrderedDict(),
u'openstack_config': {'username': 'dewayne', 'tenant_name':
'dewayne-tenant', 'password': 'xx', 'auth_url': '
https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
failed
|Traceback (most recent call last):
|  File
"/home/vagrant/incubator-ariatosca/aria/orchestrator/workflows/executor/process.py",
line 342, in _main
|task_func(ctx=ctx, **operation_arguments)
|  File
"/home/vagrant/venv/lib/python2.7/site-packages/adapters/context_adapter.py",
line 434, in wrapper
|ctx.task.retry(str(e), retry_interval=e.retry_after)
|  File "/usr/lib64/python2.7/contextlib.py", line 36, in __exit__
|raise RuntimeError("generator didn't stop after throw()")
|RuntimeError: generator didn't stop after throw()

The node template:

vm:
  type: aria.openstack.nodes.Server
  properties:
image: { get_input: image }
flavor: { get_input: flavor }
create_if_missing: true
resource_id: aria_helloworld_vm
management_network_name: aria_helloworld_network
  requirements:
- key_pair: keypair
- port: port
  interfaces:
Standard:
  create:
inputs:
  openstack_config: { get_input: openstack_config }

Re: subnet connected to router

[DeWayne Filppi]

Simple really.  For a particular template that was using the Openstack
plugin, I was trying to set the "openstack_config" parameter in the inputs
for an interface operation.  Specifically, a Subnet node has a relationship
to a Router node, and the add_target operation was failing because the
supplied "openstack_config" input was being ignored.   More specifically,
the add_target operation below gets the default openstack_config (empty
strings):

subnet:
  type: aria.openstack.nodes.Subnet
  properties:
resource_id: aria_helloworld_subnet
create_if_missing: true
  interfaces:
Standard:
  create:
inputs:
  openstack_config: { get_input: openstack_config }
  requirements:
- gateway:
#- router:
node: router
relationship:
  type: aria.openstack.subnet_connected_to_router
  interfaces:
Configure:
  add_target:
inputs:
  openstack_config: { get_input: openstack_config }
- network: network


On Tue, Aug 29, 2017 at 2:43 AM, Ran Ziv <r...@cloudify.co> wrote:

> Can we re-state the problem at hand? It's been somewhat difficult to follow
> this thread.
>
>
> On Tue, Aug 29, 2017 at 3:45 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > Great! So, now let's think what makes your full Openstack example
> > different... I'm off for the day, will continue looking tomorrow.
> >
> > On Mon, Aug 28, 2017 at 7:43 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > It validated and seems correct via show -f.
> > >
> > >
> > > On Mon, Aug 28, 2017 at 5:31 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > > > OK, let's please go back to my simpler example on master. If that
> works
> > > for
> > > > you, we're on the same page and can try to reproduce the bug there.
> > > >
> > > > On Mon, Aug 28, 2017 at 7:23 PM, DeWayne Filppi <dewa...@cloudify.co
> >
> > > > wrote:
> > > >
> > > > > Hopefully.  Has nothing to do with the Openstack plugin.  My
> example
> > > had
> > > > no
> > > > > reference to it.  Just switched to master branch, and it had no
> > effect.
> > > > > The subnet node has a direct "node:" reference to the router node.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 3:52 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > As I said, if you're not using git master, you need to add a
> "node"
> > > > field
> > > > > > to the requirement to solve this error.
> > > > > >
> > > > > > If you must use the Openstack plugin, I can't help you much
> because
> > > I'm
> > > > > not
> > > > > > very familiar with it. Perhaps someone else on the list could
> > assist?
> > > > > >
> > > > > > But I have a feeling this is a higher-level issue, we just need
> to
> > be
> > > > > > patient and try to isolate it.
> > > > > >
> > > > > > On Mon, Aug 28, 2017 at 5:49 PM, DeWayne Filppi <
> > dewa...@cloudify.co
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Sent this before:
> > > > > > >
> > > > > > > I got this:
> > > > > > >
> > > > > > > Validation issues:
> > > > > > >   5: requirement "my_requirement" of node "my_node2_1" has no
> > > target
> > > > > node
> > > > > > > template
> > > > > > >
> > > > > > >
> > > > > > > I'm rushing because I need a workaround at least very soon.
> > > > > > >
> > > > > > > On Mon, Aug 28, 2017 at 3:46 PM, Tal Liron <t...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > DeWayne, please slow down. We need to be on the same page
> here.
> > > At
> > > > > the
> > > > > > > very
> > > > > > > > least we need to use the same versions of ARIA.
> > > > > > > >
> > > > > > > > Why couldn't you use my example?
> > > > > > > >
> > > > > > > > On Mon, Aug 28, 2017

Re: subnet connected to router

[DeWayne Filppi]

It validated and seems correct via show -f.


On Mon, Aug 28, 2017 at 5:31 PM, Tal Liron <t...@cloudify.co> wrote:

> OK, let's please go back to my simpler example on master. If that works for
> you, we're on the same page and can try to reproduce the bug there.
>
> On Mon, Aug 28, 2017 at 7:23 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Hopefully.  Has nothing to do with the Openstack plugin.  My example had
> no
> > reference to it.  Just switched to master branch, and it had no effect.
> > The subnet node has a direct "node:" reference to the router node.
> >
> > On Mon, Aug 28, 2017 at 3:52 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > As I said, if you're not using git master, you need to add a "node"
> field
> > > to the requirement to solve this error.
> > >
> > > If you must use the Openstack plugin, I can't help you much because I'm
> > not
> > > very familiar with it. Perhaps someone else on the list could assist?
> > >
> > > But I have a feeling this is a higher-level issue, we just need to be
> > > patient and try to isolate it.
> > >
> > > On Mon, Aug 28, 2017 at 5:49 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Sent this before:
> > > >
> > > > I got this:
> > > >
> > > > Validation issues:
> > > >   5: requirement "my_requirement" of node "my_node2_1" has no target
> > node
> > > > template
> > > >
> > > >
> > > > I'm rushing because I need a workaround at least very soon.
> > > >
> > > > On Mon, Aug 28, 2017 at 3:46 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > DeWayne, please slow down. We need to be on the same page here. At
> > the
> > > > very
> > > > > least we need to use the same versions of ARIA.
> > > > >
> > > > > Why couldn't you use my example?
> > > > >
> > > > > On Mon, Aug 28, 2017 at 5:38 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > Note that creating a subtype of Subnet had no effect.   Tried to
> > > force
> > > > > the
> > > > > > settings into a common subtype as a workaround, but had no luck.
> > > > > >
> > > > > > On Mon, Aug 28, 2017 at 2:31 PM, DeWayne Filppi <
> > dewa...@cloudify.co
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I couldn't use your example.  The one I just sent illustrates
> the
> > > > > problem
> > > > > > > and has no openstack dependency.  I just forgot to delete the
> > > import
> > > > > > > statement.
> > > > > > >
> > > > > > > On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > >> DeWayne, could please use the example I provided? I prefer to
> > > start
> > > > > with
> > > > > > >> something without Openstack or any other dependencies so we
> can
> > > > > isolate
> > > > > > >> the
> > > > > > >> bug precisely.
> > > > > > >>
> > > > > > >> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <
> > > > dewa...@cloudify.co>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > OK.  Here's the example with no dependencies.  Two nodes.
> > > > > > >> >
> > > > > > >> > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > imports:
> > > > > > >> >   -
> > > > > > >> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
> > > > > > >> > extension-cloudify/master/plugins/openstack/plugin.yaml
> > > > > > >> >   - aria-1.0
> > > > > > >> >
> > > > > > >> > dsl_definitions:
> > > > > > >> >   openstack_config: _config
> > > > > > >> > username: dewayn

Re: subnet connected to router

[DeWayne Filppi]

Hopefully.  Has nothing to do with the Openstack plugin.  My example had no
reference to it.  Just switched to master branch, and it had no effect.
The subnet node has a direct "node:" reference to the router node.

On Mon, Aug 28, 2017 at 3:52 PM, Tal Liron <t...@cloudify.co> wrote:

> As I said, if you're not using git master, you need to add a "node" field
> to the requirement to solve this error.
>
> If you must use the Openstack plugin, I can't help you much because I'm not
> very familiar with it. Perhaps someone else on the list could assist?
>
> But I have a feeling this is a higher-level issue, we just need to be
> patient and try to isolate it.
>
> On Mon, Aug 28, 2017 at 5:49 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Sent this before:
> >
> > I got this:
> >
> > Validation issues:
> >   5: requirement "my_requirement" of node "my_node2_1" has no target node
> > template
> >
> >
> > I'm rushing because I need a workaround at least very soon.
> >
> > On Mon, Aug 28, 2017 at 3:46 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > DeWayne, please slow down. We need to be on the same page here. At the
> > very
> > > least we need to use the same versions of ARIA.
> > >
> > > Why couldn't you use my example?
> > >
> > > On Mon, Aug 28, 2017 at 5:38 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Note that creating a subtype of Subnet had no effect.   Tried to
> force
> > > the
> > > > settings into a common subtype as a workaround, but had no luck.
> > > >
> > > > On Mon, Aug 28, 2017 at 2:31 PM, DeWayne Filppi <dewa...@cloudify.co
> >
> > > > wrote:
> > > >
> > > > > I couldn't use your example.  The one I just sent illustrates the
> > > problem
> > > > > and has no openstack dependency.  I just forgot to delete the
> import
> > > > > statement.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > >> DeWayne, could please use the example I provided? I prefer to
> start
> > > with
> > > > >> something without Openstack or any other dependencies so we can
> > > isolate
> > > > >> the
> > > > >> bug precisely.
> > > > >>
> > > > >> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <
> > dewa...@cloudify.co>
> > > > >> wrote:
> > > > >>
> > > > >> > OK.  Here's the example with no dependencies.  Two nodes.
> > > > >> >
> > > > >> > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > >> >
> > > > >> >
> > > > >> > imports:
> > > > >> >   -
> > > > >> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
> > > > >> > extension-cloudify/master/plugins/openstack/plugin.yaml
> > > > >> >   - aria-1.0
> > > > >> >
> > > > >> > dsl_definitions:
> > > > >> >   openstack_config: _config
> > > > >> > username: dewayne
> > > > >> >
> > > > >> > data_types:
> > > > >> >   config:
> > > > >> > properties:
> > > > >> >   username:
> > > > >> > type: string
> > > > >> > default: 'NOT SET'
> > > > >> >
> > > > >> > relationship_types:
> > > > >> >   subnet_connected_to_router:
> > > > >> > derived_from: ConnectsTo
> > > > >> > interfaces:
> > > > >> >   Configure:
> > > > >> > add_target:
> > > > >> >   implementation: connect.sh
> > > > >> >   inputs:
> > > > >> >   openstack_config:
> > > > >> > type: config
> > > > >> > required: true
> > > > >> > default: {}
> > > > >> >
> > > > >> > node_types:
> > > > >> >   router:
> > > > >> > derived_from: tosca.nodes.Root
> >

Re: subnet connected to router

[DeWayne Filppi]

OK. Git master is fine with me.  I'll see how that goes.

On Mon, Aug 28, 2017 at 3:52 PM, Tal Liron <t...@cloudify.co> wrote:

> As I said, if you're not using git master, you need to add a "node" field
> to the requirement to solve this error.
>
> If you must use the Openstack plugin, I can't help you much because I'm not
> very familiar with it. Perhaps someone else on the list could assist?
>
> But I have a feeling this is a higher-level issue, we just need to be
> patient and try to isolate it.
>
> On Mon, Aug 28, 2017 at 5:49 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Sent this before:
> >
> > I got this:
> >
> > Validation issues:
> >   5: requirement "my_requirement" of node "my_node2_1" has no target node
> > template
> >
> >
> > I'm rushing because I need a workaround at least very soon.
> >
> > On Mon, Aug 28, 2017 at 3:46 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > DeWayne, please slow down. We need to be on the same page here. At the
> > very
> > > least we need to use the same versions of ARIA.
> > >
> > > Why couldn't you use my example?
> > >
> > > On Mon, Aug 28, 2017 at 5:38 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Note that creating a subtype of Subnet had no effect.   Tried to
> force
> > > the
> > > > settings into a common subtype as a workaround, but had no luck.
> > > >
> > > > On Mon, Aug 28, 2017 at 2:31 PM, DeWayne Filppi <dewa...@cloudify.co
> >
> > > > wrote:
> > > >
> > > > > I couldn't use your example.  The one I just sent illustrates the
> > > problem
> > > > > and has no openstack dependency.  I just forgot to delete the
> import
> > > > > statement.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > >> DeWayne, could please use the example I provided? I prefer to
> start
> > > with
> > > > >> something without Openstack or any other dependencies so we can
> > > isolate
> > > > >> the
> > > > >> bug precisely.
> > > > >>
> > > > >> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <
> > dewa...@cloudify.co>
> > > > >> wrote:
> > > > >>
> > > > >> > OK.  Here's the example with no dependencies.  Two nodes.
> > > > >> >
> > > > >> > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > >> >
> > > > >> >
> > > > >> > imports:
> > > > >> >   -
> > > > >> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
> > > > >> > extension-cloudify/master/plugins/openstack/plugin.yaml
> > > > >> >   - aria-1.0
> > > > >> >
> > > > >> > dsl_definitions:
> > > > >> >   openstack_config: _config
> > > > >> > username: dewayne
> > > > >> >
> > > > >> > data_types:
> > > > >> >   config:
> > > > >> > properties:
> > > > >> >   username:
> > > > >> > type: string
> > > > >> > default: 'NOT SET'
> > > > >> >
> > > > >> > relationship_types:
> > > > >> >   subnet_connected_to_router:
> > > > >> > derived_from: ConnectsTo
> > > > >> > interfaces:
> > > > >> >   Configure:
> > > > >> > add_target:
> > > > >> >   implementation: connect.sh
> > > > >> >   inputs:
> > > > >> >   openstack_config:
> > > > >> > type: config
> > > > >> > required: true
> > > > >> > default: {}
> > > > >> >
> > > > >> > node_types:
> > > > >> >   router:
> > > > >> > derived_from: tosca.nodes.Root
> > > > >> >
> > > > >> >   subnet:
> > > > >> > derived_from: tosca.nodes.Root
> > > > >> > requiremen

Re: subnet connected to router

[DeWayne Filppi]

Sent this before:

I got this:

Validation issues:
  5: requirement "my_requirement" of node "my_node2_1" has no target node
template


I'm rushing because I need a workaround at least very soon.

On Mon, Aug 28, 2017 at 3:46 PM, Tal Liron <t...@cloudify.co> wrote:

> DeWayne, please slow down. We need to be on the same page here. At the very
> least we need to use the same versions of ARIA.
>
> Why couldn't you use my example?
>
> On Mon, Aug 28, 2017 at 5:38 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Note that creating a subtype of Subnet had no effect.   Tried to force
> the
> > settings into a common subtype as a workaround, but had no luck.
> >
> > On Mon, Aug 28, 2017 at 2:31 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > I couldn't use your example.  The one I just sent illustrates the
> problem
> > > and has no openstack dependency.  I just forgot to delete the import
> > > statement.
> > >
> > > On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > >> DeWayne, could please use the example I provided? I prefer to start
> with
> > >> something without Openstack or any other dependencies so we can
> isolate
> > >> the
> > >> bug precisely.
> > >>
> > >> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> > >> wrote:
> > >>
> > >> > OK.  Here's the example with no dependencies.  Two nodes.
> > >> >
> > >> > tosca_definitions_version: tosca_simple_yaml_1_0
> > >> >
> > >> >
> > >> > imports:
> > >> >   -
> > >> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
> > >> > extension-cloudify/master/plugins/openstack/plugin.yaml
> > >> >   - aria-1.0
> > >> >
> > >> > dsl_definitions:
> > >> >   openstack_config: _config
> > >> > username: dewayne
> > >> >
> > >> > data_types:
> > >> >   config:
> > >> > properties:
> > >> >   username:
> > >> > type: string
> > >> > default: 'NOT SET'
> > >> >
> > >> > relationship_types:
> > >> >   subnet_connected_to_router:
> > >> > derived_from: ConnectsTo
> > >> > interfaces:
> > >> >   Configure:
> > >> > add_target:
> > >> >   implementation: connect.sh
> > >> >   inputs:
> > >> >   openstack_config:
> > >> > type: config
> > >> > required: true
> > >> > default: {}
> > >> >
> > >> > node_types:
> > >> >   router:
> > >> > derived_from: tosca.nodes.Root
> > >> >
> > >> >   subnet:
> > >> > derived_from: tosca.nodes.Root
> > >> > requirements:
> > >> >   - router:
> > >> >   capability: tosca.capabilities.Node
> > >> >   relationship: subnet_connected_to_router
> > >> >
> > >> > topology_template:
> > >> >
> > >> >   node_templates:
> > >> >
> > >> > router:
> > >> >   type: router
> > >> >
> > >> > subnet:
> > >> >   type: subnet
> > >> >   requirements:
> > >> > - router:
> > >> > node: router
> > >> > relationship:
> > >> >   type: subnet_connected_to_router
> > >> >   interfaces:
> > >> > Configure:
> > >> >   add_target:
> > >> > inputs:
> > >> >   openstack_config: *openstack_config
> > >> >
> > >> >
> > >> > On Mon, Aug 28, 2017 at 1:14 PM, Tal Liron <t...@cloudify.co> wrote:
> > >> >
> > >> > > I'm again confused, DeWayne. Is the error with the example I
> > provided
> > >> > here?
> > >> > > Please let's start with this minimal example to make sure we're on
> > the
> > >> > same
> >

Re: subnet connected to router

[DeWayne Filppi]

Note that creating a subtype of Subnet had no effect.   Tried to force the
settings into a common subtype as a workaround, but had no luck.

On Mon, Aug 28, 2017 at 2:31 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> I couldn't use your example.  The one I just sent illustrates the problem
> and has no openstack dependency.  I just forgot to delete the import
> statement.
>
> On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> DeWayne, could please use the example I provided? I prefer to start with
>> something without Openstack or any other dependencies so we can isolate
>> the
>> bug precisely.
>>
>> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <dewa...@cloudify.co>
>> wrote:
>>
>> > OK.  Here's the example with no dependencies.  Two nodes.
>> >
>> > tosca_definitions_version: tosca_simple_yaml_1_0
>> >
>> >
>> > imports:
>> >   -
>> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
>> > extension-cloudify/master/plugins/openstack/plugin.yaml
>> >   - aria-1.0
>> >
>> > dsl_definitions:
>> >   openstack_config: _config
>> > username: dewayne
>> >
>> > data_types:
>> >   config:
>> > properties:
>> >   username:
>> > type: string
>> > default: 'NOT SET'
>> >
>> > relationship_types:
>> >   subnet_connected_to_router:
>> > derived_from: ConnectsTo
>> > interfaces:
>> >   Configure:
>> > add_target:
>> >   implementation: connect.sh
>> >   inputs:
>> >   openstack_config:
>> > type: config
>> > required: true
>> > default: {}
>> >
>> > node_types:
>> >   router:
>> > derived_from: tosca.nodes.Root
>> >
>> >   subnet:
>> > derived_from: tosca.nodes.Root
>> > requirements:
>> >   - router:
>> >   capability: tosca.capabilities.Node
>> >   relationship: subnet_connected_to_router
>> >
>> > topology_template:
>> >
>> >   node_templates:
>> >
>> > router:
>> >   type: router
>> >
>> > subnet:
>> >   type: subnet
>> >   requirements:
>> > - router:
>> > node: router
>> > relationship:
>> >   type: subnet_connected_to_router
>> >   interfaces:
>> > Configure:
>> >   add_target:
>> > inputs:
>> >   openstack_config: *openstack_config
>> >
>> >
>> > On Mon, Aug 28, 2017 at 1:14 PM, Tal Liron <t...@cloudify.co> wrote:
>> >
>> > > I'm again confused, DeWayne. Is the error with the example I provided
>> > here?
>> > > Please let's start with this minimal example to make sure we're on the
>> > same
>> > > page. If the example validates for you, we can try adding features to
>> try
>> > > to see what replicates the bug.
>> > >
>> > > On Mon, Aug 28, 2017 at 1:37 PM, DeWayne Filppi <dewa...@cloudify.co>
>> > > wrote:
>> > >
>> > > > Yeah, except my original example I sent *did* specify the node.
>> > > >
>> > > > On Mon, Aug 28, 2017 at 10:06 AM, Tal Liron <t...@cloudify.co>
>> wrote:
>> > > >
>> > > > > OK, so unfortunately you still have the bug. To workaround, you
>> have
>> > to
>> > > > > specify the "node" field explicitly for all requirements. Or you
>> can
>> > > use
>> > > > > git master for now.
>> > > > >
>> > > > > On Mon, Aug 28, 2017 at 11:58 AM, DeWayne Filppi <
>> > dewa...@cloudify.co>
>> > > > > wrote:
>> > > > >
>> > > > > > I'm on 0.1.1
>> > > > > >
>> > > > > > On Mon, Aug 28, 2017 at 9:48 AM, Tal Liron <t...@cloudify.co>
>> > wrote:
>> > > > > >
>> > > > > > > Hm, are you using a git snapshot or a release? This issue was
>> > fixed
>> > > > on
>> > > > > > git
>> > > > > > > but not released

Re: subnet connected to router

[DeWayne Filppi]

I couldn't use your example.  The one I just sent illustrates the problem
and has no openstack dependency.  I just forgot to delete the import
statement.

On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <t...@cloudify.co> wrote:

> DeWayne, could please use the example I provided? I prefer to start with
> something without Openstack or any other dependencies so we can isolate the
> bug precisely.
>
> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > OK.  Here's the example with no dependencies.  Two nodes.
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> >
> > imports:
> >   -
> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
> > extension-cloudify/master/plugins/openstack/plugin.yaml
> >   - aria-1.0
> >
> > dsl_definitions:
> >   openstack_config: _config
> > username: dewayne
> >
> > data_types:
> >   config:
> > properties:
> >   username:
> > type: string
> > default: 'NOT SET'
> >
> > relationship_types:
> >   subnet_connected_to_router:
> > derived_from: ConnectsTo
> > interfaces:
> >   Configure:
> > add_target:
> >   implementation: connect.sh
> >   inputs:
> >   openstack_config:
> > type: config
> > required: true
> > default: {}
> >
> > node_types:
> >   router:
> > derived_from: tosca.nodes.Root
> >
> >   subnet:
> > derived_from: tosca.nodes.Root
> > requirements:
> >   - router:
> >   capability: tosca.capabilities.Node
> >   relationship: subnet_connected_to_router
> >
> > topology_template:
> >
> >   node_templates:
> >
> > router:
> >   type: router
> >
> > subnet:
> >   type: subnet
> >   requirements:
> > - router:
> > node: router
> > relationship:
> >   type: subnet_connected_to_router
> >   interfaces:
> > Configure:
> >   add_target:
> > inputs:
> >   openstack_config: *openstack_config
> >
> >
> > On Mon, Aug 28, 2017 at 1:14 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > I'm again confused, DeWayne. Is the error with the example I provided
> > here?
> > > Please let's start with this minimal example to make sure we're on the
> > same
> > > page. If the example validates for you, we can try adding features to
> try
> > > to see what replicates the bug.
> > >
> > > On Mon, Aug 28, 2017 at 1:37 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Yeah, except my original example I sent *did* specify the node.
> > > >
> > > > On Mon, Aug 28, 2017 at 10:06 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > OK, so unfortunately you still have the bug. To workaround, you
> have
> > to
> > > > > specify the "node" field explicitly for all requirements. Or you
> can
> > > use
> > > > > git master for now.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 11:58 AM, DeWayne Filppi <
> > dewa...@cloudify.co>
> > > > > wrote:
> > > > >
> > > > > > I'm on 0.1.1
> > > > > >
> > > > > > On Mon, Aug 28, 2017 at 9:48 AM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > Hm, are you using a git snapshot or a release? This issue was
> > fixed
> > > > on
> > > > > > git
> > > > > > > but not released yet.
> > > > > > >
> > > > > > > On Fri, Aug 25, 2017 at 7:20 PM, DeWayne Filppi <
> > > dewa...@cloudify.co
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I got this:
> > > > > > > >
> > > > > > > > Validation issues:
> > > > > > > >   5: requirement "my_requirement" of node "my_node2_1" has no
> > > > target
> > > > > > node
> > > > > > > > template
> > > > > > > >

Re: subnet connected to router

[DeWayne Filppi]

OK.  Here's the example with no dependencies.  Two nodes.

tosca_definitions_version: tosca_simple_yaml_1_0


imports:
  -
https://raw.githubusercontent.com/cloudify-cosmo/aria-extension-cloudify/master/plugins/openstack/plugin.yaml
  - aria-1.0

dsl_definitions:
  openstack_config: _config
username: dewayne

data_types:
  config:
properties:
  username:
type: string
default: 'NOT SET'

relationship_types:
  subnet_connected_to_router:
derived_from: ConnectsTo
interfaces:
  Configure:
add_target:
  implementation: connect.sh
  inputs:
  openstack_config:
type: config
required: true
default: {}

node_types:
  router:
derived_from: tosca.nodes.Root

  subnet:
derived_from: tosca.nodes.Root
requirements:
  - router:
  capability: tosca.capabilities.Node
  relationship: subnet_connected_to_router

topology_template:

  node_templates:

router:
  type: router

subnet:
  type: subnet
  requirements:
- router:
node: router
relationship:
  type: subnet_connected_to_router
  interfaces:
Configure:
  add_target:
inputs:
  openstack_config: *openstack_config


On Mon, Aug 28, 2017 at 1:14 PM, Tal Liron <t...@cloudify.co> wrote:

> I'm again confused, DeWayne. Is the error with the example I provided here?
> Please let's start with this minimal example to make sure we're on the same
> page. If the example validates for you, we can try adding features to try
> to see what replicates the bug.
>
> On Mon, Aug 28, 2017 at 1:37 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Yeah, except my original example I sent *did* specify the node.
> >
> > On Mon, Aug 28, 2017 at 10:06 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > OK, so unfortunately you still have the bug. To workaround, you have to
> > > specify the "node" field explicitly for all requirements. Or you can
> use
> > > git master for now.
> > >
> > > On Mon, Aug 28, 2017 at 11:58 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > I'm on 0.1.1
> > > >
> > > > On Mon, Aug 28, 2017 at 9:48 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > Hm, are you using a git snapshot or a release? This issue was fixed
> > on
> > > > git
> > > > > but not released yet.
> > > > >
> > > > > On Fri, Aug 25, 2017 at 7:20 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > I got this:
> > > > > >
> > > > > > Validation issues:
> > > > > >   5: requirement "my_requirement" of node "my_node2_1" has no
> > target
> > > > node
> > > > > > template
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 25, 2017 at 3:42 PM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > OK. Now we're getting somewhere. I tried to create a more
> minimal
> > > > > example
> > > > > > > to reproduce this, but without success. My example correctly
> > > assigns
> > > > > the
> > > > > > > value when I run "aria services show -f". I wonder if it's a
> bug
> > > that
> > > > > was
> > > > > > > fixed somewhere or if there's something else going on in your
> > more
> > > > > > complex
> > > > > > > example.
> > > > > > >
> > > > > > > Could you try with the attached yaml?
> > > > > > >
> > > > > > > On Fri, Aug 25, 2017 at 5:33 PM, DeWayne Filppi <
> > > dewa...@cloudify.co
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Yeah:
> > > > > > >>
> > > > > > >>   Arguments:
> > > > > > >> process: {} (map)
> > > > > > >> Sub-process configuration.
> > > > > > >> script_path: 'connect.sh' (string)
> > > > > > >> Relative path to the executable file.
> > > > > > >> 

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[DeWayne Filppi]

gt; > backports.shutil-get-terminal-size, clint, colorama, wagon,
> > CacheControl,
> > > retrying, bottle, click, setuptools, networkx, shortuuid, Jinja2
> > >
> > > ==End Console output=
> > >
> > >
> > > Vish
> > >
> > >
> > > 
> > > From: Vishwanath Jayaraman <vishwana...@hotmail.com>
> > > Sent: Friday, August 25, 2017 11:20 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > "tosca:Root" in WebServer"
> > >
> > >
> > > Ran,
> > >
> > > On a fresh Ubuntu 16.04.3 LTS install, I followed the below steps
> > >
> > > 1  sudo apt-get update -y
> > > 2  sudo apt install -y python-pip git
> > > 3  sudo pip install --upgrade pip setuptools
> > > 4  sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
> > > 5  sudo pip install apache-ariatosca
> > > 6  sudo pip install apache-ariatosca[ssh]
> > > 7 ctx (console output message is "ctx: command not found")
> > >
> > > From the above steps, does it look like I could be missing something
> that
> > > is not installing the 'ctx' binary.
> > >
> > >
> > > Thanks
> > >
> > > Vish
> > >
> > >
> > > 
> > > From: Ran Ziv <r...@cloudify.co>
> > > Sent: Friday, August 25, 2017 4:43 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > "tosca:Root" in WebServer"
> > >
> > > Hi Vishwanath,
> > >
> > > Thanks for helping in updating the hello-world example readme. Sorry
> > about
> > > the lack of clarity there regarding the need to copy the template's
> > > resources as well.
> > >
> > > Regarding the ctx error, the ctx is a binary that should get installed
> in
> > > your environment when you install ARIA. It should not be installed
> > > separately.
> > > try reinstalling ARIA and running "ctx" from the shell - that should
> give
> > > you an error, but one from the "ctx" program, not one that such a
> program
> > > was not found.
> > >
> > >
> > > On Fri, Aug 25, 2017 at 4:40 AM, Vishwanath Jayaraman <
> > > vishwana...@hotmail.com> wrote:
> > >
> > > > For a first time user, its not apparent in the instructions at
> > > >
> > > > http://ariatosca.incubator.apache.org/getting-started/ that they may
> > > need
> > > > to copy the entire examples directory or clone the github repo, I
> will
> > go
> > > > ahead and open a JIRA to update the README.rst with those additional
> > > > details.
> > > >
> > > > Only issue pending at this time is "ctx: command not found" error.
> > Once,
> > > I
> > > > get a response on how that gets installed, I will include that in the
> > > > dependencies section.
> > > >
> > > >
> > > > Vish
> > > >
> > > >
> > > > 
> > > > From: DeWayne Filppi <dewa...@cloudify.co>
> > > > Sent: Thursday, August 24, 2017 1:28 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > > "tosca:Root" in WebServer"
> > > >
> > > > I'm running in a cloned github repo, so all is there.  On another
> > front,
> > > > the Aria port type for Openstack requires that every port have a
> > > > public/floating ip.
> > > >
> > > > On Thu, Aug 24, 2017 at 11:11 AM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > You need not just the helloworld YAML file, but also all the
> scripts
> > it
> > > > > references. Try copying the whole examples directory to make sure.
> > > > >
> > > > > We are planning to eventually display a validation error if the
> YAML
> > > file
> > > > > references artifacts that don't exist, so you wouldn't have to wait
> > > until
> > > > > execution to see the error. Th

Re: subnet connected to router

[DeWayne Filppi]

Yeah, except my original example I sent *did* specify the node.

On Mon, Aug 28, 2017 at 10:06 AM, Tal Liron <t...@cloudify.co> wrote:

> OK, so unfortunately you still have the bug. To workaround, you have to
> specify the "node" field explicitly for all requirements. Or you can use
> git master for now.
>
> On Mon, Aug 28, 2017 at 11:58 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I'm on 0.1.1
> >
> > On Mon, Aug 28, 2017 at 9:48 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Hm, are you using a git snapshot or a release? This issue was fixed on
> > git
> > > but not released yet.
> > >
> > > On Fri, Aug 25, 2017 at 7:20 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > I got this:
> > > >
> > > > Validation issues:
> > > >   5: requirement "my_requirement" of node "my_node2_1" has no target
> > node
> > > > template
> > > >
> > > >
> > > > On Fri, Aug 25, 2017 at 3:42 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > OK. Now we're getting somewhere. I tried to create a more minimal
> > > example
> > > > > to reproduce this, but without success. My example correctly
> assigns
> > > the
> > > > > value when I run "aria services show -f". I wonder if it's a bug
> that
> > > was
> > > > > fixed somewhere or if there's something else going on in your more
> > > > complex
> > > > > example.
> > > > >
> > > > > Could you try with the attached yaml?
> > > > >
> > > > > On Fri, Aug 25, 2017 at 5:33 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > >> Yeah:
> > > > >>
> > > > >>   Arguments:
> > > > >>     process: {} (map)
> > > > >> Sub-process configuration.
> > > > >> script_path: 'connect.sh' (string)
> > > > >> Relative path to the executable file.
> > > > >> openstack_config: {'username': 'NOT SET'} (map)
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Fri, Aug 25, 2017 at 3:31 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >>
> > > > >> > And you're saying that also in "aria services show -f" you see
> > that
> > > > it's
> > > > >> > NOT SET?
> > > > >> >
> > > > >> > On Fri, Aug 25, 2017 at 5:29 PM, DeWayne Filppi <
> > > dewa...@cloudify.co>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Never mind, figured it out from the code.  Here's the
> simplified
> > > > >> > template:
> > > > >> > >
> > > > >> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > >> > >
> > > > >> > >
> > > > >> > > imports:
> > > > >> > >   - aria-1.0
> > > > >> > >
> > > > >> > > dsl_definitions:
> > > > >> > >   openstack_config: _config
> > > > >> > > username: dewayne
> > > > >> > >
> > > > >> > > data_types:
> > > > >> > >   config:
> > > > >> > > properties:
> > > > >> > >   username:
> > > > >> > > type: string
> > > > >> > > default: 'NOT SET'
> > > > >> > >
> > > > >> > > relationship_types:
> > > > >> > >   subnet_connected_to_router:
> > > > >> > > derived_from: ConnectsTo
> > > > >> > > interfaces:
> > > > >> > >   Configure:
> > > > >> > > add_target:
> > > > >> > >   implementation: connect.sh
> > > > >> > >   inputs:
> > > > >> > >   openstack_config:
> > > > >> > > type: config
> > > > >&g

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[DeWayne Filppi]

Thats all I run in as well.

On Mon, Aug 28, 2017 at 9:49 AM, Tal Liron <t...@cloudify.co> wrote:

> That is definitely a bug. Could you please try installing apache-ariatosca
> in a virtualenv and see if you get the ctx link there? We mostly test in
> virtualenvs.
>
> On Fri, Aug 25, 2017 at 9:27 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > After the installation of apache-ariatosca, I executed the "pip show
> > apache-ariatosca" command and below is the console output. Which of the
> > below is related to "ctx"? Also, the /usr/local/bin/ is missing the 'ctx'
> > binary on the 16.04 ubuntu, however, I do see the 'aria' binary in that
> > location.
> >
> >
> > ==Begin Console Output===
> >
> > Name: apache-ariatosca
> >
> > Version: 0.1.1
> >
> > Summary: ARIA
> >
> > Home-page: http://ariatosca.incubator.apache.org/
> >
> > Author: ARIA
> >
> > Author-email: dev@ariatosca.incubator.apache.org
> >
> > License: Apache License 2.0
> >
> > Location: /usr/local/lib/python2.7/dist-packages
> >
> > Requires: psutil, ruamel.yaml, SQLAlchemy, logutils, requests,
> > PrettyTable, jsonpickle, click-didyoumean, blinker,
> > backports.shutil-get-terminal-size, clint, colorama, wagon,
> CacheControl,
> > retrying, bottle, click, setuptools, networkx, shortuuid, Jinja2
> >
> > ==End Console output=
> >
> >
> > Vish
> >
> >
> > 
> > From: Vishwanath Jayaraman <vishwana...@hotmail.com>
> > Sent: Friday, August 25, 2017 11:20 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Seeing error "Validation issues: unknown parent type
> > "tosca:Root" in WebServer"
> >
> >
> > Ran,
> >
> > On a fresh Ubuntu 16.04.3 LTS install, I followed the below steps
> >
> > 1  sudo apt-get update -y
> > 2  sudo apt install -y python-pip git
> > 3  sudo pip install --upgrade pip setuptools
> > 4  sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
> > 5  sudo pip install apache-ariatosca
> > 6  sudo pip install apache-ariatosca[ssh]
> > 7 ctx (console output message is "ctx: command not found")
> >
> > From the above steps, does it look like I could be missing something that
> > is not installing the 'ctx' binary.
> >
> >
> > Thanks
> >
> > Vish
> >
> >
> > 
> > From: Ran Ziv <r...@cloudify.co>
> > Sent: Friday, August 25, 2017 4:43 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Seeing error "Validation issues: unknown parent type
> > "tosca:Root" in WebServer"
> >
> > Hi Vishwanath,
> >
> > Thanks for helping in updating the hello-world example readme. Sorry
> about
> > the lack of clarity there regarding the need to copy the template's
> > resources as well.
> >
> > Regarding the ctx error, the ctx is a binary that should get installed in
> > your environment when you install ARIA. It should not be installed
> > separately.
> > try reinstalling ARIA and running "ctx" from the shell - that should give
> > you an error, but one from the "ctx" program, not one that such a program
> > was not found.
> >
> >
> > On Fri, Aug 25, 2017 at 4:40 AM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> > > For a first time user, its not apparent in the instructions at
> > >
> > > http://ariatosca.incubator.apache.org/getting-started/ that they may
> > need
> > > to copy the entire examples directory or clone the github repo, I will
> go
> > > ahead and open a JIRA to update the README.rst with those additional
> > > details.
> > >
> > > Only issue pending at this time is "ctx: command not found" error.
> Once,
> > I
> > > get a response on how that gets installed, I will include that in the
> > > dependencies section.
> > >
> > >
> > > Vish
> > >
> > >
> > > 
> > > From: DeWayne Filppi <dewa...@cloudify.co>
> > > Sent: Thursday, August 24, 2017 1:28 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > "tosca:Root" in WebServer"
> > 

Re: subnet connected to router

[DeWayne Filppi]

I'm on 0.1.1

On Mon, Aug 28, 2017 at 9:48 AM, Tal Liron <t...@cloudify.co> wrote:

> Hm, are you using a git snapshot or a release? This issue was fixed on git
> but not released yet.
>
> On Fri, Aug 25, 2017 at 7:20 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I got this:
> >
> > Validation issues:
> >   5: requirement "my_requirement" of node "my_node2_1" has no target node
> > template
> >
> >
> > On Fri, Aug 25, 2017 at 3:42 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > OK. Now we're getting somewhere. I tried to create a more minimal
> example
> > > to reproduce this, but without success. My example correctly assigns
> the
> > > value when I run "aria services show -f". I wonder if it's a bug that
> was
> > > fixed somewhere or if there's something else going on in your more
> > complex
> > > example.
> > >
> > > Could you try with the attached yaml?
> > >
> > > On Fri, Aug 25, 2017 at 5:33 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > >> Yeah:
> > >>
> > >>   Arguments:
> > >> process: {} (map)
> > >> Sub-process configuration.
> > >> script_path: 'connect.sh' (string)
> > >> Relative path to the executable file.
> > >>     openstack_config: {'username': 'NOT SET'} (map)
> > >>
> > >>
> > >>
> > >> On Fri, Aug 25, 2017 at 3:31 PM, Tal Liron <t...@cloudify.co> wrote:
> > >>
> > >> > And you're saying that also in "aria services show -f" you see that
> > it's
> > >> > NOT SET?
> > >> >
> > >> > On Fri, Aug 25, 2017 at 5:29 PM, DeWayne Filppi <
> dewa...@cloudify.co>
> > >> > wrote:
> > >> >
> > >> > > Never mind, figured it out from the code.  Here's the simplified
> > >> > template:
> > >> > >
> > >> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >> > >
> > >> > >
> > >> > > imports:
> > >> > >   - aria-1.0
> > >> > >
> > >> > > dsl_definitions:
> > >> > >   openstack_config: _config
> > >> > > username: dewayne
> > >> > >
> > >> > > data_types:
> > >> > >   config:
> > >> > > properties:
> > >> > >   username:
> > >> > > type: string
> > >> > > default: 'NOT SET'
> > >> > >
> > >> > > relationship_types:
> > >> > >   subnet_connected_to_router:
> > >> > > derived_from: ConnectsTo
> > >> > > interfaces:
> > >> > >   Configure:
> > >> > > add_target:
> > >> > >   implementation: connect.sh
> > >> > >   inputs:
> > >> > >   openstack_config:
> > >> > > type: config
> > >> > > required: true
> > >> > > default: {}
> > >> > >
> > >> > > node_types:
> > >> > >   router:
> > >> > > derived_from: tosca.nodes.Root
> > >> > >
> > >> > >   subnet:
> > >> > > derived_from: tosca.nodes.Root
> > >> > > requirements:
> > >> > >   - router:
> > >> > >   capability: tosca.capabilities.Node
> > >> > >   node: router
> > >> > >   relationship: subnet_connected_to_router
> > >> > >
> > >> > > topology_template:
> > >> > >
> > >> > >   node_templates:
> > >> > >
> > >> > > router:
> > >> > >   type: router
> > >> > >
> > >> > > subnet:
> > >> > >   type: subnet
> > >> > >   requirements:
> > >> > > - router:
> > >> > > node: router
> > >> > > relationship:
> > >> > >   type: subnet_connected_to_rou

Re: subnet connected to router

[DeWayne Filppi]

I got this:

Validation issues:
  5: requirement "my_requirement" of node "my_node2_1" has no target node
template


On Fri, Aug 25, 2017 at 3:42 PM, Tal Liron <t...@cloudify.co> wrote:

> OK. Now we're getting somewhere. I tried to create a more minimal example
> to reproduce this, but without success. My example correctly assigns the
> value when I run "aria services show -f". I wonder if it's a bug that was
> fixed somewhere or if there's something else going on in your more complex
> example.
>
> Could you try with the attached yaml?
>
> On Fri, Aug 25, 2017 at 5:33 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
>> Yeah:
>>
>>   Arguments:
>> process: {} (map)
>> Sub-process configuration.
>> script_path: 'connect.sh' (string)
>> Relative path to the executable file.
>> openstack_config: {'username': 'NOT SET'} (map)
>>
>>
>>
>> On Fri, Aug 25, 2017 at 3:31 PM, Tal Liron <t...@cloudify.co> wrote:
>>
>> > And you're saying that also in "aria services show -f" you see that it's
>> > NOT SET?
>> >
>> > On Fri, Aug 25, 2017 at 5:29 PM, DeWayne Filppi <dewa...@cloudify.co>
>> > wrote:
>> >
>> > > Never mind, figured it out from the code.  Here's the simplified
>> > template:
>> > >
>> > > tosca_definitions_version: tosca_simple_yaml_1_0
>> > >
>> > >
>> > > imports:
>> > >   - aria-1.0
>> > >
>> > > dsl_definitions:
>> > >   openstack_config: _config
>> > > username: dewayne
>> > >
>> > > data_types:
>> > >   config:
>> > > properties:
>> > >   username:
>> > > type: string
>> > > default: 'NOT SET'
>> > >
>> > > relationship_types:
>> > >   subnet_connected_to_router:
>> > > derived_from: ConnectsTo
>> > > interfaces:
>> > >   Configure:
>> > > add_target:
>> > >   implementation: connect.sh
>> > >   inputs:
>> > >   openstack_config:
>> > > type: config
>> > > required: true
>> > > default: {}
>> > >
>> > > node_types:
>> > >   router:
>> > > derived_from: tosca.nodes.Root
>> > >
>> > >   subnet:
>> > > derived_from: tosca.nodes.Root
>> > > requirements:
>> > >   - router:
>> > >   capability: tosca.capabilities.Node
>> > >   node: router
>> > >   relationship: subnet_connected_to_router
>> > >
>> > > topology_template:
>> > >
>> > >   node_templates:
>> > >
>> > > router:
>> > >   type: router
>> > >
>> > > subnet:
>> > >   type: subnet
>> > >   requirements:
>> > > - router:
>> > > node: router
>> > > relationship:
>> > >   type: subnet_connected_to_router
>> > >   interfaces:
>> > > Configure:
>> > >   add_target:
>> > > inputs:
>> > >   openstack_config: *openstack_config
>> > >
>> > >
>> > > There is a script in the same directory referred to "connect.sh":
>> > >
>> > > #!/bin/sh
>> > >
>> > > ctx logger info "HERE $openstack_config"
>> > >
>> > >
>> > > When "install" is run, the output of the log statement is "NOT SET"
>> (the
>> > > default).  Even though I have overridden it (should be "dewayne").
>> > >
>> > >
>> > >
>> > > On Fri, Aug 25, 2017 at 3:06 PM, DeWayne Filppi <dewa...@cloudify.co>
>> > > wrote:
>> > >
>> > > > For the simplified example I need to provide a shell script or
>> python
>> > > > script that dumps the inputs passed to the operation impl.  Not sure
>> > how
>> > > > that's done in ARIA.  IOW, I don't know how to refer to inputs, and
>> > don't
>> > &

Re: subnet connected to router

[DeWayne Filppi]

Yeah:

  Arguments:
process: {} (map)
Sub-process configuration.
script_path: 'connect.sh' (string)
Relative path to the executable file.
openstack_config: {'username': 'NOT SET'} (map)



On Fri, Aug 25, 2017 at 3:31 PM, Tal Liron <t...@cloudify.co> wrote:

> And you're saying that also in "aria services show -f" you see that it's
> NOT SET?
>
> On Fri, Aug 25, 2017 at 5:29 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Never mind, figured it out from the code.  Here's the simplified
> template:
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> >
> > imports:
> >   - aria-1.0
> >
> > dsl_definitions:
> >   openstack_config: _config
> > username: dewayne
> >
> > data_types:
> >   config:
> > properties:
> >   username:
> > type: string
> > default: 'NOT SET'
> >
> > relationship_types:
> >   subnet_connected_to_router:
> > derived_from: ConnectsTo
> > interfaces:
> >   Configure:
> > add_target:
> >   implementation: connect.sh
> >   inputs:
> >   openstack_config:
> > type: config
> > required: true
> > default: {}
> >
> > node_types:
> >   router:
> > derived_from: tosca.nodes.Root
> >
> >   subnet:
> > derived_from: tosca.nodes.Root
> > requirements:
> >   - router:
> >   capability: tosca.capabilities.Node
> >   node: router
> >   relationship: subnet_connected_to_router
> >
> > topology_template:
> >
> >   node_templates:
> >
> > router:
> >   type: router
> >
> > subnet:
> >   type: subnet
> >   requirements:
> > - router:
> > node: router
> > relationship:
> >   type: subnet_connected_to_router
> >   interfaces:
> > Configure:
> >   add_target:
> > inputs:
> >   openstack_config: *openstack_config
> >
> >
> > There is a script in the same directory referred to "connect.sh":
> >
> > #!/bin/sh
> >
> > ctx logger info "HERE $openstack_config"
> >
> >
> > When "install" is run, the output of the log statement is "NOT SET" (the
> > default).  Even though I have overridden it (should be "dewayne").
> >
> >
> >
> > On Fri, Aug 25, 2017 at 3:06 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > For the simplified example I need to provide a shell script or python
> > > script that dumps the inputs passed to the operation impl.  Not sure
> how
> > > that's done in ARIA.  IOW, I don't know how to refer to inputs, and
> don't
> > > see any example.
> > >
> > > On Fri, Aug 25, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > >> That you supply where? Override where? What is the error? Sorry
> DeWayne,
> > >> very hard for me to follow your explanation. We really need a complete
> > >> simple example here and the exact errors that you get.
> > >>
> > >> On Fri, Aug 25, 2017 at 4:06 PM, DeWayne Filppi <dewa...@cloudify.co>
> > >> wrote:
> > >>
> > >> > Yes, in my case the relationship bewteen the subnet and router
> > >> (add_target)
> > >> > is executed properly.   The problem is that the "openstack_config"
> > input
> > >> > that I supply is not passed as an input.  When I run 'aria service
> > show
> > >> > -f', it is clear that my override is ignore and default (all empty
> > >> strings)
> > >> > is used.
> > >> >
> > >> > On Fri, Aug 25, 2017 at 2:02 PM, Tal Liron <t...@cloudify.co> wrote:
> > >> >
> > >> > > Is my attempt not what you meant? Was your error different?
> > >> > >
> > >> > > On Fri, Aug 25, 2017 at 4:01 PM, DeWayne Filppi <
> > dewa...@cloudify.co>
> > >> > > wrote:
> > >> > >
> > >> > > > OK.  You want something not tied to Openstack, probably with
> just
> > >> two
> > >> > > > nodes.  W

Re: subnet connected to router

[DeWayne Filppi]

Never mind, figured it out from the code.  Here's the simplified template:

tosca_definitions_version: tosca_simple_yaml_1_0


imports:
  - aria-1.0

dsl_definitions:
  openstack_config: _config
username: dewayne

data_types:
  config:
properties:
  username:
type: string
default: 'NOT SET'

relationship_types:
  subnet_connected_to_router:
derived_from: ConnectsTo
interfaces:
  Configure:
add_target:
  implementation: connect.sh
  inputs:
  openstack_config:
type: config
required: true
default: {}

node_types:
  router:
derived_from: tosca.nodes.Root

  subnet:
derived_from: tosca.nodes.Root
requirements:
  - router:
  capability: tosca.capabilities.Node
  node: router
  relationship: subnet_connected_to_router

topology_template:

  node_templates:

router:
  type: router

subnet:
  type: subnet
  requirements:
- router:
node: router
relationship:
  type: subnet_connected_to_router
  interfaces:
Configure:
  add_target:
inputs:
  openstack_config: *openstack_config


There is a script in the same directory referred to "connect.sh":

#!/bin/sh

ctx logger info "HERE $openstack_config"


When "install" is run, the output of the log statement is "NOT SET" (the
default).  Even though I have overridden it (should be "dewayne").



On Fri, Aug 25, 2017 at 3:06 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> For the simplified example I need to provide a shell script or python
> script that dumps the inputs passed to the operation impl.  Not sure how
> that's done in ARIA.  IOW, I don't know how to refer to inputs, and don't
> see any example.
>
> On Fri, Aug 25, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> That you supply where? Override where? What is the error? Sorry DeWayne,
>> very hard for me to follow your explanation. We really need a complete
>> simple example here and the exact errors that you get.
>>
>> On Fri, Aug 25, 2017 at 4:06 PM, DeWayne Filppi <dewa...@cloudify.co>
>> wrote:
>>
>> > Yes, in my case the relationship bewteen the subnet and router
>> (add_target)
>> > is executed properly.   The problem is that the "openstack_config" input
>> > that I supply is not passed as an input.  When I run 'aria service show
>> > -f', it is clear that my override is ignore and default (all empty
>> strings)
>> > is used.
>> >
>> > On Fri, Aug 25, 2017 at 2:02 PM, Tal Liron <t...@cloudify.co> wrote:
>> >
>> > > Is my attempt not what you meant? Was your error different?
>> > >
>> > > On Fri, Aug 25, 2017 at 4:01 PM, DeWayne Filppi <dewa...@cloudify.co>
>> > > wrote:
>> > >
>> > > > OK.  You want something not tied to Openstack, probably with just
>> two
>> > > > nodes.  Will do.
>> > > >
>> > > > On Fri, Aug 25, 2017 at 1:55 PM, Tal Liron <t...@cloudify.co> wrote:
>> > > >
>> > > > > DeWayne, this is still not very minimal, and I don't understand
>> what
>> > > > "dies"
>> > > > > means. Could you please provide the error?
>> > > > >
>> > > > > Here's my stab at a minimal example, please let me know if it's
>> what
>> > > you
>> > > > > got:
>> > > > >
>> > > > > tosca_definitions_version: tosca_simple_yaml_1_0
>> > > > >
>> > > > > relationship_types:
>> > > > >
>> > > > >   MyRelationship:
>> > > > > interfaces:
>> > > > >   Configure:
>> > > > > add_target:
>> > > > >   inputs:
>> > > > > my_input:
>> > > > >   type: string
>> > > > >
>> > > > > node_types:
>> > > > >
>> > > > >   MyNode:
>> > > > > requirements:
>> > > > >   - my_requirement:
>> > > > >   capability: tosca.capabilities.Container
>> > > > >   relationship: MyRelationship
>> > > > >
>> > > > > topology_template:
>> > > > >
>> > > > >   node_templates:
>> > > > > my_node:
>> 

Re: subnet connected to router

[DeWayne Filppi]

For the simplified example I need to provide a shell script or python
script that dumps the inputs passed to the operation impl.  Not sure how
that's done in ARIA.  IOW, I don't know how to refer to inputs, and don't
see any example.

On Fri, Aug 25, 2017 at 2:17 PM, Tal Liron <t...@cloudify.co> wrote:

> That you supply where? Override where? What is the error? Sorry DeWayne,
> very hard for me to follow your explanation. We really need a complete
> simple example here and the exact errors that you get.
>
> On Fri, Aug 25, 2017 at 4:06 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Yes, in my case the relationship bewteen the subnet and router
> (add_target)
> > is executed properly.   The problem is that the "openstack_config" input
> > that I supply is not passed as an input.  When I run 'aria service show
> > -f', it is clear that my override is ignore and default (all empty
> strings)
> > is used.
> >
> > On Fri, Aug 25, 2017 at 2:02 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Is my attempt not what you meant? Was your error different?
> > >
> > > On Fri, Aug 25, 2017 at 4:01 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > OK.  You want something not tied to Openstack, probably with just two
> > > > nodes.  Will do.
> > > >
> > > > On Fri, Aug 25, 2017 at 1:55 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > DeWayne, this is still not very minimal, and I don't understand
> what
> > > > "dies"
> > > > > means. Could you please provide the error?
> > > > >
> > > > > Here's my stab at a minimal example, please let me know if it's
> what
> > > you
> > > > > got:
> > > > >
> > > > > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > >
> > > > > relationship_types:
> > > > >
> > > > >   MyRelationship:
> > > > > interfaces:
> > > > >   Configure:
> > > > > add_target:
> > > > >   inputs:
> > > > > my_input:
> > > > >   type: string
> > > > >
> > > > > node_types:
> > > > >
> > > > >   MyNode:
> > > > > requirements:
> > > > >   - my_requirement:
> > > > >   capability: tosca.capabilities.Container
> > > > >   relationship: MyRelationship
> > > > >
> > > > > topology_template:
> > > > >
> > > > >   node_templates:
> > > > > my_node:
> > > > >   type: MyNode
> > > > >   requirements:
> > > > > - my_requirement:
> > > > > relationship:
> > > > >   interfaces:
> > > > > Configure:
> > > > >   add_target:
> > > > > inputs:
> > > > >   my_input: test
> > > > >
> > > > > The above gave me this exception:
> > > > >
> > > > > AttributeError: 'NoneType' object has no attribute '_name'
> > > > >   File "/home/emblemparade/ariatosca/aria/parser/consumption/
> > > > consumer.py",
> > > > > line 73, in consume
> > > > > consumer.consume()
> > > > >   File "/home/emblemparade/ariatosca/aria/parser/consumption/
> > > > modeling.py",
> > > > > line 36, in consume
> > > > > self.context.presentation.presenter._get_model(self.context)
> > > > >   File "/home/emblemparade/ariatosca/aria/utils/caching.py", line
> > 84,
> > > in
> > > > > __call__
> > > > > return_value = self.func(*args, **kwargs)
> > > > >   File
> > > > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > > > tosca/simple_v1_0/presenter.py",
> > > > > line 82, in _get_model
> > > > > return create_service_template_model(context)
> > > > >   File
> > > > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > > > tosca/simple_v1_0/modeling/__init__.py",
> > > > > line 123, in create_service_template_model
> > > > > fix_nod

Re: subnet connected to router

[DeWayne Filppi]

Yes, in my case the relationship bewteen the subnet and router (add_target)
is executed properly.   The problem is that the "openstack_config" input
that I supply is not passed as an input.  When I run 'aria service show
-f', it is clear that my override is ignore and default (all empty strings)
is used.

On Fri, Aug 25, 2017 at 2:02 PM, Tal Liron <t...@cloudify.co> wrote:

> Is my attempt not what you meant? Was your error different?
>
> On Fri, Aug 25, 2017 at 4:01 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > OK.  You want something not tied to Openstack, probably with just two
> > nodes.  Will do.
> >
> > On Fri, Aug 25, 2017 at 1:55 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > DeWayne, this is still not very minimal, and I don't understand what
> > "dies"
> > > means. Could you please provide the error?
> > >
> > > Here's my stab at a minimal example, please let me know if it's what
> you
> > > got:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > relationship_types:
> > >
> > >   MyRelationship:
> > > interfaces:
> > >   Configure:
> > > add_target:
> > >   inputs:
> > > my_input:
> > >   type: string
> > >
> > > node_types:
> > >
> > >   MyNode:
> > > requirements:
> > >   - my_requirement:
> > >   capability: tosca.capabilities.Container
> > >   relationship: MyRelationship
> > >
> > > topology_template:
> > >
> > >   node_templates:
> > > my_node:
> > >   type: MyNode
> > >   requirements:
> > > - my_requirement:
> > > relationship:
> > >   interfaces:
> > > Configure:
> > >   add_target:
> > > inputs:
> > >   my_input: test
> > >
> > > The above gave me this exception:
> > >
> > > AttributeError: 'NoneType' object has no attribute '_name'
> > >   File "/home/emblemparade/ariatosca/aria/parser/consumption/
> > consumer.py",
> > > line 73, in consume
> > > consumer.consume()
> > >   File "/home/emblemparade/ariatosca/aria/parser/consumption/
> > modeling.py",
> > > line 36, in consume
> > > self.context.presentation.presenter._get_model(self.context)
> > >   File "/home/emblemparade/ariatosca/aria/utils/caching.py", line 84,
> in
> > > __call__
> > > return_value = self.func(*args, **kwargs)
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/presenter.py",
> > > line 82, in _get_model
> > > return create_service_template_model(context)
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/modeling/__init__.py",
> > > line 123, in create_service_template_model
> > > fix_node_template_model(context, model, node_template)
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/modeling/__init__.py",
> > > line 209, in fix_node_template_model
> > > requirement))
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/modeling/__init__.py",
> > > line 293, in create_requirement_template_model
> > > create_relationship_template_model(context, service_template,
> > > relationship)
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/modeling/__init__.py",
> > > line 318, in create_relationship_template_model
> > > relationship.interfaces)
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/modeling/__init__.py",
> > > line 621, in create_interface_template_models
> > > interface = create_interface_template_model(context,
> > service_template,
> > > interface)
> > >   File
> > > "/home/emblemparade/ariatosca/extensions/aria_extension_
> > > tosca/simple_v1_0/modeling/__init__.py",
> > > line 354, in create_interface_template_model
> > > interface_type =
>

Re: subnet connected to router

[DeWayne Filppi]

tosca_definitions_version: tosca_simple_yaml_1_0

imports:
  -
https://raw.githubusercontent.com/cloudify-cosmo/aria-extension-cloudify/master/plugins/openstack/plugin.yaml
  - aria-1.0

dsl_definitions:
  openstack_config: _config
username:
password:
tenant_name:
auth_url:

topology_template:

  node_templates:

router:
  type: aria.openstack.nodes.Router
  properties:
external_network: gateway_net
create_if_missing: true
resource_id: aria_helloworld_rtr
  interfaces:
Standard:
  create:
inputs:
  openstack_config: *openstack_config

network:
  type: aria.openstack.nodes.Network
  properties:
resource_id: aria_helloworld_network
create_if_missing: true
  interfaces:
Standard:
  create:
inputs:
  openstack_config: *openstack_config

subnet:
  type: aria.openstack.nodes.Subnet
  properties:
resource_id: aria_helloworld_subnet
create_if_missing: true
  interfaces:
Standard:
  create:
inputs:
  openstack_config: *openstack_config
  requirements:
- router:
node: router
relationship:
  type: aria.openstack.subnet_connected_to_router
  interfaces:
Configure:
  add_target:
inputs:
  openstack_config: *openstack_config
- network: network

Dies in add_target of subnet_connected_to_router because default (empty)
openstack_config input being used rather than the override.  I didn't put
the "implementation" line in because doing so has no effect.



On Fri, Aug 25, 2017 at 1:03 PM, Tal Liron <t...@cloudify.co> wrote:

> Could you create a minimal YAML file that demonstrates this problem so we
> can reproduce it? It could be a bug.
>
> On Fri, Aug 25, 2017 at 2:48 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > I don't know if this is a clue or not, but I modified the
> > relationship:  aria.openstack.subnet_connected_to_router, in the aria
> > openstack plugin.yaml to require the 'openstack_config' input for the
> > Configure.add_target operation (and got rid of the default).  Afterwards,
> > any attempt to validate this:
> >
> > subnet:
> >   type: aria.openstack.nodes.Subnet
> >   properties:
> > resource_id: aria_helloworld_subnet
> > create_if_missing: true
> >   interfaces:
> > Standard:
> >   create:
> > inputs:
> >   openstack_config: { get_input: openstack_config }
> >   requirements:
> > - router:
> > node: router
> > relationship:
> >   type: aria.openstack.subnet_connected_to_router
> >   interfaces:
> > Configure:
> >   add_target:
> > inputs:
> >   openstack_config: { get_input: openstack_config }
> >
> > Fails with the error : Validation issues:
> >   4: interface definition "Configure" does not assign a value to a
> required
> > operation input "add_target.openstack_config" in "relationship"
> >
> > Which is further confirmation that the input isn't seen, and normally the
> > default gets used (empty strings).  I don't see examples anywhere that
> show
> > how to properly override the interface inside a relationship inside a
> > requirement.
> >
> >
> > On Fri, Aug 25, 2017 at 10:57 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > "implementation" is a required field in the TOSCA spec, so you must
> > specify
> > > it even if it is the same.
> > >
> > > On Fri, Aug 25, 2017 at 12:47 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > It appears that this issue *was* fixed by repeating the
> implementation
> > > key
> > > > in the add_target block.  Intuitively, I would expect that fields I
> > > didn't
> > > > override would be untouched, but apparently not.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > Did you read the wiki? ARIA will send those specially formatted
> > > > > dependencies as arguments to the @operation function.
> > > > >
> > > > > It would help to see your complete example, as I don't know what
> > you're
> > > > > doing and not doing anymore. Could you throw it into a 

Re: subnet connected to router

[DeWayne Filppi]

I don't know if this is a clue or not, but I modified the
relationship:  aria.openstack.subnet_connected_to_router, in the aria
openstack plugin.yaml to require the 'openstack_config' input for the
Configure.add_target operation (and got rid of the default).  Afterwards,
any attempt to validate this:

subnet:
  type: aria.openstack.nodes.Subnet
  properties:
resource_id: aria_helloworld_subnet
create_if_missing: true
  interfaces:
Standard:
  create:
inputs:
  openstack_config: { get_input: openstack_config }
  requirements:
- router:
node: router
relationship:
  type: aria.openstack.subnet_connected_to_router
  interfaces:
Configure:
  add_target:
inputs:
  openstack_config: { get_input: openstack_config }

Fails with the error : Validation issues:
  4: interface definition "Configure" does not assign a value to a required
operation input "add_target.openstack_config" in "relationship"

Which is further confirmation that the input isn't seen, and normally the
default gets used (empty strings).  I don't see examples anywhere that show
how to properly override the interface inside a relationship inside a
requirement.


On Fri, Aug 25, 2017 at 10:57 AM, Tal Liron <t...@cloudify.co> wrote:

> "implementation" is a required field in the TOSCA spec, so you must specify
> it even if it is the same.
>
> On Fri, Aug 25, 2017 at 12:47 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > It appears that this issue *was* fixed by repeating the implementation
> key
> > in the add_target block.  Intuitively, I would expect that fields I
> didn't
> > override would be untouched, but apparently not.
> >
> > On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Did you read the wiki? ARIA will send those specially formatted
> > > dependencies as arguments to the @operation function.
> > >
> > > It would help to see your complete example, as I don't know what you're
> > > doing and not doing anymore. Could you throw it into a GitHub repo
> > perhaps?
> > >
> > > On Thu, Aug 24, 2017 at 6:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > 'dependencies' is a child of implementation in the spec.   I don't
> > think
> > > > it's going to do anything for me anyway.  I just want to pass
> > > > openstack_config to the add_target operation as inputs.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:28 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > What is the error?
> > > > >
> > > > > On Thu, Aug 24, 2017 at 6:22 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > actually "dependencies" fails validation.
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 4:08 PM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > Oops, sorry, this is the syntax:
> > > > > > >
> > > > > > > interfaces:
> > > > > > >   Configure:
> > > > > > > add_target:
> > > > > > >   primary: my_script.sh
> > > > > > >   dependencies:
> > > > > > > - "openstack_config > { get_input: openstack_config }"
> > > > > > >
> > > > > > > On Thu, Aug 24, 2017 at 6:00 PM, Tal Liron <t...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > A few syntax problems:
> > > > > > > >
> > > > > > > > 1. It looks like you don't have any operation implementation,
> > > which
> > > > > is
> > > > > > a
> > > > > > > > required field. (What do you expect the inputs to be sent
> to?)
> > > > > > > > 2. Also, you are not naming the input. It should be "inputs:
> {
> > > > > > > > my_input_name: { get_input: openstack_config } }"
> > > > > > > > 3. But #2 won't work because you can't just add inputs in
> this
> > > > case,
> > > > > > > > because they are not declared at the interface type.
> > > > > > > >
> > > > > > > &

Re: subnet connected to router

[DeWayne Filppi]

In any case, seems I'm mistaken.  Inputs are still not being passed.

On Fri, Aug 25, 2017 at 10:57 AM, Tal Liron <t...@cloudify.co> wrote:

> "implementation" is a required field in the TOSCA spec, so you must specify
> it even if it is the same.
>
> On Fri, Aug 25, 2017 at 12:47 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > It appears that this issue *was* fixed by repeating the implementation
> key
> > in the add_target block.  Intuitively, I would expect that fields I
> didn't
> > override would be untouched, but apparently not.
> >
> > On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Did you read the wiki? ARIA will send those specially formatted
> > > dependencies as arguments to the @operation function.
> > >
> > > It would help to see your complete example, as I don't know what you're
> > > doing and not doing anymore. Could you throw it into a GitHub repo
> > perhaps?
> > >
> > > On Thu, Aug 24, 2017 at 6:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > 'dependencies' is a child of implementation in the spec.   I don't
> > think
> > > > it's going to do anything for me anyway.  I just want to pass
> > > > openstack_config to the add_target operation as inputs.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:28 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > What is the error?
> > > > >
> > > > > On Thu, Aug 24, 2017 at 6:22 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > actually "dependencies" fails validation.
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 4:08 PM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > Oops, sorry, this is the syntax:
> > > > > > >
> > > > > > > interfaces:
> > > > > > >   Configure:
> > > > > > > add_target:
> > > > > > >   primary: my_script.sh
> > > > > > >   dependencies:
> > > > > > > - "openstack_config > { get_input: openstack_config }"
> > > > > > >
> > > > > > > On Thu, Aug 24, 2017 at 6:00 PM, Tal Liron <t...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > A few syntax problems:
> > > > > > > >
> > > > > > > > 1. It looks like you don't have any operation implementation,
> > > which
> > > > > is
> > > > > > a
> > > > > > > > required field. (What do you expect the inputs to be sent
> to?)
> > > > > > > > 2. Also, you are not naming the input. It should be "inputs:
> {
> > > > > > > > my_input_name: { get_input: openstack_config } }"
> > > > > > > > 3. But #2 won't work because you can't just add inputs in
> this
> > > > case,
> > > > > > > > because they are not declared at the interface type.
> > > > > > > >
> > > > > > > > Assuming you do have an implementation, you could you try
> > passing
> > > > it
> > > > > > > using
> > > > > > > > execution configuration:
> > > > > > > >
> > > > > > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > > > > > > Execution+Configuration
> > > > > > > >
> > > > > > > > Try something like this:
> > > > > > > >
> > > > > > > > interfaces:
> > > > > > > >   Configure:
> > > > > > > > add_target:
> > > > > > > >   primary: my_script.sh
> > > > > > > >   dependencies:
> > > > > > > > - openstack_config: { get_input: openstack_config }
> > > > > > > >
> > > > > > > > On Thu, Aug 24, 2017 at 5:49 PM, DeWayne Filppi <
> > > > dewa...@cloudify.co
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> In the ARIA usage of the p

Re: subnet connected to router

[DeWayne Filppi]

Pity.  I guess the stock answer is "if you want to hide such details,
create your own type".

On Fri, Aug 25, 2017 at 10:57 AM, Tal Liron <t...@cloudify.co> wrote:

> "implementation" is a required field in the TOSCA spec, so you must specify
> it even if it is the same.
>
> On Fri, Aug 25, 2017 at 12:47 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > It appears that this issue *was* fixed by repeating the implementation
> key
> > in the add_target block.  Intuitively, I would expect that fields I
> didn't
> > override would be untouched, but apparently not.
> >
> > On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > Did you read the wiki? ARIA will send those specially formatted
> > > dependencies as arguments to the @operation function.
> > >
> > > It would help to see your complete example, as I don't know what you're
> > > doing and not doing anymore. Could you throw it into a GitHub repo
> > perhaps?
> > >
> > > On Thu, Aug 24, 2017 at 6:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > 'dependencies' is a child of implementation in the spec.   I don't
> > think
> > > > it's going to do anything for me anyway.  I just want to pass
> > > > openstack_config to the add_target operation as inputs.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:28 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > What is the error?
> > > > >
> > > > > On Thu, Aug 24, 2017 at 6:22 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > actually "dependencies" fails validation.
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 4:08 PM, Tal Liron <t...@cloudify.co>
> > wrote:
> > > > > >
> > > > > > > Oops, sorry, this is the syntax:
> > > > > > >
> > > > > > > interfaces:
> > > > > > >   Configure:
> > > > > > > add_target:
> > > > > > >   primary: my_script.sh
> > > > > > >   dependencies:
> > > > > > > - "openstack_config > { get_input: openstack_config }"
> > > > > > >
> > > > > > > On Thu, Aug 24, 2017 at 6:00 PM, Tal Liron <t...@cloudify.co>
> > > wrote:
> > > > > > >
> > > > > > > > A few syntax problems:
> > > > > > > >
> > > > > > > > 1. It looks like you don't have any operation implementation,
> > > which
> > > > > is
> > > > > > a
> > > > > > > > required field. (What do you expect the inputs to be sent
> to?)
> > > > > > > > 2. Also, you are not naming the input. It should be "inputs:
> {
> > > > > > > > my_input_name: { get_input: openstack_config } }"
> > > > > > > > 3. But #2 won't work because you can't just add inputs in
> this
> > > > case,
> > > > > > > > because they are not declared at the interface type.
> > > > > > > >
> > > > > > > > Assuming you do have an implementation, you could you try
> > passing
> > > > it
> > > > > > > using
> > > > > > > > execution configuration:
> > > > > > > >
> > > > > > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > > > > > > Execution+Configuration
> > > > > > > >
> > > > > > > > Try something like this:
> > > > > > > >
> > > > > > > > interfaces:
> > > > > > > >   Configure:
> > > > > > > > add_target:
> > > > > > > >   primary: my_script.sh
> > > > > > > >   dependencies:
> > > > > > > > - openstack_config: { get_input: openstack_config }
> > > > > > > >
> > > > > > > > On Thu, Aug 24, 2017 at 5:49 PM, DeWayne Filppi <
> > > > dewa...@cloudify.co
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >>

Re: subnet connected to router

[DeWayne Filppi]

It appears that this issue *was* fixed by repeating the implementation key
in the add_target block.  Intuitively, I would expect that fields I didn't
override would be untouched, but apparently not.

On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:

> Did you read the wiki? ARIA will send those specially formatted
> dependencies as arguments to the @operation function.
>
> It would help to see your complete example, as I don't know what you're
> doing and not doing anymore. Could you throw it into a GitHub repo perhaps?
>
> On Thu, Aug 24, 2017 at 6:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > 'dependencies' is a child of implementation in the spec.   I don't think
> > it's going to do anything for me anyway.  I just want to pass
> > openstack_config to the add_target operation as inputs.
> >
> > On Thu, Aug 24, 2017 at 4:28 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > What is the error?
> > >
> > > On Thu, Aug 24, 2017 at 6:22 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > actually "dependencies" fails validation.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:08 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > Oops, sorry, this is the syntax:
> > > > >
> > > > > interfaces:
> > > > >   Configure:
> > > > > add_target:
> > > > >   primary: my_script.sh
> > > > >   dependencies:
> > > > > - "openstack_config > { get_input: openstack_config }"
> > > > >
> > > > > On Thu, Aug 24, 2017 at 6:00 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > A few syntax problems:
> > > > > >
> > > > > > 1. It looks like you don't have any operation implementation,
> which
> > > is
> > > > a
> > > > > > required field. (What do you expect the inputs to be sent to?)
> > > > > > 2. Also, you are not naming the input. It should be "inputs: {
> > > > > > my_input_name: { get_input: openstack_config } }"
> > > > > > 3. But #2 won't work because you can't just add inputs in this
> > case,
> > > > > > because they are not declared at the interface type.
> > > > > >
> > > > > > Assuming you do have an implementation, you could you try passing
> > it
> > > > > using
> > > > > > execution configuration:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > > > > Execution+Configuration
> > > > > >
> > > > > > Try something like this:
> > > > > >
> > > > > > interfaces:
> > > > > >   Configure:
> > > > > > add_target:
> > > > > >   primary: my_script.sh
> > > > > >   dependencies:
> > > > > > - openstack_config: { get_input: openstack_config }
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 5:49 PM, DeWayne Filppi <
> > dewa...@cloudify.co
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> In the ARIA usage of the plugin, I need to pass openstack_config
> > > > > >> explicitly
> > > > > >> to every operation.  Since the relationships are implicit, how
> do
> > I
> > > > > >> accomplish this?  Currently I get errors when trying to connect
> a
> > > > subnet
> > > > > >> to
> > > > > >> a router.   I've tried overriding the relationship like so:
> > > > > >>
> > > > > >> subnet:
> > > > > >>   type: aria.openstack.nodes.Subnet
> > > > > >>   properties:
> > > > > >> resource_id: aria_helloworld_subnet
> > > > > >> create_if_missing: true
> > > > > >>   interfaces:
> > > > > >> Standard:
> > > > > >>   create:
> > > > > >> inputs:
> > > > > >>   openstack_config: { get_input: openstack_config }
> > > > > >>   requirements:
> > > > > >> - router:
> > > > > >> node: router
> > > > > >> relationship:
> > > > > >>   type: aria.openstack.subnet_connected_to_router
> > > > > >>   interfaces:
> > > > > >> Configure:
> > > > > >>   add_target:
> > > > > >> inputs: { get_input: openstack_config }
> > > > > >> - network: network
> > > > > >>
> > > > > >> Note the router requirement.  Does this syntax look correct?
> > > Spoiler:
> > > > > >> openstack_config never makes it to the plugin.
> > > > > >>
> > > > > >> DeWayne
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[DeWayne Filppi]

I think I responded to the wrong thread.  Thanks

On Fri, Aug 25, 2017 at 2:44 AM, Ran Ziv <r...@cloudify.co> wrote:

> DeWayne, not really sure how the port-floatingip issue got linked on this
> thread, but in any case it's a known issue and the problem has already been
> fixed in this PR:
> https://github.com/cloudify-cosmo/aria-extension-cloudify/pull/52
>
> But it hasn't been merged yet. Should happen over the next week.
>
>
> Ran
>
> On Fri, Aug 25, 2017 at 12:43 PM, Ran Ziv <r...@cloudify.co> wrote:
>
> > Hi Vishwanath,
> >
> > Thanks for helping in updating the hello-world example readme. Sorry
> about
> > the lack of clarity there regarding the need to copy the template's
> > resources as well.
> >
> > Regarding the ctx error, the ctx is a binary that should get installed in
> > your environment when you install ARIA. It should not be installed
> > separately.
> > try reinstalling ARIA and running "ctx" from the shell - that should give
> > you an error, but one from the "ctx" program, not one that such a program
> > was not found.
> >
> >
> > On Fri, Aug 25, 2017 at 4:40 AM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> >> For a first time user, its not apparent in the instructions at
> >>
> >> http://ariatosca.incubator.apache.org/getting-started/ that they may
> >> need to copy the entire examples directory or clone the github repo, I
> will
> >> go ahead and open a JIRA to update the README.rst with those additional
> >> details.
> >>
> >> Only issue pending at this time is "ctx: command not found" error. Once,
> >> I get a response on how that gets installed, I will include that in the
> >> dependencies section.
> >>
> >>
> >> Vish
> >>
> >>
> >> 
> >> From: DeWayne Filppi <dewa...@cloudify.co>
> >> Sent: Thursday, August 24, 2017 1:28 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: Seeing error "Validation issues: unknown parent type
> >> "tosca:Root" in WebServer"
> >>
> >> I'm running in a cloned github repo, so all is there.  On another front,
> >> the Aria port type for Openstack requires that every port have a
> >> public/floating ip.
> >>
> >> On Thu, Aug 24, 2017 at 11:11 AM, Tal Liron <t...@cloudify.co> wrote:
> >>
> >> > You need not just the helloworld YAML file, but also all the scripts
> it
> >> > references. Try copying the whole examples directory to make sure.
> >> >
> >> > We are planning to eventually display a validation error if the YAML
> >> file
> >> > references artifacts that don't exist, so you wouldn't have to wait
> >> until
> >> > execution to see the error. This would be part of our general work on
> >> > improving artifact support.
> >> >
> >> > On Thu, Aug 24, 2017 at 12:26 PM, Vishwanath Jayaraman <
> >> > vishwana...@hotmail.com> wrote:
> >> >
> >> > > I copied the helloworld.yaml to '~/examples'  (i.e home directory)
> on
> >> my
> >> > > box.
> >> > >
> >> > >
> >> > > From the instructions at http://ariatosca.incubator.
> >> > > apache.org/getting-started/
> >> > >
> >> > > I executed the
> >> > >
> >> > > aria service-templates store examples/helloworld.yaml
> >> my-service-template
> >> > >
> >> > > command from the home directory.
> >> > >
> >> > >
> >> > >
> >> > > Additional Info:
> >> > >
> >> > > - I am running this on a fresh Ubuntu 16.04 system
> >> > >
> >> > >
> >> > > ARIA Installation sequence followed is below
> >> > >
> >> > > - sudo apt-get update
> >> > >
> >> > > - sudo apt-install python-pip
> >> > >
> >> > > - pip install --upgrade pip setuptools
> >> > >
> >> > > - sudo pip install apache-ariatosca
> >> > >
> >> > > - sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
> >> > >
> >> > > - sudo pip install apache-ariatosca[ssh]
> >> > >
> >> > >
> >> > > After I execute
> >> > 

Re: subnet connected to router

[DeWayne Filppi]

Never mind.  Found it.

On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:

> Did you read the wiki? ARIA will send those specially formatted
> dependencies as arguments to the @operation function.
>
> It would help to see your complete example, as I don't know what you're
> doing and not doing anymore. Could you throw it into a GitHub repo perhaps?
>
> On Thu, Aug 24, 2017 at 6:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > 'dependencies' is a child of implementation in the spec.   I don't think
> > it's going to do anything for me anyway.  I just want to pass
> > openstack_config to the add_target operation as inputs.
> >
> > On Thu, Aug 24, 2017 at 4:28 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > What is the error?
> > >
> > > On Thu, Aug 24, 2017 at 6:22 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > actually "dependencies" fails validation.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:08 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > Oops, sorry, this is the syntax:
> > > > >
> > > > > interfaces:
> > > > >   Configure:
> > > > > add_target:
> > > > >   primary: my_script.sh
> > > > >   dependencies:
> > > > > - "openstack_config > { get_input: openstack_config }"
> > > > >
> > > > > On Thu, Aug 24, 2017 at 6:00 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > A few syntax problems:
> > > > > >
> > > > > > 1. It looks like you don't have any operation implementation,
> which
> > > is
> > > > a
> > > > > > required field. (What do you expect the inputs to be sent to?)
> > > > > > 2. Also, you are not naming the input. It should be "inputs: {
> > > > > > my_input_name: { get_input: openstack_config } }"
> > > > > > 3. But #2 won't work because you can't just add inputs in this
> > case,
> > > > > > because they are not declared at the interface type.
> > > > > >
> > > > > > Assuming you do have an implementation, you could you try passing
> > it
> > > > > using
> > > > > > execution configuration:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > > > > Execution+Configuration
> > > > > >
> > > > > > Try something like this:
> > > > > >
> > > > > > interfaces:
> > > > > >   Configure:
> > > > > > add_target:
> > > > > >   primary: my_script.sh
> > > > > >   dependencies:
> > > > > > - openstack_config: { get_input: openstack_config }
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 5:49 PM, DeWayne Filppi <
> > dewa...@cloudify.co
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> In the ARIA usage of the plugin, I need to pass openstack_config
> > > > > >> explicitly
> > > > > >> to every operation.  Since the relationships are implicit, how
> do
> > I
> > > > > >> accomplish this?  Currently I get errors when trying to connect
> a
> > > > subnet
> > > > > >> to
> > > > > >> a router.   I've tried overriding the relationship like so:
> > > > > >>
> > > > > >> subnet:
> > > > > >>   type: aria.openstack.nodes.Subnet
> > > > > >>   properties:
> > > > > >> resource_id: aria_helloworld_subnet
> > > > > >> create_if_missing: true
> > > > > >>   interfaces:
> > > > > >> Standard:
> > > > > >>   create:
> > > > > >> inputs:
> > > > > >>   openstack_config: { get_input: openstack_config }
> > > > > >>   requirements:
> > > > > >> - router:
> > > > > >> node: router
> > > > > >> relationship:
> > > > > >>   type: aria.openstack.subnet_connected_to_router
> > > > > >>   interfaces:
> > > > > >> Configure:
> > > > > >>   add_target:
> > > > > >> inputs: { get_input: openstack_config }
> > > > > >> - network: network
> > > > > >>
> > > > > >> Note the router requirement.  Does this syntax look correct?
> > > Spoiler:
> > > > > >> openstack_config never makes it to the plugin.
> > > > > >>
> > > > > >> DeWayne
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: subnet connected to router

[DeWayne Filppi]

I'm just trying to get the HelloWorld example to run on Openstack.  Since
the openstack_config property doesn't do anything, I'm having to pass it to
all the operations.  Which wiki?

On Thu, Aug 24, 2017 at 4:59 PM, Tal Liron <t...@cloudify.co> wrote:

> Did you read the wiki? ARIA will send those specially formatted
> dependencies as arguments to the @operation function.
>
> It would help to see your complete example, as I don't know what you're
> doing and not doing anymore. Could you throw it into a GitHub repo perhaps?
>
> On Thu, Aug 24, 2017 at 6:53 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > 'dependencies' is a child of implementation in the spec.   I don't think
> > it's going to do anything for me anyway.  I just want to pass
> > openstack_config to the add_target operation as inputs.
> >
> > On Thu, Aug 24, 2017 at 4:28 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > What is the error?
> > >
> > > On Thu, Aug 24, 2017 at 6:22 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > actually "dependencies" fails validation.
> > > >
> > > > On Thu, Aug 24, 2017 at 4:08 PM, Tal Liron <t...@cloudify.co> wrote:
> > > >
> > > > > Oops, sorry, this is the syntax:
> > > > >
> > > > > interfaces:
> > > > >   Configure:
> > > > > add_target:
> > > > >   primary: my_script.sh
> > > > >   dependencies:
> > > > > - "openstack_config > { get_input: openstack_config }"
> > > > >
> > > > > On Thu, Aug 24, 2017 at 6:00 PM, Tal Liron <t...@cloudify.co>
> wrote:
> > > > >
> > > > > > A few syntax problems:
> > > > > >
> > > > > > 1. It looks like you don't have any operation implementation,
> which
> > > is
> > > > a
> > > > > > required field. (What do you expect the inputs to be sent to?)
> > > > > > 2. Also, you are not naming the input. It should be "inputs: {
> > > > > > my_input_name: { get_input: openstack_config } }"
> > > > > > 3. But #2 won't work because you can't just add inputs in this
> > case,
> > > > > > because they are not declared at the interface type.
> > > > > >
> > > > > > Assuming you do have an implementation, you could you try passing
> > it
> > > > > using
> > > > > > execution configuration:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> > > > > > Execution+Configuration
> > > > > >
> > > > > > Try something like this:
> > > > > >
> > > > > > interfaces:
> > > > > >   Configure:
> > > > > > add_target:
> > > > > >   primary: my_script.sh
> > > > > >   dependencies:
> > > > > > - openstack_config: { get_input: openstack_config }
> > > > > >
> > > > > > On Thu, Aug 24, 2017 at 5:49 PM, DeWayne Filppi <
> > dewa...@cloudify.co
> > > >
> > > > > > wrote:
> > > > > >
> > > > > >> In the ARIA usage of the plugin, I need to pass openstack_config
> > > > > >> explicitly
> > > > > >> to every operation.  Since the relationships are implicit, how
> do
> > I
> > > > > >> accomplish this?  Currently I get errors when trying to connect
> a
> > > > subnet
> > > > > >> to
> > > > > >> a router.   I've tried overriding the relationship like so:
> > > > > >>
> > > > > >> subnet:
> > > > > >>   type: aria.openstack.nodes.Subnet
> > > > > >>   properties:
> > > > > >> resource_id: aria_helloworld_subnet
> > > > > >> create_if_missing: true
> > > > > >>   interfaces:
> > > > > >> Standard:
> > > > > >>   create:
> > > > > >> inputs:
> > > > > >>   openstack_config: { get_input: openstack_config }
> > > > > >>   requirements:
> > > > > >> - router:
> > > > > >> node: router
> > > > > >> relationship:
> > > > > >>   type: aria.openstack.subnet_connected_to_router
> > > > > >>   interfaces:
> > > > > >> Configure:
> > > > > >>   add_target:
> > > > > >> inputs: { get_input: openstack_config }
> > > > > >> - network: network
> > > > > >>
> > > > > >> Note the router requirement.  Does this syntax look correct?
> > > Spoiler:
> > > > > >> openstack_config never makes it to the plugin.
> > > > > >>
> > > > > >> DeWayne
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>