►
Description
Kubernetes Data Protection WG Bi-Weekly Meeting - 01 June 2022
Meeting Notes/Agenda: -
Find out more about the DP WG here: https://github.com/kubernetes/community/tree/master/wg-data-protection
Moderator: Xing Yang (VMware)
A
A
So
today
we
have
a
main
topic
which
is
about
the
cpt,
so
fun
and
others
who
have
been
working
on
the
cbd
project
will
be
giving
an
update.
A
C
So
can
you
see
my
screen
now?
Yes,
yep?
Okay,
so
this
is
like
a
community
project
that
we've
been
working
on
it
for
a
while
and
recently
I
banned
me
and
preset-
and
now
a
few
more
sean
also
worked
actively
on
this.
C
So
we
we
presented
to
the
community
sync
up
in
about
in
last
week
and
we
got
some
feedback
today.
I
will
share
with
you
all
all
the
feedback
and
all
the
the
current
status
of
it,
but
I
also
want
to
walk
through
a
little
bit,
so
everybody
who
did
not
attend
that
meeting
would
have
some
background
of
what
going
on.
So.
For
this
we
proposed
a
capped
for
different
source
snapshot
cap.
I
I
put
a
link
on
our
meeting
document
here.
C
We
did
have
we
have
a
link
here,
and
so
this
is
the
document
that
the
cap
that
we
are
proposing
and
this
cap
have
two
main
parts.
One
of
them
is
the
the
enhancement
to
csi's
interface
that
we
want
to
introduce
and
that
one
this
over
here.
C
So
this
one
is
the
differential
snapshot
service
that
the
enhancement
to
the
csi,
that,
if
a
vendor
who
want
to
support
this
csi
enhancement,
they
can
implement
this
service
here
and
they
can
add
this
into
their
csi
driver
package,
and
it
will
go
to
support
this.
C
So
this
one,
the
feedback
on
on
this
one,
we
don't
receive
any
negative
feedback
on
this
csi
enhancement,
so
the
the
other
part,
which
is
the
the
enhancement
to
I
mean
the
the
the
crd,
which
is
how
we
use
this
for
how
this
user
would
view
this
differential
snapshot,
csi
is
receiving.
Have
we
see
some
feedback
and
we
need
to
address
those
feedback.
I
think
there's
some
critical
feedback
from,
I
think
from
ben
and
then
another
one
from
seth
that
asked
us
to
reconsider
many.
C
You
know
a
main
component
in
our
path,
so
let
me
walk
through
the
design
quickly.
First
and
then
I
will
introduce
what
then
and
sad
has
feedback
to
us
and
and
then
ivan
will
help
me
share
what
we
have
done
to
address
this.
So
by
the
way
this
is.
I
also
put
the
link
that
ivan
is
proposing
to
addressing
feedback
from
then
here
so
in
later.
If
I
run
out
of
time,
he
can
you
guys,
can
just
look
into
the
document
and
know
what's
going
on.
C
So,
let's,
let's
walk
to
a
quickly
walk
through
the
the
proposal
that
we
propose
for
this
one
first.
So
when
the
user
want
to
get
the
differential
snapshot
between
two
pre-existing
snapshots,
let's
just
say
the
user
like
a
backup
client
right,
like
backup
vendor,
create
a
volume
snapshot,
one
of
the
pvc
and
then
later
he
created
a
volume
snapshot.
Two
of
the
pvc
ring
hit
backup
procedure,
and
now
he
wants
to
make
a
different
snapshot
of
this.
C
We
would
then
have
our
csi
snapshot
sidecar,
the
blue
box,
that
you
guys
seen
here
this
will
watching
watch
for
this
cr
and
when
you
see
that
he
created
what
it
does,
it
will
make
a
grpc
call
to
the
corresponding
driver
in
this
case.
In
this
example,
we
here
here
is
the
the
ebs,
the
amazon
ebs.
We
put
it
in
our
demo
to
as
an
example
of
how
this
one
will
be
called.
C
So
the
csi
snapshot
controller
here
will
make
a
grpc
call
to
the
ebs
plugin
and
the
corresponding
will
talk
to
the
ebs
to
make
the
shipping,
so
snapshot
internally
is
using
the
lead
chain
block,
but
for
this
from
this
architecture,
this
the
whole
thing
from
here
from
this
ebs
plugin
should
be
implementing
by
the
csi
distorted
vendor
right
this
part,
the
csi
snapshot
is
implemented
by
the
community,
and
this
software
part
is
the
the
backup
software
is
a
backup
vendor
right.
C
C
We
will
stop
into
this
cr
and
then
the
backup
vendor
the
backup
software
client
here
will
get
this
chain
block
list
from
this
cr
and
you
know,
proceed
with
their
differential
snapshot,
and
that
is
the
critical
point,
because
we
put
everything
in
this
cr
object
and
it
can
be,
it
can
be
large
and
we
did
some.
C
We
have
some
design
to
try
to
mitigate
the
amount
of
data
that
is
being
stored
on
the
on
this
object,
but
it
still
have
a
negative
impact
on
the
I
o
of
the
scd,
and
that
is
what
I
think
then
and
sat
is
concerned,
is
that
their
main
point
is
that
the
scd
is
not
designed
for
high,
I
o
and-
and
for
I
o
a
lot
of
I
o
here,
and
we
can
see
that
you
know
each
of
the
chain
block.
Can
I
mean
it's?
C
Each
of
these
cr
can
can
contain
a
lot
of
chain
block
and
it
will
create
some.
I
o
pressure
on
this
lcd,
and
that
is
the
negative
poi
that
we
got
from
this
cr
and
I
think
ben
have
made
some
suggestions
into
the
alternative
design.
I
have
captured
it
here
in
this
document
about
the
the
next
alternative
that
out
in
the
desire
that
that
we
we
got
from
the
meeting
with
the
community
last
week
and
after
that,
we
we
sit
back
together.
C
We
sit
down
together
and
we
look
into
what
we
can
do
to
address
this
one,
and
we
can.
We
need
to
have
some
discuss
and
after
that
I
then
have
proposing
a
new
design.
The
remember
that
the
the
design
that
we
proposed
it
do
not
change
the
csi
enhancement
that
we
propose.
It
does
not
change
this
this
this
part
right
here.
It's
only
pa.
It's
only
changed
the
first
part,
which
is
the
how
you
know
how
the
how
we
view
this,
this
differential
snapshot
in
the
kubernetes.
C
So
with
that,
I
want
to
pass
to
to
event
for
to
talk
about
the
new
design
enhancement
design
that
we're
proposing
ivan.
You
want
to
share
your
screen.
D
Okay,
cool,
oh
sorry,
my
my
voice
might
sound
a
bit
different
today,
I'm
like
a
bit
under
the
weather,
but
I
still
assure
you
that
I'm
ivan
I'm
not
some
like
random
stranger
yeah,
so
like
following,
like
the
feedback
we
got
from
during
the
csi
community
meeting
like
we
got
together
and
tried
to
address
some
of
the
concerns,
and
the
first
thing
that
we
talked
about
is:
let's
come
up
with
a
proper
name,
for
you
know
like
the
api
and
this
crm
and
stuff.
D
So
what
you're
seeing
here
is
like
the
proposed,
like
rename
crd
originally
like
it
used
to
be
something
called
like
get
change
blocks,
and
then
you
get
to
get
change
boxes
and
get
change
blocks
list
type
of
thing
so
decided
to
get
rid
of
that
get
prefix
and
call
it
differential
snapshot.
D
Full
disclosure,
like
a
lot
of
this,
is
inspired
by
like
the
existing
pvc
and
design
and
that
relationship
between
pvc
and
the
volume
snapshot
design.
So
you
borrow
quite
a
bit
of
inspiration
from
it.
D
If
anything,
you
see
here
that
totally
makes
no
sense
or
it's
oh,
don't
go
there
type
of
thing
just
feel
free
to
voice
it
up,
and
we
truly
truly
appreciate
those
kind
of
feedback,
because
that's
how
we
know
like
that,
we
can
move
one
step
closer
to
the
targeting
go:
go
post
so
yeah
we
want
to
rename
like
the
whole,
the
high
level
get
change
blocks,
crd
to
something
called
differential
snapshot
and
then
there's
spec
and
status,
not
surprisingly,
and
within
the
spec.
D
You
know
that,
like
the
type
local
object,
reference
is
actually
a
reference
to
the
gvk
of
like
the
pvc,
the
volume
snapshot
and
potentially
any
other
like
the
parties.
You
got
that
the
controller
may
have
our
back
permissions
to
access,
so
we
find
this
more
generic
and
more
like,
I
guess
in
a
way
idiomatic.
D
So
you
know,
in
this
case,
user
would
specify,
like
the
you
know,
the
the
the
gpk
and
the
name
of
the
volume
snapshot
for
the
base
and
the
target
as
parameters
to.
A
D
So
the
interesting
thing
yeah.
So
this
is
the
you
know
you
know
trying
to
totally
avoid.
Like
the
you
know,
the
the
you're
trying
to
like
yeah,
like
you
know,
as
you
know,
we
go
through
like
the
original
requirements
and
then
the
white
paper
and
all
those
things
again.
There
is
a
potential
that
we
may
have
to
do.
Differential
snapshot
for
files,
even
though
right
now
is
block,
but
so
we
have
some
discussion
around
like
okay.
A
D
Yeah,
so
at
this
point
we
don't
know
right
like
it's
whether
like
so
this
is
the
kind
of
feedback
that
we
are
hoping
to
get
it's
using
like
local
object.
Reference
like
over
generalized
an
over
generalized
solution.
A
Kind
of
at
this
point
yeah,
because
it's
we're
doing
alpha
right
so
making
it
more
complicated
since
the
your
you
know
this
structure
name,
is
this
differential
snapshot
anyway?
I
mean,
but.
A
C
I
also
think
this
should
be
simply
a
string
of
the
volume
snapshot.
Name
should
be
enough,
so.
D
It's
not,
I
feel
like
so
at
this
point,
I'm
not
convinced,
but
we
can
take
this
offline,
but
is
that?
Is
there
another
lesson
to
be
learned
from
pvc?
You
know
like
why?
Don't
no.
A
That's
not
a
lesson,
that's
because
we
know
at
that
time
there
will
be
other
use
cases
coming.
We
already
know
that
when
we
added
this
typed
local
object
reference,
it's
different
from
this
one.
This
is
different
right.
This
one.
We
don't
really
know
what
what
else
we
can
go
ahead
and
use
potentially
file,
but
the
file
should
also
be
a
snapshot.
So
so
that's
right,
yeah,
that's.
D
Is
file
gonna,
be
a
volume
snapshot
cr
as
well.
A
It's
also
snapshot
yeah
files.
Also.
We
also
use
this.
We
don't
have
another
snapshot
api
for
just
a
file,
it's
based
on
the
underlying
implementation
right.
So
it's
very
strange
that
you
have
this
one
here
that
we
don't
have
any
other
use
and
then
just
remember
this
is
since
this
is
a
you
know,
still
alpha
right.
So
if
we
want
to
changes,
we
can
just
change
later,
but
I
think
it
is
definitely
normally
when
you
have
this
one.
We
already
know
something
else
is
coming
like
you
know,
but
right
now
we
do
not.
D
Okay,
yeah
point
taken
so
let's
yeah,
let's
maybe
like
if
we
yeah
okay,
point
taken
yeah
cool,
you
can
make
a
note
of
that
and.
D
Yeah
so,
and
then
again
like
following
the
pvc
like
design
like
the
moat,
is
where
we
kind
of
think
like
okay,
is
it
gonna
be
like
a
a
block
versus
like
a
file
snapshot,
type
of
thing
and
then
just
going
down
to
things
like
maximum
entries
and
custom
parameters
that
can
be
included
in
the
request
and
the
status
itself
like,
as
farm
pointed
out
earlier,
we
used
to
have
like
a
list
of
change
blocks
with
the
metadata
of
the
change
blocks,
included
and
embedded
inside
the
status.
D
So
for
now
like
this,
design
is
returning
a
ui,
a
url
and
then
like
I'm
with
the
different
faces
indicating
like
because,
like
part
of
partially
like
as
things
are
happening,
you
know
you
can
imagine
or
try
to
recall,
like
you
know
when,
when
a
pot
is
spinning
up,
you
know
like
under
the
status,
there's
different
conditions
and
faces
as
the
as
the
part
goes
through.
D
So
we
are
thinking
like
some
sort
of
list
of
faces
to
indicate
like
what
is
happening
as
the
you
know,
as
the
backup
software
try
to
invoke
the
stream
uri
to
get
back
the
streams
of
this
changing
box.
C
Status
string
like
so
in
case
that
it
is
a
failure,
then
we
can
put
the
error
there
instead
of
this
this
thing
here,
so
we
need
to
add
one
or
two
more
field
indicating
the
status
and
the
error
message
or
or
description,
or
something
like
that
that
that
be
more
information
about
this
request,
success
or
it
failed,
or
at
least,
and
so
on
and
so
forth.
You
know.
A
D
D
Yeah
I
haven't
like
yeah,
we
haven't
thought
too
much
about
what
yeah,
okay
again
totally
fine.
Let
me
just
add
a
note
here.
Yes,.
D
Okay,
cool,
so
that's
kind
of
like
what
we
have
in
mind.
The
main
thing
here
is
really
still
like.
You
know
the
uri
we're
gonna
go
and
talk
a
little
bit
about
our
current
thought
on
what
how
the
what
the
url
should
look
like
the
main
thing
is,
like
ui,
is
being
embedded
into
the
status
instead
of
a
list
of
you
know,
change
blocks
on
metadata,
so
any
other
thoughts,
comments,
feedback
feedback
so
far,.
C
When
we
talk
about
the
security
of
this
uri,
we
might
want
to
add
some
more
feel
into
this.
This
different
source
status.
We
can
talk
about
that
when
we
get
to
that
point.
Yeah
okay
sounds
good.
D
So
I
think
yeah
so
yeah
like
this
is
kind
of
what
we
envisioned
like
in
the
whole
like
what
flow
will
look
like,
so
the
backup
software
would
create
like
a
cr
of
differential
snapshot.
You
know
giving
it
like
just
two
like
I
guess
like
at
this
point.
Like
volume
snapshot
I
ids
and
then
the
differential
snapshot
controller
would
be
watching
it
will
be
a
sidecar
embedded
into
the
provider
csi
driver.
D
In
this
case
we
use
the
evs
driver
as
part
of
our
previous
prototype,
so
the
controller
will
be
watching
the
you
know
the
creations
of
the
differential
snapshot
resource
and
when
that
happens
like
the
first
so
like
all
the
controller
is
going
to
do
between
the
same
sidecar.
D
We
at
this
point
we
are
envisioning
like
two
separate
process
or
go
routines
or
whatever
call
it.
The
controller
will
update
the
status
resource
with
the
ui,
and
then
you
know
originally
was
thinking
of,
like
you
know
some
status
to
show.
D
You
know
what
face
is
going
through
again.
If
this
is
something
that's
not
desirable,
like
we
can
change,
it
also
want
to
know
and
learn
more
a
little
bit
about
why
faces
are
not
desirable.
So
the
ui
would
look
something
like
you
know,
port
number,
I
think
so,
the
stream
okay.
So
let's
talk
about
this,
can
you
see?
D
Hopefully
it's
not
too
small
the
fonts,
so
the
stream
uri
ui
is
something
that
like
so
like,
ideally
in
the
in
the
ideal
case,
it
would
be
like
the
service
that
front
the
deployments
or
whatever,
like
the
dns
name
right,
so
it
would
be
like
full.namespace.svc.cluster.loco.
D
When
you
know
the
deployment
inside
the
declare
inside
the
deployment
gamma
in
you
know,
discovery
and
constructed
as
part
of
the
code,
so
there's
kind
of
like
the
current
thoughts,
so
the
the
the
first
important
thing
about
the
streaming
ui
just
you
know
how
we've,
how
we
built
it
where,
where
the
host
name,
how
how
it
is
discovered
and
constructed.
D
So
it's
just
a
better
way
to
provide
a
more
deterministic
like
stream
uri
without,
depending
on
the
part,
dns
name,
you
know,
yeah.
We
will
welcome
the
kind
of
feedback
and
ideas
I
look
into
how,
like
you
know
with
pot
like
yeah,
you
can
give
it
a
static
host
name.
You
can
know
with,
like
I
think,
since
1.22
you
can
use
this,
you
can
set
the
hostname
as
a
fqdn
all
these
things,
but
they
all
required.
F
E
F
D
Yeah
yeah,
if
like,
if
we
can
yeah,
definitely
I
personally,
I
would
much
prefer
like
if
there's
a
service,
if,
if
we
can
guarantee
that,
there's
a
service
resource
in
front
of
it,
and
then
we
just
used
to
see
us
observe
this
dns
mean
I
mean
even
like
you
know,
depending
on
what
the
deployment
and
operation
model
looks
like,
we
might
even
be
if
it
is
like
deployment
through
a
helm
chart,
we
might
even
be
able
to
say
include
the
service
that
select
the
labels
of
the
part
right
and
then
use
helm
to
do
is
go
templating
magic
doing
come,
install
to
make
sure
that
our
service
would
always
select
the
part
of
the
of
the
drive
driver,
for
example,.
F
So
yeah,
but
I
mean
how
it
gets
installed,
is
usually
a
question
for
the
csi
driver
author
right,
like
we
have
a
csi
driver
and
you
can
deploy
with
a
helmet.
You
can
deploy
it
a
bunch
of
other
ways
and
that's
sort
of
for
for
us
and
our
customers
to
figure
out,
but
at
the
end
of
the
day,
as
long
as
the
service
gets
created,
then
you'll
have
something
that
backup
software
can
talk
to
to
to
get
this.
Get
this
snapdiff
data.
F
F
D
Yeah
yeah
and
definitely
like
yep.
That
sounds
good
to
me,
because
the
only
other
fallback
I
can
think
of
is
that
you
know
the
party
and
us
still
like
if
we
can
avoid
having
to
do
this,
you'll
be
great
so
yeah
anyway.
So.
E
Work
because
we
have
to
update
all
these
objects
that
pump
out
restarts,
but
for
me
the
bigger
question
is
this:
so
basically,
one
of
the
problems
we
wanted
to
address
was
to
limit
the
size
of,
or
these
objects
right
and
that's
why
you
have
max
entries
set
to
64
there
and
and
also
it
seems
basically,
instead
of
actually
populating
the
object
with
the
change
blocks
itself.
You're,
actually,
programming
uri,
so
we
can
find
change
blocks
elsewhere.
Right,
that's.
E
C
C
C
D
D
You
know
it
will
point
it
back
to
at
this
point,
like
seems
like
car,
but
it's
a
listener
process
in
there.
So
this
listener
would
just
like
go
through
the
same
grp
pc
flow
that
fong
showed
earlier.
It
would
talk
to
the
eds
plug-in,
so
the
jpc
client
side
would
be
I'll,
listen
that
would
be
the
jpc,
client
side
and
then
the
and
then
the
ebs
provider
plug-in
would
be
the
grpc
server
side.
So
we'll
invoke
the
aws
ebs
direct
api.
That
says
you
know
given
this
to
snapshots.
D
Yeah
get
right
and
then
give
me
the
snapshots
now
go
and
call
into
aws
on
ebs,
drag
and
get
give
me
back,
auto
change
blocks
and
then,
like
all
of
these
responses,
will
be
streamed
directly
back
to
the
backup
software
and
then
the
backup
software
would
be
responsible
and
then,
of
course
like,
as
this
response
is
coming
back.
D
Aws
of
itself
would
also
provide
like
enough
information
to
paginate
the
requests,
so
the
backup
software
will
make
have
to
make
the
decisions
on
whether
you
want
to
continue
to
fetch
more
blogs.
D
You
know
over
the
same
streaming,
uri
and
passing
more
information
like
you
know,
the
next
token,
the
maximum
results,
etc,
etc,
and
at
this
point
like
we
would
totally
totally
like
just
leave
the
differential
snapshot
custom
resource
alone,
so
nothing
would
ever
get
saved
into
a
cd
and
then
once
the
backup
software
from
there
can
decide
what
it
wants
to
do
with
those
responses
that
we
come
back
from
aws.
D
You
know
so
it's
kind
of
like
the
general
gist
of
it.
I
mean
like
they
have
some
details
around.
Like
you
know
as
we,
how
do
we
do
the
streaming
between
the
background
software
and
listener?
D
I
think,
like
one
thing
that
was
brought
up
was
grpc
over
http,
but
it
means
that
potentially,
we
have
to
put
like
a
gateway
in
front
of
that.
The
great
ring
process,
depending
on
the
amount
of
footprint
there
we
may
or
may
not
need
to,
we
may
have
to
look
further
into
it
or
do
we
want
to
follow
like
what
currently
like
two
color
logs
and
exact
and
forwarding
are
doing.
You
know
basically
do
like
a
protocol
upgrade
to
speedy
and
then
just
continue
on
like
streaming
after
the
protocol.
D
Yeah,
I
think
like
if
we
can't
just
do
it
with
our
machine
like
or
just
straight
up
the
good
old
handshake
request
response.
Okay,.
F
Yeah
I
mean
my
my
personal
qualm
with
grpc
is
just
that
you
requires.
You,
know,
code
generators
and
extra
libraries
and
a
bunch
of
stuff
that
makes
it
a
hassle
to
consume
from
some
programming
languages
whereas
json
over
http.
Is
you
know
you
can
you
can
write
a
client
for
that
in
five
lines
of
python
code
or
you
know,
or
whatever
you
want
to
do
it
just
makes
it
a
lot
easier
to
interact
with
and
and
there's
really
only
one
thing
we're
doing
right,
which
is
here's.
The
snapshot
name,
give
me
back.
F
C
Is
the
maximum
size
for
that
attp
respawn.
F
C
F
C
F
The
code
is
going
to
be
a
lot
smaller
if
you
just
do
something
simple,
like
json
over
http,
rather
than
having
to
go,
build
a
whole
grpc,
because
grpc
is
really
designed
for
like
high
performance
sort
of
communication,
where
you're
doing
lots
of
rpc
calls
and
with
with
presumably
very
small
payloads
right
here.
D
Yeah,
if
we
definitely
if
like
if
we
don't
need
to
like,
have
like
a
bi-directional
streaming
thing,
then
totally
I
think
like
I'm
just
playing
on
like
you
know,
json
over
http
is
great.
It's
like
yeah,
like
you
know,
give
the
response
back
to
the
backup
server.
D
If
you
want
more
issue,
another
request
that
totally
works
for
me
to
fund
your
question
like
there's
no
size
limit,
but
like
the
http
client
everything
go,
it
has
some
sort
of
default
timeouts
that
we
may
have
to
make
it
either
configurable
or
to
try
it
out
to
see
like
how
that
may
affect
us,
but
yeah
otherwise,
like
yeah.
C
So
it's
like
it's
not
like
the
the
csi
different
snapshot.
Listener
can
be
something
like
a
like
a
red
server
right.
It's
when
you're.
C
That
you,
you
call
a
get
command
with
that
ui
stream,
that
right
there
and
then
it
just
get
back
the
body
without
the
chain
block
in
the
body
right,
yeah.
F
And
I
wouldn't
worry
about
anything
like
a
timeout
like
these
calls
are
going
to
be
made
in
environments
with
reasonably
fast
networks
where,
even
if,
even
if
the
metadata
for
the
change
blocks
is
100
megabytes
you're
going
to
move
that
in
in
milliseconds
right,
100
megabytes
is
nothing
for
http
to
to
shove
through
a
pipe.
So
I
don't
see
the
problem
with
just
using.
C
That
so
good
to
me,
I
mean
another
thing
that
another
concern
that
we
we
still
debating
is
the
security.
Sorry
yeah
you.
D
Go
ahead
and
talk
about
that
yeah.
Sorry
before
we
talk
about
security,
the
other
thing
I
want
to
quickly
address,
because
I
know
security
is
like
a
big
thing
here.
It's
probably
going
to
take
a
lot
longer
to
discuss,
but,
like
the
other,
like
a
design
like
a
discussion,
we
have
been
having
is
like
whether
we
want
to
keep
the
listener
as
part
of
the
site
car,
or
should
it
be
separated
into
a
different
part
or
entity
or
whatever
what
we
want
to
call
it.
D
But
I
think
like
at
this
point
like
unless
there's
compelling
reason
we
prefer
to
put
it
in
the
same
site
car
simply
because,
like
this
will
allow
it
to
discover
you
know
the
the
provider
plug-in
over
local
unix
socket.
C
C
Kind
of
bring
up
that
point
is
because
of
the
scale
right,
so
the
the
differential
snapshot
controller
is
is
to
only
do
a
very
little
work,
but
the
differential
listener,
the
box
that
you
see
there
it
might
need
to
serve
a
lot
of
the
requests
coming
back
and
forth
and
it
might
hold
on
to
the
the
connection
longer.
C
So
I
wonder
if
we
can,
you
know
scale
it
in
some
way.
If
we
separate
it
into
like
a
separate
into
like
a
survey
with
multiple
parts
in
the
back,
then
we
can
scale
it
easier,
but
maybe
in
the
prototype.
Maybe
we
don't
need
to
talk
about
that.
Yeah.
D
Yeah,
I
think
also,
like
you
know,
yeah
we
can
revisit
it
if
there's
a
need,
but
I
think,
like
even
scaling
itself
is
not
going
to
help
because
your
request
is
going
to
be
sequentially
paginated
anyway.
It's
not
like
you
can
make
comparing
calls,
but
at
this
point
like
unless
it's
a
strong,
no,
please
don't.
C
D
C
Yeah,
so
so
the
the
idea
was
that
we
we
do
not
want
other
other
component
able
to
get
into
this
stream
right.
We
only
want
the
the
creator
of
the
cr,
the
differential
snapshot
cr
to
able
to
read
from
this
stream
uri
that
we
post
there,
so
we
need
to
have
some
kind
of
protection.
The
mechanism
to
put
in
so
we
did
we
debate
on
that
yesterday
on
how
to
help
protecting
this
ui
stream
from
non-intentional
as
user.
C
This
cr
itself
is
readable
by
many
many
components
that
might
have
the
same
permission
right,
but
we
only
want
the
the
creator
of
it
to
access.
So
one
idea
is
a
two
I
think.
Yesterday
we
chat
on
slap
that
that
we
have
some
kind
of
a
secret
or
a
certificate
that
being
created
by
the
the
backup
vendor,
backup
software
that
create
the
cr
and
it
put
the
certificate
in
a
secret
or
something
like
that,
and
they
share
the
secret
here
in
the
cr.
C
We
can
put
it
into
like
a
in
a
parameter
or
something
like
that
right
and
then
on
the
server
side
on
the
csi
snapshot
listener.
It
might
also
have
its
own
certificate
and
by
exchanging
a
certificate
in
the
establish
of
the
connection,
the
backup
software,
the
backup
vendor
here,
the
creator
of
that
differential
snapshot
can
securely
and
and
and
and
secretly
connecting
to
the
listener
the
service
securely.
And
that
is
one
proposal.
D
Think
like
so,
whichever
approach
that
we
use,
I
don't
think
we
should.
We
should
make
make
sure
we
don't
put
like
secret
in
plain
text
into
the
cr,
unless
the
public
search
is
fine,
but
definitely
not
some
sort
of
secret
tokens
or
whatever,
but
anyways
the
so
yeah.
D
Like
you
know,
yes,
security
is
always
such
a
big
and
broad
thing,
but
at
the
minimum
the
baseline
is
that
we
definitely
want
the
communication
between
the
backup
software
and
the
listener,
for
example,
to
happen
to
be
encrypted
over
you
know
and
to
happen
over
https.
D
So
you
know
not
get
into
conversations
like
okay.
How
do
we
propagate
the
dls
server?
You
know
what
about
renewal
officer,
management
of
the
cia
trust
and
all
those
things
I
think,
like
you
know
that
one,
I
guess
again.
One
of
two
ways
I
can
think
of
is
that
basically
it
can
just
be
another.
D
Like
you
know,
infrastructure
requirements-
hey
miss,
you
know,
if
you
have
sub
manager
deployed
already
make
sure
you
have
this
secret
so
that
you
know
resource
created,
so
our
csi
site
car
can
pull
the
public
search
in
the
trust
forum
and
then
make
sure
the
backup
software
also
trusts
the
same
chris
and
have
the
same
access
to
the
same
secret,
etc,
etc.
So
it's
basically
like
it
just
becomes
now
like
a
p.
D
Absolutely
yeah,
that's
kind
of
like
the
second
approach
we
thought
of,
like
the
you
know,
we
delegated
right
to,
of
course,
like
the
aps.
Server.
First
of
all
has
to
trust
us
now.
He's
like
you
know,
like
total,
all
the
way
down
right
like
how
do
we
it's
like
what?
Basically,
what
aggregated
api
server
can
do
is
like
in
the
api
service
resource.
Then
you
probably
know
this
and
a
few
of
this,
oh
and
a
few
of
you
are
familiar
with
this
right.
D
You
declare
like
you
see
you
put
a
ca
trust
in
there
and
that's
how
this
api
server
trusts
you
and
after
that
we
just
said
hey.
You
know
every
time
I
got
a
request,
you
just
delegate
the
authentication
authorization
to
api
server.
I
said:
can
I
trust
this
person,
or
this
request
coming
from
this
source,
and
then
the
api
server
was
a
year
on
there
and
then
and
of
course,
now
we're
getting
very,
very
close
to
like
okay,
are
we
heading
down
the
aggregated
aps,
server
path,
which
is
not
a
bad.
C
D
You
know
it
just
means:
yeah
we're
gonna
have
to
tap
into
using
like
the
aggregate
api
server
packages
and
how
to
set
it
up.
Yeah.
F
I
I
like
piggybacking
on
the
our
back
systems
already
exist
because
it'll
simplify
deployment
of
this
thing
right
with
less
stuff
to
to
lay
down,
and
the
configuration
will
be
familiar
to
people
who've
dealt
with
kubernetes
before
you
know
just
granting
another
role
or
granting
another
action
to
a
role
and
then
binding
it
to
an
account.
Everyone
understands
that
and
then
and
best
of
all,
I
think
the
authentication
is
known
to
be
secure
right,
like
if
we
invent
our
own
authorization
scheme.
F
Even
if
it's
like
mtls,
you
know
with
standardized,
you
know
tls
stuff.
You
still
have
to
convince
yourself
that,
like
no
one
can
get
the
secrets
and
no
one
can
you
know
it's
just
with
kubernetes
it's.
You
know
that
the
the
authorization
scheme
is
secure
and
it's
just
a
matter
of.
Can
we
plug
into
it
in
a
way
where
you
can
sort
of
delegate
exactly
the
permissions
you
want
to
the
service
that
needs
to
to
do
this,
work,
which
is
going
to
be
the
backup
service
right.
F
D
Yeah
yeah,
if
the
yeah-
I
again
that
would
that
makes
a
lot
of
sense
to
me,
because
if
the
backup
server
is
already
apart,
you
will
have
a
service
account.
Then
we
can
trust
the
api
server
to
tell
us
that.
Does
this
service
account
have
to
appropriate
our
permissions
to
talk
to
us
and
etc
right,
so
it.
F
C
It's
not
good
to
me,
I
mean
the
basically
the
backup
vendor
would
have
its
own
security
account.
I
mean
service
account
and
it
will
have
appropriate
banks
to
only
able
to
access
this
differential
snapshot.
Cr
and
read
form
it's
like
that's
the
only
the
only
thing
that
it
can
do
that
then
then,
otherwise,
other
other
components
were
not
able
to
access
this
cr
at
all.
Right.
F
Well,
there's
there's
two
things:
there's
I
mean
the
cr
will
have
our
back
around
it,
because
all
crs
have
our
background
on
them.
Right
you
have
to.
You
have
to
be
granted
permission
to
even
read
the
cr
at
all
so
you're,
getting
through
one
hoop
of
of
our
back
just
to
be
able
to
read
the
cr,
and
then
we
can
put
up
an
additional
barrier
that
says:
okay
after
you
have
the
cr
and
you
get
the
url
and
you
open
the
connection
to
this
service.
F
It's
also
going
to
authenticate
you
and
make
sure
that
you
have
some
additional
privilege
to
be
able
to
call
that
api.
Okay,
and
then
I
mean
the
second
one
is
arguably
optional
right.
F
If
you
would,
if
you
just
want
to
use
the
ability
to
read
this
crd
as
your
gate,
then
you
could
just
put
some
cookie
in
the
crd
and
say
anyone
who
knows
the
cookie,
I'm
going
to
trust
them
and
that's
good
enough,
but
but
yeah
it's
it's
even
better
to
have
a
second
layer
of
our
back
on
the
second
http
connection,
where
you
have
to
authenticate
as
a
kubernetes
user
and
then
somehow
I
don't
know
exactly
how
that
works.
To
be
honest,
how
you
would,
if
you're,
not
the
api
server
but
you're,
some
other.
D
Yeah
yeah
either
we
rely
on
again
falling
back
on
the
trs
cert.
You
know,
I
think
yeah,
like
you
know,
like
the
trs
cert,
like
you
know,
with
this,
like
all
these
like
attributes
in
there,
it
can
serve
as
some
sort
of
identity.
I
mean
that's
really
what
like
things
like
the
service
mesh
do
right.
You
know
they
use
the
trs
as
a
form
of
identity,
ticket
and
api
server
would
know
how
to
anyway
yeah
there's
a
lot
of
cool
yeah.
I.
C
D
So
sorry,
well,
I
have
everyone
on
the
phone.
There's
one
last
design
item
that
I
want
to
quickly
like
get
feedback
on.
If
we
have
maybe
two
more
minutes
which
is
over,
like
you
know,
if
there
is
like
multiple
driver
parts,
how
do
we
handle
it?
You
know
so,
for
example,
by
default.
If
I
deploy
ebs,
csi
driver,
it
comes
with
two
parts:
it's.
G
D
A
demon
set,
it's
just
a
deployment
with
which
defaulted
to
two
replicas.
So
if
there
are
two
of
these
against
sidecar
see
this
sidecar,
how
do
we
handle
it?
At
this
point?
We
kind
of
want
to
lean
towards
just
following
what
the
csr
external
resizer
driver
is
doing.
I
think
he
has
some
sort
of
built-in
leader
leader
elections.
That
says
only
one
would
be
the
effective
and
active
leader
and
work
on
the
rest
will
stay
asleep
until
the
leader
died.
F
G
C
Sorry,
I
cannot
hear
you
very
well,
could
you
repeat
the
question
louder
or
something
all.
G
D
I
don't
think
there
is
not
at
the
service
level,
so
yeah
there
needs
to
be
some
quote-unquote
intelligence
or
either
like
we
just
use
like
the
pop
dns.
I
don't
know
I
I
don't
want
to
use
a
partners,
but
if
there
is
the
only
way
to
determine
how
to
determine
deterministically
identified
the
leader,
then
we
don't
have
to
fall
back
to
the
top
level
resolution.
D
Thanks
john
appreciate
it:
okay
cool,
I
think
that's.
C
All
I
have
like
yeah,
so
the
the
update
is
that
we
we
have
a
meeting
on
every
thursday
morning
at
8
00
a.m,
pacific
time.
C
So
if
you
want
to
participate
in
this
project,
please
you
can
send
me
a
message
on
slack
or
I
think,
email
me
and
then
we
I
will
invite
you
to
into
that
conversation
that
we
have,
and
currently
the
split
of
the
work
will
be
as
following.
I
will
work
on
enhancing
the
crd
according
to
what
we
just
discussed
and
also
enhance
the
deep
snap
controller
and
ivan
preset
and
sean
we're
working
on
the
different
snapshot
service,
with
all
the
security
hook
and
and
all
that
stuff
that
ui
we
just
saw.
C
We
just
present
to
you,
please.
If
you
have
an
expert
in
in
this
area
that
we
are
just
mentioned
just
you
can
go
ahead
and
jump
in
and
help
us.
That's
all.
I
think
I
have
for
today
and
thank
you
guys.
Thank
you.
A
So
you
guys
will
be
working
on
a
poc
right
based
on
this
discussion.
I.
C
Think
we
need
to
discuss
a
little
bit
more
to
secure,
actually
just
to
have
a
solid
design,
and
then
we
will
create
a
prototype,
but
we
we're
running
the
we're
running
the
work
a
little
bit
in
parallel,
like
my
part,
can
be
done
without
a
solid
design,
because
I
I
can
just
enhance
the
crd.
You
know
I
mean
controller
a
little
bit
right,
but
on
the
main
part,
is
on
the
on
on
ivan
precept
and
and
sean
to
redesign
that
service.
We
rely
that
service.
D
Yeah
we
can
break
up
the
tasks
into
smaller
chunks
like
during
our
engineering
sync
up
and
go
over
there.
Otherwise,
I
think
we
at
this
point.
I
am
confident
that
we
have
a
clear
path
forward.
I
think
some
of
the
some
parts
might
be
harder
than
the
others,
like
you
know,
delegating
to
api
server,
etc,
etc.
So,
but
yeah,
I
don't
think
we
have
a
clear
path
forward.
A
Okay,
another
thing
is
just
small
thing
right
now.
I
think
it's
fine
you,
because
this
is
what
you
are
using
for
the
poc,
but
when
you
formally
submit
a
cap,
please
make
this
generic,
knowing
oil
diagrams.
A
A
Thank
you
yeah
funny
one
and
everyone
else
who
are
working
on
this
cbt
yeah,
because
I
made
really
great
progress
so
so
we're
still
trying
to
do
an
alpha
f
array.
We
can.
We
can
still
try
to
try
to
do
that.
You
know
this.
We
have.
A
A
But
but
but
we
also
we
can
actually,
since
this
is
complete,
auto
tree,
we
can
also
say
hey.
We
don't
really
have
to
follow
all
of
those
we
just
you
know
we
just
continue.
We
can
still
continue
working
on
this
yeah.
We
can
do
that
too.
We
can
you
know.
Initially,
we
can
just
try
to
follow
those
deadlines,
but
if
we
can't
get
it
done,
then
we
can
just
have
it
just
checked
out
like
what
cozy
has
been
doing.
A
C
Maybe
I
will
consult
with
you
offline
on
how
to
proceed
with
1.25.
It's
with
this
one
yeah.