-
Notifications
You must be signed in to change notification settings - Fork 85
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
Fix Kafka cleaner & Azure Location creation flakies #2097
base: development/2.6
Are you sure you want to change the base?
Conversation
Hello williamlardier,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Request integration branchesWaiting for integration branch creation to be requested by the user. To request integration branches, please comment on this pull request with the following command:
Alternatively, the |
/create_integration_branches |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option
The following options are set: create_integration_branches |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_integration_branches |
tests/ctst/common/common.ts
Outdated
|
||
// Topic is cleaned, we don't need to check it anymore | ||
// Ensure we're accessing the correct partition details | ||
const lowOffsetIncreased = parseInt(partition.low) > |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need to parseInt
here and not below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not done with the pr yet, jira transitioned it in review because I created the PR (not in draft to have the integration branches), but I still have some parts to improve, especially on the 2.8 branch
I will let you know when it's done
tests/ctst/steps/utils/kubernetes.ts
Outdated
// So the status might not be updated immediately after the overlay is applied. | ||
// So, this function will first wait till we detect a reconciliation | ||
// (deploymentInProgress = true), and then wait for the status to be available | ||
const timeout = 15 * 60 * 1000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why 15 minutes ? can we make it configurable ? The default TO in cucumber is 100 seconds, should we make it 100 seconds as well by default ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can access the timeout from the test by default, by passing the test object in the function, so that we wait just what's needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, to answer the question: the functions will have the timeout as a parameter, but the default remains 15min; the reason is that the service restart can take up to 3~4min as per my observations, and sometimes longer, if some tests are running at high frequency, blocking kube from restarting the pods quickly (as they are still handling requests).
So, the steps reyling on these functions will need specific timeouts.
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_integration_branches |
9538041
to
dd79b07
Compare
dd79b07
to
746a5c6
Compare
/force_reset |
Reset completeI have successfully deleted this pull request's integration branches. The following options are set: create_integration_branches |
Integration data createdI have created the integration data for the additional destination branches.
The following branches will NOT be impacted:
You can set option
The following options are set: create_integration_branches |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
The following options are set: create_integration_branches |
tests/ctst/common/common.ts
Outdated
@@ -342,8 +339,13 @@ Then('kafka consumed messages should not take too much place on disk', { timeout | |||
.filter(t => (t.includes(this.parameters.InstanceID) && | |||
!ignoredTopics.some(e => t.includes(e)))); | |||
|
|||
timeoutID = setTimeout(() => { | |||
assert.fail('Kafka cleaner did not clean the topics within the expected time'); | |||
}, (topics.length || 1) * checkInterval * 5); // Timeout after 5 Kafka cleaner intervals |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we increase the timeout by the number of topics?
- the timeout is based on kafka-cleaner period, and we check every (remaining) topic on each iteration: so number of topics should not increase the timeout...
- move the timeout here prevents catching issues with kafka connection (
listTopics()
call above) which could get stuck...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I adapted the logic, it's true we do not need to wait for each topic, but for sure we needed to wait more, as the cleaning might be slower in the CI due to other tests jeopardizing resources temporarily...
/wait |
/approve |
low
property evolution to be more robust.Change in 2.8+: 032cb7e