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

[Ray Chen]

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.salk...@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@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Angus Salkeld]

-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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev