►
From YouTube: Kubernetes SIG Apps 20230206
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
Welcome
to
February
6,
ccaps,
meeting
I'm
Janet
and
together
with
me,
is
my
check,
who
is
also
our
co-host
I'm,
going
to
be
your
host
today
and
then
we
have
an
announcement
in
a
few
discussion
topics
and
my
check
has
posted
the
the
link
to
the
agenda
in
the
chat.
A
So
your
first
thing
is
the
announcements
on
enhancement.
Freeze
is
this
on
this,
but
around
the
end
of
this
week,
so
take
a
look
at
that
link.
127
enhancement
freeze
is
coming.
A
B
Yeah
sorry
I
forgot
to
put
my
name
on
it:
hey
Jenna,
it's
Kevin,
so
I
just
wanted
to
bring
awareness
to
I,
have
that
well
I
decided
to
take
that
issue
related
to
adding
the
prefix
labels
for
the
batch
apis
for
the
job
name
and
controller
uid
and
I
have
a
a
pull
request
for
that.
B
But
it's
it's
been
kind
of
difficult
to
find
approvers
for
some
of
the
code
around
the
package
registry
batch
and
so
I
was
just
hoping
to
maybe
bring
some
awareness
to
that
PR
and
see
I
actually
think
Aldo
just
assigned
it
to
him.
So
this
may
be
not
as
big
a
deal,
but
in
general.
That
was
why
I
added
it
to
the
agenda
I
was
having
some
trouble
getting
finding
the
right
people
to
approve
some
of
the
code,
especially
related
to
the
package
registry
batch
area.
D
Both
the
package
registry
and
package
API
will
be
approved
by
the
API
reviewers,
because
they're
actually,
basically
the
same
as
long
as
you
maintain
both
and
I.
Remember
that,
while
scrolling
through
the
original
issue
that
Tim
opened-
and
he
did
point
it
out
to
have
both
of
the
also
the
labels
set
in
parallel
for
good
couple
releases
and
a
proper
release-
note,
and
maybe
a
a
note
in
the
document
that
these
old
latest
labels
are
being
deprecated
in
favor
of
of
the
new
prefixed
ones.
D
It
looks
reasonable,
so
I'll
I'll
try
to
but
yeah
for
the
approval.
If
I
can
say,
if
it
was
like,
there
will
be
someone
from
the
API
team,
ATM
machine
learning,
team.
B
D
D
So
he
should
be
able
to
to
tag
rpr
and
ask
ask
for
channel
there's
API
reviews
or,
alternatively,
it's
a
API
machinery,
although
I'm
pretty
sure
that
they
would
still
want
to
see
someone
from
the
Zig
API
gig
apps
to
leave
their
Mark.
B
All
right,
I
guess
for
documentation.
What
is
there
is
that
a
separate
PR
as
far
like
the
website,
or
is
that
part
in
the
pr.
D
No
you're
correct
that
will
be
the
website
repository.
You
want
to
create
a
rpr
and
find
the
the
bits
which
are
talking
about
those
labels.
If
there
is
no
particular
one
I,
don't
remember
off
top
of
my
head.
D
The
current
structure,
if
there
is
nothing
like
that
currency
I,
would
just
put
a
note
somewhere
towards
the
top
of
this
document,
so
that
people
who
are
opening
this
document
are
at
least
aware
that
something
like
that
might
be
happening
even
days
don't
be
if
nobody
is
relying
which
we
cannot
assume,
it
would
be
good
to
to
have
a
section
somewhere
there
about
that
deprecation
and
that
change.
B
Thank
you
and
I
guess:
does
this
fall
under
enhancement,
threes,.
D
E
Ahead,
so
regarding
the
website,
you
need
to
open
a
change
but
towards
the
the
branch
for
the
next
release,
which
is
the
127
release,
the
reason
being
that
you
know
this
is
kind
of
like
a
new
feature
or
I
mean
it's
gonna.
It's
not
you're,
not
gonna,
backboard
or
anything.
E
So
it
should
go
for
the
next
version,
so
you
should
open
the
pr
for
the
branch
for
the
next
version
of
of
the
website,
so
it's
gonna,
that's
that
should
be
merged
only
when
the
release
is
going
to
happen
and
in
terms
of
enhancements.
This
is
not
an
enhancement.
This
is
more
of
a
I
guess,
kind
of
also
kind
of
like
a
bug
fix,
so
you
don't
need
a
cap
or
is
that
it
doesn't
fit
through
the
enhancements
it
doesn't.
D
Yeah
I
was
I
was
wondering
about
it
earlier
today
whether
this
is
worthy
at
all
of
a
cap.
What
I'm
leaning
towards
what
Alba
said
that
this
is
a
buck
six
more
so
as
long
as
we
just
make
sure
that
people
are,
we
will
leave
them
appropriate
time
to
switch
over.
Even
if
this
is
shouldn't
be
heavily
used.
We
still
need
to
make
sure
that
the
overlap
is
there.
D
The
branch
that
Aldo
was
talking
about
for
the
website
is
desk
1.27.
That's
just.
B
All
right
well,
that
sounds
that's
all
very
helpful.
Thank
you
all.
E
Right
regarding
deprecation
I
feel
like
the
most
natural
rule
to
follow,
is
the
rule
for
GA
features
or
GI
apis.
This
means
that
for
I
think
it's
either
three
or
four
releases,
the
actually
we
might
not
be
able
to
remove
it.
I
think
we'll
need
to
check
with
with
Jordan
or
other
API
reviewers,
but
basically
for
now,
you
have
to
keep
supporting
both.
So
both
should
work.
B
E
Never
depends
on
rule
for
a
the
interpretation
of
group
4A
for
the
application,
so
we
would
have
to
ask
the
API
reviewers
what
they
think.
A
B
There's
really
no
way
to
remove
that
until
we
can
guarantee
that
everyone
has
the
new
label
I
think
at
least
there's
some
requests
about
upgrade
policies
that
I
found
very
difficult
to
reproduce,
so
I
kind
of
went
with
the
policy
of
selectors
will
use
the
old
label
until
we
can
guarantee
that
the
new
label
is
there
in
among
any
of
the
upgrades
that
we
support.
So
that
was
at
least
my
thought
process.
E
D
Wouldn't
be
simpler
to
just
set
the
the
new
labels
for
now
and
leave
the
selector
until
128
in
128.
Given
this
the
supported
school
plus
minus
one,
we
would
be
able
to
switch
the
selector
to
use
the
new
ones
and,
and
then.
D
I
yeah,
the
I
have
some
reservation
towards
doing
an
or
I'm,
not
sure
that
will
work
correctly
or
we'll
just.
E
F
F
D
Probably
no
okay,
so
we
would
just
publish
both
use
the
new
one
and
the
old
one
would
be
their
for
eternity,
or
at
least
V2
gets
introduced.
E
I
think
the
job
controller
could
eventually
migrate
to
only
use
the
new
ones,
because
these
are
jobs
and
they
would
finish
So
eventually
like
in
two
or
three
releases.
You
shouldn't
have
any
jobs
that
are
still
running
that
have
the
only
half
the
the
all
labels.
D
F
F
Oh,
there's
a
really
good
blog
post
about
people
who
were
doing
batch
work
at
scale
mostly
using
crime,
job
they're,
just
doing
tons
and
tons
of
them,
and
they
they
develop
custom
infrastructure
in
order
to
track
the
life
cycle
of
crime
jobs
and
to
report
Telemetry
based
on
completion
and
all
that
and
if
they're,
using
those
labels
and
we
break
all
their
stuff
because
they
disappear,
that's
yeah
I
think
am
I
doing
lift,
but
but
that's
that's,
not
cool.
E
B
Yeah
I
think
in
general,
that
was
the
consensus
I
sort
of
came
to
was
with
the
selector
was
keep
setting
that
and
then
eventually,
once
we
can
guarantee
all
users
have
both
the
the
new
label,
then
we
could
eventually
switch
to
using
that
selector
in
the
job
controller,
but
I
think
with
this
round
it's
probably
published
both
and
keep
using
the
old
selector
for
this
first
release,
so
we
don't
break
anything
and
then
that
was
at
least
the
consensus.
That
was
the
I
think
the
general
idea
that
I
came
to.
A
G
A
G
Yeah
I
think
so.
Yeah
I
would
like
to
talk
about
this
issue
and
solve
it
for
users
who
are
incorrectly
using
pdbs,
and
this
has
has
to
do
with
constraints.
We
have
regarding
setting
the
max
unavailable
and
minimum
available
and
our
support
each
of
these
but
like,
but
according
to
which
values
We
Set.
G
What
What's
like
what
controllers
can
be
spots,
be
owned
by
and
when,
and
we
are
documenting
this
as
well,
but
like
not
all
users,
reads
the
documentation
fully
and
when
this
happens,
we
are
not
giving
any
information
to
the
user,
that
they
are
unmanaged
posts
and
the
only
thing
we
do
is
having
a
log
which
has
a
level
four.
So
it's
not
really
visible
like
when
people
use
bdbs
in
an
unsupported
way.
G
So
if
we
could
solve
that
either
by
introducing
event
or
condition
on
pdb,
that
would
mention
that
we
have
unmanaged
plots.
D
I
can
think
of
two
actors,
whether
a
user
who
is
aware
about
this
problem.
Would
he
fix
it
or
whether
he's
doing
this
on
purpose,
and
we
should,
in
parallel,
try
to
inform
cluster
administrator
through
some
kind
of
metric.
D
G
For
example,
as
I
said,
when
you
have
Max
unavailable,
is
zero,
and
but
but
for
example,
for
an
admin
or
for
some
other
actors
who
are
reading
the
status
of
a
pdb,
it's
like
inconsistent
and
they
are
not
expecting.
For
example,
the
expected
parts
or
the
desired
healthy
is
incorrectly
said.
So
even
for
admins,
who
are
observing
these
values,
it's
unexpected
that
they
are
not
like
consistent.
D
This
is
more
like
about
the
the
usability
of
the
pdbs
to
help
the
users
know
that
potentially
there's
something
else
there
were
picking
up
or
something
yeah.
D
I
wonder
about
a
case
where
this
could
potentially
lead
to
unwanted
data
leak.
For
example,
I'm
I,
don't
remember
how
exactly
where
looking
at
the
pods
under
pdb?
Is
there
a
potential
for
pdb
to
take
apart.
G
It's
good
also
like
detect
scenarios
when
you
have
when
you
are
selecting
samples
through
some
labels,
and
then
you
have
additional
posts.
You
are
not
expecting
like
interfering
with
your
Bots
from
some
other
application,
so
this
this
could
handle
this
case
as
well.
So
it
would
also
inform
the
users
who
use
the
pdbs
properly,
but
they
will
have
like
other
reports
that
should
not
belong
there.
G
F
C
I
think
what
Philip
is
asking
for
is
the
status
shows
that
the
disruption
is
allowed
or
not,
whereas
in
the
documentation
we
say
that
our
Max
unavailable,
we
say
that
it
is,
it
should
not
be
used.
So
that
is
the
change.
I.
Think
Philip
is
asking
for
right.
Philip,
correct
me:
if
I'm
wrong.
G
D
The
line
can
that
you
pointed
out
is
only
entering
a
warning
when
we
fail
to
calculate
the
pods,
which
are
the
expected
account
desired,
healthy
and
managed
parts.
The
next
check
after
the
one
that
you
paid
it
out,
is
checking
whether
there
are
unmanaged
spots,
which
is
pots
that
are
not
under
any
controller
controller
yeah.
And
then
we
only
do
an
info
added
before,
which
literally
means
a
lot
of
that
information
even
is
even
hidden,
because
majority
of
the
controllers
are
running
by
default
would
be
two
if
I
remember
correctly.
D
So,
if
I
understand
practice,
Philip
wants
to
put
a
similar
warning
like
one
above
also
for
this
case,
so
that
users
know
that
oh
there's
also
this
one
or
two
other
pods,
which
are
we
are
taking
under
this
under
this
pdb,
which
might
be
actually
problematic
for
you
in
the
long
run,
because
you
think
that
your
app
is
properly
managed
by
the
PDP.
But
it
is
not
because
someone
or
some
some
other
part
is
here.
C
C
G
Yeah
regarding
the
solution
for
the
condition,
I
think
that
this
probably
should
require
a
cap
to
see
how
it
should
be
defined.
D
I'm
not
sure
if
you
need
a
cap,
I
would
just
put
a
warning
all
on
on
a
pdb
just
like
the
one,
a
couple
of
lines
before
yeah
and
you
link
the
702.
Seven
sorry
709.
If
you
look
at
line,
704
I
would
just
put
a
warning
event.
There's.
C
D
Temp
required
for
this
kind
of,
for
this
kind
of
addition
right.
F
G
No
I
I
meant
like
yeah
I,
I
guess
the
event
is
probably
the
most
like
Western
pragmatic
solution.
I
was
just
mentioning
if
we
wanted
to
introduce
a
condition
that
then
it
could
require
a
cap
like
if
he
would,
if
there
were
some
like
consumers,
who
would
like
to
know
that
the
pdb's
are
misbehaving.
I
would
like
to
read
it
on
API
level.
So.
F
D
F
So
conditions
are
weird
I,
don't
like
yeah.
You
probably
would
want
to
do
a
cap.
If
you
want
to
introduce
or
just
like,
like
they're,
not
they
don't
benefit
from
the
same
level
of
stability
as
the
rest
of
the
API
by
Design.
Right
like
they
say,
you
can
like
do
not
depend
on
conditions,
is
called
out
or
build.
State
machines
on
conditions
is
kind
of
called
out
broadly
right,
so
we
can
add
and
remove
those
in
ways
that
are
so
wait
like
yeah
I
mean
I'm
not
opposed
to
the
condition
either.
D
I
would
probably
just
go
with
it
with
an
event:
we've
been
pretty
consistently
using
the
the
warning
level.
C
D
Across
several
controllers,
for
for
notifying
users
that
either
there
is
a
misconfiguration
in
their
in
the
resource
or
a
controller,
is
misbehaving
because
something
else
is
causing
issues
so
I'm,
not
sure
if
a
condition
is
required
for
this
particular
case
and
like
with
all
the
other
stuff,
it's
easily
readable
from
the
from
the
API.
A
Okay,
our
last
topic
is
Rahul.
H
Looks
good
to
me
from
that
I
just
need
an
approver.
The
comment
suggested
Macy,
but
if
I'm
not
sure
who
wants
to
look
at
that.
A
H
Ed,
it
was
a
bug.
A
D
Isn't
that
the
topic
that
we
discussed
couple
months
back
if
I
remember
correctly?
Yes,
10,
headed
initial
staff
at
looking
at
your
PR.
F
Okay,
yeah
I
can
I
can
approve
all
right
thanks,
I
didn't
think
you
needed
me
to
approve
it.
I
gave
a
review.
You
have
lgtm,
you
just
needed
to
approved
yeah.
A
If
not,
we
can
end
the
discussion.
The
meeting
today
early
all
right
thanks,
everyone.