►
From YouTube: 2022-01-26 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
C
C
Right
yeah,
so
I
have
one
one
one
good
microphone,
but
I
can't
use
that
one
today
and
zoom's
background
noise
filtering
seems
to
be
really
bad.
D
E
F
C
D
C
Yeah
yeah
by
next
week
I
think,
okay,
I'm
flying
back
situation
there.
It's
so
awful
that
I
don't
know.
I'm.
D
C
C
D
Yeah
I
have
enough
travel
coming
up
myself
this
year
that
I
just
ended
up
buying
one
of
those
little
testing
machines,
probably
the
one
that
david's
familiar
with
the
same
one.
I
think
they
gave
out
to
all
the
google
employees.
It's
quite
handy
yeah,
it's
pretty
cool
yeah.
D
C
Sure
yeah,
so
I've
seen
a
couple
of
requests
over
the
past
few
weeks
or
even
in
the
same
week
that
one
person
was
was
requesting
some
sort
of
interceptor
filter
or
a
round
tripper
for
the
client,
the
client
side
of
things
or
the
client
settings,
and
someone
else
was
asking
for
an
authorization
mechanism
or
rate
limiter
for
for
ingestion.
So
for
receivers
now
they
both
can
be
implemented
in
the
same
similar
pattern
as
interceptors
and
before
actually
doing
that.
C
So
we
have
something
that
is
similar
to
that,
and
that
is
on
on
the
client
side,
or
rather
on
the
receiver
side.
We
have
authentication
mechanism
which
is
implemented
as
a
as
an
extension,
and
we
have
the
the
client
settings
or
the
client
authentication
mechanism
as
well
for
the
client.
What
is
it
called
client
authenticator,
which
is
a
round
tripper
for
http
or
interceptor
for
jrpc,
but
it's
transparent
to
whoever
is
implementing
the
interceptor,
because
it
is
just
an
intersection
authenticator.
C
So
I'm
wondering
if
we
want
to
apply
the
same
authentication
pattern
elsewhere
for
those
use
cases
right.
So
if
we
should
build
a
a
generic
mechanism
for
the
receivers
to
use
so
that
you
can
build
interceptors
and
for
outgoing
http
connections
or
each
outgoing
connections,
http
or
grpc,
in
a
way
that
they
can
then
also
build
interceptors,
those
would
then
be
extensions
and
they
can
be
then
referred
or
referenced
on
the
client
settings.
Your
pc
settings.
C
I
think
it
is
config
http,
config
jpc
and
on
the
receiver
side
on
on
the
on
the
same
packages,
actually
so
configuration
for
future
pc
or
if
anyone
sees
any
any-
and
it
has
any
objections
on
the
way
that
we
are
doing
that
for
authentication.
F
F
I'm
not
completely
sure
how
exactly
it
needs
to
be
implemented,
but
I
suspect
it's
probably
possible
to
do.
My
only
concern
right
now
is
that
it's
yet
another
thing
that
we
need
to
work
on
and
I'm
a
bit
kind
of
cautious
about
spreading
our
efforts
a
bit
too
thin
if
we
take
this
one
as
well.
So
maybe
I
guess
maybe
not
right
now,
but
in
the
future,
if
you
will
something
like
that
would
be
my
response
in
this
case,
I
don't
know.
C
That
that's
not
fair,
yeah,
I
think
that's
and
the
people
who
would
be
working
on
that
they,
I
think
they
would
be
stretching
their
own
age,
so
they
would
be
fixing
something
that
they
need
right
now
and
I'm
not
sure
they
would
be
working
on
anything
else
than
that.
But
I
I
do
get
the
point.
We
it
does
divert
our
attention
to
places
where
it
should
not
be
so
I
totally
agree
that
it
can
be
done.
Postgame.
G
B
I
thank
you,
google,
for
that
all
right,
so
I
have
my
fourth
prototype
so
a
lot.
A
few
weeks
ago,
I
mentioned
that
I
was
going
to
look
at
adding
the
optional
skill
support
manually
into
the
protos,
sorry
for
the
protos.
B
So
what
I
did
here
in
this
pr
is,
I
kind
of
started
the
work
towards
that
direction,
to
what
I
would
have
done
here
and
I
can
share
my
screen
where
people
can
just
pull
the
pr
themselves,
but
basically
I've
added
the
mid
max
field
to
the
histogram
data
point,
and
rather
than
going
through
and
refactoring.
B
Everything,
as
I
had
kind
of
alluded
to
before,
all
I've
done
is
I've
just
added
the
field
manually
to
the
existing
photos,
so
I've
mentioned
in
the
description.
Some
of
the
some
of
the
challenges
with
this
approach
is
that
basically
we
have
to
stop.
B
We
have
to
stop
using
the
gen
proto
all
together
once
this
is
in
because
then
we'll
have
to
either
we
stop
using
it
or
we'll
have
to
manually.
Add
it
back
in
in
some
ways.
So
I
guess
we
could
have
some
kind
of
set
script
that
adds
the
functionality
back
in
if
we
want
to,
but
that
might
get
a
little
bit
tricky,
but
other
than
that
I
just
wanted
to
get
some
eyes
on
on
the
draft.
B
There's
still
a
bunch
of
work
to
do
here,
there's
I
have
to
add
the
same
fields
for
exponential
histogram
data
point
exponential
histogram
and
then
I
have
to
also
add
make
the
sum
field
optional.
If
we
want
to
support
all
the
proposed
optional
fields,.
F
B
F
B
F
B
I
mean
the
suggestion
would
be
if,
if
we're,
okay
with
patching
it,
I
I
would
go
as
far
as
we
can
with
the
generated
code.
So
I
would
take
the
tr
that
you
have
that
regenerates
with
all
of
the
deprecated
messages,
cleaned
up
and
then
then
go
ahead
and
apply
this
patch
to
it
and
then
and
basically
moving
forward.
We
would
just
have
to
add
the
fields
manually
as
as
we
as
we
as
the
protos
change
or
whatever,
which.
B
Yeah,
which
thinking
back
of
the
of
the
flow
that
we
have
today
when
the
produce
change,
we
basically
have
to
do
a
bunch
of
manual
work
anyways
to
make
sure
that
the
p
data
is
added.
So
this
would
just
be
shifting
see
the
manual
work
to
do
it
a
little
bit
more
upfront
because
we
wouldn't,
we
would
be
doing
it
like
even
to
add
it
just
to
the
the
proto-generated
codes.
F
Yeah,
looking
at
the
change
what
you
changed
in
the
generated
code,
it's
like
10
20
lines
of
code.
I
think
I
guess
my
first
reaction
is
that
this
is
preferable
right.
Why?
Why
rewrite
everything?
If
you,
if
you
just
need
to
touch
like
10
20
lines
of
code-
and
maybe
you
can
even
extract
that
to
a
separate
function
like
that
minimize
the
amount
of
the
code
that
is
actually
modified
in
the
generated
code
if
we
can
reliably
patch
it?
F
E
F
For
so
yeah,
and
it
opens
up
the
possibility
of
doing
some
custom
work
on
the
other
fields
that
I
would
want
to
try
like
the
ones
I
mentioned
like
any
value,
is,
is
very
inefficient
right
now
it
can
be
replaced
by
another
data
type.
That
is
much
more
much
better,
so
I'm
yeah.
I
think
I
like
this
approach.
B
B
G
I
just
wanted
to
ask:
we
are
get
to
release
0
43
today
for
concrete
right.
There
are
no
blockers
for
that.
G
A
H
H
I
think
we
asked
this
in
the
so
in
the
collector
channel,
but
at
what
point
are
we
looking
at
building
out
support
for
exemplars
on
the
prometheus
exporter
and
receiver?.
E
H
I
I
don't
see
any
reason
why
we
shouldn't
do
it
anthony
that
is
the
I
think
it's
stable
now
the
prometheus
openmetrics
format
definition
for
is
it
sorry.
Let
me
double
check.
E
E
E
Yes,
absolutely,
I
think
I
gave
you
some
pointers
in
the
slack
chat
as
to
where
to
start
for
that.
H
Right
great,
thank
you
for
that
and
the
the
other
question
that
I
that
I
had
was,
I
I
think,
anthony
you
are
helping
us
out
with
the
same,
but
in
general,
the
the
prometheus
receiver
and
exporter
are
not
compliant
with
how
prometheus
itself
handles
the
data.
I
think
we
discussed
that
briefly.
Can
we
use
this
forum
to
see
if
there
is
interest
in
making
sure
it's
100
percent
compliant
with
how
prometheus
does
does
the
scrapes
and
exposition
or.
E
Sure
so
well,
this
is
certainly
since
there's
nothing
else
to
be
discussed
here.
I
think
we
can
use
this
form,
but
there's
also
a
prometheus,
open,
telemetry
work
group.
That's
specifically
formed
to
ensure
that
the
the
data
models
are
interoperable
and
that
we're
doing
the
correct
thing
at
the
points
where
we're
translating
between
them
that
meets
the
hour
before
this
wednesdays
at
8,
pacific
11
eastern.
E
So
that
would
also
be
an
appropriate
place
to
discuss
that
we
have
some
people
from
the
prometheus
project
involved
in
in
those
meetings.
Do
you
have
a
specific
issue
or
yeah.
H
Yeah,
the
the
primary
issue
is
that,
at
least
in
the
collector
pipeline,
in
many
places
we
sanitize
a
single
underscore
prefix,
whereas
the
prometheus
line
protocol
only
reserves,
two
underscores
a
single
underscore-
is
still
valid
and
their
sanitization
logic
on
the
prometheus
report
doesn't
do
the
key
underscore
replacement
on
the
label
keys.
So
we
are
not
able
to
do
a
one
one
to
one
swap
to
move
to
open
telemetry
collector,
where
we
were
using
prometheus
and
scrape
square,
and
we
were
scraping
something
that
had
an
underscore
in
in
the
prefix.
E
Correct
and
there's
a
pr
open
to
add
a
feature
flag
too,
and
to
remove
that
that
standardization,
so
the
the
problem
I
had
with
removing
it
directly
was
that
nobody
working
on
the
project
currently
has
an
understanding
of
why
it
was
added
in
the
first
place
and
and
if
it
was
important,
and
so
I'm
reluctant
to
simply
remove
it
without
having
a
solid
understanding.
E
So
if
we
can
get
that
pr
landed
to
add
a
feature
flag
to
disable,
it
get
some
experience
running
without
that
sanitization,
then
we
can
hopefully
get
some
more
confidence
that
it
can
actually
be
safely
removed.
I've
discussed
this
with
the
prometheus
folks
in
the
prometheus
work
group
and
they
agree
that
there
should
not
be
a
need
to
sanitize
those
labels.
But
if.
A
E
Yeah
an
issue
that
was
coming
up
from
something
that
wasn't
simply
the
prometheus
to
prometheus
pipeline,
but
say
there
was
no
tlp
to
prometheus
issue
that
was
caused
by
this
or
the
other
way
around
we
may
need
to.
There
may
still
be
a
reason
for
it
that
we
don't
yet
know.
Okay,
that
makes.
H
Sense
that
makes
sense.
My
my
subsequent
question,
which
I
want
to
bring
up,
is
the
same
issue,
is
seen
on
the
prometheus,
the
prometheus
exporter
and
the
prometheus
receiver
as
well.
So
once
we
get
this
in,
would
it
be
possible
to
extend
the
same
feature
flag
across
the
prometheus
components
that
that
that
we
have.
E
The
feature
flag
that's
listed
in
the
pr
currently
would
be
specific
to
the
prw
exporter.
If
this
is
something
that
that
does
need
to
be
applied
globally,
we
should
take
a
step
back
and
look
at
whether
we
should
define
a
more
appropriate
name
for
that
feature
flag
or
consider
whether
there
should
be
three
separate
feature
flags.
E
I
don't
I
don't
know
what
the
best
way
to
handle
that
is
for
a
cross-cutting
feature
that
maybe
should
be
implemented
in
some
places.
Maybe
not.
It
seems
like
it's
probably
a
thing
that
should
be
all
on
or
all
off,
I'm
interested
in.
If
anybody
else
has
any
thoughts
on
that
matter,
though,.
I
I
don't
know
if
I
mean
a
feature
flag
is
fine.
If
we're
not
certain
about
it,
I
feel
like
there
must
be
a
github
comment
or
something
somewhere
that
we
just
need
to
dig
up
to
figure
out
why
it
was
done,
and
then
we
can
feel
good
about
removing
it.
But
if,
if
we've
tried
and
can't
find
it,
then
I'm
fine
having
one
global
feature
flag
to
to
do
this.
I
think
that's.
H
Reasonable
right,
at
least
in
my
explorations,
what
I
could
find
is
that
this
was
something
that
was
inherited
from
open
senses.
So
that's
that's
as
far
as
sacred
I
could.
I
could
get
and
the
same
method
is
copy
pasted
across
several
processors,
both
prometheus
and
non-prometheus,
like
span
matrix
processor,
also
copy
paste,
the
same
sanitized
processor.
So
it's
really
difficult
to
identify
where
it's
actually
needed
versus
where
it's
not.
E
Okay,
yeah.
I
think
we
can
continue
discussion
of
this
on
the
pr
then
for
this,
and
if
there
are
further
prometheus
data
model
or
interrupt
specific
questions,
the
prometheus
work
group
that
meets
right
before
this
is
probably
the
the
best
place
to
go
for
that,
as
we'll
also
have
some
folks
from
that
prometheus
project
that
we
can
talk
to
about
the
issues.