On Fri, Jun 01, 2012 at 01:59:25PM +0800, Mark Wu wrote:
On 05/31/2012 09:08 PM, 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! ;-)
No body dares to blame the VDSM maintainer! :P
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.
It seems I misunderstood your previous comments. I am sorry for that.
I'm even sorrier for not being clear enough!
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.
yes, we can pass an API.Global() instance to MOM, but MOM also needs to create API.VM instance. Without clientIF, I could pass a wrapped VM class to MOM. But it's ugly.
I admit it is not pretty. How about adding factory functions such as Global.constructVm() ? I think it would appease the no-singleton gods.
So I try to remove clientIF in API exposed interface, and make the caller can use vdsm API just after importing the module. It could be cleaner. What's your opinion?
Thanks a lot!!
Thank you. Either way I kinda fear the first out-of-prject dependecy on API.py. The latter API is not yet stable nor complete. Brace yourself to guard against surprises, and to move along as the API changes. I cannot stress enough the need for a unit test for every functionality required by mom.
Regards, Dan.