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

USHIFT-3490: workload partitioning enhancement #1648

Merged

Conversation

eslutsky
Copy link
Contributor

No description provided.

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 21, 2024
@eslutsky eslutsky changed the title WIP: workload partitioning enhancement USHIFT-3490: workload partitioning enhancement Jun 27, 2024
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jun 27, 2024
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jun 27, 2024

@eslutsky: This pull request references USHIFT-3490 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature to target the "4.17.0" version, but no target version was set.

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 27, 2024
@eslutsky eslutsky changed the title USHIFT-3490: workload partitioning enhancement USHIFT-3490: WIP: workload partitioning enhancement Jun 27, 2024
@eslutsky eslutsky changed the title USHIFT-3490: WIP: workload partitioning enhancement USHIFT-3490: workload partitioning enhancement Jul 29, 2024
Copy link
Member

@pmtk pmtk left a comment

Choose a reason for hiding this comment

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

Document could use a bit of formatting

@eslutsky eslutsky force-pushed the workload-partitioning branch 6 times, most recently from 59cb2a6 to 11b224a Compare July 31, 2024 12:53
```json
{
"management": {
"cpuset": "0,6,7"
Copy link

@sjug sjug Jul 31, 2024

Choose a reason for hiding this comment

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

It would be especially friendly if the user could specify the reserved CPUs in one file and it propagates to all the necessary config (on service start?).

Copy link
Member

Choose a reason for hiding this comment

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

I agree that this sounds desirable. @eslutsky - can you comment please?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

as a principle we Dont change OS configuration from Microshift runtime, so all systemd/OS related configuration values has to be configured externally.

@eslutsky
Copy link
Contributor Author

eslutsky commented Aug 2, 2024

there are few duplicate files that needs to be managed , for example:

  • /etc/systemd/system/crio.service.d/microshift-cpuaffinity.conf
  • /etc/systemd/system/microshift.service.d/microshift-cpuaffinity.conf
  • /etc/systemd/system/ovs-vswitchd.service.d/microshift-cpuaffinity.conf (existing)
  • /etc/systemd/system/ovsdb-server.service.d/microshift-cpuaffinity.conf (existing)

can we use symbolik links to point all this file to some central location ? WDYT?

@jerpeter1
Copy link
Member

can we use symbolik links to point all this file to some central location ? WDYT?

These files are all identical, but they probably exist as separate files because someone might want to have different CPU affinity for each of these things. If that's not something we want to keep, then this suggestion makes some sense.

@eslutsky
Copy link
Contributor Author

eslutsky commented Aug 5, 2024

can we use symbolik links to point all this file to some central location ? WDYT?

These files are all identical, but they probably exist as separate files because someone might want to have different CPU affinity for each of these things. If that's not something we want to keep, then this suggestion makes some sense.

the problem is that symbolic links are not supported by the blueprint/osbuilder..

Signed-off-by: Evgeny Slutsky <eslutsky@redhat.com>
@eslutsky
Copy link
Contributor Author

eslutsky commented Aug 5, 2024

Document could use a bit of formatting

fixed

@pmtk
Copy link
Member

pmtk commented Aug 5, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 5, 2024
Copy link
Contributor

openshift-ci bot commented Aug 5, 2024

@eslutsky: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@jerpeter1
Copy link
Member

/approve

Copy link
Contributor

openshift-ci bot commented Aug 6, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jerpeter1

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

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 6, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit 5e48358 into openshift:master Aug 6, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants