----- Original Message -----
> From: "Saggi Mizrahi" <smizr...@redhat.com>
> To: dl...@redhat.com
> Cc: "Federico Simoncelli" <fsimo...@redhat.com>, 
> vdsm-devel@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" <dl...@redhat.com>
> > To: "Saggi Mizrahi" <smizr...@redhat.com>
> > Cc: "Federico Simoncelli" <fsimo...@redhat.com>,
> > vdsm-devel@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
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to