►
Description
2023-04-05
Recording
[GC] space vs app finalisation
A
B
The
problem
was
the
space.
Finalizer
was
like
failing
the
first
time
around
or
something
it
was.
It
was
deleting
the
space,
but
it
was
still
being
retried
for
some
reason.
I
remember
and
then
Second
Time
Around
the
space
wasn't
there
and
it
would
fail
right.
So
we
changed
it
so
that
it
ignores
that
failure,
so
that,
if
you,
if
it's
a
not
found
error,
it
should
just
carry
on
because
it
means
this
place.
You're
trying
to
delete
is
already
gone.
Yeah.
B
Oh
yeah,
because
of
patching
and
stuff,
but
we
were
wondering
if
we
do
need
that
special,
like
space
finalizer,
we
went
through
the
comments
and
the
command
history
and
this
seems
to
be.
The
reason
seems
to
be
like
we
need,
for
if
we
don't
wait
for
all
the
apps
to
be
gone
before
we
finalize
the
space
like
there
are
issues
things
stop
failing,
but
I
was
wondering
if
we
should
get
rid
of
the
space
finalizer
and
just
let
what
everything
is
failing
because
of
not
found
errors
to
tolerate,
not
found
errors.
B
C
A
A
B
A
bit
of
a
smell,
if
you
have
a
finalizer
that
needs
to
wait
for
another
finalizer
and
like
in
general,
they
should
be
tolerant
and
they
should
just
carry
on
as
much
as
they
can,
because
as
much
as
possible,
because
otherwise
yeah
the
we
end
up
with
an
environment
that
couldn't
be
uninstalled.
Basically
because
for
some
reason,
yeah.
A
B
It's
also
quite
complex:
it
waits
for
60
seconds
and
stuff
like
it
looks
at
the
deletion
dates
to
see.
If
it's
older
than
60
seconds,
if
it's
sold
there,
then
it
gives
up
or
something
and
I
hope
that
all
this
logic
we
can
just
get
rid
of
just
because
you
know
Cuban
kubernetes
takes
care
of
it
and
stuff.
A
A
C
If
there's
nothing
else
can
I
mention
the
tidy
up
Manchester
doing
at
the
moment
on
the
Handler
test.
Maybe
might
be
something
that's
worth
mentioning,
so
we
had
an
idea
a
while
back
that
it'd
be
nicer
if
all
the
big
Json
comparisons
and
the
handless
tests
were
actually
taken
care
of
and
the
presenter
package,
because
that's
the
thing
where
we
we
turn
records
into
presented,
lists
of
Records
or
presented
record.
C
The
handlers
are
becoming
a
lot
more
concise,
and
now
you
can
sort
of
read
them
Page
by
page
and
see
what's
going
on
there
and
all
the
things
that
are
covered
so
we're
filling
in
the
old
hole
has
been
missed.
I
think
previously
you'd
go
through
2000
lines
of
Json
and
just
it's
not
readable,
we're
down
to
roll
I,
think
alphabetically.
C
C
Well
any
Json
path
really,
and
it
will-
and
you
can
put
a
matcher
on
the
other
side
of
it
and
assert
about
portions
of
your
Json.
So
that
makes
it
a
lot
more
readable.
So
you
can
do
in
one
line
what
you
were
doing
in
hundreds
and
you
can
even
do
fancy
things
as
well
like
when
you
have
lists
and
you've
got
resources,
which
is
a
slice,
an
array
you
can
put
square
brackets
star
square
brackets
and
then
a
field
name.
C
C
C
So
we
reckon
that's,
probably
not
really
a
problem
on
GAR
anymore.
We
think
Jr
is
just
being
very
efficient
with
its
garbage
collection.
It
goes
and
deletes
blobs
very
quickly
and
we
can
see
in
the
go
container
registry
code
that
it
checks
if
a
blob
exists
and
if
it
is
there,
when
it
pushes
an
image,
it
doesn't
upload
that
part
of
The
Blob.
C
It
doesn't
upload
that
blob
part
of
the
image,
so
it
seems
like
build
pack
lifecycle
or
kpac
is
a
good
point
to
be
retrying
machine
droplets
for
us,
I
I,
don't
know,
I've
asked
the
k-pak
people
at
what
they
think,
but
brick
wall.
So
far,
so
there's
a
message
on
the
kubernetes
kpac
slack,
probably
the
second
last
one.
If
anyone
can
poke
somebody
that
knows
somebody
in
kpac
to
have
a
look.
I,
don't
know
it's
not
really
affecting
us
anymore.