Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects

On Tue, 2019-02-19 at 19:46 -0800, James Bottomley wrote:

On Wed, 2019-02-20 at 11:04 +0800, Ian Kent wrote:

quoted

On Tue, 2019-02-19 at 18:20 -0800, James Bottomley wrote:

quoted

On Tue, 2019-02-19 at 23:06 +0000, David Howells wrote:

quoted

James Bottomley [off-list ref] wrote:

quoted

I thought we got agreement years ago that containers don't
exist in Linux as a single entity: they're currently a
collection of cgroups and namespaces some of which may and some
of which may not be local to the entity the orchestration
system thinks of as a "container".

I wasn't party to that agreement and don't feel particularly
bound by it.

That's not at all relevant, is it?  The point is we have widespread
uses of namespaces and cgroups that span containers today meaning
that a "container id" becomes a problematic concept.  What we
finally got to with the audit people was an unmodifiable label
which the orchestration system can set ... can't you just use that?

Sorry James, I fail to see how assigning an id to a collection of
objects constitutes a problem or how that could restrict the way a
container is used.

Rather than rehash the whole argument again, what's the reason you
can't use the audit label?  It seems to do what you want in a way that
doesn't cause problems.  If you can just use it there's little point
arguing over what is effectively a moot issue.

David might want to use the audit label for this, I don't know.
And maybe that's a good choice initially.

But going way off topic.

Because there is a need to not clutter kernel space with logging,
leaving it to user space to handle but also without providing user
space with sufficient information to do so there will need to be
some sort of globally unique (sub-system) identifiers of kernel
objects for which user space needs logging information so that
if or when that kernel to user space information flow is
implemented the consistent identifiers that will be needed will
at least exist for some kernel objects.

Yes, that's way off topic for this series but I think it's something
that needs at least some consideration for new implementation work.

Unfortunately properly implementing such an encoding scheme probably
warrants a completely separate project so, as you say moot wrt. this
series.

James

quoted

Isn't the only problem here the current restrictions on the way
objects need to be combined as a set and the ability to be able add
or subtract from that set.

Then again the notion of active vs. inactive might not be sufficient
to allow for the needed flexibility ...

Ian