@rhatdan Could you provide image and run command with which I can test this?

nice, I like this approach

@rhatdan You should write integration-cli test.
And I didn't get expected ID from /etc/machine-id with codekoala/arch:latest and fedora/systemd-systemd:latest. I think it is some hardcoded /etc/machine-id in these images.

It will not override an existing /etc/machine-id. So I guess you need to make sure there is no /etc/machine-id in the image, before running. I have not tested this with a systemd container yet. I am just following the example given on the document page. I will look into testing or having someone test this next week to make sure it works properly. (I am on Vacation next week).

is this really so insignificant to not need documentation?

I added some mention of container_uuid to the examples and a line to docker run man page. Do you want this mentioned elsewhere. Not sure we document any other environment variables being set.

ping @shykes

What do you think about this proposed change? Are we ready to support letting containers know the ID?

Back from Vacation, updating Pull Requests and seeing if there is anything I can do to move these along.

Docs LGTM - @jamtur01 @fredlf @ostezer

LGTM. Ping @jamtur01

@crosbymichael @shykes this would also close #6481

Docs LGTM

Will there be a way to disable this? I can perfectly imagine that I wouldn't like my processes to know they're running within Docker by checking for the existance of this environment variable; sorry for the pedant minimalism, but I would also not clutter (further) the environment variables with this feature.
I understand systemd expects this environment variable and it would be nice if it were already set, but on the other hand not everybody is running systemd in containers...

Well you could unset container_uuid within the containers init. I think adding an option to stop this would be a waste.

At first, there is still no tests. And I still want to see how this works.

@LK4D4 Added integration test.

What is the magic command to allow me to test only my test? Not the entire test suite?

TESTFLAGS='-run TestCLIImageTagRemove' make test-integration-cli

hostname makes sense to override, Env container_uuid not so much.

@rhatdan Hello, I just realized that we talking about inside container env, so will not this be the same like:

docker run -it --rm -e container_uuid=$(uuidgen) busybox printenv container_uuid

How about we just set the Docker container ID in a CID envvar ?

I would be okay with adding container_uuid if we also add container_id or something like that so systemd and users can benefit :) but this is just my opinion
maybe an okay compromise?

I'm fine with making the container's ID available to the application in a well-know and well-supported env variable. It would be strictly better than applications trying to infer it from something that is not fully supported, like the hostname.

I think we should avoid the term "uuid" since, technically, the current ID is not a uuid, and even if it were, we reserve the right to change the allocation method later. For example with the new trust primitives, it is likely that each container will have its own encryption keypair, and we could use the public key as an identifier. As far as the application is concerned, all that matters is that there is a single, globally unique string which identifies the container in which it is running.

So, I suggest we store the container ID in $cid, document that fact in the specification so that applications can rely on it, and move on.

I realize that systemd expects the precise variable name $container_uuid. I don't think that's an issue, in this context systemd is the application, and if you're packaging an image running systemd, there are various ways to "translate" $cid to whatever the application expects. It doesn't seem viable for us to try to honor natively all the requirements of all the applications we might call. What if a systemd competitor expects another env variable, or if a future version of systemd changes the variable name? Will we be expected to change?

Hopefully this makes sense to everyone. It seems like a no-brainer to me.

@shykes true, but what if there were an abstraction that would allow manipulation for a $container_id. So if a UUID env is expected, then that could be accomplished?
Something like the container create/start/stop hooks we talked about?

Turns out there is more to getting systemd wired up correctly then just passing in the container_uuid. I have extended this patch to handle setting up journalling to allow journal inside the container to write messages that the journal outside of the container can see. I have to work on one more patch to setup the machine-ctl to recognise that a there is a container running. docker needs to send the UUID to docker via dbus to make this happen. Once it is fully instrumented then there would be more container information available in the HOST OS, including using machinectl, ps -o machine, journal -M machine etc.

Review session with @tiborvass @unclejack @crosbymichael

Although the PR initially started about "exposing" container ID, the requirements have changed along the way to supporting the systemd journal. We believe with this new information we should take a step back and think about the requirements to support the systemd journal with Docker containers.

We're closing the PR as it won't be merged as it is, but discussions can continue here.

This is not unexpected, since if I could not convince you to support setting an Environment Variable within an image, I doubt you would consider mounting /var/lib/journal. Sadly it leaves those of us looking to run systemd correctly within a container little options.