Description of problem: When diffing schema of a new 5.3.0 installation and a 3.7.1 -> 5.3.0 upgrade, several differences are showing (all coming from pre 5.2.0 times): Constraints: * upgraded schema lacks rhn_clientcapnam_name_unq (rhnClientCapabilityName) * upgraded schema lacks rhn_kvt_label_unq (rhnKickstartVirtualizationType) * upgraded schema doesn't put NOT NULL on rhnKickstartCommandName.sort_order * upgraded schema doesn't put NOT NULL on rhnKickstartCommandName.uses_arguments Data: * rhn_command_parameter differs in two lines (columns sorted alphabetically): - 16 password public 1 SNMP Community String 80 30 1 40 password system 1 community config + 16 password public 1 SNMP Community String 80 30 1 40 text system 1 community config - 113 password public 1 SNMP Community String 80 4 1 40 password system 1 community config + 113 password public 1 SNMP Community String 80 4 1 40 text system 1 community config * rhn_db_environment differs in two lines (columns sorted alphabetically): - RHNSAT LICENSE + WEBDEV LICENSE * rhnKickstartCommandName differs in one line (columns sorted alphabetically): + autostep N 1 N - autostep N 1 Y Version-Release number of selected component (if applicable): rhn-satellite-3.7.1-7 to Satellite-5.3.0-RHEL4-re20090220.1 upgrade How reproducible: Always Steps to Reproduce: 1. Install rhn-satellite-3.7.1-7 2. Upgrade to some of the recent 5.3.0 builds 3. On another machine, install a new 5.3.0 satellite 4. Check that following queries return the same data on both installations: > select * from user_constraints where constraint_name = 'RHN_CLIENTCAPNAM_NAME_UNQ'; > select * from user_constraints where constraint_name = RHN_KVT_LABEL_UNQ; > desc rhnKickstartCommandName ^^ this needs to say NOT NULL for sort_order and uses_arguments columns > select FIELD_WIDGET_NAME from rhn_command_parameter where command_id = 16 and DATA_TYPE_NAME = 'password'; > select FIELD_WIDGET_NAME from rhn_command_parameter where command_id = 113 and DATA_TYPE_NAME = 'password'; > select * from rhn_db_environment; > select * from rhnKickstartCommandName where name = 'autostep'; Actual results: Mentioned queries differ. Expected results: Mentioned queries return the same results. Additional info: All the differences mentioned above come from upgrades before 5.2.0. SQL upgrades from 5.1.0 to 5.2.0 and beyond are good.
Created attachment 333352 [details] 2.5-89 to 5.3.0 schema upgrade differences Just for the record, I'm attaching differences between newly installed 5.3.0 and a schema upgraded from 2.5-89 (a.k.a. rhn-satellite-2.0-64) to latest 5.3.0. It shows couple of more differences, although these most likely won't be fixed. Purpose of this comment and the attached log is purely informative.
satellite.git SATELLITE-5.3: 4a8a1d9633acf15f57605f6f1042f104338959ab
spacewalk.git master: 79e3d430f5ed8b0eddef81b9e22b357d3e9741da fe100d328115f40bed13e0abc7755fcf9a8ffced spacewalk.git VADER: d07c05a3b736654f727db4435fec1c6472039599 fbe69154500eeabbcd4eb5db46587abfc17bf07c
Created attachment 340366 [details] sql script for comparison Attachment contains sql script that should be used for verification of this bug. It needs to be run with sqlplus and needs to return same results on a new & upgraded Satellite.
satellite-schema-5.3.0.18-1
Blocked as of right now by a spacewalk-schema-upgrade bug. Will retest when I can.
Upgraded 3.7 to 5.3 Using the script provided, the returned results match for both the upgrades 5.3 sat and the cleanly installed 5.3 sat. Verified.