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 <[email protected]>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 > > [email protected] > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > 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 [email protected]
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
