Cancelled: vdsm call
by Dan Kenigsberg
A single instance of the following meeting has been cancelled:
Subject: vdsm call
Organizer: "Dan Kenigsberg" <dkenigsb(a)redhat.com>
Time: Tuesday, October 14, 2014, 2:30:00 PM - 3:30:00 PM GMT +00:00 Britain, Ireland, Portugal
Invitees: vdsm-devel(a)lists.fedorahosted.org; otavio.ferranti(a)eldorado.org.br; smizrahi(a)redhat.com; asegurap(a)redhat.com; dkuznets(a)redhat.com; ybronhei(a)redhat.com; bazulay(a)redhat.com; fromani(a)redhat.com; fsimonce(a)redhat.com; scohen(a)redhat.com; ovedo(a)redhat.com ...
*~*~*~*~*~*~*~*~*~*
If you receive this e-mail, it means that you are invited to the
bi-weekly phone meeting of Vdsm developers. This is an opportunity
to discuss design problems, pending patches, and persistent bugs.
Even if you do not join, you may solicit subjects for discussion on
the mailing list or over #vdsm(a)irc.freenode.net.
Note the new meeting time and conference code.
Conference code: 353-86-075-901.
Dial-in information:
https://www.intercallonline.com/listNumbersByCode.action?confCode=3538607...
9 years, 7 months
modularizing vdsm-tool's configurators
by mtayer@redhat.com
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.
I would like to know:
1.) If there are any objections to this.
2.) What is the best way to describe the interface for future
implementers. A text file at configurators package __init__?
at the class using the implementations? Are there any examples
for this inside vdsm?
Thanks,
Mooli tayer.
9 years, 8 months