----- 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.

In any case, I personally like this being hard and tiresome to do because it 
makes living with bad design less tolerable.

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.
> 
> Regards,
> Dor
> 
> >
> > You could also just fix the design :)
> >
> > ----- Original Message -----
> >> From: "Federico Simoncelli" <fsimo...@redhat.com>
> >> To: "Saggi Mizrahi" <smizr...@redhat.com>
> >> Cc: "Dan Kenigsberg" <dan...@redhat.com>,
> >> vdsm-devel@lists.fedorahosted.org, "Adam Litke" <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" <smizr...@redhat.com>
> >>> To: "Adam Litke" <a...@us.ibm.com>
> >>> Cc: "Dan Kenigsberg" <dan...@redhat.com>, fsimo...@redhat.com,
> >>> vdsm-devel@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" <a...@us.ibm.com>
> >>>> To: vdsm-devel@lists.fedorahosted.org
> >>>> Cc: "Dan Kenigsberg" <dan...@redhat.com>, fsimo...@redhat.com,
> >>>> "Saggi Mizrahi" <smizr...@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?
> >>
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> 
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to