►
From YouTube: Kubernetes Release 1.26 Retrospective Part 1 on 20221102
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).
B
Welcome
to
the
kubernetes
1.26
release
team
retrospective
part,
one
we
are
doing.
These
are
the
mid
cycle
retro
to
understand
what
went
well
so
far.
What
can
we
do
better
in
the
next
few
weeks
of
the
release
cycle
or
the
remaining
part
of
the
release
cycle
before
we
get
into
business?
Do
remember
the
kubernetes
community
meeting
and
it
is
governed
by
the
kubernetes
photo
conduct.
So
please
be
a
nice
to
everyone,
and
this
meeting
is
also
being
recorded.
B
Before
we
start
with
the
current
release
cycle,
there
are
a
few
housekeeping
items:
oh
okay,
just
for
information,
the
meeting
notes
and
the
chat,
so
I
would
request
you
all
to
open
that,
and
the
first
agenda
item
is
like
the
previous
letter
of
follow-up.
So
I
put
a
I,
put
the
exact
exactly
the
same
table
from
last
name,
and
we
can
go
over
those.
B
What
we
can
do
is
we
can
see
like
who
is
on
this
call
and
then
the
what
it
did.
What
is
done
already
so
something
some
line.
Items
are
already
marked
green,
so
we
may
not
need
to
go
over
them,
but
I'll
just
go
over
the
items
where
I
see
like
people
are
on
this
call
the
first
one
automating
weekly
signal
report.
Leo,
do
you
have
any
updates.
A
B
A
B
D
A
A
C
D
B
D
F
Oh
I
think
there
was
I
think
everything
went
well
with
it
so
far,
I
did
receive
some
private
feedback
that
later
on
this
and
how
to
we.
How
do
we
clean
up
or
if
you
need
to
clean
up
any
enhancements
that
are
no
longer
on
opted
in
or
like
if
they,
if,
if
they
didn't,
have
all
their
code
in
time
for
code
freeze
or
the
opted
out?
F
G
G
That
this
has
been
a
spectacular
change
as
well.
I
think
that
it's
been
really
really
well
received
and
is
is
has
been
yeah
I
can't
I
can't
I
can't.
Thank
you
folks
enough
for
doing
this.
One
one
small
iteration
suggestion
that's
come
up
is
potentially
tracking
non-cap,
Docs
updates,
but
I
think
that's
a
conversation
I'm,
not
exactly
sure
where
that
conversation
should
happen,
but
it's
yeah.
It's
been
great.
So
far,.
G
A
F
G
A
D
G
That's
right:
that's
right!
I,
remember
now,
I
thought
we
I
thought
we
had
agreed
not
to
make
a
decision
there,
though,
but
I
couldn't
remember
who
I
think
it
was
I
think
it
was
Benjamin
Elder
mentioned
that
it
there
was
a
spot
that
that
discussion
should
go
to
in
order
for
that
decision
to
be
made
rather
than
us,
making
it
in
the
room
at
the
time
I.
Just
unfortunately,
I,
don't
I,
don't
I,
don't
recall
where
that
should
have
been.
E
B
H
B
B
A
B
B
D
F
Yep
still
here,
so
this
is
a
new,
so
part
of
the
docs
team
teams.
Task
for
the
release
team
is
to
generate
reference
talks.
We
can
reference
docs
for
like
keep
control
and
the
API
server.
This
is
instrumentation
recently
created
a
generator
to
generate
the
page.
That's
listed
here
for
metrics
that
the
metrics
stated
that
the
kubernetes
exports,
so
it's
up
running,
and
so
this
is
I
believe
this
is
part
of
the
cap
that
Leo
mentioned
that's
on
that
link
there.
F
There
is
a
link
in
that
in
the
pull
request
to
the
on
how,
on
these
there's
a
link
within
a
PR
to
another
PR,
with
the
steps
on
how
to
run
the
generator,
but
ideally
we
will.
This
will
be
fully
documented
before
you
know
the
doc
same
has
to
run
the
generator,
but
for
until
then,
in
second
sick
instrumentation
will
run
new
generator.
So
this
is
a
request
for
the
docs
team
to
add
to
add
this
additional
task
in
part
of
the
reference
doc
generation.
B
F
B
H
E
F
G
G
B
G
G
I
Got
it
but
yeah?
That's
that's
just
me
picking
out
loud
right
so
because
we
started
one
of
the
one
of
the
first
ones
that
I
remember
from
the
start
was
the
the
success
in
using
GitHub
boards
for
track.
So
several
different
teams
are
are
using
it
successful
in
terms
of
comms,
where
we've
we
have
a
view
on
the
kubernetes
126
tracking
sheets,
which
is
automatically
updated.
So
we
have
no,
no,
no,
no
issues
there,
so
it
works
correctly.
I
I
know
that
docs
also
use
is
also
using
the
the
board,
so
I
think
that
in
this
release
it's
the
is
the
the
first
time
that
the
boards
are
being
widely
used.
Perhaps
in
the
next
one,
with
the
Lessons
Learned
of
this
one,
we
could
see
if
there's
any
space
for
making
the
usage
of
the
board
more
uniform
right
so
so
check
what
different
teams
are
using
in
terms
of
boards
if
they
are
using
separate
boards
or
a
single
board
with
multiple
views.
I
There
for
this
release,
we
are
not
using
tracking
sheets.
We
are
using
sorry
this.
My
my
toddler
is
singing,
so
we
are
using
100
of
project
work
for
this
release.
It
was
a
decision
that
we
made
early
on.
We
are,
we
decided
not
using
a
separate
board,
and
one
of
the
reasons
was
that
it's
actually
quite
useful
to
re
reutilize.
The
work
done
in
terms
of
the
enhancements
tracking
since
we
automatically
get
what's
in,
what's
tracked,
what's
in
Risk
what
was
removed
from
Milestone
and
we
don't
have
to
duplicate
nothing.
I
So
it's
we
get.
We
get
the
the
real-time
status
of
the
enhancements
that
are
on
the
release
and
in
our
review
we
just
added
additional
Fields
like
feature
blogs:
opt-in,
Shadow,
responsible
blog
release
date,
other
steps
that
we
we
discussed.
So
it's
working
quite
nice.
So
maybe
this
experience,
along
with
the
experience
of
others
who
that
have
set
up
independent
boards,
not
related
then
as
far
as
I,
know
not
collecting
that
information,
but
maybe
it
doesn't.
A
I
think
for
for
for
docs
cons
and
enhancements
makes
definitely
sense
for
the
other
teams.
So
CA
signal,
for
example,
think
so
maybe
there's
like
an
opportunity
to
integrate
something
CS
from
CS
signal
and
Bug
triage,
for
example,
but
yeah
I
think
that's
that's
a
good
good
idea
overall
to
to
push
this.
B
E
I
B
H
H
Thanks
yeah
I
was
discussing
this
with
nivedita.
The
CI
signal
lead
So
currently
for
the
when
we
raise
issues
for
any
failing
tests,
I
raise
the
issue
and
then
I
have
to
go
and
manually.
Add
that
issue
to
our
project,
to
our
issue
tracking
board
and
again
there
are
some
opportunities
to
automate
all
of
that,
probably
using
GitHub
actions.
Once
an
issue
is
created,
it
has
certain
tags.
H
D
B
H
F
B
D
Yeah,
because
on
the
project
board,
I
believe
you
can
just
add
a
column.
That's
all
of
the
tags
that
are
associated
with
the
items.
I
think
you
can
set
up
filters
for
the
items
that
have
specific
tags.
Two,
if
you
want
to
filter
views,
but
we
might
not
need
individual
columns.
But
if
there's
not
individual
columns,
I
know
it
makes
it
harder
to
generate
like
the
graphs
if
people
are
interested
in
the
stats.
So.
B
Yeah
I
think
the
problem
we
mentioned
is
so
for
say,
signal
issues
in
the
issue
you
write,
which
create
the
definition
which
test
it
is
failing
and
that
information
is
duplicated
as
like
fields
in
the
board.
View
I
really
don't
have
a
good
way
to
solve
this
problem
other
than
like
passing
through
the
issue
contents
in
the
project
board,
but
this
also
seems
to
be
like
a
very
death
problem.
That's
that's
why
I
am
wondering
like,
shall
we
even
evaluate?
Why
are
we
studying
like
multiple
pieces
of
information
and
then
see
like
what?
B
A
A
A
D
B
B
B
D
D
D
B
B
B
F
B
D
Education
I
just
found
a
doc
that
it
looks
like
Laurie,
Apple
wrote
in
the
community
repository
under
the
chairs
and
tech
leads
folder
that
goes
really
into
depth
about
how
to
like
opt
your
enhancements
in,
but
it's
all
related
to
this
this
the
spreadsheet.
So
we
should
definitely
update
that
I'll
I'll
drop
a
link
in
the
chat.
C
Yeah
so
like
in
every
release,
as
we
know
like,
except
one
or
two
people
every
time,
new
people
join
in
the
team
and
for
them
actually
it's
very
difficult
to
identify
the
flaky
test,
because
we
also
don't
have
the
complete
guide,
the
complete
documentation
for
detecting
flaky
test.
If
we
like
go
on
the
test
grade,
it
will
show
most
of
the
like
tests
are
flaking
and
if,
at
the
time
of
the
voting,
it's
very
difficult
to
identify
which
one
is
really
flaking
or
not
so
I.
C
Think,
although
we
have
a
video
on
this,
but
I
think
few
people
prefer
reading
documentation
over
the
video,
so
I
think
we
should
write
detail
guide
for
the
flake
detection
or
anything
else
which
which
will
be
easier
for
people
to
identify,
tricky
tests
so
because
it
already
created
a
lot
of
confusion.
So
that's
why
I'm
saying
this.
C
E
D
B
Back
this
problem,
it
occurred
like
okay,
how
do
you
determine
what's
a
flake
and
how
do
we
learn
back
then
worked
to
create
a
small
series
of
like
you
can
say
these
are
pairing
sessions
to
go
over
problems
and
then
like
Flakes,
and
then
seeing
like
what
is
going
on.
I
will
link
both
of
the
YouTube
videos
on
the
chat
as
well.
A
D
A
A
A
Yes,
maybe
we
can
also
reference
I
just
sent,
but
this
goes
into
more
detail
and
yeah,
so
so
the
problem
is
also
that,
for
example,
like
deflecting
and
like
using
command
line
tools
and
everything.
So
that's
not
the
requirement
in
the
selection
process,
for
example,
that
you
have
like
a
deep
knowledge
about
certain
things
that
might
be
required
to
deflake
tests.
So
there's
like
a
like
a
I,
don't
know
it's
like
a
certain
level
of
I,
don't
know
complexity
or
something
that
we
can
that
we
can
maybe
deliver
from
a
CS
signal
team.
A
A
C
D
H
Just
throwing
some
thoughts
here
is
my
understanding
wrong
that
as
a
new
Shadow
I
expect
these
to
be
covered
like
the
flaky
test
as
a
part
of
the
onboarding
process.
Obviously,
in
a
way,
data
was
also
a
shadow
within
the
team,
and
then
she
moved
to
a
lead
position
where
even
she
didn't
get
that
information.
H
So
at
some
point,
I
think
when
the
onboarding
was
happening,
these
processes
were
dropped
that
shouldn't
like
shouldn't
I
as
a
new
Shadow,
expect
these
things
to
be
covered
as
the
part
of
the
CI
signal
on
boarding
theme
to
help
me
understand
on
how
to
identify,
rather
than
trying
to
find
out
10
different
links
that
I
need
to
go
and
then
read
like
that.
My
understanding
is:
that's
the
whole
point
of
onboarding
Am
I
Wrong
in
understanding
that
or
expecting
that.
B
B
H
Sorry,
but
like,
why
do
we
put
that
limit
of
30
minutes
to
one
hour
like?
Oh,
is
there
any
reason
that
it
has
to
be
completed
with
it,
and
onboarding
is
supposed
to
be
my
understanding
again
and
I
could
be
wrong
is
to
help
people
get
is
to
help
new
Shadows
get
comfortable
with
their
roles
and
responsibilities.
Now
that
may,
for
some
complex
teams
take
two
hours
so
why?
Why
do
we
want
to
restrict
it
to
30
minutes
in
one
hour.
H
E
B
Go
over
the
basics
go
over,
it's
like
think
of
it
like
as
an
University
lecture,
I
I
usually
model
it
like
that.
So,
whenever
I'm
learning
something
in
the
kubernetes
community,
I
usually
look
at
the
breadth
of
the
problem
and
then
like
dive
deep
into
a
single
point.
Ca
signal
is
a
very
big
Topic
in
the
community
because
you
have
to
understand
like
how
does
testing
travel?
How
does
the
discrete
work?
How
do
we
write
tests-
and
this
is
I-
agree
that
it's
not
possible
in
an
hour
an
hour?
E
D
B
The
videos
that
we
have
and
obviously
there
can
be
like
hundreds
of
questions
on
them
and
then
they
should
ask
the
lead
about
those
questions
and
even
I
feel
like.
We
should
not
ask
those
questions
privately.
We
should
probably
like
push
those
questions
in
the
ca
signal,
public
slack
channel
the
reason
I
push
for
this
is
the
question
that
you
were
asking.
B
H
So
it's
a
lot
of
information,
and
it's
also
not
in
one
place
like
right
now
we
saw
those
links
which
would
be
missed
and
I
did
read
a
lot
of
documentation
in
the
beginning.
I
updated
a
lot
of
documentation
as
well,
but
I'm
realizing,
there's
still
documentation
that
I
missed
out
on.
So
that's
why
I'm
saying
if
I
would
have
if
I
was
the
lead.
H
I
would
have
preferred
going
through
all
of
those
important
information
and
obviously,
if
you
need
more
details
or
debt
providing
them
the
required
links,
but
rather
than
leaving
it
on
Shadow
members
to
okay,
go
and
figure
it
out
on
your
own,
that
that
would
have
been
my
Approach
feeling
comfortable
that
everybody
in
the
team
has
the
right
knowledge
and
the
skills
to
perform
their
roles
which,
because
currently
I,
don't
understand
how
test
grid
works.
I,
don't
know
how
to
write
the
test.
H
So
there's
a
lot
of
again
finding
that
I
have
to
go
digging
out
that
I
have
to
do
which,
with
the
day
job
I
may
not
always
have
the
capacity
to,
but
when,
if
somebody
just
walks
me
through,
you
know,
sometimes
you
need
a
bit
of
hand
holding
and
then
you
can
pick
it
up
quickly.
That's
just
my
my
thoughts
on
this.
G
B
Them
is
like
I
do
agree
that
we
should
promote
more
pairing
sessions,
but
how
do
we
do?
This
is
a
policy
for
the
whole
release?
Team
is
kind
of
tricky
I
believe
we
can
do
this
for
sub
teams,
maybe
in
the
ca
signal-
and
we
can
write
that
hey
since
this
is
a
complicated
role,
please
feel
free
to
like
contact
pairing
sessions,
but
again
I
have
equal
gracious
Point.
D
B
B
If
we,
you
know,
handbooks
have
anyway
codified
a
policy
of
just
one
hour
sessions,
we
should
probably
remove
it.
I,
don't
think
we
should
policy
that
we
will
only
do
on
our
onboarding
sessions.
We
should
say
like
this:
is
the
directive
please
feel
free
to
like?
Do
it
like
do
an
onboarding
session
which
could
be
of
lesser
duration
or
of
more
duration
or
spread
over
maybe
two
weeks
or
three
weeks?
B
But
then
again,
I
am
also
a
little
concerned
about
people
pointing
out
if
we
say
this
as
a
directive,
that
a
lead
has
to
do
like
half
an
hour
sessions
like
every
day
for
two
weeks,
because
a
lot
of
us,
like
a
lot
of
us,
don't
do
kubernetes
like
on
full-time
roles.
Some
of
us
here
are
like
just
volunteers,
doing
it
on
their
own
time
aware.
H
H
If
we
do
that
as
a
thing
rather
than
trying
and
like
going
and
doing
it
individually,
finding
things
on
our
own,
that's
that's
how
I
feel,
but
I
understand
that
this
may
not
be
feasible
for
all
the
all
the
all
the
release,
themes
but
I'm,
just
saying
it
from
the
CI
thing.
This
is
my
first
Shadow
role
as
well.
Within
the
release
team,
there
could
be
other
teams
which
obviously
don't
require
the
same
of
knowledge,
but
to
me
to
feel
more
involved
and
engaged
in
my
role.
D
B
A
F
B
H
B
B
Has
a
set
of
Emirates
advisors
in
a
way
the
enhancement
sub-project
leads
are
essentially
people
who
have
been
on
the
release
team
in
the
past
and
can
act
as
emulators
advisors,
but
for
the
ca
signal
team
I'm,
not
sure
like
who
would
be
that
group
and
I?
Think
I
vaguely
remember
history,
that
the
ca
signal
team
was
actually
I,
think
a
different
sub
project
before
and
then,
which
was
absorbed
into
like
different
parts
of
the
community.
One
release
team
and
the
other
being
tested.
But
I
may
be
wrong
in
saying
that.