►
Description
Milestone planning for Kubernetes Cluster API Provider AWS on 06/08/2020 at 1800 UTC
A
Hi
everyone-
this
is
the
cluster
ap
aw
cluster
api,
provide
aws
milestone
planning
meeting
of
august.
The
sixth,
where
please
be
advised
running
under
the
cncf
code
of
conduct,
so
be
cool
to
everyone,
use
the
racehand
feature
if
you'd
like
to
speak,
make
sure
you
put
your
name
down
if
you
want
to
in
the
meeting
notes
which
I've
dropped
in
chat,
and
I
will
do
so
again
for
anyone
else,
who's
joined
in
the
last
minute
or
two
okay.
A
B
B
Thanks
yeah,
so
there
are
basically
two
major
components
to
having
a
fully
functioning
eks
support.
The
first
is
the
control
plane,
so
there's
a
control,
plane
provider
that
is
primarily
being
worked
on
by
the
folks
at
weaveworks,
and
richard
is
here
then
the
other
component
is
the
eks
bootstrap
provider.
B
Which
the
new
relic
folks
have
a
pr
open
for,
and
we've
kind
of
done,
one
big
cycle
of
review
and
that's
still
open
on
the
control
plane
side.
There
are
a
couple
of
kind
of
interesting
things
that
have
come
up,
because
this
is
like
the
second
control
plane,
so
things
start
looking
to
get
a
little
bit
interfacey.
B
As
you
know,
this
gets
implemented.
So
there
have
been
a
couple
of
refactors
to
some
of
the
scope-shaped
interfaces
in
kappa
and
those
refactors
continue
a
little
bit
there's
some
kind
of
like
a
reordering
of
things
for
reconciling
security
groups,
for
example,
because
in
eks
land
you
get
a
new
security
group
with
your
control
plane.
So
reconciling
security
groups
before
reconciling
the
control
plane.
Is
you
can't
do
it
completely?
You
have
to
do
it
again
in
order
to
get
access
to
that.
B
So
that's
just
kind
of
an
example
of
some
of
the
reorganization
that
has
come
out
of
this
work.
The
other
major
thing
worth
highlighting
is
the
fact
that
cappy
proper
needs
to
establish
a
client
to
the
target
cluster
and
the
way
that
that
works
in
cube
adm
is,
you
know:
cubitium
generates
a
fully
valid
q
config
using
certs.
All
the
way
through
eks
doesn't
want
you
to
do
that
at
all.
They
want
you
to
use
either
the
aws
cli
or
the
aws
im
authenticator
to
establish
a
client
to
the
cluster.
B
So
the
only
way
eks
is
giving
you
a
cube.
Config
won't
work
in
the
capi
container
without
giving
it
aws
credentials
for
one
and
two
installing
one
of
those
two
binaries.
So
there
was
a
little
bit
of
discussion
about
moving
that
to
a
service
account
token
model
in
the
short
term
and
question
mark
question.
Mark
question
mark
for
the
long
term.
B
The
the
other
thing
that
came
up
kind
of
related
to
this
with
a
bootstrapping
is
we.
On
the
new
relic
side,
we
were
approaching
aws
machine
pools
from
an
eks
context
and
not
from
a
cube,
adm
context,
the
relevant
difference
being
that
refresh
logic
is
not
necessarily
a
thing
that
works
all
the
way
through
in
the
qb
provider.
So
just
kind
of
to
call
out
like
aws
machine
pools,
which
we
also
have
a
pr
for,
will
work
with
the
eks
bootstrap
provider
pretty
well.
A
C
It
would
help
if
I'm
muted,
myself
yeah,
though
andrew
pretty
much
covered
it
all.
I
guess
there's
one
other
thing
is:
there's
a
slightly
factor
around
labels,
sorry,
the
tags
and
the
the
tags
package.
So
that's
that's
gone
for
a
couple
of
iterations
to
make
it
more
useful
and
less
ec2
specific
so
that
we
can
have
essentially
like
a
tags
dot
with
eks
and
it
does
the
eks
specific
tagging
yeah
and
the
security
groups.
C
C
I
guess
the
other
thing
that
would
impact
this
as
well.
Is
the
cluster
aws
admin
cli
and
the
required
permissions,
and
we've
got
a
good
idea
of
the
additional
I
am
permissions
required
and
then
they're
attached
to
the
ticket,
but
to
make
this
usable.
Obviously
we
need
to
get
that
change
done
as
well.
C
A
Thanks
that
okay,
it
sounds
like
we've
got
a
good
idea.
What
needs
to
be
done
and
needs
to
plug
away.
So
I
think
for
the
last
bit.
We
just
think
about
version
numbers
and
what
things
are
going
into
each
release,
but
before
we
do
that,
I
dropped
this
spreadsheet
link.
So
we've
had
a
roadmap
document
in
the
repo
I'll
share.
My
screen
this.
A
A
So
we
have
a
doc
that
I
more
or
less
emerged
out
of
discussions
in
kubecon
san
diego.
I
think
so.
It's
pretty
informal
discussion
and
we've
not
really
probably
looked
at
in
a
long
time,
so
just
want
to
make
sure
that
we
go
through
this
and
we
we
sort
of
agree
with
this
and
maybe
sort
out
priorities
for
these
things.
A
So
one
of
the
things
thought
about
doing
is
if
we
sort
of
consider
these
in
terms
of
like
how
desirable
these
are,
feasibility
and
visibility
maybe
get
a
score
out
of
them.
So
I
think
we
just
take
them
one
at
a
time.
We
can
go
through
that
so,
first
one
being
dual
stack:
ibv4
ipv6
support,
I'm
not
sure
who's
us.
A
So
it's
not
necessarily
like
so
in
terms
of
visibility,
so
visibility
and
users
might
be
zero
in
terms
it's
not
really
visible,
but
it
might
be
considered
desirable
from
a
kubernetes
space.
I
don't
know
how
important
this
is
to
anyone
else.
Is
this
a
thing
that
anyone
else
is
seeing
that
they
need
need.
A
D
A
A
A
A
It
I'm
really
scared
of
it.
Actually,
it's
a
lot
of.
We
have
a
lot
of
conditionality
in
the
controller
now
we've
had
discussions
with
aws
as
well,
and
that
jay
popped
up
on
the
chord
about
possibly
using
the
aws
controllers
for
kubernetes.
So
what
we
would
do
in
this
is
break
up
that
aws
cluster
object
and
allow
you
to
construct
the
various
components
and
then
that
can
account
for
all
all
weird
and
wonderful
varieties
of
networking
in
aws
context,
the
infinite
permutations
of
thereof.
A
B
B
B
A
A
B
If
we
should
kind
of
define
how
far
into
machine
pools,
because
with
eks
support,
there
are
a
couple
of
ways
to
approach
a
machine
pool
from
the
asg
like
unmanaged
side,
there's
also
like
the
managed
there
might
be
a
couple
machine
pool
providers
in
in
kappa,
depending
on
or
maybe
they're,
not
in
kappa
code
base.
But
you
know
they're.
It's
worth
calling
out
that
there
is
a
managed
node
group
idea
that
may
or
may
not
be
in
scope
for
the
for
the
milestone.
A
C
C
C
B
A
Yeah
all
right
and
I'm
giving
it
a
low
feasibility
in
terms
of
like
I
don't
know
how
far
gate
would
map
onto
a
machine
for
to
be
honest,
no
idea
what
it
would
look
like
cool
next
one
is
they're
using
using
ack
if
it
arrives,
I
think,
unless
anyone
objects,
it's
very
desirable
and
probably
incredibly
feasible
as
well.
Well,
migration.
A
B
So,
where
it
gets
a
little
bit,
more
spicy
is
like,
if
you
use
the
vpc
cni,
which
is
a
thing
that
just
makes
a
bunch
of
calls
and
cappa
is
also
making
a
bunch
of
calls.
You
can
get
into
a
scenario
where,
like
kappa's
volume
in
a
self-managed
cluster
of
aws,
calls,
will
actually
slow
down
your
pods
abilities
to
get
ips
and
that's
true,
eks
or
not.
A
B
Hi
me
again,
so
there
is
a
degree
of
this
that
comes
with
the
unmanaged
node
group
support.
The
struct
that
we've
created
does
have
the
I
forget,
the
name
of
the
fields,
the
the
instance
distribution
fields
that
allow
you
to
say
like.
I
would
like
to
use
a
spot
pool
for
some
portion
of
my
asg,
so
that
is
in
there.
What
is
not
in
there
is
saying
I
would
like
an
individual
machine
object
to
be
provisioned
via
like
a
spot
pool,
or
something
like
that.
A
A
D
C
A
C
C
A
A
A
Yeah
yeah
and
I've
no
idea
about
the
image.
I
think
it
might
be
pretty
horrible
for
container
d,
so
also
this
might
be
difficult.
Yeah
window
support,
that's
another
one.
So
I
think
this
is
mostly
an
image
builder
question,
because
I
think
you
can
pretty
much
one
cloud
in
it
at
the
moment
and
then
anything
else
I
know
azure
is
going
to
be
working
on
a
bootstrap
provider
that
does
the
things
through.
I
know
whatever
it
is:
powershell
design
state
configuration
system,
the
unattended
stuff,
I
guess,
is
what
they're
doing.
D
A
A
We're
trying
to
figure
out
whether
or
not
there
was
some
generic
cluster
api
and
why
one
wide
way
to
do
this,
I
think
the
conclusion
was
not
not
really
given
that
we've
done
some
hacks.
I
guess
in
cluster
api,
mainly
around
retrying,
cube
adm,
the
in
need,
for
necessity,
to
have
to
do
this.
It
should
have
gone
down
but
like
how
I
think,
important
for
the
new
relic
people.
If
you,
because
you've
been
bringing
up
clusters
a
lot,
do
you
still
see
the
need
to
do?
B
So
there
are
kind
of
a
couple,
different,
interesting
things
here.
So
on
the
machine
deployment
side,
there
is
a
like
machine.
Health
checks
actually
get
rid
of
most
of
our
problems
in
that,
like
oh
there's,
no
node
like
let's
just
keep
retrying
and
then,
like
you,
know
I'll,
just
notify
myself
in
some
way.
B
A
All
right
thanks
for
that,
I
I
haven't
even
considered
machine
pools
at
all,
so
that
would
be
even
completely
different
once
again,
so
that's
good
feedback
I'll
start
having
a
look
again.
What
to
do?
If
there's
anything
we
can
do
next.
One
is
machine
load
balancers,
so
I'm
not
sure
why
this
is
an
aws
roadmap
per
se.
A
A
D
I
think
we
could
leverage
kind
of
you
know
this
concept,
and
it
would
also
give
us
the
ability
to
support
more
than
just
elb
classic,
so
it
would
give
us
a
way
to
potentially
swap
in
an
nlb
or
if
folks,
wanted
to
spin
up
kind
of
a
separate
load
balancer
for
ingress
services.
There
would
be
a
facility
to
do
that
as
well,
using
the
same
type
of
tooling,
that
would
manage
kind
of
a
control,
plane,
load,
balancer.
A
A
D
A
Anyone
objects
to
those
numbers.
You
should
be
able
to
be
able
to
edit
this
by
the
way
it's
on
this
chair
to
the
same,
a
cluster
lifecycle,
main
list,
I
think,
and
finally,
from
those
roadmap
items
it's
to
use
eventbridge,
for
instance,
notifications.
So
things
like
when
the
machine
turns
off
stuff,
we
can
kappa,
can
get
notified
automatically
through
some
mixture
of
sns
topics,
sqs
cues.
A
A
A
Still
got
quite
a
lot
of
nights,
but
I
think
our
big
ticket
items
are
there
for
doing
multi-tenancy
delete
that
because
we
broke
that
up
into
the
different
the
managed
machine
pools
or
the
varieties
thereof,
not
so
much.
The
far
gate
version
getting
those
performance
improvements
rate
limiting
done
eks
in
general,
just
getting
the
support
for
that.
The
cloud
watch
event
bridge
notifications.
A
A
A
Yeah,
so
what
I've
done
is
this
project's
night?
So
it's
on
the
kubernetes
six,
but
we
can
create
projects
within
the
sixth
organization
and
we
can't
necessarily
create
a
project
on
the
project
itself.
So
what
I've
just
been
doing
is
bucketing
the
all
of
the
open
issues
which
I
think
there
was
about
94
into
various
categories,
and
then
we
go
go
through.
D
A
A
A
Okay,
maybe
on
that
basis
there
we
maybe
we
make
we
zero
six,
zero,
all
singing
dancing,
initial
eks
support
and
then
machine
pools
in
zero
six
x.
Well,
zero.
You
know
whatever
that
is
zero,
six
one,
probably
for
end
of
september,
so
end
of
end
of
august,
zero,
six,
zero,
eks
initial
machine
pool
zero
six
one
end
of
september
september.
Does
that
sound
about
right.
A
Yeah
and
personally,
I
will
be
doing
performance
improvements,
stuff
things
like
that
for
probably
the
zero
six
zero
timeline
as
well,
probably
follow
up
with
the
event
bridge
well
before
you
follow
up
with
the
multi-tenancy
stuff,
so
yeah
I'll,
put
event
bridge
and
performance
improvements,
zero,
six,
zero
and
then
multi-tenancy
for
zero
six
one
and
with
the
machine
pools
as
well.
Does
that
sound
about
right.
A
I'm
okay
with
not
immediately
picking
times
with
15
minutes
for
the
rest
of
these,
and
we
can.
Maybe
people
can
give
a
thought
about
these.
We
can
come
back
to
these
in
the
next
meeting.
I
think
we've
got
a
clear.
We've
got
a
very
clear
idea
what
we
want
to
get
done
in
the
next
two
months
and
we
can
take
the
next
meeting
when
there's
more
people
around.
Why
didn't
you?
Opinions
go
through
some
of
these
other
items
that
we
know
less
around
the
desirability
thereof:
around
gpus,
bootstrap
value,
detection,
spottings,
etc.