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