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:
> 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