<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Ryan,<div class=""><br class=""></div><div class="">Keeping in mind that 'mistral-lib' must not depend on ‘mistral’ below are my comments:</div><div class=""><ul class="MailOutline"><li class="">I think porting keystone utils over to mistral-lib is OK, I don’t see any other options (‘mistral’ will depend on ‘mistral-lib’ but not the way around)</li><li class="">Porting the entire mistral.context is OK too for the same reason.</li><li class="">Porting the entire exceptions.py module is OK. But.. All general exceptions not related to actions should not be under ‘actions/api’ because this package should contain only stuff needed for implementing new actions. I would suggest we move all the exceptions into ‘mistral_lib/exceptions.py’ but keep ActionException (and other possible exceptions inherited from it) in ‘mistral_lib/actions/api.py”. That way the design would stay clean. As a rule of thumb: we need to keep under ‘api’ as little as possible, only that stuff that is really supposed to be stable and hence can be treated as API.</li></ul><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">Any other comments are very welcome.</div><div class=""><br class="webkit-block-placeholder"></div><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Renat Akhmerov</div><div class="">@Nokia</div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">8 авг. 2016 г., в 21:33, Ryan Brady <<a href="mailto:rbrady@redhat.com" class="">rbrady@redhat.com</a>> написал(а):</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I started looking at the context requirements from two separate points of view:</div><div class=""> - create a security context in mistral lib that could be an attribute in the mistral context</div><div class=""> - port entire mistral context over</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I would appreciate any feedback or discussion on the current proposed design.<br class=""></div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">Ryan</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://specs.openstack.org/openstack/mistral-specs/specs/newton/approved/mistral-custom-actions-api.html" class="">https://specs.openstack.org/openstack/mistral-specs/specs/newton/approved/mistral-custom-actions-api.html</a></div><div class=""><br class="">[2] <a href="https://review.openstack.org/#/c/352435/" class="">https://review.openstack.org/#/c/352435/</a><br class=""></div><div class=""><br class=""></div><div class="">[3] <a href="https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py" class="">https://github.com/openstack/mistral/blob/master/mistral/utils/openstack/keystone.py</a></div><div class=""><br class=""></div><div class="">[4] <a href="https://github.com/openstack/mistral/blob/master/mistral/context.py#L76-L87" class="">https://github.com/openstack/mistral/blob/master/mistral/context.py#L76-L87</a></div><div class=""><br class=""></div><div class="">[5] <a href="https://github.com/openstack/mistral/blob/master/mistral/utils/__init__.py#L49-L94" class="">https://github.com/openstack/mistral/blob/master/mistral/utils/__init__.py#L49-L94</a></div><div class=""><br class=""></div><div class="">[6] <a href="https://github.com/openstack/mistral/blob/master/mistral/exceptions.py" class="">https://github.com/openstack/mistral/blob/master/mistral/exceptions.py</a></div><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class="">Ryan Brady<div class="">Cloud Engineering</div><div class=""><a href="mailto:rbrady@redhat.com" target="_blank" class="">rbrady@redhat.com</a> </div><div class="">919.890.8925</div></div></div>
</div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></div></body></html>