►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
SIG Apps Deep Dive – Janet Kuo & Kenneth Owens, Google (Intermediate Skill Level)
SIG Apps is dedicated to all facets of designing, developing, and running applications on Kubernetes. This is a working sessions and the content will be driven by the interests of the attendees. Topics could involve Helm, Charts, the workload APIs, tool development, tool interoperability, or any other topic relevant to the space. This is your opportunity to let your ideas help shape the future direction of the community.
About Janet Janet is a Software Engineer for Google Cloud. She joined the Kubernetes project before the 1.0 launch in 2015. She is an active SIG Apps contributor and the owner of Kubernetes workload APIs. She strives to build the best experience for running workloads in Kubernetes.
About Kenneth
He is a software engineer at Google.
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
Well,
first
of
all,
given
that
it's
like
8:30
I'd,
like
to
thank
you
all
for
showing
up
I
mean
this
is
kind
of
late
in
the
evening
for
most
of
us.
So
this
is
the
siga
deep
dive.
I'm
looking
around
I
see
a
lot
of
you
guys
and
know
most
of
you,
some
of
you,
some
of
your
new
faces.
So
just
out
of
curiosity,
how
many
people
know
what's
the
gaps
is.
A
Okay,
so
mostly
this
side
of
the
room,
all
right
so
for
you
guys,
say,
gaps
is
kind
of
on
one
side,
it's
kind
of
a
landing
page
for
kubernetes,
it's
kind
of
eclectic.
It's
designed
for
people
who
are
developers
of
kubernetes
people
who
develop
things
that
are
in
the
ecosystem,
like
helm,
draft
compose
and
for
people
who
work
on
the
core,
workflows
API.
So
that's
deployment
staple
set
replica
set
replication
controller
which
hopefully,
nobody
in
the
room
is
still
using
in
production.
A
Now,
if
everybody
read
the
description
of
this
session,
it's
really
meant
to
be
a
working
session.
So
this
is,
you
know
your
sig,
the
sessions
for
you.
So
the
topics
that
we
want
to
come
together
and
talk
about
are
topics
that
we're
gonna
decide
in
the
room
right
now
and
if
there
are
no
suggestions.
Well,
I've
got
a
few
in
my
back
pocket
that
we
can
just
bring
up
and
then
the
other
thing
is.
A
We
were
planning
to
actually
split
up
and
do
discussions
in
kind
of
small
groups,
but
that
was
when
we
were
looking
at
the
participation
and
it
was
like
178
we're
a
much
smaller
size
than
that.
So
do
we
like
it
by
show
of
hands.
Do
we
want
to
split
up
into
small
groups
and
talk
about
particular
subjects,
or
do
we
just
want
to
kind
of
talk
about
subjects
as
a
room.
A
B
A
A
A
Okay,
so
if
we
go
with
this
set,
that's
and
we
do
10
minutes
a
topic-
that's
pretty
much
gonna
be
all
time.
So
do
we
want
to
suggest
a
few
more
things
and
decide
what
we
want
to
talk
about,
or
do
you
wanna
kind
of
adopt
this
as
what
we
want
to
talk
about,
so
we
can
talk
about
service
message,
messaging
and
Janet
could
probably
speak
fairly
intelligently
on.
That
is
everyone
else
in
the
room?
Well,
yeah,
let's
put
it
up
there
right,
we
can.
We
can
go
with
that
and
see
where
that
takes
us.
A
Ok,
so
in
terms
of
where
we
start
I
guess
we
can
start
with
applications.
So
what
was
the?
What
was
the
first
kind
of
thing?
What
is
an
application
on
kubernetes
I
mean
that's,
that's
a
pretty
good
question.
I,
don't
think,
there's
actually
an
official
definition
of
that
right
now
and
kind
of
if
you
install
something
that's
an
app
and
kubernetes.
What
you
really
get
is
a
loosely
coupled
group
of
network
primitives
like
services,
maybe
some
work
loads
controllers
like
staple
sets
and
deployments
and
ultimately
a
bunch
of
pods.
A
Then
some
storage,
primitives
pvcs
Peavey's
that
kind
of
loop
together
to
form
what
an
application
is
and
I
guess.
Traditionally,
we
think
of
an
application
that
provides
something
that
provides
value
to
an
end
user
or
a
service
to
maybe
another
service.
If
you
have
a
micro
services
architecture,
so
let
me
ask:
does
anybody
have
any
thoughts
on
what
an
application
is.
A
A
A
Well,
then,
you
run
it
right,
but
that
sort
of
manifests
that
distribution,
it's
very
different
characteristics
and
there's
a
very
different
set
of
concerns
around
it.
Then,
when
you're
actually
running
the
application
right
on
one
side,
you're
you're
concerned
with
telemetry
coordinates
ensuring
that
the
application
is
up
and
looking
at
the
performance
of
the
application,
with
package
management
you're
ensuring
that
the
appendices
are
met
and
that
you
actually
installed
what
you
think
you've
installed
and
generally,
hopefully,
that
the
process
of
installing
that
application
is
repeatable
across
multiple
different
environments.
D
A
So
for
most
organizations,
at
least
from
my
experience,
both
irrelevant
right,
like
I'm,
not
gonna,
probably
well,
most
people
probably
aren't
going
to
roll
a
bespoke
database
and
deploy
that
on
top
of
kubernetes
in
a
production
environment,
they'll
install
a
package
like
maybe
he'll,
MySQL
or
he'll
and
Postgres
to
get
the
DB.
But
data
storage
by
itself
doesn't
really
provide
much
value
to
most
customers
right.
A
So
I
guess
I
guess
my
kind
of
thought
was
that,
if
so,
let's
say
I'm
using
helm
to
deploy
applications
into
kubernetes
and
I'm
using
it
to
deploy
packaged
applications
that
I
get
from
another
source
right.
How
am
I
getting
the
bespoke
applications
that
are
developed
internally
into
the
cluster?
Am
I
using
an
entirely
different
mechanism
like?
Is
that
what
how
do
do
people
have
any
input
on
that?
How
do
you
guys
do
that
or
do
you.
E
Yes,
so
we
you
want
for
us,
one
of
the
big
things
we
want
to
do
is
reduce
our
dependency
on
upstream
stuff,
so
cuz
we
run
on
over
to
AWS.
So
we
make
a
big
point
of
taking
all
the
images
we
depend
on
on
pushing
them
into
ECR,
because
if
AWS
is
down
we're
down,
we
don't
need
to
care
about
that.
But
you
know
if
docker
hub
is
down
and
we
can't
start
nodes,
then
that's
a
sad
time.
E
So
for
me,
I
guess,
in
terms
of
applications,
the
I
don't
really
think
sort
of
distinction
between
a
bespoke
application
in
a
and
an
envelope
application
is.
Is
that
useful
in
terms
of
getting
the
applications
onto
the
Kasbah
I
mean
it's
useful
in
other
ways,
especially
when
it
comes
to
packaging
and
things
like
that
I
think,
but
I
think
in
terms
of
actually
the
tooling
that
you
would
use
to
put
the
application
onto
a
cluster.
That's
going
to
be
the
same,
no
matter
what
you're
gonna
have
a
docker
image
and
you're
gonna.
E
Have
you
know
some
associated
shenanigans
around
it
like
services
and
ingresses,
and
all
that
sort
of
stuff
to
make
it
useful
to
other
things,
and
that's
going
to
be
pretty
much
the
same.
The
thing
that
will
be
different
is
where
the
doctor
image
is
sourced
from
and
that's
pretty
much
gonna
be
the
only
difference
as
far
as
I
can
say,.
G
F
An
endpoint
with
the
contract
right,
so
application
in
my
view,
is
essentially
not
not
only
a
single,
so
it
could
be
a
single
service,
but
usually
that's
not
a
very
certification.
You
usually
have
lots
of
packages,
lots
of
so
lots
of
packages
which
have
been
installed
into
a
cluster
and
therefore
become
running
services
which
have
been
managed
by
the
team
together
work
to
create
an
application
which
is
then
a
higher
level
thing.
You
could
offer
obviously
package
the
two
in
two
with
the
dependencies
into
package
two
and
then
this
would
be
a
higher
level
concept.
F
A
Another
team
is
managing
it.
You
care
about
telemetry.
Only
in
terms
of
like
did
it
go
down
and
if
it
goes
down,
who
do
I
call
get
it
back
up?
Get
me
back
inside
my
error
budget
right.
So
then
you
got.
You
know,
white
box
services
and
that's
kind
of
what
we're
talking
about
a
lot
of
times
with
applications
right.
So
I'm
gonna
turn
up
a
bunch
of
primitives,
whatever
they
are,
and
then
I'm
gonna
provide
a
service
potentially
to
another
team.
A
Now,
inside
of
the
company,
you
know
I
own
the
service
I'm
responsible
for
it,
both
the
operations
of
the
service,
the
deployment
of
the
service
and
probably
the
code
for
the
service.
Unless
it's
like
one
of
these
prepackaged
pre
box
applications
like
MySQL,
you
know
so
then
there's
gray
box
right.
You
could
be
sharing
a
cluster
with
somebody
providing
a
service
to
them
and
you
own
the
SLO
you
own,
the
internal
service,
but
from
their
perspective,
it's
black
box
from
the
large
organizations
perspective.
It's
a
black
box
service.
A
A
So
I
mean,
like
all
of
these,
are
kind
of
valid
viewpoints
and
for
future
directions
of
it.
I
mean
we
do
spend
a
lot
of
time
talking
about
it,
but
I
really
I
think
what
we
want,
as
a
community
is
feedback
from
users
and
feedback
from
developers
around
how
we
should
define
these
things
and
like
what
your
thoughts
are.
A
Yeah,
that's
fair,
but
then
how
do
we
represent
that
in
something
that's
meaningful
inside
of
kubernetes,
like
one
of
the
things
that
we've
done
from
the
appdev
working
group
and
kind
of
taken
over
inside
of
say,
gaps?
Is
this
application
CRD
and
that's
really
how
what
we're
trying
to
do
to
be
able
to
aggregate
these
resources
inside
of
kubernetes
and
display
them
conrad
over?
There
has
done
some
awesome
work
and
Tyner
in
terms
of
like
actually
doing
a
UI.
A
If
I
have
this
gray
box
application
as
far
as
a
team,
that's
managing
it,
that
might
be
an
app
right
as
far
as
the
organization
that
owns
let's
say,
multiple
teams
that
are
composed
and
sharing
those
services,
the
entire
thing
might
be
an
application
and
their
news
should
have
an
app
might
be
I
want
to
see
everything
like
all
of
those
applications
and
their
dependencies.
The
original
kept
we
had
out
for
the
applications
here.
D
had
a
new
of
dependency.
A
If
I
think
it
was
Matt
butcher,
who
kind
of
said
you
know
it
doesn't
work
across
a
namespace,
it
doesn't
really
allow
me
to
aggregate
across
clusters,
so
it's
fairly
weak
I'm,
not
sure
if
this
is
useful
in
the
general
case.
So
it's
actually
an
area
where
we're
looking
for
a
lot
of
input
and
contribution
in
terms
of
what
will
work
for
the
community.
A
A
So
on
the
application
CRD,
you
can
come
to
the
repo
you
can
join.
The
Deaf
working
group
leave
issues
directly
comment
on
issues
that
are
open.
You
can,
you
can
definitely
open
PRS.
We
will
review
them
not
this
week
because
we're
all
here,
but
at
some
point
in
the
future
you
can
come
every
Monday
morning,
9:00
a.m.
PST
and
participate
in
cig
apps,
which
now
I
understand.
Why
it's
at
that
time,
because
you
guys.
A
Yeah,
but,
but
that's
definitely
a
way
and
like
that's
kind
of
the
cool
thing
about
sig
apps,
like
we
really
do,
get
a
lot
of
different
viewpoints
from
a
lot
of
different
people
at
various
different
roles
in
their
organizations.
Everything
from
like
traditional
society,
necessary
types
to
developers
to
organizations
where
there
is
no
real,
clear
distinction
between
that
role.
Right,
like
I
Deb
I,
do
ops.
I
do
p.m.
A
A
A
Okay,
what
about
staple
everybody?
Familiar
with
stateful
stats,
demon,
stats
so
forth
so
I
mean
that,
along
with
the
the
batch
API
is
pretty
much.
What
the
whole
thing
is
and
the
only
reason
it's
aggregated
together,
I,
don't
really
know
the
history
of
why
we
aggregated
the
whole
thing
together.
I
mean
I
could
tell
you
how
it
was
invented
right.
We
had
pods
people
wanted
many
pods,
then
well
I
mean
so
like
demons
had
starters
an
extension
to
run
system,
administrative
tasks
right.
A
That
was
after
replication
controller,
which
eventually
turned
into
replica
set
when
we
took
deployment
config
and
turned
it
into
deployment
and
brought
it
into
the
extensions
group.
For
so
there's
a
history
of
evolution,
but
I,
don't
know
how
we
name
workloads,
API
other
than
just
seen,
references
and
documentation
over
the
years
like
it's,
the
workloads,
API
yeah.
A
Maintaining
it
and
you
can
help
us
prioritize
what
bugs
get
fixed.
You
can
help
us
prioritize
what
features
get
added
and
we're
very,
very
focused
on
adding
customer
value
like
we're
not
sitting
here,
just
trying
to
do
a
cool
stuff,
because
it's
hard
there's
a
lot
of
that
to
do.
But
ultimately
we
want
to
do
things
that
are
going
to
keep
production
clusters
healthy
and
let
you
guys
run
your
workloads
in
a
way
that
makes
it
easy
so
come
to
the
cig.
Apps
meeting
and
that's
an
easy
way
to
you
know,
get
involved
with
that.
A
Okay,
so
for
everybody
else,
people
were
basically
running
everything
at
a
beta
level
of
stability,
which
we
tried
really
hard
not
to
break,
but
we
did
break
from
time
to
time
for
what
maybe
three
years,
ish
something
along
those
lines
yeah.
So
we
finally
took
it
v1
and
one
of
the
things
about
that
was
we
deferred.
A
There
are
a
lot
of
things
we
want
to
do
and
a
lot
of
things
we
even
want
to
do
at
the
time,
but
we
kind
of
took
the
position
that,
like
ultimately,
what
we
owe
you
guys
more
than
anything
else
is
stability.
Like
all
the
other
stuff,
we
could
do
everything
else
we
could
add
to
this.
Api
has
to
take
a
backseat
to
you,
want
boring
infrastructure,
and
we
kind
of
got
that
message
loud
and
clear,
like
I,
just
want
it
to
work,
so
I
mean
at
three
years
after
a
lot
of
revisions.
A
A
H
B
H
H
H
A
I
mean
like,
if
you
wanted
to
do
something
like
alright,
let's
say
so:
I
get
for
a
lot
of
people,
I
mean
some
people
are
gonna.
Tell
you
the
futures
sto,
the
future
is
linker
day.
The
future
is
server
but
service
measures,
and
that
may
be
true.
They
may
be.
That's
not
true
for
everybody.
The
simplest
thing
you
can
do
is
set
up
a
mixer
in
front
of
your
servers.
A
That
does
it
for
you
right,
because
you're
you're
not
looking
for
like
mutual
lofty
LS
between
every
pod
and
zero
trust,
authentication
or
rolling
traffic
update,
like
none
of
the
core
features
for,
is
to
go
out
of
interest.
You
just
want
a
simple
traffic.
Mister
I
mean
that
that's
what
would
a
primitive
like
that
looked
like
inside
of
kubernetes
and
how
will
we
implement
it
at
the
network?
A
Layer
right
I
mean
I'm,
not
really
sure
that
there's
a
good
way
to
do
that,
based
not
only
on
the
primitives
that
we
represent
in
the
API,
but
on
the
representation
that
we
have
for
the
network,
fundamentally
as
a
physical
entity.
Without
doing
something
like
a
service
mesh
like
IP
tables,
isn't
going
to
get
you
that
if
you're
looking
for
layer,
seven
load,
balancing
and
traffic
filtering
there.
E
A
But
then
there's
another
complication
right,
so
even
if
they're
kind
of
slowing
down
like
kubernetes
is
tried
to
be
more
stable
over
the
past
couple
of
releases
and
take
less
things
in
the
core.
This,
especially
if
in
shift
already
has
already
tried
it
out.
If
there's
enough
demand
for
it,
I
mean
it's
reasonably
something
we
could
probably.
I
A
Well,
at
least
I
can
take
it
as
an
action
item
to
make
sure
that
networking
is
aware
of
it
and
here's
your
request
and
that's
another
function
that
the
gaps
will
play
like.
If
you
come
to
our
meetings
and
you
do
have
a
complaint-
that's
relevant
about
deployments,
but
really
requires
Sagat
or
sig
networking
or
in
some
cases
six
storage
to
implement.
It
will
carry
the
message
for
you,
so
I'll
take
an
action
to
table.
A
But
Auto
pausing
was
a
lot
easier
to
implement
because
staple
sets
are
ordinal
in
nature
right
and
you
can
say
also
they're,
not
probabilistic,
whereas
you
know
a
replica
set
tries
to
give
you
three
ish
right.
You
might
get
four,
you
might
get
two
at
any
particular
time,
so
the
pause
would
have
to
have
different
semantics,
probably
I.
A
A
Yeah
for
sure
it's
but
I
mean
honestly
for
people
who
do
come
as
a
gap.
So
a
lot
of
times
we
do
get
kind
of
so
I
mean
the
application
tiers
really,
depending
upon
what
Brian
and
Tim
tend
to
call
the
nucleus,
which
is
pod,
the
storage
api's,
but
networking
api's.
So
you
know
we
kind
of
take
your
requirements,
drive
them
into
the
workloads,
API
interface
and
sometimes
that
drives
requirements
all
the
way
down
into
the
nucleus,
and
we
may
not
always
implement
them
ourselves,
but
we
chase
down
the
right
people
to
go,
implement
them.
A
C
J
I
A
So
another
thing
we
are
looking
at
to
prevent
this
is
at
the
API
server
level
trying
to
do
per
object,
quotas,
yeah,
so
job
is
kind
of
funny.
In
that
the
way
the
way
most
people
think
about
job
is
that
the
job
should
run
to
completion,
and
let's
say
that
you
wanted
to
save
something
off
prior
to
completing
successfully.
It
should
probably
save
that
off
somewhere
off
cluster.
That's
not
the
way
it's
implemented,
and
that's
not
currently.
The
way
it's
documented.
A
Currently,
it
says,
go
ahead,
run
will
save
the
pods
off
for
you
and
then
you
can
go
into
them
later
and
get
your.
So
that's
a
thing
and
that
that
kind
of
causes
issues
for
clusters
get
overwhelmed.
So
looking
at
that,
we're
probably
gonna
fix
it
because
it
is
v1.
We
can't
really
break
it
completely
by
putting
quotas
on
there
to
keep
the
control
plane
safe,
no
matter
how
crazy
it
gets.
E
A
I
A
I
K
A
A
I
A
So
I
mean
that's
actually
one
of
the
intentions
of
stateful
set,
though
right.
It
doesn't
just
because
it
provides
storage.
Primitives
doesn't
mean
you
actually
have
to
write
data
to
it.
If
you
require
a
unique
identity,
particularly
a
unique
network
identity,
that's
not
stupid!
That's
what
it's
designed
for.
So
there
I
mean
there.
Definitely
you're,
not
I,
know
you
feel
alone.
I
know
you're,
like
I,
could
have
done
this
with
the
deployment
I'm.
The
person
doing
this
you're,
not
other
people,
do
the
same
thing:
yeah,
yeah
yeah,
and
it's
actually
an
intended
use
case.
A
C
K
A
I
would
say:
elasticsearch
is
one
of
the
most
popular
applications.
People
talk
about
running
kubernetes
on
there's
some
issues
with
staple
set
and
elastic
search.
Just
because,
like
you
have
to
jump
through
a
lot
of
Hoops
in
order
to
tell
it
to
stop
the
rolling
update
and
not
leave
the
cluster
under
replicated
when
it
reports
ready
right,
there's
an
elastic
search,
char,
it
says:
hey
I'm,
ready
to
serve
traffic
I'm
good
I'm
good,
but
there's
an
entirely
separate
check
for
if
knocking
that
shard
over
would
leave
the
elastic
search.
A
A
We
were
talking
about
this
yesterday
about
doing
something
specific,
to
make
it
a
little
bit
easier
to
run
elastic,
search,
natively
on
a
staple
set
and
to
be
able
to
block
the
rolling
update
when
it
is
under
replicated
their
entire
categories
of
distributed
system.
That
would
benefit
from
that
type
of
a
feature.
A
So
we're
thinking
about
that,
and
maybe
one
thing
we
could
do
in
say,
gaps
is
bring
in
a
lot
of
it's
like
I,
have
a
lot
of
discussions
these
days
with
people
who
want
to
run
elastic,
search,
we're
running
elastic,
search
on
kubernetes
or
who
are
elastic
the
company,
so
maybe
brave
yeah,
so
maybe
bringing
everybody
into
a
roman
sig
apps
to
talk
about
these
things
and
kind
of
decide
what
the
correct
correct
direction
for
the
community
is
would
be
a
great
thing.
There
are
at
least
two
elastic
search
operators
out
there.
A
One
of
them
is
of
a
pretty
good
quality,
so
I
mean
maybe
coming
together
as
a
community
and
putting
all
efforts
into
that
would
be
the
right
thing
to
do
or
if
elastic
was
willing
to,
you
know,
get
involved
in
it,
maybe
having
them
host,
something
that
we
all
contribute
it.
That
would
be
good
too,
but
yeah.
You
were
you're
not
alone
in
saying
I.
A
Okay,
so
for
one
of
the
things
we
decided
not
to
do
in
the
core
API
prior
to
GA,
that
if
your
OpenShift
user,
you
might
be
familiar
with
their
deployment
hooks
and
even
anybody
heard
of
these
things,
yeah
well
yeah
I
mean
you
wrote
them
right.
So
so
the
premise
is:
let's
say
you
are
running
a
database
and,
let's
say
prior
to
a
rolling
update
on
your
web
application.
You
want
to
put
a
hook
in
to
do
a
schema
migration
on
the
database
right
or
maybe
after.
A
A
A
A
A
G
F
G
We
support
we
have
deployment
configs,
which
is
it's
what
predates
deployments
in
kubernetes
and
we
support
different
kinds
of
hooks.
We
support
pre
cooks,
so
before
deployment
starts
are
allowed.
You
can
do
whatever
you
like,
like
database,
migration
or
different
use
cases.
Actually,
you
can
bring
down
different
different
service,
different
deployment,
because
your
your
deployment
depends
on
that.
So
you
want
to
do
an
upgrade
and
you
have
to
like
switch
stuff.
I
would
serve
whatever,
with
a
support,
also
post
hooks
for
sending
emails
or
whatever
you
like,
clean
up
stuff
bring
up
back
in
service.
G
That
depends
on
your
service
that
you
upgraded
and
also
we
support
meat
hooks
for
for
recreate
deployments,
which
is
also
a
place
where
you
want
to
actually
that's
the
place
where
you
want
to
do
it.
Database
migration,
because
you
bring
down
your
database
and
then
you
do
the
schema
migration
and
you
bring
it
up
back
up
the
new
version
and
we
want
to
because
our
customers
depend
on
that
stuff,
and
we
want
to
have
this
feature
in
kubernetes
with
deployments
and
potentially
also
stateful
sets
and
demos
can
take
advantage
of
those
features.
C
The
difference
would
be
like
we
want
to
have
it
in
general,
so
you
could
actually
run
it
at
any
percentage.
So
if
your
deployment,
which
like
0
20
or
whatever
you
choose,
it
will
run
a
hook
for
you
so
the
way
it
will
be
important
it
it's
like
it
will
actually
use
who
jobs.
So
it
will
create
a
job
and
you
can
configure
anything
there
like
it's
your
customization
point.
It
will
around
the
job
for
you,
so
we
can
choose
what
you
want
to
do
there,
like,
especially
this
case
I.
C
Guess
if
you
want
to
the
canneries,
you
could
actually
use
that
hook
to
create
a
separate
service
matching
the
labels
for
the
new
pots
from
the
new
replica
set.
So
you
would
have
kind
of
split
it
for
the
deployment
into
two
from
the
old
replica
funding
from
the
Oh
replica
set
and
affirm
the
new
one.
So
you
could
actually
switch
traffic
if
you
would
have
ingress
with
lights.
I.
K
C
That's
how
we
do
it
in
open
shift,
or
at
least
our
customers,
because
I
actually
see
this
as
a
strong
customization
point
like
it
yeah
there's
the
most
important
thing
like
you
guys
can
actually
choose
what
it
should
do,
we'll
just
around
the
job.
For
you
at
a
specific
point,
you
tell
us
and
we
run
it.
It's.
G
C
K
C
J
G
A
That's
the
thing:
if,
for
anybody,
who's,
not
a
contributor
to
kubernetes
everything
in
the
ecosystem
works
through
opening
an
issue,
and
eventually,
oh
so,
okay,
let's
go
to
the
new
process.
The
new
process
is
a
cap
so,
rather
than
opening
a
proposal
inside
of
community
which
you
open
is
a
cap
which
is
a
little
bit
more
convoluted,
but
basically
it's
a
proposal
that
has
to
go
through
a
process
of
receiving
feedback
from
everybody
in
the
community
and
further
existing
features
that
have
open
caps
and
open
proposals.
A
Anyone
in
this
room
or
anyone
else
for
that
matter
is
open
to
come
in
and
leave
feedback
so
before
we
start
implementing
coda
before
we
start
moving
things
in,
we
want
to
get
general
consensus,
not
just
from
open
shifters
or
Googlers
or
Amazonians,
or
anybody
else
like
for
any
one
product
that
it
works.
We
want
your
consensus
that
it's
something
that
you
want
to
see
inside
of
core
kubernetes
and
that's
the
only
way
it
gets
in
so.
A
A
We
get
a
lot
of
people
who
are
administrators,
contributing
to
ideas
that
are
being
you
know,
brewed
up
by
developers
that
kind
of
have
a
little
bit
more
reality
to
them
like
what
hey,
that's,
not
really
safe
for
somebody.
Who's
got
to
deal
with
it
at
two
o'clock
in
the
morning.
Just
so
you're
aware
we
probably
shouldn't
do
that
so
I
guess
moving
on
to
hell.
How
many
guys
are
go
sure
sure.
A
A
Well,
we
actually
hold
on
so
we're
actually
yeah
the
community,
so
one
your
airflow
is
$10
tends
to
be
a
work
flow
scheduler,
which
is
something
that's
a
way
you
could
set
up
a
ETL
pipeline
right.
There
is
work
in
the
airflow
community
and
in
conjunction
with
the
kubernetes
community,
to
provide
first
class
support
for
air
flow
in
kubernetes.
I
We
ever
we
even
got
to
the
point
that
we
had
the
proposal
accepted,
merged
and
aria
started
actually
working
on
the
mother
plantation,
but
then
I
was
talking,
and
that
was
like
two
years
ago,
because
I
was
talking
with
Google
folks
in
back
in
and
back
in
London
yeah,
and
they
told
me
that
they
have
something
internally,
that
that
just
does
not
work
and
everyone
are
using
external
stuff.
And
then
we
had
a
lengthy
discussion
with
Brian
and
Eric
again
about
the
topic,
and
we
agreed
back
at
the
time
that
it
will
be
reverted.
I
The
proposal
was
removed
entirely
and
that
whatever
will
happen
around
the
work
flow
should
happen
outside
of
the
core,
and
that
was
the
beginning
of
ensuring
that
we
are
not
putting
into
the
cube
core
stuff.
That
is
more
higher
level
that
can
be
built
on
top
of
the
primitives
that
the
kubernetes
already
provides
so
yeah
that
that
was
one
of
the
reasons,
and
that's
that's
probably
why
I
closed
your
proposal
issue
order?
Okay,
yeah!
It's
yes,.
G
I
A
I
A
A
About
the
word,
sir,
but
again
we
could
get
a
lot
of
people
to
talk
about
various,
so
I
mean
like
one
of
the
guys
on
my
team
is
actually
contributing
to
the
airflow
and
kubernetes
thing.
So
there's
a
lot
of
interest
in
making
that
a
better
experience,
if
it's
a
bad
experience
for
you
right
now
and
then
there's
so
many
other
ones
that
it's
like
it.
At
this
point,
we've
evolved
the
community
like
an
entire
ecosystem
of
kubernetes
workflow
schedulers.
A
Even
if
you
think
about
like
meta
particle
is
in
some
ways
kind
of
like
a
code
native
workflow
scheduler
right
like
there.
There
are
a
lot
of
things
that
fit
that
domain.
There's
no
way
at
this
point,
because
we
have
an
ecosystem
of
them
that
we
could
pick
one
and
just
bring
it
into
core.
That
would
be
yeah.
That's
that's
that.
K
C
A
A
Okay,
no,
okay,
no
okay,
so
I
think
one
of
the
other
co-chairs
Matt
was
responsible
primarily
for
the
latest
2.9
release,
which
was
basically
stability,
release,
form
or
anything
else.
I
mean
2.9
is
going
in
to
break
fix,
BAU
mode.
At
this
point,
home
3
is
probably
what
everyone
is
interested
in
and
it's
in
active
development.
All
of
the
stuff
you
see
listed
here
is
really
mostly
ideation
at
this
point,
but
this
is
a
good
capture
of
the
direction
that
helm
oh.just
secure.
A
A
So,
from
my
perspective,
all
I
can
say:
is
this
like?
If
you
look
in
the
home
repository,
there
are
a
lot
of
charts
that
are
well-thought-out
in
terms
of
how
do
I
deploy
the
application,
but
this
the
lifecycle
management
that
they
to
operations
really
isn't
baked
into
helm
and
I.
Don't
know
if
that's
really
the
right
place
for
it.
So
that's
one
issue,
I've
seen
people
have
the
other.
A
Is
you
gotta
find
some
way
to
inject
some
way
to
extract
metrics
and
telemetry
from
anything
that
you're
turning
up
in
helm,
if
you're
actually
going
to
run
it
in
production
which
isn't
something
that
I've
seen
templating
in
most
of
the
charts
there
I
mean
most
of
the
questions.
I
see
when
I
open
up
is
like
how
do
I
know.
A
K
A
People
do
tend
to
fork
them
right
now
in
order
to
run
them
from
what
I've
seen
but
people
some
people
do
just
run
them,
as
is
again,
then
they
may
be
using
other
methods
in
order
to
modify
the
pod
to
do
things
like
it's
a
lemon
tree
at
log,
shippers
I'm,
not
sure
so.
But
what
was
your
specific
question
in
terms
of
what
add
weapon
addressed.
A
Well
I
mean,
like
generally
I,
think
what
a
lot
of
people
are
doing
is
turning
up
an
internal
part
repository,
and
there
are
definitely
ways
that
you
can
point
your
helm
point
tiller
and
in
helm
3.
There
will
be
no
tiller
to
multiple
repositories
for
resolution,
so
I
think
people
are
generally
turning
up
their
own
repos
internally
and
especially
like
when
we
talked
about
bespoke
applications
earlier,
a
lot
of
people
have
their
own
helmet
arch
that
they
develop
internally
and
that's
primarily
what
they're,
using
so
I,
think
internal
helm.
A
Repos
are
kind
of
the
suggested
mechanism
to
solve
that
problem
in
terms
of
making
it
less
painful.
I
think
chart
museum
is
probably
the
current
state
of
the
art
for
making
home
less
painful
I'm,
not
a
user
of
it.
I
know
the
authors
of
it.
They
seem
to
be
for
their
organization.
They
claim
it
solved
that
problem
and
added
a
lot
of
value.
I
would
point
you
at
that.
Not
officially
endorsing
it,
of
course,
but
just
saying
that,
like
it's
a
method
that
other
people
have
been
successful
with.
A
A
A
So
in
okay,
alright
I'm
going
to
I'm
going
to
channel
my
home
developer
right
now,
so
in
theory
the
the
templating
system,
that's
currently
inside
of
helm,
is
loosely
coupled.
You
could
replace
it
with
another
templating
system
if
you
wanted
to-
and
this
is
in
helm,
two
like
there
is
an
entire
mechanism
inside
of
helm
that
actually
allows
you
to
replace
the
existing
templating
system
with
another
one.
A
Well,
I
know
I'm
not
talking
about
an
existing
plugin
and
you
do
have
to
go
I'm
talking.
You'd
have
to
put
some
sweet
hours
into
it
and
actually
develop
your
own
integration
for
your
templating
system
and
plug
it
into
hell.
But
the
helm
developers
put
that
that
that
hook
in
there
on
purpose,
to
allow
for
people
to
develop
their
own
templating
system,
I
think
in
helm,
3
one
of
the
goals
is
to
make
it
easier
to
do
that.
A
A
D
K
A
So
I
mean
for
helm
three
again
they're
trying
to
make
it
easier
to
integrate
if
you're
looking
for
helm
case
on
it
in
specific
I
would
try
to
get
one
of
the
mats
and
Bryan
Liles
in
the
room
and
see
if
they're
willing
to
support
or
what
the
direction
would
be
going
forward.
It's
definitely
so
different.
Templating
systems
in
elm
is
definitely
a
goal
like
the
ability
to
support
them.
A
A
That
well
I
mean
interfacing
kubernetes,
with
secret
stores
in
a
reasonably
is
something
that's
kind
of
a
work
in
progress
too
right,
so
kubernetes,
vault
integration,
it's
a
bang
and
then
interfacing
with
the
various
hardware.
Key
management
systems
that
exists
on
the
various
cloud
providers
is
probably
going
to
leverage
that
same
infrastructure
right.
A
So
the
idea
we
want
better
secrets,
management
interfaces
and
potentially
even
configuration
store
interfaces
are
things
that
the
community
is
actively
looking
into
right
now,
because
we
have
these
primitives
on
the
cloud
and
stuffing
config
maps
in
the
SCT
is
kind
of
like
relative
to
what
we
could
be
doing
a
little
week,
right
so
same
with
stuffing
secrets
into
the
API
server
when
we
could
be
consuming
them
from
something.
That's
a
bit
more
purpose-built
for
that.
A
A
A
Yeah,
but
they
need
the
room.
This
is
like
the
last
glass
bra,
so
I
mean
like
honestly.
What
I
would
say
is
this
definitively
or
you
continue?
Can
we
can
continue
having
conversations
outside
of
the
room
in
in
five
minutes
and
just
like
door
own
thing,
nothing,
nobody
is
going
to
kick
us
out
of
the
bill
and
well
I
hope.
A
H
A
There's
that,
but
the
the
I
think
the
real
answer
for
that
is
server
side
apply,
but
that's
gonna.
Take
oh
yeah,
so
I
mean
it's
a
work
in
progress
right
now.
Maybe
we
get
an
alpha
in
111,
if
not
alpha,
like
112
I
guess
so,
you're
looking
for
at
least
three
releases
before
it
comes
out
and
the
beta
use
a
usable
way
enabled
by
default,
you
could
talk
to
the
API
machinery.
Guys.
Daniel
Smith
in
particular,
is
a
good
person
to
reach
out
to
who's
at
the
conference.
A
Now
he's
kind
of
been
spearheading
the
effort
to
it.
The
answer
is
basically
this
you
do
could
be
cuddle
apply,
that's
client-side
code
that
helm
is
basically
vendored
and
everyone
else
is
bended
or
implemented
themself
in
some
kind
of
way,
that's
sort
of
like
the
way
Kuby
cuddle
does
it.
So
what
we're
trying
to
move
is
all
that
logic
to
the
server.
So
in
theory
all
that
DIF,
like
and
all
of
that
everything
you're
doing
when
you're
doing
a
strategic,
merge,
patch
or
a
three-way
merge
patch
should
live
server-side
in
the
near
future.
K
A
And
it
should
just
work
now
if
you're
asking
can
I
help,
you
fix
the
problem
you
have
today
with
what
is
in
production
right
now,
no,
like
I,
don't
think
I
think
it's
a
problem.
That's
pretty
common!
That
we've
heard
complaints
about
it,
but
it's
not
unique
to
hell.
I
mean
I
guess.
The
best
thing
you
can
do
is
try
to
diff
what
you've
got
currently
with
what
you
have
client-side
to
determine.
A
If
it's
been
modified
before
applying
your
update
and
that's
a
way
you
can
go,
but
it's
also
fairly
hard
to
automate
right
like
where
do
you
look
like
I
mean?
Basically
you
could
say
well
if
the
diff
is
empty,
then
we
have
a
proper,
but
if
is
not
empty,
then
we
have
a
problem.
But
what
do
you
do
with
that?
Does
that
generate
Paige
like
how
do
you?
Where
do
you
go
from
there
and
then?
How
do
you
roll
it
back?
If
you
don't
have
like?
A
Do
you
just
try
to
merge
patch
out
the
diff,
because
that
definitively
won't
work
in
all
cases
depending
on
what's
been
altered,
so
without
the
server-side
functionality?
I'm
not
sure,
if
there's
a
really
good
way
to
move
forward
other
than
just
like.
Unfortunately,
look
it
and
see
what's
change
and
then
make
a
human
decision
about
like
what
do
I
do
to
move
forward
like
how
do
I
back
this
guy
stuff
out
so
I
can
roll
forward
with
the
building
upgrade
I
actually
want.
You.
A
I
mean
I
mean
like
yes,
so
that's
the
thing
like
I
said
use
our
back,
but
that's
actually
kind
of
a
flippant
answer,
because
I
can
say
that
and
that
works
where
I
live
but
like
where
he
lives.
Maybe
these
people
do
Neelix
I
mean
you
can't
are
back
out
people
who
break
glass
in
the
events
yeah,
but
you
can
yell
at
them.
That's.
A
Two
of
them
I
believe
they're,
releasing
the
state
resources
or
the
ones
that
are
thinking
of
using
now
and
then
potentially
the
apps,
your
D
as
well.
But
the
release
and
state
resources
are
the
only
things
that
they're
going
to
use
and
I
believe
they're
going
to
be
CR
DS
at
this
point
and
remember
any
of
everything
up
here,
which
will
also
reintroduce
at
the
intro.
A
It's
still
somewhat
speculative,
like
your
best
bet,
and
if
the
intro
will
give
these
slides
out
which
have
the
links
to
the
current
ongoing
work
on
home
3,
you
can
go
and
check
out,
what's
actually
in
flight
there
and
the
status
of
all
the
proposals
and
the
open
issues
and
much
like
the
rest
of
kubernetes.
You
are
always
welcome
to
leave
comments
and
say
no
stop
that
it's
broken.
That's
not
going
to
work
for
me.
Have
you
thought
about
this
and
the
helm
guys
like
most
of
the
kubernetes
core
contributors
are
always
willing
to
listen.
A
Now
I
can't
actually
I,
don't
know,
I
can't
actually
answer
that
I
mean
like
so
we
have.
We
have
people
on
art,
so
there
are
people
on
my
team
specific
who
are
helming,
chart,
maintainer,
x'
and
so
I
mean
Google
is
to
some
extent
but
I
mean.
But
what
contributes
has
have
been
a
lot
of
like
developing
the
test,
automation
infrastructure,
turning
that
up
inside
of
prowl
making
sure
we
actually
have
tests
for
all
the
charts.
A
It's
really
been
something
that's
been
more
of
a
contribution:
istic
apps
like
building
those
tests
and
owning
them,
and
using
them
to
ensure
that
we
haven't
modified
the
workloads
API
in
such
a
way
that
it
breaks
Helmand
all
the
charts
prior
to
release
I,
don't
think
we
actually
count
them
as
release
blocking,
but
we've
been
really
good
at
keeping
our
test
screen.
So
he's
done
that
I.
A
Mean
like,
like
I
use
it
from
time
to
time,
but
it's
not
like
mainly
work
in
the
cluster,
not
not
on
it.
So
much
when
we
dog
food,
we
tend
not
to
use
helm
as
the
dog
food,
but
I
mean
it
is
obviously
a
popular
way
for
so
there
there
are
people
who
run
on
Google
who
do
use
helm
right,
and
you
know
we
won.
A
We
saw
sig
apps
had
I
went
home
to
work
well
for
anybody
in
any
cloud
on
top
of
kubernetes
Google
had
on
I
want
it
especially
to
work
well
on
gke
for
for
people
who
are
running
on,
you
know,
running
their
workloads
in
my
house
and
again
helm
had
on
like
the
entire
thing
was.
You
know
it
was
thing.
It
was
something
that
people
came
together
and
like.
How
can
we
add
value
to
this
community?
How
can
I
manage
package
is
better,
so
I
think
everybody
who's.
A
A
participant
in
the
community
is
really
just
looking
to
make
your
lives
easier,
and
you
know
there's
a
lot
of
opinions
on
the
right
way
to
do
packaging.
There
are
hooks
in
helm,
2
and
they're,
trying
to
put
hooks
now
home
3
to
make
it
easier
to
be
more
opinionated
personally
and
to
turn
up
infrastructure.
That's
a
modification
that
leverages
the
existing
helm
infrastructure
in
order
to
add
value
to
your
cluster.
So
there's
that
alright,
so
I
got
the
official
wrap
it
up
box.