8:09 a.m.
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?
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
2:27 p.m.
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.
----- Original Message -----
From: "Adam Litke" <agl(a)us.ibm.com>
To: vdsm-devel(a)lists.fedorahosted.org
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
"Saggi Mizrahi" <smizrahi(a)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?
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
2:39 p.m.
----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: "Adam Litke" <agl(a)us.ibm.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
vdsm-devel(a)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" <agl(a)us.ibm.com>
> To: vdsm-devel(a)lists.fedorahosted.org
> Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
> "Saggi Mizrahi" <smizrahi(a)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?
2:52 p.m.
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.
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.
You could also just fix the design :)
----- Original Message -----
From: "Federico Simoncelli" <fsimonce(a)redhat.com>
To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
vdsm-devel(a)lists.fedorahosted.org, "Adam Litke" <agl(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" <smizrahi(a)redhat.com>
> To: "Adam Litke" <agl(a)us.ibm.com>
> Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
> vdsm-devel(a)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" <agl(a)us.ibm.com>
> > To: vdsm-devel(a)lists.fedorahosted.org
> > Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
> > "Saggi Mizrahi" <smizrahi(a)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?
3:05 p.m.
----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
vdsm-devel(a)lists.fedorahosted.org, "Adam Litke" <agl(a)us.ibm.com>
Sent: Wednesday, October 3, 2012 9:52:03 PM
Subject: Re: API: Supporting internal/testing interfaces
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.
We used to use it (before the code rotted away) to add to VDSM the
startCoverage() and endCoverage() verbs for tests.
I can't get to like it.
Another option is having the code in an optional RPM (similar to how
debug hook is loaded only if it's installed)
That's Adam's proposal. It's my preferred option too if it will
be actually needed.
You could also just fix the design :)
I'm scared, you spent too much time in tlv, you start resembling
someone that I know well :)
--
Federico
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
> vdsm-devel(a)lists.fedorahosted.org, "Adam Litke" <agl(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" <smizrahi(a)redhat.com>
> > To: "Adam Litke" <agl(a)us.ibm.com>
> > Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
> > vdsm-devel(a)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" <agl(a)us.ibm.com>
> > > To: vdsm-devel(a)lists.fedorahosted.org
> > > Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
fsimonce(a)redhat.com,
> > > "Saggi Mizrahi" <smizrahi(a)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?
>
3:16 p.m.
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.
Regards,
Dor
You could also just fix the design :)
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
vdsm-devel(a)lists.fedorahosted.org, "Adam Litke" <agl(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" <smizrahi(a)redhat.com>
>> To: "Adam Litke" <agl(a)us.ibm.com>
>> Cc: "Dan Kenigsberg" <danken(a)redhat.com>, fsimonce(a)redhat.com,
>> vdsm-devel(a)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" <agl(a)us.ibm.com>
>>> To: vdsm-devel(a)lists.fedorahosted.org
>>> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
fsimonce(a)redhat.com,
>>> "Saggi Mizrahi" <smizrahi(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
6:27 a.m.
----- Original Message -----
From: "Dor Laor" <dlaor(a)redhat.com>
To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>,
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.
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" <fsimonce(a)redhat.com>
>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
>> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
>> vdsm-devel(a)lists.fedorahosted.org, "Adam Litke"
<agl(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" <smizrahi(a)redhat.com>
>>> To: "Adam Litke" <agl(a)us.ibm.com>
>>> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
fsimonce(a)redhat.com,
>>> vdsm-devel(a)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" <agl(a)us.ibm.com>
>>>> To: vdsm-devel(a)lists.fedorahosted.org
>>>> Cc: "Dan Kenigsberg" <danken(a)redhat.com>,
fsimonce(a)redhat.com,
>>>> "Saggi Mizrahi" <smizrahi(a)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(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
8:22 a.m.
----- Original Message -----
From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
To: dlaor(a)redhat.com
Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>,
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>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>,
> 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
9:38 a.m.
On Thu, Oct 04, 2012 at 09:22:31AM -0400, Federico Simoncelli wrote:
----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> To: dlaor(a)redhat.com
> Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>,
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>
> > To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> > Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>,
> > 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).
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(a)us.ibm.com>
IBM Linux Technology Center
4243
days inactive
4244
days old
vdsm-devel@lists.fedorahosted.org
8 comments
4 participants
participants (4)
-
agl＠us.ibm.com -
Dor Laor -
Federico Simoncelli -
smizrahi＠redhat.com