►
From YouTube: 2021-10-07 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
A
A
B
A
C
C
C
On
this,
it's
not
a
big
deal,
so
I'd
be
okay
with
just
removing
the
open
telemetry.
If
it's
based
off
consistency.
C
I
would
think
it's
like
like
for
the
team
mentions,
it's
like.
C
Like
like,
I
guess
what
do
mentions
do
right,
they
just
they
notify
you
on
github
and
I
guess
you
could,
like
click
on
it
as
a
hyperlink
to
go
to
the
team.
I
guess
right.
Those
are
the
two
things.
A
C
C
Oh
yeah,
I
think
these
are
the
pr's
transferred
from
last
week,
so.
C
Pretty
sure
I
we
looked
at
this
before
yeah,
I
did
yeah.
A
A
A
A
thing
to
me
already
yeah
I'll,
take
a
look
this
week.
C
Yeah,
I
have
a
question
for
that
one
actually
for
adding
like.
I
guess
it's
not
a
huge
change,
but
it's
still
kind
of
like
support
for
it.
Should
we
should
we,
like
maybe
inquire,
maybe
he
if
he
wants
to
be
an
owner
for
this
or.
A
I
find
people
to
fix
things
yeah
and
then
we
have
this
one.
Do
you
want
to.
D
D
Like
not
satisfying
the
baggage
requirements
earlier,
we
were,
you
know,
skipping
the
extra
entries
or
like
invalid
entries.
Do
we
want
to
do
that
or
do
we
want
to
just
state
in
the
empty
context.
D
D
Yeah
that
we
will
so
if
you
scroll
down,
I
have
added
a
comment.
There.
D
So,
for
for
some
cases
we
were
written
in
empty
context
and
for
some
cases
we
was
trying
to
skip
it.
So
I
changed
the
implementation
to
you
know
written
the
empty
context
in
all
and
all
invalid
cases
this.
This
is
also
the
case
with
the
other
language
implementations
if
they
find
out
that
at
least
one
baggage
entry
is
invalid.
A
D
Just
written
the
error
message
and
empty
span
con
sorry
empty
context.
D
So
the
baggage
entry,
even
if
like
one
entry,
is
invalid,
they
lock
their
message
and
then
they
send
the
md.
I
see.
A
D
It
probably
like
it's
like
they
could
also
just
you
know,
drop
that
single
entry
and
then
continue
it.
But
I'm
not
sure
if,
like
what's
the
reason,
they
chose
that.
A
D
Like,
for
example
like
if
the
if
the
entry
has
like
so
we
only
allow
like
there's
a
maximum
number
of
entries
that
we
want
to
have
if
the
entries
number
of
entries
exceed
that,
do
we
want
to
write
an
empty
context,
or
do
we
want
to
ignore
the
the
extra
ones.
A
A
Yeah,
I
know
you
could
you
could
argue
both
ways?
Maybe
maybe
return
return,
the
number
of
entries,
so
at
least
some
things
keep
working.
So
imagine
a
use
case
where
there's
a.
A
And
someone
adds
additional
entries,
and
that
makes
everything
that
breaks
everything.
So
if
we,
if
we
return
at
least
the
valid
ones,
then
existing
use
cases
keep
working,
but
the
new
new
feature
that
was
added
does
not
work,
but
on
on
the
flip
side,
it
makes
things
hard
to
like
it
makes
hard.
It
makes
it
harder
for
users
to
detect
breakage.
I
guess.
A
D
So
the
max
max
length
check
is
for
the
like
whole
header
length,
and
then
there
is
also
number
of
pages
that
we
want,
like
the
number
of
entries,
that
that
should
be
there
in
the
baggage
header
that
can
also
exceed
like
it.
Can
it
may
satisfy
the
maximum
header
length,
but
it
may
not
satisfy
the
number
of
entries
length.
D
So
in
in
case
of
when
they
exited,
we
were
returning
an
empty
context.
I
see,
but.
C
D
C
D
Technically,
it's
still
an
invalid
header
so
like
in
one
case
we
were
retaining
an
empty
context.
In
one
case
we
were
returning
like
we
were
keeping
them
so
in
in
this
pr
I
retaining
an
empty
context
in
in
all
the
invalid
cases.
I
wanted
to
ask
like
what
do
we
want
to
hear.
C
Yeah,
that's
a
question
I
feel
like
as
long
as
we're
consistent.
It's
good
would
this
be
actually
breaking.
D
So
assuming
that
users
know
that,
like
they
have
to
follow
the
maximum
header
and
number
of
pages
that
they
can
put
in
the
baggage,
this
will
not
really
affect
for
those.
You
know
who
are
following
the
back
specification,
but
but
I
wouldn't
expect
right
yeah
this.
This
kind
of
very
detailed.
A
I
am,
I
think,
as
long
as
we
like
this
pr
audio
does
a
good
job
of
adding
these
warnings
and
they
they
explain
in
in
detail
whether
they
explain
exactly
what's
wrong.
So
this
is
as
long
as
we
don't
like
throw
a
generic
message.
Header
is
invalid
and
actually
tell
the
user
what
they
need
to
fix
to
make
it
work.
C
Actually,
I
actually
prefer
the
like
just
the
drop
individual
entries
in
baggage,
but
not
not
for
like
a
specific
conceptual
reason,
but
like
it's
kind
of
like
what
we're
doing
for
attributes
already,
you
know
so
it
will
be
at
least
a
common
theme
across
like
our
our
like
api
surface
right,
then
again,
I
don't
know
if
baggage
and
attributes
have
like
similar
character
should
have
similar
characteristics
like
conceptually
right,
like
does
it
makes
like
for
attributes
like
to
drop
one
key
value
pair,
like
the
attribute,
still
makes
sense
right,
but
like
for
baggage,
I
don't
know.
C
C
A
I
think
just
dropping
in
valid
one
sounds
fine,
but
I'm
not
sure
if
we
want
to
label
it
as
being
consistent
with
attributes.
Just
for
the
reason
like
tomorrow,
we
might
have
another
another
similar
question
like
in
a
similar
design
decision
and
then,
if
we
use
the
argument
to
stay
consistent,
attributes
that
might
not
make
sense,
always
for
baggage.
A
A
Yeah,
that
makes
sense.
I
guess
I
guess
what
I
was
trying
to
say
is
not
to
document
or
like
oh.
D
Maybe
maybe
I'll
create
an
issue
on
the
specification
because,
like
like
different
languages
following
different
like
I,
I
also
inclined
to
you,
know,
include
the
valid
ones
and
you
know,
drop
the
invalid
ones,
but
different
languages
following
different
like
different
ways
of
doing
it
might
not
be
a
best
experience
for
the
end
user.
I
think
getting
this
clarified
from
the
specification
might
help.
D
Sure
yeah
I'll.
A
Yeah,
I
think
we
should
decide
what
you
want
to
do
now,
merge
this
and
then
go
to
spec,
and
we
can
update
it
later
like
we
can
go
to
spec,
not
with
the
question,
but
with
the
recommendation
that
this
this
is
what
should
happen
and
the
recommendation
should
probably
be
the
same.
I
mean
it
should
be
the
same
as
what
we
merge
in
the
sphere
and
and
if
expect
disagrees,
then
we
can
go
and
update
it
later
again.
I
guess
we
already
decided
that
it
wouldn't
be
a
breaking
change.
Right,
so
should
be
fine.
D
Sure,
because
I'll
make
the
change
right
now,
it's
written
in
the
context
in
that
case,
but
I'll
change,
the
implementation.
C
Oh,
just
I
guess
kind
of
off
topic
for
related
to
that.
I
guess
that's
also
related
to
like,
like
what
we're
going
to
be
doing
for
like
error,
handling
and
stuff
right,
like
it's
like
another
use
case,
just
a
heads
up,
but.
C
Oh,
like
the
like
the
whole
like
discussion,
what
we
had
last
week
about
like
right,
what
kind
of,
like
you
know,
errors
that
we're
gonna
be
catching.
A
All
right
all
right,
so
that's
all
that's
here,
but
I
we
also
wanted
to
discuss
this
vr.
Unfortunately,
diego
is
not
here
and
he
had
some
opinions
on
it.
So
maybe
we
can.
C
A
Sorry
topic
my
generic
name,
yeah.
B
Yeah,
so
I
actually
before
I
even
commented,
I
I
noticed
that
they
tagged
the
java
one
up
here
and
they
already
renamed
it.
So
if
you
hover
over
the
java
contrib
at
the
very
first
yeah
you
just,
however,
you
see
it
says
hover
a
card
is
unavailable.
So
I
think
that's
your
answer.
B
C
B
C
Just
I
just
don't
care
enough
about
this,
to
be
honest,
like
like
it's
good
practice
to
question
stuff
like
this,
but
I
really
don't
care
yeah.
A
Okay,
so
the
next
thing
was
the
new
open
telemetry
package
that
I
had
proposed
into
the
design
dock
that
I
presented
last
week
and
so
part
of
the
proposal
was
this-
that
this
package
would
contain
a
helper
function
called
configure
tracing
and
then
feature
configure,
metrics
and
logging
as
well,
and
that
will
allow
people
to
easily
manually
instrument
it
as
described
in
the
in
the
document.
You
can
take
a
look
again
and
it
will
also
host
the
hotel
instrument
and
bootstrap
commands
to
make
it
possible
to
to
automatically
instrument
applications.
A
But
diego
has
a
concern
that
that
the
instrument
command
should
stay
in
open,
telemetry
instrumentation
package.
So
but
unfortunately
we
cannot.
We
cannot
discuss
it
he's
not
here.
B
A
A
But
when
you
run
it,
if
you
don't
configure
the
sdk,
somehow
it
just
doesn't
run
doesn't
work.
It
doesn't
do
anything,
so
it
has
an
implicit
implicit
dependency,
whether
we
like
specify
it
in
packaging
or
not.
So
if
you,
if
you
look
at
it,
I
tried
to
quickly
add
some
diagrams.
A
A
Sdk
also
uses
open
generally
instrumentation
has
a
explicit
dependency
on
it,
but
since
this
package
contains
the
command
instrument
command,
it
has
an
implicit
dependency
on
sdk
like
there
is
a
circular
dependency
in
it
like
at
a
conceptual
level
how
we
avoid
this
is
that
we
add
an
entry
point
for
sdk
configuration
in
this
in
the
command,
and
that
way
we
kind
of
side
load
the
sdk
instead
of
importing
it
directly,
and
then
we
have
the
open,
telemetry
disk
draw
and
right
now,
the
instrument
instrumentation
command
also
has
an
impulsive
dependency
on
this
thing,
because
if
this
is
not
installed,
then
the
command
doesn't
do
anything,
and
then
we
have
this
throws,
and
they
also
depend
on
this
thing.
A
A
Where
sdk
uses
this
package,
instrumentation
packages
use
this
to
instrument
to
implement
instrumentations,
and
we
we
essentially
reduce
this
package
to
being
a
library
for
instrumentation
authors
and
nothing
else
right
now,
it's
a
library
for
instrumentation
authors,
it's
an
it's
a
cli
package
for
end
users
and
it's
it
also
has
the
base
distro.
So
it's
like
a
library
for
distro
authors
as
well.
So
if
we
just
move
this
command
here
and
implement
what
was
proposed,
then
this
is
dramatically
simplified.
Its
responsibilities
are
completely
reduced
to
only
provide
functionality.
A
That's
important
for
instrumentation
authors
to
implement
implementations
and
then,
as
the
people
who
want
to
implement
people
who
want
to
or
instrument
open
telemetry,
they
just
installed
this
package
and
it
has
excellent
dependency
on
sdk,
and
this
thing
and
distros
need
only
one
dependency.
That
will
be
the
open,
telemetry
package.
C
So
yeah,
I
think
we
talked
about
this
idea
before
about
just
splitting
the
auto
instrumentation
and
instrumentation
related
functionality.
We
just
never
executed
on
it,
so
this
is
a
way
bringing
it
to
fruition.
I
think
it's
a
good
idea
so.
A
If,
if
you
have
opinions
or
any
concerns.
C
A
C
B
Yeah,
I'm
confused
why
it's
controversial,
but
right
yeah,
like
your
second
diagram,
made
more
sense
to
me
all
the
arrows,
pointing
in
one
direction.
You
know.
C
Oh
on
a
side
note:
now
we
really
need
to
get
rid
of
this
sdk
dependency
on
open,
telemetry
instrumentation.
C
So
it's
really
like
we
kind
of
like
hacked
together
a
way
to
avoid
it
for
our
builds
and
everything.
But
it's
it
really
doesn't
make
sense
so
yep.
So.
A
A
A
Yeah,
maybe
I'll
add
it
I'll.
Add
it
to
the
notes.
B
Oh
okay,
it
looks
like
diego
did,
look
at
it,
which
I
hadn't
noticed
yet,
but
anyway,
I
just
wanted
to
bring
this
to
everybody's
attention.
B
Okay,
because
the
sorry
so
so,
basically
I
think
oh
wait.
You
worked
mainly
on
the
tracer
proxy
right
yeah
that
one
that
one
works
that
one
that
implementation
wouldn't
work
here,
where
we
basically
just
check
the
global.
When
the
user
calls
the
tracer,
because
we
have
async
instruments
in
the
metrics,
so
the
async
instruments
don't
have
they
don't
expose
any
methods
at
all.
So
once
the
user
creates
them,
they
sort
of
just
sit
there.
B
C
B
B
Got
it
yeah
anyway,
it's
implemented
here.
I
don't
think
it's
too
terrible
and.
C
B
Right
so
so,
just
like
imagine,
you
created
an
async
counter
right
and
you
give
it
a
call
back.
The
sdk
is
the
sdk's
responsibility
to
to
execute
that
callback,
periodically
right
yeah.
B
So
in
the
case
of
the
proxy,
the
way
it
works
with
tracing
is
when
somebody
actually
tries
to
use
the
tracer.
That's
when
we
look
up
if
there's
a
real
trace
of
the
provider
and
then
we
create,
we
create
all
the
real.
We
create
a
real
tracer
behind
the
scenes,
but
since
the
user
never
actually
uses
the
async
instrument,
we
don't
have
any
opportunity
to
do
that.
C
B
Yeah
yeah
and
this
this
also
avoids
so
there's
locking
when
you
create
like
new
new
proxy
instruments,
so
like
during
sort
of
the
setup
code,
but
there's
no
locking
during
the
actual
calls
to
the
instruments.
So
I
think
that
should
be.
Okay,
like
you
know,
that
should
hopefully
be
like
a
one-time
cost
when
people
create
instruments
and
yeah.
A
I
think
it
sounds
sounds
good
I'll,
take
a
look
at
the
implementation,
but
I
guess,
as
long
as
we
don't
like
the
solution
doesn't
lock
us
into
an
implementation
which
I
don't
think
it
does.
Can
we
change
or
include
later
it
should
be
fine,
I
think
I'll.
Take
it
all
right
cool.
Thank
you.
I
mean
conceptually
looks
good
yeah
all
right.
C
C
Yeah,
like
that's
pretty
much
it
like
a
lot
of
the,
we
have
a
lot
of
new
pr's
and
contrib
too,
but
that's
I
don't
foresee
people
joining
the
sick
call
to
push
those
and
apparently
recently
I
learned
that,
like
three
to
four
weeks
is
actually
not
a
long
time
for
a
pr
to
get
in.
So
I
gotta
lower
my
bar,
usually
for
for
this
kind
of
stuff.
So
yeah
I
mean.
A
I
mean
depends
on
the
pr
like
there
was
a
pr
that,
like
features
and
stuff
yeah,
there
was
a
pr
to
try
to
widen
the
supported
versions
of
ginger
or
ginger
and
scratch
yeah.
C
A
C
A
Needed
to
be
done,
yeah
after
that
there
was
another
issue.
So
so
the
issue
was
the
ci
is
checking
in
it
pulls
the
bootstrap
gen
from
core
from
a
specific
git
comment.
But
when
you
run
talks
generate
locally,
it
pulls
it
from
main.
A
C
C
A
C
A
Guess
it
wasn't
documented
in
the
list
of
steps
to
do,
but
anyway,
it
won't
even
be
required,
hopefully
yeah
all
right.