►
Description
Kubernetes Data Protection WG Bi-Weekly Meeting - 23 March 2022
Meeting Notes/Agenda: -
Find out more about the WG here: https://github.com/kubernetes/community/tree/master/wg-data-protection
Moderator: Xing Yang (VMware)
A
B
A
B
I
can
share
my
screen,
but
there's
not
much,
except
for
the
document
that
we've
already
been
seeing.
So
you
see
my
screen
now
yeah,
so
we
discussed
most
about
cbt.
Discussion
is
either
on
slack
or
in
our
private
meetings
with
a
few
engineers,
and
we
captured
all
of
the
meeting
minutes
on
the
document
that
you
can
see.
B
B
So
after
discuss
with
the
the
engineer
involved,
we
like
say:
let's,
let's
give
it
a
try
to
see
how
it
go.
You
know,
let's
discuss
to
see
if
we
can
find
a
way
to
overcome
the
limitation
of
the
cid
approach.
The
limitation
that
we
try
to
overcome
is
that
they
see
the
size
of
the
c
arctic.
The
the
size
of
the
cr
on
the
kubernetes
api
server
would
eventually
you
know,
hogging
the
resort
there,
especially
if
we
create
a
cr
and
it
will
be
stored
in
the
xcd.
B
If
that
is
the
case,
then
it
will
eventually
run
out
of
spay
or
hogging
the
the
resort
there.
So
we
discussed
about
a
few
idea
that
to
overcome
that-
and
one
of
the
way
that
we
can
we
talk
about-
is
the
aggravation
api
aggravation
a
lot
of
this?
Still,
we
still
in
you
know,
exploring
we
still
haven't
have
any
conclusion
yet
so
we're
just
still
researching
and
there's
a
few
engineers
proposing.
B
B
B
We
think
that
we
should
do
like
a
prototype
and
just
just
try
to
rough
out
all
the
the
idea
to
see
if
it
actually
work
this
way
or
not,
and
this
proposal
that
I
put
here
is
we're
going
to
try
to
do
like
a
cle
approach.
That
means
that
we
want
to
create
us.
It's
similar
to
you
know
any
customer
resource
yeah.
We
we
create
like
a
cid
with
respect.
The
spec
is,
basically
we
don't.
We
simply
sit
for
this.
B
You
know
a
little
bit
here
and
there's
like
state
and
error
to
see
how
it
go
and
if
this
one
we,
if
we
create
this
one,
then
we
should
create,
like
a
controller,
to
listen
to
that
event
right.
So
the
controller
simply
when
this
event,
when
this
cr
is
object,
is
created
on
the
api
server,
then
this
controller
will
simply
listen
to
it
and
call
the
you
know
we're
going
to
pick
one
of
the
storage,
maybe
powerstor
emc
or
aws
or
vmware
ebs
right.
B
We
whoever
implement
this,
will
be
we'll
pick
one
right
and
what
we
do
is
when
we
receive
that
cr
object
like
if
it
is
created,
then
we
will
call
the
different
snapshot
api
or
the
of
the
specific
stories
that
that
we
have
at
hand.
Then
we
gonna
translate
the
result
into
the
format
that
we
want
here
and
responded
to
I
mean
and
whoever
listened
to
create
this
c
object
will
wrap
the
response
right
so
that.
B
B
Yeah,
okay,
yeah,
so
so,
and
then
we
also
proposing
to
create,
like
a
backup
controller,
to
employ
this.
This
whole
workflow
here
right,
so
it
will
create
the
cr.
It
will
wait
for
the
controller
to
you
know,
update
the
status
and
it's
it's
backing
up
the
data
according
to
the
result.
So
that's
the
high
level
of
the
backup
controller,
the
detail
I
put
it
here,
but
again
we
still
in
you
know
we're
still
in
in
discussion.
B
B
So
that
way
we
can
employ
the
the
cbt
right,
the
the
chain,
blockchain
chain,
block
tracking
right,
the
the
difference
or
snapshot
for
block
right
without
the
volume
in
the
back
end.
For
example,
if
this
a
like
an
file
system,
pvc
with
the
nfs
in
the
back
end,
then
we
cannot
do
anything.
So
we
only
focus
on
the
file
system.
B
Pvc
with
the
block
backend
right,
so
that
is
my
update
for
for
the
you
know,
for
the
cbt
thing
for
the
cbt
effort
that
we
have
again,
we
communicate
with
each
other
on
slack
on
this
w
g
data
protections
channel.
So
if
anyone
who
are
interested
in
the
project
or
want
to
contribute
just
jump
in
and
discuss
there,
we,
I
will
try
to
schedule
a
meeting
every
week,
usually
on
friday.
B
A
A
D
B
A
B
B
B
A
B
All
we
have
to
implement
one,
it
should
be
simple:
it
just
should
be
copy
block
into
a
back-end
into
a
backup
story:
okay
and
then
now
with
the
cbt
right
at
this
point,
we're
going
to
create
an
object,
a
cr
object
with
this
format
here
right.
If
we
have,
if
we
already
have
a
previous
snapshot
right,
we're
going
to
specify
the
snapshot
base
here
and
the
current
snapshot
and
volume
id
and
so
on
and
so
forth
and
start
offset
will
be
0
and
and
so
on
and
so
forth.
B
B
B
B
B
B
Prototype
a
little
bit,
it
only
illustrates
that
it
can
be
done.
It's
not
essential
to
the
the,
because
the
thing
that
essentially
this
one
right
is
that
this
controller
and
and
this
and
the
crd
here
you
see
the
main
piece.
This
one
is
just
an
effort
to
tie
together
a
workflow
that
illustrates
that
this
cbt
can
be
done.
Okay,.
B
D
B
B
B
B
A
B
E
B
A
E
No
idea
yet,
okay,
so
we
haven't
flushed
it
out
fully,
but
the
concept
you
were
having
was
to
take
the
change
block
list
out
of
the
status
and
instead
have
more
like
a
cookie
that
points
to
a
set
of
change,
block
resources
and
those
change
block.
Resources
would
be
provided
by
the
aggregated
api
server
and
pretty
much
generated
on
demand
by
calling
csi,
if
that
makes
any
sense,
so,
okay
and
then
the
advantage
of
that
we
haven't,
we
haven't
actually
figured
out
exactly
how
to
do
it
yet.
E
But
the
general
concept
is
that
then
pagination
is
just
handled
by
the
kubernetes
pagination
api
for
for
iterating,
over
lists
of
objects,
and
and
so
then
it
becomes
a
little
it's.
It's
not
quite
so
imperative
that
the
api
looks
less
imperative
driven
and
we
should
be
able
to
take
all
of
that
stuff
out
of
the
fcd,
but
it's
still
accessible
via
the
regular
kubernetes
apis.
E
A
F
D
B
B
Right
here
this
this
context,
we
don't
know
how
many
by
that
one
that's
contact
is,
is
a
vendor
specific,
but
if
we
just
take
the
size
of
the
obsessed
and
the
size
of
the
you
know
the
the
size
and
the
boo
and
the
zero
and
and
this
field
then
approximately
for
each
cr
we
can
contain
98
000
metadata
block,
which
is,
I
think,
would
be
very
substantial.
I
mean
for
for
the
difference
between
two
volume.
B
If
we
can
capture
that
98
000
and
besides
I
mean,
if
there's
a
lot
more
than
that,
then
it
might
be
just
better
just
you
know
to
back
up
the
whole
volume
right
and-
and
so
that's
why
that's
just
some
data
that
I
have
here
and
I've
done
some
calculation
too,
like
if
the
block
size
is
very
small
like
512,
then
it's
not
much
right.
It's
98!
B
It's
just
about
48
megabytes,
it's
not
really
impressive,
but
if,
if
the
block
is
big
like
2
megabyte
block,
then
this
one
can
the
metadata
that
can
describe
192
gigabyte
right.
On
top
of
that
dave
also
mentioned
many
ways
we
can
combine.
For
example,
if
subsequent
I
mean
the
the
block
that
lie
next
to
each
other,
we
can
combine
them
into
one
block
right.
D
Yeah,
I
think
the
fact
that
the
responses
are
you
know,
unbounded
in
sizes,
that
definitely
worrisomes
and
concerning
and
enhancing
you
know
we're
putting
a
lot
of
thoughts
into
how
to
mitigate
that,
and
you
know
I
wish
like
there
is
a
cookie
cutter
way
to
say:
oh,
you
know
you
know
implement
it.
You
know
all
will
be
fixed
right,
so
it
feels
like
they
have
to
be
multiple
approaches
to
it.
I
read
somewhere
that
I
mean
like
I
guess.
D
D
You
know
stuff
like
that,
and
if
we
really
have
to
store
it,
then
I
think
someone's
making
suggestions
about
like
some
sort
of
garbage,
auto
garbage
collection
mechanism
somewhere
in
this
slab
channel.
So
I
think
the
way
I
look
at
it
is
there'll
be
multiple
approaches
and
things
need
to
be
implemented
to
mitigate.
B
B
D
F
Yeah
well,
one
of
the
reasons
why
I
was
bringing
that
question
up
is
even
if
we
use
aggregated
api
server,
that
api
server
needs
an
lcd
to
back
whatever
we
are
posting
there
right.
So
I
was
wondering
if
we
are
just
moving
the
problem
space
of
putting
it
in
a
cluster
lcd
to
putting
it
in
a
different
lcd
which
is
solved
by
the
aggregated
api
server.
D
Yeah,
I
mean
that's
definitely
a
good
point
right
but,
like
I
guess,
with
the
reason
with
aggregated
api
custom,
api
server
is
because
we
have
control
over
that
front.
You
know
if
we
look
at
the
matrix
server.
If
we
look
at
some
of
the
service
master
solutions
out
there,
they
have
aggregated
api
server
that
don't
necessarily
store
things
into
scd
as
they
work
with
and
handle
and
manipulate
the
the
resources
objects
there.
D
So
I
mean
like
kind
of
going
back
to
what
they
were
saying
earlier.
They
might
become
a
more
you
know
like
the
balance
between
a
declarative
versus
an
imperative
kind
of
invocation
method,
yeah,
but
yeah.
I
think
that
definitely
agreed
against
someone
up
there
that
don't
really
don't
store
everything
in
general.
But
yes,
std
will
be
a
core
thing
in
there,
even
with
like
a
custom
api
server.
This
kind
of
what
does
sdk
is
gonna.
Ask
you
when
you
write
the
go
code,
it
was
gonna.
E
Well
hold
on
hold
on
so
so
for
the
aggregated
api
server
backing
like
the
change
block
list
it.
Wouldn't
it
doesn't
need
to
to
store
a
copy
of
it.
It
can
go
to
the
csi
driver
and
just
ask
for
things
on
demand,
and
that
was,
I
think,
what
we
were
thinking
of
doing
so
it
wouldn't
actually
read
at
all
store
it
someplace
and
then
serve
it
it
just
whenever
it
gets
requests
for
certain
types
of
change
blocks.
It
goes
and
asks
the
csi
driver
for
them
using
the
api.
That's
defined.
D
You
know
like
we,
we
can
talk
about
it
when
we
get
third
but
like
of
the
api
server
like
library,
like
they're
gonna
ask
for
references
to
std
whether
you
use
it
or
not.
It's
a
different
thing,
but
it's
part
of
the
setup
and
bringing
bootstrapping
the
api
server
is
gonna.
Ask
you
for
like
a
cd
path.
E
D
A
A
B
B
A
Okay,
so
I
just
want
to
show
this
one
quickly,
so
this
one
it's
ready,
if
you
guys
want
to
take
a
look
and
provide
feedback,
and
then
we
will
submit
a
pr
to
get
us
merged,
basically
just
to
talk
about
what
we
did
last
year
right.
So
we
have
the
you
know
the
white
paper
and
caps
and
the
work
that
are
not
in
a
caveat.
You
know
we
have
cbd.
A
Okay,
so
now
we
have
there's
a
question
here
from
anja
now:
do
you
understand
the
highlight?
What
is
status
container
notify
cap
so
that
one
yeah
so
shanty,
and
I
need
to
talk
about
it
and
then
see
how
we
address
those
comments,
because
we
thought
we
have
addressed
those,
but
then
I,
but
definitely
there
are
reviewers
who
still
think
there
are
concerns
that
are
not
addressed.
So
we
just
need
to
go
back
to
that
and
think
about
how
to
address
those
comments.
Those
are
not
straightforward.
A
A
I
also
want
to
I.
I
also
want
to
ask
you,
so
I
know
that
we
we
do
that
because
we
want
to
be
able
to
request
the
application.
This
is
from
our
point
of
view.
Is
there
any
other
use
case
so
so,
for
example,
right
now
right?
That
is,
of
course,
a
better
solution.
It's
more
like
kubernetes
native
is
more
secure.
A
G
D
G
A
A
A
Yeah
just
really
just
need
to
think
about
how
to
address
those,
because
you
know
we
thought
it's
a
dress,
but
it's
maybe
it's
not
right.
So
there's
still
some
things
that
we
need
to
put
out.
Yeah
they're.
Also,
there's
also
there's
an
api
review
question
that
I'm
still
trying
to
figure
out
how
to
how
to
address
that
so
yeah.
So
that's
why
yeah,
but
we
will
get
back
to
that.
A
A
E
A
Here
fix
one
thing
but
break
something
else
so
now,
for
so
normally
we
do
release
after
every
kubernetes
release
so
like
after
1.24
release,
we
normally
like
a
few
weeks
after
that
we
will
be
doing
a
snapshot
of
release,
so
that
will
be.
When
is
that
what's
the
ga
date
for
is,
that
is
that
I
think
the
19th
of
april
right
so
probably.
A
A
G
A
A
D
C
G
A
G
E
A
G
A
What
makes
sense
to
cut
a
release
for
all
the
stable
branches,
but
like
for
the
food
that,
oh,
I
think
we
we
just
recently
cut
a
patch
release,
but
but
I'll
see
so,
okay
yeah.
Maybe
it
still
makes
sense
right.
So
if
we
want
to
release
this
on
5.0,
maybe
it
also
makes
sense
to
release
this
on
5.x,
okay,
I'll
I'll,
see.