►
From YouTube: 2022-01-26 GitLab.com k8s migration EMEA/AMER
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
Week,
okay
last
few
days
of
work,
and
I
want
to
see
today's
demo.
C
C
The
problem
is,
I
was
I'm
using
jaeger
tracing
to
visualize
the
traces
and
it
doesn't
really
offer
any
any
way
to
like
analyze
like
a
bunch
of
traces
and
doubt
any
anything
from
that.
Should
I
start.
B
A
C
C
C
So
I
tried
tracing
a
few
pipe
lines,
for
example.
This
is,
I
think,
two
days
yeah
the
two
days,
so
you
can
see
you
can
see
patterns
within
one
pipeline
so,
like.
C
Normal
things
like
jobs,
that
don't
that
are
not
blocking
like
this
careful
stuff
like
that,
can
be
easily
seen,
and
you
can
drill
down
further,
so
the
jobs
of
the
pipeline
that
is
triggered
by
in
dev,
but
I
couldn't
figure
out
how
to
use
a
figure
to
to
sort
of
kind
of
aggregate
analysis
on
like
multiple
traces
and
see
which
ones
are
commonly
taking
a
lot
of
time.
Stuff.
Like
that,
I
don't,
I
don't
think
jaeger
provides
any
such
functionality,
other
tools
like
lightstep
and
honeycomb.
They
provide
that
functionality.
A
I
think
in
stackdriver
we
also
can
do
this
kind
of
aggregation
of
traces
right.
I
think
we
are
using
this
even
for
some
of
the
go
projects,
so
maybe
we
could,
instead
of
sending
traces
to
giga,
we
could
also
configure
to
send
them
to
a
stack
driver.
Maybe
if
we
have
better
tooling
for
analyzing
traces
there.
I
didn't
look
into
jaeger
since
a
long
time
and
also
too
deep
and
into
a
stackdriver,
but
I
mean
the
idea
of
of
telling
the
tree
is
that
that's
more
or
less
vendor
agnostic
right?
C
A
Yeah,
but
I
really
like
this
approach
because
I
always
wondered:
do
we
have
built-in
metrics
and
gitlab
to
just
see
when
different
pipeline
jobs
start
and
end
to
exactly
get
that
out
of
our
pipelines?
Right
and
I
guess
collecting
this
matrix
would
be
not
really
working,
because
it
would
have
a
very
high
cardinality,
I
think,
depending
on
which
pipeline
you
run
it
on
and
so
on.
But
exactly
for
these
cases,
maybe
tracing
is
the
right
solution.
C
There
is
the
problem
that
we
sometimes
rename
our
jobs.
So,
for
example,
recently
we
removed
the
auto
deploy
prefix.
So
it's
like
every
job
had
like
a
auto
deploy
prefix.
I
don't
know
if
this
job
from
october
might
show
it
yeah
see
or
to
deploy,
wait
him.
So
I
don't
know
if
this
kind
of
renaming
of
jobs
would
affect
the
aggregate
analysis,
but
we
can
try.
A
C
No,
unfortunately,
I've
not
seen
anything
that
is
actionable
sort
of.
F
D
Fit
with
the
sort
of
stuff
andrew
mentioned
on
the
platform
direction
right
like
perhaps
this
is
a
kind
of
a
sort
of
theme
we
want
to
pull
out,
which
is
properly.
You
know
proper
visibility
or
observability
into
deployment
pipelines.
C
F
Yeah
I
mean
we,
I
guess
we'd
probably
first
need
to
talk
to
product
teams
about
building
that
kind
of
stuff
into
the
product.
A
I
think
that
starts
to
get
interesting
is
also
points
like
in
our
runners
when
they
start
pulling
images
how
long
it
takes
to
pull
an
image
when
it
starts
to
get
started
up
and
so
on,
because
this
is
where
we
can't
really
look
into,
because
we
can't
script
this
in
any
way.
So
this
is
happening
in
the
application,
and
I
don't
know
if
you
have
that
but
unload
these
numbers
right
to
see.
If
you
have
a
trend
of
increasing
pull
times
for
images
and
things
like
that.
B
So
when
you
look
at
the
at
the
job,
the
ci
output
of
the
job,
you
have
foldable
sections
right,
so
yeah
the
there
are
some
of
them.
There
are
generated
by
the
runner
itself
and
those
are
something
for
download
time
preparation
time
in
terms
of
the
is
the
image
ready
and
things
like
that.
B
Yeah
sure
I'm
just
saying
that
if
the
data
is
there,
we
can
try
to
get
it
out.
Even
if
it's
just
one
of
query,
query
or
if
we
are
going
to
build
an
api
for
getting
this
out.
C
So
the
thing
is
the
way
it
output
into
the
into
the
job
logs.
You
can
pass
this
and
extract
the
timestamp,
so
I
had
done
that
for
one
of
them,
but
I
think
I've
not.
C
C
So
you
can
do
this
for
any
pipeline.
I've
done
it
for
pipeline,
but
drills
down
into
the
package
of
pipeline.
So
like.
A
D
Interesting
because
yeah,
that
would
might
be
an
an
interesting
kind
of
addition
like
if
we'd
have
had
that
on
packaging.
For
the
last
six
months,
we
would
possibly
have
seen
dev
coming
right,
yeah.
C
C
C
The
package
of
pipelines-
I
think
they
don't
change
much
so
might
be
easier
to
analyze.
Those
that's.
D
True,
they
tend
to
add
jobs,
not
like
rename
and
stuff
yeah.
What
do
you
want
to
do
is
the
next
step
ruben
like
do
you
think
you
have
enough
to
write
an
issue
about
this
approach,
or
is
it
something
which
sort
of
I
guess
like?
We
will
certainly
be
discussing
platform
metrics
in
the
next
few
weeks.
D
C
Yeah,
there
are
multiple
approaches
to
do
this.
For
example,
I
think
robert
had
done
something
with
pandas
recently
this
month.
A
C
Sort
of
get
like
mean
durations
of
the
packager
pipeline
package
of
pipeline
jobs,
so
I
don't
know
if
that
will
be
more
effective
and
I
think
the
verify
team
is
also
working
on
or
thinking
about
doing
this
kind
of
thing
natively
in
in
the
product.
D
C
C
Yeah,
I
can
record
it
in
in
an
issue:
yeah
yeah,
awesome,
okay,.
C
I
think
pipelines
have
increased
by
like
20
minutes
in
the.
C
E
And
this
is
going
to
drastically
change
when
we
complete
the
next
stage
of
the
staging
canary
pipeline
work
that
graham
and
meyer
are
working
on
too.
But.
D
C
C
Jaeger
is
simply
a
ui
to
see
your
traces,
so
it
depends
on
your
collection
of
traces
and
sending
it
to
jaeger
if
you're
doing
it
in
real
time,
it'll
be
visible
in
real
time,
but
to
do
it
in
real
time.
You'll
have
to
probably
integrate
with
the
product.
I
guess
because
what
I'm
doing
now
is
simply
using
the
jobs
and
pipelines
api
to
extract
the
start
time
end
times
and
then
push
that
to
jaeger
yeah.
F
One
one
of
the
challenges
that
you
run
into
there
is
because
you
have
a
hierarchy
of
these
spans.
The
root
span
has
started,
but
it
hasn't
finished
yet
right,
and
so
you
basically
don't
have
that
root
span.
Yet
so
you
can
sort
of
find
these
subspans
potentially,
but
the
the
visualization
is
kind
of
partial
and
yeah,
so
I've
when
I've
tried
to
do
that
kind
of
thing.
In
the
past
it
wasn't
super
usable
for
long-running
still
ongoing
jobs.
For
this
reason.
F
Yeah
I
snuck
one
in
there,
so
I
figured
out
one
of
the
issues
that
we
were
seeing
with
redis
replicas,
where
we've
got
a
vm,
a
set
of
vms,
and
we
want
to
add
some
pods
as
replicas
to
those
vms.
F
So
I
have
already
some
vms
running
and
if
I
ask
this
vm0
what
its
role
is,
it
is
the
primary
and
it
has
the
vm-1
as
a
replica,
and
so
I
now
want
to
add
in
this
case
it's
only
got
one
replica
instead
of
two.
It
doesn't
really
matter
that
much
in
this
case
for
the
purposes
of
this
demo,
so
I'm
going
to
install
helm
to
set
up
now
a
redis
cluster.
So
this
we've
already
seen
in
the
past.
F
I
think
skavik
already
demoed
this,
maybe
a
couple
weeks
ago,
two
weeks
ago,
so
this
is
gonna,
go
ahead
and
install
the
helm
release
for
ls,
okay,
so
we've
got
our
first
pod
that
is
coming
up,
and
this
is
still
a
little
bit
messy
in
that
it
goes
through
some
weird
kind
of
reboot
cycle.
F
So
it's
it's
kind
of
waiting
for
dns
to
become
up
to
date
and
only
once
dns
is
up
to
date.
Will
the
sentinel
process
be
able
to
actually
discover
this
redis
process,
so
that's
kind
of
why
we
we
have
this
failure
here
on
the
sentinel
container
within
this
pod,
and
this
is
also
why
well,
I
guess
we
see
ready
one
of
two,
so
it
it
takes
a
while
for
this
to
reattempt
and
reconnect,
and
I
think
it
now
managed
to
properly
do
it.
F
So,
yes,
so
we've
got
ready
two
out
of
two,
and
so
it
goes
on
to
the
next
pod.
So
what
we
should
already
be
able
to
do
and
yeah
you
can
see
the
first.
The
first
step
is
going
through
a
crash
loop,
so
it's
sort
of
a
similar
issue
there,
but
now
that
we
already
have
one
of
these
parts,
I'm
gonna
kind
of
fast
forward
and
set
this
node
0
to
be
a
replica
of
our
vm
cluster.
F
F
And
so
I'll
go
ahead
and
do
that
and
if
I
now
go
ahead
and
ask
the
vm
what
its
role
is
still
the
primary.
But
now
it's
got
two
replicas
right,
so
we've
got
the
vm,
and
now
we've
got
node
0
as
the
as
the
other
replica
and
it's
a
host
name,
not
an
ip
address.
So
this
is
the
novelty.
This
is
the
thing
that
we
fixed,
which
has
been
plaguing
us
for
like
two
weeks.
E
One
of
the
items
I
had
a
question
on
is,
I
couldn't
tell
I
remember,
doing
the
research,
but
I
forget
what
the
result
was.
The
id
of
the
replica
changes
anytime.
A
new
pod
comes
back
online,
which,
during
one
of
our
testing
scenarios,
we
were
adding
one
pod
at
a
time
to
our
infrastructure
and
because
of
that
configuration
change,
older
pods
get
recycled,
so
they
get
generated
with
a
new
replica
id
and
because
of
that
sentinel
thought
the
pod
was
down
when
it
was
in
fact
up
and
participating
at
least
within
redis.
E
F
I
don't
know
yet
I
haven't
seen
that
resurface,
but
I
think
it's
a
scenario
that
I
should
try
and
recreate
as
well.
Yeah.
E
Okay,
I
guess
the
other
question
I
had
is
we
had
spun
up
two
issues.
One
was
to
investigate
creating
a
deployment
where
it
kind
of
joins
the
cluster
automatically,
and
for
this
we're
able
to
successfully
get
rolling,
I
don't
have
a
quick
way
to
demo
that
so
I
can't
really
showcase
it,
but
I
did
at
least
prove
inside
the
issue
that
it's
possible.
E
Okay,
akbad
you've
been
working
on
sshd
in
between
your
release
management.
You
want
to
talk
a
little
about
the
blocker.
G
There
is
a
blocker,
I
think,
as
reported
by
sean,
it's
something
related
to
sh.
Sorry,
the
rsa
keys,
like
are
not
readable.
I
think
by
the
shd,
if
I
remember
correctly-
and
this
is
blocking
us
from
proceeding
to
production-
and
one
thing
from
our
side
is
also
the
observability
like-
I
think
the
mr
is
now
ready
somehow
like.
I
will
just
work
on
the
comment
from
scarbeck
and
we
can
merge
it
later
and
I
think
it
would
be
ready
for
us,
but
it's
plugged
from
the
other
side
from
the
source
code
team.
G
E
G
E
Okay,
that's
fine!
I
just
want
to
make
sure
that
you
know
before
we
push
this
into
production,
that
that
readiness
review
has
been
completed
and
been
reviewed
by
other
members
of
our
infrastructure
team,
and
I
know
performance
testing
was
on
that,
so
we're
blocked
for
moving
from
production
but
stuff
like
that.
Shouldn't
be
blocked
at
this
moment
in
time.
E
Okay,
the
last
thing
on
the
agenda
alessio
or
rather
amy
tasked
alessio,
with
trying
to
figure
out
what's
going
to
be
blocked
when
the
dev
instance
gets
migrated
over
to
gcp
during
that
maintenance
procedure.
E
E
So
if
anyone
else
has
any
thoughts,
I
just
kind
of
want
to
bring
this
threat
to
everyone
else's
attention.
Just
in
case
amy,
I
say
you've
got
a
question
that
you
may
want
to
verbalize.
A
I
think
it's
still
hard
to
tell
I
mean
just-
were
able
today
to
fix
the
most
urgent
chef
issues
to
get
a
chef
run
through,
but
now
the
devil
is
in
the
details.
Right
shouldn't
get
everything
working
as
we
need
it
and
it's
really
hard
to
say
concrete
date.
I
mean
I
would
hope
that
the
with
the
help
of
baloo
should
not
be
able
to
work
on
this
node.
A
Also
to
get
the
configuration
working
for
gitlab
itself
and
see
what
the
what
ifs
you
need
to
fix
and
add
via
chef,
then
testing
the
data
migration.
So
this
all
still
needs
some
time
and
I'm
not
sure
if
you
would
be
able
to
manage
this
next
week
I
mean
we
could
try
to
and
a2-
and
I
hope
too,
but
it's
really
hard
to
tell.
D
Let's
try
to
like
if
it
means
like,
let's
try
and
get
this
done
as
soon
as
we
can,
because
it's
causing
so
many
pain
points
like
definitely
like.
If
that
means,
we
need
to
ask
for
some
help
like
if
we
need
to
value
to
help
with
things
or
or
whatever
that
is
then
then,
let's
ask
I
would.
I
would
definitely
love
to
have
this
completed,
like
the
migration
completely
do
the
clean
up
later,
but
I
would
love
to
have
this
migrated
like
asap
like
this
week
or
early
next
week.
A
Yeah,
so
I
will
spin
up
a
few
issues
for
what's
still
missing.
That
came
apart
today,
and
I
think
we
can
in
parallel
also
start
already
with
testing
the
data
zoom,
because
we
have
a
working
machine,
at
least
for
copying.
Data
too
right
now
and
I'll,
see
that
we
get
gitlab
up
and
running
as
it
needs
to
be
usable.
B
I
was
going
to
add
something
to
this,
which
is,
I
think
we
should
for
any
blockers
that
we
have
in
terms
of
things
that
we
can't
do
during
immigration
like
this.
I
think
we
should
spawn
up
a
new
issue
and
fixing
that
issue,
because
it's
really
hard
to
believe
that,
basically,
if
dev
goes
down,
we
can
shut
down
the
the
business
because
we
are
we
can
I
mean
I
can
understand
that
we
can
deploy
new
stuff
fine.
I
can't
really
understand
that,
but
not
being
able
to
roll
back
not
being
able
to
scale
anything.
B
This
is
not
acceptable
in
my
view,
so
I
mean
if
we,
this
is
something
that
we
have
to
fix.
Sooner
or
later,
I
say
sooner
because
it's
it's
really
unbelievable.
D
Yeah,
I
think
we
can.
We
can
figure
that
stuff
out
following
the
migration
for
sure,
because
what
I
want
to
make
sure
we've
got
a
few
days
notice
of
is
to
schedule
this
in
so
that
release
managers
can
plan
around
that.
Like
you
know,
we
we
will
certainly
not
want
to
be
trying
to
do
everything.
On
the
same
day,
there
will
be
some
down
time,
so
that's
kind
of
the
the
you
know.
Let's
get
an
estimate
in,
but
but
yeah
henry
to
your
point
like.
D
D
A
Can't
start
the
data
copy
testing
and
that
will
give
us
also
time
estimate
for
how
long
the
downtime
needs
to
be,
and
if
we
confirm
that,
then
we
also
know
how
how
big
the
impact
will
be
of
the
migration
right
and
then
it's
easier
to
scatter
a
point
where
we
want
to
do
this
like.
If
it's
very
long,
then
we
would
maybe
consider
doing
it
on
a
weekend
or
at
low
traffic
times.
But
if
it's
just
for
an
hour,
maybe
then
we
could
do
it
just
at
any
time
that
we
use
it.