►
From YouTube: 2021-06-24 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
well
doing
well,
I'm
just
catching
up
on
the
message
you
sent
me
yeah,
I'm
sure
to
ping
you
back
after
this
is
off
sorry
about
the
late
response.
Yeah.
A
Yeah,
I
think
that
we'll
jump
into
the
meeting
here
a
little
bit,
but
your
first
pr
is
ready
to
merge
the
second
one.
I
haven't
taken
a
look
at
yet,
but
I.
B
A
A
A
Oh
shoot,
okay,
I
think
we
might
have
quorum,
let's
see
gustavo,
but
otherwise
I
think
we
probably
have
enough
people
to
get
started
here.
Well,
start
off.
Welcome
everyone,
please
be
sure
to
add
your
name
to
the
attendees
list
on
the
agenda
doc
and
if
you
have
anything
you
want
to
talk
about,
add
it
to
the
agenda.
Please
we'll
get
started
here.
If
I
can
figure
out
how
to
share
my.
A
A
Yeah
one
more
thing:
okay,
cool
yeah,
so
welcome
everyone.
We
have
a
pretty
light
agenda
for
the
day,
so
I
imagine
we
could
probably
get
out
of
here
and
maybe
record
time
actually,
unless
someone
has
something
to
talk
about,
it's
been
kind
of
a
slow
week.
I
know
I
have
been
working
on
some
other
things,
not
particularly
dedicated
to
the
project
so
reduced
time
on
here,
but
still
actively
looking
at
it.
A
Here's
the
current
project
boards,
one
of
the
things
I
wanted
to
do,
which
I
forgot
to
do
right
before
the
meeting
was
we
can
close
out
this
other
project
board
here.
If
there's
no
objections
yeah,
I
guess
that
was
a
one-click
sort
of
thing.
Okay,
so
yeah
that
project
board,
I
think,
should
be
all
set.
A
We
have
updated
the
docs
and
we're
looking
at
this
new
project
board
here
that
we
were
just
looking
at
and
we
have
six
items
already
done
three
to
do
this,
one
kind
of
being
the
I
think,
the
important
one
for
this
cycle
just
make
sure
you're
making
sure
we
get
feedback.
There's
nothing
here.
I
should
probably
assign
this
to
myself
unless
somebody
else
is
really
excited
to
pick
it
up.
A
I
don't
have
the
most
amount
of
time
this
week,
but
I'm
planning
to
get
after
this
next
week,
so
hopefully
that's
something
we
can
take
on.
Otherwise
we
have
two
node
issues
already
identified
and
I
think
that's
pretty
good.
There
might
have
been
another
one.
I
meant
to
do
a
little
bit
more
triaging
right.
Before
being
sorry,
I'm
not
the
most
prepared.
I
thought
I
saw
another
one
come
back
in
yeah.
This,
I
think,
also
needs
to
get
included.
That
was
the
one
or
at
least
decided
on
before
that
rc.
A
So
three
issues
in
the
two
four
issues
in
the
to-do
column,
but
yeah
so
pretty
light
nothing
too
much
to
talk
about
there.
I
don't
know.
We
also
wanted
to
talk
about
something.
A
Cool
moving
on,
we
have
robert
talking
about
some
prs
with
some
race
conditions.
It
looks
like.
B
Pr's,
but
one
one,
I
think,
is
more
important
and
it
is
this
one,
so
basically,
this
just
fixes
a
race
condition.
I
know
that
at
least
an
attorney
already
reviewed
it.
So
it's
quite
simple
and
I
think
that
this
one
could
be
safely
probably
merged.
Of
course,
after
reviews
and
the
second
one
is
more,
is
a
lot
harder
and
basically
I
do
not
think
the
second
one
is
high
priority,
but
you
you
can
take
a
look
and
judge
yourself.
A
D
I
I
have
not
like
I've,
barely
been
able
to
carve
out
this
recently
this
meeting,
so
I
can
try
and
take
another
crack
at
it,
but
I
don't
know
when
it
might
not
be
till
monday.
Honestly.
So.
A
I
agree
yeah,
I
there's
not
a
immediate
pressure
to
get
this
merged,
but
I
yeah
just
a
heads
up
on
the
put
on
your
radar.
I
guess
monday
sounds
perfectly
fine,
imagine
maybe
even
tuesday.
C
A
A
A
C
I
looked
at
it,
it
seems
like
it
is
probably
the
right
thing
to
do.
My
only
comment:
there
was
just
about
those
tests
that
there
there
was
a
comment
that
you
could
uncomment
that
and
test
that
serrama
is
doing
the
same
thing
without
the
wrapper.
So
I
think
we
should
probably
just
test
both
if
it's
just
a
case
of
wrapping
that
that
whole
test
in
a
for
loop,
one
that
wraps
the
producer
and
one
that
doesn't,
then
we
we
get
at
least
notification
if
we
start
behaving
differently
than
drama
under
these
scenarios.
C
A
Yeah,
okay,
perfect
cool.
Well,
that
is
everything.
So
maybe
it
is
this
record
time
for
our
meeting
this
week.
Yeah
I
it's
I'm
guessing
people
are
taking
a
little
bit
of
a
breather
after
we
got
that
rc
out.
I
know
I
am.
I
know
that
I'm
answering
a
lot
of
questions
here
internally
at
splunk
that
have
been
asked
me
over
the
past
few
weeks.
So
yeah-
I
imagine
this
is
pretty
common.
I
see
josh
might
be
on
the
call.
Maybe
I
should
stop
sharing
the
screen.
E
Hi
hi
tyler,
I
I
have
been
trying
to
come
to
these
meetings
last
week,
got
interrupted
halfway
through,
but
I'm
I'm
here
again
sorry.
I
was
a
minute
late.
Two
I
just
wanted
to
say
to
everyone.
E
I
am
starting
to
ramp
up
on
hotel,
go
again,
I've
updated
some
of
our
code
bases
to
the
latest
release
and
I'm
getting
more
familiar
with
kurt
state
or
like
things
that
I
missed
in
the
last
months
or
many
months
it
turns
out,
and
I
want
to
do
work
on
metrics
sdk
and
api
development.
I
I'm
pretty
pleased
with
the
current
state
of
the
sdk,
although
I
have
a
long
list
of
minor
things.
E
I'd
like
to
do,
I
feel
like
the
priority
right
now
is
on
getting
an
api
directory
and
package
that
looks
good
in
godoc
and
I'm
remembering
back
to
some
very
specific
feedback
that
yana
brought
to
this
meeting
once
almost
a
year
ago.
Maybe
so
I've
been
sort
of
thinking
about
like
api
first,
like
reskinning
of
the
sdk,
because
I
don't
my
theory
hypothesis-
is
that
the
sdk
doesn't
really
need
to
change
to
accommodate
a
new
api.
E
So
that's
where
I'm
starting
I've
considered
ways
of
just
cutting
back
on
code
density
and
complexity
in
the
api
package
as
an
alternative
like
just
kind
of
subtractive
fixes
like
can
I
move
stuff
out
of
the
package
that
maybe
could
move
into
an
internal
directory
or
could
move
into
a
sub
package
where
it's
not
going
to
clutter
the
documentation
if
it's
like
purely
implementation
machinery,
I
think
that
would
help
so
I've
thought
about
both
approaches
and
I'm
still
not
sure
which,
which
I
like
best
like
the
sort
of
like
fix
in
place
and
rename
in
place
to
get
to
the
current
place
where
the
specs
are
or
start
from
scratch.
E
With
a
like
lightweight
like
easy
to
read
documentation,
I
think
the
second.
My
approach
is
my.
My
first
stab
is
going
to
be
to
try
from
scratch
and
then
I'll
probably
run
into
a
wall
and
think
gosh.
I
don't
want
to
reinvent
this,
because
I've
done
it
once
so,
just
to
that's
my
report
as
I'm
starting
to
think
about
that.
I've
also
been
like
a
little
bit
thinking
out
of
the
box.
E
There's
a
proposal
coming
for
multivariate,
metrics
and,
and
it
argues
that
you
should
redesign
the
record
batch
api
in
some
ways,
so
I
also
kind
of
thought
about
removing
both
batch
interfaces,
which
is
where
much
of
the
complexity
comes
from.
Well,
mostly,
the
asynchronous
batch,
which
is
like
hugely
complicated.
E
So
I
could
take
that
stuff
out,
but
I
think
it's
kind
of
like
some
kind
of
batch
facility
is
probably
important
in
the
long
run
for
go.
The
other
thing
you
could
imagine
taking
out
is
bound
instruments,
and
but,
but
I
know
the
specs
are
like
someone's
gonna
propose
very
soon
to
to
say
that,
like
there's,
each
language
can
choose
an
optional
mechanism
for
optimizing.
The
code
path
and
one
of
them
is
abound
instruments.
It's
a
very
classic
pattern.
It
works
in
java.
E
E
There's
like
also
the
segment
io
has
a
library
that
does
like
a
very
different
approach
to
api,
which
is
based
on
a
struct
with
some
field
tags
and-
and
I
could
definitely
imagine
an
interface
like
that,
but
it
would
mostly
benefit
this
multivariate
case
like
if
I
have
to
record
six
metrics
in
one
statement
I
can
fill
in
a
struct
with
six
fields
and
they
have
struct
tags
that
say
what
kind
of
instrument
they
were
and
I
registered
this
multi
instrument.
E
Maybe
that's
a
good
way
to
do
batch,
recording
synchronously,
maybe
that's
another
way
to
do
a
way
to
think
about
doing
batch,
recording
asynchronously.
That's
all
those
are
all
my
thoughts,
I'm
kind
of
working
with
right
now
and
I'll
keep
coming
to
report
back.
A
Cool
yeah
that
all
sounds
interesting
very
interesting,
actually
is
gustavo
still
active.
E
A
C
One
thing:
that's
not
specifically
really
related
to
this
egg,
but
the
the
spec
issue
that
I
created
to
discuss,
adding
the
tracer
provider
method
to
the
span.
Api
bogdan
had
asked
a
question
there
regarding
how
that
would
be
handled
for
metrics
and
logs,
and
I
know
you
had
expressed
some
thoughts
about
the
the
need
for
that
for.
C
Sorry
about
that,
the
the
need
for
that
for
the
four
meters
I
think
for
logs
we
probably
stick
a
logger
in
the
context
and
give
the
ability
to
pull
and
locker
from
the
context.
I
don't
know
that
there's
a
whole
lot
that
is
going
to
be
in
the
logging
api
beyond
a
logger
and
that
kind
of
encapsulates
all
of
the
current
contacts
plus
the
the
pipeline
and
all
of
that.
E
Yeah,
okay,
thank
you
anthony.
I
remember
some
early
discussions
and
some
I
I
mentioned
in
the
moment
of
this
tuesday
meeting
when
you,
when
we
were
talking
about
this,
how
I
sort
of
wish-
or
you
know
that
there
was
some
sort
of
context
and
a
way
to
refer
to
a
provider
for
all
the
telemetry
sources,
and
I
guess
the
reason
why
I
said
that
in
response
to
what
you
just
suggested,
is
that,
like
there's
this
big
question
about
whether
you
register
instruments
with
a
provider
or
whether
you
just
register
instruments?
E
E
E
So
I
think
I
don't
feel
like
spending
cycles
arguing
for
it.
But
my
what
I
would
like
to
see
would
be
a
single
provider
concept
that
has
metrics
providers,
trace
providers
and
logs
providers
and
then
there'd
be
a
current
one
of
those
in
the
context.
E
Whatever
that
means
in
each
language,
I
also
like
I
mean
in
terms
of
ancient
documents
on
this
topic.
E
So
you
could
say,
given
a
provider
put
in
the
context,
now
call
into
some
code
and
that
code's
going
to
say,
I'm
changing
my
resource
context
by
adding
some
scope
variables
and
you
push
those
into
the
resource
and
then
you'd
have.
You
know
essentially
find
grain
resources
and
you
could
control
it
using
contexts
and
providers.
E
There's
an
old
ot
issue
with
this,
and
a
branch
of
the
ancient
hotel
go
code
base
that
I
packed
this
together
to
show
what
it
would
look
like,
but
it
just
always
felt
like
a
roadblock
for
otel
to
start
talking
about
putting
providers
in
contexts
and
and
what
that
really
means,
because
we
don't
you
know
as
soon
as
you
start.
My
proposal
about
resource
scope
starts
to
say
that
resources
should
not
be
constants
that
there's
some
other
research
like
data
model
there,
and
it
requires
you
to
change
your
data
model
for
resources.
E
E
In
any
case,
I
feel
like
open
census
was
the
one
that
sort
of
set
forth.
This
idea
about
sorry,
open
census
had
hadn't
ever
addressed
the
resource
scope
concept,
nor
had
open
tracing.
So
we
were
sort
of
left
with
very
little
in
open
telemetry
for
resource
semantics
and
so
on.
A
So
anthony
one
of
the
things
I
was
thinking
about
also
with
that
comment
that
bogdan
left
is
one.
I
think
that
it
introduces
scope
to
that
pr
that
shouldn't
be
introduced,
that
pr
is
dedicated
to
solving
the
tracing
problem,
but
I
understand
his
concern
if,
like
we
want
to
have
similar
things
in
other
signals
that
may
be
worth
considering.
I
don't
know
if
that
stuff
should
be
blocking
that
issue,
though,
and
I
think
that
kind
of
is
the
answer
that
I
came
to
as
well
for
that
metric
set
of
the
question.
A
Was
it
that's
kind
of
what
josh
was
just
saying
like
it
may
not
or
what
you
were
saying
as
well?
It
may
not
make
sense
to
do
that,
like
the
concept
of
an
instrument
may
be
something
that
the
instrumentation
itself
is
like
created
on
startup
and
since
that's
the
case
like
it
may
not
make
sense
to
have
it
like
propagated
through
some
sort
of
context,
request
path.
Rather
it's
just
something
that
is,
you
know
a
part
of
the
instrumentation.
C
Yeah,
I
think,
there's
discussions
on
going
in
the
metrics
api
sig
as
well
about
how
to
deal
with
multiple
sdks
within
an
application.
If
you
want
to
push
and
pull
or
have
one,
that's
high
frequency,
one,
that's
low
frequency,
so
that's
probably
a
better
place
to
to
resolve.
A
A
But
yeah
a
little
a
little
aside
here
for
the
ghost
egg,
but
I
think
it's
important
for
those
that
didn't
go
to
the
specification
meeting.
One
of
the
concepts
that
also
came
up
with
this
tracer
provider
thing
was:
maybe
it's
just
a
go
thing,
so
I
think
that
kind
of
actually
is
a
good
decision
or
a
good
default,
because
we
kind
of
talked
about
this
last
week,
where
it
was.
You
know
if
at
worst
that
that
could
be
the
case.
A
The
only
thing
we
didn't
want
to
have
happened
was
that
we
put
it
in
there
and
then
all
of
a
sudden,
the
hotel
people
decided
to
specify
it
differently.
So
I
don't
think
that
that's
gonna
be
the
case.
So
it's
a
positive
news.
A
E
There
maybe
have
been
a
bird
chirping.
I
have
nothing
more
to
add,
but
I
appreciate
the
reminder
anthony
about
that
issue
and
I'll
try
to
think
of
what
we
should
say
about
metrics.
There.
A
D
A
Kind
of
where
it's
going
too,
we
have
josh
on
the
call
who
sometimes
has
some
really
interesting
user
cases
or
use
cases
of
hotel.
So
everybody
else
has
some
ideas.
C
Liz
did
forward
me
a
question
yesterday
via
twitter
from
someone
at
ccp
who
make
eve
online,
which,
as
a
long
time,
eve
player,
is
very
exciting
to
me.
They
had
some
questions
about
how
to
use
the
hotel
go
api,
and
I
know
there
are
already
honeycomb
customers
using
that
so
presumably
they're
starting
to
instrument
some
of
their
systems
with
hotel
go,
which
is
very
cool.
C
A
Yeah,
this
is
really
cool.
I
feel
like
we
need
a
spreadsheet
plug-in
for
eva
online
or
something
like
that
eve
is
a
spreadsheet,
plug-in
yeah
right
yeah,
that's
really
good
to
hear
I.
I
love
hearing
these
stories
of
adoption,
but
also
makes
us
understand
that
the
work
we're
doing
is
valuable
not
going
into
a
void.
That's
always
really
helpful.
A
David
any
update
on
the
grpc
kubernetes,
yes,.
F
So
I
actually
I
sort
of
have
a
user
question.
In
a
sense,
it
is
a
kubernetes
api
server,
a
public
endpoint
or
not.
C
C
A
C
Is
is
public
there
kind
of
has
a
slightly
broader
meaning
than
just
is
this
available
to
the
general
internet?
I
think
it
means,
is
there
a
trust
boundary
between
the
caller
and
us
right,
yeah,
which
may
still
be
on
two
private
networks,
but
I
don't
want
my
trace
to
be
a
child
of
or
my
spanish
to
be
a
child
of
what's
over
there.
I
I
just
want
to
create
my
own
and
know
that
that's
their
create
a
link
so
that
I
can
correlate
them
later.
C
If
someone
comes
to
me
with
a
customer
support
question
or
something
like
that
right,
I
imagine
this
is
probably
going
to
be
a
common
use
case
for
cloud
providers
as
well
right,
say:
aws
is
doing
internal
tracing
of
our
services
and
the
request
one
of
our
apis
comes
in
it's
bearing
trace
context.
We
want
to
say
okay,
we'll
link
to
that,
but
we're
creating
our
own.
A
Yeah,
okay,
I
think
that's
yeah.
I
don't
know
if
there's
a
good
answer.
It's
a
good
question.
That's
definitely
the
right
question.
I
I
think
it's
probably
one
of
those
things
where
it's
probably
best
to
be
safe
by
default
and
then
maybe
provide
a
configuration
to
allow
overrides
of
that.
But
yeah,
I
don't
know
it's
a
good
question.
A
Cool
yeah
awesome.
Well,
I
think,
with
that
we
could
probably
close
it
out,
I'm
going
to
give
it
a
little
pause
if
marielle
says
something
else.
I
wanted
to
add.
A
Well
perfect,
a
short
week,
hopefully
everyone's
enjoying
a
little
bit
of
a
break
as
we
kind
of
pick
up
the
momentum
and
try
to
get
this
rc
out,
hopefully
get
some
more
feedback
in
the
next
few
weeks
and
hopefully
get
some
more
work
done.
Thanks
to
everyone
for
joining-
and
I
will
see
you
all
next
week
or
virtually.