On Wed, 2019-02-20 at 11:04 +0800, Ian Kent wrote: > On Tue, 2019-02-19 at 18:20 -0800, James Bottomley wrote: > > On Tue, 2019-02-19 at 23:06 +0000, David Howells wrote: > > > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > 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. James > 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 >
