[ovirt-devel] Killing XMLRPC on master

[Michal Skrivanek]

> On 20 Jun 2016, at 18:41, Piotr Kliczewski <pkliczew at redhat.com> wrote:
> 
> 
> 
> On Mon, Jun 20, 2016 at 6:22 PM, Nir Soffer <nsoffer at redhat.com <mailto:nsoffer at redhat.com>> wrote:
> On Mon, Jun 20, 2016 at 11:33 AM, Martin Sivak <msivak at redhat.com <mailto:msivak at redhat.com>> wrote:
> >> 1. Mom is still using xmlrpc
> >>
> >> Mom must move to jsonrpc.
> >> Martin: can you update on progress of this work?
> >
> > We would like to avoid going through VDSM completely, except from the
> > broker part. Is it possible now to "parasitically" listen to vdsm
> > events and engine commands without having to go through VDSM API?
> 
> Sounds like a good plan.

bypassing vdsm for mom things is a good idea, but we need to make sure we’re not killing the rest of the system

> 
> Piotr, how far are we from letting mom listen to engine queue so it get engine
> events/responses for certain verbs?

> 
> We can do it now for both events and responses. We need to remember that we would
> receive anything that the engine is receiving. We could do better but that it would take
> more time.

so it would receive all responses for only the defined verbs?
It would wok well for getAllVmStats

>  
> 
> > You can drop XML RPC,. vdsm does not depend on MOM working anymore.
> > Just the balloon and ksm stats will be missing from data that are
> > being sent to the engine.

and a lot of things stops working then;)

> 
> Balloon and ksm stats are sent today from mom to vdsm, and reported by
> vdsm to engine?
> 
> If vdsm is only a middleman  and does not use this info, best to send
> it directly
> to engine via the stomp broker part of vdsm.
> 
> Piotr, how far are we from having engine listening for mom events using the
> vdsm broker?

I don’t think we should move any monitoring pulled from libvirt into mom - it would need another expensive and problematic call

> 
> It can be used now but the engine needs to know to listen for them. We would 
> need to implement engine subscriber (one class). 
>  
> 
> > There also were some issues with eventfd in the json library, I assume
> > those are fixed now.
> 
> They should be fixed here:
> https://gerrit.ovirt.org/57942 <https://gerrit.ovirt.org/57942>
> 
> But suffering from these issue show that the api was not use properly,
> you should create one client and reuse it for the entire life of the
> application.
> 
> 
> Nir
> 
> >
> > Martin
> >
> > On Sun, Jun 19, 2016 at 1:02 PM, Nir Soffer <nsoffer at redhat.com <mailto:nsoffer at redhat.com>> wrote:
> >> Hi all,
> >>
> >> We are still wasting time on maintaining both xmlrpc and jsonrpc. If we kill
> >> xmlrpc, we can greatly simplify the code base, making it easier to mainain
> >> and add new features.
> >>
> >> I suggest to kill xmlrpc in 4.1, and disable it *now* on master.
> >>
> >> Currently the we have 3 issues:
> >>
> >> 1. Mom is still using xmlrpc
> >>
> >> Mom must move to jsonrpc.
> >> Martin: can you update on progress of this work?
> >>
> >> 2. sos plugin using vdsClient
> >>
> >> Need to port it to use jsonrpc library, or jsonrpc client
> >>
> >> New jsonrpc client:  https://gerrit.ovirt.org/35181 <https://gerrit.ovirt.org/35181>
> >>
> >> 3. Engine is using xmlrpc server for ovf upload/download
> >>
> >> We must support current engine in 4.1, so we cannot remove
> >> upload/download feature in this version, but we can remove the
> >> xmlrpc support in this server.
> >>
> >> Currently we abuse the xmlrpc server, supporting PUT and GET for
> >> upload and download (XMLRPC is using only POST). We can disable
> >> POST requests in protocoldetector, and not register anything with
> >> the xmlrpc server.
> >>
> >> Thoughts?
> >>
> >> Nir
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160622/2548386a/attachment-0001.html>