►
From YouTube: Kubernetes SIG Apps 20190401
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
And
if
we
like
to
start
with,
this
is
actually
as
Pyrus
talking
first,
but
we
only
have
a
couple
of
things
in
the
workloads
and
I
want
to
talk
about
those
first,
just
because
it
should
be
relatively
fast.
We
can
have
more
discussion
after
Paris
does
the
mentoring,
but
in
case
anyone
just
wanted
to
be
able
to
drop
off
real
quick
after
we
did.
That
and
just
gonna
give
a
brief
one.
A
So
two
things
the
max
unavailable
for
staple
set
merged,
but
it
probably
still
needs
a
bit
of
work
to
go
to
implementable,
but
it's
approved
emerged
and
then
there's
a
kept
open
for
taking
pod
disruption.
Budget
to
GA
I'd
have
some
feedback
on
it.
I
think
we're
mostly
there,
but
there
are
a
couple
of
things
that
are.
A
A
little
bit
still
open
so
one
is.
We
have
a
scale
sub
resource
now
and
kind
of
an
open
question
is,
and
this
is
feedback
I'll
leave
on
the
cap
to
do.
We
want
the
pod
disruption
budget
to
be
able
to
interact
with
an
arbitrary
scale
sub
resource
so
that
you
can
apply
pas
disruption
budgets
to
see.
Are
these,
for
instance,
right
so
like?
A
If
I
have
my
cluster
app
and
my
clustered
app
implements
a
custom
scale,
sub
resource
I'd
like
to
be
able
to
probably
apply
a
disruption
budget
to
that,
then
the
other
thing
is
the
many
available
percentage
was
kind
of.
So
we
added
max
unavailable
to
pot
disruption
budget
because
it
was
more
clear
exactly
what
you'd
be
expressing
there
and
the
intention
was
to
remove
min
available.
A
But
it's
not
really
clear
to
me
that
people
don't
still
find
that
feature
useful,
so
it'd
be
good
to
get
feedback
from
people
on
whether
you
know
removing
min
available
is
something
we
should
do,
or
we
should
just
keep
the
semantics
where
you
can
specify
either
yeah.
That
was
all
I
had
so
Parris
are
you
here?
I
am.
B
So
since
this
is
a
small
group,
I
actually
think
this
is
even
better
for
me
personally,
because
I
really
want
to
kind
of
start
a
discussion
with
very
large
SIG's,
especially
those
who
have
a
lot
of
sub
projects
or
have
a
lot
of
owners,
files,
etc.
As
we
start
talking
about
things
like
succession
planning
and
how
you
are,
how
you're
helping
folks
have
burnout
and
stuff
like
that,
so
first
things.
First
thanks
for
again
for
having
me
this
is
this
is
awesome.
B
Is
everyone
here,
for
the
most
part
associated
with
an
owner's
file
in
some
respects
on
this
call
right
now,
I
mean
can
obviously
I
know
you
are,
and
then
obviously
I
know
salty
is
as
well
for
CLI
and
stuff
like
that.
What's
that
are
the
rest
of
the
callers,
just
contributors
or
reviewers
approvers
with
make
up
up
this
call.
B
It
just
doesn't
line
up
and
or
even
anybody
has
necessarily
time
to
do
so,
and
we
actually
just
did
a
contributor
experience
survey
last
late
last
year
and
most
of
the
responses
were
overwhelmingly
I.
Just
don't
have
time
to
mentor.
So
we
do
have
tons
of
things
that
we
can
do,
though,
to
feed
the
gaps
and
things
like
that
in
order
to
move
people
throughout
these
again,
I
call
them
career
ladders.
But
you
know
it's
open
source
ladders,
decision-making
ladders,
things
like
that,
but
in
order
to
do
so
we
have
to
do
some
housecleaning.
B
B
B
Obviously
we
have
a
contributor
guide,
one,
that's
in
community
repo
that
covers
most
things,
but
I
know
that
some
of
the
say
Apps
projects
do
have
their
own
contributing
markdown
file.
If
you're
listening
right
now
and
you're
in
a
sub
project,
that
does
not
have
one
think
about
it,
think
about
how
your
your
on-ramps
can
help
with
this.
B
Just
by
being
explicit
as
to
what
folks
need
in
order
to
start
contributing
and
I
say
need
I
mean
like
knowledge
like
basil,
for
instance,
do
people
need
basil
in
order
to
be
in
order
to
be
successful
within
this
sub
project,
for
example,
and
again,
that's
just
an
example:
that's
not
saying
that
they
do
and
then
also
we're
gonna
go
into
creating
roles
in
a
second.
This
is
I.
Consider
this
a
part
of
the
housecleaning,
but
this
is
a
really
good
cool
way
to
scope
out
work
and
I.
B
Guess
I'll
talk
about
that
in
a
second
and
then,
of
course,
the
overly
communicative
start
now
and
I
say
that
by
being
explicit
with
what
you're
looking
for.
So,
if
folks
on
here
know
that
they
have
certain
work
that
needs
to
be
done
or
kept,
that
needs
to
be
done,
advertise
it
on
kubernetes,
dev,
say:
hey!
We're
looking
for
people
to
help
us
out
with
this
thing,
there's
also
a
roll
board
on
discussed
a
kubernetes
io
beat
please
the
explicit
there
that
has
SEO,
that's
caching.
B
So
when
people
are
searching
for
the
web,
that's
not
behind
a
firewall.
So
that's
just
stuff
that
I've
noticed
that
other
parts
of
the
project
do
extremely
well
and
get
a
lot
of
feedback
and
from
it,
for
instance,
I
just
saw
Phil
what
rock
do
one
recently
for
user
group
formation
documentation,
some
more
governance
work
and
he
was
super
explicit
and
had
about
five
people
reach
out
to
him
and
now
he's
forming
a
team
around
this.
B
B
Well,
so
I'm
sure
you
all
are
doing
a
ton
of
different
plaintiff
like
a
lot
of
different
hats
right,
like
I
know,
for
me,
like
I'm,
I'm,
co-chair
and
contributor
experience
and
I
feel
like
I
play
a
lot
of
different
roles
like
all
the
glue
that
the
project
doesn't
necessarily
have
so
I
mean
this
could
be
like
triage.
This
could
be
onboarding
new
contributors.
This
could
be
like
a
project
manager.
This
could
be
whatever.
B
So
right
now
we're
building
a
triage
team,
so
we
will
have
a
triage
captain,
a
PR,
Wrangler
and
then
they'll
rotate
they'll
have
shadows,
it's
very
similar
to
the
release
team,
we're
creating
role
books,
and
this
is
really
a
good
way
to
start
mentoring,
because
they're
gonna
have
shadows
and
we've
seen
with
the
release
team
that
the
way
that
they're
mentoring,
it's
just
natural
based
on
roles
and
the
roles
description
that
we're
defining.
For
that.
B
Excuse
me
I'm,
sorry
and
then
I
wanted
to
bring
up
the
new
contributor
ambassador
team,
because
we
do
have
new
contributors
that
like
join
signe,
teens
and
stuff
I
mean
I,
know
sig
apps
has
that
you
know
you
all
have
that
a
lot?
Why
not
have
like
a
dedicated
monthly
thing
and
you
can
advertise
it
on
the
top
of
your
agenda
that
says,
like
hey
new
contributors,
come
to
this
call
and
then
you'll
have
someone.
That's
you
know
experienced,
doesn't
yeah.
B
It
doesn't
necessarily
need
to
be
a
maintainer,
but
somebody
that
is
also
trying
to
find
ways
to
help
out
with
the
project
and
then,
like
sort
of
that,
gets
up
there
and
help
scoop
out
work.
They
could
do
like
live
issue
triage.
They
could
really
just
dig
into
the
project
in
ways
that
they
need
to
be
like
kind
of
handheld
that
we
don't
necessarily
have
other
avenues
for,
and
this
is
something
that
we're
starting
to
kick
up
in
a
lot
of
other
groups
and
we
haven't
necessarily
gone
forward
with
it.
B
Cool
another
thing
that
we
found
in
contributor
experience
and
just
through
my
travels
and
open
source,
is
that
we
need
to
start
generating
more
contributor
content.
That's
not
necessarily
documentation
inside
of
a
community
folder
and
what
this
means
exactly
I
mean
it
can
mean
anything.
We're
we're
talking
like
this
about
a
subject
and
we
are
recording
it
live
streaming.
It
people
are
consuming
content
in
all
kinds
of
ways.
These
days,
I
guarantee
you
everybody,
that's
on
the
line
right
now
gets
their
content
in
or
prefers
content
in
some
way.
B
That's
not
like
the
other,
and
this
is
really
helpful
because
and
I
like
to
talk
about
this,
because
this
takes
away
a
lot
of
time
burdens
from
normal
one-on-one
mentoring
because
you're
giving
people
what
they
need
and
you're
doing
it
in
a
way
where
you're
already
on
the
thing
anyway,
so
like,
for
instance,
if
you're
doing
a
code
review
right
now
or
tonight
like
and
you're
just
sitting
there
and
you're
just
chilling
like.
Why
not
record
you
and
why
not
talk
it?
B
Why
not
talk
about
it
and
then
you're
gonna
go
through
step
by
step
and
teach
someone?
What's
in
your
brain
and
your
methodology
on
how
you
do
a
code
review,
this
is
so
popular
on
twitch
right
now,
I,
don't
know
if
anybody's
seen
these
but
Leo,
some
people
with
the
Apache
project
do
them,
and
it's
really
really
super
cool
and
we've
done
meet
our
contributors,
which
is
a
once
a
month
like
sort
of
upstream
mentoring
initiative,
but
actually
I
think
I
have
yeah
here
it
is
so
some
of
you
have
actually
been
on
here.
B
Some
of
you
if
Nazis
come
on
as
a
mentor,
if
you
have
not,
but
this
is
just
a
once
a
month
initiative
where
we
get
six
six
of
us
on
from
various
different
parts
of
the
upstream
project,
and
we
answer
questions
from
people
who
are
in
slack
in
a
meter.
Contributors
Channel
right
here
so
like
the
questions,
come
live
and
it
can
be
like.
What's
a
cap,
I
have
no
idea
why
my
test
is
flaking.
B
What
the
heck
is
say,
gaps.
Why
do
I
care
like
anything
above
the
Sun
right,
and
we
even
do
code
based
tours
so
sig
apps,
could
come
and
give
like
some
kind
of
code
based
tour
and
look.
This
has
already
had
this
already
has
900
views
and
we
don't
advertise
as
anywhere
outside
of
contributor
networks.
So
from
just
like
a
time
perspective
alone,
we
feel
like
this
is
pretty
worthwhile
and
something
that
sig
apps
could
definitely
take
advantage
of
with
like
the
many
facets
that
is
sig
apps,
so
especially
like
workloads
API.
B
That
would
be
super
dope
for
you
all
for
you
all
to
do
like
live
code,
live
code,
reviews
stuff
like
that.
So,
like
you
can
do
this
a
couple
of
different
ways
like
so
you
can
employ
contributor
experience
to
help
you
we
can
come
in.
We
can
come
in
and
either
livestream
it.
We
could
record
it
for
you
whatever
or
your
chairs
can
just
feel
empowered
to
do
it
themselves.
B
You
also
have
host
keys
that
you
can
give
out
to
other
people
to
like
record
zooms
yourself
and
then
put
it
on
your
YouTube
playlist
and
then
the
cool
part
is.
We
can
link
this
stuff
from
your
contributing
markdown
files,
so
this
is
more
ways
to
get
other
people
involved
in
your
project
and
again
even
current
contributors.
B
This
is
not
just
necessarily
new
contributors,
people
who
are
contributing
and
other
facets
of
the
project
that
might
be
able
to
help
you
all
get
through
certain
parts
of
any
challenges
that
you're
having
and
then
also
from
a
Content
perspective.
I
did
want
to
mention
contributor
summits
and
make
sure
that
we're
taking
advantage
of
them
to
their
highest
extent.
B
So
if
there
are
parts
to
cig
apps
that
either
need
to
have
a
birds
of
a
feather
or
a
workshop
or
some
kind
of
training
session
like
let's
do
it
contributor
experiences
all
ears
and
I
know
for
Barcelona
I
do
want
to
plug
Barcelona.
We
have
some
space
for
sakes
to
do
face-to-face
meetings
for
like
roughly
30
people,
and
this
would
be
just
your
contributors.
This
would
be
obviously
outside
of
the
intro
and
the
deep
dive.
B
But
if
anybody
is,
you
know
interested
in
that
kind
of
thing
to
where
it
would
just
be
a
close-knit
group
of
your
contributors
that
we
be
working
on
a
problem.
Let
me
know-
and
we
can
get
you
the
space
for
that.
We
have
about
seven
sakes
right
now
that
are
gonna.
Take
advantage
of
that
space
for
contributor,
only
kind
of
meetings,
questions
about
generating
content,
that's
not
documentation.
B
Or
even
why
that's
helpful
I'm
actually
like
just
a
like
kind
of
like
give
a
side.
Note
I'm,
a
part
of
this
professors
of
research
study
at
Oregon,
State,
University,
she's,
doing
some
open
source
work
for
growing
contributors,
and
one
of
the
main
things
that
keeps
coming
up
is
just
the
lack
of
documentation
very
similar
to,
like
you
know,
consumers
and
users,
and
just
the
lack
of
how
to
get
into
the
next
rung.
B
So
it's
very
important
that
we
think
about
ways
on
how
to
do
that.
So
I'm
almost
done
and
then
y'all
can
can
finish
up
the
meeting,
and
we
can
have
like
a
discussion
to
someone.
Here's
I
want
to
ask
you
some
questions.
Another
thing
I
wanted
to
introduce
to
y'all
is
group
mentoring.
This
is
not
something
that
usually
happens
in
open-source.
This
is
definitely
a
concept
that
might
be
new
to
many
of
you,
but
this
is
something
that
we've
tested
and
something
that
also
cluster
lifecycle
does
like
a
little
bit
more
of
an
informal
basis.
B
But
the
important
things
to
take
away
here
is
that
there
is
power
and
peer
mentoring,
like
this
burden
of
mentoring,
doesn't
need
to
necessarily
be
on
just
maintainer
x'.
You
can
get
a
group
of
people
together
and
we
can.
We
have
the
infrastructure
to
do
it.
We've
set
up
the
community
infrastructure
around
this,
but
a
group
of
people
would
get
together
in
a
private
environment,
about
ten
people
with
three
Mentors.
So
that's
like
a
three.
B
It's
like
a
three
to
three
assure
a
she
o
or
she's
a
one,
two,
three
one:
two:
three
ratio,
I
apologize
and
but
everybody's
together
in
this
shared
communication,
space
working
on
shared
goals
and
that
shared
goal
would
be
to
take
somebody
from
likes
a
reviewer
to
approver
and
they're
working
based
off
of
the
community
membership
guidelines,
and
let
me
see
I
think
I
have
do
I.
Have
the
community
membership
guidelines
up,
I,
don't
but
I'm
gonna
do
I'm
gonna
get
to
them
right
now.
B
Community
membership:
yes,
here
we
go
so
these
groups
are
formed
around
these
goals,
like
we
already
have
these
goals
right
now,
and
this
again
is
around
how
we're
creating
trust
and
how
we're
moving
up
the
ladder
based
on
these
trust
roles.
Slowly,
for
instance,
reviewer
we've
said
like
this
person
should
be
a
member
for
at
least
three
months
things
like
that.
B
All
we
have
to
do
is
advertise
to
your
mailing
list,
say:
hey,
we
we
need
more
approvers
and
especially
in
this
certain
area
and
we're
looking
for
a
group
of
people
who
are
currently
reviewers
and
they
all
want
to
be
approvers
and
then
get
everybody
together
and
then
determine
that
in
a
three
month
time
period
that
you're
going
to
give
them
feedback
based
on
base
off
the
reviews
that
they
do
and
also
give
them
guidance.
And
again
this
again.
B
Current
open-source
standards
are
what
on
and
does
anybody
have
any
questions
about
group
mentoring,
a
lot
of
sherry
sharing
my
screen
here,
because
this
is
sort
of
a
new
kind
of
concept.
I
mean
it's
not
necessarily
new.
As
far
as
like
I'm
sure,
everybody
at
some
point
has
been
a
part
of
some
group
where
you've
all
learned
together,
but
this
would
be
you
know
in
a
different
kind
of
a
way
of
getting
I
guess
contributors
into
certain
rungs
of
a
ladder.
B
Why
don't
you
like?
You
can
pin
the
community
membership
document
to
your
meeting
notes.
You
can
talk
about
on
your.
You
know
on
your
meeting,
say:
hey
we're
looking
for
more
approvers
in
this
area.
You
can
talk
about
it
on
the
kubernetes
dev
mailing
list
with
4,000
people.
You
can
talk
about
it
in
the
kubernetes
blog,
tell
a
story
about
how
you're
building
something
and
that
you're
willing
to
mentor
people
in
a
certain
way
and
then,
of
course,
ask
there's
nothing
like
a
survey.
So,
like
the
next
time,
y'all
do
a
survey.
B
There
any
parts
of
the
project
I
mean
I,
say
project
I,
mean
say:
gaps.
Are
there
any
parts
to
say
gaps
that
you
feel
need
attention
like?
Do
you
feel
like
you
need
certain?
Do
you
feel
like
there's
approvers
that
you
need?
Do
you
feel
like
the
owners
file,
people
that
you
have
now
are
currently
actively
engaging
and
getting
other
people
in
owners
files
talk
to
me
about
that
stuff?
Well,.
A
To
take
care
of
there
like,
for
instance,
I
think
caisson
is
still
listed
on
a
project
as
a
project
when
sig
apps
and
as
far
as
I
know
Brian
and
the
hefty
Oh
slash
vmware
guys
are
killing
that
project
all
together.
So
we
need
to
clean
that
up.
I
think
helm
is
now
I
think
we
cleaned
our
stuff
up
with
helm,
respect
to
that
being
a
top
level
for
the
owners
files
in
stay
gaps.
We
should
probably
spread
our
approvers
around
a
little
bit
more.
A
We
could
build
more
reviewers,
I
guess
it's
not
something.
We've
been
trying
to
manage
actively
in
terms
of
growing
contributor
ship.
The
thing
about
it
is
like
with
the
API
is
going
v1
about
a
year
ago
and
with
sig
architecture,
encouraging
heavily
new
contributions
to
be
developed
out
of
tree
using
crts.
A
You
know,
there's
a
limited
amount
of
activity
relative
to
the
early
days
of
the
project.
When
it
was
you,
you
can
code
and
test
something
pretty
fast
entry
and
just
get
it
shipped.
You
know
with
with
the
increase
in
stability,
the
velocity
and
cadence
of
new
features
is
much
lower
and
then,
with
the
kept
process.
That
also
slows
things
down
a
little
bit.
I
think
the
way
I've
been
trying
to
review
or
help
grow
contributor
ship
is
by
people
who
actually
it's
open
source
right.
A
People
generally
contribute
to
open
source
because
they
have
a
need
to
do
something
that
the
software
doesn't
do
and
when
they
find
that
need
I,
try
to
help
them
open
up
a
cap
and
get
the
cap
looked
at.
Get
the
cap
Shepard
forward
act
as
an
approver
for
it
or
find
someone
else
to
collaborate
with
other
SIG's,
where
it's
necessary
and
then
kind
of
help
them
drive
the
process
of
getting
the
cap
through
and
making
the
contribution.
And
what,
if
you.
A
Sorry
go
ahead
me,
that's
how
you
grow
a
contributor
ship
right
like
if
you
have
to
have
a
need.
You
have
to
have
an
idea
Express
that
idea
and
figure
out
how
you're
gonna
get
it
into
the
into
the
repository
and
into
the
tree,
and
then
you
know
we'll
help
you
try
to
make
that
happen.
Assuming
that
you
know
the
idea
that
you've
got
it
we
feel,
like
is
generally
useful
and
we
have
a
you
know,
broad
agreement,
that
this
is
something
we
should
put
in
tree.
What.
B
If
you
did
that
as
like
a
role,
what,
if
what?
If
you
had
someone
like,
either
bi-weekly
or
once
a
month,
that
would
have
a
thing
that
would
have
a
like
a
kept
AMA
like
how
to
get
your
cap
in
say,
gaps
or
something
like
along
those
lines
to
where
you
could
kind
of
scale.
That
and
then
that
would
help
save
like
time
and
energy.
B
A
I
mean
we
just
did
a
review
of
the
new
cap
process
that
cap
process
as
it's
being
evolved.
We've
done
a
couple
of
reviews
of
the
cap
process
and
then
every
week
when
we
do
the
workloads
every
week
or
bi-weekly,
when
we
do
the
workloads
discussion
for
the
ongoing
caps
that
effect
the
workloads
API,
we
discuss
them
here,
current
status
of
them,
and
then
you
asked
for
people
to
take
a
look
to
make
sure
that
the
community's
putting
eyes
and
not
just
the
approvers,
are
putting
eyes
on.
What's
gonna
go
into
tree,
yeah
I'm.
A
You
could
also
believe
what
about
building
some
triage
teams.
I
mean
that
makes
sense.
Our
triage
hasn't
been
that
bad,
though
our
tests
are
mostly
passing
where
we
were
once
one
of
the
most
flaky
and
now
we're
one
of
the
least
flaky
again
because
of
the
cadence
of
oceans
were
not
really
it's
not,
as
you
know
crazy,
as
it
once
was.
If
people
want
to
be
test
maintainer,
as
though
I
mean
like
I'm,
more
than
happy
to
get
more
people
to
spread
that
burden
out
a
little
bit
more
yeah.
B
And
I'm
just
thinking
to
like
it
might
not
be
bad
to
do
the
triage
team
now
that
it's
not
that
now
that
now
that
it's
not
that
crazy
and
then
also
think
about
the
fact
that
these
folks
are
also
gonna,
get
a
purview
and
other
aspects
of
the
project
or
again
sake.
Apps,
but
I,
want
to
say
projects,
big
apps
and
get
and
then
might
be
able
to
start
contributing
heavier
there
too.
So
that's
another
thing
like
with
the
release
team.
B
How
can
we
organize
the
project
in
ways
where,
like
mentorship
just
comes
naturally-
and
it's
not
just
like
you-
know
artificial
right,
just
like
what
you're
doing
with
like
you
know
explaining
Kem's
to
people
but
like
how
can
we
maybe
do
that?
All
iconic
cadence
or
maybe
could
we
do
that
I
was
like.
B
Could
we
do
that
from
a
project
perspective
like
should
we
do
like
a
like
a
Capps
AMA,
every
two
weeks
think
about
stuff,
like
that,
like
I'm,
super
happy
to
to
talk
about
like
how
we
could
do
project
wide
stuff
to
like,
if
you
think
like
hey,
this
is
a
problem
for
apps
and
it's
probably
a
problem
for
others
tell
me,
and
we
can't
think
about
that
sure.
A
I,
just
don't
I
get,
there's
not.
Caps
are
new
enough.
That
I
think
the
people
who
were
actively
involved
with
the
project
are
familiar
with
them.
I
feel
like
it's
like
Pinterest
offered
a
new
cap
recently
and
like
they're
like
what
are
these
things
like
you
know,
if
someone
who's
just
using
the
software
for
the
first
time
or
who's
using
the
software
but
hasn't
contributed
to
it,
decides
they
want
to
make
a
contribution.
A
B
Yep
and
if
you
if
there
is
ever
in
the
case
where
it's
like
hey,
this
company,
wants
to
start
contributing,
I'm,
unsure
and
I,
don't
have
the
time
you
can
always
push
them
to
contributor
experience.
There's
plenty
of
us
that
will
actually
do
like
one-on-one
support,
especially
for
companies
who
aren't
onboarding,
like
you
know
more
than
one
engineer
to
do
something
upstream.
So
we're
here
for
that
as
well.
B
But
that's
it
for
me,
like
I,
said
it
would
be
cool
to
figure
out
from
your
contributor
base
like
what
areas
they
might
want
to
grow
in
so
just
by
asking
so
just
like
sending
an
email
that
says
like
hey,
cuz
everybody,
because
anybody
here
ever
wanted
to
be
a
reviewer
or
an
approver
like
if
so
speak,
now
forever
hold
your
peace,
kind
of
an
email
and,
like
I
said
you'll,
be
surprised.
B
I
bet,
you
there's
quite
a
few
people
that
will
step
up
and
we
can
start
like
either
forming
groups
around
that
or
we
can
start
delivering
content
in
areas
that
they
might
need
it,
but
I'm
happy
to
help
in
any
way.
If
you
have
an
idea,
let
me
know
and
I
you
can
catch
me
on
flack
cool.
Thank
you
yeah.
No,
thank
you.
A
The
only
other
thing
I
wanted
to
add
is
there
is
a
that
cap
I
just
mentioned
from
Pinterest.
They
opened
it
against
the
gaps
and
that
people
want
to
take
a
look
I
added
that
to
the
workloads
discussion
topic
so
as
well.
It's
kind
of
like
a
lower
touch
version
of
pod
replacement,
so
we
don't.
We
don't
really
have
a
way
in
couplet
right
now
of
doing
things
like
modifying
the
the
shape
of
a
container
in
terms
of
resource
limits
and
requests
without
actually
doing
a
full
restart
of
the
pot.