[ovirt-devel] Killing XMLRPC on master

Nir Soffer nsoffer at redhat.com
Wed Jun 22 09:52:52 UTC 2016


On Wed, Jun 22, 2016 at 12:24 PM, Piotr Kliczewski <pkliczew at redhat.com> wrote:
>
>
> On Wed, Jun 22, 2016 at 10:39 AM, Michal Skrivanek
> <michal.skrivanek at redhat.com> wrote:
>>
>>
>> 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> wrote:
>>>
>>> On Mon, Jun 20, 2016 at 11:33 AM, Martin Sivak <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
>>
>
> If we subscribe to engine response queue we receive all the traffic. At the
> moment there is no way
> to define verbs we listen to. This functionality is only for events.
>
>>
>>
>>>
>>>
>>> > 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;)
>>
>
> Maybe we can disable [1] it before dropping it. We can slowly fix master and
> if needed we can enable it for
> specific envs.
>
> [1] https://gerrit.ovirt.org/#/c/59172/

Unfortunately this is not possible, as ovf upload/download depends on http
server used by xmlrpc. We probably need to support engine 4.0 depending
on this for couple of years.

Disabling required removal of the xmlrpc verbs, maybe also the xmlrpc
dispatcher, and leaving the http server serving GET and POST requests.

Use BaseHTTPServer.BaseHTTPRequestHandler here:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/rpc/bindingxmlrpc.py#L99

Use BaseHTTPServer.HTTPServer here:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/rpc/bindingxmlrpc.py#L296

And finally we remove POST here:
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/rpc/bindingxmlrpc.py#L1285

But until mom migrate to jsonrpc, I think the best would be to remove all the
xmlrpc verbs except these used by mom, or the sos plugin.

Martin listed the verbs used by mom here:
http://lists.ovirt.org/pipermail/devel/2016-June/013298.html

- getAllVmStats
- vmSetCpuTuneQuota
- vmSetCpuTunePeriod
- getIoTunePolicy
- getIoTune
- setIoTune
- setKsmTune

sos plugin is using these (via vdsClient):

- getVdsCapabilities
- getVdsStats
- getAllVmStats
- list
- getVGList
- getDeviceList
- getAllTasksInfo
- getAllTasksStatuses
- getConnectedStoragePoolsList
- getSpmStatus

Removing anything else from bindingxmlrpc.py is possible now.

>>> 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
>>>
>>> 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> 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
>>> >>
>>> >> 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
>>
>>
>



More information about the Devel mailing list