►
From YouTube: 2021-02-12 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
A
A
Yeah
yeah:
let's,
let's
kick
it
off;
fortunately,
josh
mcd
can't
make
it
today.
Luckily,
we
have
a
backup
josh.
So.
D
D
Yes,
so
can
we
take
some
time
what's
that
yeah,
so
this.
A
Is
just
my
request?
I
was
looking
at
the
just
looking
at
the
spec
burned
down.
You
know
our
kanban
board
and
noticed
we
hadn't
there's
a
number
of
data
model
issues
that
aren't
on
here.
I
thought
maybe
we
could
just
just
take
a
quick
moment
and
and
just
run
through
them.
Real,
quick
and
just
add
them.
Add
them
to
this
board,
assign
someone
to
them-
or
you
know,
just
make
sure
they're
they're
those
the
issues
that
we
got
or
at
least
just
like
up
to
date.
A
We
don't
have
to
like
necessarily
like
debate
them
all,
but
okay
like
it
would
be
good
to
know,
what's
like
to
do
and
like
what's
what's
in
progress
and
all
that
I
guess
they're
all
probably
to
do.
A
Yeah,
so
I
was
looking
here
so
this
is
our
compound
board.
We
still
got
this
one
issue
and
then,
if
we
go
to
specs
and
you
go
to
issues
and
go
to
label
area
data
model,
then
we've
got
this
set
of
stuff.
A
That
is
the
the
one
kind
of
annoying
thing
about
projects.
As
far
as
I'm
aware,
they're,
not
I'm
sure
you
could
write
a
bot
to
do
some
of
this
stuff,
but
they
by
default
they're
not
automatically.
E
F
A
I
assume
these
issues
are
all
up
to
date,
but
and
the
assignees
are
right.
But
if
you
do
see
something
like
that,
that's
not
correct.
E
For
the
moment,
all
of
them
probably
are
assigned
to
j
macd,
but
let's
first
move
them
to
the
repo
and
then
discuss
about
the
chinese,
make
sense
project.
A
Okay,
okay,
my
filter
is
just
being
silly,
so
this
is
all
of
them.
Then,
okay
and
we've
only
got
one
with
a
linked
pr,
I'll.
E
So
issues
assignee,
okay,
so
I
now.
D
I'm
reading
it
correctly,
he
needs
also
issues
just
checking.
A
One
so,
I
believe,
dropping
the
string
value
labels
moving
labels
to
attributes
has
an
issue.
A
Yeah
yeah,
so
so
we
have
have
an
issue
for
that
one.
I
owe
you
a
an
otep
for
which
is,
I
believe
at
least
one
part
of
this,
which
is
around
the
mapping
like
conversion
from
attributes
to
strings
that
should
be
pretty
straightforward.
A
I'm
not
sure
how
much
work
beyond
that.
Do
you
think
there
is
to
this
this
pr?
It
would
be
pretty
simple:
spec
change.
E
Are
we
comfortable
we
eat
with
eating
the
cost
of
of
some
languages
where
this
will
be
always
new
objects?
Because
of
this.
A
I
don't
know
that
it
would
necessarily
always
be
a
new
object.
Why
would
that
be
the
case?
Just
because
you
can't
create
attributes
in
a
reusable
fashion,
yeah.
H
A
E
And
everything:
okay,
let's
let's,
let's
put
this
as
a
data
model,
I
don't
know
if
it's
marked
as
a
data
model,
this
yeah
it.
A
Is
I'm
I'm
happy
to
take
this
one
if
I'm
just
since
I'm
doing
the
string
conversion,
I
don't
think
it's
that
complicated
of
an
issue
made
the
decision
to
do
it.
D
A
Right,
yeah
and
you're
correct.
I
think
that
was
the
position
riley
wanted
us
to
go
with
was
at
the
api
level
having
it
be
attributes,
but
in
the
data
model
having
it
be
strings
only.
G
E
I
J
Like
it
is
because
we
want
to.
E
To
support
prometheus
and
prometheus
being
string
so
without
making
sure
that
we
can
support
prometheus
100,
we
cannot
do
this
change.
Does
it
make
sense
why
I
think
it's
still
important,
even
though
that
conversion
happens
only
in
the
collector
when
or
only
in
the
prometheus
exporter,
we
still
need
to
have
that
documented.
G
E
No,
I
don't,
I
don't
think
we
decided
that,
but
sure
I
think
we
were.
We
are
considering
doing
that
right.
B
D
D
A
Okay
cool
already,
so
so
that
that
gets
that
one
cleared
up
so
for
these
other
two
yeah
moving
explicit
boundaries
for
fields
for
histograms.
I
don't
actually
have
the
details
about
what
josh
wants.
G
G
I
have
a
question
here,
so
I
talked
with
some
folks
who
are
working
on
like
premises
and
like
micrometer.
So
the
question
here
is:
do
we
try
to
design
the
protocol
that
later,
if
there's
another
algorithm,
which
is
not
histogram,
something
else,
let's
say
like
algorithm
defined
by
aliens?
G
E
G
E
Already
have
all
of
the
things
that
you
mentioned
add
a
new
type
of
aggregation
like
let's
say
d
sketch,
whatever
t
digest
or
something
like
that,
we
can
always
have
that
easily.
Then.
G
G
I
mean,
like
you
got
to
you,
got
to
handle
those
like
dimension
like
what's
the
allowed
value
and
whether
you
want
to
do
the
class
like
the
doncast,
from
whatever
type
to
string
those
things
and
meanwhile
having
having
so
many
different
type
of
aggregations
would
make
things
complex,
probably
just
focus
on
the
the
basic
thing.
Like
me
max
count,
and
then
people
will
have
questions
like
do
you
have
unique
account
or
not.
I
think,
like
people
have
questions,
why.
G
Why
would
histogram
be
a
priority,
but
unique
content
is
not,
and
I
have
no
answer
for
them.
I
think
probably
just
stick
with
the
basic
obvious
thing
that
people
all
agree
about
and
then
treat
like
discount,
like
distinct
account,
histogram
anything
else
as
plugin
we
can
back
later
once
we
have
a
relative
stable
for
the
basic
stuff
that
makes
sense
or.
E
I
think
histograms
are
one
of
the
most
important
things
if
we
talk
about
prometheus,
integrations
and
yeah,
so
I
disagree
with
the
fact
I
agree
with
you
that
we
we
have
a
limited
subset,
which
I
think
we
do
right
now.
We
only
have
gauge,
which
we
kind
of
don't
know
an
unknown
aggregation
or
whatever
we
have
a
sum
aggregation
and
we
have
a
histogram
aggregation.
We
have
only
three
things:
that's
it.
E
We
don't
have
and
yeah
some
some
if
it's
monotonic
is
whatever
people
call
counter.
Otherwise
it's
so
we
do
have
all
of
these
things
and
very
well
defined,
very
extensible,
the
only
problem
with
histogram
and
something
that
you
just
triggered
in
my
mind,
based
on
these
is,
do
we
want
to
have
only
one
histogram
definition
that
has
multiple
types
of
bounds
versus
have
explicit,
histograms,
exponential,
histograms
and
so
on
as
different
types.
E
That's
a
it's
a
great
great
thing
that
I
I
think
we
need
to
discuss,
and
that
may
mean
that
this
pr
is
actually
not
necessary,
not
required,
but
I
would
say
that
that
I
think
we
limited
pretty
well
the
scope.
In
my
opinion,
riley,
okay,.
F
Okay,
the
min
max
field.
Sorry,
I
just
wanted
to
understand
what
you
said.
Did
you
just
say
that
we
need
to
define
the
scope
of
what
that
definition
for
histogram
support
means?
Yes,.
E
G
E
So
so
that's
one
thing
that
we
want
to
park
away,
but
only
one
thing
rightly
that
we
want
to
do
is
decide
if
we
have
to
add
it.
E
Do
we
extend
the
histogram
type
itself
or
is
that
a
different
type
of
aggregation
which
we
I
don't
know
we
can
both?
We
have
an
accessibility
of
the
type
or
we
can
make
it
the
histogram
extensible
so
far,
histogram
is
not
easily
extensible
and
that's
why
the
pr
tries
to
do
to
make
even
histogram
accessible,
but
the
solution
may
be
as
simple
as
you
know
what
we
have
exponential
histogram
and
we
have
explicit
histogram,
and
I
don't
know
we-
we
can
chat
about
that.
E
But
there
are
options,
so
I
think
defining
the
scope
there,
but
the
only
thing
that
we
care
at
this
moment
is
to
make
sure
we
support
only
the
explicit
buckets
histogram
and
that
our
model
supports
adding
extra
definitions.
E
E
I
think
george
knows
has
more
context,
so
maybe
maybe
make
an
action
item
to
jack
mcd
to
to
file
the
issue
or
find
the
issue,
and
we
can
assign
somebody
for
that
for
the
first
one.
For
the
first
thing
you
can
put
my
name
as
the
owner
of
the
entire
histogram
part.
This.
A
K
A
Okay
and
okay,
we'll
bounce
this
back
to
j
macd.
If
he
is
going
on
break,
though
maybe
I'll
see
if
he
can
get
it
done
before
that,
otherwise,
who
who's
the
backup
on
this
one.
E
A
Okay,
so
yeah
for
I'll.
Do
the
string
attribute
conversion,
the
rest
of
the
work
is
being
handled
through
the
api
group.
It
sounds
like
so
maybe
we
can
bring
that
up
there
riley
do
you
know
if
there's
needs
to
be
an
issue
created
for
for
that
part
of
it
or
someone
assigned.
Do
you
want
to
just
wrangle
that
sorry?
I
I'm
trying
to
understand
your
question.
Sorry.
So
for
converting
labels
to
attributes.
A
A
G
E
A
So
we
have
to
decide
whether
we're
keeping
that
strings
for
us
and
just
doing
the
conversion
or
sorry
keeping
that
as
strings.
Are
we
going
multi-value,
multiple
types
for
us
and
just
converting
the
strings
for
prometheus.
E
E
A
E
A
Yeah,
I
think
I
have
just
a
click
on
that
front
of
like
well.
You
technically
could
put
lists
and
maps
there.
There's
a
difference
between
you
could
technically
do
that
versus.
That
is
like
a
meaningful
feature.
A
I
So,
instead
of
like
trying
to
solve
all
of
these,
do
we
have
the
number
of
like
innumerable
issues
that
we
wanted
to
solve
written
down
somewhere?
So
then,
maybe
we
can
have
like
a
better
understanding
of
all
the
problems
associated
with
like
the
string
conversion.
I
know
bogdan
you're,
pretty
you
have
a
lot
of
thoughts
on
this.
You
know
like
you
just
identified
one,
but
I
imagine
there's
a
lot
more
right.
F
H
We
don't
have
an
owner,
that's
what
I'm
identifying.
We
don't
know
who
is
owning
raleigh.
G
I'm
collecting
the
gaps
and
requirements
for
the
api
not
for
this
particularly,
but
I
I
think
the
scenario,
because
when
we
do
the
api,
we
got
to
think
about
the
efficiency
and
that
covers
a
little
bit
sdk,
although
we
try
to
like
have
that
stage
thing,
but
the
scenario
should
also
apply
here
like
when
you
design
the
scenario.
It's
not
specific
about
api
right
yep,
but
then
still
you
have
the
question,
because
the
scenario
wouldn't
ask
you
to
have
accessibility,
those
things,
so
it
won't
cover
the
entire
thing.
G
E
In
this
case,
that's
what's
the
scenario
we
want
to
convert
them
to
string
and
if
we
are
able
to
convert
them
to
string,
we
know
how
to
compare
them.
We
know
how
what
we
can
support
and
what
we
cannot
support.
So
that
was
the
scenario
like
in
this
case,
because
it's
not
a
scenario
like
a
real
world
example,
because
we
are
talking
only
about
the
data
model.
I
think
it's
a
reasonable
scenario
for
this
data
model.
E
We
need
to
be
able
to
convert
this
into
a
flat
string
string
map,
how
we
do
that
and
what
is
the
equivalence
of
what
is
equal
to
whatever
that
will
determine,
and
a
lot
of
questions
will
come
from
there,
because
I
will
ask
then
why
these
two
maps
are
not
equal
or
something
like
that.
We
will
ask
questions
like
that
and
we
will
determine
if
it's
possible
or
not,
and
what
is
missing.
E
So
I
think
that's
what
that's
why
we
are
asking
ted
to
write
the
otep
for
for
string
conversion,
because
there
we
will
have
questions
like
this.
Oh,
but
if
these
two
converse
to
the
same
string,
why
the
heck?
Initially
they
were
not
equivalent
and
because
this
will
break
a
back
end
that
suppose
for
every
key
value
combination.
You
have
only
one
value
reported,
but
now
because
of
this
conversion,
you
have
two:
how
do
you
deal
with
that?
Okay,.
A
A
That's
just
what
would
bogdan
raised
around
not
being
able
to
potentially
use
pointers
or
reusable?
You
know
attribute
sets
essentially,
or
do
we
add
that
concept
of
attribute
sets
but
okay,
let's
let's
move
on
for
this,
I
think
we
got.
We
got
enough
to
tackle
that.
E
E
I
think
we
wrote
down
in
this
meeting
or
somewhere,
but,
yes,
it
is
somewhere.
Okay,.
A
I'll
I'll
check
in
with
j
macd
again
on
this,
but
he
promised
the
metrics
roadmap
document
for
next
week.
I
just
want
to
check
in
with
it
dc.
Remember.
Is
that
something
you
guys
still
have
in
your
calendar
to
create.
A
G
A
A
Okay,
real
quick
diversion
j
macd
was
mentioning
this
time
is,
is
a
little
difficult
for
him,
though
he
can
make
it,
and
it's
super
late
for
europeans,
I
so
just
on
josh's
behalf.
I
want
to
double
check.
Do
are
people
happy
with
this
time
or
would
they
prefer
moving
it?
I
think
this
meeting
now
alternates
between.
L
L
G
L
And
that
sounds
pretty
brutal,
but
yeah
I
mean
we
have
two
hours
of
metrics.
I
E
I
Tuesday
works
for
me
as
well.
I
think
that
was
the
original
proposal
that
I
misread.
So
I
apologize
for
that,
but
yeah.
E
How
about
you
they,
after
spec
after
the
spec
meeting
or
around
that
time,
like
be
european
friendly,
yeah.
I
The
only
thing
is
that
ruby
sig
is
during
9
a.m
to
10
a.m,
but
I
mean
I
don't
I
haven't
seen
too
many
people
from
the
ruby
say
get
this
meeting.
So
I
don't
know
if
there's
an
actual
yeah.
F
I
don't
think
that's
a
conflict.
Okay,
it's
probably
good
to
put
it
right
after
the
spec
meeting.
Would.
A
E
Perfect,
let's
propose
that
and
maybe
circulated
okay,
a
couple
of
people.
I
think.
G
E
No,
we
are
moving
just
the
data
model
meeting
the
api
meeting
it's
thursday
and
right
now
it
alternates
you
have
to
discuss
with
the
people
in
that
meeting.
If
you
want
to
move
it
only
for
11
or
whatever,
but
this
is
discussion
is
just
for
the
mating
related
to
data
model.
F
G
I
G
E
Okay,
great
all
right,
let's
move!
I
made
a
joke
about
road
maps.
I
just
wrote
one
for
the
collector,
so
if
everyone
is
interesting,
please
read
it.
Don't
we
don't
have
to
spend
time
here,
but
it's
it's.
You
can
show
the
the
file
thing,
but
it's.
It
has
couple
of
phases
only
well
defined
the
first
two
phases
and
then
then
a
bunch
of
do
is
to
evaluate
once
we
get
there.
E
A
bunch
of
action
items
issues
needs
to
fix,
everything
is
tracked
and
then
we'll
track
more
into
issues
once
this
is
approved,
but.
A
All
right
moving
on
how
do
we
make
progress
on
converging,
hotel,
metrics,
spec
and
openmetric
spec?
C
So
can
we
do
what
the
senate
and
congress
do
and
they
have
different
bills?
We,
you
know,
do
a
settlement
meeting
and
you
know
take
two
maintenance
from
here
to
maintain
us
from
there
and
do
a
working
team
to
propose
a
converge.
Spec
because,
like
we
did,
that
with
open
sense,
open
tracing
seems
to
have
worked,
I'm
sure
we
can
do
it
again.
E
C
E
E
Yeah,
but
we
need
some
priyanka
is
great,
but
I
I
also
think
we
need
some
of
the
people
who
which
we
had
previously
in
the
room-
sarah's
great
chris,
a
yes,
some
good
names
here.
So
I
think
I
think
we
need
a
couple
of
other
people.
I
mean
definitely
represent
maintenance
from
both
projects,
but
but
we
need
some
some
third-party
people
to
help
not
kind
of.
A
Yeah,
oh,
I
can't
I
don't
I
mean
as
the
person
who
organized
the
last
round
of
this
stuff.
You
know
I'll
reach
out
how
about
this
I'll
reach
out
to
chris
and
sarah
and
talk
to
them
about
helping
to
organize
this.
Since
all
the
projects
we're
talking
about
are
under
the
cmcf.
I
agree.
That's
that's
the
best
avenue
to
go
here.
I
mean
I
do
know
the
prometheus
people.
You
know
richard
hartman,
they're,
they're,
taking
part
in
this.
A
F
I
mean
richard
has
committed
to
actually
joining
in
and
working
on
this
with
us
yeah.
So
I.
C
E
So
mark
I
think
it
will
be
useful
with
only
one
condition
I
think
when
we
went
to
the
meeting
between
open
sensors
or
open
tracing,
we
kind
of
went
with
the
open
mindset
that
we'll
have
to
do
breaking
changes
or
we'll
have
to
to
do
something
that
may
not
feel
good
for
open
tracing
or
for
for
open
sensors,
and
that's
why
we
invented
a
new
thing,
and
we
are
doing
great
on
that.
I
think
I
think
so
far
what
I'm,
what
I've
heard
from
openmetrics
is
my
way
or
or
the
highway.
E
I
Here,
like
we
have
had
these
conversations
before,
like
we've,
had
workshops
with
the
open
metrics
team,
and
I
think
we
actually
have
some
documents
documenting
a
lot
of
this
stuff
and
I
feel
like
a
lot
of
people
on
this
call,
were
involved
in
those
conversations
and
they
included.
You
know
the
distinction
of
the
fact
that,
like
you
know,
there's
separate
goals
for
the
otlp
compared
to
the
openmetrics.
I
I
The
idea
of
having
openmetrics
support,
things
that
are
more
than
just
metrics
was
something
that
was
possible,
but
it
was
something
that
was
like
well,
you
could
also
tack
on
some
other
standards
from
the
cncf
that
also
have
other
protos
that
could
eventually
support
open
tracing
or
some
sort
of
like
tracing
stand,
or
something
like
that,
but
like
open
metrics
is
not
really
looking
to
expand
to
encompass
all
of
the
goals
of
what
the
otlp
is
and
then
it's
also
like
you
know.
It
came
to
the
question
of
like
well.
I
If
that's
that
the
case,
then
maybe
the
otlp
was
supposed
to
be
this
lingua
franca
between,
like
all
open,
telemetry
components
and
openmetrics,
was
something
that
we
were
going
to
support,
and
I
think
that
was
the
conclusion
of
that
statement.
I
I
hear
you
that,
like
customers
are
a
little
bit
confused
as
to
like
which
one
do
you
support,
and
I
think
that
was
something
that
was
a
kind
of
a
open
question
in
that
meeting,
and
I
think
that
the
answer
to
that
was
like
you
know,
whichever
one
makes
sense
to
them
like
if
the
customer
needs
to
eventually
support
ingest
of
tracing
and
log
events
like
the
otlp
is
probably
the
one
that
they
should
be
supporting
and
if
you
know
they're
only
ever
interested
in
the
open
metric
standards
and
that's
the
case
like
there's
always
going
to
be
the
optometric
collector,
which
we've
said
that
we
want
to
provide
that
as
a
compatibility
layer
and
that
you
can
translate
the
open,
telemetry
or
otlp
into
openmetrics,
and
so
there
should
be
some
way
to
actually
make
that
conversion
happen.
I
So,
like
from
a
customer
standpoint
like,
I
think
that
there
is
some
sort
of
like
a
conclusion
there,
but
I
think
that
like
if
you
did
want
to
have
a
longer
conversation
like
the
people
that
you
would
invite
from
openmetrics
are
have
already
you
know.
Had
this
discussion
and
they're
they're
pretty
like
as
bachan
said,
pretty
firm
into
understanding
that
they
don't
want
to.
You
know,
modify
things
too
sorry
guys.
C
Let
me
be
very
like
at
aws
we
tend
to
be
very
customer
obsessed,
and
our
customers
tell
us
that
this
doesn't
work
for
them
and
we're
heavily
invested
in
both.
You
know
open,
telemetry
and
cortex,
which
is
kind
of
prometheus.
C
I
am
troubled
by
the
ideas
that
probably
just
want
to
create
its
own
committee's
agent,
because
that's
directly
like
it's
a
customer,
they
need
to
say
that
or
open
telemetry
collector
so
like.
If,
if
we
can't
get,
you
know
those
two
projects
to
converge,
then
we'll
have
to
follow
cortex
and
create
a
cortex
that
supports
open
telemetry.
E
I
I
know
I
know
I
know
mark
and,
as
I
said,
it's
it's
it's
very
hard
and
I'm
willing
to
spend
time
on
resolving
this
as
long
as
the
other
part
of
the
story
is
willing
to
do
changes
that
are
required
to
to
convert
someone.
A
Yeah
awesome
I'll
reach
out
to
chris
and
sarah
and
see
if
the
cncf
can
broker
it.
I
agree
it's
worth
a
shot
mark
right
like
it's
worth,
it's
worth
a
shot,
but
I
also
agree
with
what
what
tyler
said
is.
There
is
going
to
be
no
scenario
where
open
telemetry
doesn't
support
open
metrics.
A
B
A
B
C
Give
you
let
me
give
you
an
immediate
example
of
what
my
problem
is.
I
you
know
came
to.
I
have
customers
and
I
run
this
managed
prometheus
thing
and
I
have
customers
and
they
say
how
do
I
scrape
kubernetes
metrics
or
kafka
metrics
or
whatever,
and
I
said
well
open,
telemetry
yeah,
they
said
well,
you
know
the
committee
support
is
not
really
even
there
and
then
you
know
when
I
went
and
asking
the
prometheus
they
said.
Oh,
this
is
not
really
prometheus
support.
B
C
Agent,
because
it's
our
version
of
you
know
mini
prometheus
scraping.
So
do
you
feel
like
how
customers
get
the
headache?
Okay,
so
I
want
for
me
to
server
to
scrape
I
run
open
telemetry
to
scrap.
I
want
graffana
agent
to
scrape
that's
not
good
for
the
industry,
not
good
for
the
customer,
not
good
for
all
of
us,
because
we
are
again
spending
time,
maintaining
parallel
code
bases.
They
do
the
exact
same
thing.
A
Yeah
well,
yes,
you
can
get
them
to
play
ball,
you
know
but
but
but
if
they,
if
they
don't
want
to
like,
we
can't,
we
can't
force
them.
But
what
we
can
do
is
ensure
that,
like
the
collector
does
make
it
easy
to
convert,
which
means
if
the
collector
is
embedded
in
kubernetes,
then
you
know
it's
just
a
configuration
change.
How
do
you
want
to
get
your
metrics
like?
I
think
I
think
that's
that's
a
thing
we
can
make
sure
we
offer
to
people,
but
I
agree.
A
I
do
hope
that
they're
willing
to
like
see
the
how
it
would
be
helpful
to
everyone
if
we
just
like
pick
a
standard.
K
But
is
it
even
possible
like,
given
the
current
protocol
with
deltas,
to
be
able
to
even
like
support
all
the
incoming
things
that
speaks
otlp
to
be
exported
to
prometheus
as
well?
As
you
know,
I
think
the
easier
part
is
scraping,
promotes
and
exporting
to
other
vendors,
but
the
other
way
is
broken
right
now,
and
you
know
it
is
inherently
incompatible.
I
Yeah
this
is
this
is
exactly
like
one
of
the
the
things
that
was
discussed
like
you
know,
they
aren't
really
excited
about
adding
support.
That's
you
know.
Conversion
of
deltas
or
any
sort
of
like
transport
of
things
that
are
are
not
cumulative,
so
it
really
is
that
the
oclp
is
a
superset
of
the
functionality.
I
think
in
the
open
metric
space,
and
then
it's
just
about
the
compatibility
with,
like
particular
data
types
but
like
mark.
I
C
Sorry
to
do
that
to
you,
but
would
it
impossible
to
kind
of
start
a
short
google
doc
of
what?
Why
do
we
think
it's
important
to
converge,
and
maybe
where
do
we
see
the
deltas
between
the
specs
like
was
that
analysis
even
haven't
ever
done
to
say
here
are
where
the
specs
are
different
than
the
rest
is
kind
of
a
line.
K
Not
exactly
like
all
the
differences,
richard
has
a
talk
about
some
of
the
protocol
differences,
but
it
doesn't
capture
everything.
Well,
if
you
have
by
the
way
you
mentioned
that
you
had
some
notes.
Maybe
it's
we
can
just
compile
everything
yep
together.
C
E
C
C
I
agree
that
our
customers
want
us
to
for
for
monitoring
to
just
work.
They
don't
want
to
run
anything
that
I
don't
disagree
so
do
I
know
whether
that
means
that
kubernetes
needs
to
push
matter.
I
don't
know
like
I.
I
leave
the
smart
decision
to
jana.
That's
why
she
get
paid
the
big
bucks.
Okay,
I'm
just
the.
E
I
think
admin
yeah,
you
have
a
great
admin.
E
But
but
that
being
said
diana,
I
think
I
think
there
are
some
this
kind
of
tricky
discussion
which
I
think
were
parked
long
time
ago
in
prometheus
and
if
there
is
ever
a
conversation
about
convergence,
I
think
all
these
things
should
be
addressed,
not
just
that.
G
E
K
Apart
from
the
differences,
does
it
also
make
sense
to
document
the
risks
like
I
mean,
I
think
everybody
understands
like
what
convergence
like
not
having
convergence
means,
but
you
know,
I
think
they
don't
understand
the
scale
of
it
or
they
don't
necessarily
think
that
it's
an
emergent
issue,
so
my
biggest
difficulty
so
far
is
to
be
able
to
communicate
the
urgency.
K
I
No
jokes
aside,
I
think
that's
important.
I
I
think
mark
could
probably
help
out
in
that
sense
as
well
to
talk
about
like
customer
stories
or
something
like
that.
Some
because
I
I
do
think
like
that's
a
really
good
motivator
like
we're
here.
For
that
reason,
so.
K
A
Yeah
yeah,
if
we
could
get
that
documented,
also,
like
I
wonder
about
like
if
there's
a
cost
component
that
could
be,
you
know
shown
out
like
if
I
presuming
there's
a
cost
reduction
from
not
having
to
run
all
these
sidecars
things
like
that,
showing
that
there's
real,
concrete
value
in
in
supporting
this.
It's
not
just
a
theoretical.
E
Good
point:
the
other
thing
you
need
to
to
know
everyone.
I
was
there
by
the
way
in
the
first
big
meeting
of
openmetrics
and
google,
especially
samir
tried
super
hard
to
to
open
the
discussions
about
the
push
model
to
open
the
discussions
about
a
lot
of
other
things,
and
it
was
just
nowhere
in
hell
to
to
accept
that.
So
just
an
afraid.
C
Were
you
in
the
meeting
where
mark
said
speaking
about
me
in
third
person
that,
if
they
won't
let
us
expand
remote
right
to
support
a
google
backends
will
fork
prometheus.
E
C
I
think
that
tom
and
richie,
and
now
that
I
know
the
recorder
I'll
be
nice,
thorman,
ritchie
and
julius
and
all
those
guys
are
really
smart
and
good
guys,
and
I
think
you
know
they
want
to
do
the
right
thing
same
as
us.
So
we
just
need
to
talk
through
the
issues
and
see
if
there's
a
way
to
make
everybody
happy
or
mostly.
C
A
That's
critical:
it's
worth
giving
it
one
big
big,
this
time
with
feeling
and
who
knows
people
change
their
mind.
You
know
it
took
a
while
for
open
tracing
open
census
to
come
together.
So
you
know,
I
always
have
hope
that
we
keep
reaching
out.
Eventually,
you
know
positive
things
can
happen
there.
Okay,
I
think
last
time
on
the
agenda
jana.
This
is
yours.
I.
K
Think
I
think
this
is
we
can
wait.
This
is
like
kind
of
like
an
fyi
for
josh,
specifically
like
there's
a
new,
sparse,
histograms
proposal
on
the
primitive
side.
So
they
want
to
have
like
this,
like
you
know
automatic,
like
exponential
histogram
boundaries,
and
they
will
introduce
a
new
type
for
that.
It's
just
a
proposal
right
now,
but
it
would
be
good
to
align
if
it
ever
happens.
Something.
K
Is
similar
to
the
histogram
type
that
josh's
is
currently
working
on.
E
K
Is
I
I
couldn't
read
all
the
details
and
I'm
like
I
mean
the
doc,
is
very
long
and
doesn't
necessarily
explain
some
of
the
like
details
of
the
implementation,
it's
more
of
like
a
motivational
document.
K
If
I
can
get
to
that
like
before
you
I'll,
let
you
know
how
they
want
to
implement
it,
but
I
haven't
been
able
to
get
to
that
yet.
Okay,
thank
you.
A
Alrighty,
well,
I
think
we're
at
time
that
was
some
good
progress
and
yeah
looking
forward
to
seeing
some
road
map
stuff
next
week,
glad
that
we're
getting
the
feet
under
ourselves
with
these
new
new
sigs
exciting
times.