Open Stack

Here is my "mixin way", draftly. https://review.openstack.org/#/c/53826/


On Fri, Oct 25, 2013 at 11:36 AM, Illia Khudoshyn
<ikhudoshyn at 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 <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
>



-- 

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/7b5c6248/attachment.html>