►
Description
The OpenContrail community has developed an integration with OpenShift, now also commercially available through the combination of Juniper Networks Contrail Networking with Red Hat OpenShift Container Platform.
In this briefing, James Kelly, Guilhem Tesseyre, and Savithru Lokanath from Juniper will present and demo how the integration is deployed, works, and adds value. OpenContrail for OpenShift automates the full lifecycle of its networking virtual domains, tenants, subnets, and security policies, all in sync with the lifecycle and workflow of OpenShift users and application builds, deployments and services. Beyond providing SDN multi-tenancy and micro-segmentation, OpenContrail is ideal for collapsing OpenStack and OpenShift SDNs, and adding advanced networking to OpenShift atop any infrastructure.
B
C
Thanks
very
much
Diane
and
thanks
to
everyone
in
the
friendly
commons
community,
for
tuning
in
and
certainly
for
having
us
folks
at
juniper
and
from
the
open,
contrail
community,
come
and
talk
a
little
bit
about
how
open
shift
and
open
contrail
work
together.
So,
as
you
mentioned,
I'll
introduce
us
briefly,
but
we
will
be
passing
the
torch
from
myself
to
TDM
and
then
to
stab
you
through
as
we
go
so
I'll.
Let
them
say
a
little
bit
more
about
them,
but,
as
you
can
see,.
B
C
B
C
Actually,
since
kubernetes
sort
of
generated
a
lot
of
interest
and
caught
my
attention,
then
I
quickly
saw
how
Red
Hat
and
the
open
shift
community
embraced
that
there's
something
really
exciting
to
see
and-
and
you
know,
I've
actually
certainly
done-
podcasts
of
open
contrail.
You
know
hacks
with
open
shift
even
dating
back
to
beyond
a
year
ago.
So
that's
a
little
bit
about
me.
C
I'm,
going
to
be
kicking
off
the
talk
sort
of
just
giving
you
guys
a
brief
introduction
of
what
to
expect
a
little
bit
of
background
about
open
contrail,
and
then
you
know
we'll
cover
the
agenda
a
little
bit
more
on
the
next
slide.
Vm
is
going
to
kind
of
take
over
from
me
and
talk
about
the
integration
between
open
shift
and
open
contrail
and
then
so.
This
room
is
going
to
take
it
from
there
with
a
live
demo,
so
without
further
ado,
let's
kind
of
jump
in
here
and
kind
of
talk
about
the
agenda.
C
So
what
to
expect
today,
you
know
again,
like
I,
said:
I'll
be
going
through
a
quick
introduction
of
contrail,
as
we
can
locally
call
it
for
short
as
a
project.
It's
open
contrail,
but
we
usually
just
say
contrail,
so
I'll
kind
of
use
the
two
interchangeably
and
explain
the
difference
between
junipers
contrail
offering
and
the
open,
contrail
community
and
project
ems
pretty
much
got
the
second
part
of
this.
C
So
first
things
first,
you
know
we'll
talk
a
little
bit
about
open
contrail
and
give
you
some
background
on
it.
So
you
might
have
heard
about
open
contrail
as
a
project
it's
been
around,
since
it
was
seated
by
Juniper.
Networks
in
2013
got
a
patchy,
pretty
permissive
license.
The
actual
software
was
originally
written
by
a
bunch
of
people
sort
of
in
the
networking
industry,
as
well
as
other
folks
from
Google
and
so
forth.
B
C
As
well,
and
certainly
those
of
you
that
are
familiar
with
Red
Hat,
of
course
they
have
an
open
stack
offering,
and
you
know
open
stacks,
pretty
old
now
and
I
guess,
you
know
fairly.
Quite
a
lot
of
people
are
familiar
with
Neutron
and
the
networking
side
of
OpenStack
and
open
contrail
was
really
the
first,
probably
big
popular
open
source
solution
for
OpenStack
that
was
not
just
open
source,
but
also
commercially
available
and
quite
mature
and
kind
of
ready
to
go
in
production.
C
We've
seen
large
customers,
you
know
as
big
as
AT&T
many
gaming
companies,
many
large
enterprises
and
banks
adopted
and
Oakland
contrail
is
kind
of
known
in
the
OpenStack
community
for
sort
of
being.
You
know
the
number
one
open
source,
but
also
commercially
available
software
defined
Network
solution.
According
to
you
know,
quite
a
few
user
surveys
running
now
in
that
OpenStack
community,
but
building
on
that
heritage.
Of
course,
you
know
we.
C
Networking,
if
you
were
looking
at
it
up
on
juniper,
dotnet,
juniper
and
Red
Hat,
have
worked
together
for
quite
a
long
time
as
mutual
technology.
Alliances
as
well.
The
really
made
sense
for
us
to
add
support
for
open
shift,
and
some
of
the
guys
will
talk
about
all
the
specific
versions
and
how
that's
happened.
You
know
you've
seen
different
support
for
open
shift
in
the
community
of
open
contro
for
over
a
year
now
in
sort
of
alpha
beta
experimental
modes
and
we've
recently,
you
know
sort.
C
More
formal
support
for
and
are
going
through
than
the
certification
of
Juniper
control,
networking
with
OCPD
open
shift
container
platform
from
Red
Hat
they're
really
excited
about
that.
So
a
quick
word
about
about
what
open
console
is.
You
know,
I've
said
it's
basically
an
SDN,
it's
an
SDN,
that's
kind
of
opinionated
in
the
sense
that
it
is
his
only
software
based.
It
allows
you
to
create
very
flexible
networking
and
security
constructs
with
pretty
sensible
defaults,
but
there
is
a
lot
of
advanced
Sdn
and
customizable
options
in
it
as
well.
C
Obviously,
having
worked
with,
say,
customers
over
a
long
time
and
years
of
development.
Now
from
hundreds
of
engineers
and
really
you
know
in
the
space
of
open
shift,
I
guess
you
could
kind
of
generalize
it
to
to
a
few
things.
I
mean
you
know
this
is
you
know
really
general
but
saying
that
it
adds
multi-tenancy
support
at
the
network
level
as
well
as
microsegmentation
support
at
the
network
level?
And
you
know
these
are
probably
terms
that
you've
heard
of
both
in
the
openshift
community
and
certainly
in
the
kubernetes
community.
C
I
know
micro
segmentation
or
the
ability
to
do
sort
of
custom
or
isolation
is
a
sort
of
top
of
mind
right
now,
because
I
know,
kubernetes
1.7
was
just
released
and
network
policy
objects
were
actually
incubating
for
quite
a
while,
but
now
generally
available,
and
that's
something
a
different
country
lad,
amongst
other
things,
so
going
along
to
my
next
slide,
we
kind
of
position
open
contrail
is
sort
of
you
know
like
the
Lord
of
the
Rings
one
ring
to
rule
them
all
the
one
Sdn
to
rule
them
all.
We
know
that
with
OpenShift.
C
So,
if
you're
running
openshift
a
top
of
OpenStack
or
if
you're
running
open
ships
on
top
of
Amazon,
Web
Services
or
the
Google
Cloud
or
real
anywhere
as
long
as
there's
IP
connectivity
between
all
of
the
different
hosts
open
contrail
can
work
so
a
little
bit
more
of
an
overview
in
terms.
You
know:
we've
talked
about
this
top
level
of
the
different
environments.
That
contrail
supports
many
of
these
on
the
left-hand
side
of
the
top
or
more
Enterprise
related.
A
C
Systems
from
companies
like
AM,
Docs
and
there's,
you
know,
integrations
there,
but
a
wide
variety
of
services,
like
I,
said
that
have
matured
over
many
years
of
development,
fundamentally
layer,
2
and
layer,
3
virtual
networking
constructs
where
you
can
really
bring
your
own
IP
addresses.
You
know,
as
the
next
thing
says,
right.
The
the
DDI
F
as
we
sort
of
call
it
for
short
or
DNS
DHCP,
IPAM,
IP,
address
management
and
floating
IP
addresses
quality
of
service
custom
security
policy
load,
balancing,
which
is
obviously
something
kind
of
top
of
mind
for
micro
service
architectures.
B
B
C
Of
contrail
we'll
talk
about
the
architecture
on
the
next
slide
at
a
very
high
level,
but
one
of
the
biases
that
you
have
in
contrail
in
terms
of
it
being
able
to
work
with
other
systems.
It
obviously
needs
to
work
with
other
networking
systems,
a
Juniper.
Those
would
all
be
based
on
Juno's.
You
know
they'd
be
based
on
various
operating
systems
that
other
vendors
like
cisco
or
restriction,
louis
and
others
that
we've
tested
interoperability
and
federating.
D
C
So
this
might
make
sense
a
little
bit
more
seeing
how
control
is
implemented
from
a
logical
architecture,
diagram
of
building
blocks
and
sort
of
a
logical
view
of
what
it
allows
you
to
do.
Create
these
flexible
Network
constructs
on
the
the
right
hand,
side
right:
you
create
a
blue
virtual
network,
red
green
virtual
network
or
whatever
you
want
to
call
them.
They
have
various
workloads
in
they
can
have
you
know
overlapping
IP,
address
spaces
or
their
own
customizable
address
spaces,
and
normally
networks
are,
if
you
call
them.
C
Virtual
networks
are
probably
isolated,
but
policy
allows
them
to
be
connected
together.
We
can
even
connect
them
together
with
interesting
services
in
between
them.
That
may
be
physical
or
virtual,
such
as
firewalls
as
a
common
example,
and
then
the
left-hand
side
of
the
diagram
is
sort
of
saying
you
know
we
have
centralized
policy
definition
and
distributed
enforcement
of
that
policy,
and
if
you
wanted
to
parse
contrail
at
the
highest
level,
you
could
probably
say
that
it's
really
two
components
right.
C
It's
a
logically
centralized
controller
that
box
in
the
middle
and
then
distributed
agent,
that
we
call
the
V,
router
or
virtual
router
right
and
that
pretty
much
runs
on
all
of
the
compute
nodes,
whatever
they
may
be
and
whatever
workloads
they're
running.
And
then
we
build
some
overlay
which
can
exist
overtop
of
any
network,
whether
it's
a
network
like
the
AWS
network
or
a
physical
IP
or
Ethernet
network,
whatever
it
happens
to
be,
and
of
course,
all
of
the
vir
outer
sort
of
connect
up.
C
You
see
it's
using
XMPP
here
and
the
slide
to
the
controller,
the
controller
Confederate.
With
other
controllers.
The
controller
can
also
federal-aid
with
actual
network
devices,
whether
they
be
physical
or
virtual
layer,
2
or
layer.
3
network
devices,
a
common
example
is,
of
course,
to
talk
out
over
the
internet
or
outside
of
the
overlay
through
a
gateway
or
through
a
wide
area
network
and
at
the
very
top
end
you
see
it's
got
a
restful
api
that
plugs
it
into
many
different
kinds
of
workers
systems,
openshift
included.
C
D
You
James
for
a
deduction
and
laying
out
the
architecture
and
the
different
use
cases
of
Cantrell,
so
my
name
is
int.
Sir
I'm
a
solution,
engineer
I've
been
with
Juniper
for
about
two
years
now,
working
in
the
contribution,
it's
mainly
with
either
telcos
or
large,
comprises
on
how
control
spending,
how
control
works
and
trying
to
solve
very
different
issues
through
Sdn
and
working
across
different
types
of
virtualization,
and
lately
mainly
around
containers,
run
times,
especially
with
kubernetes
and
open
shifts.
So
let's
jump
right
in
and
look
at
how
we
integrate
with
them.
D
We've
opened
shapes,
so
just
you
know
to
put
control
on
the
map.
I
think
that's
pretty
obvious,
but
you
know
when
you
look
at
this
tag
that
I
guess
most
of
you
guys
are
familiar
with.
We
basically
sit
at
the
networking
layer
and
we
will
replace
the
native
open
ship
at
the
end.
Solution
that
comes
with
the
traditional
I
would
say:
open
shift
stack
so.
B
D
Being
said,
let's
look
at
how
we
plug
all
that
together.
So
I
guess
you
guys
are
familiar
with.
You
know
very
nice
architecture.
You
have
your
master
in
two
different
nodes:
the
different
components
of
a
kubernetes
master,
vfk
server,
the
replication
controller,
schedulers,
etc.
What
we
do
basically,
is
that
we
have
implemented
a
store
plugin.
We
call
the
contrary
queue
manager
that
basically
listens
on
the
distance
to
the
API
server
and
based
on
the
events
it
sees.
There
will
then
create
the
appropriate
objects,
on
the
contrary,
so
a
little
bit
in
the
same
fashion.
D
But
you
know
the
cubelets
watch
is
the
API
and
then
we'll
update
its
configuration.
If
it
sees
that
the
resource
is
being
created,
then
we
pretty
much
do
the
same
thing
on
earth
on
our
hand,
watching
the
API
server,
creating
the
appropriate
objects
in
control
and
then
the
configuration
of
the
v-rod
accordingly.
D
So
that's
what
happens
from
a
control
brain
perspective,
so
we
integrate
in
the
in
the
background
it's
totally
transparent.
Actually,
so,
basically,
from
user
perspective,
the
workflow
stays
the
same.
So
you
still
create
your
pod
services,
your
deployments
in
the
same
fashion,
and
it's
just
that
contra
will
pick
up
these
events
and
then
implement
the
network
configuration
in
the
back
in
the
background
from
a
data
plane
perspective.
So
you
know
James
laid
out
the
architecture
with
a
control
plane
and
the
distributed
data
plane.
D
So
from
a
data
plane
perspective,
we
have
our
component
that
we
call
it
the
router
that
basically
installs
on
the
different
compute
nodes
and
we'll
replace
the
cube
proxy
part.
So
we
see
we
were
basically
substituted
to
it
because
we
implement
our
own
rules
and
policies
there
and
we
integrate
with
the
cube
let
privacy
and
I
plugin.
D
So
then,
when
the
cubelet
will
need
to
instantiate
pods
on
its
on
a
certain
node,
it
will
call
out,
through
V
and
I,
plug
into
the
router
to
provide
the
networking
configuration
and
the
V
router
would
have
had
received.
Its
configuration
from
the
controllers,
who
you
know
would
have
been
triggered
by
the
creation
of
an
object
in
the
system,
basically
prove
a
contract.
Q
manager.
Ok,
so
that's
basically
how
we
integrate
same
behavior
as
far
as
control
is
concerned.
D
Just
one
more
component
is
to
manager
that
listens
to
the
API
and
trigger
the
configuration
on
the
control
side.
So
just
to
give
you
a
view
of
them,
the
mapping
of
the
main
primitives
intranet
is
what
they
map
into
control
objects,
because
some
people
are
familiar
with
contrary
in
an
openstack
environment.
So
basically
the
namespace
would
map
into
control
onto
a
project.
So
we
every
time
you
have
a
namespace
and
we'll
all
see
that
in
the
the
next
slides.
But
you
want
to
isolate
it.
D
For
example,
then
you
would
create
specific
projects
in
which
you
will
have
virtual
network
etc.
The
pod
concept
relates
to
you
know,
from
a
cultural
perspective,
again
not
from
a
conceptual
perspective,
abut
to
virtual
machine.
The
service
equals
to
a
CCMP
load,
balancer,
meaning
what
I
mean
by
that
is
that
every
time
you
will
actually
create
a
service
in
openshift,
no
result
in
the
creation
of
an
ICMP
load
balancer
to
access
the
the
pods
that
are
initiated
in
the
infrastructure.
D
D
D
That
actually
through
the
demo,
but
we
support
this
type
of
implementation,
so
looking
at
the
different
features
so
James
mentioned
in
the
introduction,
but
we'll
bring
to
the
table
some
different
type
of
isolation.
So
we
obviously
support
you
know
default
mode,
but
you
know
known
as
a
cluster
mode
where,
basically,
you
have
one
large
virtual
network.
D
You
know
fetching
IP
addresses
from
two
different
iPods
for
Aipom
your
service
and
basically,
we
implement
all
the
overlay
networking
to
allow
the
pods
to
talk
to
each
other,
the
services
to
be
exposed
externally
to
be
reached
out
from
outside
of
a
cluster.
So
this
is
all
supported.
What
we
also
in
what
do
we
implement
it?
On
top
of
it
is
this
concept
of
namespace
isolation?
D
So,
basically,
when
you
create
your
namespace,
you
can
just
by
defining
an
annotation
in
the
namespace
declaration
trigger
on
control
side,
the
creation
of
separate
projects
and
a
separate
virtual
network.
So
what
it
does
is
that
it
basically
isolate
or
your
pod
and
services
that
belong
to
this
namespace
and
then
you
can
control
based
on
the
virtual
network,
who
you
want
to
talk
to
who.
So
that
gives
you
flexibility
inside
your
namespace.
D
D
We
look
at
how
we
get
as
a
user-
it's
very
flexible
because
on
top
of
it,
as
was
mentioned,
we
have
this
mode.
We
call
custom
isolation,
basically
so,
but
that
can
be
seen
in
different
use
cases
where
you
want
to
break
down
your
application
to
different
networking,
so
the
different
types
of
network,
so
you
can
create
networks
in
Cantrell,
then,
and
then
you
know
spin
up
your
pods
and
spacing
your
networks,
but
there
is
also
specific
use
case,
for
example,
when
it
comes
with
integrated
with
OpenStack,
for
example.
D
So
you
actually
would
create
virtual
machines
spin
up
on
specific
virtual
network
and
then
pods.
Let's
say
you
have
an
application,
but
at
the
front
end
in
containers
in
the
backend
that
sits
in
a
VM
that
runs
on
OpenStack.
You
still
can
create
the
networking
between
these
two
two
layers
by
using
this
custom
isolation,
because
you
can
actually
specify
where
you
want
to
run
your
front-end
and
that
ties
directly
with
a
networking
from
your
virtual
virtual
machine
environment.
So
that's
actually
pretty
nice
and
it
gives
you
the
flexibility
across
the
whole
stack
of
either.
D
You
know
allowing
communication
between
the
elements
isolating
them
into
namespaces,
allowing
them
to
talk
with
external
resources.
So
that's
that's
pretty
neat
and
what's
the
isolation
features
that
we
bring
to
the
table
and
just
wanting
to
remind
that
so
every
time
we
we
do
that
we
provide
a
CMP
load
balancing
between
all
the
parts.
So
this
load
balancing
concept,
is
totally
software-defined
and
also
made
it.
We
provide
all
the
security
policies
that
go
with
it.
D
We
also
provide
external
access
ever
be,
is
not
and
we'll
see
that
in
the
in
the
live
demo
or
via
the
allocation
of
floating
IPs,
and
as
we
mentioned
you
know,
we
have
the
integration
from
a
control
plane
to
external
gateways,
using
protocols
like
bgp.
So
all
the
all
the
virtual
networking
configuration
what
you
would
do
in
your
cluster
can
be
directly
and
automatically
announced
and
all
the
practices
can
be
advertised
and
propagated,
using
bgp
to
vr
af-s
and
each
of
em
and
PS
VPN,
for
example,
to
get
out
of
the
cluster,
etc,
etc.
D
Ok,
so
now
it's
for
isolation
just
quickly
on
ingress,
you
know,
I
guess
most
of
you
guys
are
familiar
with
the
concept
of
ingress
in
open
shapes,
basically
exposing
services
to
the
outside
world
and
being
able
to
route
traffic
to
different
services.
So
it
gives
a
different
part
of
your
application
being
able,
based
on
the
URL
or
the
hostname
or
things
like
that
to
actually
direct
traffic
towards
services
that
then,
in
the
back
end
server
purpose.
Kruger
pod
so
already
explained
that
service
for
us
is
a
CMP
load,
balancer
and
in
front
of
a
service.
D
We
can
have
an
ingress,
but
basically
every
time
you
create
one
object
of
that
type.
We
spin
up
two
instances
of
each
approxi
one
active
one
backup
and
these
instances
of
HF
proxy
will
get
also
configured
with
policies
around
policy
with
you,
you
put
in
place
and
we'll
see
that
in
the
demo.
Typically
here
and
that's
the
example
we'll
see,
you
will
get
slash,
dev
environment
and
a
slash
QA
environment,
so
you
have
to
application
in
to
serve
by
two
different
services
and
based
on
the
URL.
D
This
har
oxy
lab
answer
will
basically
route
the
traffic
toward
the
respective
services.
Ok,
so
one
last
feature
one
is
talk
about,
is
the
concept
of
Nestene
installation.
So
basically
we
support
using
OpenStack
as
an
infrastructure
as
a
service
software
to
spin
a
virtual
machine
in
which
you'll
be
able
to
create
kubernetes
cluster
openshift
cluster
etc.
So
the
idea
here
is
really
to
have
one
Sdn
controller
for
both
layers
for
virtual
machines
for
the
containers
so
just
going
through
this
is
rather
this
diagram.
D
You
know
we
use
an
open,
stack
and
control
to
provide
VMs
to
install
open
shift
so
that
from
control
networking
perspective
grades,
you
know
traditional
virtual
network
owner
be
Rotter,
plugs
type
interfaces
tor.
These
virtual
machines,
then
we'll
use
these
virtual
machines
to
install
open
shapes.
So
then
you
know
you
find
all
your
different
components.
I
just
represented
the
coronaries
component,
but
you
know
you
get
you
get
the
idea,
so
you
with
the
main
many
different
components
of
the
controller.
D
Then
let's
say
we
create
a
virtual
network
that
we
call
green
in
that
case,
to
connect
OpenStack
and
open
chief
workload.
So
when
we
spin
our
virtual
machine,
that's
traditional
control.
Networking
plugins
have
interface
in
a
creative
vrf,
so
this
virtual
machine
industry
network
get
associated
with
this
vrf,
so
it
gets
its
its
own
and
proper
routing
context,
basically
being
able
to
reach
anything
else
on
this
same
year,
drum
effort,
then
what
happens
when
we
launch
a
pod
and
that's
where,
for
example,
we
can
use
this
custom
isolation
that
I
was
talking
about.
D
So
you
get
this
implementation
where
you
have
VLANs,
basically
on
top
of
these
interfaces,
and
it
allows
you
to
connect
work
clothes
from
different
type
of
hypervisors
across
different
faster.
Potentially,
we
can
so
that's
how
we
build
power,
this
interconnection
between
the
ends
and
pods,
using
a
combination
of
overlay
networks
and
70
phases
with
Magda
name.
Okay,
and
so
you
can
replicate
that
as
many
times
as
you
want
and
have
over
virtual
machines
over
pods
different
virtual
network,
allow
communication
between
these
virtual
network
or
not
by
different
type
of
policies
on
them,
etc.
D
So
that's
what
I
wanted
to
highlight
in
term
of
feature.
So
if
I
recap,
all
the
isolation
features
regime,
P
load,
balancing
the
ingress
into
Asian
and
the
support
of
a
nested
installation
of
container
cluster
on
top
of
virtual
machine
provided
by
OpenStack.
So
now
you
might
be
wondering
okay,
so
how
do
I
install
control
with
weave
open
shape,
so
very
different
options
and
very
still
working
progress?
D
So
everything
on
this
slide
is
not
necessarily
100%
available
right
now,
but
I
wanted
to
mention
it,
and
most
of
it
is
going
to
be
available
very
very
soon.
So,
as
James
mentioned
in
the
introduction,
we're
working
on
a
certification,
we've
open
shapes,
so
that
is
actually
targeted
for
next
release.
Portal
2.1
that
should
come
I
get
beginning
of
September.
So
so
then
we
would
be
directly
integrated.
We've
open
shift
sensible,
so
that
will
give
you
what
a
way
to
deploy
at
the
same
time
open
shift
and
control
together.
D
As
of
now
to
deploy
a
country
in
a
container
environment,
we
actually
add
an
instable
playbook,
so
I
pointed
out
in
the
links
at
the
end,
the
sensible
playbook,
so
you
can
go
check
it
out
and
you
can
use
it
to
deploy
country
with
open
shapes
coronaries,
for
example,
we're
working
on
helm
charts.
Actually,
so
we
we
already
have
helm
charts
to
deploy
control
where
we're
not
like
yet
100%
good
proof
and
tested,
so
they
will
be
supported
officially
in
one
of
our
future
releases.
But
just
so
you
know
and
keep
it
in
my
router.
D
We
actually
will
have
an
implementation
to
deploy,
charts
and
again
there
is
a
control
docker
repo
on
github
it
has.
The
on
charts
can
go
check
them
out.
So
one
thing
that
we
did
with
a
control
for
dots
already,
which
came
up
couple
months
ago,
that
we
actually
contour
eyes
or
control
software,
so
the
ID.
So
if
you've
been
following
open,
contra
we've
been
posting
packages
up
to
the
two
versions
and
then
for
free
dot.
D
X
was
no
optional
packages
on
the
PPA
either
the
source
code
is
always
available
and
one
can
always
go
and
build
it,
but
basically
the
ID
with
a
containerization
to
take
advantage
of
it
would
be
to
make
this
container
publicly
available
right
off
the
CIA
Harmons.
So
right
now
we're
actually
reworking
the
tuning
of
her
CI
environment
so
very
soon
we'll
make
available
the
containers
directly
out
of
CI
so
that
people
can
consume
them
directly
and
then
deploy
them
in
their
environment
of
choice
and
with
that
I'll.
D
Just
give
you
guys
an
introduction
on
the
demo
that
savage
crew
is
gonna
unfold
to
giving
you
the
main
you
know,
features
were
going
to
be
shown
and
then
all
its
I
know
savage
fruit
comment
through,
as
is
unfolding
the
demo.
But
basically
here
is
the
setup
we
have
control
running
weave
up
in
shifts.
D
We
have
it
like
standard,
namespace
and
open
shift
context
called
20
per
namespace
and
we're
gonna
spin
up
some
pods.
So,
first
it's
not
really
presented
in
the
demo,
but
but
you
know
you'll
get
the
ID
and
that's
basically
what
happens
every
time
you
know
the
pod
gets
created,
but
the
given
pod
is
going
to
be
important.
Services
are
gonna,
be
created,
we're
gonna,
associate
external
IP,
so
in
this
case
we'll
do
a
will
will
do
it
for
us,
but
I'm,
just
giving
you
the
workflow
and
basically
what
it
implies
on
the
control
side.
D
Every
time
we
do
that
type
of
operation
is
that,
basically,
when
we
associate
the
external
IP,
you
would
create
a
floating
IP
but
then
gets
advertised
automatically
using
bgp
to
be
gateways.
So
that's
what
I
was
explaining
earlier
work
earlier
when
we
take
advantage
of
basically,
you
know
MPLS
VPN
concepts
and
advertising.
This
practice
is
through
bgp.
I
will
give
access
from
the
external
world
to
the
resources
that
are
on
the
cluster
and
then
let's
say
your
application
scales
up.
D
You
change
the
number
of
replicas
automatically
the
service
is
implemented
as
an
EMP
load
balancer,
so
you
would
load
balancer
traffic
between
the
different
parts.
So
that's
you
know
one
thing
and
you'll
see
that
happening
in
the
background.
When
the
services
are
going
to
program
we
created,
we
will
show
namespace
isolation
by
bt,
creating
a
namespace
in
which
we'll
say
that
we
want
the
isolation
to
be
effective
and
so
to
isolate
the
pod
and
services
inside
this
namespace.
D
Basically,
creating
this
part
will
see
that
the
communication
between
the
you
know,
non-isolated
namespace
and
the
x-ray
namespace
will
not
be
possible.
On
the
other
hand,
pod
scheduled
in
this
isolated
namespace
will
have
you
know,
communication
inside
the
namespace.
That's
going
to
be
just
fine,
then
from
this
namespace
will
show
the
s
not
feature
so
basically
allowing
this
part
to
access
or
allowing
your
application
to
access
internet,
for
example,
through
patch
resources
and
we'll
finish
with
a
fan-out
ingress
example.
D
It's
a
little
bit
like
I
was
explaining
in
the
slide
with
two
different
type
of
services,
with
URL
routing
definitions
and
then,
depending
which
one
we're
actually
querying
queue.
Environment
death
will
be
then
redirected
to
the
services
and
each
of
the
services
will
then
load
balance
the
requests
toward
the
pods
in
the
backend
okay.
So
that's
all
I
had
with
the
integration
regarding
the
integration.
We've
open,
shapes
to
the
different
features
of
the
installation
and
now
I'll
hand
it
over
to
send
it
through
for
a
live
demo.
Thank
you
guys.
Ok,.
A
B
B
Initially,
when
we
provision
contrail,
we
create
two
I
Pam's,
mainly
the
service
I
Pam
and
the
poly
Pam.
So
the
part
I
Pam
is
large
subnets,
it's
a
slash
to
a
subnet
and
the
parts
whenever
a
part
is
launched.
It
spend
in
this
particular
subnet.
Whenever
services
launched
and
services
come
up
on
this
10
9600
slash
troll
subnet
and
these
hype
amps
are
associated
with
one
network,
which
is
called
the
cluster
network.
B
So
right
now
these
are
the
number
of
different
projects.
I
have,
in
contrast,
which
maps
to
our
different
namespaces
in
OpenShift.
So
the
first
slab
the
move
is
about
namespace
isolation.
Let's
quickly
jump
and
create
two
new
namespaces
I
have
two
namespaces
one,
which
is
an
isolated
namespace
and
another
one
on
an
isolated
need
space.
B
So
the
whole
idea
here
is
to
create
these
namespaces
launch
two
parts
in
each
of
these
namespaces
and
then
try
to
ping
between
them
and
verify
that
you
know
the
thing
doesn't
go
through
so
by
default,
openshift
doesn't
provide
any
isolation.
This
is
the
value
add
that
contraire
brings
in
and
how
we
go
about
creating
a
isolated
namespaces.
We
have
this
annotation
and
whenever
this
annotation,
which
says
isolation,
is
equal
to
true,
then
we
attach
relevant
security
groups
to
the
virtual
network
and
that's
how
we
isolate
that
namespace
from
the
rest
of
the
world.
C
B
So
whenever
we
hear
an
isolated
namespace,
new
virtual
network
is
created.
The
reason
why
we
do
it
is
people
we
want
all
the
parts.
We
don't
want
all
the
parts
to
present
in
this
isolated
namespace
to
talk
to
other
parts
present
in
non
isolated
namespace
and
that's
when
we
create
a
security
rule-
and
we
say
parts
within
this,
namespace
can
communicate
amongst
themselves
and
you
know
deny
all
for
the
rest
of
the
pods.
So
let's
see
how
it's,
how
it
works
and.
D
B
B
B
B
So
this
is
the
demo
of
the
isolated
namespace.
Now,
let's
go
ahead
and
create
a
source
NAT
functionality
where
we
allow
Internet
access
to
all
of
these
parts.
So
by
default
you
know
these
parts
cannot
access
the
Internet,
because
we
believe
that
you
know
the
pods
are
pre-built
packages
and
they
don't
need
to
access
the
Internet.
So
we
you
know
this
would
be
a
security
functionality
that
we
can
enhance
and
hence
we
don't
allow
Internet
access
by
default.
B
B
Let's
call
this
example
and
then
we
have
an
external
gateway
network
which
is
our
publicly
facing
network
and
let's
select
that
virtual
network
and
let's
connect
the
cluster
Network
to
public
network.
So
whatever
part
comes
up
on
this
cluster
Network
we'll
use
this
public
network
to
get
out
to
the
Internet.
So
once
this
router
object
is
created
now,
if
we
go
back
to
the
pod
and
think
again,.
B
Now
we
see
that
the
part
can
reach
out
to
the
Internet.
So
this
way
we
actually
torch
NAT.
So,
basically,
whatever
IP
is
present
on
the
Christian
network,
we
NAT
it
to
the
IP
person
on
the
public
network
and
we
reach
out
to
the
Internet
and
that
can
also
be
verified
in
the
forge
tab
of
the
non
isolated
network.
So
basically,
this
IP
uses
a
floating
IP
from
the
cluster
network
in
order
to
get
out
of
the
Internet.
As
you
can
see,
this
is
the
this
is
IP
that
it
uses
personality.
B
B
I'm
on
non-isolated
namespace
and
let
me
create
a
part
in
dev
and
QA
in
his
pitches.
Basically,
and
what
I
have
in
dev
was
basically
an
application
which
rental
application
which
says
left,
and
I
similarly
I
have
a
bad
QA
application
which
displays
QA
in
the
front-end.
So
let's
go
ahead
and
create
this
pod.
B
B
B
Now
have
three
web
app
dev
pods
and
three
robot
QA
parts
and
their
respective
services,
government,
QA
and
similarly,
in
the
contrary,
web
UI.
If
you
go
to
the
ports,
we
see
that
you
know
there
are
number
of
VM
virtual
machine
interfaces
created
three
for
the
Dell
pods
and
three
for
the
QA
parts,
and
we
also
have
two
for
the
services
and
the
way
we
differentiate.
The
services
from
the
parts
is
through
this
device
type,
which
is
the
K
test
load
balancers.
So
these
IPS
dot
155
on
dot
15
are
actually
the
service
eyepiece.
B
B
B
B
B
C
B
So,
contrary
matically
pushes
this
rules
in
the
backend
on
the
agent
node,
so
that
whenever
a
traffic
comes
on
the
ingress
IP
it
automatically
forward
this
to
either.
You
know
the
service
dev
or
the
service
QA
parts
respectively
and
in
the
haunted
web
UI.
If
I
refresh
the
screen,
then
I
have
a
public-facing
IP
for
define
out
ingress,
which
is
1080
430
1.53,
which
comes
from
a
public
virtual
network
and
on
opening
on
the
UI.
If
I
put
that
IP
/
def,
it
should
take
me
to
the
dev
part.
B
As
you
can
see,
the
IP
address
is
246,
which
is
one
of
the
back
end.
There
parts
hitting
refresh
you
know
it
takes
me
to
a
different
IP,
which
shows
that
you
know
easy
and
be
load.
Balancing
is
working
in
the
backend,
so
/qa
should
take
me
through
the
few,
a
part
which
it
does
and
if
you
have
a
six
to
forty
two
and
on
refresh
you
know
it
takes
me
to
a
different
part,
two,
forty
four.
B
So
this
shows
us
the
simple
finality
English
type
and
there's
also
one
more
English
type
which
I
would
like
to
show,
and
that
is
named
Beijing
list
where
we
passed
the
host
name
and
the
header
field,
and
that's
how
basically
it
differentiate
where
to
go,
which
back-end
service
to
use
so
in
this
I
have
I
passed.
This
host
called
Jeff,
calm
and
QA
calm.
So
whenever
the
head
del
matches
either
one
of
these
host
types-
and
it
goes
to
the
different
back-end
services
present
here,.
B
B
D
B
Rule
which
is
being
created
for
the
HTF
of
he
is
load
balancing
and
in
the
contrail
web
UI.
If
I
refresh
the
screen,
I
should
see
another
IP,
which
is
m84
3154
for
the
name
beijing
list
and
now,
if
I
just
enter
this,
then
it
should
throw
me
an
error
which
it
does
because
I
haven't
passed
the
host
information,
the
header
information.
So
I
use
this
tool
to
pass
the
header
information
and
when
I
pass
post
equal
to
TF,
calm
and
I
hit
refresh.
B
It
should
take
me
one
of
the
coupons.
So
this
shows
us.
You
know
the
bypassing
the
host
information
in
the
header.
It
directs
us
to
different
parts
and
seamlessly
in
the
backend.
So
this
is
the
demo
that
I've
got
in
terms
of
nested
isolation,
English
types
and
so
not
and
contraire
does
offer
you
know
rich
analytics
as
well.
So
you
can
see
the
different
node
types
here.
So
this
is
one
of
the
node
that
I
have
that
I
actually
launched
the
vocal
depart
workloads-
and
this
is
my
control
node.
So
there's.
B
Information
here
that
you
can
grab
like
how
much
traffic
is
coming
to
each
of
this
pods,
the
CPU
utilization
on
the
nodes
and
stuff
like
that,
so
you
would
never
require
a
third
party.
You
know
a
monitoring
tool
in
order
to
capture
all
this
information.
Analytics
components
does
this
for
you.
So
this
is
where
we
bring
the
value,
add
in
a
portion
of
the
control,
and
yes.
C
D
Diane
I
was
trying
to
catch
up,
you
know
and
going
through
each
of
them
at
a
time,
but
you
know
writing
and
reading
you
have
a
new
response,
a
successor
to
leave
a
question
about
them
like
how
to
basically
spend
the
same
network
across
different
clusters.
So
you
know,
I
was
talking
about
you
know.
Running
OpenStack
on
topic
remains
open
ships
are
running
open,
you
know
of
the
stack
on
top
of
it
or
running
open
ships,
credit
inside
of
OpenStack,
etc.
D
So
those
I
already
answered
and
explain
one
thing
I
was
you
know
about
to
write,
is
also
if
we
consider
different
clusters
like
we
have
a
way
to
kind
of
generate
networks
across
different
class
format.
We
use
different
controllers,
that's
also
an
option,
you
know.
Basically,
since
we
sync
our
controllers
using
BGP,
you
can
have
virtual
networks
and
you
know
exchange
networking
information
in
each
of
a
cluster
based
on
you
know,
basically
importing
quarter
fraud
targets
and
these
kind
of
stuff.
D
B
A
D
Then
there
was
a
question
about
the
advantageous
over
Indian
solutions
like
this,
which
nuage
Cisco
there
is
I
mean
various
multiple
answers
to
it
like
some
are
more
like
fabric
oriented,
some
are
more
based
on
overlay.
Some
are
directly
in
the
underlay.
I
mean
there
is
there's
a
lot
of
differences,
so
you
would
require
like
a
one
to
one
corporation,
for
you
pretty
much
I,
don't
know.
If
anybody
else
wants
that
things
and
that's
what
yeah.
C
I
mean
so
going
back
to
what
I
said
at
the
beginning,
I
mean
the
fact
that
it's
open
source
that
it
it's
not
a
niche
solution.
Just
for
containers
like
you
know,
if
you
look
at
something
like
maybe
calico
or
Conte's,
they
tend
to
be.
You
know
mostly
for
containers.
The
other
thing
is
you
know.
If
you
talk
to
net
ops
people
eventually,
you
know
they
will
have
some
sort
of
say
in
the
the
DevOps
stack
in
the
open
chip
cluster
right,
because
you
need
to
connect
other
things
at
that
point.
C
You
know
one
one
tool
to
rule
them
all
like,
so
they
don't
have
to
learn
something
new.
It's
also
really
helpful,
and
then
you
know
when
you
get
to
this
sort
of
cliff
of
where
you
can't
do
something.
With
these
more
niche,
less
mature
solutions,
yeah
sure
they're
lighter
weight,
but
then
you
get
to
some
point
where
you
can't
do
something
right
controls.
You
know
quite
mature,
very
rich.
C
And,
like
I
said,
you
know,
I
think
they're,
sensible
defaults,
where
it's
approachable
and
easy
to
use,
but
then,
when
you
need
to
do
something,
sophisticated
chances
are.
There's
probably
you
know
somebody
that's
thought
of
that
before
we
have
some
tough
networking
customers.
So
so
that's
something
to
think
about
as
well.
The
analytics
just
sadi
through
pointed
out
is
another
thing
right.
Yeah.
D
And
I
use
something
that
is
in
general,
you're
kind
of
kind
of
an
afterthought
or
but
our
analytics
API
is
actually
pretty
rich
and
gives
a
lot
of
visibility
on
the
operating
States
of
your
network.
So
that's
something
we
like
to
point
out
as
a
differentiator
as
well,
these
all
the
information
you
can
basically
extract
from
our
analytics
and
then
you
can
integrate
it
in
your
monitoring
or
troubleshooting
tools.
As
a
customer,
that's
a
big
difference.
There's.
D
Question
there
was
two
more
I
mean
a
consumer
question
was
one
question
from
George
and
asking
about
what
it's
like
here
on
OpenStack
with
Neutron
and
open
shapes
we've
opened
Cantrell,
so
in
that
case
like
but
very
consider
Europe
to
networking
domains.
Basically,
in
that
case,
like
you
know,
either
we
integrate
with
Neutron
as
a
neutron
plug
in
and
then
use
control.
We've
open
stack,
but
if
you
use
plain
veneer,
Neutron
then
and
use
open
control.
D
We've
opened
chips
on
the
other
hand,
and
you
want
to
have
somehow
some
kind
of
synchronization
in
terms
of
networking
event,
you
will
have
to
go
through
a
gateway
or
exchange
routing
information.
You
don't
have
like
direct
integration.
In
that
sense,
you
know
like
what
I
meant
when
I
explained
the
next
read
mode.
Was
that
basically
used?
You
know
Venetian
plug-in
points
to
contra
API
and
the
C&I
plug-in
uses
country
as
well.
In
that
case,
that's-
and
there
is
another
question
from
Ally-
about
how
to
handle
high
availability
and
service
recovery.
D
D
It
is
scale
out
and
what
we
do
in
general
in
front
of
it.
So
we
have
a
lot
balancer
in
front
of
it
to
load
balance
all
the
requests
and
in
the
back
hands.
The
database
is
a
sequel
database
that
is
clustered
across
different
node
to
basically
ensure
that
if
you
know
one
node
comes
to
fail,
one
process
actually
on
one
node
comes
to
cell,
then
the
other
processes
can
take
over
the
load
and
the
work
there
is
just
couple.
D
Processes
are
very
specific
that
are
more
in
an
active
backup,
backup
kind
of
a
thing,
but
otherwise
it's
all
active
active
and
we
support
a
2
n
plus
1
model
of
failure.
Where
n,
basically,
is
the
number
of
fare
so
store
in
one
theater,
we
have
free
controllers
with
free
controllers,
handle
the
whole
high
availability
and
failover,
but.
A
D
B
D
That's
it
otherwise
in
terms
of
design
the
solution
itself,
if
you
have
multiple
controllers,
then
you
know
they
will
handle.
They
share
themselves,
yeah,
it's
more
of
a
stable
or
billable
answer
in
front
of
each
a
most
most
customers.
We
so
we
have
customer,
be
still
have
their
like
hardware
load
balancer
solution
when
they
use
remote
clusters,
we
put
that
in
front
and
they
use
it
to
access
different
resources
in
your
cluster
at
the
point
to
control.
In
that
case,
we
have
some
people
that
use
software
load.
C
Front
of
the
contrail
service
console
API,
yes,
yeah
yeah.
That
kind
of
goes
back
to
you
know
the
different
installation
modes
that
we
talked
about
to
and
what
kind
of
differentiates
us
versus
some
of
the
competitors
actually
as
well.
You
know
contrail
does
support
in
service
software
upgrades,
so
you
can
go
between
one
version
of
contrail
and
another
within
an
open,
shipped
cluster
with
no
downtime,
but.
A
A
I
want
to
respect
people's
times
and
what
I'll
try
and
do
is
I'll
capture
the
questions
here
and
maybe
I'll
share
them
with
the
speakers
and
if
you,
if
there's
more
links
or
things
that
you
want
to
share
when
I
publish
this
as
the
blog
dot
on
the
video
in
the
blog
got
on
OpenShift
comm,
we
can
add
those
links
and
other
further
details
and,
along
with
the
blog
articles
and
links
that
are
here.
So
I
really
want
to.
Thank
you
guys
for
your
time
today
and
for
everybody
for
your
great
questions.
A
This
is
obviously
a
big
hot
topic
and,
though
I
you
know,
sometimes
you
never
know
what
everybody's
going
to
ask
great
questions
on.
Nds
have
been
really
good
questions
and
it
was
a
wonderful
presentation,
so
it
this
may
be
one
of
those
YouTube
videos
that
people
watch
all
the
way
through
the
end
we'll
find
out
later,
and
so
thanks
guys
for
doing
this
and
we'll
look
forward
to
another
one
soon.
Thanks.