10:31 a.m.
----- Original Message -----
From: "Mooli Tayer" <mtayer(a)redhat.com>
To: vdsm-devel(a)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
3:27 a.m.
New subject: Fwd: [vdsm] modularizing vdsm-tool's configurators
[moving thread to devel(a)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(a)redhat.com>
To: "Mooli Tayer" <mtayer(a)redhat.com>
Cc: "engine-devel(a)ovirt.org" <devel(a)ovirt.org>, "Yaniv Bronheim"
<ybronhei(a)redhat.com>, "Yeela Kaplan" <ykaplan(a)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(a)redhat.com>
To: vdsm-devel(a)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
3497
days inactive
3502
days old
1 comments
2 participants
participants (2)
-
Mooli Tayer -
Nir Soffer