►
From YouTube: 2021-09-02 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
B
Good,
I
missed
this
meeting
like
last
week.
Again
there
are
a
couple
of
fires.
Sorry
for
that
that
happens.
A
Are
the
fires
out,
it's
still
sort.
B
A
B
Yeah,
do
you
are
you?
Are
you
going
to
kubecon
or
planning
to
like
virtually
do
it.
A
B
A
evpf
summit
I
think
the
day
before
so
it's
like
psyllium
folks,
like
thomas
graph,
it's
like
the
guy
who's
like
organizing
it
like.
If
you
are
coming
or
wanna,
you
know
join
virtually
there
might
be
like
I
I
don't
know.
I
don't
have
the
details,
but
I
can
dislike
you.
A
Yeah
I
might
reach
out
to
thomas,
then
I
I
gave
a
lightning
talk
at
the
epf
summit.
So
there's
a
five
minute
talk
on
what
what's
hard
about
the
collector.
What.
A
Oh
yeah,
it
was
on
the
networking
session
instead
of
in
the
observability
session.
Just
that's
where
it
landed
yeah,
we
added
some
measurements,
so
we
had
some
production
workloads
and
we
looked
at
the
number
of
data
points
you
get
per
container
and
number
of
data
points
you
get
per
per
socket.
So
you
have
these
socket
data
points
and
there
are
we
measured.
I
think
it
was.
A
Yeah,
that's
the
ratio,
and
then
I
think
that
was
the
number.
It
was
hundreds
of
thousands,
so
I
can
pull
it
up
if
you
want.
A
B
There's
there
must
be
a
recording,
it
was
kind
of,
like
all,
I
think,
recorded
yep.
C
Well,
yeah,
I
live
in
south
florida
in
a
town
called
pompano
beach.
It's
near
miami!
B
Okay,
maybe
we
can
begin,
I
guess
no
one
else
is
coming.
A
It's
gonna,
I
think
you
and
michael,
are
kind
of
not
overlapping
a
lot.
You
know
fast
couple
weeks.
A
So
you
know
that
you
proposed
two
weeks
ago
kind
of
a
list
of
topics
to
that
we'd
need
to
cover
before
accepting
the
contribution-
and
we
talked
about
this
with
with
michael
as
well
and
morgan
last
week,
and
I
think
that
list
is
fine.
So
we
can.
We
can
go
over
that.
One
of
the
action
items
I
had
from
that
list
was
to
understand
how
enrichment
works
for
containers.
A
The
concern
was:
is
there
going
to
be
a
lot
of
duplicated
code
and
therefore
duplicated
effort
between
kind
of
open,
telemetry,
the
the
go
side
of
the
collector
and
the
ebpf
collector
and
c-plus
plus
code?
And
so
I
I
did
a
survey
of
of
the
processors
in
open,
telemetry
and
open
telemetry
contrib
to
see
what
metadata
could
be
used
for
for
enriching,
telemetry,
so
kind
of
what?
What
what
functionality
can
we
elide
from
the
current
flowmo
collector
in
the
contribution?
So
we
can
talk
about
that
too.
That.
B
Would
be
very
useful
because
I
was
not
quite
sure
if
there's
actually
anything
in
the
current
processors,
the
current
processors
still
like
some
like
resource
resource
detection
but
like
they
detect
where
the
collector
is
running
in
so
I
was
wondering,
like
you
know,
for
a
ip,
for
example,
came
with
you
like.
Is
there
any
processor
that
does
like?
You
know,
reverse
lookups
and
like
figures
out
what
it
is,
hi
hi,
morgan.
D
Hey
sorry,
I
was
recording
a
conference
talk
but
wrapped
up
early.
B
A
Cool
so
so,
let's
talk
about
enrichment,
sorry,
morgan
I'll
I'll
fill
you
in
just
like
we're
talking
about
kind
of
the
duplicated
code,
kind
of
enrichment
code
between
open
telemetry,
collector
and
and
the
current
ebpf
collector
proposal.
The
flow
multiple
collector
what's
duplicated.
So
what
I
found
is
that
there
are.
There
were
two
processors
that
do
enrichment
and-
and
I
I
want
to
first
kind
of
recognize
my
my
own
experience.
A
It's
not
like
I've
been
writing
the
processor
code
for
many
years,
and
I've
just
went
in
and
read
read
what
what
I
was
able
to
find
right.
So
it's
like
all
kind
of
if
there's
a
magic
third
repository.
I
don't
know
of
that,
does
magic.
I'm
just
I
haven't
seen
that,
but
I
did
look
at
the
open
telemetry
now.
A
So
there
to
the
kate's
processor,
what
that
does
is
it
looks
at
the
ip
addresses
where
telemetry
is
coming
from
on
resources,
so
they're
gonna,
I
think
the
topology
is
you:
have
you
have
the
source
of
telemetry
connecting
to
a
receiver?
The
receiver
then
knows
the
ip
address
of
the
the
source
of
telemetry,
the
and
using
that
ip
address.
A
The
kate's
processor
looks
up
that
ip
in
the
with
the
kubernetes
api
to
get
the
pod
name
and
then
enriches
kubernetes
can
pod
name
into
the
resource.
So
that's.
B
Cool,
so
it's
is
it
like
at
the
otlp
receiver
like
level
like
it
automatically
like,
can
annotate
the
incoming
ip
and
then
like
the
processor,
can
use
it
to
just
do
the
you
know,
reverse
lookup
and
figure
out.
A
As
far
as
I
understood
it,
so
I
haven't
experimented
with
it
as
far
as
I
could
read
from
the
code
and
from
the
the
the
readme
documentation.
Yes,
that's
the
idea.
It
actually
has
two
topologies
in
one
topologies.
It
does
there's
a,
I
think
they
call
it
the
agent
and
the
collector
mode.
I
don't
know
I
don't
remember,
which
is
which
but
jonah
you're
you're
nodding.
So
I.
C
A
So
the
two
modes
are
either
you
run
it
next
to
the
next
to
the
collector
shipping,
sorry,
the
the
telemetry
source,
and
then
you
do
the
mapping
on
that
node
and
the
other
one.
Is
this
pass-through
mode
where
it
make?
If
you
have
a
centralized
collector
that
where,
where
telemetry
from
multiple
data
sources
are
flowing
through
kind
of
that
consolidates
telemetry
collection
from
multiple
other,
oh,
I
think
maybe
hotel
collectors.
A
So
if
you
have
a
two-tier
architecture,
you
can
run
the
case
processor
in
a
way
that
tunnels
for
lack
of
better
word
tunnels
that
ip
address
data,
so
that
a
centralized
collector
could
then
do
the
enrichment,
so
that
collector
can
then
get
information
about
all
the
pods
in
the
system,
not
just
the
ip
of
the,
not
just
the
pods
running
on
a
node.
So
it
has
these.
As
far
as
I
understand
it
has
two
modes:
either
you
run
it
on
a
node
and
then
you
filter
it.
A
B
Cluster
and
the
idea
is
like
you
know,
you
can
cache
more
aggressively,
so
you
don't
have
to
do
the
lookups.
A
Yeah
so
that
could
be
used
to
enrich
telemetry
from
coming
from
the
collector
right.
So
if
we,
if,
if
the
flowmill
collector
the
evpf
collector
packs
the
the
telemetry
kind
of
the
the
flow
data
coming
out
of
each
container
into
a
resource
in
the
same
format
as
the
case
collector
expects,
then
you
we
could
use
the
case
collector
directly
in
order
to
enrich.
B
But
isn't
it
like
slightly
different
because
kate's
collector
is
looking
at
the
resource,
the
ip
like
where,
where
actual
telemetry
is
collected
flow?
What
the
you
know,
the
data
like
the
ebpf
stuff
is
going
to
collect,
is,
like
you
know,
source
and
you
know
destination
ip
and
we
want
to
be
able
to.
I
mean
we
will
just
reuse
some
of
the
code,
but
you
know
we
can't
use
it
as
it
is,
but
there
is
at
least
some
stuff
that
we
can
reuse.
A
Yeah,
what
the.
A
What
the
conflomo
collectors
do
for
kubernetes
is
they
subscribe
to
all
of
the
pod
updates?
Actually,
all
of
the
yes
all
of
the
pod
updates,
and
so
you
get
in
your
back
and
you
get
a
stream
of
all
the
updates.
You
know
this
pod
arrived
this
pod
finished,
the
spot
arrived,
the
spot,
finished
and
and
kind
of
it
allows
you
to
do
this
enrichment
on
both
sides
of
both
the
source
and
destination
right.
A
A
B
I
think
that's
where
we
should
start
regardless,
that's
the
easier
optional,
so
we
can
always
mandate
people
to
use
the
collector.
Maybe
it's
topologically
a
bit
more
complicated,
but
that's
where
we
should
be
starting.
Trying
to
you
know
we
do
all
these
things
in
the
c
plus
plus
code.
It's
just
gonna
also
take
a
long
time
to
implement
and
so
on.
So
you
know
that
that
shouldn't
be.
You
know
in
our
short
term
roadmap.
A
Yeah
so
kind
of
an
an
idea,
and
I
think
I
wrote
it
in
that
in
that
document
and
it's
linked
from
the
meeting
notes.
The
the
proposal
is
to
really
pack
with
the
flowmo
collector.
It
know
kind
of
it
collects
the
container
for
every
socket.
So
it
knows
for
every
socket
what
container
it
was
in.
So
it
could
associate
the
pod
ip
with
that
container
and
then
for
every
tele,
every
piece
of
socket
the
telemetry
that
it
sends
out
pack
it
with
the
the
pod
ip.
A
Awesome
so
so
I
think
the
other
piece
I
I
found
that
open
telemetry
does
really
well.
So
I
didn't
find
what
I
didn't
find
was
other
container
data
sources
or
for
container
metadata,
so
docker
swarm,
nomad
ecs.
A
A
So
what
that
does?
Is
it
basically
collects
information
about
the
kind
of
host
and
the
environment?
So
you
know
it
has.
For
the
three
major
kubernetes
manage
manage
kubernetes
clusters,
google,
google,
aws
and
and
azure
it
collects
the
cluster
name
and
kind
of
the
name
of
the
node.
It
has
a.
I
prefer
ecs.
I
think
lambda
too,
so.
B
A
B
There's
a
bunch
of
other
things,
it's
it's
more
about
the
host.
I
was
wondering
like
if
we
can
kind
of
like
come
up
with
something
very
similar.
You
know
it
has
this
like
driver
abstraction,
so
you
can
write.
You
know
multiple
implementations,
so
I
think
my
question
would
be:
should
we
be
using
like
kate's
processor
or
should
we
build
something
else,
because
we
may
you
know
just
build
all
these
like
different
implementations.
Also,
it's
gonna
do
something
like
not
quite
the
same.
B
B
At
the
same
time,
so
I
think
you
know
we
can
reuse
a
lot
of
bits
from
the
gates
for
the
kate's
processor
to
implement
the
kubernetes
support.
But
it
would
be
nice
to
be
able
to.
You
know,
extend
it.
A
B
An
abstraction
I
don't
want
to
complicate
too
many
things
but
like
if
people
ask
for,
like
you
know,
running
this
on
acs
and
like
automatically
being
able
to
you,
know
just
discover
what
is
source
and
destination
it
would
be
nice
to.
You
know,
have
this
like
abstract
model,
where
you
can
like
implement
based
on
platform.
B
Let's
say
that,
like
I'm,
going
to
run
the
reci
the
agent,
the
collector
on
acs
as
a
sidecar,
and
I'm
going
to
be,
like
you
know,
collecting
network
data
through
the
ebpf
agent
we're
working
on,
I
can
configure
the
collector,
so
it
can
actually
like
discover
what
ecs
tasks
it's
talking
to.
So
it's
not
like
it.
Wouldn't
just
you
know,
export
data
with
ip
addresses
and
can
like
do
the
you
know
the
enhancement.
B
B
That
that
might
determine
us
to
reuse
the
kate's
processor
versus
actually
creating
a
new
processor.
I
think
that's.
That
was
the
context
of
my
question,
like
I
think,
if
we
can
create
a
new
one,
we
can
create
some
of
those
abstractions,
because
kate's
processor
is
very,
you
know,
specific
specifically.
B
But
it
could
be
a
long-term
thing.
Also,
you
know,
let's
start
with
kubernetes,
and
then
we
can
extend.
Introduce
introducing
new
processors.
Later
is
also
fine.
D
D
So
I
have
a
question
so
what
else
like
we?
We
created
this
cig
to
talk
about
this,
this
group,
to
talk
about
how
we
wanted
to
pull
this
donation
into
hotel?
What
other
questions
are
blocking
that.
B
We
had
like
couple
of
others
like
do
you
remember
the
high
level
like
in
the
dock?
There's
this,
like
I
mean
I,
I
proposed
some
of
the
high
level
items.
One
of
them
was
resolving
metadata.
The
other
one
was
like
separate
process
or
you
know
making
it
a
part
of
the
collector
by
turning
it
into
a
receiver.
We
decided
to
start
with
the
separate
processor
right
like
we
also
have
consensus
on
that.
B
The
other
topic
was
whether
we
want
to,
like
you
know,
do
any
aggregations
in
the
in
the
open,
telemetry
collector
to
turn
these
events
into
like
metrics
or
anything
we
can
discuss
about
that,
and
it
could
be
like
a
long-term
thing
and
it
will
be
a
long-term
thing
because
it's
a
complicated
topic,
but
this
will
make
us
decide
whether
we
want
to
make
the
the
flow
of
male
spec
a
part
of
the
open,
telemetry
spec
or
we're
just
going
to
be.
B
A
So
yeah
not
to
summarize
so
I
think
kind
of
do
you
think.
B
Do
you
remember
the
topic
like
I
remember.
A
We
took
good
notes,
which
is
I'm
thankful
for,
thank
you
and
I
think,
morgan,
you,
you
helped
too
so
the
the
so
yes,
those
were
our
three
or
four
things
so
kind
of,
and
I
think
by
now
kind
of
we
understand
kind
of
metadata
resolution
and
and
how
to
run
the
collector
initially.
B
A
B
Ebpf
agent
is
going
to
produce
and
it's
it's
kind
of
like
you
know
we
may
want
to
document
it,
so
people
can
consume
the
you
know
the
logs
to
just
whatever
generate
whatever
they
want
to
do,
but
if
you
kind
of
like
you
know,
can
contribute
some
code
to
generate
some
metrics
out
of
them,
which
is
the
hard
part
we
don't
even
have
to
do
the
you
know
we
don't
have.
B
We
may
not
really
have
to,
like
you
know,
document
the
flow
spec,
especially
if
maybe
like
it's
good,
not
to
do
it
for
now,
until
we
agree
on
the
spec
and
so
on,
maybe
keeping
it
more
of
like
an
internal
thing.
I
don't
know
this
is
my
opinion
by
the
way.
I
just
don't.
You
know
it's
just
my
personal
opinion,
I'm
curious.
Actually,
what
you're
thinking.
C
I'm
I
haven't
attended
a
meeting,
so
I'm
mostly
reading
listening
and
catching
up
on
what's
been
going
on.
C
D
It's
it's
it's
basically
I
mean
that
the
early
debate
for
context
jonah,
that
probably
isn't
this
probably
isn't
captured
in
the
docs
as
well
as
was
do
we
want
to
bring
this
in
and
make
it
like
the
home
of
all
things
ebpf
in
the
collector,
or
do
we
bring
it
in
to
say
here's
a
great
source
of
network
telemetry
that
happens
to
use
eppf,
but
but
like
ignore
that
that's
just
like
the
implementation
of
it.
D
D
D
B
I'm
I'm
involved
they're
also
doing
an
open,
telemetry
exporter
support,
so
they
already
aggregate
the
data
to
turn
them
into
metrics
and
some
other
formats,
and
they
will
be
talking
all
tlp
and
they're
kind
of
like
thinking
about
you
know
on
on
their
dashboard.
You
will
be
able
to
go
and
like
configure,
hey
export,
my
data
to
this
like
open,
telemetry
endpoint,
and
they
will
be
you
know,
exporting
that
data
in
otlp
format.
B
So
that's
what
they've
been
working
on
open
sourcing,
the
project
kind
of
like
made
it
I
think
they've
been
working
on,
like
you
know,
making
it
a
part
of
cncf
and
so
on
so
like
they
will
be.
I
think
announcing.
Some
of
these
integrations
soon.
C
C
B
There's
there's
there's
one
contributor
from
pixie
he's
not
here
today,
but.
B
Yeah,
the
scope
is
much
higher,
also
like
they
generate,
like
you,
know,
profiles
and
other
things
which
open
telemetry
doesn't
have
any
support
for.
So
you
know,
I
think
these
approaches
are,
I
mean
open,
telemetry
and
pixel
is
very
orthogonal
in
some
sense,
but
they
want
to
be
able
to
at
least
like
you
know,
export
the
data
in
that,
for
you
know
in
open
telemetry
format,
so
you
can
take
it
wherever
you
want,
because
pixel
doesn't
have
a
you
know:
storage
or
retention
story.
At
this
point.
C
D
Yeah,
okay,
so
so
going
back
to
like
what
we
need
to
close
on,
so
it
sounds
like
there's.
Basically
one
topic
left.
We
only
five
minutes
left
today,
but
I
assume
like
next
call.
Hopefully
we
get
michael
from
dynasty
from
datadog
buckets
he's
been
super
helpful
as
well,
and
I
mean
like
I
I'm
just
basically
looking
for
a
path
to
basic
closing
on
on
getting
the
donation
in,
so
I
it's,
he
seemed
very
pretty
supposed
to
just
bring
it
in.
So
I
assume
probably
next
week
of
the
following
week.
D
If
we
manage
to
have
michael
janna
jonathan
on
the
call,
we
can
probably
close
up
on
all
the
sort
of
the
initial
purpose
of
this
group.
The
initial
investigation
bring
in
the
code
and
then
start
working
on
it.
B
So
what
are
they
expecting
in
terms
of
like
artifacts
like?
Are
they
expecting
a
road
map
in
in
the
beginning,
or
is
it
more
of
like
you
know
you
bring
all
the
actual
contributions?
Like
start,
you
know
contributing.
B
So
where
are
we
in
the
state
of
like,
I
think
acceptance
like?
Are
they
still
expecting
to
see
some
sort
of
like
you
know,
this
is
the
road
map
or
sort
of
like
the
long-term
plan?
Yes,.
D
D
I
I
think
at
least
a
medium
term
plan,
not
maybe
perhaps
not
long
but
like
what
the
tc
I
think
was
looking
for
was
like
first
off
just
having
people
who
don't
work
at
splunk,
saying
that
they
would
like
this
to
come
into
the
project,
probably
more
than
anything,
because
initially
it
was
like
myself
and
jonathan
a
few
others
and
and
their
feedback
was
totally
understandable,
they're
basically
like
yeah.
D
This
looks
great,
but
we
want
like
to
know
that
literally
one
at
least
one
other
company
likes
this,
and
I
think
yeah,
and
particularly
with
yourself
and
and
the
folks
at
datadog,
have
been
extremely
positive
to
this
coming
in
and
perhaps
jonah
as
well,
and
so
that
that
that
is
the
the
primary
thing.
D
I
think
something
useful
would
be
like
an
opinion
doesn't
even
be
strongly
held,
but
just
like,
we
want
to
bring
this
in
it's
going
to
have
its
initial
functionality
and
here's
like
a
literally
half
page,
like
just
a
charter
for
where
we
see
this
going
in
the
next
year.
Right
like
are
we
going
to
add
things
beyond
network
telemetry?
D
Are
we-
and
this
is
this,
for
example,
another
one
that
michael
was
big
on
was:
are
we
going
to
continue
to
capture
the
data,
as
I
think
logs
is
what
it
does
currently
and
then
expect
it
to
be
translate
in
the
collector
well
long
term-
probably
not
right
but
short
term?
Probably
yes,
because
it
works
right
and
just
like
the
sort
of
few
big
rocks
that
we
see
are
this
this
group
working
on
both
to
make
this
more
useful,
but
also
just
generally
more
hotel
native.
D
So
we
can
start
on
that.
I
won't
be
here
next
week,
but
I'll
be
here
the
following
week.
So
I
suggest
we
just
do
that
and
bring
the
code
in
and
start
going.
C
Yeah
for
sure
yeah-
I
won't
I'll
be
here
next
week
if
I
can
make
it,
but
I'm
going
to
miss
a
couple
weeks,
I'll
be
out
of
the
country
so
but
yeah
I'm
definitely
interested
in
this
data
source.
I
think
we
just
have
to
figure
out
the
use
cases
a
little
bit
more.
D
C
C
B
B
C
A
I'll
be
able
to
make
next
week,
but
two
weeks
from
now
I
think
I
won't
be
able
to
make.
I
will
be
here
two
weeks
from
now,
but
not
next
week.