►
From YouTube: 20190422 - 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).
A
Hello
and
welcome
to
the
April
22nd
edition
of
the
cluster
API
provider
EWS
office
hours-
it
is
a
holiday,
so
I
expect
live.
Attendance
will
be
relatively
small
today,
we'll
copy
the
agenda
into
the
chat.
If
there
are
any
topics
that
you
would
like
to
cover,
please
go
ahead
and
add
them
to
the
agenda
and
I'm
pretty
sure
we
have
everybody
already
on
the
attending
list.
For
today
to
start
I
did
want
to
start
by
reiterating
one
of
the
PSA.
A
So
we
had
last
week,
there's
going
to
be
a
demo
to
say
kws
on
the
3rd
of
May.
Nadir
is
going
to
be
doing
that
demo.
So
if
anybody
would
like
to
attend
to
go
ahead
and
watch
that
I'd
go
ahead
and
encourage
that
next
item
that
we
have,
we
have
0
dot,
2.1
tracking
or
a
bug-fix
release.
I
think
there
are
two
outstanding
PRS
that
we
potentially
want
to
get
in
before
we
cut
that
release
and
that's
PR
number
7,
26
and
706
with
726.
A
C
They
put
it
on
the
agenda
to
discuss
a
little
bit
later,
but
I
think
the
the
the
only
thing
blocking
that
PR
is
deciding
what
should
block
that
PR.
There
was
I
think
three
different
sort
of
directions.
We
could
take
it
or
we
could
take
it
one
so
I'm
having
to
discuss
that
now
or
later.
We
can
pick
it
up
at
the
later
agenda
item.
Thank
you
all.
A
Right
next
item
is:
there's
a
PR
out
there
712
for
updating
the
owners,
aliases
and
security
contacts.
It's
mainly
synching
with
the
recent
cluster
API
changes
to
those
files
and
sig
leadership.
It
was
kind
of
outdated,
especially
on
the
sig
leadership
standpoint.
One
other
changes
is
that
I
removed
Denisha
from
the
cluster
API
provider,
AWS,
maintainer,
z--
I-
don't
think
that's
really
controversial,
because
it
will
actually
not
remove
any
actual
capabilities
that
Denis
she
would
have
being
part
of
the
thicket
of
US
leadership.
She
would
already
have
kind
of
maintainer
access
anyway.
A
So
please
take
a
look
at
that
PR.
Unless
there
are
any
objections,
we'll
we'll
merge
that
in
a
week
one
other
thing
that
I
want
to
bring
up
was
related
to
the
end
to
end
tests.
They
are
all
wired
up
now
and
they're
firing
for
all
merges
to
the
master
and
also
we
have
periodic
jobs
wired
up,
but
they
are
currently
failing
and
let
me
go
ahead-
are.
A
They
are
post
submit.
One
of
them
is
post,
submit
the
basal
CI
e
to
e
failing
job
is
a
post
cement,
job?
Okay,
so
it
wouldn't
block
PRS
anyway
and
I'm,
the
other
ones,
a
periodic
job,
so
another
of
them
are
actually
in
the
few
are
blocking
workflow
got
it,
but
ideally
we'd
be
able
to
use
those
to
gauge
the
health
for
release,
say
for
like
you're
at
2.1
reasonable.
However,
since
they
haven't
quite
worked
since
they've
been
wired
up,
you
know
they
do
not
really
good
signal
right
now.
A
B
C
So
there's
been,
there's
been
a
decent
out
of
discussion
on
there.
It's
a
pretty
meaty
change,
even
if
the
codes
not
not
so
not
so
complex.
The
three
sort
of
outstanding
questions
that
I
was
tracking
were
what
tagging.
If
any,
we
want
to
do
for
shared
resources
like
provided
B,
pcs
on
the
in
cluster
cloud
provider,
like
there's
a
constant
that
says
that
you
to
egg
it
was
shared
and
that's
what
that
means.
But
the
values
never
seem
to
be
referenced
in
that
code.
A
What
I
don't
think
we
should
effectively
try
to
tag
anything
that
is
provided
to
us,
because
we
may
not
even
have
permission
to
modify
that
resource.
So
I
think,
assuming
that
we
can
tag
kind
of
a
predefined,
pre-existing
infrastructure
that
people
are
ending
to
us
as
little
presumptive,
but
other
than
that.
It
also
would
require
that
somebody
providing
us
this
would
have
to
pre
tag
it
and
and
I,
don't
think.
That's
necessarily
a
very
good
user
experience
either.
C
That
was
sort
of
my
concern
as
well,
especially
if
we
have
we're
planning
on
having
many
clusters
sharing
a
VP
C
and
either
that
gets
to
be
a
very
large
list
of
shared
tags
or
there's.
You
know
yet
another
concept
of
like
a
super
shared,
so
yeah
I'm
happy
to
revisit
that
I
guess
in
the
future,
but
it
sounds
like
for
this
PR.
Maybe
we
can,
as
is
where
it
preserves
the
existing
functionality
of
not
requiring
provided
resources,
be
tagged
in
any
particular
way.
C
A
A
A
C
It's
so
that
I
mean
tests
pending
testing
it
looked
like
it
would
be
sufficient
to
fix
the
the
backwards
compatibility
just
at
like
hard
coding.
Looking
for
that
old
managed
tag,
as
well
as
the
sort
of
new
owned
tag,
and
so
there
will
be
one
reference
or
two
references
to
that
until
we
drop
support
for
that
2.0
lifecycle.
D
A
E
B
C
Okay,
that
helps
all,
although
and
if
it
gets
out
of
line,
we'll
write
up
some
steps
and
I.
Would
you
know
on
the
Br.
C
C
The
previous
behavior
was
that
it
would
decide
it
managed
the
resource
if
it
was
managed
by
any
cluster
API
code
base
that
had
access
to
the
resource
so
hard
and
I
can
tell
you
a
story
where
this
is
an
improvement,
but
it
does
add
some
complexity,
so
that
was
the
I
think
Vince.
That
was
your
your
comment
on
the
his
manage
is
unmanaged
calls
I
just
wanted
to
raise
that
and
make
sure
like
I
wasn't
missing
something
important
to
there.
D
D
D
D
E
So,
just
specifically,
the
last
bullet
on
the
agenda
is
worth
calling
out.
I,
so
I
think
there's
some
strange
racing
happening
happening
in
the
network,
reconciliation
with
respect
to
the
security
groups.
I
guess
the
only
reason
why
I
haven't
raised
too
much
of
us
think
about
it.
Just
yet
is
because
I
have
a
feeling
that
706
may
help
it
a
little
bit
but
basically
non-deterministic
lis.
E
The
network
reconciliation
will
create
a
security
group
and
then
immediately
fail
on
that
security
group
already
existing
like
two
seconds
later,
and
it's
like
a
30%
of
the
time.
40%
of
the
time
issued
that
I
only
noticed
because
I
make
like
10
to
15
clusters
a
day
but
yeah.
So
it's
just
something
that
I
think
this
PR
may
fix.
E
A
E
Yeah
and
and
I'd
like
to
add
I,
actually
think
that
the
addition
of
those
two
additional
ingress
rules
for
the
IP
n
IP
actually
slightly
exacerbated
the
race.
Just
by
adding
a
little
bit
of
extra
processing
to
the
security
group
that
it,
it
catches
a
little
bit
more
frequently
than
it
was
before
so.