----- Original Message ----- > From: "Antoni Segura Puimedon" <asegu...@redhat.com> > To: de...@ovirt.org, "users" <users@ovirt.org> > Sent: Wednesday, 30 July, 2014 2:15:36 PM > Subject: Testday: json rpc > > 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.
After discussing with Jiři: the 'stale data thing' resulted in https://bugzilla.redhat.com/1125244 > > 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 > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users