►
Description
SIG Cluster Lifecycle - Cluster API Provider AWS Office Hours - 20210222
A
Hi
this
is
the
cluster
api
provider
aws
meeting
of
the
22nd
february.
2021,
please
be
aware:
we're
binding
by
the
cncf
code
of
conduct
sprawling
is
be
excellent
to
each
other.
Go
put
your
name
in
the
attending
you
haven't
already,
I
don't
know,
go
through
the
first
one
is
psas.
Fargate
adr
has
been
accepted,
rich.
B
So
we
had
some
discussions
about
how
to
represent
that
from
a
resource
kind
point
of
view.
Initially,
we
thought
yeah,
let's
try
and
make
it
like
a
a
different
type
of
machine
pool,
but
when
he
even
started
to
look
at
it,
he
realized
that
you
know
some
of
the
properties
on
the
machine.
Ball,
don't
map
and
it
doesn't
naturally
map
to
the
to
the
filegate
profile.
So
has
some
input
from
david
and
cecile
from
an
aks
point
of
view,
with
their
azure
container
instances.
B
So
we
we
adopted
a
similar
approach,
but
they
they
map
it
to
a
sort
of
like
a
eventual
node.
Don't
they
one
machine,
whereas
whereas
this
doesn't
map,
but
we've
got
our
own
resource
kind,
it
doesn't
there's
no
cappy
upstream
or
alternative
equivalent,
sorry,
so
he
so
we
yeah.
We
have
decided
that
and
that's
enough
to
be
able
to
look
at
he's,
actually
mike's
actually
been
implementing
it
and
he's
pretty
close
to
getting
that
done
as
well.
A
A
B
C
B
B
A
A
B
B
Yeah,
I
guess
this
is
driven
by,
I
guess
the
capital,
the
other
day
about
the
release
date
for
v1
alpha
four
and
the
two
week,
freeze
and
stuff
like
that,
and
when
I've
been
implementing
the
adopting
a
odc
provider
or
associated
the
no
adc
provider
for
authentication
and
adding
it
to
the
control
plane
types,
it's
made
me
realize
that
sort
of
needs
a
refactor
to
be
sort
of
just
growing
a
bit
organically.
I
guess-
and
you
know
things
like
you
know:
do
we
put
the
authentication
stuff?
Do
we
structure
it?
B
A
Yeah,
I
guess
we
should
adopt
the
same
sort
of
release
approach.
Probably
possibly
I
mean
proposals
are
doing
today.
I'm
definitely
trying
to
get
some
in
today.
Obviously,
that's
not.
We
can't
just
announce
it
well.
Can
you
find
a
proposal
in
the
next
minus
two
hours?
Please
that's
so
maybe
we
should.
B
A
A
Yeah
cool
and
they
will
also
have
a
very
good
like
idea
about
what
what
kind
of
like
conditions
then
status.
Stuff
they'll
want
exposed
because
they'll
be
consuming
that
downstream
and
sort
of
trying
to
expose
that
in
like
uis
and
stuff.
So
yeah
they'll
have
a
good
feel
of
like
what
they
need
to
know
about
the
state
of
the
cluster
and
stuff,
so
they
will
have
some
good
feedback.
I
think.
B
B
We
weren't
setting
conditions
for
when
we
did
things
like
upgrading
the
the
version,
and
you
know
it
stayed
in
the
ready
state
as
well.
So
so
mike
actually
put
a
change
in
that
when
it's
upgrading
you
know
there
is
an
upgrading
conditions
that
indicates
that
so
hopefully
that
should
satisfy
that
one
scenario
for
them
as.
A
A
B
Again,
when
I
was
doing
the
oadc
stuff,
there's
a
bunch
of
enums
around,
you
know,
update
types
and
update
status,
previously
we've
sort
of
replicated
those
our
own
versions
of
those
into
into
kappa
things
like
easter,
instant
state
and
stuff.
Like
that.
So
I
was
wondering
what
the
guidance,
if
there
is
any
guidance
around
whether
we
replicate
those.
So
we
don't
automatically
inherit
and
expose.
A
A
Yeah,
so
again
it's
it's
like
it's
like
people
like
harry.
She
were
like
consuming
them.
You
don't
really
you
don't
want
to
directly
expose
the
aws
types
to
them
so
that
they,
if
someone's,
writing
a
controller.
That's
nippling
cluster
api
resources,
they're
not
sort
of
having
to
import
that
aws
sdk.
A
B
As
well,
isn't
it
really
again,
this
is
all
related
to
this
work.
Where
so
we're
adding
this
provider
association
in
there
it
has
no
weight
function
in
the
sdk,
so
at
the
moment
most
of
the
controllers
will
take
an
action
and
then
they'll
call
the
sdk
wait
functions
and
then
literally,
wait
to
that
point
within
the
console
loop.
B
A
In
2018,
a
lot
of
the
apis
didn't
support
the
item
potency
token.
They
do
now
yeah,
so
yeah.
We
will
need
like
a
if
we
go
along
the
wiki
rate,
re-cue
stuff
we
will
have
to
so.
I
think
what
happens
now
is.
If
you
don't
provide
a
item
potency
id
every
time
you
make
sd
call,
it's
gonna
just
generate
a
new
one
internally
and
use
it
for
the
internal
retry
behavior,
but
we
also
want
it
for
the
complete
re-cue
operation
as
well.
A
B
B
Really
quite
handy
but
but
they've
butchered
the
api,
so
you
get
a
list
of
update
ids.
So
that's
one
request
and
then
you
have
to
loop
around
that
and
make
another
request
to
get
the
details
of
that
update.
So
there's
no
way
so
it's
like
you
have
to
do.
20
calls.
If
you
just
want
to
get.
You
know
the
status
of
20
updates
and
you
can't
filter
and
then
you
cut
you
have
to.
B
A
B
D
A
D
A
C
So
initially
we
thought
to
add
this
into
infrastructure.tml
so
that
we
don't
ask
users
to
create
that
new
instance.
But
then,
since
this
is
a
new
type,
we
we
actually
can't
create
it
in
the
infrastructure,
remote
at
the
same
time
of
cr,
creating
the
crd
itself
and
creating
an
instance
of
it.
So
we
have
two
options:
now
we
can
either
bump
the
version
that
supports
multi-tenancy
to
zero
seven
0,
or
we
can
put
this
multi-tenancy
feature
behind
a
feature
gate.
So
what
would
be
preferable
to
you.
C
C
A
B
Sorry,
rich,
so
it's
because
you've
done
the
the
diversion
bump.
That
means
the
release,
notes.
You'd,
have
something
saying
create
this
instance
of
this
crd
yeah
yeah,
yeah
yeah
like
say
it's
exactly
what
we
did
for
eks.
Wasn't
it
when
we
had
the
the
manual
instructions
about
how
to
enable
the
provider.
B
A
D
A
C
A
Yeah,
okay,
yeah.
Maybe
then
do
the
hacky
creation
and
controller
and
feature
gate
that
so
as
I'll
add
a
flag
to
disable
it
that
you
can
disable
the
hacky
creation.
So
someone
could
deploy
secure
by
default
control
everything
manually,
but
by
default
for
this
series
we
we
do
it
for
you
and
then
the
next
release.
We
go
no
sort
yourself
out.
Do
it
properly.