►
From YouTube: SIG Instrumentation 20220929
Description
SIG Instrumentation Bi-Weekly Meeting Sept 29th 2022
B
B
B
C
So
to
start
this
off,
there's
something
called
a
shadow
program
that
seek
the
lease
does
right
now
and
it
has
been
doing
for
a
while,
and
the
aim
of
this
this
program
is
so
basically
you
would.
You
would
see
the
contributors
that
you
know
that
are
learned
with
a
positively
a
kubernetes.
You
know
it
could
be,
let's
say
KSM,
so
the
contributor
in
general
has
more
time
and
less
experience
in
that
particular.
You
know
regarding
that
particular
code
base
and
it's
completely
the
opposite
for
the
maintainers.
C
So
the
shadow
program
aims
to
be
a
balance
between
these
attributes
and
the
redistribution
of
responsibilities
between
you
know
the
maintainers
and
the
contributors
so
that
both
of
these
parties
can
get
what
they
desire.
So
it
could
be,
like
you
know,
there's
multiple
points
that
I
put
down
as
a
you
know
as
how
this
could
benefit
us
in
the
longer
than
I'm
just
going
to
go
over
some.
C
Some
of
the
some
of
these,
which
is
a
long-term
maintenance
situation,
solution
for
all
non-duplicated
projects,
which
is
also
related
to
you,
know,
Reviving
smaller
projects
that
are
implicitly
reaching
end
of
life,
for
example
the
ones
that
are
not
being
maintained
anymore
and
the
the
maintainers
are
simply
just
you
know
they
don't
have
enough
time
to
attain
to
these
projects.
So
who's
going
to
take
these
up
right,
there's,
there's
there's
always
some
contributors
Who
come
out
of
nowhere
and
contribute.
C
You
know
to
minor
issues
or
something,
but
we
don't
have
you
know
commitments
from
them.
We
don't
have.
We
cannot
have
the
rights
right.
We
cannot
have
a
major
push
in
the
direction
that
we
want
using
that
contributor
base
so
yeah
again,
better
Outreach
for
the
sake
Shadows
yeah.
Of
course,
there's
there's
something
for
the
Shadows
too.
C
In
this,
which
is
you
know,
they
are
promoted
to
higher
roles
if
they
deliver
as
expected
and
yeah
I
have
you
know,
I
have
emphasized
what
the
maintainers
would
kind
of
do
what
they?
What
the
ask
is.
This
is
not.
These
are
not
hard
hard
requirements,
but
these
requirements
are
based
off
of
what
Sig
release
has
been
doing
or
what
their
maintainers
have
been
doing
and
what
we
could
ideally
do.
So
it's
it's
broken
into
three
different.
C
The
other
one
is
the
one
that
needs
to
happen
every
iteration
every
year
and
finally,
there's
the
multiple
one
which
needs
to
happen
with
multiple.
You
know
with
individual
Shadows
between
the
maintainers,
so
maintainers
would
need
to
talk
to
the
Shadows
every
single
Shadow
about
this.
These
particular
tasks
that
are
there
under
multiple
engagements
in
order
to
make
sure
that
the
Shadows
understand
the
Viewpoint
of
the
maintainer.
C
B
B
You
can
see
here
rainbow
mango
was
basically
a
shadow
and
was
promoted
all
the
way
to
an
approver
for
a
top
level
approver
for
all
of
the
instrumentation
code.
So
we've
basically
have
done
stuff
like
this
before,
just
not
officially
but
yeah
I
mean,
like
our
team,
is
pretty
receptive
to,
like
you
know,
obviously,
mentoring
and
having
shadows
and
doing
whatnot.
B
C
A
B
A
B
A
Yeah
I,
actually
find
me
add
to
to
your
point
and,
like
I,
see
the
benefits
for
kubernetes
and
we've
done
it
in
the
past,
but,
like
I,
think
the
most
benefit
we
could
get
from
that
is
on
the
sub
projects,
because,
like
a
lot
of
them,
are
running
kind
of
an
FC
currently
like.
If
you
saw
a
couple
of
weeks
ago,
like
I,
updated
the
owner
files
of
like
Prometheus,
adapter,
custom,
Electric,
Supply
and
stuff
like
that
and
I'm
the
only
approver
and
reviewer
nowadays,
so
that
that's
the
situation.
B
A
B
No,
it's
not
just
the
sub
projects,
it's
literally
everything.
We
have
one
person
on
all
of
the
code.
We
have
no
redundancies,
so
if
anybody
leaves
then
basically
we
lose
expertise
in
huge
parts
of
the
code
base.
That's
the
problem,
yeah,
so
pranju
I
agree
with
you.
We
need
this
I,
don't
know
how
to
set
up
a
Google
group
or
a
calendar
for
that
matter.
B
The
role
of
handbook
we
could
probably
just
copy
and
paste
from
the
from
the
Sig
release
team.
It
looks
like
otherwise,
if
we're
willing
to
not
do
this.
I
am
I'm,
also
like
accessible
via
slack
and
and
willing
to
do
mentorship
stuff,
like
I,
have
done
this
before
when
people
have
reached
out
to
me
and
I
am
willing
to
do
it
whenever
just
to
be
on
record.
A
B
A
A
B
B
Sure
I
mean
yeah,
look
if
I'm
mentoring,
someone
who
will
be
on
kubernetes
kubernetes
and
our
code
in
kubernetes
kubernetes
in
component
base
and
this
technology
stuff
and
whatever
right
like.
If
you
do
it
I
imagine,
you
would
be
doing
like
Cube,
State,
metrics
or
metric
server,
I,
don't
know,
probably
KSM
right.
Well,
the
Matrix.
A
B
B
A
B
C
A
B
B
A
A
B
Yeah,
but
how
do
you
monitor
the
feature
gate
enabled
metric
exactly
right?
It
doesn't
even
make
sense.
It's
a
matter.
It's
a
metametric
like
it's
a
meta
feature
metric
right
like
it's
nice,
though
look
at
this
now
we'll
be
able
to
tell
which
features
are
enabled,
and
we
can
count
and
do
splices
across
the
fleet
to
determine
which
sections
of
the
fleet
have
certain
features,
enabled.
B
B
B
A
A
B
A
B
Applied
for
a
face-to-face
sign,
instrumentation
meeting
at
kubecon,
so
if
you're
going
to
be
at
kubecon,
there
is
a
high
probability
that
there
will
be
a
face-to-face
sign,
instrumentation
meeting
and
this
like
I
I,
love
the
face-to-face
instrumentation
meetings.
We
did
a
lot
of
planning
in
Barcelona
in
2019
and
then
we
like
tracked
out
like
literally
years
of
stuff,
and
we
actually
accomplished
most
of
it.
So
I
am
excited
about
having
another
face,
to
face
and
being
able
to
to
track.