<div dir="ltr">Hi,<div><br></div><div>There is a stackforge project Mistral which is aimed to provide generic workflow service. I believe Zane mentioned it in his previous e-mail. Currently, this project is at a pilot stage. Mistral has working pilot with all core components implemented and right now we are finalizing DSL syntax for task definitions. Mistral can call any API endpoint which is defined in a task and Mistral exposes hooks to trig workflow execution on some external event. </div>
<div><br></div><div>There will be a meetup where Renat Akhmerov (Mistral lead) will present Mistral, its use cases and current status of the project followed by a demo. Here is a link: <a href="http://www.meetup.com/openstack/events/163020092/">http://www.meetup.com/openstack/events/163020092/</a></div>
<div><br></div><div>We plan to finish Mistral core development during Icehouse release and apply for an incubation. I think in J release Mistral can be used by other OpenStack projects as all bits an pieces will be available at this time.</div>
<div><br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 4:53 AM, Hugh Brock <span dir="ltr"><<a href="mailto:hbrock@redhat.com" target="_blank">hbrock@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> On Jan 31, 2014, at 1:30 AM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
><br>
> Excerpts from Zane Bitter's message of 2014-01-30 19:30:40 -0800:<br>
>>> On 30/01/14 16:54, Clint Byrum wrote:<br>
>>> I'm pretty sure it is useful to model images in Heat.<br>
>>><br>
>>> Consider this scenario:<br>
>>><br>
>>><br>
>>> resources:<br>
>>> build_done_handle:<br>
>>> type: AWS::CloudFormation::WaitConditionHandle<br>
>>> build_done:<br>
>>> type: AWS::CloudFormation::WaitCondition<br>
>>> properties:<br>
>>> handle: {Ref: build_done_handle}<br>
>>> build_server:<br>
>>> type: OS::Nova::Server<br>
>>> properties:<br>
>>> image: build-server-image<br>
>>> userdata:<br>
>>> join [ "",<br>
>>> - "#!/bin/bash\n"<br>
>>> - "build_an_image\n"<br>
>>> - "cfn-signal -s SUCCESS "<br>
>>> - {Ref: build_done_handle}<br>
>>> - "\n"]<br>
>>> built_image:<br>
>>> type: OS::Glance::Image<br>
>>> depends_on: build_done<br>
>>> properties:<br>
>>> fetch_url: join [ "", ["http://", {get_attribute: [ build_server, fixed_ip ]}, "/image_path"]]<br>
>>> actual_server:<br>
>>> type: OS::Nova::Server<br>
>>> properties:<br>
>>> image: {Ref: built_image}<br>
>>><br>
>>><br>
>>> Anyway, seems rather useful. Maybe I'm reaching.<br>
>><br>
>> Well, consider that when this build is complete you'll still have the<br>
>> server you used to build the image still sitting around. Of course you<br>
>> can delete the stack to remove it - and along with it will go the image<br>
>> in Glance. Still seem useful?<br>
><br>
> No, not as such. However I have also discussed with other users having<br>
> an OS::Heat::TemporaryServer which is deleted after a wait condition is<br>
> signaled (resurrected on each update). This would be useful for hosting<br>
> workflow code as the workflow doesn't actually need to be running all<br>
> the time. It would also be useful for heat resources that want to run<br>
> code that needs to be contained into their own VM/network such as the<br>
> port probe thing that came up a few weeks ago.<br>
><br>
> Good idea? I don't know. But it is the next logical step my brain keeps<br>
> jumping to for things like this.<br>
><br>
>> (I'm conveniently ignoring the fact that you could have set<br>
>> DeletionPolicy: Retain on the image to hack your way around this.)<br>
>><br>
>> What you're looking for is a workflow service (I think it's called<br>
>> Mistral this week?). A workflow service would be awesome, and Heat is<br>
>> pretty awesome, but Heat is not a workflow service.<br>
><br>
> Totally agree. I think workflow and orchestration have an unusual<br>
> relationship though, because orchestration has its own workflow that<br>
> users will sometimes need to defer to. This is why we use wait<br>
> conditions, right?<br>
><br>
>> So yeah, Glance images in Heat might be kinda useful, but at best as a<br>
>> temporary hack to fill in a gap because the Right Place to implement it<br>
>> doesn't exist yet. That's why I feel ambivalent about it.<br>
><br>
> I think you've nudged me away from "optimistic" at least closer to<br>
> "ambivalent" as well.<br>
<br>
</div></div>We (RH tripleo folks) were having a similar conversation around Heat and stack upgrades the other day. There is unquestionably a workflow involving stack updates when a user goes to upgrade their overcloud, and it's awkward trying to shoehorn it into Heat (Steve Dake agreed). Our first thought was "Tuskar should do that," but our second thought was "Whatever the workflow service is should do that, and Tuskar should maybe provide a shorthand API for it."<br>
<br>
I feel like we (tripleo) need to take a harder look at getting a working workflow thing available for our needs, soon...<br>
<span class="HOEnZb"><font color="#888888"><br>
--Hugh<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
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><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div>