test: include podman-stressor

[dougsland]

podman-stressor - A tool based on Podman, cgroupv2, and systemd that creates a cgroupv2 namespace with limited resources according to user input and starts 'N' containers to ensure Podman behaves correctly.

Additionally, it is possible to enable a stress feature that uses the stress-ng tool to stress each container in parallel and verify if the applications and services running in the container environment are stable and secure.

This tool also ensures that containers do not exceed their resource limits, even in the presence of memory, CPU, or other system interferences.

Furthermore, it is an excellent way to test container scalability and interference between containers using Podman, allowing you to trigger 100, 1k, 5k, or even 1 million containers.

Why bash?

We just call existing programs, no need to add extra layer of python, golang or rust for calling program at this moment.

Does this PR introduce a user-facing change?

None

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: dougsland Once this PR has been reviewed and has the lgtm label, please assign flouthoc for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[OWNERS](https://github.com/containers/podman/blob/main/OWNERS)** Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[dougsland]

cc @ypu

[Luap99]

@dougsland You have a good description of what this does but not why? What is the ultimate goal of stress testing podman? Who is going to run this? Who is maintaining this code and/or why does this need to be in our upstream repository?

[giuseppe]

should this be its own project?

[edsantiago]

This is already its own project: https://github.com/dougsland/podman-stressor

@dougsland thanks again, but can you offer a compelling reason for placing this in the podman repo? I don't see us running it in CI, and this is not something we can possibly maintain. Presumably you have a target audience in mind for running this, can you work with them?

[dougsland]

Hi @Luap99

@dougsland You have a good description of what this does but not why? What is the ultimate goal of stress testing podman?

In short, when working in the auto industry, it's important to prove for certifications that components in the entire solution are as resilient as possible and do not fail in the initial rounds in different angles of tests. Cloning from an official repo seems better than a personal project or downstream only.

Who is going to run this? Who is maintaining this code and/or why does this need to be in our upstream repository?

Initially myself.

@giuseppe

should this be its own project?

could be an idea, I am not sure where. maybe in containers/?

@edsantiago

This is already its own project: https://github.com/dougsland/podman-stressor

Personal repo.

@dougsland thanks again, but can you offer a compelling reason for placing this in the podman repo? I don't see > us running it in CI, and this is not something we can possibly maintain. Presumably you have a target audience in mind for running this, can you work with them?

shared above the details.

Please let me know your thoughts guys.

[baude]

@dougsland what you are seeing here is a general lack of comfort with adding this to the podman repo proper because ultimately the team becomes responsible for maintaining it. And this is something we cannot accept at this point. And it will not run in our CI, etc. Having it in its own project makes sense but if it carries the podman name, then the same rul more or less applies that the team is responsible for maintaining it. I think if you renamed it, we could give you a spot on github under the containers organization. How does that strike you?

[dougsland]

@dougsland what you are seeing here is a general lack of comfort with adding this to the podman repo proper because ultimately the team becomes responsible for maintaining it. And this is something we cannot accept at this point. And it will not run in our CI, etc. Having it in its own project makes sense but if it carries the podman >name, then the same rul more or less applies that the team is responsible for maintaining it. I think if you renamed it, we could give you a spot on github under the containers organization. How does that strike you?

Sounds good to me. Thanks all.

[dougsland]

@dougsland what you are seeing here is a general lack of comfort with adding this to the podman repo proper because ultimately the team becomes responsible for maintaining it. And this is something we cannot accept at this point. And it will not run in our CI, etc. Having it in its own project makes sense but if it carries the podman >name, then the same rul more or less applies that the team is responsible for maintaining it. I think if you renamed it, we could give you a spot on github under the containers organization. How does that strike you?

Sounds good to me. Thanks all.

As reference only: https://github.com/containers/engine-stressor