Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update playbook example and other potential enhancements #108

Closed
ingmarfjolla opened this issue Jul 25, 2023 · 4 comments
Closed

Update playbook example and other potential enhancements #108

ingmarfjolla opened this issue Jul 25, 2023 · 4 comments

Comments

@ingmarfjolla
Copy link
Contributor

Hi, we just used this collection to automate an upgrade and were wondering what enhancements might work / what might not be needed for the repo. @pavuluriharsha @elaczyns

  1. Updating the playbook examples for both the analysis and upgrade.

I see that a PR with updated documentation has been merged, so would it be worthwhile to add example playbooks for the analysis and upgrade that make use of the variables? As an example in the upgrade playbook:

- name: RHEL OS Upgrade
  hosts: all
  strategy: free
  force_handlers: true
  vars:
    satellite_organization: 'my_organization'
   satellite_activation_key_leapp: 'key'
   satellite_activation_key_post_leapp: 'key'
    leapp_upgrade_opts: '--target 8.8'
    update_grub_to_grub_2: true
    selinux_mode: permissive
 
  tasks:
    - name: Perform OS upgrade
      ansible.builtin.import_role:
        name: infra.leapp.upgrade
...

we needed to make use of the variables and having an example in the repo for others would be handy to see an example.

  1. Should this repo make mention of the xfs fix?

One of the issues we ran into was here: https://access.redhat.com/solutions/5057391 and we tested and verified the upstream RPM worked without needing to add any extra space and this collection was able to default to using that. Is that something this repo should mention as a possible workaround? If so, there could be an extra role added (we just added a task) that might take care of installing that on the target machines with the caveat that it's currently unsupported.

  1. Should the analysis task fail if there are inhibitors?

We added our own assertion at the end of the analysis task that would fail in the case of any inhibitors so that we wouldn't move forward with the upgrade. This one is more of a question, but for my own understanding is there a reason the analysis task doesn't currently aim to fail if there are any inhibitors?

@djdanielsson
Copy link
Collaborator

djdanielsson commented Jul 25, 2023

  1. good idea
  2. no, because it is a temporary thing. at most maybe create an issue with the solution
  3. that is up to the users, in some cases people may not want it to fail but that is why we provide a fact for users to easily use just the way you did.

@ingmarfjolla
Copy link
Contributor Author

cool, will get a PR up in a couple days for 1 and open an issue for 2

@swapdisk
Copy link
Member

@ingmarfjolla, does merged PR #109 solve number 1? Anything else needed to close this issue?

@ingmarfjolla
Copy link
Contributor Author

@swapdisk sorry I missed this, yes I think we can close this now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants