►
From YouTube: SIG Apps' meeting 20210209
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
Okay,
welcome
everyone
to
cigarettes.
Today
is
the
eighth
of
february.
My
name
is
athan,
abdullah
and
I'll
be
leading
us
today.
Actually
an
announcement
to
kick
us
off
is
that
actually
this
will
be
my
last
meeting
that
I'll
be
leading
as
a
co-chair
of
sea
gaps.
A
A
A
All
right
so
jumping
into
the
first
discussion
here:
where
should
new
contributors
to
the
workflows
controllers,
get
started.
A
So
I
know
this
is
a
question
that
that
tends
to
come
up
fairly
often
with
new
contributors.
Is
there
something
that
we
can
do
better
to
make.
C
It
more
clear
where
people
can
get
started
so
so
this
is
matt
farina,
I'm
the
one
who
raised
this
question
and
the
reason
I
raised
it
is
since
our
last
meeting
I've
had
multiple
people
hit
me
up
in
slack
in
just
a
direct
message
and
ask
that
question.
How
do
I
get
started?
I
want
to
contribute
code
and
I
was
looking
for
a
way
to
give
them
something.
C
That's
documented
well
a
place
to
get
started
just
to
point
them
in
the
right
direction
and
we
have
a
contributing
guide
over
on
the
community
repo
which
is
in
dire
need
of
some
love.
It's
not
in
good
shape
and
doesn't
give
good
direction,
and
so
I
figured
I
wanted
to
ask
the
question
here
to
see
what
people
had
to
say,
and
these
would
be
people
who
are
just
generally
new
contributors.
C
A
Thanks
matt:
are
there
any
newer
contributors
on
the
call
who
have
recently
gone
through
this
and
have
some
paints
to
share.
D
I'm
a
recently
new
contributor
not
not
to
kubernetes
but
to
see
gaps,
and
I
what
I
would
suggest
to
newer
contributors
is
to
start
with
unit
tests
and
perhaps
even
integration
tests.
I've
noticed
our
code
coverage
can
be
improved
a
lot,
so
those
are
changes
that
should
be
welcome.
D
And
then
there
is
bigger
kubernetes
issues.
I
mean
issues
are
across
the
across
the
whole
project,
such
as
structure,
structure,
logging.
We
are
migrating
to
k
log
v2,
so
those
projects
can
be.
Those
changes
can
be
done
as
well,
but
the
my
question
to
to
the
rest
of
the
team
would
be
what's
the
best
way
to
get
reviews.
Yeah
do
do
we
have
a
system
for
that.
D
Right,
yes,
at
least
in
my
experience,
it's
been
hard
to
get
reviews.
I
understand
that
people
are
busy,
but
if
there
is
some
yeah,
what's
the
best
approach
to
being
slack
or
or
if
there's
like
a
round-robin
reviews.
D
That's
that's
the
question.
B
So
much
is
here
four.
There
are
two
topics,
two
questions
being
brought
up
to
answer
the
later.
With
regards
to
reviews,
I
personally
prefer
when
people
reach
out
to
me
directly.
I
know
that
it's
sometimes
a
little
bit
tricky
and
it
takes
a
little
bit
more
time
like,
for
example,
the
past
two
three
weeks.
B
Ninety
percent
of
my
time
was
spent
on
reviewing
caps
and
I
was
pushing
the
majority
of
the
the
remaining
reviews
to
this
week
and
and
the
remaining
ones,
but
I
think
that
probably
the
direct
either
direct
messages
or
on
the
sig
apps
and
people
will
pick
up.
The
other
thing
is,
it
is
tricky
and
I'll
probably
slowly
refer
to
the
first
question.
It
is
tricky
to
to
know
all
the
controllers,
like
the
tip
of
your
finger.
B
And
there
are
there's
usually
people
that
own
certain
parts
of
the
controllers,
only
a
handful
of
people
can
easily
dive
into
into
pretty
much
every
single
controller,
and
probably
just
reaching
out
to
a
particular
expert
of
an
area,
is
the
best
option.
E
I
would,
I
would
add
that
I
think
I
guess
my
question
would
be
to
people
who
want
to
contribute.
What
is
the
goal
of
your
contribution
right,
like
I
think
there
are
different
paths
forward
like
we've
been
successful
when
people
have
had
specific
needs
either
for
their
particular
business
that
they
work
for
for
the
community
in
general,
where
they
were
interested
in
diving
somewhat
deeply
into
a
topic
and
into
a
controller,
even
if
the
time
horizon
was
particularly
long
in
order
to
contribute
there
to
achieve
a
specific
outcome.
E
Examples
could
be
some
of
the
stuff
that
my
jack
has
done
with
staples
at
aldo
some
of
the
contributions
you're
making.
So
when
people
are
interested
in
doing
something
specific
because
there's
a
goal
in
mind,
I
think
it's
easier
for
us
to
collaborate
and
help
them
shepherd
it
forward.
E
Even
though
we
can
still
probably
optimize
our
organization
if
you're
looking
to
make
general
contributions
to
kubernetes
core,
the
the
workloads
controllers,
in
particular
might
not
be
like
the
best
place
to
get.
Your
initial
commits
aldo
did
call
out
some
good
ones
with
respect
to
things
that
you
like
unit
tests
are
always
welcome.
If
you
want
to
try
to
help
shape
up
performance
testing,
definitely
welcome
so
tests
are
always
welcome
documentation.
E
Improvements
are
always
welcome.
Website.
Improvements
are
always
welcome,
but
we're
talking
about
apis
that
have
been
v1
and
that
are
complicated
and
utilized
by
most
customers
that
touch
the
platform.
So
we
have
to
be
somewhat
risk-averse
in
terms
of
what
we
take
in
and
we
have
to
be
careful
and
it
does
require
kind
of
a
non-trivial
like
starter
mode
of
expertise.
In
order
to
be
able
to,
you
know,
make
really
sweeping
contributions
like
most
contributions
to
the
workloads
controllers,
because
they're
v1
are
probably
going
to
start
with
a
cap
right.
E
So
you
know
if
there's
functionality
that
people
are
looking
to
add
because
they
have
a
need.
We
can
help
with
shaping
that
cap
and
helping
get
that
kept
through
and
then
helping
the
contribution
go
through.
But
if
it's
more
like,
I
want
to
start
contributing
to
kubernetes,
and
I
want
to
get
my
first
initial
commits
in
then
I
would
go
back
to
what
aldo
said
earlier.
They're
they're,
probably
like
small
good
first
issues,
but
they're,
not
that
many
of
them-
and
you
know
it
might
not
be
like
for
many
contributors
that
come
to
the
project.
E
I
think
the
initial
commits
that
I
see
them
do
that
I've
seen
them
do
over
time.
They'll
start
with
like
features
in
the
cli
or
minor
api
things,
and
then
from
there
get
deeper
and
deeper
in
they
generally
don't
start
with
things
like
scheduling
or
controllers
and
or
like
deep
into
the
api
machinery
or
core
networking
unless
they
have
specific
features
that
they're
looking
to
add
in
those
domains.
B
The
baggage
of
the
initial
knowledge
is
pretty
big,
I'm
pretty
sure
that
we
could
work
on.
B
Maybe
tagging
some
of
the
good,
first-time
issues
and
probably
tests
are
a
good
one.
We
have
ryan
on
the
call-
and
we've
been
talking
about
this
topic
for
for
quite
a
while,
and
I'm
pretty
sure
that
adding
or
changing
one
of
the
pre-existing
tests
and
promoting
them
to
conformance
is
a
good
way
for
someone
to
dive
into
how
the
controller
works
and
and
provide
that
contributions.
B
E
B
I
do
hope
that
the
majority
of
our
controllers
were
written
in
such
way
that
the
critical
pieces
are
highly
tested,
with,
with
probably
going
down
a
little
bit
more
over
time,
but
just
running
locally
and
trying
to
figure
out
what
could
be
the
most
critical
pieces
and
comparing
that
with
coverage
reports
would
be.
What
was
my
my
suggestion.
E
The
coverage
reports
last
time
I
ran
them
weren't
terrible
the
way,
especially
with
going
the
way
the
controllers
are
written.
Achieving
very
high
coverage
like
say
above
70
80
percent,
might
be
difficult
but
possible.
If
that's
what
we're
looking
to
do,
though,
it's
not
clear
to
me
that
in
all
cases,
achieving
high
code
coverage
guarantees
that
your
code
is
bug
free,
and
I
could
point
to
literature
that
kind
of
says:
that's
not
necessarily
the
case.
I
I
would
say
that
one
thing
that
we
do
have
that
might
make
contributing
slightly
more
difficult.
E
Is
that
the
way
the
unit
tests
have
evolved
over
time?
It's
very
it's
been
very
much
feature
based
right,
like
we
have
unit
tests
that
have
been
there
since
forever
and
that
haven't
been
refactored
and
then,
as
new
features
have
been
added
to
each
controller
and
as
the
api
versions
have
evolved,
we've
added
added
kind
of
layers
of
unit
testing
on
top
of
it,
but
we
haven't
gone
back
and
really
like
comprehensively
refactored
the
unit
tests.
E
In
order
to
do
something
that's
like
to
make
it
more,
I
guess
comprehensible
and
more
easily
digestible.
So
I
mean
that.
Would
be
the
only
thing
I
would
say
there,
though,
is
the
scope
of
doing
that
would
be
like
somebody
with
like
a
a
really
good
qa
background
who's
super
interested
in
in
testing.
E
D
Something
easy
I've
noticed
around
that
a
lot
of
our
tests
are
old,
so
they
have
not
been
written
with
te.ran
and
whenever
you
do
a
new
feature
that
it's
very
useful
to
have
those
in
place
already.
So
you
can
filter
your
your
subtests
so
that
kind
of
refactoring
making
making
those
changes.
I
think
it
will
be
very
useful
for
the
future.
B
While
I
was
recently
entering
the
segaps
space,
I
was
helping
him
to
kick
off
the
crown
job
controller.
I
know
that
he
wants
to
share
his
thoughts
as
well.
F
Yeah,
I
think
I
like
to
check
in
some
of
the
thoughts
that
have
been
raised
here.
It
is
important
to
come
in
with
a
specific
goal.
Certainly
in
my
example,
my
I
had
a
lot
of
idea
that
I
would
want
to
help
with
crown
jobs,
api
and
the
controller
so
and
then
again,
second
thing
is
point
that
he
raised
earlier
that
once
you
have
that
goal
in
mind,
you
can
find
out
people
who
are
like
who
can
guide
you
with
that
controller.
So
for
me
he
was
not
just
helped
me
a
lot.
F
I
think
one
one
point
that
I
want
to
raise.
That
was
harder
for
me
at
least
to
get
started
is
that
it
is.
I
couldn't
find
an
easy
way
to
start.
The
controllers
on
a
local
machine
to
test
certainly
needed
a
little
hand
holding
to
get
me
started
there.
F
F
I
think
heading
documentation
would
really
help.
Yes,
like
not.
We
don't
need
to
have
like
polish
documentation,
but
maybe
some
hacking
guide
or
something
like
that.
That
would
help
developers
to
get
local
environment
started.
Maybe
that
would.
F
F
And,
and
also
regarding
the
unit
testing,
I
think
someone
raised
the
point
that
our
unit
tests
evolved
over
time
and
yeah.
I
think
I
certainly
see
that
the
case
in
current
controller,
that
is,
the
tests.
F
The
pattern
of
test
being
used
was
fairly
old
and
I
think,
with
the
even
with
the
new
controller,
it's
the
same
pattern,
because
we
didn't
get
time
to
refactor.
All
of
that,
so
it
might
take
some
time
or
it
might
take
at
least
a
good
amount
of
learning
code
to
dig
into
that
pattern
and
get
started
with
newcomers.
F
So
I
I'm
not
sure
like
it.
It
might
be
a
controller
to
control
our
case
by
case
basis
of
how
hard
or
easy
it
would
be
to
get
started,
at
least
in
the
current
upcase.
It
was
a
little
consuming
and
I
needed
some
sort
of
help
to
drop
that
so
yeah.
That
is
my
journey.
A
B
Maybe
that's
something
that
we
could
cover
during
the
upcoming
cube
cons
cigarette
session,
maybe
some
kind
of
a
hacking
how
to
hack
on
a
controller
type
of
a
demo
and
and
then
we
could
probably
reuse
that
one
as
a
pointer
to
newcomers.
H
A
You
looks
like
we
are
in
regarding
the
testing.
You
said
the
conformance
folks
have
some
tools
around
that.
I
Yes,
I
am
from
a
company
called
ii
iii,
we
are
contracted
to
make
conformance
happen
and
we
developed
quite
a
few
tools.
The
difficult
thing
is
when
you're
writing
conformance
test
to
determine
whether
you're
actually
hitting
the
end
points
or
not,
and
we
developed
quite
a
few
tools.
I
You
you're
all
probably
already
familiar
with
the
api
snip
web
page,
which
shows
you
which
endpoints
are
conformant
to
which
not
and
with
api
snoop
comes
snoop
db,
which
you
can
install
locally
on
a
client
cluster,
and
you
can
actually
run
snoop
db
against
any
go
test
that
you
might
write
and
see
whether
you
are
touching
an
endpoint.
So
basically
clear.
All
your
events
run
your
test,
use
snoop
db
and
you
can
actually
look
back
and
see
which
endpoint
was
hit.
So
if
there's
anybody
interested
in
conformance
testing
or
just
e3.
J
I
G
G
Okay
moving
on
here.
A
Is
updates
on
some
working
flights,
so
we
have
the
crown
job.
A
B
The
crown
jobs
are
are
in
place.
I'm
in
sync,
with
with
ally
ally,
already,
has
some
fixes
for
the
for
the
old
controller,
I'm
currently
working
on
changing
the
the
feature
gate
to
default
and
I'll
be
in
the
next
one
up
is
to
get
the
api
for
cron
jobs
to
v1,
which
will
be
happening
later
this
week.
B
A
The
audio
is
a
little
difficult
to
hear
modern,
but
I
think
you
said
these:
these
caps,
the
the
campus
inversion.
These
pls
are
just
implementing
the
changes.
Yeah.
That's
what
I
understand:
yeah
yeah.
K
A
I
What
we've
done
is
to
help
track
where
we're
going
with
conformance.
We
opened
an
umbrella
issue
and
basically,
in
there
it's
just
a
summary
of
things
that
we
shared
in
google
files
and
just
get
it
formally
into
the
into
the
repo,
and
I
basically
divided
it
into
different
endpoint
groups
showing
what's
tested
and
what's
not
tested
diamond
set.
We
are
working
on
at
the
moment
there
was.
I
We
have
a
working
test,
but
it's
not
touching
status
and
we
got
some
very
good
feedback
from
the
conformance
meeting
this
week
about
the
ways
data
should
be
tested
because
there's
a
bit
of
controversy
about
status
for
all
endpoints
across
kubernetes,
and
there
was
a
lot
of
discussion
about
that.
So
we'll
probably
get
that
in.
I
The
next
week
then
stateful
set
there
is
for
the
batch
of
the
stateful
set
scale.
There's
one
test
that
just
needs
to
review
and
approve
that
can
go
in
so
we'll
touch
that
and
then
the
scale
test
is
very.
J
I
I
The
moment
for
the
rest,
everybody
that's
interested
in
getting
involved
with
e3
is
test,
writing
or
conformance
stage
writing.
This
is
a.
I
Have
any
tests
there
is
in
the
previous
meeting?
I
did
mention
that
I'll
get
back
about
what
has
this
that
could
be
promoted,
which
already
have
valid
e2e
test.
That
is
touching
the
end
point
and
it
does
come
up
in
the
water
logs,
but
there's
actually
only
one
end
point
that
have
that
if
you
look
at
it,
let
me
just
see,
I
think
the
last
hyperlink
in
that
right
at
the
bottom
is
this
status.
If
you
click
on
that
hyperlink,
it
will
show
you
I'm
just
waiting
for
it
to
come
up.
I
J
I
So
that's
actually
the
only
existing
test
that
is
tested,
but
not
conformance
tested
that
could
be
promoted,
but
as
it's
just
a
driveway,
it's
not
valid.
So
actually
everything
on
the
left-hand
side.
You
see
there
in
basically
white
over
them
with
a
mouse,
you'll
see
there's
the
other
enthusiast
endpoints
and
those
are
all
that's
in
that
radar
issue.
So
we
opened
this
and
if
there's
any
questions,
please
reach
out,
let
us
give
you
information
and
help.
You
share
our
tools
and
we
really
like
to
to
help
we're
doing
all
we
can
from
our
side.
I
And
even
you
are
planning
to
to
get
a
kept
in
with
new
apis
that
should
have
conformance
tests.
Even
when
you
get
to
the
point
where
you
want
to
touch
test,
those
please
reach
out,
we
can
help.
You
show
you
about
around
how
apis
you
work
and
what
it
does
to
be.
I
The
test
it's
actually
going
to
show
up,
as
conformance
once
forward,
once
you're
done,
because
part
of
the
cncf
requirements
is
actually
nothing
is
allowed
to
go
to
ga
and
be
merged
in
at
the
end
of
the
release,
unless
it's
got
performance
tests
for
all
new
endpoints
coming
to
ga.
So
we
we
would
like
to
help
you
and
keep
in
mind
that
test
freeze
is
in
24
march.
I
J
I
I'm
probably
preaching
to
to
the
wrong
people.
You
probably
know
all
this,
so
your
pr
must
be
merged
and
in
on
the
test
grid
two
weeks
before
test
freeze,
so
we
can
actually
create
the
conformance
vr
to
get
it
into
conformance.
So
it's
actually.
The
timeline
is
quite
tight
to
get
it
in
in
121.
Just
just
as
a
note.
A
That's
good
to
know,
thank
you
yeah.
If
anyone
is
interested
in
helping
out
with
some
of
these
performance
tests,
it'd
be
great
if
you
could
check
out
this
issue
and
get
involved.
Thank
you,
rihanna.
Are
you
the
right
person
to
reach
out
to
people
questions
around
how
to.
I
Yes,
you're
welcome
to
reach
out
is
probably
most
people
in
the
community
know:
hippy,
okay,
he's
the
master.
He
he
would
probably
drive
people
around.
Then
we've
got
stephen
caleb.
We've
got
a
few
test
writers.
I
am
more
the
project
manager
looking
after
things,
so
I
I
am
not
the
primary
code.
I
G
A
A
K
A
C
F
E
E
A
J
B
I
think
what
they
I
think
I
might
have
some
idea
what
they
mean
it
looks
like
they
are,
creating
they
hit
a
wall
because
of
quota,
and
then,
when
one
of
the
terminating
previous
replicasets
actually
goes
down,
they
would
want
to
see
immediate
creation.
But
since
we
previously
started-
and
we
got
into
the
loop
of
exponential
back
off-
there's
no
turning
back
and
they
think
that,
because.
B
There
is
a
spot,
we
should
create
a
new
controller
instantly,
but
they
just
hit
the
exponential
back
off
and
they
hit
it
a
sufficiently
amount
of
time
that
we
are
towards
top
of
the
the
spectrum
of
the
back
off,
which
means
every
next
retry
is
happening,
every
significant
amount
of
time.
I
think
the
max
might
be
the
16
minutes
that
they're
talking
about
no,
I
actually
think
the
max
is.
I
E
Sounds
like
what's
happening,
but
the
thing
that
I
think
is
interesting
to
me
is
like.
Maybe
we
should
at
least
consider
the
ability
to
configure
the
exponential
back
off
parameters
because,
like
my
trivial
answer
to
this
person
is
like
increase.
Your
quota
like
you,
need
to
have
a
little
bit
more
headroom
and
you
won't
have
a
bad
time
like
right
now.
E
It
seems
like
they're,
very
tight
to
capacity
and
they're
only
able
to
redeploy
their
rep
their
their
new
replicas
in
the
event
that
they
kill
off
some
old
ones,
because
they
very
very
tightly
pack
their
cluster,
which
is
something
we
don't
advise
that
you
do
so
like.
There's
the
issue
of
here's,
how
you
can
have
a
better
time,
but
it's
worth
at
least
maybe
talking
about
whether
we
should
have
some
ability
to
override
the
exponential
back
off
parameters
and
like
we
might
actually
have
exposed
that
already.
I'm
not
sure
that
we
have,
though,.
B
Yeah,
but
even
if
you
end
up
in
the
same
situation
and
the
back
off
is
configurable,
you
will
eventually
hit
the
max
for
the
exponential
back
off.
E
It's
a
foot
guide.
Yes,
it's
a
foot
gun
for
sure.
Yes,
the
question
would
be
like.
If
we
did
it,
I
mean
it's
a
football,
but
it's
one,
that's
hidden
in
a
closet
right
like
I,
don't
think
anybody,
only
people
that
would
really
want
to
tweak
it
would
probably
touch
it
like.
I
don't
think
it
would
be
a
feature
that
you
would
expose
like,
oh
and
by
the
way
here
is
a
really
great
tunable
for
you
to
use,
but
it
might
be.
Maybe
it
wasn't
at
least
we're
thinking
about
it.
B
But
yeah
I
would,
I
would
commend
with
regards
to
probably
the
room,
there's
also
the
ability
to
remove
the
old
replica
set,
the.
I
can't
remember
the
exact
name,
the
history
parameters
which
by
default
are,
I
can't
remember
if
we
set
it
to
more
than
one
three
or
six,
something
like
that
that
sits
in
my
head.
Maybe
he
can
tweak
it
to
something
smaller
this
way
he
won't
be
having
too
many
old
replicas
sitting
around
if
he
wants
to
have
tightly
packed.
B
A
Later,
okay
need
to
keep
the
application
running
required
to
resolve
the
entire
pod.
Instead
of
just
a.
E
Container,
I
don't
know
why
this
is
us.
G
E
I
think
because
if
this
does
progress
forward,
there
are
probably
are
implications
for
controllers,
even
though,
like
I
mean
so
like,
let's
say
you
add
a
third
pod
lifecycle
or
another
bicycle
for
job
for
all
the
batch
workloads
and
all
the
stateless
serving
workloads
we're
still
going
to
have
a
default
that,
basically,
you
can't
change
right,
like
deployment's
always
going
to
be
set
to
always,
if
there's
another
request
to
have
that
to
be
configurable,
we
need.
We
should
be
aware.
B
Yeah,
there's
a
link
pr
that
basically
allows
setting
restart
policy
to
never,
but
that's
only
for
replicas.
Surprisingly,.
B
J
B
Yeah,
that's
bad.
We
there's
this
on
land,
not
without
a
discussion.
E
B
B
It
might
have
some
weird
fallouts
that
one
might
not
necessarily
expect.
E
B
Yep,
that's
that's
what
I
said
there.
I
put
a
hole
in
there.
Thankfully
it's
it's
from
some
from
someone
for
outside,
so
it's
not
testable
by
default,
but
then
there's
additionally,
my
hold
so.
K
G
E
When
you
change
the
number
of
replicas
you're
scaling
the
deployment
you're,
not
modifying
the
deployment
in
place.
So
definitely,
if,
like
let's
say,
you
updated
the
resource
requirements
for
or
limits
for,
one
of
the
containers
or
labels
or
something
like
that
with
a
pause
deployment.
You
shouldn't
get
a
new
role
out,
but
I'm
not
sure
what
the
intended
the
original
intended
behavior
of
simultaneously
scaling
a
pause
deployment
was
supposed
to
be
or
if
we
ever
communicated
the
official
like
something
official
about
those
semantics.
H
E
B
Before
eventually,
jumping
into
any
conclusion
or
fixing,
because
I've
noticed
there's
a
pr
already
open
to
solve
this,
we
should
consider
whether
anyone
is
actually
relying
on
that
behavior,
because
I'm
pretty
sure
that
if
we,
for
example,
decide
that,
oh,
if
it's
paused
nothing
should
be
happening.
E
Well,
in
particular,
the
reason
I
was
saying
we
should
definitely
investigate
what
we
say
we
were
going
to
do
is
because
I
can
see
a
use
case
where,
like
you,
pause
the
deployment
in
order
to
stop
the
roll
out
of
some
modification,
but
all
of
a
sudden,
you
need
extra
capacity
in
order
to
keep
something
up,
so
you
scale
it
up
in
if
I'm
scaling
up
a
deployment,
so
I
have
a
deployment
inflate
it's
going
badly.
I
pause
it
because
it's
going
badly,
but
I
need
extra
capacity.
E
If
I
up
a
number
of
replicas,
I
want
the
previous
image
in
my
scale.
Up
like
this
is
the
behavior.
I
would
want
to
remediate
a
lack
of
capacity
in
production
during
a
failed
rollout,
so
I
like,
I
would
not
want
to
change
it,
but
my
question
is
like:
is
there
a
reason
why
the
user
expects
something
different?
E
E
Like
so,
if
you
have
image
a
and
you
raw
image
b,
image
b
hits
infant
mortality.
It's
dying,
so
you
pause
the
roll
out
to
stop
rolling
out
more
instances
of
image
b.
But
now
you
don't
have
enough
image
a
to
serve
the
qps,
that's
ingressing
to
your
cluster,
so
you
up
the
replication
you
in
in
thinking
about
what
I
would
want
in
that
in
that
instance,
I
would
want
more
of
image
a
to
roll
back
out.
So
I
have
enough
capacity
to
get
right
before
I
deal
with.
E
So
I'd
be,
I
would
be
hesitant
to
change
it,
but
I
would
like
to
at
least
see
what
what
did
we
in
the
docs
tell
people
the
behavior
should
be
with
respect
to
scale
versus
pausing,
like
you
know,
rolling
out
the
declared
desired
state
of
the
actual
pod.
B
B
I
know
that
we
have
a
separate
endpoint
that
is
designed
just
to
express
the
scale,
but
for
controller
there's,
no
difference
if
somebody
called
a
scale
or
directly
modified
the
replicas.
B
And
with
that,
I
would
probably
treat
a
scale
similarly
to
any
update.
G
D
Yes,
that's
me:
I'm
trying
to
initiate
a
cap
on
next
next
release,
but
yeah.
This
is
to
other
feedback.
G
Okay,
great,
I
think
that's
all
we
have
time
for
today,
yeah
thanks
everyone
for
joining
and
see
you
all
in
two
weeks.