►
From YouTube: Kubernetes SIG Apps 20191104
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
But
we
wanted
to
discuss
primarily
missed
announcements.
Kubik
on
intro
and
deep
dives
are
coming
up,
they're
listed
on
the
website,
I
believe
rooms
haven't
been
selected
yet,
but
dates
and
times
have
so.
If
you're
going
to
San
Diego
come
check
out
and
participate.
There's
any
topics
that
you
guys
particularly
want
to
talk
about,
I
think
from
the
deep
dive
we'll
have
plenty
of
time
for
open
discussions
and
to
bring
up
new
topics.
But
if
there's
anything
a
particular
and
just
let
us
know
so,
code
freeze
is
coming
up.
November
14th.
A
Does
anybody
need
anything
I
see
the
maximum
available
PR
review
from
my
ink
so
that
I'll
go
take
a
look
at
I
assume.
That
means
that's
the
maximum
available
for
staples
at
PR
and
the
implementation
coming
in
by
Monday,
so
that
should
probably
make
the
cut
that
shouldn't
be
a
problem.
There's
anything
else,
yeah,
let
us
know
and
then
for
discussion
topics.
I
believe
Janet
was
the
one
yeah
who
had
the
recommendation,
labels
for
apps
and
she
wanted
to
you
to
discuss
this
so
I'll
hand
it
over
to
her.
B
Hey
so
I
believe
it's
a
wild
girls
that
we
discussed
the
recommended
labels
for
all
the
apps
and
one
of
the
labels
is
managed
by
label
that
you
can
use
it
to
record
which
app
you
use,
which
tool
you
use
to
manage
your
app.
So
my
question
is
what,
if
I
have
a
series
of
torch
and
that's
used
to
deploy
this
app?
C
Job
yeah,
Jenna,
I,
think
I
understand
where
you're
getting
at
so
the
little
context
on
this.
This
was
formed
a
little
bit
out
of
helm
with
a
managed
by
helm
had
a
similar
annotation
and
the
idea
behind
it
was,
if
you
have
something:
that's
not
just
installing
it
but
kind
of
managing
it
right,
so
you
might
have
how
managing
some
applications
and
then
other
tools
managing
other
applications
have
kind
of
got
the
ownership
on
the
upgrade
and
listing
in
other
processes
right
and
even
if
you're
gonna
go
between
tools.
C
You
may
want
to
switch
this
over
time,
and
it
was
this
idea
that
kind
of
one
tool
has
the
ownership
lock
on
it.
Now,
if
you're
dealing
something
like
it,
so
it
wasn't
meant
to
record
your
entire
CI
pipeline
or,
if
using
git
ops,
which
is
a
pole
model
rather
than
the
push.
You
know
your
entire
pipeline
of
tools.
C
The
whole
idea
was
to
say
this
is
the
thing
that
kind
of
owns
it,
whether
you're,
using
in
CI
we're
using
it
locally,
whether
you're
using
it
someplace
else,
and
it
wasn't
meant
to
document
your
whole
tool
chain.
If
we
wanted
to
document
that
tool
chain
somewhere,
I
would
suggest
maybe
a
different
thing
for
it.
If
that
makes
sense,
yeah.
B
C
So,
and
maybe
this
gets
into
it,
if
I'm
using
a
CI
toolchain
right,
let's
just
grab
something
like
circle,
that's
popular!
If
I've
got
it
deploying
what
I
say,
it's
managed
by
circle
or
or
circles,
just
one
of
the
tools,
because
my
Q
and
a
one-off
use
the
same
tools
you're
using
inside
of
circle
to
go
triage
and
correct
a
problem,
and
so
is
it
I'm
trying
to
dig
deeper.
Do
how
much
of
this
array
of
tools
really
says?
What's
managing
it
or
what's
just
being
used
in
the
process
through
the
main
line.
B
So
I'm
thinking
the
Mensch
by
label
is
not
the
right
place
to
store
this
information
and
interests
it
to
hear
how
people
are
storing
this
information
or
some
information
like
this,
like
you
have
a
serious
things
that
you
want
to
record
in
your
resource,
then
how
do
you
do
do
about
it?
So
I
put
an
idea
in
the
agenda
doc.
B
A
Mm-Hmm
I
actually
use
annotations
for
this,
mostly
like
the
in-house
automation
that
I
use
to
like
Orchestra,
create
various
things
in
the
cluster,
primarily
like
we
use
annotations
as
opposed
to
labels.
It's
not
selectable
right,
like
it's,
not
usually
something
that
humans
would
interact
with,
but
it's
kind
of
just
to
like
understand
the
provenance
of
something
in
everything
too
so
I
mean
maybe
that's
slightly
orthogonal
to
what
you're
talking
about,
like.
A
C
This
is
actually
one
of
the
reasons
I
asked
what
the
use
case
was
for
you
know.
What's
the
reason
behind
it,
I
think
Ken
I
heard
you
talk
about
recording
Providence,
and
so,
if
something
comes
in
and
modifies
it,
you
can
record
that
because
you're
getting
the
provenance
of
basically
who's
touched
to
everything
and
on
Janet's
side,
I
heard
I,
think
I
heard
you
say
you
were
talking
about,
maybe
visualizing
it
and
querying
on
it.
You
know
we'll
go
back
to
the
circle,
see
I,
maybe
I
say
give
me
everything.
C
D
C
E
F
B
B
C
B
C
Mean
from
the
Providence
aspect,
I'm
also
wondering
granted.
This
is
this
is
just
getting
trickier
because
you
know
when
it
comes
to
Providence,
just
touching
something
in
saying
it's,
there
doesn't
give
you
a
whole
lot
of
provenance.
It
actually
makes
me
wonder
if
there's
a
way
to
incorporate
something
like
in
toto
into
the
stack.
C
C
C
C
A
Okay,
so
I
think
that
was
all
we
had
on
the
agenda.
Does
anyone
else
have
anything
they
want
to
bring
up.
G
Guys
I
sorry
I
have
one.
This
is
Steve.
Christine
I
have
one
quick
question,
I'm
sure
I
very
infrequent
visitor
to
see
gaps.
Okay
is
this
where
we
would
talk
about
like
developer
tooling,
like
so
that
developers
don't
have
to
write
yeah,
Moe
and
all
that
kind
of
stuff
to
work
with
kubernetes,
or
is
that
it
is
there
another
sig
for
that
I.
C
A
Jump
about
god,
I
mean
so
there.
There
was
a
working
group
for
developer
tooling,
but
hey
I
haven't
seen
them
meet
in
quite
some
time.
Sig
Apps
is
a
good
place
to
do
that.
I
think
we
traditionally
have
talked
a
lot
about
developer,
tooling
and
things
surrounding
the
ecosystem
that
we
use
the
workloads
API
from
a
maintainer
perspective,
we're
kind
of
concerned
primarily
with
the
workload
avianna
yeah.
C
It's
so
in
the
past
we
spent
quite
a
bit
of
time
talking
about
developer
tooling.
There
was
the
I'm
forgetting
the
name
of
the
work
group.
It's
spun
out,
but
it's
closed
now
and
so
the
developer
tooling
technically
falls
back
here.
Since
then,
the
CNC
F
has
also
created
the
their
own
app
delivery.
Sega.
C
The
CNC
F,
which
is
the
parent
organization
to
kubernetes,
has
created
special
interest
groups
to
support
the
TOC
technical
Oversight
Committee,
and
they
also
they
have
a
cig,
app
delivery,
and
that
is
another
venue,
but
we
have
talked
a
lot
about
kubernetes
specific
developer
tooling
over
time
to
simplify
that
whole
process
and
I
personally,
would
be
very
interested
in
hearing
more
about
that.
If
folks
had
things
they
wanted
to
talk
about
or
share
in
that
space
have
opinions,
I'd.
G
Love
to
hear
opinions
too,
but
those
are
cheap,
I
guess
the
reason
I
was
kind
of
asking
it's.
Not
it's
not
really
about
app
delivery
right,
it's
more
about
app
construction,
so
the
to
try
to
get
kubernetes
adoption
in
the
sense
of
this
is
actually
a
good
place
to
do
your
development
work.
How
do
you
actually
construct
an
app?
How
do
you
wire
things
together
easily?
How
do
you
do
I
would
have
mad
I
was
thinking
that
would
fall
under
see
gaps.
It's
not
how
I
deliver
an
entire
app
once
I
built
it.
C
And
I
think
it
falls
into
both
the
scope
here
and
over
there
some
of
the
things
we
may
look
at
incubating
a
project
here
or
we
may
just
encourage
and
share
and
demo
projects
we
do
have
demo
slots.
We
haven't
had
many
demos
lately,
but
if
you
go
to
the
past
of
cig,
apps
you'll
see
many
demos
of
different
tools,
including
some
CN
CF
projects
when
they're
very
early
on
like
telepresence,
which
is
a
debugging
tool
that
you
can
use
while
you're
building
a
service
along
with
a
bunch
of
other
micro
services.
D
G
Maybe
so
I'll
give
you
my
for
my
I,
don't
know
if
you
want
to
do
it.
Do
you
want
it
now
sure.
C
G
May
sit
so
I'm,
so
just
by
way
of
background
I
was
one
of
the
original
developer
advocates
on
open
shift
right,
so
I
no
longer
work
on
open
shifts,
I
no
longer
even
working
Red,
Hat
I
now
work
at
crunchy
data,
the
Postgres
people.
We
have
an
operator
we
used
to
have
a
stateful
set,
but
then
it's
been
migrated
to
an
operator.
My
job
is
developer
relations
at
crunchy
data
so
and
we
to
get
people
excited
about
using
Postgres,
but
I
am
excited
about
getting
people
using
the
operator.
G
C
C
They
create
an
apt
package
and
then
the
99.9%
of
other
people
use
apt-get,
install
Postgres,
and
they
don't
ever
have
to
know
that,
because
somebody
who
understands
the
complexities
brings
them
together
so
that
almost
nobody
else
has
to,
and
that's
the
if
you
have
a
home
package,
and
so
in
that
case,
I
think
how
I'm
successful,
but
almost
no
developer
should
ever
have
to
create
their
own
home
package.
It's
a
small
subset,
so
it
doesn't
really
solve
the
developer
problem.
Exactly.
G
So
but
I
think
for
most
people
what
ends
up
happening
is
they're,
saying:
oh,
how
do
I
get
my
Python
app
on
to
kubernetes?
Oh
well,
either
you're,
building
a
container
and
writing
a
MoU
or
build
a
helmet
art
to
install
your
container
on
to
kubernetes.
But
there
is
no
good
solution
like
there's
sui
which
never
went
anywhere
right
and
it
still
had
problems
and
RedHat
doesn't
now
I
can
talk
freely
since
I'm
no
longer
write,
hat
I,
don't
think.
Red.
Hat
really
cares
that
much
about
us
to
sort
source
to
image
the
s2
I.
G
They
still
have
it
there,
but
it
development
I'm,
making
it
better,
hasn't
really
happened,
and
so
there
is
no
good
solution
for
I've
got
code.
I
want
stuff
in
kubernetes
know.
C
There
was
draft
that
the
Microsoft
folks
have
been
working
on,
but
that's
basically
a
dead
project
unless
somebody
else
wants
to
go,
take
it
on
and
that
was
kind
of
like
take
your
path
solution,
but
move
it
locally.
So
they
would
detect
what
you're
writing
in
try
to
create
the
right
docker
file
for
you.
They
used
helm
charts,
but
they
just
tried
to
create
configuration
in
the
background
and
gave
you
that
closed
loop
save
thing
and
they
called
the
draft
pack.
But
it's
basically
built
on
the
idea
of
a
build
pack.
C
And
how
do
you
have
that
locally?
So
you
get
those
loops
even
with
applications
that
are
not
so
much
12
factor
right
right,
which
is
rigged
into
the
past,
but
you're
right
this
last
year,
I
looked
at
a
whole
lot
of
data
on
this
and
I
found
that
there
aren't
good
tools
for
this.
Quite
frankly,
in
fact,
if
you
want
to
take
something
like
WordPress
right,
WordPress,
the
prototypical
example
and
you
back
it
with
my
sequel
or
Maria
DB,
and
you
want.
C
What
or
Postgres
yes
I'm
gonna
get
your
basic
your
basic
setup
going
right,
not
like
no
pod
security
policy,
no
horizontal,
pod,
auto
scaling
any
of
those
things
right.
You
just
take
your
basic
thing:
you're
low
barrier
to
entry,
you're
talking,
13
different,
manifests,
13
and
you're,
probably
talking
what
a
thousand
lines
of
yam
oh
yeah,
and
that's
just
to
launch
your
basic
work.
That
is
a
terrible
user
experience.
So
I
agree
with
you
so
I'm
very
curious.
Do
you
have
any
ideas?
Okay,
we've
defined
it
terrible
yeah.
D
C
G
No
I
get
I,
get
it
and
I
do
that's
know,
that's
part
or
as
here--is
hoping
there
be
people
here
who
would
have
better
ideas
right,
I
haven't
I,
don't
I'd
have
to
have
an
engineering
team
and
people
who
were
like
I
mean
I,
can
think
of
things
but
I'm
afraid
I've
ever
seen
that
Simpsons
episode,
where
homers
put
in
charge
of
designing
the
car?
Yes,
so
I'm
a
little
afraid
of
designing
the
Homer
Simpson
car
when
I
say
the
things
that
I
want
I
mean
I.
G
There
was
some
iteration
I
did
just
before
I
left
Red
Hat
on
stuff.
That
I
thought
was
better
in
the
sense
of
we
need
something
at
all.
We
need
I
know,
there's
the
coop
API,
but
I
almost
think
there
needs
to
be
an
API
and
concepts
above
Kubb
for
developers.
So
I
think
the
I
was
the
draft
of
the
spec
for
okd
no
keyd.
What
do
they
call
it?
G
Odie
Odie,
oh
I,
don't
know
it's
a
new
command
line
tool
which
was
supposed
to
be
higher-level
concepts
for
developers
because
I
don't
think
most
developers
who
want
to
deliver.
It's
like
saying:
if
I
want
to
develop
a
desktop,
app,
okay.
Well,
you
have
to
learn
Linux
kernel
internals
to
develop
a
desktop
app
right
like
that's,
not
the
level
we
want
most
developers
working
at
so
I
think
what
we
kind
of
need
at
some
level
is
the
kubernetes
community
to
say:
okay
yeah!
D
C
C
Looked
at
it
so
I
don't
know,
and
it's
still
yeah
Mille,
but
if,
as
far
as
I
can
tell
right,
so
if
you're
gonna
go
with
a
pass
and
you're
gonna
grab
something
like
Heroku
or
Cloud,
Foundry
right
still
have
to
configure
it
and
for
them
it's
JSON.
You
still
have
a
small
file
that
passes
certain
things
in
such
as
12
factor
app.
Here's
your
domain!
Here's!
How
much
memory
we
need
right!
There's!
There's!
There's
minimal
characteristics
like
that,
but
based
on
that,
you
can
generate
a
lot
more
based
on
a
lot
of
assumptions.
C
D
C
A
proof
of
concept:
it's
not
released
yet
and
I
found
that
for
I,
don't
know
what
percentage
of
cases
between
15
like
80%
of
cases.
You
can
actually
do
that
for
kubernetes.
You're,
not
gonna,
get
all
the
crazy
features,
but
almost
nobody
does
and
then
you
can
generate
stuff,
in
fact,
from
your
generation
of
code.
You
can
say
you
know
what,
in
this
cluster
I'm
using
ingress
in
this
cluster
I'm
using
ISTE,
oh
and
this
cluster
I'm
using
link
or
D,
so
in
my
generation,
generate
the
right
stuff
for
each
one
of
those
cases.
G
G
We're
gonna
make
it
easy
for
you,
because
at
that
point
then
I'm
invested
in
the
platform
and
then,
if
I
need
something
crazy,
then
I'm
willing
to
invest
the
mental
and
time
and
all
that
other
energy
to
learn
the
okay
yeah
I
can
use
my
typical
thing
to
generate
some
stubs,
but
then
I'm
gonna
spend
the
next
four
days.
Writing
yamo
trying
to
get
this
really
complicated
thing
going.
But
if
you
start
with
that,
you
have
to
write
a
whole
bunch
of
complicated
Yambol
to
begin
with,
most
developers
like
I'm
out.
No
thank
you.
G
C
So
they
did
I
would
say
I
just
to
take
a
look
at
it,
I'm
hoping
to
before
coupe
con
cos.
We
won't
have
a
meeting
in
two
weeks
on
Monday,
which
is
something
we
should
probably
talk
about
in
this
meeting.
We
won't
be
meeting
again
until
December,
2nd,
and
so
it
might
be
worth
trying
to
get
a
demo
from
them
in
here
to
talk
more
about
it.
I
haven't
had
a
chance
to
evaluate
it,
but
you're
absolutely
right,
there's
a
gap
there
and
we
probably
need
to
get
more
conversations
going
on
that
gap.
C
So
people
can
start
to
talk
about
it
because
I'll
be
honest.
I've
talked
to
people
on
this
and
I've
heard
from
lots
of
organizations
at
this
cognitive
learning
that
you
have
to
do
is
a
problem.
It's
like
a
real-world
problem
that
we're
running
into,
and
there
are
organizations
out
there
that
are
saying
no
to
kubernetes,
because
the
onboarding
is
too
difficult,
especially.
G
C
G
Especially
for
their
developers
to
me,
they
expect
to
get
into
this
stuff.
I
mean
it's
still
expensive
and
hard
for
them.
Developers
are
like
I'm
already
learning
like
the
latest
and
greatest
JavaScript
I,
don't
have
time
to
learn
how
to
write
ya
mole
to
disk
lair.
All
these
things
that
these
low-level
concepts
that
I
don't
care
about
anymore
right,
like.
G
B
C
Business
logic
right,
I,
don't
want
to
be
too
concerned
with
all
the
intricacies
underneath
it
because
I'm
concerned
with
my
layer,
you're
concerned
with
your
layer.
Let's
have
clean
interfaces
between
the
layers
that
allow
us
to
engage
on
that
and
so
I
think
you're.
Absolutely
right
and
I
would
love
to
have
more
talk
in
that
so,
okay
Q
for
bringing
it
up
I
would.
A
Airbnb
is
an
example
there.
There
are
many
examples
out
there.
Pinterest
like
you'll,
build
develop
models
and
orchestrators
that
are
geared
to
their
specific
or
close
using
crts.
So
that's
one
approach.
If
you're
looking
for
something
uniform
that
solves
the
problem
in
the
general
I
haven't
seen
anything
that
is
adequate
to
do
that,
if
you're
looking
to
offer
that
as
we'll
build
that
under
the
domain
of
say,
apps
any
like
you,
it's.
G
A
lot
of
work,
you
know
I
I,
completely
agree,
but
I
also
think
that
see
gaps
could
at
least
push
the
the
model
of
what
we're
trying
to
accomplish,
maybe
not
actually
build
it.
But
at
least
say
there
is
a
need
for
this
and
then
see.
If
people
you
can
coalesce
I
mean
the
problem
with
what
you're
talking
about
the
people
who
build
their
own
stuff
are
the
unicorns
who
build
their
own
stuff
and
so
yeah.
You
can
get
air
B&B
to
adopt
communities
and
yeah.
G
You
can
get
these
real,
these
companies
that
have
huge
technical
staffs
with
deep
expertise,
but
to
be
at
the
same
level.
That's
like
saying
the
people
who
used
to
adopt
Linux
right.
It
used
to
be
unicorns
or
people
who
had
really
big
staff,
and
then
things
started
going
on
top
of
it
to
make
it
easier
for
people
to
run
and
package
stuff
and
to
put
together
the
things
they
wanted
and
that's
when
you
start
getting
more
mass
adoption.
So.
A
I
mean
I
should
but
like
I
would
say
this
to
like
people
who
run
open
source
Linux
without
a
support,
contract
from
say,
Red,
Hat
or
canonical,
and
who
don't
know
how
to
maintain
their
own
kernel.
Hygiene
are
probably
not
doing
themself
any
favors
in
the
long
run
when
a
security,
vulnerability
pops
up
right,
but.
G
That's
a
totally
different
discussion
at
that
point.
You've
at
least
said
got
them
to
say:
oh
I,
love,
Linux
and
I
want
to
run
Linux,
which
is
the
problem
that
I
think
we're
gonna
end
up
facing
in
this
group.
If
you
can't
make
it
so
that
developers
like
I
love
kubernetes,
it
makes
my
job
better
as
opposed
to
I
hate
kubernetes,
because
just
to
get
my
app
launched
so
I
have
to
write
31
yamo
files.
That's
what
I'm
and.
C
C
So
they
may
do
a
lot
of
the
development
on
Windows
or
Mac,
and
then,
when
the
application
is
run
in
production
or
even
in
the
QA
environments
or
dev
environment
or
whatever
it's
running
in
Linux,
they
see
no
difference
and
they
never
had
to
learn
the
the
Linux
kernel
api's.
In
order
to
do
this
because
their
tools
just
automatically
work
and
translate
into
that
environment
right.
G
So
I
like
to
think
of
communities
as
new
OS
right,
the
distributed
system
operating
system
and
I
think
we
just
need
to
build
a
tooling
or
I'm,
making
it
easier
for
developers
when
I
say
we
I
don't
mean
this
group
specifically
I
mean
we
the
community.
We
need
to
start
building
the
tooling
so
that
it
can
actually
act
that
way
for
higher
level,
apps
and
app
division
developers.
That.
A
Would
say
this
right
like
if
you
want
to
use
the
analogy
like
app
developers,
use
nodejs
or
JVM
Beam
or
like
if
you're
saying
that,
like
not,
everyone
is
a
si
developer
that
understands
the
low-level
system,
calls
sure
like
there's,
not
just
one
way
to
do
it
right.
It's
not.
All
app
developers
run
nodejs
on
top
of
the
powerful
primitives
that
are
provided
by
an
operating
system.
Their
community
is
that
built
Java.
A
They
built
the
JVM
and
the
people
who
build
the
JVM,
do
right
at
UC
and
do
understand
low-level
kernel
primitives
across
multiple
operating
systems.
The
same
is
true
of
the
CLR
runtime,
which
powers
net.
The
same
is
true
of
v8,
which
powers
nodejs
so
I
mean
there's,
definitely
a
need
for
people
to
build
these
platforms
that
provide
value
and
in
terms
of
developer,
velocity
and
ease
of
use
on
top
of
an
operating
system.
A
The
question
is:
should
there
be
one
to
rule
them
all,
or
should
there
be
many,
and
you
know
for
particular
use
cases
like
it?
No
js'
is
not
my
favorite
javascript
is
not
my
favorite
thing
for
a
back-end
surface,
but
it's
popular
and
it
has
its
use
case.
Java
can
be
verbose
but
again,
like
it
still
powers
much
of
the
enterprise
because
of
its
kind
of
prolific
presence
so,
like
maybe
the
answer
might
be.
There
are
many
different
models
that
you
can
build
on
run.
C
I
mean
you're,
so
maybe
let
me
put
it
this
way:
Kent
Kent,
if
you
don't
mind,
maybe
put
it
this
way:
it's
not
about
kubernetes,
owning
and
building
one
version
here
right.
This
is
different
than
us,
owning
and
building
one
version.
It's
we're
in
a
position
of
leadership
where
we
can
encourage
the
development
of
these.
C
We
can
showcase
them
and
we
can
give
certain
kinds
of
rewards
in
the
way
that
developers
get
rewarded
by
being
called
things
like
that,
in
order
to
continue
to
encourage
the
development
of
these,
because
right
now,
we've
identified,
we
need
them,
but
we
don't
have
them.
So
how
can
we
encourage
the
development
of
these
outside
of
the
kubernetes
project
in
order
to
help
them
facilitate
the
growth
of
kubernetes
usage
and
happiness
and
joy.
A
C
Would
love
to
have
reference
to
them
because
usually
when
I
see
them,
they
are
a
DevOps
tool,
not
a
developer
tool
and
the
line
difference
isn't
called
out
its
DevOps
people
saying
look
at
this
tool,
developers
should
use
it
and
then
a
developer
comes
along.
He
goes
this
isn't
for
me,
this
is
for
DevOps
people,
there's
a
difference,
and
it's
it's
not
noted.
C
A
Then
I
think
the
other
thing
is
to
go
and
talk
about
the
difference
between
what
kubernetes
enables
for
organizations
and
what
it
does
for
developers,
because
the
experience
of
somebody
who's
using
kubernetes
system
development
environment
on
top
of
mini
crew
is
very
different
from
what
your
actual
requirements
are.
Once
you
want
to
deploy
it
at
scale
across
the
organization
with
hundreds
of
thousands
of
engineers
who
are
continuously
deploying
into
production,
it's
not
the
same
concerns,
at
least
but
from
from
looking
at
both
sides
of
it
from
my
company.
A
C
I
would
say
that
Google
is
a
unicorn
case
and
the
company
that
you're
at
they
went
and
they
hired
people
who
specifically
were
experts
in
kubernetes
in
order
to
pull
this
off
and,
quite
frankly,
almost
there
aren't
enough
bodies
out
there
in
order
for
every
company
that
needs
this
to
go,
hire
that
expertise
in
order
to
make
it
happen,
it
needs
to
be
automated.
It
needs
to
be
made
a
low
barrier
to
entry,
and
so
that
that's
that's
just
one
of
the
problems
that
is
ending
up,
showing
up
I
guess.
C
H
I,
don't
hey!
This
is
Nagi
I'll,
add
my
two
cents,
because
I
think
both
within
sig
apps
and
6e
Ally
I
was
looking
at
the
topic
of
having
some
higher-level
API,
just
like
Steve
was
describing
and
honestly
each
and
every
single
approach.
That
I
was
taking
led
me
to
the
conclusion
that
oh
yeah,
this
will
address
the
basic
ten
twenty
percent
of
these
cases,
but
as
soon
as
I
want
to
tweak
it
with
I,
don't
know
my
specific
deployment.
H
Currently
that
that
effort
hasn't
moved
a
lot
due
to
a
splitting
that
keeps
the
deal
out
of
the
main
repo,
but
I
do
hope
that,
after
we're
done
with
this
effort,
we
could
return
to
that
one,
at
least
to
ensure
that
the
the
entry
level
is
much
better
for
users.
On
top
of
that,
I
think
it
would
be
useful
to
sync
with
SiC
usability.
I
guess
see
if
that's
for
you
or
you
can
also
show
up
for
the
six
UI
and
speak
about
it.
C
One
thing
that
I
would
throw
at
this
is
I
think
that
a
lot
of
the
app
developers
out
there,
the
developers,
many
of
them
don't
even
want
to
use
a
CLI,
and
so
what
we
need
is
things
that
can
be
used
to
power
tools
built
on
top
of
C
lies.
A
significant
amount
of
people
want
to
use
a
GUI,
quite
frankly
and
I
know
around
kubernetes
we
are
so
used
to
C
lies.
I
live
in
my
terminal
right.
In
fact,
I've
got
tabs
and
windows.
C
I've
probably
got
as
many
as
I
have
browsers,
open,
interacting
and
doing
different
things,
and
that's
not
the
typical
use
case
when
you
get
into
lots
of
developers,
especially
in
the
enterprise
and
so
the
ability
to
have
things
at
a
higher
level
abstraction
where
they
don't
even
have
to
open
up
a
terminal.
It's
important
and
I
know.
We
don't
think
that
a
lot,
especially
in
the
the
ops
DevOps
space,
but
that's
where
a
lot
of
them
are
at
and
that's
why
I
say
it's
different
yeah.
G
And
I
think,
but
I
do
think
that
this
is
what
I
do
like
the
coop
has
really
done
around
their
CLI.
It's
basically
just
calling
into
a
rest
interface
right.
So
then
the
higher
life
we
that
you
could
sync
think
of
the
CLI
is
at
least
prototyping
some
of
the
things
that
you
can
then
put
a
GUI
on
using
the
same
rest,
Yeah
right.
So
that's
what
I
really
liked.
G
Also
when
you
I
don't
know
if
it's
in
coop,
CTL
or
coop,
cuddle
or,
however,
people
want
to
pronounce
it
but
an
OC,
you
could
to
pass
a
debug
flag
and
it
would
show
you
all
the
rest
calls
that
were
happening
under
the
scenes
when
you
reducing
the
CLI,
I'm
sure,
there's
something
in
cute
cuddle
or
something
like
that.
Yeah.
G
I
realize
a
good
place
to
start,
but
it's
not
the
end
condition,
but
then
I
think
tooling.
Vendors
could
take
that
over
right,
I
could
see
and
tell
like
IntelliJ
has
already
done
stuff
around
kubernetes.
If
there's
enough
developer
adoption
of
I
develop
in
kubernetes,
then
the
tooling
vendors
will
be
like
well,
that's
where
the
developers
are.
That's
what
we
need
to
build
tooling
around
to
make
it
easier
that
I,
don't
think
that's
we
don't
have
to
necessarily
take
on
what
the
GUI
looks
like
I.
Just
think
we
need
to
know
so.
There's
constant
yeah.
H
H
We
do
try
to
put
a
lot
of
effort
into
ensuring
that
the
this
and
truth
to
be
told
since
I
spent
majority
of
my
time,
like
99%
of
time
for
within
the
CLI,
at
least
from
my
perspective,
whenever
I
look
at
OpenShift
web
console,
I'm
always
mesmerized
how
far
they
they
went
between
releases
because
I.
This
is
like
literally
how
frequently
I
look
at
the
web
UI
being
the
CLI
person.
G
G
I'm
like
okay,
we're
just
gonna
use,
Red,
Hat's
distribution
of
kubernetes,
because
there's
no
way
I'm
writing
yamo
all
the
time,
and
even
if
you
want
to
use
it
on
straight
kubernetes,
I'm
still
going
to
use
OC
new
app
to
generate
or
the
web
UI
to
generate
that
yeah
Mel
at
least
that
I
can
then
take
and
modify
to
use
in
a
straight
kubernetes
cluster.
But
there's
no
way
I'm
going
down
that
route
on
my
own.
So.
H
That's
that's
literally
what
I
would
like
to
see
happening
within
the
cube
CTL
having
this?
Oh,
this
is
the
app
generate
me
at
least
a
initial
bunch
of
youngs
for
me
to
start
with,
and
then
sooner
or
later,
I
was
like
twiddling
with
the
ohms
and
I.
Think
that's
a
good
first
step
that
we're
missing
in
Luci.
Do
you.
H
C
Look
at
that
level,
which
is
not
the
level
of
granularity
and
app
developers
gonna
care
about
they.
Quite
frankly,
a
lot
of
them
from
any
apps
are
gonna,
want
the
Heroku
level
and
and
I'm,
assuming
that
Heroku
is
doing
a
lot
with
uber
Nettie's,
because
hey
at
the
the
cloud
native
found,
they're
gonna
be
talking
they're,
giving
one
of
the
keynotes
I
saw
and
and
they've
been
hiring
for
kubernetes
people
and
their
systems
in
the
past
were
basically
a
container
manager
on
top
of,
but
they
were
using
LXE
containers
before
or
whatever
they're
using.
G
Go
here,
yeah,
sorry,
so
here's
the
I'm
gonna
post
it
in
the
chat.
Also
this
is
what
I
had
started
speaking
out
and
had
started
the
work
on
openshift.
It
was
o
dó
and
this
we
got
rid
of
the
concept
of
pause
in
talking
about
it,
for
developers
like
pods
were
underneath,
but
we
had
things
called
components
like
there's
an
application.
G
But
what
did
we
call
them
a
project,
an
application
and
component,
so
a
project
and
multiple
applications
inside
of
a
project,
and
then
you
have
components
within
an
application,
not
a
pod,
and
you
don't
have
an
ingress.
You
have
just
give
me
a
URL
like
that
was
what
it
was
supposed
to
be
so
that
talking
the
concepts
of
developers,
but
underneath
the
hoods
it
does,
what
the
good
the
right
thing
right.
So
so
a
single
component
right.
So
a
single
component
application.
C
G
So
things
like
storage
right
like
this
is
the
thing
that
I
think
is
terrible
in
kubernetes
land
also
is
talk
developers
having
to
deal
with
storage,
so
an
OD,
oh
it's
just
or
oh.
Do
storage
create
some
storage
on
the
node,
node
storage
right
I,
just
want
storage!
I!
Don't
want
to
talk
to
you
about
PVCs
I!
Don't
want
to
talk
to
you
about
what
labels
and
all
that
other
stuff.
Just
give
me
some
disk
and
I
want
this
to
have
like
this
kind
of
behavior,
that's
it
and
where
to
mount
it.
That.
A
Sort
of
sounds
good,
but
like
so
you
have
to
remember
that
kubernetes
is
designed
to
kind
of
be
versatile
and
try
to
provide
the
most
value
for
many
users.
Right
and
all
you
want
to
do
is
run
a
stateless
serving
workload.
Fine,
that's
that
should
be
straightforward,
a
mad
experience.
Maybe
you
could
be
optimized
quite
a
bit,
but
when
you
start
talking
about
you're.
C
G
G
It's
again
right
now
the
experiences
start
from
their
start,
as
if
you
have
to
understand
all
the
pieces
to
run
something
with
network
going
storage.
The
idea
with
something
like
o
do
is
I.
Don't
need
that
no-one's,
building
that
app
out
of
the
box
they
need
to,
and
once
I've
decided,
Oh
Cooper
nice
stuff
is
nice
on
kubernetes
I
can
go
learn
that
other
stuff.
G
C
You
have
to
create
a
deployment
you
have
to
create
a
service.
You
got
to
have
an
ingress.
You
also
have
to
have
an
ingress
control
like
nginx
ingress
installed
in
your
cluster
right
right
and
so,
and
you've
got
to
know
the
right
annotations
to
put
on
your
ingress
so
that
engine
X
ingress
can
pick
it
up,
and
so
you've
already
had
to
create
all
these
things
to
know
this
context.
In
order
to
launch
your
simple
service
right,
you.
G
Have
to
learn
a
pod,
you
have
to
learn
a
pod
descriptor.
You
have
to
learn
a
template.
You
have
to
learn.
You
wanted
to
go
through
what
all
the
different
things
we
make.
People
have,
there's.
No
there's
no
description
in
our
yamo
files
about
what's
actually
required,
what's
not
required,
so
you
actually
have
to
go
through
and
learn
a
yamo
format
and
all
the
things
in
there
and
what
those
words
mean
and
how
to
fill
them
in
appropriately
with
no
type
support
like
it's
no
problem
with
putting
in
a
typo
or
anything
else.
G
A
G
It's
never
like
been
easy,
like
docker
composed
was
actually
pretty
pretty
damn
easy
and
we
don't.
We
kubernetes
benefited
from
the
size
of
its
community
and
the
fact
that
docker
was
jerks
to
everybody
else
and
killed
their
community,
but
docker
car
actually
built
good
software,
and
it
had
worked
as
good
as
kubernetes
worked
out
of
the
box.
We
would
have
lost.
G
You
could
use
a
compose
file
to
import
it
into
swarm
and
then
that
would
just
do
the
right
thing
so
for
a
developer.
They
just
had
to
start
with
compose
to
get
Apache
running
right
and
the
competence
in
compose
were
really
freaking.
Simple
I
want
this
pod
I
want
this
docker
container
I
want
this
docker
container
I
want
them
to
talk
to
each
other
and
I.
Want
you
to
give
me
a
URL
and
that's
all
you
had
to
say,
and
there
was
no,
it
was
maybe
I,
don't
remember
who
was
Yammer
or
not?
G
C
Think
about
it.
This
way
just
think
about
any
different
way.
With
a
lot
of
the
other
systems
out
there,
people
can
have
fun
in
five
minutes.
I
can
go
launch
very
simply
my
simple
service
and
then,
as
I,
need
to
deal
with
more
complicated
I
learn
more
complicated.
We
expect
that
you
start
with
the
most
complicated
possible
situation,
and
you
have
to
learn
all
of
that.
Even
to
do
this
simple,
which
means
you
don't
get
to
start
with
this
simple.
C
You
have
to
start
with
the
most
complicated
in
order
to
deploy
my
my
stateless
micro
service
I
have
to
go,
learn
enough,
where
I
could
also
deploy
the
most
complicated
thing
that
I'm
ever
going
to
deploy
right.
I
have
to
learn
all
of
that
even
to
do
the
simple
and
that's
where
we
run
into
a
problem
and
I'm
reminded
here
stripe
and
there
cron
setup
did
everybody
see
what
they
did
a
couple
of
years
ago.
They
came
up
with
a
super
simplified
cron
format,
so
the
developers
never
had
to
do
it.
C
A
Have
to
know
the
rest
rest
did
the
same
thing.
My
point,
is
it
like?
Yes,
I
see
a
lot
of
organizations
building
their
own
platform
on
top
of
kubernetes
and
using
kubernetes
and
infrastructure
Orchestrator
in
order
to
make
the
lives
of
developers
easily
easier.
We
do
the
same
thing
at
racks.
Right
like
it's
not
I
mean
it
like
is
the
level
of
effort,
small
No,
but
you
don't
need
a
to
say,
give
you
a
thousand
engineering
engineer
team
to
do
it.
It's
also
a
little
bit
hyperbolic,
but.
C
But
right
now
most
of
this
stuff
is
in-house
proprietary.
It's
not
out
house
which
are
out.
You
know
out
in
the
open
source,
which
means
most
people
can't
pick
it
up,
because
ma
earn
enough
people
who
can
go,
develop
those
tools
who
understand
so
that
every
company
can
have
their
own
bespoke
processes.
So
you
end
up
with
most
people
just
suffering
through
it,
because
you
don't
have
the
tools
to
put
on
top
I.
G
Think-
and
the
point
of
saying
you
even
have
to
have
an
engineering
team
to
build
the
tooling
on
top-
is
a
broken
assumption
like
if
that's
what
it
takes,
then
most
companies
aren't
going
to
adopt
like
oh
well
to
really
get
it
to
work
decent
for
your
people
inside.
You
actually
need
to
go,
hire
an
engineering
team
of
five
people
and
they
can
do
it.
If
you
find
three
people
or
five
people
who
know
kubernetes
pretty
well
and
also
have
experience
and
billing
developer
tooling,
you
can
probably
do
something
at
your
company.
G
A
Sympathetic
to
the
pain
of
people
are
coming
on
to
kubernetes
for
the
first
time
for
sure,
but
you
keep
coming
back
to
this
argument
that
we
need
to
increase
adoption
or
that
adoption
is
troubled
like
do
we
really
do.
We
have
data
to
support
that
kubernetes
adoption
is
troubled,
that
we're
being
at
the
application
at
the
application
developer.
G
Level
yeah
every
time
I
go
out
to
a
customer,
say
and
I
talk
to
them
about
OpenShift
and
they're
like
yeah,
we're
not
introducing
that
to
developers
yet
because
there's
no
way
they're
gonna
understand
it
and
they're
not
gonna,
be
able
to
use
it.
Every
single
customer
I
go
to
the
ops
team
likes
it.
No
application
they're
like
we'll
just
have
them
develop
stuff
in
containers
and
we'll
figure
out
how
to
do
it
forth.
So.
C
So
let
me
say
this
anecdotally:
by
people
who
go
to
customers.
There's
piles
of
information
out
there,
a
statistics,
wise
I,
read
one
analysis
and
I
can't
remember
who
did
it
so
I
can't
track
it
down
that
talked
about
things
like
container
taking
on
versus
kubernetes,
and
they
actually
did
a
bunch
of
the
measurement
on
it.
But
I
can't
remember
who
did
it
so
I
know
a
lot
of
anecdotal
information.
We've
got
that
where
I'm
at
piles
of
it
and
I've
heard
everybody
else.
C
G
Think,
yes,
it's
like
vitamins
where
no
one's
gonna
pay
for
the
the
clinical
trials
on
vitamins,
because
there's
not
enough
money
in
it.
No
one's
actually
going
to
pay
for
the
survey
to
actually
go,
find
out
the
actual
data
and
then
usually
what
ends
up
happening.
Saying.
Well,
there's
no
actual
data,
so
this
isn't
actually
really
a
problem.
That's.
G
A
Has
nice
enough
to
share
it
about
if
we're
talking
about
adoption
about
market
saturation
like
out
of
people
using
containers?
Are
people
using
other
things
in
kubernetes,
because
it's
so
painful,
which
is
a
different
thing
to
meet
and
should
be
work
to
try
to
make
the
application
developers
life
easier,
which
I
think
we
should
so.
C
How
you're
here,
because
one
of
the
problems,
though,
because
you
know
what's
going
on
with
this,
but
we're
also
trying
to
get
into
a
lot
of
new
markets
such
as
the
enterprise,
the
enterprise
is
now
adopting
containers
and
cloud
at
a
much
stronger
rate.
Right
and
you've
got
I
mean.
There's
application
to.
There
are
teams,
building
applications
that
have
three
four
five,
six
or
more
hundred
developers
working
on
an
app
and
now
you've
got
to
onboard
them
to
doing
things
with
kubernetes.
C
That
is
a
gigantic
cost
sink
for
them
to
go,
learn
all
of
this
kubernetes,
which
then
becomes
cross
prohibitive,
and
so
they
say
well.
We're
gonna
go
to
a
different
set
up.
That
is
more
conducive
to
onboarding
our
stuff
than
to
going
with
kubernetes,
and
this
is
happening
because
they're
looking
for
things
that
have
a
much
smaller
barrier
to
entry,
where
they
don't
have
to
spend
so
much
time
on
boarding.
So
many
people
kubernetes
like
what
yeah,
what
do
they
use
instead,
yeah.
A
G
But
that's
like
I
agree
with
you,
so
I'm
saying
kubernetes
has
one
kubernetes
will
be
the
container
operating
system
over
the
future.
That
is
without
a
doubt.
There
I,
don't
think,
there's
any
discussion
about
that
anymore.
I
think
the
question
is
whether
we
can
actually
get
app
for
me.
It's
not
about
adoption
at
the
company
level,
it's
adoption
at
the
developer
level
and
whether
developers
like,
if
you
just
want
to
build
a
system
or
a
debit.
This
is
just
a
seesaw
DevOps
or
some
systems
administrator
tool.
That's
fine,
but
I.
G
C
About
this
right
now,
the
SIS,
admins
and
DevOps
people
tend
to
like
kubernetes,
and
they
are
now
dragging
the
app
developers,
the
developers
on
kicking
and
screaming,
because
they
don't
like
it
do
we
want
to
keep
that
as
the
status
quo.
Or
do
we
want
to
make
it
so
they're
delighted
by
it
as
well
and
they're
not
being
ripped
along
kicking
and
screaming
annoyed
that
their
organizations
are
trying
to
force
them
to
use
it?
How
do
we
want
the
the
situation
to
be
I
mean
obviously.
A
I'd,
like
I'd
like
it
to
be
a
wonderful
experience
for
developers
and
like
inside
of
my
company
I
work
very
hard
to
try
to
you,
know,
build
the
right,
primitives
and
abstractions
on
top
of
kubernetes
to
make
that
happen
in
order
to
first
in
order
to
develop
something,
that's
more
useful
to
the
community
and
build
an
abstraction.
On
top
of
it,
though,
like
I
think
it's
a
great
idea,
it's
just
it's
a
high.
A
It's
a
very
high
level
of
effort,
so
I
mean
you,
you
need
to
get
people
invested
in
contributing
to
something
and
it
would
probably
be
outside
the
scope
of
kubernetes
proper
right
like
if
you
want
cig
apps
to
host
I.
Could
I
could
be
all
all
behind
that,
but
it's
a
matter
of
like
actually
getting
developers
to
spin
something
up
and
build
something
and
then
test
it
and
then
before
it's
actually
like
primetime.
C
We
can
help
that
growth
leading,
doesn't
mean
owning
and
controlling,
leading
means
and
nailing
and
encouraging
building
up
others
to
do
this.
It's
the
ecosystem
around
kubernetes
that
needs
this.
So
how
do
we
encourage
and
enable
and
get
them
excited,
because
so
often
they're
told
not
to
in
fact,
there's
been
public
statements?
C
There
have
been
long
discussions
on
Twitter
and
in
other
venues
where
people
saying
no
every
developer
should
learn
all
the
complexities
of
kubernetes
and
they're
being
told
not
to
do
this,
and
people
right
now
are
being
discouraged
from
doing
this,
and
there
have
been
debates
about
discouraging
that.
So
how
do
we
encourage.
G
People
to
do
this
and
so
I'm
expecting
our
timeline
to
be
something
like
the
storage
cig
storage
in
the
beginning
was
absolutely
miserable.
There
is
very
few
plugins,
but
the
storage
stick
just
kind
of
actually
started
talking
about
it.
Making
standards
around
it,
putting
some
code
in
to
get
things
to
work
properly
and
I
would
imagine
that
would
be
kind
of
what
we
would
do
around
app
development
right
like
and
over
time.
C
I
make
two
suggestions
now:
I
want
to
do
a
time
check
because
we're
six
minutes
over
I
don't
want
to
be
respectful,
because
people
are
dropping
off.
They've
got
to
go
to
other
meetings,
so
the
only
thing
I
would
ask
is
if
we
could
wrap
up
this
discussion
and
move
it
into
future
discussions,
the
next
of
which
would
be
four
weeks
out
because,
where
every
other
week
and
we're
not
meeting
in
two
weeks.
G
A
G
G
So,
like
I
tried
that
at
Red
Hat
with
that
odio
thing,
where
I
put
together
a
spec
and
then
we
started
working
and
then
for
various
reasons
it
it
I
mean
it's
happened,
but
it's
happened
to
varying
degrees,
I,
don't
understa,
and
nor
do
I
think
I
should
become
a
go
developer.
That
is
not
where
I
make
my
and
I
don't
think.
I
should
actually
be
a
core
person
on
kubernetes,
but
I.
G
D
One
small
comment
I
have
is
like
as
part
of
sick
architecture,
I'm
leading
a
group
which
is
doing
tech,
death
research
for
kubernetes,
and
we
are
basically
looking
at
issues
PRS
or
or
discussions
which
basically
can
help
reduce
tech
debt
in
Gore
to
burn
at
ease.
So
if
you
think
there
are
things
related
to
usability,
that
would
basically
require
features
or
anything
that
we
can
do
in
the
goal.
A
And
make
if
there's
things
that
we
can
do
for
the
workloads
API
to
make
them
more
consumable?
That's
always
feedback
we'd
like
to
have
to
you,
but
Matt,
like
you,
said
time
check
for
like
eight
minutes
over
so
I
strap
it
up
for
today
we're
going
to
miss
the
next
meeting
because
of
Kubek
on
so
we'll
see
you
in
four
weeks
time
thanks
everybody
thanks
everyone
for
such
a
great.