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 <a...@us.ibm.com>
IBM Linux Technology Center
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
