►
From YouTube: Kubernetes SIG Apps 20211213
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
A
My
name
is
mate
and
I'll,
be
your
host
today,
announcements,
I
forgot
to
add
it,
but
there
is
a
contributor
celebration
happening
this
friday
and
as
one
of
the
events
I
will
be
holding
either
sig
apps
or
six
cli
deep
dive,
depending
on
how
many
people
will
be
interested
in
one
or
the
other
sig
involvement,
so
whether
I'll
be
talking
about
controllers
or
towards
the
cli
itself,
how
to
construct
them
any
questions,
or
maybe
there
will
be
I'll,
be
jumping
between
one
another
and
answering
different
questions
that
will
entirely
depend
on
the
participants,
so
that
would
be
kind
of
like
ama
on
sig
apps
and
six
cli.
A
That's
how
I'm
hoping
to
to
do
it
I'll
link
the
the
schedule
and
the
particular
event
after
this
particular
after
this
call
janet
can
do
you
have
any
other
announcements
other
than
we're
open
for
124,
basically,
because
the
123
was
released
last
week.
A
A
A
We
are
slowly
working
on
it,
since
2019,
ravi
and
and
mayank
are
pushing
this
forward.
We
are
hoping
that
124
will
be
the
time
when
we
will
be
able
to
finish
this.
One
ravi
with
philip
will
be
also
working
on
the
consolidating
statuses
for
controllers
and
from
what
I've
heard
from
them.
A
The
goal
is
to
have
the
initial
version
of
the
cap
merged
by
124,
so
no
particular
work
will
be
most
likely
starting
around
that
time,
but
we
are
hoping
to
to
get
the
the
ideas
out.
The
third
topic
that
morton
volunteered
to
pick
up,
which
is
a
follow-up
from
a
discussion
that
we
had
a
couple
weeks
back,
which
is
about
pdbs
and
how
they
are
counting,
not
ready,
pause,
because
currently
there
are
differences
in
between
how
controllers
and
how
pdb
themselves
are
trading,
not
ready,
pods
more
than
already
open
a
cap.
A
Problems
with
crunch
up
time,
time,
zone
parsing
or
specifically
with
an
upgrade
that
we
did
to
the
parsing
library
for
cron
spec,
there
was
a
slow
window
when
it
was
possible
to
inject
the
the
time
zone
through
a
unsupported
environment
variable
there
was
an
ask
about
supporting
time
zones
for
prawn
jobs
for
quite
a
while,
we've
been
putting
it
aside
for
for
quite
a
while,
because
we
were
waiting
to
first
of
all,
ga
the
crown
job
and
as
part
of
that
work,
we
are
also
changing
the
controller.
A
Now
that
the
majority
of
that
work
has
been
completed,
we
will
be
picking
up
the
time
zone,
support
and,
if
I
remember
correctly,
there's
already
a
pr
changing
the
api
and
the
controller
to
support
the
time
zone.
So
I'm
hoping
to
open
a
cap
describing
the
process
how
it
will
be
rolled
out
over
the
next
couple
releases.
A
I'm
pretty
sure
that
they
might
sum
up
that
they
will
be
some
topics
coming
from
aldo
and
abdullah,
which
are
our
colleagues
from
the
sixth
scheduling.
They
have
been
working
on
improving
the
job,
the
majority
of
the
batch
workloads,
so
I'm
pretty
confident
that
they
will
be
continuing
their
work.
A
So
there
is
a
high
chance
that
some
of
their
items
will
also
show
up
on
this
list,
I'll
double
check
with
them
and
we'll
include
that
in
the
in
the
agenda,
especially
which
particular
caps
that
they
are
thinking
about
addressing
in
124,
and
I
remember
that
there
was
a
topic
about
automatic
pvc
deletion
for
safety
sets.
But
I
and
I
remember
that
in
123
that
was
alpha
so
I'll
double
check
with
the
author.
A
If
he's,
if
he
will
be
pursuing
124
to
upgrade
this
future
into
into
beta
around
that
time,.
A
Okay,
matt
farina
or.
A
B
It
was
yeah.
A
Oh
yeah,
the
author,
yes
yeah
yeah,
so
I
guess
I'll
reach
out
to
him
and
ask
him
and
I'll
update
the
the
agenda
accordingly,
so
that
people
that
will
be
looking
afterwards
can
easily
track
the
work
that
is
happening
in
the
next
releases.
A
Okay,
do
we
talk
about
the
working
group?
Oh
right,
so
there
is
a
proposal,
but
I
don't
see
anyone
from
the
yeah.
We.
A
Least
like
broaden
but
yeah,
so
there
was
an
email
last
week,
if
I
remember
correctly
and
I'll
try
to
dig
up
that
particular
email
about
opening,
either
a
work
group
or
a
special
interest
group
about
batch.
A
This
is
the
link.
Let
me
open
it
up
quickly
and
I'll,
send
it
to
the
chat
as
well.
So
this
is
coming
from
abdullah
and
aldo,
so
these
are
basically
the
folks
that
were
working
on
job
api
enhancements,
such
as
index,
job
job
suspension,
improving
the
tracking
of
pots
in
a
job
and
a
lot
of
work
that
is
devoted
to
improving
the
new
hour
scheduling
and
scheduler
and
in
general,
so
the
proposal
from
them
is
to
have
a
either
a
special
interest
group
or
a
working
group
devoted
entirely
to
batch
workloads.
A
If
you
read
through
this
pretty
lengthy
issue,
the
majority
of
the
folks
are
leaning
towards
proposing
a
working
group,
especially
that
the
outcomes
are
not
fully
known
yet,
and
on
top
of
that,
it
is
a
cross
cross,
referencing,
two,
six
that
that
we
are
know
already
that
we
know
already.
So
that
will
be
both
six
scheduling,
because
a
lot
of
the
numerous
stuff
is
related
with
scheduling
and
as
well
as
the
sig
apps.
Someone
also
mentioned
sig
note,
which
might
be
also
interested
in
this
work.
A
So
the
majority
of
the
the
suggestion
is,
to
start
with
a
working
group,
try
to
figure
out
the
scope
of
the
work.
What
the
end
goal
is
and
eventually
further
decide
what
to
do
with
this,
whether
to
create
a
separate
subproject
or
a
special
interest
group
devoted
entirely
into
this
topic.
A
Does
anyone
have
any?
I
don't
know,
thoughts,
questions
suggestions
specifically
for
this
topic
feel
free
to
leave
your
comment
on
the
issue.
B
I
I
don't
see
how
it
could
be
as
sig
just
because
it's
not
clear
to
me
what
code
they
would
own
unless
they
wanted
to
take
the
batch
from
workloads,
which
really
doesn't
make
sense
to
me
to
open
up
a
sig
just
for
that
code
for
a
working
group.
It
makes
a
lot
of
sense
because
again
it
crosses
a
bunch
of
boundaries.
It's
not
even
clear
whether
I
imagine
there
probably
will
be
some
modifications
to
node,
but
definitely
scheduling
and
the
workloads
apis
would
be
part
of
it.
B
So
that
seems
like
a
good
use
of
a
working
group
to
me
like
the
intended
use
of
a
working
group.
Basically
to
me-
and
you
know,
I
guess
the
other
part
that's
unclear
to
me-
is
if
they
like,
if
it
evolves
to
a
place
where
they
like,
want
to
build
new
controllers
or
another
project
on
top.
That
sounds
great.
But
until
that
point,
and
then
that
point-
maybe
it's
a
sig.
B
A
Yeah
it
could
be
easily
a
sick,
owned
sub
project,
even
co-owned
between
six
scheduling,
sig
note
and
sig
apps,
depending
on
the
scope
and
the
and
the
interaction
of
what
it
is
touching.
If
it
is
just
a
controller,
then
it's
sufficient
to
have
it
under
just
sig
gaps.
A
If
it
will
be
if
it
will
have
a
tighter
integration
of
diff
at
different
levels,
or
let's
say
it
will
be
it'll
have
its
own
scheduler
logic,
because
that's
possible
as
well,
then
a
cross
cross
sig
saw
project
is
definitely
something
worthy
because,
like
you
said,
having
entirely
separate
sick
with
the
current
number
of
six
is
a
good
starting
point.
B
Yes,
we
should
reach
out
to
them
to
see
if
they
want
us
to
sponsor
from
sig
apps
or
if
they
need
a
sig
app
sponsor
as
well
and
then
just
go
from
there.
Then,
if
that's,
where
they're,
already
sort
of
aligned.
A
Okay
hearing
on
with
that,
I'm
gonna
close
the
call.
Thank
you
very
much
and
the
meeting
in
two
weeks
is
cancelled
because
that
will
be
right
after
holidays.
So
most
of
us
will
be
out
around
that
time.
So
see
you
all
in
the
new
year.
Thank
you
very
much
enjoy
holidays.