Skip to content

Add a test plan for the pulp-worker scalability test. #494

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

Merged
merged 1 commit into from
Apr 23, 2025
Merged

Conversation

decko
Copy link
Member

@decko decko commented Apr 16, 2025

No description provided.

@decko decko force-pushed the worker_testplan branch 2 times, most recently from 49aa8be to 2ebe84d Compare April 22, 2025 16:52

For database, we're using the AWS RDS PostgreSQL 16, on a db.m7g.2xlarge instance class.
In theory, the maximum number of connections is defined by `LEAST({DBInstanceClassMemory/9531392}, 5000)`
as written [here](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html#RDS_Limits.MaxConnections)
Copy link
Member

Choose a reason for hiding this comment

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

Maybe, it would be helpful to interpret this with a claim of the total count.


## Test Plan

1. Warn the pulp stakeholders (@pulp-service-stakeholders) that a test gonna happen in stage. All tasks must be stopped.
Copy link
Member

Choose a reason for hiding this comment

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

Realistically we can't ask folks to stop the tasks. I think warning them we're scaling down the memory footprint and their tasks may fail due to memory errors is what they need to know. Also I think they need to know how long the test will run for (how long can they expect failures).

2. Create a MR reducing the resource for each worker, and increasing the number of workers. [here](https://gitlab.cee.redhat.com/service/app-interface/-/blob/master/data/services/pulp/deploy.yml#L75).
It can be approved by anyone from the team. Just need to wait for the app-sre bot to merge it.
3. After it got merged, check for the database metrics and application logs. The results from the run will be down in this document.
4. We need to check if there's any new worker being started. For that, we need to use the `WorkersAPI` and check a set with the names from time to time.
Copy link
Member

Choose a reason for hiding this comment

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

This step needs more detail. To me, it's the whole metric of interest. I'd avoid writing real rigorous code here, and maybe verbally describe the set-name difference "check" and maybe in pseudo-code describe it for clarity for the reader.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added an example of a script that can do the job.

@decko decko force-pushed the worker_testplan branch 2 times, most recently from 090b7bd to a4d8f39 Compare April 23, 2025 15:49
@decko decko force-pushed the worker_testplan branch from a4d8f39 to 50de5fe Compare April 23, 2025 16:40
Copy link
Member

@bmbouter bmbouter left a comment

Choose a reason for hiding this comment

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

@decko I think this is ready to go! Feel free to merge it and then open up a new MR revising the table once the data is available.

Does that sound ok to you?

@decko decko merged commit a9b12b3 into main Apr 23, 2025
1 check passed
@decko decko deleted the worker_testplan branch April 23, 2025 19:15
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