On Thu, May 31, 2012 at 09:03:37PM +0800, Mark Wu wrote: > On 05/30/2012 11:01 PM, Dan Kenigsberg wrote: > >On Wed, May 30, 2012 at 10:49:29PM +0800, Mark Wu wrote: > >>Hi Guys, > >> > >>Recently, I has been working on integrate MOM into VDSM. MOM needs > >>to use VDSM API to interact with it. But currently, it requires the > >>instance of clientIF to use vdsm API. Passing clientIF to MOM is > >>not a good choice since it's a vdsm internal object. So I try to > >>remove the parameter 'cif' from the interface definition and change > >>to access the globally unique clientIF instance in API.py. > >Please remind me - why don't we continue to pass the clientIF instance, > >even if it means mentioning it each and every time an API.py object is > >created? It may be annoying (and thus serve as a reminder that we should > >probably retire much of clientIF...), but it should work. > > > In the old MOM integration patch, I passed the clientIF instance to > MOM by the following method: > vdsmInterface.setConnection(self._cif) > > Here's your comments on the patch: > > "_cif is not the proper API to interact with Vdsm. API.py is. Please > change MOM to conform to this, if possible. > > I think that mom should receive an API object (even API.Global()!) > that it needs for its operation. Even passing BindingXMLRPC() object > is more APIish than the internal clientIF object."
Please do not blame me! ;-) I do not mind passing an API.Global() that happens to hold an internal private reference to _clientIF. I just want that if we find the way to obliterate clientIF, we won't need to send a patch to MOM, too. > > So I try to remove cif from API definition to make MOM can call the > VDSM API without having clientIF. I do not understand - MOM could receive an API object, it does not have to construct it by itself. Regards, Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel