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.


vdsm-devel mailing list

Reply via email to