►
From YouTube: 20210324 SIG Arch Prod Readiness
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
All
right,
hello,
everybody!
This
is
the
kubernetes
sig
architecture,
production
readiness,
sub
project
meeting
for
march
24th
2021,
let's
get
started
so
I
see
we
have
elena
and
david
each
put
an
item
on
the
agenda,
but
I
wanted
to
stick
ai
review
on
the
agenda.
A
We
all
had
some
action
items
or
several
of
us
did
anyway,
and
I
will
say
that
I
have
not
done
mine.
Yet,
let's
see
that's
where's
mine
yeah.
That
shouldn't
be
too
hard
to
do,
but
I
haven't
done
it.
There's
not
a
lot
of
urgency
since
we're
not
you
know,
but
it's
going
to
come
up
soon
now
or
pass
code
freeze
we're
coming
up.
You
know
before
too
long
it'll
happen
that
we're
planning
the
next
release
and
we're
getting
into.
B
A
B
B
One
is
to
possibly
have
the
bot
add
assignments
based
on
the
prr
request
file
reviewers,
if
that's
possible
to
do
and
the
other
is,
I
think,
changing
the
order
of
the
questions
in
the
template,
which
I
should
probably
do
first
because
by
having
the
sli
question
before
the
slo
question,
people
are
like
here
are
some
metrics
and
now
I
will
invent
slos
when
it
should
be
the
other
way
around.
C
Okay,
I
also
need
to
update
the
template
in
a
different
spot,
though
so,
hopefully
we
won't
all
conflict
and
I
thought
about
the
phrasing,
but
did
not
actually
open
a
pr
which
is
almost
as
good
as
not
having
done
it
at
all.
C
B
Equivalent
for
the
end
viewer
but
yeah,
I'm
hoping
that
I'll
get
a
chance
to
at
least
finish.
C
B
The
template
rejigger
should
be
fast,
so
hopefully
by
the
end
of
the
week.
If
I
can
remember.
A
A
All
right,
when
should
I
do
mine
my
next
meeting
it
like
shouldn't,
take
very
long
but
I'll
just
be
realistic.
C
A
Okay,
cool
so
you're
by
end
of
week,
two
dude,
okay!
Well,
that
was
easy.
I
don't
think
wojtek
has
any
action
somehow
he
managed
to
avoid
that.
But
he's
got
enough
to
do
okay,
so
then
atlanta,
you
had
wanted
to
discuss
this.
B
B
Mute
button
yeah,
so
one
of
the
things
that's
come
up.
A
lot
is
that
we
have
a
lot
of
people
who
so
there's
like
currently
standard
is
four
weeks
for
enhancements
freeze
and
we
have
a
lot
of
people
who,
for
the
first
two
weeks
before
enhancements,
freeze
as
a
chair,
I
am
like.
Please
get
your
stuff
done.
B
Please
work
on
your
enhancements,
please
get
them
ready
for
review
and
nothing
happens,
and
then
once
we're
two
weeks
out
from
the
deadline,
people
are
like:
okay,
fine,
I'm
working
on
it,
and
I
think
that
this
is
not
just
like
at
least
for
my
sort
of
info,
formal
polls
with
chairs
and
whatnot
it's.
This
is
not
just
me
experiencing
this.
B
It
sounds
like
this
is
pretty
common
people
are
very
deadline
driven,
and
so
one
thing
that
I
was
floating
around
is
making
a
suggestion
to
the
next
release
team
to
please
put
enhancements
freeze
earlier
in
the
cycle,
so
my
suggestion
would
be
week
two
instead
of
week,
four,
because
we're
not
really
getting
anything
done,
which
means
that
we've
got.
You
know
like
that
many
fewer
weeks
to
actually
get
code
written
because
things
don't
tend
to
get
fully
approved
until
the
enhancements
freeze
deadline,
at
least
in
my
experience.
B
So
lots
of
chairs
seemed
like
excited
about
this,
but
one
concern
is
that
it
reduces
the
amount
of
time
that
we
would
have
to
do
pr
review.
So
I
wanted
to
make
sure
that
I
raised
this
here
before
I
went
and
like
talked
to
the
release
team,
I
wanted
to
get
everybody
else's
feedback.
A
A
C
Oh
no,
okay,
so
I
have
a
reservation
not
related
to
so
we
have
a
lot
of
sig
that
have
a
two
week
meeting
cadence
and
while
it's
important
to
discuss
all
or
discuss
many
of
the
enhancements
at
those
meetings
ahead
of
time,
there
are
cases
where,
like
you
want
to
have
a
meeting
to
remind
people
that
you're
almost
there
and
then
maybe
one
to
discuss
some
outlying
issues
and
a
two-week
cycle
wouldn't
give
us
time
to
do
that.
A
I
I
hear
what
you're
saying
the
question
for
me
would
be
how
soon
the
schedule
gets
published.
You
know,
like
you,
can
start
doing
those
reminders
before
the
the
release
cycle
begins.
I
mean
usually
it's
not
like
it
might.
In
my
recollection,
it's
not
like.
Oh
we
ship
1.21
on
this
date
and,
and
that
starts
week
one
I
mean.
Usually
they
don't
even
have
a
schedule
together,
yet
at
least
last
time
they
didn't.
Maybe
that
that's,
maybe
I'm
I'm
just
recently
biased
here.
B
I
would
love
to
move
away
from
like
the
nag
driven
development
that
we
have
in
kubernetes
right
now
and
like
from
what
I
have
experienced
in
six
with
both
weekly
and
bi-weekly
meetings.
Nobody
seems
to
listen
at
the
first
announcement
in
the
first
bi-weekly
meeting
anyways.
It's
only
really
oh
darn.
It
we
forgot
in
the
like
the
sort
of
second
final
reminder.
B
B
Might
it
like
having
a
four-week
window,
ensures
that
if
sigs
have
bi-weekly
meetings
that
they
can
meet
twice
before,
caps
are
over
but
or
sorry
before
the
cap
deadline
comes
in,
but
I
am
vaguely
under
the
understanding
right
now
that,
like
I
think
we're
changing
the
requirements
such
that
sigs
only
have
to
meet
like
once,
every
three
weeks
or
four
weeks.
B
So
if
that
happens,
then
you
know,
like
people
could
potentially
completely
miss
this
window
and
I
think
it's
kind
of
on
six
to
make
sure
that
their
meetings
are
aligned
with
the
release
cycle.
So.
A
So
I
think,
I
think
what
I'm
going
to
say
is
david.
I
think
it's
a
valid
point
and
but
this
group's
not
the
one
to
really
make
the
point
with
like
if
you're
not
concerned
about
production
readiness-
let's,
let's
just
assume
that
for
the
for
this
group's
point
of
view,
we're
agnostic
unless
way
tech
is
as
a
concern
and
then
probably
bring
that
up
to
the
release
team
in
that
discussion,
because
we're
not
going
to
make
a
decision
here
right
with
regard.
D
To
that,
so
I
agree
yeah.
So
I
I
think
from
my
perspective,
like
from
purely
like
pr
perspective,
I
I
don't
have
any
strong
opinion.
D
I
think
that
I'm
not
sure
I
fully
buy
the
argument
that,
like
I
mean,
I
fully
agree
that
people
are
doing
everything
on
the
last
minute,
but
like
it's
not
that
like
as
soon
as
the
caps
are
approved,
they
start
working
on
the
implementation
and
they
they
like.
They
don't
manage
to
do
that
on
time
because,
like
the
the
coding
part
of
the
release
cycle
is
too
short,
it's
just.
B
I
think
that's
fair,
but
like
I'm
on
upstream
now,
full
time-
and
I
found
four
weeks
to
be
too
short
to
get
everything
done
and
the
release
that
I
needed
to
get
done.
Like
structured
logging,
we
had
that
like
started
from
the
get-go
and
like
we
ended
up
spilling
like
a
week
into
test,
freeze,
and
I
mean
to
be
fair.
B
That
was
a
very
large
thing,
with
a
ton
of
coordination
that
was
required,
but,
like
I
also
had
another
kept
that
I
was
doing
like
actual
code
implementation
changes
for
that
like
I
was
so
busy
dealing
with
bugs
in
the
first
half
of
the
cycle
that,
like
you,
know
like
it,
would
be
nice
to
be
able
to
spend
two
weeks,
crunching
bugs
and
then
like
work
on
my
feature
in
the
next
week
and
then
have
more
than
like
two
weeks
to
get
it
in
or
that's
the
off.
B
That
was
the
thing
that
I
was
personally
running
into,
which
kind
of
sucked
and
like
I'm
on
this
full-time
upstream
for
people
who
are
not
like
not
having
the
flexibility.
There,
I
think,
is,
you
know,
potentially
a
concern,
and
I
mean
obviously
people
are
like.
Oh,
but
like
you
could
always
get
your
cap
approved
earlier.
The
issue
is,
I
have
not
like
in
practice
seeing
people
getting
the
caps
approved
earlier
than
the
enhancements
freeze.
D
I
think
I
think
I
think
it
happens.
I
think
most,
the
most
of
the
cabs
that
I
was
driving
was
was
approved
somewhere
in
the
middle
or
like
towards
the
end
of
the
release
cycle,
and
that
was
preparation
for
the
next
three
days.
So
I
think
it
depends
on
like
when
exactly
you
come
up
with
the
idea
and
stuff
like
that.
C
Yeah
I
mean
api
machinery
ended
up
in
the
case
where
we
knew
about
three
weeks
in
advance.
What
it
was
we
were:
gonna
put
into
the
release
and
from
there
it
was
just
making
sure
that
they
were
done.
B
A
But
before
you
answer
that
the
other
I
wanted
to
make
another
point
which
I
I
jumped
like
the
specific
dates
I
mean
all
of
this.
Work
can
be
ongoing
anyway,
right
people
might
be
working
on
a
draft
of
a
cat
for
a
couple
of
weeks
before
they
even
put
a
pr
out
there.
So
so,
just
because
we're
not
seeing
pr's
doesn't
mean
works
not
happening,
so
we
also
have
to
think
about
that
that
if
we
shorten
that
time
period
that
could
affect
that.
A
Although
we
also
could
say
that
you
could
be
working
on
your
caps
for
the
next
release
right
now-
and
you
know,
and
probably
people
should
be-
I
am
exactly
good.
So
I'm
sorry,
I
do
just
want
to
table
this
because
it's
an
interesting
discussion,
but
we're
not
really
the
decision-making
group
for
this
particular
thing
here
and,
and
so
we're
just
gonna
end
up
repeating
all
of
these
arguments
at
the
release
team
meeting.
A
If,
when
you
bring
this
up
there,
so
I
I
think
that
I
personally
and
from
pr
point
of
view,
none
of
us,
I
think,
object
to
what
you're
saying
happy
to
have
a
discussion
offline
on
on
this.
But
I
know
we
have
time,
but
I
just
I
don't
like
to
have.
I
don't
know
I
just
again.
B
C
I
do
so,
I
remember
way
back
when
trying
to
build
out
the
list
of
how
do
we
know
we're
being
effective,
and
this
was
the
first
release
where
we
were
actually
gating,
and
I
want
to
make
sure
that
we
have
thought
ahead
enough
to
collect
numbers
from
120
to
be
able
to
compare
against
121,
to
figure
out
whether
we
were
as
successful
as
we
hoped.
A
I
am
not
now
what
we
we
ran
now,
a
year
ago,
ish
we
ran
when
we
first
started.
We
ran
that
survey
and
I
think
we
found
there's
some
things
we
could
improve
in
the
way
we
ask
questions,
but
we
may
want
to
what
I
had
intended
to
do
was
run
that
survey
periodically
at
least
twice
a
year
or
something,
but
we
haven't.
So
we
probably
should
do
that
soon,
tweak.
It
have
better
questions
like
there
were
some.
A
There
was
some
data
missing
and
when
we
went
to
do
the
analysis
like
which
specific
versions
did
you
roll
back,
we
didn't
really
have
that
if
I
recall
correctly,
but
you
should
probably
tweak
that
send
that
out
again
so
that
we
start
collecting
the
data
on
current
releases.
But
the
reality
is
right.
120
is
still
not
out
there
in
most
of
the
cloud
providers,
or
at
least,
if
it
is
it's
not
like
like
for
gke
at
least
it's
only
in
our
rapid
channel
with
you
know,
which
we
don't
recommend
for
production.
A
So
you
know.
C
I
will
point
out
some
vendors
have
shipped
120
and
can
have
num
ask
for
numbers
about
it,
but
I
agree
that
getting
something
out
now
we'll
be
able
to
gather
data
for
the
last
three
releases
fairly
easily
right.
I
think
we
should
go
ahead
and
do
that
so
that
we
have
some
sort
of
closer
baseline
for
comparison.
A
A
A
And
atlanta,
since
you've
joined
since
we
did,
this
would
love
it.
If
you
have
other
ideas
for
how
we
can
get
this
data
about
effectiveness
of
production
readiness
review,
we
had
quite
a
bit
of
discussion
on
it
when
we
first
started
up
the
program
and
it's
really
pretty
hard
to
measure,
because
a
lot
of
the
information
about
failures
and
things
like
that
aren't
necessarily
going
to
be
shared,
aren't
necessarily
easy
to
gather,
even
if
they
are
even
if
people
were
willing
to
share
them.
A
So
we
we
did
a
survey
way
back
when
and
learn
some
things
and
we'd,
like
you
know
we'll
do
it
we'll
do
another
survey
now
and
try
and
learn
some
things,
but
you
know
so
we
have
some
signal,
but
you
know
with
80,
80
or
so
respondents
last
time
it's
not
a
super
strong
signal,
but
it's
something.
C
A
Enable
alpha
in
production,
terrifying
amount.
C
A
C
A
What
I'll
do
is
I'll
plan
to
send
updated
survey,
questions
for
review
before
next
meeting
wow?
That
is
some
bad
typing.
A
Okay,
awesome
all
right,
I
think
that's
it's
high
time.
We
did
that.
Okay,
anything
else,
folks
or
shall
we
call
it
a
day.
A
Okay,
thank
you
all
we'll
see
you
in
a
couple
weeks.
Let's
get
our
items
done
before
then
and
we'll
be
we'll
be
getting
ourselves
ready
for
the
next.
The
next
go-around.