►
From YouTube: CNCF TOC Meeting - 2018-02-20
Description
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
B
B
B
B
B
All
righty
is,
is
Brian
grant
or
Camille
on
the
line.
Yes,.
C
E
B
Sure
no
problem
so
on
slide
six.
So
we've
mentioned
this
in
the
past
that
two
seats
are
freeing
up
on
the
TSV.
These
are
TOC
selected
seats,
so
essentially
the
TOC
themselves,
votes
and
nominates
these
seats.
So
if
you're
interested
in
running
for
this
way,
the
highly
advise
you
to
talk
to
your
fellow
TOC
members
nominations
are
opening
up.
B
Today,
the
TOC
has
been
nominating
some
folks
I
plan
to
close
in
the
nominations:
GARCH
six
and
then
we'll
do
the
voting
for
about
a
week,
we'll
close
voting
on
March
14th
and
announce
the
results
on
the
15th
any
questions.
Oh,
these
are
Brian
and
Solomon's
seat
by
the
way
Brian
grant
and
Solomon's
and.
B
E
So
please,
if
you
are
looking
to
be
nominated,
then
members
of
the
voting
TOC
will
probably
oblige
you
know
I'd
say
there's
a
relatively
low
probability.
If
your
request
for
nomination
getting
rejected
it
may
happen,
but
it's
it
is,
in
my
view,
unlikely,
but
you
do
need
to
be
nominated.
So
if
you're
interested
in
this
don't
be
ashamed,
throw
your
hat
in
the
ring
now
until
Tom,
Preece
or
someone
else.
E
Okay
good,
so
if
next
topic
is
the
proposed
sandbox
model
correct
for
us
yep
slide
seven
yeah
I'm
now
in
the
deck
great
feel
snow.
You
know
here's
what
we
came
up
with
after
the
last
toc
meeting,
where
thanks
everybody
for
all
of
your
feedback
on
the
sandbox
concept.
That
was
super
helpful
and
we've
now
got
a
document
which
has
largely
been
written
by
Chris,
thanks
Chris,
with
some
input
from
the
TOC
and
a
few
other
people
which
we
would
like
to
move
to
a
vote
as
soon
as
we
can
maybe
not
today.
E
Has
everybody
read
that
proposal.
If
you
haven't
do
open,
it
now
have
a
pretty
quickly.
It's
not
it's,
not
a
long
document.
I,
don't
think
it's
feasible
for
us
to
vote
on
this
today,
but
I
think
we
can
discuss
the
absolutely
most
important
points,
one
of
which
is
that
we
have
an
explicit
declaration
that
we're
not
going
to
do
marketing
and
there
is
an
intent
to
clarify
what
that
means
in
practice,
because
in
reality
we
are
going
to
do.
E
We
hope
to
publicize
projects
in
the
sandbox
so
that
people
know
they
exist
and
might
want
to
contribute
to
them,
but
we
want
our
focus
to
be
around
building
community
rather
than
you
know
going
around
saying
this
is
production-ready.
Everybody
should
start
using
it
right
now,
which
is
what
you
would
consider
normal
product
marketing.
E
So
that's
one
important
point
and
there's
quite
a
lot
of
language
in
the
document
about
playing
down
expectations
here.
I'm
really
looking
for
people
to
vociferous
lis
objects
only
the
language
at
this
point.
Secondly,
we've
tried
to
come
up
with
a
model
where
the
bar
to
getting
into
the
sandbox
is
lower
than
Inception,
because
one
of
the
issues
we
ran
into
that
caused.
E
What
somebody
amusingly
called
storage
gate
is
that
there
was
a
perception
of
blessing
or
election
to
some
elite
by
being
made
an
inception
project,
and
while
we
do
think
that
you
know
getting
recognition
is
important.
Nonetheless,
we
want
to
kind
of
take
out
the
idea
that
work
process
similarities
between
the
sandbox
and
incubation.
So,
for
example,
we
don't
want
they'll,
be
there
will
not
be
a
voting
process
and
a
presentation
and
a
document
and
they're
very
in
order
to
get
something
into
the
sandbox.
E
E
G
H
E
I,
don't
think
it
personally
I,
don't
think
it's
a
good
idea
to
require
that
it
is
Paulo
incubation,
graduation
story
and
personally
I'm
open
to
raising
the
bar
for
incubation,
multi
companies
contributing
and
things,
but
I
think
that
we
need
to
be
super
careful
not
to
create
perverse
incentives
at
the
very
earliest
stages.
Right.
H
B
I
I
J
G
Are
we
gonna
create
any
rigid
ridges?
Maybe
the
wrong
word
timelines
around
this
I
mean
I.
Could
you
know
something
be
in?
Will
we
have
a
timeline
for
the
sandbox
before
we
would
come
up
for
a
vote
for
archiving
or
it
doesn't
seem
like?
We
have
good
criteria
on
terms
of
timelines
of
these,
like
after
a
year
after
six
months
or
after
three
months,
there's
an
evaluation
period.
I
B
K
So
one
thing
that
might
be
missing
inside
the
diagram
is:
is
it
and
I
think
we?
This
is
verbally
described
down
below,
but
it's
the
notion
that
projects
are
still
encouraged
to
be
reviewed
initially
at
an
incubation
level,
but
you
know
they
might
find
themselves
going
through
sandbox
first,
if
for
the
lazy
reader,
those
that
draw
their
eyes
to
the
diagram
initially
might
consider
that
the
sandboxes
is
the
only
path
to
incubation.
F
C
Well
we're
the
reason
for
the
sandbox
is
that
we're
also
entering
a
phase
with
it,
where
there
are
a
lot
more
early
stage,
projects
being
started
and
developed,
so
I
think
that
shift
will
continue
to
occur
over
time,
but
I
don't
think
we're
completely.
We
completely
discovered
all
of
the
more
mature
projects.
F
Yet
maybe
do
you
want
to
put
some
language
in
the
dock
to
to
that
effect,
that
the
the
projects
that
will
will
be
potential
candidates
or
not
being
the
sandbox
right
incubation
are
those
that
have
matured
outside
of
the
CN
n,
CF
sure
I,
really
what
I'm
trying
to
do
is
I
would
like
to
avoid
a
the
stigmatizing.
The
sandbox
such
that
everyone
wants
to
stress,
wants
to
skip
straight
to
incubation
and
effectively
magnums.
This
is.
E
E
The
doctrine
tries
to
be
explicit
that
there's
two
things
one
is
that
the
the
process
is
not
discriminatory,
meaning
that
the
TOC
will
more
favored
projects
from
the
sandbox
just
because
they're
in
the
sandbox
when
it
comes
to
incubation,
but
also
to
that
the
rete.
One
of
the
reasons
you
should
be
in
the
sandbox
is
to
get
to
incubation
faster,
because
you
know
the
idea
is
that
these
are
things
that
are.
C
Do
agree,
though,
that
we
don't
want
to
disadvantage
projects
in
the
sandbox,
so
I've
made
a
comment
about
this
with
regards
to
I.
Forget
some
other
some
other
issue,
so
we
do.
We
do
want
to
be
careful
that
they're
not
disadvantaged,
that
the
projects
couldn't
do
things
that
they
would
normally
be
able
to
do
to
grow
and
thrive
outside
senses.
C
E
E
K
Part
of
the
reason
that
I
raised
my
voice
earlier
tasks
about
Orca
highlight
the
notion
that
folks,
who
are
just
looking
toward
the
diagram,
might
consider
that
sandbox
as
the
the
only
way
in
is
back
to
Brian
grants.
Point
Lee
we've
been
here
at
SolarWinds,
we've
been
doing
a
fair
bit
of
work
with
a
snap
and
in
considering
where,
where
it's
home
might
might
be,
and
and
that
that
project
itself
is
probably
you
probably
most
appropriately
considered
as
something
of
an
incubation
and
so
good
that
we've
got
clarity
around
the
notion.
K
F
E
F
And
if
we
do
that,
I
just
want
to
reinforce
some
of
the
language.
That's
already
there
about
the
sandbox,
really
being
the
the
preferred
path.
It's
not
obvious
to
me.
For
example,
a
until
snap
would
be
a
candidate
necessary
for
direct
incubation
I
think
we
all
want
to
get
ourselves
out
of
the
problem
of
where
we
are
adjudicating
a
bunch
of
projects
that
are
relatively
small
projects
and
relatively
new
projects
that
we
don't
think
are
insignificant.
F
But
that's
the
problem
we
at
the
TOC
are
trying
to
solve,
and
I
don't
want
to
recreate
that
problem
by
implying
that
everybody
should
be
going
straight
to
incubation.
So
if
we're
gonna
modify
the
diagram,
I
think
we
should
I
just
think
we
want
to
establish,
but
some
pretty
clear
rules
of
thumb
in
terms
of
what
kinds
of
projects
would
go
straight
to
incubation.
F
B
E
So
here's
another
request
to
the
people
on
the
call
which
is,
if
there's
something
about
the
document,
do
you
just
feel,
isn't
quite
right
or
could
be
improved,
you're,
not
quite
sure
what
language
to
propose.
Please
do
try
an
articulate
your
question
you
or
your
doubt
on
the
public.
Cnc
have
toc
less
and
I
promise
to
spend
some
time
for
Kristal.
Both
of
us
just
turn
across
some
language
to
relate
your
concern.
F
So
Alexis,
you
were
concerned
that
this
was
not
ready
for
a
vote.
What
are
some
of
the
big
gaps
that
you
still
see,
because
this
to
me
looks
pretty
good
I
mean
modulo,
some
minor
things
with
it.
What
are
some
of
the
big
holes
that
you're
saying
I.
F
E
Okay,
all
right,
so
let's
do
that
so
once
again,
for
those
who
are
listening,
you've
got
one
week
to
voice
concerns
down
so
make
comments,
and
we
will
try
to
more
reflected
in
roughly
this
time
next
week,
Tuesday,
which
is
obviously
not
another
toc
call,
and
then
we
will
agree
informally
to
call
a
vote
on
the
document
without
requesting
soliciting
input.
Further
input
from
you,
we'll
just
call
a
vote
and
we'll
get
plus
ones
a
lot
based
on
people's
position
and
if
we
don't
get
it
over
the
line
we'll
continue
editing
it
hey.
E
Paul
for
contribute,
emote
es
appendages,
I'm,
basically
happy
with
an
ass
proposal
at
this
point,
I'm
just
looking
for
a
few
more
external
eyeballs.
My
primary
worry
that
Nats
was
that
people
who
were
not
familiar
with
messaging
might
have
a
whole
bunch
of
questions
about
it.
So
it's
really
crucial
that
the
other
people
who
volunteered
to
help
like
Quinton,
locky
and
others
could
go
and
take
a
quick
look
and
just
make
sure
they're
happy
and
anyone
else
and
I
believe.
The
same
is
true
for
APA
in
spiffy.
L
J
G
I
had
quite
a
few
comments
in
the
Google
Doc
that
don't
look
like
they
made
it
into
the
PR.
Are
we
gonna
have
a
more
consistent,
we're
gonna
start
with
the
PR,
so
we're
capturing
everything
there?
Are
we
still
going
to
continue
to
start
in
a
Google
Doc?
It
just
seems
like
some
of
the
conversations
lost
when
we
moved
from
one
to
the
next.
G
C
G
E
G
B
Got
so
there's
two
things
here:
one
is
we
kind
of
have
our
annual
reviews,
so
Cory
DNS
is
gonna
speak
a
little
bit
later
in
a
call
about
what's
going
on
in
the
past
year,
we
have
a
couple
of
projects,
in
particular
Prometheus
kubernetes
I,
believe
the
steering
committee
has
recently
decided
that
they're,
okay
moving
forward
to
graduate
so
there's
a
proposal
from
them
kind
of
in
their
backburner
to
issue
a
PR
to
us.
I,
don't
know
if
this
one's
good
speaking
up
right,
okay,
awesome,
fantastic!
B
So
from
our
perspective,
if
the
kubernetes
pyaare
comes
in
I'm,
fine
holding
a
vote
over
email
for
graduating
a
few
of
our
projects
that
have
already
submitted
proposals
depending
on
how
the
toc
feels
comfortable
I
think
both
kubernetes
and
Prometheus
are
fairly
mature
and
well
baked.
You
know
they
were
our
first
two
projects,
so
I'm
pretty
confident,
they're
good
to
go,
but
it's
really
up
for
you
to
kind
of
decide
how
you
want
to
do
this.
C
E
I
mean
essentially,
the
projects
are
self
declaring
that
they
are
ready
for
graduation
and
have
met
the
criteria
yep,
and
then
they
are
evidencing
that
that
self
declaration
in
the
PR
correct,
we
are
expecting
them
to
request
support
for
their
declaration.
Essentially,
that
is
what
of,
though
it
is
yep
right.
C
E
E
Projects
have
any
time
constraints.
I
know
that,
from
time
to
time,
people
like
to
announce
things,
there
are
requests
about.
You
know,
conferences
coming
up
and
so
forth.
Do
you
make
sure
that
you
let
Chris
know
privately?
If
you
have
worries
about
any
of
this
or
if
it's
okay
on
the
public?
If
that's
fine
too,
we
should
move
promptly.
Now
on
these
things,
yep.
B
E
J
Yeah,
definitely
that
was
a
MOS
I-q
think
an
interesting
approach
to
to
how
the
workgroup
could
have
an
output
in
the
CNC
fi
I
want
to.
First
of
all,
you
congratulate
the
service
work
group
for
the
hard
work
that
was
put
in
to
the
reference
architecture,
and
we
did
ship
that
already.
J
One
was
thinking
there
might
be
interest
to
bring
forward
some
of
these
projects
to
the
same
CF
incubation
or
for
sandbox,
which
that
kids
were
ratified,
assuming
that
they
are
cloud
native
in
scope
and
and
function
so
and
then
the
second
thing
is:
we've
started
working
on
a
cloud
event,
spec,
which
is
sort
of
an
attempt.
As
you
guys
know,
events
are
collected
and
managed
in
many
different
ways
across
every
single
cloud
provider
and
every
infrastructure
today
so
which
I
cope
with
a
kind
of
an
event
event
master
of
all
events.
J
If
you
don't
kind
of
let
you
feed
in
your
events
and
into
a
common
framework
for
event,
management
management
across
multiple
environments.
So
once
we
get
that
to
a
point
where
we're
ready
to
bring
it
to
the
TOC.
For
me,
people
do
that
dog
I
know
you're
on
the
cause.
Anything
you
want
to
add
to
to
the
white
paper
to
the
cloud
of
in-spec.
No.
A
J
E
The
second
thing
I
want
to
ask
people
on
the
TOC
cool
you
know.
Do
you
think
this
is
the
kind
of
work
that
the
working
groups
should
be
doing?
Is
this
at
least
the
first
base
satisfactory
as
a
set
of
deliverables
for
working
groups,
because
I
know
that
we
haven't
quite
figured
out
exactly
what
level
of
empowerment
should
be
given
to
individual
working
groups
around
TOC
stuff
and
we're
still
that's
something
we
need
to
figure
out
soon.
Does
this
service
working
group
represent
a
success
here?
What
are
people's
thoughts
on
this.
A
Actually,
there's
a
question:
Ken
mentioned
earlier,
the
our
working
group
coming
back
to
TOC
for
review,
or
something
like
that
later
on
at
what
point
in
our
life
cycle
with
the
TOC
like
us
to
come
back,
do
they
want
us
to
come
back
just
periodically?
You
don't
want
to
Inglot
COC
when
we
feel
like
we've
made
sitting
in
progress.
Do
you
want
to
wait
for
one
point
over
the
spec?
What
kind
of
time
frame
you
guys
looking
for
well.
E
I
think
that
the
working
group
should
report
at
the
TOC.
You
know
sporadically
every
you
know
one
to
three
months.
It
doesn't
need
to
be
regular,
but
I
think
what's
really
critical,
is
that
the
working
groups
find
their
own
road
map
exit
criteria,
success
criteria
and
essentially
act
as
a
project
and
say
this
is
what
we
want
to
do
next.
When
that
is
done,
we
will
declare
victory
and
then
we
may
have
future
work
or
not.
But
you
know
our
primary
objective
is
to
do
this
and
then
maybe
the
working
group
could
be.
E
E
I
wouldn't
say
so
far
as
you
know,
there
has
to
be
a
presentation
with
the
vote
and
approvals,
but
I
think
provided
you're
socializing
your
objectives
and
any
significant
changes
regularly
on
the
main
TOC
public
lists.
So
the
people
are
aware
of
them
and
have
an
opportunity
to
you
know
this
early
object,
then
I
think
you're
doing
the
right
things.
I,
wouldn't
you
know,
look
for
a
solicit
support,
necessary.
L
That's
your
earlier
question:
I
I
think
that
the
the
white
paper
that
was
published
by
the
service
working
group
is
super
useful,
just
for
kind
of
getting
everyone
on
the
same
page,
about
terminology
and
direction
etc
for
a
given
field.
So
I
would
encourage
that
as
a
good
starting
model
for
other
working
groups
too.
Okay,
I.
M
Was
also
just
a
comment
that
I
think
that
it
is
really
highly
valuable
to
have
a
venue
for
to
discuss
the
improper
ability
concerns
between
projects.
I
mean
I,
think
we're
still
converging
on
you
know
kind
of
effective
process
around
the
circle
is
working
group,
but
certainly
it's
you
know,
instead
of
each
project
having
one-off
conversations
with
other
projects,
to
figure
out
how
they're
interoperable
having
a
working
group
who's
focused
on
that
domain,
help
facilitate
that
conversation.
I
think
you
know,
I,
don't
really
see
another
place
for
that,
so
I
think
that's
good.
M
E
J
So
this
is
something
that,
when
we
on
the
left-hand
side
of
this
slide
is
existing
in
user
reference
architecture
and
just
to
kind
of
remind
the
TLC
members-
and
you
know
there
might
be
new
to
this-
TOC
call
we
when
what
group
formed
I
guess
it
was
trying
the
foundation
for
him
a
couple
of
years
ago.
C
J
J
And
so
on
on
slide
13
the
left
hand
side
picture.
That
is
our
current
in
use
a
reference
architecture
and
when
we,
when
we
put
this
together,
the
idea
was
this
is
supposed
to
be
kind
of
a
high-level
reference
architecture,
not
meant
to
be
technical
and
not
meant
to
be
very
specifically
detailed,
and
we
decided
you
know:
I
discussed
the
need
to
kind
of
get
to
the
next
level
of
detail
which
I'm
kind
of
calling
a
logical
architecture
that
that
might
not
be
the
right
name
and
I'm
I'm
happy
changing
names
at
any
time.
J
J
Taking
it
to
the
next
level,
here's
what
I've
been
thinking
about
and
in
other
discussions,
I've
had
over
the
last
couple
years,
control
and
observe
and
optimize
seem
to
be
kind
of
a
key
theme
that
keeps
coming
up
over
and
over
again,
and
so
did
you
kind
of
look
at
the
different
opponents
or
the
different
functions
that
make
up
kind
of
a
cloud
need
a
reference
architecture?
You
get
these
sort
of
boxes
and
they
might
be
missing
a
box
here.
Might
try
and
say
this
is
the
proposal.
J
J
All
the
other
components
have
to
map
to
those
three
logical
components
right
and
so
what
kind
of
thinking
this
is
now
there
now
seems
to
be
some
interest
in
taking
this
forward
and
looking
at
what
would
be
the
next
level
of
detail
below
that
in
use
a
reference
architecture
that
we
have
for
the
CN
CF.
This
seems
like
a
good
starting
point.
J
You
know
every
two
weeks
with
an
update
whenever
we
get
to
something
that
is
makes
sense
to
give
back,
and
so
the
idea
it
was
I,
don't
think
I
need
to
create
a
working
group.
We
could
but
I'm
almost
thinking.
This
is
almost
like
a
work
stream
outside
or
you
know
how
do
the
TOC
effort,
but
not
a
work
group
within
the
TOC
but
I'm
happy
to
to
make
it
a
work
group.
If
that
seems
to
be
the
right
approach
to
work
on
this
next
level
of
detail.
This
needed.
K
Okay
can
I.
Do
you
think
that
the
iterations
on
this
aren't
very
helpful
I
think
that,
as
you
played
them
out
over
time,
you'd
almost
it
almost
say
that
we
do
have
a
work
stream
for
this
today
and
it's
it's
the
landscapes,
if
you
imagine
what
these
a
dish
of
as
they
play
out,
it
may
become
kind
of
one
of
the
same
right
and
one
intentionally.
K
G
J
E
So
I
think
the
next
action
is
to
continue
as
you
have
been
and
we'll
treat
it
similar
to
the
cloud
native
definition
document,
where
a
small
group
of
people
who
are
dedicated
to
spending
time
on
this
work
quickly
to
come
up
with
some
more
fleshed
out
ideas,
without
going
as
far
as
calling
you,
the
working
group
and
then
present
that
to
the
TOC
and
then,
if
we
feel,
as
you
know,
justification
for
creating
a
working
group.
Subsequently,
we
can
do
that.
But
let's
see
if
we
can
avoid
creating
a
working
group,
I
think.
B
J
A
N
Oh
yeah,
thank
you
all
right,
I'm,
John,
Boehner,
DNS
and
just
a
little
bit
about
what
we've
been
up
to
for
the
last
year.
We
can
go
to
slide
16,
so
it's
been
a
pretty
good
year
for
us,
we've
grown
a
lot
our
community
and
one
of
the
one
of
the
things
we're
really
pleased
with
is
that
we
put
in
a
proposal
to
become
the
default
DNS
for
kubernetes
and
we're
on
track
for
that.
It's
not
it's
not
in
GA
yet,
but
we're
alpha
and
1:9.
N
We
should
be
coming
out
as
beta
in
110
I'm
gonna,
hoping
to
to
GA
that
in
111
I've
talked
to
folks
from
a
number
of
the
different
managed
were
other
kubernetes
distributions
and
everybody
there
I've
talked
to
you
is
planning
on
moving
their
their
cluster
DNS
to
core
DNS
in
their
distribution
or
their
managed
managed
service.
So
that's
going
well.
We
have
a
lot
of
growth
in
our
dr.
Paul's.
N
N
This
is
our
annual
review.
As
part
of
that
we
can
go
to
slide
17.
We
are
looking
to
to
graduate
to
incubated
status,
and
so
we
have,
as
was
mentioned
earlier,
we
have
a
PR
out
there
for
that.
We
do
meet
all
the
criteria
as
they're
laid
out
there
and
so
I
hope
that
we'll
be
able
to
to
have
that
vote
soon.
B
So
you
know
per
the
Charter
we're
supposed
to
review
inception
projects
on
an
annual
basis,
but
it
also
John
is
requesting
to
move
to
incubation.
So
we
have
a
choice.
We
could
try
to
lump
those
things
together
and
just
do
a
vote
over
the
mailing
list
or
separate
them
out.
I'm,
not
sure
what
the
POC
refers.
It
seems
a
little
bit
redundant
to
kind
of
do
both
since
they'll
be
so
close
to
each
other.
E
E
O
Thank
you
guys
for
having
me
again
in
TSE,
presenting
on
a
storage
topic,
I
think
to
set
some
context
on
slide.
19,
it's
important
to
note
that
Rex
ray
has
been
presented.
It
was
about
a
year
and
a
half
ago
we
brought
it
to
the
TOC
following
that.
We
also
presented
lib
storage,
which
was
really
kind
of
a
semantic
layer
of
Rex
ray
the
base
implementation
layer
for
storage
features.
O
In
the
meantime,
when
those
two
things
happened,
you
know
there
was
an
SS
kabuki
that
was
formed
by
the
TOC
to
investigate
storage
storage
related
things,
because
I
think
it
was
generally
a
new
topic
for
the
TOC
and
then
as
well.
There
was
a
group
formed
called
the
the
CSI
group
which
were
from
the
container
of
orchestrators
that
we're
all
trying
to
solve.
You
know
similar
challenges
that
both
Rex
ray
and
live
storage,
we're
trying
to
solve
and
I
think
you
guys
know.
O
The
detail
that
you
know
CSI
has
been,
has
released
a
0.1
at
this
point,
so
there
there
is
now
a
base
level
of
you
know:
contract
between
container
works
traders
and
storage
providers
that
works.
So
this
this
idea
that
you
know
were
communicating
on
slide
19
is
that
hey,
there's,
there's
challenges
in
the
ecosystem.
You
know,
recreative
storage
has
been
trying
to
address
them
for
the
last
few
years.
There's
definitely
community
momentum
built
around
things
and
there's
there's
more
work
to
do
so
on
on
slide
20.
O
You
know,
as
we
move
on
from
the
problem
statement.
You
know
the
ecosystem
is
still
fragmented.
Today,
you've
got
multiple
interfaces
out
there.
Si
si
has
been
adopted
by
my
kubernetes
and
also
by
my
maysa
and
soon-to-be
by
Cloud
Foundry.
So
there
is
momentum
in
like
moving
the
right
direction,
but
there's
still
plenty
of
work
to
do
to
make
sure
that
we
don't
continue
to
have
this
fragmented
ecosystem.
O
You
know
from
a
kubernetes
perspective,
it's
been
communicated
that
the
internal
volume
plugins
that
kubernetes
has
are
there
looking
to
eject
them
from
the
codebase
and
they're
looking
to
replace
them
with
these
CSI
plot
plugins,
but
one
of
the
questions
becomes
like
how
does
that
happen?
What's
the
process
and
what's
gonna,
take
and
I
believe
pretty
strongly
that
you
know
there's
in
building
these
plugins
and
making?
O
You
know
really
good
CSI
implementations,
there's
a
a
bunch
of
common
code
or
redundant
efforts
that
all
these
plug-in
maintainers
have
to
deal
with,
and
you
know
it's
very
important
for
them
to
be
accepted
and
replace
the
existing
plugins
they're
inside
of
kubernetes
that
this
experience
for
for
the
operators
needs
to
be
really
good
and
I
think
that
in
order
to
get
there
it's
in
it
takes
some
type
of
a
framework
where
we
can
have
collaboration.
Among
you
know
the
storage
plug-in
providers
to
make
sure
you
minimize
we're
done
in
code.
O
Ensure
great
is
your
experience,
and
that's
that
I
think
is
one
of
what
we
need
to
get
to
to
make
these
operators
across
these
CSI
plugins
and
to
get
from
where
CSI
is,
is
accepted
as
boring
the
industry
standard
on
slide
21.
You
know,
I
feel
that
that
Rex
raised
a
great
fit
for
this
category
to
divide
a
a
place
in
a
project
for
the
industry
to
to
collaborate
on
as
a
CSI
plug-in
implementation.
So
it
is.
This
job
was
pretty
simple
right.
O
He's
gonna
help
in
developing
the
plugins
so
that
you
can
provide
so
it
can
provide
a
certain
set
of
this
common
functionality
to
all
the
plugins
that
are
developed.
So
from
a
from
a
cloud
native
consumer
perspective,
the
value
is
that
there
should
be
better
user
experiences
with
the
plugins
that
are
built
using
this
framework,
and
so
the
users
are
going
to
be
trusting.
These
implementations
will
be
using
CSI
quicker
from
a
provider
and
operator
experience.
These
are
people
that
are
actually
going
to
be
the
the
kubernetes
clusters
or
other
cluster
or
orchestrators.
O
So
it
should
be
the
lowest
friction
path
to
creating
a
CSI
plugin
for
them.
Additionally,
there's
going
to
be
interoperability,
that's
provided
for
backwards
compatibility.
So
in
this
ecosystem,
the
storage
companies
need
to
focus
on
a
bunch
of
different
integration
points,
and
that
doesn't
end
just
today,
just
because
he
as
I
came
out,
they
still
need
to
maintain
compatibility,
I
guess
existing
integration
points,
and
so
you
know
one
of
the
other
things
that
Rexxar
you
can
provide.
O
Is
this
interoperability
layer
so,
as
you
build
a
CSI
plug-in
right,
you're
off
you're
actually
compatible
with
nitocris
existing
volume
interface
through
that
interoperability
layer.
So
a
few
key
points
as
to
why
storage
companies
or
projects
would
be
interested
in
collaborating
on
this
kind
of
project.
Retros
already
got
a
ton
of
existing
integrations.
So
as
a
framework,
it's
got
a
15
different
iterations
that
it
shifts
click
today
on
slide
22
we're
highlighting
the
existing
user
experience
with
something
like
docker.
O
The
the
situation
becomes
a
little
bit
more
complex
and
see
the
CSI
world,
because
in
that
space
like
the
CEOs
may
have
different
packaging
and
they
may
have
different
methods
of
getting
things
up
and
running
so
Rex
ray
can
really
fill
that
void
to
provide
value
at
the
CEO
level
on
on
slide
23,
you
know,
I
think
it's!
Yes,
you
may
be
kind
of
scratching
your
head.
Is
there
a
point
saying,
like
hey
I
thought
that
CSI
is
gonna
solve
yeah
the
the
fragmentation
problem
in
the
ecosystem
completely,
and
you
know
the
reality.
O
Is
that
there's
there's
many
different
layers
of
code
and
there's
many
there's
a
lot
of
things
that
you
consider
redundant
and
common
across
some
of
these
layers
and
so
what
we're
trying
to
communicate
on
slide.
23
is
you
know,
here's
the
different
pieces
and
here's
where
x-ray
exactly
fits
it.
So
first
of
all,
you've
got
the
CSI
spec
that
it's
great
defines
that
contract
between
a
storage
provider
and
a
cluster
Orchestrator
and
then
because
of
GE
RPC.
You
have
nursing
a
CSI
API
bindings
which
make
it
you
know
somewhat
easier
to
implement.
O
But
then
you
have
to
start
implementing
and,
like
you
know,
enforcing
what
the
contract
says
within
your
code.
You've
also
got
to
validate
kind
of
end
to
end
that
the
spec
actually
works,
as
it's
supposed
to
so
above.
The
CSI
bindings
are
on
the
CSC
at
below,
but
there's
these
implementation,
libraries
that
are
emerging
that
the
community
started
to
work
through
and
and
collaborate
on,
one
of
those
being
go
CSI
and
there's
others,
especially
a
part
in
the
kubernetes
implementation
and
those
are
really
specific
for
if
I'm
implementation,
suicide.
O
O
Figuration,
where
CSI
really
comes
or
where
it
really
comes
into
play
in
this
perspective,
is
that
it's
gonna
help
bring
to
the
table
what's
not
defined
in
the
interface
spec.
That's
the
co
specific
packaging,
maybe
that's
the
the
documentation
that
helps.
You
understand
how
it
runs
with
a
Co.
Maybe
it's
an
NCI
CD
and
deployment,
and
you
know
artifact
handling
for
it
for
any
of
the
plugins.
Aside
from
that,
you've
got
things
that
are
important
to
people
who
are
become
plugins.
Maybe
that's
the
handling
availability
of
scale
security.
O
You
know
lots
of
other
stuff
additionally,
now
there's
CNCs
projects
that
are
important
for
these
plugins
to
create
a
great
like
cloud
native
experience.
So
maybe
it's
integration
to
sed
fluent
de
jager,
like
any
of
those
projects
that
all
requires
code,
so
so
Rex
crater
is
really
meant
to
handle
the
things
that
are
not
in
the
CSI
spec,
but
are
important
for
creating
a
great
user
experience
with
these
plugins.
O
So
how
does
that
look
like
in
terms
of
how
we
create
this
native
CSI
plugin?
You
know
the
message:
is
you
build
a
native
CSI
driver
and
Rex
Ray's
back-end
is
any
of
these
native
CSI
drivers
so
focus
on
the
key
platform
capabilities
that
you
need
within
your
CSI
driver
and
you
you
shift
that
as
a
go
package
and
then
Rex
rays
actually
uses
these
CSI
drivers
as
its
back-end
and
provides
all
the
extra
value
adds
and
feature
functionality
that
I've
been
describing.
So
it's
a.
G
O
Okay,
so
storage,
people,
yep
and
there's
you
know
three
audiences
one
is
you
know
the
the
end
users
who
really
shouldn't
know
much
about
CSI.
They
just
know
that
they
have
their.
You
know,
platform
supported.
You've
got
your
operators
who
are
just
deploying
these
and
the
operators
care
about
a
great
user
experience
from
you
know
how
they
actually
get
these
plugins
up
and
running
and
then
the
other
audience
is
the
storage
providers
and
projects
want
to
be
relevant
to
CSI.
So
this
slide
is
speaking
to
how
do
I
build
a
driver.
O
So
as
a
project
wrecks,
Ray's
been
on
a
pretty
steady
release
cycle
since
2015.
This
is
slide
25,
so
we've
had
about
78
releases
activity,
wise,
pretty
consistent
repo
activity,
whether
it's
the
the
events
generated
through
github
or
whether
it's
the
the
downloads
you
know
through
been
triggered
docker
hub.
So
a
very
steady
amount
of
demand
for
the
project.
Quinn.
G
O
Slide:
six:
twenty
six.
We
speak
to
lead
the
collaborators
and
pour
requests
so
in
addition
to
the
Downloads
on
the
other
side
of
it,
we've
had
plenty
of
collaborators
and
pull
requests
that
have
gone
through
the
project
and
a
pretty
steady
amount
over
the
past
couple
years.
I
I
expect
that
you
know
Rex
raised
importance
in
the
ecosystem.
Is
gonna
increase
dramatically
at
this
point?
O
Obviously,
on
the
right
side,
there's
lots
of
non
public
users
that
yeah
you
can
see
the
categories
of
they're
in,
but
on
the
left
side,
we've
got
plenty
of
public
users,
so
you
know
whether
it's
being
the
default
implementation
for
for
masive
sphere.
So
all
my
severe
deployments
shipwrecks
rated
by
default
for
storage
primitives,
whether
it's
in
the
rancher
catalog
or
also
available
through
Safi
io
from
a
corporate
perspective.
We've
had
plenty
of
collaborators,
whether
they're
contributing
plugins
or
speaking
publicly
about
using
it.
There's
the
list
of
different
corporations
on
slide.
O
28
I
actually
opened
up
a
thread
ahead
of
time
to
discuss
with
a
community
like
to
let
the
rectory
community
know
that
they
were
thinking
about
contributing
into
a
foundation,
and
here
we
had
open
support
from
from
other
companies
that
want
to
collaborate
on
it
if
Rex
rate
was
inside
of
a
foundation,
so
you've
got
diamante,
and
this
history
report
works
for
anterior,
SolidFire
storage
OS.
These
are
all
companies
that
that
wish
to
have
any
foundation.
So
they
can
collaborate
on
this
CSI
implementation,
so
finishing
up
on
on
slide.
O
20
I
think
that
storage
is
a
critical
component
to
for
quality
of
environments.
I
think
that
you
know
vac
being
one
of
the
major
challenges
that
I
started
out
with
the
only
nice
quality
of
environment,
kind
of
dresses
that
you
know
much
pretty
wise
people
are
thinking
about
using
these
these
environments
and
kubernetes
etc
for
more
critical
workloads.
So
this
this
area
is
kind
of
maturing
and
they're.
O
Asking
tougher
questions
so
I
think
we're
at
a
tipping
point
when
it
comes
to
the
you
know,
spanning
the
types
of
applications
that
are
relevant
in
cloud
native,
you
know
for
storage
companies,
it's
very
competitive
and
I.
Think
that
you
know
one
of
the
things
that's
gonna
help
CSI
mature
and
help
us
get
to
where
we
can
eject
plugins
from
kubernetes
is
that
you
know
we
need
a
project
that
the
source
companies
can
collaborate
openly
on
with
open
governance
and
I.
E
We're
around
the
time,
then,
thank
you
very
much
for
that.
That
was
very
helpful.
Yeah
I
have
a
few
quick
questions
and
then,
when
I
just
ask
press
something
so
number
one,
just
as
a
member
of
the
audience,
I
feel
what
your
explanation
of
what
it
is
could
have
been
a
bit
clearer,
and
that
should
happen.
If
you
go
to
the
next
stage,
who
would
who
its
formal
problem
it
solves
because
it
shouldn't
be
something
which
just
solves
the
problems
or
the
storage
vendors?
E
You
know:
what's
the
end-user
benefit?
Just
it's
not
them
it's
not
there.
It's
not
super
crisp.
The
other
thing
is
what
are
the
alternatives?
You
know.
What's
the
devil's
advocate
case
against
rex
ray?
I
didn't
quite
understand
that
and
again
I've
so
many
times,
I'm
a
bit
of
a
storage
idiot.
So
maybe
I'm
missing
something,
but
it
would
just
help
to
be
a
bit.
You
know
more,
simpler
in
said,
simplified
in
terms
of
respiration.
Other
than
that.
I
think
you
know
that
the
we
don't
have
time
to
call
for
a
vote
to
proceed.