ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	ksummit-discuss@lists.linuxfoundation.org
Cc: ikent@redhat.com,
	Linux Containers <containers@lists.linux-foundation.org>,
	oleg@redhat.com
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Containerisation, namespaces and keyrings
Date: Tue, 26 Jul 2016 10:16:44 -0400	[thread overview]
Message-ID: <1469542604.4212.14.camel@HansenPartnership.com> (raw)
In-Reply-To: <6125585.ae3bRTRs05@avalon>

On Tue, 2016-07-26 at 16:38 +0300, Laurent Pinchart wrote:
> > Actually, I really think this isn't a KS issue, it should be 
> > proposed for the Plumbers Containers MC:
> > 
> > http://www.linuxplumbersconf.org/2016/ocw/events/LPC2016/tracks/519
> > 
> > You have all the correct people in that session.  At KS you'll have 
> > 50% bored, 48% hostile because they hate cgroups and 2% interested.
> 
> Virtualization is increasingly affecting more and more subsystems. 
> While I don't disagree with you, I also see value in teaching 
> maintainers about containers, namespaces and the way they affect
> subsystems.

I'm certainly not averse to that.  However, the proposal was to discuss
a really esoteric feature, namely keyring namespaces.  I'm just
pointing out that KS isn't the right audience to have that discussion.

>  We should ensure that best practices can be followed going forward, 
> and avoiding subsystems being developed in a way that will make it 
> difficult for them to be virtualized later (although one might argue 
> that we've already made a mess in several subsystems anyway). KS 
> would be a good place to spread the message as widely as possible 
> among maintainers, with Plumbers a good venue for more technical
> discussions.

Hey, give us brownie points for already avoiding the KVM/Xen mess.  We
do only have one API set that every container orchestration system (be
it docker, formerly known as rocket, lxc or openvz) uses.  However,
you're right, we should discuss some of the proliferation problems of
the APIs, however I'm still not convinced that KS would have the right
audience for that ...

James

  reply	other threads:[~2016-07-26 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-22 11:01 David Howells
2016-07-22 13:29 ` Rik van Riel
2016-07-22 14:51 ` James Bottomley
2016-07-26 13:30   ` Serge E. Hallyn
2016-07-26 13:38   ` Laurent Pinchart
2016-07-26 14:16     ` James Bottomley [this message]
2016-07-27 19:47 ` Mimi Zohar
2016-07-30 17:50 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1469542604.4212.14.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ikent@redhat.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=oleg@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox