►
From YouTube: 20210830 SIG Arch KEP Reading
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
Okay,
awesome
so
for
folks
who
are
new
here,
what
we
do
here
is
basically
every
two
weeks
we
ask
people
if
there
are
any
caps
that
they're
interested
in
discussing
and
whatever
caps
are
of
interest.
We
take
around
10
minutes
per
cap,
so
we
take
two
caps
per
session.
A
We
take
around
10
minutes,
reading
it
and
then
post
that
discussing
it.
So
in
terms
of
maybe
questions
or
feedback
or
anything
of
that
sort,
or
if
the
author
is
on
the
call,
if
they
want
feedback,
they
can
ask
for
specific
feedback
as
well.
That's
the
whole
point
of
it
and
like
this
is
just
to
familiarize
ourselves
with,
like
the
whole
kept
process,
and
I'm
saying
kept
a
lot
for
folks
who
are
not
familiar
kept
stands
for
kubernetes
enhancement
proportions.
It's
it's
like
a
detailed
document.
A
If
you
want
to
add,
update
or
deprecate
features
in
kubernetes
that
you
have
to
go
through
that
process.
So
that's
what
we're
trying
to
familiar
familiarize
ourselves
with.
We
have
one
kept
on
the
agenda,
which
is
cube,
cuddle
sub
resource.
I
think
the
author
is
on
the
call
hi
you
guys
thanks
for
joining.
So
let's
take
10
minutes
and
read
that
like
go
through
the
cap,
we
can
extend
it
because
we
have
this
one
kept
today.
A
A
Okay,
I'm
guessing
that's
a
no,
so
we
can
probably
start
so.
The
folks
have
questions
right
after
that.
A
All
right,
so
I
have
a
question
so
is
there?
Is
there
like
any
difference
in
the
way
in
like
the
implementation
of
cube,
curtail
scale
and
you've
got
new
patch,
hyphen
knife
and
sub
resource
screen?.
B
So
scale
necessarily
of
updates
the
scales
of
resource
weight
patch
is
up
to
you.
You
can.
You
can
actually
send
in
any
patch
object
to
update
the
update
the
underlying
object-
and
in
this
case,
as
as
far
as
this
particular
sub
kept,
goes
the
sub
resource.
At
that
point,
adding
the
surprises
flag
at
that
point
sends
a
patch
on
the
surface
source
object
on
the
scale
sub
resource,
okay,
so,
okay,
let's
see
upgrade.
A
All
right,
so
I'm
guessing
this
will
be
alpha
and
123.
B
You
know
yes,
so
the
that's
the
timeline
for
it,
so
this
will
be
alpha
in
123,
and
one
of
the
things
that
you
probably
would
have
observed
is
cube.
Cuddle
applied,
doesn't
support
sub
resource,
yet
right
because
cubecut
will
apply,
is
a
very
tricky
command
to
deal
with
because
of
clients
that
apply
and
the
last
separate
annotation
and
so
on.
So
initially
it
will,
it's
only
going
to
be
get
edit
patch
and
replace,
and
once
we
collect
user
feedback
on
what
else
needs
to
be
added?
B
What
changes
do
we
want
to
see,
or
if
this
is
okay
with
the
way
it
is
we'll
also
start
that
will
be
at
least
in
like
the
next
cycle.
Besides
that,
we'll
also
look
into
what
is
the
best
way
we
can
work
work
out,
supporting
subresource
with
the
apply
command
as
well.
A
A
B
I
believe
logs
are
not,
I
mean
so
initially
this
skip
does
not
does
not
work.
Does
not
it's
not
going
to
work
with
other
subresources,
it's
going
to
focus
only
on
status
and
scale
because,
like
edit
and
patch
on
logs,
that
does
not
make
a
lot
of
sense.
We
only
make
get
and
we
have
get
for
that.
It
doesn't
make
sense
to
get
sub
resource
law
of
get
logs
of
sub
resource
status,
because
that's
not
a
thing
right.
A
Okay,
so
moving
to
like,
for
example,
so
this
is
planned
for
alpha
and
123..
A
So
typically,
this
is
just
like
a
general
question
not
related
to
the
cap,
so
typically,
how
many
cycles
does
it
take
to
move
from
alpha
to
beta,
like
considering
the
previous
cadence,
because
we
don't
really
have
too
much
experience
with
the
new
one
or
is
there
like
a
fixed
number
of
cycles?
Typically.
B
Or
that
depends,
I
think,
and
eddie
can
correct
me
if
I'm
wrong,
I
don't
think
there
is
a
fixed
number
of
cycles.
It
depends
from
kept
to
cap
on
what
what
feedback
need
to
be
addressed
and
what
features
need
to
be
added,
but
I
would
assume
at
least
for
this
skip
it's
going
to
be
one
cycle
per
iteration
right,
so
alpha
to
beta
is
one
beta
to
gamma
beta
to
ga
is
one
and
so
on.
C
B
Yeah,
so
we
broke
down
the
original
pr
into
two
different
ones,
one
to
change
the
api
server.
I
want
to
change
the
client
side,
there's
still
some
feedback
that
I
need
to
address
on
the
api
server
change,
but
once
that's
merged
we
can
get
the
client
side
key
out
merged
and
then
we'll
have
it
ready
boundary
awesome.
A
So,
moving
to
like
the
work
for
beta
right,
so
other
than
user
feedback
are,
there
is.
Is
there
like?
Basically,
what
work
needs
to
be
done
or
is
work
planned
out.
B
As
such,
so
one
is
the
apply
command
like
basically,
basically
adding
some
resource
support
for
the
apply
command,
but
it
still
needs
some
more
time
to
look
into
what
needs
to
be
done
for
the
apply
command
to
work
because
of
both
the
clients
that
apply
and
serve
sort
of
play
and
if
it
even
warrants
like
its
own,
separate,
kept
to
figure
out
how
to
work
some
resources
and
to
apply
command
right.
B
So
for
the
initial
alpha
phase,
it's
just
going
to
be
the
other
commands
the
get
edit
patch
and
replace,
and
for
beta.
The
primary
focus
is
going
to
be
collect
user
feedback
and
see
if
there
are
any
other
items
that
need
to
be
addressed.
But,
as
I
mentioned
in
parallel,
apply
command
is
something
that
we'll
be
looking
at.
A
Like
I
heard
this
a
lot
right,
like
collecting
user
feedback,
getting
the
what
the
community
feels
about
it,
so
how
is
it
usually
done
so
do
you?
Is
it
done
by
our
people
submitting
their
feedback
out
of
their
own
volition,
on
like
kk,
for
example,
or
is.
A
A
survey
of
sorts
that
goes
out
for
any
particular
feature
or
a
release
for
in
general
so
like.
How
does
that.
B
A
Okay,
that
makes
sense
okay,
so
I
don't
have
any
more
questions.
So
does
anyone
have
more
questions
on
this
kept?
In
particular.
D
A
D
A
question
the
initial,
so
this
is
my
first
time
here,
decorating
club,
so
I
want
to
build
upon
the
initial
question
that.
C
B
Flag,
yeah,
yeah,
definitely
so
scale.
The
scale
command
is
very
specific
for
that
one
use
case,
but
the
patch
combined
with
the
sub
resource
flag,
is
for
a
general
use
case
right.
You
can
use
it
even
to
like
update
status,
sub
resource,
or
in
this
case
you
can
also
use
it
to
update
the
scales
of
this.
D
Okay,
okay,
so
basically
the
scale
commands
comes
handy
in
case
of
when
we
have
deployment
or
those
type
of
resources
and
sort
of
this
is
more.
This
takes
a
more
generic
approach
here,.
B
So
that's
the
focus,
so
that's
the
focus
that
that's
the
set
of
people
we
are
trying
to
this
skip
will
try
to
add
this
and
help,
but
the
scale
command
is
more
like
publicly
available
to
the
general
audience
of
kubernetes
who
want
to
interact
like
deployments
and
so
on
and
scale
up
scale
alone
and
stuff.
So
to
better
answer
your
question,
we,
I
don't
expect
people
to
use
like
patch,
with
sub
resource
scale,
to
like
scale
up
or
scale
down
deployments.
B
It's
going
to
be
through
the
scale
command,
but
the
subresource
command
subresource
flag
is
going
to
be
more
towards,
like
testing
other
things
and
then
figuring
out
how
that
works,
and
maybe
like
changing
these
observed
replicas
on
the
scale
object
instead
of
the
desired
replicas
on
the
scale.
Object
to
see
how
the
reconciler
would
then
act
and
so
on.
D
Okay:
okay,
one
more
thing
not
related
to
this
gap,
but
can
I
get
to
know
what
all
other
sub
resources
there's
a
list
somewhere
or
it's
maintained
somewhere?
Then?
What
are
the
summary
sources
that
are
available.
B
To
be
honest,
I
don't
know
the
full
list
of
all
the
sub-resources
available
on
all
the
resources,
but
a
good
way
to
figure
out
what
all
are
available
is.
Once
you
have
a
cluster,
you
can
do
like
you,
cuddle
api
resources
and
that
I
think,
spits
out
a
bunch
of
resources
that
are
available,
which
will
also
understand
if
there
are
being
some
resources.
I
believe.
A
I
I'll
take
it
as
a
no,
so
I
think
we
can
like
move
on
taking
a
look
at
maybe
the
enhancement
tracking
sheet
of,
what's
going
on
in
123
till
now
and
see
how
things
are
going
so
that
we,
I
think
we
can
like
share
screen
for
this
location
on
the
screen.
A
Yep,
okay,
awesome
thanks!
Okay,
so
I
think
till
now
we
have
around
10
caps
that
have
been
opted
in.
Most
of
them
are
from
auth
and
storage.
A
I
think
node
plans
to
update
their
opt-in
tips
by
this
week
or
early
next
week,
probably
because
for
the
past
two
two
and
a
half
weeks
they've
been
discussing
what
caps
they
want
to
work
on
or
like
what
gaps
are
optimal
in
for
this
particular
release
cycle,
and
I
there
were
quite
a
few
caps
from
node
this
time
as
well,
so
this
list
should
be
much
more
fleshed
out.
I
think
by
next
week
at
least
I
think,
there's
like
a
soft
pr
deadline,
this
time
right
so
wait
today.
A
I
think
in
the
next
four
days
is
the
pr
deadline
for
caps,
so
folks
will
probably
be
getting
their
caps
in
here
now
soon.
So
this
is
already
a
lot
from
storage
this
time
around.
So
storage
might
be
interesting,
so
we
can
probably
like
take
a
look
at
a
few
of
them
in
the
next
meeting.
So
if
anyone
here
would
like
to
is
interested
in
like
any
of
these
questions,
please
either
reach
out
or
like
add
it
in
the
agenda
doc,
but.
A
Another
thing
is
that
so
one
more
thing
I
wanted
to
discuss
was:
maybe
we
can
start
doing
like
something
other
than
other
than
isn't
something
in
addition
to
what
we
are
currently
doing,
that
is
like
reading
gaps
and
discussing
them.
That
is.
Can
we
maybe
pick
up
caps
to
like
discuss
that
are
in
the
current
cycle,
all
also
in
hopes
of
maybe
getting
new
folks
like
helping
out
with
implementation
of
these
steps,
because.
A
There
is
always
help
needed
in
at
least
testing,
so
maybe
folks
can
get
started
there.
So
another
thing
to
make
that
happen
is
that
we
need
to
get
kept
suggested
early
on
so
that
we
can
hopefully
try
and
contact
the
author
and
like
get
them
on
the
call,
if,
if
at
all,
like
time
zone
perfect,
so
that's
one
thing:
let's
see,
let's
see
if
we
can
like
try
and
make
that
happen
next
time,
so
next
one
will
be
14
15
september.
C
So
I
I
think
that's
a
great
idea.
I
think
that
that's
what
dims-
and
I
originally
had
in
mind
too,
was
during
enhancements
early
period
going
through
like
what's
on
the
tracking
sheet,
and
once
we
pick
those
caps,
we
can
send
reminder
emails
and
like
if
it's
a
six
storage
cap,
we
can
email,
six
stores
be
like
hey,
we're,
gonna
be
doing
a
kept.
Reading
of
this,
hopefully
get
some
other
folks
involved
too.
A
A
B
A
B
Comes
to
api
change,
of
course,
having
all
the
tests
in
place
is
very
important
for
a
pr
to
merge,
because
not
only
because
it
tests
your
stability,
but
also
it
establishes
contract
for
having
backward
compatibility
with
for
like
10
minus
one
and
minus
two
versions.
So
that's
one
thing
right
so
if
and
and
one
thing
to
keep
in
mind
is
especially
when
it
came
to
this
cap
was
the
api
that
you
are
talking
to
is
not
people
don't
not
only
use
it
through
cube
cuddle,
but
through
other
forms
as
well.
B
B
Try
to
start
like
get
your
pr
up
and
try
to
get
feedback
very
early,
because
the
folks
that
review
the
api
changes
are
generally
a
little
occupied
and
it
would
be
nice
if
you
give
them
a
lot
of
time
to
be
able
to
review
your
prs
because
they
are
pretty
busy
crazy.
Folks,.
B
The
same
goes
with
other
other
parts
of
other
six,
as
well
so
in
general,
or
get
your
pr's
up
early
and
then
even
up
working
and
try
to
get
feedback
early.
So
they
can
access.
It.
Don't
delay
till
the
last
week
to
get
your
kept
merged.
C
A
So
has
cli
like
operating
gaps
yet
or
is
it
yet
to
do
it.
C
No
we're
going
to
talk
about
it
next
this
week.
Whatever
our
next
meeting
is,
I
think
we
have
a
couple
debug
caps
that
are
lingering
and
waiting
to
get
in.
I
have
my
delete
cap
that
I
need
to
get
pushed
in.
I
actually
I
built
a
demo
for
it
on
friday.
I
have
to
record
that
and
send
an
email
out.
We
had
a
couple
other
ones,
but
I
don't
think
they're
going
to
make
123.
C
it's
what's
interesting
and
I
think
we
need
to
talk
about
this
as
a
project.
Again
is
we've
shortened
the
cap
opt-in
window,
but
we've
extended
the
extension
window,
so
we've
made
it
so
that
it's
a
still
a
decent
amount
of
time,
but
the
open.
You
know
opt-in,
is
like
week
three
of
the
release
already
and
the
extension
window
doesn't
end
for
at
least
another
three
to
four
weeks
after
that.
So
I
don't
know.
I
think
there
needs
to
be
more
of
a
balance
between
the
cutoff
and
the
extension.
A
I'm
hoping
like
so
I
think
this
is
the
second
release
which
is
on
the
elongated
cadence,
so
I'm
hoping
they'll
collect
some
feedback
and
work
with
just
like
six
in
general,
because
I
feel,
like
everyone
will
have
a
lot
of
changes
to
go
through
and
you
you
will
probably
get
a
few,
not
a
few,
but
like
a
lot
of
good
feedback
points
to
work
with.
C
C
A
I
think
we've
discussed
that
one.
Oh.
A
C
C
A
Yep,
so
I'm
guessing,
we
can
call
this
meeting.
A
Yeah
sorry,
my
laptop
glitched
for
a
second
there,
so
yeah.
So
thanks
so
much
for
joining,
see
you
folks
next
time
and
please
just
like
keep
an
eye
on
the
tracking
sheet.
If
anything,
pops
up
add
it
to
the
agenda
and
we
can
discuss
it
further
and
we
can
contact
the
authors
as
well.