►
Description
Leader migration, Cloud provider flag in kube-up, and more.
B
C
C
C
A
All
right,
so
that's
my
five
yeah
sorry
for
that.
Okay,
okay,
so
I
finished
every.
I
finished
the
whole
process
of
me
migrating
from
casey
and
molly
to
them
with
scalps,
which
is
great,
so
I
I
would
so
first.
I
would
like
to
I'd
like
to
have
a
shout
out
for
everybody
who,
like
helped
with
this
process.
A
Although
I
didn't
see
anybody
anybody
involving
any
anybody
involved
like
in
this
meeting
so
for
now,
I'm
trying
to
ask
like
do
anybody
have
any
experience
to
do
leader
migration
outside
of
the
helps,
because
in
order
for
that
to
graduate,
I
should
have
the
automated
test
part
I
get
ready
very
soon,
because
I
just
need
to
automate
the
test.
The
whole
process
will
scale
up,
but
I,
but
I
still
need,
like
signals
from
other
qualifiers,
to
see
if
they
have
experience
doing
the
data
migration.
E
F
So,
to
be
clear,
the
ga
requirements
only
call
for
one
automated,
but
we
need
a
sign
off
from
each
of
the
cloud
providers
planning
to
do
it
that
it
worked
for
them.
So
I
think,
as
far
as
amazon
goes
as
long
as
you're
willing
to
say
it
worked
for
you.
I
think
we're
happy
on
amma's
the
side.
I
think
then
probably
our
biggest
concern
would
be
microsoft
and
I
know
el
mico.
D
F
A
F
C
F
D
Want
to
go
next,
yeah
sure,
hey,
I'm
mike
michael
slash,
elmico
will
call
me
online.
I
work
for
red
hat.
I
primarily
work
on
things
like
cluster
api
and
the
auto
scaler
and
stuff
like
that,
but
our
team
has
crossover
into
these
cloud
providers.
So
I
like
to
come
here
and
see
what's
going
on
and
help
out
when
I
can.
E
B
B
G
C
A
A
So
could
you
just
go:
go
up
a
little
bit
yeah
we
used
to
have
a
we
used
to
have
a
resource
log
field.
Could
you
go
to
the
right
yeah,
putting
it
louise
right
instead
of
this
one
yeah,
we
used
to
have
a
reason
yeah,
so
it
should
be
the
instance
or
endpoints,
but
endpoints
were
was
removed
in
124,
which
means
this
field
can
only
be
nonsense
and
because,
because
it
is
defaulting
to
lenses
and
only
can
only
take
an
instance,
then
we
may
as
well
just
remove
this
field.
A
C
A
A
C
A
F
I
I
actually
think
that
this
is
probably
a
good
idea
to
split
if
nothing
else,
one
of
the
things
that
is
inevitably
going
to
come
with
an
api.
An
api
change
is
whether
or
not
we
need
to
go
through
api
review
and
especially
for
api.
If
we
do-
and
I
don't
think
we
should
have
to
go
to
api
review,
but
I
think
it
is
likely
to
be
a
discussion
and
if
we
do
having
it
broken
out,
the
way
that
jared
had
is
probably
a
good
idea.
C
Yeah
makes
sense,
I
I
guess,
like
the
the
only
concern
I
was
raising
is
like
because
it
happens,
it
happens
before,
like
you,
promote
the
api
and
then
we
forget
about
the
gate,
or
vice
versa.
So
just
just
things
like
that,
but
like
no
objection
to
splitting
it
in
general,
unless,
unless
we're
saying
explicitly
that
we
don't
need
the
we're
okay,
decoupling,
the
feature
gate,
but
the
api
version.
A
C
A
F
Gotcha
quick
mention
jared.
I
notice
we
still
have
v
one
alpha
one.
We
probably
should
go
ahead
and
delete
that
okay
and,
if
you're,
if
you've,
actually
noticeably
changed,
v1
beta1,
which
you
seem
to
have
by
removing
the
leases
field,
it
probably
makes
sense
to
deprecate
v1
beta1
and
try
and
delete
it
as
soon
as
we
can.
C
C
E
F
E
C
Yeah,
it's
one
of
those
like
weird
confusing
integrations
but,
like
the
credential
provider,
is
a
separate
subsystem
of
cubelet
independent
from
the
cloud
provider
flag
to
my
knowledge,
so
yeah
like
that's.
Why
and
that's
why
there's
two
feature
gates
because
there's
no
like
good
way
to
like
logically
bundle
it
into
the
same
feature
gate
so
setting
cloud
provider
external
but
not
disable.
The
cubic
credential.
E
Not
a
problem
necessarily
yeah,
so
the
reason
why
I'm
asking
is
just
because
we
are
deciding
whether
or
not
to
ship
our
next
version
with
a
credential
provider
and
how
decoupled
that
is
from
disabling
cloud
provider
is
a
consideration.
So
if
we
have
cubelet
running
with
cloud
provider
equals
aws,
you
know
and
we
have
the
credential
provider,
then
the
external
credential
provider,
then
there's
two
code
paths
for
getting
credentials.