To help with SRU review, I'm adding here the discussion taken from the merge review.. basically I would like to give it a try backporting all fixes for fence_aws into Focal and adding that same agent version in Bionic (like a minor SRU exception). Instead of relying in the test case results, I would like to rely in my functional/regression tests for a pacemaker cluster configured in AWS with this new agent (if possible).

---- Discussion with @bryce from the Ubuntu Server Team:

> I also read through each of the patches to understand what they do, and make sure the changes look safe, which they indeed do.  One thought I had though is that the common theme in the patches is improvements to debug/logging output; the SRU team sometimes demurs over debug/logging changes as less important than actual bug fixes.  At least you'll want to include good justification on this in the SRU text.

My justification to that is that Bionic does not have anything and I really would like Focal to be "as good as Focal", instead of adding something better in Bionic just because it did not have anything. Or even adding something not as good as Groovy just because of formal reasons.

> Commit 1c2f791b changes the cli option behavior, which is akin to an API change.  I.e. before if you passed --region but not --access-key or --secret-key it would ignore --region and use configured values, with this change you can specify just --region and the keys will come from the config file.  This feels more like a behavioral change than a bug fix, so I might anticipate some pushback from the SRU team on this.

Yes, this was per AWS request... and follows the same idea as the previous justification. This change allows one not to explicitly put the access or secret keys in the cluster CIB file (so its more secure also).

> In terms of SRU, I notice there are not (upstream|downstream) bug reports associated with the patches, which may make one wonder if these fix actual defects encountered in the wild, or are more like clarification/refactoring.

> I understand the logic of since the scripts don't exist in bionic to bring the current versions rather so as to have the most up to date code.  But as you mention this then leaves a weird situation and having to pull delta into focal that otherwise might not be needed.  

> Did you consider pulling the fence_aws from focal rather than the one in groovy?  (And then cherrypicking the most relevant bug fixes from groovy, like the encoding fix and/or the race fix?)

Yes I did.. unfortunately its a SRU philosophical question. I'm considering fence_aws here as a confined code that is mostly supported by AWS themselves. I can go on that direction but I feel it is not the best for our user base.

> Alternatively, if you definitely do want to backport the whole stack, did you consider filing for an SRU exception for this package?  If it really is important to keep the scripts identical on all LTS's that might be a better long term approach.

That would be a no-go because of agents metadata and pacemaker. Pacemaker should be able to handler older and newer fence-agents packages.. but it is not as good as "compatible with all further versions". 

I would like this to be considered a small SRU exception as it is for fence_aws only.