►
From YouTube: 2021-06-03 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
Hello,
everyone,
sorry
for
being
late
previous
meeting
running
a
little
bit
longer
and
thanks
for
reviewing
the
the
prs.
I
think
I've
got
a
lot
of
nice
feedback.
So
can
we
give
two
minutes
for
people
to
join?
I
I
want
to
see
if,
like
josh
and
bogdan
will
join
so
I
I
know
j
macd
he's
moving
to
a
new
house,
so
he
probably
won't
be
able
to
speak
too
much,
but
he
mentioned
he
might
be
able
to
join
and
just
listen
here
and
I
haven't
seen
bogdan
for
a
while.
A
B
A
A
B
A
A
C
Basically,
we
talked
about
this
last
time
and
I
created
one
issue
and
I
put
a
comment
based
on
based
on
your
request.
One
of
them
is
the
measurement
return
type
for
the
async
instruments.
Like
can
we
provide
something
to
the
user,
which
makes
it
easier
so
that
they
don't
need
to
wrap
their
own
like
value
provider
function
into
another
function,
which
will
provide
a
measurement
and
the
other
one
is
basically
like
why
measuring
time
is
hard
and
why
I
think
we
should
provide
a
timer
for
the
users
in
the
api.
A
Yeah,
so
for
the
for
the
timer,
my
current
thinking
is
when
we
talk
about
timer.
It
brings
a
lot
of
questions
about,
like
you
use,
monotonic
timer
or
you
just
use
the
system
time,
and
do
you
want
to
give
people
flexibility
so
they
can
specify
which
timer
they
want
and
potentially
like
last
time
they
talked
you
give
some
dependency
injections.
People
can
specify
their
fake
timer
during
unit
ties
or
something,
and
that
brings
a
lot
of
questions
and
my
ultimate.
C
Like
point
here,
wait
a
second
because
the
first
point
what
you
mentioned,
that
is,
that
is
exactly
my
point.
I
don't
want
the
users
to
have
a
choice:
yeah
then
they
then
they
when
they
measure
time
they
always
must
use
the
the
monotonic
timer
and
never
use
the
system
time
the
wall
clock.
That's
that's
the
whole!
That's
like
at
least
like
yeah
half
of
the
half
of
the
whole
problem
that
mostly
even
then
users
like
measuring
time.
C
They
they
will
use
the
system
time
and
that
that
is
wrong
because
that
that
is
that
can
go
like
measurements
can
go
like
a
very,
very
off.
A
C
C
A
Okay,
so
anyone
else
wants
to
speak
for
this.
I
know
johnny
probably
would
agree
with
jonathan,
because
he
also
have
more
experience
from
the
java
side,
and
that
seems
to
be
the
common
practice
on
c
plus
plus
I
I
know
like
in
the
open
time
gc
plus
there
has
been
a
lot
of
debate
and
in
the
end
we
have
to
provide
the
option
for
people
to
use
either
the
system
time
or
the
monotonic
time.
C
Could
you
please
point
me
to
if,
if
this
is
like
written
anywhere,
because
to
me
it's
it's
not
a
debate,
it
should
not
be
a
debate
like
it's
never
ever,
because
using
the
system.
Time
is
inherently
inherently
wrong
when
you
measure
latency-
and
I
tried
to
like
write
this
down
in
that
in
that
issue-
command
like.
Why
is
it
or
why
is
that
so
wrong
to
do.
C
A
A
C
So
I
am
not
saying
that
users
should
not
have
access
to
the
time
because,
like
if
we
want
to
give
a
time
or
clock
abstraction
which
will
give,
which
will
basically
make
it
easy
for
them
to
test
these.
C
C
C
Sorry,
I
I
try
to
capture
this
as
well
in
in
my
comment,
and
maybe
this
is
only
my
experience,
but
my
experience
is
that
when
you
are
talking
about
matrix
most
of
the
times,
you
are
using
a
timer
and
you
are
measuring
latency.
D
If
I
can
say
something
here,
I
think
I
I'd
agree
that
a
lot
of
times
when
you
use
time
in
java,
you're,
actually
grabbing
date
and
your
resolution
is
really
really
low
same
with,
like
c
plus
plus.
If
you
want
the
high
resolution
timer,
it's
a
different
call
and
that's
the
one.
D
We
really
really
really
really
want
people
to
use
by
default
and
if
they
want
to
use
the
other
timer
cool,
they
can
measure
something
across
several
days,
but
that
shouldn't
be
I
giving
them
something
that
does
the
right
thing
would
be
ideal,
so
you
don't
accidentally
use
the
wrong
one.
So
I
I
totally
agree
like
I
know
in
cps,
plus
it's
an
issue.
I
know
in
java
it's
an
issue
that
the
resolution
timer
you
want
to
use
is
different
than
the
one
you're
used
to
using
for
date.
D
A
C
Yeah
and
like
as
josh
mentioned
like
the
resolution
is,
is
one
thing.
The
other
thing
like
that
that
is,
that
is
the
first
issue,
for
example,
if
your
like
system
time,
its
granularity
is
one
second,
then
if
you
are
measuring
anything
between
zero
and
one
second,
your
your
measured
latency
will
be
either
zero
or
one.
Second,
I
understand,
and
the
other
issue
is
the
system.
C
Time
can
and
will
change
so,
for
example,
if
you
are
like
calculating
so
if,
if
your
system
time
like
respects
deep
seconds,
then
every
time
in
the
year
usually
like
at
the
end
of
it,
it
will
be
off
by
by
a
second
or
two
yeah.
Also
if
the
system
timer
is
getting
off
and
you
have
ntp
and
you
are
syncing
it
or
somebody
just
like
goes
to
the
box
and
basically
sets
the
time.
Then
your
measurements
will
be
like
very,
very
off.
A
Yeah,
I've
seen
that
a
lot
and
in
microsoft
I've
seen
people
also
talking
about
the
time
synchronization
between
multiple
servers.
They
have
something
like
vector
log,
so
they
want
to
make
sure
if
you
have
service
a
calling
service
b
and
they
might
have
some
synchronization
issue-
you
you
don't
want
to
have
some
some
telemetry
in
system,
a
saying,
hey.
I
happened
at
this
time
and
then
turn
out
in
service
b.
A
That
actually
happened
before
service
a
start
calls
with
b
and
they
introduce
a
very
complex
synchronization
mechanism
and
they
put
vectorized
clock
just
to
make
sure
things
are
still
sequential
and
that's
a
complex
topic.
So
so
how
about
this?
I
I
think
before
we
declare
feature
freeze.
We
still
have
window
to
explore
this.
That
gives
us
a
limited
time
window
and
even
if
we
miss
the
time
window,
this
can
be
a
nice
additive
change.
We
add
to
a
stable
version.
So
if
people
think
this
is
something
we
we
definitely
want.
A
I'm
happy
to
explore
the
python
part
and
build
some
prototype,
but
my
ask
is:
I
need
another
language
prototype,
so
we
can.
We
can
explore
what
type
of
api
we
need.
I
think
it
should
be
relatively
straightforward,
but
my
worry
is:
we
cannot
extend
the
scope
indefinitely,
for
example,
people
look,
for.
A
I
won't
have
the
plug-in
feature.
I
can
specify
my
own
timer.
I
want
to
be
able
to
provide
my
own
vector
clock.
I
I
think
that
will
will
eventually
like
lead
us
nowhere.
So
if
we
can,
we
can
clearly
restrict
ourselves
to
a
limited
number
of
goals
and
put
anything
else
as
additive
change
later,
we
might
be
able
to
do
that
before
feature.
Freeze,
I'm
happy
to
spend
some
time
up
to
explore,
but
I
know
in
general,
people
are
very
busy.
I
hope.
A
C
So,
first
of
all,
my
my
only
like
ask
is
just
to
create
these
two
and
provide
some
feedback
or
like
tell
what
you
think
in
the
comments.
A
At
the
duration
api
that
we
give
people
some
syntactical
sugar,
we
let
them
say
this
is
your
duration,
and
by
default
it
will
look
like
a
histogram
and
you
you
don't
have
to
put
any
time
we're
going
to
track
the
duration
for
you
from
the
language,
syntax,
sugar
and
the
default.
Behavior
is
we'll
use
a
high
precision
clock.
So
you
don't
have
to
worry
about
that.
E
A
I'm
I'm
open
either
way
like
either.
I
can
build
something
on
my
local
machine
and
send
a
pr
in
the
python
repo
market
that
don't
merge
and
just
give
people
ideas.
This
is
the
api
I
come
up
with
and
it
seems
to
be
working
and
these
are
challenges.
So
we
can.
We
can
proceed
further
or
if
you
want
me
to
make
it
more
official
thing,
I
I'm
happy
to
collaborate
with
you
on
that.
C
Also,
diego,
what
what
you
can
do
if
you,
if
you
are
like,
go
to
the
to
the
second
link
to
the
timer
comment,
I
like
placed
some
a
link
to
a
python
example
that
that
really
did
and
also
the
documentation
of
python,
which
will
tell
you
like
what
is
wrong
and
why
it
is
that.
So,
if
you
are
using
it
anywhere
in
your
code,
you
can
very
easily
like
search
to
that
and
detect
the
problem
and
also
the
documentation
will
tell
you
like
what
is
the
right
way
to
do
it.
A
Thank
you
yeah,
so
so
my
my
ask
would
be
please
help
me
to
get
better
idea
of
how
badly
you
would
want
this,
because
currently
I
I
think
jonathan
see
this
as
a
super,
important
thing
and
and
otherwise
people
will
make
mistake
and
john
he
seems
to
agree.
This
is
nice
to
have
seen
and
also
josh,
but
it
doesn't
seem
to
me
like
you
believe
this
is
something
you
definitely
want
for.
The
stable
release.
A
D
A
Understand
how
important
this
is
from
your
opinion,
like
how
customers
would
see
benefits
and
if
we
add
that
later,
do
you
see
like
a
lot
of
people
would
make
mistake
and
then
we
will
tell
them
hey
now,
there's
a
better
instrumentation
and
you
have
to
change
your
instrument
from
histogram
to
the
duration,
syntax,
sugar
or
you
think.
It's
fine.
I
don't
care
like
in
java.
I
can
have
my
extension
api
just
to
give
people
an
option,
but
they
don't
have
to
be
the
native.
F
Instrument-
okay,
I
can
yeah.
I
can
definitely
do
that.
Do
you
want
me
to
add
my
comment
here
in
this
magnus
pr.
A
F
A
I'll
do
this
yeah
and
there
go
by
default.
I
I
I
will
do
some
local
experiments
similar
like
when
I
put
the
metrics
back.
I
have
the
python
snippet
code,
so
this
is
my
local
experiment
and-
and
I
continue
offline
to
send
you
my
initial
idea-
and
you
tell
me
whether
you
want
to
you-
want
me
to
work
on
your
prototype
or
it's
just
fine
like
we
work
individually
on
this
perfect.
That's
awesome!
Okay,
thank
you!
A
So
the
next
topic
I
have
to
follow
up
prs
that
I
want.
I
want
to
see
if
we
can
close
the
this
one
is
a
higher
priority,
because
this
is
part
of
the
api.
It's
not
changing
the
current
design,
it's
just
trying
to
clarify
existing
state,
and
I
believe
there
are
some
nice
comments
from
from
josh
and
and
john.
I
I
probably
resolved
that
for
the
most
part,
so
I
want
to
see
if
people
feel
okay
or
for
them
like
junk.
A
Okay,
yeah,
so
so
thank
you
that
that
seems
to
to
be
fine
for
this.
Okay,
thanks
a
lot
and
and
just
want
to
clarify
in
the
epa
spike,
we
only
state
the
fact
trying
to
tell
people
like.
If
you
have
a
sync
instrument,
you
will
have
access
to
the
context.
That
means
anything
that
is
publicly
accessible
from
the
contacts
like
the
trace
id
spam
id
and
the
attributes
attached
to
a
spam
or
the
baggage
and
anything
else
like
you
can
imagine,
won't
be
available
for
async.
A
You
don't
have
access,
but
regarding
how
people
can
access
those
things
and
enrich
their
existing
like
telemetry
like
the
metrics,
it's
not
covered
by
the
api.
Instead,
it's
in
the
sdk
spec
just
want
to
make
sure
people
understand.
Okay,
next
one
is
relatively
lower
part,
it's
not
a
blogger,
but
it's
important.
A
This
is
about
the
the
view.
I
I
saw
that
a
lot
of
questions
from
josh
and
and
also
diago
is
here,
so
I
want
to
make
sure
we're
on
the
same
page.
So
let
me
explain
my
understanding.
We
have
two
concepts
hint
and
view
you
are
coming
from
the
ic.
It's
basically
telling
the
customer
hey.
If
you
use
some
instrumentation
library
like
http
client,
they
already
give
you
something
like
http,
request,
duration
and
and
something
else,
but
with
view
you
can
customize
the
behavior.
A
By
saying
I
know
the
library
is
giving
me
10
dimensions,
but
I
don't
care
about
them.
I
only
want
three
or
you
want
to
say.
I
know
it's
a
histogram,
but
I
won't
use
the
view
to
define
the
the
bucket
size
and
that's
why
this
is
in
the
isdk,
because
the
application
owner
is
going
to
use
that
to
configure
the
behavior
and
in
addition,
you
can
see
more
details
in
the
pr
the
video
allows
people
to
say.
A
I
know
the
instrumentation
is
giving
me
three
dimensions
like
htv,
http
status,
code,
http,
verb
and
and
something
else.
But
in
addition
to
that
I
know,
there's
important
dimension
from
my
baggage.
I
want
to
take
the
the
user
device
type,
whether
it's
android
or
ios,
from
the
baggage
and
use
that
as
my
matrix
dimension.
So
they
can
do
all
this
crazy
stuff,
but
this
is
only
for
isdk
and
there's
a
very
similar
concept.
A
If
you
look
at
that,
it's
almost
the
same
idea
as
view
I
haven't
spec
that
out,
because
we
agree
that
we're
going
to
hammer
out
the
view
and
then
take
the
lesson
and
come
back
to
the
api
to
spec
that
out,
the
the
hint
api
is
part
of
the
api
spec.
It's
it's
intended
for
the
application,
not
not
for
the
application
owner
for
the
library
owner
to
give
a
hint,
so
application
developer
can
get
the
default
behavior
and
the
scenario
is
captured
in
the
old
tab.
But
I'll
briefly
explain
here.
A
So
if
you
own
the
http
client
library
and
the
instrument
that
you
know
all
the
created
dimensions,
you
want
to
report
through
the
instrument,
but
you
also
know:
what's
the
recommendation,
you
tell
the
user
by
default.
I
think
these
three
dimensions
would
be
super
useful
and
for
this
duration,
I
think,
based
on
the
technical
scenario,
the
histogram
buckets
would
make
sense.
I
want
you
to
use
this
histogram
bucket,
instead
of
forcing
everyone
to
define
their
own
histogram
bucket.
A
A
And
based
on
that,
I
I
can
quickly
go
through
the
the
comments,
so
I
I
think
one
outstanding
comment,
type
thing
here:
josh
mentioned
the
view
is
defined
in
the
sdk
and
feels
like
api
thing.
So
I
I
think
my
answer
is
view
in
the
sdk
is
intended
for
application
developer
and
the
api
will
have
something
very
similar.
We
call
the
hint
api
so
library
developer,
to
provide
the
the
guidance.
What's
the
default,
behavior
and
and
the
flow
will
be
like
hey.
If
the.
D
A
Yes,
there
is
so
the
the
flow
and
hint
changes
that
default
aggregation
in
some
way
it
doesn't
have
to,
and
normally
it
shouldn't
hint.
What
I
can
imagine
the
most
common
case
is
hint
tells
the
user
here
are
the
dimensions
that
are
most
interesting
to
you
like
in
the
hdb
client
library,
the
library
author
might
decide.
A
Okay,
so
so
let
me
give
you
two
examples:
one
is
in
the
instrument
you
report,
ten
dimensions,
http
verb,
http,
url
and
you
know
http
url
is
crazy,
but
someone
might
need
it
like.
Normally
people
don't
want
each
url
because
that's
going
to
blow
their
system
away,
like
dimensional,
exploring
and
also
potential
security
leak,
but
you
want
to
give
that
power
and
you
give
the
hint
to
people.
I
think
for
99
percent
of
the
scenario
people
would
care
about
the
duration
based
on
the
http
verb
and
the
status
code,
nothing
else.
A
So
this
is
where
you
give
the
hint
api
you
tell
people,
you
only
want
these
two
dimensions
in
most
of
the
cases.
The
second
scenario
is
you're
saying
this
is
http
duration
and
by
default
it's
a
histogram.
But
what
about
the
bucket?
Should
people
use
like
start
from
one
second
10
seconds
100
seconds,
or
this
is
a
high
performance
scenario.
You
think
it
should
be
measured
in
milliseconds.
A
So
this
is
something,
but
the
unit
can
give
some
hint,
but
but
still
the
user
has
to
define
the
bucket.
But
if
the
hint
api
can
give
the
library
author
the
benefit
we
can
provide
the
default
bucket,
then
application
developer
will
just
say.
I
want
to
subscribe
to
this
instrument,
and
all
I
got
is
a
perfect
dashboard
and
literally
realized.
Oh,
my
service
is
actually
slow,
so
I
I
don't
need
that,
like
very,
very
small
bucket
on
the
like
milliseconds,
I
only
want
like
100
milliseconds
one
second
10
seconds.
D
Okay,
so
so
I
understand
I'm
a
library
provider
and
I'm
providing
10
labels,
and
I
hint
that
three
of
them
aren't
useful,
yeah
or
or
are
duplicate
of
other
labels.
By
default,
nothing
happens.
All
five
of
them
come
out
in
time
series
or
by
default,
because
I
hinted
at
that.
I'm
going
to
aggregate
those
away
unless
somebody
configures
it
differently
in
the
sdk.
A
If
the
library
owner
gives
you
the
hint
and
the
application
user
is
lazy,
they
don't
specify
any
view.
Then
we
respect
the
hint
as
much
as
possible.
Okay,
note
I
put
the
tricky
word
here
as
much
as
possible,
because
some
system
might
figure.
Oh,
I
can
only
support
80
percent
of
the
hint.
There
are
certain
thing
I
I
don't
have
the
cover,
but
for
them
the
thing
could
say
you
want
100
histogram
buckets,
but
the
system
might
decide.
Okay,
I
only
have
support
for
at
maximum
10
buckets.
A
They
might
decide
to
reduce
that
based
on
whatever
they
prefer.
There
has
to
be
a
rule,
but
the
view
api
gives
the
ultimate
controls.
The
application
developer
can
override
any
behavior
and
just
tailor
for
their
scenario.
And
if
the
vo
api
asked
for
some
specific
thing
like
I
want
10
buckets
and
the
system
is
saying,
I
cannot
do
that.
I
only
support
up
to
8
bucket
size.
Then
it
should
result
in
some
error.
A
Okay
and
is
the
the
hint
api
is
already
documented.
So
no
no,
so
it's
probably
missed
that.
So
so.
In
the
previous
meeting
we
discussed
that
the
hint
ap
and
the
view
api
conceptually
they're
very
similar.
So
what
we're
going
to
do
is
we
document
the
view
api
in
the
isdk
and
that's
the
that's
a
high
priority
thing,
because
we
we
need
that
learning
to
come
back
to
the
api
spec
and
after
we
finish
the
hint
api.
You
know
api
spec,
it's
a
complete
api
spec.
A
D
So,
from
the
standpoint
of
the
user
right,
I
take
a
dependency
on
some
http
framework.
It
provides
a
bunch
of
built-in
stuff
that
has
a
hint
that
leads
to
a
default
view
and
I
just
consume
it.
How
is
how
it
is,
if
I
want
to
provide
a
new
metric
from
some
measurement
they
already
have
like?
I
want,
I
don't
like
how
they're
doing
their
histograms
and
I
want
say,
99th,
percentile,
calculated,
right
and
and
reported
separately
as
its
own
thing.
I
would
add
a
view,
and
that
would
be
the
sdk
yeah.
Okay,.
A
And
this
part
has
been
prototyped
before
I,
I
guess
I
I
heard
from
josh
that,
like
he
did
some
experiment
and
and
john
I'm
not
sure.
If
you
you
did
some
experiment
as
well,
but
I
I
I
know
you
did
the
the
selector
the
instrument
selector
part.
I
heard
that
from
bogdan.
B
A
G
Yeah
and
the
go
example
that
I
had
mentioned
in
the
past
is
that
you
can
configure
selectors,
for
which
aggregator
is
used,
for
which
dimensions
potentially
will
be
removed
in
the
processing
pipeline,
and
that's
about
it.
You
can
there's
also
a
choice
of
temporality,
which
is
a
thing
that
has
been
requested.
D
Well,
there's
also
the
possibility
of
creating
a
completely
different
metric
that
doesn't
override
the
underlying
one
right,
so
I
guess
yeah
it
is.
I
have
a
lot
more
questions
when
it
comes
to
hints,
but
I
I
hear
what
you're
saying
around
there's
going
to
be
a
piece
in
the
api
and
a
piece
in
the
sdk
that
that's
fair.
I
think
some
of
my
other
concerns
are
still
kind
of
valid
around.
G
Can
I
ask
you
an
open
census
question
in
that
case,
so
I
do
recall
the
sort
of
canonical
example
that
was
used
when
we
discussed
this
a
year
and
a
half
ago
was
the
case
of
grpc
instrumentation,
which
had
essentially
two
options:
sort
of
low
cost
and
high
cost
configuration,
and
it
was
a
a
method,
call
that
you
would
call
into
grpc,
which
would
then
call
its
view
setup
code,
and
there
was
basically
two
code
paths,
the
normal
case
and
the
expensive
case.
F
D
I
I
I
think
our
learning
there
was
that
so
that
was
all
part
of
like
the
api
which
led
to
this
kind
of
invasive
approach.
Right
like
this
is.
This
is
why
I
think
we're
trying
to
detangle
in
open
telemetry
in
open
senses
the
the
way
the
views
worked.
You
know
it
was
part
of
your.
It
was
part
of
your
api,
like
if
you
look
at
some
of
the
the
collector
observability
reviews
where
you
have
to
like
register
these.
These
open
census
views
to
get
observability
out
of
the
collector.
D
It's
the
same
kind
of
problem
of
you
have
someone
who's
writing
instrumentation
with
the
metric,
and
then
you
have
this
this
this,
like
external
api
for
consumption,
that
you
don't
have
a
lot
of
wiggle
room
and
control
over
right
right.
So
I
mean
you,
you
kind
of
gave
the
lesson
of
if
I
want
control
over
reviews
and
someone's
setting
up
something,
I
don't
like
I'd
literally
have
to
find
a
hook
into
their
code
to
change
their
setup
behavior.
D
So
the
hint
api
is
better
than
that
in
the
sense
of
you
could
have
a
hint
api.
That
does
what
you
consider.
The
right
thing
in
general
and
then
people
could
write
something
more
advanced,
but
the
notion
that
you
want
a
user
writing
both
of
those
options
like
one
of
those
options,
I'm
not
sure
of
you
know
I
I.
G
I
started
thinking
of
this
as
in
relation
to
the
new
schema
support.
G
That's
been
added,
and
instead
of
thinking
of
this
as
a
hint
really
thinking
of
this,
as
sort
of
essentially
providing
a
schema
and
in
the
case
of
resource
attributes,
there's
been
a
little
bit
of
a
like
question
standing
around
there
about
whether
we
can
sort
of
bind
resource
attributes
downstream
and
and
then
in
that
case
there
seems
to
be
two
different
classes
of
resource
attribute:
they're,
the
primary
identifiers
and
they're
the
secondary
identifiers
and
I've
started
to
think
of
this
question
about
the
api
question
that
riley's,
posing
as
one
of
basically
saying
whether
the
attribute
that
you're
providing
on
the
metric
event
is,
is
primary
or
secondary
in
the
sense
that
in
the
default
setup,
I
would
like
to
keep
the
primary
identifiers
and
drop
the
secondary
identifiers
and
potentially
that's
how
the
api
could
land
and
and
I'm
and
it's.
G
A
Yeah,
so
it
it
seems
we
we
need
more
clarification
here.
So
my
suggestion
would
be
how
about
this,
like
I'm,
I'm
not
pushing
for
this
pr,
because
I
I
think
there
has
to
be
a
lot
of
discussions.
A
So
meanwhile,
I
can
send
a
pr
on
the
api
part
just
to
document
what
I
can
see
on
the
hint
and
then
I'll
update
the
pr
to
point
to
each
other.
So
so,
when
you
review
the
pr
you
can
compare
the
hint
and
the
view
and
I'll
put
some
explanation
on
the
sequence
like
josh
you
ask
like.
If
there's
no
hint
there's
no
view,
then
the
instrument
will
be
taken
and
all
the
dimensions
will
be
reported
and
if
there's
hint
but
there's
no
view,
then
we're
going
to
respect
the
hint
as
much
as
possible.
A
So
something
like
that
and
it
will
be
it'll,
be
a
little
bit
complicated,
so
I'll
I'll
put
something
here
and
even
for
myself
like
like
until
I
start
to
actually
write
it
down.
I
start
to
notice
a
lot
of
questions
I
have
so
how
about
that,
like?
We
don't
struggle
yeah
much
here
and
I'll
put
the
I'll
put
the
hint
api
and
we
can
compare
two
and
and
then
have
the
next
discussion.
I
think
this
part
is
important.
A
D
The
I
think
the
current
proposal
here
is
kind
of
this
middle
ground,
where
I
think
we
either
want
to
be
dumber
or
smarter,
where
you
could
have
an
api.
That's
basically
like
go
get
me
this
set
of
metrics
and
I'm
gonna
transform
them,
and
whenever
I
give
you
back
you
blow
away
what
I
filtered
in
and
here's
what
you
get
out,
and
so
from
that
standpoint
you
have
an
api
where
the
views
can
decide
whether
or
not
the
underlying
metric
makes
it
out
the
door
or
not,
and
we
have
flexibility
to
build
anything.
D
D
This
is
where
suggesting,
I
think,
really
what
we
want
is
prometheus
rewrite
role,
style
queries
as
views
where
we
say:
here's
a
query
run
against
instruments
and
here's
the
metric
that
comes
out
the
door
right
and
that's
kind
of
like
the
high
level
view
that
we
can
do
all
sorts
of
intelligence
and
smarts,
and
I
would
suggest
that,
like
initially
I'd,
rather
see
the
really
dumb
one
where
you
have
way
too
much
control
and
we
build
something
flexible.
On
top
of
that.
D
If
we
feel
like
we
can
do
that
efficiently
and
we
can
provide
a
good
user
story
around
it,
just
because
I
think
right
now
we're
in
this
middle
ground,
where
we're
we're
like
partially
doing
things
for
the
user
and
partially
not-
and
my
concern
is
that
we're
we're
not
giving
ourselves
enough
flexibility
to
handle.
D
What's
going
to
come
at
us
and
then
the
other
thing
is
we're
going
to
keep
getting
pushed
to
go
more
and
more
and
more
clever,
so
that
that's
basically
what
I'm
trying
to
was
trying
to
tease
out
and
my
understanding
here.
A
Okay,
I
I
yeah,
I
see
your
point,
so
let
me
ask
you
this
question:
do
you
think
the
ultimate
like
super
powerful
you
can
do
whatever
you
want
solution
is
actually
the
processor.
A
A
G
I
support
that
statement
riley.
I,
the
idea
of
configuring
views
and
it
sounds
like
compiling
a
complicated
configuration
into
a
bunch
of
processor
components
that
have
the
sort
of
efficient
implementation
of
what
you
requested
and
it's
like
a
really
big
project,
especially
the
idea
that
we
standardize
and
specify
how
to
do
that.
G
But
as
far
as
the
basic
building
blocks
of
a
pipeline,
the
ones
I
was
trying
to
provide
were
you
can
filter
out
dimensions
or
attributes,
you
can
change,
aggregators
and
so
on,
but
all
the
things
that
you
can
do
is
you
know.
As
far
as
configuring
histogram
buckets,
that's
included
in
choosing
an
aggregator
choosing.
All
the
like
variations
are
also
just
things
you
can
do
by
configuring
processors.
A
Yeah
so
so
josh,
like
view
is
already
like
the
convenience
layer
and
and
we
have
the
full
power
in
the
processor,
and
I
can
definitely
see
your
concern.
I
also
have
the
concern
when
I
remember
pogba
initially
mentioned
like.
A
Can
we
just
make
the
view
or
the
hint
taking
a
yamo
file
start
making
me
super
worried
because
yama
file
people
can
put
whatever
there
and
later,
for
example,
if
yama
is
not
popular
and
something
else
replace
yamo?
What
are
we
going
to
do
so?
So
there
is
certainly
some
balance,
and-
and-
and
this
is
what
I'm
thinking
like
when
people
look
for
the
ultimate
power,
the
processor
can
do
whatever
you
want
and
with
the
view.
Initially,
we
only
focus
on
a
limited
set
of
scenario,
but
that
view
can
be
extensible.
A
So
if
later
people
want
to
add
additional
stuff,
we'll
need
to
keep
some
bar
and
depending
on,
what's
the
complexity,
the
the
goal
is,
we
don't
want
to
make
the
view
super
complex,
because
the
intention
is
for
convenience
and
if
certain
thing
is
going
beyond
that
point,
then
we
tell
people,
no
we're
not
going
to
do
that.
In
the
view,
because
it's
very
hard
to
do
some
complex
logic
through
configuration,
what
you
can
do
is
you
just
go
and
write
your
own
processor.
D
Right
right,
I
think
that's
fair,
so
I
guess
my
suggestion
would
be
maybe
pushing
this
the
current
definition
a
little
higher
level,
even
possibly
yeah
more
limited
just
just
to
to
reduce
some
of
that
yeah
I
mean
I
I
mentioned
my
fears,
but
basically,
when
I
see
selection
criteria,
I
think
query
language
and
how
I
I
I've
talked.
D
I
told
josh
this
a
few
times
that
I
think
we're
going
to
be
pushed
into
defining
some
a
query
language
effectively
or
like
adopting
promql
at
some
point
somewhere
in
hotel
for
these
kinds
of
things
and
that's
but
yeah
anyway.
I
I,
when
I
see
views
and
I
see
prometheus,
rewrite
rules.
I
see
kind
of
solving
similar
use
cases,
and
that's
that's.
One
of
my
fears
here
is
your
right.
Processor
is
completely
open
and
flexible,
but
this
notion
of
selection
criteria
set
of
metrics
as
an
efficient
operation.
D
I
think
that's
what
I'm
pushing
on
like
that.
That's
that's
the
low
level
bit!
I
have
this
query.
That
gives
me
a
set
of
metrics
that
I
can
process
and
then
what
does
it
mean
if
I
process
these
metrics,
do
they
still
exist?
Can
I
remove
them?
You
know
those
kinds
of
questions
like
like
just.
We
should
be
incredibly
clear
in
that
interface.
What
happens?
D
A
Okay,
I
I
hear
you
so
I'll
update
this
pr,
based
on
our
discussion
and
and
I'll
need
your
guys
to
give
feedback
on
whether
you
know
we're
heading
towards
the
right
direction.
It's
a
hard
balance
and
meanwhile
for
folks
who
might
struggle
with
understanding
the
relationship
between
view
and
hint.
I
I
can
send
another
pr
and
and
both
should
be
relatively
lower,
like
it's
not
urgent,
so
we
can.
We
can
take
a
week
or
two
just
to
hammer
that
out.
A
And,
and
for
the
sdk,
I
I
think
there's
a
another
big
chunk
of
the
aggregation.
We
probably
should
start
to
document.
What's
the
default
aggregation
similar
like
in
the
in
the
tracing
part,
we
have
some
default
thing
like
the
default
sampler
provided
by
the
isdk
and
the
default
exporters
provided
by
the
idk.
I
think
for
metrics
part,
the
default
exporter
is
quite
straightforward.
A
I
I
think
we
probably
need
some
like
in-memory
model
and
a
console
model
for
people
to
troubleshoot
and
and
then
the
otlp
and
then
permit
this
and
premises
is
being
the
the
only
pool
matrix
reporter.
So
we
probably
need
four-
and
I
can
I
can
write
the
the
skeleton
of
the
dog.
Then
we
can
hammer
out
the
details
later
and
for
for
the
default
aggregation.
A
A
A
That's
all
from
my
side,
and
the
last
topic
I
have
is
like:
we've,
we've
brought
up
this
topic
twice
in
the
spec
meeting
and
so
far
since,
like
people
either
they
support
or
they
don't
care
they
give
us
freedom.
So
I'm
going
to
update
the
timeline
based
on
our
previous
discussion.
So
we
we
try
to
ship
api
before
the
sdk
and
we
try
to
push
both
ahead
of
time
and
try
to
be
a
little
bit
aggressive.
B
So
riley
I've
got
some
potentially
good
news.
I
have
strong
armed
josh
cereth
into
maybe
into
helping
out
with
prototyping,
which
is
why
he's
here
at
this
meeting
so
awesome.
D
A
Yeah
and
I
understand,
and
and
by
the
way
do
you
think
you
can
delegate
like
aaron
or
someone
in
your
team
to
join
this.
At
least
I
want
to
make
sure
like,
like
we're
aligning
on
the
high
level
direction,
for
example,
we're
saying:
hey
riley
like
we're
doing
something
crazy
here
and
that
wouldn't
fit
the
open
census
requirement.
I
want
to
get
that
feedback
as
early
as
possible,
so
the
either
way
work
for
me
like
you,
find
some
delegates
and-
and
we
can
get
the
message
back
or
I
can.
A
I
can
send
a
summary
of
what
we
discussed
in
the
in
the
like
channel,
so
you
can.
D
The
the
thing,
the
thing
that
we
found
with
open
senses
when
we
tried
to
do
open
census,
compatibility
layers
and
metrics,
is
effectively
we're
going
to
get
aggregated
data
out
of
open
senses
because
of
the
way
views
are
hooked
in
and
because
the
way
the
instrumentation
works,
we
can't
really
get
access
to
open
census
compatibility
until
after
it's
already
been
aggregated
in
open
census.
D
So
from
an
sdk
standpoint,
I
need
a
hook
to
get
to
fire
in
aggregated,
open
census
data
if
we
want
to
have
open
census,
open
telemetry
in
process
compatibility
and
then
in
terms
of
the
the
metrics
in
the
data
model
that
that's
well,
I'm
if
you
deviate
there,
I'm
not
as
worried
as
long
as
I
sorry.
If
you
deviate
what
your
instruments
do
versus
what
open
census
does
I'm
not
as
worried.
D
I
think
we
can
provide
a
migration
path
that
works
for
people
and
if
the
migration
path
is
you
keep
your
current
open
census
metrics
and
we
use
open
telemetry
with
new
sorry
new,
open
time,
tree
metrics
and
old,
open
census,
metrics
and
we'll
give
you
a
path
over
time
to
to
account
for
things.
D
That's
fine,
I
don't
think
you
should
make
100
open
census
compatibility
a
requirement
for
your
current
api,
but
from
an
sdk
standpoint
I
am
going
to
ask
for
a
hook
to
send
in
these
open
senses,
aggregated
metrics,
if
possible,
to
get
that
compatibility
layer
out
the
door
cool
was
that.