►
Description
API Review for https://github.com/kubernetes/kubernetes/pull/80568
01 August 2019
B
And
so
I
I
am
gonna
start
from
being
moderately
familiar
with
this
and
then,
as
we
drill
in
I'm,
gonna
focus
more
on
the
procedural
stuff
first,
just
on
what
these
look
like
and
I
might
ask
a
few
meaning
questions,
but
I'm,
probably
gonna
stay
focused
on
the
technical
for
this
we're
trying
to
get
more
of
that
on
the
caps
and
I
will
talk
about
places
where
you
know,
I'm
surprised
or
something,
and
it's
just
kind
of
talk
as
I
go
some
of
the
stuff.
That
might
surprise
me.
B
B
B
B
C
A
Please
so
the
the
way
it
works
is
that
when
you
specify
a
in
line
ephemeral,
CSI
volume
in
a
pots
back,
there
is
no
volume
ID
that
you
associate
with
it.
The
volume
ID
gets
generated
on
mount
time
and
I
think
it's
it's
generated,
assuming
the
pod
ID
that
way
it's
unique
per
pod.
So
if
your
pod
got
you
know,
if
your
pod
kott
deleted
and
we
created,
then
the
volume
ID
that
comes
to
the
driver
is
going
to
be
different.
B
B
A
B
You
know
like
use
case,
wise,
I,
assume
and
y'all
can
tell
me
if
this
is
the
correct
assumption.
I
assume
this.
Many
of
the
use
cases
for
this
are
for
things
that
are
ephemeral
either
per
pod,
but
might
live
on
the
host,
and
so
someone
particularly
clever
in
CSI
might
use
this
to
do.
Local
sharing
between
pods
in
the
same
name.
Space
by
offering
an
anteater
that
is
garbage,
collected,
went
and
there's
no
pods
from
a
given
namespace
running.
On
a
note.
B
Yes,
this
is
possible
I,
mostly
like
it
so
I
often
like
you
know,
don't
know
if
I've
ever
liked
you
and
I
have
got.
This
sounds
like
I
like
to
start
on
terminology,
so
I
don't
think
a
femoral
is
wrong.
It
actually
is
correct
in
the
context
of
what
you're
describing
you
know,
a
lot
of
the
questions,
I
would
ask
would
be,
is
ephemeral.
The
best
word
for
this.
B
If
you
could
use
this
to
do
persistent
and
someone
would
be
confused,
and
so,
like
you
know,
a
lot
of
the
questions
on
meaning
are
with
someone
using
this
understand
that
it
the
primary
purpose
and
then,
if
someone
wanted,
if
this
was
intended
for
a
larger
set
of
use,
cases
that
are
less
frequently
used,
does
the
terminology
confuse
them
so,
like
persistent,
actually
is
a
word
that
we
use
in
a
number
of
other
places?
Does
the
meaning
of
persistent
here,
majus,
the
meaning
in
other
places
like?
B
Would
someone
with
someone
like
my
assumption
coming
into
this,
would
be
like?
Okay,
persistent?
That
probably
means
it
connects
to
a
persistent
volume
claim.
So
if
it
says
persistent
volume
claim
that
has
to
do
with
persistent
volumes
and
if
it
says
ephemeral,
it
doesn't
have
to
do
with
persistent
volumes.
Is
that
correct,
correct?
Yes,
that's
pretty
good
naming
and
then
maybe
usually
in
a
review,
I'd
be
like
okay
driver
mode.
B
Someone
going
and
implementing
a
new
driver
there'll
be
plenty
of
other
Doc's,
but
like
though
the
last
resort
is
always
look
at
the
API,
because,
usually
that's
where
people
go
so
I
might
say.
Okay
in
this
review,
you
know
I.
Think
I'd
probably
add
a
comment
here
which
would
be
you
know.
The
driver
mode
is
really
important.
It
would
be
good
to
add
a
little
bit
of
extra
Co
doc
here
and
actually,
probably
in
the
point
of
use.
So
what
I
would
probably
say
is
like
add,
go
doc
here.
B
A
B
B
And
I
always
try
to
like
come
up
with
examples,
so
like
I,
actually
really
care
about
this
feature,
because
I'm
gonna
go
abused,
this
for
all
sorts
of
things,
and
so
like
like
I
get
I
have
some
use
cases.
Not
all
eight
characters
have
always
had
that,
but
I
do
like
putting
in
the
comments
of
the
actual
API.
If
it's
a,
if
it's
intended
for
an
extender,
what
you
might
do,
we've
rarely
gotten
to
a
case
where
we
have
too
much
go
doc
in
the
API
definitions
very
garbage
collected.
D
B
B
So
just
one
minor
comment,
you
know
in
the
comments
always
use
the
JSON
form
of
the
name,
like
that's
the
that's
the
thing
that
I
really
wish.
We
had
a
good
automation
thing
for,
but
it's
practically
impossible
to
write
the
docs
great
you
tell
the
you
tell
the
default,
you
list,
the
other
modes.
I
might
suggest.
B
You
know
again,
like
adding
an
example,
because
this
is
intended
for
an
extender,
adding
an
example
of
how
they
might
use
it
or
how
an
implementer
might
use
this,
because
this
is
used
by
both
end-users
and
their.
This
API
is
most
likely
to
be
used
by
an
extender,
because
an
end
user
doesn't
ever
set
this
right
correct.
So
then
I
would
probably
just
I,
probably
just
suggest
giving
the
extender
or
a
few
examples
adding
more
go
doc
here,
we'll
never
go
wrong
and
duplicating
go
doc.
B
B
A
B
So
this
actually
from
an
API
perspective
other
than
those
few
things
so
like,
okay,
so
I
would
go
in
and
look
at
the
constants
I'd
look
at
the
godox
I,
usually
keep
digging
on
the
go
dog
until
I
felt
reasonably
confident
that
if
I
did
a
cute
control,
explain
on
the
field
and
I
didn't
know
much
about
CSI
that
I'd
be
able
to
guess
what
this
is
for.
So
generally
I.
B
This
is
a
this
is
not
anything
that's
specific
to
to
this
team
or
not,
but
across
the
cube
space,
as
explained
has
gotten
better
and
as
our
open
API
Doc's
have
gotten
better.
More
people
are
depending
on
it.
You
know.
A
couple
of
consoles
out
there,
like
open
shift,
is
starting
to
add,
like
an
API
Explorer
people
who
have
viewers
using
open,
API
viewers,
adding
more
description
to
the
actual
top-level
object
becomes
more
valuable,
so
anything,
that's
a
fundamental
property
of
the
CSI
driver.
B
There's
actually
a
really
strong
benefit
to
adding
in
the
go
doc
of
the
object
itself.
Short
they've
been
about
what
those
cases
might
be
and
we're
not.
We
don't
strictly
enforce
this,
but
it's
kind
of
as
people
go
through
cleaning
it
up
and
at
some
point
in
the
future
I
know
we
will
try
to
go
through
and
clean
this
up,
but
it
would
be.
You
know
in
this
object
level,
doc.
B
If
this
is
a
new
field
that
fundamentally
changes
something
that
someone
would
describe
the
field
would
be
good,
I'd
get
examples
in
there
and
then
I
would
do
a
higher-level
meta
here,
which
might
be
you
know
we
can
certainly
do
more
than
just
you
know.
A
few
sentences
here,
explain
probably
I
would
say
once
we
get
past
like
three
or
four
paragraphs.
Maybe
that
would
be
too
much,
but
there's
always
the
opportunity
to
say.
B
Okay,
CSI
driver
captures
information
to
the
Container
stores
interface
volume
driver
deployed
on
the
cluster
as
CSI
drivers
do
not
need
to
create
one
directly.
That's
kind
of
a
more
mechanical
detail,
I
might
say
over
time,
and
we
don't
have
to
do
it
in
this
review.
But
just
as
a
general
thing
is
when
we
go
and
tell
them,
we
can
probably
do
a
better
document
job
of
documenting.
This
is
adding
another
couple
sentences
here
about
what
an
extender
would
do
means
someone
who
does
cute
control.
B
Explain:
CSI
driver
gets
a
little
bit
of
a
snippet
like
Oh,
a
CSI
driver.
For
this
case
you
know,
might
be
CSI.
Drivers
represent
the
object
installed.
I
represent
the
type
of
driver
and
kubernetes
uses
it
in
the
fields.
You
know:
CSI
drivers
spec,
calling
out
the
important
ones
like
attach
required
every
but
see
pot
info
on
mount
a
tetra
car
there's
a
little
bit
more
mechanical,
so
mode
is
the
third
field.
B
The
mail
and
use
that
way
and
ephemeral,
which
can
be
created
on
the
spot
and
are
used
for,
can
be
used
for
extension
of
behavior
on
the
node
and
then
maybe
take
the
examples
used
in
the
other
places
and
just
do
like
a
really
simple
decoration,
again
not
required
for
this
PR.
It's
good
to
be
thinking
about
that.
Always
because,
if
you
can
answer
the
question
about
CSI
in
this
explain
and
orient
people,
you
probably
save
yourself
time.
B
Explaining
later
we
don't
require
doc
links
here,
I
think
at
some
point
we
might
you
know
some
of
the
original
cube
objects
have
a
few
of
those
down
the
road
it
might
be.
This
would
be
a
great
place
to
have
the
if
there
is
a
canonical
if
there's
a
canonical
doc
location
for
writing.
A
CSI
driver
I
think
it
should
go
there,
so
so,
if
not
not
required
for
this,
but
a
good
good
way
to
think
about.
What's
the
purpose
of
the
go
doc
and
how
does
it
help
users
yeah.
B
You
know
it's
funny
because
I
always
feel
like
we
spend
a
lot
of
time
on
the
API
review.
I
generally
feel
that
the
API
is
the
thing
that
ends
up
saving
you
time.
So
it's
like,
even
though
it's
hard
for
us
to
do
part
reason
that
I
know
Jordan
and
I
and
Tim
and
others
have
always
been
so
nitpicky
is.
If
you
answer
the
question
here,
you
don't
have
to
answer
it
later
and
I.
B
Think
I've
noticed
at
least
talking
to
people
extending
queue,
the
ones
that
have
more
upfront
description,
I
notice,
I
can
answer
a
different
type
of
questions.
It's
not
scientific
at
all,
but
the
great
thing
is:
is
that
if
you
put
it
in
go
talk
on
the
thing
it
shows
up
in
lots
of
places
downstream
and
so
the
extra
time
just
that's
okay,
so
you've
got
the
new
mode
field.
We
talked
about
that.
You
know
I
would
generally
look
at
so
we
talked
about
constants.
B
So
there
are
places
where,
when
adding
a
new
field,
we
would
explicitly
avoid,
even
if
it's
something
that
other
fields
were
wildly
wrong,
we
probably
fix
it,
but
if
or
we'd
say
you
know,
you
know
you
should
use
the
correct
so
like
if
you
were
to
use
a
boolean
instead
of
an
enumeration,
even
if
everything
else
on
that
struct
used
Julianne's.
But
enumeration
was
the
right
thing
because
we
generally
don't
like
to
add
a
new
lian's
unless
they'll
never
be
any
other
choices.
B
So
we
would
go
and
say
be
consistent
as
the
tiebreaker
on
thing
is
where
it's
not
clearly
just
broken.
So
I,
don't
think
that
applies
here,
but
just
as
a
that's
like
another
one
is
consistent.
He
matters
within
the
API
so
much
because
that
reduces
confusion
and
confusion
is
a
really
hard
thing
to
measure.
So
we
just
kind
of
treated
as
an
axiom
and
go
from
there
so
somewhat
of
an
arbitrary
axiom.
B
A
B
You
know
you
would
pass
it
through
the
annotation
in
this
case,
because
a
we
agree,
at
least
in
theory,
that
this
should
be
an
array
of
enumerations
B,
because
it's
defined
in
another
spec
already
and
C,
because
this
something
is
either
ephemeral
or
not.
So
this
is
probably
appropriate,
which
is
the
use
of
ephemeral
as
a
an
attribute
as
a
boolean.
So
we're
converting
our
enumeration
into
a
boolean.
That's
okay,
because
it's
a
lower-level,
primitive!
B
B
B
We
generally
don't
pass
enumerations
down
to
lower
level
extensions,
because
then
we
have
to
go
passing
an
enumeration
to
something
if
they
don't
handle
it.
There's
a
you
know,
that's
a
bug,
so
this
is
generally
fine.
That
would
be
what
would
be
going
through
my
head
talking
through
it.
It's
fine
to
convert
an
enumeration
to
a
boolean
in
this
case.
A
B
B
A
B
Okay,
so
as
an
example,
what
you're
saying
is:
it
would
be
impossible
without
the
gate,
for
the
Alpha
feature
to
have
an
inline,
CSI
volume
source
correct.
This
means
we
do
not
have
to
define
the
behavior
of
an
existing
CSI
plug-in
that
somehow
got
this.
If
there
had
been
a
way
for
someone
to
have
specify
this,
we
would
have
had
like
if
we
had
accidentally
added
a
field
that
allowed
it.
Even
if
it
didn't
work
correctly,
we
would
still
have
to
define
what
the
default
behavior
is
for
those
old
plugins.
B
So
that's
like
a
you
know,
usually
during
an
API
review,
because
this
is
a
new
field.
So
this
is
two
things.
This
is
a
new
field,
but
it
is
a
communication
with
an
existing
plug-in
API.
So
the
new
field,
usually
is
it's
got
to
be
optional
by
default.
The
default
value
cannot
change
the
behavior
of
the
cluster
generally
unless
you
change
the
API
version,
because
you're
passing
this
down,
because
this
is
to
api's
really
it's
the
API
to
the
driver
and
then
the
drivers
API
to
the
tool.
B
An
API
reviewer
just
needs
to
double
check
that
okay,
well
I'm.
Calling
somebody
else
with
a
new
value:
we
have
to
define
the
default,
so
I
would
generally
say
a
CSI
driver
in
the
wild
passing
whatever
new.
We
pass
can't
change
the
existing
behavior
and
CSI
drivers
are
allowed
to
ignore
things.
They
don't
recognize,
which
has
been
the
case.
So
there's
not
really
anything.
We
have
to
do
except
say
if
this
annotation
is
absent,
define
the
behavior.
B
And
I'm
not
sure
that
this
is
I'm,
not
sure
that
this
is
right
for
the
annotation.
It
might
be
like
a
note
below,
because
it's
gonna
be
kind
of
tight
and
go
doc,
but
it's
like
it's
important
to
define
to
think
through
that.
What
happens
when
we?
If
someone
has
a
CSI
driver
today-
and
they
don't
see
this
value,
what
can
they
assume?
So
in
the
case
here?
Is
we
didn't
send
this
before
this
graduated?
B
So
it
means
that
if
you
see
this
value
at
all,
it
means
that
you're
running
a
version
of
kubernetes
that
supports
this,
and
one
of
two
things
is
true.
If
it's
true,
that
means
the
CSI
driver
included
ephemeral
as
a
mode,
and
this
is
an
inline
volume
source
if
it's
false,
but
if
it's
absent,
that
means
the
feature
is
not
enabled
or.
B
The
presence
of
the
annotation
is
required
to
allow
the
is
required
to
allow
the
underlying
implementation
to
assume
that
and
it's
it's
kind
of
like
I
think
this
is
like,
where
I
worry
the
most
about
API
review
and
transferring
this
knowledge.
Is
it's
really
hard
to
reason
about
some
of
these,
and
you
know
the
patterns
are:
there's
a
new
field
in
an
API
resource.
There's
really
something
else.
That's
novel
here,
which
is
adding
you
you
new
field
to
an
extension.
B
It's
technically
a
new
field
to
an
existing
APA
resource,
but
I
think
there's
enough.
Novelties
is
where
the
novelty
comes
in
is
if
you're
calling
someone
else
it's
different
than
if
you're
writing
it
to
an
API
object
and
someone's
reviewing
it
reading
it
in
so
away
is
just
like.
If
you
have
a
read-only
config
object
that
you
assume
writing
is
totally
out
of
scope.
You
can
make
different
assumptions,
so
this
is
just
generally
like
trying.
B
B
Does
the
the
field
values
for
things
that
are
strings
or
constants
so
generally
and
I?
Think
Jordan
has
an
example
of
this?
If
I
go
look,
you
can
actually
propel
it
modes
to
try
so
like
just
like
with
the
fuzzer.
You
can
provide
default
values.
This
would
be
something
that
I
would
probably
be
like
check.
B
You
know
some
of
this
is
just
having
data
there,
because
in
the
past,
serialization
has
inferred
constants
in
a
few
cases.
Bad
ideas,
but
you
know
just
from
a
parsing
and
round-tripping
perspective,
having
good,
fuzzers
and
so
forth
is
pretty
important
in
in
an
API
review.
I
might
suggest
that
you
had
a
fuzzer,
so
I
would
go.
Look
at
you
know.
I
would
assume
that
you
passed.
The
fuzzing
I
would
probably
suggest
here
that
this
be
a
let's
see.
What
are
we
doing
here
if.
A
B
It's
not
the
end
of
the
world.
If
we
don't,
however,
we
had
in
the
past
caught
things
around
buzzing,
we're
spending
a
little
bit
of
extra
time
on
the
fuzzer
can
save
effort
later
it's
we
don't
really
allow
people
to
fuss
with
constants.
Now
in
the
very
first
versions
of
lots
of
API
is
the
constants
might
have
a
ball
we're
getting
better
at
it,
but
just
as
a
general
rule.
B
B
Of
the
round-trip
tests
should
set
defaults.
The
bug
really
is
that
it's
not
the
buzzer
that
should
be
defaulting.
It
is.
This
is
just
a
we'd,
never
fixed
this
in
each
cavity
area.
But
what
should
really
happen
is
we
should
fuzz
an
object
in
the
wild
like
as
it
would
be
in
at
rest,
there
should
be
a
round-trip
test
that
C
realises
it
and
DC
realises
it
with
no
D
or
DC
realizes
than
si
realises
it
with
no
decoding
and
verify
it
ends
up
in
a
canonical
form
that
should
not
do
the
faulting.
B
We
should
then
also
have
a
roundtrip
test
that,
because
the
round-trip
test
started
by
testing
the
internal
conversions
and
back
that's
what
the
current
ones
they
does.
That
does
do
two
faulting,
so
you
have
to
fill
out
the
defaults,
but
we
could
actually
move
that
out
and
say:
take
the
initial
object,
run
the
defaulting
test
and
get
the
object
back.
If
the
object
doesn't
equal,
the
input
object
run.
The
appropriate
defaulting
then
verify
it.
However,
we
can't
do
that
because
of
some
of
the
older
of
conversion
logic.
B
So,
just
for
today
we
basically
do
the
in
a
perfect
world.
We
wouldn't
do
two
faulting
in
fuzzers.
Unfortunately,
we
don't
live
in
that
perfect
world.
What
will
you
do
just
run
the
default
or
after
it
and
we're
close
to
that?
Someone
would
just
have
to
go.
Do
it
and
no
one
has
taken
a
chance
to
do
it.
So
that's
whatever
the
helper
is
here.
So
this
just
as
an
example
sure.
B
You'd,
be
sorry
I'll
correct
that,
so
you
would
yeah.
You
would
do
the
defaulting
afterwards,
because
you
have
to
do
two
faulting
just
forcing
basically
don't
trust
the
generic
buzzer
define
your
own
and
I
would
say
what
we
try
to
do
is
actually
try
to
cover
as
a
mini,
because
this
is
fuzzing.
We
want
to
cover
the
logical
cases.
The
default
buzzer
does
half
nil,
half
not
nil,
but
because
we
have
three
so
you'd
still
have
to
do
the
defaulting.
I
guess
you
could
remove
this,
but
yeah.
B
B
B
So
this
is
a
pet
peeve
and
I'm
not
gonna,
make
ya'll
deal
with
this,
but
this
is
unnecessary
and
this
is
the
style
that
people
have
done,
but
I'm
at
some
point,
I'm
going
to
go
and
fix
all
of
these.
This
forces
an
allocation
which
we
don't
want
to
do
so
validation
is
actually
one
of
our
heavy
hitters
in
and
update
flows.
B
Validations
do
about
1/5
to
1/6
of
all
allocations
during
a
update,
and
that's
because
our
validations
are
really
inefficient
for
two
reasons:
path:
field
path
which
is
expensive
and
also
this,
so
every
one
of
these
will
cause
an
allocation
on
the
heat
and
the
go
Lane
canonical
way
to
do.
This
are
all
errors
feel
that
errorless
that'll
be
milled
to
start
because
nil
and
empty
are
the
same
for
a
slice.
B
What
would
happen
would
be
you
wouldn't
do
any
allocation
here,
I'm
not
going
to
put
that
comment
in
because
it
needs
to
be
consistent
across
the
whole
codebase,
but
just
as
a
as
a
pert
as
it's
a
go,
Lang
style,
never
initialize
an
empty
array
always
do
far.
Our
in
D
slice
always
do
far
and
then
append
initializes
it
as
necessary.
B
Test,
so
you
know
I,
usually
validation
test.
This
was
good.
Jordan
is
a
little
bit
more
picky
than
I
am,
and
he
might
make
you
do
30
or
40
tests,
which
is
good
I,
usually
look
for
something
along
the
lines
of
testing
that
you
at
least
exercise
most
of
the
branches.
In
there
do
we
have
a
invalid
one,
combined.
D
B
Not
a
huge
deal,
but
even
though
in
theory
all
the
code
coming
into
this
should
set
it.
People
can
use
the
validation
functions
on
deserialized
objects,
and
so
it
should
fail
validation
if
it's
null
the
same
as
if
it's
empty
string,
but
we
don't
want
it
to
cause
a
panic,
and
so
just
as
a
just
as
a
usual
rule,
I
ask
people
to
test
the
mill
case
in
there
are
invalid
scenarios,
even
if
it
should
be
defaulted,
I
mean
we're
pretty
close,
so
they
die.
B
This
is
this
is
a
pretty
good
one
other
than
some
minor
API
stuff
you
know,
I
would
have
stayed
focused
at
that
I
usually
go
through
and
do
a
pass
on
the
code
just
for
the
things
that
you
you
all
have
already
caught.
You
know,
as
I
saw
from
the
comments,
validation,
the
strategy,
the
round
tripping,
and
you
know,
obviously,
spending
a
little
bit
more
time
on
the
go
dock.
B
For
the
author
is
valuable
down
the
road
usually
and
I've
gotten
more
stickler
about
this,
as
we
cut
on
over
the
years,
but
like
the
more
that
we
can
get
to
a
really
good,
go
dock,
and
probably
a
really
good
release,
note
which
I
sometimes
check
I
might
even
nitpick
once
this
gets
updated.
I
would
go.
Ask
this
to
be
a
little
bit
more
explicit
just
so
that
when
it
comes
time
for
the
release,
notes,
someone
who
reads
it
has
a
chance
like
you
know
the
I
talk
about
use
cases
in
the
API
doc.
B
This
is
such
an
exciting
feature.
This
is
someone
can
go
use
a
CSS
ID
driver
to
build.
They
know
level
extension
that
deals
with
the
file
system,
which
means
they
can
inject.
They
can
share
things
across
pods
securely.
They
could
inject
Kerberos
credentials.
They
could
add
sockets
that
allow
people
to
talk
to
a
proxy
of
the
docker
daemon-
and
you
know
I
personally-
get
excited
about
that,
but
trying
in
the
release
note
to
at
least
give
someone
a
clue.
What
this
is
helps
this
stand
out.