►
From YouTube: SIG Instrumentation 20221110
Description
SIG Instrumentation Bi-Weekly Meeting Nov 10th 2022
A
A
B
B
C
B
B
Okay
yeah,
so
mixance
is
basically
you
know,
a
set
of
alerts
and
dashboards
that
you
know,
projects
that
are
usually
working
with
metrics
expose.
So,
for
example,
if
you
have
a
operator
and
that
operator
has
some
meta
metrics,
so
you
would
want
to
have
them
in,
let's
say
have
a
have
a
dashboard
for
that,
so
that
folks
are
able
to
easily
visualize
that
in
a
grafana
in
a
dashboard
and
all
these
metrics,
you
would
have
alerts
on
top
of
them.
B
That
would
utilize
these
metrics
to
alert
whenever
there's
something
wrong
with
the
operator
yeah.
So
Damien
had
this
comment
and
Wiley
was
not
I.
Think
really,
plus
one
with
this.
He
kind
of
wanted
to
you
know
he
was
on
board
with
the
idea
of
instrumentation
owning
the
mixes,
that
for
all
these
sub
projects,
for
the
sub
projects,
that
not
all
but.
C
We've
been
like
removing
mix-ins
right
like
there
were
a
bunch
in
kubernetes
kubernetes
and
we
were
spinning
them
out,
but
we're
like
not
even
I'm,
not
even
sure
that
those
were
all
finished
and
I.
Also
not
sure
who
is
maintaining
those
in
their
current
state
like
I,
think
they're
kind
of
not
really
maintained,
I
mean
I
could
be
wrong.
But
I
was
one
of
the
approvers
for
like
spinning
some
of
that
stuff
out
and
I.
Think
like
we
did
the
initial
migration
PR
and
then
they've
kind
of
gone.
C
A
I
I
mean
my
understanding
is
basically,
if
like
KSM
has
some
standard
sets
of
metrics
and
they
have
stable
metrics
and
specifically,
you
can
create
like
slos
from
these
things,
and
you
would
not
have
to
intersperse
that
with
metric
data
from
other
sources,
I
I
don't
see
why
that
would
be
necessary.
I
mean
like
at
most.
You
could
mix
them
with
metric
data
from
let's
say
the
cube,
API
server
but
I
believe
that's
basically
necessary
dependency
anyway,
so
yeah
I
mean
I,
think
I
think
it
makes
sense.
A
A
The
next
topic
is
also
Brown
Shoe,
which
is
enabling
discussions
on
the
repo
that's
already
been
enabled
by
the
way,
so
you
can
yeah
yeah,
not
sure
how
much
people
will
use
it.
Historically,
people
don't
seem
to
use
GitHub
discussions
that
much
but
I
guess
it's
helpful
since
there's
no
dedicated
Google
group
for
KSM.
C
A
B
Yeah
there
was
an
AI
on
Damien
regarding
the
Google's
group.
You
know
coming
up
with
the
Google
flip
for
this
particular
thing.
So
that's
basically
what
so,
basically
all
of
these
points
and
all
of
the
experience
that
we
have
at
this
moment
is
based
off
of
what
Sig
enhancements
has
that
has
done
with
this
with
their
own
shadow
and
for
this?
Basically
they
they
have.
You
know
the
at
the
end
of
every
shadow
program.
B
They
have
this,
you
know
they
increase
the
member
list
and
you
know
for
the
folks
Who
deliver
and
then
they
again
you
know
roll
out
new
Google
forms
and
all
that
stuff
and
then
they
prepare.
The
set
of
you
know
major
features
that
need
to
be
that
need
to
go
in
so
I
was
thinking.
Maybe
we
can,
you
know,
start
talking
on
that.
B
You
know
start
it
rating
on
that
front
and
kind
of
you
know
start
so,
because
I
saw
you
know,
Catherine
and
I
have
been
contributing
for
a
while.
So
maybe
you
know,
if
down
the
line
we
can
become
members,
then
you
would
have
a
broader
force
and
we
can
have
you
know.
You
know
we
can
get
on
with
this
Shadow
program
and
you
know
start
assessing
what
what's
next.
For
this.
C
I
think
that
it's
a
great
idea
to
get
people
shadowing
and
whatnot
one
thing
that
I
would
caution
us
a
little
bit
on.
We
are
much
smaller
and
we
have
less
formalized
roles
within
Civic
instrumentation
so
like
there
is
a
lot
of
process
around.
How
I
think
someone's
at
Stig
enhancements
enhancements
is
a
subproject
of
Sig
architecture.
I
think
you
meant
stick
release
release,
has
the
release
team,
yeah
and
and
enhancements
is
part
of
it.
It's
confusing,
I
agree.
I
have
had
this
discussion
many
times,
but
they
have,
like.
C
C
With
like
every
release,
we
have
a
form
and
then
we
have
to
go
and
select
shadows,
and
then
we
have
to
like
formally
onboard
the
shadows
and
blah
blah
blah
like
I
know
that
that
requires
a
lot
of
work
on
the
part
of
folks
in
the
release,
team
and
I.
Don't
want
to
sign
focusing
instrumentation
up
for
that
much
work
because
I
don't
think
that
that
will
have
necessarily
a
lot
of
bang
for
the
buck.
So
I
would
rather
see
like
hey,
let's
figure
out
how
like
I
agree.
C
A
B
A
C
D
C
Yeah
I
I
would
say:
I,
don't
worry
too
much
about
that
you're
already
involved
in
places
that
you
know
aren't
necessarily
subject
to
those
free,
Cycles
I
will
say
that
there
is
absolutely
an
ebb
and
flow
of
contributors
throughout
the
years.
If
you
ever
look
at
some
of
the
dev
stats
graphs,
you
can
see
in
you
know,
sort
of.
C
As
there
is
like
a
northern
hemisphere,
winter
holiday
shut
down,
we
tend
to
see
a
lot
lower
contributions,
end
of
like
November
and
throughout
the
month
of
December,
but
realistically,
like
you
know,
just
just
work
on
some
stuff,
I.
Think
generally,
our
criteria
for
sponsoring
many
folks
in
Civic
instrumentation
are
happy
to
sponsor
new
orc
members
and,
like
the
bar,
is
not
super
high.
We
want
to
see
you
active.
We
want
to
see
you
want
to
continue
to
contribute.
C
If
you
are
interested
in
contributing
code,
I
believe
that
most
of
us,
like
definitely
the
bars
you
must
have
at
least
one
merged
pull
request.
I
like
to
see
a
few.
If
I'm
gonna
sponsor
someone,
they
don't
have
to
be
huge,
they
can
be
really
small,
like
the
extra
small
size.
Pr's
are
totally
fine,
but
you
can
read
more
about
the
proc.
The
process.
I.
Think
Han.
You
had
a
a
copy
of
the
contributor
ladder
open.
Maybe
we
could
link
that
in
the
minutes
and
the
chat
yeah.
C
Yeah,
so
this
explains
all
of
the
requirements
for
Community
membership
and
we're
really
excited
if
you're
interested
in
getting
involved.
I
know
it
can
be
somewhat.
You
know
confusing,
but
you
know
just
like
take
a
look
at
the
open
issues
and
PR's
on
projects
that
you're
interested
in
maybe
like
review
some
PRS,
maybe
you
know,
go
through
some
issues.
Submit
a
PR
for
a
small
thing.
C
It
doesn't
have
to
be
big,
could
be
typo
fixes,
preferably
not
like
large
type
of
fixed,
PRS
and
kubernetes
kubernetes,
because
those
rarely
get
merged
because
they're
hard
to
review,
but
definitely
like
you
know
and
reach
out
to
the
maintainers
in
the
sub
projects
that
you
are
interested
in
working
in.
So
if
you're
interested
in
Cube,
State,
metrics
I
think
there's
like
three
approvers
there,
including
Damien,
if
you're
interested
in
working
on
metrics
and
kubernetes
kubernetes,
there's
a
bunch
of
us
who
review
those
and
so
on
and
so
forth.
C
So
hopefully
that
gives
you
some
pointers
of.
Like
you
know,
the
guidelines
are
in
the
dock,
for
what
you
need
to
do
like.
We
mostly
just
follow
the
guidelines
within
instrumentation
and
then
who
do
you
ask
for
help
talk
to
the
approvers
in
the
places
that
you
want
to
contribute,
feel
free
to
reach
out
to
any
of
us
on
Slack.
A
E
Yes
hi,
can
you
hear
me
yep
yeah?
Yes,
yes,
so,
basically
at
tubecon
there
was
a
demo
about
using
open
tracing
to
trace
cubelets
and
the
kubernetes
runtime
and
I'm.
Also
working
on
like
a
project,
research
to
reuse,
kernel,
tracing
to
trace
cubelets
and
the
kubernetes
runtime,
so
I
thought
it
would
be
interesting
to
basically
show
a
bit
about
the
kernel
chasing
because
it's
not
really
well
known
in
life.
A
E
E
A
program
on
like
certain
system
calls,
while
ltdng
is
more
about
like
recording
the
different
events
and
like
seeing
which
event
called,
which
and
there's
a
tool
called
Trace
compass
that
allows
you
to
like
analyze
the
kernel
trace
and
with
that
you
can
actually
see
the
critical
path
of
a
process
and
see
which,
with
with
which
other
processes
communicated.
So
in
the
case
of
the
cubelet
you
can
see
you
can
see
the
cubelet
actually
like
contact
tick,
contacting
container
d
to
basically
schedule
ads.
E
A
E
E
Basically,
every
process
how
they
communicate
between
each
other
and
the
one
at
the
bottom
show
the
critical
path
of
like
the
cubelet,
and
basically
we
can
do
an
analysis
of
like
where
the
time
was
spent
and
like
on
which
process
it
was
waiting.
So
I
I've
put
some
annotation
on
the
basically
Gantt
chart,
and
here
you
can
see
basically
like
the
Zone
in
purple.
Is
me
using
Cube
CTL
to
like
start
the
to
to
apply
my
deployment.
E
Then
the
blue
Blues
only
is
like
the
the
pad
starting
up
and
in
the
middle
there's
like
a
orange
spot,
where
you
can
see
the
the
cubelet
scheduling,
basically
starting
up
a
count,
energy
processes
and
like
contacting
them-
and
you
can
also
like
compare
these
events
with
like
CPU
usage
and
memory
usage,
disk
usage.
So
in
case
of
like
latency
issues,
you
can
easily
diagnose,
like
the
reason
why,
like
a
certain,
startup
was
slow
like
on
which
process
it
was
waiting
for.
You
can
also
see
like.