►
From YouTube: 2021-01-07 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).
A
A
B
A
A
D
Cool
welcome
the
first
demo
of
the
year,
so
let's
get
started
so
blockers
are
looking
pretty
good
so
on
the
first
one,
the
structured
logging.
D
So
I
left
the
thing
I
know
oh
well,
I
linked
in
a
note
for
epic
20
and
it
looks
well.
My
question
is:
does
this
unblock
us.
B
But
we
don't
for
web
sockets
in
particular.
I
guess
it
kind
of
depends
on
action
cable
to
know
how
much
additional
logging
to
expect
and
whether
this
is
going
to
cause
problems
for
the
cluster
for
non-action,
cable.
It
doesn't
matter
because
that
web
sockets
traffic
is
already
going
to
the
get
you
know
is,
has
already
been
going
to
the
git
node
pool,
and
it
just
isn't
a
lot.
So
it's
not
going
to
cause
a
problem
for
logging.
B
B
D
One
question
I
had
so
on
the
comment
that
roberts
left,
so
he
says
like
step:
one
is
completed
and
step
two
there's
nothing.
We
can
do
and
he
says
this
will
unblock
us.
So
what
else
do
we
need
for
this.
B
It's
linked
under.
A
D
So
it
doesn't
sound
like
there's
any
active
work
going
on.
B
So
I'm
taking
a
look
at
what
we
have
now.
Let
me
share
my
screen.
B
B
How
about
we
just
take
an
action
to
talk
to
the
distribution
team
and
come
up
with
a
plan
for
this?
I
just
really
haven't
been
following
this
closely
me.
Neither
actually
scarback.
Do
you
mind
doing
that.
A
Already
involved
with
it,
it
looks
like
the
work
for
the
gitlab
web
service
container
should
have
already
been
completed
so
I'll
I'll
have
to
review
that
so
yeah
I'll
take
an
action
item
to
review.
A
A
I
think
what
we'll
what
if
everything
works
or
looks
as
desired,
we'll
probably
figure
out
that
we
need
to
simply
upgrade
our
home
chart,
maybe
not
even
that,
because
this
work
looks
like
it
was
in
cng.
So
I
I'll
review
things
and
we'll
come
back
to
it.
D
Awesome,
cool
and
andrew
is
still
out
says,
probably
not
much
update
here,
but
the
labels
stuff,
the
charts
bit-
is
scheduled
for
13.8
and
whatever
this
one
is.
B
So
I
think
I
think,
where
we
stand
here,
is
that
a
lot
of
we
added
saturation
metrics
for
kubernetes.
You
can
see
cpu
memory
in,
like
the
drill
down
details
on
the
dashboards.
We
are
missing
the
top
level
saturation
metric,
which
is
missing
for
git,
so
we
opened
up
an
issue
for
that.
Did
you
talk
to
andrew
when
he
comes
back
we'll
dig
into
it
myself?
B
We're
also
still
missing
the
hba
saturation,
which
is
what
one
of
these
issues
is
for,
which
is
to
tell
like
when
we
are
saturated
for
scaling
like
like,
for
example,
we
hit
our
max
pods
and
we
can't
scale
anymore.
B
I
think
for
as
far
as
where
is
this,
where
this
positions
us
for
websockets
and
api
for
websockets
we're
going
to
create
a
new
service
which
means
adding
a
new
service
to
the
service
catalog.
My
plan
here
is
that
part
of
the
readiness
is
going
to
be
ensuring
that
we
have
the
dashboard
working
for
staging,
and
then
everyone
can
just
like
nod
their
heads
and
say
like
this
is
good
enough
for
prod
for
api.
B
I
think
we'll
need
to
do
a
little
bit
more
work
and
that
will
involve
talking
to
andrew
as
well
so,
but
this
won't
start
until
next
week.
I'm.
A
A
This
one
copy
I'll
just
put
at
the
bottom
that
issue
right
there,
that's
the
one
that
we
created
to
address
the
need
to
add
the
labels
to
various
parts
of
our
chart,
and
that's
the
issue
that
I
pulled
to
do
just
that.
So
I
started
with
the
get
lab
shell.
I
plan
to
move
through
all
the
charts
after
I
get
at
least
one
out
the
door.
A
D
Cool,
I
think
it
might
be
this
one,
but
we
can
ask
andrew
next
week
cool
and
then
the
only
other
one
we've
got
on
the
list
is
pages
and
that
is
progressing.
So
on
e
there's
a
the
latest
comment
with
the
progress,
but
also
on
the
top
of
the
epic.
D
B
I'm
wondering
what
the
the
chances
are
we'll
get
to
pages
in
the
next
quarter.
D
D
What
do
we
have
like?
What?
What
can
you,
what
can
we
see
between
where
we
are
now
obviously,
api
and
api.
D
B
And
web,
unless,
if
we
decide
to
do
pages
after
api.
B
Too
well,
let's
try
to
remain
optimistic.
B
D
Cool
so
it
might
fit.
Well
then,
right
if
we're
assuming
we're
doing
web
after
api,
and
then
that
might
line
up.
B
Cool,
I
wanted
to
run
through
the
labeled
issues,
because
I
think
there's
been
some
additions
since
our
last
meeting,
and
I
added
a
couple.
One
of
them
is
that
I
I
discovered
this
morning
that
we're
missing
this
unicorn
sampler
interval
from
the
monitoring
section
of
gitlab
yaml.
This
isn't
supported
in
the
charts.
It
is
supported
in
omnibus
we
set
it
to
10
seconds
or
no.
We
set
it
to
5
seconds,
but
the
default
is
10..
B
D
What
does
that
one?
Well
just!
Why
do
we
need
to
use
that
like?
Could
we
put
in
a
kind
of
a
just
a
overview
of
what
this
does
to
help
andrew,
and
I
schedule.
B
Yeah,
this
is
for
how
this
is
for
prometheus
metrics
and
it's
how
often
metrics
are
sampled
from
the
application,
so
this
happens
like
every
10
seconds
currently
by
default.
B
There
was
a
change
made
a
year
ago
by
ben,
which
I
guess
I
guess
like.
B
I
have
an
outstanding
comment
to
bend.
I
understand
a
little
bit
better
why
this
was
reduced
from
ten
to
five
seconds,
but
currently
there's
a
divergence
in
our
configuration
between
vms
and
kubernetes,
and
I
don't
like
it
like.
I
want
to
make
sure
that
we're
the
same
yeah,
so
I
guess
like
I'll
wait.
Till
ben
gets
back
to
us.
I
I
already
have
the
mr
to
change
the
application
default,
so
it's
just
a
matter
of
getting
it
maintainer,
reviewed
and
merged.
If
that's
the
direction,
we
go.
B
The
second
one
I
added
is
the
our
nginx
bypass
issue
and
this
is
being
able
to
set
the
bouncer
type
for
the
web
service
so
that
we
can
bypass
nginx,
I'm
upgrading
this
to
a
blocker,
because
I
I
think
I'm
thinking
more
and
more.
This
is
the
direction
we're
going
to
go
for
future
migrations
that
we're
not
going
to
use
the
nginx
ingress.
B
Of
course,
we'll
have
to
see
we'll
test
this
on
web
sockets
first,
but
I
mean
we're
really
close
to
getting
this
mr
merged.
I
don't
think
there
are
any.
There
are
no
outstanding
comments,
I'm
basically
just
waiting
for
a
maintainer
approval,
so
I
expect
this
to
happen
today.
B
Aha,
yes,
gitlab
pages
cognitive
support
and
proxy
request
buffering.
So
I
guess
like
if
engine
x
goes
proof,
then
this
goes
poof
because
we
won't
be
using
nginx
anymore.
That's
that's
the
dream,
but
you
know
we'll
see
what
happens.
B
B
I'm
not
sure,
like,
I
think
this
issue.
The
thought
of
this
issue
was
like.
We
should
make
it
the
default
in
the
chart
if
it's,
what
we're
doing
for
gitlab.com,
but
I
think,
like
I'm,
gonna,
remove
this
as
a.
D
B
For
that,
I
can
talk
briefly
about
the
helm3
progress
just
as
kind
of
an
overview.
It
was
a
bit
hairy
for
get
by
pound
files
because
of
prometheus
operator
because
we
needed
to
upgrade
the
chart.
I
would
say
most
of
the
hairiness
happened
on
preprod,
which
was
nice,
because
you
know
it
didn't
cause
any
problems
or
interrupt
anyone.
B
Once
we
got
through
that
hairiness,
then
we
moved
to
staging
and
that
went
fairly
smoothly.
I'm
in
the
process
of
upgrading
the
ops
cluster
now
just
waiting
for
an
mr
approval
that'll
be
done
then
I'll
move
to
the
ci
cluster.
Hopefully
there
will
be
no
issues
there
and
then,
after
that,
we
just
need
to
do
staging.
B
D
So
the
only
question
at
the
moment
is
we
have
a
patch
to
put
out
after
the
security
release,
so
hopefully
we'll
be
able
to
get
the
security
release
wrapped
up
before
too
long
packages
are
still
building
right.
Now,
once
that's
done
once
we've
got
the
security
released,
hopefully
mairo
will
be
able
to
get
their
patch
started.
B
Well
for
the
patch
release
it.
Actually,
I
don't
think
there's
anything
that
this
would.
This
doesn't
impact
the
patch
release
at
all,
because
the
patch
release
is
only
going
to
the
release,
it's
not
being
deployed
to
staging.
That's.
B
Maybe
so
in
that
case,
can
I
just
go
ahead
and
talk
to?
I
don't
think
maya's
online,
yet
right
or
maybe
she
is
but
see
if
we
can
start
it
now.
D
Let's
just
make
sure
these
packages
build,
I
think
once
the
packages
are
well,
let's
just
make
sure
they
publish,
I
think,
once
we
start
the
publish,
they
were
probably
quite
safe
and
then
yeah.
I
think
it's
probably
fine.
B
Great
do.
D
You
have
a
sort
of
rough
schedule
so
assuming
we
can
get
staging
done
this
week,
are
you
thinking
like
monday
for
production
or
how
long
do
you
want
to
wait.
B
Yeah,
I
just
put
it
right
in
the
agenda
here,
so
I'm
thinking
we'll
be
done
done
on
monday,
with
this
epic,
like
we
can
close
out
the
epic
monday
staging
today,
production
monday
and
I'm
planning
to
finish
up
the
ops
nci
clusters
today
worst
case
tomorrow,.
B
I
wish
I
had
a
better
sense
of
what
the
impact
is
going
to
be
like.
I
assume
it's
no
downtime,
but
what
do
you
think.
A
Oh,
it's
probably
gonna
be
a
downtime,
I'm
pretty
sure
everything
gets
recreated.
So
I
had
to
do
our
zono
clusters,
one
at
a
time.
Why.
F
A
A
But
we've
got
an
issue
to
test
in
pre-prod,
so
I
will
certainly
do
it
there
first
to
validate
that.
That's
that's
not
going
to
be
a
problem
or
if
it
is
going
to
be
a
problem
we
could
handle
that
appropriately.
Luckily,
we
have
zonal
cluster.
So
if
there
is
a
blip
in
the
service,
we
could
always
take
it
out
of
rotation
perform
the
upgrade,
throw
it
back
into
rotation,
keep
going.
B
D
So
remind
me
what
the
what
this
blocks!
If
what
do
we
need
to
do,
this
nginx
upgrade
ahead
of.
B
The
biggest
thing
for
me,
personal,
the
biggest
thing
for
for
me
personally,
I
think,
is
the
fact
that
we
have
diverged.
We
have
diverged
on
charts,
so
we
can't
take
master
anymore.
So
as
we're
like
making
improvements
to
charts,
we
have
to
always
like
pick
them
into
our
forked
branch,
which
really,
which
really
sucks.
B
I
guess
like
there
is
the
possibility
that
you
know
when
we
bypass
engine
x.
This
problem
really
goes
away
skybrake.
I
was
thinking
about
this
and
what
what
happens?
If
we
change
this
like
for
the
transition,
if
we
decide
to
transition
to
a
service
type
of
load
balancer,
can
we
do
that
seamlessly
or
is
that
going
to
be
another
one
of
these
things
where
we
have
to
do
it?
One
cluster
at
a
time.
A
I
think
we
could
do
it
seamlessly
because
we'll
still
have
the
service
available
to
us.
The
nginx
service
so
we'll
just
add
a
new
endpoint
in
h.a
proxy
for
each
of
the
clusters,
and
then
we
could,
if
we
want
play
with
the
weights,
if
necessary,
to
make
sure
that
we're
not
causing
a
problem.
And
then
we
can
just
turn
down
the
nginx
service
endpoint
and
then
eventually
remove
them.
B
A
B
And
then,
and
then
the
nginx
upgrade
thing
is
like
none
other.
This.
F
B
Yeah,
let's
keep
that
as
an
option.
I
guess
what
we
could
even
do
for
the
we
could
even
like
test
this
out
on
canary
for
a
while,
like
to
be
on
the
safe
side
right.
We
could
just
use
the
load
balancer
service
type
on
canary,
see
how
that
works.
If
that
works,
I
think
I
would
feel
pretty
confident
like
I
don't.
I
don't
see
any
big
risks
here.
B
A
Seemingly
failing
health
checks,
I
looked
at
that
yesterday
and
the
last
occurrence
I
solved.
This
happened
on
the
31st
december,
but.
B
F
B
Yeah,
I
mean
actually
we
could
just
like
do
we
could
we
could
configure
it
on
one
cluster
or
two
clusters
and
run
it
running
like
split
yep,
so
that
could
be
one
way
we
could
test
it
out.
Yeah,
I'm
looking
forward
to
seeing
like
whether
this
problem
goes
away
and
that
our
that
our
drops
were
due
to
nginx
and
also
this
other
issue
this
this,
like
long.
B
Yeah,
okay,
cool!
I
think
that's
pretty
much
all
I
got.
A
D
Monday,
cool,
okay,
and
is
there
anything
we
need
to
do
to
help
out
with
web
sockets
or
action?
Cable.
B
B
Yeah,
I'm
glad
you
brought
that
up
amy,
because
I
completely
forgot.
I
asked
the
developers
to
open
up
an
issue
because
of
our
lack
of
action-cable
prometheus
metrics,
and
this
is
like
this
is
what
I
see
is
like
the
only
like
big
thing
to
come
out
of
the
readiness
review.
B
The
the
issue
is
that
the
metrics
that
we
have
right
now
are
only
only
cover
the
protocol
upgrade
for
the
websockets
connection,
but
that's
all
we
get
so
there's
very
little
visibility
into
errors,
for
example
through
prometheus.
I
think
we're
kind
of
limited
to
logs
here.
B
B
I
think
I'll
send
it
to
you
today
for
review
and
then
for
the
issue
which
is
which
was
like
supposed
to
be
driven
by
development,
but
like
we
have
the
architecture
and
then
I
think
I'll
just
try
to
answer
these
questions
as
much
as
possible
and
then
close
it
out.
B
But
yeah,
that's
that's
pretty
much
it
where
we,
where
we
stand
now
we're
started
to
bring
up
the
infrastructure.
I
think
scarborough.
You
brought
up
the
note
pools
yesterday.
C
B
And
I
think,
like
I
said
before
my
plan
here,
is
to
get
this
running
in
staging
and
then
add
it
to
the
service.
Catalog
make
sure
we're
okay
with
the
monitoring
and
then,
if
we
are,
then
we
can
move
forward.
D
D
Yeah,
I
think
so.
I
think
we
should
make
sure
that
happens
before
we
go
ahead
and
put
this
into
production,
because
I
feel
like
it's
going
to
be
on-call
engineers,
who
feel
the
most
pain
from
this,
and
I
think
once
something's
up
and.
F
B
B
We
need
to
yeah,
I
mean
I.
I
didn't
think
that
this
would
be
a
blocker,
but
if
we
want
to
change
it
to
a
blocker,
maybe
we
should
have
a
discussion
with
development
to
kind
of
scope
out
the
work
to
see
what
was
going
to
be
involved.
I
know
that,
like
sid
asked
about
this
feature
in
the
last
development
group
conversation
and
there's
a
lot
of
attention
on
it
and
there's
a
lot
of
like
frustration
that
it
hasn't
happened
already.
D
But
we
have
to
keep
that
in
mind
yeah.
I
totally
agree.
I
totally
agree,
I
think,
just
with
this
one
I
I
think
we
need
to
make
sure
there's
definitely
a
commitment
to
schedule
this
and
get
it
done.
Otherwise,
it's
just
going
to
sit
in
a
backlog.
I
fear
so
yeah.
Let's
have
a
let's,
have
a
chat
and
make
sure
that
developers
know-
or
at
least
we
absolutely
know
like
what
needs
to
happen
and
who's
going
to
do
it
and
when
it's
scheduled
for.
B
That
sounds
that
sounds
good
I'll.
Maybe
maybe
we
can
bring
this
to
andrew's
attention
as
well.
B
Okay,
I'll
just
add
this
to
the
agenda
here
so.
B
D
I
actually
have
one
next
week
yeah,
so
I
can.
I
could.
B
D
Fantastic,
is
there
anything
else?
It's
one
thing:
rehab
you'd
like
us
to
cover
or
share
she
kindly
joined
us
today.
Yeah.
F
Well,
I'm
just
sitting
here
trying
to
understand
what
you're
saying
really
but
yeah.
I
I
think
it's
an
interesting
meeting,
I'm
only
starting
to
learn
the
details
of
kubernetes
so
to
see
in
action.
It
was
a
different
story.
Yeah.