►
From YouTube: Kubernetes - AWS Provider - Meeting 20200724
Description
Recording of the AWS Provider subproject meeting held on 20200724
A
Hello:
everyone
welcome
to
sig
cloud
provider
on
friday
july,
24th
2020.
just
reminder:
everybody
to
this
meeting
is
recorded
so
follow
the
community
standards
and
be
nice
to
everyone.
A
B
Yeah
sure
so
yeah,
I
know
in
some
past
meetings
we,
you
know
I
kind
of
floated
this
idea
around
about
possibly
just
like
starting
on
a
clean
slate,
the
new
provider
version
where
we
could
kind
of
take
all
the
good
parts
of
the
existing
provider
implementation
and
then
maybe
like
re-evaluate
some
of
the
parts
that
we
don't
like
about.
B
It
make
all
the
breaking
changes
we
want
and
then
see,
if
you
know,
there's
an
appetite
for
it
for
the
as
an
only
out
of
tree
implementation,
and
so
I
I
don't
even
know
myself
if
this
is
a
good
idea
yet,
but
I
did
want
to
kind
of
just
run
with
the
idea,
get
like
a
working
alpha
implementation
in
the
current
external
repo
and
see
where
it
goes,
and
so
this
pr
is
basically
just
the
boilerplate
code
just
to
get
like
the
the
new
version
wired
in
and
then
I'd
like
to
incrementally.
A
So
I
do
like
this
idea
a
lot.
Maybe
I
should
show
my
screen.
Oh,
it
looks
like
it's
disabled
justin.
Are
you
able
to
share
screen.
A
A
A
lot,
the
the
other
things
that
we
could
do
to
sort
of,
because
I
think
one
of
the
reasons
why
one
of
the
reasons
why
I
like
this
idea
is
because
it
unblocks
people-
and
there
was
conversation-
I
was
just
catching
up
with
this
there's
conversation
a
little
a
little
while
ago,
maybe
a
month
ago,
about
some
folks
from
netflix
who
have
some
features
they
want
to
get
in.
I
think
the
node
names
is
one
of
them
that
they
they
have
a
patch
for
their
current
patch
on
their
cloud
provider.
A
For
so
one
is
we
try
to
shepherd
them
and
get
that
into
upstream,
which,
as
andrews
pointed
out,
there's
been
you
know
it's
a
it
can
be
a
slow
process,
but
I
think
so.
If
we
decide
to
go
that
way,
we
can
you
know
we
can
put
some
effort
there.
The
other
one
is
obviously
this
v2
provider.
A
And
the
other
one
is
just
making
the
switch
like
trying
to
quickly
make
the
switch
over
to
like
actually
copy
the
code
over
and
deprecate
the
version
upstream
sooner
rather
than
later.
A
Do
you
andrew?
Do
you
see
those
as
alternatives,
or
do
you
see
a
possibility
for
this
v2
provider
and
you
know
making
the
switch
sooner
or
yeah
later.
B
Yeah,
so
I
want
to
make
it
clear
that
the
existing
the
existence
of
a
v2
would
not
imply
removal
or
deprecation
of
v1.
B
B
You
know
naming
thing
and
I
think
I'm
at
a
point
where
I've
seen
enough
issues
to
say
like
I
think
we
should
just
declare
bankruptcy
on
those
things
because,
like
I'm
sure,
it's
possible,
but
they
seem
really
hard
to
do
right
and
like
I,
I
worry
that
there's
a
lot
of
users
we're
gonna
break
along
the
way
and
because
we're
already
in
this
weird,
like
out
of
tree
transition
and,
admittedly
like
the
aws
providers,
is
a
little
behind
compared
to
the
other
providers.
B
So
I
want
to
kind
of
get
things
kick-started
and
I
think
this
v2,
I
I
think
doing
the
experimental
v2
is
either
gonna.
B
Show
us
two
things
the
first
one
being
like
this
is
the
right
way
to
do
it,
and
if
we
can
make
this
v2
shiny
enough,
like
it'll,
get
us
kind
of
get
started
on
on
the
get
more
people
adopting
external
or
we'll
find
that
it
wasn't
worth
it,
and
it
actually
would
be
worthwhile
to
just
like
put
all
the
effort
into
the
existing
provider
and
figure
out
the
migration
semantics
and
get
it
working
there.
B
So
so
so
so
I
think
overall
for
me,
I
I
don't
think
it's
going
to
be
possible
to
do
this
in
the
existing
one,
and
I
think
we
should
only
reevaluate
it
if
we're
finding
that
this
new
v2
thing
is
not.
C
C
I
like
very
much
the
idea
of
saying:
let's
do
a
breaking
change
in
some
like
opt-in
way
and
not
worry
about
compatibility
and
then
say
like
okay
like
is
it
good?
Can
we
get
there?
Is
it
worth
getting
there?
Is
it
worth
like?
You
know
those
sort
of
things.
C
I
don't
know
that
we
can't
do
that
in
tree,
to
be
honest,
if
you're
willing
to
say
or
in
the
existing
location,
if
you're
willing
to
say,
like
you
know,
pass
the
v2
environment
variable
or
use
a
different
image
name
or
something
like
that,
and
you
get
that
behavior
there's
a
there
is
a
lot
of
like
very
subtle
code
in
the
v1
like
provider.
Honestly,
I
don't
like
the
two
things
you
cited.
I
don't
think
you're
going
to
solve
them
by
just
doing
it
differently.
C
Like
the
naming
thing,
we
almost
could
do
now
the
that
that
problem
is
not
about
existing
nodes.
I
don't
think
the
the
that's
more
about
like
plumbing
through
the
node
object
in
more
places
and
the
the
elb
or
the
load
balancer
name
again.
I
think
the
problem
there
is,
if
you
change,
if
you,
if
you
have
an
annotation
or
something
what
happens
when
someone
changes
the
annotation
is,
I
think,
like
one
of
the
issues,
I
I
guess
you
could
say
well,
you
could
have
a
mode
where.
C
You
have
a
mode
where,
like
the
name
is
derived
from
the
namespace
and
the
name
of
the
service
or
the
you
have
a
service,
I
I
actually
like.
So
I
like
the
idea
of
I
like
the
idea
of
experimenting.
I
I
I
suggest
we
do
that
by
trying
to
just
do
it
in
the
existing
cloud
provider,
just
because
I'm
worried
about
what
happens
when
we
have
these
two
cloud
providers
like
that,
like
that.
That
is
a
never
mind
the
v1
v2
thing
like
imagine.
C
There
were
two
cloud
providers
for
gcp
like
let's
just
like
take
someone
else
like
that
is
that
is
just
gonna
cause
like
confusion
for
those
kubernetes
users.
B
I
I
think
I
think
it'll
be
confusing
if
we
don't
document
it,
I
think
if
we
document
it
it'll
be
fine
right,
like
we
can
say
like
hey
like
these,
are
the
options
to
pass
it
to
these
flags.
V1
is
exactly
what
is
in
three,
but
the
auditory
version
and
v2
is
a
completely
breaking
thing,
only
applied
on
a
new
cluster
and
here's
documentation
on
what
changed
and
what's
different.
C
Having
a,
I
don't
know
like
having
a
flag
on
that,
just
like
turned
turned
off
like
huge
sections
or
replaced
huge
sections
of
the
entry
provider
like
that
to
me
feels
very
doable
as
well,
but
like
when
we've
tried
to
have
two
branches
it
it's
sort
of
not
gone
well
in
the
past.
So
I'm
like
having.
A
Kind
of
like
it's
kind
of
like
a
release
branch,
you
know
you
have
the
like.
If
we,
if
we
make
the
commitment
that
it's
not
we're,
not
going
to
treat
it
as
two
different
forks
that
get
equal
time
and
equal
development
and
we
treat
it
as
the
idea
being
we
want
to
move
on
to
v2
we,
you
know
new
development
goes
on
b2.
V2
really
is
where
we,
you
know
where
we
want
to
go,
and
then
bug
fixes
when
you
know
v1
is
allows
us
to.
A
B
Yeah,
exactly
and-
and
we
don't
even
have
to
go
as
far
to
stay,
to
say
that
we're
not
going
to
add
new
features
in
the
existing
one.
Maybe
that's
something
we
can
re-evaluate
later
but,
like
you
know,
adding
to
justin's
point.
I'm
hesitant
to
start
adding
like
various
flags
and
toggles
in
the
existing
provider,
to
like
start
turning
off
and
turning
on
different
behaviors,
because
that's
going
to
be
a
bunch
of
changes.
B
C
Do
we
care
if
the
do
we
carry
entry
provider
churns
if
we
don't
like,
if
there's
if
there's
code
churn
but
not
like
you
know
it's
like
a
different
code
path,
I
I
don't.
I
don't
think
we
would
object
to
that.
I
wouldn't
object
to
that.
I
don't
know.
B
Like
I,
wouldn't
I
don't
think
we
want
any
of
the
legacy
entry
providers
to
start,
adding
new
code
paths,
new
code
paths
with
new
features
or
new
new
like
feature
gates
or
toggles,
or
things
like
that
right,
like
that's
supposed
to
already
be
deprecated
and
at
some
point
like
we
should
cut
the
tie
from
vendoring
in
the
staging
repo
and
just
vendor
it
in
here
right.
So,
unless
we're
willing
to
do
that
cut
now,
like,
I
don't
feel
good
about
having
all
this
turn
in
kk
and
then
pulling
pulling
it
into
here.
B
So
that's
one
factor
of
it.
The
second
one
is
like
yeah
like
I.
B
If
we're
gonna
make
breaking
changes
right
like
in
like
plumbing
like
so
like
the
implementing
the
cloud
provider
interface
is
not
that
hard
right
and,
like
I
don't
like
to
me,
like
the
amount
of
work
involved
in
adding
new,
toggles
and
flags
in
the
existing
provider
or
and
just
like
doing
a
display
where
you
just
pass
in
a
new
provider
name
and
if
a
different
thing
like
to
me.
That's
the
same
level
of
complexity
and
I
think
from
a
user
experience
perspective.
B
B
But
what
I
would
like
to
say
is
what
I
would
like
to
get
agreement
on
is:
let's
run
with
that
experimental
b2
provider
like
it's
non-binding,
we
can
delete
it
at
any
point,
but
let's
see
where
it
goes,
let's
see
what
changes
we
we
can
break
and
maybe
at
some
point
we'll
compare
like
v1
and
v2
and
we
can
kind
of
do
an
analysis
on
whether
it'd
be
possible
to
to
converge
v1
into
this
new
v2
thing
without
breaking
users.
C
That's
that
does
so.
So,
tactically,
you
are
we're
still
going
to
vendor
v1,
so
we're
going
to
copy
v1
from
kk
into
the
cloud
provider
aws
repo.
It's
not
copying,
it's
an
actual
like
vendor,
import,
okay,
cool
and
so
the
v1.
C
If
I
use
external,
if
I
use
the
cloud
provider
aws
in
v1
mode,
I
use
the
vendored
version.
Now.
If
I
use
v2,
I
get
the
new
code
that
doesn't
that
sounds,
and
we
always
have
the
option
in
the
one
of
sorry
mb2
of
referencing
any
v1
code.
We
want
to
or
copying.
D
A
Yeah
I
like
this
idea
just
because
I
think
it
will
unblock
us
from
you
know
the
mental
block
of
like
we
don't
want
to
do
a
bunch
of
stuff
in
kkk,
but
you
know
it'll
give
us
a
kind
of
a
clean
slate
to
to
get
some
momentum
going
so,
and
I
think
I
think,
maybe
justin
to
alleviate
your
concerns
of
of
confusing
users
with
two
different.
A
You
know
versions
to
use
what,
if
we
we
call
it
v2
alpha
or
something
for
now
until
we
say
okay
enough
people
have
experimented
with
it.
We've
figured
out
most
of
the
issues
and
we
want
to.
You
know
fully
recommend
it
as
the
way
to
move
forward.
Then
we
call
it
v2
or
something
like
that.
C
C
Yeah-
let's
try
it,
I
there
is
more
subtlety
in
there,
I
think
than
than
I
think
you
might
expect,
but
I'm
in
favor
of
doing
that,
like
I
would
certainly
start
by
implementing,
I
don't
know
be
interesting,
so
happens
I
would
have.
I
would
have
probably
like
kept
looks
like
they
were
turning
nil
right
now.
It
would
have
kept
them
returning
the
v,
the
v1
ones
and
like
started,
replacing
them
one
at
a
time.
But
let's
see
where
it
goes,.
C
Like
most
things,
we
don't
need,
but
yes,
I
think
I
think
it's
good.
I
think
there's
also
the
like,
there's
also
an
open
question
of
like.
Should
we.
C
Like
should
we
should
load
balancer
actually
be.
I
guess
it
doesn't
matter
like.
There
was
a
debate
about
whether
we
should
have
put
nlb
into
into
the
aws
cloud
provider
or
whether
we
should
have
said
look.
If
you
turn
on
nlp
or
eob
v2
like
it,
it
should
have
just
like
done
nothing
and
we
could
have
had
the
x
an
external
controller.
Do
it.
I
guess
that's
very
much
the
same.
C
C
When
it
was
in
tree,
we,
there
was
like
very
valid
suggestions
that
probably
we
should
have
done
that
and
a
lot
of
people
like
like
want
to
use
low
balance.
We
want
to
change
one
thing,
as
we
know
from
the
annotations
and
like
it
might
have
been
nice
to
have
a
something
more
like
ingress
there
like
a
a
richer
thing
there,
but.
B
Yeah,
like
one
option,
is
part
of
the
initialized
call
on
line
45.
We
can
just
run
a
per
load,
balancer
type
controller
so
like
instead
of
implementing
the
bouncer
we
just
run.
You
know
one
eob
controller,
one
nld
controller
and
run
with
that.
Possibly.
C
C
So
yes,
I
I'm
okay
with
that.
I
feel
like
yeah
and
so
this-
and
this
is
only
going
to
be
in
the
external
yeah
controller
manner.
So
that's
fine,
because
it's
just
sort
of
like
you
know,
anyone
in
the
community
could
create
the
same
thing
right
like
there.
There
will
be
other
cloud
controller
measures,
that's
fine,
yeah,.
B
If
we
have
an
external
only
one
and
we
see
those
feature
requests
in
tree,
we
can
say
like
oh
look
at
this
shiny
thing
you
have
to
you
know,
use
out
a
tree
though,
and
that'll
fix
like
we
could
like
this
feature
is
implemented,
is
just
out
of
tree,
and
so
I'm
hoping
that
kind
of
moves
the
needle
along
for
for
other
efforts.
C
A
I
think
it
depends
on
their
timeline
and
it
depends
on
how
quickly
this
v2
gets
up
and
running.
I
think
we
just
say:
hey
you
know
I
I
mean
I
think
it's
it's
likely
that
we'll
get
the
v2
up
and
running.
A
You
know
in
a
similar
sense,
at
least
in
an
alpha
state
in
a
few
weeks.
So
if
they
you
know,
if
they're
willing
to
to
contribute
to
it,
then
I
think
we
recommend
that.
C
If,
if
we
can
in
that,
like
you
know,
show
it
show
it
working
in
there
and
then
we
have
it
in
both
which
will
also
be
nice
yeah
but
yeah.
If
it's,
if
it's
a
bug
fixed
to
be
one,
then
presumably
they
should
do
it
in
b1
or
if
it's
that
sort
of
thing-
and
I
presume,
like
the
the
ongoing
annotations
on
load
balancers,
will
almost
go
into
v1
and
we
can
address
what
we
want
to
do
in
v2
in
a
separate
design,
discussion.
C
C
And
I
I
I'm
very
much
in
favor
of
something
exactly
like
that.
Like
you
know,
we've
seen
this
with
ingress
and
ingress
v2
and
like
gclb,
google
cloud
load
balancer
was
using
ingress
v1,
but
ended
up
with
a
sidecar,
something
like
a
storage
glass
effect
like
a
sidecar
crd.
That
would
describe
like
the
gclb
extensions
to
ingress,
and
it
seems
like
that
is
in
every
access
superior
to
annotations.
A
C
D
I
agree
I
pasted
in
chat
a
link
to
a
comment
from
someone
at
aws
that
mentions
they're,
proposing
they
have
the
official
alb
ingress
controller,
but
they're,
proposing
a
more
generic
aws
load,
balancer
controller.
That
would
cover
nlbs
as
well.
C
A
A
Got
it
yeah?
I
had
asked
yang
yang
who's,
one
of
my
co-workers,
who's
working
on
networking
aspects
of
cloud
provider
to
to
join
this
meeting
I'll
have
I'll
see
if
he
can
come
next
time.
I
think
he
can
make
it
this
week,
but
they're
working
on
this,
a
proposal
for
this
so
I'll
see
if
he
is
willing
to
come
share
it
next
week.
I
don't
know
too
much
about
it
yet.
C
If,
if
it's
incompatible
in
terms
of
what
it
needs
to
do,
it
might
be
nice
to
have
like
the
storage
class
analogy
could
hold
and
that
you
have
a
reference
to
a
storage
class
class
which
is
not
the
one.
We
expect
not
one
of
our
built-in
ones,
and
we
say
that's
some
other
controller
is
obviously
doing
this
so
we'll
back
off
and
we'll
do
nothing
effectively.
B
Yeah,
this
came
the
idea
of
like
like
right
now:
service
controller,
just
watches
all
service
type
lvs.
There
was
some
conversations
about
like.
Should
there
be
a
generic,
ignore
the
service
annotation
for
the
cloud
provider?
So
maybe
that's
worth
discussing
more
broadly.
C
And
we're
going
to
talk
with
sick
networking
as
well.
B
So
can
I
get
a
lgtm
on
that
on
that
pr,
and
then
we
can
I'll?
Oh
I'll,
probably
have
like
a
pr
per
interface
implementation
and
then
I'll
do
frequent
status
updates.
Folks,
here.
B
A
Cool,
so
I
lgtms
the
next
one
is
just
bumping
to
one
eighteen,
six
lgtm
that
will
request
reverse
andrew.
A
A
Yeah
is
there
any
reason
we
shouldn't
do
that
now.
B
B
Yeah
I
like
that,
okay
and
then
I
so
actually,
right
after
you
approve
that
one
pr.
I
actually
ended
up
cutting
the
new
release,
tag
for
alpha.1
and
then
I
pushed
the
image
already
and
I
need
approval
on
the
manifest
change.
So
that's
pull
request.
B
A
D
A
Cool
I
just
wanted
to.
I
was
looking
at
the
there's
an
existing.
We
have
two
tests
right
now
for
this
repo
in
prague
that
are
two
two
pre-submits.
I
guess
I
should
say
and
they're
just
really
simple
they're.
Just
one
of
them
is
a
like.
A
make
make
check
which
does
like
go
bad,
go
lent,
go
gofund
and
then
the
other
one
is
like
a
make
test.
A
Good,
so
I
was
looking
at,
I
was
thinking
we
could
conceivably
also
just
have
a
pre-submit
that
just
I
think
I
saw
this
in
the
gce
config
like
just
run
some
you
know
kubernetes
ate
or
something
on
cops
with
cops
configured
to
use
the
the
external
cloud
provider.
So
I
saw
that
cops
supports
external
cloud
provider
to
some
degree.
Sorry
you
can.
A
So
I
was
just
sort
of
following
that.
Does
that
sound
like
a
reasonable
approach
to
you
guys?
Am
I
going
down
the
right
path?
There.
C
Yes,
we
we
also
can
add
like
so
what
you
described
is
like
the
power
user
mode,
where
you
can
essentially
change
any
flag.
You
want
to
in
cops,
and
so
you
can
it's
not
entirely
true,
but
you
can
more
or
less
do
anything
you
want.
We
also
have
like
higher
level
abstraction
flags
and
we
should
probably
add
one
for
using
the
aws
external
cloud
provider.
C
In
the
meantime,
it's
very
reasonable
to
do
it
your
way,
I
did
click
on
the
link.
I
didn't
see.
Those
are
the
two
jobs
we
have
today
right
yeah,
they
aren't
the
new
yeah.
Okay,
it
it
may
prove
easier
to
simply
add
the
higher
level
flag.
I
don't
know,
but
yes,
what
you've
described
sounds
very
reasonable.
Yeah.
C
C
We're
always
trying
to
have
this
could
be
another
app.
This
could
be
a
good
add-on,
actually
we're
always
trying
to
figure
out,
or
I'm
always
trying
to
figure
out
how
to
sneak
add-ons
in
peter's
smiling.
So
like.
I
wonder
if
I
can
sneak
add-ons
in
this
way,
but
yes,
we're
we're
starting
to
add,
like
the
ability
to
so
currently.
C
All
all
manifests
for
things
that
we
install
automatically
are
sort
of
baked
into
the
cops
tree,
the
cops
binary
top
source
code
tree
and
then
in
the
cups
binary,
and
I
am
trying
to
get
that
so
that
it
can
pull
from
external
locations
or
easily
pull
from
external
locations,
be
they
cluster
add-ons
or
other
things,
and
I
can't
remember
exactly
how
much
that
we've
got
in
so
far,
but
I
will.
I
will
push
on
that
as
well.
C
D
A
Yeah,
so,
according
to
sid's
post,
as
it
was
written
a
while
ago,
it's
not
enough,
you
have
to
do
this
other
configuration
along
with
it,
so
maybe
just
combining
all
of
those
into
just
one
flag.
D
A
All
right,
that's
everything
we
have
on
the
agenda
today.
Did
anyone
have
anything
else
they
want
to
discuss
while
we're
still.