----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
vdsm-devel(a)lists.fedorahosted.org, "Adam Litke" <agl(a)us.ibm.com>
Sent: Wednesday, October 3, 2012 9:52:03 PM
Subject: Re: API: Supporting internal/testing interfaces
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.
I can't get to like it.
Another option is having the code in an optional RPM (similar to how
debug hook is loaded only if it's installed)
That's Adam's proposal. It's my preferred option too if it will
be actually needed.
You could also just fix the design :)
I'm scared, you spent too much time in tlv, you start resembling
someone that I know well :)
--
Federico
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
> vdsm-devel(a)lists.fedorahosted.org, "Adam Litke" <agl(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" <smizrahi(a)redhat.com>
> > To: "Adam Litke" <agl(a)us.ibm.com>
> > Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
> > vdsm-devel(a)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" <agl(a)us.ibm.com>
> > > To: vdsm-devel(a)lists.fedorahosted.org
> > > Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
fsimonce(a)redhat.com,
> > > "Saggi Mizrahi" <smizrahi(a)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?
>