►
Description
OpenShift in Telco Panel -
Moderator: Paul Lancaster (Red Hat)
Guillaume Poulet (Optus)
Paul Fischer (Bell Canada)
Vasily Chekalkin (Optus)
B
D
A
Thank
you
so
few
questions
today,
I'm
looking
for
a
lot
of
your
experiences
on
how
you're,
using
openshift
and
kubernetes
within
your
within
your
companies.
What
I'd
like
to
start
off
with
is
maybe
you
can
talk
a
little
bit
about
how
the
line
between
the
IT
side
of
your
business
and
the
network
side
of
your
business
is
sort
of
blurring
at
this
point
and
what
they're,
how
they're
coming
together
and
how
they're
both
sort
of
leveraging
containers
and
kubernetes
and
openshift
I.
B
A
D
So
I
mean
one
of
the
biggest
convergence
that
I've
seen
is
like
the
built
Bell
Canada's,
currently
very
involved
in
the
own
app
own
app
project.
Oh
that
project,
there's
just
a
lot
of
stuff
which
you
you
could
almost
look
at
that
as
somewhat
of
a
back-end
IT
system
and
and
that's
currently
controlled
by
Network
right
now.
But
it's
it's
it's
the
same
type
of
platforms
and
stuff
they're
doing
on
that,
although
they're
not
running
on
open
ship,
but
it's
all
kubernetes
right.
D
The
same
is
what's
actually
happening
in
sort
of
IT,
so
the
one
thing
that
is
sort
of
spreading
across
the
organization
doesn't
matter
if
your
network
or,
if
you're
in
your
nightie,
is
that
that
just
the
containerization
of
everything
right
and
it
is
different,
like
not
everyone's
running,
like
a
platform
base,
but
it's
just
it.
It's
just
spread
like
wildfire
across
the
organization.
So
that's
something
where
you
know
we're
needs.
Then
we
start
looking
at
a
like
the
architecture.
It
looks
very
similar,
I
mean.
A
D
C
I
probably
can
add
to
all
these
conversions.
We
started
with
containers
on
networks,
and
then
we
moved
to
a
key
and
it's
actually
showing
your
different
sides
of
the
story.
How
network
people
think
was
how
IT
people
think
and
yes,
it's
big
big
cultural
shift,
so
we
bring
best
of
the
both
walls
and
actually
open
shift
showing
like
different
things
to
different
people,
and
we
still
can
use
common
platform
common
to
common
set
of
practices
or
developmental,
deploying
copywriting
things,
and
it's
exciting.
It's
actually
exciting,
with
merchant
networker
90.
Now,
okay,.
A
Okay,
so
just
like
to
follow
up
on
that
thing,
that
you
imagine
that's
a
little
uncommon,
but
you
why
you
mentioned
starting
with
containers
on
the
network
side,
but
so
one
of
the
things
that
we're
hearing
a
lot
about
today
in
telco,
especially
in
the
you
know,
sort
of
post
virtualized
world
is
we're.
We
know
that
a
lot
of
folks
will
delivering
virtualized
network
functions.
B
From
all
perspective,
I
think
we
we,
the
story
of
software
engineers
moving
into
network
and
and
the
culture
in
a
team
inevitably
was
clad
in
native
meaning
that
we
want.
You
want
to
be
able
to
system.
You
want
to
build
the
you
want
to
write
the
configuration
on
how
it
should
be
deployed,
how
you
going
to
configure
it,
etc,
and
so
in
network.
B
It
was
abused
very
quickly
for
us
that
containers
as
we
were
prototyping
new
systems
were
the
easy
way
for
us
to
get
started
and
when
we
got
started
and
got
a
prototype
and
started
production
izing
it
we
wouldn't
go
back,
and
so
today
we've
got
CNS
running
in
the
labs,
obviously
for
prototyping,
but
also
in
production.
We
found
this
is
a
great
way
to
operate
and
it
gives
a
different
meaning
to
docker,
particularly
to
operations
team
way
that
they
really
start
understanding.
B
I
think
the
operation
people
were
the
most
excited
about
it,
because
it
there
was
a
level
of
innovation
that
you
don't
see
as
much
space
and
also
when
we
have
more
of
a
DevOps
approach
to
what
we
do.
It
means
that
things
like
metrics,
for
instance,
the
fact
that,
as
developers,
we're
going
to
write
metrics
at
the
same
time
as
we're
going
to
write
code
that
gives
that
level
of
confidence
sure
to
the
operation,
guys
that
started
letting
us
and
give
us
more
control
of
our
infrastructure,
because
they
saw
that
we
had
the
right
practice.
B
A
D
I
would
I
would
say
that
it's
a
it's
a
little
farther
behind
and
then,
where
maybe
should
be
I
the
thing
with
the
CNS
I
like
me,
primarily
if
you
look
at
Bala
they're
like
we're.
Basically
an
operator
yeah
cool
software
right
I
mean
we
have.
We
have
some
engineering
and
if
you
do,
there
is
pockets
within
within
Bell
where
people
are
developing
the
software
themselves
and
yes,
there's
some
other
symptoms.
A
D
And
give
it
to
you
and
what
we've
been
mean,
what
I
found
when
I
was
working
with
that
is,
is
they
would
you
know
they
would
take
a
big
huge
piece
of
software
and
stick
it
in
a
container
that
was
very
large,
and
here
you
go
run
that
and
that's
not
really
what
that's
not
really
how
you
want
to
run
this
stuff
on
a
distributed
platform,
you
really
kind
of
need
to
make
it
more
cloud
native
and
split
the
control
plane.
The
data
planes
up
the
data
plane
is
also
a
large
problem.
Right
now.
D
Accelerate
in
the
data
plane
in
in
the
container
side
is
is
I
would
say
not
exactly
mature,
yet
I
mean
there's
a
lot.
If
there's
a
lot
of
solutions
out
there
that
you
can
use,
but
when
I
was
playing
with
that
stuff,
it's
it
was,
it
was
far
from
production
writing.
You
know,
you
know
from
an
Operations
perspectives.
A
A
D
Okay,
but
we're
I
mean
we're
a
large
telco
in
Canada,
we're
small,
it's
you
know
like
I
mean
pushing
these
bushes
got
the
big
vendors
to
do
this
stuff
is
I
mean
they
know,
I
think.
Inevitably
they
know.
What's
coming,
I
mean
it's
not
everything's
gonna
stay
in
a
Vietnam
I,
don't
think
I
mean
some
stuff,
maybe
but
rights
other
stuff.
That
just
makes
sense
to
to
you
know,
pull
apart
and
you
know,
control
plane
functions
actually
worked
fairly.
Well
because
they're,
don't
they
don't
have
they
don't
have
to
do
that
that
you
know
massive.
D
You
know
push
through
the
data
the
data
plane,
but
so
so
container
izing.
Those
is
actually
not
like
such
a
huge
deal.
It's
yep,
it's
the
s,
the
other
parts
of
it
that
are
that
are
challenging,
so
I
think
you
know
it.
They've
heard
us
you've
yelled
about
it.
You
know
and
and
said
this
is
sort
of
where
we
need
to
go
and
I
think.
But
it's
just
it's.
It's
basically
trying
to
develop
that
and
I.
Don't
think
it's
just
a
super
easy
problem
to
like
take.
You
know
something
that
I
you
know
distributed.
B
We
started
this
journey
by
creating
application
servers,
so
you
can
think
of
it
as
atoms
into
our
network
mm-hm,
and
it
was
a
good
opportunity
for
us
to
say.
Oh,
we
we're
going
to
visualize
this
and
to
end,
and
the
friction
was
very
much
between
the
existing
network
function
and
this
world
world,
which
is
may
look
like
a
black
box
at
first,
but
as
huge
potential
and
the
idea
of
putting
a
new
layer
of
virtualized
network
and
Ernie's
etc.
But
you
can
always
start
anyway
in
a
network.
B
We've
started
for
Rio
is
the
most
complex
functions
you
know
by
taking
the
MRF,
but
you
can
take
a
component
around
the
HSS
or
you
can
take
small
functions
of
your
network,
start,
concentrating
them
and
run
them
in
parallel
to
other
functions.
So
you
you,
don't
necessarily
need
to
go
through
a
full
transformation
to
get
started
and,
as
you
have
a
first
CNF
out
there
and
you
can
build
the
operation
but
all
around
it,
get
the
experience
and
start
growing
from
that
fictive
lee
with
vendors
or
a
equipment.
B
A
Okay,
so
just
let's
stay
on
the
idea
of
CNF
a
little
bit.
One
of
the
things
Pauline
you
mentioned
was
maturity,
and
perhaps
maybe
you
guys
could
elaborate
a
little
bit
about
what
you'd
like
to
see
from
the
community,
because
I
mean
this
is
a
community
event
where
you've
got
a
lot
of
attention
out
there
on
things
that
may
be
adjacent
to
kubernetes,
for
instance,
where
things
like
the
multi
functions
that
you
guys
need
might
be
need
to
improve.
So
this
is
your
opportunity
to
sort
of
give
us
some
feedback
around
that
yeah.
C
I
can
jump
on
the
technical
side
a
couple
of
years
ago,
when
I,
when
we
developed
in
first
MRF
and
I'm
coming
from
idea
side.
I
had
no
idea
about
networks.
No
one
told
me
that
it's
impossible
to
implement
containerized
a
tomorrow
function,
yada,
yada,
yada,
so
I
just
implemented
it
and
for
deploying
from
within
container.
We
did
some
interesting
hugs
like
developing
to
host
network,
because
we've
got
different
network
interfaces
for
signal
and
confer
media,
as
probably
most
Joker's
do
so.
C
You
should
go
this
way
and
just
don't
think
about
this
horrible
past,
but
again,
like
in
my
operational
head,
I
can't
just
change
architecture
easily
on
actual
production
network.
So
it's
always
trade-off
between
how
fast
you
can
progress
on
things
and
how
fast
you
can
adopt
to
things
past
point
of
production
deployment
and
migration
paths
will
help.
Probably
not
only
us
where
everyone
saying,
okay,
like
community-driven
and
red
hard-baked
migration
paths
and
waypoints
into
the
future,
how
actual
MRF,
not
only
matters,
how
actual
things
should
be
done.
C
A
B
A
B
A
A
B
C
B
When
you
talk
about
self
filling
all
the
configurations,
you
can
put
around
your
your
clusters
that
the
benefits
are
really
that
the
promise
of
NFV
and
the
effective
implementation
of
communities
and
network
effectively.
You
can
see
that
you
can
deliver
those
benefits
with
these
solutions.
So
this
there's
no
problems
with
taking
risk
right.
A
I
mean
I
think
we've
seen
that
you
know
virtualized
functions,
running
sr
iove
are
at
least
you
know
delivered
today
and
it's
you
know
running
in
production
for
the
next
vision
that
is
moving
into
containers.
So
what
what
you
guys
are
effectively
telling
the
community
is
that
we
need
more
work
around
things
like
Malta's,
but
we
also
need
more
of
a
path
on
how
to
get
there
is
that
is
that
correct
I
mean.
D
So
some
Malta
sand-
and
you
know
with
when
you're
doing
when
you're
doing
CNS
or
being
after
you're
gonna
need
multi
multiple
interfaces,
we're
that
Malta
syn
the
CNI
geni
are
on
the
same.
The
same
sort
of
path
is
like
using
multiple
CN
eyes
within
communities.
That's
some
cool
stuff
but
like
to
me
when
we're
we're
talking
about
bypassing
the
data
plane,
for
you
know:
si
ROV
or
euro
BSD
PDK,
all
that
kind
of
stuff
VPP.
Why
don't
we
put
work
into
speeding,
speeding
up
the
Linux
kernel
right
because
that's
usually
the
bottleneck?
A
D
They're
now
no
longer
there
and
I
have
to
use
a
whole
new
toolset,
because
the
the
IP
stack
is
gone
right.
It's
something
else
so
that
that's
to
me
is
just
a
really
abrasive
way
to
do
that.
I
mean
I,
guess
it
it's
the
only
way
right
now
we
can
do
that
way,
but
I
would
rather
see
it
that
we
we
actually
get
some
of
the
acceleration
going
through
Linux
properly.
Fortunately,.
D
A
Okay,
so
maybe
it
will
get
on
through
the
next
thing,
the
automation
of
application
deployment.
One
of
the
things
that
we
have
going
on
here
at
OpenShift
Commons
is,
of
course,
the
operator
workshop,
which
is
next
door,
which
I
encourage
everyone
to
stop
by
if
they
they
have
a
chance.
But
maybe
you
guys
can
talk
a
little
bit
about
how
the
automation
of
applications
using
operators
is
a
concept
that
you
guys
are
thinking
about,
or
perhaps
even
using
at
your
company.
Maybe.
B
I
can
take
the
first
button.
Yeah
operators
is
great
for
us
because,
as
we
work
with
third-party,
whether
it's
Kafka
or
we
deploy
it,
can
deploy
itself.
We've
got
these
simple
ways
of
deploying
these
projects
as
they
they
come
as
standard
almost
off-the-shelf,
but
then
on
and
on
the
next
end,
on
the
new
new
systems
that
we
build.
I.
Think
if
you
actually
want
to
talk
about
this
is
the
the
majority
of
our
systems
to
fit
into
the
operator
model
in
in
in
some
iterative
development
process.
Yes,.
C
Very
heavily
using
copywriters
for
production
deployments
for
testing
for
development
latest
one
was
Easter
which
no
one
wants
to
deploy
by
hand.
Just
don't
don't
even
think
about
it,
and
we
are
using
good
for
encryption
in
transit
like
as
go-to
solution
for
our
own
software.
We
started
journey
to
operate
a
world-first.
We
making
sure
that
we've
got
every
config
every
template
every
deployment,
everything
it's
properly
committed.
Templated,
we
have
reproducible,
builds
reproducible,
deployments,
reproducible,
see
ICD,
and
at
this
point
of
time
they
got
it
sorted
out.
C
Okay,
so
next
step
will
be
actually
used
operator
as
a
last
step
to
generate
all
the
stuff
instead
of
some
kind
of
the
templating
system.
It
took
us
some
time,
but
it
took
some
time
for
operators
SDK
to
mature
as
well.
So
now,
I
think
it's
one
of
like
best
point
of
time
for
us
to
start
using
cap
raters
to
deploy
our
own
software
and
our
own
solutions.
Okay,
so
soon
all.
D
D
Like
about
us
is
and
me
being
selfish,
it's
just
the
ability
right,
I
can
see.
What's
going
on,
I
can
actually
publish
or
subscribe
what
I
want
the
the
end
user
to
kind
of
see
and
that's
the
it's
a
powerful
thing
and
the
fact
that
it
can
keep
itself
updated
and
all
that
it's
just
it's
the
right
way
to
go
right.
It's
basically
like
kubernetes
for
applications
in
some
ways
with
the
control
of
constantly
running,
to
update
yourself
and
look
at
what,
where
it
stayed,
is
it's
a
it's
a
it's
great
I.
A
I
think
we
have
a
vision
for
growing
operator,
have
a
lot
this
year.
Yeah
good
I
mean
you
know
we
we've
we've
pushed
a
lot
of
our
ecosystem
to
actually,
you
know,
add
to
it
probably
seen
them
some
growth
there
this
year,
but
and
you
expect
to
ramp
that
up
quite
a
bit
right
feedback
from
you
guys
always
wanted
on
that
by
the
way.
So,
let's
see
a
few
more
questions,
you
know
I
guess,
from
from
an
operational
perspective,
what
are
the
most
important
things
when
you
guys
considered?
C
Talk
from
applicational
perspective,
I
am
I'm
all
deaf
and
I'm,
also
up
so
I'm.
Looking
at
my
software
how's
it
going
so.
Visibility
was
one
of
the
most
important
things.
I
know
how
my
software
runs
way
turns,
and
it's
a
great
able
so
I
can
scale
it
up
scale
it
down,
deploy
a
new
version
and
it
helps
a
lot.
It
helps
to
maintain
health
of
your
systems.
C
On
another
hand,
it
took
us
some,
it's
learning
curve,
how
you
change
your
software
development,
how
you
change
your
development
practices,
the
foolish
DLC
was
adjusted
for
deployment
cure
software
and
openshift
like
right.
Now
we
have
creamy
tales
as
Caminos
matrix
as
requirement
basic
requirement
for
your
software.
When
you
design
it,
you
start
with
what
matrix
I
will
have
you
start
with
health
checks,
because
it's
helps
or
its
requirement
for
self-healing
functionality.
You
need
to
know
that
your
application
has
like
live
database
connection,
so
it's
all
goods
and
things
things.
So
it's
it's
learning
curve.
B
Open
shifters
doesn't
come
out
out
of
the
box
as
this
magic
platform
that
self
heal,
etcetera.
You
actually
have
to
learn
and,
as
the
city
was
saying,
learn
and
then
and
then
tweak
it
to
what
do
you,
what
the
self-healing
means?
What?
What
is
the
strategy
when
something
goes
wrong
right?
So,
yes,
it
can
be
magic,
but
it's
not
out
of
the
box
when
we
actually
need
to
define
this
as
engineers
and
tweak
the
systems
to
work
efficiently
same.
C
B
D
I
think
it's
work
on
both
sides
like
work
from
it.
The
system
is
that
kind
of
you
know
managed
in
the
background,
but
also
work
for
the
application
developers
too,
and
especially,
if
they're,
not
they
don't
know
like
a
lot
of
them
groups
that
we're
onboarding
and
IT,
don't
necessarily
they've
never
done
containers
at
all
before
so
they.
You
know
they're
used
to
like
SS
aging
into
a
container
to
look,
and
it's
like
well,
what
are
my
logs,
where
what's
going
on
here,
so
that's
that's
kind
of
like
a
hurdle.
D
C
D
For
us
was
like
a
light-year
jump
because
they
integrated
tectonic
in
the
back
so
now
I
can
see
the
whole
from
a
cluster
wide,
what's
actually
going
on,
and
you
know
managing
capacity
and
quotas
and
all
that
kind
of
stuff
at
a
cluster
level.
It's
like
really
really
helpful.
Instead
of
sort
of
hacking
it
together
with,
like
you,
know,
scripts
and
ansible
and
stuff
like
that.
So
that's
what
we're
doing
before.
So
it's
a
it's!
A
So
one
last
question,
because
we're
coming
the
end
of
our
time
here,
but
how
you
know,
operators
aren't
necessarily
known
as
the
most
cutting
edge.
So
let's
talk
about
a
little
bit
about
how
you
guys
are
changing
that
culture.
What
what
you
guys
are
doing
to
make
it
more
innovative
inside
of
your
own
shops
did.
A
B
B
D
B
Paid
off
you
just
got
to
make
the
right
decision
on
which
community
you
you
can
going
to
choose
that
mentality
shift
I
think
is
being
set
by
not
screwing
up,
so
it
is
possible.
It
is
possible
to
to
embrace
something
that's
getting
edge.
You
have
to
understand
the
boundaries
around
it
and
know.
Most
importantly,
when
this
is
going
to
fail,
is
this
on
a
critical
path
or
not,
and.
A
B
D
B
A
D
I
would
say
that
it's
it's
actually
not
really
the
containerization
or
the
kubernetes
side
it,
but
it
the
it's.
The
C
ICD
kind
of
changed
in
the
background,
the
pipelines
that
really
drive
the
the
speed
of
deployment
of
software
so
because
that's
all
I
mean
it
kind
of
comes
part
and
parcel
like
you,
deploy
this
stuff
and
then
well.
How
do
I
actually
integrate
with
it?
How
do
I
talk
to
it?
D
Well,
you
need
to
go
through
some
sort
of
CI
chain
and
and
and
once
you
start
doing
that
once
the
developers
some
overcome
that
hurdle
and
learn
how
to
do
that,
it's
it
like
sells
itself,
because
it's
so
much
faster
and-
and
you
know
you
can
even
integrate
like
testing
in
there
and
everything
so
much
more
from
sort
of
foolproof
and
it's
all
driven
by
code.
So
it's
it's
a
lot
better
than
what
we
used
to
do,
which
is
you
know
like
waterfall
project
management,
stuff
right,
everybody
in
a
meeting
room.
D
A
D
A
D
D
Project
or
whatever
service
we're
offering
that's
changed
right,
so
we
can
offer
these
things
just
so
much
faster.
Then
to
you
know:
hey
what
we
need
this
to
be
running
on.
You
know:
kubernetes
are
open
shift
or
whatever
so
and
that's
sort
of
where
I
think
you're
getting
your
advantage
there.
But
okay.
A
B
You
in
the
culture
change
with
when
you
can
display
the
benefits.
One
thing
that
we
did
was
to
start
implement,
obviously
having
a
test
driven
approach
to
what
we
were
doing
and
deploying
end-to-end
with
actual
cell
phones
are
connected
in
Faraday
cages
and
end-to-end
testing
connected
to
a
CDC
ICD
pipeline.
B
When
people
started
saying
this,
and
so
also
you
can
change
something
and
have
an
end-to-end
test,
run
20
minutes
after
and
have
a
full
result
of
what
this
would
do
on
our
network,
that's
a
chance
of
displaying
a
benefit
and,
and
then
that
would
encourage
people
to
back
back
this
up
and
you
rarely
get
once
you
get
to
that
benefit
point.
You
rarely
get
people
skeptical
about
the
risks.
Okay,.