►
From YouTube: CNCF OpenTelemetry Community Meeting 2020-02-11
Description
CNCF OpenTelemetry Community Meeting 2020-02-11
B
E
C
C
E
C
E
E
E
We
have
been
getting
a
lot
of
feedback,
which
is
great,
but
we
also
need
approvals
when
the
time
comes,
yeah
but
I'm,
pretty
confident
that
if
we
fought
you
from
the
very
on
the
most
important
part,
so
these
peers,
we
can
reach
them
for
this
milestone.
There
will
be
other
things
that
we
might
want
to
probably
improve,
but
that
can
be
done
on
the
next
milestone.
You
know
things
that
are
not
so
important
and
then
we
have
the
matrix
update.
Yes,
maybe
you
want
to
say
something.
H
G
And
is
I
think
ready,
I
addressed
all
the
comments
I
had
pending
last
night,
and
so,
if
you're
part
of
that
review,
especially
Chris
and
Tyler
and
rule
very
appreciated,
I
think
please
take
another
look
and
approve
only
chris
has
approved
at
this
point,
but
I've
all
the
feedback
was
very
supportive,
so
I
think
it's
ready
to
go
and
then
I
just
want
to
mention
that
I
think
it's
okay
to
snapshot
0.3
right
now
with
that
in
there
are
two
documents
that
are
out
of
date
still
in
the
spec
they're,
not
controversial.
It's
just
that.
G
That's
already
it's
sharing
347
or
something
like
that.
I'm
at
this
point,
interested
in
help
I've
become
a
little
a
little
fatigued
by
all
this
metric
spec
work,
and
it
seems
to
me
that
others
are
both
motivated
and
able
so
I'm
curious.
If
there
are
volunteers
who
would
like
to
pick
up
any
of
these
tasks,
but
I
just
mentioned,
because
I
seem
to
be
the
bottleneck
at
this
point
and
I
have
a
few
other
responsibilities.
So
anyone
who's
interested,
please
talk
to
me
and
I,
think
that's
it
for
metrics.
E
E
E
Ok,
great,
ok,
so
I
want
to
get
started,
we
probably
with
either
dead
or
Bachmann,
or
you
George-
to
prepare
detrol
tagging.
Okay,
we
can
talk
about
that
offline,
okay
and
the
second
item
is
about
actual
reviews,
and
this
is
something
related
to
the
you
know
to
the
premiums
PR,
so
that
we
really
really
really
need
more
people
paying
attention
to
that.
As
I
said,
we
really
have
a
lot
of
people.
E
Actually,
you
know
providing
feedback
which
is
great
and
it's
something
we
really
need,
but
we
also
need
approvals
and
because
of
the
requirements
you
know,
I
could
have
expected
that
it
wouldn't
have
been
so
hard,
because
we
only
need
two
approvals
at
the
specification
level,
but
still
it
has
taken
a
lot
of
time
and
what
related
issue
is
was
filled
by
Julie
about
that.
If
he's
feeling
that
there's
not
you
know
a
consistent
state
regarding
both
Judy's,
not
here
so
I
guess
we
can
discuss
that
offline.
E
G
E
G
E
E
H
Step
around
some
quickly,
I
wasn't
present
at
the
original
discussion
when
this
characteristic
was
removed,
I
think
it
was
removed
last
year,
I
think
bogged
down
put
in
there.
Pr
I
just
wanted
to
highlight
a
scenario
where
this
would
break
the
type
of
scenario
I
deal
with
frequently
and
wanted
to
get
somebody
to
consider
it
to
see
whether
an
amendment
it's
worthwhile
or
not.
Having
said
that,
obviously,
you
guys
have
your
hands
full
with
on
other
issues,
so
no
rush.
We
just
wanted
to
kind
of
raise
it
as
an
issue.
That's
all.
F
Yeah,
maybe
there
was
some
discussion
of
allowing
samplers
to
reconsider
the
decision,
but
I
don't
think
that
it's
in
scope
for
0.3,
so
I
think
that
we
should
probably
punt
this
I
think
the
lasting
solution
is,
you
know,
reconsidering
the
sampling
decision,
but
we
won't
have
that
for
0.3.
So
that's
fine.
How.
H
C
Would
have
been
and
say
we
want
to
release
a
beta
for
languages
that
got
an
initial
whatever
that
initial,
five
or
so
languages,
and
if
people
are
mostly
satisfied
with
0.3
version
of
the
spec
we
kind
of
want
to
get
those
into
beta,
and
then
we
could
start
looking
at
well.
What's
what's
awkward
here
in
terms
of
practical
reality,
what
do
we
need
to
shift
and
have
that
be
per
the
beta
word
all
right?
Okay,.
F
E
I
E
E
I
F
Yeah
I
raise
this
one
because
of
a
question
in
the
dosing
yesterday
and
it
seems
like
in
this
Baker
case.
There
are
other
SIG's
encountering
the
same
issue,
so
it
is
appropriate
to
raise
it
respect
level.
The
question
is
just:
is
this
locking,
or
is
this
a
thing
or
we
can
do
our
own
things
and
then
harmonize
out.
F
C
This
is
a
nice
something
that's
near
and
dear
to
my
heart.
I
haven't
been
talking
about
it,
just
because
I
didn't
want
to
distract.
You
know
from
getting
like
the
core
beta
stuff
at
the
door,
but
it's
certainly
my
experience
from
open
tracing
that
there's
lots
and
lots
of
convenience
to
be
had
and
that
we
absolutely
should
have
a
package
of
like
convenience
and
helper
stuff.
C
As
far
as
like,
should
it
be
mixed
in
with
core
API
stuff,
or
should
it
be
separate
package
I,
don't
know,
I
would
say
the
one
thing
I'm
curious
about
is
to
me:
there's
like
two
kinds
of
convenience:
the
one
where
I
think
there
shouldn't
need
to
be
any
approval
or
much
too
much
thought
is
any
I
would
define
a
convenience
method,
is
one
that
calls
down
to
lower
level
API
methods
right.
So
as
long
as
it's
at
like
a
higher
level
of
abstraction
than
like,
of
course,
I.
C
F
G
Approached
this
in
a
spec
work
by
making
a
bullet
in
the
spec
that
says
optional,
this
is
something
that
languages
should
probably
consider
if
they're
going
to
do.
It
then
do
follow
these
recommendations.
If
you're
not
there's
justifiable,
like
I,
was
thinking
about
it.
Last
night
we've
introduced
a
notion
of
a
timer
metric
instrument,
which
is
just
a
measure
instrument
where
you
forcely
units
to
be
correct,
and
you
and
you
force
the
you
know
the
type
to
be
correct
for
the
built-in
type
timing
type
of
the
language.
G
This
is
just
a
convenience,
but
you
can
imagine
there's
SDKs
that
just
like
don't
care,
there's
if
there's
no
built-in
time
type
of
your
language,
maybe
you
don't
care.
There's.
No
time
like
you
have
a
execution
environment
with
no
clock,
maybe
that's
possible.
So
it's
just
be
list
I
like
to
list
those
as
optional
in
the
loopers
back.
J
Let's
say
this
is
a
little
bit
of
a
segue
to
the
next
item
on
the
list.
If
people
ready
for
that
that
that
particular
method,
what
I
looked
at
it,
was
about
recording
an
error
on
a
span
and
I
just
wanted
to
highlight.
There
are
there's
some
work,
inflight
about
recording
errors,
the
first
two
bullet
points:
there
are
recording
them
as
events
and
the
first
one
is
mine.
It's
it's
really
simple.
The
second
one
is
kind
of
an
extension.
J
J
If
one
was
a
clear
winner
over
the
other,
I
wrote
a
little
bit
of
code,
which
is
in
kind
of
the
last
comment
on
both
of
them
and
I
felt
like
both
of
them
were
actually
super
reasonable,
but
I
felt
like
that
code,
looks
kind
of
like
boilerplate
and
could
definitely
live
in
something
like
a
span
record
error
or
something
method.
So
I
think.
J
Once
we
get
conventions
around
recording
errors,
we
may
find
that
we
want
one
of
these
methods
on
our
stands
most
of
us,
but
at
any
rate,
have
a
look
at
those
things
comment
on
them,
especially
look
at
Vladimir's,
because
I
think
his
approach
covers
a
little
bit
more
than
mine
does
and
then
there's
also
an
approach
by
by
Kevin
brach
off
for
type
span.
Events
I
think
between
these
three
some
sort
of
fusion
between
them.
We
can
probably
come
up
with
a
reasonable
story
for
errors.
E
F
E
J
I
think
that's
all
I
had
to
say.
If,
if
you
do
look
at
those
comments
and
you
look
at
the
code
that
I
wrote
down
there
and
you
wanted
to
like
write
some
up
for
your
language
to
its
paste
it
in
for
for
fun
or
just
to
help
kind
of,
like
you
know,
lobby
for
for
one
over
over
the
other
like
that,
could
be
interesting
and
help
us
make
a
decision.
J
G
Perfect
I
have
a
request
on
that
topic.
Actually
it's
a
little
off-topic,
but
I
would
like
to
have
new
rooms
to
discuss
errors
for
one
and
sampling
for
another.
I
think
that
these
these
topics
are
deep
and
we
haven't
discussed
either
enough,
given
what
just
several
the
recent
conversations
here.
I
don't
know
how
to
make
a
get
a
room,
though
so,
if
someone
could
help
I'd
like
to
create
new
two
new
rooms
and
I
have
things
to
say
about
both
of
these
sure
I
can
help
you
with
that
Josh
thanks.
So
cool
sampling
and
errors.
E
C
G
We
use
this
term
to
describe
sort
of
alternate
configuration
of
aggregations,
potentially
multiple
aggregations
on
metrics
census,
open
census
had
this
and
I
was
a
little
I
guess
this
things
did
things
went
unsaid
since
last
summer,
but
but
basically
I
always
considered
this
to
be
an
SDK
specific
API,
because
the
mechanisms
you're
gonna
use
to
implement
these
are
gonna
vary
widely.
The
supports
that
you're
gonna
have
are
gonna
vary
widely,
but
that's
not
necessarily
a
open
and
closed
case.
You
certainly
can
identify
some
set
of
views
that
are
sort
of
universal
at
some
level.
G
Calls
for
a
way
for
users
to
be
able
to
configure
their
own
aggregations
potentially
directly
at
the
API
level.
This
this
was
said
without
any
further
discussion,
that
that
is
a
requirement
for
the
beta
and
there's
just
no
time
and
I'd
like
to
call
it
an
SDK
API.
Even
though
I
don't
I,
don't
know
what
people
think
but
I
I
see
like
with
sampling.
There
are
so
many
ways
to
implement
this
type
of
functionality
that
we're
hurting
ourselves
by
pinning
it
putting
down
an
API
right
now.
G
C
Okay,
so
it
sounds
like
there's
been
some
discussions,
but
something
that
we
need
is
what
it
sounds
like.
We
need
like
two
basic
things.
One
is
like
a
posting
of
like
what
does
it
mean
to
get
a
language
repo
to
beta,
like
what
do
we
want
to
see
in
there
before
it
gets
called
beta
and
then
I
think
the
other
thing
is
once
we're
in
beta.
Does
that
change,
like
our
release
patterns
already
trying
to
tighten
certain
things
up,
Liz
I
know
you
had
done
some
work
in
the
past.
F
What
I'd
originally
proposed
was
you
know
having
this
discussion
of
like
hey,
you
know,
beta
does
not
mean
that
you're
not
going
to
be
expected
to
update
your
SDK
right.
Like
you
know,
please
update
your
SDK
regularly,
or
else
you
will
potentially
be
sad
and
broken,
so
we
may
as
well.
You
know
be
proactive
about
breaking
you
rather
than
then
have
you
be
surprised
and
sad,
okay,
but
then
I
walked
it
back
because
it
was
excess
of
complexity
at
the
time.
Okay,.
C
F
G
Great
I
also
I,
was
just
looking
at
the
list
of
the
launch
notes
there,
like
I,
just
think
we're
setting
ourselves
up
for
failure
by
saying
this
can
be
done
in
mid-march,
unless
we
cut
scope
and
like
some
of
the
stuff
in
here
is
hasn't
even
begun.
Like
no
language
implementation
has
no
TLP
exporter
right
now,
and
it's
pretty
close
to
March,
so
I'm
just
like,
and
that's
not
an
API
change
either
so
is.
Do
we
really
need
to
get
beta
on
saying
every
language
has
Specht
every
feature,
plus
all
this
list
of
like
support?
C
C
G
A
lot
of
stuff
listed
there,
that's
not
really
quite
in
the
spec,
and
it's
like
it's
stuff
that
the
STK
spec
says.
So
that's
that's
kind
of
a
high
level
for
me
is:
are
we
finishing
the
API
and
the
SDK
data
right
now
or
is
it
just
the
API
I
think
just
the
API
is
reasonable,
but
I
think
the
rest.
If
we
just
throw
all
that
in
it's
hopeless,
not
that
I.
G
C
Maybe
we
can
get
a
hustle
going
and
have
some
some
kind
of
proposal
ready
for
that
community
meeting,
as
I
would
like
to
get
that
nailed
down
and
then
like
up
on
the
project
Status
page
of
the
website,
in
a
way
this
little
more
concrete.
Oh
by
the
way,
there
was
some
related
action
in
the
community
repo.
There
was
like
a
maturity,
matrix
I
think.
F
F
C
F
F
E
C
E
C
G
Mentioned
earlier
that
there
are
two
documents
that
have
not
been
updated:
they
will
be
glaringly
inconsistent
and
it's
either
something
I
can
do
like
in
three
hours
or
it's
something
that
we
should
just
update
to
say.
This
is
out
of
date.
We're
gonna,
follow,
follow
up
in
you
know
a
week
and
it's
like
there
are
two
documents
on
metrics
one
was.
This
is
the
high
level
big
picture?
This
is
what
we're
doing
and
then
here's
the
sort
of
detail
on
each
method
for
a
user's
perspective.
G
G
L
C
I
C
It's
true
I
think,
maybe
related
to
that.
This
is
maybe
under
beta
planning
or
maybe
a
separate
agenda
item,
but
just
writing
starting
to
build
the
ecosystem
and
writing
plug-ins
for
various
libraries
and
frameworks.
I
think
there's
been
some
debate
about
like
where
do
those
go?
Should
those
be
in
like
the
core
language
repose
or
should
those
be
in
separate
repose?
C
Do
we
do
one
thing
for
the
beta
and
then
move
them
out
somewhere
else
later,
just
from
talking
different
things,
it
seems
like
different
working
groups,
have
different
ideas
about
what
they
prefer
there,
but
I'm
curious.
Does
anyone
have
like?
Are
there
any
Sigmund
Tanner's
on
the
call
who
have
like
questions
or
issues
around
where
the
plugins
need
to
live
to
the
time
being.
M
Oh
yeah
I
would
love
not
to
like
that
a
beta
issue,
it's
it's
at
least
in
the
Python.
So
it's
easy
for
us
if
we
can
keep
them
all
in
the
same
repo
for
now
and
then
split
it
out
in
the
template
three
players
later,
especially
because,
as
we
make
changes
to
the
API,
it's
much
easier
to
test
them
when
we're
all
using
the
same.
You
know
bit
of
CI.
G
Also
becomes
impossible
or
very
difficult,
I
should
say
it's
your
fixed
plugins
one
at
a
time
when
they're
different
repos,
if
you're,
making
sweeping
API
changes
still
so
I
think
putting
like
we
can't
yet
start
separating
these
things
until
beta
is
here.
Otherwise,
it's
just
gonna
lead
to
broken
plugins
great,
actually.
E
C
I
do
have
one
request
on
that
front:
it's
not
a
huge
deal,
but
we
have
the
registry
on
the
website
and
it
would
be
great-
it's
maybe
just
a
background
task
or
so
on,
but
it
would
be
great
to
start
listing
all
the
plugins
that
have
been
written
up
in
their
registry
I'll
see
if
I
can
get
some
people
to
help
with
that.
Just
to
start
adding
visibility
to
the
project.
C
People
come
to
that
website
and
likewise,
if,
if
you
want
to
write
plugins
somewhere
that
aren't
in
the
core
industry
and
you're
just
maintaining
themselves,
maintaining
it
yourself
because
that's
easier,
this
is
a
way
to
to
not
have
those
plugins
just
get
lost.
So
it
also
suggests
for
people.
I
think
this
maybe
came
up
in
the
Java
JavaScript
sig,
where
they
were
trying
to
put
the
brakes
on
writing
plugins
because
they
didn't
want
to
maintain
so
many
I'm,
not
sure
yeah.
D
C
A
C
C
G
C
Well,
it's
good
to
be
back
just
just
from
this
review
right
here.
It
sounds
like
you
know.
The
main
thing
is:
we
need
to
make
sure
we're
being
responsive
to
discussions
in
the
specification
repo
and
we
need
to
kind
of
batten
down
the
final
details
of
like
what
an
initial
ap
beta
watch
would
be
so
I'm
gonna
go
around
it
and
try
to
do
some
cat
herding
on
on
those
two
fronts
over
the
next
couple
of
days
so
expect
to
hear
from
the
angular.
A
A
C
Cool
okay
yeah
in
general,
though,
the
website
needs
more
more
content
and
LinkedIn
explanations
for
a
lot
of
these
things
forgot
to
do
so
kind
of
cleaning
the
website
up
and
making
that
a
more
useful
resource
for
the
community
and
all
the
people
coming
in
on
our
way
to
beta.
That's
that's
also
important.
People
want
to
help
with
that.