►
From YouTube: Kubernetes SIG Apps 20190325
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
Okay,
welcome
everyone
to
sig
apps.
This
today
is
the
25th
March
I've
just
shared
the
link
to
the
agenda
here
in
the
chat.
So
if
you
want
to
follow
along
and
help
take
notes,
that
would
be
great.
My
name
is
Adnan
Abdullah,
sane
and
I'll
be
leading
us
through
this
meeting
today
we
also
have
Matt
Farina
on
a
call
who
is
also
a
co-chair
of
stickups.
A
B
So
this
is
one
of
the
things
that
Parrish
Pittman,
who
works
with
contrived
a
quant
adifferent
SIG's
to
share-
and
this
does
impact
our
sig
quite
a
bit
because
of
some
of
the
work
we
do
anytime.
Any
API
in
kubernetes
is
changed.
It
has
to
go
through
an
API
review
process
that
includes
command
line,
flags
and
switches
that
includes
additions
to
the
API.
Maybe
a
select,
you
know
some
things
in
email
and
we
want
to
add
another
possible
value
to
it,
such
as
the
way
we
do
update
something
like
that.
B
Every
little
nuance
change
to
our
API
goes
through
a
review
process
and
right
now
there's
a
small
set
of
approvers.
You
can
actually
see
them
here.
Clayton,
Jordan,
Tim,
Brian,
grant
and
Eric
tune
are
the
current
approvers
of
any
API
review
changes
in
addition
to
that
they're
actually
shadowing
people
to
be
headed
to
this
process,
there's
a
little
bit
of
knowledge.
That
needs
to
be
known
in
order
to
do
this
and
they
are
currently
taking
on
board
some
mentors
and
shadowing,
and
things
like
that,
so
somebody
here's
ends
up
being
interested.
A
B
Oh,
you
are
here
all
right:
fantastic,
yeah,
okay,
so
Paris
asked
us
to
go
over
the
process
with
the
different
SIG's
and
what's
involved
just
so,
people
are
aware
of
it
and
it
is
all
highly
documented.
So
you
can
see
I
can't
see
it's
in
the
kubernetes
community,
repo
sig
architecture,
API,
review
process,
sega
architecture
owns
the
api
review
process
and
it's
all
documented
here,
and
so
you
know
it
gets
into
things
like
the
overview.
We
really
want
to
keep
everything
established
in
the
same
conventions.
We
also
have
things
like
deprecation
policies
and
they're.
B
Very
careful
about
api
changes
these
days,
just
to
be
really
smart
thought
through
try
to
make
things
consistent,
stuff
like
that,
and
so
here
it
even
says
in
the
goals
you
know
they
want
to
protect
against
disruptive,
inconsistent
or
destabilizing
changes.
Things
like
that
and
they
want
the
process
to
be
documented
and
easy
to
follow.
There's
actually
a
cap
there's
actually
a
board
or
different
things,
go
through
it.
So
what
api's
need
to
be
reviewed.
B
Basically,
just
about
everything
now,
if
it's
a
third
party,
I
can
nominate
some
for
an
api
review,
but
really
anything.
That's
a
change
to
the
api,
including
command-line
switches
goes
through
now.
Here
are
talks
in
detail
about
which
projects
aren't
scoped,
so
this
is
kubernetes
kubernetes.
So
if
something
like
mini
cube
or
cops
or.
B
Any
of
the
other
projects
that
are
sub
projects
don't
have
to
go
through
this
process.
They
probably
can
opt
into
it,
but
I,
don't
think
the
API
reviewers
want
to
take
a
look
at
it
here,
they're,
really
keeping
in
scope
things
like
kubernetes,
kubernetes
repo,
which
in
this
case
does
include
things
like
coop
control,
which
is
part
of
the
kubernetes
kubernetes
repo
at
this
time.
So
anything
in
there
goes
through
this
things
like
dns
go
through
it.
B
Yeah
and
some
of
the
other
projects
may
go
through
in
the
future,
but
really
we're
not
scaled
up
to
it.
Now.
So,
let's
see
the
mechanics
we're
getting
to
the
mechanics
and
Ken
you
may
know
more,
so
you
can
jump
in
I'm
just
kind
of
skimming
through
this.
So
there's
a
pre
review
checklist.
You
need
to
go
through
and
really
these
days
everything
needs
a
cap.
So
anything
that's
going
to
be
a
real
change
to
kubernetes.
That's
not
a
bug
fix.
It
needs
to
go
through
a
kubernetes
enhancement
proposal,
kubernetes
114.
B
They
required
that
every
new
feature
to
land
in
kubernetes
114
go
through
this
process
of
a
cap
and
so
windows
nodes
or
everything
else
that
was
going
to
go
in
has
a
cap
for
it,
and
there
are
certain
details:
they're
gonna
want
about
each
of
those
caps.
If
something
has
to
have
upgrades
downgrades
things
like
this,
you
see
the
kubernetes
is
starting
to
move
slower
and
be
more
thoughtful
and
everything
that
we
do
to
make
sure
we
don't
break
API
change
them
things
of
that
nature.
B
So
once
we
get
to
something
that's
a
cap
and
it
needs
an
API
review,
then
you
can
request
an
API
review
and
that's
as
much
as
adding
a
label
is
how
you
can
add
it,
and
then
it
goes
into
their
backlog
of
reviews
and
it's
been
updated
and
so
there's
a
project,
tracking
board
and
I.
Think
this
is
it?
Is
it
updated
or
you
can
see,
what's
in
review
and
I
think
the
board
needs
to
be
updated,
because
there's
not
enough
on
here,
there's
actually
more
things
that
need
to
be
reviewed.
B
This
board
needs
to
be
updated
at
the
moment.
It's
not
working
right,
but
there's
more
things
that
need
to
be
reviewed.
Then,
if
somebody
reviewed
one
thing
per
day,
unless
they
actually
managed
to
get
through
the
whole
backlog
which
they
might
have,
there
was
actually
a
time
when
there
was
more
things
than
they
could
get
through
for
114
if
they
did
one
a
day.
B
So
you
can
see
lots
of
people
are
trying
to
change
or
make
additions
to
the
API.
But
there's
a
board
word
supposed
to
be
tracked
and
of
course
that
means
you
can
get
hub
query.
It
for
your
own
tooling,
and
things
like
that
and
your
own
searches.
If
you
want
to
do
that,
and
so
here
it
gets
into
the
backlog
and
they're
gonna
have
somebody
who's
assigned
to
go
review
it
and
then
they'll
review
it.
We
had
the
list
earlier
and
then
there's
different
stages
in
progress.
Approved
changes
requested
rejected
again.
B
This
is
kind
of
typical
to
what
we
go
through,
but
every
API
I
needs
it,
and
this
is
kinda.
It's
kind
of
that.
Just
that
general
flow
and
if
it's
rejected
they
actually
have.
You
know
if
it's
completely
rejected.
If
the
issue
is
archived
in
the
project
review
board,
they've
got
different
ways
of
handling
this,
and
so
here
is
the
normal
review.
Lifecycle
timing
right.
So,
if
T
is
your
request
on
the
first
week,
it'll
be
prioritized
and
queued
in
the
first
three
weeks,
you
should
have
the
first
review
complete.
B
C
C
So
we're
trying
to
capture
that
and
I
think
Jordan
Liggett
has
done
a
lot
of
work
to
like
spelling
more
of
that
out
and
obviously,
if
I
can
find
that
documentation,
but
in
the
interim
were
also
training,
generalist,
API
reviewers
via
shadowing,
in
order
to
spread
that
knowledge
a
bit
more
broadly,
so
other
people
can
do
so
if
you're
interested,
and
that
already
gave
you
the
contact
information.
So
you
can
sign
up
for
shadowing
that
would
be
generalist
approval
across
the
API
service.
C
The
other
thing
is:
there's
not
a
whole
lot
of
API
review
changes
going
114
and
not
too
many
going
in
115.
We
do
have
some
stuff
in
workloads,
some
of
the
caps
we
discussed
last
week,
so
I
don't
know
I
could
see
if
other
people
are
interested.
If
people
heard
the
API
reviewer
will
be
willing
to
shadow
multiple
reviewers
on
those
cats
were
go
from
there,
but
yeah.
That's
kind
of
like
that.
Thanks.
B
A
Since
I'm,
like
it
okay,
so
next
we
have
merging
provisional
caps
and
next
steps.
I
think
there
are
two
or
three
caps
are
open:
that
we're
looking
to
to
merge
in
a
provisional
state
can
do
you
have.
You
might
have
more
of
an
update
on
that
I
think
it's!
The
the
stateful
set
max
unavailable
and
a
volume
resize
caps.
C
So
they're
three
side
cars,
it's
merged,
but
there
is
another
open
PR
to
that
cap
which
needed
to
get
merged
that
I
approved
and
should
merge
the
storage
one.
The
state
will
set
one
I'm,
actually
waiting
for
Assad
or
Michelle
pakad
from
store
inside
its
approved
from
a
sig
outside,
but
in
the
actual
block,
isn't
approve
her
from
storage
as
well,
so
I
talked
to
them
on
Friday.
Hopefully
that
merges
today
and
this
the
other
one
for
staples
said
I'm.
Just
probably
I
was
looking
at
it
on
Friday
I.
C
Think
it's
ready
to
merge,
there's
still
some
content
that
I
went.
They
there's
still
open
issues
in
terms
of
addressing
backward
and
compatibility
and
having
to
roll
out
plans
and
release
plans
for
alpha
beta,
GI,
so
forth
and
so
on.
But
I
think
it
is
completed
enough
and
talking
to
some
other
people
that
we
can
go
ahead
and
merge
it
and
then
work
from
there.
It
probably
isn't
ready
for
a
di
Ravello.
C
Yeah,
so
my
thought
is
kind
of
that.
We
don't
yes,
that's
you
can
do
another
PR
with
it.
I
think
it
does
require
more
discussion.
I'm,
not
sure
there
are
some
other
parties.
I
know
that
are
interested
I
think
we
can
so
one
thing
that
I
think
was
successful
with
the
sidecar
cap
was
merging
the
initial
PR
and
then
opening
separate
issues
to
discuss
the
things
that
people
were
interested
in.
It
allowed
the
conversation
to
like
to
progress
forward
and
for
people
to
discuss
those
topics
in
a
smaller
forum
instead
of
one
giant.
C
D
A
E
Yeah
yeah
could
I
ask
a
few
questions
about
the
sidecars
cap.
Absolutely
so
yeah
we've
got
to
a
state
now,
where
Signet
of
guy,
on
there
kind
of
115
roadmaps
they're,
just
looking
for
some
reviewers
from
their
side,
we
still
have
a
few
things
died
now
in
terms
of
the
implementation.
Details
like
like
the
one
stickler
that
still
hasn't
been
decided
as
the
actual
API
and
how
it's
going
to
be
implemented.
I
think
I
think
most
people
don't
particularly
like
having
having
a
boolean
I,
know,
I've
suggested.
E
C
It
is
your
cap
and
if
no
one
officially
rejects
it
and
emerges
and
they
pass
this
API
review
you
get
to
make
that
decision.
I
mean
respect
feedback
from
your
collaborators,
of
course,
but
ultimately
you
know
sure
cap
we're
just
trying
to
Shepherd
it
through.
So
if
you
like
I,
think
Antwon
gave
good
feedback
that
we
should
do
it
this
way
and
I
kind
of
agree
with
it.
I
think
in
the
past.
Boolean
is
for
stuff
like
this
to
fitness.
C
So
in
historical
context
the
enumeration
makes
more
sense
to
me
I'm
supportive
of
that,
but
I
didn't
see
anybody
not
supporting
it.
So
if
you
think
that's
the
right
way
to
go,
then
we
should
we
can
start
there
and
then,
if
the
API
reviewers
give
feedback,
they'd
rather
have
a
boolean.
We
can
discuss
it.
E
C
C
C
It
might
be
good
to
see
if
linker
D,
which
is
another
service
mesh
in
this
space,
would
be
interested
in
adopting
it
for
their
sidecar
injection.
We
could
just
look
at
fruity
a
criteria.
I
think
a
good
criteria
is
large
community
adoption
if
people
are
bought
into
it
and
using
it
in
production,
and
it's
a
very
strong
signal
that
we've
got
it
right
from
alpha
to
beta.
The
bar
is
a
little
bit
lower.
I
mean
it's
functional.
It's
working
you've
got
some
adoption.
C
But
we've
been
really
bad
about
following
them,
as
a
community
in
general,
we'd
like
to
get
better
so
I
think
we're
kind
of
moving
to
a
mode
where,
instead
of
late
in
things
that
at
beta
for
a
couple
of
years,
if
we
are
comfortable
with
them,
we'd
like
to
progress
them
from
beta
to
generally
available
within
one
or
two
releases,
as
opposed
to
letting
sit
for
a
year.
The
only
kind
of
caveat
to
this
is,
if
you
release
it
to
beta
and
you
get
it
wrong.
C
You
can't
deprecated
a
beta
API
until
you
it's
a
new
beta
generally
means
it's
a
level
of
stability
that
we're
going
to
move
forward
to
AJ.
There
will
be
a
ga
of
something
like
this.
We
may
have
to
do
an
additional
data
to
get
there,
but
the
confidence
is
usually
actually
that
we
won't.
So
that's
the
feedback
activity
on
that.
Ok,.
E
B
Be
able
to
give
a
little
help
here,
so
the
idea
with
provisional
was
to
merge
things
very
very
early
as
soon
as
the
idea
is
ok
with,
even
if
all
of
the
details
are
not
fleshed
out
here,
and
so
that's
what
the
provisional
state
is.
It's
like,
yes,
we're
good
with
the
idea,
but
we
need
to
move
forward
and
actually
figure
out
some
details
before
can
be
implemented.
C
What
I'm
kind
of
foggy
on
still
when
the
processor
originally
came
out?
Each
cig
was
supposed
to
have
some
of
its
own
sub
process
in
order
to
like
move
things
from
provisional
to
implementable,
like
it
could
be
basically
a
boat
and
a
majority,
or
it
could
be
like
minimum
number
of
dissenters
or
no
dissenters
after
so
people
some
period
of
time.
Something
like
that.
C
B
C
B
C
But
I
think
he
lobe
is
more
active,
and
so
he
would
be
one
you
could
reach
out
to
Joe
kind
of
had
the
original
intention.
But
I
don't
know.
If
he's
like
you
know
the
details
himself,
I,
don't
I
kind
took
that
he
wasn't
and
then
Jase
might
also
have
good
context
on
what
the
current
state
is.
So
he'd
be
good.
Some
person
to
reach
out
through
there
yeah.
B
C
In
in
this
particular
case,
what
I
would
like
to
see
I
think
most
of
its
there?
You
mentioned
some
of
the
little
sticking
points.
I
think
the
other
kind
of
one
that
we
have
to
figure
out
is
the
relationship
between
init
containers
and
sidecars
that
might
be
contentious
once
that's
there,
and
once
the
api
is
done
and
there's
a
rollout
promotion
plan,
I
think
we
could
move
it
to
implementable
and
I'd
be
comfortable.
Is
it
daunting
and
were
derrick
agree
on
the
node
side?
C
C
A
C
And
so
good
to
me
only
other
thing:
it's
next
week
would
be
a
workloads
discussion
for
anybody
who's
on
now
and
leave
just
to
mention
again,
we've
started
doing
a
thing
for
people
in
other
time
zones
in
particular
one
suggest,
participate
in
workloads
discussion.
We
will
do
that
first
in
the
meeting
and
then
we'll
move
on
to
anything
else.