►
From YouTube: GitLab 12.9 Kickoff - Configure:Orchestration
Description
GitLab PM Daniel Gruesso goes over the planned work for the 12.9 release which will ship on March 22nd, 2020.
A
Hi,
this
is
Daniel
Russo
I'm,
the
product
manager
for
the
configure,
orchestration
group
and
today
we'll
be
going
over
the
kickoff
for
the
release,
12.9,
which
will
be
shipping
in
on
March
22nd.
So,
let's
dive
right
in
one
of
the
first
items
that
we
started
working
on,
the
last
release
was
getting
Auto
DevOps
and
all
of
its
components
ready
for
kubernetes
1.16.
And
if
you
remember,
when
we
did
the
kickoff
for
the
last
release
for
12-8,
we
talked
about
how
this
is
basically
comprised
of
three
parts.
A
The
first
one
is
migrating
ingress
to
use
the
new
API
endpoints,
so
that
has
been
completed.
The
second
one
is
migrating.
The
deployment
template
to
use
the
new
endpoints
and
that
has
been
completed,
and
then
the
last
piece
that
we
have
left
is
basically
migrating
all
the
Postgres
chart
to
support
the
new
endpoints.
So
that
is
what
will
be
taken
care
of
as
part
of
12.9
here
so
moving
right
along.
A
As
you
know,
we
are
currently
working
on
delivering
templates
to
deploy
gitlab
managed
apps
using
git,
lepsy
I,
and
this
you
know,
will
provide
great
convenience
with
the
ability
to
know.
Not
only
custom
is
those
charged
prior
to
installing
them.
It
will
also
allow
users
and
you
to
take
advantage
of
all
the
good
luck
primitives
that
come
built
in
such
as
version
control,
authorization
and
all
that
good
stuff.
So
we
already
have
quite
a
bit
of
template.
A
Currently,
GE
has
this
ability
to
configure
subnets
support,
for
example,
when
you're
creating
a
cluster
you
can
have
it
be
part
of
the
default
Network
which
will
provide
you
a
default
subnet.
But
if
you
already
have
an
existing
subnet
that
you
want
your
cluster
to
be
part
of
to
do
more
efficient
networking,
you
can
also
do
that.
So,
basically,
what
we
want
to
do
is
bring
that
capability
to
the
cluster
creation
process
in
gitlab
to
allow
for
creative
flexibility
of
networking.
This
will
be
working
on
that
as
well.
A
The
next
thing
that
we're
will
continue
to
work
on
is
automatically
creating
a
cluster
management
project
if
one
is
not
specified
manually.
So
this
is
when
you
installed
gitlab
managed
apps
as
we're
getting
ready
to
switch
to
this
new
CI
process.
You'll
need
a
cluster
management
project
that
holds
all
the
configuration
values
for
your
applications.
So
in
case
you
do
not
specify
one
good
lab
will
do
it
automatically
for
you,
and
that
is
basically,
as
the
app
is
getting
ready
to
be
installed.
We'll
do
that
check
in.
A
If
the
project
is
not,
there
will
automatically
create
one
for
you
with
all
the
relevant
templates.
The
next
thing
that
we're
going
to
work
on
is
adding
littmus
chaos
to
get
let
manage
tabs.
So
what
we're
going
to
do
is
we're
going
to
work
on
the
template
that
will
allow
you
to
deploy
litmus
chaos
to
get
let
manage
tabs,
and
this
is
very
cool.
This
is
our
first
incursion
into
chaos,
engineering
and
it
will
allow
you
an
easy
way
to
run
generic
chaos.
A
Experiments
on
on
your
kubernetes
cluster,
so
some
of
those
are
like
deleting
paths,
killing
containers,
emulating,
network
corruption,
draining
nodes
things
like
that,
so
very
cool
generic
experiments
that
you
can
run
as
part
of
this,
and
what
we're
hoping
to
do
is
that
this
will
set
us
up
to
run
this
as
part
of
our
DevOps,
which
is
some
configuration.
So
we're
very
excited
about
this,
as
this
will
enable
other
Coulomb
experiments
down
the
line.
A
The
next
thing
that
we're
going
to
work
on
is
going
to
be
the
product
discovery
for
running
Auto
DevOps
on
air
gap
networks.
So
we
have
a
lot
of
users
that
run
their
get
lab
instance
on
network
that
does
not
have
external
access,
but
they
will
still
like
to
take
advantage
of
auto
dev
off.
So,
as
you
know,
auto
develops
has
a
lot
of
components
from
auto,
build
all
the
way
to
monitoring
it
uses
some
dependencies
that
are
basically
fetched
just
in
time
externally,
as
they
ever
need.
A
It
and
we'd
like
to
bring
the
ability
for
folks
that
have
air
gap
networks
to
just
take
advantage
of
the
sync
capabilities.
As
you
may
imagine,
there's
a
lot
of
moving
parts
and
we'll
be
doing
discovery
to
come
up
with
a
sound
plan
to
take
us
forward,
and
the
last
thing
that
we're
going
to
work
on
is
the
ability
to
use
cloud
native,
build
packs
with
auto
dev
ops.
So
currently
we
auto
dev
ops,
matches
your
project
using
Heroku
ish,
and
it
will
use
this
build
packs
that
are
kind
of
legacy
build
packs.
A
A
So
this
new
project
of
cloud
native,
build
packs
is
a
CNC
F
project
and
it
will
provide
us
with
a
mechanism
to
detect
this
code
and
produced
kind
of
a
cloud
native
compliant
runtime
image
that
will
be
smaller,
much
more
efficient
and
really
have
only
the
dependencies
that
are
needed
to
run
in
this
sort
of
environment.
So
we're
very
excited
about
this.
It
will
make
auto
dev
ops,
faster
and
more
efficient,
and
that
is
the
last
of
it.
This
will
be
shipping,
as
I
said,
on
March
22nd.