►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Apps SIG - Matt Farina, Samsung SDS & Adnan Abdulhussein, Bitnami
Kubernetes SIG Apps covers developing, deploying, and operating applications on Kubernetes with a focus on the application developer and application operator experience. In this deep dive we will look at the general experience for application developers and operators along with specifics of the Workloads API and Application CRD. The topics discussed will be based on the desires of those in attendance and the conversation will go where attendees would like it to go.
To learn more: https://sched.co/Grf2
A
The
first
thing
I'll
say,
is
hi,
I
am
Matt,
I
am
one
of
the
co-chairs
of
sig
apps
with
me
is
Adnan
he's
one
of
the
other
co-chairs.
I
ken
couldn't
be
here
this
week,
but
he
is
the
third
co-chair
he's
out
of
google,
and
so
we
are
the
co-chairs.
So
if
you
have
questions
after
this
feel
free
to
track
us
down
we're
happy
to
point
you
in
the
right
place
and
in
the
right
direction
with
any
of
this
stuff,
but
we
kind
of
have
been
overseeing
sig
apps.
A
So
this
is
what
sig
Apps
does
and
what
it's
responsible
for
scopes
and
things
have
changed.
See.
Gaps
has
been
around
for
a
few
years,
helm
used
to
be
part
of
it,
but
it
became
so
big.
It's
spread
off
into
its
own
CN
CF
project,
and
these
days
this
is
what
we
have,
and
so
things
like
the
workloads
API,
and
it
actually
goes
a
little
bit
beyond
that.
But
the
workloads
API
is
one
of
the
things
that
we're
responsible
for
and
we'll
call
it
tools
and
documentation
to
aid
the
ecosystem.
A
You
know
around
interoperability,
so
we're
not
trying
to
do
the
ecosystem
or
have
all
the
ecosystem
projects
be
in
cig
apps,
but
there's
lots
of
places
where
well.
Two
tools
want
to
work
in
the
same
space
and
they
want
to
be
interoperable
with
each
other.
Maybe
you
wanted
to
employ
something
with
one
tool
and
then
have
the
structure
of
that
visualized
in
another
tool
and
they're
entirely
unrelated
projects.
That's
one
thing
that
falls
into
the
scope
of
sig
apps.
A
How
do
we
do
that
and
how
do
we
get
different
organizations
to
negotiate
to
come
up
with
that
same
thing
around
interoperability?
The
third
thing
is
Grandfather
projects
and
right
now
we
have
compose
it's
like
docker
compose,
but
it's
for
kubernetes,
and
so
that's
another
project
that
technically
falls
under
this.
Although
add
none
and
I
haven't
had
much
to
do
with
it
in
quite
a
long
time.
We
discov
you,
know
solving
app
development
and
deployment
problems,
and
what
do
you
do
around
that?
How
do
you
go
about
problem-solving?
A
How
do
you
go
about
doing
these
things
and
then
how
do
we
share
some
of
that
knowledge
and
then
in
the
rest
of
the
community,
whether
we're
at
sig
architecture
or
someplace
else?
We
represent
app
developers
and
app
operators
because
the
persona,
the
role
it's
really
different
from
that
of
well
a
cluster
operator
or
an
infrastructure
developer.
A
We
do
things
very
very
differently
if
you're
doing
app
development
and
operation,
and
if
you
saw
the
striped
keynote
the
other
night,
they
talked
about
not
exposing
kubernetes
to
their
app
developers
to
their
app
operators
and
one
of
the
examples
they
gave
us
for
Kron
they,
this
short
llamo
file,
that's
all
they
had
to
do.
They
didn't
have
to
do
cron
jobs
or
any
of
these
other
things.
A
It
was
very
shortened
to
the
point
and
they
had
a
small
Python
subset
language
that
they
could
declare
what
an
application
needed
to
do,
and
then
they
transform
that
into
everything
that
they
needed.
It's
similar
to
sigh
cube
and
qej,
and
some
other
projects
that
I've
been
around
kubernetes
for
a
while,
and
you
know
they
looked
at.
What
does
that
experience
look
like
because
they
wanted
to
minimize
the
kubernetes
knowledge?
A
And
you
know,
if
you're
an
infrastructure
operator,
if
you're
an
infrastructure
developer,
you
actually
have
to
maximize
that
knowledge,
and
so
it's
a
different
persona
to
bring
to
the
table.
So
when
we
go
to
other
meetings,
whether
you're,
just
a
co-chair
or
whether
you
just
anybody
who's
around,
say,
gaps
we
try
to
represent
who
those
people
are
and
how
they're
different
and
how
their
experience
needs
are
different.
A
And
so
what
is
the
deep
dive?
Some
people
just
give
talks
in
their
deep
dives,
but
this
was
the
recommendation
given
to
anybody
doing
deep
dives
on
how
to
do
it.
It's
an
opportunity
for
us
to
to
discuss
things
to
problem-solve,
to
to
come
together
to
figure
something
out,
not
just
a
process.
Discussion
but
I
have
a
technical
debate
get
into
some
details.
Figure
out.
Some
needs
not
just
stand
up
here
where
we
give
another
talk
on
something.
A
So
it's
an
opportunity
for
you
to
engage,
and
so
with
that
I
wanted
to
put
up
what
sig
Apps
is
working
on
right
now
we
obviously
have
the
workloads
API
things
like
stateful
set
daemon
set
deployments
and
things
around
that
there's
even
some
other
things
that
we'll
get
into
around
secrets
and
some
of
the
things
that
surround
that
has
to
do
with
applications.
There's
the
application,
CRD
and
controller,
which
is
a
project
we're
working
on
in
the
kubernetes
SIG's
github
org.
We
have
something
new
called
portable
service
definitions.
A
A
Maybe
take
that
same
group
of
things
and
deploy
it
into
mini
cube
and
in
all
places
you
want
to
interact
with
a
a
sass
I'll
call
it
you,
if
you're
an
Amazon,
it
would
be
RDS
you'll
want
it
to
interact
with
and
locally
you'll
just
want
to
spin
up,
maybe
a
my
sequel
cluster
right,
but
you
don't
want
to
keep
changing
and
deal
with
that
orchestration.
You
want
it
to
be
declarative.
A
We
started
with
a
kubernetes
enhancement
proposal
which
was
merged
as
provisional,
and
now
we've
got
to
go
figure
out
the
architecture
and
how
we're
going
to
build
this,
but
that's
one
of
the
things
we're
on
we're
also
talking
about
how
do
we
enable
the
ecosystem,
and
then
we
did
an
application
survey
in
2018
and
there
are
folks
who
are
asking
and
want
to
talk
about.
Are
we
gonna
do
this
again
or
should
somebody
else
do
it?
A
So
we
do
have
that
as
well,
and
so
with
that,
my
question
is
I've
got
things
that
I
can
talk
about
with
you
all
in
questions
we
can
get
going.
But
what
do
you
want
to
talk
about?
What
kinds
of
things
does
anybody
in
the
room
have
something
they
would
like
to
talk
about?
Okay,
I
will
start
here,
yeah
I.
B
B
The
config
map
doesn't
follow
the
lifecycle
of
the
replica
set
so
I'd
like
some
way
to
when
I
update
the
deployment
it
snapshots
the
config
Maps
in
time,
along
with
the
replica
set
and
make
sure
that
the
replica
set
members
all
have
the
same
config,
and
when
you
roll
forward
and
roll
back.
It's
always
consistent.
A
C
A
C
So
since
you
do
capture
batch
jobs,
one
of
the
problems
that
we're
having
is
when
we
try
to
declare
a
job.
It
immediately
runs,
but
sometimes
that's
not
always
what
you
want
signs.
You
want
it
to
run
at
a
later
date,
or
it's
like
when
you
decide
to
trigger
it
so
being
able
to
define
a
job
without
actually
running
it
and
then
later
on
being
able
to
run
it
when
you
decide
that
that
trigger
should
be
going
is
something
that
we
kind
of
need
to
figure
out.
D
E
I'd
be
really
curious
about
what
ideas
people
have
for
evolving.
The
future
of
the
deployment
object,
I
think
we're
seeing
at
koukin
this
year
that
a
lot
of
people
are
writing.
Custom
deployment
takes
on
deployments
to
do
like
canary
or
Bluegreen,
and
the
current
API
doesn't
really
what
you
do
that
without
some
very
delicate
pause,
dancing,
Oh.
F
G
Thanks
I
was
just
wondering
if
there's
any
interest
or
attention
on
hot
patch
of
certain
aspects
of
pods
and
deployments,
particularly
things
like
config
I,
also
share
interest
in
the
separate
config
lifecycle
from
outside
app
lifecycle,
discussion
and
one
way
to
view
that
is.
Can
a
config
map
simply
get
hot
patched
in
potentially
without
restarting
the
pots,
it's
very
expensive
to
restart
pods.
In
some
cases,.
A
H
I'd
like
to
say,
as
close
as
possible
parity
between
a
stateful
setting
and
deployment,
there
are
some
things
that
could
quite
easily
be
equivalents.
For
example,
things
like
falling
claim
templates
could
exist
in
a
deployment
that
don't,
and
the
idea
is
that,
hopefully,
that
you'll
be
able
to
switch
to
one
on
the
other,
with
other
small
variations.
I
A
A
Right
are
there
any
others
and
we
start
rolling
through
these?
Alright
fantastic.
The
first
one
was
config
map
life
cycles.
Alright,
so
this
one
talked
about
deployments
and
two
replicas
sets
and
the
config
map
life
cycle
and
not
I,
don't
know
if
you
have
anything
to
add
on
this,
but
the
the
the
thing
that
I
know
is:
there's
a
cap,
a
kubernetes
enhancement
proposal
by
Janet
who
works
at
Google
around
so
config
maps
and
secrets,
which
are
are
special
in
kubernetes,
because
you
can
mount
them
and
do
things
with
them.
A
A
So
if
you
do
something
like
in
helm
and
you
do,
an
update,
helm
would
create
a
new
config
map
with
a
slightly
different
name,
and
you
would
have
the
two
of
them
there
and
the
old
one
would
ease
the
old
config
map
and
the
new
release
would
use
the
new
config
map
and
wants
everything
that
used
the
old
release.
One
away
the
other
config
Mac
could
be
taken
down
too.
A
Our
secret
doesn't
have
that.
So
how
do
you
specify
that
and
Janet's
working
on
an
enhancement
proposal
to
try
to
solve
that
and
she's
been
working
through
the
edge
cases
and
the
architecture,
and
things
like
that
with
other
people
who
deal
with
the
architecture?
And
so
there
are
ideas
on
how
to
solve
it.
I
would
hope
it's
there
later
in
2019,
but
I
don't
think
it's
going
to
move
very
fast,
I
think.
A
Know
there
hasn't
and
that's
because
Jana
was
the
driver
and
if
you
don't
know,
Janet
is
one
of
the
co-chairs
for
the
China
conference
and
for
this
conference
and
for
the
next
year,
a
paean
conference
and
since
she's
the
driver
who's
been
talking
to
everybody
and
has
that
domain
knowledge
and
she's
been
so
busy.
I
would
hope
that
maybe,
in
the
start
of
the
era,
get
some
movement,
it'll
probably
die
now
and
again,
Europe
and
hopefully,
when
she's
freed
from
her
things,
she
can
get
back
involved
with
it.
A
A
lot
of
that
a
I
reach
out
to
me
or
Edna
afterwards,
and
we
can
get
you
connected
with
the
context.
What
this
takes
is
people
with
knowledge
of
that
problem,
domain
and
P,
or
people
willing
to
go,
learn
the
knowledge
of
the
problem
domain,
because
it's
garbage
collection
around
kubernetes
and
that
does
take
a
little
bit
for
folks
to
learn.
But
anybody
who
wants
to
we
can
help
you
learn
and
get
involved,
but
it
takes
contributors
and.
A
Okay,
so
you've
solved
it
by
basically
using
helm
and
wrapping
that
in
a
CR
D
and
a
controller
and
the
CR
DS
the
parent
object,
and
then
you
get
the
cleanup
of
it
from
the
owner
references.
Okay,
that's
gonna!
Oh
you've
got
to
comment
on
this
I'm
coming
this
the
by
the
way.
This
is
for
the
recording,
the
reason,
I
repeat
things
back
and
for
the
mic
more
than
y'all
hearing
each
other.
K
We
don't
use
helm
so
I,
don't
know
if
this
like
applies
necessarily,
but
we
solve
this
problem
by
I
mean
solve
like
worked
around
it
by
basically,
when
we're
generating
our
objects,
we
have
a
funk
like
a
utility
function
that
will
basically
like
hash
the
name
of
the
config
map
based
on
the
contents.
We've
also
done
this
for
some
other,
like
CR
DS,
that
we've
defined
that
are
also
tied
to
the
pod
lifecycle.
We
haven't
really
figured
out
the
garbage
collection
thing.
K
I
think
we've
built
some
janky
cron
job
on
our
own,
but
yeah
in
another
case
where
this
has
come
up
to
I.
Think
someone
mentioned
like
the
hot
reloading
of
configs
and
we've
actually
kind
of
tried
to
avoid
that,
because
then
you
kind
of
lose
kubernetes
protections
around
like
updates
and
stuff.
It's
makes
it
too
easy
to
break
all
your
stuff
at
once.
Yeah
yeah.
C
One
of
the
things
that
I've
found
as
well
is,
if
you
try
to
delete
a
config
map
and
it's
being
used,
it
won't
get
deleted
from
the
API
until
it
stops
being
used.
So
one
of
the
ways
you
can
garbage
collect,
jeez
go
delete
all
config
Maps
and
then
the
ones
that
aren't
meant
to
be
deleted
a
whole
hopefully
not
be
deleted.
A
Yeah
yeah,
as
far
as
this
goes
of
it,
but
that
even
gets
into
the
philosophy
of
kubernetes
and
we're
we
in
say
gaps,
sometimes
struggle
with
that,
because
we
want
a
simple
experience
where
you
don't
have
to
explain
much
to
the
users
and
the
coober.
Many
of
the
kubernetes
infrastructure
folks
want
to
let
everybody
have
access
to
every
balla
and
whistle
and
knob
and
those
are
kind
of
opposed
and
that's
where
we
get
into
the
UX
conversations.
So
I
definitely
understand,
and
yes
afterwards,
please
come.
A
J
C
No,
so
suspending
the
problem
with
his
suspending
is:
if
your
schedules
too
fast
it'll,
get
to
100
miss
schedules,
then
I'll
stop
running
on
the
cron
job.
This
is
more
like
I'd
like
to
create
a
kind
of
like
job
template,
which
you
then
continually
create
new
jobs
from
they
have
the
exact
same
template.
So
it
just
means
you
want
to
keep
re,
defining
all
your
configuration
all
of
your
secrets
and
everything
that
the
job
template
requires
every
single
time.
F
C
H
A
So
I'll
put
on
the
by
cigar
connector
hat
for
a
minute
here.
Cig
architecture
is
when
it
comes
to
lots
of
feature
requests
like
this.
The
philosophy
is
not
in
core:
let's
do
it
as
an
extension.
Let's
let
the
ecosystem
figure
out
how
to
do
it
and
share
it
amongst
themselves.
So
something
like
this
we're
probably
not
likely
to
get
inside
of
the
core
of
kubernetes
in
the
near
future,
but
I
understand
the
use
case,
so
my
suggestion
would
be.
A
C
Is
is
saying
that,
like
I've
kind
of
tried
to
stay
away
from,
even
though
like
I
still
use
them
for
Prometheus
operators
and
stuff,
how
much
buy-in
is
there
for
like
CR
DS
or
than
the
cig
apps
like
it?
You
guys
is
saying:
hey,
look
any
new
extensions,
no
more
core
at
all!
Keep
making
C,
IDs
and
we'll
start
supporting
those.
So.
A
I'll
say
this:
isn't
a
cig
apps
thing:
the
overall
architecture
for
kubernetes
is
owned
by
cig
architecture,
and
the
philosophy
that
cig
architecture
has
had
for
about
a
year
is
to
move
towards
anything
new
like
this.
Do
it
in
the
ecosystem
and
deploy
it
in
and
more
and
more
so
we
want
to
do
that
with
CRTs
and
and
controllers
to
support
them.
That's
sig,
Architecture
stance.
A
So
if
we
want
to
get
something
new
like
this,
in
sig
apps
has
to
go
before
sig
architecture
and
specifically
the
API
reviewers,
and
to
get
buy-in
so
the
architecture
and
the
API
has
to
go
in
and
right
now.
The
answer
is
almost
always
no
do
it
in
the
ecosystem,
and
people
have
heard
a
lot
of
knows
when
they
go
to
sega
architecture.
To
ask
for
permission
on
this.
A
So
that's
kind
of
the
general
philosophy,
because
kubernetes
wants
to
slow
down
all
of
the
new
features
and
add
them
into
the
ecosystem
and
let
people
develop
on
top
of
kubernetes
but
make
kubernetes
more
extensible.
So
we
want
to
get
you
know.
Crd
is
get
rose
to
GA.
We
want
to
make
that
more
of
a
GA
thing
and
solve
all
of
the
hard
problems
around
them.
So
so
we
can
expand
because
kubernetes
we
don't
want
to
be
a
bottleneck
and
we
don't
want
the
community
around
just
the
core
of
it
to
be
a
bottleneck.
A
J
J
Alright
yep
yeah
so
see
you
now
is
basically
a
spec
for
packaging
dysphoria
DAPs,
it's
not
specific
to
kubernetes.
It's
actually
kind
of
I,
guess
higher
level
than
that
and
there's
a
spec
right
now,
and
if
you
get
to
seen
that
bio,
you
can
find
a
github
repository
for
that
and
then
there's
also
duffel,
which
is
an
implementation
of
the
spec.
A
Were
interested
in
what
people
thought
of
it
was
that
it
okay,
so
I
guess
I'll
have
my
quick
two
cents
on
it.
It's
a
spec
on
how
to
install
applications,
and
it's
built
around
the
idea
of
an
installer
image,
and
you
bundle
that
up
as
a
no
CI
compliant
image
that
you
can
run
and
any
container
runner
can
do
it
and
then
the
spec
there
are
there's
a
reference.
Implementation
called
duffel,
a
vs
code
extension.
A
The
idea
is
to
keep
them
separate
so
that
you
know
you've
got
a
spec
that
says:
here's
how
you
do
things
and
then
you
have
implementations
that
are
all
compatible
with
each
other
as
long
as
they
work
with
the
spec
and
so
they've
created
a
vs
code
extension
and
installer,
they
created
a
UI
installer
using
electron,
so
you
can
have
a
you
know:
build
a
UI
click
Next
and
walk
through
collect
information
and
install
it
using
electron.
So
you
can
have
a
variety
of
different
tools
as
long
as
they
implement
the
spec.
A
It's
kind
of
a
higher-level
thing,
though
it
I
don't
think
there
are
dependencies.
So
you
say
dependencies.
You
bundle
everything
in
it.
Has
two
flavors
there's
a
lightweight
where
it
can
go
out
and
fetch
things
and
then
there's
a
heavyweight
where
all
the
images
and
everything
that
you're
going
to
ship
are
bundled
into
a
one
package
and
it
can
deal
with
and
that
lets
you
do
with
things
like
air,
gapped
environments
or
edge
networks
for
IOT,
and
so
there's
things
like
that.
A
H
B
A
A
So
you
could
have
something
that
went
through
and
saying:
AWS,
orchestrated,
RDS
and
created
a
database,
and
then
you
could
pass
that
into
a
he'll
charge
and
then
deploy
the
helm
chart
into
kubernetes,
and
you
can
use
different
things
talking
to
different
api's
and
services
to
make
the
whole
package
installable.
You
didn't
just
have
to
do
it
one
way
and
it's
not
even
just
kubernetes
specific.
You
could
use
this
with
meso
s--
or
OpenStack
or
AWS
services,
or
a
combination
of
AWS
and
the
third-party
service.
J
There
are
a
couple
of
things
I
like
about
the
scene,
app
spec
and
one
of
them
is
the
way
it
handles
credentials.
So
you
can
define
your
set
of
credentials
on
your
local
machine
and
then,
when
you
go
and
do
a
scene,
I've
installed
perform
a
scene
of
operation,
it
will
actually
mount
in
those
credentials
either
by
file
environment
variables,
and
you
can
also
setup
different
runners,
so
by
default
or
just
run
a
docker
image
on
your
machine.
J
A
A
That's
a
great
question
with
this:
you
can
probably
do
a
lot
of
imperative,
stuff
and
I.
Imagine
a
lot
of
people
well,
because
if
you're
gonna
do
something
like
I
need
to
get
a
database
and
RDS
to
go
back
to
my
past
example,
you're
gonna
create
that
first
get
the
credentials
out
of
it
inject
those
using
helm
or
customized,
or
something
like
that
into
your
kubernetes
stuff.
To
do
it
that's
very
imperative-
and
there
are
times
right
now
when
you're
dealing
with
multiple
services,
that
there
isn't
another
good
option
to
do
that
easily.
A
And
you
know
with
that,
we
could
talk
about
okay.
Well,
you
can
run
a
controller
and
you
can
write
that
and
you
can
do
this
declarative
and
could
all
do
all
these
interactions
we're
starting
to
do
that
with
some
of
our
stuff.
But
it
doesn't
really
exist
today
and
that
may
be
more
complicated
for
a
lot
of
people
than
writing
a
script
in
an
image
using
some
API
tools.
I
already
know
and
that's
an
easier
experience,
maybe
for
the
developers,
then
writing
controllers
running
in
kubernetes
and
doing
so
when
we
start
to
get
new
experience.
A
A
A
Is
you
end
up
with
a
container
image
where
you
can
do
what
you
want
on
it
with
certain
formats
or
certain
rules
like
you
have
to
have
a
something
that
gets
executed
at
a
certain
location
in
it,
and
it
has
to
know
how
to
take
certain
details
in
you
know
like
how
to
respond
to
a
certain
environment
or
variables
that
will
tell
you
the
event.
Are
you
installing?
Are
you
removing?
What
else
are
you
doing?
A
So
you
have
to
do
those
kinds
of
things,
but
otherwise
it's
up
to
you,
and
so
you
could
just
use
coop,
cuddle
or
coop
control,
and
you
could
use
just
a
bunch
of
EML
files
and
deploying
to
kubernetes
and
that's
perfectly
legitimate.
You
could
use
terraform
in
there
and
that's
also
perfectly
legitimate.
You
could
have
an
entire
imperative
workflow
that
you've
written
yourself
that
takes
in
the
environment
or
variables
and
they
config
at
9:00,
talked
about,
and
you
could
act
on
it
and
do
everything
imperative.
You
could
do
that
too.
A
A
Yes,
you're
right:
there
is
not
an
engine
outside
of
the
package
that
takes
imperative
configuration
and
makes
the
state
right
it
lets
you
install
now,
if
you
wanted
to
give
it
just
generate
those
things
and
send
them
in
you
could
do
that
as
well.
It
is
not
meant
to
be
that
imperative
kind
of
configuration
because,
quite
frankly,
to
be
fault-tolerant
to
look
at
the
world
and
all
the
Sasa's
and
everything
we
have
out
there.
We
don't
have
that
ability
to
do
that
today.
A
L
L
A
With
this
community
I,
don't
think
we
will
ever
find
one
thing
to
rule
them
all.
We
do
lots
of
things
differently
and
I
expect
multiple
solutions,
and
this
by
the
way
was
not
just
meant
with
kubernetes
in
mind
right.
The
docker
folks
and
the
docker
apps
are
looking
at
how
they
do
this
for
their
stuff
entirely
separate
from
anything
kubernetes
related,
because
this
is
not
a
kubernetes
coupled
project.
A
Deployments
things
like
that
and
okay,
so
Canaries
stuff,
like
that
you're
probably
gonna,
find
everything
that
needs
to
happen
to
that
will
be
built
on
top
of
it
in
the
near
future.
At
some
point,
we'll
probably
roll
to
version
2
of
those
api's
but,
as
I
said
before,
remember
API
changes
are
very
hard
and
they've
got
to
get
authorized
through
sig
architecture,
and
so
I
would
just
say:
don't
expect
those
in
the
next
couple
of
years
but
expect
those
situations.
A
We've
had
em,
see
gaps
of
people
doing
this
with
tools
built
on
top
of
it
and
that's
where
I
expect
the
innovation
to
happen,
and
if
some
really
good
patterns
start
to
evolve
and
show
up
there,
then
we'll
look
at
going
to
version
2
of
the
workloads
controllers
and
we'll
be
able
to
bring
those
in,
but
well
I.
Don't
expect
that
to
happen
in
the
core
of
it.
But
if
people
have
tools
to
do
this,
we
would
love
to
share
anything
else.
You
think
about
that.
Yeah.
J
J
A
A
A
It
is
but
at
the
same
time,
for
somebody
coming
in
from
the
outside
and
their
user
experience,
what
tasks
are
they
trying
to
do
and
what
do
they
need
to
do
to
accomplish
that
task?
If
you
just
have
one
big
mass
thing,
sure
you've
got
all
the
knobs
and
all
the
configuration
there,
but
we're
not
thinking
about
it.
What
does
an
end-user
who's
doing
this
need
to
accomplish,
and
how
do
we
make
that
experience
from
I
have
to
learn
about
this
object?
A
I've
got
to
learn
about
the
fields
and
what's
going
on
with
it
and
accomplish
something
with
it?
That's
part
of
the
reason
it's
nice
to
have
different
kinds
that
you
can
map
it
to
the
kinds
of
tasks
in
situation.
You
have
to
do,
and
it's
that
experience
it's
not
just
configured
in
general,
it's
helping
solve
for
that
human
experience.
A
What's
going
on
with
the
application
Siri,
so
the
application,
C
or
D
was
originally
part
of
that
interoperability
task
that
I
talked
about
before.
Where
you
have
multiple
things,
maybe
you
deploy
an
application
with
a
helmet
art
or
from
the
Google
marketplace,
and
you
want
to
visualize
it
in
dashboard
and
see
everything
paired
together.
How
do
you
describe
that?
How
do
you
list
that
in
a
directory
like
the
metadata,
that's
in
a
helmet
art
yamo?
A
How
do
you
deal
with
these
things
and
associate
stuff,
and
many
tools
want
to
solve
this
problem
and
that's
where
the
application
CRD
came
about,
and
it's
not
meant
to
be
an
installer
or
a
deployer
for
anything?
There's
many
third-party
tools
can
do
that,
because
our
scope
is
interoperability,
not
solving
all
of
these
problems,
especially
when
the
ecosystem
wants
to
and
not
everybody
wants
to
be
consistent
and
how
they
do
it,
because
different
people
have
different
philosophies
and
we
want
to
enable
all
of
those
and
so
applications
here.
A
D
A
I
A
It
could
be
dependent
on
the
case.
You
might
have
a
tool
that
does
it
transparently
and
lets
them
know.
You
might
have
another
thing
where
it's
a
specific
object,
alongside
the
rest
of
the
things
we're
not
trying
to
dictate,
because
just
like
people
want
to
use
different
tools
for
different
things,
they've
got
different
flows
and
work.
Styles
and
kubernetes
is
not
trying
to
be
a
pass
and
apini
aid
and
how
these
parts
are.
That's
it's
an
intent.
A
If
you
go
to
what
is
kubernetes
you're,
actually
gonna
find
a
things
that
it's
not
and
something
that's
really
opinionated
like
this
is
something
that's
listed
as
one
of
the
things
kubernetes
isn't
gonna
do
because
other
tools
built
on
top
of
it
will
be
more
opinionated.
You
know,
one
of
the
things
that
I
wrote
about
recently
was
cloud.
A
Foundry
can
use
kubernetes
as
a
scheduler
and
they're
working
on
doing
that
instead
of
diego,
because
there's
an
opinion,
but
kubernetes
is
that
scheduler
in
there,
and
so
the
kubernetes
project
wants
to
let
other
things
build
on
top
of
it,
as
people
want
them
to
be,
rather
than
trying
to
solve
everything
for
everybody,
and
so
we
don't
have
an
opinion
on
that.
I.
J
Think
some
just
add
my
two
cents
today,
I
think
some
tools
certainly
could
write
like
helm.
For
example,
ready
has
a
lot
of
that
metadata
in
its
charter
yamo.
It
knows
all
the
resources
in
in
that
particular
chart,
so
some
tools
could,
but
if
I
was
deploying
something
with
cube,
CTL
cube
CTL
doesn't
have
all
the
knowledge
that
you
know
in
terms
of
metadata
that
we
want
to.
We
want
to
put
in
the
app
CRD,
so
in
that
case
we
might
need
to
use
it
to
write
the
application
CID.
All.