Bug 1286452 - block moving a host to 3.6 cluster if the host doesn't work with jsonrpc
block moving a host to 3.6 cluster if the host doesn't work with jsonrpc
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: BLL.Infra (Show other bugs)
3.6.0
x86_64 Linux
unspecified Severity medium (vote)
: ovirt-3.6.2
: 3.6.2.5
Assigned To: Oved Ourfali
Jiri Belka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-29 11:36 EST by Barak Korren
Modified: 2016-03-11 02:21 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-11 02:21:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
oourfali: ovirt‑3.6.z?
rule-engine: planning_ack?
oourfali: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 49639 master MERGED core: update cluster upgrade warning message Never
oVirt gerrit 49702 ovirt-engine-3.6 MERGED core: update cluster upgrade warning message Never
oVirt gerrit 49705 ovirt-engine-3.6.1 ABANDONED core: update cluster upgrade warning message Never
oVirt gerrit 50921 master MERGED engine: Set host protocol to jsonrpc automatically 2015-12-27 05:24 EST
oVirt gerrit 51094 ovirt-engine-3.6 MERGED engine: Set host protocol to jsonrpc automatically 2015-12-28 04:20 EST
oVirt gerrit 51095 ovirt-engine-3.6.2 MERGED engine: Set host protocol to jsonrpc automatically 2015-12-28 05:30 EST

  None (edit)
Description Barak Korren 2015-11-29 11:36:19 EST
Description of problem:
When reinstalling host it is impossible to specify that it should be moved to use JSON-RPC. This makes it hard to move it into a 3.6-level cluster.

Version-Release number of selected component (if applicable):
engine: 3.6.1-0.2.el6

Steps to Reproduce:
1. Setup RHEVM with two clusters:
   1.1. A level-3.5 cluster with el6.7 hosts 
   1.2. A level-3.6 cluster with el7 hosts
2. Switch one of the hosts in the 3.5 cluster to maintenance
3. Re-install OS on the host to el7
4. Edit host properties in the admin GUI, move it to the 3.6 cluster
5. Attempt to reinstall vdsm on the host from the admin gui

Actual results:
After step #4 an error message pops up informing that JSON-RPC is needed for 3.6 cluster level, but the host is moved anyway.
After step #5 an error message pops up informing that JSON-RPC is needed for 3.6 cluster level and the host is not installed.

Expected results:
It should be possible to request that the host wil be re-installed with JSON-RPC in the vdsm installation window.

Additional info:
As a work-around the host can be moved back to the 3.5 cluster, vdsm re-installed, then changed to json-rpc and them moved and activated in the 3.6 cluster.
Comment 1 Oved Ourfali 2015-11-30 03:04:28 EST
> 
> Actual results:
> After step #4 an error message pops up informing that JSON-RPC is needed for
> 3.6 cluster level, but the host is moved anyway.

This should be blocked.
Piotr - please handle that one.


> Expected results:
> It should be possible to request that the host wil be re-installed with
> JSON-RPC in the vdsm installation window.
> 

If blocking the move to a 3.6 cluster, you'll just need to edit the host while in maintenance, and select to use jsonrpc.

Changing the title accordingly.
Also, moving the bug to oVirt.
Comment 2 Red Hat Bugzilla Rules Engine 2015-11-30 03:04:34 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 3 Barak Korren 2015-11-30 03:23:36 EST
Blocking sounds like a very bad user experience.
There is no actual basis to determine the host doesn't use JSON-RPC other then an outdated database record. The host itself doesn't even have VDSM installed mind you.
Had I completely erased the host from the system and then re-added it, things would've gone smoother - the host would have been installed with JSON-RPC. The fact that the re-installation window, which from a user point of view should be doing the same thing, doesn't let you do that is just annoying from a user perspective.
Comment 4 Oved Ourfali 2015-11-30 03:30:16 EST
(In reply to Barak Korren from comment #3)
> Blocking sounds like a very bad user experience.

It is better than allowing it and failing you afterwards.
I see no issue with failing. It is like any other issue we have, and we already do that.

> There is no actual basis to determine the host doesn't use JSON-RPC other
> then an outdated database record. The host itself doesn't even have VDSM
> installed mind you.

It is the engine that decides how to work, not the host, so it depends on what's set in the DB.
Comment 5 Piotr Kliczewski 2015-11-30 03:54:35 EST
(In reply to Barak Korren from comment #3)
> There is no actual basis to determine the host doesn't use JSON-RPC other
> then an outdated database record. The host itself doesn't even have VDSM
> installed mind you.

For older cluster levels than 3.6 user can see which protocol is used in host edit dialogue and you can change it by putting host to maintenance. For those clusters you can still choose protocol, which will be used for host communication, during host installation.
Comment 6 Barak Korren 2015-11-30 04:04:22 EST
(In reply to Oved on comment #4)

> It is better than allowing it and failing you afterwards.
> I see no issue with failing. It is like any other issue we have, 
> and we already do that.

The fact that you already do that doesn't make it a good UX. The error message is quite opaque, it mentions 'JSON RPC' which would be an alien term for any admin that isn't versed in the oVirt internal implementation history. The only mention of that term in the UI is hidden behind an 'Advanced' button.

This is akin to the "Call the sysadmin" style error messages from some of our beloved competing products.

It would be far better to, instead of blocking, tell the user that switching the host to JSON-RPC would be needed and offer the ok/cancel option to do that on the spot.

Also note that the option to move to JSON-RPC doesn't show up for the re-installed host until after VDSM is re-installed. This makes the host OS upgrade process tedious, with the user having to carry out multiple steps instead of telling the engine "look I reinstalled the OS, now do what you need to use this host", which is what IMO, the "reinstall" button in the UI is supposed to mean.

(In reply to Piotr on comment #5)
> For older cluster levels than 3.6 user can see which protocol is used 
> in host edit dialogue and you can change it by putting host to
> maintenance.

You can gather I already know that from the description of the work around I specified in the bug description.
But Like I said above, it is hidden behind an 'advanced' button, and not easy to find, even for someone who already heard about the switch to JSON RPC (me), not to mention someone who hears about it for the first time from the error message (E.g someone who ins`t professionally involved in RHEV/oVirt development...).
Comment 7 Oved Ourfali 2015-11-30 04:34:29 EST
(In reply to Barak Korren from comment #6)
> (In reply to Oved on comment #4)
> 
> > It is better than allowing it and failing you afterwards.
> > I see no issue with failing. It is like any other issue we have, 
> > and we already do that.
> 
> The fact that you already do that doesn't make it a good UX. The error
> message is quite opaque, it mentions 'JSON RPC' which would be an alien term
> for any admin that isn't versed in the oVirt internal implementation
> history. The only mention of that term in the UI is hidden behind an
> 'Advanced' button.

We can improve the error message, but I don't see a UX issue here.

> 
> This is akin to the "Call the sysadmin" style error messages from some of
> our beloved competing products.
> 
> It would be far better to, instead of blocking, tell the user that switching
> the host to JSON-RPC would be needed and offer the ok/cancel option to do
> that on the spot.



> 
> Also note that the option to move to JSON-RPC doesn't show up for the
> re-installed host until after VDSM is re-installed. This makes the host OS
> upgrade process tedious, with the user having to carry out multiple steps
> instead of telling the engine "look I reinstalled the OS, now do what you
> need to use this host", which is what IMO, the "reinstall" button in the UI
> is supposed to mean.
> 

This would be addressed before re-install, in what I've provided.

> (In reply to Piotr on comment #5)
> > For older cluster levels than 3.6 user can see which protocol is used 
> > in host edit dialogue and you can change it by putting host to
> > maintenance.
> 
> You can gather I already know that from the description of the work around I
> specified in the bug description.
> But Like I said above, it is hidden behind an 'advanced' button, and not
> easy to find, even for someone who already heard about the switch to JSON
> RPC (me), not to mention someone who hears about it for the first time from
> the error message (E.g someone who ins`t professionally involved in
> RHEV/oVirt development...).

We can improve the error message, which will address that, to point the user to where the setting is.
Comment 8 Yaniv Kaul 2015-12-02 15:16:20 EST
I'm honestly not sure why the engine can't just switch protocols for the vdsm.  Looks like a missing verb between engine and vdsm?
Comment 9 Oved Ourfali 2015-12-02 22:49:10 EST
(In reply to Yaniv Kaul from comment #8)
> I'm honestly not sure why the engine can't just switch protocols for the
> vdsm.  Looks like a missing verb between engine and vdsm?

It is not a matter of ability. 
It is a matter of the administrator to do the change, and not Changing things behind his back. He could have changed it in the past to solve some issue he had, so this is something that shouldn't just automatically happen. 

We have similar behavior in other cases as well.
Comment 10 Oved Ourfali 2015-12-02 23:03:04 EST
I  addition, the host need to be in maintenance. When upgrading the host we can't know the purpose of the administrator is to upgrade cluster level as well.
Comment 11 Jiri Belka 2016-03-01 12:10:07 EST
ok, rhevm-3.6.3.4-0.1.el6.noarch

a host being part of 3.5 cluster with xmlrpc protocol is reconfigured transparently to use 'stomp' (jsonrpc) protocol after it is "moved" to 3.6 cluster. activation of the host was later successful.

Note You need to log in before you can comment on or make changes to this bug.