Hi everyone,
Some offline conversations and thoughts yielded a notion of providing a
formal policy/transition backing to on-error, on-success and on-finish. I
have a few thoughts in and etherpad (see
https://etherpad.openstack.org/p/mistral_task_policy).
The headliner : on-error, on-success and
Yes. It is a bug and should be done before line 119: self._do_task_action(
db_task). It can definitely lead to bugs especially since _do_task_action
itself updates the status.
On Wed, Mar 26, 2014 at 8:46 PM, W Chan m4d.co...@gmail.com wrote:
In addition, for sync tasks, it'll overwrite the
+1
On Wed, Mar 19, 2014 at 5:33 AM, Stan Lagun sla...@mirantis.com wrote:
+1 for both
On Wed, Mar 19, 2014 at 3:35 PM, Renat Akhmerov rakhme...@mirantis.comwrote:
Team,
So far I've been just the only one core member of the team. I started
feeling lonely :) Since the project team and
...@mirantis.comwrote:
Hm.. Interesting. CI wasn't able to reveal this for some reason.
My first guess is that there's a race condition somewhere. Did you try
to debug it? And is this error 100% repeatable?
Renat Akhmerov
@ Mirantis Inc.
On 12 Mar 2014, at 11:18, Manas Kelshikar ma
can move the conversation to the review.
Thanks!
On Wed, Mar 12, 2014 at 11:00 AM, Manas Kelshikar ma...@stackstorm.comwrote:
I pasted only for python 2.6 but exact same errors with 2.7. Also, I
posted this question after I nuked my entire dev folder so this was being
run on a new environment
I see this error when I run tox. I pulled down a latest copy of master and
tried to setup the environment. Any ideas?
See http://paste.openstack.org/show/73213/ for details. Any help is
appreciated.
Thanks,
Manas
___
OpenStack-dev mailing list
able to reveal this for some reason.
My first guess is that there's a race condition somewhere. Did you try to
debug it? And is this error 100% repeatable?
Renat Akhmerov
@ Mirantis Inc.
On 12 Mar 2014, at 11:18, Manas Kelshikar ma...@stackstorm.com wrote:
I see this error when I run tox
I agree, let's rename data to spec and unblock the check-in.
Nikolay - Sorry for the trouble :)
On Mar 5, 2014 10:17 PM, Renat Akhmerov rakhme...@mirantis.com wrote:
Alright, good input Manas, appreciate.
My comments are below...
On 06 Mar 2014, at 10:47, Manas Kelshikar ma
distinguish between these two models so that it
wouldn't be confusing?
- Do we have a better naming in mind?
Thanks.
Renat Akhmerov
@ Mirantis Inc.
On 05 Mar 2014, at 08:56, Manas Kelshikar ma...@stackstorm.com wrote:
Since the renaming is for types in mistral.model.*. I am thinking we
be
derived from these Spec objects which fits well with the current paradigm.
Thoughts?
On Mon, Mar 3, 2014 at 9:43 PM, Manas Kelshikar ma...@stackstorm.comwrote:
Hi Nikolay -
Is your concern that mistral.db.sqlalchemy.models.* and mistral.model.*
will lead to confusion or something else?
IMHO
research carefully this etherpad and leave your comments.
It's a pretty tricky thing and we need to figure out the best strategy how
to approach this kind of things. We're going to have more problems similar
to this one.
Renat Akhmerov
@ Mirantis Inc.
On 25 Feb 2014, at 10:07, manas kelshikar
Hi Nikolay -
Is your concern that mistral.db.sqlalchemy.models.* and mistral.model.*
will lead to confusion or something else?
IMHO as per your change model seems like the appropriate usage while what
is stored in the DB is also a model. If we pick appropriate names to
distinguish between nature
I looked at the review prior to looking at the discussion and even I was
confused by names like DSL*. The way I see it DSL is largely syntatic sugar
and therefore it will be good to have a clear separation between DSL and
model. The fact that something is defined in a DSL is irrelevant once it
How about ...
invoke_http invoke_mistral to fit the verb_noun pattern.
On Wed, Feb 26, 2014 at 6:04 AM, Renat Akhmerov rakhme...@mirantis.comwrote:
Ooh, I was wrong. Sorry. We use dash naming. We have on-success,
on-error and so forth.
Please let us know if you see other inconsistencies.
Agreed on both event - trigger moving triggers out of workflow. Lets get
the blueprint started.
/manas
On Wed, Feb 26, 2014 at 8:51 PM, Renat Akhmerov rakhme...@mirantis.comwrote:
Hi team,
When I tell peopleI about Mistral I always have a hard time explaining why
we use term event for
Hi everyone,
I have put down my thoughts about the standard repeat action blueprint.
https://blueprints.launchpad.net/mistral/+spec/mistral-std-repeat-action
I have added link to an etherpad document which explore a few alternatives
of the approach. I have explored details of how the std:repeat
16 matches
Mail list logo
