Bug 1249374 - Move all 3.6 and above host communication to jsonrpc
Move all 3.6 and above host communication to jsonrpc
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
---
Unspecified Unspecified
unspecified Severity low (vote)
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Piotr Kliczewski
Pavel Stehlik
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-02 01:54 EDT by Oved Ourfali
Modified: 2016-02-10 14:12 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-13 10:47:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑3.6.0?
tnisan: exception?
ylavi: planning_ack+
rule-engine: devel_ack+
ylavi: testing_ack?


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 46066 ovirt-engine-3.6 MERGED jsonrpc: set the protocol as default Never
oVirt gerrit 46718 master MERGED jsonrpc: set the protocol as default Never
oVirt gerrit 47147 ovirt-engine-3.6.0 MERGED jsonrpc: set the protocol as default Never

  None (edit)
Description Oved Ourfali 2015-08-02 01:54:40 EDT
Description of problem:
In 3.5 we allowed to choose either jsonrpc or xmlrpc.

In 3.6 we should do the following:
1. Have jsonrpc as the only option (can be removed from the UI)
2. Have jsonrpc as the default from the REST API, and fail for 3.6 clusters if another value is set.
3. On upgrading to 3.6 we shouldn't change the host communication protocol.


Only issue is when someone upgrades his cluster to 3.6 compatibility level. At this point the hosts are already running. What I'd suggest to do in this case is to check when running InitVdsOnUp, for hosts that are 3.6 cluster, change to jsonrpc (if not set already).
Comment 1 Piotr Kliczewski 2015-09-11 10:20:09 EDT
InitVdsOnUp is a bit too late because connection to a host is already estabilished at this time. We can do it there but it will applied during next reconnection. Is that OK?
Comment 2 Oved Ourfali 2015-09-11 11:06:01 EDT
Well, it would be best to catch it beforehand. 
Moti, thoughts?
Comment 3 Moti Asayag 2015-09-13 02:13:52 EDT
(In reply to Oved Ourfali from comment #2)
> Well, it would be best to catch it beforehand. 
> Moti, thoughts?

The correct place for such logic would be AddVdsCommand.canDoAction() and for consistency I'd add the same validation to UpdateVdsCommand.canDoAction().
Comment 4 Moti Asayag 2015-09-13 04:48:09 EDT
(In reply to Oved Ourfali from comment #0)
> Description of problem:
> In 3.5 we allowed to choose either jsonrpc or xmlrpc.
> 
> In 3.6 we should do the following:
> 1. Have jsonrpc as the only option (can be removed from the UI)

You may still have < 3.6 clusters which uses xmlrpc. Removing that option from the UI will hide that information from the user. It can be presented in a disabled way.

> 2. Have jsonrpc as the default from the REST API, and fail for 3.6 clusters
> if another value is set.

Comment 3 referred specifically for this item.

> 3. On upgrading to 3.6 we shouldn't change the host communication protocol.
> 
> 
> Only issue is when someone upgrades his cluster to 3.6 compatibility level.
> At this point the hosts are already running. What I'd suggest to do in this
> case is to check when running InitVdsOnUp, for hosts that are 3.6 cluster,
> change to jsonrpc (if not set already).

One option is blocking this action if not all of the running hosts are using JSON-RPC protocol. If there are non-running hosts which don't support JSON-RPC, we'll update them to use JSON-RPC as part of the 'update cluster version' process, and initialize hosts' brokers. This will assure all active hosts in 3.6 clusters are using JSON-RPC.
Comment 5 Piotr Kliczewski 2015-09-14 02:50:11 EDT
(In reply to Moti Asayag from comment #4)
> (In reply to Oved Ourfali from comment #0)
> > Description of problem:
> > In 3.5 we allowed to choose either jsonrpc or xmlrpc.
> > 
> > In 3.6 we should do the following:
> > 1. Have jsonrpc as the only option (can be removed from the UI)
> 
> You may still have < 3.6 clusters which uses xmlrpc. Removing that option
> from the UI will hide that information from the user. It can be presented in
> a disabled way.
> 

The idea is that none of the host will be using xmlrpc for 3.6 cluster so we are not going to hide any details.

> > 2. Have jsonrpc as the default from the REST API, and fail for 3.6 clusters
> > if another value is set.
> 
> Comment 3 referred specifically for this item.
> 
> > 3. On upgrading to 3.6 we shouldn't change the host communication protocol.
> > 
> > 
> > Only issue is when someone upgrades his cluster to 3.6 compatibility level.
> > At this point the hosts are already running. What I'd suggest to do in this
> > case is to check when running InitVdsOnUp, for hosts that are 3.6 cluster,
> > change to jsonrpc (if not set already).
> 
> One option is blocking this action if not all of the running hosts are using
> JSON-RPC protocol. If there are non-running hosts which don't support
> JSON-RPC, we'll update them to use JSON-RPC as part of the 'update cluster
> version' process, and initialize hosts' brokers. This will assure all active
> hosts in 3.6 clusters are using JSON-RPC.

It looks like good approach to me. If there are host which still use xmlrpc and
we want to upgrade cluster we can complain.
Comment 6 Sandro Bonazzola 2015-09-30 03:06:15 EDT
Please be sure to test the solution with Hosted Engine before merging.
Comment 7 Pavel Stehlik 2016-01-13 10:47:27 EST
Closing old bugs. In case still happens, pls reopen.

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