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

Reply via email to