►
Description
Kubernetes Storage Special-Interest-Group (SIG) Namespace Transfer Design Meeting - 27 July 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
B
He
proposed
to
have
a
resource,
called
storage
transfer,
request
and
another
resource
called
storage
transfer
approval,
and
that
when
the
con
will
be
controller
like
will
detect
this
two
resources
exist
and
there
will
be
open
certain
condition
matching.
Then
we
initiate
the
transfer
and
then
after
the
transfer
is
done,
the
source
pvc
will
be
deleted
and
the
target
ppc
will
be
created
and
will
be
updated
to
the
tv.
B
B
Also
followed
the
same
approach
as
mike
and
erickson,
but
also
in
the
cab.
There
was
a
comment
by
masaki.
He
actually
created
a
poc
which
will
edit
the
pvc
itself
the
entry
and
he
added
we
will
add
certain
field
to
the
spec
of
the
pvc
and
also
condition
types,
and
he
also
had
the
diagram
showing
how
this
interaction
will
happen.
B
B
B
C
C
B
B
D
So
this
was
just
so
what
I've
done
so
far,
so
in
the
way
I've
implemented
it
now
is
with
this
cluster
scope
resource
with
the
idea
being
that
there
will
be
a
namespace
scope,
api
built
on
top.
That
will
do
the
matching
and
when
the
matching
happens,
it
will
kick
off
one
of
the
cluster
scopes
resources
to
do
the
actual
transfer.
So
this
is
also,
I
guess,
another
option
for
cluster
admins
to
more
easily
do
a
transfer.
E
F
B
Okay,
so
this
is
the
resource,
the
crd,
it's
a
first
scope
resource
and
there
is
implementation
here
for
qbert
and
again
so
we
have
phases
and
in
each
phase
we
have
a
specific
state
for
the
pvc
and
opens
this.
We
update
like
respects
in
the
pvcs
on
big
decisions
even
to
like
delete
the
source,
pvc
transfers,
the
pv
to
the
new
pvc
and
so
on.
B
There
is
various
conditions
because
we
have,
I
think,
cluster
scope,
a
resource
and
also
there
is
a
problem
that,
if
yeah,
even
so,
we
can
wait
for
for
all
the
consuming
parts
that
they
are
terminated
before
we
do.
The
transfer
a
pod
in
creation.
Time
could
not
be
aware
of
that
and
could
have
a
problem
that
it's
referring
a
pvc
which
will
be
deleted
or
when
it
is
deleted
yeah.
So
far,
these
are
the
notes
that
I
have
gathered
and
I'm
opening
this
for
discussion
for
everyone.
D
Yes,
so
just
to
reiterate
this,
this
api
we're
using
it
in
keyboard
internally,
but
for
like
a
more
user-focused
thing,
we
are
going
to
be
planning
to
build
a
namespace
scoped
api
on
top
of
this.
So
I
don't
know
if
that's
an
approach
community
would
be
interested
in
as
well,
including
in
the
new
cap.
A
D
Yeah,
the
one
that
I've
implemented
yeah,
the
one
that
I've
implemented
is
cluster
scoped.
Okay,
the
the
cap
is
for
name
space
scoped
and
as
kind
of
an
implementation
detail,
I
was
thinking
the
name.
Space
scoped
would
be
implemented
by
having
a
controller
that
simply
does
the
matching
and
then
once
the
matching
is
done
for
request
and
approval
creates
internally
an
object
transfer
that
does
the
actual
transfer.
A
D
D
D
A
D
A
A
D
A
A
B
B
F
F
C
I
thought
that
was
the
principle
behind,
like
all
you
have
are
two
names
based
objects,
and
then
you
know
like
alice
and
bob
want
to
trade.
A
volume
so
alice
creates
a
cr.
Bob
creates
a
cr
and
it
moves
from
alice's
namespace
to
bob's
namespace,
and
they
don't
need
any
administrator
to
get
involved.
As
long
as
the
two
of
them
agree.
F
C
C
Anything
the
idea
is
the
guy
who
currently
has
access
to.
It
has
to
agree
to
give
it
to
someone
else
and
the
the
main
reason
that
we
want
the
recipient
to
also
create
something
is
to
prevent
giving
of
unwanted
volumes
right.
If
I
spam
you
with
100
volumes
that
you
don't
want,
you
don't
want
to
have
to
deal
with
that
so
requiring
both
the
current
owner
and
the
new
owner
to
participate,
addresses
that
problem.
F
C
C
F
C
A
C
F
C
So
it
seems
like
you
want
to
do
something
that
involves
either
creating
new
secrets
or
copying
secrets
or
moving
the
secrets
or
or
something
to
the
destination
name
space
or
or
you
require
that
that's
arranged
out
of
band
right.
You
could
just
explicitly
say:
look
if
you
don't.
If
you
have
secrets-
and
you
don't
do
something
it,
this
will
break,
and
so
you
have
to
do
something
like
that
might
not
be
friendly,
but
it
will
at
least
be
correct.
H
H
C
H
H
A
C
Yeah
yeah,
I
mean
there's
a
security
threat
that
needs
to
be
analyzed
under
underneath
all
of
this,
but
just
from
a
basic
correctness,
point
of
view,
we
have
to
have
a
stance
on
like.
Are
we
copying
secrets?
Are
we
moving
secrets?
Are
we
leaving
this
as
an
exercise
for
the
admin?
Are
we
leaving
this
as
an
exercise
for
the
users
like
who's,
whose
job
is
it
to
get
the
secrets
to
the
other
side?.
H
C
I
think
that
the
the
user
creates
them
in
the
current
model.
Like
the
in
your
storage
class,
you
can
specify
a
name
or
a
name
pattern
in
the
storage
class
and
that
will
get
stamped
on
the
pvs,
but
then
kubernetes
only
ever
reads
the
secrets
that
already
exist,
and
I,
if
I'm
not
mistaken,
I
think
portworx
is
the
heaviest
user
of
this
feature
right.
G
G
C
So
I
I
like
the
idea
of
it
of
the
pvc
ending
up
so
that
it
still
is
correct
based
on
like
how
it
would
have
looked
if
it
had
been
created
in
the
other
name
space.
As
far
as
secrets
are
concerned,
I
do
worry
a
little
bit
about,
depending
on
the
storage
class,
because
the
storage
class
can
change
or
get
deleted
after
the
volume
is
created.
C
C
To
believe
that
the
definition
of
the
secrets
in
the
storage
class
now
is
still
accurate,
yeah
and
you
have
you
have
to
go
based
on
what
the
storage,
what
storage
class
looked
like
at
the
time
that
the
volume
was
created,
because
that's
how
the
secrets
were
stamped
on
that
particular
volume,
but
you
could
still
figure
that
out.
I
think
I
hope
yeah,
because.
I
C
Okay,
well
that
that's
worth
thinking
through,
but
yeah
yeah.
So
so,
if
the
presumptions
going
to
mutate
the
pv,
so
it
points
to
secrets
that
look
like
as
if
the
pv
was
created
in
the
new
namespace,
where
it
now
lives,
then
yeah.
You
know
any
sort
of
templatized
secrets
that
point
back
to
the
original
namespace
have
to
be
updated,
and
then
it's
just
a
question
of
who
copies
them
or
who
moves
them
to
the
new
name.
Space.
F
G
C
Right,
but
if
you
have
like
alice,
who
has
a
volume
that
she
wants
to
give
to
bob
and
the
volume
is
encrypted
with
alice's
key,
which
is
in
a
secret
in
alice's
namespace
and
now
she's
handing
the
volume
to
bob
like
either.
You
have
to
re-encrypt
the
whole
volume
with
bob's
key,
which
is
something
that
this
controller
can't
do
or
alice
needs
to
give
a
copy
of
her
key
to
bob
so
that
he
can
read
the
volume.
C
C
C
D
F
That's
true
what
I'm
trying
to
say
is
that
this
is
kind
of
where
the
admin
needs
to
step
in,
because
the
storage
class
is
only
editable
about
the
admin.
So
if
the
storage
class
says
that
the
secret
for
this
pvc
is
in
the
namespace
of
the
pvc
right,
then
there
needs
to
be
some
coordination
if
the
the
secret
needs
to
be
moved
in
first,
so
I
think
that's
an
out-of-band.
I
think
that's
outside
the
scope
of
this
part.
As
I'm
trying
to
say.
F
Yes,
I
I
don't
disagree
with
that.
I'm
trying
to
say
that
I
feel
it's
outside
the
scope.
I
think
there's
a
new.
What
we're
trying
to
say
is
that
there's
a
new
requirement
that
this
will
require
for
secrets
to
also
be
transferred
to
a
new
namespace,
and
I
just
think
that,
outside
the
scope
of
this
pvc
thing
because
pvc,
it's
like
it,
doesn't
really
care
if
the
secrets
there
or
not,
it's
just
pointing
right,
it's
a
reference,
but
I
don't
think
it
should
be
this
group's
resolution.
B
G
I
C
You
don't
always
want
to
move
it.
Sometimes
you
want
to
copy
it
like,
like
pvcs,
you
don't
want
to
copy,
because
that's
going
to
cause
problems
most
likely
secrets,
you
may
want
to
leave
the
old
one
behind
and
make
a
new
one.
That's
a
copy
in
the
new
name
space.
If,
if
the
users
agree
to
share
the
secret.
I
F
C
F
D
F
F
F
C
B
C
Well,
we
still
have
to
decide
what
we,
what
exactly
we
do
to
the
pv
or
we.
We
can
say
that
you
know
you
got
to
get
the
secrets
over
there,
but
we're
going
to
point
the
new,
the
newly
rebound
pv
at
a
secret
in
the
new
namespace,
which
may
or
may
not
be
there
or
we
can
say
we're
not
going
to
do
anything
and
it's
going
to
continue
to
point
at
the
old
namespaces
secret,
which
will
cause
a
different
problem.
Oh.
F
F
F
D
F
C
I
C
I
F
C
F
C
C
D
C
D
G
C
But
we
always
get
in
trouble
anytime.
We
try
to
look
at
the
storage
class
for
existing
volumes
because
it
always
leads
to
corner
cases.
We
had
this
problem
with
resize,
where
we
had
some
pointer
to
like
allow
volume,
resizing
the
storage
class
and
and
then
when
the
resize
controller
was
asking.
If
it
was
okay
to
resize
the
volume,
it
would
go,
look
up
the
storage
class
at
that
time
and
most
of
the
time
it
worked,
but
sometimes
it
didn't
work,
and
so
we
decided
to
copy
that
field
into
the
pv.
I
E
H
A
D
In
the
controller
that
I
wrote,
there's
a
kind
of,
if
you
look
at
the
kind
of
phases
that
I
wrote
in
the
pending
phase,
you're
kind
of
waiting
for
a
bunch
of
things,
you're
waiting
for
you-
know
no
pods
using
the
pvc
and
as
well
as
waiting
for.
I
think
there
are
a
couple
annotations
that
we
wait,
that
aren't
that
don't
exist
in
the
pvc
they're
like
the
cloning
protection
and
pvc
is
source
protection.
So
we
just
wait
for
them
not
to
exist,
of
course,
their
timing
conditions,
but.
C
But
with
regard
to
the
snapshotting,
I
think,
if,
if
the
snapshot
object
is
created
and
if
the
snapshot
controller
gets
through
the
process
of
creating
a
volume,
snapshot,
content
object
that
points
to
the
pv.
At
that
point,
it
no
longer
matters
if
the
pvc
exists,
because
the
snapshotter
has
all
the
information
it
needs
to
finish,
creating
that
snapshot
in
the
original
namespace,
and
so
as
long
as
it
gets
to
that
point
before
the
transfer
completes,
then
the
snapshot
can
run
in
parallel
with
the
transfer
and
nothing
bad
will
happen.
E
C
Well,
yeah
yeah,
I
mean
if,
if,
if
you
create
the
volume
snapshot
object
and
before
the
snapshot,
controller
can
can
take
a
look
at
it
and
create
a
volume
snapshot
content
the
transfer
successfully
executes,
then
you'll
just
get
an
error
from
the
volume
snapshot
controller.
Saying
like
what
pvc
are
you
talking
about.
You
know
it's
not
here
it's
gone
and
and
that's
fine
right
as
you
just
lost
the
race.
H
C
C
C
G
C
C
C
C
C
F
E
C
E
H
C
Copying
yeah
transferring
snapshots
is
a
heck
of
a
lot
safer
but
you're
going
to
get
complaints
from
people
who
have
drivers
that
don't
support
snapshots
and
they
just
want
to
transfer
the
pcs
directly
right.
That's
because
if
everyone
supported
snapshots
across
the
board,
then
yeah
you
could
say,
look
we
only
support
transferring
snapshots
and
just
clone
the
snapshot
when
it
gets
to
the
other
side.
F
F
C
F
One,
what
I'm
trying
to
say
is
that
when
we
hear
that
use
case,
then
we'll
start
that
enhancement.
I
I
keep
trying
to
reduce
the
scope
of
this
project.
Yeah
yeah
yeah,
so
I'm
trying
to
say
look
guys,
forget
secrets,
forget,
keep
it
simple
snap.
The
volume
create
a
volume,
carry
clone
in
the
other
side
and
call
it
a
day
right.
H
C
F
C
C
C
C
C
H
The
data
that
you're,
let's
say
transferring
is
in
a
stable
and
consistent
state,
whereas
you
know
like,
I
think
what
christian
said
like
he
currently
requires.
You
know:
paul's
using
the
pvcs
in
the
source
name,
space
to
get
tear
down
so
nobody's
using
those
paws,
and
then
the
transfer
happens.
So
there's
some
element
of
coordination
here
in
between
source
and
destination
name
spaces,
whereas
with
snapshots
you
don't
even
have
that
you
don't
even
require
that
coordination.
A
D
Yeah,
so
I
I
always
thought
that
snapshots
were
a
good
good
use
case
so
totally,
but
I'm
just
wondering
if
we
can,
even
in
transferring
pvcs
use
them
internally.
So
we
would
snapshot
the
pvc
in
the
source
and
then
delete
it
and
then
transfer
and
create
like
we.
I
think
we
could
do
a
lot
of
the
orchestration.
Maybe
in
the
controller,
that's
true
of
the
transfer.
D
I
D
F
But
I
mean,
I
think,
what
we're
trying
to
say
is
that
if
the
infrastructure
supports
this,
then
what
the
user
is
really
trying
to
do
is
not
to
transfer
a
volume.
What
the
user
is
really
trying
to
do
is
to
transmit
an
app
right,
so
we
just
can
make
that
happen
easily
through
some
cr.
Just
like
we're
doing
here,
we
take
care
of
that
process.
I'm
trying
to
say.
A
D
F
C
I
mean
today,
if
you
have
admin
privileges,
you
can
manually
move
a
snapshot
across
namespaces
by
mucking
with
the
retention
policy.
Deleting
the
volume
snapshot
object,
creating
a
new
volume
snapshot,
object,
rebinding
it
and
all
that,
and
then
now
you
have
a
volume
snapshot
in
the
new
namespace
that
you
can
go
ahead
and
clone
like
that's
possible
to
do
manually
today.
F
A
A
A
A
Yeah
we
need
to.
We
need
to
have
a
follow-up,
I
think
so.
Okay,
so
it
looks
like
now.
We
are
okay.
So
now
we
are,
we
are
looking
at
whether
to
just
to
allow
transfer
volume
snapshot.
So
maybe
we
just
we
need
to
have
a
follow-up
meeting
to
continue
that
discussion
and
mustafa.
Are
you?
Are
you,
okay
with
that?
Maybe
just
yeah.