►
From YouTube: Kubernetes SIG API Machinery 20200422
Description
April 22nd, 2020
@liggitt: KEP-1693: Mechanism for warning API clients about deprecated API use
-[liggitt] proposed for beta in 1.19:
-server-side mechanism to send warnings
-server-side warnings for deprecated API use
-client-go implementation to capture/handle warnings
-kubectl implementation to display warnings
-@deads2k request for kubectl option to treat warnings as fatal
Include in GA criteria:
-Guidance for level, meaning, and structure of warnings
what should be a warning (e.g. known bad field values)?
verbosity, formatting, etc
-required for in-tree warnings
-recommended for contributions from extension mechanisms
-Parity for extensions mechanisms:
--API deprecation indicator for CRD versions
--initially: version-level
--eventually: field-level
-Warning contributions by Admission webhooks via AdmissionReview status fields
-A way for kubectl to escalate warnings to errors
-bool flag (not envvar or kubeconfig, not filtering/structured/codes)
surface deprecation status in discovery
-in API resource?
-in openapi v2 as extension?
Notes from discussion / things to consider:
-kubectl get still prefers deprecated ingress version
-maybe inform warning-adders their warning was too late (post-headers)?
A
A
B
B
B
We
announce
deprecations
of
things
fairly
regularly
variety
of
api's
and
fields
and
features
and
all
kinds
of
things,
and
we
do
that
in
release,
notes
and
those
release,
notes,
run
30
to
40
pages
and
people
get
bogged
down
and
lose
track
of
what
was
in
them
and
lose
track
of
when
a
particular
thing
got
deprecated
and
then
some
number
of
releases
later
it
goes
away.
People
are
angry,
and
so
this
is
your
proposal
for
a
way
to
give
better
visibility
to
use
of
deprecated
things,
and
so
this
is
a
proof
of
concept.
B
What
it
could
look
like
so
I
have
a
file
here
that
has
a
bunch
of
beta
auerbach
objects.
These
have
been
deprecated
for
a
couple
releases.
You
may
or
may
not
have
known
that
I
know.
I
love,
reading,
40
pages
of
release
notes,
but
not
everyone
does,
but
what
this
mechanism
would
do
if
you
use
to
keep
control
to
interact
with
these
objects
it
would
the
server
would
spit
back
warning
headers
that
tell
you
this
type
is
deprecated
what
release
its
deprecated
in
when
it
will
not
be
available
anymore.
B
If
there's
a
replacement,
what
you
should
use
instead
and
this
warning
mechanism
works
at
the
client
level
at
the
request
level,
so
it
works
for
any
type
of
interaction
with
the
deprecated
API.
So
here
I'm
getting
beta
things,
it
works
for
any
command.
So
if
I
annotate
those
things
via
the
beta
api's
I,
get
warned
cue,
control
prefers
cube.
Control
prefers
the
ga
API,
so
if
I
just
say
get
close
to
rolls,
then
I'm
using
the
the
v1
API.
B
B
We,
the
key,
is
to
set
the
bar
so
low
for
user
experience
for
so
many
years
that
when
we,
when
we
actually
do
something,
that's
like
Oh,
useful
information
when
I
need
it
like.
This
is
amazing.
It's
kind
of
a
Stockholm
Syndrome
of
user
experience,
so
I
linked
to
the
the
proposal
from
the
agenda
and
what
this
is
proposing
is
actually
a
general
mechanism
for
communicating
warnings
from
the
server
to
the
client
and
a
pretty
onion
opinionated
display
of
those
warnings
on
the
client.
B
The
initial
use
that
I
am
interested
in
is
the
one
I
just
showed
where
entire
versions
of
api's
are
deprecated
and
have
a
target
removal
date
for
target
removal
aversion,
and
we
want
to
make
that
much
more
visible,
but
there
are
other
uses
that
we
would
certainly
like
to
make
use
of
this
mechanism
before
so.
The
things
I
wanted
to
talk
about
here
were
the
server-side
approach
that
I
was
considering
and
the
client
go
implications.
I
talked
through
this
some
at
the
sig
CLI
meeting
for
key
control
and
got
me
back
there.
B
C
D
One
question
about
mechanics
overall
he's
mentioned:
cube:
Caudill
will
prefer
every
GA.
Api
other
is
an
exception.
Extensions
V,
1
beta
one
has
the
highest
priority
for
this
tall
historical
reasons.
I
think
only
networking
currently
is
the
leftover
in
that
API
I'm,
not
sure.
If,
if
keep
cattle,
wool
will
be
able
to.
B
Yeah,
so
ingresses
are
the
sole
remaining
api
and
extensions
beyond
beta
1.
That
is
the
only
api
version
where
we
prefer
a
deprecated
version
over
a
ga
version
and,
like
you
said
it's
for
compatibility
reasons,
this
was
the
first.
It
got
a
group
that
we
ever
had
and
we
hadn't
yet
defined.
What
happens
when
you
stop
comes
out?
No.
D
D
E
Not
that
it
doesn't
work
for
ingresses,
I
mean
it's
kind
of
accidental
that
the
server
prefers
non
or
prefers
the
GA
versions
that
that's
controlled
by
setting
the
precedence
and
so
like.
We
can
continue
to
set
the
precedence
to
yo,
whatever
will
be
best
for
backwards
compatibility.
So
I
I
don't
really
see
that
as
being
part
of
this
proposal.
C
I
see
some
interception
when
you're,
considering
having
a
priority,
use
a
deprecated
API
but
I,
don't
think
that
it
blocks
this
improvement.
Just
it's
worth
pointing
out
like
maybe
we
shouldn't
API.
As
we
know
deprecated,
should
there
be
a
way
to
indicate
in
discovery
that
it
is
deprecated.
We
have
that
information
now
not
related
to
this
feature,
but
we
go
off
that
capability
for
the
table.
Yeah.
E
B
C
B
E
Yeah
in
our
homegrown
discovery,
instead
of
the
open
API
discovery
were
both
places.
Now,
like
you,
wouldn't
necessarily
I,
wouldn't
have
expected
that
to
go
in
the
in
the
schema
definition,
part
of
the
custom
resource
definition
I
would
have
expected
like
a
tag
like
a
boolean
field
or
something
like.
B
B
B
Level
do
I
have
to
do
to
get
headers
there
we
go,
so
it
there's
really
no
magic
like
it.
Just
comes
back
as
a
as
a
HTTP
warning
header,
and
so,
if
I
do
something
which
involves
multiple
requests
so
like
get
with
a
watch,
the
list
request
comes
back
with
a
warning
and
then,
when
I
start,
the
watch
that
also
comes
back
with
a
warning
and
the
handler
that
I
have
wired
up
in
queue.
Control
is
D
duping,
identical
messages
per
implication.
E
C
E
B
B
B
B
We
use
a
handler,
that's
specific
to
the
client
if
one
was
given.
Otherwise
we
use
the
default
running
handler
and
we
iterate
over
them,
pass
them
to
the
handler
and
append
them
to
the
result.
So,
programmatic
things
can
get
the
actual
structured
data
that
we
parsed
out
of
the
headers,
or
they
can
just
say
for
this.
Client
I
want
to
use
this
handler
and
they
could
do
like
I
know
op.
They
could
do
at
with
the
standard
error
they
could
output
to
a
log.
B
So
I
my
goal
for
this
was
to
stand
on
existing
warning,
header,
mechanics
and
not
try
to
over
complicate
the
design
with
like
api's
within
api's
and
lots
of
coordination
between
server
and
client
on
structure
and
levels,
and
no
specific
warning
codes
like
this
isn't
warning
about
the
deprecation.
This
is
a
warning
about
a
field
level
thing,
and
this
is
a
warning
about
this
other
thing.
I.
B
B
The
other
side
of
that
is
I
am
a
cluster
administrator
and
I
want
to
know
when
it's
safe
to
upgrade
this
cluster
to
the
next
version,
so
I'd
like
to
see
if
deprecated
guys,
that
are
going
away
and
that
Excursion
are
being
actively
used
right
now
on
those
clusters,
and
so
at
the
same
place
where
we
would
be
adding
those
warning
headers
to
send
back
to
the
client
around
deprecated
API
use.
We
could
increment
a
metric
that
says
this.
Deprecated
API
targeted
for
removal
at
this
version
just
got
written
to
or
read
from.
C
C
I
mean
maybe,
but
I
would
generally
leave
that
up
to
the
server
issuing
that
warning
to
be
able
to
structure
it,
and
so
something
that
plums,
a
metric
for
warnings
doesn't
seem
immediately
valuable,
but
one
that
plums
it
for
deprecated,
API
usage
seems
very
useful
yeah.
The
metric
is
not
for
the
warning.
The
metric
is
for
the
defecated
API
use.
B
Someone
I
when
I
started
this
proposal.
I
I
recognized
that
adding
a
general
warning
my
thing
is
emit
and
there
are
like
I
can
think
of
at
least
three
or
four
things
that
I
would
also
want
to
use
it
for,
but
I
was
trying
to
avoid
gating
the
design
on
nailing
day
on
all
of
those
things.
I
think
David
wants
more
of
those
things
brought
into
this
proposal
as
GA
criteria.
So
the
specific
things
are.
B
C
B
B
So,
like
I,
said
the
mechanism
that
this
adds
accommodates
that
with
basically
no
server-side
adjustments,
the
main
questions
around
that
would
be
the
admission
review
API
for
what
books
to
communicate
back
warnings.
That
would
be
one
bit
to
settle
on
and
then
for
things
warnings
generated
from
inside
the
server
I
think
the
main
things
we
want
to
think
about.
There
are
like
just
consistent
like
a
consistent
bar
for
what
what
is
considered
worthy
of
warning
like
I.
B
C
Is
the
first
stage
of
this
I
want
to
agree
that
they
are
GA
graduation
criteria
and
they
should
be
listed
like
I
would
be
disappointed
to
have
warnings,
be
considered
a
GA
feature
and
not
be
able
to
have
admission
webhooks
provide
I,
don't
think
that
stops
anyone
from
developing
warning
and
then
using
it
for
something
like
deprecation.
That
seems
like
an
obvious
first
step,
but
before
we
get
the
GA
and
say
warnings,
our
thing
I
think
we
need
to
have
a
way
for
people
to
use
them.
E
B
There
I
my
instinct,
is
to
try
looking
given
the
number
of
things
we
have
in
progress
for
order
of
years.
My
instinct
is
to
try
to
come
up
with
a
discrete
chunk
of
function
that
solves
a
specific
problem
and
actually
complete
it,
and
then
things
that
are
orthogonal
get
proposed
and
discussed
and
done
separately.
B
I
I,
don't
feel
that
strongly
about
this,
but,
like
I,
would
see
working
on
this
deprecation
bit
as
like
one
person
or
people
are
gonna,
go
do
this
and
then,
if
someone
is
gonna
tackle
the
admission
that,
like
that's
a
second
design,
I,
don't
feel
that
strongly.
If
we
want
to
lump
it
into
one
but
yeah.
E
I
do
feel
that
this
this
concept
that
David's
been
pushing
on
that
like
there's
a
limited
time
to
get
something
from
alpha
to
beta
and
then
from
beta
to
GA,
that
is
kind
of
in
opposition
to
requesting
that
the
GA
have
all
the
features
right
from
the
beginning.
So
I
I
think
I
see
they're
not
like
a
hundred
percent
opposed
to
each
other,
but
I
see
that
that's
too
thoughts
and
some
some
conflict
is.
B
B
C
To
say
that
we
build
an
extensible
system
and
then
ask
people
to
contribute
to
that
system
and
then
provide
what
is
a
highly
valuable
feature
in
a
way
when
I
read
the
description
it
was
built
in
a
way
that
accommodates
something
like
admission
and
actually
accommodates
a
admission
today
for
everything
built-in
but
then
say
weren't
accessible
with
warnings
for
everything
entry.
But
we
don't
allow
those
warnings
out
of
tree
I.
Think
that's
a
bad
so
just
to.
E
Put
that
in
different
words,
it's
not
so
much
about
being
feature
complete
as
it
is
about.
We
have.
We
have
these
users
of
our
system
and
we
don't
want
to
create
any
like,
like
CR,
we've
worked
so
hard
to
get
CRS
and
admission
web
books
to
not
be
second-class
citizens,
that
it
would
be
a
step
backwards
if
we
add
a
feature
that
actually
makes
them
second-class
citizens.
In
some
sense,
that's.
C
E
E
B
So
to
tie
it
to
the
two
extensibility
features
we
have,
that
means
ignition
webhooks
can
contribute
warnings
and
CRTs
can
mark
versions
as
deprecated
does
that
begin,
and
the
deprecations
trigger
the
same
warnings
and
metrics
that
the
built
in
resource
and
a
PA
persons
do
and
the
ignition
what
books
contribute
warnings
the
same
way,
the
anything
in
process
time,
yeah
yeah,
yes,
maintaining
the
parity
that
we
already
have
is
a
helpful
way
to
think
about
it.
Yeah.
B
B
C
So
so
being
able
to
see,
the
warnings
is
great,
but
I
have
a
lot
of
automated
CI
systems
and
things
they
run
against
our
stage
environments,
where
you
know
you
upgrade
a
server
or
any
check.
Does
everything
still
work
and
nobody
is
like
sitting
there
looking
at
the
output,
but
if
I
had
a
way
to
say
cube
control,
please
fail.
If
you
get
any
warnings,
back,
I
would
get
kicked
and
I
did
an
upgrade.
C
Something
was
deprecated
and
I'm
using
the
deprecated
API
and
if
I
had
that
option
on
my
cute
control,
commands,
I
would
use
it
for
my
CI
and
for
my
stage
systems
so
that
I'd
be
able
to
see
oh
well.
Okay,
this
needs
update
instead
of
great.
You
gave
me
a
warning,
but
no
one
was
watching
for
that
warning
and
now
prod
died
again.
It.
E
G
C
B
C
Is
a
risk
that
such
a
thing
could
happen?
People
could
write
code
that
did
that
I
think
that
in
cube
will
do
a
fairly
good
job
of
having
them
be
like.
This
is
naughty.
Don't
do
that,
since
it
is
an
optional
flag
that
someone
have
to
opt
into
setting
having
it
fail
on
them,
so
they
can
then
go.
Look
and
say:
oh
well,
that
guy
was
Nadia,
I
guess
I'm
gonna
have
to
turn
it
off
here
until
I
get
them
fixed.
Is
it
a
choice
they
can
make,
but
I
would
think
really
hi
I
I.
E
Think
we
don't
have
a
responsibility
to
protect
users
from
themselves.
This
way
like
we're
at
it's
an
opt-in
flag,
if
you
turn
it
on
like
you're
totally
accepting,
but
a
warning
is
gonna
cause
an
error
for
your
for
your
command.
I
I
do
think
if
we-
and
probably
we
should
do
this
anyway,
is
like
we
should
well
document
the
sorts
of
things
for
which
you
can
make
a
warning
about,
so
that
you
make
sure
these
testers
for
the
standard
we
can
tell
like.
E
B
We
we
would
need
to
be
explicit
that
warnings
don't
fall
under
API
guarantees.
I
mean
look.
The
fact
that
one
of
the
warnings
were
surfacing
is
around.
The
deprecation
should
should
make
that
obvious,
like
a
thing
that
succeeded
without
warnings
on
one
release
might
get
warnings
on
a
later
release,
and
so,
if
you
are
running
in
a
mode
that
says,
treat
warnings
as
errors.
Well,
you're
gonna
get
some
errors.
Yeah.
E
B
B
C
So
we
already
faced
this
problem
and
we're
as
far
out
of
skew
it's
a
thing
that
you
can
choose
to
deal
with.
The
flag
is
up
10
you
aren't
forced
to,
but
I'm
I
can
look
at
it
and
say
you
know,
would
my
life
be
better?
If
many,
yes,
like
I'm,
going
through
now
and
I'm,
saying
like
oh
my
gosh,
why
are
we?
Why
are
we
on
V
1
beta
1
of
this
we've
had
V
1
for
almost
a
year?
Don't.
F
I
also
have
a
lot
of
people
that
are
that
can
interact
with
the
cluster
in
the
right
mode,
because
CI
has
to
do
it,
so
they,
if
they
don't
check
the
lock
messages
which
they
don't
do
and
running
green
tests
or
bills.
They
won't
see
the
warning
so
I
guess
it
would
help
to
get
a
failing
test
because
they
have
action
items
there,
but
the
risk
is
yeah
that
there's
a
little
earlier.
H
C
C
C
At
that
point,
alright,
like
I'm,
watching
cute
control,
to
see
if
you
have
a
deprecated
API,
then
I'm
going
to
parse
out
against
a
server
version
to
figure
out
whether
that
API
is
going
to
be
removed
in
three
months,
because
you
know
how
Jordan
happened
to
write
his
English
that
feels
more
alias
e
than
than
flag
II.
To
me,
here's.
E
B
I
know
that
that's
really
what
the
metrics
were
for
like,
if,
if
you
want
to
get,
if
you
want
to
make
sure
you
get
through
your
CI
run
and
didn't
use
things
that
are
deprecated
that
are
going
to
be
removed.
The
next
release,
like
that
information
is
present
and
structured
and
part
of
the
metrics
like
it'll,
say
these
api's
and
here's
our
target.
Major
minor
removal
dates
like
I,
think
there
are
better
ways
to
get
that
information.
E
My
point
was
more
like
you
can
parse
standard
error,
your
silver
like
you
can
take
standard
error
yourself
and
compare
it
to
a
table
and
failing
your
process.
If
standard
error
contains
something
that
isn't
in
the
table,
right
like
you,
don't
need
us
to
build
something
into
acute
control
to
accomplish
that
also.
F
C
B
E
H
B
Right
because
the
warning
flag
would
only
tell
you
about
Q
control
use
right,
like
it,
wouldn't
tell
you
by
the
way,
that
controller
and
that
operator
and
that
whatever
they're,
also
using
the
deprecation
guys-
and
I
violently
just
doing
that
under
the
covers.
Like
you
really
want
to
check
the
metrics.
G
E
E
F
B
D
E
I
think
there's
kind
of
two
issues
there
one
is
one
is
the
thing
to
I
think
David
was
asking
for
which
is
like
you
should
be
able
to
give
a
warning
and
a
web
hook
and
I
guess
one
through
the
user.
The
other
is
like
what,
if
the
storage
version
is
of
the
deprecated
version,
I
think
that
is
okay.
As
long
as
it's
not
true,
when
you
remove
the
deprecated
version.
F
G
B
B
E
B
To
do
that
today,
so
if
you
have
a
version
as
a
storage
version-
and
you
just
try
to
update
this-
you
need
to
drop
that
it
does
not
allow
you
to
okay,
good.
You
have
to
explicitly
update
the
status
to
remove
that
from
the
list
of
stored
versions,
which
is
the
last
step
of
doing
your
storage
migration
and
then
it'll.
Let
you
drop
the
version.
A
You
very
much
Jordan
and
thank
you
I
really
for
the
participation
discussion.
I
hope
that
you
got
everything
you
needed
and
with
that
pretty
good.
They
want
topic
today.
Remember
we
do
twice
a
week,
bug,
scrubs
or
bug
triage
is,
as
we
call
it
so
feel
free
to
join
us.
They
should
be
in
your
calendar
if
you
were
part
of
the
waiting
list
and
I
will
upload
this
meeting
later
today
to
YouTube
and
we'll
see
you
again
in
two
weeks.