►
From YouTube: Summit 2022: Volume populator support
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I'm
pleased
to
introduce
michael
he's
going
to
present
the
role
to
volume,
populators
he's
going
to
talk
about
creating
persistent
convert
disk
the
past
present
and
future.
Thank
you
michael.
It's
only
you
know.
B
Thank
you,
marcelo,
hey
everyone
thanks
for
joining
me,
those
of
you
on
the
us
east.
I
hope
you
are.
This-
will
be
a
good
presentation
to
eat
lunch
too.
I
hope,
okay,
so
the
road
to
volume,
populators
creating
persistent
keywords,
is
past
present
and
future.
B
So
this
presentation
is
basically
about
the
fact
that
kuber
cdi
will
be
supporting
volume
populators
for
initializing,
your
kuber
disks.
How
does
this
compare
to
the
existing
data
volume
api
and
you
know
what
to
do
about
that?
You
know.
What's
the
future,
for
both
of
these
things,
volume,
populators
and
data
volumes,
and
hopefully
we'd
like
to
get
some
ideas
from
you
in
the
community
right.
So
I'm
a
bit
back
in
the
beginning
of
thecube
project.
B
You
know
we're
basically
running
virtual
machines
and
kubernetes
virtual
machines
are
typically
stateful
workloads.
You,
you
know
if.
B
And
start
it
back
up,
you
probably
want
the
same
data
that
was
there
when
you
stopped
it
so
so
stateful
workloads
and
kubernetes
means
persistent
volume
claims,
but
persistent
bond
claims
are
initially
empty
and
hypervisors
need
something
they
need
disk
image
files
or
they
need
devices
that
look
like
this
commit
that
look
like
disks
that
basically
have
operating
system
files
that
you
can
boot
from.
B
B
Thing
we
considered
was
knit
containers.
So
for
those
who
don't
know
you
know
kubernetes
vms
run
in
pods
one.
The
main
container
is
running
basically
qmu,
with
your
virtual
for
your
virtual
machine
to
communicate
with
kvm
and
host
blah
blah
pods
can
have
an
ink
container,
so
init
containers
run
before
the
main
container.
B
Theoretically,
we
could
do
whatever
we
wanted
to
do
in
these
init
containers.
We
could
populate
them
at
that
point
and
have
everything
ready
for
qmu
and
that
was
explored,
but
it
was
kind
of
not
a
great
match.
A
little
awkward
I
mean
when
you
configure
your
virtual
machine,
your
create.
We
have
a
virtual
machine.
B
Crd,
we
have
a
virtual
machine,
instant
crd,
you
know
any
containers
are
things
on
pods.
What,
if
you
have
a
bunch
of
them?
Your
images,
it's
a
little
awkward
and
the
other
thing
that
was
made
them
a
little
tough
to
deal
with
was
the
fact
that
we
want
basically
this
population
phase.
We
want
this
pvc
to
initialize
it
to
be
initialized
once
the
first
time
the
vm
has
started
or
the
first
time
the
volume
is
used.
B
B
Enter
data
volumes,
so
we
needed
something
again.
This
was
a
while
ago
and
we
figured
that
creating
our
own
custom
resource
would
be
the
best
way
to
go
at
least
at
that
point
in
time.
So
we
created
this
data
volume
abstraction
it
has
essentially
two
jobs.
B
Is
to
populate
that
pvc
with
some
source
from
some
source,
but
simultaneously
we
always
knew
that
kubernetes.
This
is
a
problem
that
a
lot
of
people
are
going
to
have
in
kubernetes.
So
we
at
that
time
went
to
the
sig
storage
kubernetes
upstream
community
and
began
a
discussion
for
you
know.
What's
a
generic
solution
for
this,
and
actually
someone
from
the
cubert
cdi
team
was
the
first
to
propose
a
cap
for
volume
populators.
B
So
data
volumes
were
our
thing.
We
could
do
right
away
yet
we
still
wanted
to
participate
in
the
community
to
have
something
upstream.
They
fixed
a
more
generic
problem.
Okay,
so
I
mentioned
the
data.
Volume
has
two
jobs.
The
source
section
of
the
data
volume
spec
specifies
you
know
what
we
want
on
that
pvc,
and
in
this
case
you
want
to
download
a
file
that
has
a
seros
image.
B
A
B
Specifies
what
the
pvc,
the
data
bottom
controller,
will
create
a
pvc
on
your
behalf.
B
So
the
pvc
section
spec.pvc,
is
the
precise
configuration
we
also
have
the
spec
dot
storage,
which
will
do
some
defaulting
for
you
via
storage
profile
storage
profiles
are
key
vert
option
that
basically
the
storage
profile
for
each
storage
class
and
we'll
choose
say
the
best
access
mode
for
you.
If
you
leave
it
out
of
your
data
volume
spec,
so
there's
some
defaulting
done
there
and
it's
kind
of
nice.
You
know
less
things
to
know
the
better
all
right
and
the
data
volume
status.
B
So
I
said
the
data
volume
has
essentially
two
jobs,
and
this
is
where
you
can
track
the
status
of
those
things.
So
the
phase
is,
you
know
it
succeeded
when
it's
done.
There
are
different
phases
based
on
the
different
source
types
progress.
Some
source
types
will
support
an
incremental
progress
meter.
B
Okay,
so
we're
going
to
go
through
what
happens
when
you
create
a
data
volume
in
a
virtual
machine
instance.
You
know
you've
posted
these
two
manifests
to
a
cluster.
What
is
going
on
behind
the
scenes?
What
is
the
synchronizations
so
at
this
point,
you've
just
posted
a
day
volume
manifest
and
virtual
machine
instance
manifest
they're
both
pending
next,
the
data
volume
controller
sees
this
data
volume
manifest,
and
it
will
create
a
persistent
bond
claim
per
whatever
you
specified
in
the
data
volume.
B
B
So
the
data
bomb
controller
sees
that
okay,
I've
created
this
pvc.
I've
created
this
pod
and
it's
running
my
face
is
important
progress
so
to
a
user
that
is
watching
this.
They
can
see.
Oh
the
import's
in
progress.
You
know
it's
doing
its
work.
The
controller
doesn't
really
care
about
import
and
progress.
It
is
still
pending.
It's
waiting
for
data
launch
to
be
complete
before
it
does
anything
before
it
can
start
running
this
virtual
machine
instance.
B
B
Runs
qmu
so
that
pod
will
mount
the
pvc
that
has
some
freshly
mounted
data
freshly
configured
data
and
now
the
virtual
machine
instance
is
scheduling.
B
And,
finally,
the
virtual
machine
instance
is
running,
the
pod
is
running
and
this
is
kind
of
the
final
state.
A
couple.
Well
one
thing:
one
important
thing
to
note
is
that
the
data
volume
kind
of
has
no
not
much
of
a
purpose
at
this
point.
It's
done
its
job.
However,
you
can't
delete
it
because
it
owns
the
pvc
which
you
know.
Maybe
it's
fine,
maybe
it's
a
bummer
or
some
people,
but
that's.
B
So
that
is
kind
of
flow
data
populator
with
data
volumes.
I
think
that's
most
people
maybe
know
this
okay,
so
enter
data
enter
volume
populators.
So
while
we
were
using
data
volumes
happily
and
the
community
was
slowly
making
progress
on
volume,
populators
and
we're.
Finally,
there
flying
populators
will
be
beta
and
kubernetes.
124.
B
previous
versions
can
use
the
any
volume
data
source
feature.
Gate
populators
will
work
best
with
csi
pvcs
because
well,
if
you're,
using
a
csi
pvc
you're,
probably
using
the
csi
sidecars
that
are
provided
by
the
sig
storage.
So
they
know
how
to
deal
with
this
data
source
rep,
which
is
basically
to
do
nothing.
B
Other
provisioners
you
know,
can
handle
it
as
well,
but
it's
more
likely
to
have
luck
with
csi
volumes
and
there
is
a
pretty
cool
library
called
the
volume
populator.
That
makes
it
relatively
easy
to
create
controllers
to
create
your
own
populator
and
I'll,
be
showing
a
demo
of
using
that
library
to
create
essentially.
B
Okay,
so
yeah?
What
I'm
going
to
show
here
is
basically
in
a
populator
world
what
we
did
with
data
volumes
before
so
this
is
the
equivalent
of
the
previous
flow
with
date,
with
the
data
volume
you
know,
in
the
data
volume
it
was
going
to
one
stop
shopping,
where
you
had
one
resource
that
had
your
pbc
deaf
and
your
source
with
populators,
it's
a
little
different,
so
we
create
a
pvc
directly
that
has
a
data
source
ref
to
this
populator
resource.
B
You
know
an
api
group
populator
cbi.keyboard.io
import,
zeros
import,
so
that's
basically
it
it
may
look
a
little
weird
to
you.
Data
source
ref
doesn't
a
doesn't
a
pvc
already
have
a
data
source
field
and
you
are
right.
The
data
source
field
is
currently
used
for
creating
a
pvc
from
a
volume
snapshot
or
from
another
pvc,
but
because
of
weird
behavior
that
has
been
around
for
a
while.
B
Essentially,
the
csi
provisioner
would
ignore
a
data
source
that
was
not
a
volume,
snapshot
or
persistent
volume
claim
so,
and
it
would
just
provision
the
volume
and
apparently
some
people
in
the
world
were
taking
advantage
of
that,
and
rather
than
make
those
people
very
unhappy,
the
decision
was
made
to
add
this
data
source
ref
field
instead
and
deprecate
data
source.
So
eventually
everything
will
be
going
through
data
source,
ref.
B
Okay-
and
this
is
the
volume
populator
custom
resource
which
is
essentially,
you
could
think
of
the
source
section
of
the
data
volume
you
saw
earlier
we're
going
to
grab
a
file
from
a
url.
There
will
be
different
populator
custom
resources
for
import
clone
upload,
okay.
So
this
is
the
difference
in
the
flow
here,
in
this
case,
we're
creating
a
pvc
and
a
virtual
machine
instance
that
references
that
pvc,
initially
everything
is
pending.
Okay,
so
we've
got
a
couple
concurrent
things
going
on
here.
B
So
in
namespace
ns1,
the
vert
controller
is
going
to
start
the
vert
launcher
pod
up
right
away.
It
has
it
as
far
as
it's
concerned.
You
know
it
doesn't.
B
B
Running
in
this
ns2,
that
is
watching
for
pvcs
that
are
getting
created
and
it
sees
this
one
you
know
and
it
will
create
a
pvc
called
pvc
one
prime.
It
looks
just
like
pvc
one
except
it
does
not
have
the
data
source
ref,
so
it
should
bind
right
away
and
we
see
that
there
is
a
p
a
pv
created
up
here.
B
B
B
B
B
B
B
Okay,
so
right.
B
So
we're
going
to
apply
this
manifest
here
so
in
here
we've
got
a
couple.
Things
first
is
this:
this
is
the
populator
custom
resource
that
we
saw.
Referencing
url
here
is
the
pvc
that
is
referencing.
That
populator
and
down
here
is
a
virtual
machine
instance
that
is
referencing
that
ppc
and
yeah.
A
B
Populator
was
created
with
that
library
and,
let's
see
if
it
works,
and
these
other
consoles
over
here
will
watch
pvcs.
B
So
we
should
okay,
we
see
a
pvc
is
pending,
we
see
the
vm
is
scheduling.
What
we'd
like
to
see
next
is
pvc
gets
bound?
Okay.
Now
we
see
the
pvc
is
bound
and
the
vm
is
scheduling.
A
B
Quite
easy
to
put
together
all
right
so
now
you
may
be
thinking
wow.
Okay,
we've
got
data
volumes,
we've
got
populators,
that's
two
ways
to
do
the
same
thing:
that's
typically
not
a
great
place
to
be
in
software
engineering.
So
let's
this
is
where
I
want.
You
know
the
community
and
to
get
together
to
maybe
help.
Oh,
let
me
stop
sharing.
Let
me
go
back
to
my
slides.
B
B
B
You
know,
pvc
state.
This
is
basically
a
boolean.
That's
either
it's
bound
or
it's
not.
There
are
no
conditions,
there's
not
much
there.
So
with
populators
supporting
something
like
a
percentage
progress
we've
got
to
think
about
and
yeah.
Similarly,
they
both
have
these
conditions,
which
are
nice,
but
there
are
some
cons
with
data
volumes
that
whole
synchronization
step
is
a
bit
of
a
bummer,
and
I
didn't
even
get
into
the
weight
handling
wait
for
first
consumer,
which
is
pretty
much
a
presentation
on
its
own.
It's
very
complicated.
B
A
B
A
B
And
they're
tricky
to
back
up
and
restore.
You
know
right
now
we're
talking
to
backup
integrators,
and
you
know
a
lot
of
the
work
is
around
handling
and
the
right
way
to
make
them
restore
correctly.
B
We
wrote
a
custom
valero
plug-in
for
this,
for
example,
and
it's
basically
about
managing
data
volumes,
so
volume
populators
pros
community
standard.
We
finally
got
here.
It's
been
a
long
road,
but
it's
nice
that
we're
here
you
can
create
your
own
populator
using
that
library
pretty
easily.
Let's
say,
for
example,
you
have
disk
images
and
bittorrent
that
you
want
to
download
write.
B
Or
you
know
you
can
use
it
right
away
like
I
just
did
and
I
think
the
shared
configuration
is
kind
of
a
nice
thing.
Basically,
rather
than
having
a
url
and
100
different
resources,
you
have
a
url
in
one
place
and
reference
that
resource
that
has
the
url
the
cons,
minimal
status
and,
as
I
said
earlier,
not
all
provisioners
will
work
with
populators
just
yet.
I
think
that
will
change,
but
I
think
like
for,
for
example,
like
local
storage
provisioner,
I
don't
think
works
right.
B
So,
what's
coming
up
the
kuvert
cdi
team
plans
to
release
populators
for
each
of
the
existing
data
volume
sources.
B
We
hope
you
build
your
own
populators
we'd
love
to
hear
about
keyboard
populators
being
distributed
in
the
wild.
That
would
be
great
and
the
daily
volume
controller
will
be
updated
to
use
populators
internally.
B
The
timing
on
that
may
be
a
little
weird
because,
because
well
not
all
provisioners,
I
think
all
of
our
supportive
prisoners
necessarily
will
work
with
populators
just
yet,
but
that
will,
I'm
sure,
will
change
eventually.
So
this
is
where
we
kind
of
want
to
discuss
with
the
community.
You
know:
we've
got
these
two
we've
got
populators
we've
got
data
volumes.
Where
do
we
want
to
go?
B
Is
there
still
value
in
data
volumes?
Should
we
tweak
them
a
little
bit?
B
Maybe
that
owner
reference
thing
you
know,
maybe
you
should
be
able
to
delete
a
data
volume
once
it's
been
populated
stuff
like
that,
maybe
we
should
have
some
new
resource
as
a
data
volume
replacement
or
maybe
we'll
just
get
rid
of
them,
but
you
know
that
may
be
difficult
because
well,
for
one
reason,
data
volumes,
specs
are
part
of
vm
specs
in
the
data
volume
template
section,
so
that
could
be
quite
quite
it'd
be
hard
to
get
rid
of
them.
But
this
is
where
we
want
to
talk
about.
B
You
know
what,
where
do
we
want
to
go
as
a
community
with
data
volumes
and
populators?
I
think
that
the
populators
solve
a
lot
of
the
nice
techno
technical
challenges
like
way
for
first
consumer,
and
I
think
the
back
they're
you
know
easier
to
back
up.
So
I.
A
B
A
Thank
you,
michael
for
the
very
interesting
talk
you
know
I
I
was
very
you
know
surprised
with
that.
It
was
very
interesting,
especially
for
you
know,
performance
standpoint
that
you,
you
create.
You
know
the
virtual
launch
report
before
and
you
let
all
the
containers
be
initialized
that
I
showed
my
previous
presentation
that
it
can
takes
a
lot
of
time
and
if
you
can
do
that
in
parallel,
it's
awesome.
So
it's
very
interesting.
So
let's
see
that
we
have
some
questions
here.
A
So
daniel
asked
what
other
protocols
are
supported
for
volume
of
populators.
Besides
http.
B
So
I
guess
for
official
kubert,
you
know,
data
volumes
will
support
http
as
well
as
I
guess
registry
imports.
So
you
can
com
import,
a
disk
image
that
is
in
the
container
registry.
But
there's
really
you
know,
there's
no
limit
to
what
you
know.
You
can
do
whatever
you,
whatever
you
can
do
in
a
pod
and
write
to
a
pvc,
but
I
think
you
know
we're
going
to
support
and
everything
we
do
now,
which
is
basically
importing
from
a
registry
uploading
from
your
desktop
copying.
Other
pvcs.
A
Okay,
so
jennifer
also
asked
a
question:
if
de
la
volumes
went
away,
what
would
a
clone
workflow
look
like
create
pvc
with
volume,
populator
source
creates
volume
snapshot
and
a
new
pvc
reference.
This
next
shot
yeah.
So
this
this
gets
back.
B
To
some,
at
the
same
time,
we
started
talking
volume
populators
with
the
community.
We
started
talking,
namespace
transfer
and
their
volume
populator
has
progressed,
you
know
it
progressed.
It
took
three
years,
but
we
got
here.
Unfortunately,
the
whole
namespace
transfer
thing
is
still
under
discussion
and
there's
not
a
consensus
there.
So
there
will
be
a
a
clone
populator
and
I
think
it
will
work
pretty
much
exactly
like
data
volume.
B
The
existing
data
volume
populator
that
will
do
all
the
snapshot
stuff
under
the
covers,
so
that
that
will
be
there.
Some
of
the
authentication
stuff
will
change
a
little
bit
like
now.
If
you're
cloning
between
namespaces,
we
do
weird
auth
checks,
but
we're
gonna
have
an
alternative
way
of
doing
that.
B
There
will
be
a
clone
populator,
but
if
you
want
to
use
the
sort
of
kubernetes
primitives
that
that's
fine
too.