►
From YouTube: 2021-11-11 AMA about GitLab releases
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
Welcome
everyone
so
welcome
to
the
november
delivery
team
ama.
So
if
anyone
has
any
questions,
they
would
like
to
ask
us
about
anything
to
do
with
gitlab.com
releases
github.com
deployment
releases
to
our
self-managed
users,
kubernetes
migration
or
anything
else
related
to
those
sorts
of
things.
Then
please
go
ahead.
B
Let's
I'll
start,
what's
what's
left
with
the
kubernetes
migration,
you
know,
I
think
you
know
pages
is
in
progress.
Is
that
the
main
thing
that's
outstanding
right
now.
C
I
could
attempt
to
take
it
from
a
technical
perspective.
We
have
a
lot
of
stuff
left
that
is
not
kubernetes.
That
would
include
git
lab
pages,
which
is
currently
a
work
in
progress.
Our
gitility
nodes,
which
I
don't
know
if
we're
actually
going
to
migrate
them
to
kubernetes
prefect,
which
I
think
at
this
moment
in
time,
is
still
up
in
the
air
as
to
whether
or
not
we're
going
to
migrate
that
new
kubernetes.
C
I
think
it's
one
of
those
that
it
sounds
good
on
paper,
but
it
needs
to
be
tested
and
validated
that's
going
to
work
appropriately
for
us
and
at
the
scale
that
we
operate.
We
also
have
other.
Actually,
I
think,
out
of
all
the
omnibus
installed
stuff.
That's
in
the
database
servers,
so
postgres
is
one
that
we
probably
will
not
migrate.
Redis
is
a
project
that
the
scalability
team
is
picking
up,
so
we'll
be
kind
of
involved
with
scalability
to
handle
the
migration
of
those
instances
over
into
that
infrastructure.
C
And
then
we
also
have
stuff
that
we
don't
manage
as
part
of
the
gitlab
product
that
will
eventually
migrate
to
kubernetes
so
stuff,
like
our
monitoring
stack,
which
is
mostly
already
there,
but
we
also
have
stuff
like
camo
proxy
and
plant
uml.
Plant
uml
is
already
in
there,
but
camera
proxy,
for
example,
is
not
so.
C
At
this
point
I
made
a
comment
about
this
at
kubecon
that,
like
we're,
roughly
90
complete
with
all
of
our
front-end
services,
that
we
install
with
the
gitlab
product
in
our
health
chart.
A
And
just
to
kind
of
add
on
that,
so
yeah
for
q4
delivery
will
be
joining
up
with
scalability
to
do
redis
or
to
begin
rudder.
Should
I
say,
as
part
of
that,
we
have
to
figure
out
the
migration
approach
for
redis
and
then
we
will
likely
do
one
or
two
of
the
instances
this
quarter
and
make
a
plan
for
for
following
up
through
q1
and
q2.
So
it
should
be,
should
be
signed
soon.
But
it's
likely
to
be
a
reasonably
big
project.
B
Yeah
I'm
curious
about
the
redis
motivation,
because
I
can
see
the
same
arguments
for
not
for
not
putting
in
kubernetes
the
way
because
of
postgres
as
well,
and
so
I
guess
my
question
is:
would
there
be
a
point
that
you
say
probably
just
leave
this
in
omnibus,
because
it's
for
the
same
reasons
it's
a
database,
you
don't
want
it
to
be
auto,
scaling
and
restarting
when
you
don't
expect
it
right.
A
Yeah,
it's
a
really
great
question,
so
eagle's
done
some
great
investigation
to
get
things
started.
I
think
at
the
moment
it's
definitely
a
it
could
go
either
way.
The
main
reason
we
are
pushing
ahead
with
it
is:
it
will
really
improve
operability.
So
it's
a
big
bonus.
We
we
already
have,
I
think,
six
instances
of
redis
we're
likely
to
have
more
having
these
running
in
kubernetes
will
make
setting
up
new
instances
way
easier.
So
we're
going
to
start
with
the
the
sidekick.
A
B
A
I
would
love
us
to
have
a
great
feature.
One
of
the
the
interesting
things
we're
we're
figuring
out
at
the
moment
is
the
handling
of
kubernetes
cluster
config
changes
versus
the
handling
of
deploying
things
onto
a
kubernetes
cluster.
We
use
the
same
like
same
process
and
kind
of
move
between
the
two
and
it's
not
super
clear,
like
they
collide
a
bit,
it's
a
little
bit
messy.
D
Yeah
on
this
one,
if
you
remind
amy,
we
were
also
toying
with
the
idea
of
a
merged
train
for
deployments.
So
we
were
exactly
talking
about
these
things
where
basically,
we
will,
especially
for
kubernetes
configuration.
We
would
like
to
have
something
like
this
is
a
merged
train
that
will
deploy
to
kubernetes
our
configuration
changes
so
that
our
so
that
master
will
always
have
things
that
got
divided
to
production,
so
the
so
that
we
don't
have
to
go
back
to
the
previous
state.
D
If
some
of
our
cluster
wasn't
able
to
say,
apply
the
configuration
changes
and
there
isn't
there's
some
complexity
around
this
like
if,
because
with
merge
train,
if
something
fails
in
the
merge
ring,
everything
else
fails
after
that,
and
so
we
were
kind
of
thinking.
Can
we
have
some
kind
of
luck
around
the
environment
so
that
we
apply
all
the
changes
one
by
one
and
then
make
sure
that
only
things
that
made
to
production
are
actually
ending
up
in
master.
A
Fancy
sounds
nice
curious
for
the
rest
of
the
delivery
team,
like
what's
your
like
dream,
get
that
future.
E
A
Yeah
super
great
question,
so
the
main
challenges,
I
think
we
face
are
the
complexity.
So
one
of
our
is
our
kind
of
one
of
our
motivations
behind
setting
this
in
our
strategy
is
to
kind
of
encourage
us
to
keep
things
simple.
Keep
things
well
documented
and
make
it
as
easy
as
possible
for
other
people
to
join
in.
I
think
the
feedback
we
generally
get
when
people
read
through
our
release
tools
documents
is
that
it's
pretty
tricky.
They
are
complex.
There
is
a
lot
that
goes
into
managing
releases.
A
Unfortunately,
that
makes
it
a
little
bit
trickier.
So
that's
kind
of
the
motivation.
I
think
that's
the
main
challenge
that
the
more
we
can
simplify
our
release
and
deploy
tooling
and
one
of
the
big
ways
we're
doing
that
is
like
to
try
and
actually
get
further
into
the
product,
make
more
use
of
actual
gitlab
features,
and
that
allows
us
to
remove
a
lot
of
the
custom
tooling.
A
Been
around
for
a
while,
we
have
been
focusing
sort
of
through
this
year
on.
I
think
the
strategy
has
probably
been
there
for
pretty
much
all
of
this
year,
so
it's
always
been
our
kind
of
longer-term
goal
to
dog
food
gitlab
features
and
bring
our
tooling
back
inside
the
product
so
that
everybody
can
can
benefit
from
it.
E
And
is
there
a
specific
section
on
all
of
these
all
of
the
tooling,
and
you
know
the
documentation
that
you're
working
on?
I
see
that
the
handbook
mostly
has
like
strategy
how
we
work
etc.
But
are
there
other
pages
that
you
recommend
yeah
external
people,
reading.
A
Yes,
absolutely
so
we
have
another
page
which
goes
through
our
release
process.
A
B
A
Let's
drop
it
in
there
for
you,
so
that's
the
other
one
and
again
it's
a
lot
of
information.
We
we
needed
a
little
bit
of
a
reorgan
there,
so
you'll
start
to
sympathize
with
people's
complaints
about
the
complexity,
but
yeah
that's
a
great
place
to
to
start
with,
and,
of
course,
contributions
always
welcomes.
If
people
have
suggestions
for
how
we
can
actually
make
this
stuff
easier
to
find
them,
please
feel
free
to
open
emails.
F
To
you,
yes,
this
is
the
first
time
I've
joined
this
call,
and
I
do
not
know
if
this
is
the
right
place
to
ask
this
question.
So
forgive
me
I'm
wondering
if
there's
anything
specific
in
14.5
that
is
particularly
exciting
for
the
community
in
terms
of,
if
it's
something
that
we
really
want
to
promote
from
a
public
relations
perspective.
A
That's
a
really
great
question
and
welcome
I'm
going
to
guys,
because
we
have
no
idea
one
of
the
things
about
delivery.
Is
we
very
much
have
black
boxes
of
bad
packages?
Actually,
we
have
no
idea
really
like
beyond
the
sort
of
regular
release,
kickoff
things.
So
I
know
next
week
that
the
product
managers
are
preparing
begin
preparing.
They
do
prepare
the
release
blog
post
and
that's
really
the
the
key
thing
I
think
to
keep
an
eye
on.
A
So
let
me
I'll
ping
you
in
a
relevant
place
in
slack
christy,
so
you
can
actually
keep
a
track
of
that
one.
Thank
you.
E
A
Yeah,
that's
right
so
product
handle
all
of
the
release
notes.
The
kind
of
the
thinking
behind
that
is
the
product
managers
are
the
best
people
to
know
like,
what's
going
to
make
it
into
the
release
and
also
how
best
to
explain
it
and
sell
it
to
people.
So,
yes,
there's
a
completely
separate
process
that
runs
sort
of
alongside
the
delivery
teams,
preparing
of
the
release,
which
prepares
the
release
post
and
then
we
kind
of
join
up
together
on
the
22nd
to
coordinate
the
publishing
of
the
two
packages.