►
From YouTube: Kubernetes KubeBuilder Meeting 20200618
Description
KubeBuilder Meeting for 2020/06/18. See https://sigs.k8s.io/kubebuilder for more details.
A
A
All
right
looks
like
we
have
a
few
things
on.
The
meeting
today
are
on
the
agenda
rather
so
the
first
thing
is
from
joel
joel.
B
A
C
Hi
everyone,
so
the
topic
I've
added
for
today
is
about
qbar
back
proxy,
so
my
team,
currently
we're
trying
to
set
up
metrics
we're
using
controller
runtime.
We
host
four
controllers
in
one
part.
At
the
moment,
we
in
openshift
have
a
requirement
that
the
metrics
should
be
authorized,
so
that
means
we've
got
to
put
currently
four
q
bar
back
proxies
into
our
pod,
which
then
means
we've
got
eight
containers
which
doesn't
look
great,
but
it's
not
necessarily
a
problem.
C
One
of
my
teams
suggested
that
what
if
we
just
try
to
do
the
off
n
or
c
checks
host
https
metrics
within
within
the
controllers
themselves,
so
that
then
led
us
to
look
at
well
controller
runtime
doesn't
support
this
at
the
moment.
Would
that
be
something
they're
interested
in?
I
spoke
with
frederick
branchick,
who
is
the
one
that
run
wrote
the
q
bar
by
proxy
and
he
was
suggesting
that
we
raise
a
pr
to
refactor
that
project
so
that
you
can
kind
of
use
it
as
a
library.
C
C
So
basically,
the
question
was:
how
do
people
feel
about
secure,
metrics
and
secure
web
hooks
as
well,
because
that's
something
that
I
think
we'd
like
as
well
long
term?
Is
that
something
controller
one
runtime
wants
support
in
general,
or
should
we
just
internet
on
our
own?
That
is
totally
fair.
A
I
think
we
mainly
just
kind
of
wanted
to
punch
on
that
in
the
past,
because
we
had
some
like
discussion
about
like
what
the
what
the
defaults
should
be
for
some
of
the
https
configuration,
and
we
were
just
kind
of
like
here's,
an
easy
way
to
to
do
this.
You
can
use
q
barback's
proxy.
It
will
set
things
up
for
you
and
do
the
authorization
and
then
we
don't
really
have
to
worry
about
it.
D
I
have
one
question
actually,
so
how
does
that
work
in
this
context
like
who
is
authorized
any
any
valid
user
in
the
cluster,
or
is
it
configurable
or
how
does
it
work
with
cube
right.
C
Proxy,
so
the
way,
as
I
understand
it,
someone
correct
me
if
I'm
wrong
is
that
what
q
bar
practicing
about
proxy
does
it
looks
for
an
authorization
header
which
should
contain
most
likely
a
service
account
token.
C
It
then
does
a
token
access
review,
which
it
sends
a
token
to
the
api
server
that
gives
it
back
like
the
user
in
groups
and
then
it
can
use
those
using
groups
to
check
the
are
back
within
again.
It
sends,
I
think,
subject
access
review
to
the
api
server,
and
that
will
say
yes
or
no.
This
user
has
permissions
to
access
whatever
you've
told
it
you're
protecting.
So
in
the
cubic
proxy
config,
you
say
right.
C
C
D
E
I
was
just
gonna
say:
I'd,
be
curious,
so,
like
cue
builder,
right
now,
scaffolds
the
support
for
cubback
proxy
manifests
and
the
pods
kind
of
we're
talking
about
I'd,
be
curious
to
to
maybe
see
like
a
prototype
where,
instead
of
scaffolding
like
new
pod
stuff,
we
instead
just
embed
it
in
the
operator
binary
and,
like
you
know,
I
think
what
we
might
want
to
say
is
like,
rather
than
having
hugo
or
scaffold
extra
patches
in
the
manager
pod,
it
wouldn't
have
to
do
that
and
instead
there'd
be
some
extra
options
that
you
could
enable
when
q
builder
scaffolds
like
the
main.go
file.
E
A
Running
so
is
the
is
the
motivating
change
here,
just
like
there's
lots
of
overhead
from
running
a
bunch
of
extra
containers
yeah.
That
was
basically
the
motivation.
I'm
not
entirely
convinced
by
this,
but
my
colleague
asked
me
to
bring
it
out.
Is
so
the
other
option?
Can
we
just
take
q
bar
back
proxy
and
make
it
so
that
it
can
serve
multiple
metric
sports?
A
A
D
A
I
mean
yeah,
we
could
we
could.
It
could
be
an
optional
thing
as
well.
I
mean
the
adding,
adding
extra
and
extra
port
support
to
the
binary
or
extra
ports
to
the
binary.
The
external
binary
is
is
more
in
line
with
what
we're
doing
right
now.
I
think
probably
either
would
be
acceptable
to
me.
E
Just
exposing
a
way
for
controller
runtime
users
to
use
an
http
middleware
when
they're
setting
up
like
the
metrics
listener,
so
that
they
can
then
like
if
they
want
and
q
barback
proxy,
has
a
library
that
exposes
the
middleware
like
you
can
import
that
separately
in
your
project
and
add
it
as
a
middleware
such
that
on
the
controller
runtime
side
like
it's
just
whatever
middleware,
you
want
to
inject.
A
Yeah
I
mean
that
could
work.
We've
talked
a
little
bit
about
inverting
that
and
making
it
really
easy
to
use
some
of
our
http
handlers
with
just
like
drop
them
into
kind
of
external,
serving
areas.
A
So
if
there
was
an
easy
way
in
q
bar
back
proxy
to
just
say
like
serve
all
these
paths
behind
the
r
back
proxy,
then
if
we
went
if
we
could
go
forward
with
the
change
to
make
it
easier
to
just
serve
all
of
our
http
handlers
on
a
external
listener,
external
being
external.
From
from
like
the
default
in
controller
runtime,.
C
Those
yeah,
I
could
see
those
working
quite
well,
and
that
no
means
we
don't
have
this
problem.
If
there's
extra
features
that
people
want
to
add
in
the
future,
like
just
doing
it
for
q
bar
back
proxy
now
solves
that
immediate
problem.
But
if
we
make
the
handlers
available
or
middlewares,
then
we
can
just
do
whatever
we
want.
As
a
consumer
controller
on.
A
A
All
right,
I
I
think
that
seems
reasonable.
Then
does
anybody
have
any
opposition
or
anything
alvaro?
How
does
that
sound
to
you.
A
All
right,
let's,
I
guess,
open
that
or
write
that
down
on
an
issue
somewhere
and
we
can
move
forward
with
that.
Then
thanks
very
much
all
right.
I
think
the
next
issue
or
the
next
item
on
the
agenda
is
from
events.
F
Yeah
this
this
should
be
pretty
quick,
like
I
just
put
a
pr
up
to
enable
the
milestone
plug-in.
You
know
repo.
The
only
thing
that
I've
noticed
is
that
sully
you're,
actually
not
in
the
maintainers
group,
so
might
need
to
add
yours
yourself
or
I
can
open
up
your
to
add
you.
F
Yeah
I
I
haven't
found
like
I
don't
know
if,
like
I
can,
set
two
groups,
because
this
is
like
a
tie
to
github.
I
don't
think
I
can,
because
this
is
a
map
for
the
milestone
plugin
but
yeah.
We
can
update
the
group
and
add
you
to
it.
A
A
G
Hi,
can
you
hear
me:
okay,
yep
cool
cool,
so
first,
let
me
introduce
myself
it's
my
first
time
here.
Oren
I
work
at
vmware
and
aside
from
vmware
stuff,
I
also
contribute
to
the
gatekeeper
project.
The
opa
gatekeeper
project,
use
control,
runtime
extensively,
pretty
familiar
with
with
the
code
internals
I've
adapted
it
to
to
different
use
cases.
G
Specifically.
Today,
I
wanted
to
discuss
an
issue
I
opened
a
few
weeks
ago
trying
to
find
a
a
way
to
upstream
work.
We
did
in
gatekeeper
to
support
what
I
it's
an
interesting
use
case
that
gatekeeper
has,
but
I'm
not
sure
it's
isolated,
just
a
gatekeeper
where
gatekeeper
manages
dynamically
registered
crds
and
has
the
need
to
be
able
to
set
up
conformers
and
controllers
that
listen
for
events
on
those
with
the
assumption
that
at
some
point
those
crds
get
deregistered
and
we
want
to
be
able
to
unwire.
G
All
of
that,
the
approach
we
took
in
gatekeeper
to
kind
of
work
around
some
of
the
the
the
design
decisions
and
control,
runtime
and
kleinko
was
to
allow
removing
an
existing
informer
from
the
controller
runtime
cache.
G
G
You
can't
remove
an
informer
once
it's
been
added
to
the
cache
there's
a
whole
mechanism
in
gatekeeper
called
this
watch
manager,
which
actually
coordinates
the
reference
counting
to
see
who's
interested
in
watching
any
particular
resource
kind,
and
it
makes
sure
that
you
know
that
that's
respected
before
removing
an
informer
from
the
cash
through
some
discussion
overall
had
some
some
good
feedback,
and
I
just
wanted
to
bring
it
up
to
the
group
that
I'm
amenable
to
other
ideas,
but
I
wanted
to
see
if
there's
a
path
forward,
since
I'm
aware
of
a
few
different
cases
where
people
are
trying
to
solve
similar
problems
and
I'd
love
it
if
controller
runtime
could
be
kind
of
part
of
that
solution,
instead
of
really
hacking
around
it.
G
D
Yeah,
I
guess
so
for
me,
the
biggest
open
question
is
why
the
de-registering
of
the
event
handlers
in
the
informers
is
not
possible
today,
because
it
might
be
that
it
just.
There
was
never
a
need
for
upstream
to
add
this,
or
it
might
also
be
that
there's
actually
a
problem
with
doing
this,
and
this
is
a
question
for
which
I
would
like
to
know
which
the
reason
is
because
if
we
support
the
registering
caches,
I
think
we
should
also
somehow
have
a
solution
for
avoiding
having
event
handlers
on
caches
that
don't
exist
anymore.
G
G
I
don't
know
what
the
reason
is
that
that
doesn't
exist
today
from
my
understanding
of
the
code
in
the
shared
nixon
former,
it's
just
a
matter
of
proper
synchronization,
and
that
should
be
something
possible.
So
I'm
not
sure
if
there
was
any
reasoning
behind
that.
G
I
will
say
that
just
removing
the
event
handler
is
not
necessarily
going
to
be
enough.
For
these
case
I
described
what
we
have
is
entire
crds.
Getting
de-registered
will
cause
the
informer
to
kind
of
go
into
this
exponential
back
off
of
failures,
doing
good,
establishing
list
watch
for
a
resource
that
no
longer
exists.
G
G
There's
back
off,
but
maybe
that's
less
than
ideal
to
have
that
kind
of
be
the
steady
state
of
your
of
your
system,
especially
if
you
have
a
lot
of
these
that
kind
of
accumulate
over
time.
So
for
us
we
have
to.
With
that
in
mind,
we
have
to
really
stop
the
informer,
and
one
of
the
things
that
we're
doing
is
we're
where
the
the
pr
allows
you
to
stop.
G
It
manages
different
stop
channels
for
for
each
individual
former
and
this
kind
of
tree
representation,
and
so
you
can
stop
the
whole
cache,
but
you
can
also
stop
an
individual
and
former
with
its
with
its
stock
channel
when
it's
removed.
So
I
I
you
know,
I
think
it's
interesting
to
see
inclinco
what
the
reasoning
there
is,
but
I
don't
think
it's
mutually
exclusive
to
maybe
what
we're
looking
at
here,
which
is
how
do
we?
How
do
we
shut
down
and
former
for
something?
That's
not
there
anymore
and
really
just
tear
it
out.
D
Yeah,
I
guess
well
what
I
meant
with
finding
it
out
was
mostly
creating
an
upstream
issue
and
ask
the
api
machinery
folks,
because
I
cannot
answer
this
question.
I
don't
know
if
anyone
else
in
this
call
can,
but
this
would
be
an
important
thing
to
know.
This
doesn't
mean
that
it
necessarily
has
to
be
added
in
upstream
before
we
do
it
in
controller
one
time,
but
just
knowing
would
be
a
good
thing.
D
A
Yeah
I
can,
I
can,
at
the
very
least,
tell
you
usually
upstream,
does
not
concern
itself
with
shutting
things
down.
The
model
upstream
is
usually
anything
added
will
will
run
for
all
eternity.
There's
usually
a
token
effort
made
to
allow
things
to
be
shut
down,
but
and
and
they're
usually
like
amenable
to
like.
A
If
you're
like,
hey,
there's
a
shutdown
method
missing
here,
but
the
underlying
thing
support
shutdown,
they're
usually
amenable
to
adding
it,
but
that's
not
usually
something
they
think
about.
With
with
the
caches.
A
I
will
also
say
that
I
know
of
several
other
people
with
this
problem,
too.
I've
seen
various
different
solutions,
things
like
running
a
manager
of
managers
so
that
you
have
end
different
caches
and
stuff
like
that
which
is
kind
of
a
little
bit
clunky.
F
Yeah
I
had
a
comment
like
last
week
that
having
read
the
whole
discussion
seems
like
is
a
lot
of
worry
that,
like
this,
could
break
users
or
like
introduce
like
a
new
behaviors
that
are
not
there
right
now
and
that's
totally
totally
fair
worry
and
I've
asked
like.
Maybe
we
can
actually
have
a
document
or
like
one
of
the
proposals
that
we
have,
which
are
very
simple
and
straightforward,
so
that
we
can
think
of
a
solution
and
understand
a
little
bit
more
about
the
use
cases
as
well.
A
Yeah,
I
agree,
I
think,
having
a
little
bit
a
little
write
up
or
something
would
also
be
very
useful
here.
Just
like
the
pr
itself
doesn't
look
super
complicated.
G
A
G
It's
it's
just
a
matter
of
finding
like
this.
You
know
again
like
a
safe
approach,
that
kind
of
fits
into
the
to
the
spirit
of
the
the
the
design.
So
I'm
happy
to
do
a
write-up
that
kind
of
gives
the
abstract
of
the
the
problem
space.
You
know
how
different
ways
of
the
different
workarounds
that
have
been
done
in
the
past,
how
we're
thinking
of
solving
it
so
reference
counting.
G
Is
it's
tricky
when
you
go
directly
to
the
cache
because
there's
like,
if
you
look
at
you
know,
get
informer
again,
former
for
kind
those
are
called.
G
You
know
you
never
give
it
back
right.
So
how
do
you?
How
do
you
decrement
the
reference
count
with
existing
code?
That's
using
those
interfaces,
and
so
in
the
case
of
gatekeeper,
we're
we're
just
using
this
watch
manager,
and
we
are
only
using
that
to
access
these
these
informers.
But
I
I
I
agree
with
that.
G
I
understand
and
and
see
the
hesitation,
I'm
just
I'd
love
to
have
a
you
know,
I'd
love
to
have
that
discussion,
maybe
in
the
context
of
that
document
about
other
apis
or
other
ways
of
approaching
this.
I
think
the
cache
of
caches
is
is
problematic
at
that
point.
The
cash
isn't
really
we'd
have
a
cat,
a
cash
of
cashes,
where
each
cash
would
be
a
single
informer
and
the
cash
isn't
giving
us
a
lot
like
at
that
point.
You
write
a
completely
custom
cash
and
it
would
be
about
equivalent.
G
So
I
can
get
that
document
written
up
with
the
abstract
and
link
it
to
the
issue,
and
maybe
that's
a
good
place
for
us
to
have
further
discussion.
I
don't
I
don't
know
that
we're.
You
know.
I
wasn't
looking
for
a
kind
of
a
conclusion
right
now.
We
just
wanted
to
get
it
on
people's
radar
and
maybe
look
for
the
right
avenue
for
continuing
the
discussion.
A
Sure
yeah
sounds
good.
Let's,
let's
discuss
on
on
a
design
dock
or
something.
E
E
So
real
quick,
I
just
put
a
question
in
the
chat.
I
don't
know
if
this
is
related
or
not,
but
there's
another
open
issue
about
using
filtered
list
watches
when
you're
setting
up
like
using
list
options
when
you're
setting
up
a
cache
and
there's
some
concern
also
around
there
about
possible
foot
guns.
E
A
I
don't,
I
don't
think
it's
related.
Someone
else
can
correct
me
if
they
see
a
design
that
matches
both,
but
I
I
don't
imagine
the
final
design
for
this
will
solve
filtered
list.
Watches.
E
I'm
not
suggesting
that
it
would
solve
it,
but
it
seems
like
we're
talking
about,
like
potentially
removing
informers
that
then
stop
cause
us
to
stop
being
able
to
have
new
events
for
certain
types
add
to
the
cash
which
seems
like
it's
kind
of
in
the
same
realm
as
only
caching
instances
of
objects
that
match
list
options.
So
I
just
wanted
to.
I
don't
think
it's
going
to
be.
One
solution
fits
both,
but
it
might
be
that
whatever
solution
we
come
up
with
for
one,
we
might
want
to
consider
the
other.
A
A
All
right,
I
think,
next
up,
we
have
two
more
from
vince.
F
Yeah,
so
adding
adding
an
event
recorded
to
controllers
to
track
errors
on
objects.
So
this
came
up
like
in
in
cluster
api,
like
I've.
Seen
a
lot
of
folks
like
like
pretty
much
doing
the
same
pattern
like
returning
an
error
logging
it,
which
then
it
gets
double
log
and
like
I
have
to
explain
that
all
the
time
and
then
presenting
an
event
as
well-
and
I
was
thinking
like
we
already
have
the
log.
It
doesn't
fully
give
enough
information
yet
because
it
doesn't
also
contain
the
group
version
kind.
F
I
believe,
but
it
would
be
great
to
also
like
add,
like
an
event
there,
so
that,
like
when
you
describe
the
object,
you
can
see
that,
like
the
reconciler,
only
that
object
actually
had
a
an
error.
Reconciling
it,
of
course,
like
the
events
like
are
like,
after
like
a
certain
window
like
they
will
be
lost,
but
at
least
would
be
useful
if
you're
debugging.
A
A
Unfortunately,
which
is
something
that
I
thought
it
would
be
nice
to
solve
over
the
years
by
you
know
maybe
having
stack
traces
and
errors,
which
I
think
we
had
a
prototype
for
that
once
or
something
like
that.
But
it
would
be
nice
to
maybe
figure
out
a
better
way
to
have
extra
context
in
the
error
that
we
return,
so
that,
like
the
automatic
login,
could
handle
that
nicely.
A
F
F
But
we
can
make
it
opt-in
so
like
if
you
don't
set
up
the
controller
with
an
event
recorder
like
it,
won't
do
anything
so
that
we
we
won't
cause
problems
like
for
folks
that
are
really
using
an
event
recorder.
For
example
yeah
I
can
open
an
issue
and
but
yeah
I
was
looking
to
work
on
it
at
some
point.
A
Okay,
yeah,
I
think
that's
as
long
as
as
long
as
we're
just
careful.
We
don't
end
up
in
a
situation
where
we
accidentally
spam.
The
api
server
I
mean
the
client
side
event
collapsing-
should
prevent
that
too.
So
it
it
should
be
fine
there.
A
A
A
H
F
Yeah
there
was
the
plan.
I
think
we
only
also
like
want
to
do
errors
for
now,
because
they're,
probably
the
most
important.
D
F
Yeah,
that's
that's
actually
a
good
point.
I
need
to
I'll
scan
like
the
reboot
to
see
what
we're
doing
today
and
see
yeah.
How
like
we're
approaching
this
on
the
login
side,
like
that,
like
what
you
mentioned
like
for
the
double
logging
like
actually
and
the
the
loss
of
context.
F
That's
why
I
added
like,
at
the
other
their
point
which
is
like,
should
I
reconciler
have
some
context
and
a
logger
associated
to
it,
which
we
can
probably
create
and
pre-populate
with
the
information
that
we
have
from
the
object,
like
name
namespace,
and
maybe
the
group
version
kind
of
wanted
to
that,
would
probably
give
like
a
lot
of
more
information
to
the
internal
locker
in
controlled
runtime,
but
also
like
a
give
it
like
already
populated
to
a
reconciler.
F
A
Yeah,
I
I
think
I
think,
there's
two
different
questions
there.
I
think
providing
a
context
would
be
useful,
potentially
a
logger,
although
I
think
usually
like
the
there
ends
up
being.
It
ends
up
being
more
useful
in
the
individual,
like
reconcile
method
to
set
up
the
logger
there,
just
because
that
has
more
information
about
exactly
what's
going
on,
and
so
you
can
give
better
label
names
and
stuff.
A
But
I
think
at
the
very
least,
the
context
could
be
useful.
I
think
for
what
I
was
saying
with
errors.
I
think
it's
usually
inverted
like
the
there
there's
context
from
the
call
like
the
person
returning
the
error
that
the
person
returning
the
error
has
that
gets
lost
when
you
return
the
error
so
stuff,
like
the
current
stack
as
well
as
sometimes
like,
sometimes
even
more
user-facing
information
about
what
the
error
was
or
like
log
tags,
so
to
speak,
that
have
been
attached
to
the
logger,
but
don't
get
propagated
with
the
error.
A
Really,
just
like,
I
think,
deficiencies
in
the
way
that
we're
we're
dealing
with
errors
or
goes
error
handling.
I
I
think
there
is
a
solution
there,
but
it's
maybe
a
different
story.
I
know
a
while
ago
I
I
kind
of
uploaded
a
prototype,
so
quite
a
while
ago,
now
of
of
like
errors
that
could
also
have
tagged
values
with
them,
like
structured,
structured
errors
or
something
we
may
at
some
point
want
to
revisit
that.
A
Just
so
we
if
we
want
to
to
solve
that
kind
of
double
logging
issue
and
could
potentially
use
that
framework
also
to
solve
stuff
like
we
want
to
have
a
user-facing
error
message
that
gets
automatically
exposed
somewhere
or
something
like
that.
But
I
think
that's
potentially
a
separate,
separate
issue.
F
Yeah
that
makes
sense
yeah
for
the
context
like
you
probably
need
a
new
minor
version,
but
because
it
is
a
breaking
change,
unless
I
don't
know
if
I
want
to
like,
have
like
reconcile
and
reconcile
with
context
just
just
for
the
sake
of
it,
but
I
actually
probably
don't
so
yeah.
We
can
wait
for
zero.
Seven
to
to
add
that
context.
At
least.
G
So
quick
question
on
the
context
is
the
main
motivation
to
have
to
be
able
to
respond
to
cancellation
of
the
whole
manager
or
the
controller
being
stopped,
or
is
it
to
just
have
a
context
to
pass
to
the
to
you
know
the
different
client
apis
or
is
it
or
is
it
to
try
to
enforce
timeouts
for
reconciliation,
which
is
something
that's
not
clear
to
me,
whether
that's
an
anti-pattern
or
not,.
A
A
So
if
we
wanted
to
introduce,
you
know
boilerplate
like
basic
tracing
support
for
from
like
open
telemetry
or
something
having
the
context
there
and
automatically
putting
in
some
basic
spans
or
something
would
allow
us
to
propagate
those
those
spans
down
through.
A
If
we
could
get
bet,
if
we
we
could
have
more,
you
know
like
more
intelligent,
like
automatic
log,
logger
creation,
or
something
like
that,
and,
of
course,
if
you
wanted
to
do
timeouts,
potentially
you
could.
But
I
think,
there's
like
a
number
of
reasons
for
wanting
to
have
the
context
in
there
like
that
and
so
just
having
it
having
it.
There
is
useful
for
playing
around
with
other
stuff.
B
All
right
does
that
mean,
I
guess
I'm
up
so
bringing
back
something
we
talked
about
at
cubecon,
which
is
the
deprecation
of
fake
client.
I
think
we've
been
just
talked
before
about
like
you
know,
we
want
to
re,
remove
that
deprecation
notice,
and
so
I
just
wanted
to
talk
about
kind
of
the
path
forward
there.
B
What
I've
heard
is
that
you
know
we
need
to
like
document
the
limitations
of
of
a
fake
client.
I'm
not
super
familiar
with
what
those
limitations
are,
so
I
kind
of
like
to
you
know,
have
some
process
to
collect
those.
I.
A
Guess
yeah,
I
think.
A
I
think
there
there
we
had
just
to
list
them
off
the
top
of
my
head
ones.
I
know
about
off
the
top
of
my
head.
We've
had
a
couple
questions
about
people
wanting
to
do
wanting
to
be
able
to
set
up
the
more
detailed
like
responses
from
the
fake
client,
which
there
is
some
support
via
reactors
in
base
client
go,
but
they're
really
clunky
to
use.
In
my
experience
from
writing
stuff
in
kubernetes,
there
are
a
couple
of
points
in
the
fake
client.
A
A
Those
two
that
I
was
thinking
of,
I
I
think
the
more
important
one,
the
more
complicated
one
to
fix
is
just
like
making
sure
we
have
a
sane
layout
for
doing
like
something
more
equivalent
to
reactors
but
more
structured.
A
If
we're
going
to
do
the
fake
client
or
having
at
least
a
path
forward
for
doing
that,
we
don't
necessarily
need
to
do
that
now,
but
okay
having
a
path
forward
for
that.
B
Try
to
like
I
don't
is-
is
documenting
that
those
kind
of
limitations
enough
to
remove
the
deputy
this,
because
the
thing
is
like
we've
had
at
least
one
team
that
has
looked
at
look
looked
at
the
fake
client
and
said:
oh,
it's
deprecated
we're
not
going
to
use
it,
and
I
I
just
I
just
feel
like
that's
kind
of
it's
kind
of
like
not
a
real
deprecation
in
a
way
like,
like
we've
said:
we've
wanted
to
unmark
it
as
deprecated
and
like
like
they
didn't
look
at
the
reasons
it
was
like
or
what
the
limitations
are.
B
So
I
just
want
to
like
kind
of
remove
that
speed
bump
that
into
to
using
it.
A
Yeah
I
I'd
like
to
so
I'd
like
to
see
at
least
a
couple
of
the
smaller
things
get
fixed
before
we
remove
the
deprecation
notice.
So,
like
fixing
the
thing
with
the
scheme,
at
the
very
least
just
like
the
the
very
remove
the
very
basic
foot
guns,
then
we
can
probably
remove
the
deprecation
limit.
A
A
So
if,
if
we
remove
the
deprecation
limit
and
then
immediately
just
change
it
that
seems
kind
of
silly
or
if,
like
I,
I
think
it,
it
seems
more
reasonable
to
have
a
plan
for
how
we're
going
to
change
it
when
we
put
the
deprecation
limit
or
when
we
remove
the
deprecation
limit,
so
that
we
can
at
the
very
least
say
this
is
probably
going
to
change
like
this
in
the
future.
So
just
be
aware
that
what's
what's
gonna
happen,
does
that
make
sense.
B
Yeah
yeah,
okay,
so
I
kind
of
just
want
to
like
help
that
along
as
much
as
I
can
so
I
guess
we
can
work
on
that
scheme
thing.
That
seems
understandable.
Do
we
I
still
want
to
like.
I
feel
like
there
is
some
knowledge
out
there
of
maybe
some
other
things
that
we
have.
Can
we
just
how?
How
can
we
collect
all
those
issues?
I
think
we
should
start
a
google
doc
or
something.
A
Well,
I
think
we
should
start
linking
them
in
the
in
the
tracking
issue.
Actually,
I
think
we,
if
we
don't,
I
think
we
have
a
tracking
issue
somewhere.
If
we
don't
already,
we
should
create
one
and
just
start
linking
them
all
there.
Okay,
and
we
can
like,
we
can
add
a
thumb
into
into
the
like
first
issue
comment
or
the
first
issue
description
as
like
a
checkbox
list
of
like
these
are
the
issues
we
found.
B
D
Okay,
I
think,
apart
from
that,
we
should
probably
just
add
a
gold
or
comment
saying.
Yes,
this
is
trying
to
emulate
the
api
server
to
the
best
of
our
knowledge
and
capacity,
but
it
will
never
be
completely
accurate
because
we
I'm
pretty
sure
there
are
more
things.
People
are
just
not
aware
of
or
we'll
just
recover
later
on,
and
we
won't
be
able
to
make
a
complete
exhaustive
list.
B
So
my
perspective
on
that
is
actually
kind
of
the
opposite
is
that
we
shouldn't
necessarily
be
trying
to
emulate
the
api
server
and
instead
we
should.
You
know
it's
called
a
fake
client,
so
we
should
be
emulating
a
client.
So
you
know
mocking
the
responses
to
that,
and
you
know
the
the
object.
Tracker
storage
backend
is
kind
of
a
way
to
do
that,
that
that
makes
it
very
easy
to
use
as
a
test
writer,
but
maybe
you
know,
emulating
all
the
implementing
all
the
little
details
of
api
server.
B
That's
probably
better
left
for
an
integration
test
or
test
end.
A
Yeah,
I
think
so
I
think
largely
this
comes
down
to
largely
like
the
overall
problem
that
I've
seen
with
the
fake
client
in
the
past
is
that
people
start
using
it
and
they
start
realizing
that
their
controller
is
relying
on
some
point
of
the
api
server
that
is
not
implemented
by
the
fake
client,
and
you
end
up,
like
you
know,
just
implementing
more
and
more
of
of
things
that
are
part
of
the
api
server
in
the
fake
client
and
and
then
you
end
up
with
something
really
complicated
right,
which
is
why
we've
kind
of
been
hesitant
to
recommend
it
in
the
past,
and
this
is
actually
why
it
was
originally
deprecated.
A
Just
because
it's
it's
hard
to
use.
I
think
it's
hard
to
use
right
without
giving
yourself
issues
in
the
past,
but
so.
B
B
I
know
you're,
not
a
big
fan
of
reactors,
but
I
I
kind
of
feel,
like
that's
part
of
the
answer
here,
which
is
to
allow
test
writers
to
fake
those
specific
behaviors
of
the
api
client
of
the
api
server
that
are
important
to
that
test,
and-
and
you
know
it
also
helps
make
that
test-
really
clear
that
you
know
this
behavior
is
important
to
to
the
functionality
of
this
test.
A
A
You
end
up
with
a
lot
of
really
complicated
test
logic
or
setup
logic,
that's
very
very
brittle
often
times
or
at
least
that's
that's
my
experience
and
how
I've
seen
it
being
used
and
so
part
of
the
hesitance
was
like
when
you're
encountering
those
situations.
I'd
rather
steer
people
towards
send
tests.
F
I
agree
with
that
sentiment
in
general,
like
I
I've
mentioned
in
chat
like
that
we've,
we
found
some
issues
with
generation
and
resource
version,
for
example
they're,
like
they
don't
behave
properly
so
patch
and
update,
don't
don't
work
properly
in
that
case,
even
if
you
mix
and
match
right
like
if
that's
something
that
like
a
reconciliat
might
do
and
we
found
issues
so
my
baseline
is
like
we
found
tests
that
we're
actually
not
testing
anything
at
that
point,
and
that's
a
big
worry
for
me.
F
That's,
like
you
want
to
use
the
fake
client,
that's
fine.
We
can
remove
that
deprecation,
but
it
should
be
also
a
big
warning
that
light
says
this
is
not
enough
to
make
sure
that
you
reconcile
it.
That's
what
you
expect
it
does
right,
yeah
so
like
it,
it
can
test
like
I
mean
we're,
probably
using
only
for
unit
tests
and
I'm
trying
to
move
away
from
it,
because
it's
just
like
not
enough
it
like
a
90
of
the
times
that
we
issue
a
patch
or
where
we
shouldn't
pattern,
an
update.
F
A
Yeah,
so
out
of
out
of
curiosity
david,
can
you?
How
are?
How
are
you
using
the
fake
client
because
the
other,
the
other
thing
we
could
do?
I
know
other
people
have
like
floated
the
idea.
I
let
me
sorry,
let
me
back
up
my
I'm
a
little
scattered
today.
I've
seen
a
lot
of
the
use
cases.
I've
seen
have
been
injecting
extraordinary
conditions.
A
I've
kind
of
actually
seen
two
categories
of
like
why
we're
using
the
fake
client,
one
of
them
is
injecting
extraordinary
conditions
that
are
hard
to
simulate
with
a
real
api
server
right
and
the
other
one
is
performance
reasons
for
whatever
reason,
spinning
up
even
just
spinning
up
the
api
server
doesn't
work
or
is
insufficient
or
is
too
slow
or
whatever
both.
B
Of
those
things
yeah,
it
takes
five
seconds
to
start
a
test.
Amp,
that's
not
that's!
It's
not
a
unit
test
at
that
point
and
yeah
most
anytime,
we're
adding
reactors
that
it
is.
A
So
I
think
maybe
we
could
capture
that
use
case
better
and
just
like
have
have
start
with
an
easy
way
to
be
like.
I
want
to
inject
an
error
into
the
flow.
A
B
A
B
I
kind
of
I
see
the
logic
there.
That
makes
sense.
I
guess
the
other
case,
I'm
thinking
of
that
we've
used
reactors
is
four,
is
like
just
kind
of
using
it
as
as
a
spy.
B
So
so
you
know
just
recording
that.
Yes,
a
a.
B
I
did
update,
I
didn't,
I
got
an
update
and
this
was
contents
of
the
update
like.
If
you
know
the
reconcile
is
doing
multiple
updates
to
the
same
resource
or
something
like
that
or
a
patch
or
absorbing
the
patch
or
whatever.
A
B
G
G
On
that
is
the
is
the
wrapped
reconciler
that
intercepts
the
the
reconcile
requests
that
coup
builder
at
least
used
to
output,
because
I
still
recommend
it
because
I've
seen
people
kind
of
rely
on
that
and
expand
those
tests,
and
then
that
channel
doesn't
get
drained
and
it's
hard
to
predict
exactly
how
many
reconcile
requests
are
going
to
happen.
A
Okay,
that's
why
we
don't
scaffold
the
stuff
like
that
anymore.
A
The
current
I
think,
there's
a
pr
open
for
some
of
like
the
current
way
that
the
current
largely
the
current
thinking
of
what
at
least
what
I've
been
recommending,
and
I
think
what
we've
been
linking
to
from
the
documentation
which
is
kind
of
testing
that
the
eventual
state
ends
up
the
way
you
want
it
to
be
so
saying
like
here,
here's
my
inputs,
the
reconciler
is
running:
make
sure
that,
like
you,
eventually
reach
the
desired
outputs
right.
G
A
B
Right
exactly
it
doesn't
in
our
experience
that
has
not
been
trivial
to
to
like,
let
it
even
like
with
your
using
test
time.
You
have
to
like
wait
for
it,
wait
for
the
api
server
to
become
quiescent
and,
like
all
the
updates
have
happened,
and
then
you
need
to
check
it
and
figuring
out
when
to
do
that
is
is
hard
and
makes
for
flaky
tests.
D
Okay,
so
I
very
much
agree
on
this
sentiment
because,
especially
if
you
run
these
tests
locally,
they
tend
to
work
and
if
you
run
them
in
ci,
they
tend
to
flake,
because
in
ci
in
most
cases
you
have
a
lot
less
cpu
memory
and
everything
than
you
have
locally.
D
G
Yeah
we,
what
we
do
is
we
pull
we.
We
have
like
this
eventually
block
which
is
polling
for
the
the
undesired
state
so
again
he's
pulling
the
it's
tuning
the
pole
period,
but
also
tuning
the
overall
timeout
and
like
alvaro,
said
right
now,
if
you
set
the
timeout
too
low
and
it
works
on
an
unloaded
system.
That's
you
know,
that's
great,
you
put,
another
environment
starts,
failing
you
put
it
too
high
and
it
takes
forever
to
find
out
that
hey,
it's
actually
a
logic
error
and
it's
never
going
to
reconcile.
G
So
that's
the
tension
there,
but
trying
to
count
reconcile
requests,
doesn't
really
work
out
either
so
I've.
You
know.
I've
experienced
this
first
first
hand.
A
Yeah,
so
I
think
I
think
yeah
I
think
that's
a
fair
point
like.
F
For
what
it's
worth,
I
don't
wear
a
time
before
it's
worth
like
we
had
these
problems
in
culture,
api,
a
lot.
I've
done
some
digging
and
like,
for
example,
one
thing
is
that,
like
the
test,
suite
doesn't
use
a
dedicating
client
which
doesn't
use
a
cache
by
default
and
we'll
fix
that,
and
that's
all
like
kind
of
like
hammering
the
local
api
server.
For
example.
F
Then
there
is
the
reusability
of
test
end,
which
we
also
have
worked
on.
So
there
is
like
ways
to
improve
that.
I
can
probably
make
a
list
of
the
things
the
changes
that
we've
made
but
yeah
we
reduced
the
running
time
and
cost
api
from
10
minutes
to
two
minutes
like
just
a
few
weeks
ago,
and
it
was
actually
pretty
good
to
see,
and
this
is
improv
which
doesn't
have
many
resources,
which
is
pretty
constrained
so
yeah.
F
I
can
definitely
contribute
these
back
and
to
see
if,
like
we
want
to
make
these
defaults
but
they're.
Definitely
nice
improvements.
A
Yeah
I-
and
I
I
guess
I
am
a
bit
I
am
sympathetic
to
like
the
also
people-
have
their
own
way
of
doing
tests
that
works
well,
and
so
I
think,
yeah
I
think,
if
we
can
make,
I
think
we
we
probably
can
make
some
of
the
you
know
using
it
as
a
like
a
spy,
so
to
speak
a
little
bit
easier
and
then,
like
you
know
we
can.
We
can
recommend
certain
things
in
q
builder
and
we
can
leave.
We
can.
A
A
So
I
think
I
think
to
summarize
all
of
that
I
think
maybe
what
I
would
like
to
see
in
the
fake
client
is,
like
you
said,
collect
all
the
lists
of
of
bugs
and
then
collect
like
the
major
things
that
you're
trying
to
do
with
the
react
reactor
and
see
if
we
can
start
by
making
those
specific
targeted
things
a
little
bit
less
clunky,
because
they're,
like
the
reactors
themselves,
are
a
very
general
purpose
tool
that
gets
really
unwieldy
even
for
simple
things.
A
So
if
we
can
make
the
simple
things
easier
and
then
we
can
make
the
more
complex
things
maybe
possible,
with
just
a
better
structured
reactor,
because
there
there's,
like
a
lot
of
weird
quirks
to
the
reactor
like
the
client
go
reactors,
have
no
like
type
safety
around
the
like
around
the
resources
you
specify.
So
it's
really
easy
to
specify
just
like
a
resource
that
doesn't
exist
and
then
your
reactor
doesn't
fire
and
it
takes
a
while
to
figure
out
that
you've
like
missed
an
s
or
something
like
there's,
there's
a
lot
of
weird
quirks.
B
B
Okay,
yeah,
that
makes
sense,
and
maybe
we
can
so
we
we-
I
came
here
thinking
like
maybe
we
could
contribute
reactive
climb,
but
maybe
we
can
contribute
that
something
else
that
you
know
takes
care
of
the
major
use
cases.
That's
you
know
otherwise,
similar.
A
D
I
Yeah,
I
I
would
just
real
quick.
It
really
is
30
seconds
the
we've
seen
common
issues
with
defaults
around
core
types
in
the
q
builder
as
well
as
operator
sdk,
and
I've
raised
that
concern,
and
it's
going
to
be
a
I
guess,
introduced
or
addressed
in
the
meeting
next
week
with
the
work
group
around
expression.
So
if
you're
interested
in
that
space
come
join.