Re: [DISCUSS] Move Aria Tosca to Reporting Group 1

2016-11-01 Thread Ran Ziv
No objections here.

On Wed, Nov 2, 2016 at 5:09 AM, Suneel Marthi 
wrote:

> +1 for the move.  But we still do file the November report correct? and the
> next report would be due Jan 2017.
>
>
>
> On Tue, Nov 1, 2016 at 10:36 PM, John D. Ament 
> wrote:
>
> > Hey guys
> >
> > I typically serve as incubator report manager.  Boring job, but someone
> has
> > to do it.  Anyways, there's a slight imbalance between the reporting
> groups
> > (see [1]).  Since we're still early, I wanted to propose moving AriaTosca
> > from Reporting Group to Reporting Group 1.  Its a new podling, so it
> > shouldn't impact too much right now.
> >
> > This means your quarterly reports would be January, April, July, October.
> > Any concerns?
> >
> > John
> >
> > [1]: http://incubator.apache.org/report-groups.txt
> >
>


Re: JIRA Issue Scheme

2016-11-01 Thread Ran Ziv
Yup, I completely understand.
It did however take that first time you pointed it out for me to realize
this though, and it's simply that the JIRA issue had been created before
then :)
I'll make sure all future communication goes through the mailing list.

On Wed, Nov 2, 2016 at 4:29 AM, John D. Ament  wrote:

> Hi Ran,
>
> Thanks for the insight.  The biggest I'm trying to point out is to have
> open discussions on the mailing lists when making these types of
> decisions.  I get that you guys at Gigaspaces are colocated and probably
> talked about this in your office - would be good to also have the
> discussion here. At some point I hope Aria grows beyond Gigaspaces
> employees and in order for this to be a true team of individuals not just
> representing corporate interests, those discussions are intended to happen
> on the ML.
>
> John
>
> On Sun, Oct 30, 2016 at 6:30 PM Ran Ziv  wrote:
>
> > The reason we asked for this is because we wanted to simplify some of the
> > JIRA mechanisms (screens, issues) but with only requiring minimal changes
> > from the defaults.
> >
> > From my experience having too many issue types makes it confusing for
> issue
> > reporters to choose the right one (e.g. "story" vs "improvement").
> >
> > It's true that Documentation specifically is a valid type, but I wanted
> to
> > ask for an existing issue types scheme rather than ask for the creation
> of
> > a new one (partially because I was hoping for this to help in having this
> > issue be dealt with quickly, which hasn't quite proven to be the case..).
> > Under the current scheme, the right type for a documentation issue would
> be
> > "Task", which seems fine to me, but I don't really feel too strongly
> about
> > it either way.
> >
> > I do think types such as "test", "wish", "improvement" etc. are
> problematic
> > though, and would rather not have them around :)
> >
> >
> >
> >
> > On Sun, Oct 30, 2016 at 5:59 PM, John D. Ament 
> > wrote:
> >
> > > I just saw this ticket in the INFRA backlog -
> > > https://issues.apache.org/jira/browse/INFRA-12733
> > >
> > > Just wondering, was this discussed on the ML?  I didn't see it, and I
> > would
> > > recommend leaving in ticket types like documentation.
> > >
> >
>


Re: [DISCUSS] Move Aria Tosca to Reporting Group 1

2016-11-01 Thread Suneel Marthi
+1 for the move.  But we still do file the November report correct? and the
next report would be due Jan 2017.



On Tue, Nov 1, 2016 at 10:36 PM, John D. Ament 
wrote:

> Hey guys
>
> I typically serve as incubator report manager.  Boring job, but someone has
> to do it.  Anyways, there's a slight imbalance between the reporting groups
> (see [1]).  Since we're still early, I wanted to propose moving AriaTosca
> from Reporting Group to Reporting Group 1.  Its a new podling, so it
> shouldn't impact too much right now.
>
> This means your quarterly reports would be January, April, July, October.
> Any concerns?
>
> John
>
> [1]: http://incubator.apache.org/report-groups.txt
>


[DISCUSS] Move Aria Tosca to Reporting Group 1

2016-11-01 Thread John D. Ament
Hey guys

I typically serve as incubator report manager.  Boring job, but someone has
to do it.  Anyways, there's a slight imbalance between the reporting groups
(see [1]).  Since we're still early, I wanted to propose moving AriaTosca
from Reporting Group to Reporting Group 1.  Its a new podling, so it
shouldn't impact too much right now.

This means your quarterly reports would be January, April, July, October.
Any concerns?

John

[1]: http://incubator.apache.org/report-groups.txt


Re: JIRA Issue Scheme

2016-11-01 Thread John D. Ament
Hi Ran,

Thanks for the insight.  The biggest I'm trying to point out is to have
open discussions on the mailing lists when making these types of
decisions.  I get that you guys at Gigaspaces are colocated and probably
talked about this in your office - would be good to also have the
discussion here. At some point I hope Aria grows beyond Gigaspaces
employees and in order for this to be a true team of individuals not just
representing corporate interests, those discussions are intended to happen
on the ML.

John

On Sun, Oct 30, 2016 at 6:30 PM Ran Ziv  wrote:

> The reason we asked for this is because we wanted to simplify some of the
> JIRA mechanisms (screens, issues) but with only requiring minimal changes
> from the defaults.
>
> From my experience having too many issue types makes it confusing for issue
> reporters to choose the right one (e.g. "story" vs "improvement").
>
> It's true that Documentation specifically is a valid type, but I wanted to
> ask for an existing issue types scheme rather than ask for the creation of
> a new one (partially because I was hoping for this to help in having this
> issue be dealt with quickly, which hasn't quite proven to be the case..).
> Under the current scheme, the right type for a documentation issue would be
> "Task", which seems fine to me, but I don't really feel too strongly about
> it either way.
>
> I do think types such as "test", "wish", "improvement" etc. are problematic
> though, and would rather not have them around :)
>
>
>
>
> On Sun, Oct 30, 2016 at 5:59 PM, John D. Ament 
> wrote:
>
> > I just saw this ticket in the INFRA backlog -
> > https://issues.apache.org/jira/browse/INFRA-12733
> >
> > Just wondering, was this discussed on the ML?  I didn't see it, and I
> would
> > recommend leaving in ticket types like documentation.
> >
>


[jira] [Resolved] (ARIATOSCA-7) Celery-based task executor

2016-11-01 Thread Ran Ziv (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARIATOSCA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Ziv resolved ARIATOSCA-7.
-
   Resolution: Fixed
Fix Version/s: 0.1.0

> Celery-based task executor
> --
>
> Key: ARIATOSCA-7
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-7
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Dan Kilman
> Fix For: 0.1.0
>
>
> Create a Celery-based task executor, to enable running remote async tasks as 
> part of a workflow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


incubator-ariatosca git commit: ARIA-14 Implement initial engine tests

2016-11-01 Thread dankilman
Repository: incubator-ariatosca
Updated Branches:
  refs/heads/ARIA-14-workflow-engine-tests [created] 5a77c4716


ARIA-14 Implement initial engine tests


Project: http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/commit/5a77c471
Tree: http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/tree/5a77c471
Diff: http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/diff/5a77c471

Branch: refs/heads/ARIA-14-workflow-engine-tests
Commit: 5a77c47163728246c1189e8cb44b71ade1cbfeda
Parents: c0bf347
Author: Dan Kilman 
Authored: Tue Nov 1 16:42:34 2016 +0200
Committer: Dan Kilman 
Committed: Tue Nov 1 19:46:02 2016 +0200

--
 aria/contexts.py |   4 +-
 aria/events/__init__.py  |   1 +
 aria/events/builtin_event_handler.py |  15 ++-
 aria/storage/models.py   |   4 +-
 aria/tools/application.py|  10 +-
 aria/workflows/core/engine.py|  17 ++-
 aria/workflows/core/tasks.py |  33 --
 tests/workflows/test_engine.py   | 179 ++
 8 files changed, 239 insertions(+), 24 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/blob/5a77c471/aria/contexts.py
--
diff --git a/aria/contexts.py b/aria/contexts.py
index ae7fc66..fdd26a2 100644
--- a/aria/contexts.py
+++ b/aria/contexts.py
@@ -201,11 +201,11 @@ class OperationContext(LoggerMixin):
 """
 The model operation
 """
-return self.storage.operation.get(self.id)
+return self.model.operation.get(self.id)
 
 @operation.setter
 def operation(self, value):
 """
 Store the operation in the model storage
 """
-self.storage.operation.store(value)
+self.model.operation.store(value)

http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/blob/5a77c471/aria/events/__init__.py
--
diff --git a/aria/events/__init__.py b/aria/events/__init__.py
index 6b07213..74f3e22 100644
--- a/aria/events/__init__.py
+++ b/aria/events/__init__.py
@@ -39,6 +39,7 @@ from blinker import signal
 from ..tools.plugin import plugin_installer
 
 # workflow engine task signals:
+sent_task_signal = signal('sent_task_signal')
 start_task_signal = signal('start_task_signal')
 on_success_task_signal = signal('success_task_signal')
 on_failure_task_signal = signal('failure_task_signal')

http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/blob/5a77c471/aria/events/builtin_event_handler.py
--
diff --git a/aria/events/builtin_event_handler.py 
b/aria/events/builtin_event_handler.py
index ec3238f..2dfbd00 100644
--- a/aria/events/builtin_event_handler.py
+++ b/aria/events/builtin_event_handler.py
@@ -27,12 +27,21 @@ from . import (
 start_workflow_signal,
 on_success_workflow_signal,
 on_failure_workflow_signal,
+sent_task_signal,
 start_task_signal,
 on_success_task_signal,
 on_failure_task_signal,
 )
 
 
+@sent_task_signal.connect
+def _task_sent(task, *args, **kwargs):
+operation_context = task.context
+operation = operation_context.operation
+operation.status = operation.SENT
+operation_context.operation = operation
+
+
 @start_task_signal.connect
 def _task_started(task, *args, **kwargs):
 operation_context = task.context
@@ -62,7 +71,7 @@ def _task_succeeded(task, *args, **kwargs):
 
 @start_workflow_signal.connect
 def _workflow_started(workflow_context, *args, **kwargs):
-execution_cls = workflow_context.storage.execution.model_cls
+execution_cls = workflow_context.model.execution.model_cls
 execution = execution_cls(
 id=workflow_context.execution_id,
 deployment_id=workflow_context.deployment_id,
@@ -80,7 +89,7 @@ def _workflow_failed(workflow_context, exception, *args, 
**kwargs):
 execution = workflow_context.execution
 execution.error = str(exception)
 execution.status = execution.FAILED
-execution.ended_at = datetime.utcnow(),
+execution.ended_at = datetime.utcnow()
 workflow_context.execution = execution
 
 
@@ -88,5 +97,5 @@ def _workflow_failed(workflow_context, exception, *args, 
**kwargs):
 def _workflow_succeeded(workflow_context, *args, **kwargs):
 execution = workflow_context.execution
 execution.status = execution.TERMINATED
-execution.ended_at = datetime.utcnow(),
+execution.ended_at = datetime.utcnow()
 workflow_context.execution = execution

http://git-wip-us.apache.org/repos/asf/incubator-ariatosca/blob/5a77c471/aria/storage/models.py

[jira] [Closed] (ARIATOSCA-7) Celery-based task executor

2016-11-01 Thread Ran Ziv (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARIATOSCA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Ziv closed ARIATOSCA-7.
---

> Celery-based task executor
> --
>
> Key: ARIATOSCA-7
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-7
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Dan Kilman
> Fix For: 0.1.0
>
>
> Create a Celery-based task executor, to enable running remote async tasks as 
> part of a workflow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (ARIATOSCA-7) Celery-based task executor

2016-11-01 Thread Ran Ziv (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARIATOSCA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Ziv reopened ARIATOSCA-7:
-

> Celery-based task executor
> --
>
> Key: ARIATOSCA-7
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-7
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Dan Kilman
> Fix For: 0.1.0
>
>
> Create a Celery-based task executor, to enable running remote async tasks as 
> part of a workflow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (ARIATOSCA-14) Add tests for workflow engine module

2016-11-01 Thread Dan Kilman (JIRA)
Dan Kilman created ARIATOSCA-14:
---

 Summary: Add tests for workflow engine module
 Key: ARIATOSCA-14
 URL: https://issues.apache.org/jira/browse/ARIATOSCA-14
 Project: AriaTosca
  Issue Type: Task
Reporter: Dan Kilman
Assignee: Dan Kilman






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (ARIATOSCA-7) Celery-based task executor

2016-11-01 Thread Dan Kilman (JIRA)

 [ 
https://issues.apache.org/jira/browse/ARIATOSCA-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dan Kilman closed ARIATOSCA-7.
--
Resolution: Fixed

> Celery-based task executor
> --
>
> Key: ARIATOSCA-7
> URL: https://issues.apache.org/jira/browse/ARIATOSCA-7
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Assignee: Dan Kilman
>
> Create a Celery-based task executor, to enable running remote async tasks as 
> part of a workflow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)