►
From YouTube: 2020-09-18 CAPZ 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
Good
morning,
everybody
this
is
the
cluster
api
provider
azure
office
hours
meeting
for
september
17th.
We
follow
the
cncf
standard
process,
so
please
be
nice
to
each
other
and
raise
your
hand.
If
you
want
to
ask
a
question
or
say
something,
and
now
we
can
get
started
with
today's
meeting.
Please
add
your
name
to
the
attendees
list
in
the
document.
A
A
B
Stuff
yeah,
so
I
mean,
as
you
obviously
know,
but
just
to
let
everybody
know
we
talked
briefly
yesterday
about
what's
going
on
with
e2e.
In
terms
of
you
know,
we
have
several
jobs
that
provision.
B
We
have
several
tasks,
that
provision
clusters
and
they're
all
running
in
serial
and
now
we're
proposing
to
add
an
ipv6
cluster
and
if
that
runs
in
serial,
then
our
tests
are
going
to
take
a
horrendous
amount
of
time,
but
we
all
thought
this
should
have
been
working.
What
I
found
out
yesterday-
and
I
can
show
empirically,
is
that
the
dash
focus
flag
that
we
were
passing
in,
even
if
it
didn't
have
an
argument,
is
short-circuiting
the
sharding
and
the
multiple
nodes
that
that
ginkgo
does.
B
So,
if
we're
and
we
weren't
actually
using
the
focus
flag
in
the
context
of
the
pr
testing,
so
I
have
a
pr
out
there
that
just
you
know,
removes
the
entire
flag
and
that
seems
to
fix
it.
This
corresponds
directly
to
a
comment.
I
remem
remember,
reading
by
ansi
the
author
of
dinko,
saying
oh
yeah.
If
there's
focus,
we
don't
bother
doing
the
sharding
logic
and
using
multiple
nodes
because
reasons
I've
forgotten.
Why?
B
I
can't
find
this
comment
now,
but
I
know
it
exists
and
I'm
sure
this
is
a
thing,
but
I'm
having
trouble
finding
a
justification
for
it.
Other
than
that
that
we
can
see
that
this
happened
in
the
in
the
pr.
So
I
think
if
we
merge
that
the
other
thing
that's
confounding
here
is
obviously
nader.
You
were
showing
yesterday
that
promoting
our
it
clauses
and
the
testing
up
from
outside
of
context
seems
to
suddenly
unblock
the
parallelization
right.
A
C
Yeah,
I
was
just
going
to
ask
it's
kind
of
the
same
thing:
are
you
removing
the
focus
flag
always
or
just
when
it's
not
set,
because
in
test
and
fry
we
set
the
focus
flag
for
the
ci
tests.
So
since
we
have
like
two
suites,
we
have
capi
and
then
the
azure.
D
B
B
That's
what
it
looks
like
to
me
and
I
think
that's
what
happens
when
you
use
focus
in
genko
now
again,
I'm
having
trouble
finding
the
justification
for
this,
but
I
know
I've
read
that
I
was
starting
to
look
at
the
code
for
ginkgo
yesterday
I
was
having
trouble
finding
where
that
happens.
B
B
Yeah,
so
I
guess
I
mean,
maybe
I
need
to
pin
that
down
in
terms
of
where
that
is
in
the
code
or
documentation.
So
we
can
know
for
sure
that
focus
always
destroys
the
parallelization.
B
But
but
that's
what
seems
to
happen.
A
Yeah,
it
might
be
yeah,
maybe
there's
like
another
option
you
have
to
set
or
something
like,
but
when
I,
when
I
was
showing
you
all
yesterday
and
I
made
them
hit
and
remove
the
contacts,
I
think
I
had
a
focus
at
the
time
so
because
I
was
only
running
the
two
tests
of
azure,
it
seems
to
be
running
in
parallel,
so
you
might
have.
B
B
I
mean
I
was
hoping
to
make
the
simplest
change
possible
just
and
and
the
documentation
suggests
that
you
know
these.
It's
should
be
getting
parallelized,
whether
or
not
they're
inside
of
a
context
or
not,
but
we're
not
all
seeing
the
same
behavior.
So
it's
very
confusing
yeah.
A
B
A
B
B
Well,
so
I
guess
the
the
the
impetus
for
focusing
on
this
yesterday
was
that
we
really
can't
merge
the
ipv6
change
until
we
figured
out
the
parallelization,
because
that's
just
going
to
add
an
egregious
amount
of
time.
So
so
I
still
think
it
has
something
to
do
with
focus,
but
obviously
I
don't
have
the
final
answer
so
I'll
continue
looking
at
it
this
morning,
cool
okay,.
A
You
can
move
on
okay,
thank
you,
matt,
for
all
that
work,
yeah
sure
cecil,
you
mentioned
like
the
fast
delete
pr
yeah.
C
Yeah,
sorry
so
yeah,
I
just
wanted
to
give
an
update.
So
yesterday
we
talked
a
bit
about
how
we
could
make
azure
cluster
delete
faster.
C
So
currently,
what
happens
is
whenever
you
delete
a
cluster
that
triggers
all
the
machines
to
be
deleted
in
cluster
api,
so
cluster
api
waits
for
all
the
children
deletes
all
the
children
manually
and
then
waits
for
and
all
the
children
and
their
children,
and
so
that
deletes
all
the
machines
which
then
triggers
azure
machines
to
get
deleted,
and
that
happens
before
the
cluster
is
deleted,
which
means
the
azure
cluster
waits
for
the
vms
to
be
deleted.
C
Before
it's
deleted
and
since
in
cab
z,
we
delete
every
like
resource
by
order
of
dependency,
one
by
one.
C
It
can
sometimes
take
a
long
time
and
whenever
you're
deleting
your
entire
cluster
and
your
cluster
is
in
a
resource
group
and
that
resource
group
was
created
as
part
of
your
cluster,
which
means
it's
managed,
then
deleting
that
resource
group
is
typically
enough,
because
the
when
you
delete
the
resource
group
azure
will
go
and
take
care
of
the
dependencies
for
you
and
it's
usually
faster,
because
you
don't
have
to
wait
for
the
result
of
every
single
resource.
C
So
this
is
kind
of
a
attempt
like
best
effort,
attempt
to
leverage
that
when
we
can
so
to
take
a
look
at
the
pr,
I
haven't
added
tests
yet,
but
basically,
what
it
does
is
whenever
you
check
for
whenever
you
delete
a
an
azure
machine,
it
checks
if
the
owning
cluster
has
a
delete
timestamp,
which
indicates
that
the
cluster
is
being
deleted.
C
Then
we
skip
the
azure
machine
deletion
and
we
just
remove
the
finalizer
right
away
and
then
we
go
to
the
azure
cluster
or
the
azure
cluster
takes
care
of
deleting
the
resource
group
and
cleaning
up
the
whole
thing
if
those
conditions
aren't
met.
So
if
this
is
not
a
cluster
deletion,
if
we're
only
deleting
an
azure
machine
or
if
the
resource
group
was
brought
by
the
user,
which
means
there
may
be
other
resources
in
that
resource
group
that
we
don't
want
to
delete.
So
we
don't
want
to
delete
the
entire
group.
C
A
A
A
Okay,
I
guess
next
thing
also
ccl,
since
checks
are
here.
C
Yeah,
so
I
just
wanted
to
remind
everyone
that
there's
a
doc
that
we
put
out
there
two
weeks
ago
and
if
you
haven't
had
a
chance
to
review
it.
Yet
please
take
a
look.
I
kind
of
brought
this
up
at
the
capi
office
hours
yesterday
as
well,
because
the
design
would
require
adding
a
sentinel
file
from
the
bootstrap
provider
perspective
or
like
in
the
bootstrap
provider
contract,
but
this
is
really
the
azure
side
of
it.
C
C
C
A
C
Sounds
good
I'll
check
with
jargon
and
one
of
us
will
do
it.
A
A
A
A
I
run
it
like
at
least
10
times
like
it
always
works
for
me,
like
the
upgrades
with
different
versions.
I
think
it's
just
a
timeout
issue,
because
it
seems
to
be
mostly
failing
for
timing
out
and
the
periodic
job.
A
But
in
all
my
local
tests,
it
seems
to
take
about
30
minutes
roughly
that
one
average
for
that
part
of
the
upgrade
machine
like
upgrading
the
three
control
plate
machines
from
like
the
one
version
to
the
other
version
and
the
timer
we
have
is
at
40
minutes.
So
I
don't
know
how
slow
how
slow
that
is
on
the
ci.
You
would
think
the
ci
would
be
faster
than
my
local
machine,
but
I
haven't
been
able
to
recreate
it.
A
I
just
kind
of
hesitant
to
just
bump
up
the
time
just
because
40
minutes
seems
like
a
lot
already,
so
I
was
hoping
to
wait
for
how,
like
the
changes
with
the
parallelization,
all
that
end
to
end
refactoring.
A
Maybe
that
will
clear
up
some
some
of
that
wishes
and
like
after
failing
for
like
three
four
times
on
the
periodic
job
like
past
yesterday.
So.
A
D
What
kind
of
setup
do
you
have
vocally.
A
Nah,
it's
pretty
it's
not
very
new.
I'm
looking
looks.
D
D
And
just
curious,
I
I've
had
issues
running
locally
the
tests
where
it
would
be
flaky
mostly
on
it,
attempting
to
clean
up
after
itself
it
just
you'll,
just
kind
of
hang.
D
Okay,
how
many
are
you
dedicating
to
the
docker
vm.
A
C
A
D
How
how
many
cores
are
okay
on
ci,
like
is
ci
only
running
with
three
cores,
like
it's,
probably
a
pretty
constrained
container,
that's
fair,
but
then
again,
why?
Why
aren't
these?
Are
we
seeing
like
flakes
upstream
in
candy,
I
saw
a
email
go
through
about
kcp
flakes
upstream.
A
I
think
that
wasn't
the
adoption
and
there's
a
pr
to
fix
some
of
the
tests
for
it.
I've
seen
a
couple
of
prs
to
fix
end-to-end
stuff,
but
nothing
about
the
upgrade
one
and
because
we
were
having
trouble
with
like
the
nineteen,
zero
and
nineteen
one,
and
all
that
I
like.
I
think
I've
done
like
20
30
upgrade
tests
in
the
last
like
few
weeks
and
they've,
never
timed
out
for
me.
But
now
I
think
I
have
a
good
laptop
or
something.
C
C
Yeah,
that's
true:
they
don't
have
the
time
at
issue
as
much
how
about
we
just
increase
the
timeout
just
to
collect
data,
since
this
is
running
periodically,
and
we
know
how
many
failures
we
got
over
the
last
two
weeks
and
we
just
try
to
like
do
this
over
a
week
and
see
if
we're
still
seeing
the
same
amount
of
flakes.
C
A
C
A
C
A
A
B
Since
we're
here
cecil,
do
you
want
to
pair
on
making
new
images
iran?
I.
B
C
Yeah,
let's
do
it.
They
were
released
yesterday,
right,
yeah,
okay,
we'll
do
that
they'll
be
available
by.
C
B
C
A
Okay,
oh
by
the
way,
sorry
a
while
back,
I
told
cecile
and
david
that
I
would
try
to
find
a
better
way
of
doing
the
release,
notes
and
I
looked
into
it
a
little
bit
and
then
I
realized
that
cappy
have
their
own
like
little
tool.
That
does
that
so,
and
the
kubernetes
one
that
we
use
really
is
not
gonna
be
very
suitable
for
us.
So
I
started
trying
to
take
the
cappy
one
and
make
some
changes
to
it.
C
A
A
C
C
A
C
B
D
Why
don't
we
put
them
in
the
pr
template
in
kind
of
a
comment
like
a
comment
block,
so
it's
just
like
it
prompts
the
proper
usage
yeah.
That's
what.
A
C
C
A
Yeah
we
can
try
it
for
a
few
more
weeks
and
then
decide
sounds
good.
Okay,
I
think
that's
it.
Thank
you,
everybody
for
joining
the
meeting
and
have
a
good
trust.
A
good
day.