Open Stack

Hi Augus,

I agree with that 'trigger' should not be put in workbook. in current
implement, it's hard to get the execution context while schedule trigger.

Here is one bug to complain about missing context.
https://bugs.launchpad.net/mistral/+bug/1335758

Thanks,
Ray

On Tue, Jun 10, 2014 at 1:59 PM, Angus Salkeld <angus.salkeld at rackspace.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> I was looking at
> https://blueprints.launchpad.net/mistral/+spec/mistral-ceilometer-integration
> and trying to figure out how to implement that.
>
> I can see some problems:
> - - at the moment the trust is created when you PUT the workbook definition
>   this means that if a totally different user executes the workbook, it
> will be run as the user that
> created the workbook :-O
>
> https://github.com/stackforge/mistral/blob/master/mistral/services/workbooks.py#L27
>
> https://github.com/stackforge/mistral/blob/master/mistral/engine/data_flow.py#L92
> - - Workbooks can't be sharable if the trust is created at workbook create
> time.
> - - If the trust is not created at workbook create time, how do you use
> triggers?
>
> It seems to me that it is a mistake putting the "triggers" in the workbook
> because there are three entities here:
> 1) the shareable workbook with tasks (a template really that could be
> stored in glance)
> 2) the execution entity (keeps track of the running tasks)
> 3) the person / trigger that initiates the execution
>    - execution context
>    - authenticated token
>
> if we put "3)" into "1)" we are going to have authentication issues and
> potentially give up the idea of sharing workbooks.
>
> I'd suggest we have a new entity (and endpoint) for triggers.
> - - This would associate 3 things: trust_id, workbook and trigger rule
> - - This could also be then used to generate a URL for ceilometer or solum
> to call
>   in an autonomous way.
> - - One issue is if your workflow takes a *really* long time and you don't
> use the
>   trigger then you won't have a trust, but a normal user token. But maybe
> if
>   the manually initiates the execution, we can create a "manual trigger"
> in the
>   background?
>
> I can also help out with:
> https://blueprints.launchpad.net/mistral/+spec/mistral-multitenancy
> I believe all that needs to be done is to filter the db items by
> project_id that is
> in the user context.
>
> Any thoughts on the above (or better ways of moving forward)?
>
> - -Angus
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTlp7HAAoJEFrDYBLxZjWoqtAH/3Un3miZmcPjXCO/klU7jsXw
> nEYQhWBI+IJuZ5W9MgSHkLg2PwfL6nFxhzyFjG5GloH7QQjO+jGIeE+sBSwPPF/K
> kTkllROUhzOO+VFMTIA3y+c173oklmmUtznbuUvDLgLtxNEgtxOWyvZMF3vHO5sS
> VkzfSXhg+VbZdg7lVqkaPOtRY/tJ7uVvtskeGZJRIVbE1iINGtqW0aC0WMXXLb7c
> 7ek8H9lYuxiQ10++7lU+0g6Yn6Momtcmh5j+dTZvJsZw/XEPCc+aDYsE+Yz9tqwb
> blh2tWAqNri+xWtumyIAnfv2teJtiDUkzRqRTwxycBOdrkhQ6Nq0RpTCg15jNsA=
> =TXJE
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20140713/3cd8d2f1/attachment.html>