►
From YouTube: CNCF TOC Meeting 2021-04-06
Description
CNCF TOC Meeting 2021-04-06
A
A
A
D
A
E
A
A
A
C
C
B
Hi
everyone,
my
nickname,
is
dims,
so
you
can
call
me
dems.
Please
hit
me
up
on
slack
cncf
or
the
kubernetes
one
happy
to
chat
with
you
to
get
to
know
how
I
can
be
of
assistance
thanks
a
lot
to
michelle
big
shoes
to
phil.
Hopefully
I
will
be
able
to
learn
and
help
so
and
thanks
to
the
tfc
for
putting
me
in
so
it's
a
big
thumbs
up
for
me.
So
thanks
a
lot
I
work
for
vmware.
I
live
just
south
of
boston.
C
F
This
is
spearheaded
by
dawn,
who
thinks
we
might
eventually
want
to
make
it
a
requirement
for
graduated
projects,
a
charter
statement
being
something
that
says
this
is
what
the
project
is.
This
is
what
the
project
scope
is,
because
it
can
be
a
little
bit
confusing
if
you're
coming
across
a
project
for
the
first
time,
and
it
does
not
have
that
information
and
a
surprising
number
of
cncf
projects,
don't
for
contributor
growth,
whose
meetings
this
afternoon
for
documentation
and
progress.
F
We've
got
the
recruiting
playbook
we're
almost
done
with
the
contributor
ladder
template,
even
though
we
haven't
officially
published
it.
Yet
a
couple
of
projects
have
have
used
our
draft.
The
contributor
ladder
again
is
the
one
that
says
you
know
you
do
these
things
and
you're
a
contributor.
You
do
these
things
in
your
reviewer.
C
F
F
C
F
A
And
paris
is
making
a
note
about
like
their
reserve,
mostly
for
cubecon
activities.
We
really
try
to
be
able
to
cut
down
the
amount
of
emails
that
we
send
out
to
the
maintainer
groups,
because
there
are
things
that
are
like.
I
really
need
to
respond
by
this
deadline
and
if
it
starts
getting
missed
because
there's
a
whole.
F
Well,
part
of
it
is
we
want
to
get
the
contributor
site
up,
because
I
feel
once
the
contributor
side
is
up,
and
all
of
this
information
has
a
published
location.
That
is
not
just
this
document
inside
a
github
repo
that
will
probably
get
more
eyeballs
and
thus
more
feedback
on
it,
particularly
from
newly
selected
projects,
who
are,
after
all,
the
ones
who
need
our
help.
The
most.
C
Yeah-
and
I
also
I
think
I
I
completely
see
the
point
of
waiting
until
we
have
things
live
before
we
start
trying
to
point
too
many
people
at
them,
but
I
also
think
that,
on
a
considered
basis,
an
occasional
basis,
if
we've
got
really
useful
information,
we
should
use
those
mailing
lists.
You
know
we
don't
it's
not
going
to
be
spamming
them
if
we've
got
like
here
is
some
really
cool
resources
that
we
think
you
might
find
useful.
F
C
G
It's
it's
lee
here,
the
so
I've
long
been
very
excited
about
contributor
strategy,
but
I've
yet
to
offer
up
meaningful
feedback
now
might
be
I'm
trying
to
hold
myself
publicly
accountable.
Now
might
be
an
advantageous
time.
There's
a
couple
of
well
there's,
there's
a
couple
of
smaller
or
burgeoning
projects
that
are
mostly
being
advanced
through
the
cncf
service
mesh
working
group,
which
is
a
working
group
within
sig
network.
G
A
couple
of
these
projects.
On
the
last
time
we
met
this
past
week
there
were
maintainer
nominations
and
which
is
a
reflectance
upon
governance
for
those
projects
and
sort
of
the
contributor
ladder
for
those
projects,
neither
of
which
are,
I
don't
think,
are
necessarily
explicitly
stated,
and
so
the
two
projects
that
I'm
referring
to
one
of
them
is
service
mesh
performance,
the
other
one
is
get
nighthawk
and
both
of
these
are
potential.
G
I
don't
know.
If
I
don't
know
if
this
is
potential.
Guinea
pigs,
for
you
know,
what's
been
laid
out
by
contributor
strategy,
so
I'll
offer
that
up.
So
speaking
of
the
yeah,
oh
nice,
good,
I've
unleashed
paris,
so
I'm
good
within
the
so
there's
the
so.
The
service
mesh
working
group
within
sig
network
has
a
few
different
cross
project
initiatives.
We've
spoken
of
these
in
the
past.
This
is
where
much
of
our
time
during
the
bi-weekly
meetings
is
spent,
has
been
sort
of
advancing
these
three
initiatives.
G
One
on
service
mesh
conformance,
which
helps
smi
move
forward
in
it,
has
a
specification
as
one
that
can
you
can
measure
the
conformance
of
each
individual
surface
mesh
with
there
will
be
there'll,
be
some
of
that
shown.
I
think
inside
the
smi's
virtual
booth
at
cubecon,
the
service
mesh
performance
has
seen
an
uptick
from
some
kind
of
folks
at
an
intel
who've
been
bringing
their
knowledge
to
bear
on
the
on
both
the
spec
and
some
of
their
their
prior
work
in
the
space.
G
G
So,
hopefully
they'll
be
up
for
review
next
month,
along
with
project
reviews.
One
of
the
projects
within
sig
network
kgb
was
just
reviewed
this
this
last
last
week
and
and
accepted
into
sandbox
it.
If
you
haven't
seen
kgb.
I
just
you
know
briefly.
I
might
suggest
that
you
do.
Its
scope
is
fairly
focused
and
it's
its
use.
Cases
are,
I
would
say,
pretty
helpful,
fill
in
unmet
kind
of
unmet
niche
niche
specific
in
a
kubernetes
native
way.
G
G
G
And
yeah
and
the
sig
has
a
deep
dive
scheduled
at
cubecon.
I
think
the
last
item
here
to
maybe
highlight
is:
oh
there's
been
we've.
I've
spoken
of
this
a
couple
of
times,
really
there's
probably
a
need
for
assistance
here,
and
that
is
with
respect
to
a
service
mesh
usage
survey,
maybe
ideally
done
in
coordination
with
the
end
user
group
and
the
radars
that
go
on
there's
been.
C
G
C
C
G
G
So
so,
if
the
performance
of
a
given
environment
is
running
at
a
mesh
mark
of
85
great,
that
can
be
articulated
in
two
seconds.
You
know
with
all
of
that,
that
spec
detail
behind
it
and
so
service
meshes
like
console,
have
been
early
proponents
of
this
type
of
a
specification
so
that
they
can
speak.
You
know
fairly,
or
I
think,
both
fairly
and
accurately,
to
customers
who
are
adopting
that
mesh
and
to
be
able
to
say
to
be
able
to
empower
them
to
to
sort
of
speak
in
this
common
format.
F
C
C
B
B
Right
yeah,
the
reason
for
asking
that
question
is
cncf
runs
a
formal
program
for
conformance
of
kubernetes,
where
people
upload
their
results
and
then
somebody
gives
them
a
thumbs
up.
Somebody
from
cnc
gives
them
the
thumbs
up
and
say:
yes,
you
can
do
this
and
it
looks
good.
So
if
you
have
to
set
up
a
formal
program
of
that
sort,
then
there
is
more
work
to
be
done
on
the
cncf
side
to
to
set
up
and
run
that
program.
That's
what
I
was
asking.
Oh.
G
Sure,
nice
yeah
that's
very
much
desired
by
the
that's
my
project
itself,
there's
been
there's
a
prelude
to
that.
There's
been
some
some
work
with
the
tooling
that,
basically,
this
is
something
of
a
sona
boy
for
smi.
There's
been
work
done
with
the
tooling
to
help
verify
guarantee
provenance
of
the
results
and
integrity
of
them
as
they're
sent
in,
but
but
very
much
so
to
you
to
what
you
were
saying
like.
H
Yes,
and
also
just
to
reinforce
the
one
at
one
point
from
sig
network
just
now,
there
is
tremendous
user
interest
in
having
specification
for
both
transport
and
for
for
everything
which
is
testing
off
of
implementations,
speed
compliance,
everything
we
are
seeing
this
in
in
prometheus,
left
and
right
there
is.
There
is
substantial
interest
from
from
end
users,
so
I
think
it
would
make
sense
to
to
pursue
this
sorry
for
the
noise,
so
things
we
were
able
to
close
with
the
help
of
toc.
Thank
you
again.
H
H
Alina
and
cornelia
pulled
the
rest
or
the
remaining
parts
of
that
document
to
themselves
with
the
stick,
obviously
supporting
where,
wherever
they
need
support
so
yeah.
That
is
basically
the
the
2021
work
package
or
the
major
blocker
for
slick
observability
done.
So
we
are
now
focusing
on
the
other
stuff.
H
There
is
a
document
on
how
to
do
cloud
native
observability,
which
has
already
seen,
I
think,
easily
a
dozen
different
companies
and
people
giving
input
on
on
how
that
on
how
to
do
a
proper,
observability
101
down
in
depth
like
from
the
beginning
to
the
real
implementation.
And
what
to
be
aware
of
the
other
thing
is
a
white
paper
on
how
to
do
tracing
from
the
end
user
perspective,
which
is
currently
in
the
works
on
janitorial
level.
C
You,
I
think
your
other
liaison
is
harry.
Yes,
that's
probably
yeah,
okay,
great!
So
if
anyone
else
it's,
I
think
there
are
a
few
potential
candidates
that
kind
of
between
us
some
of
us
have
identified
for
that
might
be
suitable
for
sick
observability.
If
anyone
knows
of
anyone
else
who
the
sig
should
potentially
be
talking
to
for
those
roles,
you
know
now
is
a
good
time
to
to
put
their
names
forward.
Maybe
talk
to
richie
about
that,
but
yes,
we'd,
like
to
fill
those
seats
pretty
promptly.
I
think.
I
Hey,
it's
ricardo
hope
everyone
is
doing,
okay,
so
yeah.
So
we
have
a
few
projects
that
we
have
reached
out
and
also
presented
in
our
meetings.
Send
the
containers
and
runtime
space
we
had
ssvm,
which
is
a
web
assembly
runtime.
That's
complete
they've
also
decided
to
apply
for
sandbox
and
I
think
they
applied,
but
they
they
might
get
accepted
in
the
next
sandbox
review
meeting.
So
I
think
that
there
were
some
questions
for
them
to
get
accepted
in
another
initiative.
I
I
I
The
difference
with
some
of
the
container
runtimes
is
that
this
is
written
in
rust,
so
we'll
see
how
that
compares
to
some
of
the
other
runtimes,
so
some
progress
there
and
using
rust
another
project
that
we
reached
out
to
is
in
native.
This
is
a
project
that
allows
you
to
create
binaries
small
binaries
from
web
assembly
modules,
so
you
can
run
them
at
the
edge
and
so
they're
presenting
on
april
15th.
I
So
it's
interesting
way
of
using
webassembly
and
then
might
be
useful
for
edge
type
of
workloads.
They
said
that
they're
using
this
for
right
now
to
run
binaries
for
xbox
at
the
edge,
so
so
we'll
find
out
more
from
the
presentation
and
another
runtime
that
we
reached
out
to
is
fizzy.
This
is
written
in
c
plus,
and
you
asked
me,
which
is
a
webassembly
interpreter
cool,
so
so
that's
for
container
runtimes
in
in
in
in
the
mlaps
edge.
I
I
ai
iot
space,
a
couple
of
projects
that
we
reached
out
for
machine
learning.
One
of
them
is
tfx.
This
is
from
tensorf
the
tensorflow
community
in
there
presenting
on
june
17th,
so
they're
still
a
couple
of
months
out
but
they're
interested
in
presenting
they
said.
They'll
go
live
around
that
time
and
another
project
similar
to
tfx's
ml
flow,
and
this
is
backed
by
the
folks
from
databricks
they'll.
I
So
you
know
we
have
that
kubecon
eu
session
and
there's
some
other
events
that
are
related
to
the
sick,
that
I
mean
they're
not
directly
related
to
the
sick.
But
you
know
there
there's
some
relationship
there
with
the
cloud
dating
one
someday,
there's
a
collaborative
rust
day,
kubernetes
ai
day
and
kubernetes
on
edge
day.
B
I
A
I
C
C
J
Hello,
hey,
it's
brandon,
so
quick
update
for
six
security,
a
couple
couple
things
that
are
coming
up
and
you
know
some
asks
for
the
sake
we
had
the
retrospective
survey
from
the
security
white
paper.
That's
now
out,
so
we're
getting
feedback
from
you
know
what
other
people
think
about
the
white
paper.
What
do
you
want
to
see
more?
What
are
some
topics
that
we
should
cover?
J
J
K
J
It's
going
to
be
kind
of
like
a
glossary
of
the
different
terms
in
security
for
cloud
native,
so
it's
a
reference
that
people
can
point
back
to.
So
this
is
one
of
the
next
efforts
that
are
going
to
be
moving
forward,
so
we
have
a
team
of
about
eight
contributors
now,
so
it's
a
it's
pretty
people
are
pretty
excited
about
this
and
the
last
big
update
on
the
projects
that
we
have
now
is
we
have
the
software
supply
chain
vapor.
J
So
this
is
to
add
a
bit
of
contacts.
This
is
really
looking
at
securing
the
supply
chain,
as
well
as
creating
a
secure
software
factory
in
which
we
can
build
the
artifacts,
so
the
white
vapor
has
reached
kind
of
near
the
final
drafts,
and
so
we're
gonna
send
out
a
company
to
review
of
that
so
keep
an
eye
out
for
the
email,
we'll
probably
be
sharing
that
and
the
sick
mailing
list.
J
So
also
it's
a
special
update.
We
have
is
we
we
got
given
award
for
most
effective,
deaf
sec,
ops,
team
of
2020
from
the
devsecond,
so
that's
around
the
award
is
for
the
work
that
we've
done
with
the
white
paper,
the
work
that
we've
done
with
the
the
different
efforts,
all
together
in
six
security
and
and
the
kind
of
last
update,
which
is
isn't
really
on
the
slide.
But
we
we
have
a
new
project
board
which
I'm
going
to
link
into
on
the
chat.
J
K
C
K
Has
has
vacated
zheng
has
been
a
member
of
the
cncf
storage
sick
for
for
a
long
time,
one
of
the
original
members,
in
fact,
and
was
also
co-author
of
the
white
paper
and
I'm
sure
a
lot
of
you
also
know
her
from
the
kubernetes
storage
sig,
where
she's
a
co-chair
there
and-
and
you
know,
various
other
open
source
projects.
So
we
we
would
very
much
like
to
nominate.
K
Whilst
on
the
trc,
I
wanted
to
give
a
quick
update
on
the
the
projects
that
are
going
through
the
review
process,
the
the
longhorn
project,
we're
kicking
off
the
dd
process
with
saad
following
the
feedback
we
had
from
the
toc
we're
going
to
make
sure
that
we
provide
additional
information
during
the
daily
process
on
sort
of
the
differentiation
between
longhorn
and
some
of
the
other
projects
chubbu
of
fess,
which
is
a
distributed
file
system.
That's
also
going
through
the
incubation
process.
K
Open
ebs
we've
had
some
updates
from
from
the
project
team.
We're
going
to
make
we're
going.
Gonna
have
a
final
meeting
with
the
team
which
which
we're
back
to
schedule
and
and
then
we'll
provide
a
final
recommendation
from
the
sick
to
the
to
the
toc
to
to
to
cover
of
sort
of
any
outstanding
issues
or
or
any
concerns
that
we
might
have.
K
And
then
we
have
ongoing
work
on
two
documents
that
we're
building.
One
is
a
disaster
recovery
document
which
still
needs
some
work
but
but
hopefully
we'll
have,
but
but
we
have
a
draft
open
for
comments
and
hopefully
we'll
we'll
get
some
additional
feedback
before
kubecon
and
the
performance
and
benchmarking.
My
paper
is
also
open
for
comments.
There's
some
final
cleanup
to
be
done,
but
we
hope
to
to
finalize
before
before
cubecon
as
well-
and
there
was
a
there-
was
a
note
on
the
toc
mailing
list
about
the
twc.
C
E
C
Things:
okay,
I
had
a
quick
any
other
business
and
we
discussed,
I
think,
back
in
february
the
idea
of
adding
a
requirement
to
for
incubation
and
graduation
projects
to
have
some
form
of
documented
security
processes.
We
don't
want
to
say
what
they
have
to
be.
We
just
want
to
say
they
should
have
processes
for
people
to
report
security
issues
and
for
addressing
security
issues
within
a
project,
I'm
just
flagging
it
up
in
case.