<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 10:39 AM, Michal Skrivanek <span dir="ltr"><<a href="mailto:michal.skrivanek@redhat.com" target="_blank">michal.skrivanek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On 20 Jun 2016, at 18:41, Piotr Kliczewski <<a href="mailto:pkliczew@redhat.com" target="_blank">pkliczew@redhat.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 6:22 PM, Nir Soffer <span dir="ltr"><<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Mon, Jun 20, 2016 at 11:33 AM, Martin Sivak <<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>> wrote:<br>
>> 1. Mom is still using xmlrpc<br>
>><br>
>> Mom must move to jsonrpc.<br>
>> Martin: can you update on progress of this work?<br>
><br>
> We would like to avoid going through VDSM completely, except from the<br>
> broker part. Is it possible now to "parasitically" listen to vdsm<br>
> events and engine commands without having to go through VDSM API?<br>
<br>
</span>Sounds like a good plan.<br></blockquote></div></div></div></div></blockquote><div><br></div></span><div>bypassing vdsm for mom things is a good idea, but we need to make sure we’re not killing the rest of the system</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Piotr, how far are we from letting mom listen to engine queue so it get engine<br>
events/responses for certain verbs?</blockquote></div></div></div></div></blockquote></span></div><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>We can do it now for both events and responses. We need to remember that we would<br></div><div>receive anything that the engine is receiving. We could do better but that it would take<br></div><div>more time.<br></div></div></div></div></div></blockquote><div><br></div></span>so it would receive all responses for only the defined verbs?</div><div>It would wok well for getAllVmStats</div><div><span class=""><br></span></div></div></blockquote><div><br></div><div>If we subscribe to engine response queue we receive all the traffic. At the moment there is no way<br></div><div>to define verbs we listen to. This functionality is only for events.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> You can drop XML RPC,. vdsm does not depend on MOM working anymore.<br>
> Just the balloon and ksm stats will be missing from data that are<br>
> being sent to the engine.<br></span></blockquote></div></div></div></div></blockquote><div><br></div></span>and a lot of things stops working then;)</div><div><span class=""><br></span></div></div></blockquote><div><br></div><div>Maybe we can disable [1] it before dropping it. We can slowly fix master and if needed we can enable it for<br></div><div>specific envs.<br></div><div><br>[1] <a href="https://gerrit.ovirt.org/#/c/59172/">https://gerrit.ovirt.org/#/c/59172/</a> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
<br>
</span>Balloon and ksm stats are sent today from mom to vdsm, and reported by<br>
vdsm to engine?<br>
<br>
If vdsm is only a middleman and does not use this info, best to send<br>
it directly<br>
to engine via the stomp broker part of vdsm.<br>
<br>
Piotr, how far are we from having engine listening for mom events using the<br>
vdsm broker?<br></blockquote></div></div></div></div></blockquote><div><br></div></span>I don’t think we should move any monitoring pulled from libvirt into mom - it would need another expensive and problematic call</div><div><br><blockquote type="cite"><div><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>It can be used now but the engine needs to know to listen for them. We would <br></div><div>need to implement engine subscriber (one class). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> There also were some issues with eventfd in the json library, I assume<br>
> those are fixed now.<br>
<br>
</span>They should be fixed here:<br>
<a href="https://gerrit.ovirt.org/57942" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/57942</a><br>
<br>
But suffering from these issue show that the api was not use properly,<br>
you should create one client and reuse it for the entire life of the<br>
application.<br>
<span><font color="#888888"><br>
<br>
Nir<br>
</font></span><div><div><br>
><br>
> Martin<br>
><br>
> On Sun, Jun 19, 2016 at 1:02 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>> wrote:<br>
>> Hi all,<br>
>><br>
>> We are still wasting time on maintaining both xmlrpc and jsonrpc. If we kill<br>
>> xmlrpc, we can greatly simplify the code base, making it easier to mainain<br>
>> and add new features.<br>
>><br>
>> I suggest to kill xmlrpc in 4.1, and disable it *now* on master.<br>
>><br>
>> Currently the we have 3 issues:<br>
>><br>
>> 1. Mom is still using xmlrpc<br>
>><br>
>> Mom must move to jsonrpc.<br>
>> Martin: can you update on progress of this work?<br>
>><br>
>> 2. sos plugin using vdsClient<br>
>><br>
>> Need to port it to use jsonrpc library, or jsonrpc client<br>
>><br>
>> New jsonrpc client: <a href="https://gerrit.ovirt.org/35181" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/35181</a><br>
>><br>
>> 3. Engine is using xmlrpc server for ovf upload/download<br>
>><br>
>> We must support current engine in 4.1, so we cannot remove<br>
>> upload/download feature in this version, but we can remove the<br>
>> xmlrpc support in this server.<br>
>><br>
>> Currently we abuse the xmlrpc server, supporting PUT and GET for<br>
>> upload and download (XMLRPC is using only POST). We can disable<br>
>> POST requests in protocoldetector, and not register anything with<br>
>> the xmlrpc server.<br>
>><br>
>> Thoughts?<br>
>><br>
>> Nir<br>
</div></div></blockquote></div><br></div></div></div></div>
_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br><a href="http://lists.ovirt.org/mailman/listinfo/devel" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a></div></blockquote></div><br></div></blockquote></div><br></div></div>