[openstack-dev] [mistral] Multi-tenancy and ceilometer triggers

Angus Salkeld angus.salkeld at RACKSPACE.COM
Tue Jun 10 05:59:34 UTC 2014


-----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-----



More information about the OpenStack-dev mailing list