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

[Pedro Henrique Gomes]

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,
>> > >
>> > > I am having a problem with a template that uses Cloudify Openstack
>> > plugin.
>> > > Wanted to check out if someone has any clue, because it seems to be a
>> > bug.
>> > > I can open a ticket if necessary.
>> > >
>> > > I have a template that creates a Openstack deployment with a VM.
>> > >
>> > > --- In scenario 1) there is a node (call N1) in the template of type
>> > > tosca.nodes.SoftwareComponent that executes some scripts in the VM
>> (using
>> > > ssh). This node has as requirement host the later VM.
>> > > This scenario works fine
>> > >
>

Re: Issue in the execution context when using Openstack plugin

[DeWayne Filppi]

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,
> > >
> > > I am having a problem with a template that uses Cloudify Openstack
> > plugin.
> > > Wanted to check out if someone has any clue, because it seems to be a
> > bug.
> > > I can open a ticket if necessary.
> > >
> > > I have a template that creates a Openstack deployment with a VM.
> > >
> > > --- In scenario 1) there is a node (call N1) in the template of type
> > > tosca.nodes.SoftwareComponent that executes some scripts in the VM
> (using
> > > ssh). This node has as requirement host the later VM.
> > > This scenario works fine
> > >
> > > -- In scenario 2) there is a node (call N2) in the template also of
> type
> > > tosca.nodes.SoftwareComponent, but this other node run locally, not in
> > the
> > > VM.
> > > If both nodes exist they work fine but I dont have control over which
> one
> > > runs first
> > >
> > > -- In scenario 3) we add a requirement dependency to N1 pointing to
> N2. I
> > > want to make sure the scripts in N2 run before the scripts in N1.
> > > But in this case both nodes (N1 and N2) are executed with
> > > execute_with_ssh() which makes the orchestration break, because N2 does
> > not
> > > have a sh key, etc.
> &g

Re: Issue in the execution context when using Openstack plugin

[Pedro Henrique Gomes]

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,
> >
> > I am having a problem with a template that uses Cloudify Openstack
> plugin.
> > Wanted to check out if someone has any clue, because it seems to be a
> bug.
> > I can open a ticket if necessary.
> >
> > I have a template that creates a Openstack deployment with a VM.
> >
> > --- In scenario 1) there is a node (call N1) in the template of type
> > tosca.nodes.SoftwareComponent that executes some scripts in the VM (using
> > ssh). This node has as requirement host the later VM.
> > This scenario works fine
> >
> > -- In scenario 2) there is a node (call N2) in the template also of type
> > tosca.nodes.SoftwareComponent, but this other node run locally, not in
> the
> > VM.
> > If both nodes exist they work fine but I dont have control over which one
> > runs first
> >
> > -- In scenario 3) we add a requirement dependency to N1 pointing to N2. I
> > want to make sure the scripts in N2 run before the scripts in N1.
> > But in this case both nodes (N1 and N2) are executed with
> > execute_with_ssh() which makes the orchestration break, because N2 does
> not
> > have a sh key, etc.
> >
> > 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"
> >  

Re: Issue in the execution context when using Openstack plugin

[Thomas Nadeau]

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,
>
> I am having a problem with a template that uses Cloudify Openstack plugin.
> Wanted to check out if someone has any clue, because it seems to be a bug.
> I can open a ticket if necessary.
>
> I have a template that creates a Openstack deployment with a VM.
>
> --- In scenario 1) there is a node (call N1) in the template of type
> tosca.nodes.SoftwareComponent that executes some scripts in the VM (using
> ssh). This node has as requirement host the later VM.
> This scenario works fine
>
> -- In scenario 2) there is a node (call N2) in the template also of type
> tosca.nodes.SoftwareComponent, but this other node run locally, not in the
> VM.
> If both nodes exist they work fine but I dont have control over which one
> runs first
>
> -- In scenario 3) we add a requirement dependency to N1 pointing to N2. I
> want to make sure the scripts in N2 run before the scripts in N1.
> But in this case both nodes (N1 and N2) are executed with
> execute_with_ssh() which makes the orchestration break, because N2 does not
> have a sh key, etc.
>
> 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
>

Issue in the execution context when using Openstack plugin

[Pedro Henrique Gomes]

Hello everyone,

I am having a problem with a template that uses Cloudify Openstack plugin.
Wanted to check out if someone has any clue, because it seems to be a bug.
I can open a ticket if necessary.

I have a template that creates a Openstack deployment with a VM.

--- In scenario 1) there is a node (call N1) in the template of type
tosca.nodes.SoftwareComponent that executes some scripts in the VM (using
ssh). This node has as requirement host the later VM.
This scenario works fine

-- In scenario 2) there is a node (call N2) in the template also of type
tosca.nodes.SoftwareComponent, but this other node run locally, not in the
VM.
If both nodes exist they work fine but I dont have control over which one
runs first

-- In scenario 3) we add a requirement dependency to N1 pointing to N2. I
want to make sure the scripts in N2 run before the scripts in N1.
But in this case both nodes (N1 and N2) are executed with
execute_with_ssh() which makes the orchestration break, because N2 does not
have a sh key, etc.

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

RE: Openstack plugin

[Steve Baillargeon]

What is the purpose of the Validation interface with the creation and deletion 
operations?
What workflow invokes those operations?

Thanks

Regards
Steve B

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Sunday, October 01, 2017 10:24 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Openstack plugin

Hi,

The cloudify openstack plugin has validation interfaces, Do they still hold 
good with ARIA with the use of adapter ?


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co]
Sent: Tuesday, August 08, 2017 5:33 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

For future readers of this thread, you can find an example on how to use this 
plugin here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/OpenStack+Hello+World

On Wed, Jul 26, 2017 at 6:25 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> you got most of it right :). You would need to follow these steps:
> 1. Install the adapter
> 2. Using ARIA, Install the wagon of the plugin.
> 3. Utilize the corresponding plugin.yaml found in the repo in your 
> templates.
>
> The reason the adapter does not come with ARIA is it's an adapter for 
> Cloudify based plugins, and hence it cannot be a part of the ARIA code 
> base.
> In the future ARIA would have its own plugins, and will not need the 
> adapter for Cloudify plugins.
>
> On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Max,
> >
> > IF I understand correctly,
> > we need to take the cloudify openstack plugin and replace 
> > the plugin.yaml with the one found in the repo.
> > Install this updated plugin with ARIA
> > Install the adapter found in this repo to make use of the 
> > plugin
> >
> > Am I right with my understanding ?  Also why this adapter is not 
> > included with ARIA by default ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, July 24, 2017 9:17 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > Hey DJ,
> >
> > Basically ARIA indeed has an adapter for cloudify-based plugins. 
> > This enables support for any cloudify plugins (Provided the 
> > plugin.yaml has
> been
> > translated into TOSCA). Note that later on, ARIA will have native 
> > plugins and will not rely on kindness of Cloudify.
> > You can find the Cloudify repo here
> > <https://github.com/cloudify-cosmo/aria-extension-cloudify>. It 
> > holds some examples, the plugin.yaml and the adapter itself.
> >
> > On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Thanks for the information Tal.  What is the adapter which you are 
> > > referring here ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Friday, July 21, 2017 8:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Openstack plugin
> > >
> > > ARIA has an adapter that can use Cloudify plugins, and it has been 
> > > tested successfully with both OpenStack and AWS so far.
> > >
> > > Unfortunately there are no instructions on how to use it. I know 
> > > just the right person to write it and will ask him to do so. :)
> > >
> > > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Will openstack plugin be available as part of any ARIA release ?
> > > > Is this already been looked upon or in the backlog ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

RE: Openstack plugin

[D Jayachandran]

Hi,

The cloudify openstack plugin has validation interfaces, Do they still hold 
good with ARIA with the use of adapter ?


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Tuesday, August 08, 2017 5:33 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

For future readers of this thread, you can find an example on how to use this 
plugin here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/OpenStack+Hello+World

On Wed, Jul 26, 2017 at 6:25 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> you got most of it right :). You would need to follow these steps:
> 1. Install the adapter
> 2. Using ARIA, Install the wagon of the plugin.
> 3. Utilize the corresponding plugin.yaml found in the repo in your 
> templates.
>
> The reason the adapter does not come with ARIA is it's an adapter for 
> Cloudify based plugins, and hence it cannot be a part of the ARIA code 
> base.
> In the future ARIA would have its own plugins, and will not need the 
> adapter for Cloudify plugins.
>
> On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Max,
> >
> > IF I understand correctly,
> > we need to take the cloudify openstack plugin and replace 
> > the plugin.yaml with the one found in the repo.
> > Install this updated plugin with ARIA
> > Install the adapter found in this repo to make use of the 
> > plugin
> >
> > Am I right with my understanding ?  Also why this adapter is not 
> > included with ARIA by default ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, July 24, 2017 9:17 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > Hey DJ,
> >
> > Basically ARIA indeed has an adapter for cloudify-based plugins. 
> > This enables support for any cloudify plugins (Provided the 
> > plugin.yaml has
> been
> > translated into TOSCA). Note that later on, ARIA will have native 
> > plugins and will not rely on kindness of Cloudify.
> > You can find the Cloudify repo here
> > <https://github.com/cloudify-cosmo/aria-extension-cloudify>. It 
> > holds some examples, the plugin.yaml and the adapter itself.
> >
> > On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Thanks for the information Tal.  What is the adapter which you are 
> > > referring here ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Friday, July 21, 2017 8:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Openstack plugin
> > >
> > > ARIA has an adapter that can use Cloudify plugins, and it has been 
> > > tested successfully with both OpenStack and AWS so far.
> > >
> > > Unfortunately there are no instructions on how to use it. I know 
> > > just the right person to write it and will ask him to do so. :)
> > >
> > > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Will openstack plugin be available as part of any ARIA release ?
> > > > Is this already been looked upon or in the backlog ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

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

[Tal Liron]

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

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

[Ran Ziv]

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

[Ran Ziv]

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]

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

[Ran Ziv]

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

[Ran Ziv]

I actually think it still might be related to the issue I mentioned above :)
if the operation input isn't set with actual values, the node property
should take hold - but because of the bug I mentioned the operation input
receives empty yet still set values and therefore possibly overrides the
node properties.

On Thu, Aug 24, 2017 at 3:34 AM, DeWayne Filppi  wrote:

> Found it.  Turns out "openstack_config" in node properties is deprecated
> with extreme prejudice (IOW it doesn't work).  Putting it in the operation
> inputs makes it work.
>
> On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
>
> > Input files indeed look like that (as long as they have a .yaml suffix).
> >
> > If you do "aria services show -f" you can get a complete dump of the
> entire
> > model. Can you check that everything is correct there before we move on
> to
> > debugging the execution?
> >
> > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> > wrote:
> >
> > > Having trouble with inputs when trying to run the openstack helloworld.
> > I
> > > provide inputs that look like this:
> > >
> > > ssh_username: ubuntu
> > > external_network_name: public_net
> > > webserver_port: 8080
> > > private_key_path: ~/dfilppi-rs.pen
> > > image: some image id
> > > flavor: "2"
> > > openstack_config:
> > >   username: dewayne
> > >   password: xxx
> > >   tenant_name: dewayne-tenant
> > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> > >
> > > Openstack config map entry values all become empty strings in the
> > > execution.  Am I specifying it wrong?  There is no example inputs file
> to
> > > compare with, alas.
> > >
> >
>

Re: cloudify openstack plugin example

[DeWayne Filppi]

Found it.  Turns out "openstack_config" in node properties is deprecated
with extreme prejudice (IOW it doesn't work).  Putting it in the operation
inputs makes it work.

On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:

> Input files indeed look like that (as long as they have a .yaml suffix).
>
> If you do "aria services show -f" you can get a complete dump of the entire
> model. Can you check that everything is correct there before we move on to
> debugging the execution?
>
> On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> wrote:
>
> > Having trouble with inputs when trying to run the openstack helloworld.
> I
> > provide inputs that look like this:
> >
> > ssh_username: ubuntu
> > external_network_name: public_net
> > webserver_port: 8080
> > private_key_path: ~/dfilppi-rs.pen
> > image: some image id
> > flavor: "2"
> > openstack_config:
> >   username: dewayne
> >   password: xxx
> >   tenant_name: dewayne-tenant
> >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> >
> > Openstack config map entry values all become empty strings in the
> > execution.  Am I specifying it wrong?  There is no example inputs file to
> > compare with, alas.
> >
>

Re: cloudify openstack plugin example

[DeWayne Filppi]

I notice the example uses the deprecated 'openstack_config' property rather
than passing it to each operation.  Maybe that's it?

On Wed, Aug 23, 2017 at 3:29 PM, DeWayne Filppi  wrote:

> Actually, I see now at the bottom of the "show" output that at least the
> template inputs are getting through.  They don't somehow make it into the
> nodes though.
>
> On Wed, Aug 23, 2017 at 1:42 PM, DeWayne Filppi 
> wrote:
>
>> Probably not.  The example uses get_input
>>
>> On Wed, Aug 23, 2017 at 1:28 PM, Ran Ziv  wrote:
>>
>>> Might be related to this bug:
>>> https://issues.apache.org/jira/browse/ARIA-349
>>>
>>> Which was recently fixed in this PR:
>>> https://github.com/apache/incubator-ariatosca/commit/8981791
>>> a10f91cb4f99ff8c01fd6b130b470ffae
>>>
>>>
>>> On Wed, Aug 23, 2017 at 9:15 PM, DeWayne Filppi 
>>> wrote:
>>>
>>> > I see this related to inputs:
>>> >
>>> >  openstack_config: {'username': '', 'nova_url': '', 'tenant_name': '',
>>> > 'region': '', 'password': '', 'neutron_url': '', 'auth_url': ''}
>>> >
>>> > The model appears fine.  I'm just using the one directly from github.
>>> >
>>> >
>>> > On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
>>> >
>>> > > Input files indeed look like that (as long as they have a .yaml
>>> suffix).
>>> > >
>>> > > If you do "aria services show -f" you can get a complete dump of the
>>> > entire
>>> > > model. Can you check that everything is correct there before we move
>>> on
>>> > to
>>> > > debugging the execution?
>>> > >
>>> > > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi <
>>> dewa...@cloudify.co>
>>> > > wrote:
>>> > >
>>> > > > Having trouble with inputs when trying to run the openstack
>>> helloworld.
>>> > > I
>>> > > > provide inputs that look like this:
>>> > > >
>>> > > > ssh_username: ubuntu
>>> > > > external_network_name: public_net
>>> > > > webserver_port: 8080
>>> > > > private_key_path: ~/dfilppi-rs.pen
>>> > > > image: some image id
>>> > > > flavor: "2"
>>> > > > openstack_config:
>>> > > >   username: dewayne
>>> > > >   password: xxx
>>> > > >   tenant_name: dewayne-tenant
>>> > > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
>>> > > >
>>> > > > Openstack config map entry values all become empty strings in the
>>> > > > execution.  Am I specifying it wrong?  There is no example inputs
>>> file
>>> > to
>>> > > > compare with, alas.
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

Re: cloudify openstack plugin example

[DeWayne Filppi]

Actually, I see now at the bottom of the "show" output that at least the
template inputs are getting through.  They don't somehow make it into the
nodes though.

On Wed, Aug 23, 2017 at 1:42 PM, DeWayne Filppi  wrote:

> Probably not.  The example uses get_input
>
> On Wed, Aug 23, 2017 at 1:28 PM, Ran Ziv  wrote:
>
>> Might be related to this bug:
>> https://issues.apache.org/jira/browse/ARIA-349
>>
>> Which was recently fixed in this PR:
>> https://github.com/apache/incubator-ariatosca/commit/8981791
>> a10f91cb4f99ff8c01fd6b130b470ffae
>>
>>
>> On Wed, Aug 23, 2017 at 9:15 PM, DeWayne Filppi 
>> wrote:
>>
>> > I see this related to inputs:
>> >
>> >  openstack_config: {'username': '', 'nova_url': '', 'tenant_name': '',
>> > 'region': '', 'password': '', 'neutron_url': '', 'auth_url': ''}
>> >
>> > The model appears fine.  I'm just using the one directly from github.
>> >
>> >
>> > On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
>> >
>> > > Input files indeed look like that (as long as they have a .yaml
>> suffix).
>> > >
>> > > If you do "aria services show -f" you can get a complete dump of the
>> > entire
>> > > model. Can you check that everything is correct there before we move
>> on
>> > to
>> > > debugging the execution?
>> > >
>> > > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi > >
>> > > wrote:
>> > >
>> > > > Having trouble with inputs when trying to run the openstack
>> helloworld.
>> > > I
>> > > > provide inputs that look like this:
>> > > >
>> > > > ssh_username: ubuntu
>> > > > external_network_name: public_net
>> > > > webserver_port: 8080
>> > > > private_key_path: ~/dfilppi-rs.pen
>> > > > image: some image id
>> > > > flavor: "2"
>> > > > openstack_config:
>> > > >   username: dewayne
>> > > >   password: xxx
>> > > >   tenant_name: dewayne-tenant
>> > > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
>> > > >
>> > > > Openstack config map entry values all become empty strings in the
>> > > > execution.  Am I specifying it wrong?  There is no example inputs
>> file
>> > to
>> > > > compare with, alas.
>> > > >
>> > >
>> >
>>
>
>

Re: cloudify openstack plugin example

[DeWayne Filppi]

Probably not.  The example uses get_input

On Wed, Aug 23, 2017 at 1:28 PM, Ran Ziv  wrote:

> Might be related to this bug:
> https://issues.apache.org/jira/browse/ARIA-349
>
> Which was recently fixed in this PR:
> https://github.com/apache/incubator-ariatosca/commit/
> 8981791a10f91cb4f99ff8c01fd6b130b470ffae
>
>
> On Wed, Aug 23, 2017 at 9:15 PM, DeWayne Filppi 
> wrote:
>
> > I see this related to inputs:
> >
> >  openstack_config: {'username': '', 'nova_url': '', 'tenant_name': '',
> > 'region': '', 'password': '', 'neutron_url': '', 'auth_url': ''}
> >
> > The model appears fine.  I'm just using the one directly from github.
> >
> >
> > On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
> >
> > > Input files indeed look like that (as long as they have a .yaml
> suffix).
> > >
> > > If you do "aria services show -f" you can get a complete dump of the
> > entire
> > > model. Can you check that everything is correct there before we move on
> > to
> > > debugging the execution?
> > >
> > > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> > > wrote:
> > >
> > > > Having trouble with inputs when trying to run the openstack
> helloworld.
> > > I
> > > > provide inputs that look like this:
> > > >
> > > > ssh_username: ubuntu
> > > > external_network_name: public_net
> > > > webserver_port: 8080
> > > > private_key_path: ~/dfilppi-rs.pen
> > > > image: some image id
> > > > flavor: "2"
> > > > openstack_config:
> > > >   username: dewayne
> > > >   password: xxx
> > > >   tenant_name: dewayne-tenant
> > > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> > > >
> > > > Openstack config map entry values all become empty strings in the
> > > > execution.  Am I specifying it wrong?  There is no example inputs
> file
> > to
> > > > compare with, alas.
> > > >
> > >
> >
>

Re: cloudify openstack plugin example

[Ran Ziv]

Might be related to this bug:
https://issues.apache.org/jira/browse/ARIA-349

Which was recently fixed in this PR:
https://github.com/apache/incubator-ariatosca/commit/8981791a10f91cb4f99ff8c01fd6b130b470ffae


On Wed, Aug 23, 2017 at 9:15 PM, DeWayne Filppi  wrote:

> I see this related to inputs:
>
>  openstack_config: {'username': '', 'nova_url': '', 'tenant_name': '',
> 'region': '', 'password': '', 'neutron_url': '', 'auth_url': ''}
>
> The model appears fine.  I'm just using the one directly from github.
>
>
> On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
>
> > Input files indeed look like that (as long as they have a .yaml suffix).
> >
> > If you do "aria services show -f" you can get a complete dump of the
> entire
> > model. Can you check that everything is correct there before we move on
> to
> > debugging the execution?
> >
> > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> > wrote:
> >
> > > Having trouble with inputs when trying to run the openstack helloworld.
> > I
> > > provide inputs that look like this:
> > >
> > > ssh_username: ubuntu
> > > external_network_name: public_net
> > > webserver_port: 8080
> > > private_key_path: ~/dfilppi-rs.pen
> > > image: some image id
> > > flavor: "2"
> > > openstack_config:
> > >   username: dewayne
> > >   password: xxx
> > >   tenant_name: dewayne-tenant
> > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> > >
> > > Openstack config map entry values all become empty strings in the
> > > execution.  Am I specifying it wrong?  There is no example inputs file
> to
> > > compare with, alas.
> > >
> >
>

Re: cloudify openstack plugin example

[DeWayne Filppi]

I see this related to inputs:

 openstack_config: {'username': '', 'nova_url': '', 'tenant_name': '',
'region': '', 'password': '', 'neutron_url': '', 'auth_url': ''}

The model appears fine.  I'm just using the one directly from github.


On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:

> Input files indeed look like that (as long as they have a .yaml suffix).
>
> If you do "aria services show -f" you can get a complete dump of the entire
> model. Can you check that everything is correct there before we move on to
> debugging the execution?
>
> On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> wrote:
>
> > Having trouble with inputs when trying to run the openstack helloworld.
> I
> > provide inputs that look like this:
> >
> > ssh_username: ubuntu
> > external_network_name: public_net
> > webserver_port: 8080
> > private_key_path: ~/dfilppi-rs.pen
> > image: some image id
> > flavor: "2"
> > openstack_config:
> >   username: dewayne
> >   password: xxx
> >   tenant_name: dewayne-tenant
> >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> >
> > Openstack config map entry values all become empty strings in the
> > execution.  Am I specifying it wrong?  There is no example inputs file to
> > compare with, alas.
> >
>

Re: cloudify openstack plugin example

[Tal Liron]

Input files indeed look like that (as long as they have a .yaml suffix).

If you do "aria services show -f" you can get a complete dump of the entire
model. Can you check that everything is correct there before we move on to
debugging the execution?

On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
wrote:

> Having trouble with inputs when trying to run the openstack helloworld.  I
> provide inputs that look like this:
>
> ssh_username: ubuntu
> external_network_name: public_net
> webserver_port: 8080
> private_key_path: ~/dfilppi-rs.pen
> image: some image id
> flavor: "2"
> openstack_config:
>   username: dewayne
>   password: xxx
>   tenant_name: dewayne-tenant
>   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
>
> Openstack config map entry values all become empty strings in the
> execution.  Am I specifying it wrong?  There is no example inputs file to
> compare with, alas.
>

cloudify openstack plugin example

[DeWayne Filppi]

Having trouble with inputs when trying to run the openstack helloworld.  I
provide inputs that look like this:

ssh_username: ubuntu
external_network_name: public_net
webserver_port: 8080
private_key_path: ~/dfilppi-rs.pen
image: some image id
flavor: "2"
openstack_config:
  username: dewayne
  password: xxx
  tenant_name: dewayne-tenant
  auth_url: https://rackspace-api.gigaspaces.com:5000/v3

Openstack config map entry values all become empty strings in the
execution.  Am I specifying it wrong?  There is no example inputs file to
compare with, alas.

Re: Openstack plugin

[Ran Ziv]

For future readers of this thread, you can find an example on how to use
this plugin here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/OpenStack+Hello+World

On Wed, Jul 26, 2017 at 6:25 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> you got most of it right :). You would need to follow these steps:
> 1. Install the adapter
> 2. Using ARIA, Install the wagon of the plugin.
> 3. Utilize the corresponding plugin.yaml found in the repo in your
> templates.
>
> The reason the adapter does not come with ARIA is it's an adapter for
> Cloudify based plugins, and hence it cannot be a part of the ARIA code
> base.
> In the future ARIA would have its own plugins, and will not need the
> adapter for Cloudify plugins.
>
> On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Max,
> >
> > IF I understand correctly,
> > we need to take the cloudify openstack plugin and replace the
> > plugin.yaml with the one found in the repo.
> > Install this updated plugin with ARIA
> > Install the adapter found in this repo to make use of the plugin
> >
> > Am I right with my understanding ?  Also why this adapter is not included
> > with ARIA by default ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, July 24, 2017 9:17 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > Hey DJ,
> >
> > Basically ARIA indeed has an adapter for cloudify-based plugins. This
> > enables support for any cloudify plugins (Provided the plugin.yaml has
> been
> > translated into TOSCA). Note that later on, ARIA will have native plugins
> > and will not rely on kindness of Cloudify.
> > You can find the Cloudify repo here
> > <https://github.com/cloudify-cosmo/aria-extension-cloudify>. It holds
> > some examples, the plugin.yaml and the adapter itself.
> >
> > On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Thanks for the information Tal.  What is the adapter which you are
> > > referring here ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Friday, July 21, 2017 8:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Openstack plugin
> > >
> > > ARIA has an adapter that can use Cloudify plugins, and it has been
> > > tested successfully with both OpenStack and AWS so far.
> > >
> > > Unfortunately there are no instructions on how to use it. I know just
> > > the right person to write it and will ask him to do so. :)
> > >
> > > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Will openstack plugin be available as part of any ARIA release ?
> > > > Is this already been looked upon or in the backlog ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

Re: Openstack plugin

[Maxim Orlov]

you got most of it right :). You would need to follow these steps:
1. Install the adapter
2. Using ARIA, Install the wagon of the plugin.
3. Utilize the corresponding plugin.yaml found in the repo in your
templates.

The reason the adapter does not come with ARIA is it's an adapter for
Cloudify based plugins, and hence it cannot be a part of the ARIA code
base.
In the future ARIA would have its own plugins, and will not need the
adapter for Cloudify plugins.

On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Max,
>
> IF I understand correctly,
> we need to take the cloudify openstack plugin and replace the
> plugin.yaml with the one found in the repo.
> Install this updated plugin with ARIA
> Install the adapter found in this repo to make use of the plugin
>
> Am I right with my understanding ?  Also why this adapter is not included
> with ARIA by default ?
>
>
> Regards,
> DJ
> -Original Message-
> From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> Sent: Monday, July 24, 2017 9:17 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Openstack plugin
>
> Hey DJ,
>
> Basically ARIA indeed has an adapter for cloudify-based plugins. This
> enables support for any cloudify plugins (Provided the plugin.yaml has been
> translated into TOSCA). Note that later on, ARIA will have native plugins
> and will not rely on kindness of Cloudify.
> You can find the Cloudify repo here
> <https://github.com/cloudify-cosmo/aria-extension-cloudify>. It holds
> some examples, the plugin.yaml and the adapter itself.
>
> On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Thanks for the information Tal.  What is the adapter which you are
> > referring here ?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@gigaspaces.com]
> > Sent: Friday, July 21, 2017 8:37 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > ARIA has an adapter that can use Cloudify plugins, and it has been
> > tested successfully with both OpenStack and AWS so far.
> >
> > Unfortunately there are no instructions on how to use it. I know just
> > the right person to write it and will ask him to do so. :)
> >
> > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi,
> > >
> > > Will openstack plugin be available as part of any ARIA release ?
> > > Is this already been looked upon or in the backlog ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

RE: Openstack plugin

[D Jayachandran]

Hi Max,

IF I understand correctly, 
we need to take the cloudify openstack plugin and replace the 
plugin.yaml with the one found in the repo.
Install this updated plugin with ARIA
Install the adapter found in this repo to make use of the plugin

Am I right with my understanding ?  Also why this adapter is not included with 
ARIA by default ?


Regards,
DJ
-Original Message-
From: Maxim Orlov [mailto:ma...@gigaspaces.com] 
Sent: Monday, July 24, 2017 9:17 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

Hey DJ,

Basically ARIA indeed has an adapter for cloudify-based plugins. This enables 
support for any cloudify plugins (Provided the plugin.yaml has been translated 
into TOSCA). Note that later on, ARIA will have native plugins and will not 
rely on kindness of Cloudify.
You can find the Cloudify repo here
<https://github.com/cloudify-cosmo/aria-extension-cloudify>. It holds some 
examples, the plugin.yaml and the adapter itself.

On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Thanks for the information Tal.  What is the adapter which you are 
> referring here ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Friday, July 21, 2017 8:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Openstack plugin
>
> ARIA has an adapter that can use Cloudify plugins, and it has been 
> tested successfully with both OpenStack and AWS so far.
>
> Unfortunately there are no instructions on how to use it. I know just 
> the right person to write it and will ask him to do so. :)
>
> On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Will openstack plugin be available as part of any ARIA release ?
> > Is this already been looked upon or in the backlog ?
> >
> >
> > Regards,
> > DJ
> >
>

Re: Openstack plugin

[Maxim Orlov]

Hey DJ,

Basically ARIA indeed has an adapter for cloudify-based plugins. This
enables support for any cloudify plugins (Provided the plugin.yaml has been
translated into TOSCA). Note that later on, ARIA will have native plugins
and will not rely on kindness of Cloudify.
You can find the Cloudify repo here
<https://github.com/cloudify-cosmo/aria-extension-cloudify>. It holds some
examples, the plugin.yaml and the adapter itself.

On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Thanks for the information Tal.  What is the adapter which you are
> referring here ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Friday, July 21, 2017 8:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Openstack plugin
>
> ARIA has an adapter that can use Cloudify plugins, and it has been tested
> successfully with both OpenStack and AWS so far.
>
> Unfortunately there are no instructions on how to use it. I know just the
> right person to write it and will ask him to do so. :)
>
> On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Will openstack plugin be available as part of any ARIA release ?
> > Is this already been looked upon or in the backlog ?
> >
> >
> > Regards,
> > DJ
> >
>

RE: Openstack plugin

[D Jayachandran]

Thanks for the information Tal.  What is the adapter which you are referring 
here ?

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Friday, July 21, 2017 8:37 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

ARIA has an adapter that can use Cloudify plugins, and it has been tested 
successfully with both OpenStack and AWS so far.

Unfortunately there are no instructions on how to use it. I know just the right 
person to write it and will ask him to do so. :)

On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Will openstack plugin be available as part of any ARIA release ?
> Is this already been looked upon or in the backlog ?
>
>
> Regards,
> DJ
>

Re: Openstack plugin

[Tal Liron]

ARIA has an adapter that can use Cloudify plugins, and it has been tested
successfully with both OpenStack and AWS so far.

Unfortunately there are no instructions on how to use it. I know just the
right person to write it and will ask him to do so. :)

On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Will openstack plugin be available as part of any ARIA release ?
> Is this already been looked upon or in the backlog ?
>
>
> Regards,
> DJ
>

Openstack plugin

[D Jayachandran]

Hi,

Will openstack plugin be available as part of any ARIA release ?
Is this already been looked upon or in the backlog ?


Regards,
DJ