►
From YouTube: 2021-09-08 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
C
I
think
the
sound
quality
is
pretty
good,
but.
C
D
C
C
Okay,
let's
get
started,
I
think
again
in
the
agenda
items
that
I
had
noted
just
a
couple
of
things,
but
just
also
wanted
to
ask
if
anybody
else
had
any
questions
or
wanted
to
bring
up
any
issues.
C
First
of
all,
the
collector
update
in
terms
of
you
know
all
the
pending
pr's
and,
as
you
know,
there's
been
work
in
progress
anthony.
Did
you
want
to
give
a
quick
update
on
the
builds?
Are
we
targeting
a
release
today
for
collector
core.
A
I
think
that's
the
topic
we're
going
to
discuss
in
the
next
hour.
I
think
tigran
or
bogdan
had
some
questions
regarding
the
approach
that
I
took
to
dealing
with
the
panda
empty
for
array,
values
in
p
data
that
he
wanted
to
run
by
tigran.
So
if
taken's,
okay
with
it
we'll
get
that
closed
out.
If
not,
then
I
don't
know
how
long
it's
going
to
take
to
resolve
that.
C
Also
right
so
I
mean
again,
this
is
all
backlogging
all
the
pr's
that
are
being
merged
into
the
collector,
and
at
this
point
I
think
that
that
dependency,
I
guess,
has
gone
away,
because
we
have
actually
moved
all
the
components
that
were
sitting
in
core
into
contrib
and
at
this
point
again
folks
can
start
reviewing
for
sure,
right
and
and
and
again
we'll
pick
up
on
the
backlog
for
all
the
pr's
that
are
waiting
for
the
prometheus.
You
know
changes
that
we've
been
making.
C
I
think
that
said
david,
your
pr's
got,
did
get
merged
for
the
stillness
marker
improvements
and
again
it's
just
been
slow.
So
that
was
just
the
update
that
I
wanted
to
make
sure
everybody
had,
if
you're
wondering
why
your
pr
hasn't
been
finished.
Yet,
on
the
collector's
side,.
C
All
right,
so
that's
that
that
was
what
I
had
just
wanted
to
give
a
quick
update.
Josh
you
had
the
next
topic,
otlp
version
10
was
released
last
night.
I
saw
that
right.
E
Yeah,
so
I
released
otlp
v0.10
yesterday,
as
discussed
in
the
previous
meeting
last
week.
Just
a
minor
note.
This
only
change
there
for
metrics
is
this
new,
explicit,
stillness
marker
flag
that
lets
us
use
protocol
support
instead
of
the
nand
value.
E
I
don't
think
it
changes
functional
behavior
for
anything
in
the
prometheus
exporter,
since
there
were
man,
values
were
being
used
and
that's
acceptable,
but
this
will
be
better.
I
think
in
the
future-
and
my
hope
is
that
vendors
who
are
based
on
otlp,
such
as
lightstep,
will
begin
to
recognize
gaps
in
a
more
formal
way,
but
that's
mostly
not
for
prometheus
they've,
already
got
gaps
and
that's
great.
E
Okay,
so
so
to
correct
just
to
clarify
david.
There
are
two
different
kinds
of
men
here
and
you
should
respect
the
existing
man,
which
is
a
true
man
and
the
other
nan
is
now
a
stillness
marker.
In
theory,
the
other
man
being
the
prometheus
staleness
man-
and
this
reminds
me-
I
don't
know
exactly
what
our
otlp
spec
says
for
nan
values.
E
D
A
Yeah,
I
think
p
data
in
the
collector
is
going
to
need
to
be
updated
to
point
10
and
we'll
need
to
add
an
ability
to
set
this
flag
in
in
p
data
metrics,
and
then
I
would
expect
that
the
prometheus
receiver
will
set
that
flag
when
it
receives
the
stay
on
this
man
marker
and
the
prometheus
and
permits
from
upright
exporters
will
look
for
that
flag
and
set
on
their
output
and
then
the
stainless
men
as
appropriate
and
other
exporters.
I
imagine,
will
largely
ignore
it.
E
E
F
E
Yeah
we're
referring
to
this
the
sum
of
a
histogram,
I'm
not
sure
how
the
current
team
has
done.
This.
E
It
has
a
combined
histogram
data
point
and
so
we're
trying
to
talk
about
how
to
represent
the
stillness
in
otlp
it'll,
get
converted
back
to
the
prometheus
remote
right
protocol
either
way.
It's
just
a
question
of
how
we
represent
the
intermediate
state.
C
D
D
E
Okay,
okay,
I
will
I
will
track
the
issue
to
add
p
data
support.
It's
not
very
hard.
I
know
how
to
do.
It
sounds
like
it's
not
urgent
for
anyone,
but.
E
That
makes
sense
so
after
the
next
collector
release
that
people
are
happy
with,
we
should
start
by
sending
a
pdf
pr
to
update.
F
F
E
C
C
E
Okay,
I'll
I'll
mix
out
my
ai
file
and
issue
to
update
collector
p
data
with
visa
printing
feature.
C
C
Good
good,
thank
you
all
right,
so
I
think
that
the
other
topics
that
folks
had
at
least
on
paper
here
is
prs
from
approvers.
So
if
you're,
pending
review
and
you're
blocked
grace,
I
know
your
your
pr
has
definitely
not
been
merged,
so
I'll.
Make
sure
that
you
know
those
start
rolling
in
you
know,
especially
for
the
changes.
Even
there
are
a
bunch
more
that
are
blocked
actually
from
some
of
the
work.
Emanuel
has
been
doing
and
also
some
of
the
changes.
You
know
again,
david
really
appreciate.
C
You
know
the
prs
you've
been
working
on
and
filing
because
I
think
they
do
have
a
more
simple,
simplified
implementation,
which
is
which
is
quite
cool.
I
think
emmanuel
had
filed
his
pr
and
then
you
filed
a
better
implementation,
and
then
I
think
you
took
the
tests.
Also
right,
you
could
reuse
the
tests.
D
Yeah
so
I
kept
the
existing
tests
to
at
least
show
that
there
wasn't
a
regression.
D
C
Anything
missing
just
you
know,
please,
please
add
them.
Okay,.
C
It
should
be
now
because
vishwa
all
these
prs
are
now
on
contrib
right,
because
the
prometheus
components
have
moved
to
can
trip.
So
I'm
wondering
if
you
have
to
refile
resubmit
the
pr.
C
Oh
it
is,
it
is
yeah,
you're
right,
sorry,
so
yeah,
I
don't
see
an
issue
at
all
at
this
point,
I'll
I'll
bring
that
up
as
we
build
the
next
release,
there's
a
whole
bunch
of
items
that
are
in
flight,
but
the
good
news
is
that
you
know
tracing
stability
at
least
in
the
core
is
now
there
with
the
p
data
changes
complete
that
should
you
know
there
are
only
a
couple
of
pr's
that
bogdan
is
reviewing
right
now
and
then
we
should
be
ready
to
cut
a
release.
C
Yeah
david's
pr
did
get
merged.
Yes,
I
think
it's
been
totally
bandwidth
driven
in
terms
of
just
availability
and
that's
also
one
of
the
other
reasons
that
I'd
request
more
folks
to
actually
get
more
involved
in
the
collector,
because
it's
a
great
way
to
you
know,
become
an
approver
and
then
also
help
maintain
it
right.
Yeah.
G
Yeah
so
so
one
other
question:
I
have
on
the
stainless
marker
right.
So
after
36
release,
once
we
move
to
you
know
yeah,
you
shouldn't
break
anything.
You
shouldn't
break
the
existing
sales
market,
but
we
will.
We
will
move
to
the
protocol
representation
to
actually
represent
the
same
right,
and
that
requires
change
in
the
receiver
and
the
exporter.
A
A
It
back,
but
that
that
solves
a
problem
that
other
exporters
are
having,
where
users
are
using
the
prometheus
receiver
and
attempting
to
export
through
a
non-prometheus
exporter
to
a
system
that
doesn't
handle
nands,
and
so
some
of
the
other
exporters
have
had
to
handle,
add
explicit
checks
for
dropping
nand
values.
Whereas
if
it's
in
the
proto,
they
can
simply
ignore
metrics
that
don't
have
that
set
yeah
they're
that
they're
that
have
that
bit
set.
C
Yeah,
that's
a
very
good
point,
anthony
and-
and
I
think
maybe
we
should
have
explicit
issues
also
related
to
that
for
the
receiver
and
exporter.
Because
again,
I
think
that
this
is
towards
the
migration
that
the
collector
has
been
doing
by
removing
the
dependency
to
use
the
prometheus
receiver
for
every
kind
of
injection
so
josh.
I
think
this
aligns
well
with
the
larger
goal
of
using
the
go
sdk.
Also.
E
C
A
The
go
sdk,
we
released
a
1.0
rc3
on
friday.
We
are
currently
trying
to
update
the
contrib
repository
for
the
the
metrics
changes.
Josh
and
I
are
talking
to
the
box
and
about
that
right
now.
Excuse
me,
and
we
hope
that
this
will
be
the
last
rc
that
we
release
before
we
ship
a
1.0.
There
will
only
be
four
traces.
The
the
metrics
api
and
sdk
are
still
experimental
and
will
remain.
A
I
think
point
23
was
the
latest
release
of
those,
so
metrics
is
going
to
be
experimental
until
the
api
is
more
solidified
in
in
the
spec,
and
we've
got
an
implementation
of
the
stable
spec
api.
C
A
Probably
the
week
after
I
think,
we've
said
we
would
want
two
weeks
between
the
rc
and
declaring
a
1.0
release
for
for
a
bacon
time.
We've
had
one
report
of
a
significant
issue
that
we've
addressed
well,
we
could
appear
to
address
it,
but
it
was
not
api
impacting
so
we
should
be
fine
if
that's
the
worst.
That
happens.
C
I
other
than
that
did
we
have
any
other
issues
that
were.
C
C
I
think
the
wall-
pr
that
was
that's,
still
open,
that's
something
that
I
think
their
prs
and
flight
david.
I
think
your
comments
have
been
incorporated
by
menu
so.
C
We
are
working
on
so
right
after
you
know,
the
collector
trace
goes
trace,
stable,
then,
after
that
we'll
pivot,
and
make
sure
that
the
prometheus
components
that
are
in
flight
are
all
completed
and,
of
course,
metrics
work
on
the
collector.
You
pick
up
steel
on
that.
A
A
C
D
C
D
No,
there
is
a
pr
that
a
manual
has
opened
to
allow
specifying
a
file
containing
a
prometheus
config.
Instead
of
embedding
the
prometheus
config
in
the
collector
config.
C
D
It
the
code
changes,
look
fine,
but
I'm
curious
what
bogdan
and
tigran
have
to
say
about
it.
So
we'll
see
where
that
goes,
but
that's
something
minor.
That's
probably.
C
C
D
That's
good,
I
think
I
know
that
they've
been
doing
a
lot
of
work
on
configuration
and
I
think
there
was
some
other
proposal
out
for
having
collector
config
generally
be
piecemeal,
but
maybe
I'm
misremembering,
but
mostly
I
want
to
see
if
this
aligns
with
the
other
config
work,
that's
going
on,
which
I
unfortunately
haven't
been
tracking.
A
C
I
think
there
was
one
more
item
that
I
wanted
to
bring
up,
which
is
the
requirements
for
the
prometheus
receiver
tests,
which
I
think
you
had
brought
this
up
earlier
and
we
had
started
a
dock
that
richard
had
actually
started
to
note
that
did
you
have
a
chance
to
add
more
details
on
that.
G
I
have
a
list
of
things
I
actually
harvested
quite
a
bit
of
them
from
the
bugs
that
we
had.
Let
me
update
it.
Let
me
update
it
today.
Let
me
update
that
document
today.
C
G
C
Any
other
questions
comments
richard
or.
B
C
Okay,
cool,
I
think
thanks
everyone
and
again,
as
you
know,
the
collector
releases
come
out.
Please
take
some
time
to
test
with
the
new
releases.