►
From YouTube: CNCF TOC Meeting 2021-09-07
Description
CNCF TOC Meeting 2021-09-07
A
A
C
C
E
E
Who
was
the
other
one
dims
justin?
I
think.
C
It
is
perfectly
fine,
we
are
not
to
my
knowledge,
taking
a
vote
in
this
meeting,
so
we
should
be
fine
on
that.
Thank
you.
E
G
The
captain
project
also
presented
for
incubation
in
the
sick,
but
is
waiting
for
to
get
the
sponsor
from
from
the
tse
right
now,
but
most
of
their
work
is
done
and
they're
also
waiting.
G
Who
is
the
tt
sponsor
for
dapper
I'll?
Let
you
know,
I
think
it's
dims,
but
I
might
be
wrong.
Hey
that's
news
to
me
dennis
lee
sorry
this
is
harry.
He
sang
here.
Harry
is
the
sponsor,
so
you
were
sponsoring
another
one,
so
it
was
just.
It
was
a
couple
of
projects,
but
we
have
you
here,
so
you
could
verify
that
one
yeah
on
the
deliverable
side,
the
chaos
engineering
white
paper-
is
slowly
moving
along
here,
we're
also
still
working
on
the
charter
for
the
working
group.
G
So
the
team
has
started
to
work
on
that
one.
Our
demo
approaches
from
the
the
potato
head
project
for
showcasing
all
the
app
delivery
projects
within
and
beyond.
The
cncf
gained
more
momentum
again.
So
currently,
the
project,
which
used
to
be
a
single
service,
which
is
only
of
limited
value,
obviously
to
show
distributed
service
updates,
has
now
been
kindly
updated
to
distributed
services
and
currently,
all
the
examples
for
all
cncf
projects
are
getting
updated
as
well.
G
This
also
helps
the
work
which
we
are
then
doing
on
the
cooperative
delivery
use
cases
where
we're
then
using
the
examples
to
provision
on
the
one
and
the
application
and
the
underlying
infrastructure,
with
all
the
cncf
projects
that
are
out
there
on
the
working
groups,
they
cooperative
delivery
working
groups
with
a
working
group
that
specifically
deals
with
how
app
delivery
infrastructure
delivery
and
the
processes
in
between
fit
together
has
the
draft
charter
available
under
the
link
here
we
also
send
it
to
the
toc
mailing
list
to
get
approval.
G
Some
of
you
have
already
voted.
Some
have
not
yet
voted.
So
if
you
have
any
questions,
please
let
us
know
and
if
you
have
not
voted
yet
it
would
be
great
to
get
your
vote
and
on
the
engineering
side
it
is
still
a
work
in
progress.
So
but
then
we
should
have
the
working
group
charter
finished
rather
sooner
than
later
as
well.
So
that's
it
from
app
delivery.
Any
questions.
H
At
least
question
the
cooperative
delivery
working
group
is
that
is
that
one
in
the
same,
is
that
formerly
known
as
the
get
ops
working
group.
G
No,
that's
not
the
smoking
group,
that's
the
one
that
deals
with
the
problem
that
app
and
infrastructure
delivery
are
often
disconnected,
and
you
have
to
have
a
lot
of
handovers
a
lot
of
dependencies
who
is
it
gotcha?
Okay,
having
that
situation
that
in
many
kubernetes
use
cases,
some
cluster
is
also
provisioning,
the
underlying
infrastructure
and
there
are
dependencies
and
requirements.
So
it
was
mostly
driven
by
folks
working
on
the
infrastructure,
side
and
problems
that
went
with
on
the
upside
again.
This
is
the
best
name
we
could
come
up,
for.
G
We
just
came
up
with
cooperative
because,
like
really
bringing
infrastructure
and
f
ops
together
and
ensuring
that
something
you
actually
write
in
your
yaml
files
on
the
application
site
can
later
on
be
deployed
on
the
infrastructure,
because
storage
classes
are
supported,
networks
are
supported
and,
if
not,
you
can
check
it
actually
before
deploying
it
instead
of
having
it
in
some
cases,
fail,
silently
or
not
not
work
at
all,
so
that
that's
what
they're
dealing
with
again
naming
is
hard,
as
liz
pointed
out,
but
at
least
everybody
remembers
it
because
nobody
ever
gets
to
think
of
it
twice
what
it's
doing,
but
that's
what
it's
what
it's
about.
G
I
think
eventually
there's
also
four
sig
network
things
that
come
into
play
like
with
blue
green
deployments,
and
things
like
this
when
we
start
to
work
on
this.
H
Yeah
not
to
imply
that
the
other
working
groups
aren't
cooperative,
but
one
other
question.
If
I
mind
do
you
have
a
sense
of
like
how
much
of
the
focus
of
the
working
group
is
on
the
softer
the
human
side
of
things
like
the
softer
side
of
there
being
an
infra
team
and
an
apps
team,
and
and
and
how,
how
centralized,
yaml
or
a
single
file
that
describes
concerns
for
both
teams?
H
Like
I
guess,
what
I'm
trying
to
figure
out
is
how
much
of
the
focus
is
on
soft
psychological,
human,
gui,
sticky
things
versus.
G
Stuff,
obviously,
at
the
end
of
the
day,
oh
humans
have
to
write
those
yaml
files
in
most
cases,
but
that's
not.
No.
I
think
it's
a
combination
of
both
it's
really
the
processes
that
these
different
teams
have
like
looking
into
different
release,
cycles,
their
processes
and
how
they
work
with
how
their
work
and
get
things
done
out
there,
but
the
focus
is
still
very
much.
How
can
we
produce
artifacts
and
have
processes
that
these
artifacts
eventually
work
together?
G
G
If,
at
that
later
point
in
time,
we
come
up
with
something
that's
more
related
to
okay.
This
is
how
your
team
should
work
together,
or
this
is
what
we
have
actually
found
people
working
together.
We
had
a
longer
discussion,
also
to
not
just
obviously
come
up
with
the
white
paper
by
ideas
that
we
have
within
the
working
group.
Part
of
our
work
is
also
to
talk
to
people
and
companies
who
are
doing
this
already
at
scale
and
getting
their
best
practices
and
how
to
make
this
work.
G
So
we,
the
plan,
is
not
to
like
reinvent
the
wheel
because
we're
having
a
collection
of
all
of
the
good
practices
that
are
already
available
there
and
if
more
processed
and
organizational
stuff
will
fall
out.
I
think
it
will
find
its
way
to
some
document,
but
right
now,
it's
really
about
the
hard
technical
issues
that
you
might
run
into,
or
that
people
used
to
run
into
by
running
kubernetes-based
workloads
and
having
like
this
infrastructure
and
app
side
of
things.
F
G
Getting
started
guides
also
best
practices,
so
there's
a
lot
of
dots
but
the
red.
The
white
paper
is
like
the
bigger
one,
but
also
like
how
you
get
started,
which
type
of
tests
you
could
be
running,
giving
people
an
overview.
So
the
interesting
thing
here
is
on
the
chaos
engineering
working
group.
It
became
evident
very
early
on
that.
This
is
not
just
something:
that's
related
to
app
delivery.
G
It's
an
activity
that
spans
multiple
working
groups,
so
we
immediately
started
obviously
talk
to
networking
because
of
network
chaos,
then
to
security,
about
security,
chaos
and,
obviously
for
doing
all
of
those
chaos
related
works.
You
also
want
to
know
whether
the
system
actually
can
deal
with
the
carers
or
not,
which
then
directly
brings
you
to
observability
as
well.
So
I
think,
there's
also
a
lot
of
work.
G
That
site
brings
all
those
people
together,
which
is
also
why
it
takes
a
bit
longer
like
to
get
the
working
group
like
form,
because
it's
a
lot
of
people
that
are
involved
in
there,
but
people
very
actively
from
the
different
teams
take
part.
G
I
think
it's,
the
combination
of
a
platform
and
an
app
team
working
together
so
that
it
like
kind
of
really
works,
works
pretty
well,
so
the
people
we
have
in
there
are
those
that
are
used
to
be
on
both
sides
like
the
ones
building
the
applications
and
the
ones
building
the
platform.
And
it's
a
lot
of
the
things
that
usually
don't
go
well
together.
G
There
are
a
couple
of
examples
in
the
in
the
charter
in
there
like,
for
example,
you
use
people
assume
that
it
because
in
their
deaf
environment
they
have
storage
classes
available
that
suddenly
are
not
available
in
the
production
environment
or
a
certain
version
of
an
application
requires
certain
infrastructure
components,
all
the
way
down
to
cloud
resources
to
be
provisioned,
which
are
usually
not
part
of
the
application
definition
but
of
the
platform
definition.
But
you
still
have
this
dependency
in
your
application
code
in
there.
G
So
how
you
can
model
these
kind
of
things,
especially
as
people
start
to
use
the
tooling,
but
what
kind
of
became
obvious?
We
have
tools
pretty
much
for
everything
and
we
could
do
everything
we
needed.
So
we
can
even
use
kubernetes,
ncrd
and
various
projects
that
are
out
there,
like
akd,
even
provision
cloud
resources,
but
it's
it's
almost
like.
There's
the
infrastructure
and
some
extent
platform
side
and
then
there's
the
application
side.
But
there's
like
no
common
view
of
like
bringing
those
together
ensuring
that
they're
working
together
nicely.
H
At
work,
all
right,
we
have
a
new
co-chair,
ed
warnicky.
H
There's
yes,
yes,
this
has
been
a
long
time
coming
good
ed,
so
many
of
you
gave
some
positive
plus
ones
to
the
suggestion
that
edward
would
come
in.
He
he's
we
stand
to
breathe
some
new
life
and
into
the
what
cig
network
is
doing,
and
hopefully
I'm
deliver
on
part
of
the
the
charter
of
well
geez.
I
just
said
sig
network,
but
of
what
tag
network
is
doing
and
boy
what's
worse,
is
that
some
of
you
didn't
catch
it?
H
I
think
that's
even
worse
and
and
make
sure
that
we're
on
a
rotational
basis,
inviting
in
various
projects
within
the
tag,
also
various
working
groups
within
kubernetes
to
have
a
form
of
exchange
or
just
there's
a
lot
that
goes
on
between
the
projects
and
not
everyone
always
has
time
to
exchange
some
of
those
thoughts
and
things
so
particular
to
networking.
H
There's
there's
a
fair
bit,
there's
a
fair
bit
going
on
there's
so
anyway,
that's
part
of
the
charter
is
to
and
we
we
haven't
done
a
whole
lot
of
that
and
that's
primarily
based
on
bandwidth,
so
welcome
ed.
H
The
what
what
the
what
we
have
been
able
to
spend
time
on
is
in
the
service
mesh
working
group.
There's,
I
guess
a
couple
of
thing
items
highlighted
so
under
the
surface
mesh
performance
group,
the
folks
at
intel,
a
couple
of
folks
at
intel,
red
hat
and
layer.
Five
have
in
coordination
with
ken
owens,
drafted
a
publication
for
ieee.
If
you're
interested
in
that
sort
of
thing,
there's
there's
a
link
to
the
final
draft
and
that
talks
about
approaches
to
performance
measurement
in
context
of
a
service
mesh.
H
So
next
item
up
was
the
one
of
the
programs.
One
of
the
initiatives
inside
of
that
the
service
mesh
working
group
is
that
of
smi
conformance
and
so
since
last
we've
met
here.
Both
open
service
mesh
is
a
merge
away
from
reporting
their
conformance
on
a
release
by
release
basis,
so
so
that
that's
great
they're
kind
of
getting
into
into
the
system
by
which
they
would
automatically
report
conformance
nginx
service
mesh
had
been
joining
the
calls
most
recently
and
is
also
now
manually
reporting
their
conformance.
But
so
that's
great.
H
The
last
item
last
highlighted
item
here
is
just
on
the
topic
of
service
mesh
patterns
and
identifying
best
practices
for
various.
You
know:
pieces
of
functionality
that
service
meshes
offer
characterizing
those
into
a
service
mesh
agnostic
pattern.
So
there's
a
some
of
that
effort.
Will
fruit
or
will
be
demonstrated
at
service
mesh
con?
So
that's
nice
for
those
that
have
been
working
on
the
patterns.
F
Lee
quick
question:
what
is
the
overlap
or
you
know?
How
do
you
work
with
the
say
the
cnf
working
group.
H
Yeah,
oh
yeah,
good
question.
So
by
the
way,
is
the
cnn
parking
group
under
any
tag?
That's
what
I
was
asking.
I
think.
H
H
You
know
formalize
and
advance
a
component
of
what
they
discussed
or,
like
the
the
the
I
think,
primarily
like
testing
and
analyzing,
a
performance
of
cloud
native
network
functions
and,
and
hence
the
working
group
cnf
working
group
and
had
kind
of
a
little
while
ago
looked
been
had
proposed.
That
working
group
looked
for
a
home
sort
of
between
app
delivery,
tag,
app
delivery
and
tag
network
and
and
became
established.
H
I
don't
know
that
they
necessarily
hang
out
in
one
of
the
two
groups
you
per
se,
the
good
that's
on
the
maybe
the
softer
side
of
sort
of
organizationally,
the
I'm
talking
about
a
lot
of
gooey
and
hard
things
today.
I
don't
know
why,
but
anyway,
on
the
harder,
more
technical
side
there
is
well.
I
think
the
genesis
of
that
working
group
having
come
from
the
telco
user
group
or
tug
should
is
an
indication,
should
indicate
like
that
yeah
a
lot
of
the
there's,
a
distinction
in
they
are
service.
Mesh
providers.
H
I'm
sorry
service,
mesh,
they're
service
provider
focused
a
more
like
so
so
vnfs
and
cnfs
are
of
that
of
that
genre
of
networking,
if
you
will,
which
is
touch,
is
up
against
but
is
distinct.
It's
nuanced
very
nuanced,
but
it's
distinct
from
some
of
the
more
enterprise-centric
use
cases
of
how
some
of
the
other
projects
are
used.
So
I
it
like
is
uses
a
lot
of
the
same
network
words,
but
the
folks
that
are
interested
are
the
use.
H
Cases
and
those
that
are
involved
are
end
up
being
highly
highly
related
highly
like.
If
you
take
a
look
at
the
performance
tests
that
are
being
done
in
this
cnf
working
group
and
those
are
being
done
in
like
the
service
mesh
performance
project,
maybe
they'll
meet
on
5g
or
like,
but
right
now
the
the
the
type
of
applications
and
the
type
of
network
functions
that
are
being
analyzed
are
they're
running
in
different
environments
under
different
things
and
they're.
Hence
using
different
test
harnesses
and.
F
Yeah,
I
I
understand
that,
thanks
for
the
detail,
you
know
how
everybody
is
related
to
each
other.
The
reason
for
asking
this
question
is
like,
in
the
end
they
use
all
the
projects
that
come
from,
like
you
know,
under
the
tag
network.
F
F
H
E
I
think
I
know
from
the
early
days
of
it
being
set
up.
The
the
user
group
were
very
keen
on
having
those
discussions
without
vendors
present,
and
I
guess
that's
why
it's
a
separate
group,
that's
separate
from
you
know
tsi,
because
toc
groups
don't
have
restrictions
on.
You
know
they're
open
to
anybody,
so
I
guess
that
may
be
historically
why
it's
in
that
user
group
side.
But
I
completely
agree
if
there
was
like
overlap
between
personnel
who
were
involved
in
that
user
group
and
in
tag
network.
That
would
be
really
useful.
H
A
point
of
quick
clarification:
just
I
don't
know
if
there
is
a
there's,
I
think
you
know
there's
sort
of
three
inter
three
groups
here,
the
end
user
service
smash
working
group
which
get
to
liz's
point
is
vendor
free.
Actually
they
had
reached,
I
actually
just
presented
at
their
last
meeting.
They
were
really
curious
about
some
of
the
projects
that
are
going
on
here
and
and
so
yeah
vendor
free
the
the
service
mesh
working
group
here
vendored,
but
then
the
cnf
working
group,
I
think,
is
what
dims
is
yeah.
Okay,
cool.
A
No
so
yeah?
We
also
have
a
third
co-trainer
lolita
sharma
of
aws.
She
wants
to
just
devote
it
in
last
month,
but
she's,
not
here
to
say
hi,
but
she's
in
also.
I
think,
matt
had
a
few
points.
Also
we
had
a
break
in
or
just
over
to
you
met
for.
For
the
rest,
I
think
you
put
that
in.
I
Yeah,
the
third
one
there
should
be
gone.
I
think
I
I
timed
it
wrong
when,
when,
when
the
meeting
started
that
that
that's
that's
for
the
future,
as
richie
said
we're
coming
back
from
august
break,
we've
got
a
new
co-chair.
We're
very
excited
about
that.
Lolita
joins
us
and
brings
quite
a
bit
of
domain
expertise
as
well
as
vision
and
and
experience
building
communities,
so
so
we're
extremely
psyched
and
enthusiastic
about
that.
I
We
have
our
first
meeting
in
an
hour
just
after
this
and
we'll
be
revisiting
where
we
were
back
in
july.
So
we
have
a
number
of
work
streams.
Everything
from
the
youtube
channel,
which
I
think
we
can
do
a
lot
more
with,
as
well
as
we're
gonna
be
looking
to
recruit.
Additional
tech
leads
this
fall.
I
So
if,
if
anyone
has
recommendations
or
referrals,
please
pass
them
along
to
one
of
the
co-chairs
or
and
that's
pretty
much
it
we'll,
keep
it
short
and
sweet
today
we're
looking
forward
to,
I
guess:
q4
fall.
However,
you
want
to
place
it.
E
Okay,
any
other
questions
for
observability
folks.
H
J
Hi,
everyone
yeah,
so
some
quick
updates
for
tag
runtime.
We
had
some
presentations
in
our
meeting
so
in
the
containers
and
runtime
space.
We
had
this
presentation
for
confidential
containers.
The
folks
are
working
on
confidential
computing.
They
have
this
new
project
and
they're
thinking
about
applying
for
sandbox.
This
is
a
project
backed
by
a
lot
of
big
companies.
Intel
apple,
red
hat,
ibm
amd,
so
a
lot
of
a
lot
of
backing
from
this
project.
So
this
is
a
way
to
run.
J
J
So
in
the
machine,
learnings
machine
learning
edge
artificial
intelligence
space,
so
we
had
a
presentation
from
volcano.
This
is
a
project
that
allows
you
to
run
batch
workloads
on
top
of
kubernetes.
The
presentation
is
about
incubation,
so
they're
trying
to
go
for
incubation
and
they're
looking
for
a
sponsor
a
toc
sponsor.
So
if
anyone
interested
in
sponsoring
to
take
this
project
forward,
it
tackles
an
area
that
there's
where
there's
a
gap.
You
know
in
terms
of
batch
workloads
for
kubernetes
another
project
that
we
had
our
presentation
from.
J
What's
ml
flow,
this
this
is
end-to-end
machine
learning
and
it's
a
really
big
project.
It's
similar
to
qflo,
so.
J
Very
a
very
large
community,
so
hopefully
we
get
some
interest
from
those
folks
to
you
know
to
participate
more
in
the
cncf
activities,
cube
dl's,
another
project
in
sandbox
in
the
cncf,
and
it
allows
you
to
run
deep
learning
workloads
so
so
taking
your
model
from
training
to
production.
J
So
it's
currently
in
sandbox,
so
they're
looking
to
grow
and
possibly
go
into
incubation
sometime
in
the
future
and
finally,
in
this
space
that
we
reached
out
to
the
mlobs
community,
so
we're
asking
for
more
participation
so
that
we
have
more
in
this
space.
You
know
projects
they're
interested
in
presenting
in
our
meetings
and
for
tag
runtime
activities
we're
still
working
on
a
logo.
J
So
that's
in
progress,
hopefully
we'll
have
that
ready
in
the
next
few
weeks
in
the
container
orchestrated
device
working
group
renault,
which
was
the
main
chair
of
the
working
group
stepped
down,
so
alex
kanetsky
from
intel,
will
be
handling
most
of
the
activities,
and
we
have
some
interest
from
the
confidential
containers
community
that
possibly
they
want
to
create
a
working
group,
but
that's
in
progress
so
that
may
come
after
they
apply
for
sandbox
and
finally,
for
kubecon.
J
North
america,
in
china
we
have
tag
sessions,
tag
runtime
sessions,
so
we
want
to
get
more
exposure
and
and
hopefully
get
more
people
involved
and
the
the
one
in
north
america
is
going
to
be
an
in-person
session
and
yeah.
That's
that
that's
all
for
the
updates
happy
to
take
any
questions.
F
Thanks
ricardo,
one
sorry
go
ahead,
less.
E
J
Yeah,
so
it's
this
it's
the
same
community,
but
they
kind
of
containers
could
be
one
of
the
components
that
they
they
can
use,
but
they
they
can
use
other
runtimes,
other
vm
type
of
runtimes.
So
there's
also
a
proposed
lift
k
run.
I
think
that
will
actually
make
it
possible
to
run
confidential
containers
so
so
yeah.
So
it's
there's,
there's
some
overlap
and
in
in
a
way,
but
it's
not
exactly
the
same.
Okay,.
J
F
Yeah
the
one
question
I
had
ricardo
is
awesome.
Folks
right,
there's
a
bunch
of
awesome
projects
under
in
how
are
they
working
with
each
other
or
how
are
they
cooperating?
Is
there
any
anything
going
on
where
yeah
folks
are
talking
to
each
other.
J
Yeah
we
had
a
few
projects
present,
so
in
the
last
one
was
wasn't
cloud
liam
randall
is
the
lead
for
for
that
project
and
they
he
actually
set
up
the
the
cloud.
Wasn't
they
event
at
the
kubecon,
so
I
he's
actually
in
contact
with
some
of
those
folks,
but
we,
I
think
it
would
be
a
good
idea
to
maybe
reach
out
to
them
and
see
if
there's
something
that
we
can
do
in
terms
of
like
creating
a
working
group
but
yeah
we
didn't.
J
J
But
liam
working
on
wasn't
cloud
has
actually
started
with.
You
know
the
wasn't
cloud:
wasn't
they
even
in
the
idea,
there's
also
to
get
more
participation
from
the
community
and
more
traction
in
some
of
those
projects.
K
Hey
hey,
so
we
have
just
one
update,
but
it's
a
big
update.
We
finally
brought
to
completion
the
assessment
of
cloud
native
build
packs.
This
has
been
going
on
for
quite
some
time
since
april
of
last
year,
extremely
high
praise
for
the
diligence
and
rigor
from
the
maintainers
of
cloud
native,
build
packs
and
how
responsive
they
were
throughout
the
whole
process
entire
length,
and
they
were
absolutely
prompt
to
resolve
any
questions,
respond
to
any
feedback
that
the
assess
that
the
assessors
had
for
them.
K
A
couple
couple
notable
things:
while
the
the
project
is
watertight,
two
different
dimensions,
one
is
well
the
the
outputs
of
build
packs.
The
container
images
that
are
generated
using
build
packs
tooling
do
a
lot
of
assurance
to
abide
by
container
security
best
practices.
K
K
Reproducibility
of
these
artifacts,
then
the
the
other
layer
is
how
well
the
project
follows:
secure
development
best
practices,
while
we're
doing
the
assessment,
we're
able
to
do
the
cii
best
practices
for
the
project,
and
it
was
just
a
breeze
feeling
all
filling
out
all
the
security
criteria
because
they
were
meeting
it
already,
notably
in
addition
to
that.
The
project
team
also
started
signing
their
lifecycle
images
using
cosign
and
generating
cyclone
dxs
bonds
for
for
their
releases.
K
So
all
in
all,
really
good
assessment.
We're
about
to
merge
it
soon
we're
playing
a
little
bit
with
the
google
docs
api
to
export
all
resolved
comments.
So
people
get
more
visibility
and
transparency
into
what
were
they
assessed
against?
What
was
the
kind
of
feedback?
How
did
they
responded
to
it?
They
did
put
a
lot
of
effort
in
and
rewarding
this
the
assessment
itself,
so
the
questions
wouldn't
arise
in
first
place,
so
the
assessment
document
as
it
stands
should
be
a
good
enough
reference
with
that.
K
The
the
recommendation
to
cncf
is
to
circulate
that
assessment
as
a
vehicle
to
improve
awareness
of
of
the
project
and
how
it
compares
in
contrasts
to
ecosystem
alternatives.
When
it
comes
to
security
properties,
that's
it
for
the
assessment,
some
administrative
stuff.
K
Regarding
assessments,
we
were
a
little
bit
backtracked
with
other
assessments
that
that
were
in
the
in
the
pipeline
ahead
of
this
one,
also
that
the
project
of
due
diligence
for
incubation
bypass,
the
security
assessment,
kind
of
influenced
that
we
didn't
have
a
really
strong
sense
of
urgency
to
to
knock
this
one
out
from
the
get-go
and
it
kind
of
became
victim
to
other
priorities.
So
yeah
determining
whether
assessments
are
mandatory
for
due
diligences
would
would
help
us
triage
and
prioritize
these
better
and
then
with
well.
K
It's
been
it's
been
a
hard
year
for
everyone,
so
lots
of
job
changes,
lots
of
people
taking
leave
and
that
that
also
affected
a
little
bit
of
the
length
of
of
the
whole
assessment,
but
well
once
again
should
be,
should
be
checked
in
pretty
soon
we'll
send
an
update
to
the
group
once
it
is
happy
to
take
any
questions.
If
there.
E
K
My
understanding
is
yes,
there
is
almost
zero
heavy
lifting
involved
and
it's
quite
swappable
as
as
you've
said,
I
also
have
matthew
giasa,
who
was
involved
in
in
the
assessment
matthew.
I
don't
know
if
you
can
speak
more
detail
to
that
else,
we'll
just
defer
it
to
the
to
the
project
team
and
come
back
with
their
response.
K
E
You
know:
can
people
use
their
existing
registry
and
just
be
storing
bill
packs
in
the
same
registry,
and
you
know
like
what's
the
process
for
people
to
move
to
build
packs?
Okay,
they
may
already
have
that
documented
somewhere.
But
that's
that's.
My
kind
of
initial
reaction
to
that
recommendation
is
okay.
If
it's
easy
for
people
to
to
make
this
change,
let's
let's
encourage
it,
but
I
think
we
need
to
understand
what
that
process
of
making
the
change
involves.
L
Fair
one,
one
of
the
things
that
I
think
is
really
interesting
about
this-
is
that,
in
practice,
the
build
packs
are
are
most
often
maintained
by
the
platform
team,
which
is
one
of
the
ways
that
things
get
more
secure
is
because
you've
got
a
platform
team
who
often
take
on
the
responsibilities
for
security
and
then
organization.
L
Maintaining
these
build
packs,
essentially
maintaining
the
image
building
process,
and
then
we
have
app
teams
that
just
use
them.
I
think
that,
what's
so
interesting
is
the
parallel
to
the
conversation
that
eloise
was
talking
about
earlier,
when
he
was
talking
about
yaml
and
platform
teams
and
app
teams.
There's
there's
a
crossover
from
there.
There's
a
relationship
to
what
we're
talking
about
here
with
build
packs,
so
build
packs,
are
a
very
specific
technique
that
I
think
addresses
that
coordination
and
that
cooperation
between
the
platform
team.
L
G
G
I
think
they
still.
The
unresolved
issue
is
what
about,
like
all
the
other
yaml
configurations
that
go
beyond
just
a
container
image,
and
we
have
seen
some
projects
that
have
interesting
approaches
there,
as
well,
conceptually
very
similar,
like
you
can't
use
the
pure
yaml
and
anymore.
You
just
get
access
to
a
value
files
from
all
these
predefined
templates.
I
think
there's
also
some
interesting
developments
there
and
where
people
build
these
higher
level
components
in
kubernetes.
G
Like
you
can
say,
I
have
a
service
and
I
wanted
to
have
it
exposed
to
the
internet,
and
this
is
where
my
image
is
coming
from.
This
is
my
url
just
parameters
like
this
a
non-cncf
project.
We
were,
for
example,
talking
to
was
gimlet
a
very
small
but
interesting
project,
but
very
well
received,
and
also
by
those
platform
teams,
because
they
can
say
well,
you
can
build
whatever
you
want
to
dear
application
developer,
but
this
is
what
it's
supposed
to
look
like.
These
are
the
network
policies
you
need
to
have.
G
These
are
the
network
routes.
These
are
the
the
security
rules
that
need
to
be
there.
So
I
think,
there's
a
similar
concept.
It
exists
as
well.
That's
not
yet
part
of
build
packs,
but
but
buildback's
fit
in
there
as
well,
but
that
other
area
will
also
be
one.
G
I
think,
where
we'll
see
more
more
and
more
people
working
in
the
direction,
because
conceptually
that's
what
bill
pecks,
do
they
more
or
less
that
you
just
keep
the
application
specific
parts
and
the
rest
is
injected
underneath
and
also
updated,
automatically
and
and
similar
things
for
configuration
artifacts
like
whether
it's
humble
purim
or
health
church.
I
think
we
will
see
a
more
of
that
as
well
from
a
simplicity
and
a
security
perspective.
So
that's
exactly
the
direction
which
we're
looking
into
as
well.
J
J
You
know
part
of
their
work
that
they're
doing
is
actually
you
know,
pulling
out
like
an
encrypted
image
or
encrypted
workload
artifact
and
making
it
run
in
a
secure
way.
So,
there's
there's
overlap
with
app
delivery,
runtime
and
security
there,
and
possibly
storage
too.
You
know
how
you
store
securely
store
your
containers
right.
So
it's
kind
of
like
it's
a
very
interesting
space.
E
Yeah,
I
I
feel
quite
ignorant
about
what
the
kind
of
process
is
here
for
people
who
want
to
move
to
to
build
packs,
or
that
involves.
I
think
that
could
be
a
really
interesting
thing
to
understand,
because
it
sounds
like
build.
Packs
are
a
good
thing
and
solve
some
problems,
particularly
for
security,
so
yeah.
K
K
They
do
a
great
job
writing
up
like
the
intended
use
and
as
cornelia
was
saying,
they
do
highlight
very
well
like
the
shared
responsibilities
model
and
how
like
platform
and
app
teams
are
meant
to
cooperate
through
build
packs
and
like
what
responsibility
falls
on
on
whose
side,
so
they
do
have
quite
a
bit
of
of
that
in
writing
and
like
these
assessments,
are,
are
great
for
that
purpose.
F
So
a
quick
question
here,
keying
off
of
what
liz
was
saying
and
what
is
in
the
text
that
is
being
presented.
So
the
assessment
team
strongly
suggests
educating
awareness
of
the
project
right.
So
what
tools
do
we
have
in
cncf
that
we
can
help
make
this
happen?
I
guess.
K
Yeah
of
of
the
services
provided
to
to
projects,
depending
on
on
the
tier
they're
in
there
are
a
number
of
like
information,
dissemination
or
like
marketing
opportunities,
be
it
webinars,
be
it
social
media,
be
it
well,
let's,
let's
take
from
this
assessment,
the
those
parts
that
we're
we're
talking
about
of
like
hey,
how?
How
do
you
migrate
from
this
to
that?
And
why
would
you
in
first
place,
like
writing
up
the
value
prop
like
really
crisp
and
really
succinct?
K
So
it's
not
like
a
10
or
12
page
document,
I
think,
can
can
go
a
long
ways.
These
are
just
ideas
and
I'm
spitballing
here,
because
I
hadn't
anticipated
that
question
and
it's
something
throughout
assessments
we
find
in
the
summer
we
always
suggest
like
hey.
Let's
do
a
little
bit
more
marketing
for
for
this
project
that
might
be
like
an
expert
level
system
and
not
like
the
rest
of
the
ecosystem
is
not
aware
for
any
number
of
reasons.
E
So
I
hope
we
can
put
that
into
their
court,
but
you
know
with
support
from
cncf
that
we,
because
from
everything
I'm
hearing
this
sounds
very
positive
and
it
probably
involves
things
like
you
know:
how
do
we
get
people
to
use
examples
that
use
build
packs
instead
of
docker
files?
And
how
do
we
get
people
to
you
know
just
as
they're
talking
about
delivering
applications?
G
Yeah,
that's
I
remember
from
the
due
diligence
review
and
I
don't
want
to
do
them
wrong.
It
might
have
changed
in
between.
I
think
they
could
put
a
bit
more
into
especially
the
examples
because
I
know
when
I
was
reviewing
it.
They
had
the
examples,
but
they
were
not
necessarily
most
useful
ones
if
you
would
just
wanted
to
build
your
container,
but
that
might
have
been
changed
since
the
due
diligence,
but
I
I
agree.
I
think
this
is.
G
I
think
it's
a
bit
of
more
of
a
learning
curve
if
you
want
to
do
it
with
build
packs
than
with
your
docker
file,
but
I
think,
as
soon
as
you
move
to
a
reasonable
structure
of
your
docker
file
and
take
care
of
security
concerns,
the
additional
effort
is
well
worth
it.
Actually,
it
becomes
less
and
obviously
b
would
be
worth
it.
So
I
agree
with
your
list.
I
think
maybe
having
more
examples
on
how
to
use
build
packs
instead
of
docker,
especially
right
now.
E
Awesome
well
hopefully,
this
discussion
can
invigorate
the
project
team
to
to
help
come
up
with
some
of
these
examples.
Awesome
any
other.
K
M
Hello,
so
a
bit
of
an
update
on
the
projects
going
through
review,
the
longhorn
project
is
the
dv's
is
completed
and
we've
sent
to
saad
for
review.
He's
he's
provided
a
few
comments
back
last
night
which
we're
just
going
through,
but
that
should
be
done
shortly.
M
M
The
the
team
have
been
getting
some
of
the
licensing
and
copyright
and
variety
of
other
challenges
sorted
out,
which
they
believe
they've
done
now
and
they're
going
to
and
we're
going
to
pencil
in
a
call
with
the
team
next
week
and
then
we'll
be
able
to
make
a
recommendation
as
to
as
to
how
to
proceed
there.
M
Also
on
on
the
project
reviews,
one
one
of
the
one
of
the
things
that
sad
has
asked
us
for
is
to
to
to
get
guidance
on
how
to
deal
with
multiple
sort
of
multiple
solutions
and
sort
of
trying
to
come
up
with
a
strategy
for
for
for
how
we
decide
and
compare
which
ones
should
be
incubated
and
graduated,
whether
you
know
it's
all
of
them
or
some
of
them
or
or
or
how
we
differentiated
them.
M
So
we're
going
to
discuss
that
on
the
on
attack
call
tomorrow,
but
also
sort
of
I'd
love
to
open
it
up
to
the
floor.
If,
if
there
are
any,
you
know
particular
bits
of
feedback
that
the
toc
could
share
there
and
then
finally,
the
we've
been
working
on
a
couple
of
documents.
M
The
cloud
native
disaster
recovery
dock
is
is
done
and-
and
I
think
we're
we're
kind
of
ready
to
release
that
now
and
we
have
the
performance
of
benchmarking
white
paper,
which,
which
sort
of
had
a
bit
of
a
stall
for
a
few
months.
But
now
nick
has
picked
this
up
and
has
reviewed
the
draft
and
we've
got
the
final
section
to
be
finished
off
and
and
then
I
think
we're
done
and
it
should
be
ready
in
time
for
kubecon.
E
Great
thank
you,
so
I
I
guess
you
asked
for
thoughts
about.
You
know
how
we
deal
with
this
situation
of
three
kind
of
similar
projects.
You
know
and
how
we
evaluate
the
the
three
I
mean
for
me.
What
I'd
love
to
see
is
what
is
the
difference
between
them?
You
know
what
is
the
clear
air
that
makes
one
different
from
another
and
that
you
know
helps
helps
us
understand.
C
M
So
open
question
you
know,
there's,
obviously
each
of
the
projects
will
have
a
variety
of
you
know,
pros
and
cons,
even
if
they
solve
similar
problems
and
certainly
within
the
cncf.
M
We
we
already
have
a
lot
of
overlaps
in
you
know
different
projects,
whether
it's
you
know
runtime
or
observability
or
or
whatever
else,
and
so
the
question
is
you
know,
is
it
should
we
be
proposing
like
a
recommendation
to
include
or
not
include
one
or
the
other,
based
on
based
on
the
fact
that
they
have
similar
use
cases
or
or
or
should
we
or
should
we?
You
know,
have
multiple
options
like
like
we
have
in
in
sort
of
other
technology
areas
in
the
cncf.
E
So
I
think,
wherever
we
have
multiple
options,
it's
no
bad
thing
to
have
multiple
options,
it's
good
to
give
people
choice
and
we're
trying
not
to
be
prescriptive
and
we're
trying
not
to
be
king
makers,
but
every
time
we
have
multiple
solutions.
It
adds
some
uncertainty
for
end
users
and
if,
if
that
uncertainty
is
is
kind
of
unnecessary,
because
in
fact
no
reasonable
person
would
choose
one
of
those
three
options.
Given
the
other
two,
then
right.
E
Saying
that
that's
the
case
with
these
three,
but
you
know
if,
if
there
were
two
that
were
definitely
better
than
a
third,
then
I
would
much
rather
that
we
don't
try
and
pretend
that
all
three
are
on
the
same
level.
If
that
makes
sense.
But
it's
very
likely
that
all
three
have
some
strengths
at
which
they
excel
or
some
environment,
where
they're
they're
best
suited.
And
if
that's
the
case,
let's
try
and
be
as
clear
as
we
can
to
end
users
to
sort
of
clarify
why
we
think
those
3d
projects
are
worth
sustaining
and
using.
F
I
I
like
that,
unless
what
I
was
thinking
you
know
similar
to
that
was
like,
is
there
like
a
matrix
of
okay
here?
Are
these
are
the
features
and
here
are
the
projects,
and
so
you
have
a
matrix
where
people
can
like
figure
out
like
okay,
based
on
these
things,
let
me
pick,
let
me
start
with
one
of
these,
rather
than
the
other
ones.
E
F
And
then
you
know,
I'm
just
thinking
like
what
is
the
decision
making
process
for
an
end
user
to
go
through
these
projects,
and
would
they
just
pick
one
at
random
or
can
can
we
give
them?
Some
guidance
like
a
like
one
page
matrix
saying
here
are
the
list
of
features
or
list
of
things
that
you
need
to
look
at
here
is
where
each
of
these
you
know,
storage
options
are
useful.
F
You
know
come
up
with
something
that
will
help
them.
Like
pick
the
first
one.
B
Yeah,
hey
alex,
I'm
also
wondering
do
these
projects
have
any
adoption
stats
of
their
own.
You
know,
should
cncf
have
some
kind
of
a
common
service
or
discipline
that
that
tracks
that,
because
you
know
it's
one
thing
for
us
to
evaluate
and
recommend,
but
but
I
mean
these
projects
have
been
growing
on
their
own
for
a
while,
so
they
need
to
be
able
to
demonstrate
some
degree
of
adoption.
Otherwise
I
mean,
I
think
that
I
would
I
think
that
speaks
more
to
the
viability
of
the
project
than
anything
else.
M
I
I
mean
look.
I
agree
with
that.
There's
there
is
sort
of
a
an
implicit
assumption
that
if
the
project
passes
a
due
diligence
at
incubation
level,
that
you
know
there
are
end
users
using
it
in
production
and
adoption,
stats
and
maintainer
stats
and
all
those
yeah.
B
But
I
think
our
all
requirements
are
minimal
right,
like
three
users
or
whatever.
So
so,
if
you
know,
if
one
had
a
millions
of
deployments,
the
other
one
has
a
thousand
deployments,
then
then
it's
pretty
obvious.
You
know
which
one
is
really
leading
so
so
that
that's
what
I
mean
is
there.
Is
there
you.
B
Like
that
would
actually
be
very
helpful
from
from
a
main
user
perspective.
E
Another
sort
of
more
qualitative
assessment
might
be
asking
those
users
why
they
picked
the
ones
that
they
picked.
You
know
were
they,
you
know
if
they
picked
a
was
that,
because
that
was
the
one
they
were
familiar
with.
Are
there
particular
tendencies
within
one
ecosystem
to
pick
one
solution
over
another?
E
M
Well,
yeah,
I
mean
those
are
the
kind
of
the
the
sort
of
things
I
was
referring
to
right.
I
mean
you
know,
assuming
assuming
that
there
are
always
going
to
be
some
differences,
because
obviously
every
product
is
is
slightly
different
and
they're,
presumably
going
to
have
different
users.
M
We
we
seem
to
have
you
know
like
just
off
the
top
of
my
head
container
d
and
cryo,
or
you
know
prometheus
thanos
and
cortex,
or
you
know,
linkardi
and
envoy.
All
all
have
you
know
large
large
overlaps
today
and
the
question
is,
you
know:
do
we
kind
of
standardize
how
we
compare
these
things?
Do
we
standardize
how
we
provide
guidance
for
these
things,
or
I
mean
in
some
cases
maybe
it's
more
clear
cut
than
not
than
others.
I
guess,
but.
E
Yeah,
I
think
we're
going
to
run
out
of
time
to
fully
flesh
out
that
answer.
E
I
do
think
if
there
are
ways
we
can
compare
names
from
tom
has
suggested
about
having
metrics
that
we
can
compare
performance
metrics.
I
I
think
I
don't
think
that's
the
be
all
and
end-all.
I
do
think
if
there
are
metrics
that
would
be
useful.
E
Yes,
indeed,
let's
put
that
on
the
agenda,
yeah
all
right
in
the
last
30
seconds-
I
guess,
if
anyone
who
is
pre,
I
know
most
of
the
people
who
are
sponsors
for
these
are
not
on
the
call.
But
if
anyone
does
have
updates,
please
shout
now.
D
E
All
right
great,
thank
you
all
right,
we're
pretty
much
up
to
the
top
of
the
hour,
so
I
think
we
probably
have
to
call
it
a
day,
but
thank
you,
everyone
for
your
time
and
lots
of
really
useful
discussions
today.