In accordance with the spec[1], I started a patch[2] to port security related items from mistral to mistral-lib. This may not be the right way to approach this task and I'm hoping the patch provides a means to illustrate the problem and starts a discussion on the right solution. A custom action that creates a client that requires keystone auth will need to get an endpoint for a given project to create a client object, so I ported over the utility class[3] that deals with keystone. That utility class requires the mistral.context. I started looking at the context requirements from two separate points of view: - create a security context in mistral lib that could be an attribute in the mistral context - port entire mistral context over When I looked at the attributes[4] currently in the mistral.context, most if not all of them seem to be security related anyway. I chose to port the entire context over, but that also required dependencies on 4 threading utility methods[5] and mistral.exceptions[6], so those were also ported over. I would appreciate any feedback or discussion on the current proposed design. Thanks, Ryan [1] https://specs.openstack.org/openstack/mistral-specs/specs/newton/approved/mistral-custom-actions-api.html [2] https://review.openstack.org/#/c/352435/ [3] https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py [4] https://github.com/openstack/mistral/blob/master/mistral/context.py#L76-L87 [5] https://github.com/openstack/mistral/blob/master/mistral/utils/__init__.py#L49-L94 [6] https://github.com/openstack/mistral/blob/master/mistral/exceptions.py -- Ryan Brady Cloud Engineering rbrady at redhat.com 919.890.8925 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160808/516c1441/attachment.html>