<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>
<div>The problem with exposing Mistral DSL the way it is, is that there are many things the user should not be aware of. </div>
<div><br>
</div>
<div>Lets take the example Mistral DSL created here, <a href="https://review.openstack.org/#/c/95709/4/etc/solum/workbooks/build.yaml">https://review.openstack.org/#/c/95709/4/etc/solum/workbooks/build.yaml</a></div>
<div><br>
</div>
<div>Why should the end user know and define things like auth_token, base_image_id (which is the language pack id in the plan file), on-success actions, etc. Users should not be concerned with these things. All they should be able to do is say 'yes/no' to a
task which Solum supports, and if Yes, configure it further. Dependency between tasks, internal solum/glance/keystone id's etc should be hidden, but are required by the mistral DSL.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On Jun 4, 2014, at 1:10 PM, Julien Vey <<a href="mailto:vey.julien@gmail.com">vey.julien@gmail.com</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Murali, Roshan.
<div><br>
</div>
<div>I think there is a misunderstood. By default, the user wouldn't see any "workflow" dsl. If the user does not specify anything, we would use a pre-defined mistral workbook defined by Solum, as Adrian described</div>
<div><br>
</div>
<div>If the user needs more, mistral is not so complicated. Have a look at this example Angus has done <a href="https://review.openstack.org/#/c/95709/4/etc/solum/workbooks/build.yaml">https://review.openstack.org/#/c/95709/4/etc/solum/workbooks/build.yaml</a></div>
<div>We can define anything as solum actions, and the users would just have to call one of this actions. Solum takes care of the implementation. If we have comments about the DSL, Mistral's team is willing to help.</div>
<div><br>
</div>
<div>Our end-users will be developers, and a lot of them will need a custom workflow at some point. For instance, if Jenkins has so many plugins, it's because there are as many custom build workflows, specific to each company. If we add an abstraction on top
of mistral or any other workflow engine, we will lock developers in our own decisions, and any additional feature would require a new development in Solum, whereas exposing (when users want it) mistral, we would allow for any customization.</div>
<div><br>
</div>
<div>Julien</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-06-04 19:50 GMT+02:00 Roshan Agrawal <span dir="ltr">
<<a href="mailto:roshan.agrawal@rackspace.com" target="_blank">roshan.agrawal@rackspace.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Agreeing with what Murali said below. We should make things really simple for the 99 percentile of the users, and not force the complexity needed by the minority
of the “advanced users” on the rest of the 99 percentile users. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Mistral is a generic workflow DSL, we do not need to expose all that complexity to the Solum user that wants to customize the pipeline. “Non-advanced” users
will have a need to customize the pipeline. In this case, the user is not necessarily the developer persona, but typically an admin/release manager persona. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Pipeline customization should be doable easily, without having the understand or author a generic workflow DSL.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For the really advanced user who needs to have a finer grained need to tweak the mistral workflow DSL (I am not sure if there will be a use case for this if
we have the right customizations exposed via the pipeline API), we should have the “option” for the user to tweak the mistral DSL directly, but we should not expect 99.9% (or more) of the users to deal with a generic workflow.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Murali Allada [mailto:<a href="mailto:murali.allada@RACKSPACE.COM" target="_blank">murali.allada@RACKSPACE.COM</a>]
<br>
<b>Sent:</b> Wednesday, June 04, 2014 12:09 PM</span></p>
<div class=""><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<u></u><u></u></div>
<div><br class="webkit-block-placeholder">
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Angus/Julien,<u></u><u></u></p>
</div>
<div>
<div class="h5">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I would disagree that we should expose the mistral DSL to end users.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">What if we decide to use something other than Mistral in the future? We should be able to plug in any workflow system we want without changing what we expose to the end user.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To me, the pipeline DSL is similar to our plan file. We don't expose a heat template to our end users.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Murali<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Jun 4, 2014, at 10:58 AM, Julien Vey <<a href="mailto:vey.julien@gmail.com" target="_blank">vey.julien@gmail.com</a>><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">Hi Angus, <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Julien<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">2014-06-04 14:11 GMT+02:00 Angus Salkeld <<a href="mailto:angus.salkeld@rackspace.com" target="_blank">angus.salkeld@rackspace.com</a>>:<u></u><u></u></p>
<p class="MsoNormal">-----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><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">_______________________________________________<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><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
<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>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</body>
</html>