►
From YouTube: 20200615 - Cluster API Provider AWS 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).
B
B
A
B
Excellent
lots
of
good
stuff
going
on
in
there
any
questions
about
the
0-5
for
release.
C
Come
on
so
I
just
wanted
to
put
a
couple
things
in
here
that
we're
looking
at
hopefully
implementing
soon,
so
the
first
one
is
customizing
the
CNI
security
or
P&I
ports
for
the
security
groups.
So
we
are
trying
to
look
at
using
a
different
CNI
as
an
option,
besides
just
having
card
having
calico
hard-coded.
So
this
one
is
called
an
TRAI
and
it
uses
different
courts
than
calicoes
and
we
looked
at
a
couple
of
options.
C
One
could
be
we
just
add
the
entry
of
ports
like
we
have
the
Calico
ports
and
just
have
it
be
the
union
of
the
two.
But
we
didn't
think
that
that
would
be
good
for
the
community,
because
if
you
are
not
interested
in
using
either
calico
or
Andrea
having
all
of
those
ports
forced
on
you
didn't
seem
like
a
great
thing.
So
what
we
are
proposing
and
what
gab
from
our
side
is
working
on
is
a
an
addition.
C
That's
optional
to
the
AWS
cluster
spec,
to
allow
you
to
specify
the
ingress
rules
that
you
would
like
to
have
specifically
for
CNI
and
the
way
that
we're
designing
it
is
that
if
you
omit
it
and
don't
specify
it
at
all,
you
just
get
the
same
behavior
that
we
have
today.
So
you
get
the
Calico
rules
added
by
default.
If
you
do
specify
this
field,
then
you're
in
complete
control
over
what
CNI
ports
or
what
ports
you
want
open,
specifically
for
CNI.
C
So
this
would
replace
the
Calico
defaults
and
let
you
put
your
own
in
calico
and
if
you
wanted
to-
or
you
could
do,
the
internal
ones
or
something
else,
and
so
we
do
have
a
pull
request
open.
You
can
see
it
linked
on
the
rights.
So,
if
folks
are
interested,
it's
like
a
issue.
Please
look
at
the
PR
and
hopefully
we
can
get
that
in
fairly
soon
once
it
goes
through
review.
B
I'm
trying
to
remember
I,
don't
act
so
we
use
the
AWS
VPC
CNI
I,
don't
recall
if
that
actually
needs
anything
specific
outside
of
just
like
being
able
to
communicate
with
itself
I'm
looking
at
Seth's
face,
but
I'm
curious,
so
like,
for
example,
if,
if
I
submitted
like
an
empty
ingress
rules,
obviously
I
can
look
at
the
PR
like.
Would
that
just
give
me
nothing
well.
C
We
actually
we
had
some
commentary
back
and
forth
on
it
and
initially
I
said
sure.
If
you
want
to
have
no
rules,
just
submit
a
CNI
spec
with
no
rules
or
maybe
white.
Would
that
make
sense?
What
it
not
make
sense,
and
so,
where
we
currently
landed,
is
that
you
have
to
have
some
rules.
If
you
specify
this
field,
because
we
didn't
think
it
would
make
sense
to
say,
I
want
to
set
up
my
CNI
rules
and
have
there
be
none,
but
maybe
there
is
a
need
for
that.
C
B
C
And
I
think
in
the
future
like
if
we,
if
we
needed
to
say
it's
like
no
CNI
rules,
we
could
find
some
way
to
do
that.
But
I
know
that
nadir
has
talked
about
like
revamping
the
way
that
we
do
networking
in
Kappa
entirely
for
a
like
v1
alpha
for
like
a
breaking
API
change.
That
would
probably
be
the
place
to
do
something
like
that
as
part
of
the
re-envisioning.
C
Cool
sorry
dealing
with
some
bread-making
issues
at
home,
so
we've
had
some
users
of
TKG
since
tkg's
is
close
to
API.
We've
had
some
users
who
are
interested
in
not
having
the
bastion
security
group
always
be
open
to
the
world
on
port
22.
So
I,
don't
I,
don't
know
the
person
who
filed
this
issue.
It
was
from
a
while
ago,
but
this
is
basically.
What
we
would
like
to
do
is
allow
us
to
specify
the
Sider
blocks
for
the
Bastion,
not
necessarily
trying
to
disable
the
bastions
curity
group
right
now.
C
So
obviously,
just
a
heads
up
that
we'd
like
to
see
this
go
in
and
we'll
probably
find
somebody
to
work
on
it,
and
this
was
just
some
back
and
forth
that
as
you're
scrolling
through
on
does
it
need
to
be
Omid
empty.
And
how
do
we
do
no
rules
versus
default
or
some
rules
and
just
some
experimentation
with
things.
D
Yeah
so
I
know,
we've
had
a
bit
of
back-and-forth
on
slack,
so
they
see
their
PR
and
improves
the
way
subnets
are
chosen,
especially
when
you
bring
your
own
V
PC,
but
now
it
requires
you
to
specify
those
subnets
I
mean
that's,
probably
correct,
but
it
is
technically
an
API
change.
How
do
we
reach
consensus
on
doing
it
within
the
common
release
series.
A
B
E
Yeah
I
think
where
I've
landed
on
that
consent.
Having
that
same
concern,
Jason
is
that
it
should
be
fine
for
existing
clusters,
because
we
right
back
to
the
spec
when
we
do
the
discovery
today,
and
so
it
populated
the
things
that
the
the
change
is
gonna.
Look
for.
After
this
this
is
merged.
So
yeah,
sorry.
F
E
It
changes
from
having
a
cluster
API
autodiscover,
all
subnets
associated
with
the
B
PC
that
you
hand
it
to
only
looking
at
the
ones
that
you
ask
it
to
look
at.
So
if
you
configured
ipv6
on
some
of
your
subnets
like
it
could
matter,
maybe
in
this
sense,
but
the
that's.
The
like
closer
API
doesn't
do
anything
right
now
with
that
I
think
that
answers
your
question.
Okay,.
F
B
F
D
E
B
E
B
E
A
A
B
B
A
A
A
C
A
B
I
can
I
can
add
some
more
more
detail
here.
I
think
the
gap
is
just
kind
of
understanding
how
to
get
into
like
the
webhook
code
right
like
if
someone
with
no
context
on
queue,
builder
controller,
runtime
style
code
might
not,
you
know,
might
not
really
have
any
idea
how
to
validate
something
from
the
perspective
of
this,
so
I
can
take
that
on
I'll
I'll
assign
myself
for
now
and
just
so
I
know
it
updated
and
then
all
on
a
sign
later,
yeah.