-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Fix/stop checking unused boto versions #58715
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
Closed
major0
wants to merge
4
commits into
saltstack:master
from
major0:fix/stop_checking_unused_boto_versions
Closed
Fix/stop checking unused boto versions #58715
major0
wants to merge
4
commits into
saltstack:master
from
major0:fix/stop_checking_unused_boto_versions
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
0a298f8
to
38eee3f
Compare
3df1e0e
to
23676af
Compare
Ch3LL
suggested changes
Oct 20, 2020
23676af
to
868eaeb
Compare
08f0c56
to
f73c934
Compare
Ch3LL
suggested changes
Oct 21, 2020
56a2482
to
071c44a
Compare
Ch3LL
previously approved these changes
Oct 22, 2020
waynew
reviewed
Oct 22, 2020
waynew
previously approved these changes
Oct 22, 2020
Most boto/boto3 modules do not actively use both boto and boto3. This commit modifies the check_boto_reqs() utility function to stop assuming a boto version and to only perform a boto check for a specific version of boto should a boto version be specified.
A number of boto3 modules contain boto checks and imports, but do not actually make any boto calls via the boto libraries.
071c44a
to
142720d
Compare
waynew
approved these changes
Oct 23, 2020
Apologies on the late follow up here, but it looks like there is some merge conflicts. Can I help with anything? |
@major0 are you willing to come back to this PR and fix the merge conflicts? |
Closing due to inactivity. Please let me know if I need to re-open or please open against master with the merge conflict resolved. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Modifies the default behavior of
salt.utils.check_boto_reqs()
such that it stops defaulting the default assumption that all code needs boto and boto3.The AWS boto2 and boto3 libraries are only compatible in regards to "some" method names (though not in their arguments to those methods), they do not use the same config patterns, data structures, or even the same exceptions.
The AWS boto3 library went stable 5 years ago, and the old boto2 (boto v2) library was deprecated shortly after. The last bugfix release for boto was 2 years ago and it is all but dead now. I have been working on a number of other PR's to try to remove the need for boto from SaltStack in part to even get SaltStack to fully work with the AWS configs and new features (E.g. ECS has moved to extended ARNs that are unavailable in boto2).
Previous Behavior
Previous version of
salt.utils.check_boto_reqs()
assumed that all code needed bothboto_ver=2.0.0
andboto3_ver=1.2.6
as minimum versions, even if the code only ever used one or the other. Most boto modules include tests for both boto and boto3 as a result of this pattern even if all remaining code is strictly boto2 or boto3.Of all the code in SaltStack I have only found 3 modules that make attempts to utilize boto2 and boto3 at the same time, and they contain comments similar to:
New Behavior
salt.utils.check_boto_reqs()
to stop assuming boto modules need both boto2 and boto3.check_boto
andcheck_boto3
parameters. The performance of any test should rely on the specification of a boto/boto3 version.Merge requirements satisfied?
[NOTICE] Bug fixes or features added to Salt require tests.
Commits signed with GPG?
Yes