►
From YouTube: Kubernetes Community Monthly Meeting for 20220427
Description
Kubernetes Community Monthly Meeting for 20220427
A
Hello,
everyone
and
welcome
to
the
april
2022
edition
of
the
kubernetes
community
meeting
today
is
thursday
april
21st
2022,
and
I
want
to
thank
you
for
joining
or
watching
this
recording
a
few
housekeeping
things
before
we
get
started.
This
community
meeting
is
live
streamed
and
will
be
posted
publicly
on
youtube.
So
please
be
mindful
what
you
say
is
being
recorded.
A
This
is
an
official
meeting
of
the
kubernetes
project
and
we
abide
by
the
kubernetes
code
of
conduct,
which
boils
down
to
be
excellent
kind
of
respectful
to
each
other.
I'm
your
host.
Today,
my
name
is
ray
lojano.
I
work
at
sousa
by
way
of
branch,
labs
and,
and
I'm
also
the
sigdoc's
co-chair
and
we're
a
few
other
hats
in
the
community.
We
also
have
joseph
sandoval
taking
notes
for
us,
so
thank
you,
joseph
and
as
a
reminder,
please
meet
yourself
when
you're,
not
speaking,
I'm
going
to
paste
a
link
in
the
zoom
chat
here.
A
That
link
is
to
the
read-only
version
of
the
notes.
So
if
you're
not
taking
any
notes
or
or
adding
things
to
the
agenda,
please
use
this
read-only
version,
because
google
docs
slows
down
when
we
have
too
many
people
in
the
dock.
So
we
have
a
number
of
topics
on
the
agenda
today
and
they
are
gathered
from
the
community
as
topics
that
are
deemed
of
general
in
community
interest.
We
encourage
people
to
add
agenda
topics
when
there
is
a
topic
that
the
community
should
pay
attention
to
or
have
visibility
on.
A
So
next
month
is
kubecon
eu
in
europe
in
valencia,
spain,
so
we
typically
do
not
have
a
community
meeting
when
we
when
we
meet
at
kubecon,
there
will
be
a
contributor
summit
at
kubecon
eu
on
monday
may
16th
and
please
register
at
thecuberennings.gov
summit
website
also
of
notes
as
well.
Since
we
have
coupon
europe
and
we're
we're,
we
will
start
off
the
kubernetes
125
release
cycle
around
that
time
that
the
enhancements
freeze
will
start
shortly
after
kubecon
year.
So
this
is
a
request
to
sig.
So
please
start
planning
out
enhancements
for
125..
A
A
A
Next
announcement
is
from
sig
case
infra.
This
is
a
load
test
request,
so
the
request
is
to
please
use
registry.kates.io
instead
of
capes.gcr.I
dot
io
to
test
the
load,
and
we
want
to
do
this
to
spread
load
and
cost
rebound
cloud
providers.
We
of
course,
initially
had
it
at
gcr,
so
this
registry.kit.io
is
on
aws.
A
Lastly,
a
third-party
security
audit
for
the
kubernetes
project
will
actually
start
in
may.
This
will
be
done
by
the
ncc
group.
The
last
security
third
party
security
audit
was
in
2019,
so
this
is
so.
This
is
great
that
we're
going
to
have
a
third-party
security
audit
done
this
year,
there's
links
to
the
rfp
and
the
rfp
decision
process.
Now
it's
on
the
agenda
as
well.
A
B
Hello:
everyone,
my
name,
is
james
lavrak.
I
am
the
release
lead
for
kubernetes
124..
I
have
a
short
update
for
you.
All.
The
big
news,
of
course,
is
that
the
release
scheduled
release
date
was
pushed
back
by
two
weeks,
so
it
is
now
on
tuesday,
third
may,
in
just
under
two
weeks
from
now
the
bug
that
caused
that
delay
has
been
fixed
and
was
shipped
in
go
118.1
and
that
has
been
incorporated
and
fixed.
B
We
have
a
rc-0
that
was
cut
last
tuesday
and
is
available
for
community
testing,
and
I
would
encourage
people
to
to
experiment
and
test
with
it
we're
expecting
to
cut
an
rc-1.
Our
final
scheduled
release
candidate
next
tuesday
26
april
in
more
general
news.
The
shadow
survey
for
the
next
release
of
kubernetes
kubernetes
125,
is
open
and
will
close
friday
29th
of
april.
B
So,
if
you're
at
all
interested
in
the
release,
team
do
apply
we'd
love
to
have
new
contributors,
even
as
a
fact
in
fact,
especially
contributors
who
have
not
contributed
before
to
join
us
on
the
release
team.
If
you
have
any
questions
about
any
of
that
either
do
with
124
or
125.
Please
come
talk
to
us
in
sig
release
on
slack,
and
that
is
all
from
me.
C
In
the
absence
of
a
named
tlr
tech
lead
yeah,
thank
you,
paris,
and
we
have
found
that,
like
after
talking
to
lots
of
sick,
leads
and
not
just
sick
leave,
but
people
in
the
community.
The
roles
are
often
conflated
together.
So
when
people
picture
a
chair,
they
often
associate
the
roles
of
the
responsibilities
of
the
tl
to
them,
or
it
just
get
gets
mixed
up
when
they
really
truly
are
two
separate
things,
and
this
has
caused
confusion
and
issues
for
the
lease
team.
C
C
E
E
First
of
all,
the
idea
of
just
double
listing
the
chairs
in
some
cases
like,
I
think
that
that
makes
sense,
it
doesn't
really
create
any
extra
work.
It
just
creates
that
explicit
division,
so
the
same
people
can
do
the
same
jobs.
I
will
also
say
that
in
sig
instrumentation,
which
I
currently
am
a
co-chair
of,
we
did
do
the
split
and
then
appointed
people
separately
into
tech,
lead
and
chair
roles,
and
even
though
we're
like
a
very
small
sig
in
terms
of
volume,
most
of
our
stuff
is
out
of
tree.
E
I
think
it's
been
really
positive
for
the
sig
to
have
more
active
leadership
and
to
give
folks
more
opportunities
to
to
step
up
so
like
if
you're
worried
like
oh
no,
I
won't
find
people
to
do
this
work
or
like
we're
gonna
be
understaffed.
I
think
you
would.
You
may
be
surprised
in
terms
of
how,
if
the
opportunity
is
open,
how
many
people
are
willing
to
step
up.
C
C
Let's
see
if
there's
any
other
comments,
james,
oh
somebody
that
signalled
like
release,
I
end
up
just
paying
the
leads
as
a
whole.
When
I
need
something
from
sig
leadership
perspective
yeah,
that's
there
is
a
lot
of
times
they
there
is
like
again
the
roles
are
conflated.
You
know
they
have
separate
responsibilities.
C
C
C
A
Do
so
a
few
things
so
back
to
the
previous
topic
is
one
that
leads
into
this
as
well
having
that
default.
If
there
is
no
tech
blade
naming
both
naming
the
chairs,
both
cochair
and
tech,
lead
kind
of
helps,
identify
where
we
need
to
just
ramp
up
maintainers
and
which
cigs
need
need
more
contributors
to
become
maintainers
same
idea
with
with
with
with
having
terms
for
for
chariots
as
well.
A
C
Yeah,
actually
one
other
point
a
lot
of
times
like
when
it
comes
to
like
the
splitting
like
why
we're
only
thinking
of
this
for
the
chair
role
for
a
lot
of
times,
it
can
take
many
years
to
become
a
tl
and
to
retain
that
expertise
in
that
space.
So
that's
part
of
the
reason
why
we
are
only
thinking
of
this,
of
the
terms,
at
least
at
this
time,
for
the
chair
role.
C
Well,
unless
it
will
likely
be
a
progressive
thing,
because
you
don't
necessarily
want
all
chairs
to
retire
at
the
same
time,
I
think
it'd
be
you
know,
say
if
we
want
to
put
in
terms
over
the
course
of
by
the
end
of
2022,
try
and
find
some
more
people,
because
you
at
this
point
you
you
definitely
want
to
have
like
three
chairs.
So
that
way
you
will
constantly
have
you
know
at
least
one
person
around
and
not
two
people
sort
of
you
know
cycling
off
if
they
do
decide
to
cycle
at
the
same
time.
C
A
C
C
C
C
A
A
A
A
A
F
F
F
It's
definitely
been
a
while
for
some
folks
that
have
been
here
for
a
bit
and
annual
reports
is
a
way
for
us
to
check
in
on
all
of
our
groups.
I
think
we
have.
We
still
have
over
37
groups,
which
is
a
lot
and
groups
would
be
special
interest
groups.
Working
groups,
end
user
groups.
There
is
discussion
about
you
know,
taking
user
groups
to
the
cncf
level,
but
more
on
that,
probably
at
another
community
meeting
in
the
future.
F
G
F
Okay
cool,
so
this
is
what
the
report
summary
looked
like
last
year.
This
report,
the
reporting,
is
done
by
sig
chairs
speaking
of
the
devils,
and
what
we
do
is
we
pretty
much
collate
all
of
the
reports
into
this
summary,
which
gives
us
a
really
nice
high-level
approach
to
talk
about
our
needs
and
talk
about
the
things
that
we
need
to
keep
pace,
the
things
that
are
currently
going
on,
where
we
need
help
etc.
F
So
this
is
what
last
year's
looked
like.
We
are
almost
done,
and
this
is
our
current
issue
right
now
in
the
steer
in
steering
repo
once
we're
done
with
getting
all
the
reports
together
within
the
next
two
weeks.
We'll
have
published
the
next
version
of
the
summary,
and
we
would
love
for
all
of
you
to
help
us
get
the
word
out
for
this.
F
F
So
if
you're
wanting
to
ever
know
about
a
sig
or
a
working
group,
you
can
come
into
the
community
repo
right
here
and
then
inside
of
the
repo
itself.
There's
a
bunch
of
sigs
and
working
groups
folders,
and
so
let's
go
back
into
sig
docs
you'll,
see
inside
of
here
that
there's
annual
report.
So
you
can
check
out
individual
reports,
not
just
the
summary
itself,
because
the
summary
doesn't
necessarily
have
every
single
detail.
F
That's
on
these
reports
for
each
group,
because
we
really
highlight
the
themes
and
the
growth
areas
and
things
like
that,
as
in
the
summary
and
the
summary
is
already
an
18-page
document.
So
if
we
included
every
single
detail
in
here,
we
would
probably
be
you
know,
printing
out
that
one
meme
of
of
you
know
the
stacks
of
paper
next
to
grace
hopper
or
something
like
that.
So
definitely
trying
to
keep
the
summary
as
light
as
possible,
so
that
people
can
still
read
it.
But
yeah.
F
F
They
talk
about
the
work
that
they're
capturing
outside
of
keps
and
for
folks
that
are
just
joining
us
caps
or
kubernetes
enhancement
proposals
and
then
also
we
go
into
project
health,
and
this
is
where
we're
really
starting
to
evolve
as
a
project
in
trying
to
determine
like
what
is
project
health.
What
isn't
so?
This
is
a
really
great
way
for
us
to
kind
of
start
to
collect
that
information
so
that
we
can
come
up
as
a
you
know,
come
up
with
the
community.
F
F
But
we
ask
sigs
that
in
advance,
and
then
this
also
helps
new
folks
point.
You
know
get
that
information,
they
need
to
get
up
and
running
in
six
and
then,
of
course,
there's
always
the
good
question
here
of
what
these
groups
and
users
and
kubernetes
that
they're
not
currently
getting
right
now
and
the
groups
really
put
a
lot
of
time
and
energy
into
these
sections.
F
F
A
A
C
H
F
H
Do
we
need
more
of
a
lead
there
too,
like
do
we
need
to
spell
it
out,
as
in
like
here
are
the
risks
here?
This
is
the
potential
damage
that
can
be
done
like
make
it
very
clear,
like
we
want
people
to
hire
more
full-time,
maintainers
right,
like
that,
that's
our
real
dream
and
goal
as
a
project
right
now
is.
We
need
more
companies
to
hire
more
full-time
maintainers,
because
it's
really
hard
to
be
a
part-time
contributor
to
kubernetes.
I
So
eddie
one
of
the
problems
is
when
we,
when
we
kind
of
like
show
that
this
is
like
a
big
problem.
What
ends
up
happening
is.
First
thing
is:
oh,
it's
a
big
problem
and
the
next
one
is
like.
No,
it's
not
my
problem.
Somebody
else
will
do
it
right.
So
that's
part
of
the
reason
why,
like
breaking
things
into
chunks
and
then
shining
the
spotlight
on
that
seems
like
a
better
thing
to
do
at
this
point
you
know
so
people
will
say:
okay.
I
That
is
a
smaller
piece
of
thing
that
we
could
possibly
absorb
right
by.
You
know
pointing
out
the
value
of
it
by
saying
so,
I'm
literally
struggling
here
trying
to
figure
out
like
which
way
to
voice
the
opinions
going
up
into
different
organizations,
because
you
know
sometimes
people
will
just
walk
away.
Saying:
hey,
I'm
not
going
to
do
anything
about
it
right.
It's
like
I
said
before.
I
Exactly
exactly
so,
we
have
to
overcome
those
barriers
in
how
we
are
pitching
this
right.
So
so
we
are.
We
are
struggling
clearly
to
articulate
this
message
to
different
people
in
different
ways
to
get
the
points
across
and
still
show
that
we
are
trying
to
do
our
best
from
you
know.
Whatever
resources
we
have,
but
it
would
definitely
help
if
they
pitch
in
too
right.
I
A
J
I
think
we
proposed
there
like
priority
important,
long-term
or,
more
so
important,
look
they're,
important,
soon
and
and
critical
urgent.
I
think
there
was
a
comment
in
the
in
the
issue
that
we
should
probably
consider
extending
that
with
like
to
only
like
triage
accepted,
which
has
a
potential
to
drop
something.
But
but
if
we
didn't
triage
it,
then
it's
it's
probably
a
problem
on
its
own,
so
I
think
that's
that's
fine
to
add
it.
J
So
so
the
the
question
here
is
like:
do
you
have
any
feedback
on
that
or,
like
you
have
some
reasons
that
you
believe
that
it's
a
bad
idea,
maybe
one
more
stat.
That
is
useful.
I
think
we
have
currently
80
80
such
issues
that
were
closed,
so
we,
if,
if
we
decide
to
do
that,
we
should
probably
reopen
those
but
yeah.
The
question
is
like
to
about
your
feedback
for
doing
that.
A
Daniel
also
put
in
chats,
we
need
to
at
least
replace
it
with
some
kind
of
ping
bot.
The
bot
has
been
a
pretty
useful
way
to
get
reminded
about
the
existence
of
issues
that
were
lost
in
the
noise
and
bob
replied.
In
my
opinion,
they
should
be
abetted
by
community
members
and
plus
one
from
daniel
plus
one
from
me
as
well,
and
eddie,
and
chad
pinball
wouldn't
cause
way
more
noise.
In
his
opinion,
in
eddie's
opinion
josh
put
in
chats,
I
thought
the
proposal
was
to
still
set
them
to
stale.
D
I
So
one
of
one
of
the
issues
is
that
they
don't
get
triaged
and
assigned
to
the
right
sig.
So
there
is
a
bunch
of
issues
that
get
closed
directly
from
there
as
well.
There
are
sigs
that
have
regular
triage
calls
and
deal
with,
like
ap
machinery,
for
example,
does
a
really
good
job.
I
have
a
feeling
that
we
should
get
more
sigs
to
adopt
that
best
practice
of
having
a
triage
this
thing
and
then
figure
out
a
way
to
reduce
the
bucket
of
things
that
don't
get
assigned
to
specific
sigs.
E
All
of
the
sigs
that
I'm
involved
in
currently
do
triage,
but
I
don't
think
that
that
prevents
issues
from
getting
lost
like
node,
has
an
entire
board
of
bugs.
There
is
a
column
which
are
high
priority,
bugs
which
are
all
the
bugs
labeled
important,
soon
or
critical,
urgent
we're
still
having
them
rot
out,
because
we
just
don't
have
enough
resources
to
look
at
them
like
there's
a
backlog
of
over
150
valid
bugs
for
node.
We
don't
have
a
team
large
enough
to
make
much
headway
on
that.
I
E
I
think
that
it's
okay
for
the
bot
to
close
as
rotten
anything
that's
been
triaged
with
needs
information,
because
we
have
like
a
column
of
like
issues
where
we
ask
the
author,
like
hey,
we
can't
do
anything
with
this
bug.
It's
not
actionable.
Can
you
add
some
information,
those
get
stale
and
like?
I
would
be
totally
fine
with
those
rotting
out
the
the
ones
that
I'm
a
little
sad
about
are
the
ones
that
have
been
triage
accepted
and
they
get
rotted
out
like.
Maybe
that's
something
that
we
say.
E
K
Something
without
a
reason
you
know
like
in
in
our
repo
things
should
be
closed
by
somebody
with
a
reason
like
we're
not
going
to
proceed
with
this.
So
we
change
the
kept
to
you,
know,
rejected
or
deferred
or
something,
but
by
closing
the
issue
it
just
disappears,
but
there's
never
a
decision
that
can
be
made
on
it,
but
then
at
the
same
time,
it's
bad
because
the
decision
wasn't
made
that
needed
to
be
made.
So
if
this
is
the
same
bot,
I
think
it
is
bob
like
we.
K
E
I
think
you
could
just
turn
it
off
for
issues
in
the
enhancements
repo
while
leaving
it
on
for
prs.
Like
I
definitely
well,
the
bot
is
also
only
so
helpful
for
prs,
because
I
definitely
see
contributors
submit
a
pr.
The
pr
ends
up
needing
a
rebase
and
like
they
take.
You
know
the
rotten
labels
off
and
like
reopen
pr's
that
cannot
be
merged,
and
that
is
very
frustrating
to
me
as
a
maintainer,
because
then
I
have
to
go
back
close
the
pr
and
say
hey,
this
isn't
mergeable.
E
L
Yeah,
this
is
a
real,
really
interesting
discussion.
I
I'm
curious
as
well.
If
anybody
has
any
thoughts
specifically
around
the
timelines
like
that
was
another
thread.
That
was
another
a
thing
that
was
mentioned
on
the
the
the
issue
at
hand
is
like:
do
we
still
stale
rotten
enclose
things,
but
on
a
different
timeline
like
right
there
right
now,
the
current
timeline
from
like
any
activity?
L
K
Well,
I
I
think
that
it's
like
having
something
customizable
would
be
good
because,
like
for
the
enhancement
repo,
we
also
talked
about
this
recently,
where,
like
the
bot
messages,
don't
really
coincide
with
the
release
cycle
and
it's
actually
pretty
normal
to
have
some
spaces
between,
like,
let's
say,
beta
and
ga
like
you
are
gonna,
wait
for
maybe
two
releases
before
you
move
it
to
ga.
So
there
might
not
be
any
action
on
that
issue,
and
that
could
be
perfectly
normal.
A
C
J
Yeah
I
wanted
to
plus
one
to
what
bob
just
said.
I
think,
if
we
really
try
back
and
market
it
as
like
important,
then
I've
seen
a
bunch
of
cases
where
it
really
took
us
like
quarters,
if
not
years,
to
fix
something,
but
that,
like
the
fact
that
we
didn't
get
to
it
as
a
community,
I
think
it's.
It's
still
means
that
we,
if,
if
like,
we
can
always
like,
as
six
can
always
close
those
backs
if
they
realize
that
those
are
no
longer
valid.
G
C
For
for
once,
I
think,
like
that
sort
of
situation
will
be
more
of
a
edge
case,
or
you
know
we
should
be
talking
to
the
the
like.
We
should
try
and
educate
our
contributor
base
when,
when
we're
doing
sort
of
these
things
of
when
it
is
applicable,
to
use
the
triage
accepted
label,
I
still
think
like
it
is
probably
the
best
path
forward
to
solve
this
current
problem.
I
Yeah
so
well,
this
is
a
symptom
of
a
larger
problem.
Right
like
we're
not
getting
people
in,
we
are
not
like
bringing
them
up
to
speed
and
as
a
result,
we
don't
have
enough
hands.
Like
you
know.
Elena
is
mentioning
that
you
know.
We
know
there
are
problems,
but
we
can't
go
around
fixing
them,
and
so
we
let
things
go
unless
you
know
there
is
a
hair
on
fire
kind
of
a
situation
right.
I
We
are
paying
for
the
cpu
memory.
That's
used
when
the
ci
jobs
are
run
and
the
sick
case
infra.
We
are
trying
to
like
visit
all
the
jobs
and
say
hey.
Do
you
really
need
this,
and
can
we
shut
it
down,
or
can
you
switch
this
back
on
when
you're
ready
and
when
you're
willing
to
work
on
this
right?
So
there
is
a
cost
involved
here
now,
so
we
so
when
there
is
some
kind
of
motivation
like
that,
we
start
paying
attention
right.
I
So
I
don't
know
I
probably
went
off
on
a
tangent,
but
you
know
one
of
the
points
there
is.
We
need
to
do
better
as
a
community.
We
need
to
bring
more
people
in.
I
know
it's
easier
said
than
done
and
yes,
at
least,
if
we
know
and
acknowledge
all
the
problems
we
have.
I
think
we'll
have
a
better
chance
of
dealing
with
it.
E
Four
minutes
at
the
top
of
the
hour
yeah
the
jobs
keep
breaking.
We
spend
a
lot
of
time
in
the
sig
trying
to
make
them
not
break.
We
get
them
green.
Then
they
all
immediately
start
breaking
everyone's
like,
but
you
just
fixed
them.
We
don't
have
time
to
spend
on
that.
They
need
constant
upkeep,
so
yeah.
It
is
a
wide
range
of
issues,
as
danielle
has
mentioned
and
like
we
have
dozens
of
people
working
on
them
and
it's
still
a
problem.
So.
I
I
did
put
a
tldr
in
there
like.
If
you
get
a
ping
from
all
of
us,
say:
hey
something
is
flaky
or
something
is
failing.
Please
please
help
us,
because
it
takes
a
little
bit
of
your
time
and
it
takes
more
of
our
time
to
go,
fix
the
same
job.
It
will
be
probably
easier
for
you
to
do
it
than
us.
Thank
you.
H
Yeah
we've
talked
about
this
a
few
times
recently
too.
I
know
that
the
current
ci
signal
leads
are
working
on
some
content.
There
I
talked
to
jordan.
Jordan
is
down
for
recording
more
stuff
there.
So,
yes,
no
one
is
against
it.
Everyone
absolutely
wants
it.
It's
just.
We
need
to
get
bandwidth
and
prioritize
it.
Okay,
for.
A
A
All
right
well,
thank
you
very
much.
There's
some
shout
outs
this
month
as
well.
I
have
two
minutes.
That's
all
on
the
shout
out
channel
just
if
you
want
to
highlight
real,
quick
cast
and
fields
for
mark
markey,
jackson,
bridge
fetish,
samal
grayson
one
and
the
124
release
enhancements
team,
natalie,
blocko
antonia,
watching.