►
From YouTube: 2020-10-28 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
B
We
have
beautiful,
yellow
fall,
nice
most
of
the
trees
are
yellow.
There
is
a
lot
leave
a
carpet
on
the
ground.
A
A
A
B
B
A
A
A
A
A
Cool
all
right:
well,
it's
five!
After
let's
get
this
thing
done,
so
let
me
share
my
screen
just
so.
We
have
somebody
sharing
the
screen.
This
looks
like
the
right
chair.
A
Cool
well
again
welcome
everybody
jay
burndown
the
usual.
We
have
one
more
p2
issue
in
the
to
do
column
than
we
did
last
week,
but
we
did
close
two
issues.
So
that's
good
and
there's
still
four
in
progress
at
the
moment.
A
I
think
only
one
of
them
is
actually
actively
being
worked
on,
which
is
carlos's
e
jaeger,
propagator
well,
and
there's
one
that
I'm
kind
of
working
on
here
and
there,
which
is
some
performance,
not
a
stress
testing,
on
the
sdk
and
specifically
on
the
otlp
export
pipeline.
C
A
Yeah
I
mean
I
haven't
really.
I
haven't
started
putting
any
metrics
issues
in
at
all
into
the
into
the
ga
burn
down.
It's
all
been
trace
and
baggage.
A
So
far,
I
suspect,
when
the
metric
specification
is
closer
to
being
locked
down,
we
will
get
a
lot
more
issues
that
I
end
up
putting
in
the
ga
burn
down.
A
I
think
that
the
majority,
like
the
issues
that
are
there
are
mostly
testing
in
documentation,
so
be
good
to
crank
out,
but
I
don't
think
I
think
api
wise
we're
actually
really
close
to
just
to
being
done
with
tracing
in
baggage,
ran
into
an
issue
last
night
we're
missing
at
least
one
method
on
the
baggage
class,
which
I
hopefully
will
get
it
done
today.
A
A
A
There's
just
a
whole
lot
of
everything
is
going
to
be
broken
between
09
and
o10
functionality.
Wise
everything
should
still
be
there.
It
shouldn't
be
any
different,
but
we
just
have
done
a
lot
of
work
on
trying
to
get
the
api
into
a
more
solid
final
state.
In
these
last
bits
before
release
candidate
tracing
is
cut,
and
I
think
I
think
the
goal
is
0.10.0
will
be
our
tracing
and
baggage
release
candidate.
A
Know
I
don't,
I
think
it's.
The
apis
are
slightly
different,
obviously
than
jrpc
context,
but
I
think
kind
of
from
a
semantic
standpoint
and
the
way
that
the
context
interacts
with
the
threat
with
threading.
A
B
And
okay,
and
about
bridging
without
instrumentation,
I
probably
should
ask
that
on
instrumentation
seek.
A
Yeah
that
I
can't
speak
to
at
all-
that's
that's
a
bunch
of
black
magic,
which
apparently
is
black
magic
that
isn't
working
according
to
you
this
morning,.
B
A
Shouldn't
be,
I
think,
the
the
way
that
the
keys
are
structured
is
exactly
the
same,
the
the
way
it
gets
activated
into
the
context
or
into
the
thread
it's
still
immutable
in
the
same
way,
like
all
of
that
stuff
should
be
semantically
the
same
syntactically
slightly
different,
but
should
work
the
same
way.
B
A
Yeah
and
if
there's
gaps,
please
issues
welcome
and
we
can
get
them
sorted.
A
A
Well,
I
know
I
don't
read
it
and
I'm
the
only
one
that
really
matters.
So
there
you
go.
No,
I
do
try
to
read
it.
I
often
find
that
it's
wrong,
which
is
always
the
most
frustrating
thing
so
or
written
in
such
an
opaque
way
like
if
you
read
javadocs
and
a
lot
of
java
util
concurrent
holy
moly.
That
stuff
is
almost
incomprehensible.
A
So
anyway,
yeah
try
to
read
the
javadoc
on
like
the
phaser
or
what
is
there's
another
one.
That's
a
stamp
lock
all
those
things.
The
javadoc
is
crazy.
A
Yes,
it's
true
stamp
lock
is
also
awesome,
but
also
crazy.
A
Anyway,
that's
all
I
had
what's
up
with
the
all
any
anybody.
Well,
ken
you've
been
working
on
some
metric
stuff,
any
any
progress.
D
I've
I've
started
looking
at
the
batch
observer
stuff
and
spent.
I
think
two
hours
yesterday
whiteboarding
how
all
the
sdk
classes
work
together.
So
I
can
try
and
understand
it.
D
A
Yeah
it's
every
time
I
go
in
there.
I
have
to
refresh
my
memory
about
how
it's
all
wired
together.
A
D
Yeah
I'll
do
that
shortly
I'll
need
to
upload
it
somewhere,
so
that
was
kind
of
interesting,
some
of
it's
a
little
intelligible
unintelligible.
I
should
say
just
because
I
started
running
out
of
space
to
diagram
everything
and
it
certainly
doesn't
cover
everything,
but
it
was
basically
me
following
a
flow
through
of
creating
a
metric
from
a
builder
setting
the
callback
for
an
observer
and
then
all
the
collection
process
that
happens
out
the
back
end.
D
So
it's
kind
of
got
a
thread
of
the
sequence
of
calls
and
yeah
that
was
took
a
while,
and
I
had
some
false
starts
just
because
I
got
lost
a
few
times,
but
I
think
I
got
there
but
yeah
I'm
starting
to
have
a
look
at
that
and
hopefully
have
something
in
the
next
week.
That
kind
of
goes
more
towards
what
we
were
talking
about
in
terms
of
encapsulating
the
metric
creation
inside
the
the
observer
rather
than
externally.
A
D
A
A
How
is
that
I've
been
the
dd
sketch
stuff
I've
been
only
sort
of
following
in
the
metrics
sig.
How
did
you
get
roped
into
doing
the
implementation
or
putting
the
implementation
into
java.
A
Yeah
you
now
you'll
ken's
document
will
probably
help
you
also
to
understanding.
What's
going
on
in
there.
C
Yeah,
that
other
pr
that
you
shared
of
being
able
to
configure
the
aggregator
or
the
view
like.
What's
the
status.
A
Of
that
one,
so
that
was
done
as
a
proof-proof
concept
for
otep
that
I
wrote
and
the
otep
was
approved,
and
then
I
was
going
to
get
started.
Writing
the
spec
and
josh
wanted
to
take
on
writing
a
more
comprehensive,
sdk
spec.
That
would
include
that
and
that's
kind
of
where
we
are
at
the
moment
right
now,
it's
so
what
I
put
together
is
not
a
full
views.
Api,
it's
just
a
configure
the
aggregator
api,
which,
from
my
use
cases,
is
plenty
but
is
not
enough
for
people
who
really
want.
A
A
So
from
what
I
understand
and
my
understanding
is
very
high
level
and
cursory
view
is
a
way
to
take
to
associate
an
instrument
with
how
the
data
will
be
aggregated
and
like
labels
can
be
collapsed
on
them
or
additional
labels
could
be
added,
or
so
the
labeling
of
the
actual
recordings
can
be
adjusted
also
usually
to
reduce
dimensionality
of
that
of
the
labels.
A
So
those
are,
I
think,
the
two
main
features
of
a
view,
but
the
big
thing
which
my,
which
my
proposal
does
not
encompass
and
my
my
proof
of
concept
did
not
encompass-
is
that
in
open
census
you
could
assign
more
than
one
view
to
a
given
instrument
so
like
you
could
have
like
four
different
views
on
the
same
instrument,
one
of
which
aggregated
as
just
a
counter,
one
that
aggregated
as
a
full
histogram-
and
I
don't
know
some
other
ones
or
one
that
completely
like
collapsed
the
dimensionality
and
did
a
histogram
on
that,
or
something
like
that.
A
The
thing
that
has
bugged
me
a
lot
about
that.
Those
that
views,
api
and
open
census
is
that
it
was
controllable
from
the
api
level.
So
someone
writing
instrumentation
had
access
to
this,
and
I
think
that
the
the
contention
some
of
the
contention
we've
been
having
is
that
one
of
our
goals
with
open
telemetry
is
to
separate
those
concerns
of
instrumentation
and
then
the
end
like
how
people
want
to
aggregate
the
data,
and
so
this
api.
A
It
feels
like
to
a
lot
of
us
who
have
been
open
telemetry
for
a
year
and
don't
have
an
open
census
background
that
that
shouldn't
be
part
of
the
api.
It
should
be
something
that's
the
capability
of
the
sdk
and
lots
of
open
census.
People
are
like
no.
When
I'm
writing
instrumentation.
I
want
to
tell
people
that
this
should
be
a
counter,
and
this
should
be
a
histogram
and
etc,
etc,
or
at
least
provide
those
as
options
like
the
instrumentation
author
could
say:
hey
you
can
aggregate
in
these
three
ways
choose
what
you
want.
A
C
A
Well,
it's
all
confusing
to
me
and
I've
been
spending
a
lot
of
time
in
it
for
a
long
time,
so
you
do
not
feel
like,
like
you're
you're,
somehow
missing
something.
It's
this.
It's
complicated
and
confusing.
D
A
A
D
A
Yeah-
and
I
think
the
thing
that's
a
little
bit-
that's
that's
causing
the
difficulty
in
getting
that
spec
really
moved
forward
is
that
there
was
a
goal
that
open
telemetry
would
be
able
to
replace
open
census,
and
without
this
capability
a
lot
of
census.
Users
don't
feel
like
they
can
plug
it
in
and
use
it.
A
D
A
Wow,
look
at
that
I'll
just
turn
that
right
into
a
right
into
a
google
diagram,
so.
C
What
was
the
question
I
said
in
terms
of
the
aggregations
and
configuring
all
that
base
effectively
what
you
were
saying
for
the
views?
How
much
of
that
would
be
also
specific
to
the
exporters.
So,
if
you've
got
some
exporters
that
only
support
certain
types
of
aggregations.
A
A
C
I
think
that
to
that
point
it
would
also
be
useful
for
the
exporter
to
define
what
type
of
sketch
algorithm
to
use
as
well
yeah.
A
No,
I
think,
you're
absolutely
right
these
this.
It
feels
to
me
like
a
lot
of
this
capability
should
be
something
that
the
exporter
informs
the
sdk
about.
A
A
D
Well,
it's
interesting
because
that
kind
of
gets
into
something
I've
been
thinking
about
as
to
whether
the
sdk
needs
essentially
an
sbi
for
exporters
rather
than
having
anything
everything
internally.
So
there
can
be
a
clear
like
boundary
between
interactions
between
the
two,
as
opposed
to
exporters,
just
depending
on
the
entire
sdk.
A
Yeah
the
agent
has
that
capability
of
having
an
spi
for
exporter
for
the
exporter.
A
But
are
you
thinking
more
that
like
we
need
to?
We
need
to
have
a
like
a
sdk
exporter,
api
jar
that
is
specifically
published
for
exporters
to
use,
rather
than
having
to
depend
on
the
entire
sdk.
D
D
I
guess
you
could
say
encroachment
from
exporters
using
things
within
the
sdk
that
they're
not
meant
to
be
using
and
there's
a
clear
boundary
of
this
is
what
the
sbi
will
do.
If
you
tell
it-
and
this
is
what
exporters
get
out
and
how
it
all
interacts
together,
because
at
the
moment-
because
it's
all
bundled
in
that
there's.
No,
I
guess
you.
D
It's
also
a
case
that
there's
no
single
place
that
you
can
look
to
know
exactly
what
an
exporter
should
be
implementing
you
kind
of
got
to
go
digging
and
see
and
know,
but
it's
just
something
I've
been
thinking
about
and
from
some
other
stuff.
That
would
be
nice
to
have
that
similar
kind
of
boundary
for
the
way
out
of
the
sdk,
as
there
is
on
the
way
in
with
the
actual
hotel
api.
A
A
It
might
be
nice
to
have
a
jar
that
had
all
of
the
classes
in
it
that
you
needed
to
implement
an
exporter
and
maybe
a
spam
processor
and
maybe
a
sampler.
This
is
where
things
start
getting
a
little
fuzzy
like.
How
much
do
you
put
in
there
because
eventually,
you've
kind
of
got
all
the
data
you've
got
most
of
the.
D
D
I
guess
there
is
the
risk
that
it
requires
something
similar
to
the
api
and
that
you've
got
a
bunch
of
defaults
and
no
ops
in
and
then
there
and
stuff
that
need
to
get
overwritten,
but
maybe
there's
a
way
to
provide
some
common
classes
that
the
sdk
and
exporters
can
use
in
there.
Maybe
it's
more
than
an
spi
and
it's
more
like
a
a
shared
kind
of
thing.
Instead,
I
don't
know.
A
If
you
could
like
just
create
an
issue
to
discuss
this
in
the
in
the
java
repo,
I
think
that
would
be
great.
I
guess,
as
we
probably
unless
somebody
wants
to
really
tackle
building
it.
It
won't
happen
before
ga,
but
it's
a.
I
think,
it's
a
it's
a
good
idea
and
will
certainly
make
it
easier
for
people
to
understand
how
to
implement
the
various
extension
points.
Yeah
in
the
sdk,
which
there
are
quite
a
few.
D
Yeah
and
it's
something
I
might
be
able
to
have
a
play
with
once
I've
got
the
batch
observer
stuff
done.
A
All
right,
well
anything
else.
Anyone
wants
to
chat.
A
About
all
right,
well,
then,
I
move,
we
adjourn
a
reminder
for
everyone.
There's
a
instrumentation
group
meeting
tomorrow
morning,
ten
or
nine
pm,
nine
p.
Nine
am
nine,
am
pacific
time
and
then
another
one
tomorrow
afternoon
evening
at
six
p.m.
Pacific
time
so
people
who
are
interested
in
that
please
feel
free
to
show
up
all
right.