[LSF TOPIC] block namespaces

[LSF TOPIC] block namespaces

[Hannes Reinecke]

Hi Omar,

here's a late topic for the I/O Track: Block namespaces

We already proposed it for the (canceled) LSF last year, and now I found 
that Christian Brauner is actually present here at LSF.

What this is about: Similarly to network namespaces we'd like to explore 
the possibility of block namespaces.
Canonical use-case here is iscsi sessions within containers: if one 
container starts up an iscsi session, why should this session be visible 
to the other containers?
The discussion should be about general design and possible use-cases.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

Re: [LSF TOPIC] block namespaces

[Omar Sandoval]

On Mon, May 02, 2022 at 01:14:48AM +0200, Hannes Reinecke wrote:
> Hi Omar,
> 
> here's a late topic for the I/O Track: Block namespaces
> 
> We already proposed it for the (canceled) LSF last year, and now I found
> that Christian Brauner is actually present here at LSF.
> 
> What this is about: Similarly to network namespaces we'd like to explore the
> possibility of block namespaces.
> Canonical use-case here is iscsi sessions within containers: if one
> container starts up an iscsi session, why should this session be visible to
> the other containers?
> The discussion should be about general design and possible use-cases.

Hey, Hannes,

How much does this overlap with Chris Leech's "network storage
transports managed within a container" topic?

Re: [LSF TOPIC] block namespaces

[Hannes Reinecke]

On 5/2/22 09:09, Omar Sandoval wrote:
> On Mon, May 02, 2022 at 01:14:48AM +0200, Hannes Reinecke wrote:
>> Hi Omar,
>>
>> here's a late topic for the I/O Track: Block namespaces
>>
>> We already proposed it for the (canceled) LSF last year, and now I found
>> that Christian Brauner is actually present here at LSF.
>>
>> What this is about: Similarly to network namespaces we'd like to explore the
>> possibility of block namespaces.
>> Canonical use-case here is iscsi sessions within containers: if one
>> container starts up an iscsi session, why should this session be visible to
>> the other containers?
>> The discussion should be about general design and possible use-cases.
> 
> Hey, Hannes,
> 
> How much does this overlap with Chris Leech's "network storage
> transports managed within a container" topic?

Hmm. Good question; I don't really know. But yeah, I guess there is some.
So we could lump both of them together I think.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer

Re: [LSF TOPIC] block namespaces

[Omar Sandoval]

On Mon, May 02, 2022 at 09:17:04AM -0700, Hannes Reinecke wrote:
> On 5/2/22 09:09, Omar Sandoval wrote:
> > On Mon, May 02, 2022 at 01:14:48AM +0200, Hannes Reinecke wrote:
> > > Hi Omar,
> > > 
> > > here's a late topic for the I/O Track: Block namespaces
> > > 
> > > We already proposed it for the (canceled) LSF last year, and now I found
> > > that Christian Brauner is actually present here at LSF.
> > > 
> > > What this is about: Similarly to network namespaces we'd like to explore the
> > > possibility of block namespaces.
> > > Canonical use-case here is iscsi sessions within containers: if one
> > > container starts up an iscsi session, why should this session be visible to
> > > the other containers?
> > > The discussion should be about general design and possible use-cases.
> > 
> > Hey, Hannes,
> > 
> > How much does this overlap with Chris Leech's "network storage
> > transports managed within a container" topic?
> 
> Hmm. Good question; I don't really know. But yeah, I guess there is some.
> So we could lump both of them together I think.

I added a slot for it right after Chris's topic. We can adapt based on
how much we cover in the first topic.