Bug 644239

Summary: ISS based satellite-sync should fall back automatically on client 3.4
Product: Red Hat Satellite 5 Reporter: Jérôme Fenal <jfenal>
Component: Satellite SynchronizationAssignee: Miroslav Suchý <msuchy>
Status: CLOSED ERRATA QA Contact: Jiri Kastner <jkastner>
Severity: high Docs Contact:
Priority: high    
Version: 540CC: cperry, jhutar, jkastner, jpazdziora, luc
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: spacewalk-backend-1.2.13-14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-13 14:31:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 646488    

Description Jérôme Fenal 2010-10-19 08:28:15 UTC
Description of problem:

Satellite 5.4 comes with a new XML protocol, 3.6, incompatible by default with Satellite 5.3 version : 3.4

Specifying --dump-version=3.4 makes ISS work between Sat 5.3 & Sat 5.4, but as the satellite-sync client knows it is talking to 3.4 server, it should really switch to 3.4 XML automatically.

Version-Release number of selected component (if applicable):
Satellite 5.4, build satellite-embedded-oracle-5.4.0-20101015-rhel-5-x86_64.iso

How reproducible:
Always.

Steps to Reproduce:
1. Setup ISS, master Satellite 5.3, slave Satellite 5.4
2. satellite-sync -l does not work
3. satellite-sync --dump-version=3.4 -l works
  
Actual results:
# satellite-sync -l
23:19:25 Red Hat Network Satellite - live synchronization
23:19:25    url: https://sat.octothorpe.fr
23:19:25    debug/output level: 1
23:19:25    db:  rhnsat/<password>@rhnsat
23:19:25
23:19:25 Retrieving / parsing channel-families data
+++ sending log as an email +++

SYNC ERROR:

(Check logs/email for potentially more detail)


Error Message:
    Client version 3.6 does not match server version 3.4
    Error Class Code: 3012
    Error Class Info: Mismatching versions


Expected results:

Since client knows it is talking to 3.4 server, it should switch to 3.4 protocol automatically.

Fallback : issue message to user to use --dump-version=3.4 to make things work.


Additional info:

Comment 1 Miroslav Suchý 2010-11-03 09:59:26 UTC
Commited to spacewalk.git as d5d0fa098df3f6a56329bd093c29e968992c1036

do not check minor version of xml_dump_version
    
All dumps with the same major version are (and in future should) be backward
and forward compatible.
Old satellites can understoo new dumps as new xml attributes and elements, which old
satellite do not understood are ignored (like sha256 checksums).
And new satellites understood older dumps. We always have to be able to read old dumps.
    
If we ever move to new incompatible format, we will have to bump up major version of xml_dump.

Comment 2 Miroslav Suchý 2010-11-22 13:25:43 UTC
cherry picked to satellite.git as commit 6b9df358caeade0331d643d7509f0a0be77507e5

Comment 4 Miroslav Suchý 2010-11-23 11:05:47 UTC
Note: the verification of protocol check is made on master. Therefore this change is only for setup
Sat5.4 (master) - Sat5.3 and older (slave).

To allow 5.3 as master and 5.4 as slave we will need to backport it and release 5.3 errata.

Comment 5 Jan Hutař 2010-11-24 13:41:44 UTC
Hello,
please note this issue will be fixed in Satellite 5.4.0, so we expect configuration "Satellite 5.3.0 slave; 5.4.0 master" to work now (see comment #1).

If you want this to be fixed in Satellite 5.3.0 as well, please open support ticket.

Regards,
Jan

Comment 7 Jiri Kastner 2010-11-24 13:49:34 UTC
verified with setup mentioned in comment 5 as this bug is against satellite 5.4 version.

Comment 8 errata-xmlrpc 2010-12-13 14:31:57 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0974.html