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" <>
> To:
> Cc: "Dan Kenigsberg" <>,, "Saggi 
> Mizrahi" <>
> Sent: Wednesday, October 3, 2012 3:09:48 PM
> Subject: API: Supporting internal/testing interfaces
> Hi,
> A recent patch: 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 library that includes these
> debugging
> APIs.
> Thoughts?
> --
> Adam Litke <>
> IBM Linux Technology Center
vdsm-devel mailing list

Reply via email to