►
From YouTube: Kubernetes SIG Apps 20211115
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
My
name
is
mate
and
I'll,
be
your
host
today
we're
one
day
away
from
code,
freeze,
123
code
freeze,
which
is
due
tomorrow
november
16
at
6,
00
pm
pacific
time,
so
that
leaves
us
somewhere
around
33
hours
away
from
the
code
freeze,
so
try
putting
your
oprs
together
and
ping
folks,
either
on
slack
or
on
github
or
wherever
you
can
reach
them
and
get
your
stuff
merged
before
that
date.
After
after
that
date,
every
single
code
will
require
a
an
exception.
A
I've
linked
that
the
dates.
So
that's
pretty
much
all
with
regards
to
the
code
freeze
and
now
jumping
right
into
the
main
topic
of
our
today's
call,
which
is
a
crunch
up
time
zone.
I
should
probably
put
my
name
next
to
it
since
that's
the
topic
that
I
want
to
discuss.
A
So
the
thing
is
that
during
updating
rob,
ficron
library,
which
we
are
using
for
both
parsing,
the
the
cron
spec
and
also
for
calculating,
when
will
be
the
next
time
when
a
job
should
be
created,
a
feature
creeped
in
a
feature
that
allows
specifying
the
time
zone
for
a
cron
job,
and
it
was
brought
to
my
attention
this
past
week
or
even
slightly
before
that.
If
you
specify
a
crontzy
a
variable
before
this,
the
schedule
specifier,
you
are
able
to
set
a
crunch
up
time
zone.
A
Of
course,
that
is
a
unsupported
feature,
because
back
in
the
day,
we
decided
not
to
support
the
crown
time
zones
in
cron
job.
Although
during
one
of
the
our
previous
meetings,
we've
agreed
that,
yes,
we
will
open
the
doors
for
adding
the
time
zone
functionality,
but
I
would
prefer
the
time
zone
functionality
be
an
official
feature,
not
one
that
just
happens
to
slip
through
the
side
doors.
A
So
the
current
situation
looks
that
the
docks
got
updated
even
for
122,
because
that's
basically
when,
when
I
noticed
that
someone
was
trying
to
update
this
this
information,
which
was
pointing
that
121,
but
actually
122.
When
is
when
this,
the
seizure
started
to
work
properly,
so
the
state
that
we're
currently
in
is
that
we
have
a
feature
that
slipped
in
between
the
cracks
and
some
people
actually
started
using
it.
A
I'm
I'm
considering
two
options:
one
will
be
a
hard
fail
for,
for,
as
in
we
would
update
the
validation
mechanism,
such
that
everybody
who
are
who
is
using
this
kind
of
feature
creep
would
get
a
validation
error
and
that
would
make
their
crown
job
not
functional.
A
Alternatively,
we
would
put
a
warning
on
a
cron
job
that
is
using
this
feature
to
explicitly
state
that
this
is
an
unsupported
feature
and,
at
the
same
time,
remove
the
docs,
probably
write
a
blog
post
and
still
continue
to
pursue
the
cronj.
The
crunch
of
time
zone.
Support
in
the
next
release
so
I'll
be
curious
to
hear
what
others
think
about
this.
B
Well,
I
guess
the
the
concern
I
have
is
it's
considered
a
stable
api
and
even
though
this
was
done
by
accident,
people
have
started
using
it.
So
if
we
take
it
out
and
we
break
people's
clusters,
it's
kind
of
a
bad
show,
but
then,
on
the
other
side,
we
had
an
enhancement
for
this,
which
we
decided
not
to
accept.
B
B
Is
that
the
reason
we
decided
not
to
do
it
was
because
there
was
no
reliable
implementation
of
the
time
zone
database
that
we
could
be
expect
to
be
installed
on
any
club
every
cluster
when,
with
the
new
kind
of
golang
implementation,
while
there
actually
sort
of
is
so
it's
kind
of
six
and
one
and
half
a
dozen
in
the
other.
B
Like
I'm,
I'm
I
would
lean
more
towards
just
like
apologize
and
let
the
unintentional
feature
continue,
because
people
who
aren't
using
it
don't
ever
have
to,
and
then
people
who
are
using
it
won't
be
broken
and
maybe
updating
the
documentation.
With
an
explanation
and
a
word
of
caution.
A
Yeah,
that's
that's
basically
the
option
that
I
over
the
past
two
days,
I'm
leaning
the
most
into
because,
as
you
said,
the
the
api
is
stable
and
I
don't
want
to
break
anyone's
cluster
or
functionality,
because
we
would
harden
the
validation.
A
A
We
will
pursue
a
proper
time
zone,
support
where
the
time
zone
will
be
a
separate
field,
and
it
will
be
properly
taken
into
account,
especially
that
there
is
an
interest
in
upstream
in
in
community
to
push
this
feature
forward,
and
we
did
discuss
this
topic
a
couple
meetings
ago
and
there
is
already
apr
open.
Adding
this.
A
This
kind
of
functionality
to
cron
jobs,
like
you
said,
go
already
supports
this,
so
we
don't
have
a
problem
with
with
allowing
it,
but
at
the
same
time,
I'm
willing
to
warn
the
current
users
that
they
are
using
an
unsupported
feature.
So
docs
is
definitely
one
one
possible
venue,
I'm
also
considering
a
blog
post
describing
and
apologizing
for
for
the
state,
and
also
on
top
of
that,
I
would
probably
add
a
warning
to
a
cronjob
resource.
A
A
I'm
not
hearing
any
objections,
so
I'll
probably
go
with
that
and
I'll
make
sure
that
this
lands
in
before
we
hit
the
code
freeze
tomorrow
and
I'll,
probably
I'll,
also
make
sure
that
this
warning
goes
back
in
122
as
well.
Since
that's
the
version
where
this
is
where
this
was
exposed
and
the
same
will
apply
for
docs
and
then
I'll
try
to
put
together
a
blog
post,
explaining
this
entire
situation.
A
Okay,
does
anyone
else
have
any
other
topics
that
they
want
to
discuss
with
the
group,
or
you
have
any
particular
prs
that
you
want
to
push
through
before
the
code
freeze.