►
From YouTube: 2020-09-24 GitLab.com k8s migration EMEA
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
How
is
it
double
booked?
C
Hi
martin
yeah
scarbeck
jeff.
Now
these
days
computer
is
actually
the
only
social
thing
you
need.
Apparently
it's
so
bad
yeah
screw
2020
series.
B
B
All
right,
so
skype
we
went
through
the
blockers
this
morning,
there's
nothing
new.
Basically,
we
just
cleaned
up
the
issues
that
are
no
longer
relevant
or
no
longer
blockers
or
ones
that
we've
worked
around
and
then
we
just
reduced
the
list
to
the
things
that
we're
tracking,
which
basically
is
build
traces
or
build
logs
the
service
mapping
and
then
the
cross
az
network
traffic.
B
B
Yeah
yeah,
so,
basically
everything
everything
is
fine,
we'll
just
continue
with
the
work
to
get
case,
workloads
compatible
with
multi-cluster,
which
is
going
to
be
a
challenge
but
graeme,
and
I
talked
through
it
a
little
bit.
He
seems
like
he's.
Okay
with
the
changes
so
far,.
A
B
So
what
we
want
to
do
is
just
kind
of
assess
the
impact
of
interrupted
connections
whenever
we
cycle
pods,
and
we
were
just
discussing
how
you
know
we're
going
to
be
cycling,
pods
a
lot
and
it's
quite
a
bigger
impact
than
it
is
on
virtual
machines,
because
we
have
the
safety
of
draining
h.a
proxy,
plus
installing
the
omnibus,
before
we
interrupt
those
connections
by
sending
the
sigin
to
puma.
So
right
now
those
connections
are
being
interrupted
in.
We
only
have
a
10
second
window.
B
If
you
look
at
all
of
the
projects
and
like
how
long
we
stream
data
from
giddily
for
git
https,
specifically
the
99th
percent
dial,
is
hovers
around
six
seconds.
So
it's
it's.
Actually,
I
think
10
seconds
is
probably
fine
for
the
majority
of
projects.
If
you
look
at
just
gitlab,
though
the
story
changes
significantly,
if
you're
looking
like
the
gitlab
namespace,
you
can
see
that
the
99th
percentile
jumps
up
to
like
40
seconds.
B
If
you
look
at
www.gitlab.com,
it's
terrible
like
we
have
and
of
course,
if
you,
you
know
anyone
who's
cloned
www.com
books,
so
I
think
what
was
happening
was
is
that
we
were
kind
of
hurting
ourselves
a
bit
with
kubernetes
on
canary,
which
could
explain
why
we're
seeing
like
a
small
number
of
errors.
B
A
That
so
during
cluster
upgrades,
this
will
significantly
slow
down
slow
those
operations
down.
A
B
A
B
One
item
on
this
issue
is
for
me
to
get
the
exact
window
of
time
we
have
on
vms,
so
that'll
be
a
good
comparison
point,
so
we
at
least
know
we're
no
worse
than
what
we
have
on
vms.
I
think
it
I
think
vms
is
around
like
two
to
three
minutes.
It
might
be
as
long
as
five
minutes,
but
I
have
to
check
the
reason.
C
Why
I
was
saying
five
minutes
is
mostly
because
you
you
remember
like
when,
when
we
started
like
we
were
playing
with
the
number
of
paws,
with
first
sidekick
shards,
that
we
were
migrating,
we
were
setting
ourselves
too
low,
which
created
some
well
unnecessary
turn
like
we
can
overshot
this
and
like
see
the
impact
and
like
lower
it,
it's
easier
than
just
creating
a
lot
of
noise
like
whether
we
are
causing
a
problem
or
not
or
whatever
is
happening
there.
You
know.
A
B
We
also
found
at
least
with
aj
proxy.
Remember
we
added
this
hard
stop
after
option
to
kill
aj
proxy
processes
because
inevitably,
there's
always
a
connection,
that's
just
hanging
on
forever
with
git
ssh,
not
good
https,
but
so
I
think,
even
if
we
track
the
number
of
connections,
it's
possible,
it
wouldn't
that's
true.
It
wouldn't
matter.
A
B
Also,
it's,
I
think
I
think
this
is
specifically
that
the
blackout
period
is
specifically
for
puma,
and
these
https
connections
aren't
going
through
puma
puma
is
interacting
with
workhorse
to
do
the
authorization
and
then
workhorse
is
going
grpc
directly
to
italy,
so
our
liveliness
liveliness
is
going
through
to
puma,
but
really
puma
isn't
the
one?
That's
keeping
these
connections
open
forever.
It's
it's
workforce
does
that.
Does
that
make.
A
B
Yeah,
so
I
don't
think
the
blackout
period
would
know
if
there's
an
active
connection
for
workhorse.
I
think
to
do
that.
We
would
need
like
a
workhorse
liveliness
or
something
right
that
would
yeah.
A
B
Well,
we'll
see.
A
Slightly
related
to
this,
your
merge
request
that
you
had
and
I
tried
to
take
some
feedback
that
we
got
from
jason
and
add
a
test
and
such.
But
I
I
pulled
that
nearest.
B
A
Day
I
open
up
a
merge
request
against
your
request,
but
it's
the
test
does
not
work
yet,
and
I
can't
understand.
B
Yeah
I
mean
I'm,
I
currently
we're
working
off
the
gitlab
conference
for
now
and
then
we'll
get
this
other
thing
reviewed
as
quick
as
possible.
A
Okay,
I'm
next,
do
you
all
want
to
see
what
I'm
looking
for
during
the
evaluations
of
sidekick,
cues.
B
A
Sure
it's
knotting,
you
said
at
least
okay.
I
don't.
I
didn't
really
prepare
anything,
so
I'm
just
gonna
kind
of
walk
through
the
things
I
look
at,
but
I've
got
a
list
of
everything
that
I
do
look
at
inside
of
this
very
long
issue
at
this
point
where
I'm
migrating
cues
from
catch
all
to
catch
nfs
under
the
evaluation
section
is
like
everything
that
I'll
be
clicking
on
here.
So
one
of
the
first
things
that
we
look
at
is
a
query
that
andrew
helped
me
put
together.
A
We
have
a
tool
that
he
created
that's
installed
and
running
on
all
the
sidekick
catch-all
air
catch
nfs
fleet
servers.
So
this
is
what
things
look
like
when
we're
actively
using
nfs.
In
this
case
this
was
the
mailer's
queue
last
week
when
we
identified
that
it
was
using
nfs
unnecessarily
that
has
since
been
fixed.
So
these
days
there's
nothing
running
on
catch
and
effects,
but
what
we
want
to
see
is
basically
nothing
which
nothing,
but
we
want
it
to
say:
zero.
A
A
All
we're
doing
is
taking
we're
just
creating
a
comparison
of
whether
a
job
was
running
versus
whether
it
actually
actively
used
nfs,
and
this
is
so
such
that
we
have
enough
times
that
we've
kept
we've
captured
enough
data
to
be
confident
that
we're
actively
using
nfs,
because
if
we
see
a
little
spike,
it
doesn't
necessarily
mean
we
use
them.
If
that
just
means,
we
probably
tried
to
read
some
data
or
something,
but
we
want
to
try
to
hit
all
possible
scenarios.
A
So
this
is
what
catch
nfs
looks
like
today,
there's
always
something
that
the
operating
system
is
doing
so
these
I
usually
ignore,
but
for
an
idea
of
where
we
are
today
for
our
catch-all
fleet,
we
still
have
quite
a
few
pieces
that
are
being
accessed
so
soon.
A
So
there's
a
few
in
here
that
kind
of
look
a
little
iffy,
so
here's
one
as
an
example
we're
trying
to
write
to
or
we're
trying
to
read
from
a
directory
called
srv
gitlab
shared
town.
A
A
So
this
is
one
that
I
know
I
could
ignore,
because
if
we
look
at
all
the
events,
it
only
says
139,
but
I
know
there's
more
than
that,
because
I've
seen
it
other
in
other
areas.
We
used
to
see
all
the
catch-all
virtual
machine
or
yeah
virtual
machines
in
here,
and
this
has
been
happening
since
april
so
stuff
like
this.
A
I
know
I
could
ignore
because
we're
not
using
that
nfs
mount
since
april
of
this
year,
but
I
did
open
up
an
issue
because
we
definitely
have
something:
that's
not
working
correctly
for
this
particular
worker.
In
this
case,
it's
the
repository.
A
A
So
it's
still
checking
for
something
that
we
used
to
have
mounted,
but
we
no
longer
have
this
mounted,
so
this
will
always
fail
because
you
know
it's
not
going
to
exist
for
these
servers
nor
the
pods.
So
I
opened
up
an
issue
to
start
that
discussion
and
there's
a
few
people
chatting
in
to
figure
out
what
needs
to
be
done
with
that.
C
Can
you
can
you
link
that
issue
in
in
the
demo
doc?
Just
so
I
have
it
as
a
reference.
A
And
then
there
is
another
one
that
caught
my
attention
if
I
could
find
it
quickly.
So
this
is
another
repository
import
worker.
Oh.
A
I'd
create
an
issue
for
this,
this
one
nope,
it's
not
this
one.
Maybe
that's
why
I
didn't
show
an
issue.
A
Maybe
it
was
this
one.
This
one
doesn't
look
familiar
though
okay,
so
this
one's
showing
the
same
behavior
where
it's
trying
to
access
an
entire
repository,
but
I
know
this
was
never
possible
inside
of
our
catch-all
fleet,
because
we
don't
mount
this
directory
inside
of
our
sidekick
nodes
and
if
we
actually
go
down
further,
we
see
that
the
root
the
error
message
is
spawning
from
our
getally
nodes.
A
So
for
stuff
like
this,
I
also
ignored
completely
but
outside
of
that
the
majority
of
all
these
errors
are
just
the
standard
errors
that
we
get
across
all
sidekick
servers.
You
know,
there's
always
some
sort
of
execution
that
expired
or
some
unable
to
access
some
other
url,
that's
related
to
someone's
job
reaching
out
to
do
some
work
or
you
know,
failure
to
import
stuff
or
fail
to
export
stuff.
C
C
C
A
C
A
A
All
right,
well,
let's
move
on!
Is
there
anything
else,
jarv
that
you
want
to
talk
about
bloggers,
or
should
I
just
watch
the
recording
for
that.
B
Yeah,
I
don't
think
there
are
any
there's
nothing
there.
That's
new
information
for
you,
but
yeah
feel
free
to
watch
the
recording.
A
Slash
looking
for
feedback,
so
batch
three
was
defined
and
it's
actually
inside
of
kubernetes
at
this
moment
in
time
batch
four,
I
have
defined
basically
anything
that
was
in
batch
three,
but
I
wasn't
getting
enough
data
for
I
decided
to
push
out
that
way.
I
could
just
get
rid
of
batch
three
and
move
those
into
kubernetes
as
quickly
as
possible.
A
So
I'm
sorry
for
my
font
size
not
large
enough,
but
here
I've
selected,
whoa
one
two,
three,
four:
five:
six:
seven,
eight
nine
ten
eleven
cues
slated
for
batch
four
I've
already
created,
merge
requests,
driver
them
waiting
reviews,
but
the
execution
rate
for
all
these
is
very
low
like
less
than
one
per
second
across
all
of
these,
and
some
of
these
don't
even
show
up,
so
I
can't
even
get
them
to
show
up
in
our
charts,
which
means
they
probably
haven't
executed
in
the
last
24
hours.
A
My
goal
here
for
batch
four
is
to
move
them
off
of
the
catch-all
fleet
into
the
catch
nfs
fleet
that
we
could
use
our
tooling
to
capture
as
much
data
as
possible.
I,
with
the
execution
rate
being
so
low.
I
don't
suspect
that
this
will
have
any
sort
of
negative
impact,
because
the
amount
of
workers
on
catch
nfs
is
a
lot
less
than
catch-all.
A
So
that's
my
goal
with
batch
four
and
all
these
were
just
the
ones
that
were
pushed
out
our
last
demo
meeting
these
cron
jobs
were
slated
for
the
following
batch
because
we
didn't
have
any
information
about
those
they're
just
marked
as
yes,
I
noted
somewhere
in
some
issue
that
I
did
do
the
necessary
research,
and
I
referred
back
to
the
research
we've
done.
Crime
jobs
only
add
something
to
the
queue
they
don't
actually
perform.
The
actual
work
there's
a
different
job
that
will
pick
up
the
work
and
do
that.
A
C
C
Shouldn't
deal
with
with
nfs
at
all.
A
A
A
A
Information
that
I
was
provided
so
because
of
that
I'm
performing
that
investigation
to
some
extent
by
moving
it
to
catch
all
or
catch
nfs.
I
hate
these
names,
moving
it
to
catch
nfs
and
seeing
if
it
accesses
nfs.
Okay,
so
you
know,
we've
done
batches
one
two
and
three
already
batch
four
is
being
defined.
A
My
next
goal,
because
I
suspect
bash
four-
will
take
a
while,
like
it
will
probably
I'll,
probably
want
to
leave
that
operating
on
catch
nfs
for
maybe
a
week
just
to
make
sure
the
jobs
were
executed
enough
that
we
we
have
a
high
confidence
that
we
are
or
are
not
using
our
shared
storage,
but
after
that,
what's
blocked
is
everything
I
created
issues
for
already
I
figured
what
we
would
do.
Amy
got
me
the
epics
that
are
associated
with
some
of
these.
A
A
Well,
yes,
moving
all
these
over
just
to
figure
out
what
data
is
being
written
or
read
from
where
and
adding
that
to
these
issues
that
I've
created
to
help
bolster
the
need
to
have
someone
investigate
these
as
much
as
possible
like
at
this
moment
in
time.
I
don't
know
what
to
do
with
these
issues,
except
for
adding
information
through
discovery.
C
Yeah
and
I
think
that
that
on
its
own
wouldn't
be
helpful
to
developers
as
well-
maybe
they
know,
but
you
would
also
need
to
spend
a
lot
of
time
to
give
them
the
context
of
what
does
this
actually
mean,
because
I'm
looking
apart
from
pages
and
and
ci,
like
the
other
ones
that
are
left
all
of
them,
are
with
100
new
teams.
C
When
I
say
new,
I
mean
like
new,
like
six
to
eight
nine
months
new
falls,
so
they
were
probably
just
utilizing
the
same
concepts
that
existed
around
so
unless
we
can
provide
them
with
like
hey.
We
know
for
sure
this
is
writing
things
down
and
you
are
using
something
you
need
to
kind
of
go
between
these
two
things
and
find
out
what's
happening
right,
yeah.
B
C
A
C
C
C
Like
if,
if
you
start
collecting
this
data
immediately
right
after
batch
3,
you
should
see
some
changes
coming
up
at
the
same
time,
meaning
you'll
be
collecting
batch
four
data
and
ci
job
traces
are
in
it's
in
in
their
final
stages.
Right
like
there
is
a
merge
request
open
right
now,
that's
adding
some
functionality.
A
C
A
C
C
Four,
okay
and
they
might
provide
you
some
noise,
so
it's
gonna
make
it
more
difficult
for
you
to
make
it
like
to
figure
out
which
one
of
those
is
actually
creating
noise,
but
at
the
same
time
you
said
these
other
ones
are
so
low
in
traffic
that
you
know
like
you're,
just
gonna
be
waiting
anyway,
so
if
they
start
creating
too
much
noise,
you
definitely
then
know
you
have
some
data
right
like
you
can
remove
it,
and
we
can
then
parallelize
that
work
with
with
stage
groups
and
then
you
leave
batch
three
with
well
barely
any
traffic
anyway,
so
yeah,
you
kind
of
paralyze
it
any,
but
you
can
actually
roll
that
out
pretty
much
today.
C
Scans
and
the
requirements
management
thingy
at
the
top-
that's
top.
C
C
A
I'm
perfectly
happy
with
doing
that,
because
I
know
batch
4
is
going
to
last
a
little
while
longer
than
necessary.
So
if
we
do
find
something
writing
nfs,
I
could
gather
that
data
as
quickly
as
possible,
and
I
could
pull
that
off
of
this
batch
and
push
it
into
the
future,
and
at
that
point
we
already
have
infraded
working
on
that
issue.
With
the
information
I
provided.
A
A
C
As
long
as
you're,
actually
not
only
sitting
and
waiting
for
sidekick
and
looking
at
sidekick
numbers
like
how
is
it
reaching
nfs,
I
would
I
mean
I'm
not
amy
here,
but
I
would
really
like
to
see
the
jar
get
some
help
on
the
cross.
Az
multi-cluster,
blah
blah
thing,
sorry,
jeff.
C
It
needs
a
better
name
and
the
reason
the
reason
for
that
is
not
only
because
jar
is
a
release
manager
now,
but
it's
more
if
we
can
parallelize
some
of
this
work
better
for
all
of
us,
because
I
think
the
next
thing
that
I
want
to
see
is
web
and
api.
I
don't
want
to
wait
for
sidekick
to
finish
for
us
to
start
the
next
step
and
given
that
ci
jobs
are
in
their
final
stages
of
them,
starting
to
roll
roll,
it
out.
C
C
All
right!
Well,
thanks
for
sharing,
I
feel
sufficiently
confident
that
we
are
doing
great.
So
thanks.