Add support for Satellite 6.9 #386

jturel · 2021-06-08T13:29:26Z

No description provided.

roles/satellite-clone/vars/satellite_6.9.yml

ekohl · 2021-06-08T13:37:20Z

roles/satellite-clone/vars/satellite_6.9.yml

+satellite_installer_cmd: satellite-installer
+satellite_scenario: satellite
+capsule_puppet_module: foreman-proxy
+satellite_installer_options: "--foreman-ipa-authentication false --reset-puppet-server-ssl-chain-filepath --disable-system-checks"


Why are these 2 options always passed in? (I understand disabling system checks, at least party)

foreman-ipa-authentication false -> #268
reset-puppet-server-ssl-chain-filepath -> #349

foreman-ipa-authentication false -> #268

I guess that makes sense.

reset-puppet-server-ssl-chain-filepath -> #349

Hah, just last Friday I was playing with this: theforeman/puppet-puppet@c05e0a9

That said, it very much feels like a 6.3 -> 6.4 change due to Puppet 3 -> 4. In current versions I don't think it would be needed.

Hah, just last Friday I was playing with this: theforeman/puppet-puppet@c05e0a9

Beautiful coincidence!

That said, it very much feels like a 6.3 -> 6.4 change due to Puppet 3 -> 4. In current versions I don't think it would be needed.

Let's give it a whirl (about to start a test of this PR right now to see)

foreman-ipa-authentication false -> #268
reset-puppet-server-ssl-chain-filepath -> #349

TYVM. Could you add this as a comment in the YAML so that future us / future somebody else can find it more easily?

Can do. I feel a utility such as this (expected to run on old, old versions of Satellite) warrants excessive commenting

jturel · 2021-06-08T14:47:51Z

New one for me here:

--> Finished Dependency Resolution                                                                                                                            
Error: Package: satellite-common-6.9.2-1.el7sat.noarch (rhel-7-server-satellite-6.9-rpms)                                                                     
           Requires: ansible >= 2.9                                                                                                                           
           Installed: ansible-2.4.2.0-2.el7.noarch (@rhel-7-server-extras-rpms)                                                                               
               ansible = 2.4.2.0-2.el7                                                                                                                        
           Available: ansible-2.4.0.0-1.el7ae.noarch (rhel-7-server-satellite-maintenance-6-rpms)                                                             
               ansible = 2.4.0.0-1.el7ae

Which repo should ansible > 2.9 be coming from? Need to update the list to auto-enable it

Is it rhel-7-server-ansible-2.9-rpms ?

sthirugn · 2021-06-08T15:27:56Z

Looks good to me, but I don't have time to test it. Feel free to merge after @ekohl acks it.

evgeni · 2021-06-08T15:31:05Z

New one for me here:

--> Finished Dependency Resolution                                                                                                                            
Error: Package: satellite-common-6.9.2-1.el7sat.noarch (rhel-7-server-satellite-6.9-rpms)                                                                     
           Requires: ansible >= 2.9                                                                                                                           
           Installed: ansible-2.4.2.0-2.el7.noarch (@rhel-7-server-extras-rpms)                                                                               
               ansible = 2.4.2.0-2.el7                                                                                                                        
           Available: ansible-2.4.0.0-1.el7ae.noarch (rhel-7-server-satellite-maintenance-6-rpms)                                                             
               ansible = 2.4.0.0-1.el7ae

Which repo should ansible > 2.9 be coming from? Need to update the list to auto-enable it

Is it rhel-7-server-ansible-2.9-rpms ?

Exactly this.

evgeni · 2021-06-08T15:31:57Z

roles/satellite-clone/tasks/main.yml

@@ -60,6 +60,10 @@
  register: enable_repos_result
  when: enable_repos

+- name: Enable Ansible 2.9 repository
+  command: subscription-manager repos --enable rhel-{{ ansible_distribution_major_version}}-server-ansible-2.9-rpms


The el8 repo has a completely different name, so no need to template it here

But you could template the Ansible version, and put that into vars :)

evgeni · 2021-06-08T15:32:57Z

roles/satellite-clone/tasks/main.yml

@@ -60,6 +60,10 @@
  register: enable_repos_result
  when: enable_repos

+- name: Enable Ansible 2.9 repository
+  command: subscription-manager repos --enable rhel-{{ ansible_distribution_major_version}}-server-ansible-2.9-rpms
+  when: satellite_version in ["6.9"]


This can (and should) be done on 6.8 too, we just didn't have the more explicit dependency in the RPM that would trigger the error you posted in 6.8

I was testing this as-is and I ran into an error in the middle of execution and I think it had to with the fact that I started the playbook while running ansible 2.4 and ansible was upgraded from underneath:

TASK [satellite-clone : Install packages necessary to check DB status] *************************************************************************************** Tuesday 08 June 2021 15:28:19 +0000 (0:07:30.279) 0:10:16.888 ********** An exception occurred during task execution. To see the full traceback, use -vvv. The error was: AttributeError: 'Task' object has no attribute 'async_val' fatal: [localhost]: FAILED! => {"msg": "Unexpected failure during module execution.", "stdout": ""} msg: Unexpected failure during module execution.

This step completed successfully when I ran it a second time (with ansible 2.9 loaded from the start)

To me it seems that the initial steps in the doc should reflect the correct repo to enable to get the right ansible version installed before the clone process is started

I don't understand where this issue comes from, but if using 2.9 fixes it, we should be good.

Interestingly, docs don't say to enable Ansible repos: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.9/html/upgrading_and_updating_red_hat_satellite/cloning_satellite_server#sec-Cloning_to_Target

roles/satellite-clone/tasks/main.yml

README.md

roles/satellite-clone/tasks/main.yml

roles/satellite-clone/vars/satellite_6.8.yml

evgeni · 2021-06-09T14:59:25Z

Overall this reads correctly. I still wonder which Ansible should be used for s-clone, but maybe @mccun934 can shed some light on it.

Seems weird to have to enable the right ansible repo, and then s-clone does enable it again?

jturel · 2021-06-09T16:12:25Z

Overall this reads correctly. I still wonder which Ansible should be used for s-clone, but maybe @mccun934 can shed some light on it.

Seems weird to have to enable the right ansible repo, and then s-clone does enable it again?

It's a little wonky but the way it plays out is that it's just making sure that by the time everything is done with the clone process all of the repos are enabled as they would have been if one followed the installation docs, especially since Clone has a step to disable all repos fairly early on (likely to make sure packages are getting pulled from the expected locations).

jturel · 2021-06-09T20:45:18Z

I'm hitting an issue at the end of the process where, after the restoration is performed via foreman-maintain, the installer is run to upgrade to the latest z-stream.

TASK [satellite-clone : Run installer upgrade to match latest z-version] *********************************************************************************************************************
Wednesday 09 June 2021  19:13:20 +0000 (0:00:00.228)       0:55:28.751 ********                                                                                                                                                               
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["satellite-installer", "--upgrade", "--disable-system-checks"], "delta": "0:00:07.912125", "end": "2021-06-09 19:13:29.012080", "msg": "non-zero return code", "rc": 1, "start": "202
1-06-09 19:13:21.099955", "stderr": "ERROR: Unrecognised option '--upgrade'\n\nSee: 'satellite-installer --help'", "stderr_lines": ["ERROR: Unrecognised option '--upgrade'", "", "See: 'satellite-installer --help'"], "stdout": "2021-06-09 
19:13:24 [NOTICE] [root] Loading default values from puppet modules...\n2021-06-09 19:13:28 [NOTICE] [root] ... finished", "stdout_lines": ["2021-06-09 19:13:24 [NOTICE] [root] Loading default values from puppet modules...", "2021-06-09 1
9:13:28 [NOTICE] [root] ... finished"]}

Will update to use foreman-maintain for 6.9 and later

jturel · 2021-06-09T21:20:25Z

roles/satellite-clone/tasks/main.yml

+    when: satellite_version is version("6.8", "<=")
+
+  - name: Upgrade to latest z-version with satellite-maintain
+    command: 'satellite-maintain upgrade run --target-version={{ satellite_version }}.z --assumeyes'


Will this work as far back as 6.5? If so I can remove the above equivalent which used satellite-installer

Hi @jturel , great question!

As you saw, --upgrade was removed (with theforeman/foreman-installer@3c60c74 ). In fact, at that point it did nothing except print a notice that --upgrade is deprecated since we automatically run any pending db migrations (since theforeman/foreman-installer@1cc2378 ) was included with Foreman 2.1 (corresponding to Satellite 6.8)

IMO, rather than making the change to use satellite-maintain here with 6.9 and later versions, because satellite-maintain introduces a lot of additional overhead (running various pre-upgrade checks, unlocking packages and updating them, etc) which is intended to simplify the user experience of upgrading for customers, but doesn't have much benefit in this specific context, I would simply make the change to remove --upgrade from the task here, but include it in satellite_upgrade_options only when: satellite_version is version("6.7", "<=")

In other words, logically just running the installer still makes sense at this point, we just need to no longer pass --upgrade to it as that was deprecated in Satellite 6.8 and has been removed in Satellite 6.9.

Slightly different solution: why don't we add --upgrade to satellite_upgrade_options for 6.5,6.6,6.7 and leave it out in 6.8+? Removes the need for doing wild satellite_version checks here in the playbook as we already satellite_upgrade_options?

Thanks @wbclark & @evgeni - gonna update the vars file to prevent adding back a satellite_version check

evgeni

From an Ansible perspective this looks good (I added one comment, but nothing major).

Does a clone run succeed with these changes?

evgeni · 2021-06-10T15:19:45Z

roles/satellite-clone/tasks/main.yml

+# The location of this file changed in 6.9
+- name: Remove cpdb_done file
+  file:
+    path: /var/lib/candlepin/.puppet-candlepin-cpdb-create-done


You could fold this and the legacy path into a list and do a with_items.

Or put the filepath as a variable as for each satellite version there is always just one matching.

Or you leave it like this, as it doesn't hurt ;)

I like with_items - will do

jturel · 2021-06-10T16:15:46Z

Updated & squashed!

sthirugn · 2021-06-14T18:07:52Z

yay! @jturel++

ekohl reviewed Jun 8, 2021

View reviewed changes

evgeni reviewed Jun 8, 2021

View reviewed changes

README.md Outdated Show resolved Hide resolved

ekohl reviewed Jun 9, 2021

View reviewed changes

README.md Outdated Show resolved Hide resolved

evgeni reviewed Jun 9, 2021

View reviewed changes

roles/satellite-clone/tasks/main.yml Show resolved Hide resolved

evgeni reviewed Jun 9, 2021

View reviewed changes

roles/satellite-clone/vars/satellite_6.8.yml Outdated Show resolved Hide resolved

jturel commented Jun 9, 2021

View reviewed changes

evgeni reviewed Jun 10, 2021

View reviewed changes

Support cloning Satellite 6.9

a2042ce

jturel force-pushed the sat_69 branch from bcd67ad to a2042ce Compare June 10, 2021 16:15

evgeni approved these changes Jun 14, 2021

View reviewed changes

ekohl approved these changes Jun 14, 2021

View reviewed changes

jturel merged commit 0fd2377 into RedHatSatellite:master Jun 14, 2021

jturel deleted the sat_69 branch June 14, 2021 17:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for Satellite 6.9 #386

Add support for Satellite 6.9 #386

jturel commented Jun 8, 2021

ekohl Jun 8, 2021

jturel Jun 8, 2021

ekohl Jun 8, 2021

jturel Jun 8, 2021

wbclark Jun 8, 2021

jturel Jun 8, 2021

jturel commented Jun 8, 2021 •

edited

sthirugn commented Jun 8, 2021

evgeni commented Jun 8, 2021

evgeni Jun 8, 2021

evgeni Jun 8, 2021

evgeni Jun 8, 2021

jturel Jun 8, 2021

evgeni Jun 8, 2021

evgeni Jun 8, 2021

evgeni commented Jun 9, 2021

jturel commented Jun 9, 2021

jturel commented Jun 9, 2021

jturel Jun 9, 2021

wbclark Jun 9, 2021

evgeni Jun 10, 2021

jturel Jun 10, 2021

jturel Jun 10, 2021

evgeni Jun 10, 2021

evgeni left a comment

evgeni Jun 10, 2021

jturel Jun 10, 2021

jturel commented Jun 10, 2021

sthirugn commented Jun 14, 2021

Add support for Satellite 6.9 #386

Add support for Satellite 6.9 #386

Conversation

jturel commented Jun 8, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jturel commented Jun 8, 2021 • edited

sthirugn commented Jun 8, 2021

evgeni commented Jun 8, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

evgeni commented Jun 9, 2021

jturel commented Jun 9, 2021

jturel commented Jun 9, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

evgeni left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jturel commented Jun 10, 2021

sthirugn commented Jun 14, 2021

jturel commented Jun 8, 2021 •

edited