[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vdsm-devel
Subject:    [vdsm] VDSM API/clientIF instance design issue
From:       agl () us ! ibm ! com (Adam Litke)
Date:       2012-05-31 14:07:33
Message-ID: 20120531140733.GI4096 () localhost ! localdomain
[Download RAW message or body]

On Thu, May 31, 2012 at 04:08:52PM +0300, Dan Kenigsberg wrote:
> 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.

Today, the API consists of several, unlinked objects so passing a single
API.Global() would not be enough.  We either need to allow MOM to construct its
own API objects or produce them by calling methods in API.Global().  Personally,
I think the code would be cleaner if clientIF is a singleton (Mark's latest
patch) as opposed to adding factory methods to API.Global().

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center

[prev in list] [next in list] [prev in thread] [next in thread]