►
From YouTube: SIG Instrumentation 20211209
Description
SIG Instrumentation Bi-Weekly Meeting Dec 9th 2021
A
A
A
I
guess
I
don't
have
any
current
announcements
other
than
124
development
is
open.
Hurrah
and
unfortunately
I
don't
think
that
there's
a
schedule
up
for
124,
so
I
can't
tell
you
dates
for
anything.
I
can
go
and
check
really
quickly
and
the
release
repo
yeah.
They
don't
have
anything
up
for
124.
I
don't
think
they
have
a
release
team
assembled.
Yet
so
we
don't
have
a
schedule
yet.
So
I
can't
give
you
any
announcements.
There.
B
A
That's
what
I
would
expect
as
well.
They
did
promise
us
that
they
were
supposed
to
get
a
schedule
out
before
the
release
actually
started
and
technically
like
we're
in
the
124
cycle.
Now
like
they
cut
the
alpha
yesterday.
So
I'm
not
really
sure
what's
going
on
with
that,
but
in
any
case,
yes,
I
think
that
late
january
is
a
fair
assumption.
A
A
So,
yes,
next
topic,
selecting
a
new
tech
lead,
so
at
our
last
meeting
frederick
announced
that
he
will
be
stepping
down.
He
meant
to
send
an
email,
but
that
email
has
not
been
sent
with
that
announcement.
So
the
rest
of
us
leads
now
take
on
the
responsibility
to
do
that
and
to
announce
a
new
tech
lead
to
replace
frederick.
A
So,
if
you're
interested
in
doing
that,
please
let
us
know
we
will
probably
select
someone
and
then
there
will
be
a
lazy
consensus
period.
So
to
give
folks
a
heads
up
about
that.
I
don't
think
that
we
can
announce
anyone
today
because
han
isn't
here.
So
consider
this,
I
guess
more
notice,
but
I
will
try
to
make
sure
that
we
have
at
least
a
written
email
go
out,
because
that
should
have
happened
already
so
action
written
email
on
rhetoric,
archer,
okay,
I
will
at
least
make
sure
it
happens.
A
A
So
this
is
the
list
plus
there
might
be
some
a
few
new
things
on
this
list.
We
want
to
make
sure
all
the
new
things
are
on
this
list.
So
do
let
us
know
if
you
missed
anything,
but
this
is.
This
is
basically
the
list
of
stuff
from
the
last
release,
and
oh,
this
is
now
out.
So
I
guess
we
want
to
see
if
we
want
to
start
graduating
more
things
and
it
would
be.
This
is
a
preliminary
like.
A
Obviously
the
release
cycle
hasn't
opened
up
yet,
but
it's
good
to
have
at
least
sort
of
advanced
notice
and
make
sure
that
anything
we
want
to
plan
to
do
this
cycle.
We
have
resourcing
on
and
sort
of
everything's
in
place,
because
there
are
potentially
a
lot
of
things
that
we
could
move
forward.
So
first
item
merrick,
deprecating,
k-log,
specific
flags.
I
think
that
one
went
alpha
and
123.
do
you
want
to
move
it
to
beta
and
124.
A
D
D
A
D
A
B
I
can
look
into
it
like.
I
don't
think
there
is
much
to
do
last
time.
I
checked
okay,
because
I
I
think
the
only
item
from
alpha
to
beta
was
to
support
like
giving
a
file
as
a
parameter
for
this
particular
like
feature,
but
I'm
not
sure
like,
because
it's
not
yet
documented.
So
I'm
not
sure
where,
when
we
want
to
do
that.
C
A
A
A
Yes,
that
was
definitely
similar
to,
I
think,
some
of
the
stuff
that
they
were
interested
in.
I
don't
think
we
have
that
on
our
list,
yet
so
I'll
make
sure
to
add
that
at
the
end,
because
I
saw
you
put
that
on
the
agenda,
so
structured
logging,
I'm
assuming
we're
not
doing
anything
because
it
went
beta
and
123.
So
typically,
we
don't
ga
for
another
release.
A
D
D
A
A
A
E
E
A
A
I
asked
around
a
little
bit
about
this
one
because,
like
the
api
is
graduated,
which
is
good,
the
feature
is
not
technically
marked
as
stable,
because
we
still
have
a
lot
of
stuff
on
the
old
api
and
like
in
theory,
we're
never
going
to
get
rid
of
it,
but
jordan
suggested
I
maybe
add
a
to
update
the
cap
to
say
that
the
goal
is
that
we
don't
want
any
entry
components
using
it.
So
I
don't
think
we
have
anyone
to
own
this
one
still.
A
E
A
I
would
like
to
deprecate
this.
I
know
that
I
think
some
people
at
google
are
using
this,
but
as
far
as
I'm
aware,
it's
not
being
used
anywhere
else.
We
had
a
bunch
of
reservations
when
we
first
introduced
the
feature
and
as
far
as
I
can
tell
like,
I've
tried
to
email,
the
owner
and
get
feedback,
and
I
just
I
haven't
heard
anything.
So
I
would
like
to
announce
this
for
deprecation.
A
A
I
will
mark
this
as
deprecated.
I
will
send
the
email
I
do
have
to
touch
base
with
the
sig
security
people,
because
we
technically
moved
this
cap
to
them,
because
it
was
one
of
a
couple
of
like
security
related
caps.
We
tried
to
hand
over
to
them,
but
it
turns
out.
There
is
some
code
that
sig
instrumentation
actually
owns
for
this
one,
and
I
know
they
were
kind
of
like
well.
What
do
we
do
with
this?
A
A
A
But
there's
no
associated
cap,
so
I
guess:
do
you
want
to
go
ahead
and
just
like
write
like
us,
you
have
like
a
skeleton
cap
for
like
it
doesn't
have
to
have
all
the
details
or
whatever
also
there
might
be
design
proposals
if
it's
five
years
old
in
the
archive
design
proposal
repo.
So
you
can
totally
just
like
reference
that
as
well
and
don't
have
to
let
go
and
rewrite
everything.
F
A
A
B
If
I
can
just
like
one
at
one
thing
regarding
that
topic,
so
I
got
like
three
metrics
api
that
are
still
not
graduated
to
gi,
even
though
they
are
in
there
like
for
a
while
now
so
the
matrix
api.
We
have
also
the
custom
matrix
on
the
external
matrix
one
and
they
all
suffer
from
the
same
problem
that
they've
been
beta
for
like
too
long.
A
A
A
D
Yeah,
that's
the
contextual
logging,
so
just
to
give
everyone
some
feedback.
Some
some
background.
This
has
been
in
very
early
drafts
of
structured
logging
and
then
was
pulled
out
as
being
too
complicated
as
a
first
step,
but
I
think
we
should
bring
it
back
now,
because
there
are
use
cases
in
six
scheduling,
for
example,
where
they
ask
for
features
that
exactly
depend
on
this
functionality.
D
D
How
we
want
to
make
a
logger
available
in
a
certain
call
chain
without
falling
back
to
a
global
logger,
which
is
what
what
we
currently
do
with
k-log,
and
that
is
that
is
mostly
the
technical
question
that
we
need
to
solve,
where
we
need
to
get
agreement
among
kubernetes
developers,
because
the
cap
proposes
to
use
for
context
the
go
contact
structure
and
attach
a
logger
to
it
for
those
functions.
That
already
have
a
context-
and
I
know
that
some
people
have
concerns
about
that.
A
A
D
Okay,
so
right
now
I've
been
discussing
it
with
six
scheduling
and
with
the
folks
who
had
open
use
cases.
Four
ways
and
I've
been
pointing
them
at
the
camp,
and
I
know
that
six
scheduling
aldo
is
fully
behind
that
and
and
once
this
done,
because
they
they
want.
They
have
an
open
issue
about
enhancing
logging
in
cube
scheduler,
and
this
is
a
major
part
of
their
solution
that
they
they
want
to
do.
D
And
the
other,
the
other
thing
is
about
structured
logging.
One
observation
is
that
we
are
basically
now
touching
large
parts
of
a
code
base
to
replace
k
log
in
for
f
with
k
log
in
for
s
and
if
we
then
go
in
and
later
do
the
same
thing
with
contextual
logging,
it
touches
the
same
files
a
second
time
and
we
need
to
for
reviewers
again
when
we
make
that
second
change.
D
My
thinking
also
was
that
if
we
can
get
contextual
logging
infrastructure
in
place
in
124
and
perhaps
have
cube
scheduler
as
a
good
test
case
and
and
proof
of
concept
in
practice
that
this
works,
then
future
conversions
can
directly
do
contextual
logging
and
structured
logging
in
one
pr
for
for
certain
parts
of
the
code
base
and
overall
we
will
make
more
progress
towards
our
ultimate
goals.
If
we
combine
those.
A
That
sounds
great
to
me.
We
have
one
minute
left.
So,
let's
come
back
to
the
rest
of
our
agenda,
so
schwei
feel
free
to
ping
me
about
the
slo
stuff
offline.
I
can
help
you
with
that.
I
don't
think
we
have
francesco
today.
So
we
can
push
this
into
the
new
year.
Are
there
anything
else
that
you
would
like
to
discuss,
because
we
will
be
definitely
canceling
our
final
two
scheduled
meetings
of
the
year
and
I'm
not
sure,
what's
going
on
triage
next
week
as
there's
also
the
conflicting
contributor
celebration.