►
From YouTube: 2020-12-18 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).
B
Oh,
it
looks
like
it's
just
us
two
wow
all
right
light
day.
B
I
have
no
idea
how
popular
the
speeding
is
going
to
be
today,
given
the
time
frame
yeah,
but.
B
B
B
Yeah
I
mean
I
guess,
while
we
wait
for
people
to
come
in,
I
can
obviously
just
ask
you
like
if
you're
interested,
I
was
looking
at
the
your
commit
history
and
all
that
stuff
to
the
repo.
Like
you
you're
well
above,
I
think
the
minimum
to
become
a
an
approver,
and
I
know
we
had
talked
about
it.
B
I
just
assumed
that,
like
you,
you
needed
some
time
or
something
like
that,
but
I
think
you
were
ready
when
we
initially
talked,
but
if
you're
interested
I'd
like
to
yeah,
propose
you
and
then
see
if
we
can
get
anthony
to
sign
off
on
it
as
well,
which
I
don't
think
you
have
a
problem
with
cool.
B
Okay,
yeah,
I
really
value
the
work
that
you
do.
I
appreciate
all
the
reviews
and
all
that
kind
of
stuff,
so
yeah
super
excited
cool.
B
Yeah
definitely,
I
was
noticing
also
like
yeah.
We
can
just
kind
of
maybe
jump
in
a
little
bit
on
the
versioning
dock.
You
had
said
that
like
okay,
so
like
your
response,
was
that
like
it
is
something
of
more
of
a
global
issue,
I
think
was
the
the
takeaway
from
specifying
what
a
stable
instrumentation
actually
can
or
can't
entail
rate
yeah?
Okay,
I
so
I'm
kind
of
wondering
like
what
do
you
think
we
should
do
in
our
versioning
doc?
B
Should
we
just
try
to
not
include
that
or
or
I
mean
I
guess,
we
could
just
wait
merging
this
until
the
other
one
merges.
B
Oh,
let's
see.
B
A
A
B
B
C
B
A
B
It's
on
repos
that
you
have
some
access
to
that's
a
I.
I
don't
know
that
one's
a
tough
one
I
cuz.
I
wasn't
able
to
do
that
for
the
longest
time,
the
specification
one
and
then
I
became
a
metrics
approver,
and
then
it
wasn't
a
problem.
B
B
B
Oh
wow
cool:
this
could
be
like
one
of
the
shortest
meetings
possible.
Resolving
things.
C
C
Hi
josh,
I
have
briefly
have
a
child
with
me,
but
she
is
only
going
to
be
here
a
few
minutes.
Does
she
write
any
good
go
code?
You
write
go
code
no.
B
Well,
hopefully,
she
can
just
be
a
good
cheerleader.
We
need
a
few
of
those
as
well
yeah
yeah.
There
wasn't
too
much
to
actually
talk
about.
It's
just
been
david
and
me
hanging
out,
and
I
was
asking
david
if
he
wanted
to
become
an
approver
and
he
begrudgingly
accepted
not
so
pretty
excited
about
that
yeah,
I'm
going
to
put
a
pr
in
afterwards
and
hopefully
we'll
get
ratified
with
anthony
going
on
here
I
was
hoping
he
would
show
up,
but
I'll
just
pick
him
async.
B
We
resolved
a
few
things
in
the
versioning
dock
or
one
thing
in
the
versioning
dock,
and
then
the
only
other
thing
that
I
wanted
to
like
kind
of
address
was
the
circle
ci
stuff.
It
looks
like
the
github
actions
is
working
perfectly
fine,
so
it
might
be
time
to
just
kind
of
like
remove
the
circle
ci
stuff,
but
super
minor
miniature
miniature
minutiae
things
to
address.
I
didn't
know
if
like
if
you
guys
have
specific
pr's
you
wanted
to
go
into.
B
I
am
I,
as
always
like,
woefully
behind
on
reviewing
prs
relic
has
been
asking
me
to
do
a
lot
of
internal
things.
For
the
past
week,
so
I'm
trying
my
spare
time
to
make
sure
some
reviews
get
done,
but
it's
slow
going
so
yeah.
If
we
wanted
to
go
over
something
specifically
here,
we
have
plenty
of
time
to
kind
of
talk
through
it.
If
you
guys
had
any
questions
or
wanted
to
just
review
things.
C
I
have
to
say
I
would
love
to
spend
some
time
writing
something
for
the
metrics
our
next
next
hour,
but
and
maybe,
if
we
don't
need
to
meet,
we
don't
need
to
meet.
Although
this
also
is
an
opportunity
for
the
three
of
us
to
have
a
small
group
discussion,
if
anything
about
metrics
was
worth
discussing,
I
don't
really
want
to
talk
about
that
combined
push-pull
controller
thing,
I've
been,
but
I
have
this
topic
on
my
mind.
That's
like
right
now
about
that.
I
think
david.
C
You
have
a
useful
position
on
about
mixing
label
dimensions
and
whether
version
compatibility
requirements
cover
which
metric
dimensions
we
are
using,
and
this
topic
expands
into
so
many
directions
that
it's
like
causing
exhaustion
for
me
at
this
point,
and
I've
been
having
a
number
of
debates
with
my
own
like
data
platform
team
here
who
are
ex-monarch
people,
and
so
it's
like
I,
I
I'm
having
an
interesting
time
of
it.
I'd
love
to
hear
if
any
thoughts
of
yours
about
what
happens
when
we
mix
label
dimensions.
C
Dimensions,
I
think
I
I
feel
like
it
was
something
you
said
in
the
past,
so
I'm
using
the
wrong
terminology
at
the
moment,
but
I'm
talking
about
how,
in
our
semantic
convention
documents,
we
might
say
that
you
have
a
host
metric
host,
cpu
time
or
host
heap
memory
host
memory
with
state
labels.
So
you
have
a
state
label
for
in
use
for
your
memory,
but
what?
If
somebody
came
up
with
another
label
they
wanted
to
put
on
their
memory.
C
If
this
medic
convention
says
it's
got
one
dimension,
it's
only
got
one
dimension,
but
that
so
I
think
I'm
not
sure
what
open
sense
is
truly
believed.
In
this
regard.
I
know
that
there
was
statements
about
making
views
that
could
configure
metrics,
but
I'm
not
sure
anyone
ever
talked
into
open
census
times
about
potentially
supporting
instrumentation
packages.
That
could
vary.
C
The
number
of
label
dimensions
that
they
use
and
I
know
it's
kind
of
a
clash
of
the
worlds
here,
because
prometheus
was
very
restrictive
on
terms
of
what
label
dimensions
you
might
use
and
statsd
was
never
so
that
you
might
find
yourself
just
adding
labels
to
a
counter
because
it's
expressed
as
a
delta.
It's
almost
like
not
a
there's
like
no
problem,
adding
more
labels
on
deltas,
but
as
soon
as
you
talk
about
cumulatives,
adding
labels
means
something
in
a
way
that
I've
only
recently
become
started
to
appreciate,
and
so
I
don't.
C
I
don't
know
whether
we
should
resolve
this
by
declaring
that
you
may
never
change
your
label
dimensions
or
whether
we
should
solve
this
by
an
algorithm
essentially-
and
I
think
we
kind
of
do-
have
an
algorithm,
but
it's
been
poorly
stated
or
it
needs
to
be
written
up,
which
is
what
I
was
going
to
do
with
next
for
50
minutes.
If
we,
if
we
have
nothing
else
to
discuss.
A
Yeah,
I
mean
actually,
I
forget
who
it
was,
but
someone
brought
up
the
point
that
with
processors
you
can
always
get
rid
of
labels
and
that
that
seems
like
a
pretty
viable
solution.
So
if
it's
like,
if
we
do
want,
if
we
know
that
some
metric
is
really
widely
used
and
we
want
to
make
a
change-
adds
a
label,
we
can
always
put
out
sort
of
a
bridge
and
just
leave
it
in
its
own
package
and
say
yeah.
Here's
the
bridge,
you
want
the
old
behavior
there
you
go.
C
Yeah
and
that
bridge
I'm
thinking
of,
is
that's
a
great
way
of
thinking
of
it.
I've
also
been
thinking
about
how
to
do
it
in
the
collector,
and
I
realized
now
that
there
are
two
there's.
A
difference
like
implementing
this
in
the
sdk
is
sort
of
a
special
case
where
it's
much
easier
but
implementing
it
in
the
collector
actually
requires
us
to
get
a
little
bit
like.
We
haven't
specified
really
the
semantics
of
these
cumulative
points
when
the
time
series
timestamps
overlap
and
and
there's
certain
problems
that
might
ensue.
C
So,
if
you
delete,
I
mean
we've
introduced
this
notion
of
a
resource
in
otlp
that
prometheus
doesn't
quite
have.
So
if
I
want
to
export
some
some
metric
into
prometheus-
and
I
literally
ignore
all
my
resource
labels,
but
I
but
I
have
a
start
time
and
like
now,
I
have
a
collector,
that's
aggregating,
all
this
together
by
dropping,
like
whatever
resource
labels.
C
There
were
I'm
going
to
end
up
with
these
time,
points
that
overlap
by
their
time,
their
start
time
and
their
current
time
and
that,
I
think,
is
kind
of
meaningless,
like
you've,
just
you've
kind
of
destroyed
the
data
where
what
semantically,
I
think,
what
would
be
intended
would
be
that
you
have
these
points
that
get
sums
together.
Either
they
overlap
or
they
get
windowed
a
line.
They
get
aligned
and
then
sums
together
to
produce
a
new
type
of
is
the
sum
actually,
and
I
think
we
can
do
that.
C
C
So
actually,
I
haven't
said
the
other
half
of
my
argument
here,
but
this
has
some
observer
type
that
we've
created,
which
maps
into
a
cumulative
in
in
even
a
prometheus
model
or
the
up
down
some
observer
that
we
have
that
maps
into
this
new
thing
we
have,
which,
which
is
I
nmcs,
not
monotonic,
cumulative
thumb.
These
are.
C
I
feel
that
the
semantics
we've
prescribed
in
hotel
is
that,
if
you
want
to
add
labels
on
those
instruments,
now
there's
a
problem
because
you
might
have
one
process
outputting,
one
dimension
and
another
process,
outputting
two
dimensions,
and
the
intention
was
that
the
sum
is
preserved.
So
if
you
have
one
person
could
have
a
state
label
with
one
dimension
they're
going
to
have
like
you
know,
higher
averages
where,
whereas
the
the
other
person
has
you
know
more
more
time,
series
that
add
up
to
the
same
sum,
but
have
more
label
dimensions.
C
So
you
could
have
like
in
use
memory
and
the
variety
like
if
it's
storage,
you've
got
ssd
and
you've
got
disk
right.
So
that
the
to
me,
I
think,
the
correct
transformation.
C
If
you
want
to
output
a
cumulative
is
to
do
this
correct,
summation
and
create
a
new
timestamp
and
essentially
output
a
new
series,
and
it
requires
that
we
do
alignment
and
summation
and
so
on,
but
it's
only
it's
special
for
those,
some
observer
and
up
down
some
observers,
whereas
with
the
sort
of
value
observer
instrument
that
what
I've
also
been
calling
true
gauge.
C
C
There's
no
difference
from
a
delta
perspective
anyway,
so
I
I'm
starting
to
think
about
a
design
for
a
cumulative
transducer
or
something
like
that
that
can
erase
labels
correctly,
but
maybe
we've
gone
too
far,
and
I
and
I
sometimes
I
need
bogdan
to
help
back
me
up
because
like
open
census
is
whatever
we
say,
it
was
like.
It's
like
people
who
are
at
this
point.
C
A
A
C
Yeah
I
I
got.
I
picked
up
from
one
of
the
recent
meetings
that
you
had
worked
in
the
kubernetes
stuff
and
that
and
that
that
told
me
that
you
had
a
prometheus
sort
of
background
thinking
about
metrics
as
well.
C
And
I
I
really
do
care
that
we
have
a
story,
and
I
said
it
in
the
to
the
the
tuesday
meeting
about
like
we
can
talk
again
about
openmetrics
compatibility
and
I
think,
if
we're
going
to
allow,
allow
ourselves
to
design
a
protocol
that
supports
things
that
can't
be
done
in
a
prometheus
model
or
openmetrics
world.
C
We
have
to
both
define
a
valid
translation
into
otlp,
but
also
to
define
a
valid
translation
out
of
otlp
and
to
me
that
means
that
we
have
to
have
this
like
correct
way
to
erase
labels
if
we're
going
to
really
support,
otl
hotel
and
hotel
design-
and
that's
not
so
hard.
But
it
does
mean
that,
like
you,
you
might
have
a
configuration
in
the
collector
somewhere
that
says
as
we
as
we
are
now
about
to
export
to
openmetrics.
C
We
are
going
to
erase
all
but
the
following
dimensions
from
these
groups
of
metric
instruments
so
that
that
would
be
essentially
the
view
you
need
a
view
before
you
can
output
some
open
metrics
in
a
world
where
you
have
these
mixed
labels
on
cumulatives.
A
If,
if
you
scrape
multiple
things
that
have
the
same
set
of
labels
with
the
prometheus
receiver
and
then
try
and
send
it
to
a
prometheus
exporter,
you
only
get
one
of
the
targets
right.
This
is
the.
C
Problem
yeah:
this
is
the
problem
I
mentioned
earlier
with
cumulatives
colliding
that
overlap.
Yes,
okay,
to
do
a
correct
export.
We
need
this
imaginary
pipeline
stage
that
I'm
I've
got
an
algorithm
written
down.
I
want
to
put
it
into
a
public
issue
essentially
to
solve
this
problem.
Okay,
cool
glad
to
see
this.
Thank
you.
This
is
useful.
C
C
I
with
that,
unless
anyone
else
wants
to
talk
about
stuff,
I
I
just
learned
something
wonderful
and
also
feel
like.
I
know
you
better
david,
I'm
glad
to
hear
that
you
will
become
an
approver.
So
thank
you.
C
C
It's
that
the
way
across
hotel.
I
honestly
I
I
ca
every
time
I
finally
get
myself
a
work
block
to
just
choose
what
I'm
going
to
do
as
opposed
to
being
reactive
to
stuff.
That
white
steps
interrupting
me
with
like
last
week,
I
chose
to
catch
up
on,
go
reviews,
but
I'm
really
behind
on
other
stuff
and.
A
C
B
For
giving
give
me
some
advice
there,
david
don't
become
a
maintainer
stick
at
that
approver
level.
Yeah.
B
Yeah,
of
course,
but
yeah
josh,
I
don't
think
I
have
anything
else
so
yeah.
We
can
see
you
all
later
soon.
Thanks
have
a
good.