Add support for time namespace

[KentaTada]

The time namespace is a new kernel feature available in 5.6+ to isolate the system monotonic and boot-time clocks.

I'm sorry I mistook and closed the existing request https://github.com/opencontainers/runtime-spec/pull/1062

Signed-off-by: Kenta Tada [email protected]

[KentaTada]

monotonicNanosecs and boottimeNanosecs do not use the negative number. And I noticed that the value of offset-nanosecs is not greater than 999,999,999. So I changed those types from int64 to uint32 in this new PR.

[AkihiroSuda]

@KentaTada could you update the PR?

[KentaTada]

@AkihiroSuda @tianon I updated this pr from your comments.
If I remember correctly, Secs was required and NanoSecs was optional because of the kernel implementation.
But we changed the definition of LinuxTimeOffset from specific to generic. So, I changed Secs to optional.
I may be slow to respond, but I'll check reviews. Sorry.

[thaJeztah]

(Silly) questions;

• Do Windows containers allow for time to be namespaced? (possibly not for this proposal, but in case it's added to the Windows counterpart in future)
• As the discussion above appears to be focussing on signedness and size of integers (because we're trying to do a 1:1 mapping of the Linux kernel to the Spec), I'm wondering if we MUST follow the linux Kernel here, or if it would be beneficial to pick our own definition (does RFC3399 officially support nanoseconds and a "duration", or is there an RFC for that?).

Perhaps it's not an option, and I know many of the options were a 1:1 mapping of kernel features (out of convenience?) I also know that some of those choices made it less agnostic/portable than desired, which is why I was considering if another format would be beneficial / future proof (as long as it's not ambiguous, and documented how runtimes must interpret the config and convert it to (currently) what Linux provides).

[AkihiroSuda]

windows

I think windows is out of the scope of this PR, and windows support can be added in the config-windows.md spec separately in the future when somebody needs it.

[thaJeztah]

I think windows is out of the scope of this PR, and windows support can be added in the config-windows.md spec separately in the future when somebody needs it.

For sure! Mostly exploring if there's an platform-agnostic way to specify this configuration (and if there is, and it wouldn't be "crippling" either side, the same format could be used for Windows)

[AkihiroSuda]

@thaJeztah Can we merge this?

[AkihiroSuda]

@KentaTada Do you plan to open a PR for runc (or other runtimes)?

[KentaTada]

Hello @AkihiroSuda san

Recently, I don't have enough resources to focus on the container runtime. But @chethanah and team members are interested in implementing time namespace in runc. If it is ok to send the PR to runc instead of me, I'll ask him to take over my activity.

[KentaTada]

@chethanah san

Especially, I have no idea about the special-handling case for time namespace. For example, when it comes to IPC namespace, it affects the changeable kernel parameters(fs.mqueue.*) https://github.com/opencontainers/runc/blob/v1.1.7/libcontainer/configs/validate/validator.go#L184 So we need to investigate the properties related with time namespace at first. Could you create the new issue in runc? If it is difficult or takes a lot of time, please feel free to ask me in the issue's page.

[AkihiroSuda]

issue in runc

• https://github.com/opencontainers/runc/issues/2345

[utam0k]

👋 Hi @KentaTada @chanezon FYI: crun's implementation https://github.com/containers/crun/pull/1184