Re: [vdsm] API: Supporting internal/testing interfaces

[Federico Simoncelli]

----- Original Message -----
>  From: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt;
>  To: dlaor(a)redhat.com
>  Cc: "Federico Simoncelli" <fsimonce(a)redhat.com&gt;,
> vdsm-devel(a)lists.fedorahosted.org
>  Sent: Thursday, October 4, 2012 1:27:27 PM
>  Subject: Re: [vdsm] API: Supporting internal/testing interfaces
>  
>  ----- Original Message -----
>  > From: "Dor Laor" <dlaor(a)redhat.com&gt;
>  > To: "Saggi Mizrahi" <smizrahi(a)redhat.com&gt;
>  > Cc: "Federico Simoncelli" <fsimonce(a)redhat.com&gt;,
>  > vdsm-devel(a)lists.fedorahosted.org
>  > Sent: Wednesday, October 3, 2012 10:16:26 PM
>  > Subject: Re: [vdsm] API: Supporting internal/testing interfaces
>  > 
>  > On 10/03/2012 09:52 PM, Saggi Mizrahi wrote:
>  > > 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.
>  > 
>  > That's might be good for debugging/tracing but not for full
>  > functional
>  > tests. There are also better ways for dynamic tracing.
>  > 
>  > >
>  > > 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.
>  > 
>  > Using -test devices/interfaces is a common practice. It's good to
>  > keep
>  > them live within the code base so they won't get rotten and any
>  > reasonable user is aware it's only a test api.
>  > 
>  > Downstream can always compile it out before shipping.
>  
>  Conditional compilation kind of awkward in python, but as I said I'll
>  agree to have that as an option.
>  From what I understand litke's proposal is having the bindings in a
>  different RPM but I am actually talking about the server side code
>  not being available or at least hooked up. 
I thought that the server side was modular too and Adam's proposal was
a server side additional module that registers new verbs to expose.

>  In any case, I personally like this being hard and tiresome to do
>  because it makes living with bad design less tolerable. 
There are some things that are harder to test and debug no matter how
you implement them. To see a single extension you have to start a vm
and wait for the guest to fill the lv. A better design wouldn't change
the fact that if you don't expose a verb you can't use it.

>  In any case, I don't want new code to need to have special debug
>  verbs, if you don't test a full VDSM you shouldn't need to have one
>  running. 
Why you think that one thing should exclude the other. Here we're talking
about providing easier ways to test more (not less).

-- 
Federico