►
From YouTube: Kubernetes SIG API Machinery 20210127
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
In
recording
hello,
everybody
welcome
to
2021
our
first
meeting
this
year.
This
is
sig
api
machinery
and
I'm
glad
to
see
everybody.
I
hope
everybody
is
doing
well
and
staying
safe.
We
have
three
items
in
the
agenda
today.
I
think
we
are
going
to
slightly
change
the
order
because
david
is
delayed.
So
probably
we
can
start
with
han
and
I
moved
to
that.
B
Great
awesome
yeah,
so
the
thing
that
I
want
to
talk
about
is
promoting
aps
server
metrics
to
stable
status,
so
metrics
now
have
a
stability
level
and
we
are
now
basically
ready
to
enforce
api
guarantees
on
critical
metrics.
So
for
api
machinery
there
are
some
pretty
obvious
candidates,
stuff,
like
api
server,
request
totals
and
latencies,
and
we
can't
really
delete
these
things
without
breaking
everybody
who
manages
the
kubernetes
cluster,
so
we
would
like
to
promote
them,
but
before
we
promote
those
metrics,
we
would
actually
like.
B
I
would
like
to
remove
a
few
fields
which
are
have
been
problematic
so
so
there
are
two.
There
are
two
suggestions
here.
So
one
is.
I
will
make
them.
B
Oh,
can
you
just
scroll
up
or
scroll
through
january
27,
wait.
Am
I
not
showing
you're
not.
B
D
D
It
we
can
see,
we
can
see
your
changes.
We
just
can't
see
the
presented
like
if
you
open
the
dock
in
a
separate
tab.
It's
it's.
It's
happening.
B
Fine,
there
are
a
couple,
so
is
everyone,
okay,
with
the
general
idea
of
promoting
this
one
and.
B
Let's
see,
the
object
counts
to
a
stable
status.
These
are
these
are
both
these
have
been
in
kubernetes
for
quite
quite
a
long
time,
and
basically
we
would
get
a
lot
of
pushback
if
we
did
anything
drastic
to
these
things
already
so
they're,
like
kind
of
already
not
officially
stable.
B
I
don't
hear
any
objections
it
shouldn't
be
that
contentious
so
like
the
thing
I
would
like
to
do
is
open
up
a
pr
I'm
going
to
remove
some
labels
that
we've
had
problems
with
in
the
past
and
yeah.
I
guess
I
can.
I
can
just
cc
all
the
leads
from
api
machinery
and
just
make
sure
it
gets
done
in
121,
but
give
concerns
to
you
look
like
you
wanted
to
say
something
daniel.
C
I
was
just
you
want
to
remove
some
labels
from
the
metrics
before
promoting
them
to
stable
okay.
What
are
they
right
now?
Are
they
alpha
or
or
or.
E
C
Okay,
if
somebody's
using
these
metrics,
what
happens
you,
those
fields,
just
stop
having
values
or
does
it
break
a
monitoring
pipeline.
B
They
do,
but
it's
quite
the
ones
that
I
would
like
to
remove,
could
not
have
been
used
in
very
meaningful
ways
due
to
personality
issues
in
the
past.
In
fact,
we
had
to
modify
a
lot
of
these
values
due
to
security
concerns
over
the
past.
Like
couple
quarters,
so,
okay
people
will
probably
be
happy
about
us.
B
Yeah,
so
the
cd
object
counts
doesn't
conform
to
instrumentation
metric
guidelines,
so
sig
instrumentation
people
have
requested
that
we
call
it
storage,
object,
counts
or
api
server
storage
object,
caps.
B
The
name
yeah:
well,
I'm
going
to
deprecate
this
one
so
that
doesn't
break
I'm
going.
E
B
C
Okay
and
presumably
that's
permitted
by
our,
it
is
permitted
metrics.
C
My
guess
is
that
most
people
in
sega
api
machinery
are
not
direct
consumers
of
these,
or
maybe
we
might
have
some.
We
have
you
go.
Did
you
mention
this
in
sick
instrumentation.
B
B
We're
definitely
going
to
have
a
release
note.
The
funny
thing
is
you
have
to
you
have
to
think
about
label,
it's
helpful
to
think
about
labels
like
columns
in
sql
table.
So
if
a
client
tries
to
write
a
a
row
in
a
table
with
a
column
that
doesn't
exist,
you're
it's
going
to
error
out,
but
you
can
have
nullable
columns
and
basically
time
series
operates
like
that.
So
if
you
remove
labels,
it's
from
the
client,
it's
actually
compatible
with
back-end
storage
representation.
Of
that
I'm
serious,
it's
not
a
compatible
base.
C
Yeah,
it
makes
sense
to
me,
but
we
need
to
publicize
it
yeah.
Definitely
an
email
to
the
api
machinery
mailing
list,
maybe
kubernetes
dev.
I
don't
know
yeah.
That
sounds
that's.
C
All
right,
cool
thanks,
let's
see,
looks
like
david,
is
not
on
yet,
and
david
was
going
to
run
the
the
caps
item.
What
do
you
think
fede?
Do
you
want
to
run
the?
Can
you
run
the
caps
item,
or
should
we
shuffle
it
to
the
end.
G
D
D
All
right,
let's
see,
can
y'all
you
all
should
see
terminal
stuff
in
it.
Yes,
yeah
all
right,
so
I
just
wanted
to
give
a
quick
demo
of
just
like
real
quick
go
over
the
idles
and
just
like
some
of
the
tooling
that
I've
written
so
far
so
you
can
see
I
have.
I
have
like
kind
of
a
subsection
that
I've
of
of
core
v1
that
I've
hand
written
for
for
to
be
a
useful
example.
This
is
the
example.
That's
actually
in
the
like.
D
In
the
cap,
I've
I've
converted
I've
actually
like
converted,
auto
converted
all
of
corgi
one.
But
you
know
core
v1
is
a
little
bit
unwieldy,
so
I
figured
I'd.
I'd
just
show
the
interesting
parts
for
people
who
haven't
read.
The
cup
you
can
see
like
everything
is,
is
grouped
around
like
a
group
version
kind
or
a
group
version,
and
then
like
some
sort
of
subtype,
that
you
can
use
or
re
reuse
in
in
that
we
have.
D
You
know
documentation,
comments
and
normal
comments,
and
then
we
have
kind
of
primitives
and
compound
types
for
all
of
the
types
in
our
kind
of
platonic,
kubernetes
type
system,
as
it
were,
so
you
know
list
maps
and
lists
and
sets
and
then
like
the
primitives,
that
we
use
so
like
integers
and
strings
and
quantities,
time
duration,
all
that
jazz.
And
then
we
have
ways
to
map
to
the
kind
of
currently
to
the
open
api
validation.
D
And
you
know
we
might
be
able
to
expand
that
to
support.
Maybe
some
of
the
simple
cases
for
the
built-in
validation
for
kk.
As
that's
that's
one
of
the
open
points,
and
then
we
have
you
know,
of
course,
we
also
have
like
first
class
contracts
for
enums.
D
This
should
make
some
of
our
documentation
a
little
bit
better
and
and
unions,
which
we
kind
of
have
defined
informally
a
lot
in
kubernetes
and
have
have
been
a
common
feature
request
for
crd
authors
as
a
way
to
like
match
the
behavior
of
kubernetes
of
stuff
like
volume,
source
and
and
friends.
D
Okay.
So,
basically,
the
tool
chain
kind
of
theoretically
consists
of
this
front.
End
kdlc,
which
compiles
that
kind
of
source
idl
that
you
saw
into
a
like,
compiled
and
type
checked
representation.
That
is
it's!
It's
a
proto
message,
so
other
tooling,
can
you
know
import
that
in
whatever
whatever
language
or
whatever
they're
written
and
generate
stuff
off
of
it?
So
for
today
I'll
show
you
the
mechanism
that
generates
cr
crds.
D
It's
was
a
quick
port
from
controller
tools,
the
same
underlying
mechanism
except
without
the
go
front
end
and
then
also
kind
of
the
sketch
of
the
version
that
converts
to
like
our
go
pseudo,
idl
style.
They
say
style
because
I'll
talk
about
that
in
a
moment,
but
basically
we
can
specify
an
import
path.
D
D
I
made
made
it
have
actual
argument
flags
last
night
and
then
right
so
it
worked.
You
can
kind
of
see
like
this.
Is
the
text
proto
form
in
the
final
version
obvious
this
probably
wouldn't
be
spit
out,
but
it's
kind
of
useful
for
debugging.
D
D
So
if
we
do
like
ir
to
crd
and
then
we
do
core
v1
colon
colon
pod,
we'll
just
convert
the
pod
kind,
we
can
see
we
end
up
with
like
what
you'd
expect
from
the
schema,
including
all
of
our
appropriate
extension
points,
notice
that,
like
the
user,
didn't
necessarily
need
to
manually,
specify
a
list
type
on
their
list
map.
It's
just
because
it's
a
list
map.
We
generate
that
because
we
have
the
first
class
concept
of
that.
D
We
generate
proper
validation
for
the
enum
and
as
you'll,
see
in
a
minute
we'll
also
when
we
generate
go
we'll.
Also
generate
constants.
This
is
actually
something
that
we
don't
do
today
by
default
currently
like.
If
users
do
like
a
kind
of
one
of
our
pseudo
idl
style
enums,
they
have
to
also
manually
copy
the
values
over
and
specify
them
in
a
marker,
and
then
we
generated
this
giant
blob
of
open
api.
D
That's
what's
required
to
get
a
tagged
union,
kubernetes
style
tag,
union
working
in
our
restricted,
open
api
variant,
all
right,
and
then
I
also
have
this.
Is
I
added
this
part
to
the
demo
very
recently?
So
with
any
luck,
it
still
works.
I
just
recently
ported
it
from
my
prototype,
but
we
can
see
we
get
kind
of
kubernetes
style
pseudo
idl.
D
Out
of
this
is
roughly
one
to
one
compatible
with
the
kubernetes
go
pseudo
idl,
I
say
roughly
because
the
proto
markers
in
pseudo
idl
are
full
of
kind
of
nonsense
like
there's
a
bunch
of
values
in
that
that
proto-structure
tag
that
are
just
completely
ignored
by
the
proto
or
the
go
to
protobuf
parser,
and
some
of
them
contain
just
like
nonsense
like
they
have
they're
marked
as
repeated
when
it's
actually
not
a
slice
or
whatever,
and
so
it's
you
know
it's
hard
to
get
one
to
one
compatibility
with
that,
but
otherwise
it's
it's
one
to
one
compatible.
D
Okay,
that's
kind
of
my
demo.
I
guess
we
can
switch
over
to
the
caps,
maybe
or
if
anyone
has
any
questions.
If
we
want
to
stall
for
a
little
bit
longer.
H
Sally
did
you
did
you
cover?
Why,
like
like
at
a
meta
level
like?
Could
you
talk
a
little
bit
about
like
why
idl
like
like
make
the
simplest
possible
case
for
inventing
something
new
versus
you
know,
code
or
other
things
like,
because
I
think
that's
that's
what
I
struggle
with
reading
the
cap
like
it,
the
the
desire
is
strong
right.
We
want
to
represent
exactly
what
we
represent
and
for
every
edge
case.
We
either
have
to
work
around
it
or
get
over
the
hum.
H
That
puts
a
lot
of
burdens
on
a
language,
but
it
makes
code
more
palatable.
Are
you
is
the
argument
that
the
idl
is
the
true
goal,
or
is
it
like,
because
it's
simpler
for
end
users,
even
though
it
has
to
have
encode
all
that
complexity
like
what's
the?
Why
idl.
D
I
I
think
that
there's
right
now,
there's
a
lot
there's
a
lot
to
know
and
there's
a
lot
of
complexity
that
you
kind
of
have
to
keep
in
your
head
when
you're
writing
in
pseudo
ideol,
there's
a
lot
of
weird
stuff
that
you
can't
and
there's
a
lot
of
stuff
from
go
that
you
can't
use,
and
this
is
causing
issues
for
our
end
users,
whether
it's
people
familiar
with
kubernetes,
but
that
just
like
make
mistakes
or
or
want
to
encode
things
that
we
don't
necessarily
make
easy
to
encode
from
kind
of
a
crd
perspective
or
whether
it's
new
users
coming
to
kubernetes.
D
That
want
to
write
extensions
and
have
like
all
this
extra
burden
of
like
a
lot
of
the
weird
stuff.
That's
unwieldy
and
doesn't
really
matter
well
and
then,
especially
for
users
that
are
coming
to
kubernetes
and
they're.
Not
writing
go
right.
There
they're
writing
stuff,
like
crds
for
meta
controller
and
their
back
end
is
python
for
a
lot
of
them
like
getting
an
entire
go
tool
chain
in
place
and
set
up
is
like
not
not
a
great
experience.
D
You
know,
and
I've
had
I've
had
people
tell
me,
like
you
know
I
don't
I
don't
like
I'd,
be
willing
to
write.
I've
actually
had
people
say
this
I'd,
be
willing
to
write
an
idl
or
like
a
small
domain
specific
language,
but,
like
you
know
getting
getting
saying,
we
have
to
learn,
go
in
order
to
to
write.
This
thing
is
just
like.
That's
that's
out
of
the
question,
and
so
that's
like
one
of
that's
like
the
main
idea
and
then
one
of
the
reasons
this
comes
back
to
affect
kk.
D
You
know,
besides
it
being
potentially
nice
for
various
review
reasons.
Is
that
a
lot
of
what
people
do
today,
with
their
extensions,
is
kind
of
write.
These
wrapper
crds
so
think
of
these
as
like
custom
workload,
types,
and
so
one
of
the
things
that
they
commonly
do
is
they'll
embed.
D
They
will
embed
built-in
types
into
their
crds,
and
so,
if
we
have
two
separate
systems
between
core
and
and
extensions,
we
end
up
with
this
tooling
drift
that
is
kind
of
detrimental,
so,
whether
it's
being
able
to
easily
understand
what
the
types
in
core
are
doing
to
chord,
making
changes
that
actually
end
up
breaking
crds.
This
is
something
that
has
happened
in
the
past
that
has
like
led
to
caps
to
kind
of
fix
what
we
screwed
up
in
core
like
this.
D
That
kind
of
tooling
drift
causes
issues
today,
because
we
have
slightly
different
tool
chains
and
and
separating
them
even
further
would
kind
of
continue
to
cause
these
issues.
Yeah
I
mean-
and
I
think.
H
H
We
already
do
support
and
treat
them
as
our
idl,
even
if
they're,
ineffective
or
insufficient,
but
we're
still
building
something
net
new
that
has
to
have
relatively
high
fidelity
to
every
other
tool
that
we've
already
built,
and
that
to
me,
like
that's,
that's
the
thing
at
the
heart
of
this
is
we've
added
one
more
thing
that
stacks
to
every
other
thing
that
then
everything
has
to
be
adapted
to
like
from
a
scaling
perspective.
H
If
we
were
starting
fresh,
I
would
get
it,
but
I'm
a
little
worried
like
that's.
That's
the
the
idl
is
something
new.
We
have
a
bunch
of
existing
things.
The
proposals
bar
in
cube
to
some
degree
like
I
would,
I
might
argue
the
bar
we
have
to
clear
is
is
why
does
one
more
thing
make
the
whole
problem
better
and
reduce
the
work
that
we're
still
going
to
have
to
go?
Do
to
adapt
all
the
existing
tools
to
it?
Not
that
I
against
it.
Just
like
that's
the
argument.
I
feel.
C
All
right,
so
I
I
kind
of
agree
with
that.
I
have
yep
if
we
did
something
like
this,
my
desire
would
be
that
we
auto
convert
all
existing
kubernetes
stuff
into
this,
so
that
we
would
not
be
adding
an
additional
thing,
which
means
it
has
to
be
exactly
one-to-one
right,
like
everything
that
we
do
in
kubernetes.
C
Types.Go
files
has
to
be
expressible
in
this,
otherwise
it
can't
be
a
replacement
right,
but
if
this
is
like
adding
an
additional
step
or
adding
an
additional
way
to
do
things
to
the
system,
I
don't
think
that's
good,
because
we
already
have
too
many
ways
to
do
it.
Right,
like
server
side
apply,
has
its
own
notion
of
a
schema.
We
have
the
types.go
notion
of
a
schema.
We
have
the
open
api
subset
notion
of
a
schema
like
it
is
not
good
to
add
an
additional
one.
We
have
to
replace
something.
D
Yeah,
so
I
can
maybe
kind
of
speak
to
both
of
those
points
kind
of
to
a
couple
of
clayton's
points.
This,
like
I,
I
I
tried.
I
tried
to
design
this
to
represent
the
the
range
of
of
open
api
schemas
that
can
be
expressed
there.
There
are
places
that
you
could
maybe
write
like
open
api.
That
is
not
expressible
in
this.
C
Yeah,
if
I
can,
if
I
can
interrupt
for
a
second
I
I
don't
know
that
looking
at
open
api
is
the
thing
to
go,
because
that's
the
that's
what
we
exposed
to
crds,
but
that's
not
what
clayton
and
I
and
david,
if
you
were
here,
are
worried
about
we're
actually
worried
about
reproducing
the
behavior
in
our
existing
types.go.
H
That's
a
big
statement.
I
I
don't
know
that
I
have
the
data
to
agree
or
disagree
with
that
statement,
but
that
one's
a
big
statement
that
controller
tools
is
what
people
use
to
build
crds.
So
I
I'd
want,
like
I
think,
that's
a
factor
and
you
know
we
want
to
drive
consolidation
around
tooling.
H
So
that's
a
pro
to
more
centralized
tooling,
but
I
do
want
to
make
sure
that
that
statement
is
if
it's
used
as
evidence
that
we
that
we
establish
like
that
because,
like
the
set
of
people,
this
would
impact
the
different,
diverse
audiences
like
core
cube
people
using
controller
tools,
people
in
other
languages,
people
who
aren't
using
controller
tools,
people
who
wouldn't
touch
control,
don't
know
that
controllers
tools
exist.
We
do
need
to
be
relatively
accurate
about
what
that
that
audience
is.
D
Yeah
I
I
can,
I
can
see
what
I
can
do
there.
I
have
that
data
in
various
forms,
the
other,
the
other,
the
other
kind
of
side
of
this
for
kk.
I
definitely
agree.
I
actually,
as
part
of
the
earlier
iteration
of
this
prototype,
that
I
wrote.
I
have
the
tool
that
auto
converts
and
it
is
a
hundred
percent.
My
goal
to
a
have
the
auto
conversion
being
be
available
and
be
like.
I
I
think
you
know
we
should
auto
convert.
D
We
should
cover
all
of
kubernetes
kubernetes
right
like
this
shouldn't.
I
I
would
like
to
like
you
said,
consolidate
tooling
and
not
like
not
introduce
a
new
thing.
I
think
gradually
replace
replaced
everything
or
that
sounds
like
conquer
the
world.
Now
I
I
want
to
you
know
I
don't
want
to
add
a
new
thing.
I
want
this
to
replace
pseudo
idl
as
the
canonical
thing.
D
Obviously,
we'll
still
have
to
generate
go
types
from
the
from
the
idl,
because
we
want
to
use
stuff
and
go
but
like
this,
this
should
be
the
source
of
truth,
and
ideally
we
all
we
end
up
replacing
our
tooling
that
works
on
pseudo
idl.
Today
to
work
based
on
the
you
know,
taken
the
the
intermediate
form
that
I
showed
you,
the
ckdl
and
use
that
instead
and
for
practical
purposes
of
of
migration
kind
of
doing
that
incrementally
is
probably
better.
D
Instead
of
trying
to
you
know,
say
like
publish
everything
at
once,
we
can
start
saying:
okay,
we
generate
equivalent,
we
generate
the
equivalence,
pseudo
idl
and
everything
continues
to
work.
We
replace
one
tool
or
we
migrate,
one
tool.
We
keep
creating
tools.
C
I
agree
with
the
people
in
chat,
who
are
mentioning
the
xkcd
standards
it
sounded
like
dims
was
that
you
gonna
say
something.
G
No,
I
was
just
making
an
observation.
It's
it's
like
yeah
it
you
know
especially
coming
through.
You
know
the
web
services
stuff,
where
we
were
trying
to
do
code
generation
and
back
and
forth
and
stuff
like
that.
You
know
the
mismatch
between
the
object
and
the
serialized
representations
have,
you
know,
have
always
traditionally
bitters
in
the
past
right.
So
that's
why
I
haven't
read
the
cap
yet
so
I
will
promise
to
read
the
cap.
H
I
think
the
follow-up
to
the
the
second
question
would
be
if,
if,
for
whatever
reason,
the
the
folks
bulk
at
the
scope
or
scale
or
complexity
of
this,
what's
the
fallback
for
the
idl,
is
it
something
that
the
the
folks
working
around
the
controller
runtimes
project
would
be
fine
experimenting
with
I
mean
you
know
you
could
do
100
fidelity
and
still
not
be
something
that
we
take
on
in
basic
interim
core
kubernetes
without
more
evidence
or
more
feedback.
What
what's
the
what's
the
scenario?
What
are
the?
H
What
are
the
different
branching
paths
here,
where
you
know
for
one
reason
or
another
we
we
may
or
may
not
decide
to
go
whole
hog.
What
are
the?
What
are
the
smaller
steps.
D
Taking
this
back,
just
back
to
cue
builder,
like
I,
I
think
that
would
be
a
disappointing
outcome
because
of
what
I
mentioned-
and
I
talked
about
a
little
bit
in
the
cap
too,
the
kind
of
tooling
drift-
and
it
also
means
more
maintenance
burden.
Like
collectively
we
maintain
like
tooling,
for
two
dialects
of
pseudo
idl.
D
In
addition
to
like
a
and
a
lot
of
supporting
parsing
code,
and
I
think
I
think
it
would
be
a
shame
to
just
be
like
okay,
we're
going
to
continue
maintaining
two
different
sets
of
tooling
as
well-
and
you
know
I
mentioned
about
the
the
users
and
stuff
like
that
as
well
in
the
learning.
But
you
know
that
that
that
is
definitely
that
could
be
a
viable
outcome.
D
I
you
know
I
demoed
this
to
the
rest
of
the
q
builder
community
and
they
were
interested
so
like
we
could
take
it
back
to
q
builder,
to
experiment
with
my
yeah.
I
I
have
a
little
bit
of
a
concern
there
too,
that,
like.
C
So
I
I
have
some.
I
have
some
thoughts
around
the
feature
set.
I
noticed
one
of
your
demo
had
a
union
concept
in
it,
but
we
don't
actually
support
unions
all
right
like
right,
like
we
have
in
theory
how
you
would
do
a
union,
but
unions
are
not
a
feature
of
our
api
surface
area,
and
so
I
I
for
so
in
order
to
replace
our
types.go
like
clearly,
you
need
to
support
every
feature
that
we
currently
do
have,
but
I'm
fairly
concerned
about
supporting
features
that
we
don't
yet
have.
C
C
C
You
can
write
the
equivalent
open
api
so,
but
the
issue
is
like
open.
Api
is
a
downstream
artifact
of
our
system.
It
is
a
description.
That's
not
entirely
accurate
about
what
the
system
does
so
like.
I
think
you're
going
to
it
like
a
canonical
source
for
behavior,
and
it's
just
not
that
would
it
be
better
if
it
were
maybe
probably,
but
it
isn't
right.
So
you
can
say
things
in
open
api
that
don't
necessarily
correspond
to
what
the
validation
routines
do.
C
D
I
I
would
I
would
not
want
you
know.
I
would
not
want
union
to
sink
the
proposal.
I
will
put
that
out
there,
but
I
I
will
also
communicate
that,
like
one
of
the
very
common
current
requests
that
I
get,
you
know
as
as
a
controller
tools
maintainer
as
a
cue
builder.
D
Maintainer
is
like
how
do
I
write
stuff
like
volume
source
in
my
crd
right
and
like
people
point
out
hey,
I
could
write
the
open
api
by
hand
to
get
that
to
get
that
effect,
but
they
you
know
they
say
I
would
like
you
know.
I
would
like
a
higher
level
like
I
would
like
a
representation
where
I
you
know
where
I
can
write
something
that
looks
like
what
what
we
write
in
kubernetes
right
like
I
want
to
write
and
sort
the
market
as
a.
C
And
I
think
that's
a
that's
a
important
feature
and
it
is
on
our
list
in
the
it's
probably
up
after
immutable
fields
right
it's
on
our
list,
but
I
don't
know
that
adding
it
to
the
description
language
without
actually
making
the
system
support.
It
is
yeah
that
makes
sense.
H
And
I
was,
I
didn't
know
for
this
in
the
cap,
but
I
think
it
kind
of
weighs
on
that
whole.
We
have
a
lot
of
things
that
have
to
keep
working
and
we
have
some
more.
We
have
pragmatic
things
that
we've
been
chasing
for
a
while,
so
like
managed
fields
took
a
long
time
and
we're
still,
you
know,
working
through
the
implications
of
managed
fields.
We've
got
the
gogo
protobuf
disaster
happening
in
slow
motion,
certainly
there's
we
wanted
to
add
validation
and
defaulting
to
the
descriptive
language.
H
For
a
while,
I
was
kind
of
hoping
like
independent,
of
whether
an
ido
is
the
correct
solution
or
not
a
more
accurate
upstream
source
of
truth
for
that
could
be
attached
to
one
or
multiple
of
the
objectives.
Without
all
the
others
have
to
having
to
be
attached
is
a
desirable
thing,
but
I'm
one
of
the
concerns
I
think
I
have
about
changing
too
much
at
once
is
refactoring
for
the
forgetting,
where
we
are
like
back
to
where
we
are,
but
with
a
cleaner
structure,
doesn't
have
a
lot
of
appeal
for
me.
H
Personally,
let
me
never
be
like.
There's
doesn't
want
to
discourage
that.
Anyway,
it's
just
you
know
so
like
trying
to
think
through
making
the
case
for
him
for
a
big
change
like
this.
It
has
to
feel
incremental.
H
It
has
to
have
a
clear
it
has
to
accomplish
things
that
we
can't
accomplish
today
in
the
core
it
has
to
hopefully
free
up
time.
I
mean
anything.
That's
net
positive
developer
time
is
a
win.
One
of
the
challenges
I
think
we've
historically
had
is
a
lot
of
the
the
net
wins
have
been
for
individuals
like
outside,
and
then
the
core
contributors
basically
still
have
the
same
like
backlogs.
H
So
we've
done
a
lot
to
democratize,
maybe
one
of
the
angles
here,
and
this
is
partially
why
I
asked
sally
about
like
being
a
two
builder
thing.
First,
is
there's
nothing
more
democratizing
than
broad
communities
that
have
different
sets
of
problems
than
the
core
being
able
to
take
advantage
of
it?
I
don't
consider
that
a
failure
in
any
domain
like
experimentation
is
valuable.
H
It's
just
tough,
like
looking
at
the
list
of
things
in
the
in
the
core
backlog
that
could
be
magically
solved
by
this,
that
don't
involve
and
then
we'll
go.
Do
a
bunch
of
work
and
change
all
the
existing
stuff
and
get
back
to
where
we
were
so.
It's
like
finding
ways
for
the
ideal
to
take
on
and
help
us
solve
new
problems
would
be
one
angle
that
I
might
recommend
exploring
in
the
cap,
and
I
think
you
do
validation
defaulting,
but
then
emitting
things
that
we
don't
may
not
want
to
chase.
C
Yeah,
I
I
have
us
okay,
we
should
probably
time
box
this
in
one
more
minute.
I
I
have
a
slightly
different
take
on
that
which
is
like
just
in
the
interest
of
integrating
this
into
the
api
server
like.
I
would
like
an
integration
mechanism
that
is
a
lot
of
work
for
soli
and
not
work
for
anybody
else,
which
means
like
if
the
first
step
is
like
no
features
at
all,
but
it
also
doesn't
break
us
or
make
our
lives
harder.
C
Then
that's
fine
right,
the
the
I'm
fine
with
some
pre-factoring
we
don't
have
to
get
to
like
additional
features
immediately
in
the
first
step:
okay,
cool:
okay:
should
we
go
on
to
the
to
the
caps
and
just
do
this
without
david?
Clearly,
we'll
have
to
come
back
to
this
topic
in
the
future,
so
the
kepp
is
out
there
and
please
go
read
it
and
comment.
A
Caps
so
sure,
which
one
do
you
want
me
to
present?
We
have
our
internal
document
and
we
have
the
official
spreadsheet.
I
think
we
can
go
into
the
spreadsheet.
Maybe
that
is
more.
C
Yeah,
sorry
for
our
disorganization,
I
think
david
had
something
to
present,
but
yeah.
E
Don't
worry,
I
just
mentioned
something
really
quick
while
you
get
that
ready.
Yes,
so
a
couple
a
couple
sig
meetings
ago,
we
we
showed
that
we
have
a
cap
for
adding
apply,
support
to
client
go.
That's
like
a
typed.
You
know
like
an
actual
apply
call
with
with
the
type
that
you
pass
in
it's
an
argument.
E
We
have
working
prototypes
for
that
that
people
can
experiment
with
I've
added
it
to
the
agenda
here,
and
I
will
paste
a
link
into
chat
for
people
that
want
it.
We
are
looking
for
people
to
try
it
out,
but
there
is
a
document
explaining
how
to
try
it
out
and
then
we're
gonna.
There's,
there's
a
survey
that
you
can
fill
out
when
you're
done
we're
hoping
to
get
feedback
by
the
fifth.
So
we
can
feed
it
into
this
cap
cycle,
but
yeah
anybody
that
uses
anybody
uses
server
side
apply.
E
C
Yeah,
let's
go
through
it
real
quick.
I
think
you
can
even
put
the
I
think
it's
okay
to
I.
I
don't
think
the
spreadsheet
has.
E
C
The
document
that
david
started,
the.
C
Exactly
so,
we
went
through
outstanding
caps
and
well
maybe
I
should
call
them
pending
cups.
I
guess
it's
up
to
the
reader
to
judge
if
they're
outstanding
or
just
you
know,
ordinary
cups.
We
went
through
the
the
the
caps
and
came
up
with
some
that
we
think
we
want
and
we
left
others
and
we
tracked
down
some
people
et
cetera.
So
I
think
we
should
just
talk
through
them.
It
is
quite
a
lot
of
stuff,
I
think
we're
gonna
be
okay
but
yeah.
C
Let's,
let's,
let's
talk
about
it
server
side
apply
to
to
ga.
I
think
antoine
is
on
top
of
that.
I
don't
think
we
need
to
say
too
much
about
it.
C
C
Yeah
the
yeah,
so
please
go.
Please
go
take
a
look
at
that
joe.
I
think
you're
gonna
send
a
survey
out.
E
Yep
and
on
the
I'll
link
to
that
as
well
here
on
this
line,
but
yeah
there's
instructions
on
how
to
try
it
out
and
then
we
also
have
a
build
survey.
C
Yeah
yeah,
okay,
yeah
and
the
plan
is
to
get
something
merged
for
the
next
release.
Right.
E
Yeah
yeah,
we
have
working
code,
so
once
we
get,
I
mean
the
basically.
The
main
unresolved
question
is
like
how
we
represent
the
the
applied
configuration
once
we
get
feedback
on
that
I
hope
to
basically
get
consensus.
The
cap
is
it's
provisional,
with
the
only
end
result
being
that
one
particular
issue.
C
Yeah,
okay:
let's
see
we
should
probably
go
a
little
faster
here,
yeah,
okay,
so
we'll
get
that
in
the
in
the
list.
Next
is
the
kep
on
managing
managed
fields.
People
want
the
server
to
not
send
that
to
clients.
C
There's
actually
some
pushback
on
that
from
jordan,
who's,
like
seems
mostly
cosmetic.
I
don't
know
it
adds
a
little
bit
of
bandwidth
yeah,
so
I'm
actually
not
sure
where
we
are
in
that
one.
I
haven't
looked
into
it
recently,
but
I
think
I
was
thinking
about
that.
We
would
do
it
if
anyone
has
thoughts,
please
go
type
them
up
on
that
one
built-in
api
types
defaults.
C
I
actually
don't
know
what
the
status
of
that
one
is
is
antoine
on
the
call
no
way,
no
okay,
all
right,
but
we
want
it
skip
back
in
tls
verification.
I
believe
that's
actually
sig
auth.
We
don't
need
to
discuss
it
here.
Efficient
watch
resumption.
I
confirm
that
voicetech
is
going
to
continue
to
push
on
that.
That's
basically
the
the
one
where
api
server
sends
a
bookmark
to
watch
clients
before
it
shuts
down
namespace
labels.
That
is
a
very
tiny
amount
of
code.
C
It's
like
100
comments
or
something
on
a
cap
for
like
five
lines
of
code
or
something,
but
I
think
we've
been
convinced
and
it's
approved,
and
I
think
I
even
put
in
the
list
already
yeah
so
there's
that
one
requiring
transition
from
beta,
I
think
we're
working
on
some
email
to
announce.
So
everybody
knows
exactly
what
is
getting
deprecated
and
when,
even
though
that's
been
published
in
many
places
already,
I
don't
want
any
surprises.
C
Page
list
queries.
This
is
a
good
one.
Actually,
clayton
are
you
planning
on
doing
any
work
on
this.
C
Yeah,
I
think
I
I
think
the
there
was
a
pending
question
about
like
pagination,
doesn't
work
out
of
the
watch
cash
and
I
think
david's
position
which
I
agree
with,
is
that
it's
been
the
way
it
has
been
for,
like
10
releases
or
something
ridiculous.
So
we
should
just
call
it
ga,
because
we're
clearly
not
going
to
do
anything
about
it.
Yeah.
H
H
I
think
in
practice,
client
like
we're
already
well
and
truly,
you
know
the
kids
in
college
and
we've
done
all
we
can
in
the
sense
of
if
we
change
any
semantics
now,
regardless
of
whether
it's
better
or
not,
it's
going
to
break
the
world.
So
it's
effectively
ga
I'll
go
through
and
do
a
follow
up
and
chat
with
I'll
go
I'll
canvas.
Folks
who've
had
comments
over
the
years,
just
to
make
sure
there's
nothing
outstanding.
C
Yeah,
okay
sounds
good.
Next
two,
I
think
we're
just
paperwork.
We
don't
need
to
dwell
on
those
clinco.
That's
also
paperwork
api's
rubber
tracing.
I
took
an
action
item
on
that
one
there's
a
pr
out
that
is
rather
large
and
has
a
lot
of
dependencies,
and
I
would
appreciate
any
assistance
on
that
yeah.
I
think
this
is
it
yeah,
it's
quite
large
and
I
think
that's
the
last
one
that
we
need
to
go
through.
C
I
think
I
took
care
of
all
the
others,
so
yeah,
that's
the
that's
the
kept
list.
Does
anybody
on
the
call
have
one
that
we
missed
that
we
should
include.
A
A
I
can't
reach
out
to
andrew.
I
have
this
one.