hostname is required for new UTS namespace

[laijs]

Signed-off-by: Lai Jiangshan [email protected]

[wking]

On Mon, Dec 28, 2015 at 07:46:37PM -0800, Lai Jiangshan wrote:

• hostname is required for new UTS namespace

I'm -1 to this. “Only create a new UTS namespace if you're setting an
explicit hostname” sounds like a reasonable policy, but I doubt it's
the only reasonable policy. Maybe you're only creating a UTS
namespace to change the domain name. Or maybe you have another tool
that will be setting the hostname. So I'd rather keep this spec
policy-agnostic.

[laijs]

What's the hostname for a new UTS namespace?
For every config item, you have only two choices.

• optional, the spec should define the DEFAULT value, in most cases the default value is the value of the corresponding config item of the host or some constant value.
• required, OK, let the user set it.

It is hard for me to find a good default value for the hostname for a new UTS namespace, so I choose to mark it required. Any suggestion for the default value?

[wking]

On Mon, Dec 28, 2015 at 09:14:59PM -0800, Lai Jiangshan wrote:

What's the hostname for a new UTS namespace?

It defaults to the namespace in the host UTS namespace. For example,
say I start in UTS namespace 1 where the hostname is ‘alice’:

$ hostname
alice

On creating a new UTS namespace 2 inside namespace 1, the hostname is
still ‘alice’:

$ unshare -Uur busybox sh

hostname

alice

But we can set it to ‘bob’.

hostname bob

On creating a new UTS namespace 3 inside namespace 2, the hostname is
still ‘bob’:

unshare -u hostname

bob

For every config item, you have only two choices.

• optional, the spec should define the DEFAULT value, in most cases
  the default value is the value of the host or some constant value.
• required, OK, let the user set.

The third option (which I like best) is:

• optional, the runtime should not try and set this if the user
  doesn't specify a config value.

This lets the underlying platform default (e.g. what the Linux kernel
does) pass through without the runtime getting in the way.

[laijs]

• optional, the runtime should not try and set this if the user
  doesn't specify a config value.

it is the choice one, it is the DEFAULT value/ or default behavior. should the spec claim this default value?

[wking]

On Tue, Dec 29, 2015 at 12:36:21AM -0800, Lai Jiangshan wrote:

• optional, the runtime should not try and set this if the user
  doesn't specify a config value.

it is the choice one, it is the DEFAULT value. should the spec claim
this default value?

Sure, although I think this is general enough that we don't need to
declare it for every setting. How about patching the top of config.md
to add:

If an optional setting is unset, the runtime MUST NOT make any
system calls to apply a default value unless explicitly required to
do so by this specification.

It would probably fit in best right after the current:

The configuration file contains metadata necessary to implement
standard operations against the container. This includes the
process to run, environment variables to inject, sandboxing features
to use, etc.

For example, on Solaris the default hostname is the container ID [1,2]
while on Linux it's the host UTS namespace's hostname. So we don't
want to get into the business of defining what the platform's default
is or requiring consistency between different platforms (folks who
need consistency can set a value for ‘hostname’, etc.).

[2]: freenode's #opencontainers on 2015-12-07

[mrunalp]

I don't think that this wording is required as someone may want to continue using the hostname from the host that was assigned by default to the container.

[wking]

On Mon, Jan 04, 2016 at 03:43:34PM -0800, Mrunal Patel wrote:

I don't think that this wording is required as someone may want to
continue using the hostname from the host that was assigned by
default to the container.

+1. Although I don't see any requirements in the current spec that
the runtime leave the kernel-assigned default hostname alone, which is
why I think we want wording like 1.

[crosbymichael]

There are no requirements for settings this if you have a UTS namespace in the kernel therefore we should be impose this restriction in the spec.