►
From YouTube: 2022-05-09 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).
A
Okay,
so
of
course
this
is
a
kubernetes
migration
working
group
meeting,
so
amy
things
you
have
most
of
the
items
and
topics
of
how
about
you
drive
this
meeting
today.
B
I
can
do
that.
Yes,.
C
So
welcome
everyone.
This
is
the
9th
of
may
kubernetes
working
group
meeting.
So
first
of
all,
I
wanted
to
mention
like
welcome
to
mckelly.
So
mckelly
has
joined
us
in
delivery
and
I've
shared
the
issue
there,
where
we
sort
of
discussed
how
it
split
delivery
into
two
teams,
we'll
be
working
alongside
each
other
for
the
next
sort
of
rest
of
this
quarter
and
then
sort
of
looking
to
split
in
q3,
but
all
of
the
sort
of
kubernetes
side
of
things
will
be
sitting
in
mckelly's
team.
A
Welcome
michelle
michelle
did
I
pronounce
your
name
correctly,
mi
kelly,
kelly,
okay,
thank
you
very
much
for
correcting
me.
What
is
yeah
a
question
for
both
of
you.
So
are
you
is
kelly
going
to
pick
up
the
this
working
group
from
amy
moving
forward,
or
I
mean
you're
still
hanging
around.
C
Yeah,
so
I
think
eventually
yeah,
if
we're
still,
if
we
still
like
need
to
have
this
working
group,
then
yeah,
I
think
we'll
hand
over,
but
I'll
certainly
be
around
for
the
next
few
cool.
Thank
you
awesome
great
and
then
on
the
what's
happening.
Next,
this
one's
a
little
bit
of
what's
in
progress
as
well
as
what's
happening
next,
but
we
are
working
at
the
moment
on
migrating
camo
proxy,
we're
we're
sort
of
in
the
early
stages,
but
we're
hopefully
redeploying
into
staging
in
the
next
couple
of
weeks.
C
What
I
wanted
to
just
really
check
in
is
we're
not
currently
we
are
using
helm
but
we're
not
currently
adding
into
the
get
lab
chart,
and
I'm
just
checking
that
is
that
long-term,
the
right
decision,
or
is
this
something
like
it's
sort
of
outside,
of
the
gitlab
application?
So
does
it
make
sense
that
it
stays
outside
the
chart.
D
C
It's
a
very
profound
question:
jason,
who
who
can
help
us
answer
that?
Because
I
know
one
thing
that's
interesting,
I
think
about
camo
is
it
has
been.
It
has
been
listed
as
a
requirement
of
staging
ref
at
the
moment.
C
We're
we're
not
going
ahead
and
adding
it
in,
because
it
will
be
easier
to
add
it
once
we've
done
the
migration
to
kubernetes
and
we
have
it
in
a
chart,
which
is
where
that
I
suppose
the
question
starts
to
come
in
is:
if
we,
if
we
know
we
want
camo
on
staging
ref,
do
other
users
want
to
have
camo
on
on
their
things
as
well.
D
B
C
A
Introducing
another
dependency,
I
think
there
was
a
handbook
I
will
find
out
of
the
link.
I
think
there
is
a
handbook
to
say
when
we
introduce
a
new
dependency,
what
we
need
to
do,
and
I
think
that
there
is
a
security
page
as
well
to
specify
when
you
introduce
new
dependencies
or
what
security
reviews
needs
to
go
is
to
be
finished
so
I'll
find
out
the
link
to
the
handbook
pages.
A
C
Great
and
then
so
on,
three
so
we've
been
looking
at
doing
some
work,
we're
trying
to
improve
some
scaling
to
in
response
to
some
scaling
alerts
that
we're
seeing-
and
we
have
this
new
chart.
Mr
up,
but
it's
a
little
bit
of
a
question
I
suppose
about
our
breaking
breaking
changes
policy.
So
with
this
change
we
would
potentially
cause
problems
for
any
users
who
have
configured
custom
metrics,
which
is
that
something
we
need
to
worry
about
like
or
how
do
we
handle
something?
D
So
since
I'm
the
one
who
went
hey,
is
this
related
to
that
earlier
today,
the
short
answer
I
haven't
had
a
full
chance
to
fully
evaluate
the
cross
points
of
where
our
recorded
supported
version
versus
our
target.
Supported
version
is.
B
D
The
good
news
is,
we
have
mechanisms
in
place
to
prevent
people
from
putting
something
into
a
broken
state
right.
So
it's
it's
more.
We
have
to
evaluate
how
do
we
roll
it
out
to
users
to
not
make
it
as
an
impactful,
broken
change
or
breaking
due
to
the
nature
of
one?
Two
four
burning
is
one
two,
four
being
out
one,
two,
five
incoming
one,
two,
five
deprecates
a
lot
of
things,
not
just
the
hpa
version
that
we're
currently
deploying.
D
So
we
actually
have
a
number
of
issues
scheduled
for
the
coming
milestones.
Steven
dylan
you've
seen
the
pile
of
we
need
to
fix
this
before
x
date.
For
one
two
five,
I
can
give
you
a
more
definitive
answer
to
be
honest
after
I've
had
time
to
review
it.
But
monday
mornings
are
a
little
compact.
C
It's
absolutely
fine
yeah.
It's
no
great
rush.
Like
honestly
for
this
one.
I
was
thinking
it.
It's
it's
an
interesting
general
conversation
as
as
well
as
a
specific
for
this,
mr,
but
a
general
like
for
changes
like
this.
When
we
possibly
impact
users
like
is,
do
we
do
we
have
a
process?
We
can
already
follow.
D
We
do
have
processes
that
we
can
follow.
We
basically
have
to
deem
which
one
do
we
need
to
do
if
we're
forcibly
changing
the
object
version
and
thus
breaking
compatibility,
we
have
to
go
the
deprecation
route.
Where
we
go
look.
This
is
the
way
you
had
it
just
so
you
know
this
has
to
be
changed,
don't
change
it
please
if
you
need
to
make
a
breaking
change,
but
we're
really
changing
the
format
on
a
custom
value.
The
best
we
can
do
is
actually
have
a
warning
in
our
check.
Config.
D
D
If
we,
this
is
one
of
those
things
like
it
depends
on
what
changed
in
the
object
type
of
accuracy,
because
sometimes
the
object
version
changes,
but
the
structure
doesn't,
but
it's
interpreted
differently
kind
of
like
how
ingress
has
got
slightly
different.
It
had
new
values,
hpas
they're
fun
and
how
they're
changing
they're
changing
for
the
good,
but
we
have
to
get
everybody
to
go
with
it
carefully.
B
C
B
D
If
we
can
figure
out
the
way
to
do
it
and
get
it
in
within
this
time
frame,
then
now
would
be
a
good
time
to
do
it
right
as
a
reminder
for
everybody
in
this
call,
the
charts
are
not
version
locked
through
the
gitlab
project.
So
if
we
need
to
make
a
breaking
change
on
behalf
of
production
in
the
future,
we
have
that
ability.
B
C
C
So
I
know
we've
been
testing
on
getaly
and
we've
got
some
kind
of
some
possible
ways
forwards,
but
I
also
heard
that
there's
a
possibility
that
italy
team
would
like
italy
service
those
are
italy
cluster
to
be
running
on
dot
com
and
replacing
getting
service
and
profit
which,
if
that's
the
direction
we
want
to
take,
I
suppose
puts
another
question
mark
on
what
do
we
want
to
be
in
the
charts?
Are
we
sort
of
moving
towards
getting
cluster,
or
are
we
actually
looking
to
get
cuddly
service
into
the
chart
via
migrating.com?
C
C
A
I
suggest
reach
out
to
mark
and
also
andreas,
and
this
is
ian
of
italy
so
which
are
both
of
them
to
see
or
what
the
direction
is
heading
to
that
team
is
heading
to
yeah.
I
don't
have.
I
don't
have
good
insights
there
to
be
honest.
C
Okay,
that
makes
sense-
and
I
suppose
then
maybe
dylan
perhaps
for
you
like-
is-
is
there
a
sort
of
a
distribution
opinion
on
on
what
we
want
to
offer
with
gitly?
Or
would
it
simply
be
the
goodly
team
sort
of
is
setting
up
a
roadmap
that
we
would
we
would
follow
along
with.
B
I
can't
say
that
we
really
have
an
opinion.
I
think
it's
sort
of
up
to
them.
Besides
what
jason's
recommending
yeah
are
they
are
they
invited
to
these
calls
the.
A
They
were,
they
were
invited,
but
mark
probably
not
available
today.
B
C
Okay,
that
sounds
good
well.
What
I
do
is
I'll
do
it
on
this
epic
I
linked,
which
was
say
the
sort
of
original,
as
it
pulls
together
the
reference
architecture
as
well
as
everything.
So
I
think
that
would
be
a
good
place
to
actually
make
a
decision
on
there
great
and.
C
Are
there
any
so
we
talked
a
little
bit
about
camo
already,
but
I'm
wondering,
like
other
other
non-application,
specific
components
that
actually
we
do
care
about
for
the
gitlab
chart
as
well.
So
I'm
thinking
like
do
we
have
an
opinion
on
things
like
ho
proxy
redis
or
any
of
those.
D
So
redis
at
this
point,
essentially
we
have
the
the
bitnami
chart
that
actually
has
the
ability
to
run
h.a
redis,
it's
simply
come
down
to
for
the
most
part.
Most
of
our
clients
are
either
consuming
a
platform
for
it
or
running
out
their
own.
It's
not
that
they
can't
use
the
same
chart.
We
even
have
professional
services
that
implement
the
bitnami
redis
chart
in
a
clustered
stance.
I
say
cluster
not
for
redis
cluster,
but
redis
h,
a
sorry
we
can.
We
can
technically
do
that.
D
D
To
do
that,
it
gets
complex
when
you
get
to
the
point
of
having
to
start
redis
right.
So
when
we
start
dealing
with
the
locally
we've
called
it
the
multi-redis
scenario,
when
that
comes
into
play,
you
essentially,
you
must
run
multiple
copies
of
redises
and
the
chart
certainly
has
no
means
to
do
that.
Right
now
and
honestly,
probably
best
not
to
put
it
in
there
because
someone's
going
to
do
it
when
they
don't
need
to
and
it
gets
hyper
complex
when
it
comes
to
postgresql.
D
The
the
short
answer
on
that
one
is
pgha
in
kate's
is
its
own
beast.
Just
like
pgha
is,
and
we
have
done
our
best
to
shy
away
from
doing
something
we
know
is
complex
and
quite
possibly
dangerous
and
actually
makes
it
harder
to
do
the
upgrades,
as
our
team
knows,
and
anybody's
tried
to
do,
upgrades
in
case
of
postgres
that's
deployed
there.
The
way
in
which
you
have
to
do
it
is
to
shut
it
down,
update
it
reload
the
data
from
scratch,
because
it
doesn't
have
an
in-place
upgrade
for
same
reasons.
D
D
In
terms
of
anything
else
that
we
have
larger,
component-wise,
h.a
proxy.
D
D
I
don't
know
that
it
makes
sense
to
have
essentially
two
methods
of
proxy
again
like
it
makes
total
sense
when
you
have
a
distributed
system
but
like
in
this
particular
case.
I'm
scratching
my
head
on
the
usefulness,
though
we're
not
against
necessarily
replacing
nginx
with
h.a
proxy,
but
obviously
investigation
has
to
be
had
there
and
hilariously
yeah.
We
actually
have
something
in
51
to
investigate,
possibly
replacing
nginx
with
something
else.
D
C
C
Okay,
because
I'm
really
the
reason
I'm
sort
of
asking
about
all
of
these
things
is
sort
of
you
know
like
whether
whether
we
actually
are
still
like
how
much
of
a
kubernetes
migration
do.
We
still
have.
How
much
are
we
still
needing
a
working
group
and
a
sort
of
a
sort
of
putting
high
priority
labels
on
mrs
for
things
versus
it
just
being
now
more
business
as
usual,
as
we
continue
to
adapt
and
grow
our
sort
of
our
clusters.
D
It
still
makes
sense
because
long
term,
we
beyond
what
we're
doing
for
gitlab.com,
we're
also
looking
to
consider
pushing
people
towards
that
in
the
future,
and
we
need
to
make
sure
that
we
have
the
same
kind
of
high
quality.
Graded
experience
from
our
own
learnings
that
we
have
within
the
traditional
architectures.
B
C
In
which
case,
thanks
very
much
for
the
discussion,
everyone
and
yeah
have
a
good
rest
of
your
monday.
Take
care,
bye.