-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
podman cgroup enhancement #14654
podman cgroup enhancement #14654
Conversation
Just making a draft PR of this to see how CI likes it (probably won't) @giuseppe PTAL! cc @edsantiago I could use some help on the system tests if you get a chance, not sure if what I did is legal. |
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.
GAH. Stupid github.
Review + force-push = collision, and I don't have that much time today (you caught me just before I moved on to other things). Suggestion: $ hack/bats 200:resource This will let you test on your development environment. G'luck. |
thanks for the tips @edsantiago ! just wanted to get a head start on this for next week |
@giuseppe I think this might be ready for a formal review also I need size approval for this PR @containers/podman-maintainers (250kb I think) This is about the sze we decided on in containers/common#936 |
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.
Great work. I had a look at the PR and it seems to work well.
Should we also expose CLI flags like --memory
? I do not see it for pod create
@giuseppe I did not expose that flag yet as I was thinking of doing it (and some other resource ones) in a separate PR to keep this one easier to understand. |
934023d
to
c93e632
Compare
sure, it makes sense. We can expose the other knobs later. |
3f3359c
to
65f4667
Compare
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.
LGTM
The bloat_approved label was already discussed in the containers/common PR that added the dependency
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cdoern, giuseppe 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 |
@giuseppe do you think this is ok (for now) with the two |
I am fine with them, although, couldn't we just put them in the |
@giuseppe I think podman needed the runc replaced too since it calls it in stats.go. I am fine with either the replace or the require if it works. EDIT: yeah, c/common works in the require but runc does not (c/image or something must be reverting it). I will leave that as a replace. |
currently, setting any sort of resource limit in a pod does nothing. With the newly refactored creation process in c/common, podman ca now set resources at a pod level meaning that resource related flags can now be exposed to podman pod create. cgroupfs and systemd are both supported with varying completion. cgroupfs is a much simpler process and one that is virtually complete for all resource types, the flags now just need to be added. systemd on the other hand has to be handeled via the dbus api meaning that the limits need to be passed as recognized properties to systemd. The properties added so far are the ones that podman pod create supports as well as `cpuset-mems` as this will be the next flag I work on. Signed-off-by: Charlie Doern <[email protected]>
@containers/podman-maintainers PTAL |
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.
/lgtm
/hold
Before merging. @cdoern can you elaborate on the go.mod change? Would a require
do the trick as well?
@@ -75,3 +75,5 @@ require ( | |||
) | |||
|
|||
require github.com/docker/libnetwork v0.8.0-dev.2.0.20190625141545-5a177b73e316 // indirect | |||
|
|||
replace github.com/opencontainers/runc => github.com/opencontainers/runc v1.1.1-0.20220617142545-8b9452f75cbc |
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 is the replace 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.
I have a feeling this is no longer needed. We should be able to use runc v1.1.3, @cdoern Could you repush and see if this works?
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.
@rhatdan 1.1.3 did not include the two changes we need. Not sure why but runc chose not to pick those commits for the point release.
Just saw the comment now. I really want us to figure out what that is now. Otherwise, we are just deferring work that must be done at some point. |
|
in this PR, runc is vendored in as a replacement rather than a requirement. This is because the changes this PR depends on within runc have not been added in a point or major release yet. Vendoring in the commit as a requirement causes regressions in other important repositories. |
/hold cancel. |
/hold cancel |
I think this is blocking the CI bot, review was addressed a while back.
The replace was needed when working on github.com/containers/podman/pull/14654 but is not anymore. Drop the replace to consume the correct version of runc. Signed-off-by: Valentin Rothberg <[email protected]>
The replace was needed when working on github.com/containers/pull/14654 but is not anymore. Drop the replace to consume the correct version of runc. Signed-off-by: Valentin Rothberg <[email protected]>
currently, setting any sort of resource limit in a pod does nothing. With the newly refactored creation process in c/common, podman can now set resources at a pod level
meaning that resource related flags can now be exposed to podman pod create.
cgroupfs and systemd are both supported with varying completion. cgroupfs is a much simpler process and one that is virtually complete for all resource types, the flags now just need to be added. systemd on the other hand
has to be handeled via the dbus api meaning that the limits need to be passed as recognized properties to systemd. The properties added so far are the ones that podman pod create supports as well as
cpuset-mems
as this willbe the next flag I work on.
in this PR, runc is vendored in as a replacement rather than a requirement. This is because the changes this PR depends on within runc have not been added in a point or major release yet. Vendoring in the commit as a requirement causes regressions in other important repositories.
Signed-off-by: Charlie Doern [email protected]
Does this PR introduce a user-facing change?