----- Original Message ----- > From: "Saggi Mizrahi" <smizr...@redhat.com> > To: "Federico Simoncelli" <fsimo...@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:52:03 PM > Subject: Re: API: Supporting internal/testing interfaces > > 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.
I can't get to like it. > Another option is having the code in an optional RPM (similar to how > debug hook is loaded only if it's installed) That's Adam's proposal. It's my preferred option too if it will be actually needed. > You could also just fix the design :) I'm scared, you spent too much time in tlv, you start resembling someone that I know well :) -- Federico > ----- 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
