►
From YouTube: SIG Instrumentation 20200709
Description
SIG Instrumentation July 9th 2020
A
B
B
I
have
discussed
this
with
sully
before
and
he
was
happy
to
to
to
move
the
repo,
obviously
I'll.
I
would
double
check
this
again
if,
if
we
were
to
decide
to
adopt
this
project,
but
that's
essentially
my
my
proposal
that
we
adopt
this
project,
especially
because
pretty
much
every
maintainer
of
this
refill
is
already
part
of
sick
instrumentation.
A
Yeah
so
point
of
context
that
not
everyone
might
have,
but
it's
always
actually
on
my
team,
so
I
can.
I
can
actually
just
talk
to
them
today.
I'm
sure
it's
fine,
there's
a
couple
difficulties
about
transferring
stuff,
but
given
the
license
of
the
thing,
it
may
be
slightly
legally
more
convenient
if
we
just
created
a
sig,
instrumentation
repo
and
maintained
a
fork
and
then
had
sully
update
this
one
with
some
readme
that
says
this
one
is
no
longer
being
maintained.
Please
use
the
other
one.
B
Lilly
wrote
something
in
the
chat
she
can't.
Okay,
I
mean
she
asked.
Where
would
we
move
this?
To
which
org
I
mean
my
proposal
would
be
the
kubernetes
six
or
because
that's
where
everything
goes.
I
believe.
Regarding
the
the
legal
things
I
mean.
Obviously
I'm
no
lawyer,
but
I
I
would
assume
that
this
is
has
to
do
with
with
google.
A
D
D
I
know
that,
like
we
had
a
couple
of
discussions
around
also
taking
the
adapter
to
kind
of
like
a
cid-based
approach
in
the
future
and
like
a
couple
of
conversations,
so
I
I
like
I'm,
definitely
not
in
the
position
to
kind
of
like
do
it.
I
know
a
few
people,
but
I
also
don't
want
to
like
throw
them
under
a
bus
right
now.
D
So
I
would
need
to
double
check
and
maybe
like
frederick
as
we,
as
we
just
said,
knows
more
yeah,
but
like
definitely
like
from
our
side,
we
are
interested
in
and
like
keeping
keeping
the
component
updated
and
it's
like
essentially
also
a
crucial
part
of
the
openshift
stack
that
we
ship
so
we're
definitely
interested
in
kind
of
like
maintaining
prometheus
adapter
going
forward.
What's
the
question
frederick
like
who,
who
would
kind
of
be
able
to
shepherd
this,
and
I
think
we
we
still
have
somewhat
like
yeah
need
for
it
to
be.
A
D
That's
for
something,
if
there's
an
alternative,
so
right
now
like
there's
the
metric
server
which,
like
obviously
doesn't
talk
to
prometheus
and
then
there
are
some
some
other
adapters
for
like
cloud
provider,
specific
metrics,
but
there
isn't
really
an
alternative.
That
kind
of
like
implements
the
api
from
like
the
api
service
interface
for
metrics.
That
would
then
talk
to
prometheus.
So
it's
basically
that
one
component
that
talks
like
that's
the
glue
between
prometheus
and
the
metrics
apis
and
kubernetes.
C
C
A
No
that's
a
great
question.
There
is
precedent
for
stuff
like
this
and
I
I
can
in
api
machinery
the
way
that
we
do.
Clients
is
it's
basically
a
little
bit
of
both.
There
are
officially
supported
api
machinery,
clients
like
the
python
wrestling
client
or
the
python
client
go
client,
kubernetes,
client,
there's
also
clanco.
A
B
A
For
me,
this
is
an
implementation
period,
it's
just
because
it
uses.
For
me
this
is
my
permutation
maintain
it.
This
is
like
kubernetes,
specific
stuff,
so,
like
probably
the
best
mental
model,
for
this
is
like
there's
going
to
be
categories
of
things
that
people
bolt
on
top
of
instrumentation
such
that
there's,
like
third
party
libraries,
that
people
use
or
somebody
just
writes
in
a
personal
repo,
but
if
it
achieves
a
certain
level
of
traction,
then
as
a
community,
we
should
probably
say
we
are
officially
supporting
this
thing.
A
A
Yeah,
I
I
think
it's
fine,
it's
just
like.
I
mean
the
fact
that
api
machinery
has
multiple
clients
and
that
we
maintain
multiple
clients
doesn't
mean
that,
like
one
should
use
python
or
go,
that's
not
like
that
subjective
claim
is
not
being
made.
It's
just
yeah.
These
are
things
you
can
do.
These
are
things
that
you
can
use
and
we
will
support
these
official
ones.
A
A
D
Yeah,
I
quickly
put
something
there
kind
of
like
hijacking
it,
but,
as
you
are
asking,
I
don't
feel
that
bad
now.
So
essentially
there
was
this
issue
about
like
making
the
api
server
request
metrics
table,
and
I
commented
a
couple
of
weeks
ago,
I'm
just
wondering
if
there's
anything
to
be
done
on
on
that
issue.
A
A
D
A
A
Give
me
I
can't
say
that
I
will
have
time
in
the
next
by
the
next
one,
but
in
two
in
a
month
I
should
I
should
be
able
to
have
something
and
then
we
can
there.
Maybe
we
should
just
discuss
it
offline
because
I
am
like
your
use
case
is
also
interesting,
because
I'm
sure
we
have
different
things
in
mind
when
we
are
thinking
about
our
concerns
for
this
thing,
and
it
seems
like
you
may
have
some
insights
that
I
do
not.
B
Yeah,
I
think
in
general,
this
is
a
really
good
discussion
to
have
to
have
offline.
I
think
we
can
just
start
a
google
doc
and
kind
of
start
hashing
out
how,
because
I
think,
a
really
large
part
of
before
we
wanted
to
do
this.
We
wanted
to
review
once
again
the
like
set
of
labels
that
are
on
these
metrics.
Last
time
we
even
considered.
Maybe
we
will
only
have
the
latency
metrics
because
they
already
contain
counts
those
kinds
of
discussions
we
can
have
in
a
in
a
doc.