[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