Open Stack

Murali,

I’d like to explore the possibility that Solum users don’t need to see a pipeline DSL at all in the general case, and that only power users are interacting with it. If that UX is possible, then what DSL is used is much less important as long as it allows customizations to at least the main workflow points, and allows new ones to be inserted, and for default steps to be skipped.

I know that some contributors expressed concern that exposing a lower level DSL may constrain us if an alternate direction is desired in the future. I think we can use API versions to deal with that.

In general, I agree with Angus’ position that if we can’t find a simple way to express the Pipeline using a Mistral DSL, that we should raise that concern with the Mistral team
to see what can be adjusted to make it a better fit.

Adrian

On Jun 4, 2014, at 10:08 AM, Murali Allada <murali.allada at RACKSPACE.COM<mailto:murali.allada at RACKSPACE.COM>> wrote:

Angus/Julien,

I would disagree that we should expose the mistral DSL to end users.

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.

To me, the pipeline DSL is similar to our plan file. We don't expose a heat template to our end users.

Murali



On Jun 4, 2014, at 10:58 AM, Julien Vey <vey.julien at gmail.com<mailto:vey.julien at gmail.com>>
 wrote:

Hi Angus,

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"

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.

Julien





2014-06-04 14:11 GMT+02:00 Angus Salkeld <angus.salkeld at rackspace.com<mailto:angus.salkeld at rackspace.com>>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all

I have posted this series and it has evoked a surprising (to me) amount
of discussion so I wanted to clarify some things and talk to some of the
issues so we can move forward.

So first note is this is an early posting and still is not tested much.

https://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z

First the terminology
   I have a pipeline meaning the association between a mistral workbook,
   a trigger url and a plan. This is a running entity not just a
   different workbook.

The main issue seems to be the extent to which I am exposing the mistral
workbook. Many of you expected a simpler workflow DSL that would be
converted into the mistral workbook.

The reason for me doing it this way are:
1) so we don't have to write much code
2) this is an iterative process. Let's try it the simple way first and
   only make it more complicated if we really need to (the agile way?).
3) to be consistent in the way we treat heat templates, mistral
   workbooks and language packs - i.e. we provide standard ones and
   allow you to customize down to the underlying openstack primitives
   if you want (we should aim for this to be only a small percentage
   of our users).
   eg. pipeline == (check-build-deploy mistral workbook +
                    basic-docker heat template + custom plan)
   here the user just choose the heat template and workbook from a list
   of options.

4) if the mistral dsl is difficult for our users to work with we should
   give the mistral devs a chance to improve it before working around
   it.
5) our users are primary developers and I don't think the current
   mistral DSL is tricky to figure out for someone that can code.
6) doing it this way we can make use of heat and mistral's horizon
   plugins and link to them from the pipeline instead of having to
   redo all of the same pages. In a similar why that heat links to
   servers/volumes etc from a running stack.

- -Angus


Some things to note:
- - the entire mistral engine can be replaced with an engine level plugin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTjwz2AAoJEFrDYBLxZjWoEr0H/3nh66Umdw2nGUEs+SikigXa
XAN90NHHPuf1ssEqrF/rMjRKg+GvrLx+31x4oFfHEj7oplzGeVA9TJC0HOp4h6dh
iCeXAHF7KX+t4M4VuZ0y9TJB/jLxfxg4Qge7ENJpNDD/gggjMYSNhcWzBG87QBE/
Mi4YAvxNk1/C3/YZYx2Iujq7oM+6tflTeuoG6Ld72JMHryWT5/tdYZrCMnuD4F7Q
8a6Ge3t1dQh7ZlNHEuRDAg3G5oy+FInXyFasXYlYbtdpTxDL8/HbXegyAcsw42on
2ZKRDYBubQr1MJKvSV5I3jjOe4lxXXFylbWpYpoU8Y5ZXEKp69R4wrcVISF1jQQ=
=P0Sl
-----END PGP SIGNATURE-----

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/eabe2521/attachment.html>