►
From YouTube: 2021-04-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).
B
It's
going
pretty
good,
I'm
sorry,
I
haven't
been
part
of
the
hotel
go
project
for
a
while,
but
I
feel
like
metrics
is
coming
together.
So
things
are
good.
A
Yeah
I
agree.
Well
I
mean
I'm
sad
to
not
see
you,
but
I
do
feel
that
metrics
are
coming
together.
Well,
actually
so
yeah.
I
think,
that's
time
all
spent.
B
B
I
promise
to
do
something
else
for
tomorrow,
but
I
did
want
to
just
enter
the
conversation
with
a
lot
of
optimism,
both
that
I'm
able
to
spend
time
to
help,
because
this
is
something
I'm
very
committed
to
as
well
as
I'm
pretty
confident
that
as
long
as
we
stage
a
release
like
a
series
of
releases
with
all
the
right
steps
which
we
will
have
to
coordinate,
that
we
can
introduce
a
new
api,
perhaps
renaming
the
old
api
and
not
be
extremely
disruptive
potentially.
B
A
Yeah,
so
that
that
sounds
good,
I
do
want
to
make
sure
that,
like
we
have
some
like
common
understanding
of
like
what
the
the
goals
are
here,
I
think
that
we
all
I
just
want
to
make
sure
it's
clear,
but
like
we
all
kind
of
share,
that
idea
that,
like
the
current
existing
api
for
the
metric
stuff
is,
is
used
in
pretty
a
lot
of
places.
Obviously,
like
it's
listed
in
a
few
places,
I
think
is
like
beta
at
this
point,
which
means
I
don't
know
at
some
point
last
year.
A
It
meant
a
lot
and
then
all
of
a
sudden
it
became
not
as
much
but
the
idea
is
it's
like
reality
versus
expectation.
Is
that,
like
a
lot
of
people
actually
are
using
this
api
and.
A
Yeah,
like
just
in
terms
of
the
project
the
the
trib
library
already
uses
it
right
so,
like
I
know,
there's
vendors
that
use
it.
I
know
there's
other,
like
the
redis
client
library,
I
think
was
using
this
so
like
yeah
like,
on
the
one
hand,
it'd
be
nice,
if
you
could
just
like
you,
know,
lop
it
off
and
throw
it
away
it'd
be
it's
not
a
really
good
experience,
I
think
from
the
user
base.
You
want
to
be
like
supporting
in
the
long
run,
to
do
that
sort
of
thing.
A
So
I
think
that
we
all
kind
of
understand
that
idea
that,
like
it's
it's
ideal
to
give
them
a
path
forward,
even
if
it's
you
know
a
hard,
maybe
a
little
disruptive,
but
it's
it's
better
that
I
think
they're
saying
like
well.
This
release
is
going
to
have
no
metrics
and
then
we're
going
to
start
building
it
again.
It's
not
really
a
solution
there,
so
that
was
on
that's
one
side
of
the
spectrum.
A
I'm
looking
at
the
other
side
is
that,
like
we
have
the
trace
rc
that,
like
we,
are
really
trying
to
get
out
like
there's
a
lot
of
effort,
we
don't
have
that
many
people
very
active
in
the
project
right
now
that
darn
collector
yeah.
A
No,
but
it's
it's
something
that
I
want
to
be
conscious
of
as
well,
because
the
idea
that,
like
we
try
to
build
this
migration
path,
if,
like
the
burden,
is
you
know
severely
going
to
impact
the
timeline
for
getting
the
trace
rc
out,
which
you
know,
is
kind
of
a
made
up
date,
but,
like
I,
don't
want
the
trace
rc
to
be
going
out
next
year.
Right,
like
I
think
that
that's
something
like
I
wanted.
A
Targeting
like
a
month
or
two
with
the
idea,
I
want
to
make
sure
that
that's
still
prioritized
and
that,
like
a
lot
of
the
you
know
the
resources,
human
resources
that
we
have
allocated
to
getting
these
sort
of
things
done
are
able
to
be
able
to.
You
know,
progress.
A
So
yeah
and
like
I
hope
that
we
can
find
somewhere
that
can
satisfy
both
these
goals.
I
think
is
kind
of
like
the
idea
and
then
and
then
kind
of
going
forward
and
then
another
thing
that
we
probably
need
to
talk
about,
and
anthony
kind
of
mentioned.
This
in
the
gostig
meeting
was
just
like.
What
do
we
do
about
instrumentation
right
because,
like
if
we
have
this
migration
api?
A
C
Http
is,
is
the
one
that
really
stands
out.
I
think
the
instead
of
the
cassandra
or
the
serama.
One
might
also
have
some
instrument
asymmetrics
instrumentation,
yeah.
C
I've
been
thinking
with
http,
though,
that
it
might
be
better
to
cleanly
separate
the
http
or
the
traces
and
the
metrics
either
that
or
make
the
metrics
something
that
can
be
folded
into
the
http
handlers
optionally.
C
B
And
then
I
guess
this
is
still
not
easy
like
we
want
to
release
something
that
then
requires
consumers
of
those
libraries
to
either
to
take
on
a
second
dependency
if
they
intend
to
use
the
metric
stuff
that'll
be
an
unstable
dependency
so
that
they
can.
Then
we
can
then
move
the
tracing
half
and
forward
and
to
be
stable.
B
I
know
we
listed
ceramic
standard
out
in
http.
That's
not
a
huge
number!
I
it
doesn't
sound
tremendously
easy,
but
okay
does
that
sound
like
the
right
idea,
I'm
looking
at
the
doctor,
we
have
for.
A
This
kind
of
stuff
right
now,
which
I
could
show
it's
bigo,
go
cql
host.
No,
that's
not
mixed.
The
net.
Http,
I
think,
are
the
three
that
we
have,
so
it
isn't
actually
too
much.
The
hosts
in
the
run
time
are
pure
metrics.
B
C
It's
a
it's
another
hdp
instrumentation
addressing
that
will
be,
I
think,
very
similar
to
addressing
the
net
http
yeah.
In
fact,
is
this
the
one
that
yeah
this
is
the
one
that
wraps
the
hotel
http.
So
when
we
address
hotel
http,
this
will
be
addressed
as
well.
I'd
say
so
it's
one.
B
Of
the
consumers
of
net
hdp,
yeah
yeah
and
then
standard
output,
I
mean
like
who
really
cares
but
like
having?
Well,
I
guess
you
could
have
one
stable
dependency,
that's
just
traces
standard
out.
You
could
have
an
unstable
dependency.
That's
like
everything
centered
out.
A
That's
a
really
good
question
see
so
that's
the
other
thing,
so
this
kind
of
goes
back
to
the
extremely
disruptive
api
changes
right.
I
think
josh
kind
of
mentioned,
like
there's,
probably
a
path
forward
for
the
api
in
migrating
it
just
based
on
what
I'm
hearing
from
the
apis
metrics
sig,
like
their
names,
may
change,
maybe
maybe
some
like
calling
conventions
but
like
the
I
think,
the
semantics
of
what's
going
to
go
on
is
is
is
going
to
get
preserved.
Correct
me
if
you
have
a
different
opinion.
B
A
A
problem,
the
thing
that
I
do
see,
though,
is
the
sek
implementation,
may
be
very
different
looking
and
I'm
not
too
sure
like
where
that's
gonna
go,
and
I
think
that's
a
really
interesting
question,
because
yeah,
that
is
the
thing
that
defines
the
interfaces
that
all
these
exporters
needed
to
like
implement
in
the
first
place,
and
so,
like
you
know,
essentially,
api
down
is
really
great
to
me
and
I'm
not
like,
I
don't
know
like
I
feel
like.
A
We
need
to
be
a
little
bit
more
liberal
in
the
the
disruption
in
that
part
of
the
pipeline.
A
B
Yeah,
I
don't
know
to-
I
don't
even
know
that
we've
gotten
far
enough
in
the
sdk
planning
work
to
to
say
that
truthfully,
I
think,
there's
actually
not
much
happening
there
at
all,
and
so
I
I
kind
of
want
to
second
what
you
said,
which
is
that
the
otlp
and
the
standard
out
exporters
are
sdk
dependency
issues,
not
api
issues
right
and
I
hadn't
been
thinking
much
about
dealing
with
them,
because
it
is
a
separate
question
that,
like
there
is
actually
I
have
a
dead
pr,
that's
like
from
december
that
I
still
really
want
to
get
in,
but
I
didn't
want
to
distract
anybody
with
it.
B
It's
removing
some
quantile
stuff,
like
yeah,
we
have
cruft
in
the
sdk
that,
like
I'm
pretty
sure,
needs
to
go,
but
as
for
the
organization
of
the
accumulator
and
the
and
the
processor,
and
and
like
all
that
stuff,
I
think
we'll
stand
up
once
we
finally
start
looking
at
it
and
we
could.
We
could
end
up
changing
names
as
well
and
we
could
end
up
getting.
B
We
could
end
up
getting
more
detailed,
but
I
would
like
to
stand
on
that
for
now,
if
possible,
because
we
haven't
come
to
any
agreement
about
stripping
it
down
that
I
know
of
the
thing
that's
likely
to
be
hardest
for
metrics.
That
I
think
means
just
a
little
bit
of
waiting
is
like
that
run
time
and
the
host
metrics
instrumentation,
which
I've
been
using
as
well,
are
built
up
around
that
batch
observer
api
and
if,
if
we
don't
have
a
batch
observer,
api
standardized
for
the
new
world
it'll
be
really
hard
to
port.
B
That
code
and
also
inefficient,
potentially
and
it'll,
be
an
example
of
like
how
hotel
is
not
really
serving
the
user.
So
I
think
we
will
get
to
a
point
of
having
a
batch
some
sort
of
batch
and
server
thing,
but
it's
so
much
harder
to
get
right
and
so
much
more
time
gets
sucked
up
by
that
that
I
think
there
probably
should
have
other
priorities.
B
So
would
it
be
okay?
Then
I
don't
I'm
kind
of
trying
to
punt
the
sdk
question.
It
may
just
be
just
a
dependency
as
an
issue,
a
go
mod
question,
but
I
think
the
real
question
is
the
net
http
and
b
go
and
it
still
sounds
like
what
we
have
to
do
is
split
those
dependencies
into
two
one
for
metrics
and
one
for
trace.
A
Well
so
yeah,
but
I
honestly
see
that
as
a
step
two,
because
if
I
think
about
it,
if
I
want
to
do
a
stable
release
in
the
rc-
and
I
want
to
include
an
otlp
exporter
like
does
it,
you
know,
is
that
going
to
have
breaking
changes
after
the
fact,
because
the
you
know
the
sdk
implementation
that
I
have
to
support
with,
that
is
going
to
change
like
I'm,
I'm
a
little
hesitant
at
that
point
to
like
include
exporters
for
metric
stuff
in
the
the
rc
you
know
like
that,
could
be
really
hard
and
I
think
jaeger
and
zipkin,
like
that's
cool
because,
like
those
are
really
isolated,
those
are
trace
specific
but
like
the
otlp
one
and
the
standard
out
are
going
to
be
like
that's
a
that
could
be
really
problematic,
and
I
don't
know
how
to
handle
that
like
do.
A
C
I
had
always
imagined
that
they
would
be,
and
I
I
think
I
would
agree
that
getting
the
api
and
sdk
to
an
rc
is
the
most
important
part.
I
think
the
instrumentation
can
stay
experimental
for
some
time
afterwards.
It
would
be
great
to
get
a
1.0
http
trace
implementation
out
there
that
we
can
put
out,
but
I
would
also
feel
very
comfortable
saying
this.
Instrumentation
uses
the
stable
apis.
C
Its
interface
is
almost
certainly
going
to
stay.
Stable.
We've
just
got
some
metric
stuff.
That's
intertwined
that
we're
working
on
cleaning
up,
that's
an
easier
story
to
tell
than
hey:
we've
got
an
api
and
an
sdk,
but
we
don't
have
an
otlp
exporter
for
you.
Yet.
A
Yeah
yeah
right
yeah,
here's
a
really
good
implementation.
Oh
by
the
way
we
can't
talk
to
the
collector
yeah,
I
don't
think
that's
gonna
fly
so
I
mean
lightstep
wants
otlp
as
well.
Gosh
yeah,
I'm
sure,
and
I
think
a
lot
of
other
companies
do,
and
so
it
might
also
just
be.
A
This
is
one
of
those
things
where,
since
it's
it's
an
interface
that
we
only
expect
to
be
satisfied
in
lockstep
with
the
sdk
kind
of
how
the
api
is
an
interface
that
we
only
expect
the
sdk
to
be
satisfied
in
lockstep,
with
a
particular
version
that
we
might
be
able
to
just
say
like
well.
It
includes
like
experimental
metric
things,
but
like
we
track
those,
I
don't
know,
if
that's
possible,
to
say
like
we're,
always
updating
that
interface,
because
really
like
the
only
thing
is
it's
gonna.
A
It's
just
that
implicit
interface
and
you
know
implementation
right,
and
so
it
just
needs
to
implement
whatever
we
want
to
have
the
sdk
for
metrics
exporting
in
that
format.
Right.
C
B
C
We're
talking
about
an
exporter
implementing
one,
that's
not
yet
stable,
and
maybe
that
will
change,
but
even
then
that
exporter
package,
if
we
declare
it
1.0,
then
we've
we've
said
this:
is
this
1.0
api?
If
we
were
willing
to
say?
Okay
by
the
time
we
get
metric
stable,
that
exporter
package,
otlp
exporter
is
going
to
go
to
2.0,
just
because
we
made
a
breaking
change
to
it,
even
though
that
break
was
in
the
metrics
half
and
not
the
trace
half.
C
B
Split
the
the
exporters
that
support
both
into
sort
of
factor
them
apart
and
it
sounds
like
work,
not
great
amount
of
work,
not
a
great
deal,
though,
perhaps
that
you
could
have
a
combined
dependency
trace
only
and
a
metrics
only
or
something
like
that
and
maybe
stable
is
allowed
to
depend
on
sorry.
Unstable
is
allowed
to
depend
on
stable,
so
you
could
have.
You
could
also
have
a
metrics
depend
on
tracing
and
that
would
work.
B
Yes,
I'm
thinking
right
now
that
if
we
had
subdirectories
of
otf
the
otlp
exporter
that
were
first
specific
for
metrics
and
tracing
them,
somehow
with
a
bunch
of
magic,
we
can
make
them
be
separate
dependencies
and
then
you
can
choose
when
you
decide
to
start
up
hotel.
Do
I
want
stable,
which
means
just
tracing
across
the
board,
or
do
I
want
tracing
and
metrics,
which
means
stable,
tracing
and
unstable
metrics
combined.
A
Yeah,
I
I
hear
you
that
sounds
really
attractive,
because
on
the
one
hand
you
could
just
get
the
stable,
you
know
exporter.
That
is
what
it's
going
to
be
and
then
we
could.
You
know
accrete,
that
exporter
to
have
the
new
interface
when
the
metrics,
you
know,
sdk
defines
it
stably,
but
it
suffers
from
the
idea
that
you
would
have
two
import
paths
again
so
like
if
you're,
you
know
which
I
don't.
I
don't
know
if
this
is
a
reason
to
not
do
this.
A
A
B
A
B
A
Why
I'm
saying
that
I
was
like
it's
not
a
bad.
B
C
Well,
I
I
think
that
the
the
person
you
were
just
describing
tyler
is
is
in
line
with
what
we
were
already
talking
about
in
terms
of
global
trace
providers
and
meter
providers
right.
We
we
expect
that
global
is
going
to
your
hotel,
is
going
to
export
a
tracer
provider.
It'll
be
some
way
to
get
a
meter
provider
while
metrics
are
unstable
and
then
eventually,
when
metrics
become
stable,
otel
will
provide
a
meter
provider
as
well.
That
will
just
alias
through
to
that.
A
B
I
didn't
actually,
since
I
was
not
present
for
that.
Let's
see
if
I
followed
what
you
just
said,
so
the
global
metrics
provider
is
going
to
be
in
the
same
package
that
the
global
trace,
stable,
trace
provider
package
has.
Therefore
we
have
a
problem.
We
either
have
to
create
separate
global
packages
which
is
sort
of
unsightly,
or
we
have
to
do
some
sort
of
runtime
registration
thing.
Where
you
can
you
can
access
an
api,
that's
stable,
but
you
will
only
be
able
to
obtain
unstable
things
through
it.
If
you
have
registered
the
correct,
never
mind.
C
No,
no
instead!
Instead,
what
it
is
is
that
the
sdk
trace
and
metrics
packages
will
provide
global.
You
know
package
global
to
them,
trace
providers
and
metrics
providers
and
the
otel
global
package.
The
overarching
one
will
proxy
through
to
that.
So
for
now,
while
it's
only
exposing
global
traces,
because
they're
stable
the
proxy's
through
to
the
trace
package,
and
if
you
want
to
get
a
meter
provider,
you
get
that
directly
from
the
metrics
package.
C
When
metrics
go
stable,
there
will
be
a
global
hotel
meter
provider
that
you
can
call
which
we'll
proxy,
through
the
metrics
package,
to
get
the
meter
provider.
People
who
are
using
that
before
continue
to
function
because
it's
still
there
and
people
who
start
at
stable
will
probably
start
with
pulling
it
from
hotel.
A
Never
mind
so:
we've
actually
already
done
this
I
was
like.
Did
we
get
an
issue
or
something,
but
no
we've
actually
already
done
this
so
and
if
you
look
in
the
metrics
api
package
in
the
repo
there's,
a
sub
package
called
global,
and
this
is
where
that
implementation
of
the
metrics
globally
is
yeah.
B
B
B
A
Yeah
and
and
came
back
to
the
idea
that,
like
modules,
can
actually
be
cyclically
dependent,
but
you
can't
have
cycles
on
the
package
imports,
I
think
was
the
thing
that
came
through
and
we
were
okay
with
the
modules
being
cyclically
dependent
because
we're
gonna
be
updating
them
unlock
stuff
anyway.
So
that
makes
sense
to
us.
A
Yeah,
okay,
so
I
think
we
have
some
kind
of
like
we
have
some
understanding.
I
don't
know
when
the
timeline
on
this
is
gonna,
be
like
it
sounds
like
the
api
is
still
in
the
works,
and
I
don't
know
when
they're,
I
think
it
was
the
end
of
this
month
is
when
they're
trying
to
have
some
sort
of
like
okay.
Everyone
else
like
go,
try
and
give
me
a
first
draft
implementation.
Is
that
to
your
understanding
as
well?
Josh.
B
I
think
that's
about
right,
we're
trying
to
finish
the
data
model
documents
and
such
but
but
nothing
that
we're
debating
there.
Actually,
in
fact,
what
sdk
prototypes
might
might
look
like
or.
B
Is
what
I
meant
sorry,
and
so
yes,
I
think
that's
right
timeline.
I
think
it
would
probably
be
advantageous
if
we,
if
I
don't
think
I
fully
understand
what
what
you
all
would
like,
but
I
I
want
to
see
if,
if
we
could,
if
we
planned
it
out
and
and
put
two
weeks
between
releases
and
it
needs
four
releases,
it's
probably
best
if
we're
gonna
start
soon.
B
B
I
don't
think
anyone
actually
wants
to
use
go
as
a
prototype,
because
we
have
so
much
experience
from
go
already
present
so
that,
but
but
it
looks
like
we're
going
to
end
up
needing
to
rename
things
what
you
know
and
at
least
introduce
another
new
synchronous
instrument,
or
something
like
that
and
all
of
which
the
the
thing
I
tried
to
say
at
the
very
beginning
of
this
meeting
is
I
I
have
a
lot
of
confidence
that
we
could
complete.
B
We
could
create
a
completely
new
api
in
a
completely
new
package
that
depends
on
the
existing
sdk
without
really
changing
the
existing
sdk
that
doesn't
really
help.
You
could
also
create
the
new
api
inside
the
same
packages,
which
would
be
a
mixture
of
old
new
in
the
same
place,
which
I
don't
think
would
be
very
good.
But
then
you
just
mark
a
bunch
of
stuff
deprecated.
B
The
stuff
I'm
just
not
very
confident
about
is
is
go
modules
in
the
sorcery
that
that
is
involved.
But
I
think
I
do
know
what
I
need
to
do.
What
would
need
to
be
done
and-
and
I
think
the
first
step
would
be-
to
try
and
split
the
net
http
instrumentation.
A
Yeah,
I
think
if
that
makes
sense,
we
should
come
up
with
a
standardized
like
pipeline.
I
think,
if
that
makes
sense,
that
we
could
do
that
work.
Now.
I
I
think
I
did
I
was
trying
to
make
said
is
like
I
don't
want
you
to
start
working
on
the
the
new
metrics
api
tomorrow.
Okay,.
A
Yeah
but
yeah.
If
we
wanted
to
start
splitting
out
the
instrumentation,
I
think
that's
a
good
first
step,
while
the
api
is
still
like,
you
know,
setting
in
the
oven.
So
that
makes
sense.
I
think
we
should
try
to
like
come
up
with
a
policy
or
update
our
naming
policy
in
the
instrumentation
repository.
A
The
first
thing
that
comes
to
mind
is
exactly
like
what
you're
describing
is
like
you
know,
like
say
in
the
http
library,
our
current
package
name
is
like
hotel
http
like
create
two
subpackages
one
metric
one
trace.
A
I
I
don't
know
if
we
want
to
like
change
the
naming,
because
bogdan
or
other
people
are
not
gonna,
be
happy
with
that
many
number
of
trace
and
metric
packages,
but
like
yeah
and
then
because
I
think
the
the
end
goal
is
maybe
eventually,
like
you
know
a
year
or
two
from
now
like
we
take
both
those
packages,
we
recombine
them
into
a
single
like
top
level
package,
and
I
want
to
leave
that
option
open.
Where,
like
we
could
eventually
like
come
back.
A
Unified
name
but
yeah,
so
I
don't
want
to
like
you
know,
completely
split
out
the
top
level
path
and
then
have
people
have
to
change
import
names
or
something
like
that
severely
or
something.
But
that's
just
my
idea.
B
Yes,
I
I
totally
support
that,
and
this
is
where
I
feel
at
least
confident
in
my
planning
ahead
for
go
module
naming
but
because
I've
I've,
I
mean,
we've
seen
a
lot
of
mistakes
that
I
wouldn't
have
anticipated.
Not
that
I
made
those
mistakes.
I
just
you
know
so
I
feel
like
I'm
not
close
enough
to
the
code
to
like
really
dive
in
and
do
anything
at
the
moment
because
of
many
other
distractions,
including
a
tree.
B
That's
being
cut
outside
my
house
right
now
is
very
loud
and
because
I've
also
promised
a
few
things
to
the
to
the
api
and
the
data
model
groups
for
metrics
within
the
next
week
and
a
few
other
things.
So
I'm
not
sure
that
I
can
really
commit
in
the
next
week
and
a
half
anything.
So
that's
two
problems.
I
don't
know
if
I
know
what
to
do,
and
I
don't
know
if
I
have
any
time
in
the
next
week
and
a
half,
I
think
I
know
what
should
be
like.
B
A
I
think
that's
yeah,
I
think
that's
fair.
I
think
that's
also
a
fine
timeline
again,
like
I
said
like
I
am
super
focused
on
the
trace
rc.
We
have
11
issues
still
to
do.
Six
currently
active
right,
like
we
have
plenty
of.
C
Work
to
do
okay,
you
know.
A
I
don't
think
that,
like
we're
sitting
here,
waiting
to
get
this
stuff
done,
especially
as
the
api
is
kind
of
like
you
know,
getting
worked
out,
so
I'm
not
too
worried
after
the
rc.
Our
plan
was
to
then
try
to
look
at
the
instrumentation.
Well,
I
think
there's
a
few
things
in
our
planner
look
through
our
notes,
but
like
one
of
them
was
like,
let's
look
at
the
instrumentation
packages
and
see
like
if
we
can
clean
this
up
and
start
to
release
some
of
these
as
stable
as
well
yeah,
so
yeah.
A
I
think
that
was
kind
of
like
the
goal
there
and
yeah
we'll
that's
what
I'm.
A
Sorry,
let's
thing
like
if
we
can
get
the
rc
done,
you
know
in
in
the
next
month,
and
then
yeah,
hopefully
maybe
two
months
but
like
in
that
time
frame
that
the
api
should
become
really.
You
know
a
lot
clearer
as
to
what
we
need
to
be
changing
to
in
the
first
place,
and
so
this.
A
B
I
was
going
to
add
to
that
that,
as
far
as
light
steps
priorities,
we
would
rather
have
the
rc
and
tracing
done
than
have
me
or
gustavo
working
on
this,
but
as
soon
as
the
rc
is
out,
gustavo
becomes
more
available
to
help
with
this
type
of
problem
as
well.
So
it's
because
we
have
the
same
priorities
as
you
that
we're
that
we're
having
gustavo
work
on
trace
with
you
all
yeah
okay.
So
so
I
another
way
of
saying
that
is
eventually
I
I
can
add.
B
A
B
Yeah
yeah
before
starting.
That
sounds
good
because
I
think
probably
the
way
I
work
best
is
to
just
like,
like
get
in
the
code
and
like
see
what
happens
and
then
show
you
a
pr
and
say
here's
what
I
learned
this
is,
I
think
how
we
have
to
move
forward.
So
then
that
sounds
good.
I
will
definitely
commit
to
this
okay
cool.
B
I
really,
I
feel
I
feel
that
this
is
also
worth
just.
The
code
is
worth
saving
and
that's
part
of
my
motivation.
C
So,
on
the
topic
of
ensuring
that
we
get
the
trace
rc
out,
do
we
have
a
plan
for
what
we're
doing
with
the
otop
exporter?
So
I
think
that's
the
the
one
thing
that
we
really
need
to
solve
before
we
we
can
say
I
I
think
standard
out
exporter.
We
can.
I
wouldn't
care
if
we
leave
that
as
unstable
right,
because
people
aren't
going
to
be
using
that
in
production.
Yes,
real
things
right,
but
oglp.
B
A
Yeah,
I,
if
you
have
time
I'd,
love
to.
B
A
Yeah,
I
don't
know
what
that
interface
would
look
like,
but
if
you
feel
confident
in
that,
I
I'd
love
to
see
that
approach.
It
might.
C
And
I
think
that
concept
is
probably
a
good
way
to
go.
It's
at
least
something
that
I
would
explore
too.
If
I
were
to
try
to
take.
C
Think
that's
worth
exploration,
as
you
say,
yeah
the
otlp
or
the
the
hotel,
http
metrics
trace
split
might
be
a
bit
harrier
because
the
metrics
and
the
traces
are
kind
of
intertwined
there
right
there,
they're
metrics,
that
you
could
generate
from
spans.
They.
C
B
There
is
an
efficiency
story
that
says
it's
great.
If
you
combine
your
instrumentation,
which
is
one
of
the
long
plays
of
hotel,
but
I
think
for
the
short
term,
we
just
have
to
say
pay
the
cost
of
double
instrumenting
a
little
bit
here,
okay.
So
the
action
item
is
when
I,
as
soon
as
I
can
hopefully
a
week
and
a
half
or
less
try
to
wrangle
the
hotel
repository
in
a
way
that
you
can
get
otlp
for
trace
and
not
link
in
metrics.
B
A
B
Yeah
I,
like
maybe.
B
B
A
I
you
said
it
so
at
least
a
little
bit
yeah,
that's
fine!
I
I'm
pretty
much
rubber,
stamping
the
metric
stuff
at
this
point,
because
I
don't
have
a
strong
understanding
of
where
it's
going.
So
as
long
as
you
think,
it's
a
good
change,
I'm
okay
with
it.
Okay,.
B
Cool
yeah,
I
didn't
know
there
was
any
metrics
changes.
I
I
would
be
happy
to
review
anything
if
you
want
me
to
cool
all
right.
Thank
you
all.
I
will
be
present
for
this.
I
will
show
up.