►
From YouTube: 2022-06-13 Kubernetes Migration Working Group
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
I
just
started
recording,
so
we
are
at
the
time.
Do
we
want
to
wait?
I'm
just
here.
Thank
you.
Andreas
and
patrick,
both
of
both
of
you
are
here,
appreciate
it
cool.
Okay,
let's
get
started
today
is
june
13th.
This
is
the
kubernetes
migration
working
group.
Let's
get
started
from
the
agenda,
so
first
is
what
what
has
been
done.
B
C
Do
you
want
to
jump
straight
to
the
discussion,
though,
because
I
think
andrew
you
can
only
join
us
for
a
short,
while
is
that?
Oh.
E
At
this
point,
I
guess,
let's
start
with
a
discussion.
In
any
case,
we
switched
to
that.
I
put
this
topic
in
the
agenda
and
I
pinged
you
directly
a
couple
of
times.
I
think
last
week
to
be
sure
that
we
have
the
right
the
right
people
in
this
call
to
try
to
take
a
decision
here.
So
the
main
topic.
E
The
main
reason
why
I
put
this
individual
is
try
to
understand
what
we
want
to
do
with
the
italy
on
kubernetes
and
if
there
is
a
decision
that
has
been
taken
or
to
migrate,
the
kubernetes
at
the
current
italy
service
into
kubernetes
or
if
any
plan,
to
do
that.
This
is
a
a
request
from
delivery
that
we
need
to
understand
if
we
need
to
plan
any
migration
ongoing
or
if
it's
something
that
is
still
under
the
discussion
or
is
taking
other
other
ways.
E
F
F
I
think
the
question
becomes,
what
form
of
gideon
are
we
trying
to
support
in
kubernetes
and
how
out
of
the
box
do
we
want
to
make
it
giddily
cluster
poses
a
more
interesting
question
because
it
requires
the
prefect
database
currently
and
storage
nodes
and
auto
scaling
storage
nodes
is
a
terrible
idea.
I
think
everybody
kind
of
has
agreed
on
that.
The
question
becomes:
do
we
want
to
auto
scale
the
prefect
database
or
how
do
we
want
to
handle
that
within
kubernetes?
So
I
am
a
little.
F
I
guess
I
just
want
to
make
sure
we're
on
the
same
page
here.
I
don't
think
we're
migrating
italy
to
anything.
Italy
in
and
of
itself
should
run
in
kubernetes,
but
I
don't
believe
there's
a
migration
step
necessary
we're
not
taking
and
making
a
separate
version
of
getaway
for
kubernetes.
That's
not
the
plan
and
italy
as
it
is,
should
run
in
kubernetes
and
I
think
that's
our
goal.
G
Yeah,
I
can
talk
about
why
maybe
from
a
dedicated
and
overall
other
perspective
and
of
course
the
delivery
team
can
do
it
as
well.
But
you
know
most
of
our
direction
is
to
move
towards
cloud
native
deployments
of
gitlab
at
a
very
high
level.
It's
that's.
G
We've
seen
a
lot
of
benefits
from
operating
that
way
with
rails
and
other
services,
and
you
also
get
a
lot
more
capability
in
terms
of
operators
to
do
like
day
to
automation,
because
you
have
a
control
plane
that
runs
in
kubernetes
like
persistently,
whereas
without
it
you
have
something
like
terraform
or
ansible,
which
is
sort
of
like
point
in
time
operations.
G
So
that's
the
direction
we're
going
and
without
getting
running
in
kubernetes.
We
have
a
sort
of
fairly
more
complex
architecture.
So
you
have
a
lot
of
services
running
kubernetes,
and
then
you
have
really
only
data
leave
running
outside
of
kubernetes,
and
then
you
have
release
for
release
for
dedicated.
We
have
aws
managed
services
for
everything
else,
elasticsearch
rds
for
postgres,
you
know
elastic
cache,
right
and
so
really.
The
only
thing
running
on
vms
is:
is
google
today
and
we'd
like
to
be
able
to
get
everything
over
to
kubernetes
and
have
a.
G
An
operator
which
can
then
start
to
take
care
of
it
and
look
after
it,
you
know
over
its
life
cycle.
G
A
Just
touch
real,
quick
on
the
limitations
that
we've
seen.
I
know
there's
there's
a
lot
of
history
in
this,
this
issue
or
epic,
and
so
I
wanted
to
just
make
sure
that
it's
we're
still
seeing
like.
A
C
Is
is
gettingly
service
able
to
just
be
lifted
and
shifted
onto
kubernetes,
and
it
sounds
like
no
is
probably
the
answer
to
that.
But
yes,
theoretically,
like
it
would
work
with
constraints,
but
I
think
the
I
don't
think
we.
I
don't
think
we
in
the
testing.
That's
happened
so
far,
we've
seen
this
is
specifically
the
type
of
problem
that
runs
into
those
like
performance
issues
that
we
suspect
probably
are
there.
G
Yeah,
I
think
it
must
be
interesting
just
to
try
and
see
what
we
can
do
right
like.
I
know
we
want
to
have
like
a
constrained
memory
footprint
for
for
italy
and
because,
because
you
know,
kubernetes
runs
better
that
way,
but
the
the
alternative
we
have
today
is.
G
We
have
a
dedicated
whole
vm
to
to
giveaway,
and
I
realized
that
swap
is
like
not
a
thing
in
kubernetes
so
like
if
we
bump
up
into
swap
that's
a
problem,
but
hopefully
we're
not
doing
that,
but
we
could,
just
in
the
short
term,
just
sort
of
give.
G
You
know,
give
the
vm
containers
just
a
really
high,
like
resource
limit,
similar
to
what
we'd
be
doing
anyways
in
the
vms
and
just
see
what
happens
and
then
over
time
chip
away
at
it
a
little
bit
right.
F
F
I
have
yet
to
have
specifics
as
to
what
doesn't
work
under
kubernetes.
Aside
from
we
do
have
the
memory
constraints
that
come
and
my
understanding
is
those
come
from
underlying
get
and
how
git
works.
That's
something
we
need
to
work
around
and
understand
better,
but
I
don't
think
right
now
there
is
a
complete
blocker
for
running
gideon
kubernetes.
My
understanding
is,
it
does
run
there's
just
these
limitations
like
you
need
to
have
substantial
resources
allocated
to
it,
so
we
don't
run
into
the
resource
limitation
issues.
We've
seen
in
some
of
the
testing.
E
Thank
you.
Thank
you
mark,
so
I
mean.
Maybe
the
the
reason
of
the
question
is
just
like.
I
understand
the
kicker
running
kubernetes
and
probably
you
know
we
spoke
about
a
lot
of
limitations.
Maybe
that
part
of
git
or
other
part
of
the
architecture
that
we
have
here
they
ask
here
is
just
merely
do
we
plan
as
a
delivery
team
to
migrate
these
in
the
current
status
or
not.
So
it's
just
simply
understanding
what
we
can
do
in
the
future.
E
I
think
is
a
different
kind
of
different
kind
of
effort
than
what
we
would
like
to
discuss
here.
I
understand
the
project
will
be
some
adaptation
to
guitar
itself
to
be
more
cloud
native
oriented,
but
the
main
question
is
like:
are
we
planning
to
migrate
disease
or
we
transform
that
as
an
inner
different
effort.
F
F
We
know
if
we
give
it
as
expansive
resources,
it
seems
to
work,
but
we
haven't
stress,
tested
that
in
any
meaningful
way
other
than
what's
in
the
issue,
that's
been
linked
by
dylan
and
I
think
we
understand
those
limitations,
but
I'd
love
to
have
more
exposure
and
more
dog
fooding
of
that
such
that
we
can
start
writing
those
issues.
When
we
run
into
issues,
then
we
run
into
them
so
that
the
team
can
focus
on
those
as
they
get
prioritized.
E
I
understand
I
guess
this
still
has
a
different
effort
right.
It's
not
something
that
as
a
deliberate
team
we
can
take
on
to.
But
I
guess
it's
probably
more
investigation
needed
on
your
side.
So
I
correct
me
if
I'm
wrong,
but
I
wish
we
don't
see
this
happening
anytime
soon,
immigrating
kubernetes,
as
is
on
guitarists
or
into
kubernetes,.
E
D
G
Yeah,
I
I
think
personally,
I
I
it's
going
to
be
hard,
as
some
also
from
distribution
can
speak
to.
Is
it's
hard
to
really
understand
all
the
edge
cases
without
actually
using
it
sort
of
in
anger
in
some
position
you
can
try
and
like
run
gpt
and
things
like
that,
but
they're
only
going
to
push
it
so
hard.
G
You
know
so
some.
So
maybe
we
can
take
a
bit
of
a
phased
approach
here,
which
is,
you
know,
run
gpt
against
it
see
what
happens.
Grant
and
team
may
have
already
done
that
right
and
if
that
blows
up,
then
we
can
sort
of
get
the
baseline
of
you
know
I
this
this
might
not
be
really
ready
for
for
anything,
but
it
part
of
that
works.
I
think
it
does
because
we
have
customers,
as
you
know,
mark
mentioned
running
fully
in
kubernetes
today
with
italy
running
there,
so
it
at
least
provides
some
minimum.
G
You
know
baseline
of
functionality,
and
maybe
we
just
grab
some
repositories
that
we're
okay
with
going
down
once
in
a
while.
You
know
some
internal
ones
like
get
lab
dash
or
gitlab.com,
I'm
not
sure
if
you
can
shift
a
few
over,
but
maybe
we
can
get
some
that
have
some
level
of
usage
kind
of
like
how
we
got
started
with
with
with
prefect
right.
I
think
we
have
sort
of
prefect
with
dub
dub
dub.
Perhaps
so,
maybe
that's
too
big
to
get
started
with,
but
we'll
be
interested
in
transit.
G
We
can
just
get
one
or
two
over
and
then
just
seeing
what
happens.
F
C
And
I
think
that's
that's
correct
mark,
like
I
think
the
sort
of
question
here
is
like
do.
We
want
to
prioritize
delivery,
doing
the
actual
moving
of
things
and
getting
kubernetes
said
what
we
probably
would
require
time
from
getting
for
would
be
if
we
hit
upon
yeah
gitly
doesn't
work
in
these
circumstances
like
would
you
be
able
to
prioritize
some
fixes,
or
things
like
that?
I
mean
at
the
moment.
We
don't
know
what
those
are,
but
that
would
probably
be
as
much
as
we'd
be
expecting.
F
Excellent,
no,
I
am
a
complete
agreement
with
that
and
I
think
I'm
more
than
willing
to
to
allocate
time
to
support
that
you
know
and-
and
there
are
some
competing
priorities
here
with
things
like
fips
testing-
is
currently
taking
over
the
bulk
of
our
software
engineering
test.
As
of
current,
therefore,
the
work
on
testing
within
kubernetes
has
been
put
on
the
back
burner.
Currently,
I
know
the
fips
effort
should
be
coming
to
a
close
here
in
the
next
couple
of
months.
F
A
F
B
I
think
there
was
a
discussion
whether
we
wanted
to
after
migration,
whether
we
want
to
run
cluster
or
a
single
node
gig
link
there.
So
the
testing
was
that
was
done
as
a
single
node
bitly,
and
so
this
is
probably
a
question
for
the
delivery
team
or
for
the
infrastructure
team
that,
whether
we
want
to
run
the
gdp
cluster
in
gitlab.com
production
or
we
want
to
run
just
around
the
single
node-
that's
sufficient.
So
that
is
the
first
question
to
answer
here
then
decide
to
move
forward
and
to
be
very
clear.
D
F
Part
of
my
ignorance,
but
I
think
the
last
time
we
talked
about
this
and
I
probably
have
the
wrong
wording
for
this.
The
issue
became
having
a
kubernetes
cluster
which
ran
the
italy
service,
reach
out
to
standalone
vms
that
contain
the
storage
nodes
and
the
prefect
database,
and
that
was
something
that
we
had
not
explored
deeply,
because
our
initial
thought
was:
let's
get
giddily
running
in
kubernetes
the
service
giddily
running
in
kubernetes
accessing
a
single
node
storage
that
can
expand
if
necessary,
because
that's
just
your
baseline
testing
once
we
have
that
working.
F
The
next
step
was
to
understand
what
would
it
look
like
to
have
a
pre-effect
database,
internal
or
external,
to
the
kubernetes
ecosystem?
What
would
it
look
like
to
have
storage
nodes,
internal
or
external,
to
the
ecosystem
of
kubernetes?
Those
are
some
of
the
challenges
that
we
hadn't
necessarily
scoped,
yet
because
we
hadn't
really
proven
that
italy
service
itself
would
run
happily,
and
we
thought
there
was
probably
an
opportunity
for
additional
optimization
there
before
we
delved
into
this
prefect
database,
an
external
storage
node.
G
It
makes
sense
to
me-
and
I'm
not
sure
I
mean
it
might
be-
that
kiddily
is
not
the
right
service
to
start
with,
maybe
it's
prefect,
but
as
long
as
we
keep
the
database
out
of
it
like
I,
I
don't,
I
think.
From
my
perspective,
I
think
it's
just
important
for
us
to
start
getting
concrete
data
on
how
italy
runs
in
kubernetes
and
then
just
start
to
make
some
progress
right.
Either
we
find
bugs
and
we
can
fix
them
or
we
get
more
confidence
and
we
keep
going
until
we
find
until
we
find
bugs.
G
You
know
what
I
mean
and-
and
I
I
think
until
we
get
started
in
that
in
that
sort
of
feedback
cycle.
It's
gonna
be
hard
to
really
make
progress
here
unless
you
spend
a
whole
bunch
of
time
building
like
complex
test
harnesses
and
things
like
that,
but
it
in
some
ways
it
seems
like
it
might
just
give
me
a
customer
doing
it
today.
It
might
make
sense
to
just
pick
a
few
repositories
and
get
started
with
whatever
service
makes
the
most
sense
to
get
started
with.
G
But
I
agree
that
we'll
probably
need
to
have
some
time
allocated
from
gilly
to
support
and
think
through
repositories
and
which
ones
make
sense
and
what
size
of
them
would
make
sense,
and
I
want
to
see
delivery
too,
and
so
whatever
we
can
like.
If
that's
not
now
because
of
other
timelines,
then
hopefully
we
can
get
scheduled
soon,
but
we'll
probably
need
some
time.
E
But
I
guess
in
any
case,
this
is
something
that
need
to
be.
I
mean
I
take
it
that
right
now
in
the
current
state
is,
I
know
we
don't
deploy
kubernetes
and
correct
me
if
I'm
wrong.
E
Maybe
this
is
gonna
change
to
a
different
kind
of
effort,
as
I
said
before,
and
but
this
price
something
that
needs
to
be
prioritized
also
on
italy's
side
team
to
understand
to
test
better
address
the
issues
that
right
now
are
causing
concern
in
migrating.
That.
F
D
E
C
Or
maybe
reliability
could
perhaps
help.
I
guess
the
question
is
like
what
what's
what's
something
we
can
move?
That's
not
catastrophic
if
it
goes
down
for
some
time,
so
perhaps
we
could
perhaps
we
can
help
get
reliability
to
help
us
figure
that
one
out.
A
C
Yeah
yeah
cool-
let's
I
can
have
you
that
one
mckenna
like
I
think
we
could
probably
grab
dave
and
steve
and
co
and
and
come
up
with
some
options
that
we
perhaps
run
past
everyone
else.
But
we
could
probably
find
one
or
two
to
start
things
off
with.
F
Yeah,
the
internal
handbook's,
probably
a
good
choice-
I
would
have
said
www,
but
that's
running
cluster,
so
we
don't
want
to
convolute
it.
Additionally,
I
think,
by
by
trying
to
do
that
so
yeah.
I
think
something
like
the
internal
handbook's,
a
great
opportunity.
If
we
go
down
we're
only
hurting
ourselves.
The
sla
for
that
is,
I
mean
while
important,
not
super
critical
and
we
can
work
around
any
sort
of
issues
we
run
into.
D
F
I
would
love
to
get
gather
baseline
data,
like
let's,
for
instance,
say
we're
going
to
do
the
internal
handbook.
I'd
love
to
gather
baseline
data
for
a
week
in
some
meaningful
way,
define
what
those
parameters
would
be
gather
it
and
then
transition
it
and
gather
the
same
data
again
and
see
what
the
performance
differences
are.
Obviously,
if
it
goes
down,
that's
a
problem-
and
we
can
identify
that
immediately,
but
it's
the
less
obvious
things
that
I
think
are
where
we're
more
concerned.
C
Yeah,
I
think
we
can
take
a
look.
I
know
scarbeck's
done
a
lot
of
analysis
on
on
things
as
we've
migrated
them
through
in
the
past.
So
perhaps
once
we've
figured
out
which
which
repo
to
go
with
first,
we
can.
We
can
grab
scarbec
and
actually
figure
out,
like
what
sort
of
things
have
we
seen
in
the
past.
What
tools
and
things
have
we
have?
We
had
running
and
and
figure
out
what
data
we'll
be
able
to
get.
F
Well
not
to
volunteer
people,
but
I
know
patrick's
done
a
lot
of
work
on
the
performance
out
of
gita
as
well.
So
if
there's
specific
parameters
we're
interested
in,
it
would
be
great
to
collect
those
and
make
sure
that
we're
seeing
those
as
well,
because
sometimes
the
data
we
need
does
not
necessarily
coalesce
with
the
data
that
other
teams
are
primarily
focused
on.
C
What
we
should
be
able
to
do
if
it
ends
up
going
similar
to
any
of
our
previous
migrations,
we
should
be
able
to
run
them
side
by
side
for
quite
a
while,
and
that
gives
us
some
some
nice
comparisons.
So
hopefully
it's
not
so
much
a
case
of
like
was
that
some
unusual
event
that
we
can
actually
literally
compare
vm
to
a
kubernetes
cluster.
C
A
E
Anyone
else,
as
anything
to
add
to
the
discussion
or
was
I
guess
we
can
move
to
the
next.
E
I
guess
I'm
gonna
go
next,
so
come
epoxy.
Migration
is
in
progress.
Last
time
we
communicated
it
was
about
to
be
deployed
in
stage
in
a
couple
of
weeks
is
deploying
staging
right.
Now
is
working
properly,
it's
taking
traffic.
The
next
step
is
to
deploy
production
and
accept
traffic.
There
were
some
questions
about
security.
E
We
actually
look
at
the
security
assessment
that
has
been
done
three
years
ago
and
we
make
sure
that
all
the
requirements
and
be
fit
again
and
there
was
a
requirement
that
was
clearly
not
applicable
anymore,
and
then
we
work
with
network
policies
to
to
fulfill
that
one
as
well.
So
everything
is
like
is
going
pretty
smoothly
there
yeah
all
done
for
the
next
steps.
C
Great
and
one
of
the
other
pieces
we
have
coming
up
is
we're
working
on
the
hpa
stabilization
windows.
Second,
so
this
came
out
of
a
scalability
alert,
but
we
are.
We
have
well
the
mris
in
progress
to
to
get
this
into
the
chart,
so
other
people
can
also
like
make
use
of
this
as
well.