►
From YouTube: 2021-08-17 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
D
If
you're
on
the
old
notes,
then
there's
a
link
to
the
new
notes
anyways
at
the
top.
C
C
C
Okay,
let's,
let's
start
meeting,
thank
you
for
joining.
Okay.
Let's
go
over
the
agenda
items,
the
first
one
I
put
that
there.
This
is
for
pr
the
christian
mueller
put
together.
It's
basically
for
passing
resource
to
the
sampler,
should
sample
metals
yeah
this.
This
pr
has
been
there
for
a
little
time
alive,
but
recently
he
added
to
the
shoot
sample
method,
instrumentation
library.
C
So
if
we
want
to
add
besides
intermediate
library
resource
nasa
time,
there
was
initially
some
agreement
there.
But
bogdan
was
against
this.
So
since
we
are
ready
at
the
instrumentation
library
portion,
maybe
we
may
reconsider
adding
the
resource
as
well.
I
don't
know
whether
bogdan
or
christian
are
here.
They
call.
C
C
E
Yeah,
so
a
resource
on
should
sample
but
a
resource.
I
had
this
come
up
from
a
user,
the
elixir
library
asking
about
wanting
a
resource
on
the
sampler
itself,
like
they
want
the
the
the
probability
given
to
the
probability
sampler.
Instead
of
just
the
description,
it
could
be
an
actual,
an
attribute,
the
probability
and
an
integer
value
slope
value
to
would
that
be
good
time
to
add
something
like
that
or
propose
something
like
that
if
this
is
going
in.
E
Well,
I'm
kind
of
not
positive
what
should
sample
a
resource
on
that
means.
Is
it
the
same
as
a
if
the
sampler
has
a
resource?
I'm
looking,
I'm
grabbing
the.
D
No,
this
is
when,
when
should
sample
is
called,
it
will
receive
the
resource.
E
E
But
I
guess
yes,
so
that
needs
to
be
opened
as
a
separate
suggestion,
but
I
guess
if
this
is
going
in
and
making
a
change
around
there,
I
should
probably
do
that
soon
to
try
to
yeah.
C
B
In
general,
people
are
trying
to
really
leverage
the
sampler
to
do
a
lot
of
things
and
and
discovering
it
needs
access
to
just
about
everything.
So
yeah
taking
a
holistic
view
towards
maybe
just
ensuring
the
sampler
has
access
to
everything
it
might
want.
Instead
of
dribbling.
Those
changes
out
might
be
a
good
idea.
C
Yeah,
so
please
see
an
issue
and
yeah.
Hopefully
we
can
integrate
over
that
yeah
by
the
way
for
this
issue
that
I
just
mentioned
before
I
go
on
even
under
a
poster
gold
sample
saying
why
it
should
be
nice
to
have
that
so
yeah.
Please
take
a
look
at
that.
C
Okay,
next
item
similar.
This
is
a
new
issue.
It's
just
for
it's
relatively
minor
thing,
relatively
it's
to
clarifying
span,
name
expectations.
C
Basically,
the
issue
says
that
the
current
specification
of
course
mentions
what's
the
expectation,
but
it
doesn't
clearly
discourages
users
from
using
empty
or
known
strings
and
in
the
produce
for
spam
name
for
the
expanding
part.
It
mentions
that
with
you
know,
indeed,
a
non-null
string
or
empty
string
should
be
used,
and
instead
we
should
provide
a
fallback
value,
so
basically
there's
yeah.
I
think
that
at
this
moment
we
should
just
define
what
to
do.
C
I
guess
that
one
thing
I
was
thinking
myself
specifically
is
that
we
should
discourage
users
from
specifying
new
or
empty
strings,
and
then
once
that
is
done,
consider
whether
we
want
to
provide
a
default
value
or
not.
In
case
you
get
a
new
value.
In
any
case,
we
don't
have
to
discuss
that
now
here.
Just
please
take
a
look.
C
The
next
item
is
sampling
update.
I
don't
know
whether
gmcd
surrounds.
F
Josh
hi
everyone
I
am
around,
I
didn't
prepare
anything
to
say
today.
There
is
there's
a
thread
going
on
in
which
yuri
and
atmar-
and
I
are
discussing
some
of
the
details.
I
encourage
people
to
join
it
if
they
can
it'll
take
a
little
bit
of
reading.
This
is
otep
number
170,
where
the
lead
of
that
discussion
is
happening
and
there's
another
other
168
that
I'm
going
to
come
back
to
and
revise
this
week,
but
they're
related,
and
you
can
see
them
both
in
the
oteps
repository.
C
G
Riley
commented
that
he
can't
be
here,
I'm
losing
my
voice
or
I'm
actually
getting
my
voice
back.
I
should
say
so.
You'll
have
to
deal
with
that,
but
the
three
issues
that
you
see
one
is
for
the
export
specification
that
just
got
paired
down.
I
don't
think
it's
been
reviewed
since
it
was
discussed
at
the
last
metric
sig.
The
second
one
is
around
the
aggregator
specification
and
the
third
one
is
around
the
exemplar
specification,
which
is
now
marked
as
ready
for
review.
So
please
take
a
look.
Those
after
those
three
are
contributed.
G
I
think
there's
one
more
like
major
feature
to
the
sdk
and
I
can't
remember
what
we
called
it
off
the
top
of
my
head.
I
think
like
in
java
it's
called
the
interval
metric
reader,
but
it's
basically
how
to
tie
exporters
to
how
often
they
they
export.
C
C
I
think
it
needs
a
little
last
push
before
it
can
be
merged.
The
other
two
ones
are
still
being
discussed.
So
please
take
a
look.
Thank
you.
Thank
you
for
that.
E
Yeah,
so
I
was
looking
at
the
propagator
spec
for
the
first
time
in
a
long
time,
doing
some
refactoring
in
the
erlang
implementation
and
noticed
that
the
getter,
so
it
has
for
the
text-
map
propagator
a
getter
interface
with
a
kit,
that's
supposed
to
take
a
key
and
return
a
value
from
the
carrier.
E
The
issue
is
in
w3c
the
it's
supposed
to
be
able
to
return
multiple
values.
So
if
there's
multiple
trace
dates,
I
link
to
an
issue
and
into
the
issue
I
linked
to
the
test
in
the
w3c
repo.
If
there's
multiple
trace
parents
in
the
like
headers,
you
create
a
new
trace
id
and
if
there's
multiple
trace
state
headers,
you
combine
them
all
and
right
now
the
text
map
definition
in
the
spec
just
doesn't
work
for
that.
E
C
Yeah
yeah,
I
do
remember
we
removed
the
get
all
overload
or
something
like
that
for
1.0.
So
maybe
it's
time
to
try
to
play
with
that
idea
again.
Other
than
that.
I
am
not
that
familiar
with
trace
context
additional
requirements.
I
don't
know
whether
madwear
ted
or
bogdan
or
sergey.
You
can
comment
on
that.
Maybe
now
maybe
later.
E
H
There's
an
issue
comment
now,
but
I
think
generally,
it
depends
on
the
library
that
you're
using
to
get
the
headers
from
like
a
lot
of
them
already
kind
of
take
care
of
this
for
you
by
merging
multiple
trace
states.
I
I
think
the
way
that
they're
merged
is
by
like
a
pending,
but
some
of
them
don't,
and
so
I
guess
saying
that
I
think
this
would
be
a
problem
for
some
languages,
some
libraries
and
maybe
not
a
problem
for
others.
E
I
E
That
I'm
working
with
don't
automatically
concat
and
I
don't
actually
know
what
that
would
look
like
for
a
trace
parent,
I'm
guessing.
I
guess
it
would
be
considered.
It
would
do
the
correct
thing,
because
it
would
not
be
able
to
parse
that
and
just
toss
it
create
a
new
trace
id.
So
I
guess
that
does
work
for
transparent,
okay,.
C
H
H
And
and
everything
would
work,
I
can
try
to
dig
up
the
the
way
that
that
concatenation
is
supposed
to
work.
There's
an
rfc
for
it
somewhere.
E
J
Another
option
is
probably
to
extend
the
getter
to
have
a
get
that
returns,
the
first
value
and
get
all
that
returns
the
least.
So
there
is
a
path
forward.
If,
if
this
is
a
thing
that
we
really
need
to
handle.
C
C
Okay,
then,
going
forward
two
things,
I
guess.
First,
I
don't
know
whether
there's
an
instrumentation
sig
update
from
tef.
I
know
that
you
were
creating.
You
created
three
issues
or
the
group
that
you
are
working
with
created
three
issues
to
create
new
saves
and
all
that
is
there
any
updating
that
did
you
start
meeting.
B
Yes,
so
there
are,
I
think,
three
meeting
times
that
have
been
proposed.
I
think
they're
supposed
to
get
added
to
the
calendar
already
to
be
clear.
That
alolita
is
trying
to
drive
that,
so
I
would
recommend
poking
her
along
with
michael
lee,
from
from
microsoft.
B
They
they
have
already
been
meeting
in
private,
which
I
thought
was
kind
of
annoying,
and
so
I've
been
pushing
them
to
make
those
meetings
public,
which
is
why
they
posted
those
issues.
So
those
should
get
started.
I
would
guess
next
week,
there's
sort
of
just
a
last
call
for
whether
the
meeting
times
being
proposed
work.
So
let
me
just
quickly
add
a
link
to
those
issues.
B
C
B
A
C
Okay,
I
guess
the
one
issue
I
would
like
to
go
back
since
we
have
your
box
down.
Here
is
the
first
one
and
regarding
adding
resource
to
shoot
sample,
especially
because
instrumentation
library
is
now
being
passed
to
should
sample
as
part
of
a
nikita's
pr
that
was
recently
merged.
C
I
was
wondering
if
you
still
have
any
anything
against
this,
since
we
don't
have
christian
and
non-mueller
here.
We
cannot
probably
discuss
too
much,
but
if
you
want
to
say
something
or
comment
there,
but
it
would
be
nice
that
if
we
make
this
change,
we
do
it
this
release.
If
we
do
that.
J
So
if
I
understand
correctly
the
life
cycle,
a
sampler
is
attached
to
maybe
multiple
providers,
but
it's
attached
to
a
provider
correct.
So
when,
when
you
do
the
attachment
of
the
sampler,
you
can
probably
have
a
way
to
grab
this
resource
at
the
beginning.
So
so
I
I'm
not
hundred
percent
convinced
that
we
really
need
this.
That's
that's
the
the
use.
I
think
we
can.
C
I
I
I
mean
if
somebody
needs
a
sampler
that
needs
some
access
to
any
random
thing
on
the
internet.
They
can
write
that
right.
We're
not
going
to
add
that
to
our
sampler
api.
We
shouldn't
we
shouldn't
do
that,
so
it
feels
like
in
the
in
the
interest
of
keeping
the
sampler
api
relatively
constrained.
People
can
you
can
do
whatever
they
want
right
now
with
the
resource
they
sh
and
we're
not
stopping
them.
So
I
don't.
I
think
that
I'm
with
bogdan
on
this.
B
B
We
say
like
yeah,
you
can
like,
as
part
of
your
configuration,
grab
the
resource
and
shove
it
in
there
then
there's
like
sort
of
a
lack
of
guidance
and
if
we
turn
this
stuff
into
like
I,
I
don't
know
if
that
makes
it
harder
to
to
drive
open,
telemetry
setup
by
via
configuration,
maybe
it
does
maybe
it
doesn't,
but
if
you
have
to
generate
these
resource
objects
and
hand
them
around,
so
that's
the
only
thing
I
would
think
about.
B
J
Yeah,
that's
that's
fixed
because
that's
that
happens
dynamically
at
runtime,
so
people
can
construct
research
and
stuff,
but
resource
is
initialized
once
for
the
provider.
So
when
you
initialize
for
provider,
you
can
pass
it
to
the
sampler.
If
the
sampler
supports
this,
so
I'm
I'm
struggling,
I
I'm
a
person
that
tries
to
keep
the
api
and
the
capabilities
limited
as
much
as
we
can.
Unless
there
is
no
way
like
the
instrumentation
library,
there
is
no
way
we
can
pass
that
because
it
happens
at
runtime
dynamically
by
the
user.
J
I
J
Yeah
and
also
on
99
of
the
cases,
there
will
be
only
one
resource
per
per
service
or
per
application
so
again,
yet
another
reason
why
we
should
not
pass
always
the
same
instance
and
stuff.
So
that
being
said,
I'm
reluctant
on
accepting
that
pr.
Unless
it's
somebody
proves
me
completely
wrong,
and
I
think
this
should
be
our
mindset
from
now
on.
We
should
not
allow
new
apis
until
somebody
really
proves
us
that
they
cannot
achieve
what
they
need.
C
Yeah,
it
sounds
a
lot
right,
so
let
me
put
that
comment,
this
kind
of
agreement
that
we
reach
here
and
the
issue
and
ask
christian,
maybe
there's
something
we're
missing,
that
he
needs
that
we
are
not
aware
of
but
yeah.
If
otherwise,
let's
then
not
apply
this
change.
B
Yeah,
I
just
think
I
think,
maybe
a
side
point
to
this-
is
we
we
often
come
up
with
a
lot
of
guidance
in
these
meetings
and
in
these
discussions,
and
sometimes
we
write
that
guidance
down
in
issues,
but
but
we
don't
tend
to
write
it
down
in
documentation
anywhere,
which
means
like
these
questions,
keep
keep
coming
up.
So
maybe
just
as
like
a
side
thought,
that's
just
and
maybe
we're
all
just
too
busy
right
now
pushing
out
metrics
and
things
like
that.
B
J
Should
probably-
and
I
agree-
we
should
invest
a
bit
more
on
documenting
things.
We
were
very
early
stage
and
we
were
not
prepared
to
that
because
things
were
moving
fast,
but
now
that
we
stabilize
a
lot
of
the
things,
I
think
it's
a
it's
a
great
opportunity
and
anyway,
so
I
think
we
discussed
the
first
item.
Do
we
have
anything
else
or
we
should.