[moving thread to devel@ovirt.org] In order the be less vague: http://gerrit.ovirt.org/#/c/33914/ As this is a future plan I do not mind prosponing/rebasing on whatever is needed. Thanks, Mooli. ----- Forwarded Message ----- From: "Nir Soffer" <nsoffer@redhat.com> To: "Mooli Tayer" <mtayer@redhat.com> Cc: "engine-devel@ovirt.org" <devel@ovirt.org>, "Yaniv Bronheim" <ybronhei@redhat.com>, "Yeela Kaplan" <ykaplan@redhat.com> Sent: Friday, October 3, 2014 6:31:48 PM Subject: Re: [vdsm] modularizing vdsm-tool's configurators ----- Original Message -----

From: "Mooli Tayer" <mtayer@redhat.com> To: vdsm-devel@fedorahosted.org Sent: Friday, October 3, 2014 4:08:03 PM Subject: [vdsm] modularizing vdsm-tool's configurators

It has been suggested before to convert vdsm-tool's configurators form classes to modules and to express their interface using duck typing rather than inheritance.

I would like to get to it now before any new configurators join.

We have new multipath configurator (started in April). Having it in is more important then redesign. http://gerrit.ovirt.org/30909

I would like to know: 1.) If there are any objections to this.

I think the current configurators are in great shape and do not need any change. What is the motivation to change them? What are the possible advantages? What are the other tasks that will be postponed by this work? Nir