<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle"></style><style type="text/css"></style><style type="text/css"></style><style type="text/css"></style><style type="text/css"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<div>Hi Angus, Julien,</div>
<div><br>
</div>
<div>No major disagreements.</div>
<div><br>
</div>
<div>My thinking is that we should provide more application developer focused</div>
<div><span style="font-size: 10pt;">mechanism for customizing workflows (point #3). </span><span style="font-size: 10pt;">This may not necessarily be an entirely new DSL.</span></div>
<div><span style="font-size: 10pt;">It could just be additions </span><span style="font-size: 10pt;">to the current Plan structure. For example, we could add a section that</span></div>
<div><span style="font-size: 10pt;">defines what stages we want a particular assembly to go through
</span><span style="font-size: 10pt;">(unit testing, functional testing vs. just unit testing).</span></div>
<div><span style="font-size: 10pt;">These stages could actually be just the task names from a predefined Mistral workbook.</span></div>
<div>Btw, the stages could be listed in a different file (so not tied with a Plan).</div>
<div><br>
</div>
<div>I guess the main point is, requiring application developers to define a complete workflow</div>
<div>consisting of, what is the entry point, what should happen on failure, how many times a task should</div>
<div>be re-tried on failure, etc. seem too low level for application developers to be describing while deploying their apps to Solum.</div>
<div>Shouldn't application developers be more concerned with 'what' not 'how'?</div>
<div><br>
</div>
<div>- Devdatta</div>
<div><br>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF31820" style="direction: ltr;"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Julien Vey [vey.julien@gmail.com]<br>
<b>Sent:</b> Wednesday, June 04, 2014 10:58 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [solum] reviews for the new API<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Hi Angus,
<div><br>
</div>
<div>I really agree with you. I would insist on #3, most of our users will use the default workbook, and only advanced users will want to customize the workflow. "advanced" users should easily understand a mistral workbook, cause they are "advanced"</div>
<div><br>
</div>
<div>To add to the cons of creating our own DSL, it will require a lot more work, more design discussions, more maintenance... We might end up doing what mistral is already doing. If we have some difficulties with Mistral's DSL, we can talk with the team, and
contribute back our experience of using Mistral.</div>
<div><br>
</div>
<div>Julien</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra">
<div class="gmail_quote">2014-06-04 14:11 GMT+02:00 Angus Salkeld <span dir="ltr">
<<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi all<br>
<br>
I have posted this series and it has evoked a surprising (to me) amount<br>
of discussion so I wanted to clarify some things and talk to some of the<br>
issues so we can move forward.<br>
<br>
So first note is this is an early posting and still is not tested much.<br>
<br>
<a href="https://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z" target="_blank">https://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z</a><br>
<br>
First the terminology<br>
I have a pipeline meaning the association between a mistral workbook,<br>
a trigger url and a plan. This is a running entity not just a<br>
different workbook.<br>
<br>
The main issue seems to be the extent to which I am exposing the mistral<br>
workbook. Many of you expected a simpler workflow DSL that would be<br>
converted into the mistral workbook.<br>
<br>
The reason for me doing it this way are:<br>
1) so we don't have to write much code<br>
2) this is an iterative process. Let's try it the simple way first and<br>
only make it more complicated if we really need to (the agile way?).<br>
3) to be consistent in the way we treat heat templates, mistral<br>
workbooks and language packs - i.e. we provide standard ones and<br>
allow you to customize down to the underlying openstack primitives<br>
if you want (we should aim for this to be only a small percentage<br>
of our users).<br>
eg. pipeline == (check-build-deploy mistral workbook +<br>
basic-docker heat template + custom plan)<br>
here the user just choose the heat template and workbook from a list<br>
of options.<br>
<br>
4) if the mistral dsl is difficult for our users to work with we should<br>
give the mistral devs a chance to improve it before working around<br>
it.<br>
5) our users are primary developers and I don't think the current<br>
mistral DSL is tricky to figure out for someone that can code.<br>
6) doing it this way we can make use of heat and mistral's horizon<br>
plugins and link to them from the pipeline instead of having to<br>
redo all of the same pages. In a similar why that heat links to<br>
servers/volumes etc from a running stack.<br>
<br>
- -Angus<br>
<br>
<br>
Some things to note:<br>
- - the entire mistral engine can be replaced with an engine level plugin<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">
http://www.enigmail.net/</a><br>
<br>
iQEcBAEBAgAGBQJTjwz2AAoJEFrDYBLxZjWoEr0H/3nh66Umdw2nGUEs+SikigXa<br>
XAN90NHHPuf1ssEqrF/rMjRKg+GvrLx+31x4oFfHEj7oplzGeVA9TJC0HOp4h6dh<br>
iCeXAHF7KX+t4M4VuZ0y9TJB/jLxfxg4Qge7ENJpNDD/gggjMYSNhcWzBG87QBE/<br>
Mi4YAvxNk1/C3/YZYx2Iujq7oM+6tflTeuoG6Ld72JMHryWT5/tdYZrCMnuD4F7Q<br>
8a6Ge3t1dQh7ZlNHEuRDAg3G5oy+FInXyFasXYlYbtdpTxDL8/HbXegyAcsw42on<br>
2ZKRDYBubQr1MJKvSV5I3jjOe4lxXXFylbWpYpoU8Y5ZXEKp69R4wrcVISF1jQQ=<br>
=P0Sl<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>