<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 11:40 AM, Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> If we subscribe to engine response queue we receive all the traffic. At the<br>
> moment there is no way<br>
> to define verbs we listen to. This functionality is only for events.<br>
<br>
</span>Can't we create a new topic /engine/<verb> for each verb and configure<br>
vdsm to listen for /engine/*? That would duplicate what we have now,<br>
but MOM would be able to subscribe more selectively.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>It is not about having a topic but listing what should be posted to that topic.<br></div><div>Sending to multiple topics is there but selecting a subset to send to one of them<br></div><div>would need to be added. I am not sure whether it is good idea for sever to know<br></div><div>what should be send where.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Jun 22, 2016 at 11:24 AM, Piotr Kliczewski <<a href="mailto:pkliczew@redhat.com">pkliczew@redhat.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jun 22, 2016 at 10:39 AM, Michal Skrivanek<br>
> <<a href="mailto:michal.skrivanek@redhat.com">michal.skrivanek@redhat.com</a>> wrote:<br>
>><br>
>><br>
>> On 20 Jun 2016, at 18:41, Piotr Kliczewski <<a href="mailto:pkliczew@redhat.com">pkliczew@redhat.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Mon, Jun 20, 2016 at 6:22 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br>
>>><br>
>>> On Mon, Jun 20, 2016 at 11:33 AM, Martin Sivak <<a href="mailto:msivak@redhat.com">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>
>>> Sounds like a good plan.<br>
>><br>
>><br>
>> bypassing vdsm for mom things is a good idea, but we need to make sure<br>
>> we’re not killing the rest of the system<br>
>><br>
>>><br>
>>> Piotr, how far are we from letting mom listen to engine queue so it get<br>
>>> engine<br>
>>> events/responses for certain verbs?<br>
>><br>
>><br>
>> We can do it now for both events and responses. We need to remember that<br>
>> we would<br>
>> receive anything that the engine is receiving. We could do better but that<br>
>> it would take<br>
>> more time.<br>
>><br>
>><br>
>> so it would receive all responses for only the defined verbs?<br>
>> It would wok well for getAllVmStats<br>
>><br>
><br>
> If we subscribe to engine response queue we receive all the traffic. At the<br>
> moment there is no way<br>
> to define verbs we listen to. This functionality is only for events.<br>
><br>
>><br>
>><br>
>>><br>
>>><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>
>><br>
>><br>
>> and a lot of things stops working then;)<br>
>><br>
><br>
> Maybe we can disable [1] it before dropping it. We can slowly fix master and<br>
> if needed we can enable it for<br>
> specific envs.<br>
><br>
> [1] <a href="https://gerrit.ovirt.org/#/c/59172/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/59172/</a><br>
>>><br>
>>><br>
>>> 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<br>
>>> the<br>
>>> vdsm broker?<br>
>><br>
>><br>
>> I don’t think we should move any monitoring pulled from libvirt into mom -<br>
>> it would need another expensive and problematic call<br>
>><br>
>><br>
>> It can be used now but the engine needs to know to listen for them. We<br>
>> would<br>
>> need to implement engine subscriber (one class).<br>
>><br>
>>><br>
>>><br>
>>> > There also were some issues with eventfd in the json library, I assume<br>
>>> > those are fixed now.<br>
>>><br>
>>> 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>
>>><br>
>>><br>
>>> Nir<br>
>>><br>
>>> ><br>
>>> > Martin<br>
>>> ><br>
>>> > On Sun, Jun 19, 2016 at 1:02 PM, Nir Soffer <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>> wrote:<br>
>>> >> Hi all,<br>
>>> >><br>
>>> >> We are still wasting time on maintaining both xmlrpc and jsonrpc. If<br>
>>> >> we kill<br>
>>> >> xmlrpc, we can greatly simplify the code base, making it easier to<br>
>>> >> 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>
>><br>
>><br>
>> _______________________________________________<br>
>> Devel mailing list<br>
>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>