I'm a bit of confused, how would this CL address the need to set hostname while running in --net="host" mode?

To give a bit of background on why this is needed... In RancherOS we run everything in a container (go containers!). So network configuration happens in the a container using --net=host. This is all fine and dandy except the hostname. When we set the hostname it doesn't take effect on the host. Now we can obviously do some nsenter tricks and work around that but then we hit a more fundamental issue. If we use the nsenter tricks it will set the hostname on the host, but it won't propagate to other containers with --net=host because those containers have effectively copied the hostname at start time. We really need --net=host to not create a new UTS namespace.

@sunyc, oops. I totally read your issue wrong. Sorry, it doesn't address it. I'll delete that comment.

I'm not the expert here, but I think your patch makes total sense: +1.

I wonder if we should have some check in libcontainer too.
ping @mrunalp @crosbymichael

Yes, I think it makes to have a check in lib container.

Sent from my iPhone

On Apr 8, 2015, at 10:21 AM, Alexander Morozov notifications@github.com wrote:

I wonder if we should have some check in libcontainer too.
ping @mrunalp @crosbymichael

—
Reply to this email directly or view it on GitHub.

@ibuildthecloud I would rather go ahead and expand to a new --uts flag with the same settings like --uts host for this. What do you think about that? It gives you more control without this hiding behind something because it still makes sense to not do this for --net host.

@crosbymichael Is non-host UTS makes sense for host NET?

@crosbymichael I'm fine with the uts flag. I'll implement that if you think its a better approach. I guess at least that way we won't break something by changing the behavior of --net=host.

@LK4D4 I think it makes sense, hostname does not necessarily have anything related to networking, that is why they are in two different namespaces. I know it's kinda weird but we talked about this in the past because I asked the same question to others if we should drop UTS when we drop NET

@crosbymichael Cool, thanks!

Can we simply reuse the --hostname=XXX flag? smt like --hostname=host would make t use host's hostname , This also have the potential to make it possible to change hostname with --net="host" --hostname=XXXX ,

If prefer to not have magic value of hostname. If we add the uts flag, I think it would make sense to change Docker to support hostname with net host.

erk, I don't your use case for change the actual hostname but I don't that is the expected output for most other people

@crosbymichael I think @sunyc wants to be able to run with net=host but still have a different hostname for the container.

I though we decided for separate flag for UTS. As @crosbymichael said UTS namespace actually not directly related for networking.

1. add a --uts flag, when --uts=host ,drop UTS namespace.
2. allow --hostname only when --uts="container", regardless of --net=host

I think this seems to be the consensus here?

On Wed, Apr 15, 2015 at 12:06 AM, Alexander Morozov <
notifications@github.com> wrote:

I though we decided for separate flag for UTS. As @crosbymichael
https://github.com/crosbymichael said UTS namespace actually not
directly related for networking.

—
Reply to this email directly or view it on GitHub
#12185 (comment).

@sunyc I agree with your summary. I'm going to put in a PR for #1 only though. I agree #2 should be done but don't quite know the scope of that work.

If I understand correctly, a new PR will follow: I'm closing this one!