Support tarball upgrade

[aceeric]

What type of PR is this?

• bug
• cleanup
• documentation
• feature

What this PR does / why we need it:

This PR supports upgrading (and downgrading) RKE2 via the tarball method. It is informed by work done in this ticket.

The Rancher Federal Ansible already supports upgrading a cluster using the RPM method. But for some reason it prevents this in the tarball method. The PR simply enables the tarball method to achieve consistency with the RPM method. (It also supports downgrading via tarball because that comes along with the change for free but that's not really the goal.) This branch takes a minimalist approach: It will do what you tell it. It doesn't try to protect the person installer from doing wrong things, such as upgrading Kubernetes in a disallowed way. I made this choice because the converse would require codifying logic in Ansible that fundamentally is owned by the k8s maintainers.

Which issue(s) this PR fixes:

#154

Special notes for your reviewer:

N/A

Testing

I have tested the following scenarios in AWS :

ONE: With a two-instance cluster consisting of one controller and one worker and after each step the resulting cluster version matched the install version.

Airgap install: v1.25.11+rke2r1
Airgap install: v1.25.13+rke2r1
Airgap install: v1.25.11+rke2r1
Uninstall
Airgap install: v1.25.11+rke2r1
Airgap install: v1.25.11+rke2r1

TWO: Tested the same scenarios above with the RPM install method to ensure the changes didn't affect the RPM path:

RPM install: v1.25.11+rke2r1
RPM install: v1.25.13+rke2r1
RPM install: v1.25.11+rke2r1

The RPM downgrade to v1.25.11+rke2r1 was ignored by the Ansible. This was consistent with the pre-PR behavior, and so I stopped here for the RPM testing, satisfying myself that I had not impacted the RPM behavior.

THREE: Tested one scenario with an H/A cluster consisting of 3 control plane instances and 2 workers:

Airgap install v1.25.11+rke2r1
Airgap install v1.25.13+rke2r1

Release Notes

NONE

[mddamato]

Thank you for the contribution, @aceeric . In reviewing this I realized a few flaws and decided to take this opportunity to refactor a few things.

The first thing is it doesn't make sense to provide both a install_rke2_version string and a tarball file. I can see confusion arising if a tarball version differs from that var so I decided to have the playbook inspect the version of the tar to determine it's version and ignore that var input if the tar is supplied.

The second thing is I rearranged the version determining logic so that both rpm and tar installation methods use the same task file. this makes it easier to control when/how it's run.

I took your idea of finding the current version of RKE2 and moved it to the previous_install task file to run all the time and make those variables more consolidated.

Lastly, this should now not only allow upgrading via tar, but it should also be idempotent and only do the installation if it's not installed or the versions differ. I didn't like that it seemed to do the binary swap regardless.

I am going to commit to this today and then do some additional testing. Let me know if you find an issue with any of this.

[aceeric]

@mddamato All your points make sense. Regarding the install_rke2_version, the way we use that is so that we don't have to spend time cleaning out the tarball_install directory... This enables one to easily switch between RKE2 versions when testing things. I guess I should also add that our Ansible which includes your Ansible supports a variable stage_rke2 which - if true - curls down the version specified in install_rke2_version and places it in the tarball_install directory to automate that.

[mddamato]

@aceeric , I am not sure I understand what you mean by

so that we don't have to spend time cleaning out the tarball_install directory

Instead of relying on the version var, I want the new functionality to rely on the actual tarball provided. To switch versions you would switch the tarball which would be the only way to switch versions anyway regardless of the var

[aceeric]

@mddamato to amplify - We have an Ansible role that supports staging the binaries based on the existing install_rke2_version var and our var stage_rke2: true. The salient part of the role is:

- name: Download objects
  ansible.builtin.get_url:
    url: "{{ url + '/' + item }}"
    dest: "{{ playbook_dir }}/tarball_install"
    validate_certs: false
  with_items:
  - rke2-images.linux-amd64.tar.zst
  - rke2.linux-amd64.tar.gz
  - sha256sum-amd64.txt

So by simply changing install_rke2_version it is possible to perform successive tarball installs with various versions i.e. for compatibility testing. I provide that info as background for why my initial contribution decisioned on the version var. Anyway our additional Ansible will integrate with your approach. Possibly we could contribute our stage_rke2 role at some point. It's pretty simple.