►
From YouTube: 2021-11-02 CNCF TAG Observability 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
A
A
B
Things
things
are
going
well
joining
for
the
first
time
in
this
group,
so.
B
We
met
at
the
at
the
top
of
the
at
the.
A
Also
you'll
have
to
you
have
to
pardon
the
brain
part.
It's
funny
going
back
to
a
zoom,
you
know
versus
being
in
prison.
A
Richie,
did
you
hear
back
from
lolita?
Was
she
coming.
C
She
said
she
is
available
for
half
an
hour,
but
else
blocked.
She
can
join
from
now
until
in
30
minutes,
but
she's
not
here
bartek
couldn't
make
it
because
he
needs
to
finish
something
for
prometheus
and
that
needs
to
go
when
it
should
go
out
tomorrow.
A
Yeah,
to
be
honest,
I
feel
like,
I
think,
a
lot
of
people,
if
I'm
probably
projecting
here
but
just
recovering
from
from
khan
and
catching
back
up
with
all
the
things
is
almost
a
full-time
job
by
itself.
So
I
would
expect
today's
pretty
quiet.
I
have
some
administrivia
and
a
couple
updates
if
we
get
quorum
here,
I
was
on
the
tlc
call
just
a
half
an
hour
ago.
A
C
I
mean
we
already
had
one
call
after
and
that
actually
had
a
ton
of
new
users.
So
I'm
kind
of
surprised
we're
actually.
A
A
You
know
something
but
there's
a
little
bit
of
saturation
yeah.
I
have
a
couple
things
I
could
talk
about,
but
I
so
but
but
I
think
first,
why
don't?
We
start
anyway
because
we're
you
know
four
minutes,
and
this
is
the
cncf
meeting
the
code
of
conduct
applies.
Please
don't
do
or
say
anything
that
is
a
violation
of
that
code
of
conduct.
Maybe
we
could
do
intros,
which
might
be
really
short
here,
but
you
know
we.
A
E
Say
hi
yeah,
definitely
hi
omid,
I'm
alolita
sharma
and
I
actually
have
just
joined
the
cncf
tag.
Observability
group,
as
a
co-chair
again
super
happy
to
be
working
with
richard
and
matt
together,
and
you
know
all
of
us
have
been
kind
of
working
in
observability
for
a
while.
So
it's
really
nice
to
have
these
discussions
where
you
know
we
are
working
with
end
users
and
with
the
larger
developer
community
to
build
out.
E
C
Quick
thing:
yeah
hi
richard
prometheus,
openmetrics,
open
telemetry
and
tech,
observability
and
grafana
and
stuff.
B
Cool
and
let
me
introduce
myself
as
well,
so
I'm
omid
for
the
work
on
pixie
at
new
relic.
The
reason
I
kind
of
got
interested
in
this
looped
in
here
was,
I
noticed,
the
white
paper.
B
I
noticed
there
was
a
section
on
ebpf
and
observability
and
there
was
some
interest
in
that,
and
so
I
leave
the
ebpf
stuff
at
pixie
and
so
just
looking
to
see,
if
there's
any
way,
I
can
help
out
and
participate.
E
Oh
wonderful,
wonderful
because
I
think
I
mean
we
might
have
even
chatted
earlier
on
some
of
the
ebpf
calls
but
again
really
excited
about
the
pixie
work.
That's
ongoing
and
you
know
we
are.
I
work
actively
very
actively
on
open
telemetry,
as
you
know,
so
definitely
you
know
looking
forward
to
having
some
of
your
time,
maybe
even
on
the
ebpf
group.
A
So
lumen
is
underselling
a
little
bit.
He
basically
is
heading
up
evpn
for
pixie.
E
A
So
yeah.
B
Cool
anyways
really
happy
to
be
here,
and
just
you
know
here
to
help.
If
there's
any
way,
I
can
contribute
be
happy
to
do
so.
A
Cool
a
leader
or
richard,
is
there
anything
that
you
want
to
put
on
the
agenda?
I
have
some
stuff
I
can
put
on
if
it's
just.
C
C
White
paper
is
a
non-update,
because
I
was
sick
for
quite
a
bit
of
of
the
time
and
call
for
new
work
streams.
But.
A
A
Where
are
we
with
the
logo?
Do
we?
Actually,
I
think
we
we
saw
we
closed
down
on
one
right.
Is
there
a
follow-up
that
I
wanted
to
do
with
the
cncf
folks
to
get
our
community
space
and
our
stickers
and.
C
Our
we
gave
the
update
to
alolita
sorry
not
too
early
to
amy.
C
If
you
don't
know,
I'm
super
bad
with
them
and
they
confuse
names
all
the
time,
in
particular,
if
they're
in
similar
regions
like
cncf
region,
I
yeah
amy
didn't
get
back,
but
it
was
also
keep
going
and
such
so
I
can.
I
can
try
and
poke
again.
A
E
The
did
you
just
bring
in
me
on
slackhold.
Is
there
a
email
thread
that
we
usually
follow.
A
Yeah
that
gives
us
for
what
it's
worth
the
you
know
the
community
space
for
us,
a
logo,
I
believe,
with
the
community
space
and
then
our
youtube
channel
gets
a
logo
and
a
little
bit
more
jazz
stuff
with
some
some.
A
A
Is
there
anything
in
particular
like
if
you
think,
moonshot
type
stuff,
you
know
you
know
you've
been
working
down
in
the
bits,
literally
down
on
the
bits
of
of
collecting,
telemetry
and
signals,
for
you
know
what
a
decade
or
more
now.
So
you
know
if,
if
I
like
to
ask
a
question,
sometimes
with
folks
that
have
been,
you
know
implementing
this
stuff
for
a
long
time
or
have
otherwise
been
involved,
you
know
shake
a
sticker.
We
have
a
magic
wand,
we
know
what's
possible
now.
A
What
can
we
put
together
that
we
couldn't
before
I'll
talk
to
an
idea?
I've
got
coming
out
of
kubecon
that
I've
been
incubating
for
a
couple
of
months
now,
but
is
there
anything
that
you
know
you
would
love
to
see
or
a
collaboration
or
a
coalition
type
of
effort
across
the
the
cncf
ecosystem?.
B
That's
a
big
question
in
terms
of
collaboration,
I
mean
in
terms
of
like
cool
things,
coming
down
the
pike
I
mean.
Obviously
I
know
more
on
like
what
our
road
map
for
pixie
is,
and
so
some
of
the
cool
stuff
I
think
coming
down.
I.
B
B
You
know,
there's
a
lot
more.
We
can
do
with
as
evp
gets
kind
of
more
and
more
kind
of
rich.
I
think
there's
a
lot
of
cool
things
we
can
do
to
do
with
it
for
observability,
I
think
kind
of
helping
developers
in
terms
of
logging
stuff,
that's
happening
with
their
application
or
making
ebpf
more
pervasive
and
letting
without
really
having
to
understand
eppf,
but
getting
application
developers
to
use
the
power
of
a
bpf
so
there's
obviously
with
ppf,
trace
and
stuff.
B
There's
a
lot
of
cool
observability
stuff
happening
there,
but
kind
of
taking
that
to
the
next
level
so
that
people
don't
even
know
that
they're
dealing
with
bpf
but
but
they're
getting
the
benefits
of
observability
and
interacting
with
higher
level
kind
of
languages
and
models
and
stuff
to
to
get
that
stuff.
I
think
that
would
be
kind
of.
I
think.
That's
a
pretty
cool
direction
to
go
with
in
terms
of
observability.
A
No,
no,
no,
I
mean
there's
just
the
four
of
us
right.
Okay,
we
got
three
co-chairs
of
you
and
we're
kind
of
planning
out.
You
know
we've
just
in
my
mind,
and
this
is
what
I
said
last
hour
at
the
cs,
the
toc,
the
technical
oversight
committee
meeting.
You
know
the
dust
for
me
at
least,
has
been
settling
over
the
week
the
last
week
or
so
from
kubecon
right.
You
know,
I'm
still
ingesting
quite
a
lot
of
talks.
A
Alolita,
I
think
you,
you
said
you
were
working
on
a
blog
post,
that
kind
of
summarizes
them.
Yes,
yes,.
E
A
The
list
that
michael
posted
it,
I
I
think
I
have
a
list
from
in
our
meeting
notes
from
a
couple
weeks
ago.
It's
probably
double
that,
so
you
know,
I
think,
that's
where
everyone
is.
If
I'm
projecting
again,
what
do
you
think
of
the
ebpf
collector
announcement
from
a
few
weeks
ago
from
splunk
and
have
you
looked
at
it
yet.
B
Yeah,
I
was
actually
I
was
part
of
that
working
group.
That
kind
of
was
doing
the
evaluation
of
that.
I
think
it's
great
for
the
community
to
have
obviously
an
ebpf
collector.
I
think
we
from
a
community
perspective-
and
I
tried
to
make
this
known
in
the
the
working
group
itself
and
tried
to
kind
of
get
this
message
out
is.
I
think
we
want
to
be
inclusive
ebpf,
calling
it
the
ebpf
collector
like
ebpf,
is
just
so
wide.
B
C
B
My
feedback
was
just
you
know:
we,
we
really
should
set
a
road
map
for
open
telemetry
and
how
it
wants
to
use
ebpf,
and
maybe
we
have
an
open,
telemetry,
evp
umbrella
of
collectors,
but
calling
like
we
need
to
be
like
more
precise
with
and
have
a
road
map
and
think
a
little
bit
to
the
future
and
have
a
plan
of
how
we
want
to
kind
of
push
this
stuff
out.
Because
really,
what
was
contributed
was
just
the
network
performance
monitoring
from
splunk
right.
That's
what
it
does.
Yeah.
D
B
E
Yeah
I
mean,
and
then
or
maybe
just
to
you
know
kind
of
reiterate-
that
the
discussions
in
the
larger
community,
even
within
open
telemetry
have
been
to
you
know,
be
very
clear
about.
E
You
know
what
specific
scope
the
current
code
base
handles
and
then
also
make
sure
that
very
much
you
know
there
is
interoperability
and
integration
with
pixi
and
any
other
collectors.
You
know
that
actually
exists
as
pipelines
right,
so
the
idea
is
not
really
to
just
say:
okay,
whatever
you
have
is
what
you
know
is
the
only
solution.
That's
definitely
not
been
the
you
know
the
project's
decision.
B
And
we're
working
in
the
work
group,
like
I'm
trying
to
you
know,
also
get
the
work
group
to
kind
of
do
more,
look
more
broadly
and
look
at
other
stuff
too.
So
we're
actually
doing
a
review
of
pixi
and
then
I'm
trying
to
pull
in
other
projects
as
well.
So
it's
not
so
we
have,
you
know
splunk
flash
flow
mill,
then
there's
pixie,
but
then
there's
like
parso
just
came
out
with
an
ebpf
based
profiler
and
then
there's
you
know
so
many
different
projects
out
there
that
use.
A
Stack
state
is
using
something
you
know
to
pull
some
metrics
yeah,
I
kind
of
view
evpf
kind
of
kind
of
like
the
only
the
analogy
that
comes
to
me
is,
like
you
know,
advances
in
understanding
of
cellular
biology
and
viral
epidemiology
and
microscopy,
and
all
of
that
right,
like
we
have
all
these
new
drugs.
We
have
all
these
new
cool
capabilities
we
can
do.
A
We
also
have
like
weapons
of
mass
destruction
and
like
things
that
can
wipe
out
a
continent
and
horrible
bugs
right
so
like
with
ebpf,
you
know,
there's
so
much
you
can
do
in
a
read-only
mode
as
we
have
talked
at
length
about.
But
if
you
start
considering
what
you
can
do,
if
you
get
a
little
bit
more,
oh
yeah,
inevitably
intrusive,
you
know
you
can
start
doing.
You
know
all
manner
of
validation.
You
can
do
actual
code
path,
analysis,
not
just
blocks
and
lines
and
code
coverage,
but
code
path.
A
You
know
you
can
you
can
potentially
dramatically
reduce
the
cost
of
validation
in
terms
of
not
having
to
make
mocks
and
subs
and
fakes
when
you
can
just
fund
things
arbitrarily
with
it
with
a
proper
framework.
In
place
so
so
there's
all
kinds
of
things
that
could
be
built,
but
there's
also
all
kinds
of
you
know
potential.
A
Comes
great
responsibility,
right
standards,
but
open
norms
or,
like
almost
you
know,
you
know
kind
of
like
out
of
the
get
ops
working
group.
That
kind
of
have
not
quite
a
manifesto,
but
they
have.
These
are
some
guiding
principles
that
we
as
a
community
have
come
together
around,
and
this
is
our
current
thinking
on
you
know,
just
like
we
do
with
you
know:
hey
you
know,
genetics
is
great,
but
we're
generally
not
going
to
clone
humans
right
now.
A
A
You
know
what
does
this
thing
really
do
and
and
what
can
you
tell
your
cio
that
it
won't
do
you
know
and
language
for
that
might
be
helpful.
I
think.
B
B
I
think
people
are
there's
some
people
who,
like
are
rushing
to
kind
of
adopt
this
sort
of
stuff
and
then
there's
another
camp,
which
is
very
cautious
because
of
all
the
implications
of
you
know
the
power
that
comes
with
evpf.
So
I
think
we're
seeing
some
of
that
stuff
play
out
right
now
and
so
it'll
be
really
interesting
to
see
how
it
you
know
where
people
end
up
and
how
we
communicate
it
and
how
people
become
comfortable
with
it
and
all
that
sort
of
stuff.
A
What
is
the
magnitude
beyond
you
know?
I
think
of
it
as
like
this
awesome
new
capability,
where
you
know
we
can
go
like
my
favorite
picture
in
the
whole
universe,
for
the
last
couple
weeks
has
been
this
one
you
know
like.
We
can
just
pick
where
we
want
to
probe,
and
this
isn't
even
the
full
picture.
That's
just
some
of
it
right
around
what
are
all
the
probes
we
can
have
and
what
are
all
the
places
we
could
get.
So
yes,
cool.
C
Yeah
I
mean
the
data
explosion
back
when,
like
in
the
bro
days
and
bpf
days
or
berkeley
packet
filter
back
there
like
with
full
name.
That
was
one
of
the
hurdles.
We
also
hit
that
there
was
just
so
much
data
that
back
then
the
systems
couldn't
really
deal
with
with
everything.
If
you
just
turned
everything
to
give
me
everything,
yeah.
A
We
had
the
same
limitations
with
compilers.
That's
why
yeah
like
there's
a
lot
of
things
you
could
have
done
20
years
ago
with
compilers,
but
you
have
gigabyte
size
program,
databases.
I
got
you
off.
So
I'm
sorry.
C
Much
of
that
back
then
was
done
in
in
dedicated
cards
like
it.
A
lot
of
this
is
coming
from
your
networking
in
broad
space
and
you
had
hugely
expensive
cards
and
you
actually
had
to
write
vhdl
and
it
was
horrible,
but
the
network
chair
at
my
university
really
loved
it.
So
for
the
use
cases
I
initially,
I
thought
this
might
be
something
suited
for
the
white
paper,
but
maybe
that's
actually
something
which,
where
we
can
establish
an
actual
work
stream
uses
of
ebpf,
because
everyone
is
talking
about
it.
C
But
not
everyone
has
actually
read
up
about
what
you
can
do
with
it.
So
even
on
a
higher
level,
then
this
is
how
to
do
it
or
or
something
more
of
an
initial
high
level.
This
is
what
you
can
even
consider
doing
and
then
go
into
all
those
different
aspects
of
what
ebpf
can
do,
because
that's
like
looking
at
a
few
of
the
of
the
general
content
out
there
and
also
a
little
bit
of
the
coupon
talks
I
I
jumped
in
between
a
little
bit.
C
There
was
a
lot
of
all
this
potential
and
that's
absolutely
true,
but
there
was
not
so
much
of
reduce
this
huge
amount
of
potential
into
specific
things
which
you
can
consider
for
yourself
of,
as
pursuing
in
the
in
a
short
or
medium
term
like
yup,
almost
like
those
user
stories
use
case
books,
something
like
this,
where
you
actually
say:
okay,
this
is
something
where
you
can
use
it
and
it's
better
because
doesn't
that.
B
Yeah,
that
would
be
really
cool.
So
are
you
suggesting
that
we
have
that
as
a
separate
kind
of
something
we
publish
separately.
C
I
think,
as
it
probably
makes
sense
to
have
an
overview
in
the
white
paper
and
then
in
depth
in
the
other
thing,
but
I'm
not
certain
like
this
is
just
my
opinion.
I
also
think
this
would
mesh
super
nicely
with
with
open
telemetry
work,
because
this
could
then
be
literally
a.
These
are
the
use
cases,
and
this
is
how
we
deducted
use
from
this,
and
so
we
need
to
cover
x
use
case
and
coming
from
from
use
cases.
B
Yeah,
so
I
completely
agree,
I
think,
for
the
white
paper
we
can.
I
mean
the
white
paper
has
kind
of
got
the
observability
focus,
so
we
can
talk
about
an
overview
in
there.
I
mean
there's
only
so
much.
We
can
go
in
depth
there
right,
like
you
said
so.
I
think
we
can
kind
of
have
an
overview
there
and
fill
out
that
section
of
how
ebpf
is
used
for
observability
and
then
point
to
the
white
paper
for
more
detail.
B
The
white
paper
could
even
be
more
broad
because
than
just
observability,
because
once
you
start
talking
about
evpf
you're,
it's
it's
not
just
observability.
It's
also
security.
It's
also
network
management.
It's
you
know
again.
This
ebps
has
just
made
so
many
different
things
to
so
many
different
people
so
like
we
can
kind
of
broaden
that
and
kind
of
just
give
a
overview
of
what
our
what's
the
lay
of
the
land
with
ebtf.
C
So
as
to
the
white
paper,
we
actually
did
consider
if
we,
if
we
cut
a
101
version
which
is
super
reduced,
and
then
we
have
literally
the
same
qc,
the
the
same
everything,
sometimes
even
the
same
text,
in
a
more
verbose
version
which
goes
more
depth
as
to
the
other
aspect
with.
I
think
it
would
make
sense
to
just
try
and
establish
an
a
work
stream
within
the
tag
to
to
define
ebpf
use
cases
and
to
define
well
not
even
use
cases
but
like
you
can
use
it
for
networking
course
x.
C
And
you
have
you
have
these
in
that
interfaces,
and
this
makes
sense
because
you
can
get
stuff
directly
from
the
kernel
and
you
don't
have
to
go
into
your
into
your
application,
and
maybe
you
get
delays,
and
maybe
you
have
drop
buffers
blah
blah
blah
blah
blah.
You
get
the
raw
thing
from
the
system
and
all
those
aspects.
C
Why
is
it
nicer
to
have
tracing
coming
from
the
kernel
versus
versus
from
from
code,
which
I
write
versus?
What
are
the
advantages
of
of?
If
I
actually
do
sit
someone
down
and
they
need
to
instrument
the
code
themselves
like
this
kind
of
thing
to
explore
this,
I
can
easily
see
this
it's
being
its
own
stream
and
and
yeah
interesting
paper.
Talk
webinar
coming
out.
B
I
completely
agree,
and
there
isn't.
There
is
a
very
interesting
question
between
like
the
evp
way
in
the
open
telemetry
way,
and
I
think
there's
pros
and
cons
to
both
and
I
don't
think
either
one's
really
going
to
go
away
like
the
manual
instrumentation
stuff
and
putting
essentially
trace
points
inside
your
code
has
a
lot
of
benefit.
B
There
are
certain
things
you
just
can't
do
very
easily
with
evpf
that
you
know
it
makes
a
lot
more
sense
to
do
the
kind
of
the
the
open
telemetry
way,
and
so
I
think
in
the
end,
these
things
are
going
to
end
up
being
complementary,
but
kind
of
understanding
where
one
is
the
right
approach
to
go
and
the
other
one's
the
right
approach
to
go.
I
think
that
that
can
be
clarified
and
would
be
useful
for
the
community.
B
So
is
there,
I
know
a
few
folks
who
are
at
kubecon,
who
might
be
interested
in
collaborating
on
on
a
dock
like
this.
Is
there
anyone
else
that
I.
E
Mean
from
our
end,
definitely
there
are
several
folks.
I
mean
both
on
hotel
as
well
as
aws,
who
are
you
know,
happy
to
and
and
interested
in
collaborating.
So
I
think
that
it's
a
it
would
be
actually
a
really
good
idea.
This
I
mean
this
white
paper
doesn't
necessarily
have
to
be
extremely
detailed,
but
on
the
other
hand,
you
know
just
laying
out
the
landscape
and
actually
being
able
to
you
know
kind
of
maybe
look
at
it
from
a
maturity
standpoint.
E
That
is
what
are
some
of
the
areas
where
you
know
some
of
the
foundational
work
has
already
been
done
and-
and
you
know
like,
as
you
said,
splunk's
component
really
is
doing
networking
you
know
metrics,
for
example,
pixi's
approach
is
slightly
more
general,
you
know
so
again
actually
having
some.
What,
if
a
comparative
analysis
also
might
be
useful,
because
it
really
begs
the
question
that
you
know
what
is
what
is
the?
Is
there
a
general
collection
process
there
or
is
it?
E
You
know
it
doesn't
become
more
specialized
for
the
different
types
of
types
of
you
know:
data
and
the
different
layers.
Within
this
whole
you
know
section
right
of
profiling
and
and
and
really
you
know
from
and
the
reason
I
say
that
is
because
you
know
for
those
of
us
who
are
down
in
the
in
the
details
and
the
tra.
E
You
know
we
understand
the
distinctions
right,
but
for
a
customer
who
is
looking
at
this
and
saying
okay,
how
do
we
actually
take
this
and
and
what
tools
are
best
suited
or
what
libraries
exist
today?
What
is
the
best
practice
here
and
then
you
know,
how
do
I
take
a
decision
based
on
what
kind
of
metrics
I
can
consume
and
what's
useful
to
my
stack,
is,
is
very
useful.
I
think.
B
Absolutely
yeah
and
and
yeah
we
can
kind
of
yeah.
I
think
those
are
all
topics
we
can
kind
of
hit
and
it
would
be
it's
really
useful
for,
like
most
people,
they're
users
of
evpf,
indirectly
they're
not
actually
going
to
be
writing
vpf
code
right.
Yes,
like
you
were
saying
the
customers
and
stuff,
and
so
like
understanding
when
how
just
at
a
high
level
how
it
works
when
it's
useful,
when
you
actually
really
need
to
get
into
the
nitty-gritty
versus.
B
When
can
you
just
like
use
existing
stuff
and
kind
of,
like
I
said
at
the
outset,
I
think
I
think
the
direction
for
bpf
eventually
will
be
like.
Hopefully,
it
becomes
easier
and
easier
to
use
such
that
it's
app
most
of
it's
abstracted
away
to
users
and
people
who
are
getting
data
from
evpf
or
networking
policies
or
security
from
epf
they're
not
actually
need
to
know
much
about
etf,
but
it
would
be
nice
for
them
to
understand
how
it's
kind
of
doing
this
stuff.
Under
the
hood.
E
Yeah
yeah
exactly
so
again,
I
know
I
know
I
have
to
drop
off
in
about
a
minute,
but
how
do
we
go
about
the
next
steps
here?
Should
we
just
actually
discuss
this
as
a
framework?
Next
time
we
meet,
or
should
we
just
do
a
doc
and
just
like
start
a
google
doc
and
just
share
it
or
what
makes
sense.
C
Anyone
who's
not
here,
so
we
don't
lose
those
two
weeks
and
I
mean
we
can
start
with
an
empty
dock
and
just
start
collecting
stuff.
It's
always
a
little
bit
risky
to
start
with
a
completely
empty
dock,
but
on
the
other
hand,
it's.
E
B
E
B
B
Like
a
mission
statement
for
what
the
doc
is
supposed
to
do,
maybe
a
few
out
like
a
little
bit
of
a
skeleton
of
some
topics
that
we
can
hit
and
then
kind
of
throw
it
out
to
the
rest
of
the
team
so
that
you
know
it
just
to
seed
it
right,
because
we
just
throw
in
an
empty
dog
exactly
like
people
might
not
know
what
to
do
with
it.
E
Right
right,
totally:
okay,
cool!
So
what's
the
next
step
there.
B
B
C
E
And-
and
I
mean
once
you
share
it,
then
you
know
I
can
also
add
you
know
some
of
the
areas
that
at
least
I
have
you
know
again
gotten
feedback
on
in
in
terms
of
customer.
You
know
requests
and
how
that
relates
to
the
to
our.
You
know
to
the
hotel
stack.
That's
currently
existing
so
definitely
can
add
that
detail.
B
Perfect
that'd
be
great,
so
let
me
put
the
skeleton
together
and
then
I'll
shoot
out
to
the
mailing
list
or
or
if
I
maybe
I'll
preview
it
with
some
of
you
first
just
to
make
sure.
E
Yeah,
I
mean
definitely
I
mean
please
feel
free
to
you
know,
use
me
and
anything.
I
can
support
you
on.
E
C
C
Hey
there
yeah,
we
were
just
talking
about
ebpf
and
and
starting
a
crew
workstream
extreme
around
ebpf,
and
how
and
when
to
use
it
omit
will
be,
will
be
creating
something
else.
We
have
a
super
empty
call
this
time
around.
It's
actually
only
us.
D
I
think
it's
a
it's
a
good
time.
I
can
ask
some
basic
question:
I'm
also
joining
it
for
the
first
time
like
what
is
this
channel
about?
There's
a
discussion
about.
C
So,
are
you
familiar
with
cnc
and
how
the
texts
are
structured.
D
I'm
not
really,
I
just
yeah
okay.
A
A
great
place
to
start
is
the
talk
it's
in
the
meeting
notes
from
today
that
that
kind
of
covers
some
of
some
of
the
history
for
sure.
Welcome
what
do
you
work
on
in
your
day,
job?
What's
up,
what's
interesting
to
you
or
what
are
you
working
on.
C
So
we
normally
introduce
ourselves
and
and
tell
each
other
why
we
care
about
joining
here.
I
mean
in
this
case,
if
you're
not
certain,
why
you're
joining
and
we
need
to
send
to
you
why
you're
joining
maybe
we
need
to
pitch
first,
which
is
also
fine
but
yeah.
So.
D
A
D
C
So
the
super
short
version
is,
you
have
cncftoc
the
technical
oversight
committee.
They
decide
which
projects
get
into
cncf,
which
move
up
from
sandbox
incubation
to
graduated
and
and
all
those
kinds
of
things.
And
then
you
have
the
technical
advisory
groups
for
various
bits
and
pieces
like
networking,
security,
blah
blah
blah
and
one
of
those
technical
advisory
groups
is.
Is
us
tag
observability,
so.
D
This
is
a
group
of
people.
A
Okay,
I'll
put
up
a
slide
really
fast,
if
you
like,
and
then
I
can,
I
can
cover
the
stuff
that
I
was
going
to
cover
briefly,
but
just
to
I
just
want
to
just
just
say:
welcome.
We
have
a
unusually
small
set
here
today,
so,
okay,
this
might
help.
What
virtue
is.
This
is
the
slides
from
I'm
looking
for
this
slide.
A
So
the
cncf
has
a
technical
oversight
committee
and
we
use
there
used
to
be
called
special
interest
groups,
they're
now
called
technical
advisory
groups,
and
they
exist
to
inform
the
technical
oversight
committee
about
gaps
in
the
ecosystem
opportunities
for
collaboration
to
assist
the
technical
oversight
committee
with
a
number
of
you
know,
help
with
evaluation
and
guidance
and
things
like
that.
Okay,
again,
we
haven't.
A
We
have
a
talk
that
covers
it
in
quite
in
quite
some
detail,
but
but
in
a
nutshell,
we
we're
a
group
of
vendors
project,
contributors
and
or
folks
engaged
with
projects,
as
well
as
end
users.
People
using
cncf
technologies
to
solve
business
challenges
in
in
the
market,
and
so
the
technical
advisory
group
is,
is
an
organization
that
has
the
ability
to
to
to
help
out.
In
all
of
those
kind
of
contexts,
does
that
help
welcome
so
richie.
A
I
wanted
to
bounce
this
off
you
as
well
a
little
bit
and
whoever
so
I
put
some,
which
I
won't
spend
a
lot
of
time
on
it
here,
but
I
put
some
links
in
the
meeting
notes
to
a
doc.
I've
been,
I
started
a
couple
weeks
ago
and
we'll
be
having
a
bunch
of
updates
in
the
next
week
really
as
I've
got
a
bunch
of
stuff
on
on
paper
and
whiteboards
here
that
will
move
in,
but
you
know
you've
got
the
domain,
it's
going
to
be
under
kh.dev.
A
It's
like
a
watch,
but
with
some
additional
caching
and
kubernetes
to
watch
for
state
changes,
create
update,
delete
of
kubernetes
resources,
including
crd,
dynamic
informer,
will
allow
you
to
do
that
so
that
stream
of
events
really
where
from
that
dynamic
informer,
I
want
to
update
and
we'll
create
and
and
populate
a
neo4j
graph
database
that
uses
it's
a
whole
talk
by
itself
but
uses
a
time-based
versioning,
either
by
probably
with
a
composite
times.
A
Key
space,
you
know
so
it's
sortable
by
time,
but
really
to
be
able
to
correlate
what's
being
deployed.
You
know
in
terms
of
particular
versions
of
things,
but
also
as
operators
continue
to
spread
their
scope.
We
will
have
a
continued
explosion
of
crds
custom
resource
definitions
with
a
lot
of
interesting
interactions
between
them
and
and
the
reconciliatory
loops,
and
the
controllers
that
that
you
know
manage
them,
manage
the
instances
of
objects
that
they
represent.
A
You
know
in
a
cluster
that
is
the
system,
so
I
want
to
build
a
graph
database
of
that
and
then
use
it
in
interesting
ways
to
both.
You
know
provide
some
of
the
visualizations
that
we
would
want
to
show
of
how
graphs
and
their
topology
systemically
and
structurally
change
over
time.
So
you
know
I
have
a
design
that
I'll
be
putting
in
there.
A
You
know
where
we
leverage
some
basic
time-based
versioning,
so
you
could
think
of
you
know
if
you
have
you
separate
structure
from
state
and
for
a
particular
node
in
a
graph
graphs,
have
relationships
and
notes.
So
by
separating
the
structure
from
the
state,
you
know
you
have
copy
on
write
semantics.
A
So
you
know
if
a
crd
is
going
to
be
updated,
an
existing
one
say
rather
than
make
an
update
to
the
node,
you
you
take
the
state
from
the
node
and
that
gets
sort
of
snapshotted
and
you
and
you
have
the
new
node
that
is
now
now
current
and
there
are
different
approaches
based
on
you
know
whether
or
not
you
want
like
a
radial
set
of
snapshots
or
if
you're
gonna
have
a
ton
of
snapshots,
as
we
would
have
here,
you
might
want
to
have
effectively
a
linked
list
or
a
chain
of
nodes
that
are
the
all
of
the
previous
states,
ordered
by
time
with
links
to
themselves.
A
So
when
you
find
something-
and
you
want
to
replay
the
history
of
it,
you
have
a
very
inexpensive
traversal
to
do.
In
addition,
you
can
leverage
a
lot
of
the
graph
data
science
library
that
neo4j
has
been
working
on
the
last
few
years
to
do
centrality
analysis.
A
You
know
to
do
it
just
I
won't
go
through
everything,
because
there's
five
or
six
different
buckets
of
graph
data
science,
algorithms,
that
suddenly
we
can
bring
to
bear
on
what
is
the
system
creates
and
everything
running
in
it
and
encrypting
itself
doing.
In
addition,
I
posit
I
haven't
proved
it
out,
but
it
seems
to
me
that
that
structure
once
created
and
maintained-
and
this
could
be
done
locally
or
as
a
service
you
resolve.
A
I
want
to
build
the
capabilities,
not
not
necessarily
a
product,
but
but
lastly,
I
I
will
say
you
know,
I
think
this
approach
for
aggregations
and
other
sorts
of
things
where
we
have
systems
that
deal
with
aggregations
and
roll
ups
and
down
sampling
and
all
manner
of
things
in
a
sort
of
a
big
heavy
just
about
the
metrics
way.
But
I
think,
by
leveraging
a
graph
underlying
structure,
to
complement
the
other
systems
that
we
have.
A
I
think
we
can
provide
more
semantic
comprehension
where
I
can
enable
better
semantic
comprehension
for
practitioners
and
users,
because
you
know
a
picture
or
augmented
reality.
Glasses
with
a
3d
model
is
worth
more
than
a
few
words.
So
that's
the
overall
concept
for
the
thing.
I
think
what
we
have
talked
about
in
previous
weeks-
or
I
had
just
kind
of
meandered
on
about
a
bit-
is
a
front
door
where
it
would
be
kind
of
neat.
But
you
know
you
see
yourself
your
yourself,
your
request
and
your
your
kind
of
session.
A
If
you
will,
I've
usually
displayed-
and
so
I
think,
taking
taking
the
things
I
mentioned,
applying
some
of
the
stuff
from
current
thinking
around
streaming
systems
and
unbounded
data
sets
and
how
to
organize
them
into
sessions
like
we
do
for
click
streams,
and
things
like
that
that
that
is
also
there's
some
potential
green
field
there
or
open
area
to
just
connect.
A
Some
things
that
I
haven't
seen
connected
yet,
but
could
give
us
some
really
powerful
capabilities
to
to
leverage
these
disparate
sources
of
data
and
then
correlate
it
back
to
again
something
that
the
business
understands
in
their
own
language
or
or
you
know
not
just
leaving
it
at
a
great
level,
but
tying
that
back
to
what
work
and
effort
is
actually
being
funded
and
what
outcomes
there
are.
This
also
ties
into
sls
and
slos,
and
things
like
that
so
kind
of
incubating
some
of
these
ideas
and
some
others
it'll
be
in
that
doc.
A
If
you're
interested
or
know
somebody
who
might
be,
let
them
know-
and
you
know
we're
just
going
to
iterate
offline
for
a
little
bit,
but
I
do
see
this
as
something
that
the
tag
could
support
either
a
sort
of
like
a
sandbox
project.
So
we
can
see
what
it's
like
to
to
sandbox
a
project
and
go
through
that
process.
A
You
know
as
dog
fooding
and
to
make
it
more
available,
but
I
think
there
are
interactions
with
both
the
get
ops
working
group
around
and
I've
started.
Those
discussions
have
had
more
at
coupon
that
I'll
follow
up
on
in
writing
around
making
a
standard
for
reporting
deployments,
for
example,
so
flux
and
argo
and
new
tools
are
coming
out.
You
know
how
do
we
in
a
structured
way
and
then
provide
an
api
to
at
least
say
this?
A
Is
the
structure
of
that
information
so
that
an
ecosystem
of
tools
and
vendors
can
make
different
approaches
to
using
that
data,
but
kind
of
like
we
have
open
metrics?
You
know
to
to
to
codify
some
of
that.
I
think
we
do
need
something
there.
So
there's
an
interaction
there
and
some
of
the
prs
for
that
will
go
out
today
and
tomorrow
to
make
interest.
A
You
know
formally
at
their
guidance
and
the
other
which
I
haven't
approached
yet
is
sig
instrumentation,
because
some
of
a
lot
of
the
source
data
comes
from
controller
manager
in
many
cases
or
the
api
server
itself,
and
some
of
the
vowels
of
that
which
now
has
open,
telemetry
instrumentation.
So
much
of
what
we
need
may
be
there,
but
we
might
want
to
have
additional
hooks
and
or
have
a
dialogue
with
them
so
that
we
can
kind
of
iterate
on
future
kubernetes
that
there
are
missing
ways
to
do.
A
You
know
if
there
are
interesting
signals
that
we
want
to
get
out
of
the
controller
runtime,
the
controller
manager
and
all
of
its
dozens
of
components.
I
think
that
would
be
the
right
interested
party.
So
so
that's.
A
On
that,
as
I
said,
I've
allocated
some
time
to
come
up
in
the
coming
weeks
to
have
something
maybe
more
to
look
at
by
next
meeting
with
slides
in
the
demo
but
yeah
if
anyone's
interested
in
collaborating
that
seasons
later
reach
out
to
me
on
cncf
slack
or
you
can
find
me
thanks.
A
C
No,
oh
today.
A
Is
also
ignite
microsoft's
ex
ignite
conference
is
like
right
now,
keynotes
are
happening
so
there's
eyeballs
there
as
well.
B
All
right,
it
was
great
great
to
meet
you
guys.
A
Yeah
come
next
week,
I
think
we'll
have
a
bunch
more
people.
We
usually
will
make
an
agenda
ahead
of
time.
Sometimes
we
have
guest
speakers,
as
you
wear
ones,
yeah.
B
I
figured
yeah.
Definitely
I'm
excited
to
you
know,
come
again
and
participate
so
yeah
I'll.
Definitely
be
there
all
right.
All
right,
cool
see
you
guys.