►
From YouTube: 2020-10-09 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
Hey
chef
nick,
has
it
going
hey
going
well
I'm
about
to
hit
the
road,
so
I
won't
be
able
to
hang
out
another
qual
for
very
long
yeah.
I
wasn't
sure
there
would
be
a
call
this
week
because
last
week
you
said
that
they're
prioritizing
other
stuff
for
the
ga
yeah
yeah.
I
was
kind
of
crossing
my
fingers.
No
one
needed
me.
A
A
A
A
A
A
A
A
Hi,
I
actually
have
to
hit
the
road
I'm
traveling
today,
but
I
wanted
to
hop
on
this
call
just
to
just
in
case
someone
was
coming
back
with
a
sampler
implementation
or
had
some
specific
questions.
B
Well,
I
recently
started
working
so
I'm
at
google.
I
recently
joined
the
google
open
telemetry
team,
so
hopefully
you'll
be
seeing
more
of
me
sweet,
but
I've
been
trying
to
integrate
first
open
census
and
now
open
telemetry
into
kubernetes
for
a
long
time.
Oh.
B
So,
actually,
just
yesterday,
my
proposal
to
add
tracing
to
the
api
server
was
accepted,
so
I'll
be
doing
that
in
the
next
few
weeks.
But
I've
been
watching
you
guys
for
for
a
long
time,
in
the
shadows
and
and
hopefully
now
I'll
get
to
participate
a
little
bit
more
yeah.
A
Where,
rather
since
we're
on
the
subject,
what's
the
easiest
way
to
get
involved
or
keep
track
of
tracing
in
kubernetes,
because
I
know
I've
talked
to
people
in
the
past
and
there's
like
some
basic
tracing,
that's
easy,
but
you
know
a
lot
of
these
event.
Chains
are
beyond
the
scope
of
the
kind
of
transactional
tracing
that
we
currently
support
in
open
telemetry.
So
I'm
just
you
know,
there's
like
an
events
api
that
was
made
to
deal
with
that.
A
Sig
meetings
for
kubernetes,
yes,
great,
okay
and
tracing
and
open
telemetry
are
our
current
subjects
of
interest
for
that
that
stick.
B
So
tracing
is,
I
think
we
have
obviously
some
history
with
metrics
and
logs
that
right
now,
logging
is
working
on
moving
to
structured
logging,
but
not
using
using
basically
an
addition
to
the
k
log
library
for
metrics
we're
trying
to
work
on
defining
stability
on
top
of
prometheus
using
using
the
what's.
It
called
the
description
section
by
adding
little
tags
in
there
to
say
whether
something
is
stable
or
alpha.
A
Just
getting
started
sweet
yeah.
I
know
there
was
a.
There
was
an
open
census,
implementation
of
tracing
for
kubernetes
in
some
form
that
had
been
hanging
out
for
a
while.
Maybe
that
was
you
that
was
me:
yep,
sweet,
cool
well
on
the
sampling
front.
Is
there
anything
a
particular
interest
for
you?
Okay,
great.
Thank
you
for
these
check.
These
links
out
later
yeah.
B
So
for
sampling,
we're
we're
probably
going
to
implement
it
ourselves
in
any
sort
of
extension
using
the
baggage
api,
but
I
think
the
most
interesting
part
is
that,
because
objects
usually
live
for
long
periods
of
time,
if
you
want
to
use
object,
annotations
to
propagate
context,
you
don't
actually
really
want
to
trace
everything
that
happens
forever.
You
sort
of
just
want
to
trace
things
that
happen
initially
and
then
at
some
point,
stop
sampling
all
the
things
that
happen.
Otherwise
you
get
these
like
spans.
B
Initial
user
intent
right,
so
my
thinking
right
now
is
like
we
could
use
baggage.
We
could
add,
like
a
timeout
or
like
a
sample,
timeout
thing
that
we
propagate
along
with
it.
That
says,
after
this
time,
the
sampling
decision
should
be
no,
no
matter
what
or
maybe
there
are
other
better
ideas,
but
I'm
also
I'm
also
trying
to
learn
more
about
some
of
the
other
ideas
that
are
floating
around
here,
because
you
guys.
A
Right,
like
you,
can
you
can
trace
other
things,
but
the
a
lot
of
the
presumptions
baked
into
the
architecture
is
that
this
is
overarchingly
a
predominantly
synchronous
transaction
occurring
within
the
time
span
of
like
the
human
attention
span
right
and
that's,
those
presumptions
are
really
baked
into
like
what
a
trace
is,
and
so
when
it
comes
to
really
like
I'm
saying
this
with
kafka
kafka's.
The
thing
I'm
interested
in
tracing,
for
example,
and
the
thing
you're
most
interested
in
kafka
are
the
the
gaps
in
time
almost
like
the
processing.
A
Time
is
not
necessarily
that
interesting,
but
the
the
time
between
processing
and
the
overall
amount
of
time
is
is
interesting
and
you're
working
on
time
frames
that
are
beyond
what
a
lot
of
these
tracing
systems
are
expecting
to
deal
with.
So
I
do
think
we
need
to
address
what
more
like
large-scale,
longer-term,
asynchronous
workflows.
Look
like
yeah.
There
is
a
function
in
it
called
lynx.
That
was
more
for
scattered
gather.
I
mean
you're.
A
You're,
probably
aware
of
like
some
of
the
google
thinking
behind
a
lot
of
this
stuff,
but
I
feel
like
that's
the
part
where
it's
still
a
little
muddy
like
how.
How
do
you
link
together
a
bunch
of
transactions
like
there's
a
lot
of
ideas,
people
can
throw
out
and
you
could
even
grab
things
that
your
country
currently
has
and
kind
of
make
them
work.
But
there
there's
definitely
not
something
in
the
spec
right
now.
Explaining.
A
B
B
B
B
A
lot
yep,
so
so
that's
what
this
current
proposal
does
to
someone
who's
familiar
with
it.
It'll
look
super
basic,
it's
like
by
the
way
we're
going
to
use
this
open,
telemetry,
wrapper
library
to
to
wrap
your
http
server
nice.
You
know!
So
it's
it's
at
that
level
of
detail,
but
yeah
that
the
object
related
stuff
that
I
was
working
on
earlier
also
has
an
interesting
problem
with
multiple
parents,
basically
where,
if
I
create
an
object
and
then
you
update
it,
then
who's
responsible
for
it
and
who's.
B
A
A
Right
like
you,
came
along
and
invalidated
the
cache,
and
now
my
request
took
a
long
time
or
it's
concurrent
right
like
we're
both
competing
for
the
same
cpu
cycles
or
whatever
so
and-
and
I
there's
nothing
directly
in
the
open
telemetry
model
about
modeling
either
of
those
kinds
of
behavior,
even
though
they're
both
very
important
when
we're
talking
about
cloud
computing
or
whatever,
we
want
to
call
it
we're
doing
this
and
yeah,
I
think
we
could
start
like
just
use
links.
Links
is
like
a
really
generic
thing.
A
A
Fun:
okay!
Well,
thanks
for
the
kubernetes
update,
I
will
try
to
get
involved
with
my
schedule
allows
because
I
think
that
stuff
is
really
cool
for
sampling.
I
had
actually
just
updated
the
the
top
of
the
working
group
notes
just
to
put
a
link
to
the
issues
that
are
marked
as
allowed
for
ga.
There
are
currently
no
more
issues
marked
as
required
for
ga
on
sampling
and
that's
just
because
we
don't
want
sampling
to
have
any
public-facing
surface
area
on
the
the
instrumentation
apis.
A
It's
mostly,
we
don't
want
to
make
breaking
changes
to
the
the
public
apis,
so
the
things
that
are
probably
most
hot
to
trot
in
sampling
are
the
things
mark
has
allowed
for
ga,
because
this
is
the
stuff
that
we're
trying
to
get
in
any
ways,
even
though
it's
not
required
everyone's
like
this,
it's
I
would
say
that
things
marked
as
required
allowed
for
ga
are
the
things
where
people
raise
their
hand
and
being
like
this
thing
about
sampling
is
weird
or
like
genuinely
needs
to
be
addressed.
A
So
that's
an
interesting
list
of
stuff
to
go
through
so
share
my
screen
here,
real
quick.
A
So
what
I
care
about
on
this
front-
just
to
let
you
know,
most
importantly,
is-
is
getting
the
sampling
plug-in
api
correct.
A
I
want
to
prove
that
it
would
be
nice
that
we
can
standardize
on
some
sampling
concepts,
but,
first
and
foremost,
I
want
to
prove
that
the
kind
of
sampling
people
want
to
do
can
be
implemented
as
a
plug-in
like
if
we
can't
implement
it
as
a
plug-in.
There's
no
point
in
talking
about
standardizing
it,
and
there
are
some
issues
related
to
that
in
particular.
A
A
So
yeah,
http,
headers
and
there's
the
public
headers,
which
are
like
you
know,
trace
parent
and
then
trace
state
is
where
you
include
all
your
internal
details
that
are
specific
to
your
tracing
implementation.
Well,
one
thing
that
cares
about
those
internal
details
is
the
samplers
that
you're
running
in
your
sdk
right.
That's
precisely
the
the
kind
of
thing
that
wants
to
grab
it
the
trace
date
and
crack
it
open
and
have
a
look
at
it,
and
so
the
question
here
is
really
like.
A
No
one
have
really
thought
very
much
about
the
apis
around
accessing
trace
tape
in
the
sdk,
because
really
this
is
probably
the
first
time
we
actually
encountered
a
genuine
need
for
it.
You
know
we
knew
we
were
going
to
need
pre-state
for
stuff
somewhere,
but
this
was
the
first
time
it
showed
up
where
we
had
to
make
an
open,
telemetry
design
decision
based
on
trace
date,
and
so
you
have
a
question.
First
and
foremost
is
like
parsing
trace
state.
A
It
would
be
nice
to
be
lazy
about
that
right,
right
and
then
the
other
question
is
we
kind
of
want
context
and
trace
context
to
be
immutable.
So
is
the
sampler
allowed
to
just
read
the
trace
state?
Can
it
mutate
the
trace
state?
In
which
case
you
know,
the
sampler
has
to
also
be
able
to
return
the
tracer
yada
yada
yada.
So
I
think
this
is
a
place.
A
That's
genuinely
a
little
muddy,
because
we're
trying
to
do
the
thing
of
like
just
tack,
one
thing
on
to
the
current
plug-in
api
like:
oh,
we
need
trace
tape,
but
as
soon
as
we
put
that
in
like
actually
that
that's
like
a
a
more
meaty
design
decision,
it
turns
out
because
you're
you're
hauling
in
more
concepts
than
just
like.
What
do
I
want
to
do
in
the
sampler
plug-in
now
it's?
How
do
I
want
to
parse
trace
date
like
how
do
I?
How
do
I
give
back
a
new
trace
state?
A
What's
the
pattern,
should
we
surely
other
plug-ins
will
eventually
want
to
muck
with
this
thing.
So
as
far
as
getting
involved
in
like
stuff
on
like
open
telemetry
from
the
sampling
point
of
view,
this
is
like
a
place
where
I
think
eyes
would
be
interesting.
A
Just
having
a
look
at
the
plug-in
api
and
the
this,
the
the
sampler
plug-in
in
particular
and
how
trade
state
is
currently
being
dealt
with,
john,
was
raising
some
points
already
about
things
that
the
new
spec
required
that
are
potentially
making
it
expensive
in
the
default
case,
and
we
can
probably
sort
through
all
these
individual
problems,
but
it
would
be
nice
if
the
first
version
of
this
api
isn't
just
like
a
pile
of
booleans
and
options
and
flags
to
deal
with
like
a
bunch
of
little
special
cases.
A
It
would
be
nice
to
have
someone
take
a
step
back
and
be
like
all
right
generally.
What
are
we?
What
are
we
trying
to
do
here
and
see
if
there's
like
a
simple
way
to
to
deal
with
this
stuff?
And
I
don't
think
anyone
has
the
cycles
right
now
to
to
look
at
this,
so
that
that
would
be
putting
on
my
my
open,
telemetry,
organizer
hat
more
eyeballs
on
the
the
sampling
plug-in
architecture
specifically
around
this
tray
state
thing
would
be
really
great.
A
A
There
is
no
standard
concept
of
sampling,
existing
systems,
all
do
sampling
differently
and
sampling
itself
is
really
a
concept
tied
to
like
the
analysis
of
your
data
or
your
data
pipeline.
It's
not
really
tied
to
like
describing
what
your
system
is
doing.
A
I
think
that's
part
of
the
reason
why
there
isn't
a
lot
of
standards
around
this
stuff,
but
there
is
some
interest
in
starting
to
standardize
some
concepts
right,
like
things
like
a
sampling
priority,
is
like
becoming
a
fairly
cut
and
dry
concept
since
you're
coming
at
this
from
the
kubernetes
perspective,
one
thing
that
is
interesting
to
me
is
like
what
actually
are
the
benefits
of
standardizing
this
stuff
beyond
getting
to
a
little
bit
of
code,
reuse,
and
maybe
some
people
don't
have
to
install
a
sampler
plug-in
if
we
were
to
start
trying
to
standardize
some
concepts
around
sampling.
A
B
A
Yeah,
so
that's
that's!
That's
a
question
that
that
I
actually
have
just
around:
what
are
we
trying
to
standardize
around
sampling
and
why
so
far,
the
only
reason
people
have
wanted
to
to
come
up
with
some
more
standard
sampling
concepts.
Are
I
don't
want
to
have
to
use
a
plugin
like
I
want
people,
I
want
to
be
able
to
have
open
telemetry
connect
to
my
system
out
of
the
box,
and
if
my
system
requires
some
kind
of
sampling
algorithm
to
work
correctly,
you
know
I
don't
want
them
to
install
that
plug-in.
A
This
poses
another
question
of
like
what
happens
if
someone
misconfigures
this
thing
and
points
it
at
you
without
the
correct
sampling
plug-in
installed,
so
I'm
actually
nervous
about
sampling.
If
there's
one
giant
foot
gun
in
open
telemetry
right
now,
I
would
say
it's
sampling
yeah,
because
most
other
systems
aren't
frameworks
right,
like
whatever
sampling
algorithm.
Your
analysis
tool
uses
the
client
for
that
analysis.
Tool
has
that
baked
in
and
open
telemetry.
Is
this
framework
that's
supposed
to
connect
to
all
these
different
backends?
A
So
you
what
happens
if
you
install
the
plug-in
the
sampling
algorithm
for
one
tool
and
then
point
it
at
another
tool
without
telling
it
I
I
predict.
People
are
gonna,
do
sad
things
with
this,
but
I
don't
know
what
to
do
about
that.
But
that's
that's
the
only
reason.
I've
seen
why
we
would
actually
care
about
standardizing
this
stuff.
The
other
is
interop,
but
I
I
haven't
been
convinced
after
many
many
w3c
meetings,
that
interop
is
a
real
thing
in
terms
of
trusting
sampling
decisions
and
all
this
other
stuff
like
interrupt
between
tracing
systems.
B
Yeah
for
kubernetes,
we
don't
care
too
much.
I
think
about
whether
it's
standardized
and
open
telemetry.
Obviously
it
gives
it
a
little
bit
more
weight,
so
we
know
we're
not
making
a
terrible
decision
when
we
build
something
ourselves,
but
there's
so
many
wrappers
that
people
use
to
actually
write
kubernetes
controllers
that
we
have
control
over
all
the
code
that
they
use
to
start
up,
and
we
can
just
stick
it
in
our
libraries
and
force
them
to
do
the
right
thing
throughout
the
ecosystem.
B
A
Yeah,
I
I
couldn't
imagine
how
it
would
interact,
but
I
don't
know
I'm
just
these
are
the
feelers
I'm
putting
out
right
now
around
sampling,
because
there's
the
the
two
parts
are
making
sure
this
plug-in
architecture
gets
done
correctly
and
the
other
is
there's
really
more
interest
in
standardizing
this
stuff
in
general
and
but
but
it
seems
like
interest,
but
it's
not
necessarily
collecting
on
anything
in
particular,
beyond
people
saying
like
well,
if
my
sampling
algorithm
was
was
baked
into
open,
telemetry.
B
Would
actually
explain
it.
I
like
the
contrib
model
too,
that
like
when
I
look
at
the
go
stuff,
there's
a
bunch
of
stuff
in
core
and
then
there's
a
bunch
of
stuff
in
contrib
and
it
seems
like
you
can
still
optionally
standardize
around
some
way
of
doing
things.
And
if
it's
good
everyone's
going
to
use
it
and
you
don't
need
to
bake
it.
A
Yeah,
sorry
about
that
yeah
it
is
my
prediction
actually
we've.
This
is
the
thing
we
just
put
together
over
at
lightstep
is
a
open,
telemetry
distro.
I
actually
predict
this
to
be
a
more
common
solution
for
open
telemetry.
It's
like
a
packaging
or
distro
model,
so
I've
been
talking,
like
you,
see
me
around
open
telemetry.
I
talk
about
this
a
lot
to
answer
this
question
of,
but
my
back
end
requires
specific
plugins
or
whatever.
A
I
actually
think
a
distro
is
better
than
telling
the
end
user
to
like
remember,
to
configure
a
bunch
of
stuff
correctly
like
most
of
the
configuration
nonsense
you
have
to
do.
That
makes
open
telemetry
startup.
Look
honestly
kind
of
ugly
right
now
is
due
to
the
fact
that
it's
very
flexible
right
and
it
can
connect
up
to
a
bunch
of
systems,
but
if
you're
just
connecting
to
a
system,
then
it's
easy
to
pre-configure
all
of
that
stuff.