Anastasia,
Thanks a lot for this etherpad. I’ve read it and left my comments. Overall I
agree with the suggested plan.
Additionally, I would suggest we picture the overall package structure with a
sub-project breakdown. E.g.:
mistral:
functionaltests/
openstack/
standalone/
On 25 Jun 2014, at 07:27, Dmitri Zimine dzim...@stackstorm.com wrote:
* We must convey the action ERROR details back to the engine, and to the end
user. Log is not sufficient. How exactly? Via context? Via extra parameters
to convey_execution_results? Need a field in the model.
(reposting due to lack of subject)
Hello, everyone!
I am happy to announce that Mistral team started working on test
infrastructure. Due to this fact I prepared etherpad
https://etherpad.openstack.org/p/MistralTests where I analysed what we have
and what we need to do.
I would like to get your
Hi,
Mistral version 0.0.4* has just been released! This is an intermediate release
however it contains a series of important changes/fixes.
Here’s the list of the most noticeable changes:
Speeded up tests using Testr
Modified launch script to start any combination of Mistral components (engine,
Got some questions while fixing a bug https://review.openstack.org/#/c/102391/:
* We must convey the action ERROR details back to the engine, and to the end
user. Log is not sufficient. How exactly? Via context? Via extra parameters to
convey_execution_results? Need a field in the model.
Folks,
We’re cancelling today’s community meeting for a number of reasons
(intermediate release activities, not all important members will be available).
Let’s meet next Monday on 06/30/2014.
Renat Akhmerov
@ Mirantis Inc.
___
OpenStack-dev
In case you have urgent questions please ping me personally.
Renat Akhmerov
@ Mirantis Inc.
On 23 Jun 2014, at 18:17, Renat Akhmerov rakhme...@mirantis.com wrote:
Folks,
We’re cancelling today’s community meeting for a number of reasons
(intermediate release activities, not all
Hello, everyone!
I am happy to announce that Mistral team started working on test
infrastructure. Due to this fact I prepared etherpad
https://etherpad.openstack.org/p/MistralTests where I analysed what we have
and what we need to do.
I would like to get your feedback to start creating
Just a clarification: “reverse” flow is what I usually call “dependency based
flow” when we specify dependencies between tasks rather then direct transitions
(do this then on success do that).
* Put it off till the engine refactoring, factor the requirement of
supporting two modes into the
https://review.openstack.org/#/c/100390/
Angus asked:
Why do we even need start: start-task?
Can't we parse the workbook and figure out what to run? Tasks at the bottom of
the tree have no on-{fail,success} and then
follow upwards until you find a task that is not referenced by anything.
Yes
On 13 Jun 2014, at 07:03, W Chan m4d.co...@gmail.com wrote:
Design proposal for blueprint
https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol
Rename Executor to Worker.
I’d be ok with Worker but would prefer ActionRunner since it reflects the
purpose a little
Thanks Timur, that’s a good doc.
Anastasia and Sergey were supposed to start working on a proposal devoted to
our approaches to integration testing. I hope we’ll see them soon.
Renat Akhmerov
@ Mirantis Inc.
On 11 Jun 2014, at 13:55, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote:
Hi
I figured. I implemented it in https://review.openstack.org/#/c/97684/.
On Mon, Jun 16, 2014 at 9:35 PM, Renat Akhmerov rakhme...@mirantis.com
wrote:
I don’t think we have them. You can write them I think as a part of what
you’re doing.
Renat Akhmerov
@ Mirantis Inc.
On 31 May 2014,
Ooh, alright :) It passed by me why I was off.
Renat Akhmerov
@ Mirantis Inc.
On 18 Jun 2014, at 01:20, W Chan m4d.co...@gmail.com wrote:
I figured. I implemented it in https://review.openstack.org/#/c/97684/.
On Mon, Jun 16, 2014 at 9:35 PM, Renat Akhmerov rakhme...@mirantis.com
Hi Winson,
Sorry, I haven’t responded so far for I was on vacation. So getting back to you
now..
It’s my fault that the notes in the BP are not fairly clear.
1. By “worker parallelism” we meant that one worker (which is called “executor
now) can poll and handle more than one task from the
Hi,
This is a reminder about another community IRC meeting at #openstack-meeting
today at 16.00 UTC.
The agenda is usual:
Review action items
Current status (quickly by team members)
Further plans
Open discussion
Looking forward to see you there.
[0]
I don’t think we have them. You can write them I think as a part of what you’re
doing.
Renat Akhmerov
@ Mirantis Inc.
On 31 May 2014, at 04:26, W Chan m4d.co...@gmail.com wrote:
Is there an existing unit test for testing enabling keystone middleware in
pecan (setting
Design proposal for blueprint
https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol
- Rename Executor to Worker.
- Continue to use RPC server-client model in oslo.messaging for Engine
and Worker protocol.
- Use asynchronous call (cast) between Worker and
Hi team,
Tomorrow we discussed integration tests for Mistral and looks like we have
many ideas how we can improve them and what we also want to test.
The ideas were described in this etherpad:
https://etherpad.openstack.org/p/MistralNewTestsDesign
Please, fill free to add your ideas about our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
I was looking at
https://blueprints.launchpad.net/mistral/+spec/mistral-ceilometer-integration
and trying to figure out how to implement that.
I can see some problems:
- - at the moment the trust is created when you PUT the workbook definition
Hi team,
Thank you all for participating in Mistral weekly meeting today,
meeting minutes are available by the following links:
Minutes:
http://eavesdrop.openstack.org/meetings/mistral_weekly_meeting/2014/mistral_weekly_meeting.2014-06-09-15.59.html
Minutes (text):
Renat,
Regarding blueprint
https://blueprints.launchpad.net/mistral/+spec/mistral-engine-executor-protocol,
can you clarify what it means by worker parallelism and
engine-executor parallelism?
Currently, the engine and executor are launched with the eventlet driver
in oslo.messaging. Once a
Hi,
This is a reminder about the community meeting in IRC June 02 at 16.00 UTC at
#openstack-meeting.
Agenda:
Review action items
Current status (quickly by team members)
Further plans
Open discussion
You can also find it at https://wiki.openstack.org/wiki/Meetings/MistralAgenda
as well as
Hi all,
Thanks to all participants for visiting the Mistral meeting in
#openstack-meeting today!
The meeting minutes can be found by the following links:
Minutes:
http://eavesdrop.openstack.org/meetings/mistral_meeting/2014/mistral_meeting.2014-06-02-16.00.html
Minutes (text):
Is there an existing unit test for testing enabling keystone middleware in
pecan (setting cfg.CONF.pecan.auth_enable = True)? I don't seem to find
one. If there's one, it's not obvious. Can someone kindly point me to it?
On Wed, May 28, 2014 at 9:53 AM, W Chan m4d.co...@gmail.com wrote:
Hi,
We’ve prepared the first version of roadmap for Juno release cycle and you can
find it:
https://etherpad.openstack.org/p/mistral-juno-roadmap (here you can leave your
suggestions and comments)
https://wiki.openstack.org/wiki/Mistral/Roadmap (wiki)
You can also find more detailed list of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/05/14 02:48, W Chan wrote:
Regarding config opts for keystone, the keystoneclient middleware already
registers the opts at
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325
under
On 28 May 2014, at 13:51, Angus Salkeld angus.salk...@rackspace.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/05/14 02:48, W Chan wrote:
Regarding config opts for keystone, the keystoneclient middleware already
registers the opts at
Thanks for following up. I will publish this change as a separate patch
from my current config cleanup.
On Wed, May 28, 2014 at 2:38 AM, Renat Akhmerov rakhme...@mirantis.comwrote:
On 28 May 2014, at 13:51, Angus Salkeld angus.salk...@rackspace.com
wrote:
-BEGIN PGP SIGNED
Hi,
This is a reminder about the community meeting in IRC today at 16.00 UTC at
#openstack-meeting.
Agenda:
Review action items
Current status (quickly by team members)
Summit results
Further plans
Open discussion
You can also find it at https://wiki.openstack.org/wiki/Meetings/MistralAgenda
I tend to disagree with the whole idea. Not sure 100% though yet. Could you
please explain the point of scattering configuration all over the code? In my
opinion, we’re mixing different application concerns. With the current approach
I always know where to look at in order to find all my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/05/14 05:00, W Chan wrote:
Renat,
I want to avoid having to explicitly import the mistral.config module in
order
to have configuration loaded properly. The problem with the way
mistral.config
is coded is that we have to use
We shared and discussed the directions on Mistral development session,
and work through the list of smaller post POC steps, placing them on the
roadmap.
The notes are here: https://etherpad.openstack.org/p/juno-summit-mistral.
Renat and I developed shared understanding on most of them.
Next
On 05/12/2014 10:25 PM, Dmitri Zimine wrote:
The problem: Keystone authentication on MAC works from command line,
but fails when run from PyCharm. And I want to run PyCharm to debug!
The root cause: Keystone uses openssl cms which is only available in
new openssl. I installed openssl via
Regarding config opts for keystone, the keystoneclient middleware already
registers the opts at
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325under
a keystone_authtoken group in the config file. Currently, Mistral
registers the opts
+1 for breaking down the configuration by modules.
Not sure about names for configuration group. Do you mean just using the same
group name? or more?
IMO groups are project specific; it doesn’t always make sense to use the same
group name in the context of different projects. Our requirement
)
openstack-dev@lists.openstack.org
Date: Thursday, May 15, 2014 at 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral][TaskFlow] Integration plan
Renat, Joshua, Dmitri and Timur discussed the integration path
Renat, Joshua, Dmitri and Timur discussed the integration path for Mistral and
TaskFlow.
Quick summary - guys please correct any mistakes or omissions:
Taskflow - Mistral integration plan
1) Mistral: define the set of workflow primitives, define correspondent DSL
- Driven by user
Currently, the various configurations are registered in
./mistral/config.py. The configurations are registered when mistral.config
is referenced. Given the way the code is written, PEP8 throws referenced
but not used error if mistral.config is referenced but not called in the
module. In various
@lists.openstack.org
Date: Thursday, May 15, 2014 at 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral][TaskFlow] Integration plan
Renat, Joshua, Dmitri and Timur discussed the integration path for
Mistral and TaskFlow.
Quick
I’m inviting everyone interested in Mistral (Workflow Service for OpenStack) to
a design session today at 2pm (room B306). We’ll be talking about further
Mistral development direction and it’s very important to gather as much
feedback as possible.
Session:
I’m inviting everyone interested in Mistral (Workflow Service for OpenStack) to
a design session today at 2pm (room B306). We’ll be talking about further
Mistral development direction and it’s very important to gather as much
feedback as possible.
Session:
Thanks for joining Mistral design session today!
I’m really glad to realize that so many people are interested in the project
and it was so cool to answer your questions. We’re open to further discussions
during the summit and afterwards. Please find us anytime in ML and IRC to ask
addition
The problem: Keystone authentication on MAC works from command line, but fails
when run from PyCharm. And I want to run PyCharm to debug!
The root cause: Keystone uses openssl cms which is only available in new
openssl. I installed openssl via brew, and got it in /usr/local/bin. Terminal
Hi Mistral folks,
Congrats on getting the 0.0.2 release out. I had a look at Renat's
screencast and the examples, and I wanted to share some feedback based
on my experience with Heat. Y'all will have to judge for yourselves to
what extent this experience is applicable to Mistral. (Assume that
Hi Zane,
Great feedback! My comments below...
On 07 May 2014, at 22:29, Zane Bitter zbit...@redhat.com wrote:
The first thing that struck me looking at
https://github.com/stackforge/mistral-extra/tree/master/examples/create_vm is
that I have to teach Mistral how to talk to Nova. I can't
Hi,
This is a reminder about the community meeting we’ll have today at 16.00 UTC at
#openstack-meeting.
Agenda:
Review action items
Current status (quickly by team members)
Summit preparations
Further plans
Open discussion
It can also be found at
Thanks for joining us today.
Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-05-05-16.00.html
Full log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-05-05-16.00.log.html
My suggestion would be to skip the next two meetings due to Summit
I’m glad to announce release 0.0.2 of Mistral, Workflow Service for OpenStack,
which delivers all the functionality that we planned to deliver in PoC
development phase.
Below are all the most important links related to this release that will help
you understand Mistral ideas. It is recommended
Hi,
This is a reminder about another community meeting that we’ll be having today
at 16.00 UTC (#openstack-meeting).
The agenda:
Review action items
Current status (quickly by team members)
POC readiness and steps that left to finalise it
Open discussion
You can also find it at
Thanks for joining today’s community meeting.
Minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-28-16.00.html
Full log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-28-16.00.log.html
The next meeting is scheduled for May 5.
Renat Akhmerov
@
(not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [mistral] [taskflow] Mistral TaskFlow
integration summary
On 15 Apr 2014, at 11:13, Joshua Harlow harlo...@yahoo-inc.com wrote:
Sure, its not the fully complete lazy_engine, but piece by piece we can
Ok, no problem :)
Renat Akhmerov
@ Mirantis Inc.
On 16 Apr 2014, at 12:43, Joshua Harlow harlo...@yahoo-inc.com wrote:
I have stricken the word micro and language from my vocabulary. Begone
evil demons!! Haha :)
Sent from my really tiny device...
On Apr 15, 2014, at 10:35 PM, Renat
Some notes:
Even though we use YAQL now our design is flexible enough to plug other ELs in.
If it tells you something in Amazon SWF a component that makes a decision about
a further route is called Decider.
This discussion about conditionals is surely important but it doesn’t matter
too much if
)
openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)
Subject: Re: [openstack-dev] [mistral] [taskflow] Mistral TaskFlow
integration summary
Thank for pointing that out, Joshua.
I had a look on [1] and it seems to me that it might actually do the trick
to some
On 15 Apr 2014, at 11:13, Joshua Harlow harlo...@yahoo-inc.com wrote:
Sure, its not the fully complete lazy_engine, but piece by piece we can get
there.
Did you make any estimations when it could happen? :)
Of course code/contributions are welcome, as such things will benefit more
than
Team,
Following up on the yesterday’s community meeting I created an etherpad and
captured all the formal steps we need to make in order to consider Mistral PoC
ready [0]. Please take a look and comment and/or add other items that you think
I missed.
My expectation is to get all the items
Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary
Some notes:
* Even though we use YAQL now our design is flexible enough to plug other
ELs
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [mistral] [taskflow] Mistral TaskFlow integration
summary
On 15 Apr 2014, at 11:13, Joshua Harlow
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote:
Sure, its not the fully complete lazy_engine, but piece by piece we can get
On 16 Apr 2014, at 00:18, Joshua Harlow harlo...@yahoo-inc.com wrote:
Decider sounds like it could work also as a name, although it seems from
dataflow like work its called a switch or gate, either or I guess.
That’s fine. It doesn’t matter too much to me personally.
As far as the
I have stricken the word micro and language from my vocabulary. Begone evil
demons!! Haha :)
Sent from my really tiny device...
On Apr 15, 2014, at 10:35 PM, Renat Akhmerov
rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote:
On 16 Apr 2014, at 00:18, Joshua Harlow
Hi,
This a reminder about the community meeting in IRC (#openstack-meeting) that
we’ll have today at 16.00 UTC.
Agenda:
Review action items
Current status (quickly by team members)
POC demo scenario readiness and ways to improve it
TaskFlow integration status
Open discussion
It could also be
Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary
We prototyped Mistral / TaskFlow integration and have a follow-up
discussions.
SUMMARY: Mistral (Workflow Service) can embed TaskFlow as a workflow
Thanks for joining today’s community meeting.
Meeting minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-14-15.59.html
Full log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-14-15.59.log.html
Please join us next monday on Apr 21st.
Renat
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary
The more the better :)
If seriously, this one is less detailed and rather focuses on high-level things
, April 11, 2014 at 9:55 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary
We prototyped Mistral / TaskFlow integration and have a follow-up
, 2014 at 9:55 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org (mailto:openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary
We prototyped Mistral / TaskFlow integration and have a follow
, 2014 at 9:20 PM
To: OpenStack-dev@lists.openstack.org
(mailto:OpenStack-dev@lists.openstack.org)
OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org)
Subject: [openstack-dev] [mistral] [taskflow] Mistral TaskFlow integration
summary
Hi everyone
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary
They are all parts of conditional transitions: every task should have a number
of possible transitions; each transition consist of a reference to the task we
want to transit
: Monday, April 14, 2014 at 9:02 PM
To: Joshua Harlow harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [mistral] [taskflow] Mistral
-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
Subject: [openstack-dev] [mistral] [taskflow] Mistral TaskFlow integration
summary
Hi everyone,
This is a summary to the prototype integration we did not too long ago:
http://github.com/enykeev/mistral/pull/1. Hope it would shed some
We prototyped Mistral / TaskFlow integration and have a follow-up discussions.
SUMMARY: Mistral (Workflow Service) can embed TaskFlow as a workflow library,
with some required modifications to function resliently as a service, and for
smooth integration. However, the TaskFlow flow controls are
)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, April 11, 2014 at 9:55 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral][TaskFlow
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
Hi everyone,
This is a summary to the prototype integration we did not too long ago:
http://github.com/enykeev/mistral/pull/1. Hope it would shed some light on the
aspects of the integration we are struggling with.
There is a possibility to build Mistral on top of TaskFlow as a library, but in
Hi,
This is a reminder that we have another community meeting today at
#openstack-meeting at 16.00 UTC.
Agenda:
Review action items
Current status (quickly by team members)
POC demo scenario readiness and ways to improve it
TaskFlow integration status
Open discussion
It can also be found at
Thanks for joining today’s meeting!
As usually,
Minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-07-16.00.html
Full log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-07-16.00.log.html
Let’s meet next time on April 14th.
Renat Akhmerov
@
On 04 Apr 2014, at 07:33, Kirill Izotov enyk...@stackstorm.com wrote:
Then, we can make task executor interface public and allow clients to
provide their own task executors. It will be possible then for Mistral
to implement its own task executor, or several, and share the
executors between
Dmitri, nice work, will research them carefully early next week. I would ask
other folks to do the same (especially Nikolay).
Renat Akhmerov
@ Mirantis Inc.
On 03 Apr 2014, at 06:22, Dmitri Zimine d...@stackstorm.com wrote:
Two more workflows drafted - cloud cron, and lifecycle, version 1.
On 03 Apr 2014, at 12:49, Kirill Izotov enyk...@stackstorm.com wrote:
Actually, the idea to make the concept more expandable is exactly my point =)
Mistral's Workbook is roughly the same as TaskFlow Flow and have nothing to
do with TaskFlow LogBook. The only major difference in case of
IRC to discuss http://tinyurl.com/k3s2gmy
Joshua, 2000 UTC doesn't quite work for Renat and Kirill (3 am their time).
The overlap is:
PST (UTC-7) UTC NOVT (UTC+7)
04pm (16:00)11pm (23:00)6am (06:00)
10pm (22:00)05am (05:00)12pm (12:00)
Kirill's
I'm trying to catch up this rather long and interesting discussion,
sorry for somewhat late reply.
I can see aspects of 'lazy model' support in TaskFlow:
- how tasks are executed and reverted
- how flows are run
- how engine works internally
Let me address those aspects separately.
==
...@yahoo-inc.com
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
I'm trying to catch up this rather long and interesting discussion,
sorry for somewhat late reply.
I can see aspects of 'lazy model' support in TaskFlow:
- how tasks are executed and reverted
Then, we can make task executor interface public and allow clients to
provide their own task executors. It will be possible then for Mistral
to implement its own task executor, or several, and share the
executors between all the engine instances.
I'm afraid that if we start to tear apart the
On 02 Apr 2014, at 13:38, Kirill Izotov enyk...@stackstorm.com wrote:
I agree that we probably need new engine for that kind of changes and, as
Renat already said in another thread, lazy model seems to be more basic and
it would be easier to build sync engine on top of that rather than other
Two more workflows drafted - cloud cron, and lifecycle, version 1.
The mindset questions are:
1) is DSL syntax expressive, and capable and convenient to handle real use
cases?
2) most importantly: what are the implied workflow capabilities which make it
all work?
* Take a look here:
(not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Inline...
On Mar 27, 2014, at 5:10 PM, Joshua Harlow harlo...@yahoo-inc.com wrote:
Thanks for the description!
The steps here seem very
On Apr 1, 2014, at 3:43 AM, Renat Akhmerov rakhme...@mirantis.com wrote:
On 25 Mar 2014, at 01:51, Joshua Harlow harlo...@yahoo-inc.com wrote:
The first execution model I would call the local execution model, this model
involves forming tasks and flows and then executing them inside an
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Even more responses inline :)
On Mar 31, 2014, at 8:44 PM, Joshua Harlow
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote:
More responses inline :)
From
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
On 25 Mar 2014, at 01:51, Joshua Harlow
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote
Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
On Apr 1, 2014, at 3:43 AM, Renat Akhmerov
rakhme...@mirantis.commailto:rakhme...@mirantis.com wrote:
On 25 Mar 2014
On 02 Apr 2014, at 05:45, Joshua Harlow harlo...@yahoo-inc.com wrote:
Possibly, although to me this is still exposing the internal of engines to
users who shouldn't care (or only care if they are specifying an engine type
that gives them access to these details). Allowing public access to
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
On Apr 1, 2014, at 3:43 AM, Renat Akhmerov rakhme...@mirantis.com wrote:
On 25 Mar 2014, at 01:51, Joshua Harlow harlo...@yahoo-inc.com wrote
LGTM. If others agree we can fix the jenkins job.
Renat Akhmerov
@ Mirantis Inc.
On 02 Apr 2014, at 07:51, Dmitri Zimine d...@stackstorm.com wrote:
We agreed to review this and if/when OK, fix the murano-cli. Can you guys
please take a look?
https://review.openstack.org/#/c/81941/
DZ
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 1, 2014 at 2:59 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral][TaskFlow] Long running actions
I have an idea regarding engine design i want to share with you. But first, it
seems like we need a small overview of the current implementations.
I'm not sure how ML will react on a bunch of ASCII graphs, so here is an
etherpad:
Thanks for joining IRC meeting today at #openstack-meeting channel.
As usually,
Minutes:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-31-16.00.html
Full log:
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-31-16.00.log.html
Looking forward to see
I am in the full agreement with the proposed approach (risked to copy below,
let's see if email handles your diagrams):
* Single Engine handles multiple executions asynchronously, in non-blocking way.
* Persistence access only from API and/or Engine, Engine writes, API reads.
* Action runes
Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: Thursday, March 27, 2014 at 4:43 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Mistral] How Mistral handling long running delegate
@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running
delegate tasks
Inline...
On Mar 27, 2014, at 5:10 PM, Joshua Harlow
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote:
Thanks for the description!
The steps here seem
801 - 900 of 1122 matches
Mail list logo