►
Description
Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 03 November 2020
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
B
All
right
so
good
morning,
good
afternoon,
this
is
the
volume
populators
kubernetes
sig
storage
meeting
and
let
me
share
my
screen.
B
We
we're
pretty
happy
with
the
well
okay.
Well,
the
first
week
we
we
kind
of
agreed
that
we
wanted
to
go
with
the
storage
with
the
controller
approach
instead
of
the
validating
web
hook
and
then
last
week
we
went
into
detail
about
how
we
may
implement
actual
populators
in
terms
of
what
they're
going
to
do
with
the
kubernetes
api
layer,
and
we
spent
a
little
bit
of
time
talking
about
once.
B
We
have
like
a
prototype
of
that
working,
how
we
can
sort
of
scale
it
out
for
multiple
populators
and
try
to
get
code
reuse,
because
it
became
clear
based
on
the
discussion
around
wait
for
a
first
consumer
and
some
other
sort
of
sticky
details
around
getting
volume
provisioning
in
kubernetes
right
in
general,
that
we
don't
want
people
re-implementing
that
code
over
and
over.
We
want
one
copy
of
it
that
just
works.
That
can
be
reused,
but
we
didn't
get
time
to
go
into
that
last
week.
B
So
that's
kind
of
the
the
main
thing
that
I'd
like
to
cover
today.
Unless
people
have
anything
else,
they
want
to
add
to
the
agenda.
B
So
the
first
thing
that,
oh
I
mean.
Okay,
let
me
take
a
step
back.
B
The
pattern
we
followed
so
far
when
we
wanted
to
reuse
code
in
sig
storage
has
been.
We
write
these
side
cars
and
then
we
have
like
a
plug-in
and
a
sidecar
container,
and
then
they
talk
to
each
other
over
grpc
and
the
community
maintains
the
sidecar
and
individual
vendors
implement
plugins
and
it
seems
to
be
a
good
model
for
csi
and
it
seems
to
be
the
model
that
cozy
is
ultimately
going
to
follow.
B
So
that
was
my
first
thought
here,
but
I
realized
that
if
we
were
to
do
that
like
we
would
need
to
implement
like
a
full-blown
grpc
spec,
all
csi,
which
would
mean
like
its
own
repo,
its
own
grpc,
spec,
probably
some
sort
of
document
describing
how
to
use
it.
The
sidecar
would
have
to
conform
to
that.
The
populators
have
to
conform
to
that.
It
seems
like
a
very
heavy
approach
to
sort
of
integrating
the
shared
code
and
the
populator
specific
code.
B
So
what
I
wanted
to
sort
of
well,
I
guess
think
about
today-
was-
can
be
done
as
a
library
where
we
implement
all
the
code
in
like
some
sort
of
a
just,
a
repo
that
can
be
imported
into
other
projects.
Where
you
know
you
provide
like
sort
of
a
sample
and
then
you
import
all
of
the
the
boilerplate
code
or
me.
That's
right.
The
sample
would
contain
the
boilerplate
code
and
you
would
you
would
import
this
library
that
would
do
most
of
the
actual
work
and
then
you
would
just
implement
little
bits
of
code.
B
C
C
I
think,
ultimately,
what
it
comes
down
to
is
kind
of
the
hardship
on
us
in
as
maintainers
and
developers
of
this
code
versus
the
hardship
on
the
folks
that
are
going
to
be
doing
the
integrations
and
writing
these
plugins,
and
so
I
think
we
tend
to
want
to
lean
towards
let's
take
on
the
burden
of
the
work
and
make
it
as
easy
as
possible
to
develop
the
plugins
and
in
general.
The
pattern
that
we've
seen
is
that
it
becomes
a
lot
easier
to
do.
C
It's
harder
to
kind
of
keep
track
of.
Oh.
What
version
am
I
on
and
just
a
little
bit
more
difficult
to
integrate,
potentially
yeah.
D
I
I
agree
with
with
I
think,
with
csi
or
in
general,
with
sidecars
approach.
It's
we
can
definitely
did.
The
line
we
can
draw
is
like
the
side
car
implements
all
the
kubernetes
related
logic
and
the
actual
driver
implements
kubernetes
sort
of
agnostic
logic
related
to
a
driver
itself.
D
I'm
not
sure
at
this
moment,
while
we
don't
have
a
really
good
understanding
of
what
what
drive
or
what
we
can
generalize
and
what
should
be
a
responsibility
of
individual
drivers.
I
think
at
this
stage
might
be
a
little
bit
too
early
to
say
what
kind
of
approach
we
are
going
to
follow
if
we
are
able
to
generalize
like
huge
piece
of
kubernetes,
related
logic,.
B
And
what
benefits
you
inside
believe
we
get
from
the
side
car,
because
I
I
did
think
a
bit
a
little
bit
about.
B
Like
you
know,
if
we
go
down
the
side
car
approach,
then
I
think
it's
clear
we'll
need
some
sort
of
grpc
spec
and
that's
definitely
more
work
right,
because
you
need
to
write
that
down,
agree
on
it,
maintain
it
in
a
separate
place
and
then
have
a
sidecar
that
conforms
to
it
and
and
the
I
do
see
the
benefit
of
it's
it's
much
clearer
where
one
stops
and
the
other
one
ends
or
whether
the
one
stops
and
the
other
one
begins.
But
I
I
don't.
B
I
don't
buy
that
libraries
are
way
worse,
like
I
think
that
golang
used
to
have
fairly
bad
versioning
practices
before
modules
were
a
thing
or
go.
What
was
the
thing
before
modules
when
they
had
it
properly?
Versioned.
C
B
Dubs,
well,
no,
I'm
not
talking
about
that.
I'm
talking
about
like
when
they
had
proper
versioning
of
of
import.
Maybe
it
was
go
modules,
but
the
if
you,
if
you
buy
the
the
rules
around
how
go
modules
are
supposed
to
work
and
how
versioning
is
supposed
to
work.
B
I
think
you
can
get
a
lot
of
the
same
kinds
of
benefits
from
them
and
say:
okay
as
long
as
I'm
using
the
library
version,
one,
it's
got
this
interface
and
if
anything
breaks
that's
you
know
you
have
to
call
it
version
two
and
then
it's
just
a
matter
of
you
know
in
my
code,
when
I'm
importing
I
gotta
choose
if
I
import
version
one
or
version
two,
and
if
we
follow
the
you
know
the
go
module,
versioning
rules.
B
I
think
you
can
stay
out
of
trouble
as
far
as
like
breaking
someone
and
but
but
it
also
doesn't
lock
you
out
of
making
breaking
changes
if,
for
the
sake
of
forward
progress,
if
you
need
to
you
just
have
to
version
it
with
a
major
version
bump,
so
that
clients
don't
automatically
get
sucked
into
the
new
version
when
they
don't
want
to
so.
D
B
D
But
it
might
be
a
storage
person
who
could
have
taken
care
of
that
right
if
we
provide
it
like.
If
we
generalized
all
the
kubernetes
part
yeah
like
we
could
just
approach
a
storage
person's
name,
we
need
like
a
couple
of
interfaces
you
to
implement
related
only
to
storage,
don't
bother
with
kubernetes.
B
Itself,
but
so
so
what
you're
describing
is
like?
We
have
an
interface,
we
have
a
sidecar
and
then
we
have
a
sample
populator
and
then
you
say:
okay,
mr
storage,
provisioner
just
fill
in
the
blanks
in
this
sample
and
you're
done
right
and
that's
supposed
to
be
very
easy
which
which
we
could
do
but,
like.
I
think
you
could
do
the
same
with
the
library.
B
D
Except
maybe
troubleshooting,
but
maybe
you're
right,
as
I
said,
I
think
at
this
point.
Maybe
if
we
are
not,
if
we
are
not
able
to
generalize
right
now
or
say
how
how
we
can
generalize
logic,
maybe
its
library
is
a
better
approach
at
this
moment
to
kind
of
to
see
how
we
can,
what
exactly
we
can
generalize
how
we
can
proceed
and
then
once
we
know
more
about
that,
because,
okay,
we
can
generalize
the
entire
kubernetes
piece,
then
maybe
we'll
be
able
to
move
that
to
a
kind
of
a.
B
B
Actually
you
know
mount
the
volume
and
stick
the
data
in
it,
whether
it's
a
file
system
or
raw
block
volume
like
that
that
kind
of
integration
is
fairly
easy,
but
but
there
is
one
of
the
parts
that
would
be
hard
to
sort
of
do
through
a
sidecar
or
do
through
a
grpc
interface.
Is
that
unlike
csi
and
cosy
the
specific
shape
and
form
of
the
cr?
That
is
the
thing
that
you
populate
from
is
defined
by
the
populator
and
that's
so
that's
like.
Fundamentally,
it's
a
kubernetes
object
right.
B
You
have
some
crd
that
you've
created
that
says.
You
know
this
is
my
my
foo
data
source
and
it
has
these
fields
and-
and
this
populator
knows
how
to
populate
from
food
data
sources,
and
so,
if
you
try
to
imagine
okay,
now
we're
writing
up
the
the
the
grpc
spec
that
the
sidecar
is
going
to
speak
to
the
to
the
populator
plug-in
it's
going
to
have
to
like,
send
back
and
forth
instances
of
this
blob,
which
is
defined
by
the
by
the
populator.
B
You
know
that
are
fundamentally,
they
are
kubernetes
objects,
you
know,
but
we
can
massage
them
so
that
they
look
like
something
you
can
put
over
grpc,
but
at
the
end
of
the
day,
the
you
know,
if,
if
somebody
wants
to
define
a
cr
which
is
really
really
complicated
and
has
lots
and
lots
of
subfields
and
options
that
you
know,
they
should
be
welcome
to
do
so,
but
like
how?
How
does
the
sidecar
take
instances
of
that
and
present
it
to
the
the
populator?
B
But
this
is
the
case
where
you
very
much
do
need
to
understand
that,
like
what
you're
getting
is
a
it's,
a
kubernetes
crd
or
it's
an
instance
of
a
kubernetes
crd
and
you
need
to
populate
from
it
and
you're
the
way
you're
going
to
do.
That
is
by
producing
a
pod
that
will
either
mount
it
or
get
a
device.
If
it's
raw
block
at
a
certain
place,
and
then
it
will
do
something
to
populate
it
right
and
and
of
course
that
something
is,
is
the
part
that
we
leave
undefined,
but
it
it
feels.
D
D
B
I
mean
crucially,
you
know
when
you
go
the
grpc
route,
you
free
people
up
to
use
programming
languages
other
than
go.
If
someone
wants
to
write
a
popular
in
python
and
we
have
a
popular
grpc
interface,
you
you
could
do
that.
You
just
have
to
talk.
You
know
all
the
various
grpc
interfaces
from
python
and
then
yeah.
D
B
B
D
C
Yeah,
I
I
think
that
that's
basically
really
it
is
it's
a
cleaner
separation.
It
I
think
long-term
maintainability
becomes
simpler
because
you
have
these
independent
components,
and
so,
if
you
need
to
rev
one,
you
don't
need
to
like
recompile,
rebuild
and
and
push
out
images
of
your
own
code.
You
just
go
grab
another.
B
C
B
Yeah
I
mean,
I
guess
worst
case
you
could
convert
it
to
something
like
a
json
blob
and
right.
I
don't
know
if
grpc
has
even
the
equivalent
of
a
json
blob,
I
mean
you
could
literally
convert
it
to
like
text
yeah.
D
B
It
forced
them
to
parse
the
json
or
something
on
the
other
side
yeah,
but
but
yeah.
Those
kinds
of
solutions
feel
gross
yeah
because
then
there's
all
sorts
of
input,
validation.
You
have
to
do
and.
C
B
C
How
about
let's
play
devil's
advocate
what
if
we
had
a
well-defined
cr
crd,
where
the
set
of
fields
was
an
opaque
map
similar
to
kind
of
storage
class?
Would
that
not
work?
What
would
it
break.
B
Yeah,
I
think
that
just
pushes
the
ugliness
that
pushes
the
ugliness
into
the
kubernetes
api
yeah,
whereas
I
think
kubernetes
is
well
suited
to
say.
Oh,
you
know
you
can
define
crds
that
have
schemas
and
get
type
checking
and
all
the
the
nice
things
you
get
out
of
them.
And
so
it,
when
you
create,
like
a
you
know,
want
to
create
a
volume
from
like
a
github
repo,
and
you
define
your
github
repo
as
a
type.
You
can
put
all
the
necessary
things
in
there
and
get
good
type
checking
and
it
looks
sane.
C
Yeah
I
mean
this
is
exactly
the
problem.
We're
hitting
as
we
are.
You
know
we
we
come
up
with
like
cozy
we're
like.
Oh,
you
know
what
one
of
the
mistakes
we
made
with
kubernetes
or
we
or
with
pvc
sort
storage
classes,
was
we
kind
of
had
this
opaque
list
of
parameters
at
that
time
we
didn't
have
crds.
Wouldn't
it
be
nice
if
the
storage
class
could
just
point
to
a
crd,
an
arbitrary
crd.
C
Like
oh,
if
we
did
that,
then
a
lot
of
the
way
that
our
sidecars
work
wouldn't
be
able
to
work,
and
so
for
that
reason,
on
the
cozy
side,
we
decided
well
the
benefit
it
caught.
The
trade-off
is
is
not
sufficient
to
kind
of
push
through
that
crd
way,
so
we're
continuing
with
the
the
opaque
parameters
list
until
there's
a
better
solution:
okay,
but
I'm
not
sure
whether
the
trade-off
here
is
the
same
or
or
different.
B
Yeah
I
mean
we
absolutely
could
just
have
like
a
volume
data
source
crd
which
which
everyone
was
forced
to
use,
and
then
it
was
basically
a
string
map
and
you
had
to
basically
puzzle
out
from
the
string
map
what
you
were
supposed
to
do
and
that
would
sort
of
change
the
entire
approach
for
the
rest
of
this
as
well.
If
we
went
down
that
path,
because
then
we
wouldn't
need
a
controller
or
we
could
just
make
a
core
changes
that
this
is
something
you
know
that
I
guess
at
one
point.
B
Maybe
two
years
ago
there
was
a
proposal
to
have
like
some
sort
of
a
generic
populator
object
that
I
think,
would
have
looked
like
what
you're
describing
now
some
sort
of
just
a
string
map
kind
of
a
thing
and
that
you
would
have
to
figure
it
out
on
the
other
side.
But
I
really
like
the
the
more
of
a
structured.
You
know,
there's
multiple
different
crds
and
they
have
fields
that
are
defined
and.
D
B
Right
yeah
that
would
look
especially
weird
to
to
to
add
it
on
top
of
two
actual
objects.
So
I
like
to
I
like,
following
the
path
of
more
actual
objects,
just
open
up
the
door,
lots
of
them
yep.
I
agree,
okay,
so
so
we're
happy
with
the
idea
of
sticking
with
objects,
and
we
recognize
that
that
would
make
a
grpc
interface
awkward,
although
maybe
not
impossible.
So
so
it
feels
like
we're.
B
You
guys
would
be
okay
with
the
library
approach
or
at
least
exploring
that
more
more
deeply,
because
I,
like
I,
haven't
actually
written
the
prototype
for
either
of
the
two
I
just
started.
Thinking
about
you
know
what
would
a
grpc
interface
probably
look
like?
What
would
a
library
probably
look
like,
and
both
of
them
seem
possible
with
the
library
seems
like
less
less
work.
B
D
B
Grpc,
I
am
concerned
about
the
the
layering
that
might
evolve
like
once
you
have
a
library
you
could
have
a
you,
could
have
a
style
where,
like
you
take,
you
know,
your
plugin
starts
in
main
and
it
does
whatever
command
line
parsing
it
wants
to
do,
and
then
it
invokes
like
the
the
library's
sort
of
main
event
pump,
but
then
it
has
would
have
to
supply
all
these
like
callbacks
to
say
you
know
in
a
you
know,
for
basically
supply
handler
functions
for
all
the
different
events
that
could
occur
in
the
life
of
a
populator
and
then
have
implementations
of
those.
C
B
B
D
I
think
it's
a
detail
we
can
always,
I
think
we
can.
We
will
be
able
to
structure
and
design
libraries,
so
it
works
reminds
like
like
the
way
the
side,
cars
work
and
but
just
code
is
like
located
locally.
Maybe
we
will
be
able
to
do
that,
like
I
think
it's,
we
could
kind
of
try
that.
B
D
C
Yeah
yeah,
I
think
I
I
I
generally
agree
with
alexi
I'd
say:
let's
one,
you
know
optimize
for
speed
of
development,
which
means
let's
go
down
the
library
path
and
two
as
a
north
star,
let's
at
least
keep
the
option
of
introducing
a
sidecar
in
our
future,
and
that
would
mean
that,
as
we
introduce
this
library,
let's
kind
of
structure
it
in
a
way
where
it
would
be
possible
to
extract
it
out
as
a
sidecar
versus
completely
not
doing
that
and
then
realizing.
We
have
to
re-architect
everything
later.
B
D
B
But
like
so
so
what
will
fundamentally
need
to
happen
is
like
the
the
populator
code
will
have
to
tell
the
library
code
or
sidecar
code
like
here's,
my
pod
definition
or
something
like
a
pod
definition,
and
so
then
you're
also
passing
at
least
at
least
a
template
or
a
part
of
a
pod
definition
from
you
know.
Through
this
interface
I
don't
know
how
much
flexibility
we'd
want
to
give
in
in
the
general
case,
but.
C
Got
it
yeah,
I
think
if
it
becomes
weird
and
odd
just
lean
towards
whatever
is
easier
for
development
and
for
those
edge
cases
that'll
be
the
those
will
be,
I
guess
the
decision
makers
as
we
can
reconsider
in
the
future
whether
we
want
to
go
downside,
car
or
not.
Okay,.
D
B
Used
cases,
so
I
wanted
to
get
it
into
that
in
my
next
topic,
but
just
to
just
to
mention
one
last
thing
about
the
the
one
obvious
downside
of
the
library
is
that
if,
if
bugs
are
found
and
fixed
in
the
library,
you'll
have
to
recompile
all
the
populators,
so
that's
that's
worth
calling
out
as
a
as
a
downside
to
a
library
is,
is
there's
some.
B
I
guess
I
don't
know
what
you
call
that
just
run
time
maintenance
issues
around
bugs,
but
but
yeah
I
I
I
did
want
to
get
into
the
what,
if
it's
not
a
populator
pod
case
and
then
in
particular
like
here,
we
get.
We
get
much
closer
to
specifically
talking
about
backups,
which
you
know
I
I
want
to
minimize
how
much
we
do
when
we
get
directly
in
backups
in
this
meeting,
because
that's
more
of
a
data
protection
topic,
but
backups
are
sort
of
my
my
my
example
for
thinking
about
this.
B
B
I
have
a
backup
object
right,
let's
say
somehow:
we've
arrived
at
a
place
where
there's
a
standard
definition
of
what
backups
are
and
lots
of
different
csi
plugins
are
creating
them
things.
You
know
we
have.
We
have
implementations
that
know
how
to
restore
from
them.
B
B
So
my
thinking
was
that
you
know
if
we
had
an
object
like
that,
where
we
wanted
there
to
be
multiple
ways
to
create
it
and
restore
it
or
populate
from
it.
We
could
do
it
in
a
way
where
we,
like
one
of
the
top
level
fields
on
the
so-called
backup.
Object
could
be
like
the
format
so
like
backups
could
have
a
format
and
one
format
could
be
like.
I
am
a
tarball
in
a
bucket
right
like
that.
B
But
there
could
be
other
formats
that
are
way
weirder,
and
so
what
you
could
do
is
you
could
have
on
your
crd
that
represented
your
backup.
You
could
have
a
top
level
field
called
format
and
then
individual
csi
plugins
that
wanted
to
implement
support
for
restoring
backups
could
have
a
list
of
formats
that
they
natively
understand
and
then,
when
you
got
a
request
to
create
a
volume
from
an
object,
you
know
normally.
B
The
first
thing
that
looks
at
that
is
the
external
populator
sidecar
and
today
you
know
it
knows
how
to
handle
empty
ones
and
ones
created
from
volumes
and
ones
created
from
snapshots,
and
one
could
imagine
in
the
future
once
created
from
backups.
But
you
could
have
special
code
for
backups
and
says:
okay,
you
know
if
it
is
a
backup
we're
going
to
look
at
the
format
field
of
that
backup
and
we're
going
to
ask
the
csi
plugin.
B
B
A
Do
you
mean
by
other
csf
function?
Are
you
talking
about
some
news
yeah.
B
B
So,
but
what
I'm
getting
at
is
that,
like
you,
could
have
a
field
on
the
backup
object,
which
was
the
format
and
you
could
structure
your
csi
interface
such
that
such
that
there
was
a
negotiation
between
the
sidecar
and
the
plug-in
for
the
format
and
only
if
the
csi
plug-in
says.
Yes,
I
know
how
to
restore
from
that
format.
B
Then
the
csi
plug-in
would
have
the
responsibility
for
creating
the
volume
through
the
normal
crate
volume
path.
You
know
you
just
supply
the
the
backup,
object
and
say
you
know
here:
go
restore
from
this
and
and
with
the
rest
of
it
would
be
the
csi
plugins
job
similar
to
like
how
it's
done
with
the
snapshot.
B
But
there
would
be
an
option
to
say
you
know
I
don't
support
that
format,
so
give
it
to
someone
else,
and
then
the
external
provisioner
sidecar
could
just
do
nothing,
and
in
that
case
it
would
be
the
you
know,
the
administrator's
responsibility
to
have
some
fallback
populator.
That
knows
how
to
handle
that
format
and
could
just
implement
it
for
all
of
the
storage
back
ends
that
didn't
natively
support
it.
B
D
I'm
not
sure
about
format
I
like
in
my
mind
I
have
maybe
maybe
it's
not
right.
Imagine
like
I
imagine
that
as
like,
we
would
have
probably
something
similar
to
what
ben
suggested
is
like
first
party
backups
and
third-party
backups.
So
first
party
is
like
storage
system
itself
knows
how
to
do
that,
and
the
third
part
is
like
obviously
it's
everything
else
and
basically.
B
So
so
so
that
will
exist
no
matter
what
we
build,
but
but
but
the
key
that
I'm
trying
to
tease
out
here
is
that,
like
whatever
you
build,
the
backup
is
in
a
certain
binary
format,
right
wherever
it
is,
and
if
we
can,
if
we
can
agree
on
at
least
some
formats
and
standardize
them,
it
creates
the
space
for
people
to
either
have
a
generic
implementation
that
works,
no
matter
what
the
storage
controller
or
what
the
storage
plug
plug-in
is
or
vendors
can
do
something
more
optimized.
If
they're
able
to.
D
I
was
more
like
under
pressure
that
I
I
wanted,
maybe
to
like
whoever
created
backup
is
actually
responsible
for
restoring
it.
So
if
you
use
specific,
like
backup
mechanism
to.
C
But
if
we
had
an
opportunity
to
potentially
make
a
given
backup
consumable
by
multiple
different
vendors,
that
that
could
be
valuable.
B
Might
be
a
trick,
so
it
may
be
the
case
that
the
vast
majority
of
formats
are
proprietary,
in
which
case
the
whole
scheme
degenerates
into
exactly
what
you
described.
Where
only
thing
that
created
it
knows
how
to
restore
from
it.
But
I
would
be
sad
if,
if
that
was
the
best
we
could
come
up
with,
because
I
I
like
the
idea
of
having
more
standardized
formats
where
you
know,
maybe
initially
the
only
implementation
of
it
is
some
general
implementation
in
a
pod.
B
That
knows
how
to
you
know,
create
and
and
restore
from
that,
but
if
we
define
what
the
format
is
and
someone
writes
down
somewhere,
you
know
a
spec
for
it.
Then
it
would
open
the
door
to
someone
having
a
better
implementation
of
the
same
format
and,
ultimately,
you
know
creating
some
collaboration
and
a
you
know.
Interoperability
between
systems-
and
you
know
in
my
my
really
simple
dumb
case-
is
you
know
a
tarball
in
an
object
store
right
like
you
can
write
down
what
that
is,
and
anyone
can
say.
D
Right
because
maybe
not
everyone
can
read
from
every
whatever
like
object,
storage
or
whatever
turbo
is
located.
So
it's
like
it's
getting
more
and
more
complicated.
This
way.
B
So
so
the
the
key
is
that
the
format
just
describes
what
it
is
and
then,
if
this,
if
the
plugin
thinks
that
it
knows
how
to
deal
with
that
it,
it
can
do
so
or
you
could
decide
not
to
and
and
and
you
could
have
in
like
if
one
imagines
you're
actually
designing
backup,
in
addition
to
the
actual
backup,
criter
there's
going
to
be
backup
classes
and
other
things
that
would
allow
an
administrator
some
administrative
knob
to
say.
B
I
want
this
backup
class
to
be
handled
by
this
specific
restorer
and
backer
upper
whatever
you
want
to
call
the
thing
that
creates
backups
and
like,
and
so
if
he
happens
to
know
that
you
know
what
all
my
backups
are
in
this
standard
format,
but
the
object
store
that
they
go
into
is
not
accessible
generically,
because
I
have
weird
firewall
rules,
then
they
could
just
decide.
Okay,
I'm
always
going
to
use
this.
This
particular
implementation,
regardless
of
the
sp
says
it
knows
how
to
handle
that
format.
B
But
if,
if
there
is
the
opportunity
for
things
to
inter-operate,
then
they
could
choose
to
do
it
differently,
and-
and
I
would
I
don't
know-
I
just
there-
are
some
formats
that
are
so
easy
that
that
it
feels
like
they
really
should
be
standardized
and
shared
across
multiple
implementations,
especially
for
like
a
raw
or
so
think
about
the
raw
block
case.
How
do
you
back
up
a
raw
block
device?
You
just
dd
the
bits
into
another
bag
of
bits
somewhere
right
like.
D
My
point
was
okay:
we
can
find
this
one
format,
which
is
which
is
like
portable,
like
cbt-based
format,
for
example,
right
and
say:
okay,
cbt-based
format,
but
we
know
that
we
have
a
pod
for
cbt-based
formats
and
it
can
handle
cbts.
D
But
as
we
take
like
first
first
party
party
backups,
like
gs,
gcs
or
sorry
pd's
in
google
ebs
in
amazon,
they
all
have
like
proprietary
formats,
I'm
pretty
sure,
like
many
first
party
storages
who
do
backups,
they
have
their
own
format.
So
this
will
make
our
generalized
format
like
format
list
like
pretty
big,
and
the
only
reason
for
that
will
be
only
one
storage
will
support
that
specific
format.
So,
in
that
case,
like
it
kind
of
doesn't
make
a
lot
of
sense.
In
my,
in
my
opinion,.
B
C
D
B
And
then
and
yeah
at
the
beginning,
I
I
absolutely
believe
that,
yes,
each
implementation
will
support
exactly
one
proprietary
thing,
but
I
just
I
I
would
just
be
sad
if,
if
like
that's
the
best
week,
you
know
if
that's
where
we
ended
up
at
the
end,
where,
like
everything
was,
was
proprietary
and
not
interoperable
and
your
backups.
D
I
think
my
point
here
I
I
I
totally
I
I
like
your
idea
about
having
generalized
like
portable
format,
what
I'm
saying
like
we
can
have.
We
can
standardize
like
one
portable
format,
and
we
say
this
format
is
portable.
It's
let's
say
like
just
right,
cbt
based
and
if
you
want
to
make
portable,
yes,
you
can
do
create
portable
backups
and
restore
them
in
on
almost
any
storage
system.
Right
so.
B
So
so
here
we
are
getting
into
the
the
specifics
of
backup,
which
I
don't
want
to
do,
but
but
I
also
don't
think
that
it's
wise
to
to
believe
that,
like
we
will
choose
the
right
standard
format
because
that's
a
whole
difficult
problem
on
its
own,
and
I
would
rather
create
a
place
where
multiple
standard
formats
could,
in
theory
compete
and
the
best
one
could
win.
B
If,
if
such
a
thing
could
happen
and
cbt
does
sound
like
a
relatively
good
way
to
do,
generic
interoperable
backups,
like
you,
know
the
ones
I'm
describing
like
bag
of
bits
for
raw
block
volume
or
tar
balls
for
a
file
system
volume,
those
would
have
bad
performance
because
they're
fundamentally
not
incremental.
B
You
know
they're
always
full
copies
of
your
data,
and
you
know
there's
reasons
why
that's
not
a
good
way
to
do
backups
in
general,
but
but
but
they're
they're
really
easy
to
understand,
which
is
why
I
like
to
throw
them
out
there,
like
the
change
block
tracking,
it's
like
well.
What
is,
how
exactly
is
that
work?
You
know
you
have
to
define
it
and
has
to
be
a
spec
like
tar.
Balls
are
a
million
years
old,
so
it's
not
a
there's,
not
a
question
of
what
that
means.
B
So
I
yeah
so
so
getting
back
to
the
the
data
populator
specific
part
of
this
question,
the
main
thing
is
like.
I
think
it
would
be
smart
to
have
sort
of
a
way
for
there
to
be
two
different
data
populators
that
both
understood
the
same
crd
and
had
a
way
to
sort
of
arbitrate
between
them.
Who
was
going
to
actually
do
the
population
and-
and
so
my
my
example-
is
for
backups.
B
The
way
you
could
do
that
is
just
have
a
format
field
and
then
have
the
administrator
define
or
have
the
plugin
have
an
interface
to
to
to
tell
it.
You
know
what
formats
do
I
support
and
that
you
could
use
that
as
a
arbitrator
to
say.
Okay,
I
have
two
populators,
but
ones
with
format
x
are
going
to
be
handled
by
populator,
a
and
ones
with
format.
Y
are
going
to
be
handled
by
populator
b
and
then
and.
B
And
we
should
we
should
I
just
I
wanted
to,
because
I
think
shin
was
interested
in
this,
in
particular
like
like
what
what
what
about
the
ones
where
we
don't
want
to
have
a
you
know,
a
full-blown
pod
do
the
work.
So
so
I'm
trying
to
imagine
you
know
an
example
of
a
of
a
crd
where
you
know
when
it's
time
to
do
the
population.
B
We
don't
want
to
just
have
an
ordinary
populator
spin
up
a
pod
on
a
fake
pvc
and
write
the
data
into
there
and
then
rebind
the
pv,
which
is
what
the
standard
library
would
do
like
what
you
know.
If
we
had
something
where
you
the
you
wanted
to
implement
it
in
csi,
you
would
have
an
extension
to
csi
and
you
would
have
the
code
for
that
specific
populator
go
into
the
external
provisioner
sidecar.
D
D
B
You
know
to
create
a
fake
pvc
in
another
name,
space
to
spin
up
a
pod
that
does
the
actual
work,
and
then
you
rebind
the
the
pv
that
pvc
gets
bound
to
back
to
the
original
pvc
and,
like
that's,
that's
one
standard
workflow,
the
second
one
is
you
just
extend
external
provisioner
to
understand
a
new
type,
an
external
provisioner
does
what
it
normally
does,
where
it
just
handles
that
type
and
passes
the
relevant
bits
through
the
csi
interface
to
a
csi
plugin
that
does
all
of
the
work.
What
is
the
third
case?
A
So
well
our
case
right
now.
Basically,
what
about
what
we
do
right
now,
since
we
don't
have
this
any
voting
data
sort
yet
data
source.
Yet
so
we
first
call
csi
driver
to
publishing
empty
pvc,
and
then
we
use
that
we
populated
public
data.
So
if
we
have
this,
then
we
can
have
this.
A
C
B
A
A
A
A
B
This
that
can
solve
my
problem:
okay,
well,
yeah
and
and
the
way
you
solve
it-
is
with
the
the
fake
pvc
prime
and
then
you
do
all
the
population
on
the
pv.
And
then
you
do
the
rebind
and
that's
that's
sort
of
the
trick
that
lets.
You
have
a
working
pvc
that
that
goes
all
the
way
through
the
path
of
external
provisioner
to
create
create
it,
but
any
pods
still
can't
bind
to
it,
because
the.
A
Pvc,
but
if
we
have
this,
why
can
we
just
hold
it
like
saying
you
know
wait
until
so,
so
basically
we
don't
bind
them
right,
basically
wait
until
this
pv
is
populated,
and
then
I.
D
B
You
don't
want
to
rely
on
init
containers
because,
because
like
there
may
never
be
a
pod
right,
someone
could
just
create
the
volume
and
then
take
a
snapshot
of
it
before
there's
ever
a
pod
and
expect
that
snapshot
to
have
the
populated
data
in
it
and
and
there's
problems
when
you
have
like
you
know,
read,
write
many
pvcs
and
there's.
There
are
multiple
pods
that
are
all
trying
to
connect
to
there's
just
a
lot
of
really
ugly
issues
that
manifest.
B
If
you
try
to
sneak
this
population
process
into
like
the
first
pod
to
access
the
pvc
model,
I
I
really
like
I'm
so
so.
The
I
think
what
ching
is
proposing
is
like
an
entirely
different
way
to
sort
of
have
maybe
a
some
change
at
the
kubernetes
api
layer
that
tells
cubelet
like
you.
You
know
this.
Pvc
is
only
half
or
this
pv
is
only
half
created
and
therefore
you
know
it's
bound,
but
it's
not
usable
well.
A
I'm
saying
that
is
it
possible
that
we
don't
bound
it?
We
just
we
wait
until
we
populate
data
to
the
pv.
D
C
Yeah
showing
the
behavior
that
you're
describing
there
you
know
this
is
just
an
implementation
detail
of
how
to
get
that
behavior.
There
are
potentially
other
ways
to
get
that
behavior.
This
appears
to
be
the
cleanest
and
most
robust
one
such
that.
If
you
know
one
of
the
controllers
dies
in
the
middle
of
processing,
it
would
be
able
to
recover.
A
Yeah
yeah
how
to
sing
think
about
it,
because
yeah
right
now,
we
basically
just
hold
the
hold
off
the
pod
until.
B
C
B
A
To
pvc
pi,
if,
if
we
create
the
pvc,
if
it's,
if,
if
the
provisional,
if
the
external
provision
does
not
handle
it,
then
it
shouldn't
be
bound
yet
right,
right.
B
A
A
Fine,
it
doesn't
have
the
scope,
so
so
how
about
I
was
when
you
think,
can
we
actually
just
this
popular
can
by
decease
the
source?
It
just
create
a
blank
pvc
first
and
then.
A
A
A
B
Yeah,
so
so,
so
what
did
what
the
data
populator
would
do
in
response
to
that
pvc?
Is,
it
would
create
pvc
prime
it
would
it
would
be,
it
would
be
the
same
except
that
there'd
be
no
no
data
source
on
it,
so
it's
empty
and
and
then
the
external
populator
will
respond
to
that
one
by
creating
an
empty
volume
and
binding
it
to
pvc.
B
Prime,
then
your
populator,
could
you
know
in
the
the
first,
the
first
example
you
know
that
I
described
or
the
use
case
number
one
is:
is
the
you
just
go
ahead
and
create
a
pod
to
bound
to
pvc?
Prime
that
does
the
population
you're
saying?
No,
I
don't
want
to
use
a
pod.
My
popular
will
then
take
the
pv
that
gets
bound
to
pvc.
B
Prime
and
somehow
look
at
the
details
of
that
pv,
and
it
knows
how
to
go
straight
to
the
storage
controller
and
figure
out
which
volume
that
is
and
then
it
can
directly
put
the
data
on
it.
That's
sort
of
what
you're
describing
is
after
you
have
an
empty
volume.
You
can
go
find
it
on
the
real
back
end
and
put
the
data
on
it
somehow,
without
using
a
pod
without
using
csi
right.
A
C
A
D
B
D
B
A
B
A
A
B
So
so
that
that
would
be
the
other
benefit
of
this
design,
I
think
is,
is
you
could
you
could
if
the
pod
was
like
a
weight
for
first
or
sorry
if
the
pv,
if
the
original
pvc
was
away
her
first
pvc
or
wait
for
first.
B
And
you
could
sort
of
postpone
the
entire
invocation
of
the
population
process
until
after
there
was
a
pot
and
after
it
had
been
scheduled
and
then
you
may
still
have
a
pod
that
gets
scheduled
to
the
node
for
the
population,
but
it
could
be
a
dummy
pod
right.
It
could
just
be
a
pod
that
calls
sleep
and
and
it
and
and
then
then
the
real
population
happens
directly.
B
D
B
Yeah
yeah
something
well
I
don't
know
if
you,
if
the
populator
can
from
this
from
the
pv
definition
figure
out
what
to
do.
Then
you
don't
really
need
the
pod
to
do
anything
other
than
exists
on
a
node.
Oh
actually,
all
it
needs
is
to
get
scheduled
like
once.
The
pod
has
been
scheduled
and
then
you
can
and
the
rest
of
the
logic
that
ensures
that
the
that
the
csi
plug-in
that
that
does
provision
the
empty
volume
is
past.
The
correct
topology
information.
That's
all
that's
really
necessary
right,
but.
D
C
Yeah,
I
don't
see
the
hesitation
against
having
the
pod.
It
seems
like
it's
a
life
cycle
hook.
Basically
right
it's
like
saying:
okay,
we
have
created
the
appropriate
empty
volumes
and
now
in
the
life
cycle,
we
need
something
to
populate
this
volume.
So
we're
going
to
kick
off
a
pod,
the
populator
pod,
whether
the
populator
pod
does
the
population
directly
and
locally
is
an
implementation
detail
of
the
populator
or
it
can
certainly
call
out
to
the
back
end,
and
you
know
have
that
as
the
trigger.
C
D
A
Yeah,
I
think
that's
fine.
I
was
a
yeah,
I
mean
yeah,
even
though
we
don't
require
it,
but
if
there's
a
scheduling
piece
actually
require
a
part
to
be
there,
then
I
think
that's
fine.
A
B
Well,
so
I'll,
I
don't
know
what
what
we
need
to
discuss
in
the
next
meeting
other
than
and
I
need
to
actually
make
more
progress
on
prototyping
I've
been
I've
been
busy
doing
a
few
other
things,
but
I
will
write
up
the
notes
for
this
meeting
and
we
can
tentatively
plan
on
meeting
again
next
week
and
I
don't
know
if
we'll
have
any
new
agenda
items
by
then,
because
it
feels
like
we're
aside
from
getting
getting
the
code
written
and
some
maybe
updating
the
cap
and
various
specs.
B
You,
if
you
guys
have
any
remaining
questions,
please
put
them
on
the
agenda
for
next
week,
because
I
am
running
out
of
things
to
things
to
discuss.
I
feel
like
I
just
have
to.
I
need
to
start
coding
soon
sounds
good.
Thank
you
for
driving
this
yeah.
Thank
you
guys.
This
has
been
really
helpful.
Just
to
talk,
talk,
talk
everything
through.