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).
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?
Well, it would be best to catch it beforehand. Moti, thoughts?
(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().
(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.
(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.
Please be sure to test the solution with Hosted Engine before merging.
Closing old bugs. In case still happens, pls reopen.