Bug 1383147

Assigning to Dayle for review.

Hi Dayle,

So all the current rubrep migration steps can be removed from the docs, so:

# cd /var/www/miq/vmdb
# bin/rake evm:dbsync:replicate_backlog
# bin/rails r tools/purge_duplicate_rubyrep_triggers.rb

including this line from 1.4 and 2.4 notes

'While the old method which used ruby rep will continue to work,'

These 'note' sections will need rewording as rubyrep is no longer supported in 5.7, it only works with pglogical going forward.

It is possible we will need some different rubyrep commands just to clean up the db before the yum update process probably something like rake evm:dbsync:uninstall or if it's faster we could do rake evm:destroy_local_region <region_number> for each remote region on the global, I am currently going over this with Nick to confirm what and if we need to do this.

We will also need additional steps after the migration before starting evm. This will be upgrading postgresql to 9.5, currently we have a script to run so '/usr/bin/miq_postgres_upgrade.sh'. That should do the bulk of the upgrade process, there is a few file edits that we need to be done afterwards, however I am working with Nick to try and simplify this. So you can add these lines to start with and we can expand on file edits later if we need to manually do them.
# /usr/bin/miq_postgres_upgrade.sh
# systemctl enable rh-postgresql95-postgres && systemctl start rh-postgresql95-postgres

I also noticed while scanning through that 1.2 notes section has the following line which needs to be changed to 5.7 

'This Role is required in 5.6 to be able to log in to the User Interface.' 

also the 2.2 note section has similar, it needs 5.5, 5.6 then 5.7 currently it has 5.5 throughout.

Hope this helps,
Luke

Recording a few notes from email thread with Jan Kročil, Marianne Feifer, and John Hardy on supported migration scenarios:

5.4 was CF 3.2
5.5 was CF 4.0
5.6 was CF 4.1
5.7 is CF 4.2

5.4 was RHEL6.x and 5.5+ are RHEL7.
We won’t support upgrade from RHEL6 to RHEL7

** I've added a note at the beginning of the guide stating that migrations for 5.5 > 5.7 and 5.6 > 5.7 are supported; customers with CFME 5.4 or below must upgrade first to 5.5 before moving to 5.7.

Hi Dayle,

---
In "1.2. Back Up Current Appliances":
I don't know much on iptables but I believe you can save them to a file with

iptables-save > /etc/iptables.conf

Then restore using the following command 

iptables-restore < /etc/iptables.conf

or add that command to /etc/rc.local to reload the rules in every reboot.

---
In "1.3.1. Additional Preparation for VMDB Appliances":

We stop the replication role on the subordinate/remote database then stop evmserverd on that appliance. We then proceed to stop evmserverd on the master/global region database. So in short, yes they are two different appliances and we need to stop evmserverd on both one after the other.

We also need to add a bin/rake evm:dbsync:uninstall between steps 3 and 4, this will remove any rubyrep configuration installed to prevent errors in setting up pglogical later.

---
In "1.4. Migrating from CFME 5.6 to 5.7":

Step 2 can be removed as like you say the process has already been stopped in the preparation.

step 5 migrates everything in the database from 5.5/5.6 to work with the latest 5.7 configuration.


Additional changes, between 1.4.3/4 we need to login out and back into the appliance before running vmdb and migration steps in order to fully reload ruby first.

After 1.4.7 we need to make changes to postgres.conf following the edits printed by miq_postgres_upgrade.sh such as

Before starting the new server, the following changes must be made to 
/var/opt/rh/rh-postgresql95/lib/pgsql/data/postgresql.conf file:

 -checkpoint_segments = 15   # MIQ Value;
 -#checkpoint_segments = 3    # in logfile segments, min 1, 16MB each
 +#max_wal_size = 1GB
 +#min_wal_size = 80MB

 -shared_preload_libraries = 'pglogical'   # MIQ Value (change requires restart)
 +shared_preload_libraries = 'pglogical,repmgr_funcs'   # MIQ Value (change requires restart)

 +wal_log_hints = on

(there is a bz open to try and get this done automatically but currently its a manual task)

1.4.9 should say start evmserver not 'restart'. Also the section after .9 about re-enabling Database syncronization can be removed as can the note below it. There is no rubyrep configuration now, perhaps we should replace this section with how to setup pglogical replication.(I assume there is a doc on this that we can just link to?)

It would seem that all the above edits are relevant to both the 5.6 and 5.5 sections. Additionally to the 5.5 steps we have to make the following changes to hba.conf, ident.conf and postgres.conf

pg_ident.conf

+usermap    postgres    root

 
pg_hba.conf

+host  replication  all  all  md5

 
postgresql.conf

-#shared_preload_libraries = ''        # (change requires restart)        (line 135)

+shared_preload_libraries = 'pglogical'        # MIQ Value (change requires restart)

-#wal_level = minimal            # minimal, archive, or hot_standby    (line 162)

+wal_level = 'logical' # MIQ Value (pglogical)

-#max_wal_senders = 0        # max number of walsender processes    (line 208)

+max_wal_senders = 10        # MIQ Value (pglogical) max number of walsender processes

+max_worker_processes = 10  # MIQ Value (pglogical)     (line 588)

+max_replication_slots = 10 # MIQ Value (pglogical)      (line 589) 

(again this is part of that bz above to try and get this stuff automated)

Thanks,
Luke

Also just noticed 1.4.8 and 2.4.8 

systemctl enable rh-postgresql95-postgres && systemctl start rh-postgresql95-postgres 

should look like this

systemctl enable rh-postgresql95-postgresql && systemctl start rh-postgresql95-postgresql

> 
> Additional changes, between 1.4.3/4 we need to login out and back into the
> appliance before running vmdb and migration steps in order to fully reload
> ruby first.
> 

This change (from comment 12) resolved https://bugzilla.redhat.com/show_bug.cgi?id=1378400

Nick and Greg, thank you for the additional details and the answers I was needing. I've clarified those parts of the doc now.

I've left the step in about logging in and out to reload Ruby (Comment 17) -- if this is fixed, please let me know in case I miss it on that bug. I've added it as a 'depends on' for now.

For Nick's comments about the replication procedures, I've created a new bug for https://bugzilla.redhat.com/show_bug.cgi?id=1392717

The CloudForms 4.2 Migration Guide is now available here:

https://access.redhat.com/documentation/en/red-hat-cloudforms/4.2/single/migrating-to-red-hat-cloudforms-42/