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

Initial commit of Node Affinity Anti-Affinity workload files #91

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

wabouhamad
Copy link
Contributor

Node Affinity Anti-Affinity workload files:

modified:   docs/README.md
new file:   docs/node-affinity.md
new file:   workloads/files/workload-node-affinity-script-cm.yml
new file:   workloads/node-affinity.yml
modified:   workloads/templates/workload-env.yml.j2
new file:   workloads/vars/node-affinity.yml

@wabouhamad
Copy link
Contributor Author

@mffiedler @chaitanyaenr please review

@wabouhamad
Copy link
Contributor Author

@mffiedler @chaitanyaenr please review, been running these workloads from Jenkins since OCP 4.2

Copy link
Member

@chaitanyaenr chaitanyaenr left a comment

Choose a reason for hiding this comment

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

LGTM


The Node Affinity Anti Affinity workload playbook is `workloads/node-affinity.yml` and will run the Node Affinity Anti Affinity Workload workload on your cluster.

The Node Affinity Anti Affinity workload's purpose is to validate if the OpenShift cluster can deploy 130 pause-pods with node affinity to one labeled worker node, and 130 hello-pods with anti-affinity to another labeled worker node. Deployed pods have memory and CPU requests, and goal is to be close 85% CPU capacity after all pods are deployed.
Copy link
Member

Choose a reason for hiding this comment

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

85% is subjective to the worker node instance type right?

result_dir=${benchmark_results_dir}
fi

# git clone svt repo in /root
Copy link
Member

Choose a reason for hiding this comment

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

Maybe add a pointer to the script and pod spec/template in svt repo since they are being maintained there. This way, we will the location in case we need to modify something. On the other hand, it might be a good idea to bake in the script and pod templates into the workload itself like how we are doing in case of other workloads like nodevertical for example : https://github.com/openshift-scale/workloads/blob/master/workloads/templates/workload-nodevertical-script-cm.yml.j2#L75. This way we will have a clear idea of what workload is doing as well easier to modify it in case we want to change something. Thoughts?

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.

3 participants