►
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
Yeah,
I
I'm
looking
forward
to
the
conversation
today.
I
think.
B
A
Yeah,
that's
like
what
you
know.
Writing
is
great
about.
It.
Just
really
makes
you
think
about
other
things.
Other
things
that
kind
of
guides
you
about,
like
you
know
what
you
should
be
thinking
and
so
on.
You
know
it's
it's
sometimes
hard,
because
you
sometimes
feel
distracted
by
those
thoughts,
but
it
is
great
to
just
capture,
like
you
know,
a
bigger,
I
think,
spectrum
when
you
write.
I
I
sometimes
write
for
myself
when
I'm
thinking
about
a
problem
and
it
helps.
A
A
A
B
B
But
three
more
minutes
see
if
michael
said,
he'd
join
morgan
is
unable
to
join.
Today
he
has.
He
has
an
overlapping
webinar
he's
giving.
B
Are
you
all
flying
to
l.a
after
I
go
home
for
a.
D
B
C
B
It's
good
to
see
everybody,
so
I
think
we
have
quorum
because
I
was
just
telling
the
group
morgan
won't
be
joining.
He
has
a
webinar
overlapping
this
that
he's
giving.
B
B
So
I'm
not
sure
how
how
to
go
about
it.
We
can
go
through
the
comments
on
the
dock,
for
whatever,
whatever
you,
whatever
you
think,
is
the
do.
A
A
Like
the
big
big
topics
so
make
sure
we
make
sure
that
they're
addressed.
B
Mm-Hmm
yeah,
so
I
mean.
C
There
was,
I
was
just
gonna,
say
that
obviously
there's
a
lot
of
debate
last
week,
I'm
stuck
so
we
can
probably
close
on
those
some
of
those
topics
as
well.
The
approach
to
like
naming
and
just
future
road
map
and
plans
and
stuff
like
that.
B
So
do
you
want
to
start
with
that?
I.
C
Mean
sure
I
mean
we
talked
about
it
last
week
a
bit
and
there
was
a
lot
going
on
in
the
dock.
It's
hard,
always
you
know
over,
like
you
know,
in
person
is
better
it's
easier.
You
get
to
see
people's
faces
and
kind
of
kind
of
communicate
a
little
bit
easier.
So
let
me
why
don't
I
kind
of
just
I
think
I
started
that
thread,
so
why
don't?
C
I
just
recap
kind
of
what
I
was
thinking
and
where
we
can
kind
of
discuss
where
the
discussion's
at
so
I
guess
my
kind
of
concern
is
that
we're
trying
to
get
so.
I
think
we
all
want
to
get
evpf
out
there
into
open
telemetry.
We
all
want
to
see
this
be
a
success.
C
There
is
a
question
of
like
how
we
provision
for
future
modules
to
come
in
there's,
obviously
pixie
datadog
cloudflare,
there's
a
whole
bunch,
there's
going
to
be
more
there's
going
to
be
tons
of
other
stuff
coming
down
the
pike
in
the
future
with
ebpf,
and
so
just
my
kind
of
the
way
that
the
doc
is
kind
of
written
to
me
seems
like
we're
saying:
okay,
this
is
going
to
be
the
evpf
open,
telemetry
ebpf
collector,
and
I
think
that
we
haven't
given
enough
thought
like
in
this
work
group,
and
I
think
we
should,
I
think,
it'd-
be
awesome
to
kind
of
collaborate
and
see
like
how
different
things
would
plug
into
each
other
and
define
an
interface
and
say
here's
our
roadmap
for
how
new
things
will
plug
in
right.
C
But
we
haven't
done
that
too
much
in
this
worker
right.
Just
honestly,
we
haven't
had
the
time
right.
We've
had
a
lot
of
good
stuff
in
this
work
group,
but
we
haven't
had
the
time
so
saying
that
we're
going
to
contribute
this
is
the
open,
telemetry
evpf.
This
particular
contribution
is
open.
Telemetry
ebpf,
I
think
to
me,
is
a
little
bit.
Jumping
the
gun,
I
think
I
think
we
want
to
say
that
we
want
to
be
the
open,
telemetry
evpf
group,
but
I
thought
from
a
kind
of
positioning
perspective.
C
E
E
A
Is
is:
is
that
a
fair
thing
to
do
johnson?
Like
you
know,
you
know
using
this
component,
we
will
use
it.
You
know
as
a
starting
exercise.
You
know
we
will
figure
out
the
right,
abstractions
and
so
on
as
a
part
of
the
working
group.
E
A
C
I
think
we
want
to
start
exactly.
We
want
to
stress
the
modularity
and
that
we
haven't
figured
out
the
interfaces
and
what
the
module
interfaces
are
going
to
be,
but
today
we're
contributing
open,
telemetry
evpf,
which
is
part
of
the
open,
telemetry
open,
telemetry,
evp
npm,
which
is
part
of
the
open,
telemetry
ebpf
family.
D
C
D
C
You
can
okay,
you
can,
but
I
think
there
is
still
a
case
to
be
made.
We,
I
completely
agree
with
kind
of
the
comments.
C
To
you
know
fragment
the
space
right.
I
think
I
think
it
is
the
right
vision
to
say:
let's
have
one,
let
us,
as
the
work
group,
be
the
leaders
in
this
space,
but
I'll
just
give
you
from
an
example
of
like
like
inside
pixie
itself.
C
But
these
things
are
kind
of
pluggable
modules
and
we've
thought
about
like
how
we
can
there's
context
that
can
be
shared
across
the
different
modules
and
I
think
jonathan,
you
guys
are
doing
the
same
thing.
There's
a
context
or
some
kind
of
metadata,
that's
kind
of
uniform
to
everyone
and
then,
but
you
can
have
these
plugable
modules
that
you
stick
in,
and
so
you
have
this
extensible
architecture,
and
today
inside
pixie
we
actually
have
four
different
ebpf
modules
that
we
plug
in
to
do
four
completely
different
functionalities
right.
C
So
I'm
kind
of
saying
we
could
and
it
doesn't
have
to
be
the
pixie
way,
but
I
think
we
should
hack
it
out
in
this
work
group
right
and
find
the
common
like
hey
get
the
best
of
what
flomill's
doing
performance
practice
is
the
best
of
what
pixi's
doing
kind
of
get
all
these
ideas
together.
Obviously
we're
not
going
to
solve
that
today,
but
what
we
could
do
is
at
least
set
out
that
vision
and
say:
hey.
We
do
plan
to
do
a
modular
architecture.
C
E
B
If
I
can
chime
in
omid,
I
think
that
I
I
would
love
to
have
you
know
this.
I
think
we
share
the
vision
of
of
the
modular
modular
implementation.
Where
you
have
different.
You
know
you
know.
Collectors
plug
in
the
thing
is
that
the
you
know
this
contribution
already
has
a
lot
of
that
componentry,
and
so
I'm
I'm
worried
we're
kind
of
we're
going
to
to
you
know
box
it
into.
B
We
need
to
eliminate
all
of
that
framework,
and
you
know-
and
you
know
we're
starting
off
from
a
point
where
you
know
this.
This
discussion
is
not
you
know
getting
to.
B
You
know
the
in
some
sense.
If
we
want
to
create
a
space
to
innovate,
let's
I
think
we
would
be
better
served
by
creating
this.
This.
You
know
code
base
that
we
can
innovate
on
and
we
can
add
components,
remove
components
to
it.
But,
having
like
communicating
to
the
community
that
we
only
have
an
npm
product
kind
of
would
discourage
other
contributions
to
evpf,
and
it
kind
of
would
hurt
our
work
group
to
to
limit
what
we
do.
B
It
is
broader,
so,
even
today
the
so.
This
is
what
we
can.
We
haven't
highlighted
as
much,
but
it
has
a
module
to
collect
container
information.
So
you
get
every
time
a
container
starts
and
stops
you
get
a
notification
and
you
get
a
trigger,
for
you
know
to
get
data
from
docker
metadata,
it
fetches
metadata
from
docker
and
then
issues
that
so
you
can
have
an
online.
B
If
you
want
to
do
auditing
of
your
containers,
you
can
get
like
logs
of
all
the
containers,
starting
and
stopping
all
the
processes
that
start
and
stop
inside
containers.
You
can
say:
okay,
this
process
started
in
that
container,
and
so
you
can
do
auditing
of.
Why
is
this
ssh
running
inside
my
web
server,
so
kind
of
there's
all
already
kind
of
cpu
memory
and
io
instrumentation,
where
you
can
get
kind
of
page
faults,
kind
of
cpu
kind
of
having
your
process
be
scheduled
by
the
operating
system?
B
C
Pixi
has
something
similar,
so
it
resonates
with
me
and
then
there's
kind
of
functionalities
that
can
plug
in,
and
today
we
have
npm,
which
is
the
end
thing
that
we
really
export
out,
which
is
the
kind
of
probably
the
most
important
part
that
we're
exporting
out
in
this
contribution
right.
But
so
how
can
we
walk
this
line?
How
can
we
kind
of
because
it's
also
like
we?
How
can
we
say
that
this
should
be
the
framework
to
use?
Well,
we
haven't
compared
it
to
like
others,
what
the
interfaces.
C
They
kind
of
mesh
or
not
right.
I
think
what
we
should
have
in
hindsight.
What
we
probably
should
have
done
is
kind
of
spend
a
little
bit
of
time.
Looking
at
like
architecture
diagrams
of
like
I
would,
I
would
know
pixie.
So
I
could
like
help
on
that
side,
but
maybe
there's
other
ones
as
well.
Try
to
bring
in
as
many
and
say
what
are
those
common
set
of
kind
of
things
that
they
all
do
and
what
I.
C
Sorry,
so
sorry,
so
coming
back,
so
it's
like,
ideally
that
would
have
been
the
process.
It's
like
we
kind
of
look
at
these
things.
So
I'm
trying
to
do
this
compromise.
Where
I'm
saying
let's,
I
know
you
want
a
mess,
you
want
to
be
able
to
kick
this
off
and
I'm
totally
with
that.
We
want
to
kick
this
off
in
kubecon
right
and
say
we
have
an
ebpf,
open,
telemetry,
evpf
work
group.
That's
a
statement
I
think
we
can
conclusively
make.
C
I
think
we
can
also
say,
and
today
we
have
a
module,
that's
doing
the
npm
stuff.
That
I
think
is
also
thing,
and
you
know
you
guys
can
say
and
flo
mills
contributed
this
and
you
know
it's
the
leader,
the
first
one
to
do
this.
That's
that's
awesome
as
well,
but
I
don't
want
to
kind
of
box
everything
else
in
to
saying
like
now
like,
because
we
didn't
have
the
foresight
to
discuss
what
the
interfaces
and
everything
are
it's
like.
C
How
do
we
kind
of
fit
other
things
into
here
when
we
haven't
even
looked
at
it
right?
That's
my
concern
is,
is
how
can
we
jump
to
that
conclusion?
Without
having
looked
at
everything,
maybe
it's
found
like,
maybe
we
look
at
it
and
we're
like
yep.
This
looks
fantastic
like
this
is
great.
This
is
the
modular
system
that
we
wanted
and
it's
got
everything
we
need,
and
it's
just
we're
gonna
this
is
it
we've
decided
as
a
work
group,
but
we
haven't
discussed
it.
C
So
how
can
we
say
that
right
and
in
my
pr
in
my
experience
with
working
on
big
projects,
is
there
are
trade-offs
right
and
there
are
like
you,
take
two
different
projects
that
do
the
same
thing
and
there's
like
oh
wow.
There's
really
good
aspects
of
this
one,
there's
really
good
aspects
of
that
one,
but
we
haven't
really
discussed
any
of
that
stuff
right.
A
E
A
A
C
I
don't
want
to
without
having
seen
what
flowmill
has
inside
of
it,
it's
very
hard
for
me
to
come
and
say
yes,
I
agree
to
this
contract
of
this
is
what
interface
we
will
you
know
interface
into
without
having
discussed
it
in
the
work
group
right.
That's
just
not
fair
right
right,
like
I
said,
if
we
look
at
it
together
as
a
team-
and
we
say
yes,
this
looks
fantastic
or
only
a
few
small
tweaks
in
here,
I'm
totally
in
right.
But
let's
look
at
it.
C
Let's
look
at
it
together
as
a
team
right
and
and
come
to
that
conclusion
before
jumping
to
the
you
know,
just
saying
in
the
doc
that
this
is
going
to
be
the
open,
telemetry
evpf
collector,
and
this
is
going
to
be
the
framework
and
everything
else
is
going
to
have
to
plug
into
this.
B
I
think
so
what
you
know
after
your
comments,
what
the
document
said.
I
think
what
the
document
says
right
now
is
that
we're
you
know
we
want
to
start
with
something
we
haven't
made.
The
decision
that
you
know
this
framework
or
that
framework
is
going
to
be
the
framework,
but
we
want
to
start
with
a
repository
and
we're
going
to
switch
out
components
we're
going
to
switch
out
infrastructure.
We
might
even
you
know,
move
the
this
entire
contribution
to
another
subfolder
and
bring
in
another
subfolder
and
hang
it
under
right.
B
So
you
know
the
we
are,
I
think
the
position
and
it
was
partly
kind
of
your
request
right
like
not
not
mandating
like
this
single
framework,
and
I
think
we've
we've
done
that
the
question
is:
do
we
you
know
can,
can
we
can
we
start
off
with
something
rather
than
say
that
we
don't
know,
don't
know
anything
right
and
kind
of
I'm
worried
we'll
go
into
this?
You
know
paralysis,
mode
and
then
we'll
end
up
in
this
state,
where
we
only
have
an
npm
module.
C
Yeah,
I
I
don't.
I
don't
think
we
should
do
the
parallel
paralysis
thing
like
I'm
not
trying
to
block
this.
I
think
we
should
try
to
get
it
out
asap
right,
so
it's
just
kind
of,
and
maybe
maybe
what
it
comes
down
to.
So
what
you're
just
saying
in
words,
I'm
not
seeing
in
the
doc
as
clearly
like
you're
saying
yes,
we
want
to
have
a
framework
and
we
want
to
experiment
with
it
and
it's
very
like
fluid
and
kind
of
dynamic
at
this
point
versus
the
docs.
C
The
way
that
it's
written
is
much
more
kind
of,
I
think,
especially
the
beginning
parts
of
the
doc
is
like
very
kind
of
more
it's
not
to
me
communicating
that
as
much
it
seems
to
be
more
like
we
will
contribute
the
flow
collector
as
the
open
telemetry
ebpf
collector
that
that's
a
mixed
message
to
me
there
right,
but
maybe
what
would
help
out
as
a
diagram
kind
of
to
kind
of
set
something
up,
but
but
michael
would
go
ahead.
You
had
a
comment
yeah.
E
I
was
just
going
to
say
the
section
d
has
a
lot
of
good
writing
in
it,
and
maybe
we
should
just
move
a
lot
of
that
to
the
preamble
that
says
what
we're
contributing
here
is.
What's
going
to
be
part
of
a
ebpf
plugable
platform,
this
part
will
do
npm
and
we're
contributing
this
for
now,
but
but
what
it
is
functionally
if
not
at
present
is
the
plugable
part
to
something
that
we're
committing
to
for
the
future
right.
C
Yeah,
I
think
that
would
I
think
that
would
pretty
much
address
it
right.
I'm
not
asking
for
like
widespread
changes
to
the
document.
A
C
Just
want
like,
let's
set
it
up
very
clear
at
the
very
beginning
that
this
is
a
framework.
This
fruit
contribution
is
the
first
step
in
that,
but
it's
very
fluid
and
we
do
plan
to
improve
modularity
of
this
thing
and
we
do
need
to
hash
out
a
bunch
of
details
like
yeah,
and
I
agree
with
that.
That's
great.
A
B
A
Introduction
should
be,
you
know,
captured
that
like
introduction
reads
like
you
know,
this
is
about
networking.
It
briefly
mentions
other
things,
but
then
it
just
kind
of
fixated
on
like
networking
a
lot
that
it
sounds
like
you
know.
This
is
the
only
use
case
that
we
think
about.
It.
Kind
of
you
know
give
the
wrong
impression.
C
E
One
of
the
scary
things
a
little
bit
lightly.
I
guess
is
that
by
contributing
this
as
the
first
component
without
the
modularity,
it
sort
of
forces
it
onto
the
second
person
who
comes
along
to
build
that
abstraction
layer
and
then
make
it
pluggable
for
this
and
then
plug
their
own
thing
into
it.
So
just
asserting
that
this
is
part
of
that
plan
and
that
we
are
doing
that
and
we're
not
just
like
pushing
it
on
to
whoever
whatever
schmuck
comes
next
is,
I
think,
going
to
help.
B
So
is
this
so
there's
I
can
you
help
with
kind
of
concrete
edits
to
to
this,
so
that
we
can
make
it?
You
know
I'm
trying
to
as
long
as
we
have
everybody
on
board
they're,
so
the
the
idea,
so
I
just
moved
like
topic
d
to
like
introduction.
B
What
is
the
mandate
of
the
group
and
I'll
edit
it
to
to
make
it
fit
like
as
introduction
and
not
like
after
everything
else,
but
right
now,
the
way
it's
phrased
is
we've
decided
not
to
commit
to
flowmel
as
the
framework
and
we'll
bring
in
more
frame.
You
know
more
code
as
we
need
to,
but
if
you
want
to
make,
if
you
want
to
make
an
assertion
that
the
goal
is
is
a
unified
framework,
then
we
can
edit
that
in.
C
It's
here's
I
think
moving
it
up
is
a
good
idea.
So
why
don't?
If
you
want,
I
can
I
I
actually
think
diagrams
really
help
a
lot,
so
I
will
volunteer
to
put
together
an
initial
draft
of
a
diagram
that
kind
of
sets
up
the
vision
and
share
it
with
all
you
all
of
you.
C
I
can
do
that
pretty
quickly
and
then
we
can
iterate
on
that
right,
but
maybe
that
diagram
can
capture
what
we
kind
of
think
of
as
a
future
vision,
and
that
might
help
a
lot
and
then
we
don't
have
to
work
on
the
text
as
much
because
it'll
kind
of
fall
out
from
the
diagram
is
that,
and
I
can
work
on
that
right
after
this
meeting.
If
because
I
know
you
so
what's
the
time,
what's
the
timeline,
what's
the
what's
the
deadline
for
getting
this
thing.
C
B
A
C
I
I
will
volunteer
to
to
put
together
that
diagram
and
work
on
it
right
away,
so
I'll
probably
say
we're
kind
of
right
away
so
that
we're
we're
not
delaying
this
right.
I
understand
time
is
sensitive
and
let
me
put
it
into
the
document
and
then
we
can
kind
of
iterate
through
it
from
there,
and
you
can
provide
feedback
through
comments
and
stuff,
but
I
can
commit
to
that.
If
that
helps.
B
Thank
you
thanks
yeah,
and
I'm
I'm
here
for
this
all
day
tomorrow
too,
so
the
my
question
to
the
group
is,
I
know,
we're
kind
of
you
know
heading
towards
the
end
of
the
of
the
slot,
but
do
we
need
to
make
a
single
frame
so
are
we
taking
on
too
big
of
a
project
by
you
know
trying
to
decide?
B
You
know
a
single
framework
for
every
collector?
Is
there
a
case
to
be
made
that
you
know
profiling
might
need
a
different
code?
You
know
it
might
fit
into
the
same
code
base
but
might
fit
into
a
different
code
base,
or
you
know
if
you
want
to
do
syscall
logging,
does
it
fit
into
this
or
that
right
do
we
need
to
have
us
to
make
a
decision
that
we're
going
to
go
with
a
single
framework.
I
was
hoping
we
wouldn't
kind
of
make
it
more.
B
You
know
that
we
would
encourage
contribution
to
to
use
the
framework,
because,
there's,
I
think
in
you
know
personal
opinion.
Having
worked
on
the
flomo
code
base,
it
is
very
hyper.
You
know
it
does
what
it
does
extremely
well
like
you
can
argue
kind
of.
There
are
downsides
to
everything,
but
it
does
what
it
needs
to
do
very
well,
and
so
the
question
is:
do
we
even
need
to
mandate?
You
know
a
single
platform
or
you
know
open
telemetry.
Is
this
it?
B
C
C
My
only
thing
on
that
one
then
would
be
is
if
we
don't
want
to
kind
of
do
that,
then
calling
this
one
open,
telemetry
ebpf,
makes
no
sense,
because
the
next
thing
that
comes
it's
also
ebpf
based
it's
it's
just
going
to
get
confusing.
It's
like
well,
there's,
seven
or
let's
say:
there's
five
different,
like
ebpf
collectors,
only
one
of
them
is
called
the
open,
telemetry
evpf
right.
C
A
Can
I
add
one
more
thing
on
the
collector,
you
know
the
abstractions
are
very
simple:
you
have
an
input
and
an
output
for
a
component,
but
then
there
are
a
lot
of
like
utilities.
So
not
each.
You
know
component
maintainer
need
to
write
everything
from
scratch.
It's
not
a
framework
like
not
like
an
abstraction
you
fit
into
yourself
into,
but
there's
a
lot
of
reusability
of
things.
A
Maybe
that
could
be
an
approach
that
we
can
take
for
this
project
as
well,
but
I
think
this
meeting
is
we
don't
have
time
to
discuss
it
right
now.
That's
why
you
know
we
need
to
put
it
in
the
dock
that
we
need.
We
will
discuss
and
figure
out
the
right.
You
know
approach.
C
C
E
B
Sound
diagrams
I'm
worried
that
we're
I'm
a
bit
worried
that
we
we're
we've
done
that
we've
discussed
you
know.
We've
we've
gone
through
a
discussion,
so
we're
not
at
the
same
place,
but
we
haven't
made
this
like.
Have
we
made
a
decision
on
naming?
I
don't
feel
like.
We
have.
E
I
mean,
I
think,
there's
a
fork
right
where
the
naming
depends
on
the
architecture.
If
it's
a
common
ebpf
component
that
happens
to
run
an
npm
collector,
contributed
by
flowmill,
then
it's
an
ebpf
thing
and
if
it's
a
network
collector
that
lives
on
its
own,
then
it
needs
to
be
renamed,
but
making
one
decision
will
make
the
other
there's
only
one
decision
here
right
between
the
two.
B
I
would
argue
that
we
don't
have
to
make
the
decision
right
now
and
it
you
know
if
there
would
be
a
I,
in
my
opinion,
though,
even
if
we
choose
to
go
the
path
of
enabling
multiple
frameworks,
there
would
be
a
convergence
to
one
or
two
or
three
right
like
pixie
might
be
one
of
them.
Floma
might
be
one
of
them
or
not
right,
but
I
think
it
it
would
just
because
it
takes
so
much
effort
of
building
one
of
these.
It's
like
building
a
new
database.
B
So
if
we
need
to
rename
and
say
like
you
know,
it
is,
is
the
renaming
that
we
have
one
framework
for
c
plus
and
one
for
golang?
Is
it
that
we
have
one
for
always
on
and
one
for
on
demand
right,
we'd
be
able
to
make
this
decision
later.
I'd
argue,
I
think.
C
C
C
Who
works
on
like
who's,
making
the
announcement
who's
working
on
the
messaging.
B
The
the
announcement
is
is
not
so,
I
think
the
the
pr
package
for
kubecon
has
that
kind
of
there
is
a
contribution
in
npm
to
open
telemetry
that
splunk
made,
but
it
doesn't
go
into
naming
or
make
a
decision.
You
know
go
into
that
in
any
detail,
so
it's
we.
We
deliberately
like
kept
it
that
way,
because
I.
B
C
Important
for
the
kubecon
announcement,
you
can
still
go
ahead
with
the
of
announcement
without
figuring
out
this
last
detail.
Right.
A
Another
thing,
unfortunately,
thank
you,
okay,.