Hi fellow oVirters, On this test day I picked JSON RPC for testing: My initial environment consisted of a hosted engine setup with three hosts. Upgrading =========== The first task, then, was to upgrade everything to 3.5. My guide was http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine One issue that I encountered was that after setting the 3.5 pre-release yum repo on the engine VM and doing yum update, when doing engine-setup To make it handle the upgrade, that failed complaining about missing a package called patternfly1. I remembered that on the list Greg Sheremeta mentioned a copr repository for it, so I went ahead, installed it and repeated the engine-setup This time it succeeded, however I feel like patternfly1 should probably be an ovirt-engine-3.5 dependency and it should be in the ovirt 3.5 repository. I also noticed that after upgrading the hosts the amount of free system memory is much lower, while the VMs continue to run fine. I opened: https://bugzilla.redhat.com/1124451 Another thing that happened was that restarting ovirt-ha-agent and ovirt-ha-broker using systemd fails silently and it says that they were killed. I only got it to work again by doing: /lib/systemd/systemd-ovirt-ha-broker restart /lib/systemd/systemd-ovirt-ha-agent restart However, and obviously, doing it like that escapes from the advisable control of systemd. Another bad thing is that after doing all this we get that the current host (which has the engine running displays): --== Host 2 status ==-- Status up-to-date : False Hostname : 10.34.63.180 Host ID : 2 Engine status : unknown stale-data Score : 2000 Local maintenance : False Host timestamp : 1406640293 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=1406640293 (Tue Jul 29 15:24:53 2014) host-id=2 score=2000 maintenance=False bridge=True cpu-load=0.0856 engine-health={"health": "good", "vm": "up", "detail": "up"} gateway=True mem-free=3192 Why did the engine status go to unknown stale-data? (it also happened for the other two hosts in the setup. Changing hosts to use JSON RPC =============================== After talking with Piotr and trying it with the webadmin UI, I found out that there is no direct way to update a host's settings to use json rpc as its connectivity mechanism with the engine. This constitutes a usabiltiy bug which I filed: https://bugzilla.redhat.com/1124442 It is presumable that users will want to move to the newer and better RPC mechanism and they should be able to do so by merely putting the host in maintenance and ticking some checkbox in the 'edit host' dialog. I did the workaround of removing the host and adding it again and that worked, the host went up. Network operations via JSON RPC ================================ After the host went up, I decided to send a setupNetworks command. The operation worked out fine, but unfortunately we have a very serious gap that makes it impossible for me to use jsonrpc for network operations/development. **Logging** When doing a network operation with xmlrpc we'd get the following in vdsm.log Thread-21::DEBUG::2014-07-30 13:38:11,414::BindingXMLRPC::1127::vds::(wrapper) client [10.34.61.242]::call setupNetworks with ({'10': {'nic': 'em2', 'vlan': '10', 'STP': 'no', 'bridged': 'true', 'mtu': '1500'}}, {}, {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {} flowID [686033d4] Thread-21::DEBUG::2014-07-30 13:38:32,689::BindingXMLRPC::1134::vds::(wrapper) return setupNetworks with {'status': {'message': 'Done', 'code': 0}} As you can see, we get the bare minimum logging one could ask for, an entry with the command called and the data it received and another entry with the return result data. Doing the same with jsonrpc (and ignoring the excessive IOProcess) if I search for "setupNetworks" the only thing I get is: Thread-23057::DEBUG::2014-07-30 13:32:44,126::__init__::462::jsonrpc.JsonRpcServer::(_serveRequest) Looking for method 'Host_setupNetworks' in bridge And if I search for the data received, like 'STP', there is nothing whatsoever. As I said, unless this is fixed and we get entries with the same amount of data as before, it can't be used in production nor in development. https://bugzilla.redhat.com/1124813 TL;DR: - lack of usability upgrading an environment to use jsonrpc https://bugzilla.redhat.com/1124442 - Failure on step 7 of upgrade steps: https://bugzilla.redhat.com/1124826 - JSON RPC logging excessive but insuficient for network call debugging https://bugzilla.redhat.com/1124813