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

List:       vdsm-devel
Subject:    [vdsm] API: Supporting internal/testing interfaces
From:       agl () us ! ibm ! com (Adam Litke)
Date:       2012-10-04 14:38:47
Message-ID: 20121004143847.GA25171 () aglitke
[Download RAW message or body]

On Thu, Oct 04, 2012 at 09:22:31AM -0400, Federico Simoncelli wrote:
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizrahi at redhat.com>
> > To: dlaor at redhat.com
> > Cc: "Federico Simoncelli" <fsimonce at redhat.com>, vdsm-devel at 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 at redhat.com>
> > > To: "Saggi Mizrahi" <smizrahi at redhat.com>
> > > Cc: "Federico Simoncelli" <fsimonce at redhat.com>,
> > > vdsm-devel at 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).

In a perfect world, the code that does LV extend would exist in an independent
class (that doesn't depend on vdsm/hsm and can be tested with a simple,
standalone unit test.  Unfortunately, we do not live in a perfect world.  New
code should be testable in this way but we need something to test what we
already have.

We could always provide a debug rpm that enables a yet another binding for a
quick and dirty xmlrpc server.  This server would stick around even after the
normal BindingXMLRPC one is retired.  The debug server would have no API
formalization whatsoever and could be made pluggable so that test cases could be
easily dropped in.  This approach comes with just as many avenues of abuse as
the idea I had previously suggested.

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


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