►
Description
Kubernetes Storage Special-Interest-Group (SIG) Volume Populator Design Meeting - 18 May 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
So
hello,
this
this
is
the
sig
storage
volume,
populators
weekly
meeting.
We
have
a
short
list
of
attendees
today,
it's
just
me
and
shane,
but
the
good
news
is.
We
were
able
to
get
api
reviewers
to
approve
the
cap.
Last
week
we
got
pr
reviewers
to
approve
the
updated
version
of
it.
A
The
the
important
thing
for
people
to
know
is
that
the
tim
in
particular
was
not
satisfied
with
our
original
approach
to
backwards
compatibility,
even
though
everyone
agrees
that,
like
there
is
no
way
someone
could
intend
to
want
the
old
behavior
that
the
data
source
field
has
where,
if
you
put
garbage
into
it,
it
just
gets
ignored.
A
The
api
team
is
has
taken
an
absolute
stance
to
backwards
compatibility,
and
so
they
don't
want
to
even
have
the
possibility
of
breaking
anything.
So
so
tim
proposed
a
different
way
of
sort
of
getting
around
this
problem,
while
still
arriving
at
a
fairly
clean
api
in
the
long
run,
which
is
to
over
time
to
deprecate
the
existing
data
source
field
and
replace
it
with
a
new
one
called
data
source
ref
that
that
basically
never
ignores
user
input.
A
You
either
will
get
an
error
or
it
will
accept
the
data
source,
and
then
we
have
to
do
a
bunch
of
work
inside
cube
api
server
to
actually
to
implement
this.
A
So
for
reference
here,
I
wanted
to
show
that
the
original
two
pr's
that
that
we
had
were
both
closed
without
merging
one
of
these
was
just
going
to
bump
the
volume
populators
feature
to
beta
and
the
other
one
was
going
to
split
out
a
separate,
kept
to
deal
with
the
backwards,
incompatible
change
and
that
that's,
where
sort
of
all
the
discussion
happened.
So
on
this,
I
think
it
was
2552.
A
I
think
there
was
a
long
discussion
with
the
api
reviewers
and
we
went
over
a
couple.
Different
proposals
option
one
option:
two
option:
three:
we
ended
up
choosing
option
three,
but
all
these
threads
are
here
for
for
people
to
go
back
and
look
at
the
history
of
how
we
made
the
decision
so
yeah.
The
anything
we
did
was
gonna
sort
of
leave
some
cruft
in
the
api
in
the
long
term,
and
we
decided
that
this
was
sort
of
the
cleanest
way
to
do
it.
We
ended.
A
I
ended
up
creating
two
more
prs
that
were
the
ones
that
were
actually
merged.
One
of
these
was
basically
a
rewrite
of
the
original
volume
populators
cap
to.
I
changed
all
the
language
to
talk
about
this
new
data
source,
ref
field
and
talked
about
you
know
using
you
know
doing
that
conversion
as
part
of
this
cab,
so
we
will
use
the
same
feature
gate
the
any
volume
data
source
feature
gate
to
control
this
new
data
source
ref
field,
and
it
will
be
alpha
in
122,
because
we
can't
jump
straight
to
beta
with
a
new
field.
A
But
but
I
think
I
think
that
everyone
is
sort
of
okay
with
his
plan
and
oh
and
then
and
then
the
other
cap.
That
merged
was
just
the
the
fix,
because
I
failed
to
set
things
from
beta
back
to
alpha
correctly,
and
so
it
was
not
being
tracked
and
we
had
to
file
a
second
pr
to
do
that.
A
That's
what
the
2742
is
so
so
that's
in,
and
that
means
in
the
122
time
frame
I'm
going
to
be
implementing
this
data
source
ref
field,
and
I
just
wanted
to
to
sort
of
talk
about
it
in
more
detail.
If
you
wanted
to.
B
I
think
we
should
actually
brought
this
up
in
the
in
tomorrow's
daily
production.
When
group
meeting
that's
a
good
idea.
I
don't
want
people
to
get
panic
because,
because
when.
B
B
A
A
So
here's
how
I
was
gonna,
here's
how
I
was
gonna
present
it.
So
in
122
we
introduced
this
new
field
as
alpha
behind
the
behind
the
existing
feature
gate
in
123.
We
would
promote
it
to
beta,
so
by
default,
be
on
and
people
would
see
it,
but
everyone
would
continue
using
the
existing
data
source
field
in
124.
A
Assuming
we
don't
have
any
problems.
You
know
we
promoted
to
ga
and
at
that
point
we
would
deprecate
data
source.
It
would
continue
to
work
exactly
how
it
does,
but
if
you
used
it
with
124
or
later,
you
would
get
a
deprecation
warning
and
then
starting
with
either
124
or
125.
I'm
not
sure
when
we
would
do
this.
We
would
probably
update
the
external
provisioner
side
card
to
start
consuming
the
data
source
ref
field
instead
of
the
data
source
feature
well.
B
A
B
B
A
If
a
user
creates
a
pvc
with
a
data
source,
the
kubernetes
admission
hooks
will
copy
the
contents
of
data
source
to
data
source
ref,
so
that
anyone
using
data
source
ref
will
see
the
correct.
Oh.
B
Okay,
there
is
a
nurse
okay,
so
there
was
a
and
I'm.
B
I
just
want
to
make
sure
that,
okay,
that,
let's
don't
talk
about
experiments,
so
let's
say
even
if
we
change
external
provisional
to
use
the
the
ref
people
can
continue
to
use
the
data
source
field
right.
A
Otherwise
that
are
using
the
data
source
field
will
continue
to
work.
Fine,
but
yeah
like
there
will
come
a
time
when
we,
you
know
you
know.
Once
we
promote
this
new
field
to
ga
and
once
we've
officially
deprecated
the
old
field,
we
will
want
to
stop
documenting
it.
We
want
to
tell
people,
you
know,
please,
please
don't.
B
Is
actually
a
very
good
topic
to
talk
about
in
that,
because
I
don't
want
people
to
to
get
panic
about
this,
the
ga
feature
you
know
we
can
just
think.
Oh,
my
god,
now
you
are
making
us,
make
a
change
again
yeah.
This
is.
A
A
So
so
I
I
can
go
into
detail
on
what
what
the
plan
is
and
and
yeah,
so
so
the
the
crucial
part
is
it's
these
this.
This
detail
for
option
three
is:
is
that,
regardless
of
which
field
the
end
user
uses,
the
server
will
synchronize
both
of
the
fields,
so
they
have
compatible
content.
So.
B
A
B
A
B
The
deprecation
message
is
pretty
annoying,
because
actually
user
will
see
that
if,
if
someone
actually
use
the
you
know
cube
cutter,
they
will
see
that.
But
of
course,
if
it's,
if
it's
like
a
backup
software,
then
it's
kind
of
in
the
logs
right.
So
are
they
in
the
locks?
Maybe
they
were
yeah.
A
Well,
actually,
so
now
that
I
think
about
it,
you
know
you'll
be
doing,
gets
to
to
pvcs
and
and
creates
the
pvcs,
and
if
you
do
it
get,
I
don't
know
how
we
could
tell
whether
you
were
using
the
deprecated
field
or
not.
So
maybe
we
couldn't
provide
a
deprecation
warning
for
gets
and
lists,
which
is
the
only
thing
that
the
sidecar
will
be
doing
anyways
but
but
but
the
point
is.
B
A
C
A
B
A
B
Yesterday
jean
was
also
like
what.
B
For
information,
it's
a
little
different
because
you
are
you're
you're
trying
to
get
this
cab
merge
right
so,
but
but
for
changing,
because
since
we
are
like
the
owner
of
the
one
snapshot
feature,
so
we
are
like.
Oh
my
god,
what
is
happening,
but
I
understand
I
don't.
I
understand
that
the
you
know
the
team's
concern
and
all
of
this
I
just
want
to
make.
A
Sure
we
can
still
have
conversations
and-
and
we
can
still
convince
tim-
that
he's
wrong
and
we
can
try
to
go
a
different
direction.
I
mean
no
code
is
wrong.
B
A
B
B
A
If
you
pop,
if
you
fill
in
both
fields,
that's
a
weird
thing
to
do,
but
we'll
still
accept
it
if
the
contents
are
identical,
but
but
then
there's
going
to
be
a
bunch
of
error
cases
where
you
know
if
you,
if
you
put
like
one
data
source
in
one
field
in
a
different
data
source
in
the
other
field,
we'll
have
to
reject
that
request,
because
it
won't
make
any
sense.
If
you
put
invalid
contents
in
just
the
data
source
field,
you
will
get
the
legacy
behavior,
which
is
drop.
A
A
That
may
never
bind
and-
and
that
would
be
again,
you
know
working
as
designed
if
you
put
garbage
in
the
data
source
field,
you're
not
going
to
get
a
you're
not
going
to
get
a
pvc
out
the
other
end
and
that's
when
the
the
volume
data
source,
validator
controller
would
be
sending
you.
A
Events
saying
like
hey
this.
Pvc
is
not
going
to
bind
because
there's
no
populator
for
the
data
source
that
you've
specified
and
that
will
that
should
work
too.
But
yeah.
It's
going
to
be
a
long
road
to
go
through
three
releases
to
get
to
get
this
new
field
to
sort
of
become
the
standard
and
then
starting
like
a
year
from
now
yeah.
We
would
only
document
the
data
source,
ref
field
and
tell
everyone.
A
A
and
and
tim
thinks,
that's
the
the
cleanest
sort
of
long-term
situation
to
end
up
in
the
the
other
way.
The
other
thing
we
could
have
done
is
we
could
have
added
like
a
new
boolean
field.
A
That
would
say,
like
you
know,
give
me
the
allow,
allow
new
data
sources
or
something
or
allow
populated
data
sources
that
could
have
changed
the
semantic
for
the
existing
field,
but
the
problem
is,
we
would
have
to
drag
around
that
new
boolean
forever
in
the
in
the
api
and
tim
thought
that
was
ugly
so
having
an
entirely
new
field
and
deprecating
the
old
one
is
cleaner,
even
though
it
results
in
you
know
having
two
copies
of
everything
for
forever.
B
A
B
A
Oh
yeah,
maybe
he's
stuck
in
the
hidden
area.
Here
it
is
okay.
Jordan
said
when
spelunking
for
my
own
benefit
for
any
curious
onlookers,
so
he
looked
through
112,
113
114
and
he
says
in
115.
Something
got
weird
with
the
feature.
Enablement
logic
started,
taking
into
account
user
provided
field
values
to
decide
if
the
data
should
be
preserved
and
he
went
on
to
say,
the
logic
should
prove
should
preserve
data
source
field.
A
A
A
It
I
don't
know
what
which
change
it
was
or
who
did
it
and
I
don't
think
it's
important
to
go.
Hunt
down.
You
know
the
culprit,
but
but
yeah.
I
I
think,
according
to
jordan,
like
we
should
have
done
things
differently
back
in
either
115
or
118.
But
now
because
we
are
where
we
are,
the
only
path
forward
is
to
accept
existing.
B
A
I
mean
I
I
do
understand
that
for
for
new
alpha
fields
like
you
need
a
way
to
roll
them
back,
so
that
you
know
if,
if
people
start
using
the
field
and
then
you
change
it
or
something,
you
need
a
way
to
sort
of
zero
out.
What
was
there?
So
you
can
basically
back
out
the
change
and
say
no,
no
we're
not
doing
this
anymore
and
I
think,
with
the
data
source
field,
when
when
it
was,
I
forget,
if
it
was
snapshots
to
the
pvc
data
source
that
was
done
first,
but
no.
A
A
B
That's
yeah,
so
this
was
this.
Data
source
field
was
added
when
we
introduced
the
snapshot
support
but
because
the
clone
feature
kind
of
progressed
so
quickly,
so
kind
of
people
forgot
snapchat
was
there
first,
okay,
yeah
yeah,
so
snapchat
was
there
first
and
then
what
what
is
this
is
that
1.14,
the
force
field
is
cleared
true.
What
is
it
is
that
in
november
14,
when
this
happens,
I
think.
A
He
might
have
meant
the
pvc
yeah
he
might
have
made
a
typo
right
here,
but
but
the
point
is:
is
that,
like
the
the
field,
clearing
behavior
was
only
supposed
to
be
an
aspect
of
like
feature
gating
when's
when.
B
A
Field
was
disabled
or
something
you
should
have
gotten
this
behavior,
but
when
the
feature
was
enabled,
especially
by
by
yeah,
if
any
feature
that
uses
the
field
is
enabled,
then
it
shouldn't
have
been
preserved.
So
I
think
the
problem
is:
when
stuff
started
going
beta,
we
should
have
stopped
dropping
the
disabled
fields
if
the
feature
gates
were
turned
on
and
we
should
have
just
thrown
errors,
but
somehow
it
slipped
through
and
we
continued
dropping
invalid
data
sources.
A
And
and
that
that's
why
we
got
into
the
situation
now
where,
like
you,
could
have
put
other
stuff
in
there
and
ex
and
you
and
it
of
course
gets
dropped,
and
you
could
just
you
could
end
up
relying
on
that
behavior
and
my
original
proposal
from
last
two
releases
would
have
started,
giving
you
a
non-functional
pvc
and
that
would
be
a
regression
and
functionality
so
that
that's
what
they
didn't
like
so
yeah.
I
think
jordan
did
a
good
analysis
of
the
history.
B
So
I
still
don't
understand
why
there's
a
need
to
accept
this
source
in
the
beginning.
You
know
this
is
an
unsupported
source,
so
I'm
still
not
clear
like
exactly
when
what
yeah
so.
A
A
I
think
we
should
either
have
been
giving
you
an
error
if
you
specified
something
invalid
or
accepting
it,
but
we
shouldn't
have
been
dropping
it
when
when
it,
when
the
thing
was
in
beta
and
then
once
the
once,
the
fields
went,
ga
like
we
should
have
removed
the
logic
to
drop
invalid
contents
completely,
because
we
would
never
want
to
do
that.
We
always
should
have
gotten
an
error,
or
so
so.
A
The
idea
is
that
the
dropping
of
the
invalid
data
source
should
have
been
a
temporary
solution,
while
the
fields
were
alpha
and
it
should
have
gone
away
earlier
than
it
did,
but
it
just
persisted
and
we
ended
up
changing
it
and
modifying
it,
and
I
think
I
think
you
you
touched
some
of
this
code.
What's
his
name.
A
B
B
A
I
think
we
needed
attention
as
we
moved
from
alpha
to
beta
and
from
beta
to
ga,
and
maybe
maybe
we
didn't
get
the
attention
in
in
those
phases
so
so,
in
any
case
I
mean
now
that
we've
sort
of
done
a
postmortem
and
got
to
the
bottom
of
what's
going
on.
We
have
this
new
plan
and
I
can
present
so
is.
Is
tomorrow
the.
B
A
A
Yeah
I
can,
I
can
prepare
like
a
a
slider
or
a
little
document,
that
sort
of
outlines
what
the
change
is.
Gonna
look
like
and
roll
it
out,
and
I
guess
that
what
the
one
thing
that's
not
clear
to
me
so
so
optimistically.
It's
alpha
and
122
beta
and
123
ga
and
124,
which
is
a
year
from
now.
So
next,
next
april
or
whatever
could
be
ga.
A
And
it's
not
clear
to
me
if
we
would
immediately
push
a
new
sidecar
that
used
the
the
new
gaa
field
or
if
we
would
wait
a
whole
release
before
doing
that.
Because
because
what
will
happen
is
you
know?
Let's
say
that
let's
say
next
april,
this
is
ga
and
we
release
a
new
sidecar
external
provisioner,
4.0
or
whatever
the
next.
A
A
Yeah
yeah,
I
get,
I
guess
it's
kind
of
a
breaking
change,
but
it's
it's
basically
dealing
with
the
deprecation.
It's
it's
not
using
the
deprecated
field
and
using
the
new
supported
field.
But
that
means
that
you
can't
use
it
on
older
versions,
because
you
can
only
use
it
at
the
point
when
the
field
became
became
ga,
so
I
mean
we
do
that
all
the
time.
A
With
our
side
cards
we
have
minimum
kubernetes
versions,
we
say
for
this
sidecar,
you
must
run
with
kubernetes,
you
know
124
or
later,
and
so
we'll
just
have
to
document
that
and
be
sure
that
you
know
vendors
understand
the
the
the
version
dependency
when
when
we
eventually
make
this
site
and
that's
why
I'm
saying
we
might
do
it
in
april
or
we
might
do
it
in
august.
B
A
This
but
but
the
old
side,
cars
just
I
mean
I,
so
this
is
one
of
the
things
that
confuses
me
a
little
bit
like
with
the
snapshotter.
We
very
aggressively
move
forward
with
you
know:
snapshotter
v3,
snapshot
or
v4.
Every
time
we
made
a
change
to
kubernetes
to
move
snapshots,
you
know
to
beta
and
then
to
to
ga
we
we
kept
releasing
the
new
snapshotters
immediately,
and
so
nobody.
B
B
So
I'm
just
saying
like
because
the
backup
vendors
they
are,
if
they're
only
using
only
snapshot,
they
may
not
want
to
go.
Take
this
data
source
change
right
so.
A
This
is
for
csi
plug-in
providers
so
like
when,
when
a
vendor
ships
a
csi
plug-in,
they
have
to
decide
which
sidecar
to
bundle
with
it
and-
and
I
think
I
think
the
latest
provisioner
is
v2
so
like
if
you're
running,
kubernetes
v,
you
know
123
or
earlier
you
will
have
to
use
provisioner
v2,
but
if
you're
running
v2
or
124,
you
could
ship
external
provisioner
three
dot
393.0
with
that
would
use
the
new
field,
and
that's
just
a
that's
just
a
question
of
what
this
is
yeah.
B
We
actually
just
talked
about.
We
should
actually
reduce
the
number
of
time
that
we
are
bumping.
The
majorities
we're
actually
bumping
that
too
frequently.
A
Well,
yeah,
I
wanted
to
understand
what
the
logic
there
was
too,
but
but
clearly
there
will
be
some
release
of
the
of
the
external
provisioner
that
that
will
have
a
minimum
kubernetes
version
of
124
and
and
for
anyone
who
wants
to
run
on
an
older
version
than
124
they'll
have
to
continue
running
an
older
version
of
sidecar.
A
Yeah,
so
so
I
this
actually
reminds
me
of
a
question.
This
is
sort
of
unrelated
to
data
populators.
But
since
you're
here
I'll
ask
you
so
the
external
snapshot
or
v3
is
that
maintained
for
anyone?
Is
there
a?
Is
there.
B
It's
actually
yeah.
We
actually
recently
cut
a
release,
a
minor
release.
I
don't
know
if
you
noticed
that
okay.
B
Well,
actually,
I
didn't
want
you
to
pick
you.
I
think
you
were
in
those
csi
meetings.
There's
some
discussion
there,
because
yeah.
I
think
there
was
some
some
problems
and
I'm
not
I
shouldn't,
say
some
problems.
There
are
some
metrics
related
enhancement
that
are
not
in
the
three
point,
next
release
great
yeah.
So
that
was
the
reason.
But
then
those
are
like
kind
of
like
new
features.
You
can't
really
just
like
backport
box.
So
that's
why
we
actually
bumped
a
we
actually
cut
a
minor
release,
which
is
a
little
weird.
B
That's
like
exception,
because
we
were
saying
the
the
you
know.
The
time
between
this
two
major
releases
are
so
close.
It's
like
three
months
yeah.
So
that's
we
made
an
exception,
and
that
was
because
this
is
like
metrics.
Those
are
kind
of
required
right
for
production
elements,
and
all
of
that
I
think
I
meant.
B
Yeah,
it's
actually
it's
now,
it's
actually
even
in
the
box.
If
you,
if
you
go,
look
at
the
csr
driver
docks,
we
had
to
add
those
there,
because
this
was
not
there
before.
So
we
had
that's
why
we
had
all
of
those
discussions
and
because
they
initially
said
we
can't
backport
this,
they
want
it
back,
for
they
said
no,
you
can't
back
for
this.
It's
not
a
bug
fix
and
we're
already
4.0.
B
So
we
can't
go
back.
You
know
to
back
for
those
features
in
street
or
something
right.
So
so
then
we
had
those
designs.
Okay,
this
is
like
exact
exception.
You
really
don't
do
that,
but
if
it's
a
so
for
bug
fixes,
I
think
we
also
have
some
yeah.
I
think
you
should.
Okay,
let
me
actually
find
that
doc.
You
should
actually
go
read
that
we
should
make
make
sure
that
dog
is
clear
and
then
we
I
think
we
should
really
really
make
sure
that
we
are
following
that.
A
What
I'm
trying,
what
I'm
trying
to
understand
is:
are
we
now
maintaining
three
separate
releases
of
snapshots.
B
Yeah,
so
that's
something
that
we
try
to
avoid.
I
think
we
have
some
language
here
saying
that
what
is
what
do
we
want
to
support
and
what
we
don't.
B
Okay,
see
here
yeah,
so
this
is
in
driver
dock.
So
take
a
look
at
this,
so
if
anything
is
not
clear,
we
can
enhance
the
stock.
I
think
what
I
want
to
make
sure
that
we
actually,
when
we
make
decisions
on
backboard
and
cut
releases,
we
actually
follow
the
dock.
Rather
than
kind
of
you
know.
Every
time
we
do
things
is
not
consistent
right.
They
want
to
make
sure
it's
consistent.
B
Okay,
so
let's
say
it
says
I
don't
remember
well,
did
we
add
those?
But
yes,
it's
probably
it
should
be
here
basically
saying
that,
okay,
here
to
minimize
it
like
this,
this
paragraph,
let's
read
this
one
minimize
the
number
of
branches
in
your
support.
B
Okay,
so
we
do
not
want
to.
This
is
lecture
added.
Okay,
this
paragraph
is
added
because
we
did
cut
a
minor
version
on
the
older
major
so
and
then
we
make
only
if
the
previous
solution
is
as
long
as
time
right
so
okay,
so
we
say
the
time
between
the
previous
major
version.
Current
maturity
is
under
six
months
and
also
we
also
look
at
the
you
know
the
production,
readiness
requirements.
B
So
that's
exactly
why
we
cut
this
3r1
mining
release
on
top
of
3-0,
even
that
is
like
after
we
cut
it
4.0
it's
because
the
time
between
the
major
releases
are
just
so
close,
but
are.
B
So
we
try
not
not
to
maintain
that
many,
so
we
tried
only
like
maintain
two
major
releases
or
like
two
minor
releases.
However,
we
also
look
at
like
how
long
like
you
know
how
soon
we're
releasing
the
new
the
new
release,
the
new
major
release
right.
So
in
this
case
the
snapshotter
case
we're
just
releasing
the
majorities
too
frequently
so
between
3.0
and
4.0.
It
was
like
three
months
so
so
so
that's
why
I
was
saying:
okay,
we're
making
this
exception.
B
If
the,
if
the
two
major
release
are
released
within
six
months
and
then
we
also
look
at
the
the
reasoning
right.
So
what
do
we
want
to
back?
If
you,
if
you
have
just
a
bounty
back
for
a
real
bug,
fix
that
should
be
fine?
But
here
we're
talking
about
the
backboard,
a
feature.
B
Yeah,
this
is
for
the
reasoning.
You
know
why
we
actually
cut
it.
This
is
because
this
is
like
on
you,
you
leave
you.
Let's
say
we
cut
for
let's
say
we
just
cut
four
dollar
one
right.
So
at
this
point
we
should
only
do
4.1
something
we
should
not
be
going
back
right,
that's
the
regular
normal
pro.
We
don't
want
to
make
it
normal,
like
we
keep
going
back.
Let's
just
maintain
this
nightmare,
so
we
said
we
don't
want
to
do
that,
but.
A
B
B
Oh
this
one
is
not
really
talking
about
the
so
yeah.
So
normally,
if
you
go
to
look
at
the
releases
right,
you
actually
should
show
the
versions
another
place.
You
look
is
the
stock,
but
sometimes
I
found
the
problem.
Is
that
we're
not
updating
the
docs?
So
let
me
see
if
we
have
this
one
up
to
date,
so
yeah.
I
think
we
should.
Actually
we
need
to
clean
up
this
a
little
bit.
This
is
like.
Has
too
many
older?
Oh
my
god.
B
A
It's
there's
no.
B
That's
a
minimum.
That's
a
minimum,
recommend
it
yeah.
That
was
because
that
was
because
the
this
is
all
beta
version.
That's
the
reason
right,
because
we
didn't
end
anything
in
kubernetes
right.
We
only
there
are
only
three
times
we
make
changes
in
kubernetes.
Why
is
when?
It
was
first
when
that
tau,
when
it's
alpha
the
second
time
is
I
don't
know
what
is
this
1.14
recommended?
B
I
don't
remember
what
was
this
one
second
time
when
it
went
beta
in
1.17
and
then
it's
1.20,
that
is
ga
right,
so
there's
only
three
times
we're
making
changes
in
in
kubernetes.
I
I
actually
need
to
check
and
do
I
don't
know
what
is
this
1.14
recommended?
I
recommended
the
versions
when
the
footing
is
a
little
strange.
B
B
B
Would
yeah,
I
would
give
him
the
latest
right.
I
think
we
had
the
one
one
point
three
point.
C
B
B
Could
be
like
some
people,
sometimes
I
see
like
some
google
folks,
they
started
submitting
prs.
Maybe
they
their
customers
found
something
in
the
2.0,
something
because
they're
using
it.
So
maybe
then
that's
not
really
backpointed
to
three-point,
but
it
doesn't
mean
it
should
not
be.
B
B
B
A
Say
what
we
almost
want
is
an
inversion
of
this
table.
That
says,
with
the
kubernetes
versions
on
the
left
and
the
recommended
sidecar
version
on
the
right,
so
that
you
know
for
any
kubernetes
version,
we
have
a
community
recommended
sidecar
version
that
would
make
it
obvious
you
know
which
ones
we
we
think
you
should
be
using
and
and
anything
that's
not
in
that
list.
You.
B
You
you
mean
like
like,
for
example,
for
1.20
what
is
recommended.
A
B
I
think
that
I
believe
the
problem
is
that
why
they
have
this
complicated,
you
know
scheme.
This
type
of
thing
is
because
some
customer
may
not
be
using
all
the
features.
I
guess
that's
why
so
that's
why
they
have
this
minimum
version.
If
you
don't
want
to
use
the
newer
features
and
you
can
stay
lower,
something
like
that.
Sometimes
you
see
that
especially
if
you
have
multiple
side,
cars
right
together.
B
A
A
B
B
Yeah
yeah.
I
also
got
questions
from
like
our
csi
team
because
they
are
also
reading
the
docs,
but
the
problems
in
the
talks
are
not
up
to
date.
Sometimes
it's
very
confusing
actually.
A
Yeah,
okay!
Well,
so
so
that
that's
enough
on
on
this
topic
for
this
meeting,
so
I
I
I
guess
I
I
will
prepare
something
to
talk
tomorrow
to
the
data
protection
working
group
about
the
volume
calculators,
api
change
and
we
can.
We
can
give
it
like
10,
maybe
a
quick,
five
or
ten
minutes
of
introduction
and
then
answer
some
questions
about
it
and
go
on
to
another.