On 20 Jun 2016, at 18:41, Piotr Kliczewski <pkliczew@redhat.com> = wrote: =20 =20 =20 On Mon, Jun 20, 2016 at 6:22 PM, Nir Soffer <nsoffer@redhat.com = <mailto:nsoffer@redhat.com>> wrote: On Mon, Jun 20, 2016 at 11:33 AM, Martin Sivak <msivak@redhat.com = <mailto:msivak@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 =
--Apple-Mail=_16763C7B-934F-44FC-84DF-77685A35781C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 the
broker part. Is it possible now to "parasitically" listen to vdsm events and engine commands without having to go through VDSM API? =20 Sounds like a good plan.
bypassing vdsm for mom things is a good idea, but we need to make sure = we=E2=80=99re not killing the rest of the system
=20 Piotr, how far are we from letting mom listen to engine queue so it = get engine events/responses for certain verbs?
=20 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
=20 =20
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;)
=20 Balloon and ksm stats are sent today from mom to vdsm, and reported by vdsm to engine? =20 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. =20 Piotr, how far are we from having engine listening for mom events = using the vdsm broker?
=20 It can be used now but the engine needs to know to listen for them. We = would=20 need to implement engine subscriber (one class).=20 =20 =20
There also were some issues with eventfd in the json library, I = assume those are fixed now. =20 They should be fixed here: https://gerrit.ovirt.org/57942 <https://gerrit.ovirt.org/57942> =20 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. =20 =20 Nir =20
Martin
On Sun, Jun 19, 2016 at 1:02 PM, Nir Soffer <nsoffer@redhat.com = <mailto:nsoffer@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 =
I don=E2=80=99t think we should move any monitoring pulled from libvirt = into mom - it would need another expensive and problematic call 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 =20
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_16763C7B-934F-44FC-84DF-77685A35781C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 20 Jun 2016, at 18:41, Piotr Kliczewski <<a = href=3D"mailto:pkliczew@redhat.com" class=3D"">pkliczew@redhat.com</a>>= wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" class=3D""><br class=3D""><div class=3D"gmail_extra"><br = class=3D""><div class=3D"gmail_quote">On Mon, Jun 20, 2016 at 6:22 PM, = Nir Soffer <span dir=3D"ltr" class=3D""><<a = href=3D"mailto:nsoffer@redhat.com" target=3D"_blank" = class=3D"">nsoffer@redhat.com</a>></span> wrote:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On = Mon, Jun 20, 2016 at 11:33 AM, Martin Sivak <<a = href=3D"mailto:msivak@redhat.com" class=3D"">msivak@redhat.com</a>> = wrote:<br class=3D""> >> 1. Mom is still using xmlrpc<br class=3D""> >><br class=3D""> >> Mom must move to jsonrpc.<br class=3D""> >> Martin: can you update on progress of this work?<br class=3D""> ><br class=3D""> > We would like to avoid going through VDSM completely, except from = the<br class=3D""> > broker part. Is it possible now to "parasitically" listen to = vdsm<br class=3D""> > events and engine commands without having to go through VDSM = API?<br class=3D""> <br class=3D""> </span>Sounds like a good plan.<br = class=3D""></blockquote></div></div></div></div></blockquote><div><br = class=3D""></div><div class=3D"">bypassing vdsm for mom things is a good = idea, but we need to make sure we=E2=80=99re not killing the rest of the = system</div><div class=3D""><br class=3D""></div><blockquote type=3D"cite"= class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <br class=3D""> Piotr, how far are we from letting mom listen to engine queue so it get = engine<br class=3D""> events/responses for certain = verbs?</blockquote></div></div></div></div></blockquote></div><div><blockq= uote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" = class=3D""><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div = class=3D""><br class=3D""></div><div class=3D"">We can do it now for = both events and responses. We need to remember that we would<br = class=3D""></div><div class=3D"">receive anything that the engine is = receiving. We could do better but that it would take<br = class=3D""></div><div class=3D"">more time.<br = class=3D""></div></div></div></div></div></blockquote><div><br = class=3D""></div>so it would receive all responses for only the defined = verbs?</div><div>It would wok well for getAllVmStats</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><div class=3D""> </div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <span class=3D""><br class=3D""> > You can drop XML RPC,. vdsm does not depend on MOM working = anymore.<br class=3D""> > Just the balloon and ksm stats will be missing from data that = are<br class=3D""> > being sent to the engine.<br = class=3D""></span></blockquote></div></div></div></div></blockquote><div><= br class=3D""></div>and a lot of things stops working = then;)</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_extra"><div = class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""> <br class=3D""> </span>Balloon and ksm stats are sent today from mom to vdsm, and = reported by<br class=3D""> vdsm to engine?<br class=3D""> <br class=3D""> If vdsm is only a middleman and does not use this info, best to = send<br class=3D""> it directly<br class=3D""> to engine via the stomp broker part of vdsm.<br class=3D""> <br class=3D""> Piotr, how far are we from having engine listening for mom events using = the<br class=3D""> vdsm broker?<br = class=3D""></blockquote></div></div></div></div></blockquote><div><br = class=3D""></div>I don=E2=80=99t think we should move any monitoring = pulled from libvirt into mom - it would need another expensive and = problematic call</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""><br = class=3D""></div><div class=3D"">It can be used now but the engine needs = to know to listen for them. We would <br class=3D""></div><div = class=3D"">need to implement engine subscriber (one class). <br = class=3D""></div><div class=3D""> </div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <span class=3D""><br class=3D""> > There also were some issues with eventfd in the json library, I = assume<br class=3D""> > those are fixed now.<br class=3D""> <br class=3D""> </span>They should be fixed here:<br class=3D""> <a href=3D"https://gerrit.ovirt.org/57942" rel=3D"noreferrer" = target=3D"_blank" class=3D"">https://gerrit.ovirt.org/57942</a><br = class=3D""> <br class=3D""> But suffering from these issue show that the api was not use = properly,<br class=3D""> you should create one client and reuse it for the entire life of the<br = class=3D""> application.<br class=3D""> <span class=3D"HOEnZb"><font color=3D"#888888" class=3D""><br class=3D""> <br class=3D""> Nir<br class=3D""> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br class=3D""> ><br class=3D""> > Martin<br class=3D""> ><br class=3D""> > On Sun, Jun 19, 2016 at 1:02 PM, Nir Soffer <<a = href=3D"mailto:nsoffer@redhat.com" class=3D"">nsoffer@redhat.com</a>> = wrote:<br class=3D""> >> Hi all,<br class=3D""> >><br class=3D""> >> We are still wasting time on maintaining both xmlrpc and = jsonrpc. If we kill<br class=3D""> >> xmlrpc, we can greatly simplify the code base, making it easier = to mainain<br class=3D""> >> and add new features.<br class=3D""> >><br class=3D""> >> I suggest to kill xmlrpc in 4.1, and disable it *now* on = master.<br class=3D""> >><br class=3D""> >> Currently the we have 3 issues:<br class=3D""> >><br class=3D""> >> 1. Mom is still using xmlrpc<br class=3D""> >><br class=3D""> >> Mom must move to jsonrpc.<br class=3D""> >> Martin: can you update on progress of this work?<br class=3D""> >><br class=3D""> >> 2. sos plugin using vdsClient<br class=3D""> >><br class=3D""> >> Need to port it to use jsonrpc library, or jsonrpc client<br = class=3D""> >><br class=3D""> >> New jsonrpc client: <a = href=3D"https://gerrit.ovirt.org/35181" rel=3D"noreferrer" = target=3D"_blank" class=3D"">https://gerrit.ovirt.org/35181</a><br = class=3D""> >><br class=3D""> >> 3. Engine is using xmlrpc server for ovf upload/download<br = class=3D""> >><br class=3D""> >> We must support current engine in 4.1, so we cannot remove<br = class=3D""> >> upload/download feature in this version, but we can remove = the<br class=3D""> >> xmlrpc support in this server.<br class=3D""> >><br class=3D""> >> Currently we abuse the xmlrpc server, supporting PUT and GET = for<br class=3D""> >> upload and download (XMLRPC is using only POST). We can = disable<br class=3D""> >> POST requests in protocoldetector, and not register anything = with<br class=3D""> >> the xmlrpc server.<br class=3D""> >><br class=3D""> >> Thoughts?<br class=3D""> >><br class=3D""> >> Nir<br class=3D""> </div></div></blockquote></div><br class=3D""></div></div> _______________________________________________<br class=3D"">Devel = mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org" = class=3D"">Devel@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</div></blockquote=
</div><br class=3D""></body></html>=
--Apple-Mail=_16763C7B-934F-44FC-84DF-77685A35781C--