Open Stack

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 <mbasnight at 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
> > ikhudoshyn at mirantis.com
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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

ikhudoshyn at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131025/61b371f9/attachment.html>