-
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
ps: support the container...
notation for ps --filter network=...
#11075
ps: support the container...
notation for ps --filter network=...
#11075
Conversation
0a04b7d
to
cf72cd8
Compare
6473860
to
6af6f19
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flouthoc, Luap99 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 |
libpod/container.go
Outdated
@@ -1173,6 +1173,54 @@ func (c *Container) Networks() ([]string, bool, error) { | |||
return c.networks() | |||
} | |||
|
|||
// NetworkMode gets the configured network mode for the container. | |||
// Get actual value from the database | |||
func (c *Container) NetworkMode(ctrSpec *spec.Spec) (string, error) { |
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 does this accept a spec? The container struct already contains a spec, and nothing you're accessing here requires something that would be overwritten from the initial user-provided spec. Just using c.config.Spec
is simpler and safer.
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.
@mheon Following function is also going to be used by generateInspectContainerHostConfig
in inspect code chunk. I think for both inspect
and ps --filter
their exists a state where config does not exist (e.g., because the container was never started) for such cases I think we can read data from db.
However for inspect block ctrSpec
is already fetched from state so i thought would be more optimal to reuse the ctrSpec
as argument inoder to reduce lookup cost.
Please correct me if i am getting it wrong and i am also fine with using c.config.Spec
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.
c.config.Spec
is always valid; there is never a point at which it is not populated. It is not the final spec that is used for the container (we use it to generate the final spec), but it is very close - the changes made to produce a final spec are minimal. As such it is safe to use here - no part of what you are accessing will change during final spec generation.
6af6f19
to
cb2ab7d
Compare
@mheon I have resolved all your feedback comments in latest commit. I have a doubt on first feedback , could you please take a look and correct me if i am wrong somewhere. |
7b9054e
to
1212996
Compare
Re-basing with main to add fix for #11077 |
LGTM |
1212996
to
980fef7
Compare
@TomSweeneyRedHat thanks :) there is one change left which @mheon suggested. @mheon made relevant changes will only try to read spec from db if |
980fef7
to
fccacbd
Compare
Just a sec cleaning error handling for removed block. |
fccacbd
to
940196f
Compare
Signed-off-by: flouthoc <[email protected]>
940196f
to
2a484e7
Compare
@mheon This is resolved could you please review again. |
/lgtm |
Hi team,
Following PR extends
ps --filter
to support docker like:podman container ps --filter network=container:<CtrIdorCtrName>
.Closes: #10361