►
From YouTube: 2021-12-16 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
I
think
we
should
have
a
couple
minutes:
hi
ben
I
see
you
are
here
and
you've
offered
help
in
the
slack
channel.
I
appreciate
you
offering
and
showing
up
for
that
absolutely
when
I
saw
your
suggestion
that
that
the
language
was
confusing,
I
didn't
take
it.
I
hope
I
didn't
take
it
the
wrong
way.
I
I
have
my
own
reasons
why
I
think
that
pr
is
failing
to
attract
attention,
but
any
health
is
of
course
appreciated.
A
I
just
wanna
sit
down
and
start
saying
something
like
along
the
lines
of
gosh
open
telemetry
could
certainly
use
a
roadmap
for
sampling,
that's
larger
than
just
this
particular
piece
that
we're
working
on
right
now.
I
have
seen
some
roadmaps,
but
they're
not
really
meant
for
users
to
come
in
and
see
where
we
headed
they're
really
meant
for
planning
among
the
sort
of
leads
of
the
open,
telemetry
project.
So
I
don't
believe
there
is
a
document
that
says
here's
what
we'd
like
here's,
what
users
are
asking
for?
A
Here's
how
we
might
do
that
in
the
sort
of
direction
we're
headed,
so
that
would
actually
help.
I
think
so.
I
have
my
theories
about
this
pr
that
I'm
waiting
for
reviews
on
and
one
of
the
theories
is
it
just.
It
looks
like
we're
waiting
for
technical
approvals,
but
we're
really
waiting
for
community
approvals
nobody's
in
the
right
place
to
actually
approve
it
so
yeah.
I
appreciate
your
help.
A
Items
on
it
and
since
I
think
we
should
take
them
in
order
because
I
didn't
put
them
there
and
will
you
have
your
name
on
this
first
item,
while
we're
talking
why
you
put
your
name
on
the
notes
and
we
could
begin,
I
think,
to
talk
about
this
particular
topic.
I've
seen
I've
seen
this
been
discussed
many
times
about
resource.
C
Attributes
yeah,
that's
right.
I
I
know
that
this
is
definitely
something
that's
been.
C
Can
you
hear
me
now
by
any
chance,
looks
like
josh.
C
Okay,
good
yeah,
so
I
I
figured
this
has
been
discussed
before
so
I
don't
want
to
take
up
too
much
time
on
it.
C
I
just
wanted
to
get
some
further
clarity
on
how
it
impacts
remote
sampling,
which
is
kind
of
what
we
discussed
the
last
sampling
sig,
because
the
consensus
to
me
it
seems
currently
was
that
we
wouldn't
pass
either
resource
data
or
instrumentation
data
to
the
should
sample
method
because
of
performance
reasons,
and
also
because
it
would
require
new
interfaces
and
kind
of
a
big
spec
change
and-
and
it
didn't
seem
like
there
was
a
necessary
use
case
for
it,
because
you
could
have
the
sampler
fully
configured
a
configuration
time.
C
C
So
I
wasn't
sure
if
there
was
any
sort
of
consideration
for
that
right
now
or
if
we
should
like
work
on.
You
know
adding
that
to
the
conversation.
A
So
I
mean
I
can
summarize
why
I
think,
led
to
this
current
state.
I
know
bogan
has
been
very
opinionated
about
this
particular
topic.
I
I
think
I
support
his
opinion.
The
statement
is
that
you
could
pre-bind
the
the
whatever
information
you
need
about
your
instrumentation
library
or
your
resource
into
a
sampler
implementation,
and
then,
at
the
moment
a
span
starts.
A
You
only
have
to
consider
the
new
stuff,
not
not
the
stuff
that
that
should
have
been
known
already
and,
in
addition
to
other
statements
like,
for
example,
that
resources
should
be
immutable
and
so
on.
So
I
I
think
technically
the
argument
sound
to
me
and
when
I
think
about
how
the
spec
has
somehow
failed
to
clarify
that
you
have
a
resource
and
an
instrumentation
library.
Is
that
there's
not
no
mention
of
either
of
those
concepts
in
the
api
for
open
telemetry?
A
It's
this
concept
that
gets
shoved
in,
as
you
start
to
talk
about
the
sdk
and
there's
not
really
a
spec
for
how
to
configure
sdk
or
set
it
up,
and
so
to
me
this
is
about
a
gray
area
between
sdk
initialization
and
the
functionality
of
the
default
sdk.
A
I
guess
and
yeah
I
guess
it's
just
like
an
underspecified
void
of
open
telemetry
in
the
we're
working
on
the
metric
spec
right
now
with
a
couple
of
us
to
try
to
get
views
implemented,
and
you
end
up
kind
of
facing
the
same
question
like
there
are
all
these
configurations
that
give
you
a
suggestion
for
what
you're
going
to
do
when
the
data
arrives,
and
it's
totally
unspecified
how
you
get
those
specifications
and
what
you
do
with
them
when
you're
setting
up
yourself
or
setting
up
your
sdk,
and
so
I
think
that
when
bogdan
puts,
puts
his
foot
down
and
says
you
can't
have
those
fields
in
should
sample
it's,
because
we're
expecting
that
there
is
some
setup
that
happens
where
every
instrumentation
library
binds
its
own
samplers
and
every
resource
binds
its
own
samplers,
but
that
the
process
of
setting
all
that
up
is
totally
invisible
and
not
specified.
C
Yeah,
no,
that
that's
totally
makes
sense.
So
the
expectation
today
is
that
basically,
like
you,
should
collect
all
of
the
initial
like
resource
data
and
instrumentation
data
and
like
bind
it
to
the
sampler
when
you're
configuring,
the
sdk
kind
of
and
then
and
then
that's
how
it's
available
is
that
is
that
accurate
or
that
is
accurate.
A
A
So
so,
practically
speaking,
is
this
causing
a
lot
of
difficulty.
In
my
opinion,
like
no
user
of
openometry
is
getting
what
they
need
from
sampling,
and
it's
it's
more
about
like
this
need
to
set
up
a
what
I'm
calling
a
view
in
for
spans.
A
I'm
using
that
word
because
the
metric
spec
is
so
much
further
ahead
of
spam
of
this
tracing
spec
in
terms
of
what
we're
actually
the
ambition,
although
as
you
as
we're
seeing
in
metrics,
the
implementation
of
these
views
is
quite
tricky,
and
so
the
the
equivalent
trickiness
that
happens
in
tracing
is
about
setting
up
your
samplers,
and
we
have
these
built-ins
that
are
barely
described,
and
this
isn't
getting
back
to
ben's.
My
statement
to
ben
at
the
beginning
is
like
there's
no
overall
picture
of
how
we
reduce
sampling.
A
We
just
have
these
four
built-in
samplers
go
figure
out
how
to
use
those,
but
even
having
those
samplers
doesn't
tell
you
how
to
start
using
opentology,
because
there's
some
step
to
set
up
an
sdk,
that's
totally
unspecified.
So
you
have
to
go
into
your
particular
language
and
figure
out
how
to
start
an
sdk
and
then
figure
out
where
the
samplers
are
and
then
wire
them
all
up
and
and
you're
saying.
Well,
that's
really
hard
because
I
don't
know
how
to
do
it
and
there's
no
support
there
for
me
either.
A
I
think
so.
A
In
my
opinion,
the
the
the
user
will
be
helped
when
we
finish
more
more
of
the
work
for
the
like
the
end
state,
where
you
have
a
configurable
sampler
and
you
can
download
your
open,
telemetry,
sdk
and
there
it
is.
A
So
I
feel
like
that's
where
this
will
get
solved
or
should
get
solved.
I'm
not
that's
totally
vague,
though
yeah
so.
A
Is
that
yeah
I
mean
today
I
mean
I'm
only
familiar
with
my
own
repository
that
I
work
in
a
lot.
The
open,
telemetry
go
and
and
there,
when
you,
create
your
sdk
object,
which
is
again
not
a
specified
thing,
but
you
create
this
tracer
and
it
has
options
and
one
of
the
tracer
options
is
with
sampler
and
so
right.
A
They
also
get
a
new
trace,
a
new
sampler
bound
to
that
instance,
and
that's
all
possible.
It's
just
like
under
the
covers
and
not
specified.
So
the
fact
that
we
don't
give
you
a
constructor
that
lets
you
configure
per
instrumentation
library
samplers
makes
it
hard
to
do
what
you're
trying
to
do,
but
there's
no
spec
around
what
gets
done
to
set
up
an
sdk.
So
there's
nothing.
We
can
fix
except
write
new
spec.
I
guess.
A
It's
an
unsatisfying
answer.
I
I've.
I
also
find
this
is
one
of
my
long
frustrations
with
hotels,
there's
no
unified
story
for
setting
up
sdk.
That
sort
of
encourages
you
to
get
the
same
dimensions
on
your
attributes
for
your
metrics
and
your
logs,
your
traces
for
example.
So
the
setting
up
of
an
sdk
is
still
under
specified
and
leads
to.
You
know
totally
different
experiences
in
different
telemetry
signals.
That
doesn't
seem
great
to
me,
but
but
there's
no
spec
and
someone
would
have
to
write
it
and
we'd
all
have
to
agree
to
it.
C
A
Yeah,
I
know
I
think
I
think
that
that
makes
sense,
as
I
am
working
through
this
views
thing
in
in
the
open,
telemetry
go
prototype
for
metrics
sdk,
I'm
like
really
facing
almost
exactly
the
same
questions
is
that
you
are
going
to
create
a
meter
provider
and
each
meter
might
have
different
views
and
then
each
view
might
create
different
samplers
and
then
somehow
I
need
to
make
sure
that
when
the
span
starts,
I
have
the
right
sampler.
That
knows
it's
its
resource.
A
That
could
be
dynamic,
and
actually
I
think
we
should
have
a
separate
discussion
about
dynamic
resources.
It's
like
almost
entirely
tangential
and
and
troublesome,
but
the
idea
that
you
might
get
some
information
back
from
the
sampler
and
need
to
use
your
resource
that
that
part.
I
understand
it's
just
that
we
think
you
should
be
able
to
get
your
resource
in
place
beforehand.
It's
just
no
one's
specifying
how
to
do
it.
Okay,.
C
Okay,
yeah,
that
that
makes
sense.
I
think
that
clarifies
the
current
state
of
like
you
know.
You
just
need
to
load
the
resources
to
the
sampler
at
configuration
time
and
that's
that's
what
we'll
have
to
go
on
and
if
there
are
yeah.
I
think,
like
you
said,
dynamic
resources
are
part
of
it
because
that's
something
that
could
be
updated
at
runtime,
but
is
definitely
not
specked
out
and
not
fully
related.
But
yeah
and.
A
Someone
will
say
you
shouldn't
like
having
dynamic
resources,
maybe
break
some
semantic
model
somewhere.
I
don't
know
for
me
as
I,
as
I
work
through
this
stuff
in
metrics,
I'm
starting
to
get
a
picture
of
what
band
views
ought
to
be
specified
as
and
then
perhaps
you
know
one
answer.
One
outcome
of
this
is
gosh.
The
views
specification
for
metrics
is
awful
and
never
going
to
be
implemented
and
really
hard.
The
other.
A
The
other
outcome
will
be
okay,
okay,
we
know
how
to
implement
a
view
spec,
let's
just
go,
do
the
same
for
tracing
and
then
and
then
there'll
be
some
sort
of
standard
way
to
set
up
these
things
that
you
know
it
should
be
at
least
more
clear.
How
do
you
get
the
resource
into
place
for
your
sample
decision?
A
Yeah?
Okay,
that
makes
sense
sorry
sort
of
disappointing.
I
don't
the
fact
that
there's
no
standard
sdk
setup
mechanism,
which
leaves
this
gap.
A
By
the
spec-
and
I
don't
think
changing
that
is
going
to
solve
people's
problems,
I
think
we
should
have
a
view.
Config
first
dance.
A
A
Thank
you.
Well.
The
other
next
item
on
the
agenda
was
me
basically
asking
for
a
discussion
about
pr2047.
This
is
the
fairly
large
draft
that
I
wrote
after
the
two
oteps.
I
understand
it's
holidays
and
probably
it's
hard
to
get
attention
from
anyone.
A
A
But
my
hunch
is
that
the
reason
why
this
is
not
getting
approvals
or
reviews
either
that
it's
the
holidays
or
that
there's
sort
of
uncertainty
and
doubt
because
the
number
of
solutions
or
the
solution
space
is
actually
very,
very
large
and
having
chosen
one
particular
solution
and
and
ironed
out
a
very
extensive
document
about
it
leaves
you
feeling
what
what
else
was
possible
or
what
could
I
have
done
here
or
what
could
we
have?
What
could
we
have
specified,
and
so
there
are
maybe
there's
a
discussion
we
can
have.
A
It
will
last
week
or
two
weeks
ago,
give
a
presentation
and
partly
respond
to
will's
presentation,
which
is
essentially
like
hey.
I
just
want
something
simple.
Can
I
put
a
count
on
my
stand,
please,
which
is
a
sensible
thing
to
do,
and
I
support
it.
In
fact,
it's
totally
compatible
with
the
scheme
we
have,
although
it
will
create
other
problems
for
some
people.
I
can
see
mars
here.
I
know
ottmar's
motivation
for
the
current
proposal
has
one
more
feature
to
it,
which
is
that
it
limits
the
number
of
total
probabilities.
A
If
we
start
to
accept
this,
I
made
this
up
in
slack
over
the
last
two
weeks,
but
the
idea
of
a
c
value
is
literally
that
you
just
say
your
adjusted
count
and
promise
that
your
probability
matches
it.
That
is
a
harder
spec
to
write.
That
is
more
data
on
the
layer.
It
is
lots
of
reasons
why
that's
harder,
but
it
is
compatible.
So
if,
if
one
of
the
reasons
you
were
holding
back
on,
this
particular
proposal
is
like,
I
want
a
different
proposal.
A
Maybe
we
should
maybe
we
could
recognize
that
there
are
many
compatible
ways.
We
could
do
consistent
probability
sampling,
but
these
specs
are
not
easy
to
write.
So
I
put
together
this
issue
kind
of
trying
to
step
back
a
little
bit
and
and
help
the
community
make
a
decision.
Here.
I
put
a
link
to
it.
It's
two
two,
two
four,
basically
just
explaining
the
context
that
we
were
in
you
know
the
w3c
controls
specification
for
trace
parent
and
trace
state.
A
We
are
working
within
the
framework
of
w3c
here,
so
in
order
to
get
a
sampling
spec
that
is
fully
compatible
with
w3c.
A
We
had
to
do
something
today
and
it
may
not
be
the
perfect
final
state
for
us
as
far
as
sampling,
but
this
is
a
a
state
that
helps
us
legitimize
our
effort
with
w3c
and
helps
us
set
stage
to
ask
w3c
to
make
accommodations
for
this.
That
will
help
us
do
this
cheaply,
but
we
have
to
start
somewhere.
A
So
I
think
that
my
my
understanding
or
suspicion
here
is
it's
just
uncertainty
and
doubt
over
why
we
would
choose
this
particular
rather
compromised
proposal
as
a
first
step,
and
I
think
the
answer
is
to
get
w3c
to
give
us
what
we
want
anyway.
I
hope
that
if
I'm,
if
I
could,
answer
questions
or
help
anyone
here
with
that
pr,
I
would
be
glad
to
discuss
it
right
now.
Yuri
I
see
you're
in
the
call
you've
been
one
of
the
instrumental
people.
A
It
would
help
if
you
could
approve
it,
though
I
don't
want
to
demand.
I
know
it's
holidays
if
you're
listening
and
want
to
speak,
it
would
be
a
good
time
now,
yuri.
A
A
I
tried
to
I
and-
and
I
think
the
last
comment
here
is
if
this
is
not
readable,
please
help
me,
then
I
would
definitely
appreciate
as
a
sort
of
newcomer
to
the
group
or
the
spec.
If
you
want
to
just
make
suggestions
on
my
pr,
I
will
almost
certainly
accept
them.
If
it's
too
extensive
for
a
suggestion
in
a
github,
maybe
we
can
do
something
else.
I
also
can
certainly
prioritize
another
pass
at
that
document,
but
I
am
rather
exhausted
of
it.
So
outside
help
is
really
appreciated.
A
So
so,
if
you
feel
like
there's
confusion
or
don't
don't
see
the
long-term
vision
with
w3c,
the
the
issue
in
2224
should
help
and
it's
the
holidays
take
a
time,
don't
don't
rush
it
here.
Thank
you
yuri
anyway.
I'm
ex
I'm
excited
that.
It
feels
like
we're
close.
A
If
anyone
thinks
the
c
value
idea
is
good,
go
read
two
two
two
four
put
a
little
bit
more
idea:
the
idea
into
that
document,
and
next
I
propose
that
we
take
a
look
at
the
jaeger
sampling
protocol
that
was
put
into
a
hotel
pr
form.
I
read
through
a
bit
it
looks
like
yuri.
You
commented
that
there
was
already
an
idl.
A
That
said
the
same
thing
I
think,
but
in
any
case
I
believe
the
purpose
of
this
pr,
I
can
put
it
up,
is
to
take
what
the
jaeger
remote
sampling
protocol
is
and
write
it
down,
so
that
everyone
in
hotel
can
see
it
gosh.
I
thought
that
there
was
an.
A
And
so
I
think,
what's
lovely
is
how
small
this
is.
I
I
remember
when
we
first
talked
about
getting
open
telemetry
to
support
remote
configurable
sampling.
We
we
looked
at
this
and
we
said
okay,
this
looks
like
it.
It
will
work
for
us
because
it's
been
proven
that
jaeger's
doing
it
already,
but
there
were
things
that
were
sort
of
like
semantically,
not
fitting
with
open
telemetry.
So
like
the
use
of
the
word
operation
is
one
that
doesn't
feel
like
open
telemetry
to
me.
A
So
my
real
question
is
whether
we're
gonna
think
about
updating
this
to
like
make
it
look
like
an
open,
telemetry
thing
or
or
whether
it
it
changes
like
we
can
change
field
names
to
like
is
operation
name
span
name.
I
think
that's
what
it
is.
That's
the
kind
of
question
I
have
here,
but
I'm
glad
that
we're
making
progress
so.
D
My
concern
with
this
with
adopting
this
protocol
as
is,
is
that
it
is
very
strongly
opinionated
about
which
dimensions
you
can.
You
can
make
sampling
decision
on
right
so
specifically,
operation
name,
that's
it
like
you,
have
a
service
and
operation
and
there's
no
capability
to
do
anything
else,
and
we've
had
some
some
proposals
on
the
jaeger
tickets
about
more
sort
of
flexible
expressions
where
operation
name
is
just
one
of
the
dimensions
that
you
could
sample.
Theoretically,
it
doesn't
have
to
be
that
permanent,
even
the
service
name
technically
so
yeah.
A
A
If,
if
we're
going
to
sort
of
bless
this
for
open,
telemetry,
there's
known
issues
in
this,
we
should
fix
them,
and
I
think
that
would
be
my
first
guess
too,
is
that
other
attributes
are
in
a
way
that
people
want
to
sample,
and
I
know
that
that
whatever
that
was
a
vague
statement
there,
because
there's
so
many
ways
you
could
sample,
of
course,
but
I
I
take
it,
this
is
the
idea
is
that
you
select
a
sampling
policy
based
on
the
value
of
an
attribute,
basically.
A
And-
and
that
is
a
very
reasonable
thing
to
do
so.
Okay,
I
think,
then,
is
the
I
take
it.
A
The
request
here
is
to
review
the
spec
change
that
basically
adds
a
link
to
this
jager
stuff,
but
we're
still,
I
think,
we're
hoping
that
that-
and
I
think
since
will
is
on
the
call,
there's
some
perhaps
reconciliation,
to
look
to
look
into
with
the
amazon
x-ray
protocol,
which
is
almost
the
same,
I
think,
but
probably
does
have
those
attribute,
selectors
and
so
on,
and
then
I
think
the
one,
the
the
sort
of
intermediate
term
is
that
we're
thinking
about
whether
open
telemetry
should
have
its
own
one
of
these
protocols
or
not
or
whether
we
can
like
extend
this.
A
B
I
think,
given
the
the
different
choices
and
samplers
that
that
we're
proposing
in
open
telemetry
that,
like
the
things
that
I
see
needing
to
be
opened
up,
it's
like
well,
we've
got
probabilistic
and
rate
limiting
and
the
jaeger
remote
sampling.
But
I
mean
a
more
open
configuration
for
any
type
of
sampler.
B
A
So
I'm
wondering
what
the
x-ray
experience
is
for,
especially
in
terms
of
performance
of
having
these
like,
like
a
list
of
sampler
configurations
that
you
have
to
test
for
every
span
or
if
there
are
more
clever
approaches
being
used
already,
I'm
thinking
of
like
boolean
expression,
evaluation
where
you
have
a
bunch
of
predicates
and
the
question
is
which
predicates
match,
and
there
are
algorithms
that
do
better
than
linear,
but
maybe
they
don't
have
best
case
times
better
than
linear.
Maybe.
D
D
The
way
they
are
solved
typically,
is
by
pre-building
the
decision
tree,
which
so
that
you
don't
actually
go
and
evaluate
every
policy
and
then
again,
because
the
decision
tree
actually
collapses
all
of
those
evaluations
and
makes
it
too
much
faster
so
and
that
the
good
thing
about
that
is
that
we
could
also
just
push
that
functionality
to
the
back
end
rather
than
having
the
sdk
to
build
this.
This
decision
tree
from
the
policies
so
that
the
back
end
basically
says
yeah.
A
Cool,
I'm
I'm
intrigued
by
a
lot
of
things.
You
just
said.
One
thing
is
I
the
the
word
decision
tree
or
rules
engine
is
not
it's
pretty
new
to
me,
I
mean
I
know
those
words,
but
I
I'm
not
familiar
with
a
body
of
work
on
disable
rules
engines.
So
I'm
I'm
curious
what
what's
out
there?
I
guess,
because
I
mean
how
do
you
pre-build
a
decision
tree?
How
do
you
transmit
that?
That's
not
what
I'm
seeing
in
this
protocol
here.
So
I
guess
this
is
something
else
yeah.
D
A
The
led
step
satellite
has
an
algorithm
that
I
that
I
was
involved
with.
I
copied
it
out
of
the
paper.
It
worked
pretty
well,
but
it
did
not
have
provable
better
time
than
than
than
brute
force.
It
was
like,
probably
a
better
time
than
brutal.
So
that's
a
good,
interesting
area
for
us
to
investigate.
A
I'm
not
sure
who's
going
to
lead
this
ish.
This
effort,
this
one
that
we're
hypothetically
talking
about
in
which
we
evolve
from
the
protocol,
we're
looking
at
toward
a
future
that
has
more
configurable
rule,
expressions
and
or
more
name
sampling
policies
will
perhaps
like
adaptive
is
in
there.
I
think
x-ray
has
that
and
then
the
question
about
x-rays,
centralized
reservoir
stuff
as
well,
which
I
didn't
quite
grok,
so.
D
There
is
an
incremental
path,
and
so,
if,
if,
if
you
only
have
like
a
couple,
two
three
policies,
then
there's
no
reason
not
to
evaluate,
and
so
I
mean
people
can
make
trade-offs
as
to
like
how
complex
like
at
facebook,
the
requests
that
come
to
the
to
the
web
tier
are
subject
to
a
huge
number
of
policies
right
and
so,
like
they're
being
evaluated
kind
of
probably
inefficiently.
D
Today
we
haven't
done
that,
but
like
in
jaeger,
we
had
a
a
sampler
called
like
a
priority
sampler,
which
was
it
had
like
it
would
take
a
list
of
other
samplers
and
basically
it
asks
them.
Each
of
them
evaluate
the
condition
until
someone
of
them
says
yes,
and
then
it
just
like
stops
and
stops
evaluating
all
together
right,
and
so
at
least
that
way.
If
you
have
some
more
expensive
stuff,
you
just
like
either
push
it
to
the
end
or
something
like
that.
A
Well,
anyway,
thank
you.
My
impression
is
that
a
lot
of
us
want
this
it.
This
touches
on
the
question
that
was
raised,
the
beginning
about
resource
and
instrumentation
attributes
as
well.
Is
that
there's
some
engine
that
we
need?
That
is
both
going
to
do
the
types
of
stuff
that
yuri
just
mentioned,
but
also
be
bound
together
at
sdk
setup.
That
has
everything
you
need
to
do
this
execution
and
that
seems
like
it
will
involve
us
specifying
how
to
register
sampler
views.
A
I
I
keep
using
the
word
views
because
I
think
that's
the
closest
we
have,
and
I
think
eventually,
this
rules,
engine
type
thing
will
be
bound
together
at
startup
with
your
resource
and
your
instrumentation
library,
and
then
you
can
go.
Do
the
sampling
decisions,
so
I
think
the
the
recommendation
for
the
group
is
to
look
at
this
proposal.
Think
about
how
you
would
incrementally
extend
it
so
that
open
telemetry
can
do
rules,
evaluation
and
other
samplers.
A
I
am
definitely
going
to
be
working
in
this
area
in
the
coming
year
as
well.
Lightstep
has
has
users
also
who
want
configurable
samplers.
We
want
to
be
able
to
have
these
rules
as
well,
and
so
I
expect
that
this
will
be
a
project
in
the
coming
year.
For
me,
at
least.
A
And
with
that,
I
think
we
have
nothing
more
on
the
agenda
to
talk
about.
A
And
I
because
we're
facing
holidays
here,
I
don't
actually
have
a
an
action
item
in
mind
right
now,
two
weeks
from
now
will
be
probably
I
will
not
be
present
it's
a
holiday
here
and
then
I
think
we
should
come
back
with
plans
for
this
future
configurable
sampler,
based
on
something
like
this
starting
in
the
new
year.
A
Going
going,
okay
have
a
great
weekend
meet
you
all.
There
is
a
meeting
on
the
calendar
two
weeks
from
now.
I
suspect
I
will
not
be
there.
I
will
say
so
in
slack
before
so.
If
you're
interested
today
at
11
o'clock,
there
is
a
demo
on
multivariate
bittrex.
I'm
excited
about
that
gonna
plug
that
right
now.
I
know
it's
totally
not
connected
with
sampling,
but
it's
an
interesting
topic.
A
A
pitch
from
laurent
corel
multivariate
metrics:
it
is
a
proposal
that
we
have
column
encoding
for
metric
data,
but
it
would
also
be
very
useful
for
span
data,
something
that
lightstep
is
interested
in.
So
I
mentioned
it
because
it's
the
most
exciting,
open,
telemetry
thing
happening
today.