Virtualizing /proc/sys/kernel/random/boot_id per container ?

[Serge Hallyn]

Quoting Glauber Costa (glommer at parallels.com):
> On 08/31/2012 05:25 PM, Serge Hallyn wrote:
> > Quoting Eric W. Biederman (ebiederm at xmission.com):
> >> "Daniel P. Berrange" <berrange at redhat.com> writes:
> >>
> >>> One of the features that SystemD folks have asked us to fix in LXC, is
> >>> to make sure that /proc/sys/kernel/random/boot_id changes each time a
> >>> container is started.
> >>
> >> There may be a good reason for this.  Most of the time what I have seen
> >> of kernel requests from the direction of SystemD is that while there may
> >> be a real problem but usually their imagined solution is not a
> >> particularly good solution.  So a description of the problem is needed.
> >>
> >> Justifying something with just SystemD wants this is a good way to get
> >> a nack.
> >>
> >>> The current semantics are that this file produces a new random UUID each
> >>> time the host OS is booted. Obviously each time we start a container now,
> >>> they just see the host's random boot_id, so from a container's POV this
> >>> does not change each time it starts.
> >>
> >> That is correct.  As I recall the contract with boot_id is to provide
> >> a unique per boot value to assist in dealing with boots etc.  I seem
> >> to recall emacs uses the combination of hostname+boot_id to help
> >> generate unique lock files names.
> >>
> >> I would definitely need a refresher on how boot_id is used in practice
> >> by applications other than SystemD before I could suggest a good design.
> >>
> >> There is also a question of uptime.
> >>
> >>> There seems to be general agreement that, aside from the PID directories,
> >>> changes to data in  proc should be done by a FUSE filesystem overlay of
> >>> some kind.
> >>
> >> No.  I have yet to see a justification for using FUSE in containers on
> >> top of proc files.
> >>
> >> I have seen a lot of bad ideas suggested like hacking /proc/cpuinfo
> >> instead of providing a proper mechanism to tell applications how
> >> parallel they can/should be.
> > 
> > Should we be talking about a new set of library functions to gather info
> > like available memory and cpus, etc?  The library functions could internally
> > take into account the per-host procfiles, cgroup info, and, as the need
> > arises, new sources of information.
> > 
> 
> I think this makes a lot of sense.

Cool.  I can't do it today, but it might be worth starting a list (on wiki?)
of information userspace wants (uptime, cpuinfo, meminfo, etc) so we can come
up with a reasonable api.

-serge