<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="">So again, I’m for simplicity but that kind of simplicity that also allows flexibility in the future.<div class=""><br class=""></div><div class="">There’s one principle that I usually follow in programming that says:</div><div class=""><br class=""></div><div class="">“<i class="">Space around code (absence of code) has more potential than the code itself.</i>”</div><div class=""><br class=""></div><div class="">That means that it’s better to get rid of any stuff that’s not currently needed and add things</div><div class="">as requirements change. However, that doesn’t always work well in framework development</div><div class="">because the cost of initial inflexibility may become too high in future, that comes from the</div><div class="">need to stay backwards compatible. What I’m trying to say is that IMO it’s ok just to keep</div><div class="">it as simple as just a base class with method run() for now and think how we can add more</div><div class="">things in the future, if we need to, using mixin approach. So seems like it’s going to be:</div><div class=""><br class=""></div><div class="">class Action(object):</div><div class=""><br class=""></div><div class=""> def run(ctx):</div><div class=""> …</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">class Mixin1(object):</div><div class=""> </div><div class=""> def method11():</div><div class=""> …</div><div class=""><br class=""></div><div class=""><div class=""> def method12():</div><div class=""> …</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">class Mixin2(object):</div><div class=""> </div><div class=""> def method21():</div><div class=""> …</div><div class=""><br class=""></div></div><div class=""><div class=""> def method22():</div><div class=""> …</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Then my concrete action could use a combination of Action and any of the mixin:</div><div class=""><br class=""></div><div class="">class MyAction(Action, Mixin1):</div><div class=""> …</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">class MyAction(Action, Mixin2):</div><div class=""> …</div></div><div class=""><br class=""></div><div class="">or just</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">class MyAction(Action):</div><div class=""> …</div></div><div class=""><br class=""></div><div class="">Is this flexible enough or does it have any potential issues?</div><div class=""><br class=""></div><div class="">IMO, base class is still needed to define the contract that all actions should follow. So that</div><div class="">a runner knew what’s possible to do with actions.</div><div class=""><div class=""><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 13 Mar 2017, at 16:49, lương hữu tuấn <<a href="mailto:tuantuluong@gmail.com" class="">tuantuluong@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 13, 2017 at 9:34 AM, Thomas Herve <span dir="ltr" class=""><<a href="mailto:therve@redhat.com" target="_blank" class="">therve@redhat.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Mar 10, 2017 at 9:52 PM, Ryan Brady <<a href="mailto:rbrady@redhat.com" class="">rbrady@redhat.com</a>> wrote:<br class="">
><br class="">
> One of the pain points for me as an action developer is the OpenStack<br class="">
> actions[1]. Since they all use the same method name to retrieve the<br class="">
> underlying client, you cannot simply inherit from more than one so you are<br class="">
> forced to rewrite the client access methods. We saw this in creating<br class="">
> actions for TripleO[2]. In the base action in TripleO, we have actions that<br class="">
> make calls to more than one OpenStack client and so we end up re-writing and<br class="">
> maintaining code. IMO the idea of using multiple inheritance there would be<br class="">
> helpful. It may not require the mixin approach here, but rather a design<br class="">
> change in the generator to ensure the method names don't match.<br class="">
<br class="">
</span>Is there any reason why those methods aren't functions? AFAICT they<br class="">
don't use the instance, they could live top level in the action module<br class="">
and be accessible by all actions. If you can avoid multiple<br class="">
inheritance (or inheritance!) you'll simplify the design. You could<br class="">
also do client = NovaAction().get_client() in your own action (if<br class="">
get_client was a public method).<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
--<br class="">
Thomas<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class=""></div></div></blockquote><div class="">If you want to do that, you need to change the whole structure of base action and the whole way of creating an action</div><div class="">as you have described and IMHO, i myself do not like this idea:<br class=""><br class="">1. Mistral is working well (at the standpoint of creating action) and changing it is not a short term work.</div><div class="">2. Using base class to create base action is actually a good idea in order to control and make easy to action developers. </div><div class="">The base class will define the whole mechanism to execute an action, developers do not need to take care of it, just only</div><div class="">providing OpenStack clients (the _create_client() method).</div><div class="">3. From the #2 point of view, the alternative to NovaAction().get_client() does not make sense since the problem here is subclass mechanism,</div><div class="">not the way to call get_client().<br class=""><br class="">@Renat: I myself not against to multiple inheritance too, the only thing is if we want to make it multiple inheritance, we should think about it more thoroughly for the hierarchy of inheritance, what each inheritance layer does, etc. These work will make the multiple inheritance easy to understand and for action developers as well easy to develop. So, IMHO, i vote for make it simple, easy to understand first (if you continue with mistral-lib) and then do the next thing later.<br class=""></div><div class=""><br class=""></div><div class="">Br,</div><div class=""><br class=""></div><div class="">Tuan/Nokia</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
______________________________<wbr class="">______________________________<wbr class="">______________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.<wbr class="">openstack.org?subject:<wbr class="">unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/<wbr class="">cgi-bin/mailman/listinfo/<wbr class="">openstack-dev</a><br class="">
</div></div></blockquote></div><br class=""></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></div></body></html>