►
From YouTube: Kubernetes SIG Apps 20200113
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
B
B
Alright,
and
what
did
you
want
to
talk
about
with
regard
to
the
cap
right?
There
was
some
comments
on
the
cap
when
I
updated
the
cap
like
last
week
and
Jordan,
C
or
Martin's.
Here
we
wanted
to
discuss,
make
sure
the
kit
looks
good
so
that
we
can
go
ahead
and
start
implementing
it.
I
share
the
cap
in
a
minute.
Okay,.
B
A
I
do
so
I
was
reading
this
beforehand
and
I
do
have
one
comment
and
it's
actually
what
somebody
else
had
brought
up
and
it
was
it
was
in
the
implementation.
I've
lost
my
my
spa
tonight,
because
I
moved
on
from
reading
it
yeah
it
had
to
do
with
the
implementation
and
how
it
would
be
introduced.
Okay,.
A
Ken
and
Janet
had
previously
been
talking
about
an
alpha
one.
In
fact,
Janet
refers
to
it
in
a
comment
from
last
year
near
the
top
of
the
document,
and
she
said
we
need
an
alpha
controller
that
goes
alongside
the
current
one
that
you'd
opt
into,
and
then
after
that
shown
its
way,
then
we
could
promote
that
to
beta
and
replace
the
current
controller
with
it.
Okay,
so
and
that's
what
she
was
looking
for
in
the
time.
This
is
her
comment
from
June
12th
of
last
year:
okay
or
anything
Linda.
B
C
D
Yes,
this
is
machi.
That
was
the
original
plan
that
we
will
have
both
and
from
the
discussion
that
we
had
some
time
ago.
The
proposal
was
to
have
some
kind
of
feature
flag.
However,
you
would
be
able
to
name
to
enable
either
I'm,
not
sure
if
both
is
feasible
and
I
think
not,
but
each
separately
should
be
feasible,
and
on
top
of
that,
we
also
discuss
the
ability
of
running
the
entire
e
to
e
against
each
of
the
controller
controllers
separately,
to
ensure
that
we
maintain
the
functionality,
as
is
IC.
E
B
E
B
All
of
those
things,
that's
a
good
question,
so
that's
those
are
the
questions
that
I
also
had.
If
you
have
two
controllers,
so
I
would
think
we
would
introduce
the
status
only
for
v1
API
and
we'll
have
the
new
controller
targeting
the
v1
API
and
the
older
controller,
targeting
the
older
objects
and
as
sorry
as
we
deprecate
on
migrate,
we
will
recommend
the
customers
to
move
on
to
the
v1
API
and
then
it'll
get
the
new
state
automatically.
Alright.
E
That's
not
quite
how
it
guy
objects
work,
so
any
data
that
you
have
in
any
of
the
versions
needs
to
be
able
to
be
round
tripped
to
the
other
versions
so
that
it
doesn't
get
dropped
if
a
client
does
a
get
update
in
that
other
version.
So
if
we
add
status
fields,
we
would
add
them
to
the
beta
version,
as
well
as
the
v1
version.
So
we
don't
have.
E
B
F
B
E
That
seems
like
the
kind
of
thing
that
could
be
like
if
you
have
a
single
method
that
handles
a
cron
job,
and
then
you
beat
a
cron
job
to
it,
either
based
on
polling
or
based
on
like
an
informer
with
a
in
queue
method.
It
seems
like
you
can
switch
the
method
without
reimplemented
everything
about
the
control.
C
B
D
B
E
The
the
way
that
we
support
controllers
today
once
we
release
the
v1
API
mm-hmm,
the
next
release.
We
can
update
the
controller
to
speak
to
the
v1
API
and
ok.
So
if
you
continue
to
implement
against
the
v1
beta
one
API,
which
needs
to
have
the
data
present
in
order
to
round-trip
these
new
fields
successfully.
Okay,.
E
B
A
So
in
functionally
speaking,
if
I
hear
this
right,
we
would
probably
add
these
fields
as
part
of
a
V
1
beta,
2,
API
and
we'd
have
two
separate
controllers.
When
you
can
opt
in
to
use
the
new
version,
it
would
be
alpha
and
you
wouldn't
have
both
running
it
would
be
one
or
the
other,
and
they
would
both
support.
The
V
1
beta
2
API
well.
C
A
That's
true
right
and,
and
so
both
controllers
would
do
that
and
then,
if
the
alpha
controller
works
well
and
we
work
out
the
bugs
on
that,
and
that
would
be
promoted
to
a
beta
controller
and
the
old
controller
could
be
removed
and
entirely
and
it
would
be
no
switch
anymore.
The
new
controller
would
be
in
place
and
then
we
would
have
that
for
a
release
and
once
that
all
proved
out
with
the
new
controller
and
the
API,
then
all
of
it
would
be
promoted
to
GA.
Okay,
that's
not
about
right,
I,
I,.
E
D
More
changes
required
with
regards
to
scheduling,
maybe
not
necessarily
with
adding
cron
jobs,
but
it's
more
about
when
people
start
modifying.
So
imagine
you
have
a
current
cron
job
that
triggers
every
an
hour
and
you
have
and
you
basically
create
a
queue
with
the
upcoming
jobs
so
that
they
are
served
within
the
next
hour
within
to
whatever
and
then
user
comes
in,
and
he
modifies
that
the
current
cron
job
to
be
wrong
every
half
an
hour.
D
That's
that
part
of
the
scheduling
inside
of
a
cron
job
controller
will
require
significant
rewrite
because
in
the
preview,
the
current
one
you
will
you're
always
pulling
and
you're
just
reacting
to
to
the
current
time.
Whereas
with
the
informal
based
approach,
you
need
to
react
on
two
events
happening
on
a
cron
job,
but
at
the
same
time
you
still
need
to
schedule
the
cron
jobs
at
the
specific
point
in
time.
D
E
With
fake
clocks
and
failure,
and
if
I'm
just
trying
to
understand
a
scenario
where
we
ship
a
second
controller
that
operates
on
these
additional
capabilities,
but
we
haven't
tested
it
well
enough
to
be
confident
or
in
replacing
the
current
controller.
That
we
know
has
significant
issues
so
like
well.
The
current.
A
Controller
has
significant
issues.
I
do
want
to
point
out
that
the
controller
is
widely
used
in
production,
so
the
issues
with
it
are
really
really
well
known
and
so
switching
from
one
controller
to
another
with
something
that's
just
widely
used,
I
mean
we
say
our
our
beta
stuff
shouldn't
be
used
in
production
right,
but
it's
massively
widely
used
in
production
today,
and
so
that's
one
of
the
reasons
that
we'd
like
to
take
a
little
bit
more
care
and
hand-holding
with
it.
E
Are
well
known,
but
they're
issues
like
we
can
schedule
multiple
jobs
in
pathological
matter
yeah.
It's
not
that
it's
not
just
the
ones
where
like.
If
you
have
more
than
500
cron
jobs,
it
doesn't
behave
well,
it
is
actually
like
scheduling
problems
with
the
current
one.
If
a
node
goes
away
and
then
comes
back,
you
can
schedule
a
bunch
of
jobs.
I
think
things
like
that.
That
I
would
expect
the
new
controller
to
add
test
scenarios
for.
D
Yes
right,
but
the
problem
is
still
the
term
between
what
we
have
currently
and
will
be
ship
and
then,
at
the
same
time,
I
would
like
to
be
able
to
put
the
users
to
give
it
a
try
to
the
new
controller.
It
will
take
some
amount
of
time
of
testing
and
the
testing
that
you've
mentioned
is
just
an
initial
part.
D
I
would
still
want
to
somehow
protect
the
users
from
being
thrown
into
a
new
controller
that
we
like,
no
matter
how
much
testing
we'll
put
into
it
at
this
point
in
time,
it
still
will
be
a
rather
limited
amount
of
testing.
I
want
to
have
the
controller
being
tested
by
actual
users
to
ensure
that
when
we
do
the
switch
it
is,
it
was
more
or
less
verified
by
other
people
not
just
one
ago,
not
just
us.
D
B
E
I
I
would
expect
this
to
be
a
feature,
a
feature
gate
and
so
the
the
way
feature
gates
works.
They
start
in
alpha
disabled
by
default
oke.
Then
they
move
to
beta
and
are
typically
enabled
by
default
at
that
point,
okay
and
then,
when
they
graduate
to
GA,
they
get
locked
to
be
true,
and
we
announced
that
this
feature
is
now
GA
and
the
feature
gate
will
be
removed
in
the
next
release,
and
so
it
it's
just
a
monotonic
like
a
ratcheting
enablement.
C
E
E
E
B
E
And
so,
while
the
API
is
in
beta
like
before,
it
has
gone
to
a
ga
API,
if
you
are
making
changes
that
are
additive
and
backwards
compatible,
so
things
like
reflecting
more
status
into
the
API,
those
additive
changes
can
be
made
in
the
existing
API
versions.
Typically,
you
make
the
additions
you
want.
You
get
them
tested.
Once
you
have
user
feedback
on
sort
of
the
final
shape
of
the
API,
then
we
typically
promote
it
to
GA,
with
no
changes.
B
E
B
So
added
a
bunch
of
desiccated
nan
who
is
on
on
the
call
added
a
bunch
of
test
cases.
We
want
to
make
sure
that
I
mean
these
are
just
starting.
We
will
obviously
add
more,
but
do
you
see
something
signe
significant,
that's
missing!
Please
call
and
comment
on.
The
cap
really
include
those
as
well
like
for
scale
testing.
E
I
would
I
would
work
with
six
scalability
on
that
question.
In
particular,
we
did
similar
things
when
we
were
defining
scale
limits
for
custom
resources
grande
for
custom
resources.
The
dimensions
we
found
helpful
were
like
the
average
size
of
the
custom
resource,
because
the
schema
is
arbitrary.
You're
these,
it
might
be
things
like
the
interval,
so
the
rate
at
which
the
cron
job
is
going
to
spawn
jobs
and
then
the
scale
of
those
jobs,
just
gonna
define
parameters
that
we
have
tested.
Okay,.
B
E
Mean
for
a
resource
whose
job
is
to
make
sure
things
run
at
specific
intervals.
That
seemed
like
an
important
thing
to
at
least
describe
the
guarantees
around
a
and
and
definitely
describe
the
policies
like
if
the
controller
manager
is
not
running
when
a
job
is
supposed
to
be
fired
like
it
doesn't
matter
how
good
our
code
is.
If
it's
not
running,
it's
not
gonna,
create
the
job
and
so
being
really
clear
about
what
happens
when
it
starts
back
up.
Does
it
yeah.
B
E
So
so
the
things
we
need
to
do
are
defined
very
clearly
what
the
policies
are.
If
the
controller
is
not
running
when
it
should
be
starting
a
job
and
then
test
that
what
we
describe
actually
happens.
So
if
we
say
it
skips
jobs,
and
we
should
test
that,
that's
what
happens
if
we
say
it
like
spawns
them.
We
should
test
that
if
we
say
you
have
an
option,
we
should
test
the
option
and
then
specifically
for
someone
monitoring
that
cluster.
E
A
B
D
Oh
so,
there's
there's
when
talking
about
jaw
being
glades
on
being
spawned
by
cron
job
controller
ain't,
take
into
account
that
the
user
can
modify
deadlines
or
starting
a
job.
It
is
called
starting
deadlines
seconds.
I,
remember
that
we
had
something
like
that,
but
did
not
remember
the
field
name.
So
there
is
an
option
for
a
user
to
specify
a
bigger,
not.
D
B
Okay,
correct
yeah,
so
I
know
there
is
a
starting
deadline,
but
if
you
mess
you
don't
start
the
job,
but
there's
yeah.
That
is
pretty
much
it.
So
do
you?
Okay,
do
you
need
jitter
around
this?
Some
timers
have
a
jitter
configuration
which
allow
which
prevent
the
thundering
herd's
as
which
is
acceptable
for
that
object.
B
E
B
A
D
C
So
this
is,
we
were
working
on
taking
pdbs
to
GA,
there's
a
link
here
to
the
project
which
tracks
these
issues
and
I'm,
taking
this
opportunity
to
ask
for
more
people
to
look
at
those
issues
and
PRS
I.
Think
some
of
the
PRS
are
relatively
small
and
straightforward
other
have
deeper
sort
of
questions
that
needs
more
discussion
before
we
can
decide.
If
you
want
to
do
something
about
it
or
if
and
if
so,
what
should
I
be.
A
F
D
A
I
had
a
discussion
just
past
week
about
PD
B's
I,
think
there's
some
mold
sending
issue,
not
sure
if
it's
even
described
well,
it
was
brought
to
my
attention
just
like,
like
I'm
saying,
like
I'm
saying
last
week:
I'll
have
a
look
at
it
and
then
I'll
go
through
through
the
changes
that
we
have
do
you
have
any
timeframes
for
when
you're
planning
to
GA
PDP's?
Is
it
like
118
think
or
it's
rather
you're
trying
to
pass
the
road
pave
the
road
towards
that
one
and
one
of
the
next
releases
I.
C
Think,
if
it's
well
as
soon
as
possible,
but
if
we
can
make
or
address
all
issues
and
make
all
the
change
we
need
for
118,
that's
great,
if
not
we'll
the
plot.
My
plan
is
to
keep
pushing
and
then
see
if
we
can
into
119.
So
it
depends
really
on
how
long
it
takes
to
get
through
the
the
outstanding
issues.
I.
E
D
C
E
E
Then
we
have,
you
know
a
whole
set
of
potential
pods
that
we
can
encounter
and
I
think
if
we
just
make
a
table
of
you
know
for
this
input
and
this
type
of
pod.
This
is
how
we
behave,
and
then
we
can
you
shop
that
around
and
get
feedback
on
back.
There
are
a
lot
of
really
undefined
cases
today,
I
mean.
D
Basically,
what
I'm
hearing
from
Jordan
is
start
a
CAC
describing
the
outcomes
and
then
maybe
it
would
be
reasonable
to
set
it
out.
Yeah
I.
E
A
E
We
started
surveying,
you
know
like
I
said:
GA
just
doesn't
just
mean
the
API.
It
also
means,
like
we've,
looked
at
many
bugs
and
we're
confident
that
they're,
minor
or
addressable-
and
we
are
now
so
I-
would
I
think
an
update
to
the
cap
that
adds
this
specification
and
documentation
both.
So
we
conviction,
we've
implemented
it
and
tested
it,
but
also
so
users
who
want
to
use
this
thing
can
reason
about
what
it
is
they're
even
using
and.
D
E
D
C
A
C
Yeah
I
can
I
can
take
that
on
and
try
to
update
the
cap
with
some
of
the
information
I
try
to
I
think
some
of
these
things
are
discussed
in
a
couple
of
issues
and
PR
surrounds
I.
Try
to
get
that
all
into
one
place,
so
people
can
find
it
and
then
yeah
see.
If
we
can
get
the
right
people
to
look
at
it
and
then
hopefully
decide
what
we
have.
We
want
it
to
work.
Yeah.
E
It
would
also
be
helpful
to
point
to
any
existing
documentation,
whether
that's
like
website
documentation
or
API
documentation.
So
we
know
if
we've
made
specific
promises
to
users
already
like
explicit
ones,
then
we
should
definitely
honor
those
and
then,
in
this
too,
in
this
grid
of
inputs
and
outputs
describing
what
the
current
behavior
is
would
be
helpful
as
well,
because
that
that's
sort
of
an
implicit
promise
to
users
about
how
it
should
behave
and
in
the
absence
of
clear
communication,
they
will
expect
it
to
keep
it
hitting
that
way.
Yeah.
E
So,
when
the
current
behavior
is
it
errors
and
blocks
all
your
operations
like
that's
a
thing
that
we
could
maybe
improve
and
and
make
stopped
airing,
but
even
there
we
need
to
be
careful
because
it's
possible
that
someone
is
counting
on
it.
Blocking
operations
yeah,
so
yeah
describing
the
crime
behavior
would
be
a
great
starting
plea.
Please
yep
I'll.
C
A
H
Hi,
my
name
is
Ashish.
I
am
working
on
the
execution
hooks
implementation
of
the
execution
hooks,
so
I
wanted
to
kind
of
get
folks
to
look
at
an
ongoing
PR
that
I
have
and
kind
of
solicit
feedback
and
make
progress
so
feel
free
to
take
a
look
at
the
PR
I
put
a
link
to
the
PR
on
the
meeting
notes
so
that
that
was
just
an
announcement
from
my
end,
I'm
happy
to
walk
through
the
changes
or
what
is
the
status.
So
let
me
know
if
folks
are
interested
in
doing
that.
H
So
the
whole
idea
is
so
we
have
part
life
ii
books
right,
so
things
to
run
before,
starting
apart
and
things
to
run
when
a
part
is
terminated.
But
there
is
this
specific
scenario
say
you
want
to
snapshot
a
volume,
that's
mounted
by
a
pod,
so
before
you
actually
can
do
that
I
apologize
for
the
background
noise.
H
Let
me
know
if
it's
getting
too
much
now,
but
so,
if
the
part
has
a
volume
mounted-
and
you
want
to
snapshot
that
volume
you
want,
we
want
to
first
query
for
the
database
of
me
think
that
right,
that
is,
writing
the
volume
make
it
stop.
Writing
and
then
take
a
snapshot
to
kind
of
make
it
in
an
application,
consistent
snapshot
so
that
the
application
can
just
restart
from
so
to
perform
such
operations.
H
You
want
to
be
able
to
run
specific
commands
on
a
part
or
inside
a
container
more
specifically,
and
those
are
the
so
that
is
where
an
application
execution
hook
would
come
into
place.
So
somebody
would
create
an
execution
hook
which
is
associated
with
a
hook
action
and
then
vents
when
the
controller.
When
the
execution
of
controller
sees
such
an
object
being
created,
it
will
go
and
run
that
action
on
the
half
of
thing.
A
Dropped
it
in
the
chat
here.
If
somebody
wants
to
open
up
the
cap
on
earth,
it
originally
came
out
of
safe
storage,
but
it
made
more
and
I
think
they
wanted
to
use
it
for
things
like
backups
and
but
it's
far
more
of
an
Apps
related
thing,
because
there's
more
things
you
can
do
with
it
than
storage,
which
is
how
the
discussion
landed
over
here.