►
From YouTube: Kubernetes SIG Apps 20220725
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
Good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are
today
is
july
25th-
and
this
is
another
of
our
bi-weekly
sega
apps
meetings.
My
name
is
mate
and
I'll
be
your
host.
Today,
quick
announcements.
The
code
freeze
is
expected
to
land
round
later
half
of
the
next
week,
depending
on
where
you
are,
in
your
time.
Zone
it'll
be
either
august,
2nd
or
august
3rd
I'll
link
to
the
release
date.
So
you
can
verify
your
exact
timing
and
a
week
later
will
be
a
test
freeze
if
you're
not
familiar
with
the.
A
What
these
two
are
code
freeze
is
all
the
enhancements.
All
the
code.
Changes
have
to
be
merged
by
that
day
of
test
freeze
happening
a
week
later
allows
us
to
submit
only
tests
for
for
a
week
longer
than
code
changes
janet.
A
Do
we
have
any
other
announcements
that
you
are
aware
of
that
I
might
have
missed
no
okay
cool,
so
we
can
jump
to
the
main
topic
of
our
discussion,
phillip,
to
discuss,
adding
the
the
new
available
conditions
to
replicas,
let's
play
faithful,
said
damon
said
and
in
general,
meaning
of
those
various
conditions.
I've
noticed
that
there
was
some
initial
pre-discussion
happening
on
the
mailing
list,
so
if
you
haven't
had
a
chance
to
look
through
that,
it
would
be
good
to
also
read
that
for
a
better
understanding.
B
The
cap
is
targeting
consolidating
the
statuses
or
the
conditions
across
all
the
workloads
we
have,
and
I
would
like
to
keep
it
simple
and
focus.
First
yeah,
it's
across
three
workouts
on
available
condition,
although
the
discussion
in
the
mailing
list
focuses
mostly
on
the
job,
and
if
you
have
time
we
can
get
to
that
as
well.
B
So,
like
the
so,
I
created
the
pr
for
the
replicas
available
condition
and
we
had
a
little
bit
of
discussion
with
danielle
that
the
available
condition,
like
the
meaning
of
the
word,
might
not
be
that
descriptive
for
a
replica
sets
since
there
might
be
like
in
general
use
case.
There
might
be
a
lot
of
replicas
that
are
not
running,
and
so,
if
you
are
familiar
with
the
deployment
available
condition.
B
This
is
this
is
like
the
base
case,
which
we
are
basing
this
off,
but
it's
not
exactly
applicable
for
all
of
the
others.
I
will
explain
why
and
then
we
can
come
up
with
some
solution
so
for
the
replicas.
That's
the
main
problem
is
that
there
might
not
be
all
the
replicas
running
and
for
state
process
and
demonstrates.
B
I
think
the
the
main
problem
is
that
in
deployment,
the
the
replicas
are
equal
and
the
meaning
of
available
might
mean
a
different
thing
in
the
stateful
set
or
demon
set
where
each
replica
is
has
a
special
function
either
that
is
assigned
to
especially
to
a
node
in
case
of
the
demonstrable
or
that
this
has
its
special
pvc,
for
example,
in
stable,
set.
B
Yeah,
I
don't
know,
does
anybody
have
questions
for
this.
B
Yeah,
so
I
guess
the
main
problem
is
in
the
naming.
B
So
there
were
some
suggestions
that
instead,
like
the
main
focus,
is
to
have
like
the
same
names,
meaning
the
same
thing
in
each
workload.
So
the
user
knows
like
what
to
expect
from
each
workload
even
like
without
looking
at
it
at
it.
But
the
problem
is
the
workloads
are
not
the
same.
B
So
that's
why
there
is
an
option
to
use
a
bit
different
names
for
available
like
one
one
thing
could
we
could
have
is
to
detect,
like
that
all
of
the
desired
replicas
are
available
in
replica
set
or
niemann
set
or
stateful
set,
and
have
also
such
and
also
a
possibility
to
have
such
a
condition
as
an.
B
Where
not
all
of
the
replicas
are
available,
and
in
the
case
of
deployment
in
when
we
are
doing
a
new
rollout,
we
have
max
unavailable.
So
this
is
taking
into
account
when
deciding
if
the
available
is
true
or
not.
So
when
we
are
rolling
out,
the
deployment
still
can
be
considered
available.
Even
some
of
its
replicas
are.
A
So,
as
I
understand
the
biggest
issues
that
was
raised
by
daniel
and
the
first
pr,
which
is
the
replica
set
of
label
condition,
api
was
around
the
meaning
of
available
for
replica
set
daniel
claimed
that
it
is
possible
for
replicas
that,
with
huge
number
of
replicas
assigned
to
it
for
such
replicas
that
to
never
get
to
the
available
state
and
rather
be
at.
A
I
don't
know
ninety
percent
of
their
replicas
running
so
assume,
assuming
we
would
have
a
replica
with
a
hundred
parts.
A
Daniel
was
claiming
that
he
had
examples
of
multiple
replicas
such
replica
assets
where
they
would
never
reach
those
100
pots,
but
rather
they
would
be
consistently
averaging
around
90
paths
at
a
time
and
that
by
itself
would
be
sufficient
to
claim
that
the
replica
is-
and
here
he
was
proposing
using
some
kind
of
a
different
term
instead
of
available.
But
rather
I
don't
know
operational
or
something
along
those
lines.
A
A
A
a
way
for
user
to
specify
what
is
the
the
threshold
at
which
we
would
flip
the
switch
from
it's
available
or
it's
not
or
it's
operational
or
it's
not
whether
that
would
be
half
half
of
the
of
the
required
replica
set
plus
one,
which
means
basically
would
be
above
half
or
it's
more
like
it
should
be
hard
to
put
it
around
80
or
90
percent.
A
B
A
That's
something
that
I
was
actually
considering,
because
the
the
problem
as
I'm
seeing
it
currently
is
that
you
are
daniel
claims
that
here's
what
I
found
his
comment
he
was
advocating
not
to
include
available
at
all,
because
that's
rarely
the
case
where,
when
it
happens,
but
to
be
able
to
say
functional
operational
or
something
like
that,
we
would
need
to
know
the
threshold
at
which
the
user
claims
their
replica
set
functional
or
operational.
A
Whatever
the
name
would
be
chosen,
because
I'm
pretty
sure
that,
even
if
we
hard
coded
at
any
given
percentage,
whether
that
will
be
51,
75,
80
or
90
percent
of
pots
available
the
moment
we
introduce
such
functionality,
there
will
be
questions
about.
How
can
I
make
my.
A
A
B
Yeah
so,
like
I
think,
one
issue
with
this
approach,
even
though
it
for
replicas,
it
could
work
great.
I
think
for
customers
like
this,
but
if
we
take
it
in
the
context
of
consolidating
it
across
all
of
the
workloads
and
so
like
the
the
meaning
of
also
the
available
condition,
is
a
bit
different
compared
to
this.
So
in
case
of
other
goals
like
the
deployment,
we
would
be
also
considering
like
introducing
this
condition
as
well.
Here.
A
B
I
I
think
it
just
counts
together,
like
the
available
replicas
with
max
unavailable,
and
I
think
it's
inconsequential
on
the
rollout,
if
I
remember
correctly-
okay
yeah,
but
since
the
max
unavailable
is
a
royal
thing
and
also
like
in
the
case
for
available
and
progressing.
B
And
so
I
guess
we
already
have
the
problem
like
with
progressing,
and
I
guess
to
some
extent,
if
I
available
that
people
are
misunderstanding,
these
two
conditions
that
they
are
tight
to
get
together
with
roll
up
so
yeah.
A
Yeah
I'm
curious
if
we
would
go
with
operational,
functional
in
case
of
a
replica
asset,
then
what
it
would
mean
for
our
deployment
to
be
operational,
would
it
mean
that
it
would
get
functional
the
moment
the
new
replica
set
gets
functional
because
in
that
case
we
could
actually
depend
the
condition
of
the
higher
level
controller
on
the
state
of
their
level
lower
level
controller.
So
the
moment
the
new
replica
set
reports
functional
that
means
we
could
actually
make
the
deployment
also
functional.
B
Yeah,
I
think
it's
a
good
idea
that
it
would
depend
on
the
logic
of
a
replica
and
I
suppose
like
if
you
can
like
put
any
threshold
you
like.
I
guess
it
could
be
also
independent
on
the
rollout.
B
A
I
don't
know
because
that
would
again
we
would
have
to
introduce
this
this
threshold
across
the
board.
A
Sorry
up
for
all
the
controllers,
which
is
not
something
that
I'm
I'm
actually
interested
in
doing
as
of
now.
So
I
would
rather
have
it
done
differently.
A
I've
linked
the
mailing
list
thread
that
philip
started
last
friday
about
the
topic,
even
though
it
initially
steered
toward
jobs,
which
is
something
that,
if
I
remember
perfectly
enough,
if
I
understood
philip
correctly,
we
would
be
taking
care
of
at
a
later
stage
I'll
try
to
comment
on
this
in
the
thread
just
that
we
go
to.
We
get
it
back
to
the
original
point
of
discussion,
namely
the
functional,
slash,
operational,
slash
available
conditions
and,
let's
try
to
work
it
out,
just
like
clayton
described
in
the
in
the
email
thread.
A
This
topic
is
not
something
that
we
will
be
able
to,
or
we
are
not
interested
in
pushing
this
quickly
through,
because
the
goal,
the
end
goal
of
the
entire
changes
is
to
ensure
that
we
can
build
tooling
on
top
of
those
controllers,
such
that
they
can
consistently
talk
with
any
other
controller
happening
beneath
it.
So
like
the
example
of
deployment,
which
is
built
on
top
of
replica
set,
would
be
reusing,
the
same
condition
to
report
further
up
the
chain
in
a
similar
manner.
A
A
B
A
Yeah,
let's
start
with:
let's
start,
let's
start
simple
and
focus
on
this
one
particular
condition:
let's
try
to
solve
it,
at
least
for
the
workload
controllers,
with
the
job
for
the
workforce,
the
the
batch
controllers
at
the
back
of
our
mind
and
then
slowly
hopefully
come
to
a
conclusion
like
I
said
it's
not
something
that
I
want
to
push
quickly
through,
but
rather
focus
and
get
a
a
decent
feedback
from
the
community
and
and
be
able
to
have
a
reasonable
conclusion.
B
Yeah
yeah,
I
think
it
makes
sense
to
make
this
step
for
the
like,
for
also
for
the
state
reset
and
even
set
because,
as
I
mentioned
in
the
beginning,
I
don't
think
like
available
properly
describes
like
what
would
be
expected,
and
maybe
this
other
condition
would
suit
them
better,
and
the
available
condition
could
stay,
maybe
only
in
the
deployment.
B
A
Okay,
hearing
no
other
topics,
I'm
gonna
give
you
back
about
37
minutes
of
your
time.
Thank
you
very
much
all
and
see
you
next
time,
bye,
y'all!
Thank
you.
Thanks,
hi.