Here is my "mixin way", draftly. https://review.openstack.org/#/c/53826/
On Fri, Oct 25, 2013 at 11:36 AM, Illia Khudoshyn <ikhudos...@mirantis.com>wrote: > I'll try to code it this weekend. Hope, could be able to show it by Monday. > > > On Fri, Oct 25, 2013 at 7:46 AM, Michael Basnight <mbasni...@gmail.com>wrote: > >> >> On Oct 23, 2013, at 7:03 AM, Illia Khudoshyn wrote: >> >> > Hi Denis, Michael, Vipul and all, >> > >> > I noticed a discussion in irc about adding a single entry point (sort >> of 'SuperManager') to the guestagent. Let me add my 5cent. >> > >> > I agree with that we would ultimately avoid code duplication. But from >> my experience, only very small part of GA Manager can be considered as >> really duplicated code, namely Manager#prepare(). A 'backup' part may be >> another candidate, but I'm not yet. It may still be rather service type >> specific. All the rest of the code was just delegating. >> >> Yes, currently that is the case :) >> >> > >> > If we add a 'SuperManager' all we'll have -- just more delegation: >> > >> > 1. There is no use for dynamic loading of corresponding Manager >> implementation because there will never be more than one service type >> supported on a concrete guest. So current implementation with configurable >> dictionary service_type->ManagerImpl looks good for me. >> > >> > 2. Neither the 'SuperManager' provide common interface for Manager -- >> due to dynamic nature of python. As it has been told, >> trove.guestagent.api.API provides list of methods with parameters we need >> to implement. What I'd like to have is a description of types for those >> params as well as return types. (Man, I miss static typing). All we can do >> for that is make sure we have proper unittests with REAL values for params >> and returns. >> > >> > As for the common part of the Manager's code, I'd go for extracting >> that into a mixin. >> >> When we started talking about it, i mentioned to one of the rackspace >> trove developers privately we might be able to solve effectively w/ a mixin >> instead of more "parent" classes :) I would like to see an example of both >> of them. At the end of the day all i care about is not having more copy >> pasta between manager impls as we grow the "common" stuff. even if that is >> just a method call in each guest to call each bit of common code. >> >> > >> > Thanks for your attention. >> > >> > -- >> > Best regards, >> > Illia Khudoshyn, >> > Software Engineer, Mirantis, Inc. >> > >> > 38, Lenina ave. Kharkov, Ukraine >> > www.mirantis.com >> > www.mirantis.ru >> > >> > Skype: gluke_work >> > ikhudos...@mirantis.com >> > _______________________________________________ >> > 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 >> >> > > > -- > > Best regards, > > Illia Khudoshyn, > Software Engineer, Mirantis, Inc. > > > > 38, Lenina ave. Kharkov, Ukraine > > www.mirantis.com <http://www.mirantis.ru/> > > www.mirantis.ru > > > > Skype: gluke_work > > ikhudos...@mirantis.com > -- Best regards, Illia Khudoshyn, Software Engineer, Mirantis, Inc. 38, Lenina ave. Kharkov, Ukraine www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru Skype: gluke_work ikhudos...@mirantis.com
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
