►
From YouTube: Kubernetes SIG Cluester Lifecycle 20180404 - Cluster API
Description
Meeting Notes: https://docs.google.com/document/d/16ils69KImmE94RlmzjWDrkmFZysgB2J4lGnYMRN89WM/edit#
Highlights:
- Kubeadm GA with Cluster API testing
- New import alias
- Machine Deployments progress
- CloudProvider migration effort
- Milestone updates
A
A
A
Okay,
moving
on
the
next
one
I
added:
this
is
about
the
repo
migration,
so
we're
moving
to
the
are
moving
part
of.
What's
in
the
cube,
deploy
repo
to
the
kubernetes
6
/
cluster
API
repo
I
have
taken
upon
myself
to
configure
the
KH
redirector
for
all
criminate
e-cigs
repos,
so
we
should
have
a
redirect.
Now
we
have
to
decide
if
we
want
to
use
it
and
I
was
hoping.
We
could
just
get
consensus
in
this
meeting
and
make
a
decision
on
that.
So
we
can
move
forward
with
the
migration.
A
There
was
I
believe
Chris
Love,
who
thought
they
shouldn't
noted
that
she
would
that
she
doesn't
think
we
need
to
use
it
she's
perfectly
fine,
using
github,
comm,
/,
kubernetes,
cigs,
/
cluster
API,
but
I
thought
we
would
follow
the
convention
of
what
most
recruit
managers
doing
and
using
the
vanity
domains
up.
But
I
was
just
wanting
to
get
a
decision
on
this.
What
do
people
think
about
that?.
B
C
A
A
It
may
maybe
stronger
than
I
remember.
Her
argument
was
that
she
wants
to
keep
it
as
little
as
possible.
The
kids
that
I
know
redirect
is
a
bit
confusing
to
a
newcomer
and,
furthermore,
there's
a
bit
of
magic
linking
the
two
together
and
if
you
don't
know
how
it
and
if
you
don't
know
about
it,
could
be
hard
to
trace
what
her
concerns
and
she
said
if
we
switch
hosting
providers
later
on,
we
could
just
we
can
use
tools
like
setting
grep
to
update
our
code
bases
as
needed.
B
A
Confusion
is
already
there
in
the
code
base
all
right.
That's
also
a
good
point,
so
I'm
going
unless
there
are
no
strong
objections
and
I'm
just
gonna
put
a
stake
in
the
ground
and
say
we
are
going
to
use
the
vanity
URL
speak
up.
If
you
disagree
on
the
issue
by
no
later
than
5
p.m.
specific
time
today
or
I'm,
gonna
close
it
with
that
decision.
A
A
B
B
A
There
was
some
discussion
in
the
channel
about
have
we
been
in
touch
with
the
people
doing
the
cloud
provider
migration
out
on
the
main
repo,
and
for
those
of
you
who
don't
know
what
that
is,
there's
an
effort
going
on
in
the
main
kubernetes
repo
to
take
out
all
the
cloud
provider
specific
code
into
separate
repos
and
then
separating
what
is
currently
the
controller
manager
into
the
cloud
provider,
agnostic
controllers
and
then
a
cloud
provider
controller
manager
that
can
selectively
that
can
be
selectively
compiled
against
whatever
cloud
provider.
It
needs
to
be
deployed
with.
A
It's
it's
not
a
good
place
for
us
right
now,
because
we're
still
in
the
rapid
prototyping
phase
and
I
mean
that's
just
that's
going
beyond
the
question
of.
If
it's
the
right
place,
even
if
it
were
the
right
place,
I,
don't
think
it
would
be
the
right
place
right
now
and
so
I
had
that
meeting
with
him
yesterday
and
I'm
just
reporting
back
that
status.
Does
anyone
have
any
questions
about
that.
A
A
There's
something
in
chats
just
says:
no
that
sounds
good,
okay,
consensus
from
the
crowd.
Alright.
Moving
on
to
the
last
item
in
the
agenda
warning
last
item,
if
you
have
anything
you
want
to
talk
about,
please
add
it
Rodrigo
at
another
item
and
he's
also,
not
here,
oh
great,
so
the
stable
alpha
API
milestone
there.
Just
a
discussion
about
stable,
API,
I'm
gonna
bring
that
up
real
quick.
A
We
want
to
get
to
that
fairly
quickly
here.
If
there
are
any
things
that
you
consider
need
to
be
changed
about
the
current
API
for
an
alpha
release.
Please
put
it
in
that
milestone
or
ask
someone
to
put
in
the
most
one.
If
you
don't
have
permissions,
one
thing:
Rodrigo
wanted
to
block
the
stable
API
was
getting
the
API
validated
from
the
autoscaler
team
to
make
sure
that
it
would
soups
their
needs.
Are
we
had
plans
to
suit
their
needs?
And
that's
part
of
that
is
the
machine
class
PR
that
Robby
put
out.
A
It
doesn't
mean
that
we
have
to
put
the
machine
class
in
the
alpha
release.
It
means
that
friends,
that's
my
comment
of
like
the
available
capacity
would
be
better
represented
as
on
the
machine
as
what
capacity
cubelet
could
reserve,
and
so
that
would
be
an
actual
change
to
a
type
that
we
want
to
have
in
the
Alpha
API.
Whereas
changes
to
machine
class
are
ya,
might
not
necessarily
be
in
the
initiative
of
v1.
Does
that
make
sense,
I.
B
A
But
at
some
point
we
need
to
cut
an
alpha,
v1
and
then
breaking
changes
can
go
an
alpha,
v2
and
I.
Think
Rodrigo
was
just
running
from
like
some
like,
since,
like
some
consensus
on
what
alpha
v,
one
should
be
and
just
getting
making
sure
that
we
can
satisfy
Auto
scalers
cases
with
just
the
basic
types
that
we
have
like
if
more
types
need
to
be
added
on
later,
that's
fine,
but
no
major
changes
to
the
basic
types
for
that.
A
B
B
A
B
Mean
if
you
look
at
the
the
cluster
autoscaler,
they
all
pretty
much
want
like
CPU.
They
want
memory
optionally,
like
the
GPO
of
all
those
resources
that
are
in
the
core
v1
source
code
list
and
based
on
those
things.
They
can
pretty
much
say
that
they
want
to
have
a
machine
with
this
exact
things
and
all
the
additional
parameters
like
the
couplets
version
and
etc.
They
don't
care
about
these
things,
so
yeah.
A
So
yeah
that's
discussion.
They
have
the
capacity
field
of
the
machine
class,
which
is
just
the
resource
list,
and
I
was
saying
that
they
should
combine
that
with
some
sort
of
specification
on
the
machine
itself.
With
the
reservation
like
how
much
cubelet
will
reserved
for
that
specific
machine
center
machine
deployment,
that's
what
they
should
care
about,
but
the
other
versions
you're
right.
They
don't
they
don't
care
about
like
cubelet
version
or
anything
like
that
are.
A
I
see
what
you're
talking
about
the
thing.
That's
commented
out
that
he
that
he
said,
maybe,
okay,
we
can
discuss
that
in
the
PR
I'm,
not
sure
he
feels
strongly
one
way
or
not
about
this
as
long
as
we
get
something
that
satisfies
the
autoscaler
team,
and
he
did
this
I
think
kind
of
in
like
a
last-minute
rush
before
his
vacation
just
to
get
it
out
there
yeah.