►
From YouTube: 2020-06-04 Spec SIG
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
C
B
C
It's
Amelia
twice
that
I'll
find
it
right.
I
just
created
it
specifically
for
calendar
advice.
We
should
talk
about
how
we
want
people
to
do
discussions,
there's
talk
of
switching
to
slack,
for
example,
but
but
it
appears
to
solve
the
calendar
in
by
problem
at
least,
but
I
want
someone
else
other
than
me
to
go.
Use
it
and
tell
me
that
it
works
so.
B
C
All
right,
yes,
witching
dislike,
might
be
a
post
GA
thing
we'll
see,
but
but
let
me
know
about
the
Google
Group
for
the
calendar,
because
thus
far
I
asked
two
people.
Do
it
they're
like
well,
I
didn't
really
need
this
and
I
didn't
try
it
I
need
I,
need
someone
else
other
than
myself
to
actually
confirm
that
it
works
before
I,
send
it
out
there
and
have
like
20
people
get
angry
because
they
can't
use
it
yeah.
B
C
B
B
C
D
I
think
you're,
probably
right
unless
I'm
waiting
for
Bodmin
jump
on,
because
then
he's
always
really
good
at
that,
but
yeah
we
can
kind
of
jump
in
where
we
have
time
goes
over
five
minutes
after
phone,
so
yeah,
please
join
if
you're
joining
the
meeting.
D
If
you
have
any
agenda
items,
fill
them
in,
it's
gonna
be
a
little
like
today.
So
if
you
have
a
more
important
things
to
do,
I
suggest
that
you
do
those
kinds
of
things.
I
guess
it's
all
I
can
say
so
to
start
off.
Most
of
this
stuff
is
coming
from
Josh.
Even
though
he's
not
here,
the
idea
is
currently
right.
Now
the
big
thing
blocking
the
metrics
progress
is
being
able
to
transport
the
output
of
metric
aggregations
along
Sparta
bus
protocol,
and
that
is
work
in
the
open
telemetry
for
a
repo
that's
going
on.
D
Currently
there
was
a
recent
merge
which
included
a
monotonic
type
or
monotonic
types
in
the
open,
telemetry
proto.
We
just
kind
of
we
talked
about
this
in
the
past.
It
actually
ended
up
getting
merged,
which
was
exciting.
D
This
is
the
ends
results
for
people
who
weren't
following
it
is
there's
a
tight
and
in
the
type
of
the
metric
proto
descriptor,
there's
now
a
monotonic,
int
and
monotonic
doubles.
These
are
really
useful
because
they
have
an
or
durability
nature
to
them,
which
allows
for
backends
to
understand
if
they
can
make
sort
of
great
aggregations
on
them
or
any
sort
of
comparative
operations
on
top
of
the
function.
So
this
is
really
good.
D
This
is
one
of
the
things
that
was
needed
in
the
support
for
the
open,
somewhat
read
specification
and
not
losing
any
sort
of
details.
As
we
transport
the
metric
output
of
the
aggregates,
there
are
a
few
others.
One
of
them
is
a
discussion
around
the
temporality.
That's
also
already
been
added.
Josh
was
looking
to
remove
that.
So
that's
still
a
work
in
the
progress.
He
also
was
looking
to
encapsulate
more
metrics
types
in
in
the
actual
solution
to
this.
D
He
is
still
working
on
a
proof-of-concept,
though
so
I
don't
think
it's
too
necessary
to
go
into
that
through
the
concepts,
but
at
the
high
level.
Sorry
I
was
just
looking
at
this
right
before
the
meeting
for
all
those
joining.
Now
you
can
see
scroll
horrible,
go
code
or
wonderful,
go
code
depending
on,
if
you
like
door
at
which
I
do.
But
this
is
the
idea
is
eventually
to
change
in
open
telemetry
itself,
so
kind
operators
which
is
going
to
percolate
up
to
the
spec
I
think
eventually
is
the
idea.
D
D
But
yeah
I
think
with
that
the
idea
on
top
of
that
was
custom
aggregations
using
fuse.
This
hasn't
been
touched
on
in
a
while.
A
lot
of
this
was
put
on
hold
because
we
need
to
give
the
added
instruments
which
we
had
just
merged
and
have
been
released
in
the
VCR
FIO
specification,
and
that
is
also
related
onto
some
categorical
concepts
that
we're
addressing
in
the
open
sponsored
protocol.
Some
of
the
workouts
just
describing
I
think
at
this
point
there
is
enough
concept
work
that
we
could
probably
start
redressing
the
views
API.
D
But
yes,
I
think
that
if
you're
interested
in
the
views
specification
or
any
sort
of
views
addition
to
the
metrics
API,
this
is
about
to
be
the
next
major
thing
addressed
after
we
get
that
nailed
down,
and
it
is
the
last
major
feature
anticipated
in
the
metrics
API
prior
to
the
GA
release.
So
it's
it's
coming
to
an
end
sort
of
thing,
a.
B
Lot
of
questions
so
feel
free
to
jump
in
here.
So
let
me
start
by
the
issue
of
custom
aggregators.
So
for
Amazon,
like
we
have
a
problem
with
the
default
aggregators
because
of
the
way
we
send
data
to
the
back
end
today,
so
I
crossed
not
being
able
to
do
custom.
Aggregator
will
probably
be
a
showstopper.
So
what
I
think
I'm
trying
to
figure
out
and
then
it
can
correct
me
if
I'm
wrong
is
one
you
know,
how
do
we
think
one
do
we
increase
it
that
will
be
supported
for
v1?
E
Marker
I
think
you
captured
a
right.
Basically,
we
asking
for
the
FASFA
locks
ability
for
us
to
configure
or
for
the
user
to
config
which
aggregator
he
want
to
bring
in
that's
one
and
second
delay
the
behavior
of
the
aggregator,
because
if
the
matrix
have
multiple
dimensions,
we
want
the
ability
to
configure
okay.
This
is
the
dimension.
We
want
to
materialize
the
matrix
ever
get
on
those
donations
right
so
especially
I
can
give
you
an
example,
especially
in
the
in
the
in
the
kubernetes
situation.
The
matrix
usually
are
hard
covered
cardinality.
E
So
if
we
aggregate
on
the
entire
list
of
the
matrix
we'll
end
up
a
lot
of
matrix,
so
yeah
yeah
and
the
circular
case
is
we
want
to
have
the
flexibility
to
do
a
pass-through.
So
today
the
workflow
is
designed.
We
have
to
go
through
certain
aggregator
to
pass
the
data
to
the
downstream.
But
what,
if
we
our
back
end
want
the
raw
data?
He
doesn't
expect
the
client-side
due
to
any
aggregation.
E
So
we
want
to
find
a
solution,
so
we
can
do
a
pass-through,
so
the
SDK
will
pass
through
the
raw
data
and
pass
down
to
the
exporter.
Exporter
can
either
directly
sent
to
the
backend
or
exporter
sent
to
the
collector
right.
So
in
this
scenario,
another
problem
we
noticed
is
if
we
do
a
pass-through,
because
today
the
metrics
type
we
define
for
passing
the
passing
the
data
to
a
downstream
only
have
three
types:
one
is
Sun,
the
other
one
is
summary
and
histogram.
E
So
for
those
raw
data
which
data
type,
we
should
use
to
carry
those
metrics
to
the
downstream.
We
can
use
our
Sun,
because
this
is
basically
either
playing
data
structure
of
value.
We
can
put
it,
but
we
will
lose
information
of
the
original
metrics
type
and
semantically
sounds
like
a
hack.
It
says
its
aggregated
value,
but
we
put
a
raw
data
into
it.
So
we
try
to
seek
solution
in
in
the
area
as
well.
So.
D
Some
sort
of
ability
to
have
passed
through
this
was
something
that
what
he
was
going
to
try
to,
including
this
proof
of
concept.
I
didn't
see
it
looking
at
that
issue
that
he
originally
just
had,
but
yeah.
That
is
something
that
he
was
trying
to
have
in
the
proof
of
concept,
was
the
concept
of
the
pass
through
so
I
think
that
was
understood
from
from
Josh's
perspective,
I'm
interested
to
hear
what
kind
of
aggregation
values
you
wanted
to
include.
D
The
original
idea,
with
making
open
telemetry
in
some
sort
of
Stax
architecture,
was
to
decouple
the
API
from
the
SDK
and
to
decouple
that
from
D
exporters
themselves,
with
the
anticipation
that
things
like
this,
where
you
had
major
overhauls
to
the
internals
of
aggregation
or
really
even
the
processing
pipeline
of
SDK,
would
result
in
an
Us
SDK
having
to
be
written.
So
I'm
kind
of
interested
like
if
they're,
very
common
aggregation
types
that
are
more
Universal
to
the
broader
open
source
community.
I.
Absolutely
think
that,
like
we're
interested
in
exploring
them,
but.
B
I'm
really
confused
about
before
we
going
to
be
how
to
solve
it.
I'm
gonna
confuse
about
the
statement
about
the
SDKs
because,
like
in
my
mind,
one
of
the
key
value
for
customer
ID
opting
open
parameter
E
is
that
there's
one
collector
and
they
can
plug
in
one
or
more
exporters
for
one
or
more
pic
and
then
those
solutions
are
they
want
if
we
start
doing
multiple
versions
of
the
collector
that
fades
away
so
I'm
not
trying
to
spend
the
idea
of
multiple
SDKs.
In
that
context,
yeah.
D
D
Like
the
go
tell
me
you
jest
Java,
open,
telemetry,
dotnet,
I'm,
actually
in
Python
and
Jas,
and
that
kind
of
thing
the
collector
repository
is
a
separate
project
where
there's
a
unification
of
open,
supplementary
and
other
telemetry
types
into
a
centralized
processing
pipeline
that
can
then
be
exported
to
many
different
other
things.
The
SDK
that
I'm
talking
about
is
in
the
language
SIG's.
So.
B
D
D
So
if
anyone
they
call
is
much
more
versed
in
the
collector,
the
processing
pipeline
can
also
provide
some
sort
of
aggregation,
or
even
some
sampling
like
tell
base
sampling
is
possible.
There
there's
also
some
annotation
possibilities
there,
so
that
is
definitely
something
specific.
What
we're
talking
about
here
are
those
more
of
the
language
things
in
the
specification.
There's
the
open,
3
SDK
and
that
has
a
receiver
from
the
open,
telemetry
API
and
those
are
going
to
be
the
metric
instruments.
D
Those
metric
instruments
are
then
going
to
go
through
some
sort
of
processing
and
that
processing
can
then
have
output
of
aggregation.
Aggregation
types
are
currently
just
I'm,
not
let's
see,
if
I
can
do
it
from
memory,
I
think
there's
an
array
type,
there's
a
some
type,
there's
a
min/max
and
then
I
think
histograms
are
also
supposed
to
be
included
in
that
one
I,
don't
know
about
Dede
sketch
currently,
but
those
are
the
aggregations
that
I
was
talking
about
the
processing.
E
F
Thank
you
yeah.
This
is
me
I'm
also
from
watching
so
I
brought
this
issue
in
so
I.
Think
the
confuse
here
is,
we
don't
want
to
rewrite
the
SDK
yeah.
We
are
trying
to
see
if
there's
a
way
we
can
make
it
a
FIFO
SDK
to
be
configurable,
so
we
can
rewrite
our
own
aggregator,
but
we
just
want
to
plug-in.
We
don't
want
to.
You
know
the
underlined
SDK
core.
We
needed
to
meet
you
everything
from
the
SDK
side.
F
That's
actually
what
we
are
looking
for
and
also
I
put
the
issue
that
382
there
is
actually
I,
think
Josh.
He
already
had
yeah
if
you
can
open.
Thank
you,
yeah,
yeah,
yeah,
I,
think
this
is
also
one
thing
he
put
here
to
make
it.
People
I
said
he
configurable
yeah.
We
we
probably
just
wanted
to
see
for
this
yeah
I
think
he
put
a
really
good
idea
there.
That's
actually.
What
are
we
looking
for,
but
we
want
to
see.
Is
there
any
block
up
there?
Why?
F
C
We'd
like
to
be
clear,
I
think
we
need
this
in
order
to
shift
really
like,
not
only
just
so
that
it
sounds
like
Amazon
has
some
custom
aggregations
they
want,
but
like
their
customers,
end-users
who
are
gonna
have
custom
aggregations
that
they
need
as
well
so
yeah
I.
Don't
think
anybody
plans
on
shipping
the
GA
of
opens
llama
tree
without
allowing
people
to
customize
or
add
different
aggregation
logic,
I
think
it's
just
it's
not
there
yet,
because
no
one's
picked
it
up.
So.
D
Proposal
that
you
wanted
to
that
was
different
than
this
I
think
that
you
should
probably
include
it.
There
I
think
we
would
love
the
contribution
from
Amazon
I'm
firm,
tight,
but
I
do
think
that
it
needs
to
be
make
sure
that,
like
we're
all
in
line
on
that
issue,
otherwise
the
prototype
probably
won't
go.
So
far.
It's
been
contrast,
but.
C
Yeah
just
just
reply
to
the
issue:
I
think
Josh
I'm,
not
as
familiar
this
year,
I
think
Josh
already
laid
out
like
a
design
proposal,
just
basically
expand
on
that
make
sure
you
get
like
Josh
and
bog
and
and
Tyler
people
to
buy
in
and
then
go
prototype
and
build
it
yeah,
absolutely
yeah.
Everyone
wants
this.
This
is
definitely
requirement
the
reason.
The
only
reason
it's
not
here
is
not
a
reflection
of
the
lack
of
desire.
It's
just
a
reflection
of
not
everything
your
metrics
is
done.
B
Mean
do
we
go
to
lose
them
yeah
cool.
So
now,
can
you
go
back
to
my
stupid
question
so
now
I'm
just
another
dynasty's
aggregator
in
this
decay?
My
question
is:
when
the
collector-
let's
say
the
onerous
decade
in
my
world
for
a
second
and
the
collector,
just
collects
data
on
the
OS
or
from
kubernetes
through
the
four
meters
exported
on
the
node.
Does
that
go
to
an
aggregator
in
the
collector
or
does
not
radiation
I?
Think.
C
Right
now,
there's
no
aggregation,
because
Tigran
mentioned
this
on
one
of
the
most
recent
collector
calls.
But
again
that's
just
a
point.
In
time
thing
they
already
have
sort
of
equivalents
labor,
but
they've.
Something
called
like
a
trace.
Processors
allows
them
to
do
additional
processing
on
traces
and
that's
what
Tyler
was
discussing
before
I,
don't
know
if
I
there's
one,
that's
planned,
I
think
someone
I've
already
started
working
on
it
for
metrics
I,
don't
think
it's
finished
yet.
B
C
Correct
the
pipeline's
there's
just
nobody
is
actually
gone
and
written
aggregator
talked
to
Tigran
at
the
next
collector
meeting
because
we
actually
discussed
it
this
week.
It's
either
something
he
was
planning
on
doing,
but
if
someone
wants
to
pick
it
up,
I'm
sure
you'd
be
very
happy
to
let
them
do
it.
F
Yeah
I
think
I
also
put
a
third
question
there.
It's
actually
Daniel's
also
mentioned
that
yeah
if
it's
kind
of
the
follow-up
of
this
customer
aggregator.
So
once,
if
we
can,
you
know
bringing
our
own
over
here,
there's
that
we
can
expose
all
the
raw
data
yeah.
That's
the
other
question.
How
can
we
you
know
past
those
we're
working
with
users?
How
can
we
make
it
a
collector
work
with
those
raw
data?
F
Actually,
that's
the
thing
I
talk
with
Josh
offline
on
the
Gator
he
was
suggesting
he
was
suggesting
that
we
can
use
the
counter,
but,
like
Dennis
also
mentioned
yeah,
we
miss
some
semantic
meaning
from
if
we
are
kind
of
hijacked
that
our
field.
So,
if
I
think
it's
a
solution,
is
either,
can
we
bring
in
a
brand
new
a
new?
You
know
if
this
is
a
lot
everyone
needs.
You
know.
Most
of
people
really
need
a
zero
Tara.
F
D
D
I'm
wondering
with
Josh
actually
eyes
open.
Oh
this
is
this
is
the
issue
that
you
opens:
yeah,
yes,
yeah,
I'm,
sorry
I
have
another
chance
to
read
through
it.
I
don't
yeah
I
think
that
if
you
have
understanding
of
like
fields
that
are
missing
in
the
proto
currently
like,
we
would
love
to
hear
more
about
them
and
what
you
think
is
actually
needed
in
the
products
it
makes
fair.
D
This
transport
is
reflective
of
the
the
data
that's
going
forward
in
that
the
backend
can
and
then
use
it
in
a
more
productive
manner,
because
this
is
definitely
something
that
we're
currently
trying
to
work
out
support
specifically
for
other
patient
I
coming
out
of
the
SDKs,
but
that's
what
he
is,
but
they
can.
The
is
that
if
you
want
raw
types,
is
that
not
good
enough
I
guess
is
the
question,
and
maybe
you
have
things
in
mind
that
I
am
not
aware
of.
F
Yeah
I
think
the
only
things
that
are
for
the
to
store
the
raw
data
type,
but
the
only
things
we
are
yeah
we're.
Looking
for
one
attribute,
you
know
from
the
system
from
the
Josh
I
think
that
just
one
attribute
we're
looking
for
there
is
anything
either
we
can
submit
a
pure.
If
you
know
you
guys
can
take
a
look
review
to
see
if
that
makes
sense
or-
or
you
know,
buy
even
cause
a
more
complicated.
We
need
to
add
a
new
data
type
in
the
proto
to
support
that
yeah.
F
So
if
we
expose
so
take
example
right
now,
we
have
six
six
type
of
metrics.
If
we
can
expose
also
six
type
of
metrics,
it
is
collector.
We
want
to
buy
a
savior
store
in
the
value
like
counter
data
points,
we
want
to
know
what
was
the
original.
You
know,
metrics
type,
for
example,
if
it's
a
sum
of
observer,
always
up
to
encounter
those.
D
Information
yeah,
okay,
I,
see
you're,
saying,
okay,
this
is
sorry.
It's
all
clicking
now,
yeah
I
think
there
was
some.
This
was
supposed
to
be
a
part
of
the
purpose
right
that
Josh
is
also
making
for
an
end-to-end
thing,
so
yeah,
okay,
this
make
sense
if
you've
got
it
captured
in
in
this
issue.
I
think
that
that's
that's
a
good
step
and
I
think
that
we
should
try
to
try
to
make
that
happen.
If
you
have
the
time
and
you
want
to
open
a
PR
in
the
I
mean
you're
obviously
welcome
to
do
that.
D
D
B
Can
think
on
the
regime
was
what
a
way
to
do
the
first
part
for
him,
whoever
as
long
as
we
can
move
forward.
I,
sorry
Dutch
for
a
second
sorry
from
sidetracking.
One
thing,
Benny
said
so
in
a
kubernetes
world,
where
the
like
you
know,
a
port
can
have
a
lot
of
key
value
pairs.
Each
of
them,
I
think
shows
up.
Keep
me
honest
here,
the
custom
metric
type.
B
D
B
E
D
That's
also
a
part
of
the
music
VI
itself
is
just
like:
how
is
that
gonna
be
specified?
Ideally,
it's
gonna
be
specified
by
the
operator,
not
by
the
instrument,
or
is
definitely
the
ask
similar
to
what
it
was
in
open
telemetry
and
then
how
does
that
actually
look?
There's
also,
you
know
related
to
that.
How
do
you
specify
the
view?
It's
also,
how
do
you
configure
the
SDK
itself
late,
there's
still
another
question
if
we
want
to
like
provide
a
standardized
configuration
additionally
to
do
that,
so
you
can
configure
both
of
those.