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