-
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
use cached containers.conf #16238
use cached containers.conf #16238
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vrothberg 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 |
c801b92
to
78634ef
Compare
Performance benefits on my machine are in ns but I assume that's because containers.conf is mostly commented out. Parsing a custom containers.conf would take longer where the benefits would be more visible. |
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
An unexpected armada of errors. |
@Luap99 any suspicion what's causing the farts? |
78634ef
to
65cafa7
Compare
OK, I think I got it. Must have been the volume path. |
@containers/podman-maintainers PTAL |
/hold |
Tests are very angry |
Down to one failing test. I'll tackle that tomorrow o/ |
I have an alternative to this. |
I really don't like how we are using the pointer to the default config and mess with it. There's still some issue when creating the reset runtime which is painful to debug. |
OK, I see what's going on. The static dir (i.e., root) is being joined with "libpod" later on which in turn changes the default config. We really need to separate the concerns of "displaying defaults on the CLI", "loading a default config", "storing and altering a config in the libpod runtime". At the moment, we conflate them into one and I think that's too risky to cause hard-to-debug issues in the future. |
65cafa7
to
e48fa43
Compare
Updated the PR to not use the default config for storing the CLI values. I will have a closer look at how we pass around the |
e48fa43
to
de4dc9d
Compare
OK, I started shaving the yak. I thought this will be a quick fix. |
Use `Default()` instead of re-loading containers.conf. Also rework how the containers.conf objects are handled for parsing the CLI. Previously, we were conflating "loading the defaults" with "storing values from the CLI" with "libpod may further change fields" which ultimately led to various bugs and test failues. To address the issue, separate the defaults from the values from the CLI and properly name the fields to make the semantics less ambiguous. [NO NEW TESTS NEEDED] as it's not a functional change. Fixes: containers/common/issues/1200 Signed-off-by: Valentin Rothberg <[email protected]>
de4dc9d
to
4e29ce2
Compare
I reworked |
Search flake is kicking in hard :( I opened #16248 but think I need to tackle that here as well. |
There's no guarantee that the searched image will be returned, so only make sure that "alpine" is mentioned somewhere. Fixes: containers#16248 Signed-off-by: Valentin Rothberg <[email protected]>
LGTM |
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 am not sure why we would need two configs? This will increase memory usage, unsafe.Sizeof(*config)
returns 1704 bytes right now, with this change we would double it.
Also I don't like that the original field is also renamed since this creates a unnecessary large diff IMO.
Did you read the commit message? I personally prefer a couple of bytes over messing with the default config. If so, please give actionable proposals. "I don't like XY" is not something I can work with. There's an inherent design flaw in Podman ran exactly into this trap as it was abusing the default config for storing CLI values. A clearer separation of concerns would be to not use a
Please read the commit message. I don't care much about the diff but care about error potentials. |
I try to understand this but I think I missing something. I see that we overwrite the config fields with cli options and you fix this by using another empty Config for that. But what is the point of that when in libpod.NewRuntime() you use the default config, which is then modified in newRuntimeFromConfig() with the values from the empty config. Therefore the default is still changed so I would assume we need a copy there as well? Or maybe it is better to just make config.Default() return a copy so that callers cannot modify the internal data. |
There is definitely more to improve. I really don't like how the
This PR stops conflating "loading the defaults" with "storing values from the CLI". It does not stop "libpod may further change fields". I can volunteer to have another look this week at the issue. But I think we should merge the PR as the issue is now at least more obvious than before. I was surprised by how many things fell apart after the initial change. |
Ok fine for me, this is definitely an improvement but we should keep an eye on this because it is super fragile. |
Thanks! I agree and will take another look this week. |
Use
Default()
instead of re-loading containers.conf.[NO NEW TESTS NEEDED] as it's not a functional change.
Fixes: containers/common/issues/1200
Signed-off-by: Valentin Rothberg [email protected]
Does this PR introduce a user-facing change?
@Luap99 @alexlarsson PTAL
I did not measure performance impacts.