►
From YouTube: 20190605 - Cluster API Office Hours
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
June
5th
edition
of
the
cluster
API
office
hours,
a
sub-project
of
state
cluster
lifecycle.
We
have
a
pretty
big
agenda
today,
but
if
you
have
any
additional
topics
that
you
want
to
bring
up,
please
go
ahead
and
add
them
to
the
agenda
now
and
also
add
yourself
to
the
attending
list.
I
just
want
to
remind
everybody
that
we
have
established
meeting
etiquette
and
to
use
the
raise
hand
feature
in
zou.
A
If
you
want
to
respond
to
topic
and
also
if
there
is
any
topic
that
you
want
to
bring
up,
that
is
tangential
to
item
currently
being
discussed.
Please
add
it
to
the
agenda
as
a
new
unrelated
topic
and
I
am
going
to
try
to
do
my
best
to
moderate
as
we
go
along
I've
added
some
time
boxing
to
the
agenda
items
as
well.
So
let's
try
to
go
ahead
and
keep
conversation
within
those
bounds.
And
the
first
item
on
the
agenda
today
is
Vince
with
the
versioning
and
releases
documentation,
PR.
B
Yes,
thank
you
Jason.
We
opened
this
last
week
and
it
just
adds
some
information
to
the
readme
about
like
what
we
do
for
a
person.
You
maintain
compatibility,
it's
mostly
kind
of
copies
from
the
controller
runtime,
and
it
meant
to
be
very
short.
The
summary
of
its
like.
We
would
like
to
release
closer
API
when
there's
a
release
plus
6
weeks
and
for
each
release,
will
open
up
a
new
release
x
branch
following
be
the
competitor
that
we
have
today.
A
B
A
Yep
all
right.
Moving
on
to
the
next
item,
VMware
has
recently
open
sourced
a
cluster
upgrade
tool
that
we've
started
to
work
on
that
works
within
the
bounds
of
the
v1
alpha
one
data
types,
since
there
are
folks
that
have
discussed
this
with
me
in
the
past
and
I've
shared
a
document
that
I
created
in
the
past
around
a
potential
upgrade
path
for
B
1,
alpha
1
cluster
API
built
clusters.
This
upgrade
tool
is
basically
an
implementation
of
that
document
and
it's
still
very
much
a
work
in
progress.
A
C
Thanks
I
just
wanted
to
say
that
echo
it's
a
work
in
progress,
we've
only
tested
it
against
the
AWS
provider.
It
has
a
set
of
prerequisites
and
expectations
for
the
way
that
the
machines
have
been
provisioned
in
order
for
it
to
function
correctly,
and
it
definitely
should
not
be
used
against
production
clusters.
C
It
we
haven't
implemented
idempotency
for
it
right
now,
so
it's
kind
of
a
relatively
unintelligent
loop
when
it
tries
to
create
the
control
planes
and
if
it
or
control
plane
machines,
and
if
it
hits
any
errors,
it
just
throws
its
hands
up
in
the
air
and
stops.
So
we
certainly
expect
that
there
need
to
be
improvements
and
we
have
open
issues,
but
we
would
love
to
have
people
kick
the
tires.
A
D
C
So
the
main
reason
that
it's
a
separate
project
right
now
is
that
cluster
API
doesn't
currently
manage
control,
plane
machines
in
any
sort
of
orchestrated
fashion
for
upgrades,
and
while
we
could
put
the
logic
or
try
to
put
the
logic
into
cluster
API,
we
feel
that
the
machine,
bootstrapping
proposal
which
we'll
be
discussing
in
a
few
minutes,
is
a
prerequisite
along
with
adding
proper
control,
plane
support
to
cluster
api.
So
we
don't
want
to
keep
this
project
alive
forever.
C
C
D
B
Thank
you
so
for
new
folks
that
have
just
joined
the
project
like
we
went
in
the
past
couple
month
into.
Oh
all,
the
feedback
that
like
would
receive
the
from
the
v1
m41
providers,
implementation
and
like
upstream
implementation
as
well,
and
we
found
out
that,
like
there
have
been
like
a
lot
of
kind
of
shortcomings
in
the
initial
implementation,
which
were
to
be
expected.
B
We
took
kind
of
an
approach
of
like
saying.
Maybe
we
should
split
the
cluster
EK
into
work
streams
and
we
did
with
so
for
the
month
of
April
and
in
May,
which
then
have
been
closed,
and
we
kind
of
like
a
gutter
like
a
lot
of
feedback,
a
lot
of
use
cases
and
a
lot
of
good,
like
brainstorming
and
doing
cube
con
a
few
folks
like
chatot
like,
and
there
was
a
strong
interest
to
kiss
scope.
Small
and
this
PR
is
direct.
B
This
proposal
is
the
result
of
that
wish,
so
we're
kind
of
like
trying
to
scope
everything
down
to
just
the
machines
and
introducing
States
and
the
shins
and
kind
of
cutting
out
the
bootstrap
mechanism
into
its
own.
Its
own
controller
and
so
machine
were
kind
of
like
a
reference
like
a
specific
external
with
bootstrap
mechanism
and
but,
while
still
giving
users
the
ability
to
bring
their
own
if
they.
B
Could
you
please
mu
if
you're
not
talking,
here's
some
noises,
the
if
the
document
is
linked,
I
will
share
my
screen,
though,
to
just
go
over
like
quickly.
This
is
kind
of
like
where
everything
started.
This
is
it
from
like
at
the
work
stream
that
was
called
the
North
lifecycle
management
work
stream.
That
work,
shouldn't
kind
of
like
did
a
good
job
like
is
specifying
like,
like
the
stays
in
the
transitions
and
it'll,
be
a
very,
very
high
level,
and
this
is
like
kind
of
like
reporter
here
as
well.
In
this
diagram.
B
I
hope
everybody
can
can
see
it.
I
can
zoom
in
if
that's
necessary,
we
kind
of
like
go
from
like
machine
create
and
like
in
there
in
all
the
steps
like
from
the
creation
of
a
machine
from
a
user
perspective,
they're
like
a
need
to
be
taken.
This
is
not
final
at
all
like
this
is
more
like
what
we're
thinking
about
and
like
the
proposal
is
meant
to
be
kind
of
like
the
starting
point
and
like
after
we
kind
of
merge
it
like
there's
always
room
for
it
for
iteration
like
it.
B
Nothing
is
ever
final
in
like
in
the
purpose
of
this
proposal,
so
this
is
kind
of
the
state's
transition
that
we
would
imagine
a
machine
to
have
so
we
go
from
pending
the
provisioning
to
running
and
delete,
then
the
deletion
state
as
well.
This
have
been
like
less
work
on
as
of
right
now
and
we
have
been
focusing
on
like
at
this
part
like,
especially
because
it
involves
the
bootstrap
mechanism.
B
If
that's
possible,
the
the
summary
and
motivation
for
for
the
this
proposal,
as
I
mentioned,
like
came
from
like
a
lot
of
feedback
that
we
have
received,
and
the
goal
is
to
just
work
on
machine
for
the
goal
of
this
proposal
and
to
make
sure
that
machine
goes
from
like
it
being
an
infrastructure
object
or
like
it.
Just
like
a
generic
machining
to
a
kubernetes
known.
That's
the
charter
of
like
cluster
API
to
like
manage
kinase
clusters
and.
B
B
On
the
other
points
that
have
been
in
here,
one
other
thing
is
I
would
like
to
propose
to
turn
the
document
into
a
pull
request
and
to
a
full
spectral.
Buy,
is
Friday
and
then
give
it
like
a
week
time
out
to
kind
of
merge
and
maybe
like
start
to
work
on
it.
As
I
mentioned,
the
proposal
is
not
final
and
like
they
have
been
there.
There's
there's
probably
like
a
lot
of
like
open
questions,
but
we
can
address
them
like
as
we
go.
E
We
have
some
now
in
response
to
my
request
in
the
agenda,
but
I
feel
like
it's
important
to
focus
on
all
of
the
sides
of
the
users,
especially
when
most
of
the
actual
design
in
the
cap
is
focused
on
what
do
the
people
implementing
and
like
on
the
implementation
side
need,
if
that's,
what
we're
gonna
focus
on
in
the
design
I
feel
like.
We
need
use
cases
to
like
sort
of
corroborate
that
design.
F
Yeah,
yes,
sorry
I
didn't
try
to
pride,
my
heart,
because
my
comments
for
the
previous
topic
adjust
the
deadline,
given
that
a
lot
of
minor
elements
are
contentious.
Do
you
think
that
one
week
is
probably
too
short,
probably
two
weeks
I
mean
this
only
differ
consideration
of
the
group
if
it
overall,
we
have
a
good
remembered
as
a
couple
of
element
that
may
be
probably
based
on
the
common
herd.
Racial
father
probably
got
a
little
bit
more
or
one
week
with
an
extension,
but
forcing
this
week
just
a
proposal.
A
B
B
We
can
always
go
back
and,
like
it
revisit
the
proposal
as
time
passes
by
one
of
the
things
that
back
up
stream
kubernetes
does
is
merge
early
and
then
update
the
provola
as
we
go,
because
implementation
is
gonna
be
much
different
than
what
we
can
actually
think
about
it.
It's
like
there's
like
good
constraints
and
thank
you
restraints,
like
we
probably
go
into
and
we'll
probably
like
a
lot
of
these
things.
It
will
probably
come
up
as
well.
B
So
if
we
can,
I
would
really
like
to
get
into
the
one
week
time
frame
and
then
as
dimensions
like
yeah
like
in
a
provisional
stage,
and
then
we
can
refine
as
we
go.
All
right,
I
believe
does
was.
G
I
was
just
going
to
ask
I
think
basically
what
Vince
just
described
is
we
would
land
at
provisional
and
then
there's
some
process
for
deciding
when
it's
no
longer
provisional
or
traditional,
and
it's
implementable,
I
guess
is
that
the
the
phase
we
wanted
to
end
up
in
so
how?
How
does
that
work?
How
do
we
get
it
to
that
state.
A
H
I
I
want
to
bring
up
that.
We
just
changed
the
scope
last
week
about
what
it
is,
we're
all
trying
to
do
here
and
since
then
this
is
the
only
proposal
that's
been
created
in
this
newly
defined
scope
and
I
keep
hearing
how
we
want
to
merge
this
proposal
in
a
week,
and
there
has
not
been
time
afforded
for
other
people
to
contribute
proposals
counter
to
this
one
and
discuss
alternatives
in
because
this
proposal
is
very
different
from
what
we
discussed
in
the
work
streams.
G
Oh
yeah
I
feel
like
that's
kind
of
what
we
talked
about
just
a
second
ago,
although
we
didn't
really
talk
about
other
proposals.
So
I
assume
that
if
there
were
other
proposals,
they
would
go
through
a
similar
sort
of
process
where
you
know
write
up
a
document
like
this
talk
about
it
in
a
meeting
get
the
PR
landed
with
it
in
a
provisional
state,
and
then
you
know
either
accept
one
or
the
other
or
reject
both
or
whatever
right.
C
Just
want
to
clarify
that
we
did
talk
about
the
scope
at
last
week's
meeting,
I'm
reviewing
the
notes
and-
and
we
did
bring
up
the
idea-
that
we
could
reduce
the
scope
to
machine
states
and
bootstrapping
this
proposal,
so
I
think
people
have
had
at
least
a
week
to
potentially
suggest
alternatives.
So
I
just
wanted
to
mention
that.
I
So
the
reason
why
I
agree
with
Michael
in
terms
of
having
more
time
is
I
feel
a
this
proposal
incorporates
a
lot
of
ideas
that
we've
been
talking
about
for
a
long
time,
but
it
wasn't
until
earlier
this
week
that
I
first
had
the
opportunity
start
reading
it
I
think
I
knew
him
as
well,
that
you
know
independent
of
my
appearance,
understanding
its
finding
provisional
and
we
can
iterate
on
it.
The
main
concern
I
have
is
this
as
I've
been
reading
through
this
I've
become
more
and
more
convinced
that
this
is
the
right
conceptual
model.
I
I
know
this
when
the
extension
workstream
was
was
a
thing
it
did.
It
wasn't
really
me:
two
people
understood
some
of
the
things
that
daniel
Smith
Brian
grants,
Jordan
Liggett
the
kind
of
things
that
they
would
give
us
feedback
on
in
terms
of
an
API
design,
and
so
my
concern
about
would
be
poured
on
this
quickly
and
again,
like
I
saw
this
Monday,
so
I've
been
busy,
I've
really
read
it
and
it
could
be
totally
off
base
here,
but
healing
it's
important
to
get
the
conceptual
framework.
F
Just
briefly,
it's
like
just
to
make
clear
I,
mostly
agree
with
this
proposal.
Does
not
so
he
because
against,
but
the
process
for
me
I,
don't
feeling
like
is
I,
really
realized
the
way
it's
happening.
Everything
is
like
I
don't
mean
to
sound
the
worst
right.
It's
like
transparency,
like
a
transparency
for
the
large
community.
Maybe
the
people
who
watch
more
closely
more
know
what's
happening,
and
this
is
not.
There
is
any
lack
of
truth
from
the
people
who
is
driving
this
forward.
F
Nothing
like
that,
but
they
think
that
this
landing
here
I
mean,
if
you
don't
wear
the
Kubik
on.
You
know
we're
aware
of
this
community's
conversations.
I
think
that
we
were
too
mean
to
worry
the
worst
dreams
and
we'll
the
same
happens
with
the
warfarin
saying
it
is
tension
mechanisms
I
just
here
as
a
comment
in
the
conference,
that
there
will
be
a
proposal
and
we
proposal
which
is
different
to
the
other.
To
do
we
were
discussing
and
he
will
repeat
this
process-
I,
don't
know
it
is
the
best
weight
for
the
route
forward.
F
J
Yeah
I
mean
I
I
I,
also
like
the
underlying
proposal.
I
think
there
are
concerns
about
the
process.
I
also
want
to
say
I,
guess,
I
liked
the
way
the
the
VMware
upgrader
thing
was
sort
of
happening
externally
in
building
sort
of
evidence
and
I
was
just
wondering
whether
we
are
blocked
from
doing
that
here
like,
in
other
words
whether
or
not
we
decide
to
merge
this
today.
Like
is
it?
J
Can
we
put
it
into
providers
back
and
sort
of
prototype
this
today
and
do
that,
maybe
even
in
like
at
least
in
kappa
and
possibly
in
you
know,
other
cost.
Shaker
providers
as
well
to
sort
of
start
in
progress,
make
sure
that
everything
works
start
concrete
fleshing
it
out
and
understanding
the
other
any
other
poses
that
come
up
better
I,
just
I'm
trying
to
get
us
to
a
code
first
world
or
not
come
first,
but
like
early
code
world
and.
J
So
as
I
understand
it
correct
me,
please
the
words
we're
talking
about
basically
adding
some
fields
to
spec
and
status
in
in
the
machine
object.
Yes,
we
could
put
those
instead
into
their
provider
spec
and
like
use
something
akin
to
reflection
to
like,
but
like
a
known
path
so
like
find
them,
regardless
of
where
they
are,
or
just
like
change
in
a
fork
right,
I
guess,
I'm,
just
sort
of
asking
whether
we
can
proceed
and
point
to
a
PR
that
actually
looks
good
and
works
well.
I
So
so,
if
we
were
going
to
follow
Justin's
suggestion-
which
I
think
is
a
good
one,
I
don't
know
what
is,
and
basically
it's
change,
but
what
I
would
like
to
see
is
an
example.
Bootstrap
controller
right
like
if
I
can
see
the
example,
bootstrap
controller
that
was
developed,
independent,
so
here's
the
reason
I'm
apparently
like
to
see
it
I'd
like
to
see
it
isn't
people
with
help.
I
They
are
concrete,
my
understanding
and
ideas
about
how
this
will
work,
but
there's
another
thing,
but
I
think
we
overlooked
part
of
part
of
something
that
we've
done
this
year
has
been
really
helpful.
Is
we've
created
word
streaming,
speeding,
we've
created
more
of
a
synchronous
communication
and
more
delegation
of
work.
This
has
helped
us
make
more
yes
more
quickly.
That
I
think
he
did
in
the
RET
month.
I've
been
involved
in
this.
I
I
A
I
think
we
have
a
challenge
here
and
that
if
we
are
trying
to
follow
kubernetes
kind
of
community
process,
you
know
in
general
for
large
breaking
types
of
changes.
It's
generally
recommended
to
come
with
a
cap
versus
you
know
not
just
coming
with
a
large
PR
that
would
implement
you
know
the
type
of
behavior
you
know,
especially
for
some
that's
disruptive
rather
than
something
that's
completely
out
of
it.
They
can
be
done
kind
of
how
to
tree
and
and
more
easily
prototype.
A
So
we
have
a
challenge
in
as
we
define
our
community
processes.
How
do
we
want
to
try
to
tackle
those
types
of
things
you
know
and
what
level
do
we
expect
the
community
you
know
effort
put
into
before
they
start
implementing
something
that
you
know
of
that
as
well,
because,
generally
for
large
breaking
type
of
changes,
you
know,
that's
you
know
is
the
it
doesn't
make
sense
to
do
the
design
work
upfront.
Does
it
make
sense
to
do
a
prototype
upfront
to
initiate
the
design
work?
A
B
I
just
wanted
to
say,
like
this
is
V
1
alpha
2,
it's
early
proposal
and,
like
things
are
gonna
change
and
they
will
change
if
you
went
out
for
one
it's
not
going
away.
I
do
share
like
the
same
concerns
like
other
have
raised
like
about
like
there's
like
some
open
questions.
There
is
like
the
need
for
liquor.
Some,
maybe
some
good.
B
The
the
main
thing
is
like
Jason
man
just
like
should
we
follow
the
practice
that,
like
kubernetes,
has
been
doing
like,
given
that,
like
we're
a
sub-project
and
my
instant
instant
feeling
today
is
like
that,
should
be
a
yes
and
like
I
I
mean
we
could
probably
put
the
work
in
at,
but
at
the
same
time
the
project
like
has
to
move
forward
like
b1a4
email,
looks
like
something
completely
their
friend.
That's
also
fine.
B
K
Next,
yes,
I
kinda,
think
that
perhaps
this
may
be
a
middle
ground
here,
so
maybe
not
going
to
the
extent
of
building
a
bootstrap
privada,
but
maybe
building
the
tests
for
that
privada.
So
building
almost
the
unit,
almost
the
unit
test
for
that
Harada,
so
people
couldn't
see
how
corrado
would
be
expected
to
behave
without
actually
implementing.
It
might
be
a
middle
ground
that
that's
easier
quicker
to
get
it
done
and
implementable.
C
Just
+12
doing
a
prototype
I
think
that
while
it
would
be
ideal
to
have
a
fully
formulated
an
agreed-upon
cap
before
we
do
any
coding
I
think
that
having
some
examples
could
help
work
through
possible
concerns
and
it's
entirely
possible
that
there's
major
flaws
in
this
proposal
that
will
find
help.
If
we
do
a
prototype.
L
David,
so
I
just
wanted
to
say
that
I've
I've
heard
some
opinions
here.
That
think
that
a
week
is
plenty
of
time
and
I
know
that,
for
some
things
it
is
I
would
say
that
for
significant
cats
that
are
having
a
fair
number
of
comments,
like
the
ones
that
I've
heard
here,
an
API
machinery
we
hold
and
tried
to
gain
agreement.
If
someone
asks
for
a
reasonable
extension
that
doesn't
seem
like
an
onerous
thing
right.
L
The
comments
that
I
heard
here
rehearse
specific
around
wanting
a
prototype
that
demonstrates
how
something
works
wanting
to
have
information
about
how
providers
would
be
integrated
to
assess
the
design
and
saying
from
one
person
who
wants
to
have
more
time
to
consider
whether
perhaps
he'd
like
to
have
a
proposal
of
his
own
I.
Don't
quite
understand
the
push
here
to
try
to
I,
don't
want
to
say,
silence
those
opinions,
but
numerous
people
have
expressed
to
hear.
A
Me
so
I,
don't
necessarily
think
that
that's
necessarily
the
case
and
I
think
if
we
do
need
more
than
a
week
to
get
enough
consensus
to
go
ahead
and
PR
to
the
repo.
That's
perfectly
fine,
I
think
the
worry
that
we
have
is
that
this
is
something
that
we've
been
working
for
months
as
a
community
on
how
do
we
decide
decide?
Where
do
we
go
from
v1
alpha
1
to
the
future
and
up
until
recently,
we've
spent
a
lot
of
time
going
through
different
processes
and
different
documents?
A
And
we
really
haven't
you
know
other
than
having
those
discussions.
We
haven't
gotten
anywhere,
where
we
have
anything
actionable
to
move
on
to
for
B,
1,
alpha,
2
and
and
part
of
the
desire
to
go
ahead
and
try
to
get
at
least
something
in
place
is
to
start
as
we
did
as
was
coined
by
Tim
in
the
face-to-face
that
we
have
AQ
Khan
is
too
biased
towards
action
rather
than
stagnate.
On
continually
discussing
and
I
saw
Tim,
you
had
your
hand
raised
I.
Think.
D
It's
totally
reasonable
to
just
let
the
PR
mold
and
be
in
provisional
until
a
POC
is
in
place,
and
then
we
can
have
another
further
discussion.
I,
don't
think,
there's
anything
that
prevents
us
from
having
alternative
approaches.
At
the
end
of
the
day,
it's
about
people
who
are
going
to
do
the
work
and
actually
step
up
to
actually
show
that
they
were
going
to
commit
to
that
work.
D
F
Just
two
comments:
first,
as
I
do
missions
real
time
and
that
we
got
into
this
war
stream
work
and
we
weren't
liking
into
our
knowledge,
paralysis.
I
agree.
But
as
again,
it's
not
clear
how
this
were
related
to
chemical.
Blue
is
related
this
something
that
has
leaning
missing
it's
something
new,
it's
fine,
but
then
we
spend
a
lot
of
work
in
the
English
streams
and
they're.
Not
only
talking
about
this
one
and
talking
about
Princeton,
also
other
works
industry
by
the
extension
mechanism.
F
We
will
follow
the
same
pattern
that
we
would
just
basically
forget
what
we
did
at
the
stream
and
somebody
would
land
a
proposal
or
anyway,
I
mean
that's,
not
what
anyone
can
learn
and
we
proposal
I,
don't
know
and
second
I.
Second,
the
comment
I
can't
remember,
who
that's
saying
that
having
cold
would
put
a
write
a
lot.
The
bar
for
even
continue
the
discussion,
because
there
were
some
implementation,
and
this
is
good
enough
for
some
people
than
the
I'm
afraid
for
one.
F
Hang
is
good
to
have
some
implementation,
because
you
have
some
practical
way
to
test
idea.
I
like
that,
but
it's
easily
be
confused
with
a
reference
implementation,
so
we
need
to
balance
that
I
mean
I'm,
not
against
the
the
idea
that
all
country
was
open
to
that,
but
it's
important
not
to
implicitly
present
it
as
a
reference
architecture
mentation
that
can
be
refined
it.
There
was
just
an
experiment:
I
will
say
yet
the
don't
even
be
as
part
of
the
closer
API
repository
at
all
chose
Eastern
repository.
B
Just
wanna
have
to
close
this
discussion
and
just
saying
like.
Instead,
if
that's
okay,
like
let's
just
open
the
PR,
remove
the
time-out
for
now
and
as
we
like
have.
If
we
do
have
a
lot
of
comments
as
David
and
Tim
suggested,
we
can
keep
the
PR
open
until
we
reach
consensus,
and
then
we
can
close
it
probably
like
in
the
next
few
meetings.
Communities
like
we'll
need
like
to
kind
of
like
reach
consensus.
So
I
would
expect
like
the
time
frame
to
at
some
point
like
to
get
this
Pierre
merged
or
rejected.
A
G
No
I
I
thought
Leah's
idea
was,
you
know
pointing
that
out
was
great
and
I
just
thought.
I'd
take
a
stab
at
adding
a
few,
so
I
don't
know
Vince.
Did
you
pull
any
of
the
use
cases
from
the
other
documents
that
we
had
been
working
on
before
this
one
as
well
or
just
the
ones
that
were
here
in
the
meeting
note
I
have.
G
A
G
So
it
wasn't
really
clear
to
me
how
much
of
the
details
you
wanted
to
get
into
in
this
meeting
versus
waiting
for
that
pull
request
and
have
code
review
comments
there
versus.
So
is
this
the
sort
of
thing
that
you
meant
when
you
said,
put
comments
in
the
agenda
doc:
I
guess
it
was
Andy
and
Vince
that
had
said
that?
Yes,.
B
G
Then
there's
a
concern
there
about
having
to
make
multiple
updates
to
different
objects
in
order
to
make
that
work
so
like
the
bootstrap
might
need
a
whole
different
image
or
something
like
that
in
order
for
guess
that
would
be
the
infrastructure,
so
you
have
to
update
the
infrastructure
object
to
give
it
a
new
image,
as
well
as
updating
the
version
number
on
this
object,
and
that's
two
API
calls.
So
that's
a
race
condition
so
I
wonder
if
that's
the
right
place
for
it,
but
maybe
I'm
also
misinterpreting
what
it's
for.
So
the.
B
Basic
idea
behind
this
versioning
spec
is
to
like,
like
if
the
user
like
I
would
say,
like
I,
want
a
separation
of
kubernetes,
but
the
field
itself
is
optional,
which
like,
if,
like
you
don't,
if
you
have
like
a
bootstrap
provider
and
names,
provided
that
don't
care
about
this
field,
this
could
be
either
like
informational
or
could
be
empty.
Yeah.
G
It's
not
so
much
about
whether
it's
optional
or
not.
It's
where
it
lives.
So
if,
in
order
to
upgrade
I,
have
to
also
change
the
image,
because
I
need
a
new
version
of
the
OS
in
order
to
even
support
that
version
of
kubernetes,
then
you
have
to
make
two
changes
and
they're
on
two
different
objects
right,
and
you
can't
do
that
in
one
call.
I
I
C
C
So
for
this
example,
you
could
change
the
version
value
in
the
machine
spec
and
then
the
underlying
server
should
be
immutable,
but
there
are
cases
where
certain
distributions
or
certain
providers
would
be
interested
in
doing
in-place
upgrades
and
I
had
some
time
to
think
about
that
and
I'm
I'm
tempted
to
suggest
that
the
way
that
we
use
this
version
field
is
it's
an
intent
for
a
kubernetes
version
or
distribution
version.
That
is
what's
provisioned
on
the
underlying
infrastructure
for
a
machine.
C
So
one
way
to
place
upgrades
possibly
for
openshift
would
be
you
set
this
machine,
spec
version
to
blank
and
then
manage
the
version
in
your
open
shift,
configuration
and
so
I.
Think,
like
that's,
that's
a
possibility.
Maybe
it
works.
Maybe
it
doesn't
and
then
in
terms
of
a
race
condition,
possibility
and
having
to
keep
to
the
machine.
Spec
version
in
sync,
with
a
QA
DM,
bootstrap
config
or
an
OPA
shift.
Config
I
think
we
would
probably
take
the
approach
of
immutable
machines,
and
so
we
wouldn't
do
an
in-place
upgrade.
C
And
if
you
wanted
to
go
from
1:13
to
1:14,
you
would
not
be
changing
a
machines,
spec
version.
You
would
be
creating
a
replacement
machine,
and
so
it's
two
different
modes
of
operation
that
both
support
upgrades
where
one
is
machines,
both
the
Machine
custom
resource
and
the
underlying
server,
are
immutable
and
a
second
being
the
the
machine
stays
immutable,
but
the
custom,
bootstrap
config
could
be
mutated
and
you
could
do
in-place
upgrades
that
way.
Ok,.
G
Yeah
so
that
I
think
I
think
the
short
version
of
that
is,
it's
not
necessarily
meant
to
do
upgrades.
It's
not
part
of
her
rewriting
right.
Ok,
well,
that
that
results.
Some
of
my
concern
there
is
still
a
concern
that
you
could
have
a
an
image
specified
in
the
infrastructure
block
that
doesn't
support
the
version
of
kubernetes,
that's
requested,
but
I
don't
know
that
we
can
get
away
from
that,
and
unless
we
have
some,
you
know
really
canonical
versioning
management
thing
that
knows
about
all
the
images
in
the
world.
So
yeah.
H
Just
on
quickly
on
the
topic
of
mutability,
vers
immutability,
that's
obviously
a
conversation
we
need
to
have
that
obviously
impacts.
The
decision
making
of
this
document
I
think
there's
some
unstated
assumptions
that
this
document
is
attempting
to
codify,
and
we
should
be
explicit
about
those
mutability
assumptions
in
this
particular
proposal.
So
we
can
have
discussion
points
around
those
idols.
Instead
of
just
discussing
them,
live
on
the
call.
A
I
Earlier,
but
based
on
Andrews
comments,
maybe
I
understand
the
visitor
for
clarification.
The
machine
resource
is
the
thing
that
I
believe
is
he
mutable.
The
underlying
physical
machine
is
the
main
business
outside
of
the
scope
of
the
API,
and
that
is
mutable.
So
that's
how
you
implement
an
in-place
upgrade
right.
The
peak
the
actual
kubernetes
machine
resource
is
being
modeled
as
a
pod
resources.
You
can't
change
image
odd
right.
You
have
to
create
a
new
positive
image
and
I
thought.
That's
what
we
voted
on.
Rihanna
coupon.
It.
D
F
A
G
Yeah
so
there's
a
string
field
there
for
the
it's
called
the
controller
phase,
type
and
I
just
thought
it
would
be
useful
to
have
a
machine-readable
value
and
a
human
like
it.
Much
more
verbose
human,
readable
value,
so
I
thought
making
that
a
2-part
field
would
be
useful
and
then
I
had
the
question
about.
If
we
do
that
or
even
if
we
don't,
if
it's
just
a
string,
do
we
it's
declared
as
a
type?
G
C
A
G
Yeah,
so
the
running
state
is
tied
to
the
the
thing
that
gets
created
becoming
a
node
and
we
already
have
node
states
somewhere
else.
So
I
wonder
if
we
need
to
couple
those
two
things
together
or
if
it's
good
enough
to
say
that
the
the
thing
that
you
created
is
alive
and
you
can
talk
to
it,
and
that
means
it's
whether
or
not
it
actually
has
all
the
kubernetes
stuff.
On
top
of
it.
Yet.
D
So
the
if,
if
folks
wanted
to
implement
their
own
bootstrap
controller,
they
could
transition
to
the
running
State
on
their
own
and
it
could
still
go
through
a
separate
thing
if
you
wanted
to.
But
if
you
look
at
the
state
machine
diagram,
there
exists
the
pre
and
the
post
operations
for
transitions.
The
Spree
in
the
posts
would
allow
you
to
do
whatever
pre
provisioning
you
wanted
to.
So
it's
a
dealer's
choice.
To
be
honest,
yeah.
G
So
there's
two
things
in
what
you
said
that
concern
me
a
little
bit.
We've
we've
talked
about
wanting
to
build
this
up
as
layers,
and
it
feels
like
a
layer
violation
to
say
that
a
machine
is
only
running
when
it
becomes
a
node
which
is
managed
by
some
other
thing,
so
that
that's
the
initial
part
of
the
question.
G
G
But
that
was
a
thing
that
we
could
talk
about
between
ourselves
so
that
we
understood
what
we
meant
by
what
state
a
host
was
in
and
also
so
that
users
could
look
at
it
and
say:
well,
it's
part
way
done,
but
it's
not
all
the
way
done
and
it
has
more
work
to
do
whatever
that
actually
ends
up
having
to
be
so.
But
it
sounds
like.
Maybe
that's
not
a
valid
assumption
about
what
that
state
machine
is
for
I.
I
To
comments
I
think
states
are
one
of
the
most
problematic
portions
of
this
I
also
want
to
reiterate
that
states
are
absolutely
essential
for
user
interface
matters,
so
we
will
have
to
solve
that
problem.
Final
comment
is
that
we
spent
a
lot
of
time
talking
about
how
to
create
a
running
state
for
machine
objects,
and
we
decided
that
we
would
not
and
we
deferred
to
using
node
status.
F
Yes,
from
and
I
understand
be
concerned
that
them
know
presented
regarding
tying
the
status
of
the
machine
today,
the
node,
but,
on
the
other
hand,
is
that
we
should
keep
in
mind
that
we
are
trying
to
bring
up
lots
of
notes,
but
it's
also
true
that
it
whatever
reason
the
configuration
of
these
node
is
wrong
for
whatever
reason-
and
it's
not
responsibility
of
the
Machine
controller,
to
handle
that,
and
they
no
never
get
active
in
the
cluster,
how
to
differentiate
that.
So
he
sees
probably
they
were
missing,
something
in
the
middle
of
this
one.
F
These
two
are
no.
Neither
have
originated
he's
taken
of
the
machine
on
the
line
machine
it
running
because
we
don't
want
to
just
bring
mr.
machine,
but
the
other
part
how
to
detect.
That
is
you
try
to
bring
it
up,
but
for
whatever
reason
is
not
to
be
because
otherwise,
where
people
try
and
give
macchina
bringing
the
machine
with
the
same
configuration
have
the
same
issue.
I
don't
have
an
answer
to
this
as
long
as
it's
only
there
for
me
this
man's,
like
we
are
probably
missing
something
he
D
meeting.
D
So
that's
the
intent
as
well
as
like
the
pre
and
post
portions
of
those
states.
The
edges
or
the
arrows
I
should
say,
are
where
the
custom
integrations
for
your
given
providers
exist
to
allow
them
to
do
their
whatever
specific
integrations
they
need.
This
was
kind
of
a
compromise
that
existed
in
the
node
lifecycle
group
and
we
had
lots
of
discussion
around
this
one.
This
one's
pretty
much
left
and
shift
from
the
conversations
that
we
had
from
that
group.
D
L
B
L
David
I
may
be
unfamiliar
with
how
the
stick
works,
but
I'm
used
to
having
situations
where
an
API
that's
trying
be
established
to
have
participation
and
implementations
by
multiple
disjoint
sets
of
people
is
usually
focused
on
trying
to
get
buy-in
from
all
those
people
and
the
feedback
from
people
actually
doing
the
implementing
about
whether
they
were
not.
They
think
an
API
is
suitable,
I,
perhaps
I'm
miss
Rockland.
Misunderstanding
me
comments
from
David
and
from
Doug
and
from
Pablo,
but
I
took
them
to
mean
that
they
looked
at
it.
L
B
A
So
at
some
point
we
need
to
have
some
distinction
of
Windows
backing
machines
are
actual
nodes,
whether
that's
actually
a
status
on
the
node
or
some
other
way.
You
know
we
can.
We
can
argue
that
over,
but
at
the
end
of
the
day
you
know
there
needs
to
be
a
to
manage
pools
of
you
know:
kubernetes
nodes
and
Tim,
okay,
I.
D
Agree
with
Duncan
I
think
we're
in
the
same
page
here
that
if
folks
want
to
refine
the
steam
machine
or
modify
the
existing
states,
I
think
that's
a
reasonable
thing
to
do,
and
you
know
we
would
be
talked
about
it
quite
a
bit.
Sorry
other
folks,
weren't
involved
in
the
other
conversations,
but
please
do
offer
recommended
solutions
or
changes
to
the
state
machine.