Closed ingmarfjolla closed 1 year ago
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.
cool, will get a PR up in a couple days for 1 and open an issue for 2
@ingmarfjolla, does merged PR #109 solve number 1? Anything else needed to close this issue?
@swapdisk sorry I missed this, yes I think we can close this now
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
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:
we needed to make use of the variables and having an example in the repo for others would be handy to see an example.
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.
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?