Support modifying container configuration

[mheon]

/kind feature

Description
Per discussion with @cgwalters on IRC, we should look into supporting manipulation of existing containers via functionality similar to virsh edit. This would allow a lot of flexibility with managing containers.

At present, libpod containers are almost completely immutable, which complicates this request.

Thoughts on how we could do this:

• A container would have to be stopped or created - offline changes only
• Some things would not be allowed to be changed. Image is a certain one - at that point, creating a new container would be simpler
• We can delete and recreate the container with the changed configuration, but retaining c/storage configuration.

Complications with this approach:

• Do we retain the same ID? If so, how do we ensure we invalidate and/or force a config update on all older containers? Maybe a "config revision" or similar in the DB that, if changed, indicates we reload configuration? This would require locking all config operations as well (though maybe not including ID?)
• How does this work with c/storage? We store a bit of metadata (name and ID) in there - can we modify the c/storage metadata to match changes?
• What does the API for this look like? Do we allow passing of new Container options to modify the config? Can we accept an entirely new spec, as long as Image is not modified?

[cgwalters]

High level goal here is supporting the "pet container" use case.

[rhatdan]

Interesting idea. I think we would need a full design or what we would want to allow to be changed and what the admin would see.

[baude]

Im trying to wrap my head around this one too ... can someone provide a simple use case ... like i have this and i want to do this ?

[alice-mkh]

I have ru_RU.utf8 as a locale, and I want pet containers to automatically pick up LANG variable from host shell, so that I get russian output where possible, but english where cyrillic isn't available and so LANG is set to something different, to avoid output like "mv: ???????? ???????, ???????? ????".

Having correct TERM and COLORTERM values prevents funkiness with 256 colors in different terminal emulators.

Another usecase is to run pet container with a different workdir that it was created with, so that you can e.g. start pet in the same directory you're already in.

[rhatdan]

@Exalm Would just leaking TERM and COLORTERM, LANG into the container be enough?
podman run --env TERM --env COLORTERM --env LANG ...

Should do the right thing.

[alice-mkh]

Would that reuse an existing container, or create a new one? The "pet" container use-case assumes you reuse an existing container over and over again so that it can have state, e.g. manually installed packages or shell history. So, I meant starting a container with different variables than what it was created with.
Edit: yes, it creates a new container. So that wouldn't work.

[rhatdan]

I believe the environment would be recorded the first time you use it, and then used everytime afterwards.
podman has a bug right now that makes it difficult, since you can not stop and restart a container. but we are working on fixing this.

[mheon]

I think there are usecases for this separate from pet containers - adjusting the resource limits of a container before restarting it, for example.

[rhatdan]

Yes I agree, although one mans pet container is another man's container that can be stopped and restarted.

[rhatdan]

Going through old bugzillas.

buildah has a command called config, that allows you to modify a buildah container.
Maybe we add a container command

buildah container config --env LANG=foobar CONTAINERID

This would allow us to select the container configuration that we are allowed to modify.

[rhatdan]

Lets look at adding
podman container config --env LANG=foobar CONTAINERID,
Then the next time the container gets started it would use the new configuration.

[mheon]

This would involve major and invasive changes to Podman's internals... I don't want to do this unless there is clear demand from someone that we add these features and do it now.

[rhatdan]

I guess we can leave this up to @cgwalters and @Exalm how much they need this feature?

@mheon So modifying the runtime spec would be that difficult?

[mheon]

@rhatdan Everything about libpod assumes the container config - the spec and everything else we store at create time - never changes, and so never needs to be updated. We'd need to change everything to refresh from the database every time we did a config read.

[alice-mkh]

@rhatdan I worked around this by writing a file with variables before starting container, and then sourcing and removing this file from inside. However, it's just my hacky solution, and I assume that Silverblue pet container tooling will need this as well, at least for things like $VTE_VERSION. Better to ask whoever is/will be doing that, I guess. :)

[vrothberg]

Given the age of this issue, I suggest closing it. WDYT @mheon, @rhatdan?

Personally, I am afraid of the implications of a podman container config. I can understand why that could be useful in some use cases, but I'd argue that those look like container anti-patterns to me. A buildah config ... and starting a new container could be a workaround.

[mheon]

I'd still like to get a command for cloning and modifying containers in (create a new container based on a modified version of an existing container) to partially solve this, but I think that falls under a different issue.

…

On Mon, Nov 19, 2018, 05:42 Valentin Rothberg ***@***.*** wrote: Given the age of this issue, I suggest closing it. WDYT @mheon <https://github.com/mheon>, @rhatdan <https://github.com/rhatdan>? Personally, I am afraid of the implications of a podman container config. I can understand why that could be useful in some use cases, but I'd argue that those look like container anti-patterns to me. A buildah config ... and starting a new container could be a workaround. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#376 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHYHCGsimVO3sHx4Js9honXpltPqDtSaks5uwosCgaJpZM4SNw-k> .

[rhatdan]

Cloning a container is not really what they are after here. They want to be able to modify the default environment variables of a container at start time.
I kind of like the idea of leaking more information into the container from the host. For example the LANG, TERM and COLORTERM.

Does it make sense to start the container and exec into the container with these values set to the parent process when a container starts?

[vrothberg]

Does it make sense to start the container and exec into the container with these values set to the parent process when a container starts?

Sorry to reply with a question, but yours made me think a bit more. It looks like the hypothetical container config would be restricted as we can't change arbitrary bits of the entire config. Changing the environment (LANG, TERM, etc.), however, seems doable. Hence the question (based on yours):

Can't we add some flags to start and exec? A container config might invite repeated request for things that cannot be implemented/changed.

[rhatdan]

Yes I am thinking more along the lines that these environment should be leaked into the container if not explicitly set by the user.

If I am working on a german system and run podman run, should the container run with LANG=German or English. (Defaults to English now). LANG could cause issues, since the German Lang config might not be in the container. And I know that LANG is en_US.UTF-8, and I think German is de_DE.UTF-8.

Other potential would be TZ. As well as TERM.

These things I think become more interesting

[vrothberg]

I like this kind of brainstorming.

Yes I am thinking more along the lines that these environment should be leaked into the container if not explicitly set by the user.

This might cause issues without the user's consent but having a flag for it would be nice.

[rhatdan]

Or should it be default and then the flag would turn off the leak.

I think right now if you just do
podman run --env TZ --env TERM

these environment gets put into the container.

But users will tend to forget to do this, Which to me breaks the way normal user expectations.

With fork/exec model users expect some environment to show up in the child process, in this case the container.

We could look to sudo for the model to do this.

sudo printenv LANG TERM FOO
en_US.UTF-8
xterm-256color
LANG=de_DE.UTF-8 TERM=vt100 FOO=BAR sudo printenv LANG TERM FOO
de_DE.UTF-8
vt100

Notice that LANG and TERM get passed through while foo does not

[vrothberg]

@rhatdan, the only objection against that is that I am afraid it might break something in the container. However, I am not aware of the impact of LANG. The concrete fear I have is that the container will behave differently depending on the ENV of the host/user which somehow feels like an anti-pattern. But again, I do not know exactly if LANG could yield a behavioral change. Can you elaborate on that?

[rhatdan]

@mheon What do you want to do with this issue?

[mheon]

IMO, we close this and generate an Enhancement issue for adding podman container clone to do this. We know how we want to do things now.

[mildred]

I see you planned to create a podman container clone subcommand but there is no issue created for it that I can find. Is it appearing somewhere else ?

[mheon]

I don't believe we created one. We can reuse this issue or create a fresh one and close this in favor of it.

…

On Mon, May 27, 2019, 06:20 mildred ***@***.***> wrote: I see you planned to create a podman container clone subcommand but there is no issue created for it that I can find. Is it appearing somewhere else ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#376>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3AOCF4SUPG76U7AWT7L2DPXOYVHANCNFSM4ERXB6SA> .

[bam80]

I don't believe we created one. We can reuse this issue or create a fresh one and close this in favor of it.

What is the status? Is the issue for podman container clone created?
If not, should we reopen this one?

[mheon]

The command is not yet ready. I swore that we had an issue dedicated to podman container clone, but it does not look like you do; feel free to file an RFE for it.

I'd like to get to it soon (I think some recently work we've done will make it a lot simpler), but currently all priority is on the HTTP API and Podmanv2