►
From YouTube: 2022-02-14 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,
let's
get
started
today
is
february
14th.
This
is
the
kubernetes
migration
working
group,
bi-weekly
sync
meeting.
So
let's
get
started
from
the
agenda.
The
first
item:
what's
been
done,
amy,
do
you
want
to
verbalize.
A
Cool
any
questions
about
this
is
this
really
limiting
related
to
our
early
meeting
engineer
allocation.
A
Okay,
thank
you.
Okay,
what's
happening
next,
oh.
A
C
I
was
trying
to
type
at
the
same
time,
so
you
said
amy
that
it's
ready
for
testing
who
is
doing
that
testing.
Is
that
something
that
should
be
coordinated
with
john.
B
So
he's
certainly
welcome
to
be
involved
if
he
wants
to
so
we
will
do
it
as
our
next
step.
So
I
think
it
is.
I
I
believe
we
have
the
the
kind
of
knowledge
of
how
the
rate
limiting
where
this
cluster
should
be
working
out.
It'll
be.
The
intention
is
to
run
them
sort
of
side
by
side
with
vms
and
then
run
start
running
it
on
the
kubernetes
cluster
and
the
pre-environment.
B
If
you
would
like
to
have
someone
from
quality
kind
of
give
that
a
once
over
or
check
on
the
plan,
then
absolutely
happy
to
to
loop,
someone
into
like
john
or
someone
in.
C
Yeah,
that
would
be
great,
I
think,
tag
and
john,
and
if
he
feels
like
this
is
out
of
his
seth
and
vincent
depth,
then
vince.
Maybe
we
can
find
somebody
on
your
team
who,
who
could
also
take
a
review.
B
A
Cool
more
questions:
okay,
okay,
what's
happening
next
still,
amy
you're,
yeah,.
B
Yeah,
so
just
following
on
that
to
the
next
steps,
we'll
be
planning
we'll
be
testing
out
this
plan.
Migration
paths
are
tagged
on
there.
We're
also
doing
a
piece
to
evaluate
the
redis
observability
to
see
we
we
probably
won't
have
like
for
like,
but
we'll
see
what
things
will
change
or
what
we
need
to
bring
in
to
make
sure
we
actually
maintain
observability
as
we
migrate.
A
Okay,
let's
move
on
to
the
bloggers,
we
have
two,
I
mean
first,
one.
B
Yeah,
so
just
for
this
one
I
have
follow-up
questions
is
so
I
know
we
reviewed
these
last
year
like
we.
B
These
are
not
a
blocker
for
the
migration,
but
it
would
be
great
if
we
could
actually
get
these
prioritized
so
that
we
can
actually
pay
down
some
other
tech
debt
and
also
it
repo
improves
our
deployment
reliability
to
shift
things
that
are
environment,
variables
into
actual
proper,
get
lab
settings,
and
I
think
to
answer
your
question
like
I'm,
I'm
not
sure
on
the
sev4,
so
they,
I
suppose
it's
a
question
of
like
does
a
sub
4
mean
it
will
never
get
prioritized
or
is
it
something
which
we
could
actually,
you
know
say,
get
teams
to
sort
of
be
able
to
schedule
like
in
in
a
couple
of
months
or
like
if
it
means
it
never
gets
prioritized,
then?
B
Yes,
we
should
probably
move
these
up,
but
as
I
don't
want
to
like
unnecessarily
kind
of
escalate
them,
if
if
they
will
come
in.
A
Yeah
actually
step
four,
if
you
check
our
pr
guidance
of
severities,
except
for
almost
means
that
it
will
be
the
last
thing
to
be
visited
so
living
in
the
sf4
there
is
a
higher
possibility,
is
never
going
to
be
prioritized
due
to
our
what
we
have
right
now,
the
the
engineering
team.
So
I,
if
we
really
need
this
item
to
be
implemented,
I
recommend
to
reevaluate
according
to
the
guidance
of
severity.
You
know.
A
The
the
quality
handbook
has
a
clear
guidance
then
see
what
severity
level
makes
sense
to
get.
B
This
I'll
re-prioritize
these
so
that
we
get
them
because
yeah
we
get
to
have
these.
It
would
pick
a
top
day
shifted.
A
Yeah,
and
also
there
was
a
question
from
I
think
it
was
from
michelle
to
clarify
because
last
june,
when
we
looked
at
those
these
things,
we
as
we
assessed
that
it's
not
a
blocker
at
that
time
for
the
kubernetes
migration.
B
Yeah,
that's
right,
yeah!
So
now
it's
we've
run
through
all
the
previous
steps,
so
yeah.
If
we
get
to
get
these
prioritized.
A
Yeah,
so
I
I
think
it
would
be
nice
to
say
that
is
becoming
a
either
a
blogger
or
a
much
higher
priority
for
our
scalability
and
availability,
because
yeah
yeah.
B
D
A
Thank
you
and
any
other
questions
about
this.
A
Okay
move
on
to
the
next
one
from
john.
I
will
verbalize
so
just
confirming
that
if
we
want
to
proceed
with
one
of
the
approaches
mentioned
in
that
comment
for
goodly
on
kubernetes
and
potentially
asking
for
some
help
in
implementation,
so
my
comment
my
first
comment
was:
I
read
that
comment
sounded
like
the
recommendation
is
external
dns,
so
first
we
probably
need
to
create
a
issue
and
then
identify
who
is
the
best
to
implement
that?
I
I
don't
know
the
answer.
B
Could
I
question
like
I
one
thing
I
was
a
little
unclear
on
is:
I
know
scarborough
kind
of
questioned
whether
we
should
be
using
the
the
kind
of
the
then
I
guess
the
need
to
get
the
perfect
char
ins
out
of
out
out
of
alpha
before
we
sort
of
progress.
B
What
I'm
a
little
concerned
about
here
is:
are
we
making
technical
decisions
without
a
product
decision
like
I,
I'm
not
clear
on,
like
I
know
when
you
had
a
comment
earlier
in
that
thread
about
is
exposing
the
ip
a
gitly
feature,
for
example,
like
I'm
kind
of
I,
I
think
we
have
lots
of
technical
ways.
We
could
solve
this,
but
I'm
a
little
unclear.
B
A
Actually,
that's
a
good
comment,
I
think
now
we
have
either
way
I
mean
we
identify
two
passes.
Both
both
passes
are
kind
of
blocked
right.
There
are
definitely
issues
to
resolve
to
move
either
way.
So
I
think
we
maybe
we
need
to
summarize
the
current
situation
and
then
revisit
with
a
pm
to
see
what
makes
best
sense
the
next
next
step
for
migrating
for
this
migration
right.
B
Because
I
think,
if
we're
at
the
stage
where
we
like
it
sounds
like
for
either
approach
like
having
some
engineers
working
on
sort
of
updating
the
chart
or
solving
the
external
dns
like
we
can
prioritize
that
work.
But
it
sort
of
almost
feels
at
that
point
that
we
are
entering
into
the
migration
plan
and
we
should
just
sort
of
push
forwards
from
there.
A
Okay,
so
what
we
know
right
now
is
prefact
in
kubernetes
we
have
the
charts,
not
ready
yet
and
then
eat
the
in
kubernetes.
We
have
this
this
issue
here
so
either
pass.
We
have
problems
and
we
are
blocked.
So
then
we
need
to
get
the
pm
to
make
a
call,
which
is
the
best
strategy
for
kubernetes
migration
on
gitlab.com.
Probably
that's
our
first
goal,
self-managed.
D
What
I
would
like
to
add
here
is
the
prefect
chart
effectively
needs
a
complete
rewrite.
The
time
it
was
originally
designed
it
was
a
poc
minimum
viable.
It's
basically
not
moved
forward
with
that.
While
we
waited
for
prefect
to
mature,
we
need
to
reevaluate
how
it
was
built
and
how
it
is
designed
right
now
as
clear
by
the
limitations
it
currently
has
based
on
the
current
state
of
private.
So
we
can
begin
that
work
that
will
push
out
many
things.
A
Yeah
not
asking
to
start
it
right
away,
so
I
think
that
right,
yeah,
the
right
thing
is
to
do
right
now
is
a
pm
review
and
discuss
the
pro
and
pros
and
cons
of
either
approach
then
make
a
decision.
A
D
D
This
this
is,
I
know
that
we
have
a
bunch
of
giddily.
We
don't
have
like
just
four
and
they're
all
behind
one
prefect.
We,
the
impact,
is
how
do
we
configure
prefect
on
the
outside
to
speak
to
italy
on
the
inside?
This
is
where
whether
we
use
known
ip
addresses,
roundable
ip
addresses
or
external
ens
or
whatever,
to
make
that
work.
Okay,
we
have
many
instances
of
italy
already
running
as
vms
as
isolated
in
instances,
possibly
behind
a
boxy
of
some
kind
of
balanced
traffic
or
resiliency
somewhere.
D
I
don't
know
those
instances
aren't
held
back
by
that
restriction,
so
there
may
be
more
that
we
want
to
look
at
besides,
just
prefect
in
the
chart
versus
prefect
dealing
with
buster
access
just
a.
I
feel
like
we're,
not
keeping
the
entire
scope
of
the
impact
of
testing
and
moving
italy
itself
into
the
cluster
until
we
keep
that
in
operation.
A
So
I
think
next
step,
probably
between
dylan
and
mark.
A
To
have
a
product
thing
to
see:
what's
the
best
pass
forward,
sorry
dylan
you're,
just
joining
that
we
already
discussed,
we
have
two
passes
laid
out
prefected
in
kubernetes
or
getting
the
input
in
kubernetes,
but
either
way
we
found
blockers
so
right
now
neither
will
will
likely
go
forward
without
additional
work.
So
I
think
we
need
to
summarize
the
current
situation
and
then
then
the
pm
and
probably
amy
you
you
want
to
be
in
that
talk
to
decide.
A
What's
the
best
approach
for
for
migration
on
the
uh.com
then
figure
out
what
what
are
the
required
work
next.
A
Yep,
that
sounds
good.
I
had
to
mix
up
me
with
mark
last
week,
but
we
were
gonna
connect,
so
I'll
try
this
week
and
yeah
we'll
chat
yeah.
Thank
you.
Thank.