►
From YouTube: Kubernetes SIG Cluster Lifecycle 20180131 - Cluster API
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
Hello
and
welcome
to
the
Wednesday
January
31st
meeting
of
the
cluster
API
working
group,
Robert
is
out
of
town,
so
I'm
going
to
be
hosting
a
meeting
today,
I've
been
out
the
past
few
weeks
because
I've
been
relocating
to
Seattle,
so
I'm
gonna
be
counting
on
every
one
of
the
group
to
kind
of
help
self-drive
this
meeting
the
first
item
in
the
agenda
is
following
up
from
last
week
on
a
better
folder
structure.
I.
Can
somebody
speak
to
what
we
were
working
on
last
week
and
where
we
are
with
that,
so.
C
B
B
A
D
I
can't
speak
to
that.
So
so
we
started
the
no
track.
You
know
they
all
do
different
ideas
and
the
no
work
items
that
he
has
a
no
for
or
for
an
elf
and
a
any
kind
of
beta
launches
for
the
closer
API
and
I
think
we
have
a
most
of
it.
Then
little
items
track
now
and
keep
the
toy
not
a
lot
of
them.
They
don't
have
like
details
yet,
but
I
kind
of
want
to
show
them
with
a
project
community.
D
So
so
you
guys
can
take
a
look
and
you
have
like
any
questions
or
any
comments.
Anything
they're,
my
least.
We
need
to
figure
out
how
to
actually
label
those
and
all
like
you
know
for
don't
know
the
idea
that
I
have
in
terms
of
milestones
and
get
feedback
on
that
as
well.
But
that's
kind
of
a
just
kind
of
a
yeah
I
think
most
of
the
works
out
there.
A
E
A
D
A
F
A
G
To
guys
about
these
machine
set
machine
deployment
API,
so
I
was
looking
at
you
at
your
proposal
and
it's
it
seems
really
nice
at
first,
but
I
do
not
understand.
How
would
you
consider
putting
in
place
updates
in
your
scheme
or
how
do
you
view
this
is
general
in
place
updates
and
what
level
it
will
happen,
because
all
your
first
you
are
only
create
need
and
put
it
into
the
instance
sets,
and
there
is.
G
There
is
a
question
how
it
will
be
behave.
For
example,
if
you
want
to
move
instance,
update
instance
in
place
and
move
between
I,
don't
know
different
machines,
or
so
so
there
is
a
little
problem.
I
don't
know.
Maybe
some
consideration,
maybe
I,
do
not
understand
everything.
How
would
be
the
in-place
updates
differ
in
your
schema
from
from
the
basic,
a
basis
for
sure
I
mean
for
last
two
weeks:
I
would
more
or
less
compared
to
this
to
this
machine.
A
D
Discussions
about
in-place
updating
they
just
want
to
kind
of
confirm
what
you're
referring
to
and
also
I.
Don't
I
answered
the
wrong
thing
so
we're
talking
about
like
updating
properties
on
that,
for
example,
on
a
machine
and
then
like
how
that,
if
that's
gonna,
actually
require
a
recreation
or
people
to
be
able
to
kind
of
update.
Those
in
place
is
that
is
that
what
you
mean.
I
B
Is
that
basically
describe
what
should
be
done?
Not
how
it
can
be
done
and,
in
case
update,
is
how
how
parties
take
care
by
the
controller.
So
are
we
imagine,
but
if
you
look
our
like
a
current
implementation
for
the
photos
for
the
TCP
provider
for
the
for
the
know,
the
update
we
are
doing
the
delete
after
upgrade
actively
like
update
yes
between
each
place,
update
for
you,
because
it
is
fairly
very
difficult
to
leave
a
credit
for
master.
You
know
we
have
to
do
impress
update
yeah.
D
Yeah
that
matches
my
discussion
as
well
with
Robbie
I
think
last
week
you
know
that
yeah,
the
API
is
mutable
just
kind
of
a
summary.
The
API
is
mutable,
the
controller
makes
a
call
and
whether
it
supports
and
which
propers
will
require
in
place,
update
or
not,
and
and
it
could
just
error
out
then
I'm
just
recreate,
and
on
the
beginning
later
the
know
supporting
place
upgrade
update.
D
One
thing
that
we
didn't
we
didn't
actually
discuss
is:
if
we're
gonna
have
configuration
options
you
know
like
which
ones
we
might.
If
you
want
a
force,
you
know
like
in-place
upgrade
update
or
not.
You
know
if
you
prefer
going
on
three
different
way.
We
didn't
actually
discuss
how
to
do
that.
Yet
at
this
point
it
will
because
just
like
a
controller
choice
later,
it
could
be
configured
to
known
by
the
user.
G
G
State
and
not
some
separate
field
with
errors,
so
this
failed
would
overwrite
any
intended
user
state.
The
user
would
see
when
we
try
to
create
it
fails,
but
we
do
not
see
where
it
came
from
so
basically
without
we
have
it
as
a
separate
state,
not
as
a
face
of
a
state
called
creating.
For
example,
I
was
wondering
whether
there
is
special
rationale
behind
it
or
in
this
proposal
or
or
not,
maybe
because
it
was
it
was.
It
was
in
this
presentation
that
Martin
gave
two
weeks
ago.
A
G
G
F
J
So
what
we
actually
tried
to
do
was
so
the
rationale
was
that
we
wanted
to
have
two
layers
of
states.
So
one
there
was
a
machine
state
and
the
second
layer
was
machine
phase
right.
So
we
wanted
to
have
minimum
set
of
possibilities
for
the
machine
State,
and
we
were.
We
were
expecting
that
the
higher
level
controllers,
like
machine,
said
machine
deployment.
They
would
be
a
primary
consumer
for
the
machine
State.
So,
for
example,
if
machine
state
is
currently
running
or
machine,
State
is
in
the
failed
state
or
it's
in
the
pending
state.
J
So
machine
set
is
something
that
would
like
to
react
on
this
part,
but
then,
on
the
second
layer
we
have
a
machine
phase
which
is
more
human
readable.
So
it
contains
a
lot
of
different
phases
which
we,
which
would
be
like
it's
currently
running,
where
it's
available.
The
phase
could
be
available
running
pending.
It
could
be
training
and
so
on,
so
which
is
more
for
the
human
readable
perspective,
and
what
we
really
did
was
a
different
machine
phases
were
basically
categorized
for
machine
States.
So,
for
example,
the
the
Machine
phase
called
it's
a
pending
available.
J
Danny
could
all
be
combined
and
called
a
single
machine
state
which
is
Ernie
right.
So
that
was
the
overall
idea
that
we
had
two
layers
well
lower
layer
world
was
mainly
intended
for
higher
level
machine
controllers
to
be
used,
and
the
other
layer
of
machine
phase
was
for
a
human
readability,
and
on
top
of
that,
we
had
in
the
similar
way
we
have
in
Cuban
it
is.
J
We
had
last
operation
concept,
so
we
added
a
field
called
last
operation
where
the
last
operation
was
mentioning
that
whether
the
creation
was
happening,
deletion
was
happening
or
updation
of
operation
was
happening.
So
eventually,
when
you
open
up
your
machine
object,
you
will
get
to
see
that
the
last
operation
was
create.
The
Machine
state
was,
it
could
could
be
either
in
the
pending
already
or
the
Machine
phase
could
be
any
very
two
teeth.
We
either
are
in
the
available
state
or
running
phase,
so
that
was
the
world
a
study
of
doing
it.
D
K
D
A
J
So
I
had
sight
equations
I
was
looking
over
the
clustered
API
and
I
got
to
know
that
we
have
repairer.
Then
we
have
upgrader.
Those
things
are
separate
tools
right.
We
expect
them
to
be
running
separately,
so,
for
example,
a
repeater
would
be
running
separately
or
it
will
be
a
client-side
tool
which
will
basically
take
the
Machine
status
any
time
and
repair
the
Machine
side.
But
why
could
they
not
be
part
of
the
machine
set
itself?
J
B
Dean
yeah,
as
we
we
like
those
two
for
the
rubicon
demo,
so
I
think
in
the
future
there
will
be
many
different
and
the
controller
sound
will
be
you
like
function
and
Valley
Ridge,
including
order
like
a
repair
like
maybe
maybe
scaling
is
inside
controller,
why
someone
will
be
like
really
like
society's
thin
layer
and
the
other
rich
functionality
could
be
on
the
tram
side,
so
I
think
for
the
class
API
just
provide
a
choice
for
the
different
implementation.
So,
in
the
end
the
customs
issues
be
quite
different.
B
The
same
is
maybe
in
the
cough,
so
there
will
be
like
lot
of
functionality
will
be
actually
no
can
decide
right.
It's
a
long
language
like
a
controller
on
the
controller,
can
deal
with
different
cloud
provider
right
and
the
s
Carboni
can
provide
the
unified,
like
the
front-end
use,
the
cloud
cross,
the
API
to
do
all
this,
that
scalene
repair
upgrade
or
from
the
common
from
that
so
I
think.
That's
the
reason
why
we
write
those
two
to
demonstrate
that
it's
possible
to
using
common
tool
can
work
across
different
provider.
D
D
We
should
have
a
kind
of
also
better
story
on
how
we're
gonna
go
about
upgrades
or
how
we're
gonna
suggest
our
people
to
upgrade
or
repair,
but
it
seems
like
that's
a
kind
of
a
higher-level
construct
that
can
be
built
on
top
of
the
you
know,
the
lower
layer,
no
mission
management
there
I,
don't
know
if
Chris
has
any
thoughts
or
especially
with
their
experience,
with
their
own
q
corner
and
about
this.
Does
it
make
sense
like
what
a
bank
mentioned.
A
I
would
want
to
look
at
the
API
I
honestly
haven't
looked
at
it
since
before
acute
con,
but
originally
when
Robby
and
I
were
talking
about
this,
we
very
much
favored
the
idea
of
having
simplistic
building
blocks
and
then
the
controller
would
take.
Take
that
and
then
have
custom
control
logic
that,
like
like
somebody
mentioned
early,
it
would
implement
how
so
in
the
case
of
machine
definitions
like
I,
would
always
favor
simplicity.
J
J
B
C
C
A
Because
there's
like
it
looks
like
two
concerns
here
right,
there's
like
like,
manipulating
the
nodes,
which
is
a
fairly
straightforward
process,
and
that
can
cover
everything
from
failures
to
repair,
to
upgrades,
but
then,
like
upgrading,
the
control
point
itself
is
a
little
bit
more
of
a
complex
issue
to
tackle,
but
yeah
I.
Think
one
of
the
original
ideas
behind
the
API
was,
if
you
wanted.
It
like,
for
instance,
scale
your
set
of
nodes
from
3
to
4.
That
would
be
a
declaration
first
and
then
the
controller
would
implement
that.