►
From YouTube: CNCF TOC Meeting 2021-03-02
Description
CNCF TOC Meeting 2021-03-02
A
A
A
A
A
A
A
B
B
B
Oh
liz,
one
housekeeping
note:
the
only
sig
that
didn't
have
slides
today
was
a
contributor
strategy.
So,
if
they're
here
I'll
maybe
push
them
to
the
end,
not
sure
okay,
is
there
a
placeholder
for
them
or
are
we
I've
dropped
them
from
the
deck,
but
there's
the
placeholder
is.
If
I
see
them
I'll
flag,
you
down.
B
A
What
do
you
think
shall
we
give
it
a
whirl?
Let's
do
it
all
right,
welcome
everyone
to
today's
toc
meeting,
all
the
usual
preamble
you've
made
it
and
I'm
sure,
maybe
we'll
update
that.
So
mostly
we
are
here
for
sig
updates
and
before
we
get
into
sig
updates
amy,
do
you
want
to
say
anything
about
the
renaming
of
cigs
it's
still
in
voting?
That
is
what
I
am
saying
about
it.
The
vote
is.
B
B
A
We
had
a
discussion
on
it.
I
think
it
was
the
last
public
meeting,
if
I
recall
correctly,
and
the
idea
is
to
avoid
confusion
with
kubernetes
sigs
and
kubernetes
sigs
got
there
first,
so
it
seems
only
fair
for
cnc
f6
to
come
up
with
a
different
name
and
the
name
under
proposal
is
technical
advisory
groups.
I
believe
and
there's
a
bit
more
detail
and
discussion
in
the
github
issue.
A
Also
of
note,
we
talked
a
bit
about
the
possibility
of
holding
votes
on
github
rather
than
on
the
mailing
list,
and
we're
using
this
particular
vote
as
an
experiment
to
see
how
that
whole
process
goes
and
how
people
like
that.
So
I
guess
once
that
vote
is
closed.
We
should
put
something
on
the
agenda
to
just
discuss
whether
we
liked
that
format
for
voting.
D
Hello,
everyone
as
almost
fields
in
school
always
have
to
go
first,
because
you
have
the
first
letter
in
the
alphabet,
so
some
project
updates
on
our
side.
So
there's
a
lot
going
on
now
again
on
the
project
front,
argo
requested
to
move
to
graduation.
So
this
is
an
interesting
one
for
us
in
app
delivery,
because
it's
actually
the
first
project
that
wants
to
move
to
graduation
with
insect
app
delivery.
There
were
already
some
commands,
especially
regarding
ci
batches
from
justin.
D
D
D
D
The
last
one
was
just
added
by
harry
in
here:
no
co-host
is
looking
for
sandbox
and
they
will
also
be
presenting
so
localhost
being
a
cloud
native
development
in
environment,
more
or
less
on
the
working
groups
that
we
have
the
operator
working
group.
The
artwork
is
heavily
underway
for
the
operator
white
paper
and
by
the
next
in
the
next
two
weeks.
D
We
expect
to
see
the
first
version,
so
the
first
bits
and
pieces
are
starting
to
appear
right
now,
it's
all,
obviously,
on
github
already,
what's
there,
the
github's
working
group
no
update
from
them
so
far
and
then
on
another
activities
that
are
not
in
here.
There's
some
organizational
updates
here,
so
we
have
to
do
also
some
organizational
work
in
the
in
the
working
group.
Obviously
we
had
a
hairy
move
from
into
that
uc,
which
means
that
he
said
I
was
stepping
down
as
the
co-chair
for
seek
app
delivery.
D
Brian
is
stepping
down
as
well
and
as
we
have
some
then
also
to
see
a
small
change
is
coming
up.
There
is
some
organizational
work
in
at
delivery
that
needs
to
be
taken
care
of
going
forward
and
obviously
we
will
reach
out
to
the
proper
people
and
how
we
can
get
new,
especially
the
co-chairs
in
there.
I
think
the
tlc
liaisons
are
pretty
obvious.
We
want
to
keep
so
the
harry
offered
himself
already,
which
is
quite
obvious.
D
D
D
E
F
I
think
at
least
it
will
be
great
if
you
can
help
a
little
bit
here,
so
I
I'm
hoping
to
see
maybe
at
least
one
culture
here
to
co-work
with
alloys
in
the
future,
I'm
still
working
in
only
six
after
the
race
things,
but
I
need
to
spend
some
time
on
the
tlc
side,
so
I
think
it's
good
to
have
a
new
candidate
here.
Another
thing
I
want
to
bring
up
is
flux
incubation,
it's
right
now
under
voting,
but
it
has
been
taken
for
a
while.
G
G
Oh
fair
enough,
very
good,
well
so
insig
network,
we
have
been
having
a
fair
bit
of
participation
over
the
last
three
or
four
times
that
we've
met.
So
it's
been,
it's
been
pretty
nice
there's
a
lot
of
the
activity
and
the
participation
has
been
on
initiatives
within
one
of
the
working
groups,
the
service
mesh
working
group.
G
So
we
we
have
generally
take
care
of
some
some
sig
network
business
relatively
quickly
in
part,
because
we
really
just
had
one
outstanding
project
for
a
while
under
review,
and
that
project
is
well
the
project
formerly
known
as
ambassador.
It's.
You
know
now
known
as
emissary
ingress,
and
so
it
is
proposed
for
incubation
and
it
is
out
for
a
public
review.
I
think,
as
of
a
day
or
two
ago
or
here
very
recently.
G
So
that's
a
call
for
all
of
you
on
the
phone
and
not
on
the
phone
to
go,
show
your
support
or
or
lack
thereof,
for
emissary
ingress.
Please
go
out
and
please
go
out
and
vote
for
ambassador.
I
guess
is
what
I'm
saying
get
out
and
vote
all
right,
so
that
that's
sig
network
apologies
didn't
mean
to
make
confusion.
There
of
a
lot
of
the
activities
that
have
been
going
on
in
the
sig
network
have
been
in
the
service
mesh
working
group.
G
There
are
four
or
five
initiatives
within
that
group,
so
just
as
a
quick
recap
about,
I
think
it
was
three
weeks
or
so
ago.
The
group
went
through
a
review
of
service
mesh
patterns,
there's
about
60
of
them
that
have
been
described
about
the
functionality
of
service
meshes
and
how
how
people
can
take
what
the
patterns
are
for
using
those
those
functions.
G
There
was
a
demonstration
of
the
open
application
model
and
meshery
demonstrating
some
of
a
couple
of
those
patterns,
though
the
following
week,
we
ended
up
doing
a
review
of
get
nighthawk
nighthawk
the
load
generator
for
that's
under
the
envoy
project.
Some
exciting
new
features
coming
to
that
project
and
get
nighthawk
is
an
attempt
to
well
get
nighthawk
into
people's
hands
more
easily.
G
Other
items
that
we
discussed
inside
the
service
mesh
working
group
are
well
from
the
smi
team
or
smi
maintainers,
there's
been
an
ask
for
there's
been
an
ask
for
some
assistance
on
feedback.
I
think
both
on
server
the
use
of
service
meshes
so
a
little
bit
of
a
call
and
ask
of
the
sig
to
either
collaborate
on
if
there's
an
upcoming
rate,
end
user
radar
on
service
mesh
to
either
collaborate
there
or
to
try
to
facilitate
a
different
another
survey.
G
A
more
in-depth
survey
focused
on
service
mesh
things
that
smi
the
the
maintainers
group
is
looking
for
feedback
on
where
to
where
to
focus.
There's
been
a
recent
proposal
to
for
them
to
focus
on
multi-cluster
today,
if
you're
familiar
with
smi,
it
covers
four
different,
has
four
different
specifications
covering
different
functionality
that
you
can
use
a
service
mesh?
For
I
mean
that
is
yet
to
cover
multi-cluster
things.
So.
A
G
I
think
generically
that's
an
agreeable
statement
like
oh.
That
makes
a
lot
intuitive
sense
to
me
that
you
would
the
the
gr
or
knowing
a
little
bit
of
the
background
here.
The
group
is
responding
to
asks
from
people
who
are
showing
up
to
the
meeting
saying
hey
this.
I
think
there
was
one
user
in
particular
that
showed
up
and
said:
istio
is
refactoring
how
it's
approaching
some
of
the
way
that
it
does
multi-cluster
and
that
approach
doesn't
necessarily
work
for
that
that
particular
user.
G
The
way
that
they've
deployed
kubernetes
the
way
that
they
manage
namespaces
that
had
to
do
with
the
fact
that
they're
reusing
the
same
name,
space
across
multiple
clusters
and
istio's
multi-cluster,
was
expecting
that
name
spaces
are
globally
unique
and
so
anyway,
I
think
the
group
to
respond
to
a
well-placed
comment
from
josh
is.
I
think
the
group
is
more
or
less
responding
to
to
people
that
are
showing
up
and
asking
questions
about
multi-cluster
support,
but
it's
a
good.
H
Give
some
quick
status
on
the
sick
observability,
so
I
will
try
to
be
quick.
The
main
focus
right
now
is
the
collaboration
with
open
telemetry.
On
the
incubation
proposal
that
was
proposed
couple
weeks
ago.
We
have
huge
amount
of
good
discussions
on
on
technical
levels,
adoptions
and
so
on,
and
the
project
is
such
such
large
that
yeah
it
takes
some
time,
but
I
would
like
to
invite
everyone
as
well
to
join
us
comment
on
the
on
the
document.
H
We
are
creating
and
and
kind
of
give
your
opinion
and
also
some
suggestions,
for
you
know
how
to
make
open
telemetry
better,
so
kind
of
this
is
our
main
focus
right
now.
We
also
work
on
some
white
paper
for
observability.
I
forgot
to
add
that
to
the
slides,
sorry
and
kind
of
related
to
this
incubation,
I
would
have
an
open
question
to
to
the
toc,
and
maybe
you
know
the
community
here
is
that
open
telemetry
is
very
unique
project
right.
H
We
usually
had
you
know
all
our
project
that
moved
from
sandbox
moved
to
sandbox
first
and
then
to
incubation
and
graduation
being
somewhat
ready
and
ready
in
terms
of
all
the
core
components.
All
the
core.
You
know,
goals
of
the
project
well
were
the
were
defined
adopted
fulfilled.
So
we
could.
It
was
easy
to
assess
this
right
right
now.
H
Open
telemetry
is
very
unique
on
this
field,
because
tracing
is
very
well
adopted
very
well,
you
know
constructed
the
apis
are
solid
and
you
know
very
much
using
cloud
native
solutions,
but
other
other
signals
like
metrics
and
logics
logging
are
kind
of
starting
up,
and
you
know
getting
this
motion,
but
not
getting
there.
Yet
it's
not
like
stable
and
adopted
and
very
well
aware.
So
I
wonder
you
know
if
it's
a
requirement
for
incubation
or
maybe
only
for
graduation.
H
So
this
is
like
an
open
question.
We
we
kind
of
the
main
question
right
now.
Have
I
guess
so
I
we
would
love
feedback
on
that,
but
maybe
before
this
let
me
give
yeah
the
upcoming
agenda
items
so
something
on
future.
We
want
to
focus
on.
There
is
white
paper
on
tracing
side
for
the
very
beginners
level
kind
of
guide,
how
to
start
with
with
an
open,
telemetry
and
other
tracing
projects,
and
we
are
talking
about
streaming
apis
and
how
to
observe
those
so
yeah.
That's
the
status
from
the
observability.
A
A
H
Exactly
exactly
sorry
for
bringing
that
up
to
now,
I
think
richie
asked
me
also
to
say
that
he
was
supposed
to
send
some
email
about
this,
but
he
forgot
so
yeah.
Let's,
let's
discuss
this.
I
feel
it's
very
it's
very
fuzzy
at
this
point
and
there
might
be
some
suggestions
for
you
know
there
might
be
some
recommendation
we
can
make.
I
know
open
telemetry
really
want
to
be
consistent
across
multiple
signals,
so
they
don't
want
to
incubate
like
one
project,
one
part
of
the
project
and
others,
maybe
later
so
yeah.
A
I
Yeah,
I'm
happy
to
provide
a
little
bit
of
context,
so
there
there's
two
different
aspects:
open
telemetry.
One
is
like
the
core
components
so
think,
like
instrumentation
libraries,
that
you
add
to
your
application
and
the
second
is
a
collector
component,
so
think,
like
an
agent
you
deploy
that
collects
and
processes
data,
so
those
core
concepts
exist
in
opensymmetry
today
and
are
leveraged
pretty
extensively.
I
It's
it's
pretty
dispersed,
thus
kind
of
the
question
around
the
different
signals
and
to
be
fair,
these
are
not
the
only
three
signals.
More
are
going
to
be
added
to
open
symmetry
over
time,
so
the
project
will
kind
of
expand
and
scope,
but
this
is
kind
of
the
the
initial
focus
for
for
the
project.
A
A
I
Maturity
and
we're
thinking
about
it.
Similarly
right
so
semver
is
followed
for
the
different
signals
themselves,
so
kind
of
a
similar
model
to
kubernetes,
and
yes,
additional
things
will
be
added,
so
you
have
to
be
able
to
mark
like
what
you
can
depend
on
versus
what
we'll
have
breaking
changes,
for
example.
So
that's
the
approach
that
the
project's
taking
currently.
C
H
Yeah,
I
think
it
makes
sense
just
just
from
my
side.
I
think
you
know
product
doesn't
need
to
be
perfect.
That's
for
sure
there
are
experimental
things.
However,
my
perception
was
and-
and
you
know
maybe
I'm
wrong-
is
that
you
know
that
the
signals
observability
signals
are
kind
of
you
know
have
equal
importance,
let's
say
so.
If
logging
and
and
metrics
are
not
yet
well
not
yet
defined.
H
J
Yeah,
I
I
believe
our
requirement
for
a
project
moving
from
sandbox
to
incubation.
One
of
our
major
requirements
is
that
they
have
to
have
three
users
with
it
being
implied
that
those
are
production
users,
so
yeah
and-
and
I
think
I
think
this
is
a
good
example
of
why
that's
still
a
good
benchmark,
because
you
know
is
too
much
undefined
is
enough
to
find
or
whatever
honestly
the
users
can
decide
that
right.
J
K
Also
because
some
of
those
things
if
they're
not
actually
defined,
may
also
have
dependencies
on
other
things
or
ip
policy
issues
or
all
sorts
of
other
things,
because
they
just
haven't
been
ironed
out
yet.
So
I
would
probably
caution
it
back
about
you
know.
If
a
project
has
a
dozen
repos,
you
probably
want
to
actually
specify
which
repos
or
which
components
are
specifically
joining
as
a
cncf
project.
L
K
D
Even
if
the
rest,
never
materializing
the
project
in
itself
has
value,
it
has
has
an
option.
Well,
actually,
the
the
metrics
part.
I
know
it's
also
adopted
by
very
bigger
end
user
organizations
already
just
that
logging
part
is
not
there,
so
I
think
we
have
some.
That's
also
why
we
have
like
tech
leads
and
the
cdss
technical
risk
of
things
not
actually
turning
out.
D
The
other
risk
is
that
we
won't
find
people,
then
the
other
is
organizational
risk.
Nobody
actually
working
on
it
well,
logs
do
not
exist.
I
think
how
to
write
a
logging
signal
library
excuse
my
hybrid
feedback.
It's
not
like
really
rocket
science
yeah.
This
has
been
done
before
it's
not
just
standardized
there.
It
might
take
longer
from
an
organization
point
to
find
people
to
actually
work
on
it
and
to
have
like
the
overall
agreement.
I
think
a
lot
of
this
is
really
in
the
assessment.
D
It's
a
bit
of
a
gray
zone,
and
we
will
just
see
this
higher
velocity
like
for
our
goals,
like
the
key
parts
of
the
project,
are
already
mature
enough
for
flux.
They
have
a
very
good
plan
to
move
from
version,
one
to
version
two
there's
a
lot
of
industry
momentum
in
there.
People
are
already
already
moving
there.
D
I
think
there
is
no
hard
criteria
and
I
think
the
standard
project
criteria
do
not
really
help
that
much
here
and
like
technical
vision
and
technical
stability
of
the
ideas
behind
it
is
not
really
even
a
criteria
for
the
project.
Maybe
that's
something
to
add
in
there
at
least
have
a
statement
on
assessment
by
where
I
was
reviewing.
It.
A
M
Hey
hello,
everyone!
Well,
okay,
so
we've
been
having
presentations.
We
had
a
couple
of
presentations
last
month,
so
some
updates
on
some
of
the
projects
that
I
had
mentioned
on
the
previous
meeting.
So
we
had
on
the
containers
and
runtime
space.
Sysbox
is
a
project
that
allows
you
to
run
containers
in
bm
or
day
containers
that
look
like
vms.
M
So
it
allows
you
to
run
full
workloads
that
would
run
in
the
ends
with
systemd
and
you
can
even
run
kubernetes
clusters
inside
the
container
so
pretty
interesting
project.
They
had
a
presentation
early
month,
so
another
project
that
presented
is
trout
and
that's
container
image
registry
and
the
difference
with
some
of
the
other
registries
that
are
around
is
that
this
one
is
written
in
rust,
so
they're
targeting
use
cases
that
are
looking
for
a
kind
of
faster,
lighter
weight
image
registry.
M
M
They
reply
to
our
invitation
and
they're
also
looking
at
presenting
another
run
time
or
whether
something
run
time
that,
and
I
think
their
focus
is
on
having
high
performance
workloads,
other
webassembly
runtimes.
We
have
westmore
swam
watson
time.
Some
of
them
we
reached
out
question
time,
hasn't
replied
yet
so,
hopefully
you
know
we
get
them
to
present
at
some
point
in
the
operating
system
space
in
the
meeting
next
this
month
or
the
not
the
one
thursday.
M
M
M
A
E
Hello,
everyone,
some
quick
updates
for
you
all.
Today
we
have
the
secure
supply
chain
working
group
issue,
number
510.
They
are
rapidly
moving
forward
with
a
supply
chain,
security,
white
paper.
It's
been
scoped,
we
have
a
documented
schedule
and
we're
looking
for
a
final
release
of
that
paper
before
kubecon,
so
keep
an
eye
out
for
a
call
for
community
review,
we'll
be
sending
that
out
to
our
sig
list
as
well
as
probably
the
cncf
list.
We
were
successfully
able
to
merge
the
translation
of
the
cloud
native
security
white
paper
into
chinese.
E
E
E
We're
going
to
also
be
sending
out
a
call
to
action
for
that
requesting
both
content
and
development
opportunities
from
the
community
to
contribute
to
this
really
awesome
effort.
But
the
biggest
update
of
all
is
that
we
have
updated
our
process
based
off
of
the
past
five
security
assessments
that
have
been
performed
and
the
feedback
from
the
projects
that
underwent
those
assessments.
E
We're
now
calling
them
security
reviews
to
avoid
a
lot
of
the
community
confusion
that
community
experienced
going
through
this,
but
we've
also
made
some
changes
to
the
overall
process
to
better
align
with
the
maturity
level
of
projects
moving
through
the
cncf
ecosystem.
So
we've
got
some
big
updates
there.
Lots
of
changes,
please
check
out
the
changes
in
our
repo
under
the
assessments
readme,
and
we
also
have
a
current
proposal
to
more
formally
align
these
new
changes
with
the
cncf
phases
and
that's
under
pr
534.
K
K
Shang
again
has
a
lot
of
background
in
in
storage.
Is
a
really
strong
technical
lead
and
has
been
involved
in
the
sig
for
probably
a
couple
of
years
honestly
since,
since
we
first
started
so
so,
we'd
like
to
nominate
these,
these
two
people
for
tech
leads,
I'm
gonna
follow
up
with
an
email
to
the
toc
mailing
store.
Perhaps
I
don't
know
if
this
should
be
another
one
of
those
that
goes
into
a
github
issue
for
voting,
but
I'll
I'll.
Take
your
lead
on
that.
N
N
F
K
So
the
the
longhorn
project,
we
really
need
to
click
off
the
dd
process.
I
need
to
follow
up
with
which
side
on
that
ciarabo
fs
are
currently
in
sandbox.
They
are
proposing
to
to
move
to
incubation
they
presented
to
the
sig
just
last
week.
We're
we're
getting
together
to
to
review
a
few
of
the
items
and
we
should
be
able
to
make
a
recommendation
shortly
and
open.
Ebs
is
some
other
discussion,
but
we
haven't.