►
From YouTube: Kubernetes SIG Apps 20181022
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
No
demos,
but
one
thing
I
guess
we
wanted
to
talk
about,
is
anything
related
to
the
work
was
API
and
we
can
have
any
open
discussion.
We
don't
even
have
any
announcements,
it's
a
short
short
meeting,
I
guess
unless
we
have
a
lot
to
talk
about
for
Roma's
API.
So
the
one
thing
on
the
agenda
is
from
Tomas
and
magic
and
that's
cron
jobs
to
GA.
We
wanted
to
kind
of
talk
about
well
previous
meetings.
What
do
we
want
to
do
here
like?
What's
the
plan
to
get
them
to
da.
B
C
C
C
Google
App
Engine
format
for
specifying
runtimes
schedule
times
and
the
ISO
format,
but
none
of
the
two
actually
were
implemented
ever
so
it
will
be
nice
to
have,
but
it's
not
something
that
that
will
block
us
and
additionally,
we
can
always
do
that
post
GA,
because
that
is
not
breaking
the
backwards-compatible
yeah.
So
that's
not
a
problem
so
from
a
an
API
point
of
view,
we're
in
a
pretty
good
form.
C
Interacting
with
the
api,
which
basically
means
they
react
to
changes
instead
of
realistic
all
of
the
lea
resources
and
and
the
api
which,
as
some
might
get,
the
idea,
will
require
much
more
resources
to
process
data
and
will
be
increasing
significantly
increasing
memory
usage
over
time
when
you
grow
the
number
of
jobs
and
cron
jobs
and
pods.
But.
C
Promotion
cron
of
cron
jobs
to
GA,
because
I
know
that
at
some
point
in
time,
people
will
start
banging
at
our
doors
that
we
gave
them
a
product
that
has
these
flaws.
With
this
amount
of
cron
jobs,
I've
been
talking
with
several
people,
they've
been
trying
with
couple
thousand
cron
jobs,
and
it
was
working
just
fine,
but
nobody
actually
tried
with
bigger
numbers
than
that
from
what
I've
heard.
So
we
and-
and
the
only
problem
is
that
we
just
need
to
find
somebody
that
will
find
appropriate
amount
of
time
to
actually
write
it.
C
C
There
is
an
open
PR
for
switching
cron
job
to
control
to
Sheraton
formers,
but
the
problem
with
the
current
PR
is
that
it
only
deals
with
the
simplest
part
of
the
switch
which
is
switching
on
to
sharing
the
former's.
But
it's
not
addressing
the
problem
of
actually
scheduling
the
jobs
into
into
some
sort
of
queue
or
whatever
other
mechanism
will
be
desired
and
properly
handle
the
scheduling,
part
of
of
jobs.
A
Can
add
us
in
a
minute
so
to
summarize
we're
just
saying
this:
we
have
no
NPR
out
there.
That
would
actually
add
the
Sheraton
formers,
but
it
doesn't
actually
build
a
queue
that
implements
well
sorry,
it
doesn't
employ
deadlines,
didn't
like
deadlines,
scheduling
correctly
using
shirts
scared,
informers,
so
I
guess.
The
thing
we
need
to
decide
is
when
we
want
to
do
this
work
and
how
we
want
to
do
this
work.
So,
like
the
person
we
could,
it
is
beta.
A
A
It
as
an
alpha
after
that,
we
can
test
it
pretty
thoroughly
and
then
pump
it
up
to
a
beta
and
then
just
basically
have
the
default
enabled
and
you
have
a
switch
which
would
allow
you
to
turn
it
off.
If
you
want
it
to
so,
basically
turn
it
on
by
default
and
then
after
soaking
it
in
beta
for
I'd,
say
least
or
at
least
a
release.
If
not
two,
then
we
can
consider
promoting
it
to
GA.
C
D
C
A
All
right
with
me,
so
we
can
go
back
and
figure
and
see
if
we
can
get
somebody
to
own
it,
and
you
think
you
get
out
the
cycle
to
at
least
provide
review.
Yes,
yeah.
Okay,
so
I
mean
that
would
be
that
I
think
we
imply
somebody
to
go
on
it
and
then
we
can
commit
to
providing
review
and
approval.
And
if
not
me,
then
we
get
Janet
or
somebody
else
to
do
that
too.
A
C
A
Of
them,
you
can
look
at
all
of
them
to
figure
out
how
she
reformers
work
and
how
not
to
break
the
cache,
but
I
mean
if
all
the
controllers
are
slightly
different
in
Halicki
deployment.
Does
not
the
deployment
and
replicas
that
both
use
expectations,
I
think
demons
that
uses
expectations.
It
also
has
a
global
cache
of
nodes
if
he
keeps.
A
Unfortunately,
all
the
controllers
are
slightly
different,
which
is
Iver
is
really
good,
because,
like
we
only
address
problems
that
were
drastically
different,
only
introduced
new
code
were
absolutely
necessary
or,
conversely,
we
maybe
have
some
commonality,
and
these
things
that
we
could,
after
out
in
the
common
libraries
I'm,
not
sure.
That's
actually
true.
Every
time
I
go
through
a
look
at
the
lowly,
because
I
but
known
that.
C
They
pick
a
change
and
they
apply
the
change
almost
instantly
to
the
running
pod
Wester
cron
job,
that
not
the
case
because
you
are
applying
changes
to
the
upcoming
runs
of
the
cron
job,
which
basically
requires
and
the
queue
at
the
separate
queue
for
scheduling
your
your
job,
executions,
it's
something
that
is
that
is
not
present
in
any
of
the
other
controllers.
I
wrote
something
like
that
in
open
shift
controllers,
but
in
appreciative
it
was
actually
pretty
simple,
because
we
had
at
least
that
particular
controller
had
a
constant,
constant
interval.
So
it
was
very
kicking.
C
D
Do
we
have
a
basic
write-up
of
what
somebody
needs
to
build,
basically
a
quick
spec
of
what
they
need
to
do,
because
that
would
make
it
easier
for
somebody
at
least
to
understand
the
problem,
because
we've
talked
through
a
number
of
technical
details
here
of
how
this
is
different
from
others
and
what's
going
on
and
work
it's
complicated?
Is
this
written
down
anywhere.
A
C
It's
definitely
a
good
starting
point
for
somebody
to
update
the
current
in
font
to
current
Docs
that
we
have
around
cron
jobs
and
most
probably
propose
a
cap.
That's
like
you
said
it
will
be
a
several
release,
type
of
a
work,
so
it
definitely
deserves
a
cap
and
especially
that
it's
different
than
anything
else
it
by
putting
it
in
written
will
be,
will
be
handy,
yeah.
B
I
think
we
should
get
as
well,
because
last
time
Junaid
was
rewriting
is
right.
She
was
writing
the
TTL
garbage
collector
and
they
were
like
three
reviewers
and
they
were
kind
of.
Everybody
was
thinking,
something
else
how
the
queue
should
be
implemented
and
we
ended
up
switching
the
code
at
least
two
times
as
I.
Remember
so
deciding
those
things
in
advance.
I
think
it
will
save
time
for
everyone.
Yeah.
C
B
A
Would
be
great
okay,
so
I
want
to
move
on
to
another
topic
for
workloads.
So
there's
this!
It's
in
the
thing
there's
this
interesting
problem
we
have
with
daemon
set
because
of
controller
history
when
you
change,
when
you
add
new
defaults
to
apply
templates
section
now,
one
side
we
kind
of
so
in
theory,
adding
a
new
field
with
new
defaults
has
always
been
considered
a
backward
incompatible
change.
A
However,
from
a
sync
architecture
perspective,
it
seems
like
basically
the
outcome
is
we're
going
to
need
to
continue
to
do
this,
and
this
is
going
to
be
a
thing
that
happens
now.
I
talked
with
Daniel
and
a
couple
of
other
guys
from
the
API
machinery.
This
was
a
long
time
ago,
and
they
said
they
didn't
expect
new
defaults
for
template
specs
and
they
that
doesn't
really
make
sense,
because
in
the
context
of
using
a
template,
spec
you're
really
capturing
the
users
intention
like,
for
instance,
for
this
people.
A
A
I
don't
know
tins
seem
to
kind
of
think
that
that's
not
really
what
you
would
want
to
do
anyway
and
that
we
should
move
these
things
like
if
we're
having
new
default
values.
Okay,
add
new
fields,
but
they
should
just
be
remain
empty
for
the
template,
expect
and
then
be
materialized
as
defaults
on
the
underlying
object.
For
instance,
like
you
wouldn't
add
you
don't
add
them
to
the
pot,
simply
expect
add
them
to
pot
directly.
You
don't
add
them
to
volume
clean
as
template.
A
stable
set.
A
Add
them
directly
to
the
persistent
volume
claim
if
they're
going
to
default,
we're
over
Adam
instead
of
a
persistent
volume
claim,
if
it's
a
default,
that's
really
something
that's
specified
on
the
volume
defaulted
on
the
volume
so
try
to
default
on
things
that
actually
represent
real
issues
like
compute
and
storage,
I
kind
of
like
that
idea,
I
just
want
to
see
from
a
sick-ass
perspective
and
from
other
workloads.
Maintainer
is
what
you
guys
thought
about
it.
We
think
it's
more
reasonable.
A
So
do
we
think
we
want
to
add
new
defaults
into
pot
like
template
specs,
but
what
a
benefit
there
is
defaulting
prevent
us
from
prevents
us
from
having
to
do
the
old
pointer
checks
inside
of
our
code
right
like
if
I
default.
In
essence,
the
uppermost
level
I
never
have
to
check
to
see
if
a
value
is
nil
inside
the
hood,
but
there's
still
some
places
where
you
have
to
do
that.
Anyway,
on
the
downside,
like
it
kind
of
changes,
what
the
user
is
specified
as
they're
declared
in
it.
B
The
and
the
load
selector
the
whole
thing
actually
happens
only
for
boats
and
not
for
the
boats
bank.
So
you
think
you
are
creating
a
different
boat,
then
intellectually,
because
the
admission
will
modify
it
and
if
you
comparing
the
pods
back,
it
will
never
match
right,
but
this
is
this
is
the
issue
we
already
have.
So
if
we
default
only
to
fall,
we
we
don't
introduce
any
new
incompatibilities,
I,
guess
and
also
logically,
the
user
intent.
B
As
you
said,
it's
I
have
specified
this
and
I
own
this
created
and
also,
if
you
wanted
to
default,
actually
a
demon
set.
You
would
have
to
do
the
storage
migration
or
something
when
it
actually
modifies
your
cube.
Ctl
advice
stops
working
because,
whatever
you
had
in
your
file
and
you
do,
you
define,
it
would
be
different
and
it
can
trigger
it
all
and
stuff
so
I'm
all
in
for
defaulting.
Only
the
head
object.
A
Okay
sounds
good
all
right,
so
people
do
feel
I
feel
kind
of
strongly
about
this.
If
other
people
do
chime
in
on
the
issue,
that's
listed
down
there
and
I
think
that
the
right
thing
to
do
here
is
prior
to
when
13-game
them
to
reverse
is
defaulting
into
PI
specs,
we're
moving
into
the
pot
object
and
getting
power
of
the
controllers
repeating
our
parts.
Okay,
it's
already
open.
Okay,
cool.
B
A
A
A
So
the
only
answer
we
have
right
now
is
just
don't
do
that
prevent
ideas
about
making
them
more
robust,
but
every
time
we
walk
down
this
path,
like
we
thought,
through,
like
five
or
six
different
things
and
came
up
with
a
reason,
each
time
why
we
shouldn't
or
couldn't
do
it
but
I,
don't
know
how,
broadly
that
information
has
been
shared
outside
of
a
few
people
and
were
close
and
a
few
people
and
API
machinery,
so
maybe
putting
that
out
more
broadly
and
restarting.
The
conversation
is
something
we
should
do.