►
From YouTube: SIG Instrumentation 20210610
Description
SIG Instrumentation Bi-Weekly Meeting
June 10th, 2021
A
Hello,
everyone
and
welcome
to
today's
edition
of
sig
instrumentation.
It
is
thursday
june
10th
2021..
We
have
two
items
on
the
agenda
today
and
they're
both
from
me.
Oh
no,
so
let
me
link
the
agenda
in
the
chat
and
let's
get
started
so
first
item
this
one's
a
good
one.
So
I
would
like
to
because
I
know
that
we've
talked
about
this
being
important
in
the
past,
but
then
we
haven't
really
made
any
progress
on
it,
so
I
would
like
to
put
out
a
call
for
help
with
metric
documentation.
A
It
would
be
really
cool
if
we
could
like
take
that
automation
and
expand
it
a
little
bit
and
like
ensure
that
the
help
text
was
like
actually
correct
for
everything,
and
also
we
had
like
a
registry
somewhere
in
the
documentation
of
all
of
the
metrics,
with
like
accurate
help
text.
I
think
this
would
be
really
good
because
right
now
trying
to
figure
out
what
a
given
metric
does
is
awful.
A
B
A
C
So
we
didn't
want
to
force
everyone
like
we
implemented
some
cases
that
we
wanted
to
handle
and
decided.
Okay,
let's
not
force
everyone
to
comply
to
those
cases
like
how
you
declare.
Is
it
global
or
is
it
function?
Can
you
use,
I
know
const
or,
like
borrow
some
variables
externally,
we
we
propose.
Okay,
let's
require
this
for
stable,
because
because
some
metrics,
like
you
know,
cubelet,
are
auto
generated,
and
this
like
handling
those
metrics
or
discovering
them
would
be
pretty
hard
from
buy
stuff
to
kind
of
listen.
A
B
A
A
A
B
B
D
A
B
A
A
C
A
Okay,
cool,
that's
exciting.
I
really
just
want
to
see
more
documentation
for
metrics,
because
people
are
constantly
asking
me:
what
does
this
metric
do
and
I'm
like
I
don't
know,
and
the
person
who
wrote
it
is
like
gone
and
they
didn't
write
any
documentation
either.
So
there's
nothing
I
can
do
about
it.
B
C
Good
to
discuss
and
with
I
don't
think,
do
we
have
the
sea
docs
to
what
format
they
want
to
ingest.
So
I
assume
each
each
release
comes
with
auto-generated
command
line
instructions,
so
if
we
could
hook
up
with
the
same
process
exactly
yeah
first,
do
it
manually
for
the
latest
release
or
if
someone
wants
to
do
that
technically
static
analysis
could
do
a
fill
up
for
the
previous
releases,
but
then
make
it
a
regular
easy
to
continue
process.
A
A
A
So
hopefully,
when
we
get
a
bunch
of
stuff
like
sort
of
sussed
out
for
that,
then
we'll
have
areas
for
all
sorts
of
contributors
to
come
in
and
like
actually
check
over
metrics
and
make
sure
that
the
docs
are
up
to
date
and
whatnot,
so
it'll
be
a
great
opportunity
for
new
contributors
cool.
So
if
nothing
more
on
that
topic,
we
sent
something
to
sig
node
with
me,
and
I
discussed
it
there
and
now
I've
brought
it
back.
A
So
we
suggested
that
maybe
if
we
can
avoid
shaving
that
yak,
we
should
so
and
it
looks
like
in
the
reply
merrick,
you
said
that
skipping
the
start
time
for
nodes
makes
sense,
so
just
wanted
to
make
sure
that
everybody
here
was
aware
and
that
we're
all
on
the
same
page
and
if
there's
any
concerns
about
that
or
questions
about
the
discussion.
That's
signed.
B
B
B
B
A
So
my
hot
take
on
this
is
that
we
don't
have
enough
stable
metrics
yet
for
people
to
say
it's
not
stable.
Therefore,
there's
no
sla,
because
there's
like
three
or
four
and
like
I
think
that
every
component
needs
to
have
stable
metrics
before
we
can
say
if
it's
stable,
then
you
follow
this
deprecation
guideline.
If
it's
alpha,
then
you
can
do
whatever
you
want
kind
of
thing,
because
many
of
these
metrics
that
we've
had,
for
you
know
a
dozen
releases
like
people
aren't
expecting
them
to
disappear,
even
though
they
are
alpha.
A
So
I
know
that
in
the
past
certainly
any
time
a
metric
is
removed,
it
has
to
have
an
action
required
release,
note
and
some
sort
of
steps
from
migration
off,
but
I
think
it's
better,
especially
if
things
like
do
we
have
a
guideline,
I
guess
we
are
creating
the
guideline.
Would
it
be
fair
to
say
that
if
a
metric
has
been
in
cube
for
like
say
two
or
more
releases
that
there
needs
to
be
a
minimum
of
a
one
release,
deprecation
period
for
removal.
E
A
B
We
can
I
mean
it,
wouldn't
be
that
hard
to
introduce
the
machinery
is
all
there
already.
So
if
we
have
a
rule,
it
would
be
relatively
easy
to
introduce,
but
the
problem
is:
if
we
introduce
this
thing,
we
have
to
go
and
mark
a
bunch
of
these
things
as
beta
yes,
and
it's
it's
not
us
that
does
that
it's
component
owners
and
those
component
owners
are
not
likely
to
mark
something,
as
beta
they're,
either
likely
to
categorize
something,
as
you
know,
stable
or
supported,
or
not
supported,.
F
Dude,
I
didn't
actually
look
at
the
pr,
but
does
the
group
that
owns
the
component
with
this
metric
in
this
case
want
to
remove
the
metric,
because
we're
really
providing
a
minimum
bar
that
people
have
to
reach
right
in
terms
of
like
if
you're
stable,
you
can't
remove
it.
We
don't
necessarily
specify
that
what
you
have
to
do
if
it's
alpha
you
can
provide
whatever
transition
you
want.
A
B
F
Well,
how
about
this?
What
if
we
only
allowed
metrics
to
stay
in
alpha
for
a
set
number
of
releases
before
the
component
owner
either
had
to
remove
them
or
promote
them,
because,
essentially,
what
you're
saying
is
an
alpha
metric?
That's
been
there
for
x
number
of
releases
acts
like
a
stable
metric
right,
because
stable
doesn't
mean
well.
A
We
need
something
to
prevent.
You
know
perma,
alpha
of
metrics
or
perma
beta
cube
y.
It's
a
little
bit
weird
for
us
to
only
have
the
alpha
and
like
stable.
I
found
because
people
will
add
metrics
in
like
say
an
alpha
stage
of
a
cap
and
then
they'll
try
to
graduate
it
to
beta
and
they'll,
be
like
oh,
but
I
thought
I
had
to
make
my
metrics
beta,
but
I
don't
because
there
is
no
beta
of
metrics
phase.
B
F
I
would
say
that
if
we
want
to
have
a
separate
policy
like
one
release,
deprecation
required,
then
a
separate
stage
makes
sense
to
communicate
that,
and
I
would
that
what
I
was
going
to
say
about
sort
of
forcing
upgrades
after
a
certain
number
of
releases.
Is
that
then,
instead
of
it
being
a
silent
like
component
owners
silently
taking
on
additional
responsibilities,
we
make
it
an
explicit
decision
by
them
to
like
they
have
to
do
something.
E
B
The
problem
I
have
with
that
is
like
not
all
metrics
are
like
great
for
promoting
to
stable,
because,
like
metrics
can
change
with
the
shape
of
code
and
like
the
thing
that
you
are
instrumenting
can
change
right.
There
can
be
more
dimensions
or
whatever,
like
as
development
occurs.
So,
like
it's
feasible
that
you
have
a
metric,
that's
like
very
tied
to
development
cycles,
which
changes
frequently
enough
so
that,
like
basically,
you
can't
really
have
any
guarantees
right
like.
F
B
A
Like
we
have
to
have
some
sort
of
terminal
ground
here
right,
you
can't
have
an
alpha
metric.
That's
changing
every
release
for
like
six
releases
like
it
either
needs
to
get
stable
at
some
point
or
it
needs
to
get
removed.
I
don't
think
that's
an
unreasonable
ask
like
how
many
features
stick
around
and
change
every
release
for
six
releases
like
to
give
a
you
know:
priority.
A
Like
maybe
you
set
it
to
like,
I
mean
I
don't
know
if
this
is
a
guideline
that
we
can
actually
enforce
statically,
but
if
the
like,
the
shape
of
the
metric
has
not
changed
in
a
release
for
four
releases,
then
we
kick
it
out.
If
people
don't
like,
we
automatically
promote
it
or
kick
it
out
like
if
the
labels
are
changing
or
the
state
of
the
metric
looks
very
different
from
release
to
release,
then
that
resets,
the
cycle.
B
B
A
B
A
B
A
A
A
Don't
think
that
we're
retroactively
making
any
rules
that
has
been
the
unspoken
rule
of-
or
I
shouldn't
say
unspoken
that
has
been
the
spoken
informal
rule
like
we
have
not
written
it
down
in
documentation,
but
every
single
metric
that
I've
seen
that's
effectively
been
like
you
know,
consumed
by
end
users.
We've
always
had
some
sort
of
deprecation
policy
around
it
like
prior
to
even
the
metric
stability
framework,
as
as
I
said
like
the
problem
is
everything
is
defaulting
to
alpha.
A
There's
almost
nothing
in
stable,
so
we
can't
say
90
of
metrics
and
cube,
have
no
guarantees
and
like
we
can
remove
them
willy-nilly.
That
would
break
everybody
consuming
kubernetes
and
that's
never
been.
The
policy
like
we've
never
said,
oh
yeah,
by
the
way
like
a
metric
can
just
disappear
and
in
fact
we
have
gotten
urgent,
urgent,
critical
bugs
where
people
like
this
metric
has
disappeared
and
we
move
heaven
and
earth
to
make
that
metric
go
back.
So
I
I
don't
think
that
we're
retroactively
adding
a
policy.
I
think
that
we're
formalizing
an
existing
policy.
B
A
F
I
was
going
to
say
yes,
it
would
be
fairly
simple
for
us
even
just
to
provide
recommendations,
but
not
requirements
retroactively,
so
we
we
can
say
like
for
alpha
metrics.
If
you
can
provide
this
deprecation
period,
you
should,
as
like,
a
more
that
way.
At
least
we
have
something
to
point
out
for
new.
B
Inquiries
I
mean
to
be
fair,
the
the
metric
that
they
want
to
remove
and
that
the
the
pr
that
I
linked
is
in
fact
duplicated
and
the
other
one
is
is
more
granular,
so
it's
better,
but
both
metrics
have
been
around
for
like
two
years
at
least,
and
people
depend
on
them.
I
mean
registered
watchers
just
gives
you
the
watch
accounts.
It's
going
to
be
used.
Pretty
heavily
right,
like
long
running
gauge
is
not
as
obvious
that
it
includes
the
watch
accounts.
A
Okay,
so
I
think
what
we
should
do,
I
think
we
should
have
a
policy
in
the
community
docs.
I
think
we
should
make
the
policy
what
the
informal
guidelines
have
been
for.
Like
the
past
multiple
years
of
me,
working
in
cube
and
everybody
else
here,
working
in
queue,
we
need
to
figure
out
what
the
exact
details
are.
I
think
we
can
probably
hammer
that
on
a
pr,
because
we
are
at
time
it
is
10
o'clock.