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

Re-throw ResponseException as AssertionError in BasicLicenseUpgradeIT #67182

Merged
merged 2 commits into from
Jan 8, 2021

Conversation

fcofdez
Copy link
Contributor

@fcofdez fcofdez commented Jan 7, 2021

It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with NORMAL priority, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we use the
ignore parameter in the http client and later check that the
response was correct, meaning that the check can be retried
if the license information is not ready yet.

Closes #64578

It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with priority NORMAL, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we rethrow
http client exceptions as AssertionExceptions so the check
can be retried.

Closes elastic#64578
@fcofdez fcofdez added >test Issues or PRs that are addressing/adding tests :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. v8.0.0 Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v7.12.0 labels Jan 7, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

Map<String, Object> licenseMap = (Map<String, Object>) licenseResponseMap.get("license");
assertEquals("basic", licenseMap.get("type"));
assertEquals("active", licenseMap.get("status"));
try {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this work as an alternative? This way it only retries on a 404:

        final Request request = new Request("GET", "/_license");
        request.addParameter("ignore", "404");
        Response licenseResponse = client().performRequest(request);
        assertOK(licenseResponse);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't know about the ignore parameter, that looks much better 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

Full disclosure: nor did I until just now 😁

@fcofdez fcofdez requested a review from DaveCTurner January 7, 2021 19:11
Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

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

LGTM

@fcofdez fcofdez merged commit 79f5b9c into elastic:master Jan 8, 2021
fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Jan 8, 2021
It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with NORMAL priority, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we use the
ignore parameter in the http client and later check that the
response was correct, meaning that the check can be retried
if the license information is not ready yet.

Closes elastic#64578
Backport of elastic#67182
fcofdez added a commit that referenced this pull request Jan 8, 2021
…#67212)

It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with NORMAL priority, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we use the
ignore parameter in the http client and later check that the
response was correct, meaning that the check can be retried
if the license information is not ready yet.

Closes #64578
Backport of #67182
fcofdez added a commit to fcofdez/elasticsearch that referenced this pull request Jan 27, 2021
It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with NORMAL priority, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we use the
ignore parameter in the http client and later check that the
response was correct, meaning that the check can be retried
if the license information is not ready yet.

Closes elastic#64578
Backport of elastic#67182
fcofdez added a commit that referenced this pull request Jan 27, 2021
…#68046)

It's possible that in a slow machine the cluster state updates
take a while to be applied, the license information is published
with NORMAL priority, meaning that it can take a while for the
License information to become available. This can lead to race
conditions. In order to wait until the license information is
available, the tests use assertBusy, but assertBusy only retries
if an AssertionException is raised, for that reason we use the
ignore parameter in the http client and later check that the
response was correct, meaning that the check can be retried
if the license information is not ready yet.

Closes #64578
Backport of #67182
elasticsearchmachine pushed a commit that referenced this pull request Aug 20, 2024
Relates: #110729

The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my
theory is that it's because applying the license of the cluster to
cluster state has `NORMAL` priority and therefore sometimes (very
rarely) takes more than 10 seconds. There are some related discussions
to this, see: #67182,
#64578

Since we're not testing the actual license lifecycle in this test, but
instead how an applied license impacts the query roles API, I changed
the approach to use the synchronous `/_license/start_trial` API in a
`@before` so we can be sure the license was applied before we start
testing. An alternative to this fix could be to increase the timeout.
lkts pushed a commit to lkts/elasticsearch that referenced this pull request Aug 20, 2024
Relates: elastic#110729

The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my
theory is that it's because applying the license of the cluster to
cluster state has `NORMAL` priority and therefore sometimes (very
rarely) takes more than 10 seconds. There are some related discussions
to this, see: elastic#67182,
elastic#64578

Since we're not testing the actual license lifecycle in this test, but
instead how an applied license impacts the query roles API, I changed
the approach to use the synchronous `/_license/start_trial` API in a
`@before` so we can be sure the license was applied before we start
testing. An alternative to this fix could be to increase the timeout.
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this pull request Sep 4, 2024
Relates: elastic#110729

The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my
theory is that it's because applying the license of the cluster to
cluster state has `NORMAL` priority and therefore sometimes (very
rarely) takes more than 10 seconds. There are some related discussions
to this, see: elastic#67182,
elastic#64578

Since we're not testing the actual license lifecycle in this test, but
instead how an applied license impacts the query roles API, I changed
the approach to use the synchronous `/_license/start_trial` API in a
`@before` so we can be sure the license was applied before we start
testing. An alternative to this fix could be to increase the timeout.
davidkyle pushed a commit to davidkyle/elasticsearch that referenced this pull request Sep 5, 2024
Relates: elastic#110729

The `testQueryDLSFLSRolesShowAsDisabled` failed intermittently and my
theory is that it's because applying the license of the cluster to
cluster state has `NORMAL` priority and therefore sometimes (very
rarely) takes more than 10 seconds. There are some related discussions
to this, see: elastic#67182,
elastic#64578

Since we're not testing the actual license lifecycle in this test, but
instead how an applied license impacts the query roles API, I changed
the approach to use the synchronous `/_license/start_trial` API in a
`@before` so we can be sure the license was applied before we start
testing. An alternative to this fix could be to increase the timeout.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. >test Issues or PRs that are addressing/adding tests v7.12.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CI] Failure in org.elasticsearch.upgrades.BasicLicenseUpgradeIT.testOldAndMixedClusterHaveActiveBasic
4 participants