date:20170712

Re: workflow runner error

2017-07-12 Thread DeWayne Filppi

Yes, that absolutely could be the case.  I'll try a reset.

On Wed, Jul 12, 2017 at 3:40 PM, Ran Ziv  wrote:

> Could it be that you first used an older, non-release version of ARIA, and
> then used 0.1.0 without first resetting your ARIA working directory (e.g.
> "aria reset -f")?
>
> The task table should indeed have the said column, as can be seen here:
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 0/aria/modeling/orchestration.py#L410
>
>
> If this is not the cause for your problem, perhaps attach the workflow in
> question as well, since the problem occurs during the workflow compilation
> phase.
>
>
>
> On Wed, Jul 12, 2017 at 7:41 PM, DeWayne Filppi 
> wrote:
>
> > When executing this:
> >
> >   runner = WorkflowRunner(model_storage, resource_storage,
> plugin_manager,
> >   service_id = service_id,
> >   workflow_name = workflow_name,
> >   inputs = inputs,
> >   executor = executor,
> >   task_max_attempts =  task_max_attempts,
> >   task_retry_interval = task_retry_interval)
> >
> > I get this:
> >
> >   File
> > "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> > workflow_runner.py",
> > line 102, in __init__
> > compiler.compile(self._tasks_graph)
> >   File
> > "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> > workflows/core/graph_compiler.py",
> > line 44, in compile
> > start_stub_type, depends_on, self._start_graph_suffix(task_graph.id
> ),
> > task_graph.name,
> >   File
> > "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> > workflows/core/graph_compiler.py",
> > line 80, in _create_stub_task
> > self._ctx.model.task.put(model_task)
> >   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
> > line 124, in put
> > self._safe_commit()
> >   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
> > line 187, in _safe_commit
> > raise exceptions.StorageError('SQL Storage error:
> {0}'.format(str(e)))
> > StorageError: SQL Storage error: (sqlite3.OperationalError) *table task
> has
> > no column named interface_name* [SQL: u'INSERT INTO task (name, status,
> > due_at, started_at, ended_at, attempts_count, function, max_attempts,
> > retry_interval, ignore_failure, interface_name, operation_name, _api_id,
> > _executor, _context_cls, _stub_type, plugin_fk, execution_fk,
> > relationship_fk, node_fk) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?,
> > ?, ?, ?, ?, ?, ?)'] [parameters:
> > ('install.fdf601e4-4d14-4ddf-9e57-f2c09b5293f7', 'pending', '2017-07-10
> > 04:14:20.892673', None, None, 1, None, 1, 0.0, 0, None, None, None,
> > , None,
> > 'start_workflow', None, 1, None, None)]
> >
> > I'm running 0.1.0.
> >
> > -- DeWayne
> >
> > --
> > DeWayne Filppi, Director, Solutions Architect 
> > --
> > M: +17145121706 http://cloudify.co @dfilppi
> > 
> > 
> > 
> > 
> >
>



-- 
DeWayne Filppi, Director, Solutions Architect 
--
M: +17145121706 http://cloudify.co @dfilppi

Re: workflow runner error

2017-07-12 Thread Ran Ziv

Could it be that you first used an older, non-release version of ARIA, and
then used 0.1.0 without first resetting your ARIA working directory (e.g.
"aria reset -f")?

The task table should indeed have the said column, as can be seen here:
https://github.com/apache/incubator-ariatosca/blob/0.1.0/aria/modeling/orchestration.py#L410


If this is not the cause for your problem, perhaps attach the workflow in
question as well, since the problem occurs during the workflow compilation
phase.



On Wed, Jul 12, 2017 at 7:41 PM, DeWayne Filppi 
wrote:

> When executing this:
>
>   runner = WorkflowRunner(model_storage, resource_storage, plugin_manager,
>   service_id = service_id,
>   workflow_name = workflow_name,
>   inputs = inputs,
>   executor = executor,
>   task_max_attempts =  task_max_attempts,
>   task_retry_interval = task_retry_interval)
>
> I get this:
>
>   File
> "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> workflow_runner.py",
> line 102, in __init__
> compiler.compile(self._tasks_graph)
>   File
> "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> workflows/core/graph_compiler.py",
> line 44, in compile
> start_stub_type, depends_on, self._start_graph_suffix(task_graph.id),
> task_graph.name,
>   File
> "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> workflows/core/graph_compiler.py",
> line 80, in _create_stub_task
> self._ctx.model.task.put(model_task)
>   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
> line 124, in put
> self._safe_commit()
>   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
> line 187, in _safe_commit
> raise exceptions.StorageError('SQL Storage error: {0}'.format(str(e)))
> StorageError: SQL Storage error: (sqlite3.OperationalError) *table task has
> no column named interface_name* [SQL: u'INSERT INTO task (name, status,
> due_at, started_at, ended_at, attempts_count, function, max_attempts,
> retry_interval, ignore_failure, interface_name, operation_name, _api_id,
> _executor, _context_cls, _stub_type, plugin_fk, execution_fk,
> relationship_fk, node_fk) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?, ?)'] [parameters:
> ('install.fdf601e4-4d14-4ddf-9e57-f2c09b5293f7', 'pending', '2017-07-10
> 04:14:20.892673', None, None, 1, None, 1, 0.0, 0, None, None, None,
> , None,
> 'start_workflow', None, 1, None, None)]
>
> I'm running 0.1.0.
>
> -- DeWayne
>
> --
> DeWayne Filppi, Director, Solutions Architect 
> --
> M: +17145121706 http://cloudify.co @dfilppi
> 
> 
> 
> 
>

async execution/task management

2017-07-12 Thread DeWayne Filppi

I need to:

1. Launch an execution asynchronously
2. View the execution status asynchronously
3. Cancel the execution asynchronously

I'm assuming the execution id is the key linking these.  Is this kind of
operation supported by the library, or is it assumed that the caller will
manage such ( e.g. by calling synchronous library calls in their own
threads and managing the thread externally)?  If possible with the library,
is there an example?

-- DeWayne

workflow runner error

2017-07-12 Thread DeWayne Filppi

When executing this:

  runner = WorkflowRunner(model_storage, resource_storage, plugin_manager,
  service_id = service_id,
  workflow_name = workflow_name,
  inputs = inputs,
  executor = executor,
  task_max_attempts =  task_max_attempts,
  task_retry_interval = task_retry_interval)

I get this:

  File
"/home/vagrant/src/incubator-ariatosca/aria/orchestrator/workflow_runner.py",
line 102, in __init__
compiler.compile(self._tasks_graph)
  File
"/home/vagrant/src/incubator-ariatosca/aria/orchestrator/workflows/core/graph_compiler.py",
line 44, in compile
start_stub_type, depends_on, self._start_graph_suffix(task_graph.id),
task_graph.name,
  File
"/home/vagrant/src/incubator-ariatosca/aria/orchestrator/workflows/core/graph_compiler.py",
line 80, in _create_stub_task
self._ctx.model.task.put(model_task)
  File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
line 124, in put
self._safe_commit()
  File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
line 187, in _safe_commit
raise exceptions.StorageError('SQL Storage error: {0}'.format(str(e)))
StorageError: SQL Storage error: (sqlite3.OperationalError) *table task has
no column named interface_name* [SQL: u'INSERT INTO task (name, status,
due_at, started_at, ended_at, attempts_count, function, max_attempts,
retry_interval, ignore_failure, interface_name, operation_name, _api_id,
_executor, _context_cls, _stub_type, plugin_fk, execution_fk,
relationship_fk, node_fk) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?)'] [parameters:
('install.fdf601e4-4d14-4ddf-9e57-f2c09b5293f7', 'pending', '2017-07-10
04:14:20.892673', None, None, 1, None, 1, 0.0, 0, None, None, None,
, None,
'start_workflow', None, 1, None, None)]

I'm running 0.1.0.

-- DeWayne

-- 
DeWayne Filppi, Director, Solutions Architect 
--
M: +17145121706 http://cloudify.co @dfilppi

Re: workflow list API

2017-07-12 Thread DeWayne Filppi

I first noticed it working with the API call, and then tried the CLI to
confirm I wasn't screwing up the API call.  From the perspective of the
API, the built-ins should definitely be listed.  WIth the CLI, maybe only
with a "-a" or something.  My argument is mainly completeness.  If I call a
function that returns the list of workflows, all the workflows should be
listed.  If you're going to hide built in workflows, then make the API
property "user_workflows".  Better yet have both.   This is at the
"service" level.  Now when querying the model, it makes sense to only list
workflows defined in the service template of course.

On Tue, Jul 11, 2017 at 10:33 PM, Tal Liron  wrote:

> Do you mean the CLI command?
>
> We actually have talked about this in the past, and the question was just
> how much the "built-in" (normative lifecycle) workflows should be
> considered as equivalent to any arbitrary workflow. Can you think of
> arguments for or against this thinking?
>
> On Wed, Jul 12, 2017 at 12:52 AM, DeWayne Filppi 
> wrote:
>
> > The workflow list API call doesn't return "normative" workflows (like
> > "install").  Intentional?
> >
> > -- DeWayne
> >
>

-- 
DeWayne Filppi, Director, Solutions Architect 
--
M: +17145121706 http://cloudify.co @dfilppi

Re: Missing support for type qualified name

2017-07-12 Thread Ran Ziv

Thanks DJ, I noticed :) Actually, Maxim has already started reviewing the
PR.

On Wed, Jul 12, 2017 at 9:15 AM, D Jayachandran  wrote:

> Hi Ran,
>
> I had some issue with committing changes to this PR. I closed the PR and
> opened a new one.
> Now the CI tests and build jobs are successful. Kindly check and let me
> know if its fine.
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Tuesday, July 11, 2017 2:07 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Missing support for type qualified name
>
> Hi DJ,
>
> You shouldn't create another PR - the current should simply update when
> you push your changes into the relevant branch in your fork (in this case,
> the master branch).
>
> At the moment I see 4 commits on the PR, and it seems to still be broken.
> If it hasn't updated yet, please update it.
> If it is already updated, please have a look at the errors, or let me know
> if you need any help with debugging it :)
>
> Ran
>
> On Tue, Jul 11, 2017 at 10:53 AM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Ran,
> >
> > I fixed those issues. I have commited those with changes , am not sure
> > if I have to make another PR ?
> > Could you please advice me here ?
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > Sent: Friday, July 07, 2017 3:28 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Missing support for type qualified name
> >
> > Hi DJ,
> >
> > Thank you for creating this pull request.
> > I've added you as a Contributor (role) on JIRA, so you can now be
> > assigned to ARIA issues. I've assigned you to ARIA-277 as well.
> >
> > Regarding the PR itself, it seems to be currently failing some CI tests.
> > Please see these links:
> > https://github.com/apache/incubator-ariatosca/pull/179
> > https://travis-ci.org/apache/incubator-ariatosca/builds/
> > 251017348?utm_source=github_status_medium=notification
> > https://ci.appveyor.com/project/ApacheSoftwareFoundation/
> > incubator-ariatosca/build/1.0.2410
> >
> >
> > Let me know if you need any help trying to debug or figure out these
> > issues
> > :)
> >
> > Ran
> >
> > On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv  wrote:
> >
> > > Thanks DJ.
> > >
> > > Note that in order for the project to be able to accept your pull
> > > request, you'd first have to sign up Apache's ICLA agreement.
> > > See more here .
> > >
> > > Ran
> > >
> > > On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran <
> > > d.jayachand...@ericsson.com> wrote:
> > >
> > >> Hi Ran/Tal,
> > >>
> > >> Thanks for the confirmation. I have created a JIRA issue
> > >> https://issues.apache.org/jira/browse/ARIA-277
> > >> We will let you know when we fork and make a pull request for this.
> > >>
> > >> Regards,
> > >> DJ
> > >> -Original Message-
> > >> From: Tal Liron [mailto:t...@gigaspaces.com]
> > >> Sent: Thursday, June 08, 2017 11:47 PM
> > >> To: dev@ariatosca.incubator.apache.org
> > >> Subject: Re: Missing support for type qualified name
> > >>
> > >> Thanks, DJ. This was on the list of things to do but we indeed
> > >> forgot to create a JIRA for it...
> > >>
> > >> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv  wrote:
> > >>
> > >> > Hi DJ,
> > >> >
> > >> > Sounds good. Feel free to create a new JIRA yourself!  And thanks
> > >> > for posting on the dev list before creating this issue.
> > >> > One small note, I'd personally think of this as a "story" rather
> > >> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and
> > >> > we're familiar with several other missing spec sections
> > >> > implementations at
> > >> the moment.
> > >> >
> > >> > Let me know if you need any help.
> > >> > Tal might have more to add on this (Type qualified name) as well.
> > >> >
> > >> > Thank you
> > >> > Ran
> > >> >
> > >> >
> > >> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran <
> > >> > d.jayachand...@ericsson.com>
> > >> > wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > TOSCA Simple Yaml 1.0 profile specification supports usage of
> > >> > > the following Namespace Alias
> > >> > >
> > >> > >   1.  Shorthand Name
> > >> > >   2.  Type Qualified Name
> > >> > >   3.  Type URI
> > >> > >
> > >> > > ARIA currently supports only "Shorthand Name" and "Type URI".
> > >> > > The support for "Type Qualified Name" is missing which is
> > >> > > required to adhere with the TOSCA Simple yaml 1.0
> > >> > > specifications. Could this be considered as bug
> > >> > and a
> > >> > > JIRA issue opened for this ?
> > >> > > We would like to start our contribution with this.
> > >> > >
> > >> > >
> > >> > > Regards,
> > >> > > DJ
> > >> > >
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Tal Liron
> > >> Senior Engineer
> > >> t...@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> > >>

RE: Missing support for type qualified name

2017-07-12 Thread D Jayachandran

Hi Ran,

I had some issue with committing changes to this PR. I closed the PR and opened 
a new one. 
Now the CI tests and build jobs are successful. Kindly check and let me know if 
its fine.

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Tuesday, July 11, 2017 2:07 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Missing support for type qualified name

Hi DJ,

You shouldn't create another PR - the current should simply update when you 
push your changes into the relevant branch in your fork (in this case, the 
master branch).

At the moment I see 4 commits on the PR, and it seems to still be broken.
If it hasn't updated yet, please update it.
If it is already updated, please have a look at the errors, or let me know if 
you need any help with debugging it :)

Ran

On Tue, Jul 11, 2017 at 10:53 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi Ran,
>
> I fixed those issues. I have commited those with changes , am not sure 
> if I have to make another PR ?
> Could you please advice me here ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Friday, July 07, 2017 3:28 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Missing support for type qualified name
>
> Hi DJ,
>
> Thank you for creating this pull request.
> I've added you as a Contributor (role) on JIRA, so you can now be 
> assigned to ARIA issues. I've assigned you to ARIA-277 as well.
>
> Regarding the PR itself, it seems to be currently failing some CI tests.
> Please see these links:
> https://github.com/apache/incubator-ariatosca/pull/179
> https://travis-ci.org/apache/incubator-ariatosca/builds/
> 251017348?utm_source=github_status_medium=notification
> https://ci.appveyor.com/project/ApacheSoftwareFoundation/
> incubator-ariatosca/build/1.0.2410
>
>
> Let me know if you need any help trying to debug or figure out these 
> issues
> :)
>
> Ran
>
> On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv  wrote:
>
> > Thanks DJ.
> >
> > Note that in order for the project to be able to accept your pull 
> > request, you'd first have to sign up Apache's ICLA agreement.
> > See more here .
> >
> > Ran
> >
> > On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com> wrote:
> >
> >> Hi Ran/Tal,
> >>
> >> Thanks for the confirmation. I have created a JIRA issue
> >> https://issues.apache.org/jira/browse/ARIA-277
> >> We will let you know when we fork and make a pull request for this.
> >>
> >> Regards,
> >> DJ
> >> -Original Message-
> >> From: Tal Liron [mailto:t...@gigaspaces.com]
> >> Sent: Thursday, June 08, 2017 11:47 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: Missing support for type qualified name
> >>
> >> Thanks, DJ. This was on the list of things to do but we indeed 
> >> forgot to create a JIRA for it...
> >>
> >> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv  wrote:
> >>
> >> > Hi DJ,
> >> >
> >> > Sounds good. Feel free to create a new JIRA yourself!  And thanks 
> >> > for posting on the dev list before creating this issue.
> >> > One small note, I'd personally think of this as a "story" rather 
> >> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and 
> >> > we're familiar with several other missing spec sections 
> >> > implementations at
> >> the moment.
> >> >
> >> > Let me know if you need any help.
> >> > Tal might have more to add on this (Type qualified name) as well.
> >> >
> >> > Thank you
> >> > Ran
> >> >
> >> >
> >> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran < 
> >> > d.jayachand...@ericsson.com>
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > TOSCA Simple Yaml 1.0 profile specification supports usage of 
> >> > > the following Namespace Alias
> >> > >
> >> > >   1.  Shorthand Name
> >> > >   2.  Type Qualified Name
> >> > >   3.  Type URI
> >> > >
> >> > > ARIA currently supports only "Shorthand Name" and "Type URI". 
> >> > > The support for "Type Qualified Name" is missing which is 
> >> > > required to adhere with the TOSCA Simple yaml 1.0 
> >> > > specifications. Could this be considered as bug
> >> > and a
> >> > > JIRA issue opened for this ?
> >> > > We would like to start our contribution with this.
> >> > >
> >> > >
> >> > > Regards,
> >> > > DJ
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Tal Liron
> >> Senior Engineer
> >> t...@gigaspaces.com | +1 (773) 828-9339 Cloudify | 
> >> http://getcloudify.org 
> >>  >> m=email_campaign=general_signature>
> >>
> >> 
> >> 
> >>     cosmo>
> >> [image: Azure Webinar]
> >>  >> webinar.html?utm_source=signaturesatori_medium=
> >>

Re: workflow list API

2017-07-12 Thread Ran Ziv

There's actually a JIRA issue for it:
https://issues.apache.org/jira/browse/ARIA-246

Although, as Tal's mentioned, we've never been 100% certain yet about what
should be the behavior here.


On Wed, Jul 12, 2017 at 8:33 AM, Tal Liron  wrote:

> Do you mean the CLI command?
>
> We actually have talked about this in the past, and the question was just
> how much the "built-in" (normative lifecycle) workflows should be
> considered as equivalent to any arbitrary workflow. Can you think of
> arguments for or against this thinking?
>
> On Wed, Jul 12, 2017 at 12:52 AM, DeWayne Filppi 
> wrote:
>
> > The workflow list API call doesn't return "normative" workflows (like
> > "install").  Intentional?
> >
> > -- DeWayne
> >
>

Re: workflow runner error

Re: workflow runner error

async execution/task management

workflow runner error

Re: workflow list API

Re: Missing support for type qualified name

RE: Missing support for type qualified name

Re: workflow list API

8 matches

Site Navigation

Mail list logo

Footer information