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 #53745

Closed

Conversation

github-abcde
Copy link
Contributor

@github-abcde github-abcde commented Jul 8, 2019

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) PRs:

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 using Mock.

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.
@ghost
Copy link

ghost commented Jul 8, 2019

@github-abcde, thanks for your PR! By analyzing the history of the files in this pull request, we identified @ryan-lane and @tkwilliams to be potential reviewers.

@github-abcde github-abcde requested a review from a team as a code owner July 29, 2019 07:40
@ghost ghost requested a review from DmitryKuzmenko July 29, 2019 07:40
@dwoz
Copy link
Contributor

dwoz commented Jan 1, 2020

Closing this since it has a PR to the master branch

@dwoz dwoz closed this Jan 1, 2020
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