►
From YouTube: Kubernetes SIG API Machinery 20221116 Meeting
Description
[lavalamp] Announcement: our teams are extremely out of date. Please consider proposing yourself as a member to one or more: https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-api-machinery/teams.yaml
Han started a PR: https://github.com/kubernetes/org/pull/3838/files
[liggitt] gogo/protobuf
now officially deprecated
https://github.com/kubernetes/kubernetes/issues/96564
Requirements/Desirements/Ideas for replacing gogo/protobuf
[stevekuznetsov] update on RV parsing search (xref)
[Daniel] Clayton expects a KEP before we do any changes to this, to keep this in mind.
[howardjohn] Exposing informer synced state
Interested in discussing possible options moving forward
[Daniel] will take a look at the issue and suggest offline.
[howardjohn] Generics in client-go
Interested in getting high level direction on what a path forward would look like for this: client-go/v2, generic wrappers around existing code, generic and legacy code side-by-side, third-party/sig implementation, etc? Do Nothing is also an option.
[tallclair] Contextual logging in the apiserver (KEP)
[fedebongio] Kubecon NA 2022 API Machinery Deep Dive Talk jfyi
A
B
If
han
han
has
started
a
PR
to
add
a
just,
a
Sig
API
Machinery
members
team.
If
you
feel
like
a
member
of
the
Sig,
please
suggest
yourself
as
an
addition
to
that
PR
and
we'll
do
this
as
a
big
group
merge
instead
of
a
thousand
little
PR's,
and
we
need
to
maintain
the
other
teams,
also
at
some
point
yeah
so,
but
probably
we'll
do
those
more
one-off
and
not
in
a
giant
PR.
B
A
C
B
B
A
E
E
The
short
version
is
kubernetes.
Api
types
can
serialize
themselves
to
and
from
protobuf
wire
format,
but
they
do
this
in
weird
non-standard
ways
that
we
started
for
a
variety
of
reasons
which
I
tried
to
capture
in
this
dock
and
they
rely
on
a
protobuf
generator,
which
is
now
deprecated
and
unmaintained,
which
itself
calls
into
standard
protobuf
libraries
in
non-standard,
unsupported
ways.
E
So
it's
a
layer
cake,
three
layers,
deep,
where
the
top
layer
is
us
with
our
non-standard
go
types
which
can
do
Proto,
serialization
deserialization,
depending
on
an
unmaintained
deprecated
middle
layer,
which
is
calling
into
a
supported
bottom
layer,
but
in
unsupported
ways.
So
this
is
this
is
a
sad
layer
cake,
and
so
the
question
is
like:
what
should
we?
What
should
we
do
here?
E
This
isn't
an
emergency
like
nothing
is
on
fire
today,
nothing's
going
to
block
126
release,
nothing
is
panicking,
but
this
is
sort
of
a
disaster
waiting
to
happen
like
as
soon
as
there's
a
security
issue
or
a
really
bad
bug.
That,
like
requires
changes
in
the
middle
layer,
those
those
aren't
going
to
get
fixed
or
as
soon
as
the
bottom
layer
makes
changes
to
the
runtime
behavior
that
are
in
spec
for
the
compatibility
guarantees
they
provide
but
break
the
unsupported
use
of
the
middle
layer.
E
That
will
be
a
big
problem,
so
there's
two
sort
of
or
three
sections
to
this
doc.
One
is
like
history
like
spelunking
like
why?
Why?
How
do
we
end
up
here?
What
were
the
reasons
which
still
apply,
which
maybe
don't
apply
anymore?
If
I
missed
things
that
you
know
about?
Please
leave
comments
or
make
suggestions,
so
we
can
like
get
a
full
picture
of
you
know.
What's
the
saying,
like
never
tear
down
a
fence
until
you
know
why
the
fence
was
put
up
in
the
first
place.
E
So
if
you
have
things
you
know,
I'm
missing,
please
add
them
here.
The
second
I'm
I
started
trying
to
think
about,
like
whatever
we
replace
this
current
mess
with
what
what
do
we
require
from
the
solution
and
so
I
sketched
some
things
out
there.
But
if
you
disagree
with
those,
please
leave
comments
that
you
disagree
and
why
or
if
there
are
things
that
you
think
are
additional
requirements
that
I'm
missing.
Please
leave
comments
and
then
the
last
section
is
just
sort
of
possible
directions.
That
I
was
thinking.
E
C
Yeah
I
had
a
question
about
one
of
the
requirements:
yeah.
Why
must
it
work
with
the
existing
go
types
if
we
were
to
be
able
to
generate
a
shim
type
used
for
serialization
and
deserialization,
or
if
we
had
to
change
our
type
so
that
it
was
compatible
with
this
new
serialization
or
deserialization
and
have
a
shim
type
in
the
other
direction?
E
E
Deal
with
dramatically
different
go
types
for
the
existing
goat
types
so
like.
If,
if
you
let
proto-generation
like
standard
photo
generation
have
its
way,
every
struct
field
is
a
pointer
and
like
it
just
it
really
dramatically
changes.
It
also
would
screw
up
the
Json
serialization
of
our
types,
so
I'm
saying
I,
don't
think
we
can
switch
our
current
go
types
to
be
standard,
proto-generated
types,
I
think
that
would
break
everything
built
on
top
of
existing
API
types,
generating
prototypes
separately
like
and
figuring
out
some
way
to
get
to
and
from
them.
C
E
D
C
E
C
E
Oh
I
need
to
think
about
that.
I
will
try
to
add
comments
here
to
clarify
I'll,
try
to
reword
this
to
clarify
that
point
or
you
can
take
a
stab
at
it.
I
didn't
really
expect
to
have
a
long
discussion
about
this
topic
in
this
meeting.
I
mostly
wanted
to
surface
this
explain
why
I
was
bringing
this
irritating
issue
up
again
and
and
ask
for
input
on
these
three
sections.
E
E
Maybe
we
can
Circle
back
and
if
there
are
any
like
open
questions
that
would
benefit
from
a
higher
bandwidth
discussion.
We
can
talk
about
it
in
the
in
the
December
meeting,
I'd
like
to
at
least
have
maybe
some
Avenues
to
explore,
or
some
questions
that
people
can
go
off
and
sort
of
do
spikes
on
or
experiments
without
their
benchmarks
or
something
to
try
to
prove
out
or
disprove
some
of
the
possibilities.
G
I
just
have
a
quick
update
on
the
conversation
we
had
last
time,
so
I
was
doing
a
survey
of
places
where
we
actually
find
resource
version
being
parsed
I
did
a
pass
through
all
the
official
client
libraries
and
then
all
of
the
controller
Frameworks
that
folks
have
written
in
different
languages.
I
found
nothing
using
the
code.
Search
from
GitHub
I
was
able
to
find
a
couple
parsing
bits
of
code
here
and
there
most
of
it
I
mean
I,
found
eight
unique
places.
G
Some
of
them
are
super
trivial,
where,
like
I,
think
one
of
them
is
using
it
as
a
modification
timestamp,
there's
one
that
is
like
just
doing
it
in
test
code
there's,
maybe
a
couple
of
these
that
are
actually
using
it
as
like
a
mutation
cache
as
we
expected
so
I
guess,
I'm.
Looking
for
feedback
as
to
what
the
next
step
is
here,
I'd
love
to
go
ahead
and
submit
PRS
to
all
these
I
think,
except
for
the
two
they're
actually
using
it
for
a
mutation
cache.
B
If
I
can
just
say,
one
thing,
Clayton
expects
a
cap
before
we
change
anything
like
this.
He
was
extremely
against
my
change,
which
I
still
believe
was
just
documenting
the
current
state
and
once
it
kept
and
your
changes
are
your
proposed
changes
even
larger,
so
I
imagine
he
will
want
to
kept
for
that.
Also,
that's
all
I
had
to
say
I
understood.
C
C
G
G
C
C
G
A
Okay,
very
good.
Thank
you.
Steve
I,
don't
see
Jehovah
on
the
call,
I
ping
him
so
I
I!
Guess
we
move
forward.
We
skip
the
presentation
and
let's
Joel
or
CeCe
things
differently.
Yeah
I
wasn't
prepared.
So
okay!
So
let's
go.
Do
we
have
four
Indigo
yeah
I'm
here?
Okay,
so
why
don't
we
go
with
the
first
of
your
two
topics?.
H
So
the
general
issue
is
that
today,
on
Informer,
there's
that
whole
ad
synced
function.
What
that
means
is
that
the
underlying
store
has
all
the
items
populated,
but
it
doesn't
mean
anything
about
the
event
handlers
being
called,
and
so
a
lot
of
usages
of
informers
are,
you
know,
building
their
own
State
on
top
of
event
handlers,
and
so
they
have
to
jump
through
all
sorts
of
Hoops
in
order
to
understand
when
that
is
synced.
H
So
there's
plenty
of
examples
of
this.
In
you
know,
the
first
party
kubernetes
tons
of
examples
of
external
controllers
as
well
I,
was
going
through
some
and
I
even
found
that
some
of
the
kubernetes
built-in
in
informers
like
this
mutating
web
hook,
one
was
actually
handling
this
wrong
because
it's
it's
quite
complicated
to
actually
correctly
get
the
semantics
that
I
want
to
know
when
all
of
the
initial
state
has
gone
through
the
event
handler,
which
seems
to
be
quite
common.
C
H
C
One
given
that
event,
handlers
are
usually
done
by
simply
cueing
something
into
a
work
queue
and
then
the
actual
processing
happens
by
asynchronously
dequeuing
from
a
work.
Queue
is
the
thing
we
need
to
know
whether
the
event
handler
has
been
successfully
called
and
we've
queued
to
a
work
queue
or
is
the
thing
we
need
to
know
that
the
controller
has
actually
handled
every
item
that
was
queued
to
the
work
queue
before
the
initial
list
or
when
the
initial
list
was
complete.
H
Yeah,
so
in
our
case,
what
we
have
done
is
that
in
the
queue
we
enqueue
an
item
once
we've
synced,
while
we
once
we
think
we've
synced,
it's
actually
not
exactly
right,
because
this
issue
being
q
and
item
on
the
Queue
that
says
like
this
is
the
sync
marker.
Once
you've
processed
that
item,
you
know
you're
synced,
I'm
sure,
there's
other
ways
to
do
it
as
well.
C
I
will
let
you
continue
so
that
I
can
see
that
as
well.
That's
not
that's
not
obvious,
because
even
what
you
just
described
when
you
get
to
the
marker,
that's
not
correct
right.
If
you
have
five
consumers
reading
from
a
work
queue
and
you
get
to
the
marker
and
the
other,
four
consumers
are
still
processing
you.
You
have
not
actually
processed
every
item
in
the
list.
H
D
B
The
easy
thing
to
do
in
tree
is
to
track
like
if
we
get
an
item
off
the
queue
that
is
prior
to
the
sync
item,
then
we
need
to
note
that
it's
processing
and
not
Marcus,
is
done
until
all
such
items
are
processing,
but
if
your
processing
is
to
asynchronously
trigger
something
else
somewhere
else,
we
wouldn't
know
when
that
other
thing
somewhere
else
is
done,
so
we
either
need
to
give
people
a
way
of,
or
we
could
tell
people
just
you
have
to.
You
have
to
not
call
done
until
you're
actually
done.
H
B
H
G
H
B
C
C
B
C
E
Cases
and,
like
you
know,
but
I,
think
the
case
that
we
run
into
this.
A
lot
is
like
there's
no
error
in
the
sink.
It's
just
like
I
just
need
to
observe
stuff,
so
I
can
like
enforce
policy
like
a
controller.
That's
going
to
be
continuously
reconciling
and
it's
like.
If
it
fails,
it
throws
it
back
in
the
queue
like.
Maybe
it
doesn't
care
about
as
much
about
like
needing
to
know
when
it's
done
but
like
I
have
observed
initial
State,
the
the.
F
B
E
D
B
A
logical
way
to
do
that
might
be
to
take
that
sync
item
that
we
were
talking
about
and
just
add
to
all
the
handlers,
add
an
optional
item
that
is
just
like
on
on
barrier
or
something
like
that,
and
when
we
see
that
synchron
sync
item,
we
just
call
the
on
barrier
and
when
you're
a
when
you're
implementing
this.
These
sets
of
handlers
when
you,
when
that
function
is
called
for
the
first
time.
C
E
C
H
One
is
that
you're,
potentially
processing
items
multiple
times
which
may
be
expensive,
depending
on
what
you're
doing,
but,
if
you're
not
using
a
queue
where
you're,
just
like
enqueuing,
the
name
and
you're,
actually
doing
specific
things
on
updates,
deletes
or
ads
or
whatnot
and
you're
doing
these
list.
Events
now
you're
getting
events
out
of
order
and
it's
kind
of
totally
broken.
So
it
works
decently
if
you're
using
the
kind
of
queuing
the
name
approach,
although
it
is
potentially
wasteful
if
you're
processing
multiple
items,
but
it's
not
really
Universal.
C
B
E
B
H
C
C
I
think
that
knowing
what's
up
right
here,
then
no
I'm
sorry
best
satisfied
right
here.
Rather
than
trying
to
go
back
to
the
channel.
Oh
okay,
I
was
expecting
the
layer
that
would
indicate
whether
a
controller
has
completed
its
initial
work
to
be
separate,
a
layer
on
top
not
contained
inside
the
inform.
H
E
Is
that
is,
does
that
mean
that
the
Informer
is
not
giving
event
handlers
I
mean
it
clearly
isn't
giving
event
handlers
enough
information
to
know
when
they've
been
called
for
all
the
initial
stuff
like?
Is
that
what
you're
saying
David
like
something
that
would
Plumb
that
information,
so
that
a
Handler
like
an
initial
sync
handling
Handler
could
pay
attention
to
that
and
then
know
once
it
had
the
initial
set
yeah.
C
If
we're
trying
to
avoid
a
separate
list
like
we're
a
list
where
you
go
through
it
in
the
singer,
so
make
sure
you
hit
everything,
then
yes,
I
think
if
it
needs
to
be
some
sort
of
a
marker
that
could
be
appropriate
but
I
think
understanding
whether
I
have
inspected
every
item
so
far
and
I
have
satisfactorily
dispositioned.
That
is
something
that's
known
only
to
the
controller,
because
in
some
cases
it's
okay
to
fail,
and
you
just
need
to
know
that
your
list
is
Right
In.
C
B
B
That's
something
we
can
do
I,
don't
see
an
easy
way
for
us
to
track
whether
that
Handler
has
done
something
useful
with
all
of
those
notifications
or
not
I.
Think
if
you
need
some
stronger
guarantee
that
you
than
just
that,
we've
called
your
Handler
with
each
of
these
items
at
least
once
like.
If
you
need
a
stronger
guarantee
than
that,
you
can
keep
track
of
of
it
yourself.
B
G
No
worries,
I,
guess
I'm,
just
also
thinking
like
the
comment
on
so
David's
approach
of
wait
for
housing.
Do
a
list
manually
synchronously,
do
all
the
initial
stuff
and
then
start
the
asynchronous
processing.
So
the
downsides
that
were
mentioned,
were
you
know,
processing
more
than
once
or
out
of
order.
I
feel
like
if
you're,
like,
there's
pattern
established
patterns
to
mitigate
both
of
those
things
right,
whether
that's
observed
generation
or
just
generally
being
level
driven
and
you're
going
to
want
to.
E
I
I
know,
at
least
in
the
cases
that
I
know
about
entry
like
what
you're
talking
about
for
controllers,
where,
like
I,
observe
a
thing
and
then
I
take
some
action.
I
observe
a
thing
and
take
some
action
like
yes,
level,
driven
and
like
looking
a
generation
like
that
makes
sense
for
like
we're,
gonna
serve
endpoints
and
we
need
to
know
when
we've
seen
all
the
things
we're
supposed
to
be
serving.
So
we
can
decide
whether
to
return
like
a
404
or
a
not
ready.
E
G
E
Yeah,
like
you,
can
be
like
how
you're
building
the
stuff
you're
observing
like
I
mean
the
admission
plug-in
stuff
is
actually
very,
very
simple
like
anytime.
It
gets
an
event
for
anything.
It
just
lists
everything
and
rebuilds
everything
which
you
know
most
clusters
have
small
numbers
of
web
Hooks
and
they're
slow
moving.
So
it's
generally
fine
like
how
what
your
sync
actually
does
to
take
updates
and
additions
and
like
make
that
part
of
its
active
state
is
like
it
can
vary
a
lot.
The
question
is
like:
is
it
when
it's
starting
up?
Is
it
ready?
B
H
A
H
I've
explored
a
bit
with
generics
and
client
go
there's
kind
of
quite
a
few
benefits,
I
see
potentially
higher
performance,
adding
things
like
abstractions
over
and
former,
so
that
we
can
do
thinking
logic
generically
right
instead
of
a
lot
of
generated
code.
That
type
of
thing
so
I
was
just
kind
of
wondering
like
if
there
was
any
feedback
on
like
what
this
would
even
look
like,
like,
obviously
we're
not
a
clean
slate
so
like
would
this
be
client
go
V2?
H
B
I'm
hoping
it
wouldn't
be
so
bad,
we
we've
already
done
some
work
on
the
on
the
set
types.
Also,
there's
I'm
pretty
sure
that
merged
there's
there's
now
generics
set
objects.
Those
unfortunately,
do
require
a
bit
of
a
code
change
to
use
it,
but
it's
kind
of
very
minor
and
we
left
stub
objects,
so
you're,
really
using
the
generic
one,
even
if
you're
calling
the
old
functions
still
so
I
think
we
can
probably
do
that
for
at
least
some
of
the
client
code.
B
C
C
I
honestly,
don't
feel
that
sorry
for
someone
who
has
to
say
I
need
a
pod
client
and
not
a
config
map
plan
I,
don't
feel
sorry
for
them,
but
I
really
do
feel
sorry
for
them
that
they
want
to
use
a
client
from
you
know,
125,
with
a
type
from
126.
I
feel
for
that
a
lot,
and
so
that
I
think
is
where,
where
my
deepest
interest
lies,
I
would
want
to
be
able
to
have
a
client
that
I
could
use
with
heavily
skewed
object,
types
that
are
not
compiled
in.
B
B
B
B
B
A
A
C
B
F
Good
team,
your
own
yeah,
thanks
so
to
before
I
jump
into
the
specific
proposal
here.
Just
a
little
bit
of
background
of
how
I
came
to
this,
so
I
was
debugging.
Some
specific
requests,
issues
that
we
were
seeing
on
gke
and
I
noticed
a
bunch
of
logs
in
the
API
server
logs
that
you
know
was
some
error
occurred
or
you
know
some
bad
State
happened
as
a
warning
and
there
was
no
context
as
to
which
request
was
actually
triggering
that
error,
and
so
it
wasn't,
it
wasn't
really
useful.
F
It
didn't
have
enough
context
to
say,
like
you
know
what
request
I
can't
remember
what
the
specific
error
was,
it
might
have
been
a
timeout
or
something,
and
so
I
was
thinking
that
if
we
had
audit
IDs
attached
to
more
of
those
log
lines
since
we
already
logged
the
audit
ID
as
part
of
the
HTTP
log
line,
and
then
you
can
also
get
more
context
from
the
audit
logs
as
well.
That
would
be
a
pretty
good,
simple
way
of
tying
all
of
the
request
logs
to
a
specific
request.
F
So
that's
the
that's
kind
of
the
background
and
the
motivation
for
my
interest
here
and
as
I
when
I
looked
into
what
it
would
take
to
add
audit
ID
to
all
these
requests.
You
know
a
shared
logger
instance
that
had
the
audit
ID
set
on
that
would
make
that
a
lot
simpler.
So
we
don't
have
to
manually,
add
the
audit
ID
to
every
log
line
and
it
turns
out
there's
already
an
effort
to
move
kubernetes
to
contextual
logging,
which
means
you
have
a
logger
instance.
That's
attached
to
the
context.
F
This
seems
like
a
pretty
good
fit
for
the
API
server,
where
we've
already
got
this
request
context
and
could
add
additional
values
that
we
need
think
would
make
sense
to
log
to
that.
So
yeah,
that's
that's
the
background,
I!
Guess
what
I'm
proposing
I'd
be
interested
in
picking
this
up
in
126
and
starting
to
work
on
it.
F
It
can
definitely
be
incremental.
I!
Think
the
you
know
the
the
work
here
is.
First,
we
need
to
add
a
logger
somewhere
early
in
the
request
chain,
but
then,
after
that,
it
can
just
be
incremental
efforts
to
move
existing
log
lines
over
to
structured
logging
when
they
need
it
and
and
the
context
logger
as
well.
F
H
F
G
I
would
be
more
than
happy
to
help.
I
was
actually
thinking
the
same
thing
recently,
one
other
area
where
it's
a
bit
of
a
risk
is
if
we
pull
bits
of
structured
logging
out
of
individual
log
lines
and
add
them
to
the
contextual
logger,
because
they're
generic
and
we
want
to
pass
them
down
the
stack
or
whatever
for
users
that
are
running
the
API
server
with
the
contextual
logging
feature
Flagger
off.
B
My
concern
with
this
is
just
code
churned.
It
sounds
like
a
large
number
of
changes
and
I've
seen
some
PRS
changing
log
logs
in
other
areas
of
the
code
base
and
like
often
people
are
sending
things
that
chain
50
unrelated
log
lines
and
and
are
fixing
them
and
like
one
of
them
actually
is
a
breaking
change,
and
it's
just
incredibly
tedious
and
difficult
to
review
them.
So
I
don't
know
if
anyone
else
has
has
thoughts
on
that.
C
C
C
C
F
So
I
guess
that's
a
future
change
that
we
could
be
looking
at,
but
I
think
that's
also
likely
to
be
a
really
Mechanical
Code
refactor,
as
opposed
to
the
move
to
structured
logging
or
contextual
login,
which
would
be
not
just
necessarily
A
like
mechanical
API
change,
foreign
to
Daniel's
Point.
Definitely,
a
I
agree.
100
like
this
should
not
be
something
where
someone
just
goes
through
and
changes
all
500
log
lines
in
the
API
server
over.
F
That
was
my
point
about
incrementing.
Our
incrementalism,
like
I,
think
these
could
easily
be
pretty
small
PRS
that
are
Focus
changes
and
ideally
I'd
like
to
pair
it
with
you
know
not
just
like.
If
we're
touching
that
line
anyway,
we
should
also
kind
of
consider
the
other
aspects
of
the
log
like.
Is
this
log
actually
useful?
Is
it
at
the
right?
Verbosity?
Does
it
have
all
the
context
that
it
needs.
B
D
D
It's
like
really
difficult,
if
like
you're,
not
familiar
with
kubernetes
like
log
conventions
and
log
levels
and
stuff
to
like
come
up
with
something
sane
that
you
know
is
basically
logging,
the
right
stuff
at
the
right
layer
and
actually
using
structured
logging
and
whatever
else
so
like
one
of
the
things
I
eventually
ended
up,
doing
was
defining
a
much
more
like
developer.
Friendly
interface
like
I
want
this
to
be
a
debug
log,
which
is
like
log
level.
Four
but
I.
D
Don't
know
that
so
like
just
some
considerations
there,
like
I
I,
think
at
a
bare
minimum
I
would
ask
that
you
build
this
stuff
off
of
interfaces
so
that
it
can
be
swapped
out
under,
like
at
least
bits
of
it
can
be
swapped
out.
If
you
want
to
like
you
know,
if
you're
wiring
up
the
code
yourself
and
some
other
project,
that's
consuming
this,
it's
so
not.
Everyone
cares
to
necessarily
make
like
test
assertions
against
log
lines,
but
sometimes
you
sometimes
you
care
about
a
particular
log
line
at
having
some
context.
D
That's
some
yeah
I
mean
we
have
to
have
a
cap
for
Daniel
you're
looking
at
me,
but
the
KMS
kept
says
that
we
will
log
a
particular
thing
to
make
sure
you
can
trace
it
all
the
way
back
to
your
to
your
key
vault,
it's
kind
of
hard
to
make
that
assertion.
If
you
can't
write
a
test
that
says
that
you're
going
to
lock
that
uid
for
the
person
right
so
maybe
a
weird
case,
but
you
know
it
can
be
valuable
in
certain
situations.
D
G
I
I
guess
I
think
because
this
is
using
the
Blogger
interface
there's.
Certainly
some
very
opinionated
decisions
in
that
interface,
but
it's
pluggable
and
you
can
put
whatever
sync
you
want
and
critically
it's
not
a
package.
Global
like
you
know,
one
logging
framework
we
all
know
so
I
think
this
would
actually
make
your
life
much
easier.
No.
F
C
I
actually
freeze
my
thought
on
it
and
it's
not
judgmental
against
what
you're
doing
it's
more
judgmental
on
me.
If
this,
if
this
appeared
in
the
code
base
and
was
Zero
cost
to
me
in
terms
of
reviewing
or
approving
I
I,
don't
care
Tim,
you
do
you
do
good
things
and
I
think
you
would
do
a
good
thing
with
this,
and
that
would
make
me
happy
Daniel.
Do
you
bow
into
it?
Similarly,.
C
Don't
want
to
do
it
now,
like
you
think
about
things.
I'd
be
willing
to
do,
though,
like
if
this
was
important
to
Tim,
and
he
was
personally
gonna
review
them
all
and
he
limited
PRS
to
just
changing
these
logging
bits
and
said
in
each
of
the
PRS
I've
reviewed
this
one.
It
does
nothing
but
logging,
and
you
need
to
look
at
these
four
and
I.
G
Wouldn't
this
drum
nprs
here
just
be,
it
would
consist
of
two
things
right,
like
adding
a
context
to
a
parameter
list
if
one
didn't
exist
and
then,
instead
of
using
the
package
Global
from
klog
using
this
helper
function,
to
get
a
logger
instance
and
then
call
it
so
I
think.
If
the
only
thing
that's
inbounds
is
actually
moving
to
a
contextual
logging
thing,
they
risk
is
smaller
than
what
would
have
been
from
the
structured
logging
thing
and
then
like
pulling
context
up.
D
All
I
was
gonna,
say,
is
I,
guess
I
haven't
seeing
what
the
proposed
changes
in
this
contextual
logging
kept
are
like
at
the
code
level
like
I
mean.
Could
we
could
we
do
something
like
what
we
did
with
flying?
Go
where
we
did
a
bunch
of
mechanical
changes,
first
to
wire
up
just
context
as
like
the
first
param
like
if
you
did,
that
to
K
log
and
wired
up
a
context
to
its
all
of
its
functions
as
a
first
paramet.
D
F
Can
I
jump
in
here
to
respond
to
Daniel,
so
I
think
the
we
could
do
this
in
a
really
mechanical
way.
Context
is
already
plumbed
through
most
of
the
API
server
request,
path
and
I.
Think
we
could
just
you
know
for
126
I'd,
be
totally
happy
to
say
we're
gonna,
we're
not
going
to
plumb
context
through
an
additional
places
for
this,
but
just
changing
log
lines
where
we
have
context
would
be
feasible
in
terms
of
the
structured
logging
piece.
F
The
contextual
logger
is
only
a
structured
interface,
so
it
doesn't
support
the
like.
You
know
info
F
format.
We
could
just
say
you
know
pass
in
a
single
message:
that's
format.s
printf
and
not
actually
change
the
log
message
that
does
get
logged
in
the
actual,
like
output
slightly
differently.
It's
wrapped
in
quotes,
but
that's
the
only
difference.
There.