►
From YouTube: Kubernetes SIG API Machinery 20210210
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
Good
morning
for
everybody
on
the
pacific
coast,
hello
around
the
world,
this
is
sig
api
machinery.
Bi-Weekly
meeting
today
is
february
10th
of
2020.
Thank
you
for
everybody
that
has
joined
today.
I
hope
you
are
doing
fine
in
these
crazy
times.
A
B
Maybe
kevin
yeah,
so
this
was
originally
brought
up
by
somebody
else,
but
I
was
doing
some
similar
changes,
so
I
can
discuss
this
and
the
so.
The
big
thing
here
is
about
some
some
changes
to
the
shared
informer
interface
and
the
first
change,
which
was
by
mendelsoff's
pr,
is
about
adding
the
ability
to
remove
event,
handlers
and
track
the
the
number
of
event
handlers
on
an
informer
and
basically
just
wanted
to
make
sure
there
was
no
concerns
with
adding
to
the
shared
informer
interface.
B
These
couple
methods
that
get
pointed
to
in
this
pr.
So
it's
basically
on
the
on
the
on
the
shared
informer
and
it
adds
a
remove
event
handler
an
event
handler
count
and
it
is
stopped
and
is
started
as
you
can
see
right
there,
and
there
was
some
discussion
and
back
and
forth
about
whether
we
wanted
to
add
it
to
the
sheraton
former
interface
or
create
an
extended
some
sort
of
extended
interface.
But
this
is
kind
of
what
the
the
people,
what
we've
settled
on
and
just
wanted
to
make
sure.
C
I
don't
have
concerns
about
adding
to
the
interface.
I
think
that
makes
sense.
This
is
quite
the
pr
and
it
looks
pretty
pretty
involved
and
intricate.
You
can
come
in.
B
You're,
looking
at
the
second
one
right,
the
one
that's
about
the
yeah.
C
Changing
the
the
informer
life
cycle.
B
Yeah,
so
that's
that
one's
definitely
gonna
get
split
up,
and
that
was
kind
of
the
next
thing
I
was
gonna
talk
about
was
you
know,
two
interfaces
changes
there,
and
this
was
from,
I
think,
an
earlier
discussion
we
had,
but
basically,
what
that's
doing
is
is
kind
of
three
things:
one
changing
the
informer
interface
to
to
allow
the
the
run
with
stop
options
up
and
then
the
second
thing
is
actually
using
that
change
in
controller
manager,
and
the
third
thing
is
like
fixing
a
bug
in
garbage
collector
that
now
uses
that
with
the
new
changes
will
stop
spamming,
cube
controller
manager,
logs
and
so
that'll
get
broken
up
into
basically
those
three
discrete
pieces,
but
they
were
all
kind
of
wrapped
together
for
at
least
the
initial
review
to
make
sure
it
all
makes
sense
together
like
that,
and
that's
still
kind
of
going
through
a
view
with
with
with
you,
you
yao,
but
yeah,
those
those
will
get
broken
up
into
three
pieces,
but
wanted
to
now
that
we
actually
have
a
pr
up
for
it
and
are
kind
of
set
on
the
on
the
interface
changes
wanted
to
get
get.
B
One
here
that
was
the
yeah
that
one's
smaller
and
that
one's,
not,
I
don't,
think
it's
not
the
big
one
and
not
the
one
that
that
david
was
concerned
about
oh
okay,.
C
Yeah,
it's
the
second
one
anyway.
I
just
want
to
make
sure
that
you
know
that
you
and
your
reviewers
take
all
due
care
in
that
area.
A
Yeah,
yes,
perfect,
that's
great!
I
also
have
been
corrected
that
we
are
in
the
year
2021
and
not
2020.
So
I
just
wanted
to
say
that
for
the
record
in
the
meeting-
okay,
very
good,
can
we
move
to
the
next
one.
The
duck
types
for
kubernetes.
D
Howdy
yeah,
can
we
get
a
quack
quack?
No,
I
don't
know
sorry,
I
mean
so
okay
right.
So
I
I
wrote
a
little
proposal
here.
I
I
wrote
a
little
thing.
I
basically
copy
and
pasted
the
same
document
into
the
sig
mailing
list.
There's
there's
some
more
references
that
you
can
read
based
on
some
of
the
links
in
this
document.
A
D
Almost
there
we
go.
Can
you
see
this
little
section
of
my
screen
here?
Okay,
so
yeah?
I
wrote
this
little
document
there
there's
some
other
interesting
documents
that
we've
developed
over
the
time,
maybe
a
couple
years
ago,
describing
what
we
do
with
duck
typing.
Inside
of
the
scope.
D
There
was
a
native,
but
I
think
we
are
ready
to
kind
of
talk
with
the
community
to
bring
it
upstream
into
kubernetes
itself,
and
I
it
would
be
interesting
to
be
able
to
start
in
some
sort
of
sig
repository
to
enable
two
things
right
so
producing
tooling,
to
help
generate
listeners
and
informers
around
duct
types.
D
D
They
all
have
kind
of
similar
shapes,
sometimes
like
one
example
would
be
like
we
call
it
pod
speckable,
but
things
that
have
a
template
and
a
pod
definition
that
and
then
those
things
go
off
and
build
pods
as
a
result,
so
deployments
replica
sets
and
k-native
services
we've
chosen
this
shape
on
purpose,
because
it
lets
us
kind
of
target
that
template
piece
and
we
can
make
mutations
on
resources
that
adhere
to
that
same
shape,
but
without
knowing
the
actual
type
right.
D
So
this
is
the
the
point
about
duct
typing
is
we
understand
some
partial
schema
contract
for
the
resource
in
the
kubernetes
control
plane?
We
can
read
or
potentially
even
write
to
that
resource
in
that
partial
schema
shape
without
understanding
the
full
schema
and
there's
a
bunch
of
tricks
that
we
can
leverage
to
do
that
work,
and
so
the
proposal
here
is.
We
can
upstream
those
tricks
right
so
that
everyone
doesn't
have
to
rewrite
them
all
the
time.
D
And
if
you
go
down
here
to
the
current
implementations,
this
is
kind
of
a
short
list
of
where
we
found
code,
duplication
or
duplicated
efforts
of
folks
that
are
trying
to
solve
this
or
a
similar
problem
in
the
ecosystem
of
kubernetes.
So
it
feels
like
a
general
enough
problem
that
we
can
look
at
what
what
we
could
do
to
make
common
tooling
for
the
community.
D
So
I
talked
about
the
listeners
and
informers.
There's
there's,
maybe
also
a
this
new
resource
kind
to
discover
duct
types
that
are
installed
in
your
cluster
and
I
have
a
little
demo
of
what
you
could
do
with
that.
D
If
you
would
like
to
see
okay,
so
the
little
a
little
bit
of
context
is,
let
me
move
this
okay.
So
in
k
native
sorry,
it's
a
it's
a
demo
with
k
native
pieces,
but
I'm
going
to
show
you
just
pure
kubernetes
pieces
too.
We
have
something
called
k-native
service.
The
service
exposes
its
address.
D
And
we
use
that
to
be
able
to
understand
how
to
route
to
it
on
the
data
plane
right.
So
it's
going
to
go
through
some
ingress
or
whatever
right
like
we
don't
really
know,
we
don't
really
care
all
we
care.
That
is
that
the
the
partial
schema.
So
if
we.
D
I'm
looking
for
the
I
don't
have
a
copy
of
that,
but,
okay,
so
actually
sorry,
let's
just
do
this
demos
of
the
steps.
So
I
I'm
going
to
make
a
k-native
service.
I
have
a
little
a
very,
very
simple
main
file
here.
It's
just
gonna
start
up
an
http
server
and
it's
going
to
report
back
with
a
hello
world.
If
you
send
nothing
to
it.
D
D
That's
that's
cool,
but
we
also
have
this
thing
in
canada
called
the
domain
mapping,
and
so
what
a
domain
mapping
does
is
lets
you
put
a
pretty
domain
on
onto
other
services
that
expose
the
addressable
part
right
right,
so
this
url
that
we
showed
in
the
coop
cuddle
git
status
is
in
fact
inside
the
spec
because
it
has
to
be
so.
If
we
look
at
there,
the
partial
schema
for
this
thing
that
I'm
calling
addressable
is
status.address.url
right,
so
that
little
slice
of
schema,
okay
and
so
what
what
I've
built
is.
D
I
would
like
to
take
things
that
are
addressable
and
give
auto
give
them
a
domain
mapping
and
what
a
domain
mapping
is
is
a
pretty
url
that
helps
me.
As
the
request
comes
into
the
cluster,
things
that
are
have
domain
maps
can
be
looked
up
and
then
rot.
The
traffic
can
be
routed
to
the
addressable
that
has
been
registered
for
that
pretty
domain.
Okay,
so
we
can
make
one
manually,
but
what
I'm
gonna
show
is.
D
I
call
it
the
sugar
controller,
it
adds
sugar
syntax
onto
resources
in
the
cluster,
and
I
can
do
this
because
the
sugar
controller
is
running
on
it's
looking
at
addressable
duct
types
in
the
system,
so
I'm
going
to
patch
that
hello
service
with
a
special
annotation
that
the
sugar
controller
is
going
to
recognize
and
as
a
result,
it's
going
to
make
a
domain
mapping
for
the
the
label.
D
That
was
there
right
and
so
here's
the
get
domain
mappings
that
thing's
shown
up
and
over
here
we
have
a
curl
call
getting
that
same
url,
so
it
did
in
fact
wire
up,
but
that
was
that
was
fun.
D
I'm
going
to
allow
the
domain
mapping
to
do
this
for
me,
and
this
is
a
particular
feature
of
eventing,
I'm
going
to
patch
that
service
that
was
associated
to
that
deployment
and
give
it
the
special
annotation,
and
we
can
see
that
helloworld.getrec.dev
spun
up
a
domain
mapping
it.
It
did
all
the
registration
and
stuff
and
now
from
the
outside
the
cluster,
because
this
is
running
in
azure.
I
can
ping
that
internal
kubernetes
service
so-
and
you
know
we
can
do
things
that
you
expect
like.
D
D
Demo.Hello
so
that
that
edited
and
then,
if
we
can
get
the
domain
mappings,
the
it
updated
and
it
garbage
collected
that
other
one,
because
that's
what
it
needs
to
do
and
in
this
window
I'll
show
you.
D
How
to
mistype
so
we'll
just
delete
that
service
and
we
get
garbage
collection
all
right.
So
then,
so
this
is
all
enabled
so
basically
what's
happening
in
the
the
demo.
Repos
is
that
I
have
a
controller.
That's
looking
for
something
called
a
cluster
duct
type
of
addressable-
and
here
is
this:
the
co
inside
the
cluster.
D
D
I
special
case
services
like
the
built-in
resource
type,
because
I
can't
label
that
thing
right.
I
can't
go
into
the
api
server
and
put
labels
on
kubernetes
resources,
and
then
I
you
know
I
can,
I
don't
know,
define
the
partial
schema
and
then
the
resulting
status
is
every
duck.
That's
installed
in
this
particular
cluster
at
this
instance,
and
it
shows
me
all
of
the
things
that
I
can
do
so
I
have
this
the
sugar
controllers
watching
for
this
particular
resource
and
for
every
duck
in
this
list.
That's
unique.
D
I
spin
off
another
controller,
that's
watching
for
the
addressable
type
based
on
that
gbk
and
then
I
can
do
some
magic
with
you
know
the
demo,
with
the
labels
and
stuff
one
example
of
what
you
can
do.
There's
other
examples
in
k
native
that
we
have
cluster
api,
has
a
ton
of
very
similar
examples
of
what
they're
doing
with
partial
schemas
and
contracts
on
the
control
plane.
D
And
this
is,
when
you
tell
me,
your
mic:
hasn't
worked
for
the
last
15
minutes.
F
I
wanted
to
put
in
one
clarification,
I
think
correct
me.
If
I'm
wrong,
there's
two
pieces
here,
there's
a
library
on
the
client
side.
That
makes
it
a
lot
easier
to
do.
Listers
and
informers
and
watch
a
duck
type
yeah,
yeah,
yeah
and.
F
D
H
Let
me
ask
you
this:
the
the
client
side
portion.
Does
it,
does
it
can
it
if
you
didn't
compile
the
client
with
knowledge
of
certain
like
objects
to
interface
mappings?
Can
the
client
still
act
on
those
types.
D
So
the
slight
mis-mis-speaking
is
that
it's
not
it's.
It's
client
gen,
not
coupe,.
I
So
the
client,
the
client
I
mean
the
the
duct
type
stuff-
is
dealing
with
a
partial
schema
and
we
generate
client
stuff
for
the
partial
schema.
We
do
not
need
to
know
ahead
of
time
all
of
the
mappings
of
like
gdk's
gdrs
to
that
implement
that
partial
schema.
So
I
can.
I
can
build
something
that
deals
with
a
particular
duct
type
stand
up
a
controller.
I
I
can
introduce
a
new
type
into
the
system
that
that
might
become
aware
of
through
various
means,
and
it
can
start
acting
on
it.
You
know
so,
for
instance,
if
it
comes
across
a
new
resource
that
has
an
object
ref
to
a
type
it
hasn't
seen
before.
But
you
know
the
contract
of
that
ref.
Is
that
thing
implements
the
you
know
the
scott
duck
type
right?
Then
it
can
basically
start
to
act
on
that
type
via
those
mechanisms.
C
So
in
thinking
about
things
that
could
make
this
potentially
easier
but
would
be
smaller
than
bringing
in
an
entire
client
like
that,
I
would
probably
be
thinking
about
things
like
an
ability
to
wrap
a
dynamic
client
in
something
that
could
cast
to
and
from
so
you
could
create
a
client
that
was
easy
to
use
and
cast
to
your
duct
types.
C
C
I
would
imagine
having
a
a
crd
act
as
a
registry
does
seem
like
a
significant
one,
that
I
might
be
sort
of
less
inclined
to
to
immediately
embrace.
C
And
it
technically
wouldn't
be
because
every
client
would
have
to
know
what
they're
looking
for,
but
it'll
take
a
lot
more
work
right.
You'd
have
to
inspect
the
open
api
yourself,
and
so,
if
they're,
having
an
informer
rate,
that
would
probably
be
the
way
they
short
circuit
and
make
that
I
mean.
J
So,
in
general,
we're
doing
we
have
a
bunch
of
machinery
for
telling
users
what
apis
are
supposed
to
be,
and
our
exposure
of
them
is
pretty
atrocious.
Right,
like
crds,
have
structural
schema,
but
people
don't
put
good
comments
on
them.
Where
do
you
go
get
the
comments?
How
do
you
keep
those
up
to
date?
Cube's
comments
are
written
by
robots
for
robots
in
the
api
docs,
no
matter
how
hard
we
try,
but
I
mean
like
it's
the
only
it's
the
most.
It's
the
most
meaningful
way
that
you
communicate
with
a
human.
J
There
are
places
I
could
imagine
where,
like
drafting
on
the
communication
for
a
human,
you
can
create
incentives
that
reward
people
for
doing
the
right
thing.
The
registry
is
a
step
further,
but
like
going
and
looking
at
a
whole
bunch
of
open
api
objects
to
figure
out
what
the
heck
kind
of
cube
type
is,
is
basically
the
heart
of
solly's
problem
with
idl
and
it's
the
heart
of
the
validation
problem
in
building
clients
in
any
language,
as
well
as
communicating
with
humans
about
what
the
heck.
The
purpose
of
a
like
a
new
object
shows
up.
J
What
is
it
for
who
understands
it?
So
I
kind
of
by
the
argument
that
any
investment
that
we
can
do
that
rewards
like
humans,
machines
and
duct
typing
is
a
is
a
good
central
one
and
then
some
of
the
other
aspects
of
it
like
that
are
a
little
bit
more
speculative
or
domain
specific.
Could
we
structure
it
so
that,
like
those
those
by
creating
the
first
set
of
value,
then
the
second
one
start
becoming
more
valuable
as
well,
even
if
we're
not
all
agreed
on
it
right
now
and
yes
and
you.
I
E
Can
I
do
it?
I
was
just
curious.
You
said
you
had
some
hesitations,
I
I
didn't
is
there
some
particular
sorry?
This
is
in
in
particular,
with
the
registry.
E
C
J
That
was
my.
That
was
my
gut
reaction
as
well
is
like
the
duct
typing
idea
like
I
don't
even
know
why
we're
still
discussing
it
like,
of
course,
this
is
how
people
deal
with
systems.
This
is
how
humans
deal
with
systems.
They
look
at
two
workload,
types
and
they're
like
these.
Both
look
like
workload
controllers
and
a
whole
bunch
of
people.
J
D
If
it
wasn't,
if
it
wasn't
clear
in
the
document,
the
one
of
the
first
artifacts
that
we
would
try
to
present
is
exactly
what
was
was
asked
for
it's
it's
a
wrapper
around
dynamic
client
that
helps
you
get
strongly
typed,
listers
and
informers.
That
result
in
the
instance
of
the
duct
type
right.
So
you
get
to
use
the
same
api
client
gens
that
you
get
except
this
thing
is
a
dynamic
type
that
you
kind
of
ask
for
at
runtime.
C
Yeah
now
I
will
say
that,
like
some
of
that
challenge
is
how
many
people
actually
can
review
that
sort
of
a
change.
Actually,
I
guess
the
people
that
you
need
to
review.
It
are
probably
exactly
the
ones
currently
reviewing
kevin's
pr
from
the
beginning
of
this
meeting,
but
you
know,
rather
than
then
go
off
and
build
something
in
parallel
in
a
different.
J
The
david
you
brought
this
up
in
the
background
so,
like
the
other
concern
I
have
is
like,
I
don't
want
to
say
this
is
not
a
dispersion
on
anyone
involved
in
this,
because
we're
all
equally
complicit
like
unstructured
is
a
giant
disgusting
mess
of
like
we
put
something
in
place.
We
haven't
moved
on,
but
it's
fundamental
to
the
ecosystem
doing
more
to
work
through
those
like
that
is
a
core
cube
investment.
J
I
think
that,
like
david,
I'm
speaking
on
your
behalf
in
the
sense
of
like
we're,
probably
going
to
need
to
go,
make
some
investments
to
clean
that
up
over
time.
It's
already
a
performance
issue.
Crds
are
already
like
we
use
a
ton
of
crds
and
it's
just
like
a
mess
in
terms
of
like
a
bunch
of
characteristics
of
them,
so
like
unstructured
in
an
evolution
of
unstructured,
better
client,
tooling,
better
mindset
around
how
open
api
maps
to
schema
maps
to
some
of
the
stuff
sully's
talking
about
these
are
all
like
non-obvious
or
non-uh.
These.
D
Right
and
the
repo
that
I'm
asking
for
is
a
place
to
prototype
things
that
its
long-term
life
cycle
is
probably
goes
away
because
they
get
upstream
to
other
places.
I
think
there
was
a
comment
around.
Why
don't
we
just
do
this
inside
of
like
controller
runtime
and
the
the
answer?
Is
that
there's
more
than
one
way
to
make
a
controller?
And
we
would
like
to
downstream
this
stuff
and
not
have
it
in
k
native
and
we
don't
use
it.
H
Here's
here's
my
question:
is
there
a
reason
not
to
like
just
make
this
work
with
the
with
the
informer
stuff?
That's
in
clientgo
right
now
like?
Is
that
an
all
is
that
a
plausible
alternative.
H
H
D
If
there
was
a
group
that
found
some
subset
of
things
like
objects
or
ownership,
reference,
dockers,
yeah
right,
like
those
those
things
could
be
generated
in,
except
as
an
example
like
this
here's,
what
a
duck
type
look
like:
here's,
how
you
use
it!
Here's
some
yeah,
you
typed
informers
that
you
give
it
some
gpks
and
you
get
back.
E
D
Owner
raffa,
whatever
they
are
right,
but
you
still
need
the
tooling
like
that
base
tooling.
To
make
that
all
happen,
and
and
again
like
we're
not
in
k
native.
We
we've
made
a
lot
of
effort
to
not
reinvent
some
interface.
It's
just
using
like
the
standard,
coupe,
client
client
set
interfaces
for
listers
and
formers,
and
factories
and
stuff.
H
Yeah
I
I
kind
of
have
an
ulterior
motive
for
for
bringing
this
up,
because
I
I
like,
if
we
take
on
something
like
this,
like
we've
gotta,
have
I
I
feel
like
some
some
things:
we've
we've
we've
taken.
E
H
And
that
hasn't
really
integrated
completely.
Yet,
like
we
own
a
bunch
of
sega
api
machinery,
it
was
a
bunch
of
sub
projects
and
I
think,
if
we
take
more
on,
we
need
to
make
sure
that
there's
like
a
really
clear
path
to
how
it's
going
to
be
well
integrated
with
all
the
other
things
that
we
own
and
there's
not
enough
david.
And
I
to
like
personally.
H
So
I
like
it
has
to
be
like
a
a
two-way
street
if
that
makes
sense.
So
that's
that's.
Why,
like,
if
you're
gonna
help
us
with
some
client
go
responsibilities,
and
this
actually
becomes
a
bit
of
an
easier
sell?
Does
that
make
sense.
C
I
I
also
just
I
agree
with
what
daniel
just
said
there,
and
so
you
know
phasing
in
carefully
and
not
trying
to
nuke
the
world
and
say
I
think
this
is
how
clients
should
be.
I
think
you
get
a
much
easier
path
to
success
by
trying
to
come
in
sort
of
consistent
with
what
we
have
and
build
on
top.
Instead
of
changing
that.
D
And
then
we
could
do
that.
The
the
majority
reason
why
I'm
asking
for
that.
The
repo
is
to
prototype
that
the
discovery
resource
the
the
cluster
duct
type,
because
it's
going
to
be
an
installable
component
that
has
an
artifact
that
you
would
that's
releasable
so
like
that.
Doesn't
really
have
a
good
home
right
now,
but
if
we
can
find
a
place
for
it
and
it's
behind
some
flags
or
something
maybe.
C
So
yeah,
if
the
discovery
resource
is,
is
second
at
least
the
way
I've
understood
it
and
the
way
I'm
envisioning
this
code.
I
think
the
discovery
resources
is
secondary
to
the
the
fundamental
backing
which,
as
I
understand
you,
you'd
have
a
fair
number
of
pieces
built
around
it
in
my
head.
If
I
were
building
it,
I
have
a
few
more
pieces
around
it.
I
want
to
try
to
bring
in
the
stuff
that
is
sort
of
easier
to
agree
on,
and
then
the
resource
is
significant.
It
would
be
paired
with
a
controller.
C
H
Yeah,
I
think
I
think
that
that
sounds
pretty
good
to
me
too,
if,
if
we
take
this
on
a
as
yeah
small
chunks,
that
add
value
without
without
like
that
that
that's
that,
that's
that
that
sounds
like
a
win
to
me
and
if
we're
making
client
go
better
in
the
process
that
that
definitely
is
is
appealing
yeah.
H
H
The
I
agree
with
david,
like
adding
a
crd
registry,
and
that
sounds
a
little
heavy
weight
to
start
out
with
it.
I
can
definitely
believe
that
it'll
be
useful
in
the
future,
but
I
think
there's
enough
stuff
existing
already
in
cluster
in
clusters
that
if
we
just
made
the
client
work
with
that,
then
that'd
be
good
right.
If
you
start
with
the
registry,
then
you've
got
you've
got
to
add
a
bunch
of
stuff
before
that
adds
value.
D
D
Should
I
okay?
So
if
I
should,
I
write
a
kep,
that's
like
talking
about
adding
this
kind
of
functionality,
the
just
the
kind
of
the
helper
libraries
to
client,
gen
and
things
like
that.
That's
the
first
next
step,
yeah.
H
I
think
that
sounds
about
right.
Like
I
don't
know
david,
do
you
think
we
should
stick
it
all
in
one
cap
or
do
you
think
there's
room
for
a
couple
different
cups
here.
C
I'm
trying
to
think
like,
I
guess
I
can
see
a
cap
is
a
good
way
to
structure
and
describe
it.
I
would
say
that
the
evolutionary
change
that
we
described
isn't
necessarily
like
each
individual
step
isn't
necessarily
kept
worthy
right
if
you
bring
in
and
like
so
basically,
I
would
like
to
see
it
a
cap.
C
Is
a
nice
structured
way
to
put
it,
I
don't
need
a
huge
amount
of
formal
stuff
if
your
piece
is
small
enough
right,
if
it's
small
enough
to
look
at
it
and
say
yes,
an
interface
that
does
this
with
these
inputs,
and
these
outputs
is
a
good
idea,
and
it's
it's
just
a
tweak
on
what
we
have.
I
don't
think
I
make
it
like
sit
through
an
enhancement
cycle
and
be
featured
all
that
stuff.
C
I
would
look
at
it
and
say:
okay,
this
builds
on
an
api
that
we
have
it's
the
next
evolutionary
step,
yeah.
H
C
Want
to
create,
say,
a
crd
with
this
registry,
I'm
going
to
come
down
on.
Yes,
definitely
a
cap,
we're
going
to
have
to
sit
down
and
discuss
what
we
want
to
do.
You
know
I
don't
see
a
reason
to
sort
of
gate
everything
on
that,
at
least
not
if
I
were
you,
I'd
want
to
get
the
the
common
infrastructure
in
that's
non-contentious.
First,.
D
Yeah
yeah,
that's
that
sounds
good
and,
and
there
won't
really
be
any
new
interfaces
defined
it's
it's
maybe
a
new
way
to
ask
for
a
factory,
and
then
everything
else
is
just
standard
interfaces.
D
Mutation
is
interesting
and
we
should
talk
more
about
server
side
apply,
because
that
might
help
the
problem,
because
we
have
to
be
very
tricky
about.
You
know
we
have
to
save
the
original
or
we
have
to
keep
the
original
copy
and
then
diff
it
with
the
mutation
and
then
do
a
patch
to
apply
for
spec
changes
and
things
like
that
or
status
updates.
Although.
C
H
E
Do
you
all
see
any
value
in
starting
the
process
on
the
discovery,
given
the
fact
that
it
takes
a
little
bit
longer
like
if
it's
I
I
the
reason
why
I
asked
david
about
that
earlier?
It's
like,
I
can
certainly
see
where
you're
like
look
you're,
not
gonna,
need
it,
let's
not
build
it
quite
yet,
but
I
didn't
hear
any
sort
of
kind
of
a
strong
like,
oh
my
goodness,
it's
total
garbage.
E
C
Okay,
so
in
all
honesty,
given
what
the
sig
is
trying
to
deliver
this
release,
this
one
and
sig
off,
I
don't
think
I
have
time
to
sit
down
and
review
a
cap
in
discovery.
Even
if
you
just
wrote
it.
H
Got
it
yeah
yeah,
I
would
say
you're
absolutely
welcome
to
write
one.
I
can't
make
any
promises
about
reading
it
in
the
near
future.
D
Yep,
it's
it's
fine
we
haven't
had
it
for
and
like
canada,
doesn't
quite
use
it
in
a
lot
of
places.
Yet
because
it's
fairly
new-
and
I
thought
well
we're
going
to
talk
about
duck
types
in
upstream-
maybe
we
upstream
that
that
concept,
but
you
know
this,
it
probably
could
inform
some
crd
resource
changes
and
stuff
like
that
too.
D
Actually,
so,
the
one
concrete
use
case
for
all
this
stuff
is
these
resources
that
we've
been
building,
that
kind
of
point
to
other
resources,
and
so
how
we
use
the
duct
type
concretely
is
there's
an
object
reference
in
a
spec
of
another
resource
that
says
hey
over
there.
I
want
to
talk
about
that
resource
and
the
little
dotted
line.
That
is
the
object
reef
resource.
We
define
that
as
this
must
be
this
duct
type
right
and
then
we
can
do
validation
and
then
the
point
of
this
cluster
duct
type
is
potentially
you
could
get.
D
H
Yeah
yeah
that
that
that
yeah,
I
can
see
how
that
is
handy,
but
that
that's
gonna
be
like
much
more
extensive
changes
to
our
our
like
validation
pipeline
and
like
defaulting
and
all
that
stuff,
which
I
can't
say
I'm
opposed
to.
But
we
have.
H
We
have
other
things
that
I
think
are
first
in
line
like
making
unions,
work
or
immutable
fields,
but
yeah
people
often
ask
for
or
often
want
things
that
involve
references
to
like
type
references
like
g
would
be
nice
if
this
part
of
my
crd
were
a
pod
spec
and
that
were
in
sync
with
the
version
of
pod,
that's
installed
with
the
in
the
cluster,
and
I
think
we
haven't
implemented
such
a
feature
because
it
sounds
hard
and
I
think
we
should
definitely
consider
like
right,
like
that.
H
D
To
this
duct
type,
yeah,
and
then
the
long
game
here
is,
we
could
bring
like
so
once
everyone's
kind
of
on
the
same
page,
around
duck
typing,
and
these
partial
schemas
and
people
start
wanting
to
modify
the
those
ducks
we
could.
We
could
bring
back
up
the
topic
of
custom
sub
resources.
D
As
you
know,
a
an
are-back-able
way
to
make.
Could
other
controllers
control
bits
of
your
spec
yeah?
That's.
C
C
I
would
like
that
duck
typing
pig
picture
in
and
whatever
caff
eventually
gets.
H
Yes,
duck
legs
are
delicious
by
the
way
all
right,
yeah,
thanks
for
showing
us
the
demo.
D
Thanks
for
listening
so
I'll
I'll
start
poking
at
you
know
some
client
stuff.
A
Sounds
good,
very
good,
thank
you
and
I
think
we
have
one
more
topic.
Speaking
about
the
devil,
we
were
mentioning
servers
I
apply
so
joe.
Do
you
want
to
time
in.
K
Yeah,
I
don't
want
to
belabor
this
we've
been
asked
a
while
ago
some
people
had
said
there
was
an
interest
in
hearing
an
update
on
how
service
out
of
pi
was
going.
So
I
thought
we
would
just
give
a
really
brief
update
and
give
some
links
to
people,
so
we
are
targeting
the
1.21
release
for
ga,
so
we
have
that
we
have
the
cups
in
for
that
there's
a
task
list
here.
K
If
anybody
wants
to
look
at
on
the
burn
down
and
the
progress
we've
made
on
various
things,
so
there's
a
lot
of
focus
in
the
next
month
on
getting
like
client
support
going
for
this.
So
we've
been
working
with
coop
builder
we've
been
working
with
client,
go,
we've
gotten
some
feedback
from
the
community
on
those.
So
that's
a
push
for
making
there's
also
a
couple
outstanding
items
around
dangling
fields
and
status,
wiping
and
some
other
things.
So
I
won't
say
too
much
more
antoine.
L
A
Sorry,
sorry,
too
many
screens
I
just
wanted
to
ask.
If
you
know
there
was
anything
special
that
we
have
to
do
to
address
the
comments
about
the
the
client
and
the
topic
with
duck
types
that
we
want
to
highlight
or
know.
K
I
would
be
certainly
happy
to
talk
to
people
on
what
we
could
do.
I
think
the
probably
the
first
step
would
be
have
a
look,
have
a
look
at
the
cap
for
the
apply
clients.
There's
there's
a
if
you
just
go
into
enhancements,
you
can
see
it
there
or
if
you
can't
find
it
just
ping
me
on
slack
or
something
and
there's
some
there's
some
links
around
too
but
yeah.
I
would
say
start
by
looking
at
that
and
seeing
seeing
how
well
it
fits
your
needs.
K
G
Very
good
during
the
duck
piping
discussion.
I
I
thought
like
to
some
extent
maybe
apply
already
allows
you
to
do
some
duct
typing,
because
you
can
specify
a
partial
spec,
so
you
can
like
specify
only
the
fields
you
want
to
apply
and
that
could
work.
But
it's
very.
H
Yeah
yeah
important
right,
it
doesn't
define
a
a
mapping
that,
I
guess
that's.
That's,
probably
the
the
missing
the
missing
piece
there.
D
H
Yeah
that'd
be
that'd,
be
pretty
cool.
In
fact,
I
wonder
if
it
would
be
so
cool
that
the
the
generator
should
should
actually
generate
the
the
builder
types
that
we're
introducing
with
the
apply
client.
J
Yeah,
I
think
evan
just
said
something
really
important,
that
I
did
want
to
call
out
so
like
it's
hard
to
watch
the
duct
type
with
the
current
client.
There's
a
general
problem
that,
like
big
controllers,
big
consoles,
whatever
have,
which
is
watch,
is
complicated
to
deal
with
in
large
scopes
like
you,
can
put
a
for
loop
around
types
and
sure
that
works
up
to
a
certain
point.
J
We've
had
some
historical
stuff
over
the
last
few
years,
people
proposing
ways
of
watching
multiple
things,
having
better
watches,
I
think,
there's
at
least
some
need
to
maybe
ask
some
questions
and
look
at
some
future
direction
for
watch
and
like
watch
aggregation
scaling
watch.
I
think,
watching
across
multiple
namespaces
is
something
that
there
are
a
subclass
of
problems
that
if
we
had
would
be
much
cleaner,
just
whether
it's
informer
machinery
or
whether
it's
actually
the
api
server
should
support
it.
J
J
All
of
those
are
because
essentially
like,
if
you're
trying
to
build
anything
meaningful,
that's
not
a
really
small
controller
loop,
you're,
talking
5
10,
15
resources,
and
you
start
wanting
to
do
generic
things.
The
moment
you
talk
about
generic
things
across
lots
of
resources,
you
basically
just
open,
700,
watches,
and
then
you
know,
oops
lull,
your
way
out
of
the
problem.
So
it
doesn't
want
this
idea
a
separate
problem,
but
be
interested
yeah.
H
Yeah,
I
think,
there's
a
separate
problem.
I
I
would
be
interested
in
a
I,
don't
know,
concise
list
of
what
is
blocked
on
improvements
to
watch
right
like
a
a
a
a
problem
statement,
and
it's
probably
more
than
one
problem,
but
I
I
think
it
would
be
super
helpful
to
have
a
list
of
the
actual
problems
that
need
to
be
solved
because.
J
Garbage
collectors
garbage
collector
was
like
the
first
time
that
we
ever
really
struggled
with
it
and
named
space
controller,
and
those
are
like.
We
basically
are
just
like
we'll
just
watch
everything.
It's
fine,
there's
a
whole
class
of
people
out
there,
just
hacking,
this
stuff
together
and
so
yeah,
getting
a
concise
group
and
evan
if
you're,
interested
or
there's
somebody
in
the
k
native
space
I'll
help
connect
you
with
some
other
people
as
well.
D
One
free
foot
gun
we
found
was
so
we
have
this
like
fancy,
duck
type
watcher,
that's
based
on
the
dynamic
client,
but
we
also
have
typed
clients,
and
so
we
have.
We
sometimes
run
into
a
situation
where
we
know
we
want
to
interact
with
an
actual
object,
that's
of
a
certain
type
and
we
interact
through
its
generated
cl
typed
client,
which
talks
through
its
cache.
D
But
we
get
invoked
to
the
reconciliation
through
the
dynamic,
duct
type
cache,
and
so
then
the
two
caches
are
sometimes
out
of
sync,
because
you
get
the
dynamic
event
and
the
typed
client
cache
is
still
you
know.
It
hasn't
picked
up
that
update.
Yet
so
free
foot
guns
it's
fun.
So
if
we
could
help,
you
know
solve
some
of
those
problems
too.
That'd
be
neat.
H
J
I'll
do
a
call
for
interested
parties
and
see
if
we
can
find
the
people
I
know
of
who
are
exploring
some
of
these
things,
I'll
try
to
connect
them
and
we
can
maybe
see
if
there's
some
overlap.
Okay,
yeah
yeah,
please.
A
All
right,
I
think,
that's
it
for
today.
I
want
to
thank
everybody
for
the
discussion
and
the
respect,
and
I
hope
everybody
will
stay
safe.
We'll
see
you
probably
in
two
weeks,
we'll
upload
the
recording
later
today
and
we'll
put
it
in
the
agenda.
Thank
you.