►
From YouTube: 12.4 Configure stage kick-off
Description
Daniel Gruesso (Configure PM) goes over the issues the team will focus on for the 12.4 GitLab release.
A
Hello,
my
name
is
Daniel.
I
am
a
product
manager
for
the
configure
stage
here
at
good
lab.
Actually,
I
am
one
of
the
product
managers,
as
we
recently
have
hired
a
new
product
manager
that
will
dedicate
himself
to
the
serverless
group.
So
his
name
is
Victor
naggy,
we'll,
probably
see
more
of
him
in
the
upcoming
kick
offs.
So
we
are
here
to
kick
off
the
release,
12.4
and
that
will
be
shipping
in
the
month
of
October,
specifically
on
the
22nd
and
we're
very
excited
to
bring
you
some
very
cool
features
for
the
stage.
A
Let's
get
started
so
the
first
one
that
the
configure
team
will
focus
on
will
be
the
ability
to
upgrade
Prometheus
via
get
lab
manage
two
apps.
So,
as
you
know,
the
good
lab
runner
currently
offers
you
the
ability
to
upgrade
as
a
chart
version
is
released.
So
this
will
basically
be
the
same
pattern
where
we
will
try
to
automatically
upgrade
for
you
and
then,
if
it
runs
into
a
failure.
We'll
present
you
with
an
upgrade
button
and
you're
going
to
be
able
to
upgrade
the
chart
from
the
good
lab
managed
apps
screen.
A
Let's
move
on
the
next
issue
that
we're
going
to
be
working
on
is
one
that
we
actually
started
as
part
of
12.3,
and
that
is
the
ability
to
create
a
kubernetes
cluster
and
AWS
is
eks
service.
So
basically
we
have
a
workflow
that
may
be
a
little
different
here
where
you
initially
have
to
provision
an
iam
account
over
in
your
AWS
account
and
then
good
lab
will
basically
create
a
service
account
as
you
go
through
the
workflow
other
than
that
the
workflow
is
going
to
be
very
similar.
A
You
will
be
presented
with
a
provider
screen
now,
as
you
can
see,
and
you
will
select
Amazon
eks
and
then
you
will
specify
the
information
that
it's
going
to
be
specific
to
the
cluster,
such
as
VP
C,
and
things
like
this.
So
we're
going
to
work
to
get
this
one
or
at
the
finish
line
at
the
beginning
of
12.4,
so
it
should
be
available
on
github
comm
earlier
then,
for
our
self-managed
customers
who
will
be
available
and
the
day
of
the
release.
A
Let's
move
on
ok,
so
this
next
feature
is
a
very
exciting
one
and
there's
the
ability
to
extend
our
see.
I
only
accept
logic
to
look
for
files
in
directories.
So
currently,
if
you
use
only
or
accept
it,
maybe
for
operations
such
as
running
a
job
on
on
a
particular
branch,
let's
say
that
it's
not
master
and
then
basically
adding
for
exceptions
with
the
accept
keyword.
A
So
what
we
want
to
do
is
bring
this
functionality
that
will
allow
us
to
look
for
matching
files
and
directories,
and
the
reason
that
we're
doing
this
is
that
we
want
to
extend
Auto
devops
to
run
only
when
he
has
a
matching
build
pack
for
your
project,
or
it
has
a
doctor
files.
For
example,
you
are
able
to
look
in
the
files
in
the
directory
and
say
only
run
this.
A
If
you
have
a
docker
file
in
your
repo,
then
auto
devops
will
only
run
in
cases
where
it
can
truly
add
value
and
it
will
not
run
otherwise.
So
we
are
extending
it
lab
CI
in
order
to
make
that
happen
very
excited
about
that.
Let's
move
on
this
next
one
is
the
ability
to
upgrade
the
ingress
application
via
get
lab,
manage
tabs
so
similar
to
what
I
spoke
about
earlier
in
Prometheus.
A
It
is
the
ability
to
upgrade
to
the
newer
chart
version
and
that
you
know
will
give
you
all
the
features
that
come
with
an
inversion,
so
the
upgrade
will
basically
function
in
the
same
pattern
where
we
will
try
to
automatically
update
it
for
you
and
then
present
an
upgrade
button.
That's
not
possible!
A
Okay!
This
next
one
is
allowing
the
selection
of
EPC
native
when
creating
a
kubernetes
cluster
in
GK.
So,
as
you
know,
if
you
today
create
a
GK
cluster
using
the
GCP
dashboard,
this
VPC
native
feature
is
enabled
by
default
and
just
to
talk
about
what
a
VPC
native
cluster
is.
Is
it
uses
alias,
IP
routing
that
is
built
into
the
V
PC
network?
A
So
we
recognize
that
when
you
are
getting
started
with
get
lab,
you
may
already
have
your
kubernetes
implementation
running.
You
may
already
have
some
configuration
running
and
that
a
lot
of
time
means
that
you
already
have
a
namespace
created
and
that
people
are
already
the
point
that
namespace
and
well
when
you
integrate
gitlab
with
kubernetes.
Today,
it's
kind
of
either
all
or
nothing.
So
we
are
creating
the
namespaces
for
the
projects
as
you
deploy,
and
that
is
not
something.
That's
malleable
right.
It's
not
something
that
you
can
change.
A
So
what
we
want
to
do
is
provide
you
with
the
ability
to
tell
us
what
namespace
corresponds
to
the
environment.
That
is
being
created
as
part
get
live,
CI
and
then,
basically,
we
don't
have
to
create
a
namespace
for
that
particular
deployment,
we'll
reuse,
the
one
that
you
are
already
using
and
that
will
allow
you
to
continue
with
your
workflow
as
it
is
currently
so
we're
very
excited
to
bring
you
this
feature
and
basically
allow
for
further
customization
of
the
workflow
this
next.
A
One
that
we're
going
to
work
on
is
upgrading
to
the
cube,
CTL
version
that
we're
currently
using.
So
we
want
to
upgrade
to
112,
and
that
is
currently
matching
what's
being
used
in
--gk
right
now,
and
it's
what
we're,
what
it's
being
used
in
eks
right
now,
it's
113
so
kind
of
the
compromise
we
want
there
is.
We
want
to
be
like
plus
or
minus
one
of
the
current
version,
so
we'll
be
upgrading
that.
A
Okay
and
this
next
one
is
a
very
exciting
one,
and
that
is
the
ability
to
customize
the
configuration
of
gitlab
managed
apps.
So,
as
you
know,
when
you
install
a
kubernetes
cluster
it
let
provides
you
with
the
ability
to
install
a
number
of
apps,
for
example
the
runner,
a
home
ingress,
and
when
we
install
those
apps,
we
are
using
a
chart,
a
helmet
art,
and
that
is
installing,
with
some
default
values.
A
Who
will
allow
you
to
version
control
it
and
then
at
the
time
of
installation
or
upgrade
for
that
particular
chart,
we'll
go
ahead
and
look
if
there's
a
values,
damo
file
and
it
will
use
it
and
if
there's
not
we'll,
just
use
the
default
values.
So
this
is
really
great,
as
you
know,
there's
a
lot
of
cases
where
you
may
want
to
have
further
customizations
of
your
chart
to
do
a
number
of
things.
A
So
we
really
hope
that
this
will
improve
that
and
it
can
give
you
the
ability
to
use
the
charts
your
way
Oh,
so
that
is
it
for
the
kubernetes
and
auto
devops
group,
and
then
we
move
on
to
the
serverless
group.
So,
let's
talk
about,
we
have
some
exciting
features
there
as
well.
The
first
of
them
is
the
ability
for
us
to
provide
you
with
a
domain
automatically
when
you
install
candidates.
A
However,
today,
when
you
installed
key
need,
if
you
have
to
provide
us
with
a
domain
and
then
you
have
kind
of
to
map
that
domain
with
the
ingress,
that
is
still
provides
you
after
the
fact.
So
what
we
want
to
do
is
we
want
to
make
that
easier
for
workflows
that
may
not
immediately
go
into
production.
So,
for
example,
if
you're
doing
development
testing
you
know
staging
you
may
need,
you
may
not
need
to
use
a
specific
domain.
A
So
we
want
to
provide
you
with
a
domain
automatically
for
your
project
as
you
install
key
native,
so
you
really
can
start
using
the
functions
without
much
configuration,
so
we're
very
excited
about
that.
The
next
one
is
related
to
this
as
well.
As
you
know.
Currently,
when
you
deploy
a
canady
that
connait
of
service
is
served
over
HTTP,
you
have
the
ability
to
enable
TLS
or
your
kinetic
services,
but
right
now
that's
kind
of
a
manual
process.
So
we
want
to
make
that
happen
automatically.
A
So
whenever
you
deploy
a
native
service,
your
service
function
is
going
to
automatically
be
served
over
HTTPS.
So
we're
very
excited
about
this
one
as
well
and
finally,
on
the
server
list
group.
We
want
to
give
you
the
ability
to
have
more
insights
into
the
invocations
of
your
service
functions
and
logging.
So,
for
example,
if
you
have
a
server
lowest
function
out
there
today,
there
are
some
implications
that
fail.
A
If
you
want
to
look
at
logs
or
any
kind
of
activity,
that's
happening
inside
your
punitive
service,
you
have
to
you
know,
go
into
your
cluster.
You
may
want
to
use
kind
of
the
default
logging.
That's
there.
If
you
have
something
like
stack
driver
enabled
you
can
use
that,
if
not
you
have
to
man
install
something
that
will
do
that
for
you
and
there's
kind
of
not
an
easy
way
right.
A
This
is
kind
of
an
advanced
use
case,
so
we
want
to
make
that
easier,
and
what
we
want
to
do
is
we
want
to
automatically
provision
the
elastic
sure,
elasticsearch
and
Kabana
framework
in
your
cluster
when
you
install
Kay
native.
So
when
you
install
Kay
native,
this
will
automatically
be
provision
in
your
cluster
and
we
will
present
you
with
a
link
that
will
take
you
initially
to
your
Cabana
dashboard
and
then
further
iterations.