containers.conf: appendable string arrays, Part 1 #1707
Conversation
|
The PR as is compiles in Podman. |
|
LGTM, since this will not affect any change until users setup append=true, this really has no change on exisiting users, I believe. |
Yes, existing user will (and must) not be affected by this change. I am mostly worried about how to move Podman to stop abusing the internal structure/fields and rather use getters. For the upcoming 4.8 release I prefer to focus on what the users need now and then tackle the other fields. I find it hard to estimate the effort. |
|
Now done for |
|
@nalind FYI Will open PRs tomorrow. |
Commit 6506f4f implemented a POC to allow for changing the behavior when loading multiple container.conf files in sequence. By default, the TOML encoder will override existing data/fields with the one specified in the loaded file. The POC has demonstrated how this behavior can be changed to append string slices instead of overriding/replacing them entirely. This change is the first step of integrating these appendable string arrays into containers.conf and starts with enabling the `Env`, `Mounts`, and `Volumes` fields in the `[Containers]` table. Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
|
@Luap99 Ok to merge? |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Luap99, 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 |
|
/hold cancel |
@Luap99 @rhatdan PTAL
This is how I currently imagine the appendable strings to be wired in. But before going ahead, I desire your feedback.
My plan for now is to start with env variables, volumes and mounts. Once that's in, I will tackle the remaining fields. That should make sure that the customer can play with the appendable feature in 4.8. I will only add documentation when all
[]strings have been transformed.