My personal preference is using the VDSM debug hook to inject code to a running 
VDSM and dynamically add whatever you want.
This means the code is part of the test and not VDSM.

We used to use it (before the code rotted away) to add to VDSM the 
startCoverage() and endCoverage() verbs for tests.

Another option is having the code in an optional RPM (similar to how debug hook 
is loaded only if it's installed)

I might also accept unpythonic things like conditional compilation

Asking people nicely not to use a method that might corrupt their data-center 
doesn't always work with good people not to mention bad ones.

You could also just fix the design :)

----- Original Message -----
> From: "Federico Simoncelli" <fsimo...@redhat.com>
> To: "Saggi Mizrahi" <smizr...@redhat.com>
> Cc: "Dan Kenigsberg" <dan...@redhat.com>, vdsm-devel@lists.fedorahosted.org, 
> "Adam Litke" <a...@us.ibm.com>
> Sent: Wednesday, October 3, 2012 9:39:44 PM
> Subject: Re: API: Supporting internal/testing interfaces
> 
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizr...@redhat.com>
> > To: "Adam Litke" <a...@us.ibm.com>
> > Cc: "Dan Kenigsberg" <dan...@redhat.com>, fsimo...@redhat.com,
> > vdsm-devel@lists.fedorahosted.org
> > Sent: Wednesday, October 3, 2012 9:27:02 PM
> > Subject: Re: API: Supporting internal/testing interfaces
> > 
> > Never expose such things through the API.
> > I know that it is currently impossible to test the mailbox \
> > lvextend
> > flow without a full blown VDSM running because of bad design but
> > this doesn't imply we should expose testing interface through the
> > main public API.
> 
> Ok, given that in the future we'll have a proper design, what is the
> short term alternative to efficiently test the mailbox?
> 
> You also completely dismissed Adam's proposal to ship these in a
> separate
> libvdsm-debug.so library.
> 
> --
> Federico
> 
> > ----- Original Message -----
> > > From: "Adam Litke" <a...@us.ibm.com>
> > > To: vdsm-devel@lists.fedorahosted.org
> > > Cc: "Dan Kenigsberg" <dan...@redhat.com>, fsimo...@redhat.com,
> > > "Saggi Mizrahi" <smizr...@redhat.com>
> > > Sent: Wednesday, October 3, 2012 3:09:48 PM
> > > Subject: API: Supporting internal/testing interfaces
> > > 
> > > Hi,
> > > 
> > > A recent patch: http://gerrit.ovirt.org/#/c/8286/1 has brought up
> > > an
> > > important
> > > issue regarding the vdsm API and I would like to open up a
> > > discussion
> > > about how
> > > we should expose testing/internal interfaces in the
> > > next-generation
> > > vdsm API.
> > > 
> > > The above change exposes an internal HSM verb 'sendExtendMsg' via
> > > the
> > > xmlrpc
> > > interface.  There is no doubt that this is useful for testing and
> > > debugging the
> > > storage mailbox functionality.  Until now, all new APIs were
> > > required
> > > to be
> > > documented in the vdsm api schema so that they can be properly
> > > exported to end
> > > users.  But we don't really want end users to consume this
> > > particular
> > > API.
> > > 
> > > How should we handle this?  I see a few options:
> > > 
> > > 1) Don't document the API and omit it from the schema.  This is
> > > the
> > > patch's
> > > current approach.  I do not favor this approach because
> > > eventually
> > > the xmlrpc
> > > server will be going away and then we will lose the ability to
> > > use
> > > this new
> > > debugging API.  We need to decide how to support debugging
> > > interfaces
> > > going
> > > forward.
> > > 
> > > 2) Expose it in the schema as a debugging API.  This can be done
> > > by
> > > extending
> > > the symbol's dictionary with {'debug': True}.  Initially, the API
> > > documentation
> > > and code generators can simply skip over these symbols.  Later
> > > on,
> > > we
> > > could
> > > generate an independent libvdsm-debug.so library that includes
> > > these
> > > debugging
> > > APIs.
> > > 
> > > Thoughts?
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to