►
From YouTube: Kubernetes SIG API Machinery 20200520
Description
May 20th, 2020
KEPs in for 1.19
-Recommended status conditions schema - we will create the type and perhaps helpers
-Standardize QPS and Burst - I think this will miss freeze
--Will not make it in 1.19
--Maybe survey for users in the mailing list of taking advantage of the feature
-Agree on beta requirements for api priority and fairness (not yet merged)
--Need to merge (probably does not require an exception?)
--lavalamp@ to ping commenters and close open comments
-Require transition from beta - we are implementing generator and enforcement
--David to link generator PRs and related work to the issue
-Warning mechanisms for deprecated APIs
-Tracing in apiserver - couldn’t quite get it reviewed in time, maybe could have an exception?
--Needs David to take a look
--Probably will miss 1.19
Open PRs stats review (first pass)
-Discussion about closing vs keeping frozen and stale issues and PRs
-Looking forward for a better triage / reporting mechanism using
A
Okay,
well,
hello
and
good
morning,
everybody
today
is
May
20
of
20
20
20
20
20.
We
are
having
our
bi-weekly
capi
imaginary
meeting.
Thank
you
for
those
that
are
joining
us
today.
We
have
two
main
topics
that
we
wanted
to
cover
in
this
day
of
May
1
is
the
caps
that
are
present
and
hopefully
making
it
into
one
19
and
the
other.
A
A
A
B
Okay,
this
one
so
so
status,
conditions
and
conditions
in
particular
inside
of
status
are
very
common
in
many
api's.
But
the
schemas
are
slightly
different.
This
kept
about
trying
to
make
those
schemas
well
trying
to
provide
a
standard
schema
and
when
we
get
to
future
versions
of
the
API
is
using
conditions
they
could
use
them.
We
also
get
a
lot
of
questions
for
this
from
people
outside
of
KK
core
and
a
lot
of
requests
for
the
basic
helpers
find
this
condition.
Merge,
set
this
condition.
Taking
action
till
its
condition
is
true,
those
sorts
of
things.
C
I,
like
this
I
just
have
one
question:
it
looked
like
the
discussion
on
this
had
really
not
concluded
on
the
topic
of
helpers.
It
seems
to
me
that,
if
we're
going
to
define
the
condition
type
in
meta,
v1
and
Kevin's
suggested,
we
define
the
slice
of
condition
type
so
that
we
can
attach
the
health
or
helpers
as
methods
on
the
slice
of
condition.
Then
those
helpers
need
to
be
defined
in
meta
p1
as
well.
Okay,.
B
We
would
not
define
type
defined
functions
on
top
of
our
types
that
goes
against
our
API
conventions.
I
think
that
we
have
significant
utility
just
in
the
conditions
themselves,
that
is
the
big
claim
here
and
that
the
helpers,
if
and
when
they
come
I,
don't
think
they're
gonna
require
a
separate
cap,
a.
D
B
D
C
D
B
D
C
B
I
mean
that's,
that's
fully
novel
right,
yeah,
the
idea
that
that
you
would
make
a
request
and
then
you
would
get
back
a
header
and
we
have
no
concept
of
using
headers
really
as
API,
not
not
separate
headers,
that
that
are
not
standard
and
then
honoring
that
in
a
client
library
and
then
communicating
that
if
we
wanted
it
to
be
an
API
to
other
libraries
as
well
definitely
seems
like
a
significantly
bigger
thing
to
bite
off
than
saying
we're.
Gonna
put
an
experimental
n
bar
in
one
spot.
B
D
D
E
B
D
Yeah,
that's
that's,
there's
also
some
pods
that
maybe
don't
go
through
like
like
if
you've
got
any
static,
manifests
laying
around
in
your
system.
Still
you
need
to
just
those
separately
yeah
but
doable
yeah
yeah.
Definitely
not
beautiful
I.
The
yeah
I
guess.
My
hesitation
here
is
just
making
a
promise
to
users
when
we're
not
we're
looking
for
a
low
effort
way
to
measure
something
and
and
seems
a
little
I'm,
not
sure
if
there's
other
use
cases
for
it.
I
guess
this.
B
B
There
I
don't
I,
don't
mind
starting
there.
I
will
point
out
that
we
do
have
it
on
many
commands
and
that
I
think
most
people
who
write
their
own
probably
overlook
for
this,
that
there
may
still
be
utility
and
being
able
to
have
a
client-side
throttle.
If
somebody
wanted
it
right,
we'd
probably
still
have
one
in
OC,
for
instance,.
B
But
I'm
certainly
willing
to
start
in
a
different
spot
if
we
want
to
start
an
ember,
that's
fine,
I
returning
a
header
and
then
parsing
a
header
back
on
the
client-side
and
using
that
to
go
manipulate
the
client
that
made
the
request.
I'm,
not
very
happy
with
all
the
different
things
that
would
have
to
be
created
to
do
to
do
that.
D
F
D
D
A
B
D
B
A
C
So
just
a
comments
here
on
that
one.
There
was
a
question
about
asking
for
documentation
about
observability
we'd
already
have
that
in
our
concept
page
in
the
user
facing
doc.
It
wasn't
clear
to
me
whether
or
what
was
being
requested
beyond
that,
and
then
another
thing
that
we
talked
about
earlier
was
adding
a
extending
the
status
to
report
the
concurrency
limit,
absolute
values
calculated
by
each
server.
We
talked
about
doing
that
I.
B
This
one
actually
originated
some
time
ago
and
then
maybe
a
month
or
two
ago,
came
back
up
in
cig
arch
and
we
decided
to
try
to
push
it
through.
This
requires
that
api's
API
resources
well
technically
API
kinds,
but
basically
the
type
that
you
serve
via
the
REST
API.
When
you
create
one
in
beta,
it
has
a
defined
lifespan.
The
beta
will
be
deprecated
after
three
releases
and
then
three
releases
after
that
that
particular
beta
will
be
removed.
You'll
stop
serving
it.
This
doesn't
mean
you
cannot
remain
in
beta.
B
It
just
means
that
to
remain
in
beta
for
more
than
three
releases
without
being
deprecated,
you
need
to
produce
a
second
beta
and
that's
a
good
signal
to
users
that
what
they're
using
isn't
considered
to
be
fully
stable,
but
boys
things
rushing
all
the
way
to
GA
so
the
cat
merged.
It
was
a
cigarette
cap.
B
A
B
E
B
Yes,
so
the
intent
from
the
cap
is
that
is
that
we
know
we
want
beta
things
to
not
live
in
beta
forever,
but
we
recognize
that
the
only
thing
that
we
are
able
to
cleanly
enforce
today
is
the
actual
REST
API
things
like
feature
gates
and
fields
within
existing
api's
are
unenforceable,
so
it
doesn't
make
sense
right
now
to
to
list
a
mission
statement.
We
have
no
practical
way
to
measure
you.
E
B
D
Would
say
that
the
the
user
facing
api's
are
drastically
more
important
than
the
like
cluster
operator
facing
local
api's,
but
I
would
have
been
had
they
have
a
much
broader
impact.
Yeah
yeah
I
mean
I.
Think
logically,
the
cluster
operator
api's,
are
also
important
and
should
go
to
GA.
Like
do
you
really
want
your
secrets
encrypted
with
the
beta
api,
but
that
that
affects
fewer
people.
G
This
is
introducing
a
mechanism
for
the
server
to
communicate,
warnings
back
to
API
clients
and
default
handling
inside
client
go
and
keep
control
to
surface
this
warnings
to
users,
and
then
the
first
use
of
that
mechanism
is
to
connect
to
the
cool
new
deprecated
API
indicators.
We
have
to
warn
about
use
of
deprecated
API,
so
this
uses
the
generated
bits
that
were
introduced
as
part
of
David's
code.
G
119
the
plan
is
to
get
the
server-side
mechanism
and
the
client
go
and
keep
control
mechanisms
in
place
and
then
specifically
surface
warnings
about
use
of
deprecated,
API
versions.
The
cap
also
has
other
goals,
customer
resources,
admission,
web
books
and
then
field
level
warnings,
but
those
are
not
currently
plant
the
119.
If
we
just
go
super
fast,
maybe
maybe
some
of
that
can
come
into
scope
or
119,
but
first
first
goal
is
to
get
the
mechanism
and
basic
warnings
in
case.
D
Ago,
maybe
yeah
I
was
really
so.
If,
if
you
can
go
look
in
the
vid
recordings,
if
you
want
more
details
on
that,
one
yeah
I
think
the
next
cap
is
tracing
an
API
server.
I
think
a
number
of
months
ago,
David
Ash
poll
presented
this
to
us
and
at
the
time
it
had
a
bunch
of
stuff
with
like
controllers,
setting
an
annotation
on
object.
D
He
has
recently
like
a
couple
of
weeks
ago,
updated
it
rather
significantly
so
now
it
is
just
about
the
requests
made
to
API
server,
so
like
API
server,
a
server
calls
out
to
a
web
book.
Eventually
we
call
it
a
TD,
so,
like
all
of
those
calls
would
go
through
this
tracing
mechanism
now
and
be
reported
to
like
eh-eh.
D
D
B
I
think
you
go
ahead.
Does
it
eliminate
the
like
right
now
we
have
a
very
simple
and
shockingly
useful
message
about
this.
Particular
step
was
slow
and
it
comes
out
and
drops
right
into
log
everyone's
log
by
default.
There's
no
friction
to
using
it
and
it's
very
easy
to
like
wire
up
to
a
grep
and
a
notifier.
Does
this
eliminate
that
and
say
no
I,
don't
think
any
I.
B
D
In
particular,
the
configure
a
that
my
remaining
hang-ups
on
this
earth
is
basically
configuration
alright,
like
we
kind
of
deliver
this
to
some
external
service.
Now
and
like
I,
don't
imagine
you
have
this
installed
in
a
cloud
and
you're
a
user
of
it,
but
you
don't
have
access
to
like
config
files
like
who
is
using
the
trace,
who
needs
to
be
able
to
configure
it?
That's
that's
my
remaining
question
on
this.
Is
it's
not
it's
not
obvious
to
me
that,
like
clouds
are
going
to
configure
these
for
users,
so
yeah.
D
Yeah
I
thought
I
pinged
you
on
it,
but
it
probably
evade
a
hair.
If
you,
you,
probably
put
this
in
the
mentally,
like
not
looking
at
this
right
now
buck
in
a
while
ago,
but
it
is
quite
different.
So
that's
worth
another
look,
it's
probably
a
little
late
for
this
one,
but
I
do
feel
bad
in
that
it
took.
It
was
I
was
not
super
speedy
on
the
reviews
here.
D
I
D
A
Okay,
yeah,
what's
even
hard
to
be
honest,
was
hard
to
pull
this
list
and
I
think
we
need
to
find
a
better
way
of
tracking
and
let's,
for
me
at
least
the
deadline
of
caps
freeze
and
his
mitrice
came,
like
you
know,
from
Network.
I
should
probably
have
been
more
aware
of
it,
but
suddenly
Monday,
we
were
all
running
to
see
which
gets
required
attention,
so
maybe
for
the
next
one.
A
A
Very
good
so
looks
like
on
caps.
We
are
good
the
next
one.
Really
we
can
time
box
it
to
maybe
10
minutes
or
15
or
less
I,
don't
know
if
people
is
interested
or
not
it's
more,
like
maybe
beaurocratic
cleanup
of
the
rock
block,
and
there
was
this
presentation
to
the
chairs
and
heels
looks
like
there
is
some
interest
interest
from
the
contributors,
see
contrib
X
to
start
with
money,
so
part,
creating
some
dashboards
to
show
how
different
sinks
six
are
doing
in
terms
of
open
peers.
So
this
is
public.
A
I
will
put
the
links
later.
I
put
some
on
the
notes,
but
you
can
see
this
is
all
cornet
is
actually
is
all
seats.
I
was
mistaken.
Last
night,
when
I
was
looking
at
this,
and
somebody
clarified
to
me
this
morning.
This
is
all
the
repos,
including
outside
of
cornets
cornetist,
that
are
owned
by
the
six
of
cornetist,
and
this
is
from
the
outstanding
open
pull
request.
A
There
is
a
similar
one
for
issues
that
I
have
it
opened
somewhere
here
so
so
far,
so
good
is
not
our
problem,
but
in
the
next
graph
maybe
a
machinery
now
has
a
bunch
of
open
beers.
I
think
we
are
not
the
worst
offenders,
because
we've
been
constant
in
the
number
of
open.
Like
you
know
a
we
are
not
the
words
of
a
nurse
or
we
have
been
for
quite
some
time,
but
there
is
a
growth
in
general
right
got.
A
There
different
cuts
to
these
and
I
think
this
is
working
progress,
because
some
of
the
information
I
would
like
to
have
is
not
here.
So
I
was
looking
at
different
cuts.
There
is
all
our
words,
for
example,
these
are
awaiting,
so
there
is
a
cut
for
ten
days
is
a
cut
for
more
than
a
year
and
is
complete
to
pull
together
because,
for
example,
last
night
I
was
doing
justice,
you
know,
and
it
last
night
was
222.
A
A
So
there
is
probably
other
repos
like
letting
go
or
others
I
think
the
discussion
we
had
a
mini
discussion
with
David
and
Daniel
the
other
day
and
maybe
I
open
the
discussion
here
of
what
do
you
guys
think
should
be
our
response
to
this,
for
example,
peers
that
have
been
open
for
more
than
a
year,
the
bots
Marvin
as
stale
and
then
as
frozen.
So
we
have
a
bunch
of
frozen
like
I.
Do
here,
labor.
D
D
H
A
A
B
A
B
A
D
B
So
is
this
just
issues
I
there
was
a
PR
velocity,
so
so
I
can
imagine.
It
is
1.8
with
giving
people
notice
on
their
PRS
and
saying
find
the
right
person
to
bug
on
slack
or
we
are
gonna
close
it
or
potentially
even
just
Auto,
closing
it
and
suggesting
that
a
new
PR
be
opened
because
the
new
PR
would
end
up
triggering
us
through,
like
the
weekly
scrub
yeah
perfect.
But
if
you,
if
you
just
aged
out
everything
older
than
you
know
six
months.
E
D
A
So
that
that
was
my
second
point
here,
I
feel
I've
improvised
in
to
take
a
look
to
these
deeper
and
I.
Couldn't
put
it
in
action,
but
I
think
this
is
something
that
can
help
with
that
situation,
which
is
if
we
can
use
the
labels
that
are
proposed
here
for
the
triage
workflow
instead
of
just
the
number
that
could
help
us
filter,
like
you
know,
probably
at
the
beginning,
is
more
work,
because
we
would
have
to
go
through
everything
that
it's
in
the
backlog
and
some
automated
process
should
assign
the
entry
ash
issue.
A
A
Maybe
I
don't
know
there
is
some
discussion
going
on,
but
I
don't
have
all
the
data
right,
I,
don't
have
all
the
cried,
so
yeah
I
would
say
you
know
I
just
wanted
to
bring
these
to
everybody's
attention.
Some
of
you
may
not
care
I.
Think
it's
important.
We
are
doing
a
lot
of
work
every
week
and
I
would
like
us
to
look
also
pretty
in
the
grass
and
that's
why
you
know
I
I'm
thinking
on
ways
of
taking
an
action
on
these
I.
D
A
A
good
point:
yeah
I,
mean
I'm
very
proud
of
our
triage
meeting,
because
we've
been
constant
and
I
think
that
is
one
of
our
biggest
values
there,
but
definitely
we
could,
you
know,
try
to
measure
more
now.
The
only
thing
that
we
do
is,
you
know:
did
we
close
the
list
of
things
that
appear
since
the
last
one
or
not,
and
we
can.