►
From YouTube: Kubernetes SIG Apps 20171218
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So.
The
very
first
item
we
have
is:
we've
got
a
few
announcements
and
one
of
them
that
Michelle
lovely
put
on
here,
though
she
can't
make,
is
we're
talking
about
doing
meeting
in
a
PJs
time
zone,
so
the
opposite
side
of
the
world
and
we've
had
a
lot
of
interest
in
trying
to
loop,
some
folks
in
over
there
getting
their
feedback
and
engaging
in
them
and
seeing
how
that
works.
A
In
fact,
there's
been
this
broader
idea
of
trying
to
do
this
with
maybe
some
more
sheiks
there's
been
interest
was
outspoken
at
our
face-to-face
at
coop
common
as
well,
and
so
we
are
looking
at
possible
dates
and
Michelle's
suggestion
was
February
12th.
Does
anybody
have
any
thoughts
on
the
date
or
when
we
should
do
it
and
why
you.
A
First,
they
were
flaky
and
then
got
them
working
consistently.
So
we
actually
have
real
app
tests
against
kubernetes
head
as
we
move
forward
to
watch
things,
work
or
eventually
break
if
something
happens
and
they're
actually
useful,
now
so
props
to
him,
and
then
the
next
one
is
oh
I'm,
totally
gonna
butcher.
This
name
so
I'm
sorry
must
say
it
for
working
on
the
flaky
job
tests.
We've
had
a
real
problem
with
job
tests
for
a
while
they
were
a
bit
flaky
to
say
the
least,
and
because
they
were
flaky,
the
question
came
up
of.
A
Should
we
remove
these
from
kubernetes
tests,
because
if
we're
running
tests
and
they're
flaky
or
they
don't
pass
and
the
same
thing
came
up
with
the
charts
tests,
why
should
we
do
them
and
pay
for
those
runs
and
have
that
delay
on
each
commit
of
kubernetes
itself,
and
so
that
was
fixed,
I
think
just
this
weekend.
So
thanks
folks
for
fixing
tests,
it
made
our
testing
a
lot
more
useful
and
I
guess.
The
last
thing
we
should
probably
bring
up
again
is
and
I
guess
there
was
an
extension
to.
A
It
is
there's
the
helm
summit
coming
up
in
February.
If
somebody
has
a
link,
could
you
paste
it
into
chat
here?
I,
don't
have
it
off
and
the
helm
summits
coming
into
January
and
the
call
for
presentations
has
been
extended
through
the
end
of
the
year.
So
you
have
something
you
want
to
present.
You
have
something
you
want
to
talk
about.
There
that's
been
extended
and
they're
accepting.
Oh
thanks,
Brian
and
they're.
Accepting
folks
who
also
want
to
attend
this.
A
So
save
your
seat
submit
something
if
you're
interested
and
there
is
the
link
and
I'll
add
it
to
the
notes
here
when
we
get
to
the
next
section.
So
thanks
everyone,
that's
what
I've
got
the
next
section
we
have
in
our
stuff.
Today
is
the
coop
Con
recap
and
thoughts
on
coop
con,
and
there
was
a
lot
that
happened
there.
We
had
the
summit
before
hand
we
had
coop
con,
we
had
a
se
gaps,
deep
dive
and
an
update
and
plus
everything
else
that
happened
there.
A
B
Just
a
general
recap
on
things
that
happen
at
giv,
con
or
just
experiences,
and
that
kind
of
stuff
or
related
specifically
just
a
gaps.
Sure:
okay.
Yes,
that's
an
awesome
answer,
so
my
recap
from
kimkim.
There
was
a
lot
of
interesting
topics.
If
you
saw
up
basically
every
single
vendor
those
had
sig
apps,
everyone
was
interested
in
the
end-to-end
continuous
integration,
continuous
deployment
scenario
for
applications.
So
people
were
you
be
having
vendors
like
V
or
weave
works.
You'd
have
like
SUSE
day
is
coming
out
with
a
can.
B
Enterprise
could
be
in
any
solution
and
that
kind
of
stuff,
but
then
also
there
were
other
solutions
out
there.
That
would
basically
like
either
on-premise
or
there
were
cloud
hosted
and
n
solutions
for
deploying
applications
and
actually
Kelsey
Hightower
had
a
good
demo
from
the
gke
cloud.
We
were
doing
this
too,
so
I
thought
that
was
an
interesting
thing
that
was
going
on.
Everyone
seems
to
be
talking
about
service
mesh,
which
was
an
interesting
topic
as
well.
B
C
Just
thought
I'd
mentioned
one
key
note
that
I
thought
was
particularly
applicable
to
apps
the
the
keynote
that
Brandon
Phillips
did
on
the
tectonic
dashboard
and
an
app
lifecycle
in
there.
I
think
it
was
like
a
five
minute
demo
and
I'll
try
and
find
the
video
and
paste
into
the
chat,
but
I
thought
I
thought
that
was
particularly
interesting.
D
Wove
well
into
some
of
the
other
themes
about
making
kubernetes
more
approachable
in
general
and
how
we
can
start
to
onboard
new
users
to
the
platform
and
some
of
these
things
that
we
may
take
for
granted.
Now
that
we
understand
and
know
them
well
aren't
as
easily
approachable,
so
I
thought
that
was
kind
of
an
interesting
way
of
breaking
down
the
different
use
cases
for
kubernetes.
A
A
I'll
share
one
real,
quick
one
here.
If
anybody
wants
to
think
about
it,
one
thing
that
I
noticed
was
the
global
audience
we
had
there.
We
had
people
from
all
over
and
I
met
a
number
of
people
who
were
not
native
English
speakers
and
had
conversations
with
them,
in
particular,
after
the
cig,
apps
update
and
deep
dive,
and
both
times
I
met
people
who
struggled
with
English,
who
are
diving
into
kubernetes
and
came
to
the
u.s.
A
E
Last
year
and
when
we
were
in
Seattle
a
lot
of
the
conversations
and
a
lot
of
the
talks
were
hey,
look,
I
can
run
kubernetes
in
my
business
grab
my
businesses
this
year.
It
seems
that
it's
moved
on
to
say
all
right.
Well,
we
figured
out
it
works
and
now
this
is
why
we
see
the
deeper
talks
into
like
service
messages,
because
we'd
prove
that
the
basics
from
there.
So
that's
a
that's
a
great
bit
of
success
for
a
year.
F
Yeah
I'll
add
a
quick
one.
I
thought
it
was
really
interesting.
You
know,
given
the
growth
and
everything
that's
going
on
with
kubernetes
I
thought
it
was
really
cool
to
see
how
it
seems
like
the
CN
CF
is
going
through
a
similar
growth
pattern
that
the
OpenStack
foundation
did
about
three
or
four
years
ago,
and
I'm
really
encouraged
to
see
that
the
CN
CF
and
the
open
static
foundation
kind
of
elders
are
talking
with
each
other
and
sharing
information.
I
thought
that
was
really
cool,
also
I.
F
A
Yeah
and
I
definitely
agree
with
that.
In
fact,
I'm
gonna
be
curious
to
see
how
CR
DS
can
become
easier
to
use
and
understand.
In
fact,
that
was
one
of
the
things
that
was
brought
up
to
me.
More
than
once
was
misconceptions
about
C,
RDS
or
places
you
can
use
them
and
how
we
can
use
them
there
that
knowledge
gap
from
people
who
know
it
to
try
to
get
that
out
to
just
so
many
more
people
who
are
now
interested
in
it.
F
Yeah
definitely
I
think
a
big
part
of
that
too
is
locking
down
what
it
means
to
have
a
controller.
Looking
at
a
lot
of
the
controller
examples
that
are
out
there,
it
seems
like
a
lot
of
this
stuff.
Is
you
know
that
they're
similar
in
some
ways
but
I,
don't
see
any
sort
of
unifying
effort
to
say
this
is
what
a
controller
is.
Maybe
it
exists,
I
just
haven't
seen
it,
but
I
think
I
think
that's
gonna
be
a
big
part
of
making
CR
these
taking
it
to
the
next
level.
If
you
will.
G
H
There
is
some
kind
of
formalism
around
what
a
controller
is,
but
it
is
also
somewhat
loosely
specified
and
that's
for
a
reason.
I
mean
everything
in
kubernetes
control.
Plane
is
a
controller
of
some
type
right
like
there's,
no
controller,
end
points,
control
or
service
controllers
for
CRD
controllers
and
custom
controllers.
F
Yeah
I
guess
like
I'd
love,
to
see
any
sort
of
that.
That
information
that
specifies
kind
of
like
I
mean
requirements
is
probably
too
hard
a
word,
but
just
from
looking
at
the
the
patterns
that
are
out
there,
it
seems
like,
if
you
have
some
sort
of
application.
That's
you
know
containerized
and
has
a
certain
level
of
you
know:
service
account
permissions
or
whatever
it
seems
like
you're
you're
in
the
territory
of
a
controller,
so
like
I
I,
would
love
to
see
any
sort
of
formalisms.
That
would
start
to
talk
about.
F
A
All
right,
thank
you,
does
anybody
else
have
any
other
thoughts
on
coop
gun
and
by
the
way
for
those
of
you
who've
had
thoughts.
I
haven't
been
able
to
get
them
very
well
into
the
notes,
but
I'm
gonna
start
adding
them
in
there.
If
you
wanted
to
add
some
of
those
into
the
recap
and
thoughts
section
of
the
notes,
please
do
anybody
else
have
any
thoughts.
A
A
All
right,
so
there
is
one
more
thing
I'll
throw
in
here.
If
you
want
to
see
the
slides
that
were
presented
from
the
say,
gaps
update,
they
are
here,
there's
a
couple
other
things
that
I
added
after
that
some
of
the
stuff
that
caught
my
interest
like
helm,
has
more
contributors
to
it
than
projects
even
like
Prometheus
and
fluent
D,
and
some
of
the
others.
A
That
number
is
often
seen
as
far
greater
than
the
number
of
people
who
actually
operate
the
clusters,
and
so
it's
gonna
be
interesting
to
see
how
that
space
comes
together,
and
there
was
a
little
bit
of
that
conversation.
So
I'll
leave
it
at
that.
If
you've
got
other
questions
about
what
was
talked
about
and
the
slides
are
there
and
and
I'm
not
sure
if
it
was
videoed,
if
it
was
we'll
get
that
up,
that's
what
I've
got.
A
I
I
am
I
I,
just
I'm,
really
sick
and
I
had
a
coughing
fit
and
I
leaned
down
and
I
just
broke
my
desk
off,
and
my
keyboard
is
saying:
oh
no,
no,
that
was
that
was
quite
spectacular.
So
if
somebody
could
take
notes
that
would
be
super
super
cool,
and
this
will
be
a
fairly
high
lift
on
notes,
because
you're
gonna
need
to
capture
what
people
say
as
we
move
through
this.
So
so.
I
Thank
you,
yeah
I'll,
try
and
maintain
a
desk
integrity
long
enough
to
make
it
so
yeah.
Just
a
quick,
a
bit.
First
of
all,
I
want
to
congratulate
sue
gaps
as
the
only
sig
that
has
consistently
done
retros
for
the
last
four
releases,
so
basically
a
calendar
year
which
is
really
impressive
and
frankly,
it
shows
in
what
happens
in
the
sig
there's
a
high
level
of
sophistication,
and
everybody
has
really
been
focused
on
improvement
and
it's
really
impressive.
I
I
I
We
want
to
keep
it
really
positive
and
upbeat,
but
also
I
get
to
the
kernel
of
truth
around
something,
and
so,
if
you
find
yourself
having
had
some
sort
of
frustration
with
another
individual
or
group
of
individuals,
my
ask
is
that
you
focus
on
the
process
or
the
the
procedures
that
went
into
making
the
the
situation
difficult
as
opposed
to
the
actual
people.
If
there
are
people
problems,
those
are
best
addressed
either
individually
or
at
the
sig
leadership
level.
So
an
area
I
want
to
go
quickly
through
what
we
said.
I
We're
going
to
do
for
this
release
last
retro
and
I
don't
want
to
necessarily
deep
dive
into
these,
but
I'd
love
for
you
just
to
think
about
your
part
and
how
successful
we
were
in
getting
these
done.
First
of
all,
was
automation
around
release.
Notes,
second,
was
actionable.
Alpha
releases
and
artifacts
third
was
a
better
practice.
A
better
BEC
best
practices
guide
for
charts.
I
Another
was
blog
post
at
the
end
of
the
release
for
best
practices
or
new
charts
and
other
was
a
client
that
doesn't
break
over
patch
releases
and
better
being
backwards.
Compatible
and
last
was
should
not
vendor
directly
from
kubernetes,
should
use
go
to
EPS
instead,
and
there
was
supposed
to
be
a
discussion
around
veneering
with
API
machinery
and
I'm,
not
sure
if
that
happened
or
not.
So
those
are
the
things
that
we
specifically
identified
from
the
1.8
release
cycle
that
we
were
hopeful
that
we
might
integrate
into
one
that
night
so
I.
I
If
there
are
some
of
those
that
need
to
carry
forward,
let's
make
sure
that
those
get
put
into
what
we
can
do
differently
for
110.
So
without
further
ado,
I'm
going
to
open
the
floor
to
what
went
well
and
when
not
9:00.
These
are
could
be
just
for
the
sake
in
general
or
if
there
is
any
individuals
that
were
particularly
helpful
or
or
or
just
anybody.
You
want
to
call
out
as
being
somebody
that
was
instrumental
in
success
for
1.9,
I
or
anything
that
you
saw
a
kook
on.
That
was
particularly
useful.
I
Yes,
we'll
give
that
about
five
minutes
in
the
moment
on
to
what
could
have
gone
better
and
also
I,
know
I'm
talking
faster,
but
we
don't
have
much
time
if
you
want
to
write
in
the
next
section
about
what
could
have
gone
better.
This
document
is
that
people
so
just
put
in
parentheses,
yeah
your
name
and
your
comment
and
and
then
we'll
get
to
that
in
a
second,
so
go
ahead
and
fire
away
with
what
went
well.
B
I
Pasted
that
in
chat,
awesome
and
sorry
about
that
I
should
have
done
that
beforehand.
It's
also
in
the
agenda
for
today.
H
A
Yeah
I'd
actually
like
to
jump
on
something
that
just
to
jump
on
the
testing
thing.
Both
you
know
the
test
stuff
that
I
called
out
earlier,
fake
and
mush,
and
just
trying
to
find
out
how
to
are
trying
to
get
our
testing
in
better
shape,
and
so
we
are
less
flaky.
We
used
to
be
one
of
the
worst
that
was
actually
one
of
the
areas
we
needed.
I
A
Maybe
another
thing
that
we
did
well:
we
got
the
controller's
part
of
the
workflow,
a
Aarthi
workloads
API
to
GA,
so
there's
AB
sin
and-
and
that
makes
me
happy
because
quite
frankly
going
forward.
That
means
we
don't
have
to
deal
with
the
differing
api's
and
config
files
and
especially
helm,
charts
and
stuff,
like
that,
if
it's,
this
version
use
this
deal
with,
that,
we
can
start
to
move
into
a
world
of
stable
API.
A
I
In
the
interest
of
time
we'll
go
on,
if
you,
if
things
come
up
during
the
retro,
you
just
something
comes
up
to
you
and
you
want
to
call
out
somebody
that
did
something
great
or
something
that
you
think
well.
We
can
definitely
do
that,
but
I
definitely
want
to
get
into
what
could
go
better
because
that's
how
we
get
better.
So,
let's
go
ahead
and
open
the
floor
to
whoever
wants
to
start
here.
I
B
Okay,
so
one
of
the
things
from
the
last
release
retrospective
that
we
said
that
we
were
interested
in
improving
on
was
the
backwards
compatibility
things
for
us,
not
mr.
steak,
API,
Machinery,
Clank,
oh
and
whatnot,
but
before
for
helm
and
for
other
ones,
I
think
we're
still
in
that
state
of
where
we
have
to
just
because
of
the
nature
of
API
versions.
Changing
and
migrating
over
we've
had
to
break
a
couple
of
things
in
the
API.
B
It
thinks
some
endpoints
inside
a
client
go
change
from
one
to
another,
but
anyway,
regardless
of
that
I
think
it's
great,
but
a
lot
of
things
are
moving
to
one
but
I
think
you'd
be
very
interested
in
seeing
or
not
and
seeing
if
there's
a
way
we
can
get
involved
with
trying
to
make
a
client
that's
a
little
bit
more
backwards
compatible.
So
we
don't
have
to
break
all
the
dependencies.
Every
release.
A
Yet
to
give
insight
into
that,
this
problem
is
something
that
we
tried
to
start
tackling
in
the
1.9
time
frame,
and
it
turns
out
it's
a
lot
harder
than
I
ever
anticipated
and
so
yeah
we
could
have
done
better
and
maybe
in
communicating
that
and
getting
more
people
involved
and
one
of
the
things
that
I
think
we
can
do
differently.
Moving
beyond
is
figure
out.
How
do
we
wrote
people
into
getting
some
of
this
client
stuff
going
both
in
go
and
in
other
languages
and
get
a
little
bit
more
going
with
the
sig
API
machinery?
B
I'm
just
curious:
is
there
any
cloud
providers
or
anything
right
now
that
actually
can
deploy
a
1.9
cluster
as
of
Friday
afternoon,
or
is
it
still
a
mini
cube
and
other
ones
still
trying
to
be
in
flux,
because
that
could
be
a
retrospective?
Is
availability
of
deploying
a
one
dot
I
plus
tur?
If
that's
possible
today,
I
know
cube
atom
is
definitely
one
that
could
probably
deploy
it,
one
that
I'm
but
are
they're
supported
cloud
providers
for
people
to
test
this
out.
I
Yeah,
that's
an
interesting
thing
for
sure.
It
also
calls
out
like.
Should
there
be
some
sort
of
conformance
testing
around?
You
know
different
cloud
providers
like
the
G,
ke
and
other
you
know
Amazon.
You
know
all
these
cloud
offerings
like
is
there?
Should
there
be
some
sort
of
conformance
testing
against
provider
manage
providers
in
renée's
relators
we're.
B
Not
even
better,
but
it's
there
a
way
that
we
could
document
a
process
for
users
who
are
interested
in
chomping
the
pit
and
testing
out
1.9
as
soon
as
it's
released,
because
as
far
as
as
far
as
I'm
aware
I'm,
not
sure
of
any
others
who
were
we
know,
any
better
processes.
I've
essentially
had
to
either
wait
for
mini
cube
to
release
a
1.9
or
for
1.8.
We
had
to
wait
until
mini
cube,
had
done
that
or
are
people
using
like
cube
atom
to
actually
deploy
a
cluster
locally.
J
J
We
are
also
working
towards
making
head
or
something
close
to
head
more
widely
available
in
those
environments
as
well.
You
can
always
deploy
a
cluster
of
VMs
in
GCE
and
deploy
1.9
to
those.
Of
course,
that's
a
more
involved
process
for
more
advanced
users,
but
that
that's
been
our
approach
and
I
would
assume
that
other
cloud
providers
are
in
a
similar
situation
where
customers
are
more
concerned
with
stability
than
having
newest
features
at
the
holiday
time.
B
Right
exactly
yeah
and
I
can
totally
understand
it
from
the
cloud
cover
perspective
because,
like
I
am
from
the
azure
team
and
so
we're
focused
as
well
on
stability
and
making
sure
that
customers
have
a
that.
We've
tested
out,
1.9
and
stuff
like
that,
but
for
the
people
who
are
less
so
interested
about
stability
or
a
that
in
trying
to
test
out
these
new
releases
sleeping,
be
ahead
of
it,
I'm
quite
interested
in
like
if
we
have
any
documentation
or
if
we
don't.
B
J
G
J
Cloud
provider
extraction
working
group
on
setting
up
a
framework
for
other
cloud
providers
to
run
continuous
integration,
Swedes
run
the
conformance
test
and
post
back
to
tested
so
that
we
can
expose
any
issues
across
cloud
providers
earlier
in
the
process.
So,
if
anyone's
interested
in
that
and
not
aware
of
it,
you
can
reach
out
to
me.
You
know.
Oh.
A
I
I
Development
cycles
time
so
obviously
it's
not
quite
as
involved
as
is
the
last
release
and
probably
1/10
will
be
I.
Have
a
question
did
how
did
everybody
feel
as
far
as
planning
and
preparation
for
the
release
and
all
that
was
did
it
feel
like
there
was
enough
level
of
organization
not
enough
too
much?
How
did
that
all
feel.
B
From
an
outsider,
who
was
not
publicly
there
at
the
at
the
planning
meetings
41.9
and
what
not?
Having
that
roadmap
and
seeing
the
deadlines
for
when
when
I
was
being
released,
was
incredibly
helpful
for
us
because
I'm
we
were
able
to
plan
a
held
release
well
in
time.
So
then
we
could
get
a
1.9
for
a
helm
release
with
kubernetes
one
boy
I
supported,
and
we
have
a
pull
request
in
place
for
kubernetes
1.9
when
it
were
before
he
was
released
and
now
as
soon
as
it
was
released.
B
A
So
there's
probably
one
here
that
I
see,
is
a
very
good
action
item
and
Matt
Fisher
brought
it
up.
Is
the
client
go
and
how
do
we
go
forward
with
that?
There's
been
talk
of
maybe
starting
an
independent
go
client.
That's
not
client!
Go
that
because
that
keeps
being
refactored
internally
and
API.
Machinery
is
so
busy
that
the
next
steps
to
actually
make
it
more
consumable
and
stop
changing
it.
Just
isn't
in
their
near-term
roadmap
they're,
just
very
busy
with
other
things.
A
G
A
H
Are
working
on
it
and
they
are
willing
to
work
with
us.
I
would
strongly
advise
against
forking
a
client
and
then
having
the
proliferation
of
multiple
go
Lane
clients.
We
have
this
issue
with
Java
right
now,
like
which
one
should
I
use
the
official
one,
the
fabricate
ones
so
forth,
and
so
on.
I
mean
I
feel
like
not
fixing
and
being
involved,
in
their
sake,
to
make
sure
that
we
fix.
What
we
have
is
the
wrong
way
to
go
like
we
should
fix
what
we've
got
not
fork,
something
to
make
something
new.
A
They
want
the
next
one
they
were
interested
in
was
like
a
ruby
one,
they're
actually
working
on
clients
over
there
and
those
folks,
and
some
of
the
folks
I
spoke
with
an
API
machinery.
We're
actually
interested
in
creating
a
separate
client
to
go.
Do
this
as
part
of
that
organization,
and
so
it's
probably
something
where
we
could
get.
Maybe
API
machinery,
because
the
API
machinery
folks
they're
happy
to
have
us
work
with
them,
but
they
there.
A
Do
people
think
it's
now
time
to
go,
create
a
separate
client
that
the
expectation
is
that
people
use
like
they
would
use
a
typescript
client
and
actually
coordinating
with
the
folks
in
API
machinery,
and
it's
actually
API
machinery
that
owns
the
kubernetes
client
org
and
just
trying
to
figure
out
what
the
best
path
forward
was
because
the
suggestion
initially
came
from
somebody
over
there.
Yes,.
G
There
was
the
computer
submit.
That
was
a
discussion
there
about
a
lot
of
the
client
work.
That's
one
of
them
is
worth
noting
about
the
the
girl
client
is
a
bit
is
obviously
weird
compared
to
everything
else,
because
it
basically
just
sort
of
it
exists
for
committees
usage,
but
is
then
sort
of
you
can
include
it
it's
a
huge
package.
It
has.
It
has
sort
of
features
that
they
say
that
other
clients
don't
have
by
virtue
of
it.
Being
this
sort
of
weird
first-class
thing
and
I
think
some
people
will
then
solve.
G
H
There
are
other
Enterprise
Java
integrations
like
spark
airflow
and
many
other
things
that
don't
use
client
go
and
do
you
use
the
Java
client?
It's
not
like
you
have
to
go
with
go.
I
can
certainly
understand
what
people
might
show,
go
preference,
given
the
feature
set
represented
by
client,
go
and
how
it
has
become
kind
of
a
special
client,
but
I
just
don't
see
how
we're
gonna
solve
any
of
our
problems.
By
trying
to
rewrite
it.
I
mean
here's.
A
A
question
though
client
go
is
incredibly
painful
for
people
to
use,
especially
when
they
have
to
upgrade
it's
become
a
real-time
suck
where
people
are
just
really
getting
tired
of
using
it,
and
there
are
now
some
other
ones,
starting
to
pop
up
in
the
general
community
to
get
around
that
to
have
more
of
a
stable
API
and
the
client.
The
folks
who
work
on
client
go
have
said
in
2018.
A
H
Conversation
with
them,
I
mean
I,
know
they're.
Definitely
in
talking
to
them.
I
know
they
are
definitely
focused
on
making
the
developer
experience
better
for
people
who
are
trying
to
write
third-party
controllers
and
write
API
extension
servers
and
for
people
who
have
to
import
client
go
and
manage
those
dependencies,
but
maybe
talking
to
them
and
like
you're,
saying
getting
some
commitment
out
of
them
with
respect
to
a
time
frame
and
a
delineation
of,
what's
achievable
when
I
mean
that
seems
very
reasonable.
H
A
And
I
wonder
how
different
the
case
is
for
somebody
writing
a
controller
versus
somebody
writing
a
tool
like
compose
or
one
of
the
other
many
ecosystem
tools
that
I
wonder
how
different
the
use
cases
are
there
and
what
they
have
to
do.
I'd
be
curious
to
find
those
differences,
but
in
either
case
we're
taking
up
a
whole
bunch
of
retro
time,
although
I
think
we
have
it
to
discuss
this
I'll.
Take
the
action
to
set
up
the
meeting.
I
A
Yeah
and
I'll
say
it
does
and
just
to
give
a
little
thing
here,
so
we
discussed
the
timing
and
the
issues
with
things
like
home
getting
out
in
these
retrospectives,
so
one
of
things
I
did
was
I
took
that
schedule
and
I
went
and
I
nagged
the
home
team
with
it
because
of
the
retrospective.
So
then
they
knew
how
to
plan
for
this
next
time
and
it
just
took
a
little
nagging
there,
but
it
all
happened
because
of
this
to
try
and
drive
some
of
the
movement
forward
and
so
I'm
finding
it
to
be
useful.
A
I
I
And
the
segue
into
the
next
thing:
there
is
a
talk
about
planning
and
I,
put
a
link
in
the
meeting
agenda
about
this
draft
that
we
have
that
we're
working
on
for
as
we
try
and
improve
the
features
process
and
I
put
it
in
there,
but
you
certainly
don't
have
to
use
it
and
it
may
not
be
relevant.
But
if
you
do
decide
you
want
to
use
it.
Let
me
know
we
can
can
go
through
some
that.
A
I
Just
generally
speaking,
the
cap
is
the
kubernetes
enhancement
proposal
and
it's
a
way
to
take
our
sort
of
existing
cargo
cult
culture
around
how
we
do
proposals
and
keep
metadata
and
all
that
stuff,
basically
to
try
and
provide
a
template,
so
people
can
have
have
data
to
track
release
over
release.
So
when
you're
delivering
something
huge,
it
makes
sense,
release
over
release
and
it's
actually
ke
p
I--.
I
But
so
basically
these
are
the
sort
of
rocks
or
epics
or
what.
However,
you
want
to
refer
to
them.
That
cross
multiple
release
milestones
and
the
idea
is
that
eventually
we'll
be
able
to
automate
these
into
some
consumable
format.
They'll
be
metadata,
so
you
can
look
at
any
proposal
and
kind
of
find
out
where
it's
at
and
its
life
cycle,
if
it's
halfway
through
being
implemented
or
all
the
way.
It
also
allows
us
to
have
something
to
talk
about
if
there's
architectural
concerns
or
whatnot.
I
So,
just
you
know
in
your
mind,
think
of
CAP
as
being
the
next
generation
of
what
a
proposal
is,
and
so
one
of
the
nice
things
about
having
a
proposal
process
that
is
consistent
is
that
we
can
have
the
implementation
around
the
proposals
be
consistent
as
well
so
right
now
the
feature
process
is
a
little
bit
cargo
cult
as
well.
So
we
sort
of
have
this
disembodied
process
for
tracking
features
and
the
features
repo,
and
then
it
goes
into
a
spreadsheet
somewhere,
and
nobody
has
any
idea
if
it
needs
Docs
or
not.
I
I
Essentially,
the
item
one
and
to
become
feature
issues
in
in
the
kubernetes
community's
repo
or
the
community
selim
or
wherever
that
is,
and
you
track
the
work
on
those
issues
throughout
the
release
and
basically
that's
that
is,
takes
the
place
of
the
features
repo.
So,
in
order
to
get
to
that
place,
we
you
know
during
planning.
We
basically
outline
all
things
you
need
to
know
during
the
release
to
kind
of
sketch
out
those
issues,
those
those
milestone
issues.
So
it's
really
not
complicated.
It's
just
a
matter
of
like
where
do
you
store
the
information?
I
And
why
not?
So,
in
the
absence
of
a
cap,
we
can
just
start
with
the
implementation
part
which
is
saying
what
you
want
to
try
and
deliver
for
1.10
and
kind
of
sketch
out
risks
and
dependencies
and
those
things
so
that
we
know
if
you
haven't
seen
it
a
dependency
on
API
machinery
or
something
else
that
we
can
try
and
untangle
those
things
sooner
in
the
process.
So
you
don't
get
halfway
done
and
be
like.
Oh
no,
now
what
so,
that's
pretty
much
it
in
that
show.
I
A
I've
got
a
question:
have
we
talked
about
how
this
relates
to
kubernetes
versus
sub-projects,
so
to
relate
to
something?
That's
not
that's.
Tangental
here,
like
mini
cube,
it
was
brought
up
earlier.
Is
it
the
case
where
a
major
feature
and
something
like
mini
cubes,
should
try
to
go
through
this
process
as
well
as
kubernetes
kubernetes
or
for
the
time
where
we
just
focused
on
kubernetes
kubernetes
parts,
mostly.
I
Kubernetes
kubernetes,
but
I
would
say
that
there's
probably
a
lot
of
value
in
detangling
dependencies
and
having
an
idea
what
you
want
to
deliver
regardless.
So
if
there's
a
handy-dandy
template
that
we're
working
on,
it's
not
ready
yet
mind
you,
but
in
terms
of
the
planning
and
whatnot
that
I
think
that
any
project
that
wants
to
know
what
they're
gonna
deliver
over
the
course
of
three
months,
which
is
tricky
at
best.
B
So
J's,
how
do
we
get
involved
not
with
her
process
itself,
but
how
do
we
get
involved
would
be
like
understanding
the
cap
and
understanding
the
process
itself,
because
I
was
actually
interested
in
I.
Was
gonna?
Give
a
talk
about
this
at
the
helm,
developer
summit
about
how
we're
gonna
migrate
over
if
we
are
doing
helm
3?
How
do
we
document
the
process
for
new
features
and
I
was
interested
in
coming
up
with
a
design
document
or
proposal
that
was
basically
better
based
on
Python
apps,
which
I
assume
cats
are
kind
of
and
related
to?
B
I
Exactly
what
is
yeah
and,
in
fact,
like
the
rest,
RFC
process
as
well,
so
some
of
it
came
from
that
we're
trying
to
try
not
to
reinvent
the
wheel
here
right
that
so
there
is
a
there
is
an
actual
document.
I
will
find
it
and
send
it
to
the
cig,
apps
mailing
list,
and
just
so
people
if
they
want
to
familiarize
themselves
with
it
I,
don't
have
it
right.
I
It
stub
my
head,
but
there's
probably
that
yes
yeah,
so
we're
trying
to
instigate
architecture
we're
trying
to
refine
this
it's
hard
because
rolling
out
something
like
this
across
the
project
is
so
incredibly
hard
and
getting
consensus
on
what
the
right
things
are
and
the
level
of
specificity
and
went
on
so
any
feedback
we
get
on
this,
the
more
people
we
get
looking
at
it.
Please
please
help
us
make
this
the
best
thing
it
can
be
because
I
feel.
I
A
Yeah
and
and
I'll
bring
up
here,
I
actually
own
the
task
to
move
the
or
to
do
the
PR
to
move
the
cap
and
cap
documentation
at
the
top
of
the
community
repo
and
try
to
expose
some
more
details.
So
we
can
start
improving
our
communication
on
it,
so
that
should
be
coming
soon,
but
I
expect
there
to
be
lots
of
questions.
And
so,
if
folks
have
questions,
ask
the
saiga
architecture.
A
Mailing
list
is
probably
a
good
place
because
they
synchronously
people
can
respond
to
you
and
the
folks
who
crafted
it
and
know
the
most
intent
and
what's
going
on,
are
part
of
that
list.
So,
as
you
have
questions,
please
ask,
and
hopefully
people
can
jump
on
a
respond,
although
they'll
probably
be
slow
for
the
next
few
weeks.
I
A
We'll
probably
end
up
pushing
the
bulk
of
our
planning
to
offline
in
afterwards.
Okay,
things,
I
compose
and
home
tend
to
plan
a
little
bit
differently
from
this
I
think
there's
two
areas
where
this
comes
to
mind
as
being
interesting.
One
is
I
think
there
was
some
stuff
that
Kenneth
wanted
to
do
around
the
jobs
API
stuff
in
110,
and
that
was
things
like.
A
A
And
this
provides
that
traceability
to
the
broader
app,
no
matter
how
how
you
manage
it
with
dependencies
or
not,
and
is
there
a
way
to
capture
that
at
a
much
higher
level?
And
what
would
that
look
like?
And
so
that's
what
this
is
I,
don't
know
that
well,
actually
how
much
will
get
done
in
the
one
ten
timeframe.
But
this
is
one
of
those
things
that
came
out
of
the
app
dev
working
group
as
something
to
dig
into
and
I
don't
see
him
on.
A
I
Well,
I
tell
you
what
I'm
gonna
do
I'm
gonna,
I'm
gonna
drop
off,
but
I'm
gonna
enable
alright
avail
myself
to
the
sake.
If
you
want
to
do
any
kind
of
planning
or
want
me
to
help
like
help
detangle
dependencies
or
whatever
it
is,
or
even
help,
try
a
sample
kept
I
would
love
to
help.
You
all
do
that,
because
I
think
that
this
there's
a
tremendous
amount
of
value
here
and
it's
just
a
matter
of
trying
to
fine-tune
the
process
all
right.
Thanks.
A
A
All
right,
we've
got
a
few
minutes
left
and
so
I
won't
dig
into
the
planning
stuff
today,
because
we've
only
got
a
few
minutes
left
and
we
can
get
a
little
long
on
it.
The
one
thing
that
I'll
say
that
I
forgot
to
do
in
the
announcement
earlier
was
the
charts,
repo
github.com,
/
kubernetes
/
charts
is
now
set
up
to
use
owners
files
like
everything
else,
and
so
people
can
self
manage
their
charts.
A
We're
gonna,
let
maintainer
x',
who
show
they
can
do
a
good
job
self,
manage
their
the
charts,
they've
got
and
we'll
do
that
through
owners
files
and
just
like
on
kubernetes
itself.
They
can
do
looks
good
to
me
on
it
with
reviewers
and
approvers,
and
that's
now
in
place
and
working
and
mildly
documented
on
the
charts
repo,
even
how
somebody
can
become
an
owner
and
get
their
owners
files
and
what
they
need
to
do
with
some
examples.
A
H
A
K
Okay,
Matt,
it's
John,
can
you
hear
me
sure,
can
hey?
How
are
you
good?
How
are
you
good,
I'm
wondering
I
wanted
to
say
something
about
the
topic
you
just
brought
up
so,
first
of
all,
what
is
the
like?
What
is
the
ideal
workflow
into
your
mind,
coming.
A
The
ideal
workflow
this
is
something
that's
a
kubernetes,
so
on
the
charts,
repo,
there's
a
reviewing
guidelines
document
that
has
the
details
of
the
process
and
we're
going
to
be
expanding
on
that.
But
a
chart
should
basically
follow
best
practices
which
are
going
to
be
slowly
added
to
here.
In
addition
to
the
chart,
best
practices
that
are
in
the
helm,
documentation
and
then
there's
certain
CI
tests
that
obviously
need
to
pass
and
if
it's
following
best
practices
and
passes
CI,
then
a
chart
maintainer
or
a
chart.
A
A
A
A
That's
the
kind
of
thing
that
just
in
general
and
open
source
I,
tend
to
take
the
first
one
that
came
in
or
the
best
one,
probably
the
best
one.
First,
if
somebody
was
more
complete
and
then
that's
the
one
that
can
go
in
and
then
the
other
one
is
overcome
by
events
or
a
duplicate
or
you
know
it's
a
duplicate.
K
K
A
We
actually
encourage
maintaining
the
chart
within
the
charts
repository
right
now.
We
are
working
on
functionality
that
does
not
exist
to
take
charts
from
trusted
external
sources.
One
of
the
big
reasons
for
that
was
stuff
like
get
lab,
get
labs.
The
folks
I
can't
lab,
don't
want
to
maintain
their
gitlab
chart
on
github
they'd
like
to
maintain
it
on
kitte
lab
right,
and
so
we
are
looking
at
adding
that
kind
of
process
to
it,
but
it
is
not
ready
to
go
yet.
K
K
A
There's
a
there's
a
plug-in
in
the
kubernetes
infrastructure
called
blunderbuss,
which
probably
doesn't
tell
you
anything
about
what
it
does
and
when
it's
enabled
on
a
repo.
It
can
look
at
the
reviewers
in
an
owner's
file
and
a
pull
request
and
the
code
that
was
changed
in
it
and
then
notify
or
actually
request
review
from
people
who
are
reviewers
in
the
tree.
A
For
that
particular
thing,
and
we
just
turned
that
on
as
well
and
so
once
a
reviewer
is
a
member
of
the
community
and
in
the
reviewers
file,
when
a
pull
request
comes
in,
the
tooling
should
request
to
their
review
of
the
chart
or
of
the
pull
request
for
the
chart.
And
so
that's
a
new
thing.
That's
also
just
landed
I
forgot
to
say
you.
K
A
A
Going
once
going
twice
going
three
times,
thank
you,
everyone
for
coming.
This
was
the
last
meeting
we
have
of
2017
the
next
time
we
have
will
be
in
2018.
It's
not
New,
Year's
Day,
which
I
think
is
a
Monday.
It's
the
Monday
afterwards,
so
have
a
wonderful
rest
of
the
year
happy
holidays,
and
we
will
see
you
all
next
year
thanks.
Everyone.