NAME and VERSION leak into toolbox container env

[juhp]

I noticed that envvar for ENV NAME=fedora-toolbox VERSION=30 leak into the toolbox environment.
I am not sure if this is desirable: eg NAME affects changelog entry generation in Emacs rpm-spec-mode. And probably having VERSION in the container is not that useful either.

[debarshiray]

Yeah, those variables are exported by Podman. It always felt odd that they aren't namespaced. I wonder if Docker does the same, and so it's done for compatibility.

[debarshiray]

I wish I could transfer this to libpod. Doesn't look like I have the necessary permissions for that. :(

@juhp could you please (re)file this against libpod ? We could do something to suppress these variables, but they come directly from Podman, so might be better to at least discuss it a bit first. I have no idea why such generically named and non-namespaced variables were chosen in the first place.

[debarshiray]

Oh wait, they actually come from the Dockerfile for the fedora-toolbox images.

[debarshiray]

They are mandated by the Fedora guidelines.

[debarshiray]

On closer reading, it doesn't look like the guidelines actually require them, but they are part of the example Dockerfile snippets.

[cverna]

So from a quick look at OSBS it seems that these labels are used to populate some data in koji post build. I don't think we can remove them.

I ll look into more details next week if there is a work around.

[debarshiray]

Thanks for clarifying that, @cverna !

[debarshiray]

@cverna confirmed in #fedora-containers on Freenode that NAME and VERSION really do need to be present in the Dockerfile.

[HarryMichal]

@debarshiray, I guess we could unset the env vars when the container is being initialized. That way we keep them in the Dockerfiles but they will not cause problems during runtime.

[Jmennius]

@debarshiray Can you clarify why exactly are they required?
Should we have them in non-Fedora images?

[debarshiray]

I guess we could unset the env vars when the container is
being initialized. That way we keep them in the Dockerfiles
but they will not cause problems during runtime.

The NAME and VERSION environment variables make their way into the toolbox containers from their corresponding images, and are part of the containers' metadata. See:

$ podman inspect --type container <container>

We could somehow unset the variables right before spawning the interactive shell inside the container. However, that would deepen the voodoo that we perform when launching the shell.

A cleaner alternative might be to block the environment variables from getting leaked into the container from the image, but I don't see an obvious way to do that.

[debarshiray]

Can you clarify why exactly are they required?

As @cverna mentioned, they are needed by the Fedora build system.

Should we have them in non-Fedora images?

I don't think you need them in non-Fedora images.

[Jmennius]

Thanks for the answer.
It looks like the only clean solution would be to change OSBS to rely on labels (which are actually designed for this type of metadata).

[debarshiray]

Closing.

We can revisit this once the Fedora build system no longer needs NAME and VERSION.

[JayDoubleu]

@debarshiray I might be wrong on this but by looking at the guidelines, looks like there is a requirement for the right labels to be present by fedora build system and not the env vars themeselves ?

https://github.com/containerbuildsystem/atomic-reactor/blob/bdf5ecf52db1a30a5db135d12b51a488c04ebe29/atomic_reactor/plugins/pre_bump_release.py#L253..L266

Could the env vars in Containerfile be converted to ARGS instead or change them to TOOLBOX_NAME and TOOLBOX_VERSION which would be quite useful to have inside?

[debarshiray]

Could the env vars in Containerfile be converted to ARGS instead

Just now @travier brought this up in containers/docs#15

Unfortunately, I am not an expert in Fedora's OCI image building pipeline. I
mostly follow what the maintainers of the pipeline mandate. :)