►
From YouTube: GitLab 14.1 Kickoff - Enablement:Distribution
Description
Kickoff for the 14.1 release for the Distribution team.
Planning Issue: https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/835
A
This
is
our
scheduling
issue
for
the
14.1
release
very
streamlined
product
priorities
for
this
next
milestone
follow-up
work
from
our
our
major
release.
14.0,
we
expected
some
things
to
sift
out
that
need
to
be
accomplished
based
on
the
major
release,
so
we're
gonna
follow
up
on
any
issues
that
pertain
to
that
and
then
really
work
full
steam
ahead
on
our
ga
release
of
the
operator.
A
So
jumping
right
into
the
operator
work
that
I'm
excited
about
number
one
is
we're
going
to
evaluate
options
for
our
operator
installation
so
currently
for
the
beta
to
kind
of
get
it
working.
The
installation
experience
isn't
quite
what
we
want
it
to
be.
So
what
is
encompassed
in
this
issue
is
evaluating
the
best
path
forward
for
a
more
typical
operator
experience
for
our
users
and
also
you
know,
implementing
that
so
14.1.
Hopefully
the
installation
experience
for
ga
will
be
complete.
A
Moving
on
to
another
big
ticket
item
last
milestone,
there
was
another
ssh
support
item.
It
was
more
of
a
research
one,
so
we
have
completed
that
work
and
found
the
best
path
forward.
So
basically,
what
we're
going
to
be
doing
is
deploying
our
forked
ingress
objects
from
the
gitlab
charts
to
support
ssh
in
our
operator
and
by
extension,
for
openshift.
A
A
So
this
is
very
exciting.
We
plan
to
support
4.7,
or
at
least
you
know,
see
what
that
would
entail,
and
so
this
is
a
big
step
forward
in
that
as
well.
So
these
couple
issues
as
well
as
a
few
others,
are
going
to
encompass
a
large
amount
of
the
work.
A
That's
going
to
be
accomplished
in
14.1,
really
delivering
our
users,
the
operator
as
soon
as
we
can
and
again
by
extension,
openshift
support
moving
on
another
one.
That
kind
of
popped
up
from
a
customer
is
documenting
more
secure,
patrony
patterns.
So
there
was
a
a
security
kind
of
access
problem
with
the
petroni
api,
and
so
we're
gonna
do
a
better
job
of
documenting
this
in
our
documentation.
A
So
they
asked
you
know
this
customer
asked
how
we
can
lock
down
the
port
808
and
we're
going
to
go
ahead,
and
you
know
make
sure
that
is
more
explicit
in
our
documentation,
so
moving
on
we're
on
an
increased
lifespan
of
sales
science
certificates
for
ingress
right
now,
it's
set
to
365
days
and
we're
basically
going
to
push
this
out
as
any
intermediate
step
before
essentially
regenerating
these
self-signed
certificates
before
they
expire.
So
this
is
just
a
nice
little
thing.
A
That's
one
less
thing
for
admins
to
have
to
worry
about
is
the
self-signed
certificates.
And
finally,
the
last
item
here
that
I
do
want
to
call
out
is
our
omnibus
self-service
framework.
So
this
is
more
of
an
internal
thing,
but
I
think
it's
worth
mentioning,
because
the
more
efficiency
that
we
can
provide
internally
is
more
features
and
issues
that
we
accomplish
that
are
externally
facing
so
for
this
one
I'm
really
excited
about.
Essentially,
this
stems
from
something
that
geo
did,
which
is
internally.
A
Users
can
basically
check
if
their
features
are
going
to
be
kind
of
ready
for
the
omnibus
package.
We
do
have
another
one
for
charts:
that's
going
to
be
accomplished
a
little
bit
later
in
a
couple
later
milestones,
but
this
is
a
really
great
efficiency
piece
that
will
help
our
team
drive
more
value
to
users
later
on.
A
So
really
really
excited
about
this
one
again,
we
are
mainly
working
on
ga
of
the
operator
stuff,
but
this
is,
you
know,
encompassing
a
little
bit
other
work
that
we
kind
of
need
to
do
to
keep
the
lights
running
and
then
again
kicking
off
some
things
that
will
help
us
be
more
efficient
in
the
future.
So
thank
you
very
much.
If
you
want
to
check
out
what
we're
going
to
be
working
on,
you
can
follow
the
link
for
the
scheduling
issue
and
have
a
great
day.