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

Boto3 elasticsearch master #55768

Merged
merged 12 commits into from
Jan 2, 2020

Conversation

github-abcde
Copy link
Contributor

Master port of #53745

What does this PR do?

It adds a execution module, implemented with boto3 only, to interface with the AWS ElasticSearch service.
It adds a state to allow stateful interaction with said execution module.
It adds an elasticsearch-specific utils file with waiter definitions currently not present in botocore, allowing us to use boto3's waiter system to wait until a certain state has been achieved. When the waiters are eventually added to botocore, this file will no longer be required, though past experience (and the history of PRs for extra waiters for botocore) has taught me that this may take years.
!! Requires the following (currently not yet merged) PR:

What issues does this PR fix or reference?

None that I know of.

Previous Behavior

The execution module boto_elasticsearch_domain is implemented using a mix of boto2 and boto3 exists, which does not implement all API calls the AWS ES service has made available.
The state module boto_elasticsearch_domain does not use all parameters that can currently be used with the AWS ES service in its present and absent functions.
There is no support for tagging or version upgrades. (The present-function does allow a Tags-parameter but doesn't do anything with it).
No blocking functionality is present to ensure that the requested resource are actually present after the present-function returns. The same goes for absent.

New Behavior

The new state supplies present, absent, upgraded, latest and tagged functions. The new state requires certain module functions to be loaded (which implicitly requires botocore version 1.10.77).
The upgraded and latest functions allow for managing the version (upgrading only) of Elasticsearch that is running on a targeted AWS ES domain.
The new execution module is implemented using boto3 only, with @depends-version checks per function in order to allow the module to work on multiple versions of boto3/botocore without any difficulties.
The state- and (some, where applicable) execution module functions have blocking arguments to allow blocking the return of the called function until the managed resource has the required state.
All functions pertaining interaction with AWS ES listed in https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/es.html are present in the execution module.

Tests written?

Yes, unittests for the execution module have been written.

Commits signed with GPG?

Yes

utils/boto3_elasticsearch.py: Contains custom waiter definitions that we will need to use until they get implemented in botocore (not present in 1.12.183).
modules/boto3_elasticsearch.py: Contains all functions from boto3 that interact with AWS. Added a few helper functions.
states/boto3_elasticsearch.py: Added states for the AWS ES service.
…enough.

Renamed ESUpgradeFinished2 to ESUpgradeFinished instead.
Renamed references to ESUpgradeFInished2 in the execution module.
…ded nontrivial CLI examples. Fixed broken CLI example.
@github-abcde github-abcde requested a review from a team as a code owner December 31, 2019 09:34
@ghost ghost requested a review from DmitryKuzmenko December 31, 2019 09:34
@dwoz dwoz merged commit caec765 into saltstack:master Jan 2, 2020
@github-abcde
Copy link
Contributor Author

@dwoz Note that the boto3_elasticsearch state module will not work without #55759, as mentioned in the PR description (I only built unittests for the execution module of this PR).

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

Successfully merging this pull request may close these issues.

2 participants