<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 11, 2014 at 10:34 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Soooo, how about we can continue this in #openstack-state-management (or #openstack-oslo).<br>
<br>
Since I think we've all made the point and different viewpoints visible (which was the main intention).<br>
<br>
Overall, I'd like to see asyncio more directly connected into taskflow so we can have the best of both worlds.<br>
<br>
We just have to be careful in letting people blow their feet off, vs. being to safe; but that discussion I think we can have outside this thread.<br></blockquote><div><br></div><div>That's what I was about to reply to Clint: "Let the user shoot ones feet, one can always be creative in doing that anyway".</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sound good?<br></blockquote><div><br></div><div>Sure. TBH I didn't think this thread is the right place for this discussion but "coroutines can't do that" kind of set me off :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Josh<br>
<div class="HOEnZb"><div class="h5"><br>
On Jul 11, 2014, at 9:04 AM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
<br>
> Excerpts from Yuriy Taraday's message of 2014-07-11 03:08:14 -0700:<br>
>> On Thu, Jul 10, 2014 at 11:51 PM, Josh Harlow <<a href="mailto:harlowja@outlook.com">harlowja@outlook.com</a>> wrote:<br>
>>> 2. Introspection, I hope this one is more obvious. When the coroutine<br>
>>> call-graph is the workflow there is no easy way to examine it before it<br>
>>> executes (and change parts of it for example before it executes). This is a<br>
>>> nice feature imho when it's declaratively and explicitly defined, you get<br>
>>> the ability to do this. This part is key to handling upgrades that<br>
>>> typically happen (for example the a workflow with the 5th task was upgraded<br>
>>> to a newer version, we need to stop the service, shut it off, do the code<br>
>>> upgrade, restart the service and change 5th task from v1 to v1.1).<br>
>>><br>
>><br>
>> I don't really understand why would one want to examine or change workflow<br>
>> before running. Shouldn't workflow provide just enough info about which<br>
>> tasks should be run in what order?<br>
>> In case with coroutines when you do your upgrade and rerun workflow, it'll<br>
>> just skip all steps that has already been run and run your new version of<br>
>> 5th task.<br>
>><br>
><br>
> I'm kind of with you on this one. Changing the workflow feels like self<br>
> modifying code.<br>
><br>
>> 3. Dataflow: tasks in taskflow can not just declare workflow dependencies<br>
>>> but also dataflow dependencies (this is how tasks transfer things from one<br>
>>> to another). I suppose the dataflow dependency would mirror to coroutine<br>
>>> variables & arguments (except the variables/arguments would need to be<br>
>>> persisted somewhere so that it can be passed back in on failure of the<br>
>>> service running that coroutine). How is that possible without an<br>
>>> abstraction over those variables/arguments (a coroutine can't store these<br>
>>> things in local variables since those will be lost)?It would seem like this<br>
>>> would need to recreate the persistence & storage layer[5] that taskflow<br>
>>> already uses for this purpose to accomplish this.<br>
>>><br>
>><br>
>> You don't need to persist local variables. You just need to persist results<br>
>> of all tasks (and you have to do it if you want to support workflow<br>
>> interruption and restart). All dataflow dependencies are declared in the<br>
>> coroutine in plain Python which is what developers are used to.<br>
>><br>
><br>
> That is actually the problem that using declarative systems avoids.<br>
><br>
><br>
> @asyncio.couroutine<br>
> def add_ports(ctx, server_def):<br>
> port, volume = yield from asyncio.gather(ctx.run_task(create_port(server_def)),<br>
> ctx.run_task(create_volume(server_def))<br>
> if server_def.wants_drbd:<br>
> setup_drbd(volume, server_def)<br>
><br>
> yield from ctx.run_task(boot_server(volume_az, server_def))<br>
><br>
><br>
> Now we have a side effect which is not in a task. If booting fails, and<br>
> we want to revert, we won't revert the drbd. This is easy to miss<br>
> because we're just using plain old python, and heck it already even has<br>
> a test case.<br>
><br>
> I see this type of thing a lot.. we're not arguing about capabilities,<br>
> but about psychological differences. There are pros and cons to both<br>
> approaches.<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>