<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=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">I probably like the base class approach better too.</div><div class=""><br class=""></div><div class="">However, I’m trying to understand if we need this variety of classes.</div><div class=""><ul class="MailOutline"><li class="">Do we need a separate class for asynchronous actions? IMO, since is_sync() is just an instance method that can potentially return both True and False based on the instance state shouldn’t be introduced by a special class. Otherwise it’s confusing that a classes declared as AsyncAction can actually be synchronous (if its is_sync() returns True). So maybe we should just leave this method in the base class.</li><li class="">I”m also wondering if we should just always pass “context” into run() method. Those action implementations that don’t need it could just ignore it. Not sure though.</li></ul><div class=""><br class=""></div></div><div class="">As far as mixin approach, I’d say I’d be ok with having mixing for context-based actions. Although, like Dougal said, it may be a little harder to read, this approach gives a huge flexibility for long term. Imagine if we want to have a class of actions that some different kind of information. Just making it up… For example, some of my actions need to be aware of some policies (Congress-like) or information about metrics of the current operating system (this is probably a bad example because it’s easy to use standard Python modules but I’m just trying to illustrate the idea). In this case we could have PolicyMixin and OperatingSystemMixin that would set required info into the instance state or provide with handle interfaces for more advanced uses.</div><div class=""><br class=""></div><div class="">What do you think?</div><br class=""><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="">On 9 Mar 2017, at 11:35, Ryan Brady <<a href="mailto:rbrady@redhat.com" class="">rbrady@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">At the PTG and previous discussions in IRC, I mentioned there were two different design ideas I had for the developer experience for custom action development in mistral-lib. The purpose and intent behind the patch[1] was discussed in person at the PTG and that was helpful for me wrt to scope. I feel it would be helpful to discuss and decide together the final piece of this patch. I'd like to get any feedback on either of these two ideas as they will shape how developers integrate with Mistral in the future, impact our OpenStack integration efforts in mistral-extra. Nothing stops a developer from adopting either style in their custom action libraries, but most will likely want to remain consistent with style present in the upstream code.<div class=""><br class=""></div><div class="">I have created separate declaration and usage examples in hopes of illustrating some of the similarities and differences. To me it seems the base class example is more declarative/explicit, but the mixin example is more extensible and dry. Both examples reflect on backwards compatibility and possible changes to how mistral checks for sync/async actions and how to pass the context (as needed by actions that integrate with OpenStack).<div class=""><br clear="all" class=""><div class=""><br class=""></div><div class="">base classes declaration: <a href="https://gist.github.com/rbrady/ff86c484e8e6e53ba2dc3dfa17b01b09" class="">https://gist.github.com/rbrady/ff86c484e8e6e53ba2dc3dfa17b01b09</a></div><div class=""><br class=""></div><div class="">base class usage: <a href="https://gist.github.com/rbrady/716a02fb2bd38d822c6df8bd642d3ea6" class="">https://gist.github.com/rbrady/716a02fb2bd38d822c6df8bd642d3ea6</a></div><div class=""><br class=""></div><div class="">mixins declaration: <a href="https://gist.github.com/rbrady/d30ae640b19df658a17cd93827125678" class="">https://gist.github.com/rbrady/d30ae640b19df658a17cd93827125678</a></div><div class=""><br class=""></div><div class="">mixins usage: <a href="https://gist.github.com/rbrady/248cb52d5c5f94854d8c76eee911ce8e" class="">https://gist.github.com/rbrady/248cb52d5c5f94854d8c76eee911ce8e</a></div><div class=""><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>-- <br class=""><div class="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 class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://review.openstack.org/#/c/411412/" class="">https://review.openstack.org/#/c/411412/</a><br class=""></div></div></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=""></body></html>