►
From YouTube: 2021-05-20 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
C
B
Cool,
I
think
some
people
are
filtering
in
probably
wait.
I
think
another
minute
or
two.
If
you
haven't
already
take
a
look
at
the
agenda,
talk
and
add
yourself
to
the
attendees
list
and
we'll
get
started
here
in
a
little
bit.
But
if
you
have
anything
you
wanted
to
talk
about
or
any
questions
for
us
in
general.
Please
add
it
to
the
agenda
and
we
can
jump
in
just
a
little.
B
B
Cool,
I
think
gustavo
might
be
the
only
one
I'm
not
seeing
on
yet,
but
I
don't
know
if
he's
able
to
make
it
today,
so
I
think
we
could
probably
get
started.
We
have
steve
at
this
point
as
well,
so
yeah,
it's
official,
well
cool
thanks
everyone
for
joining
I'm
glad
to
have
y'all
here,
as
I
was
kind
of
saying
beforehand.
If
you
just
joined
the
call,
please
open
up
the
agenda
doc
and
we
can
start
jumping
in.
B
If
you
have
anything
at
the
agenda,
there
is
a
good
place
but
and
add
your
name
to
the
attendees
list
and
I'll
figure
out
how
to
structure
sentences
and
share
my
screen.
Okay,
cool
yeah,
so
we
can
jump
in.
B
I
wanted
to
go
over
again,
just
kind
of
like
we've
been
doing
this
for
a
little
bit
now
our
current
rc
project
orb
we're
making
some
good
progress,
we're
getting
down
to
the
the
nitty
gritty
at
this
point,
so
I
kind
of
anticipated
some
of
this
velocity
to
be
slowing
down
but
kind
of
wanted
to
go
through
some
of
this
talk.
B
We
currently
have
one
more
thing
to
do,
which
is
something
we've
kind
of
identified
and
just
haven't
gotten
around
to
so
I
don't
I'm
not
too
worried
about
this
one.
I
am
a
little
like.
I
do
want
to
go
through
these
just
a
little
bit.
We
have
four
things
in
progress,
but
we've
also
done
a
lot
of
really
good
work.
292
done
so
in
theory
we're
on
the
cusp
of
making
an
rc.
So
I'm
really
excited
about
that.
That
being
said,
we
should
probably
jump
into
some
of
these.
A
Questions
also,
probably
want
to
add
the
one
that
I
linked
in
the
go
doc
the
the
bug
about
from.
A
Yeah,
the
http
json
that
probably
should
be
included
in
before
the
rc,
okay,
whatever
our
actions
are,
that
is
a
lot
of
bugs.
I
know.
Over
the
last
week
we
got
like
10
bugs
coming
in.
B
Cool
yeah
good
catch,
that's
a
good
one.
That
is
something
we
need
to
address.
B
A
Okay,
I
believe
my
pr
is
the
only
one
outstanding.
B
I
think
you're
right,
I
think
that's
going
to
finish
it
up.
I'm
going
to
assign
this
to
you
then
aaron,
just
because
of
that.
I
think
that
would
make
the
most
sense
and
then
just
be
sure
to
close
it
when
I
think
you
get
the
review,
that's
related
to
this
one
done,
if
I'm
not
mistaken,
yeah.
B
Okay,
let's
see
how
good
I
am
and
how
much
you
guys
are
going
to
put
up
with
my
bs
5
36.
B
D
B
There
we
go
boom
there
we
go
now
we're
all
set.
One
thing
I
have
been
doing,
though:
I've
also
been
adding
these
to
the
project
boards
to
show
that
velocity
and
the
active
work
being
done
here.
B
Going
well
so
maybe
we
can
get
a
little
bit
of
an
update
on
this.
I
know
that
there's
been
a
lot
that's
happening,
but
for
those
that
haven't
joined
the
meeting
since
last
week,
maybe
you
can
talk
a
little
bit
about
the
pr
that
you
opened
and
then
the
work
you've
been
doing
around.
E
E
And
maybe
I
was
thinking
about
copying
some
code
directly
to
the
this
otlp
trace
package
that
I
introduced
in
this
pr
and,
after
everything
settles
down.
I
can
start
to
like
remove
this
duplicated
code
and
utilize
that,
on
both
the
trace
and
metric
exporter,
I
guess
that
could
be
a
thing
that
we
could
do
not
sure.
B
Maybe
not
okay,
I
think
I'm
not
the
most
up
to
date
on
what's
going
on
here.
I
guess
I
just
saw
this
was
converted
into
an
actual
pr
and
I
have
not
gone
back
for
a
second
look.
I've
been
pretty
busy
doing
the
trace
day
stuff.
So
what
you're
saying
sounds
good
to
me.
You
know
I
definitely
am
in
favor
of
duplicating
code
that
is
not
going
to
be
exported
and
can
be
refactored
at
a
later
time.
B
To
push
for
this
ga,
so
I
would
be
in
favor
of
what
you
just
said.
If
that
helps
speed
things
up
cool
yeah,
I
like,
I
should
definitely
spend
some
time
reading
this
again,
but
if
people
on
the
call
haven't
taken
a
look
at
this,
this
could
use
smize.
It's
a
an
important
one,
because
this
is
a
critical
one
to
getting
us
to
the
rc
and
a
lot
of
other
changes
to
the
open,
telemetry
exporter
itself
are
gonna,
be
based
off
of
this.
B
So
having
things
structured
well,
right
now
is
important
for
the
next
pr,
so
it
doesn't
cause
busy
work
or
churn
or
anything
like
that.
D
B
Okay,
yes,
I
think
aaron's
on
the
call
as
well.
He
could
be
a
good
person
to
ask
for
a
review
on
this,
which.
C
C
E
Yeah,
but
that
ripple
also
contains
the
logs
pro
tool.
I
don't
know
if
that's
a
problem
or
not,
but
just
raising
that.
C
I
think,
to
the
extent
that
we're
not
exposing
any
interface
surface
that
might
interact
with
it.
I'm
less
concerned,
I'm
not
sure
this
is
I
mean
the
the
otlp
data
model,
as
it
is,
is
kind
of
supposed
to
be
an
evolvable
forwards,
compatible
and
backwards
compatible
thing,
so
I
would
be
less
worried
about
taking
a
dependency
on
the
data
model
that
may
have
alpha
features
in
it
that
I
would
having
say
or
our
exporter,
depending
on
our
metrics
sdk,
which
is
we
know,
going
to
change
significant
ways
or
is
going
to
change.
B
Yeah,
I'm
I'm
not
particularly
concerned
on
the
otp
as
long
as
there's
like
we're
only
relying
on
portions
that
are
stable,
so
splitting
that
out
is
not
really
something.
I
think
I
care
too
much
about
the
I'm
sorry
for
like
the
protobuf,
but
like
yeah,
the
exporter
itself.
B
Obviously,
that
makes
a
little
bit
of
a
difference
because
that's
based
on,
I
think,
a
lot
of
the
that
imports
the
sdk
that
imports
other
things
that
are
in
our
code
base
that
are
not
stable,
and
so
I
think
that
that's
that's,
probably
a
fair
statement
to
make.
A
C
B
E
A
Yeah
then
I
don't
see
what
we
would
gain
from
having
separate
modules
that
are
unstable,
like
because
we
won't
be
really
like
you
plan,
for
this
is
to
follow
the
data
model,
so
I
would
actually
just
prefer
not
to
have
that
portion
of
it.
I
I
would
like
to
take
in
the
bits
that
do
the
actual
go
mod,
editing
better
than
me,
just
literally
doing
go
with
it,
but.
C
It
might
be
worthwhile,
though
thinking
bogdan
and
j
mcd
on
this
issue
and
asking
their
opinion.
I
I
think
we're
interpreting
it
correctly,
but
I
would
also
be
interested
in
hearing
what
they
have
to
say.
E
B
Okay,
we'll
add
that
so
to
give
gustavo
some
guidance
here
is
his
close
this
and
just
try
to.
Oh,
I
don't
know
refactor
out
this
go
mod
stuff,
or
should
he
just.
A
I
would
honestly
just
take
the
the
four
signal
stuff
out:
that's
probably
enough,
the
mods
that
are
on
the
signals.
If
we
are
going
to
stick
to
one
particular
mod
for
the
entire
repository.
A
B
I
think
if
that
sounds,
that
sounds
good
yeah.
I
think
that
sounds
good
and
I
think
the
more
I
think
about
the
this
idea
is
like
we're
just
gonna
have
to
kind
of
given
this
is
released
as
a
single
unit
and
they
don't
version
any
of
these
independently
and
the
versioning
is
done
through
here.
We're
just
gonna
have
to
pay
attention
to
like
what
we're
actually
depending
on.
I
guess.
A
D
F
A
B
Yeah,
that's
fair!
That's
a
good
point!
Actually
yeah
yeah,
that's
a
as
as
ted
young
would
say.
That's
a
tricky
wicket
right
there,
okay
yeah!
I
I
think
I
think
I
like
the
suggestions
that
I
didn't
put
forward
so
gustavo.
Does
that
make
sense
what
to
do
here?
Yes,
yes,
okay!
B
Sorry,
it
took
me
so
long
to
respond
to
this.
By
that
I
mean
other
people
are
just
talking
to
you,
okay,
cool
and
then
so.
That
should
essentially
become
a
non-item
for
this
work.
Then
right
like
it,
should
just
be
able
to
progress
without
having
to
have
that
done.
B
Okay,
then
we're
just
back
down
to
getting
some
reviews
on
that
pr:
cool,
the
oh
okay,
the
next
one
is
this
one
talks.
Well,
this
one's
hard,
the
worst
part
about
it
is
it's
like
I
don't
know
it's
probably
50
words
overall,
actually
saying
what
it
needs
to
be
done,
and
it
is
taking
me
a
full
week
at
this
point
to
do
half
of
it
right
now.
So
currently
the
trace
date
and
the
baggage
accepts
strengths.
B
I'm
sorry
accepts
our
attribute
key
values
and
they
shouldn't
according
to
bogdan,
and
so
I
didn't
really.
I
was
trying
to
like
find
it
in
a
specification.
I
was
not
really
convinced
that
they
shouldn't,
but
I've
talked
with
him
a
fair
amount,
just
asynchronously,
and
I
probably
need
to
split
up
these
two
issues
because
they
contain
both
themselves
like
a
lot
of
work.
They're
definitely
gonna
be
different,
different
pr's,
but
the
thing
is
like
the
trace
date
itself.
B
It
makes
a
lot
of
sense
what
he
was
talking
about
and
the
fact
that
it
shouldn't
actually
be
represented
by
attribute
key
value
pairs
because
they
contain
a
type
and
it's
not
necessarily
like.
I
think
the
end
of
the
world,
if
we
you
know
it
seems
very
innocuous.
If
we
allow
that
to
have
that
type
and
then
we
have
a
way
to
serialize
that
type
as
a
string.
The
problem
comes
where
you
do
that,
and
the
user
expects
that
to
work.
B
So
then
you
have
some
sort
of
serialization
process
that
will
serialize
say
some
sort
of
type
of
an
underlying
type
of
a
string
where
an
underlying
type
of
an
integer
would
be
even
worse
right
and
say,
like
an
enum.
I
think
is
the
example
that
I
gave
here
and
they
will
serialize
it
in
one
part
into
the
trace
state
and
then
propagate
it
across
some
sort
of
resource
boundary
that
may
be
into
a
different
process,
maybe
within
the
same
service.
B
You
know
it's
kind
of
un
unknown
how
they're
going
to
use
the
propagator
right
and
then
they
try
to
use
that
same
library
to
deserialize
that
string,
but
the
problem
is,
is
like
we
don't
deserialize
something
that
wasn't
in
back
into
an
end.
We
deserialize
something
that
was
an
in
back
into
a
string
just
because
we
can't
like
that's
how
the
trace
data
is
defined.
It's
defined
as
this
opaque
string.
B
If
there
is
no
types,
there's
no
type
to
understand
like
how
you
want
to
deserialize
a
key
value
like
the
key
is
always
going
to
be
string
with
the
value
is
just.
It
has
to
be
essentially
like
a
series
of
bytes.
B
In
fact,
that's
how
it's
specified
is
like
what
bytes
are
actually
allowed,
and
so
there's
really
no
type
information
there,
and
because
of
that
you're
going
to
cause
the
user
to
unders
like
misunderstand
or
have
a
compiler
or
have
a
panic,
or
something
like
that,
because
you
implicitly
allowed
this
idea
of
types
to
be
put
into
the
trace
state.
And
then
you
aren't
able
to
deserialize
that,
and
I
think,
if
that's
confusing
having
the
trace
state
be
based
off
of
purely
strings.
B
B
So
that's,
I
think,
fair
I've
dug
into
the
trace
date.
I've
got
a
a
pr
started
on
it.
I'm
still
actively
working
on
that
and
like
three
other
things,
so
it's
somewhat
slow
going.
It's
getting
kind
of
big.
I've
also
realized
that
I've
tried
to
like
the
big
part,
is
I'm
pulling
it
out
currently,
there's
yeah
there's
a
big
diff
here,
but
I'm
pulling
a
lot
of
the
trace
state
out
into
its
own
file
because
it
this
this
trace
file
is
just
massive
and
this
is
a
cohesive
unit.
B
So
I'm
trying
to
isolate
this
to
some
sort
of
changes,
but
it's
mostly
just
to
copy
paste,
and
then
there
will
be
a
lot
of,
I
think,
there's
some
different
structure,
changes
that
are
for
the
better
and
I'm
going
to
list
those
but,
like
I
said
still,
an
active
work
in
progress,
so
keep
keep
you
all
posted
on
that.
That
being
said,
like
that's
a
lot
of
words
and
I
think
there's
a
lot
of
thought
that
I've
already
gotten
at
the
tri-state.
B
The
baggage,
on
the
other
hand,
is
a
little
bit
more
interesting
because
it's
not
immediately
clear
if
type
can't
be
included
in
a
baggage,
it's
something
that
has
been
discussed
in
the
w3c,
especially
when
they
were
developing
the
specification
and
they
explicitly
chose
not
to
include
a
type
as
a
metadata
option.
However,
they
didn't
specify
explicitly
that
you
couldn't
do
that,
and
so
it's
this
question
of
whether
we
want
to
actually
support
that
if
we
do
support
some
sort
of
typing
system
there.
B
This
is
something
bogdan
was
kind
of
saying
it
may
be
really
useful
and
it
may
be
really
useful
outside
of
just
go,
because
this
baggage
concept
may
eventually
turn
into
annotations
or
attributes
themselves
on
same
metrics.
If
you
pass
baggage
you
may
a
user
may
want
that
baggage
to
turn
into
attributes,
so
that
conversion,
maybe
may
very
well
actually
need
to
happen
in
the
future.
So
I'm
still
working
with
bogdanon
to
like
understand
like
the
concepts
there.
B
I
really
not
want
to
translate
the
entire
baggage
system
to
just
work
on
strings
and
then,
in
a
later
specification
version,
we
have
to
support
types
types
that
are
already
cast
with
the
attributes,
so
we're
still
working
on
that
sorry
go
ahead.
A
I
was
going
to
say,
with
the
baggage
baggage
carries
along
metadata,
that
we
don't
decode.
At
this
point,
we
only
decode
the
proper
yeah
string.
That
is
true
and
that's
a
problem
yeah.
Well,
it's
an
optional
thing
to
decode
the
metadata,
but
I
think
what
we
should
probably
focus
on.
First
is
meeting
the
decoding,
the
string
and
potentially
the
metadata,
and
then
once
that
is
down,
we
could
add
another
layer
on
top
of
those
to
have
baggage,
plus
that
we
could
encode
a
type
that
everybody
recognizes
in
the
metadata.
B
Okay,
I
see
you're
saying
that's
actually
a
really
good
point,
so
that
was
yeah.
One
of
the
things
is
like
this
pr
is.
There
is
going
to
be
a
need
in
the
pr
specifically
for
what
you
just
said
like
we
don't
actually
handle
the
the
optional
metadata,
but
because
we
don't
do
it,
it
is
going
to
close
things
off
in
the
future
if
things
in
the
optional
metadata
are
become.
B
You
know
important,
like
this
typing
system
or
something
like
that
and
the
way
that
we're
structuring
how
we
like
encode
this
needs
to
kind
of
get
a
rework.
I
think,
based
on
what
I
was
looking
at,
so
I
think
that's.
A
really
good
idea,
though,
is
to
try
to
just
use
this
base
type
system
of
strings,
and
then,
if
we
need
to
add
another
layer
on
top
it
translates
into
our
attributes.
B
B
Yeah,
well,
let
me
tell
you,
I'm
in
a
con
conversation
recording
and
it's
contentious-
let's
just
say
that
so
yeah
no,
but
I
I
agree
like
there's
some
there's
some
solutions
there.
It's
just
they're,
really
keen
on
having
really
positive
use
cases
before
they
want
to
introduce
these
sort
of
things
and
I'm
really
focused
on
getting
a
trace
state
pr
up.
So
I'm
not
like
the
most
active
in
this
conversation,
but
yeah.
B
Really
good
conversation
cool
go
back
to
sharon
here
I
think
the
last
one
is
aaron.
We
kind
of
talked
a
little
bit
about
it.
Maybe
you
can
just
give
an
update
as
to
like
what
you
need
to
make
sure
you're
moving
forward.
A
So
earlier
today
I
turned
this
into
a
full
pr.
I
added
the
metrics
treatment,
which
was
much
simpler
because
we
weren't
munging
around
with
the
span
stuff,
changing
the
spanned
end
and
went
off.
I
think
at
this
point
just
feedback.
B
Okay,
cool
perfect.
That
sounds
great.
I
like
carrying
that,
instead
of
really
hard
solutions
that
we
don't
have
answers
to
yet,
okay,
cool,
I
think
with
that
we
can
go
back
here.
This
is
something
we're
talking
about
a
little
bit.
This
is
something
that
I
think
with
anthony
and
I
are
trying
to
shy
away
from,
but
one
of
us
will
eventually
pick
up,
so
I
think
we
have
a
plan
forward
on
this
rc,
so
I'm
pretty
excited
about
it.
C
B
Us
to
write
is
there
I
think
we
need
to
document,
and
then
we
need
to
go
verify
because
whatever
our
choice
is,
I
think
we
might
have
implemented
the
opposite
in
in
the
past.
So
we
just
need
to
verify
that
we
like
clean
up
anything
that
doesn't
have.
I
don't
know
yes,
I
agree.
B
I
think
I
think
we've
talked
about
this
many
times
and
steve
has
very
happily
added
some
links
to
help
guide
the
conversation
when
I
forget,
but
essentially
it's
don't
do
the
things
that
they
did
there,
where
you're
embedding
a
structure
you're,
embedding
an
interface
and
try
to
you
know
make
it
work
better.
So
there's
I
think
we
have
a
good
solution.
There.
F
I
noticed
that
I'm
not
sure
if
it's
on
one
of
those
two
issues-
probably
there
was
just
traffic
on
it
again
this
week
with
people
still
complaining
about
this
decision.
You
know
they
just
keep
coming
back
to
it
and
going
you
guys
were
unreasonable,
so
not
that
one
apparently
but
yeah,
maybe
the
other
one.
B
Okay,
well
as
a
maintainer
of
this
project,
I
don't
really
want
to
film
any
questions
like
this
that
far
into
the
future,
so
let's
get
it
right
is
all
I'm
saying
and
so
yeah.
We
definitely
need
to
be
careful
about
this
one.
But
yes,
I
think
that
somebody's
just
died.
B
A
So
I
did
a
little
bit
of
a
deep
dive.
What
it
ends
up
being
the
underlying
problem
is
if
we
use
the
proto-go
that
we
created
that
uses
the
default
google
protogen
and
it
provides
zero
way
for
overriding
the
serialization
of
json.
There
is
no
way
the
spec
requires
that
the
bytes
that
are
stored
for
trace
id
and
span
id
to
actually
be
serialized
as
hex
strings,
which
is
not
what
bytes
get
serialized.
A
One
of
those
would
have
to
change
is
at
the
end
of
it.
I
suggest
we
probably
should
drop
http
json
for
the
time
being,
like
it
was
pointed
out,
that's
optional.
A
A
A
A
B
I
agree
yeah
how
we
actually
want.
D
B
When
you're
saying
this
and
talking
about
gustavo's
work,
is
that
he's
actually
building
interfaces?
So
if
we
eventually
like
wanted,
somebody
really
wanted
this
to
be
implemented,
they
could
do
this
in
their
own
module
and
they
could
just
import
it.
That
way,
because
this
is
should
be
really
pluggable
at
that
point,
so
that
could
actually
be
really
cool.
I
I
I'm
leaning
towards
I'm
leaning
towards.
We
should
just
drop
it.
Given
it's
optional,
it's
obviously
not
too
stable.
B
A
I
I
would
also
warn
people
about
that,
because
the
standard
json
library
does
not
deal
with
the
enums
properly
serializing
enums,
as
well
as
a
few
other
things
I
think
date
times
and
whatnot.
They
just
don't
get
serialized
correctly.
So
we
would
have
to
write
a
bunch
of
custom
code
on
top
of
the
generated
code.
B
F
But
sorry
aaron
are
you
saying,
though,
that
for
those
other
things
like
the
date
times
and
the
enums
that
the
grpc
libraries,
sorry,
the
google
proto
library,
whatever
is
generated
there,
that
it
does
it
correctly?
It
just
doesn't
get
the
hex
encoded
strings
versus
the
base64
encoded
strings
right.
So.
A
A
It
deserializes
based
on
grpc
terms,
and
that
is
the
only
call
out
that
we
have
in
the
specification
that
that's
different
from
it.
It
literally
does
say
like
use
the
grpc
json
deserialization,
except
for
trace
id
and
span
id.
F
That's
I
mean
I
wonder
if
in
other
languages
that
are
also
taking
the
protobuf
and
generating
or
what
they,
what
they're
supposed
to
be
doing
with
it
is
generating
serializers
and
deserializers.
What,
if
they're
running
into
the
same
problem?
It's
not
the
natural
way,
apparently
to
deal
with
it
right.
A
It
seems
like
it's
a
little
easier
to
override
those
functions
for
those
types
in
the
in
the
languages
that
have
gone
this
way.
The
the
real
thing
is,
I
think,
the
only
other
implementation
that
does
this
right
now
is
the
javascript
one,
and
I,
from
the
readings
there,
I
don't
think
they
actually
use
a
generated
grpc,
oh
right,
yeah,
because
it
was
way
too
loaded
or
something
like
that.
Yeah.
B
Like
a
handwritten
serializer,
I
am
really
interested
to
hear
what
david
ash
paul
has
to
say
about
this
if
you've,
if
you've
made
a
or,
if
you're,
paying
attention,
sorry
to
call
you
out,
but
I
just
like
at
google.
I
imagine
you
guys
have
seen
this
before
right,
like
you,
want
to
do
some
sort
of
deserialization
of
some
protobuf
with
the
json
package
and
like
it
just
doesn't.
Allow
you
to
overwrite
a
field
at
all.
B
G
You
should
really
ask
we
should
really
ask
josh.
I've
only
worked
in
open
source,
and
sadly
that
means
that
I
haven't
really
dealt
with
protos
very
much.
B
Okay,
I've
heard
josh
say:
eventually
you
have
to
write
your
own
deserialization
for
protobuf.
It
doesn't
matter
like
how
long
it
takes,
but
eventually
it'll
happen,
and
I
think
that's
gonna
be
his
answer
here.
F
I
remember
something
analogous,
I'm
not
sure
if
it's
still
in
there,
but
it
used
to
be
the
case
that
when
you
were
serializing
n64s
un-64
is
that
a
protobuf
that
for
the
for
the
json
stuff,
or
at
least,
if
I
just
say
for
the
javascript
compatibility,
would
automatically
convert
them
to
strings
because
the
the
numeric
capacity
of
the
integers
in
javascript
couldn't
handle
it.
That's
right,
yeah
everything's,
a
float,
56
bits,
so
you
get
456.,
yeah,
okay
out
of
budget,
so
yeah.
F
That
seems
like
another
thing,
that's
sort
of
in
this
area,
but
I
understand
that
here
our
spec
chose
something
for
compatibility
with
a
different
spec
right
and
they
were
hoping
for
just
lossless
conversion.
A
Yeah,
I
honestly
think
like
it
probably
wouldn't
I
don't
know
how
hard
it
would
be
to
implement
a
collector's
side
to
accept
both
like
that
would
probably
be.
The
proposal
that
I
would
make
is
to
accept
either
basic
c4
or
hex,
because
these
are
fixed
size
strings.
You
can
determine
distinguish
the
size.
You
can
distinguish
what
which
encoding
scheme
you
have
based
on
the
size.
A
Of
the
of
the
string,
because
a
base64
is
slightly
more
compact
than
a
hex
string,
but
I
don't
know
if
they
would
be
willing
to
support
that
or
not
and
like.
I
don't
there's
a
lot
there
and
I
think
the
the
short
term
is
to
close
to
remove
that
and
then
the
long
term
is
to
maybe
add
it
back.
If
we.
C
And
it
wouldn't
just
be
the
collector,
though
it
would
be
anything
that's
implementing
otlp
with
the
json
encoding.
So
any
any
vendor
who
has
an
otlp,
ingest,
endpoint
and
wants
to
accept
the
json
encoding
would
also
have
to
deal
with
that,
and
I
think
that
propagates
a
lot
further
than
just
the
collector
it
does
yeah.
I
I
think
our
best
approach
here
is
aaron
as
you
outlined
move.
It
move
it
over
from
the
existing
exporter
into
the
new
location,
where
it's
going
to
be
and
then
cut
it
in
a
separate
pr.
C
Before
we
have
a
an
rc,
I
think
there's
currently
an
option
for
specifying
a
marshalling
type.
Maybe
we
keep
that,
but
keep
only
one
value
in
its
enumeration
and
we
can
add
another
one
later
just
so
that
we've
got
that
surface
there
and
keep
kind
of
this
is
the
way
it's
going
to
be
done
when
we
decided
to
do
it.
If
we
decided
to
do
it
but
cut
it.
B
Yeah,
I
think
we
should
cut
it.
I
agree:
okay,
keeping
us
moving
forwards.
I
think
I
it's
well
all
right.
I
don't
know
that's
the
most
prudent
to
talk
about
anthony's
might
be
a
little
more
important,
but
the
contrib
mid
version
pr
stalls.
This
is
blocking
updates
from
dependebot.
At
this
point
we
have
dependencies
that
require
1.15.
So
if
you
could
use
some
eyes,
that'd
be
ideal.
Anthony
responded
to
some
of
your
or
all
your
questions,
so
you
should
just
take
another
look.
I
appreciate
it.
B
It's
definitely
not
highest
priority,
and
with
that
maybe
we
could
talk
a
little
bit
more
about
gustavo's
pr.
You
wanted
to
talk
a
little
about
paralyzing
that
anthony.
C
Yeah,
so
I
guess
the
question
here
was
just
that
in
the
pr
he's
listed
out.
I
think
you
know
eight
or
nine
steps
that
we
need
to
take
to
to
get
it
done.
So
I'm
just
wondering
gustavo,
do
you
have
any
feedback
on?
Is
there
anything
we
can
do
to
split
up
that
work
and
parallelize
it
or
are
there
interdependencies
that
mean
it's
gonna
have
to
be
sequenced.
E
I
guess
only
the
next
few
steps
that
can
be
done
by
much
more
people.
I
guess
if
we
accepted
this
other
people
can
take
some
of
these
steps.
C
E
B
Okay,
that
sounds
like
a
great
idea.
What
I
would
recommend
doing
is
if
we
could
take
the
the
examples
and
the
docs
update,
stuff
and
spec
that
out
into
their
own
issues,
and
then
we
could
visualize
the
work.
I
think
a
little
better
that
way
and
we
could
have
other
people
help
in
that
process.
It
sounds
like
both
of
those
are
also
still
going
to
be
blocked
based
on
this
pr,
so
we
need
to
get
this
merged
before
we
do
that,
but
yeah
I
like
that
idea.
B
I
think
the
the
biggest
thing
that's
going
to
hold
this
up
is
just
pr
reviews,
it's
which
is
unfortunately,
always
the
case
here
so
yeah.
I
think
that
it's
just
about
prioritizing
that
I
think
more
than
actually
breaking
these
up,
I'm
sure
you've
probably
got
some
branches
already
staged
to
get
these
in,
but
yeah.
I
think
that's
a
good
approach.
B
Can
you
be
sure
to
create
issues?
If
I'm
understanding
it's
these
two
right
here
would
be
their
own
separate
issues.
Could
you
create
those
issues
once
this
gets
merged?
Yes,
okay,
cool
anthony.
Do
you
think
that
helps
at
all
yeah?
I
think
so.
Okay,
cool:
I
think
that
that
is
everything
on
the
agenda
and
talk
through
everything.
We
have
plenty
of
time
left.
So
if
anybody
else
had
some
other
things,
I
also
realized
there's
a
lot
of
work
to
do
so.
We
can
probably
end
it
early
as
well.
B
I
would
love
to
hear
any
cool
implementation
stories
as
well.
These
are
always
really
inspiring
if
someone
on
the
call
is
using
open
sonography,
even
if
it's
just
real
basic
I'd
love
to
hear
about
it,.
G
I
have
a
story
I
can
share.
I
hopefully
I
didn't
already
announce
this,
but
I've
been
trying
to
get
kubernetes
to
use
tracing
for
a
while
right
and
as
a
sort
of
coordination
effort.
I
also
opened
an
issue
with
fcd
saying
hey
by
the
way.
If
kubernetes
has
tracing
in
the
api
server.
Well
then
you
know,
if
you
also
have
tracing,
we
can
kind
of
be
buddy
buddy
and
have
traces
all
connected
right.
G
That
would
be
cool
and
it
turns
out
they're
much
quicker
than
I
am
so
fcd
has
tracing
with
open
telemetry
implemented
before
kubernetes
does
so,
mostly
because
I'm
blocked
on
a
dependency
update,
from
wit
for
the
xcd
dependency.
So
as
soon
as
I
get
that
in
it
should
be
fairly
straightforward
and
then
but
fcd
has
tracing.
That's
the
the
big
announcement.
G
G
Because
we
didn't
want
to
be
tied
to
a
particular
back
end,
I
think
was
the
main
thing
and
we
saw
that
it
being
sort
of
the
most
collector
native.
We
said
yeah,
so
you
should
run
a
collector.
You
should
figure
out
where
you
want
it
to
go
and
you
should
run
the
collector
as
a
static
pod
alongside
cd
in
the
api
server.
B
That's
well,
first
off
this
backup.
That's
super
exciting.
To
hear
that.
I
think
that
everyone
on
the
call
that's
contributing
to
this
library.
You
know
you're,
essentially
a
dependency
of
kubernetes
and
ncd
eventually,
so
I
don't
know-
I
don't
know
if
you're
better
than
that,
but
no,
no,
it's
not
at
all,
but
no,
that's
just
like
it's
super
exciting
to
have
some
user
base.
That
is,
that
extensive
taking
on
this
dependency,
so
really
cool
here.
Thanks
for
sharing
that.
F
The
export
of
some
programs
that
that
trace
calls
to
the
api
server,
but
then
it
hits
a
black
box
right
so
really
interesting
to
see
it
go
through.
F
What
I
do
is,
I
take
sorry
they're
not
right
now,
but
there's
nothing
proprietary
about
it.
I
I
just
I
just
wrap
the
the
http
transport.
That's
used
by
a
client
go
rest
client.
F
G
Yep
and
actually
clientgo
will
also,
if
I'm
successful
with
tracing
in
kubernetes
clientgo
will
include
the
hotel
http
stuff
in
it,
so
you
won't
hopefully
have
to
do
that
yourself.
I.
F
That's
nice!
I,
like
it
steve.
B
B
A
I
I
wish
they
had
that
when
I
last
wrote
a
operator
yeah.
F
I
I
wrote
an
operator
that
I
instrumented
pretty
heavily,
and
I
want
to
say
it
was
like
70
of
the
code
was
the
instrumentation,
but
it
was
great
because
it
was
like
it
was
just
deep
inspection
that
you
could
do
of
what
it
was
doing
at
any
time.
C
Yeah,
I've
linked
a
couple
things
that
I
I've
noticed
that
are
really
cool
as
well
they're,
using
the
go
sdk
some
in
interesting
ways,
the
the
first
one
that
I
linked
caseband
tries
to
make
spans
out
of
kubernetes
events,
and
it
is
kind
of
an
interesting
use
of
our
sdk,
because
it's
actually
not
instrumentation.
It's
not
using
the
api.
It's
an
application
built
using
the
sdk
that
takes
information
and
constructs
fans
out
of
them
that
it
then
ships
to
an
exporter
which
is
different
from
the
the
normal
way.
C
We
normally
see
people
using
just
the
api
with
an
instrumentation,
and
I
thought
that
was
really
cool
to
see
how
they
do
that
and
then
the
other
is
hotel,
cli,
which
is
uses
the
the
go
sdk
and
api
to
provide
a
cli
for
constructing
spans.
So
you
can
do
things
like
instruments,
your
bash
scripts
start
a
span,
stop
a
span
all
that
sort
of
stuff
which
is
very
cool.
F
C
Spirit
yeah
liz
lucio
today
was
talking
with
someone
on
one
of
the
slacks
who
couldn't
use
build
events
because
they
were
on
windows
or
something
like
that,
and
just
the
support
wasn't
there.
She
said:
well,
you
can
use
hotel
cli
and
it
does
the
same
sort
of
thing.
A
A
B
I
think
that
you
can
I'm
looking
for
the
contributing
yeah
they're
they're
open
to
contributors
yeah.
These
are
all
really
cool.
Are
you
I'm
guessing?
These
are
gonna
make
it
into
talks
at
some
point.
C
Right
there
was
a
talk
at
kubecon
eu
about
case
span.
I
didn't
get
to
see
it.
I
assume
the
video
will
be
available
shortly,
but
michael
housingblast
from
aws
was
there
and
linked
me
to
that
and
oh
tell
cli.
I
would
assume
at
some
point
probably
yeah.
B
Yeah,
okay
and
then
david
as
well
the
kubernetes
stuff,
I'm
guessing
right
that
that
I'm
sure
that'd
be
a
really
cool
channel.
G
Oh
yeah,
I
mean
I
gave
a
demo
of
open
census
based
stuff-
that's
all
similar
to
this
in,
like
2018.,
so
I'll
I'll
do
a
rerun
with
it
actually
in
core
at
some
point.
Hopefully,.
B
Yeah
I
this
is
all
really
exciting.
I
don't
I
don't.
I
think
I
can
just
say
this
for
like
the
next.
You
know
15
minutes.
This
is.
B
B
Awesome
well
thanks
everyone
for
joining
thanks
everyone
for
the
hard
work,
as
you
can
hear
from
these
stories
like
it's
paying
off
like
it's
only
gonna
get
better,
so
I
appreciate
everyone
and
all
the
contributions
everyone's
making.
So
again,
thanks
for
joining-
and
I
will
see
you
all
virtually
or
next
week
soon
very
good
bye.
Thank
you.