►
Description
The Konveyor community is working on projects to help users rehost, replatform, and refactor their applications to Kubernetes. Crane is a Konveyor project focused on application portability and migrations of container workloads across clusters. Downstream, the product is known as Migration Toolkit for Containers (MTC). It is an operator based solution that consists of Kubernetes native APIs, as well as a guided UI based experience. With several large scale production migrations under our belt, we’ve incorporated many lessons learned back into the project. We’ll be talking about how the current generation of MTC helps users migrate their workloads between clusters and the importance of application portability in the context of hybrid cloud environments. Finally, we’ll talk about the direction of our next generation of tools and the problems we’re trying to solve in the future.
Learn more about Crane: https://github.com/konveyor/crane-lib
Learn more about Konveyor: https://github.com/konveyor
Follow us:
Erik Nelson https://twitter.com/enels
Chris Short https://twitter.com/ChrisShort
What is the Level Up Hour?
Every Wednesday at 9 AM ET we stream live demos on how Red Hat Enterprise Linux (RHEL) users and admins can benefit their organizations and improve their careers by learning how to use containers, Kubernetes, and Red Hat OpenShift.
Learn more at https://red.ht/leveluphour
How to participate in the The Level Up Hour:
Watch on YouTube every Wednesday at 9 AM ET
Chat with us on Discord https://discord.gg/5VMVGJt
Check out our GitHub repo https://github.com/level-up-hour/
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
https://www.openshift.com/
https://github.com/openshift/
#RedHat #OpenShift #tluh
A
A
A
A
A
As
you
can
see,
the
usual
suspect
langdon
is
missing.
We
wish
langdon
the
best
of
luck
he
has
taken
on
his
professorship
duties
at
boston
university
starting
this
week
and
if
you
weren't
here
last
week,
yeah
langdon
has
no
longer
at
red
hat.
So
just
to
let
you
know
he
is
off
to
being
a
professor,
so
me
calling
him
illustrious
and
a
professor
on
the
show
might
have
done
him.
Some
good,
I
don't
know,
maybe
I'll
take
credit
for
it,
though
yeah.
A
C
A
A
D
Thanks
for
having
me,
I
am
eric
nelson
I'm,
a
manager
in
an
engineering
manager
in
migration
engineering,
so
I
work
on
a
project
called
crane,
which
is
the
topic
of
this
conversation
downstream.
It's
known
as
migration
toolkit
for
containers.
I've
been
an
engineer
at
red
hat
for
six,
don't
know
five
years
at
this
point
and
prior
to
that,
I'm
a
computer
engineer,
and
actually
I
I
went
to
school
at
boston
university.
So
I
know
that's
a
pretty
good
program.
D
A
A
A
Still
sorry,
I
haven't
heard
anything
otherwise,
but
I
know
that
something
is
coming,
so
we'll
keep
the
points
going
for
now,
so
we're
talking
about
crane
migrating
container
workloads
with
crane
where
so,
I've
already
got
a
question
fielded
for
you
eric,
but
let's
let's
go
ahead
and
talk
about
what
crane
is.
First
before
we
dive
into
the
question
that
I
have.
D
Yeah,
okay,
cool
so
conveyor
is,
I
think
there
have
been
some
other
projects
from
the
conveyor
org
that
have
have
been
here
so
folks
may
have
heard
about
it,
but
I'll
just
quickly
give
an
overview.
So
conveyor
is
kind
of
an
umbrella
like
collective
of
projects
that
all
sort
of
have
a
shared
objective
to
just
move,
people
to
cloud
native
environments,
specifically
kubernetes,
and
and
so
that
that
can
be
a
like
there's
a
lot
of
paths.
D
There
there's
a
lot
of
problems
that
are
involved
so
there's
a
lot
of
projects
that
seek
to
solve
a
bunch
of
different
project
problems.
So
you
can
see
here,
there's
re-hosting,
so
maybe
you've
got
like
one
cluster
in
one
place.
You
want
to
move
it
around.
Crane
concerns
itself
with
container
workloads.
D
So
it's
kind
of
forklift
and
crane
are
kind
of
sister
projects.
In
that
respect,
then
you've
got
re-platform,
so
move
to
cube,
expects
a
source-
that's
not
a
kubernetes
cluster,
so
other
platforms
such
as
like
docker,
swarm
or
cloud
foundry.
This
will
pick
stuff
up
kind
of
analyze,
it
spit
out
kubernetes
objects
and
then
that'll
help
you
get
like
sort
of
convert.
Your
workloads
to
kubernetes
tackle,
I
think,
was
the
one
that
was
actually
on
here.
If
I'm
correct,
but
this
will
help
you
actually
refactor
your
applications.
A
B
Did
the
move
to
cube
people
not
get
the
memo
right
on
the
logan
conventions,
because
I
love
crane
and
forklift
and
tackle
because
they
are
in
fact
very
descriptive
of
what
these
things
do,
move
to
cube,
also
descriptive,
but
that's
not
from
the
moving
industry.
It's
not
for
the
the
building
industry
come
on.
You.
D
Know
yeah
it's
well.
We
know
that,
like
in
software,
the
hardest
thing
is
like
actually
naming
things
so
yeah,
but
actually
move
to
cube
is
a
is
an
ibm
project,
so
it
started
with
ibm.
So
that's
actually
the
background
there
and
why
it's
it
doesn't
it
hasn't
adopted
one
of
those
types
of
names,
fair
enough
and
then
finally
there
is
polaris.
D
B
D
C
B
All
being
related
in
the
sense
of
being
able
to
manage
this
big
picture
right
in
different
ways,
whether
it's
re-platforming
rehosting
refactoring,
it's
there's,
there's
a
tool
for
everything
right.
So
here's
the
thing
I
kind
of
wonder
as
just
sort
of
first
high-level
question
is
you
know
we
have
this
need
right
now
to
have
this
sort
of
tooling?
D
Yeah
for
sure
there
is
an
expectation
that
this
is
going
to
live
on,
and
it's
not
just
migrations,
like
migrations,
are
sort
of
like
a
point
in
time
event
and
once
you're
there,
you
sort
of,
but
you
know,
we've
learned
that
that's
not
really
true
like,
like
you
pointed
out.
Polaris,
is
something
that
you're
going
to
use
to
to
for
day
two
operations,
monitoring
things
upgrades
all
that
sort
of
stuff
and
then
crane.
D
D
D
We
also
are
running
like
meetups
there's
conversations
going
on
on
mailing
lists,
so
it's
a
community
really
is
a
more
accurate
way
to
describe
that,
and
and
again
like
that's
anybody.
Who's
interested
in
this
is
is.
This
is
a
great
place
to
kind
of
connect
with
other
people
who
are
also
interested
in
the
problem
and
work
on
tools
that
will
help
you
achieve
that.
C
D
So
I'll
go
back
a
little
bit.
The
I
mentioned
that,
like
crane,
crane
is
the
upstream
name
at
the
time
it
was
really
only
mtc,
which
is
migration
toolkit
for
containers,
I'm
just
going
to
call
it
crane,
we'll
call
it
crane
v1,
because
there's
a
crane
v2,
that's
on
the
horizon
and
that's
kind
of
the
interesting
part
of
like
what
I
was
hoping
to
discuss
here.
Crane
v1
concerns
itself
with
like
mass
cluster
evacuations.
So
this
is
something
that
a
cluster
administrator
and
that's
an
important
point.
D
It
is
only
available
to
cluster
administrators
to
pick
up
everything,
that's
in
a
in
a
cluster
and
move
it
over
to
a
second
cluster.
So
this
is
a
total
like
a
whole
ho
migration.
It
does
not
concern
itself
with
the
control
plane,
so
it
operates
at
the
application,
workload
layer
and
primarily
usually
when
you
think
about
a
kubernetes
migration.
D
It's
kind
of
three
buckets
you've
got
the
kubernetes
resources
that
make
up
the
applications,
so
you're,
like
pods
deployments
stuff,
like
that.
Your
images
that
make
up
that
back
the
containers.
So
often
these
are
images
that
are
inside
living
inside
of
like
a
registry
that
you've
either
got
inside
of
the
cluster
somewhere
else,
maybe
and
then
finally,
there's
the
the
state
which
is
kind
of
the
the
hard
part
exactly
that
lives
inside
of
the
pvs,
so
crane
picks
all
that
up
and
it
moves
it
over
in
a
specific
manner.
D
D
We've
done
like
large
scale,
migrations,
and
I
would
call
those
like
we're
talking
multiple
clusters
and
many
geos
with
thousands
of
name
spaces.
Crane
operates
at
a
name
space
level.
So
that's
the
like
unit
of
it's
the
atomic
unit
that
we
use
in
order
to
migrate
things.
Often
people
will
organize
their
applications
within
name
spaces
on
a
namespace
basis.
D
A
D
Yeah
we
have
a
wrong
question
today.
It's
a
it's
a
primary
concern
for
a
lot
of
customers.
Of
course
they
don't
have
these
things
just
living
out
on
the
internet,
they're
pretty
important
and
they
live
within
disconnected
environments.
So
there
there
are
a
couple
levels
of
disconnected
that
you
can
kind
of
think
of
air.
Gapped
would
be
one
which
is
like
this:
isn't
a
percent
100
not
accessible,
which
is
possible
and
then
separately,
you've
got
a
pseudo
disconnected,
which
is
sort
of
it
has
limited
external
connectivity.
D
Maybe
it
can
see
the
outside
world
through
a
proxy
or
something
to
that
effect.
Both
of
those
are
supported
and
we've
had
a
lot
of
people
use
mtc
in
that
manner.
So
the
way
that
that
works
is
with
with
openshift
4
there
openshift4
uses
olm,
which
is
kind
of
its
packet
operator,
repository
right,
and
there
are
mechanisms
that
allow
you
to
mirror
the
images
into
the
environments
so
that
you
can
actually
deploy
mtc
in
order
to
actually
perform
the
migration.
D
We
we,
of
course,
do
have
the
requirement
that
both
of
those
clusters
can
see
one
another
or
at
a
bare
minimum.
Well,
there's
also,
this
is
getting
into
kind
of
how
mtc's
are
architected
underneath
the
covers
mtc
uses
a
project
called
valero.
Some
folks
may
have
heard
about
that.
I've
heard
of
it
yeah.
It
is
a
backup
and
recovery
solution
for
kubernetes
the
world's
kind
of
coalescing
on
it,
as
like,
the
the
backup
and
recovery
solution,
dr
solution
for
native
kubernetes,
so
we're
built
on
top
of
that
so
actually
mtc.
D
D
For
that
reason,
we
actually
require
an
intermediary
repository
where
we
back
things
up
to,
and
then
we
recover
things
out
of
so
we
we
recommend
for
a
disconnected
and
air-gapped
scenario
to
actually
deploy.
You
can
run
like
ocs,
which
is
our
container
storage
solution
on
an
open
shift,
4
cluster
and
there
you
can
set
up
your
s3
repository,
that's
self-hosted,
so
it's
all
on
your!
Let's
call
it
your
target
cluster
and
you'd
be
able
to
use
that
as
your
intermediary
repository.
C
You
spoke
about
like
the
resources,
the
kubernetes
resources,
which
are
basically
like
the
the
whole
yaml
files
you
have
to
export
in
order
to
be
able
to
push
them
somewhere
else.
You
have
the
data
and
then
you
have
the
images,
and
so
I
I
know
that
we
started
this
project
a
while
ago,
like
two
years
ago
when
we
started
addressing
the
migration
from
three
to
four
and
at
that
point
in
time,
get
ups
was
not
yet
like
a
very
hot
topic,
so
the
whole
thing
was.
C
But
so
my
question
now
is
now
that
we
are
also
playing
in
the
get
ups
film
where,
where
we
have
this
this
notion
of
now
that
I
have
my
resources
descriptors,
like
all
my
yaml
files
stored
somewhere,
I
can
push
them
across
multiple
clusters,
and
I
can
also
keep
that
consistency
like.
If
I
update
something
from
the
source
cluster,
then
I
can
automatically.
C
Maybe
you
know,
update
it
and
mirror
it
back
to
the
remaining
clusters.
So
is
it
something
that
mtc
is
is
is
working
with?
Is
it
something
that
you
know
so
how
does
it
like?
Because
the
way
I
see
it
is
you
have
the
operator
that
does
this
thing,
it
introspects
stuff
and
it
moves
resources
somewhere
else,
but
does
it
make
sense
to
to
sort
of
plug
get
up?
C
D
A
D
Because
you're
pointing
out
like
a
real
pain
right
like
this,
is
what
people
want
to
be
doing,
and
so
we've
spent
a
lot
of
time
talking
with
services,
folks
and
people
in
the
field
and
customers
trying
to
figure
out
like
what
are
the
things
that
you
want
to
be
doing
and
how
is
mtc
was
a
little
bit
early
believe
it
or
not
like
it.
Sort
of
missed,
like
there
were
still
a
lot
of
like
people,
sort
of
figuring
the
space
out
a
little
bit
when
we
did
a
lot
of
the
initial
design.
D
This
is
sort
of
its
pro,
like
some
of
its
faults
are
sort
of
also
core
to
its
design.
It's
a
tool
that
does
a
like
a
mass
cluster
migration.
So
and
it's
it's
a
tool
for
cluster
administrators,
so
they
can
pick
up
whole
cluster
pick
up
all
the
app
workloads
and
move
them
over
to
a
target
cluster.
The
what
we
found
while
interfa
like
while
seeing
this
and
actually
in
production
migrations,
is
that
oftentimes
cluster
administrators
have
no
idea
what's
actually
inside
of
their
namespaces.
D
So
imagine
there's
a
large
university
right
that
has
all
of
their
students
running
their
wordpress
blogs
inside
of
namespaces.
Some
of
them
are
crashing
like
the
whole
cluster
is
kind
of
a
disaster.
They
don't
really
know.
What's
in.
What's
inside
of
those,
they
don't
know.
If
the
like
a
crash,
loop
pod
is
a
problem,
they
don't
know
that,
like
the
interdependencies
between
name
spaces,
the
application
owners
do
and
the
developers
do
they're
the
people
who
are
deploying
into
these
environments.
So
that
was
the
first
thing.
D
Is
that
the
fact
that
mtc
is
a
cluster
admin
required
tool?
In
addition
to
the
fact
that
the
admins
kind
of
don't
know
what's
inside,
of
those
name,
spaces
means
that
there's
kind
of
a
gap
that
needs
to
be
filled
and
that's
where
crane
2
comes
in,
so
the
app
owners
are
really
the
people
who
understand
their
applications
and
their
interdependencies,
and
everything
about
that.
D
Let's,
like
shift
the
paradigm
a
little
bit
and
have
the
developer.
The
app
owners
themselves
actually
migrate
their
own
applications
so
that
distributes
the
load
of
and
the
burden
of
a
full
cluster
evacuation.
It
also
allows
you
to
do
it
in
piecemail,
which
mtc
can
do
depending
on
how
you
how
you
slice
it
up,
but
so
that's
one
of
the
the
first
objectives
of
crane
2
is
to
actually
allow
for
app
owners
themselves
to
migrate
their
applications.
The
second
thing
is
you're
right,
like
you
kind
of
nailed.
D
A
lot
of
the
points
that
crane
2
is
is
thinking
about.
There's
I
like
to
kind
of
describe
hybrid
cloud
like
crane.
2
allows
you
to
unlock
hybrid
cloud,
because
there
are
a
lot
of
these
applications
that
are
like
snowflake
applications
in
that
they're
very
tightly,
coupled
to
the
environments
that
they
live
in
they've
probably
had
like
kind
of
duct
tape
like
changes
made
to
their
resources
over
time
that
are
specific
to
the
environment.
We
know
of
a
lot
of
examples
of
that.
D
Let's
call
them
node
selectors
resource
quotas
like
stuff
that
you
pointed
out.
So
in
order
to
actually
access
hybrid
cloud.
First,
you
need
to
a
portable
application
and
what
that
means
is
you
need
to
strip
out
a
lot
of
that
like
cluster
specific
information,
and
then
you
need
to
version
it.
You
need
to
put
it
into
git
ops
model.
It
actually
could
be
like
kind
of
any
real
version.
D
The
point
is
to
version
it
in
an
in
a
cloud
in
a
cluster
agnostic
way
and
then
so
really
and
then
continuously
deliver
it
to
your
various
clusters,
and
maybe
you
want
to
actually
layer
on
some
more
cluster
specifics
as
you
do
that,
so
that's
starting
to
sound
kind
of
like
a
pipeline
right,
and
so
what
we're
interested
in
is
with
crane
2
is
is
actually
building
that
pipeline.
Where
you
have
that
discovery
aspect
where
even
app
owners
may
not
know
what's
inside
of
their
namespaces,
so
it
goes
out.
D
It
exports
all
of
the
stuff
that's
inside
of
the
namespace,
and
then
it
applies.
Some
transforms
to
those
objects
that
are
by
the
way
commonly
like
a
lot
of
people
are
going
to
have
common
interests.
Let's
say
they
want
to
strip
the
status
which
is
not
actually
relevant
for
a
target
cluster.
For
example,
and
also
it's
not
it's
not
a
live
application,
so
it
doesn't
necessarily
have
status
at
that
point
in
time.
So
you
want
to
strip
that
stuff
out.
D
Maybe
you
want
to
like
there's
another
example
with
routers
like
maybe
you
want
to
strip
out
the
host
that
it
lives
behind
because,
of
course,
that's
cluster
specific
and
then
from
there
once
you've
applied
these
transforms
and
we
have
a
plug-in
model
around
this.
That's
I
think
it's
pretty
exciting
that
allows
like
services,
folks
with
shared
problems,
to
build
their
own
plugins
that
are
reusable.
You
can
pull
them
off
the
shelf
and
apply
them,
and
then
so
you'll
get
this
kind
of
like
stripped
down
portable
representation
of
your
workload.
D
You
flip
on
your
git
ops,
and
then
you
can
use
this
pipeline
to
deploy
it
out
into
whatever
clusters
that
you're
interested
in
deploying
it
in
so
crane.
2
is
designed
for
that
and
in
a
lot
of
ways
like
it's
a
migration
tool
and
it
allows
you
to
migrate
from
an
application
to
cluster
to
cluster,
but
really,
while
you're
doing
that
migration.
D
It's
a
great
opportunity
to
modernize
it
too,
and
and
to,
and
to
unlock
that
hybrid
cloud
by
adopting
that
git
ops
model,
and
so
we
want
to
help
people
get
to
there
as
well.
There's
a
lot
of
unsolved
problems.
There
state
is
one,
that's
tricky
and
there's
a
lot
of
conversation.
That's
happening
that
we're
involved
in
in
some
of
the
upstream
kind
of
like
sig
groups,
data
protection
stuff
like
that,
where
how
do
you,
like
fluidly,
replicate
your
state
across
a
cluster?
D
How
do
you
deal
with
the
fact
that
these
applications
are
live?
So
maybe
you
need
to
quiesce
the
applications,
move
them
into
a
read-only
mode,
so
that
you're
not
corrupting
your
data,
while
you're
moving
around
stuff
like
that,
are
tricky,
tricky
problems
to
solve,
but
that's
that's
really.
What
crane
2
is
seeking
to
solve
is
and
how
it
differentiates
itself
from
mtc,
whereas
mtc
will
continue
to
live
on
as
this
like
mass
cluster
evacuation
tool
and
crane
2
seeks
to
be
kind
of
that
tool.
C
So
without
going
into
that
much
of
advanced
stuff.
Do
you
guys
think
I
haven't
seen
mtc
recently,
but
is
there
a
way
to
sort
of
gather
the
dependencies
of
a
specific
application?
So
you
said,
for
instance,
the
admin
doesn't
know
the
application.
It
doesn't
know
to
what
services
it
needs
to
talk,
etc.
So
I
believe
it
would
be
very
helpful
when
you
look
at
an
application
definition
within
the
those
tools
to
to
have
some
something
that
says.
C
Do
you
have
something
like
that
that,
like
gathers
objects
from
the
existing
cluster
to
to
to
give
an
overview
or
an
a
topology
of
the
application
and
its
dependencies,
or
even
if
we
can,
you
know
just
describe
it
by
text
or
something
like
that?
Is
it
something
that
you
have
that
you
plan
to
have?
What's?
What's
the
the
take
on
that.
D
D
D
Yeah,
our
recommendation
is
we
we
kind
of
expect
you
expect
that
leg
work
to
have
been
done.
It
is
a
problem
that
I
think
there's
there's
opportunity
to
solve
and
make
that
easier
for
sure.
I
think
that
I've
I've
heard
some
like
rumors
of
other
tools
that
may
seek
to
do
that,
but
it
seems
it
seems
like
it
would
be
an
opportunity
and
a
perfect
problem
to
kind
of
be
explored
underneath
the
conveyor
umbrella.
C
A
D
It
could
just
be
a
third
cluster,
in
fact,
like
I've,
seen
people
run
it
on
their
laptop
and
like
a
one
of
the
developer
clusters
connect
out,
but
so
you
have
to
you,
install
it
somewhere,
and
then
we've
got
this
crd
data
model
that
represents.
You
know
everything
that
we
need.
That's
our
api,
and
so
you
can
communicate
that
with.
So
we
have
a
ui
that
can
be
used
and
that's
super
helpful.
D
It's
gotten
very,
very
useful,
as
we've
moved
forwards,
it's
particularly
useful
when
things
go
wrong
and
as
we've
learned
with
migrations,
these
almost
never
go
smoothly.
So
it's
very
helpful
to
have,
and
so
you
register
your
the
clusters
that
are
involved
in
your
migration,
so
you'd
register
the
two
clusters.
You
you
give
us
like
the
coordinates
to
the
cluster
as
well
as
your
credentials,
so
we
can
access
it.
D
Maybe
you
want
to
change
your
storage
classes,
you're
converting
from
like
cluster
to
ceph,
or
something
like
that,
and
then
there's
there's
a
few
more
details,
but
at
its
core
you
kind
of
the
mig
plan
represents.
This
is
what
I
want
to
move
and
and
there's
a
discovery
process
that
helps
you
figure
out,
what's
available
to
you
to
move
next
up
in
the
way
that
we've
we've
built
mtc.
This
is
getting
into
a
lot
of
people
want
to
reduce
their
downtime
as
much
as
possible.
D
Of
course,
so
some
of
these
applications
can
be
quite
heavy.
We've
done
terabyte
volumes
before
so
what
you're
going
to
want
to
do
is
stage
as
much
of
that
data
as
possible.
This
is
assuming
a
stateful
migration.
Of
course.
Stateless
is
a
lot
easier
where
you
don't
have
to
deal
with
this,
so
you
can.
You
can
leave
your
source
application
up
and
running
you'll
stage
as
much
of
your
data
as
possible
onto
the
target
without
taking
your
application
down.
D
So
let's
say
you
get
like
99
of
your
data
onto
the
target
and
then
you
do
your
final
cut
over
migration,
which
quiesces
the
source
application
by
default.
You
can
actually
switch
that
off
and
then
we'll
grab
that
final
delta
of
data.
That's
been
written
between
the
last
time
that
you
staged
your
data
and
currently
so
we'll
get
that
last
piece
we'll
move
it
over
and
by
staging
all
of
that
data.
D
The
time
that
it
takes
for
your
final
cutover
and
your
downtime
should
only
happen
when,
during
the
time
that
we
need
to
capture
that
final
bit,
I
think
that's
it
yeah,
that's
mtc
in
a
nutshell,
so
that's
going
to
help
that's
how
you
can
migrate
from
one
data
center
to
the
to
another.
Of
course
there
are
these
like
caveats,
where
both
of
them
actually
need
to
see
each
other.
They
need
to
have
access
to
a
replication
repository,
but
that's
that's
how
that
works.
A
C
Are
there
any
plans
to
sort
of
you
know,
try
to
plug
into
tools
like
that
that
could
help
address
that
issue
of
you
know
capturing
data,
but
also
keeping
that
you
know
update
easier
or
in
a
more,
I
would
say
industrial
way
with
with
train.
Will
it
make
sense
to
have
something
like
that
plugged
in
and
help
synchronize
the
data.
D
I
actually
haven't
heard
of
that
project.
I'd
be
interested
to
look
at
it
a
little
bit.
We
we
don't,
have
we
don't,
there's
no
plans
on
the
roadmap
currently
to
integrate
with
a
tool
that
helps
you
do
that.
I
actually
don't
feel
like.
We
haven't,
had
a
ton
of
interest
in
or
problems
that
have
been
raised
around
actively
like
active
applications
that
are
writing
during
a
migration
or
something
like
that.
D
However,
we
do
have
concepts
that
will
help
you
do
that
we
have
something
called
a
hook
that
so
our
our
migration
is
broken
down
into
an
itinerary
of
steps
and
in
reality,
it's
a
state
machine
behind
the
scenes.
So
what
you
can
actually
do
is
write
arbitrary
logic
into
hooks
during
the
migration.
So,
let's
say,
like
pre
quiesce
of
the
application
you'd
be
able
to
so
we'll
delegate
out
to
the
user.
It's
hard
to
write
like
a
fully
generic
migration
tool.
That's
going
to
satisfy
everybody's
needs.
D
So
as
part
of
that,
we
want
to
develop
a
hook
mechanism
so
that
you
can
hook
into
that
process
and
do
some
custom
work.
I've
seen
people
use
it
for
things
like
dns,
like
changes
during
migration
and
specific
time
that
that
might
be
an
opportunity
to
use
it.
So
maybe
you
want
to
hook
in
and
do
some
intelligent
operations
with,
like
your.
You
can
take
advantage
of
some
data
apis
that
you
that
are
available
to
you
to
switch
things
on
so
that
you
can
replicate
it
across
clusters.
D
Stuff
like
that,
so
you
can
hook
in
and
the
way
that
it's
implemented
actually
is
out
of
the
box.
It
uses
ansible,
but
actually
it's
just
a.
We
run
an
image
and
we'll
provide
it
kind
of
a
there's,
a
there's
like
a
yeah
there's
a
there's
a
contract,
so
you
can
rely
on
like
you'll,
get
some
specific
information
about
the
migration
that's
going
on,
and
it's
just
using
an
entry
point.
So
you
it
doesn't
actually
have
to
be
ansible.
So
you
can
provide
us
a
playbook
it'll.
D
D
There
isn't
that,
like
ongoing
data,
sync
post
migration,
but
with
there's
a
lot
of
investigation,
that's
going
on,
we
have
folks
in
some
of
the
like
data,
the
seg
groups
that
are
looking
at
data
movers
and
volume
replicators
stuff
like
that,
that
are
that
are
lower
level.
Kubernetes
concepts
that
I
think
seek
to
to
achieve
similar
ideas
where
you're
sort
of
like
propagating
data
across
and
changes
across
multiple
clusters
in
pvs,
and
there
there's
also
like.
I
think
some
of
the
storage
providers
will
actually
provide
that
as
well.
A
So
speaking
of
like
storage
layers
and
things
like
that,
if
we're
using
something
like
open
data
foundations,
formerly
known
as
open,
container
storage
or
openshift
container
storage,
how
do
we
migrate?
How
does
crane
migrate
those
pvcs?
Is
it
still
using
valero
at
that
point,
or
is
there
something
that
we're
leaning
on
in
the
odf
space.
D
We
have
a
few
different
mechanisms.
There's
I'm
picturing
a
slide
that
we
have
that's
floating
around,
that's
kind
of
like
a
pyramid.
There
are
a
bunch
of
options
that
are
available
to
you
and
like
you're,
going
to
choose
one
depending
on
what
makes
the
most
sense
for,
like
the
storage
that
you're
using
so
there's
two
mech,
two
ways
that
you
can
actually
move
your
data.
D
I'm
struggling,
I
don't
want
to
call
it
move,
because
that's
one
of
the
ways
is
a
move
versus
a
copy
right,
so
I
think
something
like
70
of
of
people
are
using
actually
just
nfs
so
with
nfs.
It's
interesting
because,
like
if
you've
got
a
ton
of
data
like
a
terabyte
volume
copying
that
data
is
going
to
take
a
very
long
time.
Obviously
so
one
of
the
better
approaches
there
is
like.
Oh
I've
got
shared
storage
and
both
of
my
clusters
can
see
the
shared
storage.
D
D
That's
the
golden
source,
you're,
not
cloning,
it,
which
means
you
need
to
be
careful,
and
there
are
implications
for
rollback
and
stuff
like
that,
when
you're,
actually
picking
up
your
your
data
of
course,
backup
all
like
healthy
backup
practices
apply
here
so
and
then
separately.
There's
a
layer
below
that
where,
depending
on
your
storage
provider,
let's
say
you're
using
amazon
that
they're
I'm
blanking
on
the
name
of.
D
A
few
so
most
of
them
have
snapshot
apis.
Csi
is
one
of
the
formats
that
everybody's
talking
about
and
crane2
is
interested
in,
so
we
can
actually
create
a
snapshot
and
recover
from
a
snapshot
on
target
side
so
that
that
operates
at
a
different
level
than
the
file
system,
and
then
one
layer
down
from
that
is
actually
like
a
file
system
level
copy.
So
we
had
a
couple
ways
of
doing
that
in
the
initial
versions
of
of
mtc.
D
D
Incremental
backups
functionality,
we
had
some
limitations
with
that.
We
ran
into
some
limitations,
and
so
we
actually
optimized
that
with
some
of
our
recent
mtc
releases,
where
we
offer
a
direct
data
migration.
So
now
we
offer
direct
volume,
migration
and
direct
image
migration,
which
means
you
can
skip
that
intermediary
replication
repository
and
we'll
actually
rsync
the
data
using
like
an
s
tunnel
mechanism
directly
into
your
target
cluster.
So
in
theory
that
should
cut
your
migration
time
in
half.
For
that
and
that's
something
that
that
we
developed
in-house.
D
So
that's
our
solution,
and
actually
I
have
an
interesting
story
about
that
too.
As
of
our
our
most
recent
release,
where
there's
this
is
moving
towards
the
crane
2
world,
where
we
we
kind
of
learned
a
lot
and
and
have
codified
that
knowledge
into
a
library
called
crane
lib
and
so
we're
moving.
Some
of
that
logic
out
of
mtc
into
reusable
libraries
and
then
we're
bringing
that
where
we're
factoring
it
and
bringing
it
back
into
mtc.
So
mtc
now
depends
on
cranelib.
The
interesting
part
about
that
is
now
crane.
D
2's
cli
is
able
to
actually
use
the
same
mechanism
and
so
we're
developing
all
of
that
in
in
one
core
place,
there's
also
another
project
known
as
scribe:
that's
that's
connected
to
red
hat
and
that
we're
interested
in
contributing
to,
because
it's
also
solving
a
lot
of
similar
problems.
And,
of
course
this
is
like
kind
of
the
open
source
way.
Let's
combine
forces
and
start
to
do
our
development
upstream.
D
A
B
I
had
a
question
that
if
I
got
fireworks
go
way
back,
you
know
you
were
talking
about
crane,
2
and
some
of
the
design
goals
and
and
things
that
you
were
looking
at
doing
there
and
you
know
if
you
think
about
crane
one,
it's
pretty
much
sort
of
seen
as
a
one-shot
deal
right
and
it's
let's
get
you
through
that
migration,
I'm
simplifying,
but
with
crane
2.
It
sounded
like
you're,
also
guiding
the
application
owner
towards
some
practices
that
will
be
better
in
the
future.
D
Absolutely
that's
the
goal.
Right
is:
let's,
while
you're
doing
this
micro,
it's
it's
almost
like
a.
We
try
to
avoid
saying
this,
but
it's
almost
like
an
anti-pattern
to
just
pick
up
something
and
put
it
into
the
destination
right,
because
you're
you're
carrying
with
you
all
of
that
craft
and
and
that
legacy
just
you
know,
weight
that's
associated
with
this,
like
environment,
specific
application,
that's
just
not
truly
cloud
native
in
the
sense
that
it's
like
fluid
and
portable.
So
we
have
the
opinion
that
you
know.
B
You
know
to
make
a
metaphor
of
it,
I
think
about
moving
one's
home,
and
you
know
what,
if
you
have
a
bunch
of
cruft
in
your
attic,
that
first
move
that
you
make
you'll
go
wow.
I
don't
ever
want
to
do
that
again
and
then
you
discover
that
there's
other
things
along
the
way
that
you
think
well.
Okay,
if
only
somebody
had
told
me
that
that
you
know
getting
a
storage
unit,
you
know
that
I
could
that
I
could
take
the
stuff
and
stage
it
there
before
actually
moving
it
to
the
home.
B
That
would
not
be
ready,
or
you
know,
until
the
the
moving
day
you
know.
There's
that's
kind
of
what
I'm
hearing
about
crane
2
is
that
it
does
start
guiding
some
practices
towards.
What
will
you
know
from
from
the
from
experience?
Right
is
here's
what
has
been
a
challenge
in
the
past.
These
are
the
the
hurdles
that
we
have
encountered.
B
D
Yes,
that's
it
that's!
I
really.
I
love
that
metaphor,
because
it's
actually
really
apt,
like
when
you're,
when
you're
doing
it.
You
know
you
you
sort
of
like
acquire
all
of
this
junk
and
then
like
and
that's
your
source
application,
but
when
you
do
that
move,
it's
an
opportunity
to
kind
of
get
rid
of
all
of
that,
make
yourself
a
lot
more
fluid
and
able
to
move
again
in
the
future
without
all
of
that
burden.
D
So
that's
a
that's
a
great
that's
a
great
analogy,
and
then,
on
top
of
that,
the
the
it's
almost
like
you,
you
remove
the
necessity
for
migrations
at
all,
because
you've
moved
yourself
into
an
environment
where
you
are
portable
enough,
where
it's
like,
I
sort
of
it
reminds
me
of
when
git
started
to
become
popular.
It
was
like
for
a
long
time.
Branching
was
a
very
expensive
operation.
It
was
not
something
that
was
to
be
taken
lightly.
D
Git
just
said:
hey
why
just
branch
early
and
often
and
it
sort
of
changed
a
lot
of
those
patterns
like
and
and
we're
better
for
it,
and
so
it's
almost
like
moving
into
this
get
ops
world.
It's
just
like
I'm
redeploying
into
different
environments
and
hybrid
cloud.
That's
just
a
matter
of
course.
That's
a
normal
day-to-day
thing,
and
so
you
you
remove
the
problem
entirely
because
you're
fluid
enough
and
you're
designed
to
take
advantage
of
of
hybrid
cloud.
B
Yeah
well
so
I
think
that's.
The
difference
is
the
difference
between
being
cloud
native
versus
hybrid
cloud
native
in
a
hybrid
cloud
native
world,
the
notion
of
migration
starts
to
actually
disappear
a
little
bit
because
you've
already
built
things
in
a
way
that
you're
not
tackling
it
as
a
migration.
It
simply
just
comes.
C
Yeah
you're,
basically
just
instantiating
new
apps
somewhere.
So
so
I
do
have
a
question
regarding
that.
You
know
the
notion
of
hybrid
cloud
approach,
so
one
of
the
the
things
I
liked
with
the
with
the
convert
and
openshift
virtualization
is
the
ability
to
have
a
hybrid
application
that
is
composed
of
containers
and
of
virtual
images.
C
C
So
I
have
two
questions,
so
the
first
one
would
the
correct
way
of
doing
it
today,
like
first
migrating,
the
vm
from
outside
kubernetes
to
the
source
cluster
within
the
same
like
namespace
of
the
application,
or
something
and
then
migrate,
the
two
together
with
ntc.
So
the
question
then
is:
is
ntc
able
to
understand
a
crd
like
virtual
machine,
or
is
it
just
like
playing
crds
that
kubernetes
understands
by
default?
C
So
that's
the
first
part
of
the
question
and
the
second
one
is
like:
if
we
think
a
little
ahead
are
there
plans
to
have
like
an
umbrella
ui
that
allows
you
to
combine
both
like?
I
have
a
container
coming
from
this,
and
I
have
a
vm
coming
from
this
and
they
do
migrate
as
a
single
entity
in
a
target
namespace
or
something
like
that,
although
they
both
come
from
two
different
tools.
D
Yeah,
I
think
in
that
scenario
I
actually
have
not
had
any.
I
don't
know
of
anybody.
Who's
actually
tried
to
use
mtc
and
mtv,
which
is
the
container
and
the
fert
tools
in
conjunction
with
one
another
crane
and
forklift.
I
haven't
seen
it
done
and
I
haven't
seen
actually
really
any.
I
haven't
had
interest
come
across
my
desk
so
to
speak,
but
I
think
there's
no.
That
doesn't
mean
that
they
can't
be
used
in
conjunction
with
one
another.
D
Operated
workloads
are
actually
an
interesting
problem
that
mtc
in
some
cases
has
difficulty
with
because
there's
sort
of
an
interesting.
This
is
a
bit
of
a
side
tangent,
but
like
chicken
migrate,
the
do
you
migrate,
the
cr
that
the
operator
is
actually
operating
on
and
delegate
to
the
operator
to
reconstruct
the
the
application
on
the
target
side.
That's
actually
probably
the
correct
way
to
do
it
and
then
helm
is
another
whole
thing,
so
I
can
get
into
that.
D
We
found
this
to
be
extremely
valuable
during
some
of
our
like
more
difficult
production
migrations.
We
need
those
like
those
failure
loops
to
be
as
tight
as
possible,
so
that
you're
not
waiting
on
timeouts.
You
can't
have
this
like
monolithic
migration.
You
need
to
be
able
to
verify
like
the
steps
that
are
happening
and
when
you
need
to
go
backwards
because
something
breached
your
expectations,
you
need
to
be
able
to
go
backwards
like
like
one
little
step,
not
not
back
to
the
beginning
of
the
migration,
so
we've
taken
a
lot
of
those
learn.
D
It
like
lessons,
learned
and
incorporated
them
into
crane
tool,
crane
2..
So
as
a
result,
because
it's
this
collection
of
tools,
it's
very
flexible
for
its
use,
so
you
can
kind
of
pick
and
choose
what's
useful
for
you,
for
example,
like
crane
has
a
the
crane.
Cli
has
a
command
that
says
export.
If
all
you
care
about
is
just
discovering
and
exporting
everything
that's
inside
of
one
namespace,
it
will
do
that
for
you
and
it
will
output
that
then
it
has
a
transform
command.
D
That
will
allow
you
to
layer
on
those
changes
that
jafar
mentioned
to
strip
things
out
really
actually
do
arbitrary
things
because
it
run
it
runs
using
a
plug-in
mechanism,
and
so
you
can
use
it.
You
can
choose
not
to
use
it
and
so
you'd
be
able
to
use
crane
2
and
maybe
the
cli.
You
can
build
solutions
on
top
of
it
that
you
can
then
integrate
with
something
like
mtv,
which
is
by
the
way,
also
architected
in
exactly
the
same
way.
D
That
mtc
is
so
that
it
has
an
api
surface
that
is
represented
by
a
series
of
crs
and
crds.
So
you
can
automate
that
you
can
build
something,
that's
calling
into
crane
2
and
then
maybe
it's
creating
crs
and
and
watching
status
of
those
crs
to
wait
for
mtv
to
migrate
vms.
And
then
maybe
you
go
do
something
else.
Maybe
move
around
to
load
balance
or
something
like
that.
D
So
that's
kind
of
our
philosophy
is
that
we're
trying
to
build
these
like
core
building
blocks
and
then
we're
going
to
offer
like
an
opinionated
solution
that
uses
those
we'll
we'll
take
sort
of
a
a
position
on
how
we
think
you
should
use
those.
But
of
course
you
can
get
into
the
toolbox
and
start
building
your
own
solutions
easily,
as
well.
B
D
D
D
A
A
Beautiful,
thank
you.
Let's
get
to
some
point
sharing
here.
Real
quick.
I've
realized
we're
kind
of
already
diverging
from
our
normal
schedule
here
to
an
extent.
So
this
is
the
level
up
hour.
You've
been
watching
it
for
a
little.
While.
Let
me
know
if
you
can't
see
my
screen
so
about
us.
So
randy
is
here,
but
randy
does
not
have
a
twitter.
So
that's
fine,
so
I
made
him
a
short
code
just
for
apparently
he's
not
sharing
the
right
screen.
That's
fun!.
A
A
A
But
what
you
all
really
want
to
know
is
this
sweet,
sweet
internet
points,
who's
got
what
and
what's
got
who.
So,
if
you
want
to
participate
in
what
we
call
sweet
sweet
internet
points,
all
you
have
to
do
is
go
to
the
forum,
that's
shown
on
p
on
screen
here
and
I'm
going
to
drop
links
for
everybody
in
chat.
A
You
too
can
get
your
sweet,
sweet
internet
points
which
at
this
point,
have
no
real
value
other
than
bragging
rights,
but
we
hope
to
have
some
some
real
value
to
them
in
the
near
future.
We
keep
saying
that-
and
you
know
maybe
that'll
happen,
but
narendev
is
clearly
in
the
lead
with
and
I'll
hack
him
right
behind
him
and
then
noah
friction
followed
by
conan,
kudo
bacon,
fork
and
joe
fuzz.
A
So
if
you
want
to
see
your
name
on,
this
list
feel
free
to
check
the
archive
of
shows
and
go
back
to
get
other
codes
to
drop
in
to
the
form.
To
get
you
more
points,
and
I
think
that's
the
last
slide.
Yes,
it
is
so
any
other
questions
from
the
audience,
any
other
questions
from
jafar
or
randy,
or
anybody
at
this
point
erica
did.
You
feel,
like
you,
covered
everything.
A
So
yeah,
please
check
out
the
conveyor
community
itself,
link
drop
there
and
then
when
in
doubt
please
like
subscribe
and
share
as
always
and
coming
up
next
on
the
channel,
assuming
there's
no
more
questions
or
anything
from
the
audience
I'll.
Give
you
a
few
seconds
to
chime
in
coming
up
next
on
the
channel
today
is
ask
an
openshift
admin
with
the
one
and
only
andrew
sullivan,
but
we
also
have
a
special
guest.
A
My
friend,
john
spinks
will
be
coming
on,
we'll
be
talking
about
red
hat
insights
for
open
shift.
This
is
like
having
a
a
highly
technical
person
sitting
in
your
data
center,
saying
hey
something's
broken
over
here,
but
you
don't
know
that,
because
this
config
mismatch
is
very
unusual
kind
of
thing,
so
it'll
be
interesting
to
see
how
that
works
in
openshift.
I
know
we've
talked
about
it
on
the
channel
as
far
as
rel
goes,
but
in
openshift
clusters
that'll
be
a
very
interesting
topic
of
discussion.
B
A
A
D
The
only
other
thing
I'll
mention
too,
is
that
conveyor
as
an
organization
is
actually
on
the
kubernetes
slack
instance.
So
if
you
want
to
actually
reach
like
all
the
engineers
are
there
that
are
working
on
this,
you
can
talk
to
us
every
day,
we're
in
there.
So
that's
the
kubernetes
slack
and
then
it's
like
just
pound
conveyor
you'll
find
us
yeah.
A
Let
me
find
the
slack.kubernetes.io
link
real,
quick
to
drop
in
chat
and
you
can
find
them
on
the
conveyor
channel.
That
is
conveyor
with
a
k
and
they'll
be
healthy,
happy
to
help
you
out.
I
am
also
in
that
slack
so
feel
free
to
ping
me
with
anything.
As
always,
you
can
reach
me
on
twitter,
at
chris
short
or,
if
you
have
any
questions
or
suggestions
for
future
shows
feel
free
to
email
me
short
at
redhat.com
and
yeah
thanks
everybody.