►
From YouTube: 2022-02-02 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
Sorry,
I
think
my
my
systems
were
listening
to
me.
A
C
C
A
A
It's
how
to
be
more
conversational,
so
all
right.
So
I
think
that
david,
you
had
entered
a
couple
of
things
and
I
was
hoping
that
anthony
could
have
also
joined
but
just
wanted
to
kind
of
cover,
at
least
on
my
agenda.
We
had
let
me
pull
up
our
meeting
notes.
A
I
had
a
couple
of
topics
that
I
wanted
to
just
you
know,
touch
base
on
and
I'm
not
sure
if
you
have
any
or
mishra.
Let
me
see.
Let
me
pull
up
my
full
of
our
agenda
items.
D
A
A
A
And
david,
I
know
you
had
actually
been,
you
know,
had
started
some
of
the
changes
for
the
prometheus
spec
update.
B
A
Updates,
do
you
have
a
link
to
that?
I
can
find
it
in
my
browser
and
just
let
me.
A
A
David
you're
you're
lagging
in
this
is.
B
Okay,
I
wanted
to
call
out
two
things
that
we
found
during
the
spec
update
process.
One
is
that
the
process
start
process
start
timestamp
seconds
shouldn't
be
used
to
set
the
start
time
of
prometheus
metrics.
I
wanted
to
call
that
out
here,
since
I
know
that
there
are
a
lot
of,
or
at
least
some
users
of
the
prometheus
receiver
that
attend
this
call.
B
The
rationale
for
it
is
in
the
issue
and
if
you
are
using
it
and
think
that
this
would
break
your
use
case,
then
we'd
love
to
hear
about
it
before
we
remove
it.
It'll
probably
be
deprecated
with
a
feature
flag,
so
there'll
be
other
opportunities
to
sort
of.
Let
us
know
what
your
use
cases
are
and
make
sure
that
we
can
meet
those
correctly.
B
But
that's
that's
the
plan
for
now,
because
it's
not
it
doesn't
make
sense
from
a
prometheus
perspective
to
use
the
process
start
time
as
the
start
time
of
a
metric.
In
most
cases.
A
So
david,
what
are
the
use
cases
that,
specifically,
I
mean,
have
you
seen
any
usage
usage
where
that's
being
used?
Is
it
in
the
code
or
is
it
just
downstream
the
way
that
the
you
know
time
series
is
being
processed.
E
B
Let
me
remember
which
brian
pointed
out,
and
so
I've
tried
to
capture
that
discussion,
but
I
just
want
to
make
sure
again
that
we
don't
break
people,
so
there'll
probably
be
a
deprecation
period
as
well,
during
which
people
can
state
their
use
cases,
and
hopefully
we
can
help
them
work
around
it.
Yeah.
C
B
B
The
second
thing
that
came
up
is
perhaps
a
data
model
question,
but
basically
from
my
understanding,
and
maybe
the
maybe
brian
or
any
of
the
other
prometheus
folks
on
the
call
can
correct
me
unknowns
or
prometheus
metrics
in
general,
but
unknowns
in
particular
are
expected
to
be
interpreted
as
basically
any
type.
B
B
So
the
issue
from
this
is
something
that's
come
up
with
some
of
the
way
people
have
been
using
the
collector
at
google,
which
is
that
sometimes
people
send
metrics
that
should
be
interpreted
as
cumulatives
as
unknowns
and
currently
in
the
receiver,
we're
converting
those
to
a
gauge
which
in
most
cases,
seems
to
be
correct.
But
basically
I'm
wondering
if
either
one
we
need
to
preserve
the
notion
that
it
was
unknown
to
allow
people
to
interpret
it
as
a
different
metric
type
in
the
future
or
two.
B
B
A
David,
I
think
we've
also
seen
that
problem
and
I
think
let
me
dig
up
the
bug.
I
think
we
reported
it
also,
but
we
do
need
to
figure
out
if
this
isn't
shortcoming
of
the
data
model.
Because
again,
what
is
being
emitted
from
the
for
the
prometheus
exposition
format
from
source
is
not
not
an
issue.
I
mean
we
validated
that.
C
So
your
proposal
is
to
leave
it.
Don't
don't
assume
it's
it's
a
gauge
right
yeah,
but
then
that
means
they'll
be
interesting.
The
metric
assets,
which
is
the
same
as
the
case.
B
A
B
D
B
B
The
flag
sounds
worse
than
adding
unknown
as
a
metric
type,
only
in
the
sense
that,
if
we're
going
to
make
a
change
to
the
data
model,
anyways
the
having
an
unknown
type
explicitly
seems
better.
But
I
do
like
having
an
attribute
or
something
to
identify
it.
It
feels
kind
of
similar
to
how
we're
reconstructing
job
and
instance,
is
we're
just
taking
all
the
data.
We
don't
know
how
to
preserve
today
and
putting
it
somewhere
where
we
know
to
look
so
that
at
least
potentially
would
be
a
viable,
short-term
solution
that
wouldn't
require
data
model
changes.
D
Yeah,
I
think
that
would
be
my
initial
inclination
as
well.
It
seems
like
it's.
The
easiest
thing
to
do
should
convey
the
information
and
as
long
as
we
have
conventions
for
it,
all
of
the
prometheus,
interacting
components
can
know
what
to
look
for
and
how
to
deal
with
it.
A
Yeah,
that's
a
good
call
out,
though
I
think
I
do
think,
though-
and
I
don't
know
if
this
entry
is
this
issue-
a
result
of
that
inability
on
the
second
iteration.
This
is
another
bug
that
you
know
which
could
be
related,
but
I
don't,
I
don't
think
so.
A
D
Metric
types,
having
seen
the
exposition
that
we're
dealing
with
here,
it
is
being
reported
as
a
counter
in
both
of
them
yeah.
C
D
And
it's
it's
inconsistently
being
treated
as
a
gauge
from
multiple
sources
that
have
the
same
exposition,
but
each
source
gets
treated
consistently.
So
you
know
pod
a
is
always
treated
as
a
gauge
and
pod
b
is
always
treated
as
a
counter,
even
though
they're
exposing
the
same
exposition,
which
is
super
weird.
But
I
don't
think
that
this
is
related
to
those
metrics
being
of
unknown
type.
A
Okay,
I
mean
that's
that's
good
to
understand,
because
I
think
that
we'd
have
to
figure
out
what
I
mean.
They're,
a
favorite
of
data
inconsistencies
being
reported
in
the
I'm
serious,
so
I'll
I'll
collate
the
bugs
that
are
being
reported,
at
least
on
the
on
contrib,
and
then,
let's
take
a
look
at
it
next
time.
D
So
I
think
there
was
one
bug
reported
that
might
be
somewhat
related,
which
is
that
there
was
a
user
who
had
a
metric
family
for
a
histogram
and
a
metric
for
a
counter
or
gauge
that
had
the
same
name
and
an
error
was
being
reported,
I
think
it
was
suggested
that
we
should
treat
the
non-histogram
part
of
that
as
a
non-non-metric
type
and
be
able
to
deal
with
it
separately.
D
D
I
think
that
was
after,
but
people
report
bugs
against
old
versions
all
the
time
so.
E
A
Anthony,
I
also
had
the
wall
pr
did
you
want
to
give
an
update
on
that,
because
I
know
you've
been
taking
a
look
at
it
and
that
was
based
on
the
original.
D
Yeah
so
so
emanuel
had
done
a
bunch
of
work
to
add
a
wall
to
the
remote
right
exporter
and
it's
it's
about
half
implemented
in
the
main
branch
and
he
had
a
pr
to
wire
up
the
rest
of
it,
and
so
I
had
resurrected
that
pr
got
it
dealt
with
all
of
the
merge
conflicts
that
that
happened
and
all
of
that,
but
during
review,
some
questions
were
raised
about
how
some
of
the
concurrency
worked
and
that
caused
me
to
to.
D
I
think
believe
that
it
could
get
into
a
place
where
the
go
routine.
That's
reading
off
of
the
wall
would
be
stopped,
but
nothing
would
start
it
up
again,
and
so
new
data
points
would
come
in
and
continue
to
be
written
to
the
wall,
and
there
would
be
nothing
to
read
off
of
them
until
the
exporter
got
restarted.
D
So
I
need
to
go
back
and
make
sure
that
my
understanding
of
that
is
correct
and
find
a
fix
for
that.
If
I
can,
I
haven't
yet
had
a
chance
to
do
that,
but
that
is
on
my
plate
for
this
week.
A
Okay,
cool,
I
mean
again
david.
I
know
you've
been
reviewing,
so
thank
you
for
for
that,
but
I
think
anthony.
Maybe
we
should
take
a
look
at
it
and
see
if
that's
something
that
we
can
finally
fix.
D
Yeah
yeah,
thank
you,
yeah
sure
I
I
think
it'll
likely
just
be
reviews
again
once
it's
ready.
It's
it's
an
incredibly
subtle
thing.
It
all
looks
correct
until
you
start
walking
backwards
from
the
possible
error
cases
and
say:
okay,
if
if
an
error
happens
here,
what
happens
then?
And
that's
when
I
started
to
be
less
short
about
things.
A
Should
we
also
look
at
again,
I
think
we
addressed
the
next
topic
we
had
was
a
spec
update.
Did
folks
have
a
chance
to
look
at
this
because
I
think
david,
you
had
a
draft
pr
which
is
still
a
draft.
I
think.
B
Yeah,
I
think
both
bogdan
and
josh
approved.
I
don't
I'm
not
familiar
enough
with
the
spec
update
process
to
know
how
many
more
green
check
marks
I
need,
but
I.
A
Mean
the
question
we
had
and
anthony,
and
I
will
also
take
a
crack
at
working.
Adding
some
more
detail
here
is
that
I
think
that
what
we
are
outlining
currently
is
you
know
what
the
what
is
being
done
in
the
code
right
now
right,
I
mean
that's
correct.
The
question,
though,
is
that
what
else
do
we
want
to
address
and
call
out
which
might
be
specific
to
the
you
know
to
the
protocol
itself?
A
That
is
the
openmetrics
prometheus
metric
which
which
you
know
from
an
naming
point
of
view
from
other
conventions.
You
know
anything
else
right
so.
B
A
A
D
B
C
B
I
think
you
can
have
multiple
exemplars
on
a
bucket
in
remote
right,
because
I
was
confused
when
I
was
looking
at
the
collector's
remote
right
implementation
for
the
translation,
because
it
doesn't
like
have
any
of
the
complicated
logic
to
try
and
choose,
which
example
are
for
a
bucket
to
use,
and
that
seems
to
be
because
you're
allowed
to
attach
multiple
in
remote
right,
but
not
in
the
exposition
format,
but
other
than
that.
Everything
else
should
be
the
same,
and
I
think
I
called
that
out.
A
Okay,
so
I
think
the
action
item
here,
though,
is
that
we'll
take
a
look
at
it
and
again
vishwa
and
grace
you
guys
should
also
you
know.
Add
you
just
read
through
at
least
do
a
thumbs
up
and
add,
you
know
again
add
any
comments
where
we
need
to
add
more
I'll.
Also
do
the
same
but
david.
Thank
you
for
at
least
starting
this
process
that
will
at
least
get
the
spec
documented.
A
A
A
A
The
other
change
that
I
just
wanted
to
call
out
before,
I
think-
and
this
is
just
we
will
make
present
a
design
on
this
next
week-
is
that
we're
in
the
process
of
changing
the
sig
v4
implementation
for
the
receive
prometheus,
remote
right
exporter,
which
is
used
by
the
aws
prometheus
remote
right
exporter,
specifically
because
you
know
what,
when
we
had
written
the
initial
remote
right
exporter,
we
kind
of
separated
out
the
core
logic
into
the
into
two
into
a
different
module
and
then
had
a
wrapper
around
that
for
the
6v4
specific
logic
for
signing
into
aws
services
right.
A
So
what
we
are
doing
right
now
is
actually
modularizing
it
so
that
you
know
any
aws.
Specific
exporter
can
actually
use
that
6v4
module
and,
and
so
again
expect.
We
plan
to
walk
through
the
design
next
week,
as
well
as
and
hopefully
an
initial
implementation,
so
just
just
fi
it's
consolidating
and,
and
so
that
will
change
the
way
that
the
remote
right
exporter
is
being
called.
A
That's
all
I
had
anything
else
wish
for
grace
on
your
end,.