►
From YouTube: SIG Instrumentation 20210708
Description
SIG Instrumentation Bi-Weekly Meeting July 8th 2021
A
A
A
Okay,
I
can
try
to
repeat
what
you
just
said:
you
might
want
to
try
a
headset,
so
I
think
han
just
attempted
to
say
that
there
is
a
conflict
right
now
with
the
current
triage
session,
which
is
9
a.m.
Pacific
time
on
wednesdays,
I
believe
it
conflicts
with
an
open
telemetry
meeting
or
something
like
that,
something
upstream
that
is
not
a
cube
meeting,
and
so
we
are
proposing
to
move
it
to
the
same
slot
as
this
meeting.
A
So
this
is
9
30,
pacific
time
on
thursdays
and
so
right
now
we
currently
are
alternating
meeting
wednesdays
and
thursdays
and
instead,
we'll
just
be
in
the
same
slot
every
week,
it'll
just
be
alternating
triage
in
our
normal
meeting
and
we
wanted
to
get
folks
feedback.
I
think
han
updated
the
invite
already,
but
wanted
to
make
sure
that
that
still
worked
for
everyone.
B
A
A
A
B
A
B
A
B
B
B
A
A
Me
pull
up
I'm
going
to
share
my
screen.
Let's
take
a
look
at
the
list
because
I
think
a
lot
of
people
here
are
not
currently
on
the
review
list
and
then
I
think
we
also
have
some
people
on
the
list
who
we
have
sort
of
kept
on,
but
maybe
aren't
active
reviewers
and
we
shouldn't.
So.
Can
everyone
see
my
screen
yep
great?
So
here
is
the
owners
aliases.
A
Let
me
find
instrumentation,
so
here's
our
current
list
of
reviewers,
which
is
mostly
like
the
current
list
of
approvers
plus
a
few
other
people.
So
I
think
we
have
coffee
pack
andy,
who
is
not
active
sergio
and
really
like,
not
a
lot
of
other
folks
who
are
getting
pinged
first
instrumentation
reviews.
So
we
would
like
to
add
people.
Let
me
see
if
I
can
find
the
reviewer
there's
the
contributor
ladder
thing
there.
A
We
go
community
membership
that
will
take
me
to
approver,
but
so
for
those
of
you
who
are
not
currently
familiar.
Kubernetes
has
a
community
membership
ladder,
and
so
there's
this
sort
of
process
going
from
like
member
to
reviewer
to
approver
to
sub
project
owner
and
the
these
like
reviewer
to
sub
project
owner
steps
are
mostly
reflected
in
what
are
called
owner's
files.
So
this
is
an
example
of
an
owner's
aliases
file.
Let
me
go
find
one
of
our
owner's
files
in
kubernetes,
kubernetes,
probably
from
component
base,
or
something
like
that.
A
Who
can
review
them
and,
like
you
know,
a
label
gets
auto
applied,
so
we
know
that
it
applies
to
us,
and
so
this
list
is
pulled
from
this
list
over
here
and
the
owner's
aliases
file
at
the
root
of
the
repo
and
right
now
we
don't
have
a
lot
of
people
in
that
list
outside
of
the
current
approvers
list,
and
some
of
them
are
also
not
super
active,
so
we
want
to
add
more
people
to
that
list.
So
what
does
it
take
to
get
there?
A
So,
in
order
to
become
an
a
reviewer,
you
must
first
be
a
member.
So
if
you're
not
already
a
kubernetes
org
member,
you
need
to
go
through
and
meet
all
the
requirements
and
become
one.
So
if
you
are
missing
sponsors
and
whatnot,
you
can
reach
out
to
us
and
we
will
make
sure
that
you
know
you
get
your
plus
ones
for
your
sponsorship
and
then,
after
three
months
you
will
be
able
to
apply
to
become
a
reviewer.
A
A
We're
happy
to
add
you
to
become
a
reviewer
right
at
that
point,
because
we
don't
have
nearly
the
pr
traffic
that,
like
I
think
these
guidelines
were
written
in
mind
for
and
then,
if
you've
been
doing
a
great
job
as
a
reviewer,
then
eventually
you
can
become
an
approver
after
three
months.
So
I
just
wanted
to
make
sure.
Let
me
copy
a
link
to
this
file
into
our
notes,
so
people
can
take
a
look
at
it
if
they
haven't
looked
at
this
file
before.
Are
there
any
questions.
D
A
A
A
No,
you
don't
need
to
create
the
pr's
yourself.
In
fact,
this
is
all
about
just
reviewing.
So
like
you
can't
review
your
own
pr,
you
have
to
review
other
people's
pr's,
so
you
can
become
a
reviewer
without
having
contributed
to
this
code
base.
You
simply
need
to
make
sure
that
you
are
doing
reviews
and
then
we
will
check
to
make
sure
that
the
reviews
are
high
quality.
A
So
you
know
if
you're,
just
like
throwing
lgtm
on
everything
without
making
any
comments
or,
like
you
know,
sort
of
deeply
looking
at
that
code,
then,
maybe
like
that's
not
enough
to
become
a
reviewer,
you
need
to
actually
go
through
and
review
that
code
and
you
may
ask
well
how
do
I?
How
do
I
do
a
good
review?
We
have
a
guide,
and
so
this
is
linked
in
the
requirements
for
reviewers.
A
C
A
A
Any
other
questions
that
sort
of
answered
the
question
that
I
was
going
to
ask,
which
is:
how
do
I
find
things
to
review
and
I
think
the
answer
is
you
could
look
at
prs
that
have
the
sig
instrumentation
label
on
them
in
kubernetes
kubernetes,
but
if
you're
not
really
sure
where
to
start
jumping
in
on
that,
not
feeling
super
confident
come
to
our
triage
meetings.
We
will
help
find
you
things
to
work
on,
just
show
up
and
be
like
hey.
I
want
to
review
things
and
we
are
very
happy
to
share
work.
A
D
D
D
D
A
C
E
D
So
that
that
was
discussed,
I
think
on
121,
if
we
should
launch
graduate
studies
looking
to
beta
with
cube,
let's
migrate
it.
The
problem
back,
then,
was
that
the
the
original
cap
proposes
two
separate
things.
One
is
the
migration
itself
and
second,
the
the
json
as
an
alternative
format
to
really
consume
the
deluxe
and
problem
is
that
we
are
more
further
with
migration,
because
lots
of
people
are
contributing
and
it's
easier
and
it's
easier
to
to
do
small
changes.
D
D
That
that's
only
my
fault
that
I
don't
want
to
block
it
further,
because
I
think
I
I
would
also
want
to
I'm
planning
to
talk
with
spectra
if
and
the
second
lead
to
what
what
we
are
trying
to
actually
to
discuss
what
we
are
trying
to
achieve
and
like
what
would?
What
really
that
data
means
and
if
the
mind
definition
of
beta
for
json
should
be
maybe
separate
than
migration
for,
and
migration
of
locks.
E
D
D
Interesting,
if
you
have
any
ideas
about
alternatives,
because
now
we
are
like
we
we
are
we.
The
cap
is
mostly
about
giving
people
alternatives.
So
if
you
think
you
like
you,
have
an
ideas
about
how
people
can
do
it
better
without
those
skeletal
features
that
we
are
removing
them
would
be
great.
Currently,
we
are
yeah,
depending
on
some
some
tool
that
was
created
randomly
without
intervention,
so
it
would
be
great
if,
if
we
have
some
better
long-term
solution,
yeah.
A
B
A
Yeah
they're
they're,
temporary,
but
like
caps,
are
also
temporary
right,
like
they
start,
and
then
they
end.
So
I
mean
I
think
that
would
probably
be
a
question
for
the
the
enhancements
team.
I
think
that
we
haven't
had
a
like
it's
interesting.
The
way
that
working
groups
have
worked
out
in
the
past
we
haven't
actually
had
with
the
cap
that,
like
you,
know,
sort
of
the
the
the
working
group
got
disbanded
when
they
kept
merged
kind
of
thing.
A
A
F
Thanks
we'll
try
and
get
there's
one
pr
that
I
really
would
like
to
get
in,
so
I
suppose
I'll
take
this
opportunity
to
post
it
here,
but
yeah.
We
have
the
primary
pieces
in
the
big
initial
pr.
Obviously,
and
then
a
couple
of
follow-ups
have
made
it
in
the
last
one
that
I
would
really
like
to
get
in
is
the
piece
that
connects
it
to
xcd
so
that
we
can
join
this
work
with
the
stuff
lily
already
did.
F
E
A
A
E
Yes,
so
I
I
I
I
missed
two
like
comment
in
time.
I
commented
on
the
pr
after
it
was
merged.
It
was
one
of
the
caps.
I
think,
like
one
thing
that
was
unclear
to
me
was
what
this
means
for
like
c
groups
v2,
because
a
bunch
of
metrics
stuff
changes
from
v1
to
b2-
and
I
remember
this
was
being
discussed
in
the
like
general
c
groups.
V2.
A
E
Right,
it's
more
of
a
it's
more
of
a
compatibility
problem,
because
almost
literally
everyone,
I
know
relies
on
these
metrics
and,
like
c
groups,
b2
doesn't
track.
I
don't
know
what
it
was
anymore,
whether
it
was
network
stats
or
cpu
stats.
I'm
not
I'm
not
sure
anymore
what
it
was,
but
the
the
recommendation
was
to
use
like
ebpf
to
collect
this
type
of
data
in
the
future,
and
I
I
feel
like
we
should
have
at
least
let
the
the
container
runtimes
know
well
in
advance
that
this
is
coming.
If
we're
doing
this.
A
It
because,
like
all
of
the
container
run
times
once
the
changes
get
made
to
the
cri,
they
have
to
go
and
implement
them.
So
it's
being
made
in
in
consult
with
them.
I
would
say
like
on
the
c
groups:
v2
side
of
things
c
group's
v2
is
still
an
alpha
and
so
like,
I
think,
until
that
graduates
to
beta,
we
don't
necessarily
have
like
the
big
same
stability
guarantees
that
we
might
need
there,
and
I
think
the
other
thing
too
is
like
until
we
start
telling
people
like.
A
Oh,
you
should
migrate
onto
c
groups
v2.
I
don't
think
that
that's
ever
in
the
short
term
going
to
be
a
thing
like
getting
rid
of
cruise
v1
support
in
favor
of
sea
groups,
v2
support,
it
would
be
nice,
but
like
that's
a
very
down
the
road
thing,
because
a
lot
of
people
are
running
with
kernels,
that
don't
support
c
groups
v2
and
they
are
supported
kernels
in
production.
A
B
A
Fine,
I
I
if,
if
we
like,
you
know
if
we
get
to
the
point
where
it's
like,
okay,
we're
moving
to
cruise
v2
and
this
is
a
blocker,
I'm
sure
that
we
will
find
some
sort
of
solution
for
that.
Definitely
I
looked
at
the
pr
that
that
peter
was
working
on
peter
hunt
is
currently
the
one
who
owns
this
cap
and
it
had
a
bunch
of
network
stats
stuff
in
there.
So
I
it's
certainly
part
of
the
specification.
E
Yeah
I
just
wanted
to
have
mentioned
it
because
in
the
sea
groups,
v2
cap-
I
I
forget
who
the
person
from
redhead
was
who
was
working
on.
That
said,
we'll
figure
it
out
in
this
other
cap,
which
was
the
sea
advisor
removal
cap
and
then
the
sea
as
a
removal
cap,
we're
now
saying
we'll
figure
it
out
when
the
ziggurats
v2
stuff
happens.
So
it's
kind
of
you
know
I
just
wanted
to
have
mentioned
it
that
this
will
it's.