►
Description
This session will explain why KEPs are such an important part of how we talk about proposed changes and enhancements to the Kubernetes ecosystem. Covered will be the lifecycle of how KEPs are created and managed, as well as how they integrate with the release process. We will also introduce plans for a new cli to manage KEPs programmatically.
Presenter: Jaice Singer DuMars, Google
A
One
of
the
top
voted
topics
for
this
contributor
summit
was
all
about
caps,
because
a
lot
of
people
don't
know
what
it
kept
is.
What
it's
for?
What
the
lifecycle
is,
what
we're
actually
trying
to
accomplish
by
having
this
as
a
part
of
our
ecosystem
for
contributors
and
just
as
a
show
of
hands
how
many
people
in
the
room
feel
like
you,
have
a
pretty
good
handle
on
what
a
cap
is.
B
A
Great
we're
turning
the
right
direction,
so
let's
just
give
a
little
background.
So
cap
history,
you
may
recognize
a
person
in
this
slide.
He's
amazingly
standing
right
beside
me
today,
I
volunteered
to
share
the
stage,
because
caleb
has
really
been
the
driving
force
for
this
as
an
important
part
of
our
ecosystem,
and
it
started
with
a
pull
request
out
there
about
how
we
could
adopt
the
rest,
RFC
process
and
thanks
to
version
control.
You
can
actually
go
out.
A
Look
at
this
yourself
and
see
the
history
of
that
conversation
and,
as
I
emerged
and
evolved
Kaleb
sort
of
morphed
this
into
some
new
territory,
which
looked
at
maybe
hybridization
between
the
rest,
RFC
process
and
the
Python
pet
process.
So
you
want
to
give
it
a
little
rundown
on
sort
of
your
process
there
and
I
mean.
B
B
Looking
at
the
rust
community,
looking
at
the
Python
community,
looking
at
how
the
Apache
project
developed
software,
how
OpenStack
developed
their
sub
projects,
it
was
just
a
lot
of
looking
at
what's
out
there
and
thanks
to
open
source,
that's
actually
possible
all
the
source
material
is
there
on
the
Internet,
so
it
just
takes
a
time
and
motivation.
Yes,.
A
Prior
art,
being
a
very
important
part
of
this,
so
one
of
the
one
of
the
complaints
we've
run
into
or
concerns
is
that
the
kept
process
inherently
has
certain
aspects
like
managing
maded
metadata.
That
are
a
little
tricky
to
do
as
humans,
and,
if
anybody's
ever
had
a
merge
conflict
with
a
kept
numbering
file,
you
can
definitely
attest
to
that.
B
And
you
know
one
of
the
things
we
promised
on
that
stage
in
Austin
was
that
we
would
make
automation,
as
it
made
sense
to
the
community,
not
to
replace
your
interaction
with
the
kept
process,
but
to
kind
of
augment
it
to
make
you
more
productive
at
what
you're
doing.
I
really
love
the
idea
of
automation
as
kind
of
the
Ironman
suit
versus
Voltron.
B
B
Up
actually
could
go
so
this
is
not
yet
in
coop
identities,
Organa
organization
repository,
but
the
library
is
coming
along.
You
know
I
can.
If
you
pull
me
aside
afterwards,
I
can
talk
about
the
difficulty
of
trying
to
write
software
when
your
job
isn't
that
on
a
day
to
day
basis,
but
you
know,
we've
been
able
to
get
out
some
stuff
and
we're
about
to
start
collecting
feedback.
So
that's
super
exciting
the
library's
kind
of
organized
here,
it's
say
the
world's
worst
readme
is
in
there
today
at
github.com
caleb
a
miles
/
caps.
B
There
is
tooling
to
help
migrate
to
what
we're
thinking
is
going
to
be
the
next
iteration
of
what
a
cap
is,
there's
tooling,
to
help
you
play
around
with
caps
themselves.
You
know,
like
we've,
been
talking
about
with
the
contributor
playground.
There's
you
know
stuff
to
help
you
with
that
there's
and
there's
a
basic
MVP
code
for
managing
the
lifecycle
of
an
individual
cap
through
or
to
implementation.
So
that's
what
we
got
so
far
and.
A
We'll
we'll
talk
about
that
tool
in
the
workflow,
because,
really
that
the
tool
is
intended
to
mirror
the
the
human
workflow
at
this
point
so
or
amend
a
bit.
So
just
a
quick
bit
on
why
caps,
as
Brian
mentioned
earlier
in
our
in
the
first
session
about
the
proposal
process
before,
was
very
organic
to
be
to
be
kind
and
it
did
not
necessarily
serve
the
needs
of
conveying
the
value
of
what
was
being
delivered
in
the
community.
A
So
one
of
the
things
that
Caleb
and
his
design
is
really
thinking
about
is
change
being
at
the
speed
of
trust,
because
if
we
think
about
all
the
things
we
do
as
a
community,
when
you
have
trust
between
yourself
and
whoever
is
acting
as
the
next
step
in
a
process,
it
makes
it
much
faster
and
a
lot
of
times.
That's
human
in
our
in
our
culture.
C
B
If
you
like
me,
work
at
a
very
large
corporation,
you
are
probably
familiar
with
your
own
internal
launch
process.
That's
you
know
created
because
it's
very
difficult
to
organize
a
cross-functional
team
to
deliver
value,
presumably
to
your
own
customers.
It's
a
challenge
everywhere,
and
this
is
trying
to
help
us
as
a
open
source
community,
have
something
similar
that
allows
us
to
propose
and
manage
the
delivery
of
value
to
our
users.
That's
at
the
end
of
the
day.
Hopefully,
why
we're
all
here,
yeah.
A
A
We
want
to
make
sure
that
there's
a
record
of
note
that
it
has
a
history
of
custody
with
it
and
approvals
and
all
that
stuff
in
one
place
so
that,
as
somebody
you
know,
an
archaeologist
come
comes
to
this
project
and
in
20
years
and
wants
to
see
what
happened
literally,
they
kept
can
give
you
key
decision
points
where
things
were
included
or
not
included
where
they
were
obviated
or
moved
forward,
and
currently
that's
really
difficult
to
come
by
in
our
in
our
ecosystem.
Yeah.
B
This
is
part
of
a
larger
effort
to
help
create
you
know
a
sense
of
organizational
history
for
the
project,
so
we
can
actually
look
at
what
happened.
Why
did
it
happened?
And
you
know
learn
from
our
successes
and
failures
because
yeah
you
know,
that's
why
we
have
libraries,
because
without
storing
information
you
just
cannot
operate.
You
can't
can't
improve.
A
So
again,
caps
are
a
way
of
having
consistency,
and
so
for
me,
when
I
look
at
a
cap,
it's
easier
to
review,
because
I
know
what
where
things
are
at
in
a
cap,
I
can
expect
that
there
are
certain
things
that
are
going
to
be
their
proposals
didn't
necessarily
have
as
a
seam
of
a
format.
Again,
life
cycle
can
be
tracked
and
again
single
artifact
multiple
purposes.
A
So
when
do
you
need
a
cap?
This
is
a
common
question
and
really-
and
this
is
language
directly
from
the
repo-
is
that
if
it's
something
that
needs
to
be
described
either
written
or
verbally
to
someone
else
besides
the
kept
author,
it
should
be
a
cap
because
essentially
you're
trying
to
convey
a
sense
of
value
or
or
delivery
of
something
that's
important
to
the
ecosystem.
You
want
to
have
that
as
succinct
and
well
described
and
as
crafted
as
possible
and,
of
course,
the
weird
statue
there.
A
B
A
great
source
of
the
kind
of
importance
about
why
you
need
to
fully
motivate
enhancements
is
I.
Think
Russ
Cox
had
a
beautiful
job,
explaining
that
in
blog
post
about
working
towards
go
to
its,
if
operating
at
a
large,
open
source
project,
you've
got
you
know
precious
minutes
a
day
to
review.
You
know,
proposals,
enhancements
requests
and
having
more
prose
is
really
helpful.
In
order
to
understand
why
your
proposed
enhancement
is
important.
A
So
anatomy
of
a
cap
is
essentially
a
few
things.
There's
a
metadata
section
which
heretofore
has
been
human
managed.
Obviously,
a
tool
is
going
to
be
better
at
handling
that
than
people.
Motivation
is
your
chance
to
say
why
this
is
important.
What
is
the
value
and
how
is
it
being
delivered?
The
summary
is
a
sort
of
TLDR
of
what
the
cap
is
that
can
be
shared
across
different
stakeholder
processes,
so
in
the
release
process.
In
order
to
understand
what
a
cap
is,
delivering
I,
don't
necessarily
need
to
read
the
entire
cap.
A
B
This
is
kind
of
where
we
depart
from
the
traditional
launch
process.
You
may
be
familiar
with
that
you're,
you
know
in
your
corporate
homes.
The
kept
process
is
really
about.
You
know
tracking
the
delivery
of
value,
so
you
could
consider
it
day
a
landing
process
if
you're
into
you
know
hand-wavy
buzzwords
so.
A
A
quick
look
at
programmatically
managed
metadata.
This
is
from
this
is
generated
via
CLI
from
Caleb's
library
and
essentially,
what
this
does
is
it
allows
you
to
start
putting
in
llamo
a
much
more
consumable
way
of
tracking
metadata.
I
will
say
that
it's
early
days
for
the
library
so
there's
things
that
will
change
and
whatnot.
This
is
just
an
early
view
of
that,
but
more
or
less.
This
is
reflecting
the
things
that
we
currently
track
in
a
cap.
A
One
of
the
other
things
too
that
we're
trying
to
avoid
is
a
centralized
human-generated
index
because
those
are
notoriously
prone
to
having
merge
conflicts
and
whatnot.
So
the
idea
in
the
long
term
is
that
metadata
can
be
used
to
generate
some
sort
of
centralized
index
on
a
presubmit
type
job,
or
something
like
that.
So
again,
automation
as
a
key
manager
of
that
yeah.
B
And
certainly
you
know
you
can
imagine
that
the
publishing
or
rendering
of
kept
content
for
consumption
in
the
contributor
site,
for
instance,
could
be
a
step
that
you
know
happens
after
caps
are
merged.
So
it's
something
that's
happening
continuously.
If
you're
thinking
about
managing
kept
content
like
you
would
normal
code,
you'd
want
to
be
see,
eyeing
it
and
continuously
delivering
it
to
the
to
the
users.
In
this
case,
it's
often
other
contributors,
the
tech
media,
who's
interested
in
you
know,
learning
what's
going
on
to
the
Cabrillo
as
project.
A
A
What
you're
essentially
trying
to
not
only
say
what
is
the
thing
that's
being
solved,
but
really
talk
about
the
significance
of
the
problem
so
that
everybody
can
understand
why
they
want
a
rally
around
it,
and
ideally,
this
helps
sort
of
provide
a
de
facto
prioritization,
because
when
a
sig
receives
a
cap,
it's
competing
against
all
the
other
caps
in
flight,
it's
competing
against
existing
sigmap
initiatives
or
whatever
those
are
that
they
have
in
mind
and
for
them
to
take
on
something
new.
They
have
to
understand
wow.
This
is
urgent.
A
This
is
something
that
has
value
it's
something
that
needs
to
be
done
and
bought
into,
and
caps
are
a
major
way
of
doing
that.
So,
when
Brian
mentioned
earlier
about
the
K
log
change,
dims
did
that
he
he
went
to
people
and
got
critical
mass.
He
wrote
on
mailing.
Let's
see
he
took
the
the
initiative
to
convey
the
urgency
and
the
significance
of
the
problem.
Obviously
that
doesn't
scale.
D
But
it's
never
quite
been
clear
to
me
how
long
or
large
and
scope
a
cap
is
supposed
to
be,
and
so
I
kind
of
have
a
concrete
example
of
this
right
so,
like
let's
say,
you're
doing
version
two
of
an
API
right,
and
so
you
initially
proposed
some
features
for
version
2
and
you
implement
those
and
those
are
implemented
and
you're
sitting
around
in
beta
and
people
are
like
that's
great,
but
really
needs
this
one
tweak
and
then
so
you
go
and
add
a
couple
more
features
and
whatnot.
How?
D
B
The
way
I've
been
thinking
about
caps
anyway,
has
been.
You
would
have
an
overarching
cap
so
that
you
would
track
the
graduation
of
an
API
from
alpha
to
beta.
You
would
track
also
in
the
cap.
You
know
revisions
that
would
cause
breaking
changes,
so
you'd
be
able
to
see
the
entire
provenance
for
an
API
group
that
was
added
in
one
place.