►
From YouTube: 2021-08-19 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
Doing
pretty
good
yeah,
just
chugging
through
issues
and
work,
and
everything
like
that
yeah,
the
weather
in
portland,
has
gotten
bearable.
So
that's
a
that's
a
huge
plus
glad
to.
C
A
It's
getting
pretty
chaotic,
it
used
to
just
be
like
sunny
and
fantastic
summers
and
then
rain
and
now
you're.
Just
like
I
don't
know.
I
don't
know
right
now:
there's
no
smoke
either.
It's
pretty
great
yeah.
A
Oh
boy
cool:
well,
I'm
looking
at
the
time
where
a
minute
passed,
we
could
probably
get
started.
I
don't
think
we
have
too
much
on
the
agenda
for
today.
So
if
you're
here
please
add
yourself
to
the
attendees
list,
and
if
you
have
something
you'd
like
to
talk
about,
please
add
it
to
the
agenda.
A
I
will
figure
out
how
to
share
a
screen,
looks
like
they're
one
cool,
yeah,
okay,
awesome,
we'll
jump
into
the
project
board
here
for
open
symmetry,
go
1.0
push
and
we
can
kind
of
start
it
off.
This
way,
there's
probably
actually
not
too
much
to
talk
about
this
week.
A
lot
of
prs
just
got
merged
the
first
half
of
the
week,
essentially
cleaning
out
all
of
the
hotel
test
dependencies.
A
The
hotel
test
package
itself
has
been
deprecated,
hasn't
been
released
as
a
deprecated
package
yet,
but
that
will
be
included
in
the
next
release
and
there's
recommendations
to
use
the
new
trace
test
package
with
the
default
sdk.
A
If
you
haven't
been
following
that,
that
was
a
big
one
yeah,
so
that's
all
done
the
verifying
and
update
of
otelp
trace
export
documentation
is
still
working.
I
was
just
looking
at
it
this
morning,
there's
a
few
more
requests
for
changes
that
have
come
in
and
it's
just
being
iterated
on
it
looks
like
yeah.
I
think
david
had
a
few
more
so
yeah
still
working
on
that.
A
As
for
the
remaining
five
issues
to
do,
I've
been
looking
through
these
I'd
like
to
talk
a
little
bit
about
these
to
start
off
the
meeting.
Specifically
these
first
four,
probably
this
last
one's
a
little
bit
more
nebulous
this
one.
I
would
love
to
get
some
more
feedback
on.
A
I
talked
a
little
bit
about
like
a
poll
last
time
I
looked
into
this,
and
so
the
proposal
right
now
is
just
for
people
who
are
not
familiar
with
issue
is
through
using
the
examples
that
are
included
in
the
documentation
and
setting
up
things.
A
This
import
of
something
that's
aliased
by
sdk
trace
requires
that
you
have
likely
already
aliased
it
in
the
import
path.
Sometimes
it
can
figure
it
out.
Sometimes
it
can't,
depending
on
your
tooling,
depending
on
context
of
your
tooling
there's
a
lot
of
things
that
can
make
that
challenging.
So
this
is
proposing
renaming
the
sdk
trace
package
to
sdk
trace.
A
I
was
looking
through
this
and
one
of
my
questions
was:
what
else
would
this
change?
There
was
proposal
that,
maybe
is
be
symmetric
stuff,
which
probably
needs
to
happen,
but
given
the
experimental
state
I
was
recommending.
We
probably
stay
away
from
that.
At
this
point
and
more,
I
was
looking
at
the
fact
that
the
trace
test
package
sits
within
the
trace
package,
so
that
would
probably
become
the
sdk
trace,
trace
or
sdk
trace
test
package,
which
I
said
well,
I'm
not
unprecedented
starting
to
become
cumbersome.
A
So
I'm
guessing
that's,
probably
shared
sentiment,
but
just
wanted
to
make
sure
that
it
was
clear
to
anybody
who
is
evaluating
the
choices
in
this
issue
that
that's
probably
something
we
want
to
include
in
the
change.
If
we
are
going
to
accept
it.
A
I
think
that
this
also
has
pointed
out
that
in
1014
we've
already
kind
of
gone
through
this
exercise
a
little
bit
and
asking
you
know
like.
Why
would
we
want
to
change
this
and
I
think
the
sentiment
that
was
what
was
used
to
close
this?
Was
that
there's
this
understanding
that,
like
it
can
happen
where
you'll
import,
both
the
api
and
the
sdk,
but
often
you
will
only
be
importing
one
or
the
other
so
aliasing.
It
is
not
necessarily
something
that
you're
going
to
see
a
lot
in
the
wild.
A
That
said,
I
just
spent
the
past
week
ripping
out
hotel
tests
and
working
with
these
aliases
and,
like
I
don't
know,
probably
20
different
packages.
That's
not
even
hyperbole
and
they're
aliased
differently,
all
over
the
place.
So
I
I
don't
know
what
the
wild
looks
like
is
all
I
can
say.
I
do
know
that,
like
yeah
steve
steve
knows,
maybe
he
can
china,
so
I
I.
B
Spent
much
of
yesterday
and
part
of
today
trying
to
retrofit
a
project
that
uses
open
senses
to
open
telemetry,
and
so
I've
been
knee
deep
in
the
whole
sdk
initialization
part,
which
seems
to
be
like
I've
rewritten
this
code
like
five
times
now.
B
You
know
I've
mentioned
this
pursuit
before
and
what
I
find
is
that
I'm
going
back
and
I'm
copying
and
pasting
my
import
statements
into
the
new
code
as
I'm
copying
and
pasting
little
snippets
of
code
that
I've
gotten
worked
before,
and
I
mean
I
remain
opposed
to
this
proposal
more
like
more,
because
I
think
that,
for
aesthetic
reasons
the
packages
should
be
named
as
they
would
be
named
if
they
stood
in
isolation.
B
B
I've
noticed
more
difficulty
with
things
like
the
semconf
package,
which
has
you
know,
aversion
string
in
its
tail,
that
that
confuses
my
tooling,
and
I
have
to
alias
that.
One
then
forget
that
that
I've
got
it
wrong,
but
other
than
that
I
haven't,
I
haven't
really
found
too
much
trouble
with
copying
and
pasting
the
import
statements.
So
in
other
words,
I
think
that,
if
that,
if
the
documentation
and
example
code
has
the
import
statements,
aliased
people
would
copy
those,
just
as
they
copied
the
little
code
snippets
that
are
using
those
analysis.
A
Yeah,
I
think
that
that's
agreed.
I
think
that
some
people
find
that
annoying,
which
I'm
not
necessarily
saying
that
that's
a
good
enough
reason
to
motivate
this
change.
I
mean
I
find
it
annoying
as
well,
but
I
also
think
that,
like
the
goal
is
to
just
yeah,
I
think
semcomp
could
probably
cause
more
annoyance
than
I
think
this
will,
particularly
because
I
think
semkov,
like
the
way
that
it's
imported
it
kind
of
requires
you
to
aliase
it
like
you're.
A
Never
gonna
refer
to
the
package
of
the
version
name
itself,
so
that
I
think,
is
more
of
an
issue
I
think
than
this
and-
and
I
think
we
would
probably
want
to
keep
the
simcom
the
way
it
is,
although
I'm
definitely
open
to
hearing
proposals.
Otherwise.
So
I
kind
of
agree
and
then
on
that
last
point
you
kind
of
made
about
this.
You
know
the
example
code
and
making
sure
that
if
you're
copying
code,
snippets
you're
copying
the
import
statement.
A
I
think,
if
that's
a
that's
a
good
point
like
we
could
you
know,
given
this
assumption
that
you
know
90,
maybe
80
of
the
use
cases
are
only
going
to
have
the
api
or
the
sdk,
making
sure
that
we
design
examples
to
not
have
aliases
and
be
confined
to
just
the
api
or
just
the
sdk
or,
if
they're
going
to
be,
including
both
put
them
in
different
files,
or
something
like
that,
I
think,
would
be
ideal.
A
The
only
place
that
I
actually
saw
this
aliasing
happening
is
in
the
website
docs
and
out
of
all
of
the
docs.
I
think
we
do
a
pretty
good
job,
except
for
this.
This
is
like
the
one
spot.
So
if
we
could
rewrite
this
in
some
way
where
essentially,
you
have
like
your
instrumentation
stuff
in
one
file
and
then
you
have
your
sdk
set
up
and
another
file,
this
alias,
wouldn't
exist,
and
it
may
be
a
little
bit
clearer
to
the
user.
A
It
may
also
not
be
because
it
won't
be
a
single
file,
so
I
mean
like
I
it's
something
I
think
to
think
through,
but
it
may
also
be
something
we
can
address.
The
overall,
you
know
ask
in
this
in
this
issue
here.
B
I
still
think
that
just
out
a
little
more
fervor
that
kind
of
stuttering
names
that
we're
proposing
here,
to
my
mind,
it
makes
it
look
like
you,
don't
know
how
go
works,
but
in
practice
I
understand
that
what
we're
more
saying
is
like
we
see
exactly
how
it
works
and
quite
often
it
doesn't
work
well
enough
for
it.
It
gets
clumsy
with
the
tools
that
we
have
available
today,
but
I
think
it's
a
it's
a
sad
wart
to
put
in
there.
A
I
agree:
there's
a
lot
of
things
that
I'm
coming
to
understanding
of
like
the
package
management
system
and
go
and
like
name
spacing
as
well,
that's
kind
of
annoying,
but
I
I
I
would
like
it
if
we
didn't
have
that
veneer
of
we
wrote
this
project
and
we
didn't
know
what
we're
doing
that
is
a
that
was
a
great
way
to
alienate
the
go
community,
which
is
not
something
I
would
like
to
do.
I
think,
though,
that.
E
For.
I
think
precisely
these
reasons.
All
of
that
said,
though
I
think
I
agree
with
both
of
you
that
this
is
not
a
change
that
we
should
be
making
at
this
time
and,
if
we're
not
making
it
now
we're
not
making
it
ever.
A
Okay,
that's
good
feedback,
I'm
I'm
hearing
from
the
community
that
we
want
to
close
this
issue
without
any
change
of
package
names.
I'd
like
if
anybody's
on
the
call
that
has
a
different
opinion
that
we
should
change
the
package
name.
I
please
don't
feel
intimidated.
I
really
just
want
to
hear
input,
even
if
you
just
want
to
say
yes,
I
do.
B
A
Kind
of
using
this,
I
think,
that's
that's
what
was
referenced
here
in
this
unprecedented
cumbersome
naming.
Is
that
exactly
that?
We
we
do.
You
know
if
we
did
the
sdk
trace,
then
we'd
have
to
do
the
sdk
trace
test
which
is
kind
of
what
we
do
in
otlp
otlp
trays,
hotel,
e-trace,
grpc,
glp,
trace
http,
the
metrics
one.
You
know
yeah,
there's
definitely
like
already
this
doubling
up
here.
B
A
A
Practices
saying
like
you
know,
making
sure
that
you
don't
take
good
variable
names
or
other
names
from
users,
and
I
think
that's
a
good
one
to
like
point
out
is
like
our
package
name
should
try
to
not
be
something
that
is
going
to
are
going
to
conflict
with
other
packages.
You
know,
I
think
that
that
is
lower
on
the
priority
list
than
trying
to
make
you
know
taking
things
away
from
the
user,
but
I
do
think
that
that's
something
that
is
going
to
drive
the
user
crazy.
A
B
Yeah
yeah
within
this
package,
I
expect
to
see
names
like
trace
and
metrics.
Like
you
know
what
you're
talking
about,
but
grpc
would
be
something
in
isolation.
I'd
expect
it
to
be
about
something
like
out
of
the
grpc
libraries
themselves,
as
opposed
to,
like
you
know,
conflicting
with
openstack.
A
Yeah-
and
this
is
definitely
turning
into
a
huge
bike
shed
unfortunately,
but
like
I
totally
see
the
the
problem
here,
though,
as
well,
is,
if
we're
starting
to
talk
about
exporters
and
if,
instead
of
the
otlp
otp
trace
name,
we
put
here,
we
just
put
trace.
You
would
almost
certainly
have
a
conflict
with
the
trace
from
here,
conflicting
with
the
trace
from
sdk
trace,
because
you're
going
to
be
importing
the
sdk
trace
at
the
same
time
that
you're
going
to
be
trying
to
set
up
your
export
for
almost
like
90
of
the
time.
A
So
there
would
definitely
be
a
conflict
there.
So
maybe
that's
a
good
motivation
to
have
this.
This
name
structured
this
way
here,
I'm
I'm,
maybe
grasping
at
straws
a
little,
but
I
don't
know.
I
think
that
there's
it's
a
tough
one
that
I
don't
know
if
there
is
a
generalized
rule,
that's
going
to
get
it
right.
Every
single
time.
A
A
I'm
going
to
leave
a
little
note
so
that
I
can
probably
try
to
close
this.
I
think
after
the
meeting
and
leave
a
little
comments
about
that
cool.
I
wanted
to
talk
about
probably
these
next
three,
this
last
one
I
wanted
to
just
kind
of
hold
off
on.
I
think
until
we
get
all
of
them
done
and
then
we
can
put
a
little
more
strategy
in
from
the
community
standpoint.
A
I'm
asking
about
these
because
I'm
looking
at
this
project
board
and
I'm
saying
to
myself
what
do
we
have
to
do?
That's
next
and
obviously
there's
five
to
do.
This
is
still
hanging,
but
I
think
if
that
just
needs
some
attention,
but
after
after
we
get
these
done
like
we're
ready
for
an
rc,
I
think
we're
definitely
ready
for
a
release,
so
we
can
get
some
feedback.
I
guess
is
how
I
look
at
it.
So
how
do
we
get
through
these
last
four
issues?
A
And
I
want
to
prioritize
conversation
in
this
meeting
to
make
sure
that
happens.
I
know
that
the
community
and
a
lot
of
vendors
are
excited
to
get
stale
releases,
as
well
as
people
that
have
been
working
on
this
project
for
a
while,
who
I
I
may
be,
including
myself
in
on,
and
so
I
want
to
make
sure
that
we
prioritize
talking
about
these
today.
A
A
I
don't
know
if
anybody
else
has
any
id
any
other
ideas
around
this
I've
been
thinking
about
it
and
if
this
is
involving
adding,
maybe
say
a
resolve
spam
conference,
config
method,
I
would
be
more
inclined
than
replacing
for
the
same
reason
that
renaming
the
package
at
this
late
point
in
the
game
is,
is
going
to
be
kind
of
hard
and
disruptive
to
people
who
are
staging
assuming
a
stable
release
coming
out.
So
I'm
not
really.
A
I
don't
know
if
I'd
be
okay
with
doing
this
part.
If
we
wanted
to
add
that
might
be
something
I'd
be
more
inclined
to,
but
I
also
think
that
like,
if
you
know,
there's
a
hard
opposition
to
adding
something
like
a
resolve
stance,
config
just
to
resolve
this,
then
I
don't
even
think
we
should
pursue
it.
If
there
is
a
desire,
I
think
that
we
should
do
the
benchmarks
and
we
should
say
like
hey
like
yeah.
This
can,
in
theory,
get
rid
of.
A
You
know
an
allocation,
but
that
allocation
is
in
the
first
gc
cycle.
So
like
that's
it
like.
That's
all
that
that
you
know
the
first
gc
compaction
gets
rid
of
it
and
you're
done
like
so.
What's
the
problem
yeah,
so
I
I
don't
know
like
that's
something
I
think
we
could
make
a
com.
You
know
a
concerted
effort
to
show.
This
is
not
something
we
want
to
work
on
either.
I
don't
know
if
anybody
has
any
opinions
about
this
one.
E
E
E
A
I
think
yeah,
that's,
that
is
a
little
frustrating.
I
think
bogdan
is
right
in
the
fact
that
the
new
startsman
config
makes
a
pointer
and
then
that
pointer
escapes
the
function,
but
I
I
think
that
that's
an
assumption,
I
think
you're
right.
We
should
validate
that
or
it
should
have
been
validated
with
the
creation
of
this
issue.
A
I
also
don't
want
to
just
discount
it
because
I,
based
on
my
understanding
of
the
heap
allocation,
that
makes
sense
to
me,
but
I
yeah,
I
I
see
what
you're
saying.
F
F
Wouldn't
that
just
make
alleviate
the
concern
that
seems
pretty
straightforward
and,
like
simple.
E
F
Then,
if
you're,
you
know
the
clever.
The
clever
reader
among
us
will
know
that
inside
of
that
code,
when
you're
reading
that
for
loop,
that
ranges
over
the
options
and
then
applies
it,
you
need
a
pointer,
otherwise
you're
passing
an
immutable
struct
to
and
from
so
you
can
change
your
apply.
You
can
like
go
to
this
link.
Here's
where
I
I've
seen
this
before.
You
can
go
to
some
length
to
change
your
apply
function
so
that
your
apply
takes
a
struct
and
returns
a
struct.
F
That's
been
modified,
which
is
error
prone
and
we've
seen
that
and
that
and
then,
at
the
end
of
the
day,
you've
done
a
bunch
of
work
to
make
it
so
that
there's
no
pointer
anywhere,
and
I
think
that
you
go
too
far
by
trying
to
avoid
any
pointers,
because
the
compiler
may
have
to
like
it
looks
like
there's
a
pointer,
but
the
compiler
can
be
smart
enough
to
avoid
that
keep
allocation,
and
that's
where
I'd
like
to
lean
on
the
compiler,
but
on
the
surface
of
it.
F
F
Assuming
that
no
global
right
implementation
of
the
tracer
interface
ever
captures
one
of
those
config
sorry,
what
I
actually
mean
is
that
none
of
the
methods
that
take
a
pointer
in
those
apply
functions
so
all
the
options.
If
none
of
them
captures,
then
the
compiler
can
deduce
that
nothing
ever
captures.
One
of
those
pointers
is
what
I
think
is
is
required.
B
F
Yeah,
it
would
be
nice
if
there
were
already
some
benchmarks.
I
I
feel
like
there
used
to
be
benchmarks
like
what
what's
going
on
here.
Does
sdk
trace
had
benchmarks.
F
A
Yeah,
I
don't
know
if
they're
for
any
of
the
configs,
though
I
don't
want
to
drive
too
much
into
the
just
pair
programming
in
this
meeting
yeah.
So
maybe
we
can,
I
think,
put
this.
A
I
think
the
answer
to
my
question
is:
is
that
we
need
to
put
some
time
and
effort
into
investigating
this,
so
we
can't
just,
I
think,
outright
close
it,
which
I
think
is
what
I
was
looking
to
try
to
resolve
here
in
the
meeting
in
the
conversation
or,
I
think,
having
a
plan
forward
for
somebody
who
does
want
to
pick
this
up,
which
sounds
like
yeah.
It
doesn't
sound
too
complex.
Just
needs
like
josh
is
saying,
like
look
at
the
benchmark,
find
the
benchmarks
find
some
sort
of
solution.
A
I
think
it's
important
the
newspaper
I
didn't
realize
it's
the
start
stage.
It.
A
A
Yeah
the
thing
is:
is
that
a
lot
of
the
yes
you're
right?
The
a
lot
of
the
configs
outside
of
the
trace
api
are
not
exported.
All
of
the
new
creation
functions
are
supposed
to
be
internal,
which
may
alleviate
a
little
bit
of
the
issue,
but
I
think
you're
right
if
this
is
going
to
apply
to
all
even
just
the
api
like
that
is
going
to
be
somewhat
of
a.
We
need
to
take
that
seriously.
I
guess
if
it's
just
changing
the
return
type
from
a
pointer
to
a
struct
itself.
E
A
We'll
need
to
add
some
ampersands,
I'm
sure
in
a
few
places,
but
we
can
work
on
that.
A
A
I
have
left
this
open
by
request
of
bogdan,
but
I
thought
the
consensus
from
the
community
was
that's
cool.
That
should
be
what
it
is.
You
should
never
be
doing
type
conversions
without
going
through
some
sort
of
like
switch
or
conversion
function
that
talks
about
the
under
like
the
the
type
itself.
A
Otherwise
you
get
into
situations
like
this,
which
was
a
bug
that
was
found,
and
so
I
think
that,
like
as
long
as
that's
resolved-
and
you
have
conversion
functions,
I'd
rather
not
just
have
it
so
that
you
can
convert
from
the
codes
that
codes
and
then
just
wrap
that
in
some
sort
of
type
assertion
to
make
that
proto
code.
But
I
left
this
open
in
case
the
community
wanted
to
comment
more
on
it,
and
I
haven't
seen
much
more
comment.
A
E
Okay,
I
agree:
we've
already
got
the
translation.
People
should
be
using
that
translation.
I
don't
know
adding
more
documentation
and
it's
not
going
to
stop
people
from
trying
to
do
the
wrong
thing
if
they
can,
but
we've
provided
the
way
to
do
it
properly.
A
Yeah
I
was
almost
like-
I
almost
wanted
to
make
like
our
status
codes
in
the
negative
range
just
to
make
sure
they
never
overlapped,
but
I
think
that's
a
little
bit
more.
It's
like
anti-coupling
at
that
point.
So
maybe
we
just
stick
to
saying
use
the
conversion
functions.
A
Okay,
cool!
The
next
thing
is
this
split.
The
span
config
into
the
start,
span
config
and
span
config
again.
This
is
something
that
has
been
proposed
in
the
in
the
past.
It's
just
something
that
we
need
to
kind
of
go
through
the
motions
on.
I
don't
know
if
anybody
has
any
like
desire
to
just
close
this
or
if
they
think
this
is
something
that
we
can
still
work
on.
I
guess
is
my
question
to
the
community.
F
Well,
I
guess
there's
this
history
that
I
collect
from
a
long
time
ago,
where
open
census
had
a
thing
called
span
data
which
was
an
explicit
piece
of
data
that
you
could
pass
into
the
tracing
sdk.
That
was
like
here's
your
whole
span
all
at
once,
and
we
argued
that
out
of
existence
by
saying
that
every
field
that
you
might
be
able
to
set
through
a
span
data
object.
F
You
should
be
able
to
set
through
a
trace,
start
span
option
and
then,
but
obviously
things
like
latency
can't
be
set
until
the
end,
and
that's
where
that
you
get
this
notion
of
there
being
different
configs.
But
if
you
go
back
to
this
start
of
time,
I
guess
you
know
like
sometimes
you're
just
going
to
want
to
like
here's
a
span
and
hear
of
all
all
of
its
properties,
including
the
latency,
and
that's
why
you
end
up
kind
of
saying
well.
In
that
case
I
might
just
want
to
have
one
config.
F
A
Yeah
and
I
kind
of
agree
and
the
the
way
we
had
this
conversation
last
time
was
also
to
point
out
that,
like
we
have
one
config,
but
we
have
options
that
are
scoped
to
what
can
be
passed
to
those
functions
like
you
can't
pass
the
spam
the
n-span
option
to
the
start
of
a
spam.
You
can't
pass
the
start
span
option
to
the
end
of
the
span
right
and
like
those
both
work
on
the
span
config
and
like
they
will
def,
they
will
apply
to
a
spam
config,
but
to
the
user's
perspective.
A
They
don't
they
don't
work
with
the
spam
config
like,
but
you
know,
as
the
developer,
you
may
want
to
extend
it
in
the
future.
You
may
want
to
like
use
it
in
ways
that
we
don't
see
right
now,
and
I
like
that
going
forward.
You
know
otherwise
in
the
future.
If
we
split
this
and
all
of
a
sudden,
we
realize
like
well
this
yeah,
like
maybe
you
want
to
retroactively,
create
span,
so
I
need
something
that
comprehensively
has
all
of
the
fields
for
a
span.
A
Well,
that
now
we
need
a
span
config
or
something
like
that.
I
don't
know
like
there
are
things
that
I
just
like
the
it's
still
scoped,
but
it
has
extension.
Extensibility
was
why
I
was
really
into
this.
So
what
happens
today.
E
B
E
Pass
the
end
you
can't,
though,
because
you
pass
them
through
the
span
start
or
the
start
span,
options
or
the
n-span
options
and
start
and
end
only
accepts
those
types
so
that
it
doesn't
accept
a
config
directly.
It
accepts
the
option
types,
the
interfaces
that
operate
on
that
config
and
they
operate
on
the
config
for
separate
interfaces.
Even
so,
the
same
option
can
apply
different
logic
at
start
and
end.
If
that,
even
if
that
becomes
necessary,
I
think
it's
in
config.go,
oh.
B
I
think
I
misunderstood
the
thrust
of
this
issue.
Then
you
already
have
separate
types.
A
A
Yeah,
so
to
start,
if
you
look
at
like
the
start,
span,
options
right
to
create
a
config,
that's
going
to
create
a
span
config.
If
you
look
at
the
end
span,
options.
A
Create
a
spanning
thing
and
bogdan's
saying
like
have
these
2d
be
different,
but
it's
like
the
user
only
ever
interacts
with
the
start
span
option
or
the
end
the
star.
The
span
end
option
right
so
like
I,
I
don't
like
it's
the
developer.
Who
eventually
is
like
well
actually
like,
maybe
like
right
now
we
want,
you
know,
links
you
can't
add
links
anywhere,
except
for
the
start,
but
maybe
for
some
reason
in
the
future.
We
have
a
really
good
reason
to
do
that,
so
we
want
to
add
an
end
option
to
add
links.
A
That
means
we
would
also
have
to
extend
the
spam
config
right
and
it's
like
well,
if
you're
using
the
start,
the
spam
config
already
like
that
it
has
a
link
option
and
now
you
can
just
implement
that
in
the
sdk
and
all
of
the
other
sdks
already
had
a
way
to
like
look
at
the
link.
A
So
I
think,
if
that's
also
the
other
way
is
like,
if
you
think
about
it,
from
the
sdk
implementer
perspective,
somebody
wants
to
write
their
own
sdk
like
it
is
extremely
limiting
to
say
like
well:
okay,
sdk
authors,
you
cannot
do
anything
with
all
of
these
other
fields.
When
you
end
it.
If
we
only
have
a
spent
end
config
versus
here's,
something
you
could
do
right
if
you
wanted
to
implement
your
own
options
and
then
and
then
write
those
in
like
you
could
do
that.
F
This
only
matters
for
sdk
offers.
It's
I
don't
know
you
could
you
could
restructure
like
you
could
do
a
lot
of
work
to
restructure
the
one
spend
config
into
the
things.
F
A
Yeah
and
like
that,
we
did
that
with
the
options
and
like
we've
already
scoped
it
that
way
and
we've
already
made
it
so
the
user
can't
only
pass
the
options
and
honestly,
like
the
options,
are
linked
in
the
the
godox
really
well
with
what
can
be
passed,
except
for
the
timestamp,
because
you
can
pass
that
to
like
everything
but
like
yeah,
like
if
they're
just
implementing
one
interface
they're
linked
really
well,
so
that
it
reads
really
well.
A
If
we
did
the
config,
it
might
be
a
little
bit
more
confusing
as
to
like,
I,
I
think,
everything's
been
said
on
this
one,
okay.
So
what
I've
got
from
this
is.
I
think
this
this
could
use
some
words
from
josh
as
well
as
some
some
investigation.
This
probably
needs
to
get
closed.
This
probably
needs
to
get
closed
and
I
think
this
probably
needs
to
get
closed
just
with
some.
I
think
summation
of
the
community's
perspective.
A
So
we
really,
I
think,
if
we're
looking
at
this
have
one:
where
is
it
yeah
one
one
issue
that
we
really
need
to
tackle
before
we
can
start
thinking
about
doing
another
release,
I
think,
is
what
I'm
getting
from
this
conversation.
G
A
Yeah
and
I
at
one
point-
we
did
implement
it,
so
you
could
set
this
mankind,
but
we
were
non-compliant
with
the
specification,
so
it
was
removed,
but
exactly
with
what
richard's
saying
like
if
he
was
able
to
eventually
convince
the
specification
that
that's
something
that
they
want
to
implement.
G
G
F
A
Yeah,
oh
my
god.
I
I
remember
that
multiple
times
that
has
come
up,
okay,
cool,
I
think
that's
it
for
our
little
review.
By
little
I
mean
quite
extensive.
At
this
point
I
it
looks
like
we
have
some
issues
to
talk
about
from
the
agenda.
So
josh,
I'm
going
to
hand
it
over
to
you.
If
you
want
me
to
keep
sharing
my
screen
or
I
can
stop
and
hit
it
over
you
as
well.
F
Oh
yeah,
just
no
don't
stop
quickly.
I've
been
doing
some
some
work.
I
haven't
sent
the
pr
yet,
but
I've
been
working
a
bunch
in
the
metric
sdk
and
I
saw
this
type
called
instrumentation
library.
It's
not
used
much.
It's
in
the
sdk
instrumentation
package.
It's
just
a
type
that
has
sort
of
standard
coordinates
for
an
sdk
which
are
instrumentation
library,
name
version
and
schema
url.
F
As
I
was
doing
my
pr,
which
is
fixing
one
of
the
issues
it's
about
the
meter
provider,
I
was
adding
the
sdk
the
schema
url,
just
because
I
thought
I
should
it
seemed
like
the
perfect
time
to.
I
wanted
to
use
that
type,
but
I
want
to
use
it
in
all
these
places
that
are
in
the
apis
like
itself,
not
in
the
sdk.
I
just
wanted
to
wonder
if,
if
anyone
would
object
or
like
mind
if
I
lifted
this
type
out
and
and
used
it
more,
that's
all
yeah.
A
Not
sure
that's,
that's
I
think
where
it's
coming
from
is
the
specification.
It's
the
specification
itself
defines
the
instrumentation
library
in
the
sdk,
and
it's
an
sdk
concept
is
why
that
was
put
in
the
sdk.
I
I've
run
into
this
exact
same
thing
that
you're
talking
about
it's
really
frustrating
because
a
lot
of
the
time
you
want
to
be
doing
testing,
especially
in
like
the
api
level,
with
things
that
would
use
this,
but
there
is
no
concept,
so
I
think
what
we've
done
in
the
past
is
essentially
you
spell
out
the
components
of
it.
A
So,
like
you
know,
you
can
pass
to
the
tracer
options.
You
can
pass
the
instrumentation
library
name,
but
there
isn't
really
a
structure
there.
I
would
definitely
be
open
to
hearing
proposals
on
like
changing
this.
Maybe
moving
this
to
an
internal.
The
problem
is
exposing
us
at
the
api
level.
I
think,
would
make
us
out
of
compliance
with
the
specifications.
It
could
be
internal.
F
That
that
makes
sense,
but
it's
it's
used
in
a
bunch
of
places
I
just
wanted
to.
I
just
wondered
if
that
was
what's
going
on.
Thank
you.
F
F
Right.
Yes,
that's
the
one.
I
have
something
almost
ready.
I
don't
want
to
talk
anymore
about
it,
because
I'm
exhausted.
A
Well
then,
yeah,
let's
not
burn
you
out.
That
sounds
like
a
good
idea,
cool
all
right.
I
think
that
made
it
through.
What's
on
the
list
of
the
agenda,
does
anybody
else
have
something
they
wanted
to
bring
up
ad
hoc
to
the
agenda.
A
G
Yeah,
I
okay,
so
my
project.
What
what
steve
and
I
are
working
on
is
steve.
Willoughby
over
there
is
we're
working
on
a
shim
for
customers,
new
relic
customers
who
are
already
using
the
go
agent
and
making
an
api
compatible
layer
and
ripping
out
the
rest
of
the
go
agent,
replacing
it
with
something
that
converts
to
open.
Telemetry
uses
open
telemetry
for
go,
and
it
sounds
really
straightforward,
because
our
go
agent
is
an
sdk
but
yeah.
This
mankind
really
threw
us
for
a
loop.
G
What
we're
doing
is
using
the
old
distributed
tracing,
which
is
a
new
relic
thing,
our
new
relics,
version
of
distributed
tracing
just
keeping
those
spans
around,
so
we
can
use
them
and
set
the
types
and
do
all
the
things
we
need
to
do
and
then,
when
it
comes
time
to
make
the
span
the
the
open
telemetry
span,
we
are
creating
it
copying,
attributes
into
it,
backdating
it
and
ending
it,
which
feels
like
a
complete
hack,
which
you
know.
G
From
that
perspective,
you
can
see
why
I'm
talking
about
this
a
lot,
I
could
run
a
demo
if
you
wanted
to
see
a
demo
of
it.
F
I'm
sure
if
anybody
remember
that
there
was
a
canonical
example
whenever
this
was
discussed,
which
was
like
nginx
or
some
of
the
c
plus
plus
servers
where
you're
going
to
be
starting
a
span
to
be
an
http
span
or
something
like
that.
But
you
you
want
to
start
it
like
very
early,
which
is,
I
just
accepted
a
connection
or
I
just
started
begun
reading
an
http
socket
and
now
I'm
going
to
start
instrumenting,
and
I
don't
know
the
name
yet
darn
it
right.
F
I
don't
know
anything
about
it,
darn
it
and
that's
why
this
span
data
concept
came
in,
which
is
that,
like
the
idea
that
you
might
just
at
the
very
end
of
a
span,
dump
everything
and
we
we
fought
away
that
and
replaced
it
by.
Basically,
you
can
start
and
stop
a
span
and
just
explicitly
state
every
field
at
the
moment
in
time.
I
think
which
I
think
is
what
you're
demoing.
Essentially
I
don't
and
and
yeah.
F
G
F
That
conversation,
the
the
way
I
remember
it,
there
was
this
concept
of
span
data,
which
was
like
an
entirely
separate,
trace
api
and
it
seemed
like
we
were
going
to
have
to
implement
two
of
the
two
things
and
it
seemed
like
instead
of
having
a
second
interface,
which
was
here's
your
struct.
That
represents
the
span
that
what
we'd,
rather
just
do,
is
have
start
and
end
be
functions
that
you
can
call
with
all
those
options
set.
F
Yeah-
and
I
guess
the
the
connection
to
the
stateless
like
sdk-
was
the
idea
that
yeah
that
you
that
you
that
there
ought
to
be
an
sdk
that
doesn't
have
to
remember
anything
between
start
and
stop.
I
guess
which
is
what
you
get
when
you
log.
G
Okay,
this
is
customer
code.
Actually,
this
is
the
sample
that
comes
with
the
go
agent
that
new
relic
and
basically
at
the
top,
instead
of
including
the
go
agent
from
the
relic
we're,
including
this
new
relic
open,
telemetry
ship
go
which
is
not
ready
for
consumption,
I
would
call
it
alpha
and
at
the
bottom
of
this
sample
we
setting
up
the
agent
is
really
pretty
easy.
G
You
just
say
new
application
and
you
give
it
a
license
key
in
the
environment
and
maybe
do
a
logger
and
you're
in
pretty
soon
you're
wrapping
your
http
handle
funcs
with
new
relic
our
app
handle
funds,
and
this
is
what
our
customers
are
doing
so
yeah,
there's
the
in
you
know,
there's
the
url
or
not
the
url
the
path
and
then
it
hands
off
to
whatever.
Let's
go,
look
at
mysql.
G
See
the
issue
right
so
in
this
grabs
the
context
and
then
to
start
a
segment
which
is
that's
a
new
relic
term.
Back
from
when
we
had,
it
was
just
old
transaction
traces.
It
was
not
distributed
tracing
at
all,
but
yeah.
They
just
define
the
struct
literal
and
they
can
end
it
whenever
they
want.
So
we
have
no
way
of
knowing
we
actually
don't
actually
execute
any
code.
We
hand
this
all
to
the
customer.
G
In
some
instances
the
customer
does
call
a
start
segment
and
a
segment
call,
but
not
all
the
time,
but
anyway,
what
we
did
was
defer
and
copy
which
feels
I
haven't
run
benchmarks
on
it.
Basically,
the
customer
just
sets
their
key
and
runs
the
thing,
and
it
shows
up
pretty
soon.
Here
we
go
and
I'm
going
to
run
some
traffic
against
it.
G
That's
just
work
to
running
throttle
and
just
hitting
all
these
endpoints
for
different
different
parts
of
the
of
the
agent.
This
is,
this
is
a
sample
application
that
ships
with
the
go
agent
as
well
too
there
it
goes,
and
then,
let's
see,
if
I
can
find
my
there,
it
is
here's
the
ui
see
we're
getting
spans
exciting.
The
back
end
is
actually
synthesizing
transactions,
which
is
yet
another
old-fashioned,
vpn
idea
right
and
it's
figuring
out
well,
that
must
have
been
a
mysql
thing.
G
A
G
The
there's
a
convention
that
the
customer
calls
one
of
our
functions.
The
function,
however,
has
no
real
way
of
determining
what
kind
of
segment
it
was
called
from,
because
it's
just
part
of
that
struck
literal.
It's
called
from
within
the
creation
of
the
spirit
and
yeah.
You
always
say.
Well,
don't
do
that,
but
we
can't
change
the
interface
on
our
existing
customers,
even
though
the
go
agent
feels
new
to
me
at
new
relic,
it's
been
around
for
five
years
and
people
aren't
going
to
change.
You
know.
G
G
But
yeah
I
I
I'm
really
curious
to
see
how
it
pans
out.
A
Yeah,
I
mean,
I
know
go's
one
of
the
more
forward-facing
languages
for
developers.
They
try
to
stay
a
little
bit
more
active.
But
I
know
java
was
a
huge
controversy
when
they
stopped
supporting
java
7
in
the
hotel
side
of
the
house,
which
I
think
went
end
of
life.
Like
I
don't
know,
john
joe's,
but
like
five
years
ago,
or
something
like
that.
E
F
Yeah,
I've
never
heard
reports
from
customers
of
ours
about
complaining
about
old,
go
usage,
but
that
doesn't
really
mean
much
and
we
aren't
recommending
hotel
for
users
yet.
F
In
metrics,
so
I
don't
hear
a
lot
of
feedback
about
use
of
the
hotel
trace
the
case.
E
I
think
we've
got
a
couple
issue
reports
they
they
seem
to
happen.
Every
time
we
bump
the
the
minimum
version.
Someone
will
run
into
something
and
the
the
answer
is
usually
we
don't
support
that
version
anymore
and
they
say
okay,
I'll
update,
because,
as
tyler
mentioned,
the
go
community
does
try
to
stay
fairly
up
to
date
and
go
tries
to
make
it
easy
for
users
to
stay
up
to
date.
E
I
I
do
kind
of
feel
for
the
the
people
who,
for
some
reason
or
another,
are
stuck
with
an
older
version,
but
I
hope
that
at
some
point,
when
we've
released
a
stable
version,
they
take
a
dependency
on
that
right
and
either
vendor
that
dependency
or
just
stick
with
that
version,
and
so
no
matter
how
far
back
they
go.
If
they've
got
an
application
that
needs
to
stay
unchanged,
they're
at
least
still
able
to
use
the
version
that
they
were
using
when
they
built
it.
A
Yeah
agreed,
I
would,
I
would
like
to
provide
more
coverage
of
versions
but
yeah
at
this
point.
I'm
I'm
with,
as
we've
already
had
a
large
conversations
about
this,
like
the
last
two,
the
current
and
the
last
is
what
we're
doing
and
that's
because
that's
what
god
is,
but
speaking.
B
Okay,
it's
always
confusing
how
they
they
release
it
as
1.17
is
just
the
version
not
point
zero.
Every
time.
A
Oh
man,
look
at
this
yeah
all
right,
we're
gonna.
Have
this
conversation
again.
Then,
okay,
good
to
know
good
to
know,
yeah,
so
look
out.
We
may
we
may
be
bumping
to
minimum
of
116.,
but
we'll
see.
I
think
if
that's
something
we
should
probably
try
to
lock
down
once
we
do
our
disabled
releases.
Anthony
said:
okay,
perfect.
A
I
think
we
had
some
good
user
stories.
I
think
steve's
got
his
hand
out.
G
B
B
If
you
look
at
any
of
the
exporters,
most
of
them
have
like
10
to
15
options
that
you
can
set
on
them
and
the
situation
I
keep
getting
into
is
I'm
trying
to
tunnel
many
of
those
options
back
out
as
command
line
flags,
let's
say,
and
maybe
even
with
an
intervening,
translation
layer
like
if
you
pass
this
flag
to
validate
the
value,
then
figure
out
which
hotel
option
to
set
on
this
exporter.
B
I
feel
like
I'm
doing
it
wrong,
because
we
don't
have
anything
like
a
standard,
say,
config
file,
format
or
something
where
we
could
say.
Like
you
know,
you
write,
you
write
a
config
file,
the
hotel
sdk
knows
how
to
consume
that
config
file
and
then
all
the
options.
You
know
any
anything
you
can
think
of
doing
as
a
user
of
the
program,
you
have
controller,
so
I
find
myself
having
to
make
decisions
like
okay.
B
B
You
know
this
because
at
some
point
then
I'm
going
to
have
like
75
command
line
flags
that
I'm
writing
just
for
this
one
program
and
none
of
it's
reusable
later
and
and
the
user
is
staring
that
down
is
going
to
look
at
it
and
think
this
isn't
even
really.
This
program
has
made
no
decisions.
A
Problem,
so
that
is,
I
think,
something
that
is
being
discussed
at
the
specification
level,
not
just
alone
here.
Keep
that
in
mind.
I
know.
Ted
over
lightstep
is
very
passionate
about
this,
because
you're
describing
a
real
customer
pain
point,
let
alone
user
pain
point
across
not
just
go
like
it's
across.
A
He
definitely-
and
I
think,
he's
right.
I
agree.
I
think
it
is
a
problem
I
I
will
say
it
as
well.
I
think
that
there
has
been
a
few
different
efforts
to
try
to
do
exactly
like
what
you're
saying
is
to
unify
some
sort
of
configuration
so
that
you
could
then
pass
it
to
your
java
system
as
well
as
your
go
system,
because
that
would
also
be
kind
of
a
problem
as
if
like
and
go,
you
can
figure
it
this
way
in
python.
You
do
it
this
way
and
then
you
know
erlang.
A
You
know
something
completely
different
like
that's
also
that
would
cause
a
problem
as
well,
so
there
was
a
desire
to
have
a
config
file
format
and
then
standardize
the
configuration
that
was
originally
going
to
be
a
sig
right
and
the
sig
kind
of
got
dropped
right
after.
F
There's
still
an
effort,
and
apparently
it
started
in
secret
because
there
was
not
officially
a
sig,
so
they
started
to
save
like
an
illegal
sig.
I
just
that's
not
true.
They've
been
squatting
on
the
4pm
aipac
friendly,
spec
sig
in
the
afternoon
on
tuesdays
and
talking
about
it.
I
I've
been
going
just
to
see
what's
happening
a
little
bit,
I'm
usually
at
the
end
of
my
day
and
done,
but
I
can't
really
talk.
There
isn't
otep
talking
about
it.
It's
number
165.
I
just
put
it
in
the
chat.
F
F
It's
basically
saying
that,
like
we
probably
needed
a
high
like
a
different
idiomatic
api
for
these
complex
instrumentation
packages
like
if
you're
an
http
server
instrumentation
package,
it's
not
so
easy
to
implement
the
spec
and
also
be
efficient
and
also
be
configurable,
and
I
and
I
said,
let's
put
configuration
first
because
it
seems
like
that's
the
more
cross-language
concern
and
I
I
don't
know
that.
There's
truly
a
common
idiom
for
these
complex
packages
in
these
across
languages,
and
we
heard
from
someone
in
ruby
yesterday
that
sort
of
made
it
sound
like
yeah.
F
The
java
thing
I'm
reading
here
looks
very
java
e.
I
don't
think
it
would
help
me
at
all
in
ruby,
which
is
probably
what's
going
to
happen
in
the
other
languages.
So
if
we
could
turn
it
around
and
start
talking
about
configuration
first,
I
think
that
was
the
user
story.
You
told
was
that
you're
making
decisions
about
configuration,
because
it's
hard
because
you
keep
copying
and
having
to
do
it
yourself
and
wouldn't
it
be
nice
if
there
was
like
configuration
to
me.
B
Our
our
sdk
interface
is
nice.
It's
a
nice
way
to
to
configure
it
if
you,
if
you're,
trying
to
make
one
set
of
decisions
like
if
you
knew
your
environment
and
you're
writing
a
program
to
run
in
your
environment,
where
you
know
you're
talking
to
the
collector
with
this
protocol,
and
you
know
you
never
do
this.
You
always
do
that.
It
works
nicely.
B
E
I
think
that
would
be
unfortunate.
I
think
that,
looking
at
what
build
kit
and
container
d
had
done
where
they
tried
to
put
most
of
the
configuration
in
the
environment,
maybe
the
way
forward
out
of
that
we've
already
in
the
spec
got
a
lot
of
environment
based
configuration
defined
and
I
think,
defining
some
more
and
including
some
of
the
the
structural
configuration
choices
like
which
exporters
to
use
and
being
able
to
support
that
would
be
valuable.
E
Buildkit
had
an
interesting
registry
based
approach
for
that,
where
the
application
could
you
know,
import
four
side
effects,
say
the
the
the
exporter
packages
and
it
would
register
them
with
a
registry
that
could
then
you
could
say:
okay
use
the
exporter
coming
from
the
environment,
that's
decided
by
this
registry
and
it
would
go
through
a
chain
of
responsibility
or
you
know,
a
hierarchy
with
priorities
on
each
of
those
exporters
to
decide.
B
Yeah,
that
would
be
great.
I
was.
I
was
happy
to
study
like
the
way
that
the
resource
area
that
can
pull
things
from
the
environment,
which
suddenly
gets
me
out
of
the
responsibility
of
trying
to
tunnel
a
bunch
of
that
through,
as
you
know,
as
resource
attributes
as
an
example,
I
don't
know
if
we
have
any
sort
of
catalog
what
are
all
the
environment
variables
that
are
supported
by
the
sdk.
E
Yeah,
I
don't
know
that
we
do
in
the
sdk,
though
the
spec
compliance
matrix
has
at
least
a
partial
list
of
them,
and
you
can
look
for
the
ones
that
are
supported
by
go.
I
think
we're
largely
up
to
date.
There.
A
We
are
another,
it
would
be
nice
to
be
documented.
I
think
better
document
it's
in
the
documentation
disparately,
but
you
can
also
search
the
project
for
a
prefix
of
hotel,
like
all
capitals
and
then
an
underscore
you'll
you'll
find
all
of
them
that
way.
Yeah.
F
C
Most
of
the
kubernetes
components
end
up
using
component
config,
which
is
kubernetes
yama
objects
that
supply
configuration
so
we're
likely
to
go
down
the
path
of
defining
a
kubernetes
object
that
represents
hotel
config,
at
least
for
core
kubernetes
components,
but
will
likely
be
more
opinionated
than
you're
going
to
be
because
we'll
prescribe
you
should
talk
otlp
as
a
core
kubernetes
component
and
other
things
like
that.
A
Interesting,
I
think
that's
a
that's
going
to
motivate
people
I'll
say
it
that
way.
B
A
Yeah,
I
think
that
is
a
really
good
approach
that
we
should
try
to
try
to
do
in
open
source
and
not
have
you
in
kubernetes
have
to
pick
it
up.
But
I
guess,
if
you
immediately,
like
you
said,
like
you
make
your
own
config,
I
think
if
that's
a
really
good
starting
point
at
least
to
base
it
off
of
saying
like
yeah,
that's
really
opinionated.
Maybe
we
want
to
make
it
more
general,
but
at
least
that's
a
I
don't
know.
B
Yeah,
just
just
the
one
thing
that
is
confusing
is
that
the
collector
sort
of
already
does
this,
but
it's
not,
but
it's
the
collector
it's
in
a
separate
world,
and
presumably
you
can't
configure
everything
in
the
collector
that
you
can
configure
in
the
sdk.
But
it's
just
there's
already
an
example
in
this
community
that
is
not
generalized,
so
it
sort
of
encourages
you
to
say
you
know
what
I'm
just
gonna
shunt
the
program.
B
A
G
Yeah,
I
felt
that
pain
too.
With
that
shim
I
was
just
talking
about.
I
made
some
terrible
assumptions
that
the
customer
would,
I
would
just
box
them
right
in.
Hopefully
you
know,
and
that
limits
my
use
cases
quite
a
bit
but
yeah
what
would
happen
if
we
took
the
collector
style
format
and
just
and
worked
with
that.
A
I
think
it's
a
little
bit
limited
and
I
definitely
think
that
people
talked
about
doing
something
like
that,
but
I
think
there's
a
more
generalized
solution
that
josh
is
kind
of
pointing
to
with
like
the
otep
and
holistically
across
the
project.
That
being
said,
I
think
we
need
to
table
a
conversation
we're
at
the
end
of
time.
Everyone
thanks
for
joining.
I
really
appreciate
the
conversation
and
the
feedback.
I
will
see
you
all
virtually
or
next
week,
bye.