Skip to content

Attempt to fix flaky API Key test#3367

Merged
simitt merged 9 commits intoelastic:masterfrom
simitt:flaky_apikey_test
Feb 26, 2020
Merged

Attempt to fix flaky API Key test#3367
simitt merged 9 commits intoelastic:masterfrom
simitt:flaky_apikey_test

Conversation

@simitt
Copy link
Copy Markdown
Contributor

@simitt simitt commented Feb 21, 2020

Motivation/summary

This PR aims for fixing two flaky system tests related to API Key creation via apikey command. In the current test implementation mostly the response from the command is checked, which is generally fair for testing the command. It can lead to potential issues though with following tests, when the command returned but the API Key change was not yet finished in Elasticsearch.

This PR refactors current test structure a bit to move basic wait_until_... functionality from the auth tests to the apikey command tests and make it reusable. With the changes the command tests ensure to wait until an API Key is really created or deleted in ES.

Since the PR involves moving logic around, the parts where logic is only moved is kept in dedicated commits for easier review.

The PR also moves TLS related tests to a dedicated file to keep test files cleaner.

Checklist

- [ ] I have signed the Contributor License Agreement.

  • My code follows the style guidelines of this project (run make check-full for static code checks and linting)
  • I have rebased my changes on top of the latest master branch

- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes

- [ ] I have updated CHANGELOG.asciidoc

Related issues

Fixes #3298

@simitt simitt added the test label Feb 21, 2020
@simitt simitt requested a review from jalvz February 21, 2020 13:32
@jalvz
Copy link
Copy Markdown
Contributor

jalvz commented Feb 24, 2020

when the command returned but the API Key change was not yet finished in Elasticsearch

If i understand correctly, the assumption is that a read after a write to the security API might not "see" the write? Has been confirmed with the elasticsearch team that this can happen?

@simitt
Copy link
Copy Markdown
Contributor Author

simitt commented Feb 24, 2020

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-refresh.html

If your application workflow indexes documents and then runs a search to retrieve the indexed document, we recommend using the index API's refresh=wait_for query parameter option. This option ensures the indexing operation waits for a periodic refresh before running the search.

@simitt
Copy link
Copy Markdown
Contributor Author

simitt commented Feb 24, 2020

The system tests use a refresh interval of 250ms https://github.com/elastic/apm-server/blob/master/tests/system/config/apm-server.yml.j2#L198

Copy link
Copy Markdown
Contributor

@jalvz jalvz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I guess I didn't expect that to apply to the security API.

Comment thread tests/system/test_apikey_cmd.py Outdated
password = os.getenv("ES_PASS", "changeme")
self.es_url = self.get_elasticsearch_url(self.user, password)
self.kibana_url = self.get_kibana_url()
self.base = APIKeyBase(self.es_url)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is an uncommon pattern, a comment explaining why is needed would help

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is using composition over inheritance to avoid multiple inheritance. Happy to add a comment, and change the variable name as I can see how base might be misleading.

@simitt
Copy link
Copy Markdown
Contributor Author

simitt commented Feb 24, 2020

I see. I guess I didn't expect that to apply to the security API.

That's a good point, I'll follow up on that.

@simitt
Copy link
Copy Markdown
Contributor Author

simitt commented Feb 24, 2020

@jalvz you are right, that the referenced refresh logic doesn't apply to the creation/invalidation of API Keys. I do not see how these tests can occasionally fail under these circumstances.

What do you think about still merging this PR in, as the additional wait_until calls should not add a lot of overhead when changes are immediately available. They would help to pinpoint the failure to the creation or the invalidation cmd though.

@jalvz
Copy link
Copy Markdown
Contributor

jalvz commented Feb 25, 2020

Sure

@simitt
Copy link
Copy Markdown
Contributor Author

simitt commented Feb 26, 2020

Merging this in then, as failing tests are unrelated.

@simitt simitt merged commit 36380d7 into elastic:master Feb 26, 2020
simitt added a commit to simitt/apm-server that referenced this pull request Feb 26, 2020
* Move TLS tests to separate file

* Rename test_access to test_auth

* Rename APIKey tests to APIKeyCommand

* Move APIKey logic to dedicated class

* Reuse dedicated API Key creation logic

* Split commands for flaky tests for apikey command to gain more insights by waiting 
   until apikeys are created or invalidated before moving on in tests

fixes elastic#3298
simitt added a commit that referenced this pull request Feb 26, 2020
* Move TLS tests to separate file

* Rename test_access to test_auth

* Rename APIKey tests to APIKeyCommand

* Move APIKey logic to dedicated class

* Reuse dedicated API Key creation logic

* Split commands for flaky tests for apikey command to gain more insights by waiting 
   until apikeys are created or invalidated before moving on in tests

fixes #3298
@simitt simitt deleted the flaky_apikey_test branch March 18, 2020 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fix flaky APIKeyTest test_invalidate_by_id

2 participants