►
From YouTube: SIG Apps' Zoom Meeting for 20200921
Description
SIG Apps' Zoom Meeting for 20200921
A
B
B
A
C
C
C
C
When
I
say
inside
I
mean
our
own
e-commerce
website,
this
huge
gigantic
cluster
is
running
on
kubernetes
and
then
there
are
a
couple
other
business,
that's
running
on
that
as
well,
so
it's
not
experimental
anymore.
It's
really
already
in
production
use
and
in
in
those
environment.
People
focus
more
on
efficiency
and
flexibility.
They
want
to
have
more
control
over
their
parts,
more
control
on
on
what
they
can
schedule
and
where
they
can
schedule
them.
So
they
would
like
to
have
more
control.
C
So
we
have
those
requirements
and
we
did
something
and
those
those
features
we
think
can
be
beneficial
to
to
the
community,
probably
not
as
a
generic
solution,
but
more
like
special
use
cases.
If
you
have
control
over
your
environment,
if
you
would
like
to
have
flexibilities
and
such
so
that's
really
the
motivation
behind
it.
So
currently,
open
crews
has
two
parts.
One
part
is
called
cruz,
which
is
a
bunch
of
controllers
managing
workloads,
and
then
there
will
be
a
new
operator
framework.
That's
getting
rolling
out!
C
B
C
I
see
see,
let
me
let
me
exit
this
because
I'm
using,
can
you
see
now
the
the
issue?
Yes
we're
here?
Yes,
thank
you.
Okay,
I'm
sorry
about
that.
I
didn't
know
that
zoom
is
not
picking
up
those
slides,
so
okay,
so
so
that's
the
second
slide
about
the
motivation
and
the
suicide
about
the
components
just
talked
about
these.
So
currently
we
have
five
controllers
and
the
newest
one
is
clone
set.
C
So
clone
set
gives
people
more
controls
over
what
they
can
do
on
their
past,
mainly
on
the
building
update
strategies,
and
then
we
have
sidecar
set
sidecars
that
manages
site
cars
in
the
centralized
place.
It's
it's
again
for
those
production
use
cases,
and
then
there
was
advanced
staples
that
so
the
stateful
set
was
the
first
advanced
stables.
That
was
the
first
requirement.
People
get
gave
us
the
first
requirement.
C
C
The
next
one
would
be
unif
united
deployment
so
similar
to
what
the
aws
has
on
zones.
We
have
these
domain
concept
that
you
have
passed
in
this
area
in
those
areas,
so
we
want
to
manage
them
in
the
way
that
similar
to
what
those
aws
workload
can
do
so
we
divide
them
into
subsets,
basically
domains,
and
then
we
manage
those
parts
and
the
last
one
is
called
broadcast
jobs.
C
So
there
are
jobs
that
you
want
to
run
on
selected
nodes
and
then
you
can
just
dispatch
them
and
they
are
going
to
run
simultaneously
in
parallel.
So
these
are
the
controllers
that
we
have.
So
I
think
one
of
the
biggest
question
people
have
is:
okay:
what's
the
relationship
between
these
contributors
to
what
we
have
upstream?
C
So,
first
of
all,
I
think
the
name
is
confusing.
There
are
like
advanced
staple
set.
We
are
doing
some
other
similar
names,
and
people
would
assume
that
we
were
forking
upstream
code,
but
these
are
not.
Fourth
code:
we
we
have
them
re-written
from
scratch,
so
these
are
not
for
code
and
in
terms
of
features
they
are
complementing
what
the
generic
workload
controllers
can
do.
We
are
not
we,
we
don't
want
to
overtake
or
take
over
what
the
generic
workflows
can
do.
These
are
enhancements
for
specific
use
cases.
C
So
talking
about
specific
use
cases,
I'm
going
to
use
clone
set
as
an
example,
since
it's
the
newest,
and
by
the
way
this
this
one
is
being
still
being
actively
developed.
All
the
others
are
not.
At
this
moment
we
have
a
couple
new
contributors
coming
as
well,
so
clone
set
focuses
on
update
strategies.
It
gives
you
the
freedom
to
mix
and
match
all
these
all
these
strategies,
so
you
can
do,
for
example,
in
place,
update
which
is
really
efficient.
C
If
you
have
a
large
number
of
parts,
and
you
want
to
do
updates
on
them
and
in
place,
update
will
not
bother
with
api
servers.
It's
going
to
just
pull
the
new
image
out
of
out
of
the
repo
and
update
them.
So
what
you
get?
Is
you
what
you
will
keep
your
product
id
as
a
your
id
of
it?
You
will
keep
the
ip
address.
Your
keep
your
pvc.
C
Definitely
this
is
an
efficient
way
to
do
things.
But
again
you
need
to
be
in
control
of
this.
Partition
is
another
thing,
so
you
can
say
I
want
version
one
to
have
this,
so
it's
something
we
already
have
in
other
controllers,
but
we're
just
putting
them
together
right.
So
we
also
have
some
our
own
invented
strategies
like
pause
pause
means
you're,
not
updating
on
this.
This
part
anymore.
So,
even
if
you
have
a
new
version,
it's
not
going
to
get
put
into
your
pod.
C
So
these
are
the
fine
fine-tuned
knobs
that
we
have
and
also
like
in
place.
Update
strategy
has
a
grace
period.
So
you
just
in
case
that
that
you
want
to
do
something
and
you
have
a
grace
period
so,
comparing
to
what
we
have
in
from
upstream,
we
have
deployments,
therefore
set
demonstrate
so
clone
set
has
a
lot
more
capabilities
in
terms
of
update
strategies
so,
and
some
of
them
came
from,
like
politician
came
from
a
staple
set,
but
we
are
we're
doing
anyways
and
also
unlike
stateful,
set.
C
C
Let's
say
you
have
a
flungy
sidecar,
that's
collecting
your
magics
and
then
you
can
have
a
sidecar
set.
That's
going
to
be
looking
over
all
those
side,
cars
and
it's
gonna.
Do
it's
gonna
manage
those
side,
cars
for
you.
So
you
don't
have
to
worry
about
it,
and
so,
when
you're,
when
you,
for
example,
we
use
a
clone
set
here.
C
But
let's
say
you
have
a
deployment
and
all
you
have
to
do
is
give
that
label
selector
to
use
the
car
set,
and
it's
going
to
inject
those
side
cards
for
you.
So
you
don't
have
to
do
anything
you
in
your
deployment
or
in
your
clone,
set
workflow
description.
Seca
set
can
do
it
for
you,
so
it's
it's
decoupled
from
your
workload
definition.
A
For
a
second,
so
is
it
aware
of
the
the
life
cycle
of
the
pop
it's
injecting
to
so
like
one
of
the
limitations
that
we
have
today
using
mutated
emission
control
in
order
to
inject
sidecar
proxies
or
issue
or
link?
Your
d,
for
example,
is
that
the
templates
that
it
uses
to
perform
injection
don't
respect
whether
the
workload
is
run
to
completion
or
restart,
always
right
so
like
when
you
inject
side,
cars
you're
always
going
to
end
up
most
of
the
time.
Actually
in
both
the
use
cases.
A
C
C
C
D
C
Okay,
sorry,
I
saw
that
I
lost
connection
yeah
this
morning.
It's
really
bad
so
yeah.
So
that's
pretty
much.
I
have
for
these
for
these
controllers,
because
the
others,
the
other
three,
are
less
used
and
also
they
are
not
really
feature-rich.
They
just
do
once
one
thing
and
one
thing
only:
for
example,
advanced
staple
set
mainly
takes
care
of
the
the
inkplace
update
and
then
unified
deployment
is
used
when
you
have
multi
zones,
but
you
need
to
somehow
be
able
to
define
those
subsets
first
and
broadcast.
C
C
So
hopefully
that
gives
you
the
overview
of
what
we
have
on
cruise
controllers
and
yeah.
So
these
things
were
not,
I
think,
especially
the
name
or
or
having
issues
with
the
toc
members,
because
they
see
advanced
stafford,
said
and
others
probably
they're
thinking,
there's
some
correlation
between
us
and
the
upstream.
So
but
that's
a
that's
a
good
good
way
to
think
of
it,
so
we
would
like
to
get
your
opinions
on
this.
A
A
So
in
doing
a
review
of
some
of
the
features
that
you
mentioned
well,
not
that
you
mentioned
here,
but
some
of
the
features
that
are
available,
for
instance
an
advanced
stateful
set
like
the
the
max
unavailable,
for
instance
right.
That's
actually
open
work
in
upstream
to
to
present
a
feature
like
that.
A
So
I
think,
if
you
look
historically
like
deployment,
for
instance,
it
really
comes
from
deployment
config
from
openshift
right,
so
openshift
was
very
much
or
is
very
much
a
place
where
functionality
gets
developed
in
the
open
source
for
that
specific
platform
and
then,
as
it
gets
broad
adoption
and
gets
worn
out,
gets
taken
back
into
the
upstream.
At
least
that
traditionally
has
been
the
case.
I
think
from
the
sick
architecture
perspective
they
very
much
want.
A
So
I
mean
you
have
a
bunch
of
custom
resource
definitions
right
and
the
difference
between
a
custom
resource
definition
and
a
built-in
type
is
right
now,
one
of
them
ships
on
by
default
and
it's
built
into
the
code
base,
and
there
are
some
there's
some
technical
differences,
there's
from
an
implementation
perspective
as
well.
But
the
vision
for
cig
architecture
is
that
there
really
shouldn't
be,
in
the
long
term,
a
difference
between
a
custom
resource
definition
and
a
built-in
type.
A
There
should
just
be
a
resource
definition,
so
I
think
doing
it
outside
of
tree
and
keeping
it
outside
of
tree
makes
sense
to
me
and
then,
where
there
are
features
that
we
think
are
more
broadly
usable
and
should
be
adopted
into,
for
instance
like
if
you
wanted
to
upstream
and
advance
staple
sets
teachers
in
a
staple
set.
I
don't
like.
I
don't
think
we
would.
A
You
know
I
think
anyone's
going
to
push
back
on
that
as
long
as
we
think
that
they're,
mature
and
broadly
useful,
and
not
like
tied
to
a
very
specific
use
case
for
like
one
or
two
people
right
but
developing
it
in
the
open
source,
I
think,
has
some
benefits
and
some
cost
developing
it
as
crds
as
opposed
to
trying
to
upstream.
The
entire
thing
is
built
in,
would
allow
you
to
experiment
more
and
move
faster.
A
I
would
say
as
well
that
that
would
be
another
trade-off
concern,
because
once
it's
a
built-in
type,
so
anything
we
do
at
this
point
to
the
workloads
api,
where
it's
at
v1
has
to
be
at
a
level
of
maturity
and
stability.
That
effectively
means
we're
not
breaking
anybody.
It's
fully
backer
compatible
and
it's
a
long
term
feature
that
we're
we're
going
for
the
the
benefit
to
kind
of
having
a
project.
That's
outside
of
that
school
it'll.
A
Let
you
evolve
the
apis
in
a
way
that
makes
sense
and
experiment
and
kind
of
find
all
the
sweet
spots
that
you're
trying
to
hit.
So
I
mean,
like
I,
don't
know
if
those
pads
are
actually
mutually
exclusive,
like
I
don't
think
you
have
to
upstream
the
entire
thing
and
try
to
put
it
all
in
the
to
the
core
controllers,
because
I
don't
that
that
would
be
difficult
and
not
we
can
discuss
it.
A
If
you
wanted
to
offer
it
as
a
sponsored
project,
we
can
discuss
that
and
you
know
that
allows
you
to
kind
of
both
be
under
kubernetes
governance.
If
that's
what
you're?
Looking
for
at
least
have
a
governance
model
around
the
open
source
project,
as
well
as
being
able
to
kind
of
move
fast
and
at
your
own
pace,
and
it
doesn't
preclude
you
from
offering
upstream
contributions
to
the
core
controllers.
When
they've
reached
the
level
of
maturity
that
the
entire
community
is
comfortable
with.
C
Yeah,
I
have
to
say
I
totally
agree
with
you.
So,
first
of
all,
we
even
though
these
contributors
are
already
in
use,
they
they're
still
the
at
least
the
two
of
them
are
in
active
development,
and
we
still
have
bugs
on
that
issues
as
well,
and
we
we
do
want
to
move
faster
on
this,
and
the
second
part
is
yes,
those
controllers
can
be
separated.
C
Even
the
features
can
be
separated.
We
do
plan
to
upstream
some
of
the
features
like
you
said
in
stable,
advanced,
stable
set
because
it
has
been
tested.
It
has
been
used
for
a
long
time
and
the
changes
are
not
that
big
and
it's
already
there,
for
example,
the
max
unusable
that
you
were
saying
those
those
features
we
do
want
to.
We
do
want
to
upstream,
if
possible
and
yeah.
So
I
totally
agree
with
your
assessment.
D
B
B
C
I
think
they
are
looking
for
the
technical
assessment
on
on
the
sig
to
decide
if
it
fits
in
better
because
for
us
we
propose
this
as
a
separate
project.
We
have
those
concerns
just
mentioned,
so
we
do
want
to
move
faster.
We
do
want
to
grow
for
a
while
before
we
see
the
next
steps,
because
sandbox
is
just
the
entry
point
so
maybe
after
year,
so
we
can
decide
whether
we
want
to
upstream
them,
or
we
want
to
stay
at
a
separate
project
for
for
better
case
yeah.
B
C
D
I
think
it
makes
more
sense
right,
because
if
you
were
to
become
sick,
sponsored
project
like
I
think
that
would
imply
some
review
time
from
us
right
and
so
probably
it
would
be
kind
of
well
even
develop
as
fast
as
you
could
on
your
own.
I
think,
and
you
would
have
to
sort
out
what
to
do
with
the
other
projects
as
well.
A
But
as
another
project,
it
would
give
us
a
clear
direction
to
like
send
contributors
who
are
looking
to
build
those
type
of
things
directly
to
open
crews
and
say
well.
Here's
a
place
where
you
can
go,
build
those
those
type
of
things
as
an
experiment
and
do
them
as
an
incubator,
and
you
know
if
those
features
work
out
there
if
they
become
so
prevalent
that
we
want
to
adopt
them
into
the
built-in
types.
There's
a
clear
path
to
do
that,
and
we
could
build
that
clear
path
out.
A
I
don't
necessarily
think
that
we
can
still
do
that
type
of
collaboration,
even
if
you're
a
top
level
cncf
project,
that's
not
a
problem,
but
it
might
be
in
terms
of
reducing
confusion
in
the
community.
That
might
be
provide
a
little
bit
more
clarity,
and
that
would
be
the
only
thing
I
would
say
would
weigh
towards
it.
But
I
mean
really
like
it's
it's
really.
You
know
how
you
want
to
manage
your
contributions
and
what
kind
of
type
of
governance
you
want
to
put
around
your
project.
C
C
Exactly
exactly
so,
okay,
so
what
I'm
gonna
do
is
I'm
gonna
look,
go
through
some
features
and
and
then
maybe
send
an
email
to
you
to
your
group,
stick
email
and
then
say:
let
you
guys
decide
if
that
makes
sense
to
upstream
those
features.
And
meanwhile
I
would
like
to
get
maybe
email
from
ken
or
matt
on
the
decisions
about
the
whole
project
on
the
way
should
be
staying
in
cncf.
C
E
B
That's
not
specific
necessarily
to
open
crews,
but
it
gets
to
kind
of
our
opinion
here.
They
had
this
kind
of
additional
question
said
if
the
kubernetes
project
would
actually
prefer
these
experiments
to
take
place
in
a
separate
project.
Does
that
make
open
cruise
the
natural
home
for
all
workload,
related
crdi
ideas
or
some
other
scope?
B
Now
my
first
take
on
it
is
there
is
no
natural
home
for
all
the
things.
My
gut
reaction
is
that's
almost
like
a
business
manager
saying,
let's
have
a
department
that
comes
up
with
all
these
things
and
we
imagine
them
all
under
there,
but
we're
open
source
communities
and-
and
that
doesn't,
I
don't
think
it
fits.
But
I
wanted
to
hear
what
others
had
to
say.
So
when
I
respond
to
that.
A
E
E
A
You
can't
you
can't
just
say
that
it
should
all
go
here
like
anybody
should
be
free
to
submit
open
and
competing
if
somebody
wants
to
do
open
cruise,
like
basically
a
compete
to
it
like
a
complete
rewrite
of
that,
that's
their
free
will
right,
that's
their
right
and
we
shouldn't
like
force
them
into
a
specific
project
just
because
it's
themed
a
certain
way.
That
would
be
my
opinion.
B
A
There
is
a
requirements
list
for
becoming
a
cncf
sandbox
project.
Again
I
can
link
it
out
later,
but
it's
not
it's
not
super
hard
to
get
over
that
hump,
but
it's
not
trivial
either.
So
you
know
sandbox
is
below
incubating
incubating
is
below,
I
think
who
other
than
kubernetes
and
helm
what
what's
going
top
level
that's
going
like
highest
ga
or
whatever.
B
We
call
oh
prometheus,
I
think
linker
d
there's
like
up
to
a
dozen
graduated
projects
now,
but
sandbox
runs
a
different
process.
There's
a
list
of
criteria
you
have
to
meet,
and
then
every
quarter
the
toc
gets
together
and
analyzes
all
of
the
proposed
projects.
Last
time
there
were
less
than
10,
I
think,
and
they
go
through
an
analysis
of
the
different
projects
and
decide
whether
it's
in
or
out
a
bunch
of
them
they
approved
this
last
time.
Open
cruise
was
one
of
them.
B
They
kicked
out
for
more
questions
and
information
before
they
would
make
a
decision.
I
don't
know
they'll
wait
till
their
next
time
because
they
do
it
quarterly
or
whether
they
would
do
it
out
of
the
loop,
because
this
is
a
whole
new
process
for
them
that
they.
This
is
only
their
second
pass
through
doing
sandbox
projects.
This
way.
B
F
Hi
this
is
mache,
so
basically
the
I
cleaned
a
little
bit
the
cronjob
proposal
from
barney.
It
hasn't
changed
that
much.
I
just
moved
several
pieces
that
we
discussed
over
the
past
couple
of
meetings
over
to
the
future
development
and
not
necessarily
as
a
gating
part
for
the
ga,
but
most
of
them
are
cosmetical.
F
I
would
say
trying
to
minimize
the
scope
of
this
work
so
that
we
can
actually
focus
on
the
controller
and
without
changing
that
much
the
api
as
we
discussed
land
the
controller
most
probably
over
the
the
next
three
releases,
because
we
discussed
that
we
will
do
the
alpha
controller
in
the
current
release.
The
next
one
would
be
a
beta
and
probably
around
beta.
F
E
F
F
Given
that
rewriting
basically
means
we
need
to
write
a
new
one
from
scratch
and
and
so
that
we
can
ensure
that
there
is
a
smooth
process
to
migrate
from
one
to
the
other.
We
decided
to
write
a
new
controller
and
we
will
be
gradually
replacing
the
old
one
with
the
new
one
over
the
next
three
releases.
A
Yeah
so
in
in
terms
of
like
the
changes
between
this
and
the
original
pr
from
barney,
it
basically
just
downscopes
a
lot
of
it
like
the
settled
stuff
is
out
there,
there's
a
bunch
of
things
that
were
in
there
that
weren't
necessarily
critical
to
going
ga.
So
this
is
a
much
kind
of
leaner,
thinner
path
forward
that
gets
us
to
a
ga,
a
viable
ga
faster.
It
was
the
way
I
would
phrase
it
yeah.
That
is
correct.
E
A
F
F
E
I
think
the
the
api
is
reviewed
by
by
jordan
and,
and
that
is
approved
it
looks
like
based
on
the
last
comment.
I
think
I
need
to
look.
I
need
someone
to
look
at
the
implementation
and
the
tests
have
added,
and
then,
if
that
is
looking
in
the
right
direction,
then
I
can
proceed
with
trying
to
find
an
end-to-end
test.
Okay,.