►
From YouTube: Kubernetes SIG Apps 20190729
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
So
the
goal
of
this
is
to
add
a
concurrency
policy
in
cron
job
called
ketchup
such
that
missed
jobs,
are
not
skipped
and
will
be
scheduled
in
sequential
order
instead.
So
the
motivation
behind
this
is
that
currently
in
kubernetes
cron
job,
if
any
task
is
missed,
a
cron
job
controller
will
simply
just
skip,
skip
it
and
immediately,
no
matter
what
concurrency
policy
is
in
use.
So
is
it
totally
fine
at
the
moment,
because
during
any
cron
job
currently
only
supports
kind
of
stateless
front
drop?
B
However,
it
doesn't
like
fit
for
cron
jobs
that
does
meet
that
needs
to
know
the
exact
time
range
of
the
data
is
going
to
process.
For
example,
I
can
have
a
cron
job
that
runs
every
hour
and
only
process
logs
within
the
previous
hour
say
due
to
some
bugs
or
issues
the
job.
Now
temporarily
takes
three
hours
too
long.
So,
with
current
cron
job
set
up,
multiple
jobs
will
be
skipped
in
the
middle
and
is
really
hard
to
back
them.
B
So
that's
why
I
propose
to
add
a
behavior
called
ketchup.
So,
instead
of
skipping
one
of
those
jobs,
we
kind
of
skip
stack
them
up
and
schedule
them
one
by
one.
You
see
quench
water,
so
no
the
task
is
missed,
so
the
feature
by
itself
isn't
that
like
powerful
enough,
so
I
propose
to
our
other
minor
improvements
along
with
this
feature,
the
first
one
is
I
like
to
expose
the
original
and
run
time
of
the
job
in
the
job
object.
B
So,
with
this
information
available,
the
job,
the
catch
off
behavior
could
be
more
powerful
and
useful,
because
first
of
all,
the
job
could
take
this
timestamp
and
figure
out
what
time
range
data
it
should
process
I'm.
Second
of
all,
it
could
make
back
feel
a
lot
easier
because
we
know
which
time
range,
what
webpack
fitting
the
third
one
is-
enables
more
complicated,
scheduler
logic.
For
example,
we
might
want
to
instrument
the
tenth
start
time
end
time,
or
maybe
you
have
some
offset
of
the
actual
start
and
end
time.
B
So
that's
the
first
minor
improvement,
so
the
second
one
is
currently
we
have
this
maximum
100
missed
schedules,
checks
which
says
for
all
concurrency
policy.
I
would
like
to
change
that
to
only
check
it
when
the
concurrency
policy
that
said
to
allow
so
the
I
think
the
original
implementation
that
said
added
this
Travis
camp
on
it,
because
it
tries
to
prevent
a
some
scenario
if
there's
a
copy
or
something
in
my
launch,
a
million
say
million
tasks
at
the
same
time,
if
concurrent
behavior
is
allowed.
B
However,
this
is
this
particular
scenario
is
trying
to
prevent,
actually
doesn't
exist
at
all
and
based
on
the
current
coding
temptation,
because
currently
in
the
code,
if
multiple
unmasked
schedules
are
seen,
it
will
only
take
the
pic
the
latest
one.
There's
no,
no
scenario.
It
will
launch
like
multiple
jobs
at
once
in
the
in
the
controller.
B
B
By
doing
by
only
checking
the
camp
on
allowed,
so
that
means
in
in
forbidden,
for
example,
in
forbidden
at
the
moment,
if
we
have
say
a
thousand
missed
tasks
in
the
middle
right
now,
it
will
simply
just
say:
oh
I
can't
cannot
determine
the
job
needs
to
be
started
because
there
are
too
many
missed
start
time.
Instead
of
saying
like
that,
it
will
just
simply
skip
all
previous,
a
thousand
or
whatever
a-ha
a-ha,
whatever
missed
jobs
and
started
from
the
latest
one.
B
So
that
makes
more
make
things
a
little
less
complicated,
yeah.
So
pretty
much.
It
is
the
for
the
summary
of
the
key.
The
proposal
I
made
so
I'd
like
to
you
know:
enjoins
million
seek
any.
You
know,
thoughts
and
comments
on
us
and
hopefully
can
get
someone
get
it
reviewed
sometime
and
if
you
any
any,
you
know,
questions
feel
free
to
ask.
B
D
Yeah
I
think
the
policy
is
generally
useful.
I
think
my
video
corner
cases
will
be
slightly
hard
to
catch
like
if
you
wake
up
after
a
year,
because
the
time
has
changed
or
something
on
the
server.
You
probably
don't
want
to
go
crazy
about
creating
all
those
job,
but
I
think
that
can
be
handled
and
I
haven't
read
the
proposal.
Sorry,
if
it's
some
hard
Eric's
I
have
compared
machi.
He
should
be
back
next
weeks
and
we
can
take
a
look
as
well,
because
people,
the
cron
jobs
or
is
managing
them
for
us.
B
B
A
A
E
Yeah
yeah,
so,
okay,
he
may
have
disappeared
on
us,
which
is
why
we
don't
hear
him
jumping
in
here
and
we
had
some
of
these
silence
problems.
So
for
the
moment,
I'll
talk
until
he
comes
back,
try
to
fill
in
Adnan
if
you're
there
feel
free
to
jump
back
in,
if
not
hey,
sorry
I'm
back.
Oh.
A
E
E
E
Thank
you
for
submitting
it.
The
use
case
is
I,
understand
the
use
case
and
we'll
take
a
look.
Thank
you.
The
next
topic
we
have
is
should
sig
apps
move
to
bi-weekly
calls
I'm
the
one
who
added
this
so
I'm
happy
to
speak
up
on
it.
The
reason
that
we
ask
this
question
is
quite
often
we
have
enough
for
maybe
half
a
call
instead
of
a
full
call,
and
many
of
the
SIG's
do
have
their
meetings
bi-weekly,
and
so
we
haven't
had
the
same
level
of
content
we've
had
in
the
past,
we're
in
a
lull.
E
D
E
C
E
E
No
problem,
thank
you,
yeah.
The
third
topic
that
we
have
for
today
is
coop
cons
and
Diego's
coming
up,
and
we
have
two
sessions:
an
intro
and
a
deep
dive.
Now
I'll
give
a
little
history
for
those
of
you
who
may
not
have
followed
these
because
I've
been
to
a
number
of
them.
We
have
traditionally
done
them
as
two
separate
sessions
until
the
last
one
in
Europe.
E
That's
when
we
put
them
together
in
one
in
the
previous
session,
like
the
previous
u.s.
one
where
the
intros
and
deep
dives
were
away
from
much
of
the
rest
of
the
conference.
The
sessions
weren't
that
well
attended,
but
I
know
that
a
number
of
the
cig
sessions
were
not
that
well
attended.
That
I
stuck
my
head
into,
and
it
may
be
because
they
were
scheduled
separately
physically
from
everything
else.
I
think
there
were
some
issues
with
combining
them
last
time
just
by
the
mix
of
audiences
and
so
I
think.
E
A
We
had
the
combined
session,
which
was
an
hour
and
a
half,
and
it
was
definitely
longer
than
we
needed
and
we
had
a
mix
of
people
who
were
just
new
to
the
gaps
and
wanted
to
find
out
about
what
it
was,
and
people
who
were
kind
of
sick,
apps
veterans
and
yeah.
We're
just
showing
up
so
I.
Think
splitting
them
up
in
two
separate
sessions
will
will
make
a
lot
more
sense.
C
E
E
E
E
D
A
A
E
Idea,
I
also
like
the
idea
of
talking
more
about
some
of
the
controllers,
one
of
the
things
and
it's
been
on
my
long-term
to-do
list
and
somehow
I've
never
got
around
to
it
is
if
you
actually
go
to
the
docs.
We
talked
about
the
different
controllers,
but
there
isn't
a
single
thing
that
says:
here's
what
the
different
controllers
do,
that
we
have
and
here's
how
you
would
use
them,
there's
no
overview.
E
E
So
we're
missing
the
help
on
it
or
good.
First
issue
for
apps
related
things,
yeah.
C
D
Think
we
actually
run
into
this
on
one
meeting
some
time
back
and
I
think
we
ended
up
talking
about
that.
There
are
no
clearly
good
first
issues
because
for
something
to
be
fixed
in
work
load
controls,
you
need
to
know
all
the
machinery
and
how
it
works.
Basically,
you
you
know
the
contours
and
shares
in
formers
and
stuff,
like
that
sure
yeah.
E
Know-
and
that's
one
of
the
things
we
could
do
here
and
in
a
future
cig
apps
doesn't
have
a
code
walk
through
that
walks
through
and
teaches
this
it's
one
of
the
things
Paris
has
suggested
in
the
past,
because
then
you
can
share
it
with
people
so
that
way.
Good
first
issue:
okay,
you've
got
to
learn
about
sharing
formers
things
like
that.
Oh
go!
Watch
this
video
there's
a
lot
of
people
who
learn
that
way
and
that
could
be
an
opportunity
to
help
grow
the
contributor
base
and
give
them
a
better
enough.
D
Yeah
they're,
actually,
videos
like
that.
We
just
probably
don't
link
them,
but
IRA
Komachi.
He
gave
a
talk
about
writing,
controls
and
understanding
the
Shelton
for
us
and
stuff
I
think
it
was
like
to
freak.
You
comes
back
I
think
he
actually
sent
a
link.
Last
time
we
talked
about
it.
We
just
didn't
follow
up
on
it,
I
think
and
I
bet.
Someone
else
has
given
a
similar
talk
as
well.
I
just
seen
much
ease.
That's
why
I
mention
it!
No.
E
E
A
Related
to
San
Diego,
a
key
thing
that
we
have
is
to
contribute
a
summit
and
I
think
we
can
have
a
face-to-face
I,
don't
think
it's
been
organized
yet,
but
I
was
that
was
the
case
in
Boston
and
I.
We
didn't
actually
have
a
face-to-face
session,
but
that's
something
that
we
could
do
for
San
Diego,
I.