►
From YouTube: CNCF SIG Storage 2020-11-11
Description
CNCF SIG Storage 2020-11-11
A
B
B
A
C
D
C
C
Thanks
alex
I'm
just
struggling
to
oh
here
we
go.
Maybe
that
will
work
now
giving
one.
Second,
I
was
having
some
permission
problems
there
we
go
there
we
go.
Can
you
see
my
screen
good
morning?
Everyone
yeah,
as
alex
mentioned,
a
few
of
us,
got
together
a
few
years
ago
and
tried
to
while
I
was
on
the
trc
at
the
time,
tried
to
kind
of
codify
some
of
the
principles
and
goals
behind
these
the
admission
of
projects
into
and
out
of
this,
the
cncf
and
between
the
various
different
levels.
C
I
didn't
prepare
any
fancy,
slides
or
anything
for
today
I
was
thinking
it
might
be
more
useful
just
to
treat
it
mostly
as
a
sort
of
an
overview
of
the
process
and
drive
it
through
q,
a
from
the
audience
so
so
this
is
the
document
that
we
wrote
some
years
ago
it
it.
First
of
all.
I
must
mention
that
I'm
no
longer
on
the
toc,
so
I
do
not
actually
officially
represent
the
views
of
the
toc.
In
this
regard.
C
C
But
I
think
it's
important
to
understand
that
that
there
are
three
different
levels
of
of
involvement
of
projects
in
the
in
the
cncf.
I'm
sure
most
of
you
familiar
with
these
terms,
but
it's
useful
just
to
recap
on
what
the
overall
intention
of
the
different
levels
of
are
so
the
first
one
is
called
sandbox.
C
So
so
that
was
the
the
overall
goal.
Now
what
that
means
is
that,
essentially,
if
somebody
has
a
good
idea
and
says,
I
think
I've
got
a
good
idea,
and
I
would
like
to
collaborate
with
companies
x,
y
and
z,
to
figure
out
whether
this
good
idea
can
be
turned
into
some
kind
of
useful,
open
source
project
that
could
be
a
sandbox
project
and
so
any
any
sort
of
indication
that
it
has
to
have
code
that
meets
certain
standards
or
certain
commit
rates
or
anything
else
are,
are,
I
think,
misleading.
C
C
There's
no
interest
in
collaborating
on
this
project
or
not
enough
interest
to
actually
get
a
viable
community
around
it,
or
maybe
they
do
get
a
viable
community
router
to
go
and
explore
the
space
and
decide
that
it's
actually
a
bad
idea
and
cancel
a
project,
and
these
are
all
reasonable
and
expected
potential
outcomes
of
sandbox
projects.
Of
course,
another
one
is
that
the
sam
box
project
does
become
something
useful,
that
we
end
up
with
multiple
companies
collaborating
on
a
useful
thing.
C
C
Okay,
good,
so
the
next
level
up
is
is
what's
called
incubation,
and
so
again
you
can
go
to
the
links
and
you
can
see
there
are
specific
criteria,
they're
intentionally
vague.
They
are
designed
so
that
there
is
a
fair
amount
of
latitude
that
the
toc
has
to
exercise
some
judgment
on
deciding
whether
a
given
project
should
enter
the
incubation
lab
or
not.
Oh
one,
one
thing
just
to
go
back
to
sandbox
for
a
moment.
C
One
thing,
that's
very
important
is
that
we
do
not
want
to
create
the
impression
that
by
gaining
a
cncf
badge,
a
project
somehow
becomes
credible
as
a
production
worthy
use
case
that
it
is
somehow
as
good
as
kubernetes
or
as
good
as
any
of
the
other
graduated
cncf
projects.
So
we've
put
some
pretty
strict
ruling
and
rules
around
what
level
of
promotion
a
project
may
receive
within
the
cncf
when
it
is
in
sandbox,
because
we
don't
want
to
create
confusion
by
mixing
up
these
sort
of
nascent
not
yet
developed.
C
Not
yet
mature
projects
with
you
know
clearly
mature
projects
like
like
kubernetes
and
and
the
other
graduated
project.
So
so
there
will
be.
No,
you
know
big
banners,
there
will
be
no
press
releases,
there
will
be.
No,
you
know
socks
with
with
you
know,
sandbox
project
x
on
them
at
the
cncf,
at
least
at
cubecon
events
produced
by
the
cncf
or
or
any
of
the
organization
in
to
the
extent
that
they
are.
These
are
essentially
mistakes.
C
The
intention
is
very
clearly
not
to
promote
to
actively
market
and
promote
sandbox
projects,
but
rather
just
create
a
legal
home
for
them
to
get
started
right
so
progressing
to
the
next
level,
which
is
incubation.
These
are
projects
that
are,
you
know,
still
relatively
new.
They
might
be,
you
know
1.0
or
thereabouts.
C
They
have
a
limited
number
of
users,
maybe
a
few
who
are
starting
to
use
them
in
production.
They
have
an
active
development
community
of
may.
Even
I
think
somebody
correct
me.
If
I'm
wrong,
it
may
even
be
a
single
company
who
has
got
this
thing
to
a
point
where
people
are
actually
using
it
in
production.
C
They
may
not
have
you
know
enormous
numbers
of
users
or
enormous
numbers
of
contributors,
but
they
do
have
a
viable
product
project
that,
in
the
in
the
opinion
of
the
cncf
toc
is,
is
you
know
consistent
with
the
goals
of
the
cncf
around
cloud
native
technology
and
which
they
believe
has
a
potential
to
become
something
that
that
could
get
the
the
real
stamp
of
approval
from
the
cncf?
To
say
this
thing
you
can,
you
know,
bet
your
business
on.
You
can
run
your
business
on
on
this
project.
It's
not
there.
C
Yet
it
doesn't
have
all
of
the
all
of
the
things
in
place
that
the
cncf
would
like
to
have
in
place
to
be
able
to
kind
of
bet
long
term
on
a
project,
but
it
looks
like
it's
getting
there
and
it's
usable
in
production,
at
least
with
limited
use
cases,
and
I
think
that
is
you
know.
That
is
the
point
at
which
we
do.
C
C
Questions:
okay
come
up
along
the
way.
Okay,
so
you
know
there's
there's
a
bit
of
blurb
there.
Basically,
if
you're
doing
a
technical
due
diligence,
particularly
for
for
this
cn
cncf
sig,
your
overall
role
is
to
try
and
gather
all
the
information
that
the
toc
would
be
wanting
in
order
to
make
a
judgment
call
on
whether
a
project
should
or
should
not
be
either
admitted
at
one
of
the
levels,
sandbox,
incubation
or
graduated,
or
whether
it
can
move
from
one
level
to
another.
C
Sandbox
to
incubation
incubation
to
graduation,
you
know
there's
quite
a
lot
of
hard
work
involved
here.
You
know
it
differs
depending
on
the
project,
but
you
know
the
intention
is
particularly
for
an
incubation
level
application
that
you
know
you
should
go
and
look
at
the
source
code.
You
should
go
and
build
the
software.
You
should
go
as
an
ideally
an
expert
in
the
particular
area
that
the
project
covers.
C
You
should
be
able
to
have
a
fairly
detailed
and
informed
opinion
about
the
quality
of
the
code
and
the
people
that
are
using
it,
how
they
are
using
it
how
the
software
development
process
works.
What
kind
of
testing
they
have
is
the
code
in
reasonable
quality
or
not?
Are
there
any
people
in
the
open
source
community
that
are,
you
know,
arguing
and
fighting
about
things?
C
C
Try
it
out,
you
know,
go
and
sort
of
eavesdrop
on
a
few
pr's
and
a
few
pieces
of
you
know
debugging
stuff
or
if
there's
a
cicd
process
in
place,
you
know,
go
and
watch
it
for
for
a
couple
of
days
and
see
what
stuff's
getting
merged
and
what
tests
fail
and
what
tests
exist
and
where
things
have
to
get
backed
out.
Why?
All
of
these
things
are
relevant
to
the
to
the
health
of
a
project.
C
C
The
toc
are,
are
you
know
very
busy
people
they're
very,
very
busy
people
well
they're
on
the
toc,
because
they're
typically
very
good
at
what
they
do.
They
typically
have
a
lot
of
experience
and
know
a
lot
of
things
about
cloud
native
technologies,
and
those
people
tend
to
be
given
a
lot
of
responsibility
in
the
companies
they
work
for
and
hence
they're
very
busy.
So
they
don't
have
the
time
to
do
all
the
work
that
I
just
outlined
to
you.
C
So
that
is
the
job
of
the
of
the
of
the
sigs
the
special
interest
I
drew
a
blank
there.
The
special
interest
groups
are
there
for
precisely
that
reason.
One
they're
more
focused
on
on
particular
areas
of
expertise,
and
this
one
is
the
is
the
storage
cigar
of
course.
So
we
we
gather,
you
know
more
than
one
or
two
people
that
are
very
specialized
or
experts
in
in
a
particular
area,
and
we
do
a
lot
of
that
heavy
lifting
work.
C
So
that's
that's
sort
of
the
model
that
is
that
is
proposed
here
and
there's
a
whole
bunch
of
bullet
points
here,
where
you
can
start
to
make
sure
you
understand
what
the
toc
principles
are.
What
the
project
proposal
process
is
what
the
graduation
criteria
are
between
the
various
levels,
what
the
desired
cloud
native
properties
are-
and
you
know
these
are.
These
are
pretty
foundational
things.
If
you,
if
you're,
not
clear
on
what
those
are,
then
you
won't
be
able
to
do
the
due
diligence
to
any
degree
of
usefulness.
B
Make
sure
you've
read
the
process
just
as
a
just
as
background
as
well.
It's
probably
worth
noting
that
the
the
criteria
are
layered
between
each
of
the
different
levels.
So
you
know
this
kind
of
it's
kind
of
implied
that,
in
order
to
to
achieve
incubation,
for
example,
you
will
have
achieved
all
of
the
criteria
for
sandbox
and
and
likewise,
if
you
do
fully
graduate
you
you
you
have
to
be,
you
have
to
have
all
the
criteria
for
for
incubating
too.
E
C
Yeah,
that
makes
absolute
sense
and
there
is
certain
things
that
are
kind
of
in
violet.
So
so
I
mean
there
are
certain
principles
that
apply
across
all
levels
and
things
like
cloud
native
properties.
You
know
the
the
ability
of
the
system
to
to
service
its
use
case
in
a
scalable
way
on
essentially
commodity
hardware
in
a
cloud
computing
environment.
C
Here's
some
suggestions,
as
other
places
you
might
go
to
with
that
project,
or
that
idea
does
that
make
sense
and
and
the
linux
foundation
by
the
way,
has
has
several
different
foundations
within
it,
which
cater
to
different
areas.
Networking
storage,
telcos,
machine
learning,
et
cetera,
so
it
may
just
be
that
this
thing
is
not.
You
know,
there's
nothing
wrong
with
the
design
of
this
project.
B
B
C
Yeah,
that's
true,
and-
and
actually
maybe
this
is
a
good
time
to
just
have
a
slight
kind
of
diversion.
So
one
of
one
sort
of
syndrome
I've
seen
a
few
times
for
more
than
once,
at
least,
is
that
the
you
know
kubecon
in
particular.
You
know
obviously
less
so
now
that
it's
virtual,
but
but
hopefully
we
will
resolve
that
at
some
point,
but
kubecon
in
particular,
and
the
cncf
in
general
has
been
an
incredibly
successful
vehicle
for
promoting
open
source
projects.
C
Arguably
you
know
the
most
successful
vehicle
available
to
any
open
source
project
it
provided
that
it
fits
into
the
space
and-
and
you
know
the
whole
cloud
native
space,
as
as
all
of
you
are
aware,
is
you
know
on
everybody's
tongues?
So
so
there's
a
there's,
a
very
strong
motivation
for
open
source
projects
to
be
seen
to
be
strongly
affiliated
with
the
cncf
for
a
purely
marketing
and
promotional
point
of
view.
C
On
the
flip
side,
the
cncf
is,
is
really
trying
to
create
a
foundation
or
is
it
has
created
a
foundation
to
a
greater
or
lesser
extent
which
which
helps
the
consuming
environment
that
the
people
using
and
wanting
to
use
cloud
native
technology
to
provide
them
with
it
with
the
same
structure
of
projects
where
they
can
easily
understand?
What
is
what
why
these
projects
exist,
how
they
fit
together,
whether
they
interoperate,
properly,
etc,
etc,
and
so
sometimes
those
two
goals
are
at
odds.
C
It's
got
a
whole
bunch
of
limitations
that
weren't
documented
and
now
I'm
having
a
bad
experience
and
now
cncf
you've
you've
made
my
life
difficult.
So
so,
there's
this
this
kind
of
tension
between
these
two
and
and
to
a
large
extent,
this
due
diligence
exercise,
is
designed
to
resolve
that
tension
and
and
try,
at
the
very
least,
to
clearly
explain
to
projects
why
they
may
not
at
this
time
fit
within
the
cncf
well
or
advise
them
as
to
what
they
could
do
to
change
things.
C
But
just
to
point
out
that
there
is,
there
is
a
bit
of
attention
there
and,
and
part
of
the
due
diligence
exercise
is
to
try
and
resolve
that
tension.
So
here's
a
bunch
of
questions
I'm
just
going
to
rattle
through
them.
This
is
going
to
be
kind
of
boring,
but
hopefully
it
will
trigger
some
conversation
and
questions,
because
these
are
the
explicit
questions
that
you
should
be
asking
yourself
and
noting
the
answers
to
as
part
of
your
due
diligence
exercise.
C
Can
people
you
know
with
a
diagram
understand?
Oh,
this
is
what
this
project
does,
what
are
the
primary
use
cases
and
which
of
them
are
accomplishable?
Now
you
know.
Sometimes
there
are
use
cases
that
are
envisaged
for
the
future,
but
the
project
is
not
ready
to
service
them
today,
which
of
them
can
be
accomplished
with
reasonable
additional
effort
and
are
perhaps
even
already
planned
on
the
roadmap
they'll
be
delivered
in
later
this
year
or
whatever
the
case
may
be
and
which
of
them
are
explicitly
out
of
scope.
C
So
it's
entirely
possible
that
you
have
a
you
know:
data
distribution
system
that
that
is
specifically
designed
for
particular
use
cases,
either
rate
of
churn
of
the
data
or
size
of
the
data
or
whatever.
But
you
know,
distributing
large
blobs
is,
is
explicitly
out
of
scope
or
distributing
things
that
have
you
know
millions
of
subscribers
who
want
to
know
when
the
data
has
changed.
That's
just
not
part
of
the
design
of
the
project.
So
it's
as
important
to
understand.
C
What's
in
scope
as
what
is
out
of
scope
and
and
make
sure
that
these
things
are
clear,
because
if
somebody
wants
to
use,
you
know
a
key
valued
store
to
distribute
their
movies,
it's
probably
not
going
to
work
very
well,
and
sometimes
that's
not
obvious.
When
you
read
the
marketing
blurb
around
the
project,
it
sounds
like
it.
It's
just
awesome
for
everything.
C
What
exactly
are
the
current
performance,
scalability
and
resource
consumption
bounds
of
the
software
so
do
do
the?
Does
the
project
actually
understand
exactly
at
what
point
the
software
breaks
either
performance,
wise,
scalability,
wise
or
resource
consumption
wise
and
have
they
actually
been
tested?
C
Many
of
you
might
remember
that
kubernetes
in
the
early
days
only
actually
scaled
to
like
100
nodes,
and
it
took
a
very
very
long
time,
many
many
years
to
get
it
to
even
a
few
thousand
modes
and
and
those
limits
were
empirically
derived
by
actually
doing
tests
on
some
of
the
stuff,
and
I
don't
know
where
it
stands
at
the
moment.
I'm
guessing
it's
in
the
sort
of
5000
node
region,
but
I'm
not
sure,
but
there's
an
example
of
of
that
kind
of
thing.
C
C
If,
however,
you
have
you
know
replicated
charted
system,
it
may
degrade
in
performance.
You
know
in
a
somewhat
more
graceful
manner.
How
well
understood
are
these
failure
modes
and-
and
you
can
enumerate
them-
you
know
what
happens
when
this
kind
of
node
fails.
What
happens
when
that
kind
of
node
fails?
What
happens
when
this
overloads,
when
the
network
becomes
unavailable
all
these
kind
of
things?
Does
it
fail
gracefully
or
does
it
collapse
in
a
heap
and
corrupt
all
the
data?
There
are
very
big
differences
there.
D
C
Yeah,
absolutely
you
know
one
tension
you'll
find
that
there's
a
lot
of.
If
you
want
to
do
all
of
the
stuff
yourself
manually
it
it's
a
lot
of
work,
and
so
quite
often
what
I
end
up
doing
is
going
to
speak
to
the
project.
Architects
or
the
you
know,
the
leaders
of
the
project
and
get
a
sense
of
whether
they've
thought
about
these
things.
If
they
can
give
me
reasonable
answers.
C
Yes,
we've
tried
that,
and
this
is
what
happens
or
we
haven't
tried
that,
but
but
the
architecture
tells
me
that
it
that
it
would
do
the
following.
That's
often
a
good
enough
answer.
If
the
project
leaders
have
not
even
thought
about
these
things,
then
that's
more
of
a
red
light
to
me,
because
that
indicates
that
they
designed
the
thing
without
even
thinking
about
what
the
failure
modes
would
be,
and
that
often
means
that
they're
pretty
bad.
C
And
that's
you
know
again:
it's
not
your
choice
to
it's,
not
your
place
in
life
to
decide
whether
a
given
architectural
design
is
good
enough.
It's
really
your
place
in
life
to
to
expose
the
details
to
the
toc
in
such
a
way
that
they
can
consume
them
and
perhaps
give
advice.
You
know
this
thing
looked
very
good
to
me.
This
thing
seemed
like
it
needed.
Some
improvement
in
these
areas
is
the
is
this
kind
of
the
mode
of
communication
that
I
would
recommend
trade-offs
around
performance,
scalability
complexity,
reliability,
security,
etc.
C
You
know
there
it's
it's
almost
impossible
to
build
a
system
that
is,
you
know
infinitely
performant,
infinitely
scalable,
very
simple,
highly
reliable
and
fully
secure.
It
just
doesn't
exist.
So
inevitably
explicit
trade-offs
need
to
be
made.
We
decide
that
we're
going
to
make
the
system
more
complex
in
order
to
make
it
more
secure,
maybe
or
hopefully
less
complex,
to
make
it
more
secure.
We
we
trade
off.
You
know
performance
for
reliability,
that's
a
that's
a
pretty
classic
kind
of
trade-off,
so
certain
kinds
of
performance.
C
You
know
central,
centralized,
single
point.
Failure,
relational
databases
are
actually
very
fast.
You
can
do
you
know
amazing
numbers
of
transactions
per
second
per
node
on
those
things
they
just
you
know
when
they
fall
over,
they
fall
over
and
so
so
there's
an
explicit
trade-off.
That
often
gets
made
people
use
less
performance
databases,
for
example,
to
get
better
reliability,
etc.
What
are
the
most
important
holes
in
the
project
like?
Do?
They
know
that
they
have
no
extensibility
or
integration
points,
or
they
don't
have
a
very
good
high
availability
story
at
the
moment.
C
Sometimes
knowledge
of
these
things,
particularly
at
the
incubation
level,
is,
is
good
enough.
You
know
we,
we
know
we
have
this
shortfall,
we're
working
on
it.
That's
part
of
our
incubation
efforts,
it's
still
usable
in
production,
but
there
is
this.
You
know
theoretical
failure,
mode
that
we
don't
like
and
we're
working
on
solving
that.
What
does
the
quality
of
the
code
looked
like.
C
That's
a
that's,
a
very
good
question
and,
first
of
all,
there's
no
checkbox,
and
secondly,
it
depends
very
much
on
what
what
level
we're
talking
about
here.
You
know
if,
if,
if
a
project
wanting
to
graduate
has
an
obvious
single
point
of
failure,
that
is
not
you
know
at
the
very
least,
made
highly
visible
in
big
flashing
letters
on
the
front
page
of
the
product
project.
C
C
C
E
C
E
E
C
Yeah
that
that's
very
good
feedback-
and
I
don't
think
we've
necessarily
tackled
that
specifically
alex
correct
me.
If
I'm
wrong,
we
have
the
white
paper,
which
I
think
does
a
pretty
good
job
of
outlining
the
sort
of
the
space
of
storage
and
the
kinds
of
failures
and
the
kinds
of
areas
that
one
needs
to
think
about.
C
C
Okay,
cool:
I
will
try
and
step
it
up
a
little
bit.
You
know,
code
quality
is
pretty
self-explanatory,
but
of
course
you
know
just
to
state
the
obvious.
If,
if
your
code
quality
is
pretty
bad
at
the
beginning,
it
typically
doesn't
get
worse.
It
doesn't
get
better.
It
gets
worse.
So
if
you
have
a
project
that
has
like
horrendous
code
quality
at
the
beginning,
then
you
should
raise
that
as
a
big
red
flag,
particularly
you
know,
poor
choices
of
language
languages
that
don't
scale
well.
C
If
you
don't
think
that
it's
possible
to
kind
of
move
from
a
point
where
the
project
is
to
to
graduation
ever
without
you
know
rewriting
the
whole
project,
then
that
would
be
a
pretty
big
red
flag
and
there
are
a
couple
of
languages.
I
won't
dis
any
in
particular,
but
there
are
a
couple
of
languages.
There
are
actually
you
know
major
open
source
projects
that
have
failed
because
of
relatively
simple
things
like
like
choosing
the
wrong
language
for
the
particular
project.
C
They
were
doing
and
running
into
a
wall
where
it
just
could
not
scale
to
the
the
size
of
a
project,
not
so
much
scale.
In
terms
of
performance
of
software,
but
just
scale
in
terms
of
the
size
of
the
project
that
that
they
were
planning
to
build
and
the
size
of
the
teams
and
and
the
language
may
just
not
lend
itself
to
large
projects
like
that
dependencies,
this
is
a
pretty
big
one.
C
You
know
make
sure
you
understand
what
this
thing
needs
in
order
to
work
correctly
or
well,
and
make
sure
that
you
understand
what
how
how
these
dependencies
couple
with
the
system
and
what
their
license
restrictions
may
be.
You
don't
have
to
be
a
licensing
expert,
but
but
if
this
thing
can't
run
without
some
proprietary
thing
that
you
have
to
go
and
buy
from
somebody,
then
that's
a
pretty
big
red
flag
or
if
it
is,
I
can't
run
unless
you,
you
know,
cut
and
paste
some
code
from
something
into
somewhere.
That's
obviously
a
concern.
C
What
is
the
release
model?
Do
they
have
like
proper
versioning
do?
Do
they
do
periodic
releases?
Do
we
have
like
ci
cd
systems,
continuous
integration,
continuous
development
system,
sorry
deployment
system?
So
so
is
there
automated
testing
whenever
anybody
sends
a
div?
Does
it
get
tested
and
merged?
If,
if
appropriate
and
caught,
if
it
doesn't
work
properly
etc,
these
are
all
important.
C
The
cncf
staff
have
lots
of
lawyers
and
and
licensing
experts.
So
you,
as
I
said
you
don't
have
to
be
a
licensing
expert
yourself,
but
you
do
need
to
at
least
have
a
rough
overview
of
what
what
the
licensing
requirements
are
for
the
cncf
and
and
what
projects
the
pro
this
particular
project
depends
on
and
how
exactly
they're
integrated?
C
B
Can
I
just
I
was,
I
was
just
going
to
add
sort
of
a
couple
of
points
because
over
the
last
over
the
last
year,
for
example,
at
least
you
know,
since
since
I've
been
involved
in
a
number
of
different
projects,
you
know
two,
two
recurring
things
that
that
come
up
fairly
often
are
the
licensing.
So
you
know
it's
and
the
licensing
sort
of
applies
from
sandbox
and
above
so
so
it's
it's.
B
It's
it's
useful
to
familiarize
yourself
with
the
with
the
cncf
ip
policy
and
and
understand
you
know
which,
which
classes
of
licenses
are.
Are
you
know
an
easy
slam,
dunk
and
which
others
cause
problems?
So
so
that's
definitely
worth
considering.
The
other
thing
that's
worth
considering
is
is
the
dependencies.
B
It
scales
horizontally
and
has
multiple
nodes
and
that
sort
of
thing.
But
but
for
example,
you
know,
depends
on
a
single
postgres
database
in
the
in
the
background
right
and
and
then
you
know
you
have
to
you-
have
to
ask
some
of
those
questions
about
how
you
know
what
what
options
are
available
for
for
making
those
those
aspects
of
the
system
highly
available
or
or
scalable,
for
example,
and
that's
that's
that
that
comes
up
more
often
than
you'd.
Imagine.
C
C
Is
there
an
issue
tracking
process?
You
know
most
of
these
things
with
people
using
things
like
github.
Most
of
these
things
get
checked
boxes
pretty
quickly,
but
things
like
release
management
are
not
always
as
obvious,
and
so
it's
a
good
idea
to
understand.
What's
going
on,
they
don't
all
have
to
be
perfect,
and-
and
I
want
to
be
very
clear
about
this-
it's
not
the
case
that
if
you,
if
you
get
a
cross
next
to
one
of
any
one
of
these
items,
you're
somehow
not
eligible
to
enter
the
cnc.
C
C
C
So
so
you
don't
have
to
have
an
answer,
yes
to
all
of
these
questions,
but
you
do
need
to
know
what
the
answer
is.
Is
there
a
code
of
conduct?
Does
it
have
a
license
which
licenses?
Is
there
a
like
automated
way
of
checking
whether
the
people
who
contribute
to
the
project
fulfill
those
or
agree
to
those
license
restrictions?
C
What
is
the
quality
of
communication
around
the
project?
So
usually
projects
have
you
know
slack
channels
and
github
issues
and
pr
reviews,
and
whatever
is,
is
the
quality
of
communication
good?
Do
people
respect
each
other?
Do
people
respond
to
things
when
they
get
reported,
etc,
or
are
people
having
flame
wars
in
their
pr
reviews,
or
are
they
just
leaving?
You
know
reported
issues
to
rot
for
months
on
end
all
those
kinds
of
things?
C
What
does
the
core
team
look
like?
Who
are
the
people
behind
this
thing?
You
know
how
committed
are
they
are
they?
You
know
somebody
who
works
after
midnight
for
an
hour
once
a
month
on
a
project,
or
these,
like
you,
know,
professional
people
who
have
paid
as
their
full-time
job
to
build
and
maintain
this
project.
There's
a
there's,
a
big
difference
between
the
two.
C
Are
there
any
areas
that
are
lacking
leadership?
You
know,
maybe
you
have
a
good
technical
person
who
doesn't
have
good
project
management
skills
running
the
project.
Maybe
you
have
a
good
project
manager
who
doesn't
have
good
technical
skills?
Maybe
there
are
other
areas
that
might
be
lacking.
Maybe
they
don't
have
the
right
skills
around
testing
or
release
management,
and
maybe
they
need
some
help
there.
In
some
cases
the
cncf
can
help
there.
C
C
Any
questions
around
project,
type
items,
project
management,
etc,
uses
very
important
to
understand
who
uses
the
project,
try
and
speak
to
people
who
are
using
it
and
get
an
understanding,
and
it's
sometimes
quite
often
the
case
that
you
know
everybody
wants
to
claim
that
all
the
big
famous
companies
are
using
their
projects,
their
software.
So
you'll
see
you
know,
screens
with
lots
of
visible
logos
of
you
know
where
there
is.
I
don't
even
want
to
mention
any
brand
names,
but
you
know
the
ones
I'm
talking
about
makes
it
sound
impossible.
C
I
sound
impressive
if
these
big
names
are
using
your
software
now,
there's
a
very
big
difference
between
you
know
some
intern
at
that
company
kind
of
like
install
the
software
once
versus
the
business,
runs
on
it
and
and
getting
an
understanding
of
of
exactly
what
the
use
cases
are
that
the
stuff
is
really
being
used
for
at
the
moment
and
talking
to
the
people
using.
It
is
very
important.
C
C
There's
also,
you
know
huge
amount
of
viral
marketing
out
there
around
projects,
and
so
your
job
is
to
actually
cut
through
all
of
that
stuff.
Anybody
can
read
all
the
buzz
and
the
twitter
feeds
and
everything
else
about
a
project.
That's
not
actually
the
information
that
is
useful
in
deciding
whether
a
project
is
well
used
with
whether
it
is
technically
sound
or
whether
users
of
it
like
the
project
for
for
the
right
reasons.
C
C
C
You
know
if
the
project
has
been
around,
even
if
it's
only
applying
to
be
in
the
sandbox
which
doesn't
have
any
strong
requirements,
for
you
know
heavy
use
or
or
stability
or
anything,
but
if
a
project's
been
around
for
five
years
and
allegedly
people
have
been
working
on
for
five
years
and
and
it
still
doesn't
have
any
uses,
you
should
ask
some
pretty
you
know
pointed
questions
about.
Why
have
you
got
no
users,
you
know?
Is
there
something
wrong
with
the
software?
Is
it
a
use
case
that
that
is
not
important
to
people?
C
You
thought
that
there
was
a
need
for
this
thing
that
nobody
actually
turns
out
to
need.
Those
are
questions
well
worth
asking.
You
don't
have
to
be
rude
and
you
don't
have
to
be.
You
know
disrespectful
in
any
way,
but
they're
definitely
questions
that
need
that
need
answers
and
don't
be
shy
to
just
keep
asking
until
you
get
the
answers,
you're
looking
for
or
at
least
sufficiently
in-depth
answers,
and
sometimes
you
won't.
Sometimes
people
won't
be
able
to
give
you
the
answer,
and
in
that
case,
that
that
is
an
answer
in
itself.
C
D
So
for
us
as
a
vendor,
you
know
our
our
customers
weren't
necessarily
end
users,
according
to
definitions.
So
anyway,
that's,
I
think,
an
important
thing
for
projects
to
understand
at
the
various
levels,
the
definitions
of
vendors
and
not
not
necessarily
being
users
and
their
customers,
not
necessarily
being
users
and
what
you're
really
looking
for.
B
B
So
you
know
if,
if,
for
example,
the
the
production
users
are
only
using
a
commercial
version
of
the
projects
that
includes
components
that
aren't
available
in
the
open
source
version,
for
example
those
users
probably
wouldn't
qualify
as
as
necessarily
as
end
users
of
the
of
the
open
source
project
like
like
as
what's
happened
in
provega,
but
I
think
I
think
we
can.
We
can
probably
look
forward
to
to
remy
being
that
yeah
during.
D
C
C
And
in
order
to
to
use
this
thing
in
any
kind
of
reasonable
production
environment
you
have
to
go
and
buy
the
commercial
license
with
a
whole
bunch
of
add-ons
that
you
know
are
not
open
source
that
that's
not
a
model
that
we're
promoting
here.
The
the
open
source
components,
the
stuff
that
that
lives
within
the
cncf
should
itself
be
a
viable
productionizable
productionized
system.
By
all
means
they
can
be
commercial
add-ons
and
proprietary
additions.
But
the
core
thing
that
is
open
sourced
in
the
cncf
should
itself
be
useful
in
production.
D
C
And
that's
a
good
point:
we
should
we
should.
We
should
clarify
that
alex.
Maybe
if
we,
if
you
can
make
a
note-
and
we
can-
we
can
make
sure
that
that's
because,
because
that
is
a
recur,
we've
seen
that
more
than
once,
let's
put
it
that
way,
that
that
confusion,
a
lot
of
a
lot
of
software
companies,
business
models
are
kind
of
built
around
this.
C
I
forget
exactly
what
the
commonly
used
term
is,
but
you
know:
there's
a
community
edition
or
an
open
source
part
of
it
and
there's
a
bunch
of
commercial
stuff.
That's
added
onto
it
open
core!
I
guess
is
the
term
right
and
that's
that's
quite
common
and
and
it
can
confuse
people
and
there's
nothing
wrong
with
you
know,
open
core
where,
with
the
part
that
is
open
source
is
only
usable
to
like
kick
the
tires
and
play
with,
but
that's
not
the
intention
of
the
cncf.
D
C
C
Absolutely
cool,
I
think,
we're
pretty
much
out
of
time.
So
maybe
I
should
stop
waffling
now.
You
can
read
the
rest
of
the
document
and
feel
free
to
discuss
on
the
slack
channel
or
feel
free
to
email
me.
If
you,
google
me,
I'm
sure
you
can
find
my
contact
details
or
ask
on
the
slack
channel
and
happy
to
answer
any
questions.
Offline.
A
Any
further
questions
before
we
wrap
up
hi.
Yes,
so
this
gun
is
so.
I
just
want
to
say
that
we
might
need
for
so
I'm
from
the
other
side,
the
ones
that
didn't
get
in
on
the
sandbox.
So
congratulations
right,
so
I
think
we
might
need
some
more
clarifications
about
what
is
the
bar
exactly
for
entry
in
sandbox
in
terms
of
adoption
and
project
maturity
right,
because
so
from
the
criteria
for
sandbox
right.
A
I
see
that
is
to
encourage
public
visibility
of
experiments
or
other
early
work
right,
but
doesn't
look
to
me
like
as
an
example
right.
It
doesn't
look
like
a
project
that
it
was
an
experiment
or
something
right.
It
looks
like
a
proper
company
to
me
right.
So
it's
it's
a
bit
mixed.
I
think
the
messaging
that
we
get
right
so
that
that
is
my
take
on
that
we
might
need
to
highlight
a
bit
more.
A
C
Yeah,
that's
a
that's
a
good
point
you
make,
and
I
think
I
touched
on
that
earlier,
which
is
that
sandboxes
and-
and
I
don't
think
the
cncf
documentation
is-
is-
does
any
helps
to
clarify
some
of
this
confusion,
but
my
personal
opinion
is-
and
I
was
involved
in
actually
like
concocting
the
sandbox
when
I
was
in
the
trc.
My
personal
opinion
is
that
the
sandboxes
is
intentionally
a
vague
space.
It's
a
space
where
somebody's
looking
for
a
legal
home
where
they
can
collaborate
with
other
companies
safely.
C
A
So
so,
just
if
you,
if
you
look
on
the
so,
if
someone
doesn't
know
that
right
and
goes
and
sees
you
know
what
is
the
criteria
for
the
sandbox
projects
and
what
is
the
goal
right?
I
noticed
that
you're
focusing
more
on
the
legal
aspect.
Why
they
I
mean
whether
they
see
on
the
cncf
website
right,
is
that
this,
the
cncf
sandbox
has
four
goals.
One
encourages
public
visibility
of
experiments
right.
So
if
it's
not
the
case,
I
mean
it's
fine
right.
It
just
needs
to
be
clarified.
C
D
So
much
sorry
come
on
I'll,
just
say
one
thing
that
might
be
worth
avoiding-
or
at
least
this
is
a
perception
I
have
of
apache
a
little
bit
is
like.
Sometimes
apache
is
a
place
for
projects
to
go
to
die
and
yeah.
I
don't
know
that
we,
you
know
this,
the
I
don't
know
the
cncf
is
risking
any
of
that,
but
you
did
mention
that
you
know.
Maybe
an
experiment
in
the
sandbox
doesn't
work
out,
but
the
the
apache
attic
is
almost
bigger
than
you
know.
C
Yeah
we
do
we
do
have,
and
we
should
probably
wrap
up
now
because
yeah
sorry,
but
we
do
have
a
good
conversation.
We
do
have
processes
for
archiving
projects
explicitly.
You
know
some
projects
do
die
and
that's
kind
of
reasonable
as
long
as
they're
flagged
accordingly
and
they're
they're
not
presented
in
the
same
kind
of
light
as
as
thriving
projects.
I
think
that's
fine
and
and
all
of
these
there
are
sort
of
very
vague
guidelines
around
timelines.
You
know
people
projects
cannot
sit
in
in
sort
of
limbo
forever.
C
I
think
it's
reasonable
for
a
project
to
kind
of
get
stalled
temporarily.
Maybe
companies
change
direction
and
new,
open
source
contributors
need
to
be
sort
of
engaged
in
the
project
to
get
it
going
again,
but
it
can't
just
sort
of
sit
there
forever
in
limbo,
then
it
it
will
either
get
archived
or
or
removed
from
the
cncf,
and
there
are
processes
for
that
right.
Thank
you
very
much
everyone
I
have
to
run.
It's
been
a
great
conversation.
I
enjoyed
it
and
hopefully
I'll
have
some
more
in
the
future.