►
From YouTube: OpenShift 4 Migration Tools
Description
In Red Hat OpenShift 4, migrating from 4.1 to 4.2 can be done in-place, via over the air upgrade.
Customers wanting to go from OpenShift 3.x to OpenShift 4.2 can take advantage of automation to make the process easier. A new set of migration tools is now available to easily move projects, application services, cluster configuration and associated artifacts onto the latest OpenShift release.
Join Marco Berube, Red Hat Migration toolkit Solution Owner, for a demonstration of this new tooling and for answers to frequently asked questions about migrating to OpenShift 4.
For more information, please visit: openshift.com/migration
A
So
there's
two
different
things
that
we've
built
to
help
you
actually
get
started
on
OpenShift
4,
so
the
first
one
is
the
control
plane,
migration
assistant
tool
or
cpma
cpma
helps
you
configure
your
openshift
for
cluster
to
match
when,
when
possible,
all
the
settings
that
you
had
on
your
OpenShift
3
cluster,
then
once
you
have
your
pension
for
install
and
configure
properly,
then
you
can
use
the
cluster
application,
migration
tool
or
cam
tool
to
migrate.
Your
applications
from
your
OpenShift
3
cluster
to
your
new
openshift
4
cluster.
A
Here's
what
the
cluster
application
migration
tool
looks
like
the
first
thing
I
would
do
in
the
tool
is
to
configure
both
clusters,
so
I
would
configure
my
openshift
3
cluster
and
then
I
would
have
a
credential
for
my
open
shift.
4
cluster
once
both
both
clusters
have
been
configured
and
I'm,
ready
to
add
a
repository
which
is
any
object,
storage
that
I
want
to
use
to
copy
the
data
during
the
migration
process.
Then
finally,
I
will
create
my
first
migration
plan.
A
So
migration
plan
is
a
grouping
of
all
the
namespaces,
our
projects
that
you
would
like
to
migrate
during
one
migration.
You
can
create
as
many
plans
as
you
want,
but
when
you're
executing
a
plan,
all
the
namespace
or
projects
inside
that
plan
are
gonna
get
migrated.
At
the
same
time,
here's
a
let's
have
a
look
on
all
this
work
underneath
the
hood.
So
this
tool
is
based
on
two
open
source
project.
The
first
one
is
Valero
and
the
second
one
is
rustic.
A
A
A
So
if
the
target
cluster
can
see
the
same
storage
as
your
source,
modular,
like
typically
like
it,
for
example,
like
NFS
storage,
then
in
that
kind
of
situation,
it's
actually
possible
to
move
the
PV
or
to
reattach
the
PV
to
your
target
cluster
without
any
impact
on
or
without
any
need
of
copying.
The
data
I
should
say
so.
This
is
this
is
obviously
the
fastest
option,
as
we
don't
have
to
copy
any
data
or
just
reattaching
that
pv
from
your
source
cluster
to
your
destination,
cluster.
A
The
second
alternative,
when
move
is
not
possible,
is
to
do
a
copy
of
the
data,
so
copy
is
based
on
the
wrist
stick,
a
technology
that
I
was
describing
at
the
beginning,
so
what
ristic
does
is
doing
either
full
or
incremental
copies
of
your
data.
So
first
data
is
gonna,
get
back,
backed
up
on
your
repository
and
then
during
the
final
migration.
Then
we
can
just
do
an
incremental
backups,
all
the
files
that
I've
changed
since
the
last
staging
of
your
data
and
then
that
data
will
get
restored
on
your
target
cluster.
A
So
this
is
the
two
options
that
the
the
tool
is
gonna.
Allow
you
to
bring
the
migration
process
of
the
first
one
is
stage
so
typically
the
first
time
that
you
will
execute
a
migration
plan.
You
would
typically
do
a
stage
if
you're
doing
a
copy
instead
of
a
move.
What
stage
allow
you
to
do
is
to
do
a
full
copy
of
the
data,
then,
when
you
are
clicking
migrate,
actually,
what
ristic
will
do
in
the
background
for
the
copies
to
only
do
an
incremental
copy
of
the
data?
A
A
How
to
execute
the
migration,
so
the
first
thing
as
I
was
pointing
before
we
recommend
using
the
CPM
a
tool
to
look
at
your
open
shift.
3
configuration,
which
is
gonna
help
you
configure
your
open
shift,
4
clusters
so
by
configuring,
your
open
shift,
3
cluster
and
your
open
shift,
4
cluster.
The
same
way.
This
simplifies
the
migration
of
your
projects
or
namespaces
from
one
test
or
to
another.
A
A
So
if
you
want,
if
you're
looking
at
moving
the
PBS,
you
should
attach
your
NFS
storage
to
both
clusters,
as
well
as
you'll
need
a
way
to
also
failover
the
date,
the
the
networking
aspect
of
it
or
the
access
of
your
application,
so
which
you
would
typically
do
either
using
your
corporate
DNS
or
a
load
balancer
to
move
the
network
from
going
to
your
openshift
3
cluster.
For
that
specific
application.
To
now
eating
your
openshift
4
cluster,
every
time
a
request
will
come
in.
A
So
here's
another
thing
to
consider,
as
you
are
migrating
from
your
open
shift
with
your
open
shift,
4
cluster,
you
should
be-
or
you
might
see,
a
need
to
increase
your
open
ship
for
capacity
and
decrease
your
open
shift
for
capacity
as
you're
progressing
with
this
migration.
So
a
typical
way
to
achieve
that
would
be
to
target
some
applications
on
your
open
shift.
Three
cluster
that
you're
looking
a
migrating
to
a
patch
of
4
and
then
migrate.
A
So
another
thing
to
consider
is
to
think
about
potentially
leveraging
a
fully
H
a
cluster
configuration
using
a
load
balancer
to
help
you
with
this
migration
project.
So
by
having
multiple
clusters
getting
load
balance
from
a
global
open
answer,
then
this
allows
you
to
first
remove
one
of
your
cluster
from
your
application,
little
balancing
configuration
and
then
upgrading
that
application
from
the
open
ship
3
to
the
open
ship
4
cluster.
A
Once
this
has
been
completed,
then
you
can
reconfigure
a
little
an
answer
to
point
your
traffic
against
you
open
ship
for
cluster
and
repeat
the
same
approach
for
all
your
applications
until
you
have
fully
migrated
out
of
your
open
shift
with
your
open
check
for
cluster.
This
gives
you
the
best
case
scenario,
which
should
reduce
the
amount
of
downtime.
Obviously
you
can
also
use
dns
to
do
the
same
thing,
but
by
using
a
two
cluster
approach.
This
means
that
the
traffic
still
can
hit
your
application.
A
While
you
are
migrating
from
an
open
shift,
3
to
an
open
check
for
cluster
here's
a
couple
of
roadmap
item
as
well,
that
we
are
working
on
right
now
for
the
next
releases
of
this
tool.
So
the
first
one
is
the
ability
to
do
migration
as
a
non
admin
user.
The
second
one
is
to
have
more
granularity
under
your
project
or
namespaces,
to
be
able
to
pick
specific
resources
inside
run
project
instead
of
having
to
migrate
everything
at
once
and
then.
A
Finally,
we're
also
looking
at
potentially
adding
pre
and
post
migration
and
support
playbooks
to
allow
more
complex
use
cases
to
be
executable
directly
from
this
tool.
Today,
you
could
actually
do
that
by
using
a
playbook
that
would
call
the
EPI
of
the
tool,
but
by
having
this
available
inside
the
tool
that
just
makes
it
even
easier
to
leverage
ansible
as
a
way
to
automate
the
full
process
end
to
end
when
you
are
migrating
your
applications.