►
From YouTube: Kubernetes SIG Apps 20190715
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
Welcome
to
kubernetes
cig
apps
for
Monday,
July,
15th,
2019
and
we've
got
an
agenda.
I
will
go
ahead
and
paste
it
into
chat
for
everyone
to
see,
and
today
we
have
a
few
topics.
The
first
one
is
the
long
term
fix
for
spurious
rollouts
mutating
admission
controllers
and
I
see
Thomas's
name
next
to
this.
To
get
that
right.
Are
you
here
yeah
all
right?
The
floor
is
yours,.
B
B
Hopefully,
but
basically
we
have
several
workloads
controllers
that
compile
its
template
to
a
puts
back,
which
means
that
when
an
admission
controller
admission,
web
MOOC
actually
modifies
the
put
template
or
basically
any
object,
there
can
be
a
replica
set
in
between
that
has
the
same
issue,
but
usually
it's
with
put
template,
and
if
that
put
template
is
modified
by
the
admission
of
a
book.
Well,
the
controller
doesn't
see
it
and
things
it
didn't
already
create
it
hasn't
already
created.
B
Do
you
put
according
to
the
pulse
back
because
they
don't
match
and
it
goes
into
a
hope.
Loop
usually
I,
think
they
lose
the
issue
for
at
least
deployments
Eriko
demence
it
as
well.
We
added
some
back
up
there
and
much
about
state
facades,
but
probably
this
is
pretty
spread.
It
was
the
code
base,
so
I
was
hoping.
We
can
talk
about
the
options
layout
in
that
dog
and
what
we
can
do
in
the
future.
B
B
C
Yeah,
we
were
trying
really
hard
to
comment
it.
Just
the
technology
wasn't
working
for
us,
oh
so
I
mean
we
think
that,
like
for
staples
and
diamond
set,
because
it
uses
the
revision
based
mechanism,
we
are
somewhat
out
of
the
loop,
but
the
semantics
pair
are
kind
of
like
at
the
end
of
the
day.
Whatever
is
the
output
of
every
controller
that
touches
it
after
staples.
That
creates
the
pie,
that's
about
what
make
staples
that
is
looking
for,
and
the
behavior.
C
Staples
that
are
a
demon
set,
but
if
you
remove
them
from
the
pie,
it's
going
to
destroy
and
recreate
the
pot,
because
it
doesn't
know
that
that
matches
the
current
routine
of
the
demons
that
are
staple.
So
the
differences
deployment
is
the
intermediary
objects,
which
is
the
replica
set
which
is
sort
of
like
a
controller,
a
revision
or
daemon
settings
for
for
deployment,
except
that
the
replicas
second
floor
actually
works
on
it.
So
I
mean
I
think
we
move
it
well.
C
Everyone
should
look
at
the
stuff
that
Janet
already
collected
after
having
some
conversations
with
API
machinery
about
options
where
we
landed
originally,
was
that
we
shouldn't
basically
usually
shouldn't
use
mutating
web
hooks
to
do
injection
to
staple
sets,
demon,
vests
or
replica
sets
or
deployment.
If
you're
going
to
use
a
mutating
web
hook
and
do
something
like
inject,
a
sidecar
I
have
high
security
context.
You
should
out
on
the
high
itself,
as
opposed
to
acting
on
the
intermediary
object,
which
stops
things
from
going
crazy.
C
We
have
a
better
mechanism,
no
sense
and
not
doing
it,
though,
but
if
we
can
add
another
layer
of
protection
to
ensure
robustness
that'd
be
great,
because
we
do
still
see
people
like
I've
seen
people
do
it
with
staple
set
in
such
a
way
that
it
breaks,
but
I,
don't
know
if
that
stole
problem.
I
haven't
seen
that
in
the
least
three
or
four
releases
we've
seen
people
do
it
with
replicas
set
in
such
a
way
that
wedges
Jenna
do
you
know
the
last
time
we
saw
that
actually
happen
in
a
while.
E
Last
time,
I
am
never
seen
it
happening
for
anything
other
than
the
deployment
for
this,
so
I
think
the
big
difference
is
that
and
deployment
compare.
It
smacks
lips
rather
than
the
stretch
by
back,
but
be
measure
and
staples
that
doesn't
compare.
Is
that
with
I
mean
no?
Why
is
mutating
controller
revisions?
That's
why
we
didn't
see
it
dishware,
yeah,
yeah
and
there's
an
so.
We
try
to
tell
people
not
to
mutate
this
back
of
the
the
template.
E
C
B
C
C
B
B
B
B
B
C
C
C
B
C
B
B
Make
sure
depends
on
if
you
do
grow
back
by
actually
using
the
old
replica
set
or
taking
the
old
replica
set
template
and
creating
a
new
replica
set
for
me
and
I,
actually
figure
out
which
one
we
doing
OpenShift
and
which
one
we
do
up
speed,
because
I
think
we
were
different
on
that.
Do
we
always
create
a
new
replica
set
on
rollback
in
upstream,
or
there
was
us.
E
B
C
B
C
C
And
Daniel
yeah
okay,
so
we
had
a
couple
of
people,
think
about
it
and
the
stuff.
That's
in
the
dock
is
basically
what
we
came.
The
conclusions
we
came
to
previously,
but
opening
the
conversation
back
up,
I
think
what
you're
proposing
sounds
more
reasonable,
then
at
least
more
thought
through
and
actually
the
sound
of
there's
a
implementation
and
open
ship
that
uses
something
like
it
for
deployment
comping
anyway,
let's
Alex,
Haley
open
the
cap
off
I
mean
unless
anybody
else
has
better
ideas.
Surely
we
do
not
at
the
moment.
B
C
What
you're
talking
about
doing
is
making
replica
sets
immutable
for
one,
and
there
are
ways
we
can
do
that
to
make
it
an
opt-in
feature
that
preserves
backward
compatibility.
When
you
can
say
like
there
is
an
annotation,
that's
generated
that
makes
it
immutable.
That
would
be
fine,
and
then
you
can
turn
that
off.
If
you
want
it
to
right,
so
that's
one
side
of
it
now
in
terms
of
adding
the
pointers,
we
imagine
story
moves
in
the
status
right
and
Olympian
status.
C
So
if
they're
in
status
and
we're
talking
about
adding
fields,
not
removing
them
according
to
the
laws
of
API
convention,
I
think
we're
okay,
so
I
think
this
is
something
that
can
be
done
in
a
v1
API
without
breaking
backward
compatibility,
but
we
should
get
API
review
on
it
for
sure.
The
other
thing
I
would
say
is
that
when
we
roll
it,
we
can
always
gate
it
with
that
help
of
feature
date,
and
we
can
have
it
turn
the
feature
turn
off
by
default.
B
C
Without
going
to
say
in
terms
of
the
API
and
the
guarantees
we
do
have
over
on
the
behavior
of
deployment,
I
don't
see
this
as
a
braking
modification
I
mean
I
think
it
would
be.
You
should
probably
put
it
down
on
paper
and
take
a
look
at
specifically
what's
being
proposed
just
to
make
ourselves
convinced
you
sure,
but
I
don't
see,
because
I
mean
roll
back
still
functions,
it
still
basically
functions
in
the
same
way.
C
Right
like
there
would
be
some
additional
labels
on
the
status
of
deployment
that
would
control
the
behavior
of
the
Plymouth
controller.
With
respect
to
how
it
like
the
thing
that
would
be
breaking
to
users
would
be
you
can't
wedge
to
your
deployment
controller,
which
is
like
not
feature
right.
Let's
bug
so.
C
We
can
also
put
it
up
this
big
architecture
and,
just
like
you
know
mentioning
a
cig,
architectural
meeting
and
say
hey:
does
anybody
have
any
concerns
about
this
pregame
backward
compatibility,
and
you
know
I,
don't
know
nothing
that
they
will,
but
asking
won't
her
and
just
socializing
it
with
the
rest
of
the
community,
and
we
can
do
that
and
kept
warm
before.
We
actually
like
start
writing
any
of
the
code.
So
we
don't
waste
time,
but
I
don't
anticipate
it.
C
B
Sure
and
I
was
actually
wondering
like
we
really
need
to
make
this
dependent
on
the
replica
set
immutability,
because
right
now
at
this
point
like,
but
you
can't
change
replica
said
because
the
deployment
comes
well
or
modify
Baker
wrong
thing
you
want,
but
it
doesn't
really
affect
how
it
behaves
right
like
you
shouldn't,
go
mutating
up
the
gusset.
If
you
do
it
now
well,
you
have
modified
it.
C
B
B
C
But
that
would
be
the
thing
right.
We
don't
necessarily
run
patches,
but
if,
let's
say
the
user
creates
a
mutating
web
book
that
we
can
protect
it
it's
without
without
immutability,
we
can
protect
it
on
creation.
If
the
user
implements
a
mutiny
web
hook
that
acts
on
update
it
does
injection
there,
you
wouldn't
be
employed
as
running
at
it
here.
B
C
We're
doing
a
rollout
rate,
we
do
update
the
replica
set
just
to
change
the
number
of
replicas
on
the
replica
set
and
a
minimum
and
deployment
right
all
right.
So
I
think
that
when
we
might,
my
concern
would
be
is
if
we
don't
do
the
immutability
and
there's
a
mutating
web
hook,
that
attacks
on
update
and
we
update
the
deployment
to
change
a
number
of
replicas.
We
trigger
that
they're
getting
wet
book
and
we
end
up
in
the
same
pledge
spot.
C
F
B
The
difference
is
we
don't
get
fledged,
because
if
there
is
a
mutating
update
of
a
book
and
it
you
modified
the
replica
set
to
set
annotation
or
anything
and
it
modifies
the
pods
back.
The
only
thing
that
had
is
that
it
will
be.
It
will
change
the
bones,
but
no
new
world
will
happen
in
the
new
implementation
of
what
I
am
proposing.
B
I
was
thinking
to
start
without
the
immutability,
because
I
guess
it's
easier
to
get
consensus
and
you
can
be
added
later
yeah.
Well,
I
was
hoping
we
can
get
one
day,
not
even
an
hour
playing
immutability
and
you
guys
created
with
that
I'm,
not
sure
if
there
is
a
moving
proposal
for
that
or
radical.
It
mentions
in
some
of
our
proposals
before.
A
D
D
To
plate
and
I
think
the
main
thing
he
wanted
us
to
was,
if
I
think
what
I
had
mentioned
in
the
gap
was
that
max
unavailable
won't
apply
to
PMP.
So
part
management
policy,
as
of
today
only
applies
to
scale
up
and
teardown
off
stateful
sets,
and
he
wanted
us
to
take
a
look
at
that
and
see
if
it
makes
sense
for
PMP
to
also
apply
to
max
unavailable,
because
there
is
some
overlap
between
what
max
and
available
in
PMP
does.
So.
D
We
should
take
our
stand
and
say
why
it
should
or
should
not
apply
and
then,
and
it
feels
like
it
should
apply
it.
So
I'll
update
that,
but
I
think
what
I'm
waiting
for
mainly
is
from
at
least
Janet,
or
can
to
look
at
the
choices
that
I
have
put
forward
and
like
suggesting,
which
ones
make
most
sense.
And
why
or
any
other
suggestions
you
guys
have.
C
D
C
So
I
mean
my
one
thing:
is
this:
next
we
have
burst
of
all
right
and
burst,
of
all
kind
of
indicates
that
we
don't
care
about
order.
So
if
I
was
gonna,
do
like
firm
for
introducing
field
Android
update
I,
don't
think
we
ever
really
need
to
do
that
like
if
you
have
a
burst
of
all
staples
set
that
pretty
much
says,
I,
probably
don't
care
about
ordering,
because
I'm
going
to
start
them
up
and
tear
them
down
all
at
the
same
time.
C
So
to
me
that
would
be
the
feel
that
burstable,
in
conjunction
with
a
maximum
available
other
than
something
that's
the
default,
would
indicate
that
you're
willing
to
roll
fast
that
you
don't
care
about
order.
If
we
can
get
that
I
think
that
would
be
valuable.
So,
even
though
three
is
the
moves
complicated
right,
like
that's
for
the
person
who
cares
about
ordering
so
like
I,
look
at
it
is
we're
going
to
do
maximum.
C
C
D
C
Works
will
go
out,
tear
down
scale
up
scale
down.
The
only
thing
it
doesn't
work
for
is
ruining
update
right.
So
if
because
there
is
no
way
to
there
was
no
matching
available.
So
if
you
specify
matching
available
in
conjunction
with
burstable
to
me,
that
would
be
semantics.
That
say:
okay,
I,
really
don't
care
about
worrying
right,
but
I
want
to
be
able
to.
You
know,
kill
more
than
one
at
once.
C
C
Any
like
once,
you
start
killing
more
than
one
it
once
and
some
of
those
like
disabling
the
pods
won't
start
terminating.
You
can't
actually
say
that,
because
things
like
admission
could
start
the
terminating
it's
all
about
that,
what
you
try
to
preserve
Rea,
so,
like
certain
three,
if
you
kill
a
pod
and
you're
no
hot
is
killed
when
you
have
to
replace
it.
C
The
question
is
which
pods
you
try
to
replace
and
then,
when
you
version
you
try
to
replace
it
right,
D,
and
do
you
make
sure
before
you
kill
anymore
eyes,
that
you
replace
the
pot
at
the
correct
version?
That's
the
best
kind
of
semantics
that
you
can
actually
give
so
I.
Think
I
mean
well
I'll,
go
through
and
do
and
give
my
pod
to
give
a
more
formal
review,
but
for
some
immediate
feedback
like
I
would
be
meaning
towards.
C
D
I
think
yeah
go
ahead.
No,
I
was
III
I,
think
I,
agree,
I
mean
like
what
we
would
want
is
like
the
Mavis
implementation
and
we
can
definitely
get
feedback
from
the
community
and
yeah
I.
Don't
want
to
like
put
super
complicated
stuff
right
away.
So
I
think
I'm
with
you
on
that
and
if
we
can
yeah
I
like
why?
Don't
you
put
your
thoughts
there
and
like
does
that
make
sense
like
did?
C
D
C
I
mean
that's,
that's
the
way.
That's
the
way.
I
do
think
it
would
be
the
the
swingingest
be
sure
we
could
implement.
I
mean
like
I,
could
also
give
you
some
feedback
about.
Maybe
what
order
and
you
can
do
it
in
order
to
get
an
MVP
out
the
door
as
soon
as
possible
and
then
add
more
complicated
logic
I
as
you
get
feedback
from
users,
because
I
mean
it
could
be
that
people
who
are
looking,
like
my
general
intuition.
C
Isn't
your
primary
concern
right
if
you
have
something,
that's
very
tolerant
to
disruptions
where
you're
able
to
like
mouth
two
or
three
of
them
over
at
the
same
time,
and
it's
able
to
either
normal
forum
or
do
leader
election
or
whatever
it
needs
to
do
in
Jamaica,
consistent
distributed
system
after
did
knock
them
over
and
after
you've,
not
multiple,
multiple
of
them
over.
It
may
be
that
the
ordering
guarantees
you
don't
care
as
much
about
yeah
I,
think.
F
C
C
If
you
can
tolerate
the
disruption,
but
then
the
question
becomes,
why
are
you
replicating
it?
If
you
can
tolerate
that
much
disruption,
but
if
you're
charting
it
out
for
me
fan-out,
you
probably
don't
want
to
move
any
faster
if
you're
charting
it
out
for
durability,
like
basically
I
need
more
replicas,
because
the
underlying
storage
is
unreliable,
so
I
need
to
spread
it
across
failure
domains.
You
probably
don't
want
to
knock
them
down
any
faster,
so
like
for
stream
processors.
I
can
see
something
like
this
being
valuable.
C
B
D
D
C
A
C
C
Okay,
well,
you've
been
headed
as
a
reviewer,
there's,
not
a
lot
here
yet.
Okay,
do
you
want
to
get
added
as
a
yeah.
F
C
C
F
C
C
C
C
C
C
C
C
Yeah,
try
it
like
their
thing.
They
were
we
to
do
what
he
wants.
I'm
just
trying
to
figure
out
how
we
responsive.
We
need
to
be
in
terms
of
saying:
have
you
considered
using
those
Pat
volumes
or
using
you,
can
even
use
like
a
local
PVC
with
multiple
mouths,
assuming
it
was
rewrite
many
that
would
work,
but
there's
just
so.
There's
yeah,
there's
so
much
wrong
with
like
trying
to
do
with
this.
Guy
wants
to
do
kind
of
hardly
yeah.
I
was
just
assigned
it
and
I'll
go
deal
with
it.
I'll
take.
It
seems.
E
C
It
has
a
say
we
could
just
want
to
do
this
right,
less
company
there's
there's
solutions,
but
the
answer
to
this
is
really
just
going
to
be.
We
can't
do
this
from
an
API
level.
What
you're
asking
is
not
going
to
work,
but
here
I'm
like
at
least
like
to
try
to
give
him
some
pointers
to
things
that
will
help
him
achieve
his
end
goal.
Even
though
we're
not
going
to
implement
this
piece
you're
out,
yeah.
C
So
there
there
are
problems
with
the
way
he
wants
to
use
the
words
primitives
that
affect
the
scheduler
and
a
minimum
rate
means
if
I
have
a
cron
job,
that's
referencing
a
deployment
expect
I'm
getting
his
expectation.
Is
we
get
Co
scheduled
with
the
deployment
so
that
the
pot
of
that
cron
job
can
actually
access
the
storage?
Assuming
that
it's
like
there's
conceptually
a
lot
that
that's
going
on
here
for
what
this
person's
asked
me
so
again,.
B
I,
don't
think
that
is
even
a
higher
level
primitive
for
disease.
From
what
I
see
he's
asking
to
reference
a
story,
that's
pot
local
to
be
shared
between
pots,
which
is
cursing
a
security
boundaries.
It's
cursing
also
the
fact
that
temporary
storage
would
be
shared
across
pots
which
are
on
different
nodes,
possibly
yeah.
C
C
There
isn't
you
bring
up
a
very
good
point
across
these
security
boundaries,
but,
let's,
assuming
that
we
even
can
set
up
our
back
in
such
a
reasonable
way
that
if
the
user
wanted
to
do
this,
even
though
it's
not
super
safe,
we
would
let
them
at
a
technical
level
and
at
a
storage
per
minute
level.
I,
don't
think
it
makes
a
lot
of
sense.
You
renew
the
things
he's
talking
about
doing.
It's
not
probably
not
a
good
idea,
but
it
is
doable.
C
A
And
it
is
a
pragmatic
problem
right.
You
have
an
application
that
has
some
volumes
attached
and
is
doing
things
to
it,
and
then
you
have
a
cron
job
that
wants
to
come
along
and
do
things
you
know.
Maybe
you
upload
images
with
your
through
nap
you're
running
in
a
deployment.
You've
got
a
cron
job
that
comes
along
and
optimizes
the
images
that
haven't
already
been
optimized
so
far
right.
It
only
does
it
periodically
it's
a
dumb
case,
but
you've
got
this
kind
of
use
case
so
being
able
to
access
the
same
volumes
there.
A
C
E
C
E
F
C
Anybody
went
to
decide
it
to
just
like
keep
an
eye
on
it
or
okay.
Okay,
I,
don't
even
work
here,
just
especially
Jordans
already
looking
at
it.
He
already
English
realize
bass.
Players
like
hey
know,
you
guys
are
doing
something.
Well,
if
there's
any
support
that
we
can
give
them,
it
would
be
come
on.
Katinas
come
on
in
here
express
I.
Don't
actually
think
we
have
to
do
anything
either
I
think
going
through
the
update,
I.