►
From YouTube: 2022-04-21 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
Yeah
and
there's
a
few
of
it
any
more
tornadoes
or
fire
storms
out
there.
C
B
Oh,
maybe
it's
the
the
lyric
meteor
okay
yeah,
nice
yeah,
that's
kind
of
a
bummer
yeah.
D
E
C
Google
calendar
kind
of
creates
automatically
and
then
there's
an
actual
link
in
the
text
of
the
invite.
C
F
B
F
C
The
one
that's
branded
like
a
google
document
always
goes
somewhere
weird
for
me,
but
the
one
that's
actually
the
text
in
in
the
email
is
is
the
one
you
have
to
go
to.
I
don't
know
why
or
how
those
got
set.
B
Yeah,
I
think
it
had
something
to
do
with
when
the
zoom
reshuffle
happened.
But
yeah,
I
don't
know,
that's
a
I
don't
know
how
to
clear
it
either
so
yeah
cool
we're
okay,
we're
two
minutes
in
so
we
could
probably
get
started.
Everyone
on
the
call,
please
be
sure
to
add
yourself
to
the
attendees
list
of
the
agenda
doc.
If
you
need
a
link,
it's
in
the
comments
of
the
zoo
meeting
and
if
you
have
anything
you
want
to
talk
about,
please
add
to
the
agenda.
B
Also,
if
you
have
any
like
user
stories,
can
we
add
those
now
because
I
don't
want
to
overrun
and
miss
those,
because
those,
I
think,
are
a
useful
thing,
so
just
make
sure
you
put
down
some
sort
of
link,
or
even
just
your
name
on
the
user
story,
so
I
make
sure
we
share
or
we
have
enough
time
at
the
end,
I
think
he's
kind
of
my
goal:
there,
cool
yeah.
I
think
we
have
a
fair
amount
to
touch
on
today,
so
I
wanted
to
probably
jump
off
here.
B
To
start
I
wanted
to
touch
base.
The
next
release.
Milestone
was
view
1.7.
We
have
prs
to
address
everything,
that's
in
the
milestone,
so
this
should
be
completable.
B
Very
soon
my
goal
is,
I
think,
I
put
down
april
30th
when
I
created
this
as
just
a
timeline
which
was
completely
made
up,
but
it
looks
like
it
seems
somewhat
plausible
at
this
point.
So
if
we
could
try
to
get
these
merged
this
week,
I
think
that
next
week
we
could
get
the
release
out
and
have
a
1.7
release
for
anyone
interested.
D
B
Can
look
at
the
all
the
closed
issues
and
prs
there?
The
only
thing
left
are
the
in-memory
exporter
and
then
this
pr
that
I
just
added
today
for
the
semconf
1.10.
B
This
is,
if
you
reviewed
the
other
ones
very
similar,
there's
a
lot
of
generated
code
and
there's
a
few
said
commands
that
updated
packages.
So
it's
a
lot
to
look
at
number
wise,
but
it
was
generated.
I
think
you
could
actually
probably
verify
it
if
you
wanted
to
do
your
own
generation.
Compare
the
diff,
which
I
haven't
done
because
I
made
the
pr,
but
I
think
that's
probably
you
know
if
you
really
want
to
double
check
me.
I
appreciate
the
double
check,
but
otherwise
yeah.
B
I
think
that's
a
good
one
to
put
on
your
list
of
reviews,
the
only
other
one
is
they
create
an
in-memory
exporter
for
testing.
This
is
something
that
we
needed,
especially
in
the
contrib
revo
for
testing
a
lot
of
the
implementations
against
the
new
api.
It
looks
pretty
close.
There's
two
approvals,
there's
still
outstanding
comments
on
this,
though,
and
I
think
I
need
to
go
back
and
these
are
good
responses.
I
think
these
are
resolvable.
I
was
looking
at
them
today,
but
there's
a
few
other.
B
I
think
follow-up
knits,
that
kind
of
came
in
here
from
both
me
and
josh,
but
they
don't
look
blocking
but
aaron.
If
you
have
a
cycle
or
two,
we
can
probably
get
this
merged
tomorrow
at
the
latest.
If
you
don't,
you
could
probably
push
up
fix
as
well.
So
yes,
let
me
know.
B
Yeah,
it
was,
I
don't
think
there
was
anything
really
too
big
here.
I'm
also
looking
at
this
going
like
this
might
change
as
well
in
the
next
release,
when
we
do
have
the
metrics
sdk
milestone
come
out,
it.
C
Will
but
it
yes,
it
will,
but
this
still
lays
a
pretty
good
groundwork
for
what
to
kind
of
expect
for
the
next
go
round.
B
Right
so
I
think
it's
wasted
effort.
I
guess,
is
a
good
way
to
put
it.
I
think
it's
useful,
so
yeah,
it's
appreciated.
B
Okay,
that's
it
for
this
milestone.
This
actually
has
an
owner,
make
sure
that's
set
cool.
Then
the
next
thing-
and
this
is
kind
of
the
meat
potatoes
here-
is
the
metrics
fdk.
There's
definitely
been
some
work
in
the
past
about
trying
to
get
a
working
example
out
and
this
past
week
or
last
week
we
talked
about
building
an
example
branch
and
a
new
branch
to
contain
the
feature
that
was
done.
Aaron
I
created
both
just
for
those
that
aren't
aware.
B
There's
this
new
sdk
example
branch
that
creates
the
poc
that
was
kind
of
worked
on
by
both
aaron
and
josh,
and
then
there's
this
new
sdk
main
branch,
that's
created
to
contain
all
the
feature,
work
and
that's
something
that
we're
trying
to
pr
into.
I
I'm
not,
I
think,
yeah
there
was
always
this
requires
pr's
with
approvals.
So
this
is
a
reviewed
branch.
B
This
is,
I
don't
know
this
is
blocked,
but
I
imagine
now
it
looks
you
know
not
feature
complete
if
you
would
but
like
it
looks
complete
enough,
we're
probably
just
going
to
leave
it
as
is
and
just
kind
of
reference
it
so
yeah.
If
you
wanted
to
take
a
look
at
the
full
example,
I
think
this
is
a
worthwhile
thing
to
dig
into
it's
been
interesting.
I've
been
doing
this
for
a
few
days.
C
The
the
example
branch
my
plan,
for
that
was
there-
will
be
differences
between
what
eventually
lands
in
maine
should
mostly
be
what
you
call
it.
It
should
mostly
be
like
documentation
work,
but
even
now
I've
been
writing
tests
for
the
number
package
and
I
found
that
we
are
reading
or
writing
to
it
atomically,
but
we're
not
reading
from
it
atomically,
which
doesn't
help
right.
C
It
doesn't
do
stuff,
so
there
will
be
prs
pulling
the
stuff
that
we
do
in
that
lands
in
maine
into
the
example,
so
that
we
can
keep
referencing
it
going
forward
right.
That
adds
a
little
bit
of
extra
work,
but
it
helps
know
what
you're
pulling
from
right.
So
they
don't
diverge
too
far.
B
Yeah,
that's
a
I
mean,
I
don't
know
what
other
people
feel
about
this,
but
I
feel
like
that
might
be
an
overhead
that
might
not
be
needed,
and
I
think
I
say
that
with
a
little
bit
of
foreshadowing,
because
I
wanted
to
talk
a
little
bit
about
the
project
and
how
we're
breaking
down
the
implementation,
because
I
feel
like
there's
some
there's
a
great
end-to-end
implementation
in
the
example
branch.
B
But
I
don't
feel
like
the
interface
structure
and
how
we
want
to
like
structure
the
packages
might
change
a
fair
amount,
and
so
I
just
worry:
if
that's
going
to
be
too
much
of
a
never
had
to
go
back
and
refactor,
you
know
end
to
end
every
single
time,
but
I
don't
really
know
the
answer
there.
Maybe
we
can
put
come
back
to
that.
One.
B
Sense,
yeah,
okay,
because
I
like
I
enjoy
having
a
working
example
of
the
end
to
end,
but
it
also
could
be
that
you
know
we
have
a
new
branch
as
well
new
new
sdk
example,
two
or
two
dot
new
or
two
dot
new
final,
or
something
like
that
yeah
but
yeah.
I
don't
know.
I
think
I
think
that's
a
good
idea:
okay,
but
yeah.
B
I
think
that,
regardless
of
where
we're
at
now,
if
you
want
to
be
involved
in
the
sdk
development,
I
would
recommend
going
and
looking
at
this
branch
and
looking
through
this
metrics
sdk
package
here,
because
this
is
this
is
where
it
all
happens.
This
is
the
magic,
so
yeah
definitely
worth
worth
taking
a
look
at
and
if
you're
not
interested
in
development,
but
you're
interested
in
the
development
progress.
B
I
created
this
project
board
to
try
to
track
or
track
the
project,
as
well
as
a
milestone
for
those
who
are
even
less
interested
in
the
development
process.
So
the
goal
here
is
to
have
this
track
that
alpha
released,
so
this
is
going
to
essentially
be
closed
when
we
merge
that
feature
branch
into
the
main
branch.
B
B
This
is
probably
not
accurate,
it's
probably
less
than
that
and
that's
going
to
go
into
where
the
agenda
is
going.
Is
I
want
to
talk
a
little
bit
about
this
being
incomplete,
there's,
probably
some
more
tasks
to
identify.
I
definitely
know
there
are
because
this
is
an
issue
yet,
but
I
think
that
we
probably
want
to
create
and
build
this
out
so
yeah,
maybe
just
start
talking
about
this.
B
The
way
that
I
saw
this-
and
we
talked
about
this
last
time
in
the
meeting-
was
we
could
try
to
build
up
this
feature
branch,
possibly
not
in
a
working
state,
and
the
first
thing
that
I
was
looking
at
doing
is
just
looking
at
structure
and
mostly
interface
structure
or
public
api
structure
is
probably
the
best
way
to
to
look
at
how
we're
going
to
build
the
the
new
package
and
to
do
that,
I
kind
of
broke
off
some
main
components
that
I
saw
from
the
example
branch
as
just
a
starting
point,
specifically
looking
at
things
like
adder
meter
provider,
meter
structure,
adding
segregation
package,
the
sdk
instrument
package,
the
views
package.
B
These
are
all
things
that
you
probably
need
to
reference.
The
example
branch
to
actually
have
a
good
understanding
of
what
package
is
being
referenced
here.
So
just
keep
that
in
mind
and
the
goal
is,
I
think,
once
you
have
that
to
create
something
along
this
one.
This
is
the
only
one
that
I
might
want
to
show
at
this
point,
but
you're,
you
know
stubbing
in
with
a
bunch
of
news.
B
You
know
where
there's
really
little
content,
but
you
get
a
good
understanding
of
the
actual
structure
of
what
we're
trying
to
implement
here
and
trying
to
merge.
Ideally,
you
know,
based
off
of
the
skeleton
already
exists
in
the
example
code
and
then
from
here
we
already
have
issues.
The
goal
is
to
make
sure
you
have
issues
tracking
all
the
implementation
details
that
you
need
to
do,
and
I
think
this
is
a
good
way,
because
we
can
kind
of
agree
on
the
overall
strategy
for
the
api
design
and
then
can
parallelize
the
implementation.
B
So
somebody
can
take
the
implementation
of
you
know
in
a
situation
like
synchronous
instruments,
someone
can
take
the
implementation
of
the
asynchronous
instruments
and
they
can
work
asynchronously.
So
I,
I
think,
there's
a
lot
of
value
there
to
try
to
help
speed
this
up
as
well
as
to
limit
pr
size
instead
of
having
you
know,
thousands
and
thousands
of
lines
of
code
to
review.
We
can
start
off
with
api
design
and
just
build
from
there.
B
I
think
was
kind
of
my
idea
and
that's
how
I've
structured
this
project
for
to
try
to
encapsulate
that.
But
I
also
don't
have
all
the
implementation
issues
some
of
them.
I
do
because
I
you
know
I
was
working
on
some
of
these
pr's
already,
but
I
think
you
know
aaron's
already
created
one
for
the
numbers
package,
so
this.
B
List,
I
think,
is
what
I
would
say
here
so
yeah.
Let
me
just
pause
and
see,
because
I
wanted
to
get
some
feedback
on
this.
If
there's
any
initial
ideas
or
questions.
G
Yeah,
let
me
second
that,
and
I
think
this
is
a
really
good
way
to
go
about
it.
I
think
anything
we
can
do
to
enable
parallel
efforts
will
be
great,
and
this
looks
like
a
good
way
to
get
us
moving
in
that
path.
B
Cool
yeah:
I'm
excited
to
hear
that.
C
B
Yeah
that'd
be
really
helpful,
because
that
is
definitely
something.
I've
noticed
that
you
know
I'm
putting
like
comments
with
blocked
in
here.
It's
not
like
jira,
where
you
can
actually
link
issues
for
that
kind
of
thing,
but
yeah.
I
think
that
would
be
a
really
good
thing,
also
aaron.
If
we
could
put
that
in
the
readme
here,
which
I
just
found
out.
A
B
Yeah
right
so
yeah,
I
think
you
can
go
in
settings.
I
think
yeah
right
here
and
then
you
can
essentially
just
put
in
markdown.
So
we
can.
I
link
the
milestone
here
and
then,
if
you
have
like
a
design
dock
for
that,
we
can
link
to
it
here.
I
think
it'd
be
really
helpful.
B
Yeah
these
new
project
boards
they're
beta
but
they're
better
than
the
last
ones.
That's
all
I'm
going
to
say.
B
B
I
did
my
best
to
try
to
like
encapsulate
things,
one
of
which
was
you
know
just
for
those
that
we're
following
removing
everything
from
the
existing
new
sdk
main
branch,
that
is
in
the
metrics
package,
so
that
we
can
have
a
clean
slate
and
there
are
definitely
things
we
know
we
need
to
add
back
like
the
prometheus
example
code.
Exporter
standard,
all
that
kind
of
stuff,
so
there's
tracking
of
that
documentation
is
kind
of.
I
left
that
as
tasks
as
well.
B
B
We
want
to
do
afterwards
that
we
want
to
track
in
an
issue,
but
I
guess
my
request
is
to
review
this
and
see
if
you
think
you
find
something
missing
and
if
you
do
add
it,
it
should
be
pretty
straightforward
to
add
it,
and
if
you
aren't
able
to
ping
a
maintainer
but
or
an
approver,
I
don't
know
what
the
permission
level
you
need
to
be
able
to
add
it,
but
yeah.
I
think
that
we
can
try
to
coordinate
on
that
cool
and
then
once
that's
done.
B
I
think
that
the
you
know,
the
ultimate
question
is
when
when's
this
gonna
land-
and
I
don't
know
I
I
mean
I
can
throw
out
a
date
and
I'm
almost
guaranteed
to
be
wrong,
especially
if
it's
you
know,
depending
on
the
community
which
it
is
right
like
this
is
an
open
source
project
and
it's
not
run
by
one
person
and
by
that
I'm
definitely
saying
it's
not
run
by
me.
It's
run
by
everyone
on
the
call
and
everyone
contributing.
B
So
you
know,
like
our
timelines,
are
definitely
going
to
be
dependent
on
that
community
involvement
and
I'd
like
to
probably
get
a
date
that
we
can
try
to
target
so
one.
We
can
communicate
the
broader
user
space
where
our
plans
are
landing,
but
also,
I
think
it
helped
give
us
a
goal
to
strive
for
open-ended
milestones
are
not
really
they
don't
have
as
much
priority,
even
though
this
does
have
a
priority
to
it.
B
So
maybe
I'll
ask
that
like
if
there
is
an
initial
date,
that
people
think
that
we
should
try
to
target
and
if
maybe
in
a
week's
time,
when
everyone
has
time
to
review
this,
we
can
come
up
with
a
better
date
on
that
one.
B
Yeah
me
too,
I
mean
yesterday,
oh,
I
was
going.
B
Yeah,
I
think
both
of
those
sounds
well.
I
guess
one
is
unrealistic.
The
other
is,
I
hope,
not
but
yeah.
That's
that
would
be
really
cool.
G
So
I
I
think
for
for
an
initial
you
know,
swag
stab
in
the
dark
end
of
may
sometime
in
june
would
sound
like
possibly
feasible.
We
have
the
was
it
the
the
open
telemetry
community
day
at
one
of
the
cncf
events
june
20th.
If
we
could
announce
by
then
that
would
be
very
cool.
B
Yeah,
that
would
be
really
cool.
So
what
if
I
put
june
15th
and
then
that
gives
us
like
three
days
to
get
the
release
out
and
make
sure
that
it's,
I
guess.
B
B
B
Okay,
see
I've
got
june
18th,
and
this
is
like
two
months
or
something
like
that.
It's
the
21st
yeah,
okay,
because
it's
two
months.
So
that's
really
the
back
of
the
envelope.
What's
that
seven
weeks,
something
like
that,
I'm
really
just
estimating
hard
on
that
number
space.
So
I
think
that's
reasonable.
B
It
definitely
is
going
to
require
some
coordination,
because
I
think
that
I
think
it's
doable,
though
I
think
that's
a
that's
a
good
good
estimate
in
my
opinion,
but
I
also
think
that
having
a
more
complete
list
and
seeing
the
velocity
as
we
go
through
this
week
after
week
would
probably
get
a
better
understanding
when
that
timeline
would
be
so
yeah.
I
guess
if
anybody
does
rely
on
this
date
know
that
it
is
a
soft
obvious
way
to
say
that.
B
I
think
that's
it
for
a
lot
of
the
project
structure.
I
did
have
some
questions
about
the
metrics
space
and
the
design
of
the
example
branch.
B
I
don't
know
I
see
like
four
people
at
a
time
on
the
call,
if
it's
worth
getting
into
that
discussion
here,.
C
I'm
open
to
discussing
it
here.
We,
if
you
want
to,
we
can
push
it
to
the
end
of
the
meeting
and
I'm
more
than
happy
to
go
other
time
periods
to
to
talk
about
this.
Okay,
so.
B
Yeah,
I
kind
of
like
that
idea
at
least
pushing
it
to
the
end
and
maybe
not
if,
if
that's
running
over,
we
could
probably
schedule
something
directly
for
it:
cool,
okay,
yeah.
Let's,
let's
do
that!
I
don't
wanna
for
everyone,
let
alone
just
pick
up
their
own
time
on
the
meeting.
Okay.
So
next
the
agenda
open
telemetry
calls
detection
via
ast
rewriting.
D
Yes
hi,
so
my
name
is
mike
delevsky.
I
am
new
in
open
telemetry,
but
not
new.
In
instrumentation,
and
recently
I
made
a
poc
about
open
telemetric
calls
injection
automatic
injection
via
asd,
rewriting
abstract
syntax.
Three.
So
I'm
wondering
if
someone
was
working
on
that
before
and
if
a
community
community
would
be
interested
in
such
a
thing.
D
So
on
this
repo
you
can
see
complete,
very
small,
minimal,
viable
product
and
on
this
the
first
snippet
of
the
codes
shows
original
code
and
the
second
one
is
after
ast
rewriting,
so
the
open
telemetry
calls
are
injected
there.
D
C
D
Code,
so
we
can
look
at
the
source
code
if
you
want
and
it
it's
it
adds
statements
to
the
ast.
So
it
is
just
a
code
rewrite.
It
works
like
a
compiler.
C
B
Yeah,
I
agree.
I
definitely
think
it's
an
interesting
use
case
here.
I
think
I
was
thinking
along
the
same
lines
that
aaron
was
talking
about
with,
like
you
know,
using
it
as
a
generation
tool,
I'd
love
to
know
about
like
how
you
would
handle
independency
there,
though,
if
you
run
it
multiple
times,
if
you'd
have
multiple
traces
of
the
same
function
but
yeah.
I
also
think
it's
kind
of
interesting
to
you
know
auto
annotate,
a
main
function
with
the
setup
of
a
new
tracer
provider.
B
I
do
question
the
I
guess
the
configurability
and
the
usability
of
that,
because
I
think
that
you
probably
need
to
have
an
opinion
or
you
would
have
to
be
able
to
configure
the
auto
instrumentation
tooling
itself.
To
do
that.
Configuration
which
I
don't
think
is
is
hard
but
yeah.
I
think
that's
that's
kind
of
a
cool
idea.
B
G
About
it
not
being
magic,
though,
and
just
inserting
some
code
is
that
the
user
can
then
come
along
and
change
that
code
like
if
it's
opinion
doesn't
match
what
the
user
wants
to
do.
They
can
then
change
it,
but
this
gets
them
started.
It's
it's
a
scaffold,
a
starting
point,
which
can
be
important
for
for
a
lot
of
people
who
are
just
like.
I
don't
know
where
to
start.
How
do
I
get
started.
C
G
Yeah
yeah
same
thing
with
with
cobra
like
it's:
okay,
here's
a
starting
point:
you
go
fill
in
the
actual
functional
bits.
B
I
I
agree
yeah.
I
think
it
would
be
really
cool
to
is
this
listed
in
the
registry
for
the
open,
telemetry.
D
B
Not
yet?
Okay,
I
would
yeah
like
I
said.
I
think
this
is
anthony,
makes
a
good
point
like
this
is
a
great
starting
point.
It
could
be
cool,
I
think,
eventually,
to
get
something
like
this
in
the
contrib
repo
I'd
want
to
see
some
use
cases,
though
I
think
to
make
sure
we
hit
the
right
interface.
B
I
think
a
good
way
to
try
to
get
traffic
to
this
would
be
to
list
this
in
the
registry
and
start
to
generate
some
some
uses
of
it
because
I
think
like
or
even
just
like
people
who
start
writing
blogs
or
something
like
that,
or
maybe
we
can
write
a
few
blogs
on
how
to
do
this,
because
I
think
there's
some
use
to
like
anthony
says
like
get
started.
I
think
it's
a
great
use
case.
G
Mentioning
it
in
the
slack
channel
could
be
good
too.
You
might
find
some
people
interested
there.
One
idea
that
comes
to
mind
is
in
order
to
properly
trace
through
function
execution.
The
context
is
going
to
have
to
be
passed,
so
I
saw
like.
G
G
But
does
this
check
to
see
if
the
functions
it's
adding
spans
to
receive
a
context
that
might
be
a
good
check
to
only
create
spans
when
a
context
is
already
passed
in,
so
that
you
can
expect
that
you'll
be
able
to
tie
into
a
trace.
D
Well,
probably,
we
have
to
think
about
that,
but
you
know
this
is
the
first
first
poc
first
prototype,
but
we
can
take
this
and
work
used
by
case
by
case
on
such
things.
So.
B
So
I
definitely
am
interested
I'd
love
to
see
that
as
well
and
and
try
to
evolve
this
it'd
be
really
cool
yeah.
I
agree.
I
think
postings
and
slack
and
putting
this
in
the
registry
are
really
good
steps
and
then
I'd
love
to
like
see
some
use
cases
and
honestly
I'd
love
to
play
with
it
so
yeah.
I
think
this
is.
This
is
a
great
share,
thanks
for
bringing
it
to
the
community.
B
Cool
man
we
got
auto
instrumentation
use
cases
here
so
now,
instrumentation
day
I
guess
yeah
yeah
eden
next
on
the
list
is
the
go.
Auto
instrumentation
link
as
well
I'll
hand
it
off
to
you
for
that.
H
Yeah
sure
so,
hey
I'm
idiot.
I
also
created
a
recently
project
aiming
to
do
automatic
instrumentation,
I'm
trying
to
do
it
using
abpf.
Basically,
there
is
a
pretty
detailed
document
explaining
how
it
works
and
all
the
obstacles
I
faced
trying
to
instrument
go
with
with
tbpf
there.
H
Many
weird
things
like
go:
routine,
tracking
and
timestamp
tracking,
and
it's
a
pretty
new
project,
we're
doing
this
about
the
instrumenting
libraries
like
geography
and
gorilla
marks
and
also
functions
in
the
standard
library
like
net
http.
You
can
also
show
you
that
creating
a
new
instrumentation
is
very
simple.
You
just
have
to
specify
the
function
name
that
you
would
like
to
instrument,
and
you
also
need
to
specify
which
structs
and
the
data
fields
you
would
like
to
read
from
the
function
arguments
and,
basically
that's
it.
H
The
library
handles
correlating
the
routine
id
and
timestamps,
and
we
track
different
offsets
of
structs
both
in
the
standard
library
and
in
open
source
projects
and
running.
It
is
really
simple:
if
it's
in
a
kubernetes
environment,
it
simply
can
be
run
as
a
sidecar
in
the
same
pod
on
a
regular
linux
machine.
It's
just
another
process
such
that
gets
us
an
argument.
The
process
id
of
the
compiled
go
binary
yeah.
That's
it
excited
to
hear
what
you
think
about
it.
C
I
saw
this
earlier
in
the
week
and
I
thought
it
was
really
neat.
I'm
really
excited
that
we
finally
figured
out
how
to
actually
to
deal
with
the
the
return
mangling
that
that
go
does
in
ebpf.
So
I
know
it.
Last
time
I
looked
at
ebpf
with
go.
It
was
a
while
ago,
so
that
was
always
untreaded
waters.
H
Yeah,
I
also
know
there
is
a
some
efforts
in
the
upper
geometry
operator
seed
to
to
make
automatic
instrumentation
in
kubernetes
very
easy
by
implementing
like
a
controller
for
every
programming
language.
So
I
also
thought
about
integrating
with
them
and
trying
to
maybe
provide
some
sort
of
easier
transformation
for
them.
B
Yeah,
I
think
that's
a
a
great
suggestion
is
coordinating
with
them,
because
I
definitely
know
that,
like
especially
since
you
have
already
had
like
the
kubernetes
example
building
an
operator
from
that
would
probably
be
a
pretty
easy
next
step.
B
Yeah
I'd
probably
also
recommend
that
we
list
this
somewhere
in
the
registry.
I
think
this
is
something
we
want
to
try
to
popularize
as
well,
just
to
get
some.
You
know,
collaboration
on
and
and
I'd
love
to
see
more
use
cases
on
this
one
so
yeah
again
like.
I
think
this
is
a
really
great
share.
B
Yeah,
I
kind
of
want
to
take
more
look
at
it.
I've
been
distracted
on
other
things,
but
it's
it's
definitely
something
both
of
these
transportation
ideas.
I
think
yeah
there's
a
lot
of
things.
I'd
love
to
spend
my
time
on,
and
I
don't
have
enough
time.
B
So
yeah
I'm
really
excited,
I
guess
for
both
of
them
to
have
been
taken
by
people
and
I'm
excited
to
try
to
promote
them
as
well.
As
you
know,
have
users
give
some
feedback
on
them.
I
think
it'd
be
really
cool.
B
E
The
the
oh
sorry
yeah,
the
I
was
particularly
interested
in
the
ebpf
one,
most
of
our
gopros,
that
we
write
ourselves
we're
trying
to
instrument
liberally.
But
we
do
run
a
bunch
that
we
can't
touch
and
if
I
understood.
E
H
E
Yeah
we
often
we
have
gaps
where
we
go
retracing
calls
between
programs,
where
our
calls
go
into
some
server,
that
we're
running,
that
we
didn't
write
and
instrumenting
and
getting
that
accepted
upstream
is
just
too
much
of
a
push.
So
this
would
allow
us,
I
think,
by
understanding
to
just
wrap
it
and
assuming
the
propagators
are
configured
and
the
resource
would
be
configured
through.
We
could
get
a
lot
of
use
out
of
this.
B
And
steve
yeah:
do
you
also
see
like
the
auto
code
generation
stuff
as
well
being
using
it
for
just
like
building
up
projects,
because
I
know
that
you
do
a
lot.
You
know
like
starting
services
and
like
just
coming
on
and
working
to
instrument
them.
Is
that
something
you
see
usable
as
well,
or
is
that
something
a
little
outside
of
your
wheelhouse?
E
When
taking
a
you
know
a
third
party
project,
it
would,
it
would
touch
so
many
files,
it's
very
hard
to
understand,
like
trying
to
incorporate
changes
again
from
upstream
you'd
have
to
keep
backing
up.
You
know,
take
the
changes,
merge
them
and
then
generate
the
code
again
in
order
to
be
able
to
understand
the
diffs.
E
So
I
think
that
the
one
that
you
know
the
second
project
that
doesn't
touch
the
code
itself,
even
though
it's
much
more
mystical
how
it's
achieving
its
ends,
what
would
be
easier
for
us
to
incorporate
it
interesting,
okay,
yeah
yeah?
We
already
are
using
some
for
different
reasons,
ebpf
by
way
of
calico.
E
E
Because
I
I
got
done
trying
to
figure
out
how
to
read
your
emoji
and
that
actually
made
me
go
study
the
project
more
and
try
to
figure
out.
If
you
were
insulted,
or
you
know
impressed
to
the
point
of
falling
out
of
your
chair
or
where
you
were
on
it.
G
A
little
bit
mind
blown,
I
think,
was
what
I
was
trying
to
convey.
I
Saw
it
I
couldn't
figure
out
how
something
worked
and,
of
course,
I'm
curious.
Can
you
talk
a
little
bit
about
how
how
it
does
like
association
between
incoming
and
outgoing
requests?
I
know
you
were
doing
like
figuring
out
which
go
routine.
It
was
using,
but
does
it
actually
do
propagation
or
what
heuristics,
I
guess,
does
it
use
to
like
match
up
something
coming
in
and
something
going
on.
H
Yeah,
so
currently
propagation
is
not
handled
entirely.
It's
just
correlates
by
the
corrupting
id
so
pretty
basic
right
now,
but
I
guess
we
can.
You
know,
figure
out
a
way
to
to
do
propagation
properly.
I
H
Yeah
I
had
an
example
application
of
like
a
grpc
server
that
also,
I
don't
know,
every
every
grpc
method
is
also
doing
like
an
http
request
and
because
they're
running
on
the
same
routine,
it
correlates
both
the
grbc
and
the
http
client
into
one
single
trace,
but
yeah.
There
are
many
edge
cases
and
it's
pretty
basic
implementation
form
for
now.
E
I
I
B
Cool
yeah,
I
think
again,
I
think
we
can
probably
talk
a
little
more
in
slack
on
these.
If
you
have
any
more
questions,
I
think
there's
a
neck
and
even
if
you
want
to
stick
around
if
you're,
not
a
part
of
the
open,
telemetry
cncf
slack,
please
join
I'll
try
to
post
as
well
for
the
auto
hotel
project.
Afterwards,
if
I
can
remember
but
yeah,
these
are,
I
think,
great
great
examples
of
collaboration
and
ingenuity.
B
I
was
hoping
this
project
would
spur
on
so
yeah,
it's
cool
to
see,
and
you
definitely
are
in
the
right
space,
because
this
is
a
great
user
story.
We
love
to
share
these
kinds
of
things
and
motivate.
I
think
a
lot
of
development.
B
Cool
okay,
I
think
the
only
thing
left
on
the
agenda
is
design
questions
and
these
are
related
to
the
metrics
sdk.
So
you're
all
welcome
to
stay
around
and
if
you
have
any
interest
in
the
sdk,
we
can
jump
into
that
before
I
just
remembered
tyler.
Is
there
anything
you
wanted
to
share
about
the
benchmark
progress?
I
saw
a
few
comments.
I
didn't
know
if
you
want
to
give
us
a
status
update
on
our
benchmark
test
for
our
ci
system.
B
Might
not
be
able
to
speak
right
now.
That's
also
something
I
didn't
consider,
but
the
okay
topic.
I
I
couldn't
I
wasn't
sitting
at
my
desk,
I'm
at
my
desk
now
yeah.
There
are
people
in
the
room,
all
right
benchmarks.
We
have
hardware,
it's
really
exciting.
I
I
don't
know
all
the
details
about
that
hardware
if
it's
like
somewhere
on
someone's
machine
or
if
it's
like
in
the
cloud
or
like
jurassic,
hasn't
cleared
that
up
for
me
yet,
but
the
idea
that
anthony
had
for
running
benchmarks
or
using
the
machines
as
self-hosted
runners,
which
would
be
absolutely
amazing-
and
it
looks
like
github-
has
like
a
system
in
place
to
make
that
really
easy.
I
They
really
really
really
discourage
it
for
public
repos,
because
if
you
fork
the
public
repo,
you
can
run
whatever
you
want
on
the
box,
so
they
really
only
recommend
it
for
private
repos.
I
We
probably
could
find
a
solution
that
would
allow
us
to
run
the
benchmarks
from
a
workflow
in
a
private
repo,
keep
the
benchmark
test
actually
in
the
public
repo.
So
people
can
modify
them
and
do
this
weird
hookup
between
a
public
people
and
a
private
repo
where,
like
a
workflow,
runs
in
the
public
repo
which
triggers
the
workflow
and
the
private
repo
which
then
like
the
actual
code
that
it
runs,
is
protected.
I
I
I
mean
in
theory
that
would
probably
be
doable,
but
it
sounds
pretty
complicated
and
it
sounds
like
a
lot
of
overhead,
so
that's
kind
of
where
that's
at
right
now
other
ideas
for
how
to
use
the
boxes.
I
think
that's
probably
what
we
should
be
thinking
about.
Next,
it's
like
okay.
We
have
this
idea
of
how
we
could
do
it
as
a
self-hosted
runner
in
github,
it's
kind
of
hard.
How
else
could
we
get
this
this
job
done?
I
It
wouldn't
run,
but
there
are
some
ways
around
it:
it
looked
like
where
if
people
go
and
they
like
modify,
workflows
and
stuff,
maybe
you
can
get
around
it
or
the
the
thing
that
worries
me
the
most
about
that
is
more
just
what
if
we
make
mistakes-
and
you
know
we
run
something
that
we
weren't
supposed
to
amplify,
that
across
every
sig
that
wants
to
use
the
boxes
and
the
risk
gets
a
little
higher,
so
that
is
technically
an
option
for
the
self-hosted
runner,
although
it
seems
like
there's
still
like
possible
security
risks
there.
I
B
Have
we
looked
at
the
hunter?
Sorry,
the
self
hosted
runners
and
just
manually
run
benchmarks
there
to
verify
that
they
have
a
more
stable
benchmark
performance.
I
I
Oh
yeah
forget
self.
If
we
forget
self-hosted
runners
for
a
second,
the
question
would
then
be
yeah.
Can
we
just
sshn
and
run
benchmarks
right
like
that,
would
should
be
possible?
I
think
the
answer
is
yes,
but
then
the
question
that
came
up
in
the
go
sig
on
wednesday
was
sorry.
The
collector
said
on
wednesday
was
who,
who
has
permission
to
ssh
in?
Is
it
every
maintainer?
Is
every
approver?
Is
it
every
contributor
like
that
list
and
that,
like
that
permission
gets
interesting,
so
yeah.
B
I'm
more
interested
in
just
a
a
validation
step.
I
would
not
recommend
this
in
the
long
term.
I'm
just
saying
give
you
access
to
ssh
and
have
you
go
run
the
benchmarks
and
do
some
performance
analysis
and
using
the
bench
stat
to
find.
If,
like
you
know,
we
have
consistent
performance
across
multiple
ventra
benchmark
tests,
because,
like
the
main
thing
we're
trying
to
solve
here,
is
that
the
benchmarks
wildly
vary
just
based
on
the
you
know.
B
I
I
Yeah
yeah,
especially
if
we
just
say
temporary,
but
if
the
goal
is
to
just
run
the
benchmark
somewhere,
that
isn't.
I
You
know
the
github
runners,
we
I
mean,
there's
probably
a
box
that
one
of
us
had
between
all
of
our
different
companies
that
we
could
go
run.
The
machines
are
just
just
to
test
that
out.
It
doesn't
have
to
be
the
cncf
boxes
to
do
that
particular
test
of
a
of
like
a
benchmark
validation,
so
that
could.
G
I
I
can
certainly
get
access
to
a
few
ec2
boxes
to
test,
but
I
think
we
want
to
test
in
the
environment
that
we
have.
I
G
Yeah
yeah,
as
long
as
we
can
validate
that,
whatever
boxes,
like
I
think
jurassic
said,
we've
got
some
very
amount
of
we've
got
access
to
some
bare
metal
at
equinix
or
something
like
that,
which
would
be
ideal
right.
That's
most
likely
to
be
absolutely
stable
performance
and
consistent.
You
know
over
the
long
term,
even
easy
to
you
know
you
might
end
up
with
noisy
neighbors
or
something
like
that.
G
I
think
we're
pretty
good
about
making
sure
that
doesn't
happen,
but
you
never
know
as
long
as
we
can
get
onto
the
to
the
boxes
that
we
would
run
this
on.
Validate
that
both
like
the
go
benchmarks
and
the
the
load
test
that
the
collector
has
seem
to
be
stable
and
consistent
there,
then
we
can
look
at.
G
I
I
can
I
can
follow
up
with
jurassic
and
tigran
and
try
to
get
some
at
least
temporary
access
and
and
run
the
tests
for
both
the
go
and
the
contrib.
G
And
then,
as
far
as
what
we
do
longer
term,
if
github
self
self-hosted
runners
are
a
problem
which
yeah
I
can
see
that
the
security
concerns
there.
Perhaps
we
can
do
something
with
github
web
hooks
and
you
know
having
a
service
that
can
be
triggered
by
a
web
hook.
That
will
execute
it
and
then
respond
with
the
results.
Yep.
I
D
C
If
we
do
that
and
find
that
most
projects,
don't
do
any
benchmarking,
because
this
problem
is
hard,
I'm
not
saying
we
shouldn't
do,
try
and
solve
for
it,
but
it
there
might
be
things
that
are
better
uses
of
our
time.
G
Set
up
so
looking
what
they
do
would
be
useful
yeah.
We
just
had
some
issues
with
something
we
needed
for
the
collector
that
they
rolled
back
based
on
changes
in
their
benchmark.
They've
got
fairly
detailed,
metrics
there.
So
looking
at
yeah.
I
B
Cool
it
sounds
like
we
have
a
path
forward,
so
yeah
thanks
again
tyler
for
digging
into
that.
It's
appreciated
and
all
the
collectors
say
if
you're
watching
it's
all
appreciated
cool
we've
got
12
minutes
left.
I
still
had
some
design
questions,
so
we
can
jump
into
those.
B
That's
a
good
question.
I
definitely
don't
think
we
can
get
all
of
these
talked
about
in
the
next
12
minutes,
so
maybe
before
we
do,
that,
would
people
be
willing
to
jump
on
a
call
tomorrow
and
have
some
dedicated
time,
maybe
in
the
morning
pacific
time
to
talk
about
this
is
that
something
people
would
be
interested
in.
C
C
B
Okay,
so
yeah,
I
think
if
it's
gonna
be
anything
past
like
next
monday,
we
probably
should
just
focus
on
asynchronous
conversation
and
the
issues,
but
I'd
love
to
just
get
some
some
quick
feedback
on
some
of
these
questions
or
ideas
that
are
kind
of
raised.
I
would
love
to
have
both
you
anthony
and
josh
there.
I
think,
because
we
would
have
a
lot
of
context.
I
also
want
to
make
sure
it's
open
and
it
would
be
available
to
the
rest
of
the
community
but
yeah.
B
I
wanted
to
prioritize
those
participants,
at
least
so.
Why
don't
we
touch
base
on
touch
base
after
this
to
coordinate
a
time
see
about
next
monday?
It
sounds
like
anthony's
pretty
busy
tomorrow
as
well,
and
we
can
just
jump
in,
and
I
think
maybe
we'll
just
talk
about
the
reader
one,
because
there's
no
way
we'll
be
able
to
resolve
it,
but
I
I
think
that
I
just
wanted
to
get
the
idea
out
there.
B
So
one
of
the
things
that
I
was
looking
at
in
one
of
the
issues
that
we
have
tracking
in
the
sdk
is
this
new
example
branch.
Sorry,
can
you
hear
me?
B
D
B
Yeah
for
those
who
were
on
the
call
a
few
weeks
ago,
josh
gave
a
really
great
overview
of
how
this
is.
You
know
hooked
into
the
provider,
but
I
think
that
I
was
looking
at
this
and
there's
a
lot
of
a
lot
going
on
in
this
package.
B
I
wanted
to
try
to
you,
know,
digest
it
a
little
bit
and
the
more
I'm
digesting
this
reader
interface
with
this
registry,
essentially
like
there's
just
a
method
to
register,
and
then
there's
this
like
concept
of
a
producer
and
the
producer
is
a
callback
really,
but
it's
in
an
interface
form
into
this
register
and
what
happens?
Is
the
sdk
I'm
sorry,
the
meter
per
meter
provider,
that
is
this
reader?
B
Whatever
the
implementation
of
this
reader
is
registered
with,
will
then
provide
this
function
to
a
callback
here,
essentially
in
a
register
process
which
is
it's
complex
yeah,
but
it
associates
the
reader
with
a
meter
provider
through
some
sort
of
registration
mechanism,
and
I
wonder
if
we
could
simplify
it
and
there's
a
lot
that
I
have
thought
about,
and
so
I'm
not
going
to
obviously
say
everything
I've
thought
about
in
the
past.
B
You
know
24
hours
in
eight
minutes,
but
I
proposed
proposal
together
for
a
different
approach
here,
where
the
reader
becomes
a
concrete
type,
which
is
a
structure.
The
periodic
reader
is
just
a
wrapper
around
that
with
some
sort
of
like
timing.
B
That
comes
off
of
it,
and
this
is
a
proposal
mind
you
I
have
not.
I
don't
have
a
full
implementation
of
this,
but
one
of
the
things
that
I
was
really
thinking
about
is
that,
like
in
the
specification
there's
this
really
odd
statement
that
says
that
the
sdk
should
not
allow
a
reader
to
be
registered
with
multiple
media
providers,
which
I
think
is
doable,
but
it's
also
like
a
little
convoluted,
because
if
I
take
a
reader
and
I
try
to
register
with
another
media
provider,
the
other
meter
doesn't
know
about
it.
B
It's
another.
You
know
so
or
is
there
like
a
global
state
or
like
does
the
reader?
You
have
to
know
that
the
reader
is
going
to
hold
that
you
know
that
flag
essentially
saying
like
I've
already
been
registered
and
then,
if
that's
the
case,
what
happens
when
users
start
implementing
the
interface
you
know
like?
Did
they
do
that?
So
it's
a
little
weird.
I
was
also
looking
at
some
of
the
other
implementations.
B
I
was
looking
at
mostly
python
and
java,
and
one
thing
that
really
stood
out
to
me
is
that
in
java
the
reader
type
is
not
expected
to
be
implemented
by
users
and
they
kind
of
get
my
thinking,
because
the
specification
itself
pretty
much
says
that
there's
only
ever
going
to
be
two
reader
types,
and
you
know
if
there's
only
ever
going
to
be
two
reader
types
and
if
we
wanted
to
add
one
at
a
later
point,
we
just
add
a
new
type.
B
It
was
kind
of
odd
to
me
why
we
would
want
to
have
some
sort
of
interface
and
I
think
it
cleaned
up
a
lot
of
things,
but
I
don't
know
I
just
wanted
to
like
kind
of
put
that
out
there.
I
I'm
wondering
also,
if
josh
has
thought
through
this
or
if
it
was
just
initially
like.
We
need
to
have
an
interface,
because
that's
what
the
specification
had
or
we
you
know
essentially
are
inheriting
what
the
old
controller
was.
I.
C
I've
gone
through
this
a
couple
times.
The
reason
why
we
settled
on
an
interface
and-
and
I
really
pushed
for
an
interface-
is
that
prometheus
is
weird
compared
to
everything
else,
that
we
do
that
pushes
so
in
in
the
realm.
D
C
This
the
meter,
the
metric
reader,
the
reader,
is
actually
the
source
of
when
collect
happens,
right
right
there
you'll
see
in
the
the
example
there's
a
manual
reader,
which
is
one
of
the
ins
and
implementations
that
has
the
collect
interface,
but
prometheus
is
also
a
reader
in
a
sense
in
that
it
knows
when
to
start
fire
getting
information
from
the
meter
provider.
B
As
well-
and
I
was
thinking
about
that
in
the
in
the
sense
that
like
there's
this
initialization
problem
because
like
in
the
tracing
world,
it's
you
know,
the
provider
gets
past
a
span
processor
which
gets
past
an
exporter,
and
if
we
did
this
this
way,
you
know
the
reader
is
really
the
thing
that
gets
a
meter
provider
and
an
exporter
and
yeah
like
maybe
even
an
exporter,
gets
a
reader
gets
a
meter
provider.
But
I
still
think
that
this
is
solvable
with
the
prometheus
example.
B
Where
you
have
a
concrete
meter
and
you
don't
necessarily
have
the
prometheus
example,
be
an
implementation
of
a
reader,
but
it
essentially
consumes
its
own
reader.
So
like
that
exporter
knows
to
call
you
know
a
reader
that
is
wrapped
around
a
meter
provider,
and
I
think
you
can
do
that.
Just
just
did
the
you
know
all
the
same,
just
providing
some
sort
of
media
provider
to
a
new
function,
and
then
you
know
the
prometheus
exporter
is
a
true
exporter
and
it's
you
know.
It
still
has
that
you
know
manual
collection
of
the
the
reader.
C
So
the
the
the
question,
the
the
issue
that
I
can
see
there
is
the
prometh
like
the
way
the
prometheus
one
is
built,
and
this
is
just
structured
around
prometheus-
is
it
is
within
a
go
routine
like
an
within
a
fetching
of
a
channel
that
you
pull
the
data
out
and
then
you
have
to
export
that
data
back
onto
the
channel
like
there's
a
signaling
that
happens
there,
it
it
gets
a
inform.
C
B
The
prometheus,
if
you
get
a
signal
that
you
need
to
export
right,
there's
a
there's,
a
target
being
hit
right.
The
exporter
calls
collect
and
then
collect
is
passed
down
through
the
exporter
right
because
that's
going
to
be
the
end
endpoint
and
the
collector
gets
the
you
know
the
the
signal
of
all
the
metrics
that
need
to
actually
be
exported
and
it
passes
those
back
to
the
channel.
Would
that
not
work.
C
B
It's
passed
a
major
provider
and
the
meter
provider
is
used
to
create
a
reader
and
in
the
context
of
that
reader
the
type
itself
is
passed
as
the
exporter,
so
like
you're,
you're,
self-containing
yourself
so
like
the
exporter,
is
doing
the
whole
creation
process.
But
export
is
the
thing
passed
to
the
reader
right,
like
you
pass
this
exporter
here
to
the
reader
right
and
then
when
collect
is
fired,
that
exporter
is
signaled
with
the
whatever
the
response
or
whatever.
The
export
call
needs
to
be.
D
B
B
Yeah,
but
I
think
that's
that's
what
I'm
saying
like.
I
think
that's.
Why,
like
there's
this
whole
thing,
where
it
really
isn't
that
way
like
you
can
definitely
have
the
export
to
wrap
a
reader.
It
can
be
both
ways,
there's
nothing
to
say
that,
like
you
know,
you
know.
Yes,
the
reader
passes
something
to
me,
but
I
can
also
pass
something
to
the
reader.
B
There's
an
interplay
there's
a
back
and
forth
between
the
two
and
like
that's
how
it's
already
working
in
the
example
for
prometheus
right,
like
the
prometheus
reader,
does
both
it
does
the
collection
and
it
does
the
receiving
right.
So
there's
nothing
to
say
that,
like
you,
can
have
something
that
initiates
the
collection
and
initiates
the
receiving
right
and
then
just
does
the
response
that
way.
C
But
but
that's
it
it
does
that,
because
it
is
a
reader,
it
itself
is
the
reader
if
you
have
to
like,
if
you're,
creating
a
reader
like
a
concrete,
if
you
create
a
concrete
reader,
but
it
has
to
know
the
prometheus
object
before
you
create
it,
then
you
have
to
have
a
second
step
somewhere
along
the
line.
To
also
tell
that
object
about
the
reader
that
you
created.
B
Yeah,
I
agree
and
that's
why
I
would
say,
like
you,
want
the
new
function
in
the
prometheus
exporter
to
not
essentially
like
expose
the
reader,
because
it
would
handle
reader
creation
with
appropriate.
You
know,
output
site,
but
also
handle
the
correct
wrapping
of
the
exporter
back
having
the
reader
back
integrated
with
the
exporter.
B
I
want
to
I
wanted.
Maybe
we
need
to
pause
on
this
one,
because
I
could
probably
talk
for
another
half
hour
on
this
one.
It
sounds
like
this
is
good
feedback.
I
could
probably
get
something
together
with
a
little
working
example
on
this,
but
I
want
to
be
conscious
of
everyone's
time
and
so
I'll
hit
everyone
up
on
flack
for
a
follow
up
on
this
and
we'll
see
everyone
next
week,
thanks
for
joining.