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
- Original Message -
> From: "Saggi Mizrahi"
> To: "Federico Simoncelli"
> Cc: "Dan Kenigsberg" , vdsm-devel@lists.fedorahosted.org,
> "Adam Litke"
> Sent: Wednesday, October 3, 2012 9:52:03 PM
> Subject: Re: API: Supporting internal/testing interfaces
>
> My personal preference is usi
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.
- Original Message -
> From: "Saggi Mizrahi"
> To: "Adam Litke"
> Cc: "Dan Kenigsberg" , 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
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:
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 'sendExten
On Tue, Oct 02, 2012 at 07:39:32PM -0400, Ayal Baron wrote:
>
Ayal, thanks for your thorough treatment of this subject :) I completely agree
with the framework that you have laid out here. Hopefully, we can all come to
an agreement on a quasi-official project-wide policy based on this and then
p