►
Description
Join us for a little one-on-one time with a Red Hat Product Manager - each session will feature a Product Manager focused on a specific product or project. We’ll start with an overview & discussion of the topic, then have time for Q&A.
A
Good
morning,
good
afternoon,
good
evening,
welcome
to
another
episode
of
open
shift
tv.
Here
we
are
in
the
ask
the
product
manager
office
hours,
which
is
only
going
to
be
a
half
hour
today,
due
to
some
limitations
and
schedules
and
such,
but
we
might
not
need
more
than
a
half
hour.
So
I'm
going
to
introduce
you
to
the
one
and
only
mark
curry,
product
manager
here
on
the
openshift
team,
here
at
red
hat
and
he's
going
to
talk
about
ip
second
openshift
ovn,
which
I
think
is
a
really
interesting
concept
mark.
A
Please
introduce
yourself
to
the
world
and
let
us
know
what
you're
working
on
now.
B
Yeah
great
thanks
chris
yeah.
So
again
my
name
is
mark
curry
and
I'm
an
openshift
product
manager
and
I
specialize
in
container
infrastructure
elements
and
one
of
those
is
that
of
networking.
And
so
today
I'm
going
to
talk
about
a
a
spotlight
feature
that
that's
part
of
our
openshift
4.7
release,
and
that
is
ipsec.
B
In
openshift
3.,
it
was
kind
of
a
rag
tag,
implementation
to
be
truthful.
It
worked
great,
but
we
wanted
to
do
was
we
wanted
to
build
in
a
lot
more
automation?
We
wanted
to
make
this
operator
controlled,
so
there's
autonomy
with
how
it
is
that
it
runs.
We
wanted
to
make
sure
that
it
was
using
a
a
modern
level
of
encryption
that
was
would
meet
phipps
compliance
standards.
B
We
wanted
to
add
in
the
ability
to
be
more
surgical
with
the
application
of
ipsec,
and
we
also
wanted
to
build
in
future
support
for
smart
mix.
So
the
idea
is
that
encryption,
it
you
will
take.
You
know
it
depends
on
the
size
of
the
packet
but
you're
going
to
take
a
little
bit
of
a
hit
in
performance,
thankfully,
with
ovn
we're
hitting
near
line
rate
capability
of
the
cards
already.
B
So
if
you,
if
you
just
kind
of
assume
somewhere
around
10
percent,
that's
fair,
but
what
we
want
to
do-
and
we
have
a
lot
of
customers
asking
us
for
is
the
ability
to
offload
that
encryption
to
smartnex.
And
if
that's
the
case,
you
remove
that
load
from
from
the
node
onto
the
nic
and
some
special
purpose
chips
to
take
care
of
that.
So
we
wanted
to
have
all
of
these
things
in
this
new
implementation.
B
So
there
was
a
bit
of
a
lag
before
we
were
able
to
present
it
to
our
customers,
but
we
finally
have
it
available
for
ga
and
four
seven,
and
this
is
not
the
end
of
it.
I'll
talk
about
it
a
little
bit
and
there's
more
things
that
we're
gonna
do
to
enhance
it
in
future
releases
that
I'll
talk
about.
B
So
let
me
back
up
a
bit
a
few
things,
so
probably
the
most
important
thing
to
get
out
of
this
presentation.
This
is
that,
how
do
you?
How
do
you
properly
spell
ipsec.
B
So
I
I
know
this
is
this
is
just
kind
of
funny
for
me.
I
I've
seen
it
all
across
the
board:
people
all
uppercase
ipsac
people
laura
they
they
have
up
and
down
cases
proper
case.
Just
fyi
is
in
the
rfc,
it's
capital,
ip
lowercase
sec,
and
so
I've
tried
to
do
that
everywhere.
I'm
just
trying
to
spread
the
spread,
the
knowledge
and
spread
the
word.
B
A
B
Things
will
get
so
the
count
so
we'll
talk
about
some
more
complex
things
as
we
go
along,
but
first
things
first
right.
So
one
of
the
things
that
we
have
done
again
in
four
seven
is
enable
ipsec.
So
what
is
it
so?
Ipsec,
in
a
nutshell,
is
the
ability
to
automatically
encrypt
all
internode
traffic
between
pods
data
plane
traffic,
specifically
so
that
that
traffic
is
automatically
confidential.
B
It's
been
authenticated
and
we
know
it
has
not
been
tampered
with
and
so
application
programmers
when
they
write
their
their
their
traffic
and
their
connections
between
the
pods
and
those
pods
can
be
spread
out
across
whatever
nodes
in
the
cluster.
They
could
write
their
own
authentication
scheme,
their
own
encryption
scheme.
Excuse
me
to
do
that.
B
However,
if
you're
the
cluster
administrator,
it's
probably
first
of
all
easier
and
also
far
more
guaranteed
to
to
have
that
traffic
secured
by
just
automatically
encrypting
all
the
traffic
that
travels
between
participating
nodes,
and
so
what
we
also
want
to
do.
B
Is
we
want
to
make
that
flexible
so
that,
when
you
add
new
nodes
to
the
cluster,
you
don't
again
have
to
think
about
that
and
that's
where
the
concept
of
an
ipsec
operator
comes
in
the
apusic
operator
actually
works
with
the
underlying
ovn
networking
and
with
kubernetes
to
understand
when
the
when
the
platform
has
been
modified
and
when
it
is
modified
like
say
a
new
node
has
been
added
as
part
of
an
auto
scaling
feature
or
whatever.
Then
it
automatically
will
bring
that
node
into
into
the
encryption
scheme
and
make
it
a
valid
participant.
B
So
how
does
this
work
exactly
so
there's
a
couple
of
kernel
elements
involved,
so
the
first
one
is
going
to
be
liver,
swan
and
liver.
Swan
is,
is
basically
a
user
space
daemon
that
follows
ike
the
internet,
key
exchange
specification,
and
so
that's
the
thing.
That's
actually
going
to
be
negotiating
the
ipsec
connection
between
the
different
nodes
in
the
cluster.
B
The
other
element
is
ipsec
itself
and
ipsec
itself
is
implemented
as
xfrm
in
the
kernel
itself
right,
and
so
these
two
elements
work
together
and
as
I've
described
them,
this
is
actually
being
controlled
by
our
networking.
Ovn
I'll
explain
why
in
a
moment-
and
it's
not
just
a
host
level
thing-
that's
happening
here,
and
so
one
of
the
way
we
implemented
it.
This
could
be
first
of
all
picked
up
and
placed
onto
a
smartnic
card
in
the
future,
but
also
by
keeping
it
tied
closely
to
ovn.
B
We
can,
in
the
future,
be
more
surgical
with
the
application
of
ipsec,
so
we
can
say,
for
example,
in
the
future,
not
all
traffic
between
nodes,
because
I
don't
want
all
my
traffic
to
take
that
that
encryption
hit.
Instead,
I
want
just
these
particular
name
spaces
to
be
encrypted,
the
idea
being
that
we
can
limit
our
liability
of
of
overhead
to
just
those
that
require
it
and
and
and
there's
more
that
we
can
do
from
there
right
now.
What
I've
talked
about
here
is
really
east-west
traffic.
B
Only
but
a
lot
of
people
ask
me-
and
there
are
a
lot
of
great
use
cases
for
wanting
ipsec
north
south
as
well
into
and
out
of
the
cluster.
We
have
a
lot
of
telco
use
cases
where
they
are
running
containerized
network
functions
and
they
would
like
to
encrypt
that
traffic
as
well.
For
us
all,
the
same
reasons,
and
because
of
the
same
with
the
same
kind
of
mechanism,
they
absolutely
can
just
not
the
way
we've
implemented
it
on
day
one.
So
all
the
elements
are
there
for
them
to
use
to
do
that.
Encryption.
B
It's
just
not
a
participant
in
the
east
west
operator
fueled
encryption
scheme,
though,
as
we've
done
it
in
the
future.
We
will
enhance
that
and
so
we're
in
the
stage
of
you,
know,
building
upon
building
a
design
upon
the
use
cases
that
we've
gathered
from
customers.
Looking
for
that
type
of
encryption.
B
Currently
ipsec
is
ibv4
only,
however,
as
of
about
two
days
ago,
upstream,
moved
ipv6,
dual
stack
to
beta
and
now
that
it
is
beta,
that's
a
really
great
thing.
Now
that
it's
beta,
we
can
support
this
for
our
customers,
which
means
in
the
4-8
time
frame.
We
are
poised
to
fully
support,
ipv6,
dual
stack
and
single
stack,
and,
and
so
as
part
of
that,
we
want
to
extend
that
to
ovn
ipsec.
B
So
again,
it
was
only
still
alpha
upstream
in
four
seven,
so
we
didn't
do
that
just
ipv4
only
at
four
seven,
but
in
four
eight
we're
going
to
extend
that
to
v6
what
else
on
this
slide.
So
you
know
so
the
question
often
comes
up.
Tell
me
exactly
again
what
traffic
is
going
to
get
encrypted,
so
I
drew
a
small
diagram
on
this
slide.
Actually,
I
I
don't
have
I'm
sorry.
Let
me
bring
up
a
slide
to
show
you
I'm
looking
at
a
slide,
I'm
referring
to
it
and
just
realize.
B
So
let
me
share
that
slide.
Right
now,.
B
B
So
on
this
particular
slide,
hopefully
you
can
see
this.
Yes,
I
don't
know
if
my
zoom
window
over
here
is
blocking
the
diagram,
but
let
me
try
to
move
it
so
basically,
so
what
traffic
exactly
is
is
getting
encrypted?
Well,
you
have
to
understand,
first
of
all
that
this
is
inter
node
traffic
only
so
anything
that's
using
a
geneve
tunnel
to
get
from
one
node
to
the
other,
so
anything
that
flows
through
ovn
between
nodes.
B
Now,
that
being
said,
there's
still
two
networks
that
are
across
node
and
there
is
the
actual
cluster
network,
or
sometimes
just
simply
referred
to
as
the
pod
network.
That's
the
one
where
we
have
our
overlay
networking
and
then
there's
the
host
network
and
host
networking
is,
is
literally
you're
using
the
networking
of
the
host,
which
is
a
different
networking
scheme
and
there's
lots
of
advantages
in
certain
circumstances
for
using
the
host
network.
B
So
this
is
designed
specifically
for
cluster
network
internode
data
plane
traffic.
So
why
do
I
keep
emphasizing
first
of
all
data
plane
because
traffic
that
goes
between
our
control,
plane,
nodes
and
our
worker
nodes?
We
don't
want
to
encrypt
that.
That's
already
encrypted
and
in
fact,
that's
already
encrypted
with
something
that
is
fips
compliant,
so
it's
using
https
for
that
traffic
already.
So,
let's
not
double
encrypt
it.
Let's
not
waste
time
doing
that
right.
The
other
part
to
this
is
the
actual
data
plane.
B
So
that's
the
part
we
want
to
focus
on
and
so
what
exactly
data
plane
traffic?
Well
I
can,
I
can
tell
you
right
off
the
top
that
there's
really
two
primary
use
cases,
and
then
there
are
side
effects
and
so
I'll
get
into
those
next,
but
the
two
primary
cases
is:
we
want
to
encrypt
any
pod
traffic
on
the
cluster
network
going
between
nodes
period.
B
What
we
specifically
are
not
trying
to
do
is
encrypt
traffic
on
the
host
network
pod
to
pod.
That's
that's
at
the
host
level
and
that's
a
kind
of
a
corner
case.
There
may
be
somebody
that
wants
to
do
that.
But,
generally
speaking,
that's
that's
not
what
people
are
asking
for.
However,
there
here's,
where
the
side
effects
come
in,
so
I
already
talked
about
how
we
specifically
are
weeding
out
control,
plane
traffic
as
much
as
possible
because
that's
already
tls
encrypted,
but
some
of
the
side
effects
come
in
well.
What?
B
Well,
it
turns
out
that
if
you're
going
from
the
host
network
to
the
cluster
network
between
pa
between
nodes,
the
traffic
actually
has
to
go
into
ovn
on
the
local
side
and
get
geneve
a
header
added
onto
it
before
traversing
that
tunnel
to
the
remote
node,
and
so
therefore
that
traffic
is
in
fact
a
participant
in
the
encryption
scheme
and
that
traffic
will
be
encrypted.
B
Now
I
think
those
scenarios
basically
describe
any
question
you
might
have
about
is
my
traffic
encrypted,
but
one
common
question
that
comes
up.
Is
you
know?
What
about
the
api
is
that
traffic
encrypted?
Well,
the
gotcha
here
is
that
there's
two
apis
there's
the
openshift
api
that
lives
on
the
cluster
network,
so
yes,
traffic
to
and
from
that
particular.
If
you're
excuse
me
enter
node
traffic
to
and
from
the
openshift
api
that
is
going
to
be
encrypted,
but
the
cube
api
that
actually
lives
up
on
the
host
network.
B
So
unless
you
are
going
from
the
cube
api
to
a
cluster
network
pod
that
traffic
is
not
going
to
be
encrypted,
so
those
are,
I
think
that
describes
most
of
the
cases.
People
are
interested
in
happy
to
address
any
additional
questions,
but
that's
kind
of
the
big
picture.
A
B
Yeah,
the
the
the
encryption
level
and
the
encryption
type
that
we're
using
for
this
ipsack
is
a
very
strong
aes
encryption
scheme.
We
talked
to
the
liberswan
team
before
implementing
it
and
they
they
they
had
nothing
but
good
things
to
say
about
the
particular
scheme
that
we
chose
and
they
recommended
it
in
fact,
and
so
we
have
what
we
feel
is
the
the
strongest
scheme
available
today.
That's
that's
been
proofed
as
well
as
this
is
something
a
very,
very
big
part
of
this.
B
The
primary
use
case
for
ovn
ipsec
was
fips
compliance,
so,
of
course,
we
had
to
make
sure
that
this
was
going
to
be
for
our
customers
that
required
for
regulatory
or
other
reasons.
We
need
to
make
sure
that
fips
was
being
met
and
this
encryption
actually
crushes
that
requirement,
so
we're
good
there
cool.
B
So
when
we
talk
a
little
bit
about
how
you
would
actually
do
this
on
a
cluster,
so
the
first
thing
I'd
like
to
mention
is
that
today
the
way
this
works
is
you-
and
this
actually
was-
this
came
from
a
fips
requirement,
actually,
which
was
it
had
to
be
enabled
at
installation
time
now.
You
know
for
those
folks
that
say
well,
you
know
I
don't
want
to
have
to
reinstall
my
cluster
just
to
get
ipsec.
B
In
the
future,
so
the
ability
to
just
enable
it
disable
it.
So
you
technically
could
do
it
now
through
a
more
manual
process,
but
I
don't
think
that's
in
the
best
interest
of
our
customer.
B
We
want
to
build
this
into
our
cluster
network
operator
and
have
these
things
automated,
so
that,
when
all
you
would
have
to
do
is
potentially
just
say
turn
it
on
and
then
the
cluster
network
operator
would
would
kick
off
and
it
would
set
up
all
the
certs
and
understand
which
nodes
are
participants
in
this
and
just
do
everything
for
you
and
then
another
thing
which
today
is
actually
a
fips
violation,
which
is
phipps,
says
you
should
not
be
able
to
disable
this
encryption.
B
But
technically,
if
we
enable
the
ability
to
turn
it
on
on
a
running
cluster,
we
should
be
able
to
turn
it
off
as
well.
Right,
so
that'll
be
part
of
it.
But
you
know
so
we
we
give
you
we
we
don't
dictate
or
we're
trying
not
to
dictate
how
it
is
you
implement
it
and
on
what
clusters.
But
what
we
want
to
do
is
just
provide
the
functionality
and
we
want
to
provide
industrial
strength,
security
for
you
right
out
of
the
box,
so
we're
trying
to
be
sensitive
to
that.
B
So
so
how
does
it
work
exactly?
So,
if
you
look
over
on
the
right
hand
side,
those
of
you
have
installed
in
openshift
cluster
before
this
probably
isn't
too
foreign
to
you
to
the
new
folks.
Essentially,
what
you
can
do
is
when
you
know,
there's
a
number
of
ways
you
can
install
openshift.
One
of
those
ways
is
from
the
command
line.
B
There's
a
tool
called
openshift
install
and
what
you
can
do
is
just
say:
open
shift,
install
create
cluster
and
it's
just
a
one-liner
and
the
cluster
will
come
up
with
a
default
set
of
parameters.
But
what
a
lot
of
people
choose
to
do?
Is
they
choose
to
pause
that
installation
and
add
their
their
tweaks
to
the
configuration?
B
And
so,
in
this
particular
case,
what
we're
doing
is
we're
saying,
pause.
The
installation
just
for
a
moment
create
the
manifests
and
then
I'm
going
to
go
in
there
and
I'm
going
to
edit
the
manifest
that
will
describe
how
this
installation
is
going
to
go.
So
when
we
create
all
the
manifests.
B
One
of
the
things
we
need
that'll
do
is
that'll,
make
a
manifest
directory
for
us,
and
then
we
can
create
a
yaml
file
inside
there
that
describes
ipsec
and
how
it's
going
to
be
configured
and
so
there's
a
very
simple
example
in
there
that
I
provided.
So
if
you
were
to
use
your
favorite
editor
to
create
that
cluster
network
three
config
yaml,
you
specify
the
your
cluster
network,
you
specify
any
other
parameters
about
this,
that
you
would
like
to
customize,
and
then
you
your
service
network
and
then.
B
B
The
installation
create
cluster
and
away
you
go
so
what's
going
to
happen
when
the
cluster
comes
up.
The
first
thing
that's
going
to
happen
is
the
cluster
network
operator
is
going
to
create
a
self-signed
certificate
and
then
any
node
that
comes
up
as
a
participant
in
the
cluster
that
the
cluster
network
operator,
the
cno
is
going
to
create
a
public
private
key
pair
for
those
nodes.
It's
then
going
to
send
that
public
key
around
the
loop
to
all.
The
other
note.
Excuse
me
to
the
to
the
cno
for
signing.
B
First,
it's
then,
after
it
signs
that
public
key.
It's
going
to
send
it
back
to
the
original
node
for
distribution
to
all
the
other
nodes
that
are
active
participants
in
ipsec
nice.
B
So
that's
kind
of
the
quick
and
skinny
and
then,
of
course,
when
a
new
node
joins
the
cluster
they're
going
to
get
they're
going
to
go
through
that
same
process.
So
the
cluster
network
operator
is
going
to
pick
up
on
that
and
it's
going
to
implement
that
same
cert
sharing
and
creation.
B
So
ipsec
is
enabled
again
when,
whenever
you
update
that
cluster
network
operator
during
installation
and
finally
oh
yeah,
one
thing-
I
didn't
mention
that
ipsec
config
line
in
bold
red
there,
the
braces
there
that's
actually
today,
there's
there's
really
nothing
to
be
specified
in
there,
but
quote
unquote
tomorrow,
future
enhancements.
B
We
want
to
be
able
to
give
you
additional
configuration
items
like
say,
for
example,
maybe
you
want
to
specify
a
different
crypto
algorithm,
maybe
that
aes
gcm
is
insufficient
or
maybe
that
gets
broken
somehow.
So
we
have
the
ability
to
change
that
in
the
future
and
then
there's
other
configurations
that
we've
we've
discussed
adding
in
there
and
we're
open
to
suggestions,
of
course
from
customers,
and
I
think
that
basically
is
ipsec
in
a
nutshell.
B
A
So
there's
a
couple
questions,
but
I
just
want
to
make
a
point
that
it
appears
our
restream
bot
that
aggregates
chat
between
all
the
channels
is
just
spamming.
The
channel
right
now
so
please,
you
know
if,
if
you
have
a
question
type
it
in
I'll
try
to
get
to
it
and
it'll
probably
be
repeated
several
times
so
sorry
so
yeah.
The
the
one
question
we
got,
which
I
think
is
interesting.
Someone
requested
well
what
about
wire
guard,
which
is
also
built
into
the
kernel
right.
B
Yeah,
so
wireguard
is
super
interesting
to
me
and
others
in
red
hat
and
wireguard.
The
only
problem
is
is
that
ipsec
is
the
choice
for
rel
8x.
We
are
heavily
considering
wireguard
for
rel
nine.
A
B
And
it's
at
that
point
that
we
will
make
a
decision
but
but
know
that
we
do.
We
have
had
customer
interest
about
wireguard.
It
is
very,
very
interesting
and
but
it's
it's
just
not.
It's
not
feasible
for
rail.
Eight.
A
Yeah
no-
and
I
I
figured
you
know
since
I
just
entered
the
kernel
like
within
the
past
six
months-
it'd
be
a
little
a
little
bit
of
a
longer
tail
on
that,
because
just
because
something's
in
the
kernel
doesn't
mean
we
can
automatically
flip
it
on
right.
Like
there's,
there's
a
reason
you
buy
red
hat
products
and
that's
not
because
it's
you
know
able
to
like
snap
in
the
bleeding
edge
stuff
immediately
right,
there's
some
stability
that
we
want
to
get
out
of
wire
guard
before
we
can.
B
Yep,
so
it's,
it
is
definitely
something
that
we're
we're
gonna
heavily
discuss
for
future
inclusion,
but
it's
a
tough
one
for
rally
right
now.
A
Yeah
as
so
there's
another
general
question,
I'm
scrolling
back
because
three
streambot
is
being
extra
special.
So,
let's
see
there's
a
backboard
of
wire
guard
for
rail
8
colonel
already,
though
interesting
question,
maybe.
B
B
On
that
side,
we
we
have
our
conversations
and
we
certainly
have
our
our
recommendations
to
them
and
and
our
use
cases
that
we
present,
but
ultimately
it
has
to
be
available
and
fully
supported
in
rel
if
it's
ever
going
to
show
up
in
open
shift
right
because
we
are
based
upon
all
of
our
nodes
are
built
upon
rel
core
os
which
is
derived
from
relay.
B
So
if
it's
not
a
rail
8,
that's
a
tough
one
for
us
to
it's
like
pushing
on
a
rope.
It's
a
little
tough
for
us
to.
A
B
That
is
a
very
good
question.
I
you
know
I
I
don't
know
that
we've
actually
tested
that.
Yet
I
don't
see
any
reason
why
it
would
not,
because
windows
nodes
basically
are
built
on
an
ovn
connector.
B
I
don't
you
know
just
thinking
through
the
design.
Nothing
strikes
me
as
a
obvious
blocker
for
that
to
work,
but
I
also
do
not
believe
we've
fully
tested
that
that,
but
that's
a
very
good
question.
A
A
Thing:
conan
kudo,
it's
like
either
or
right
right
now,
ipsec
is
baked
into
rel
eight.
We
need
to
get
wireguard
baked
into
rel
nine
as
well
so
yeah
there's
it's
it's
coming
feature
again.
I
apologize
for
all
the
spam
and
me
trying
to
sift
fluid
sift
through
it,
making
sure
we
get
everything
covered.
A
Ip
said,
okay,
so
here's
a
good
one.
You
mentioned
that
there
was
very
little
overhead
right.
I
think
at
first,
partly
because
of
you
kernel
and
user
context.
Switching
does
is
that
a
problem
here
or
is
it
because
it's
node
to
node?
It's
not.
B
So
so,
actually
yeah,
it's
the
the
libra
swan
is
user.
Space
ipsec,
of
course,
through
xfrm,
is
kernel
space.
So
there
is
that
element
of
context,
switching
but
the
the
real
that
that's
not
where
the
overhead
really
is.
The
real.
The
overhead
is
in
the
actual
encryption
scheme
itself
and
for
a
reasonably
strong,
fips
compliant
encryption
scheme.
There's
just
a
hit
you're
going
to
take
when
you
perform
those
calculations,
it's
just
a
natural
part
of
any
encryption
scheme.
B
You
know
I
hate
to
quote
a
hard
number,
but
I
think
it's
reasonable
to
say
it's
probably
somewhere
in
the
neighborhood
of
ten
percent.
For
most
people,
it
depends
totally
depends
on
the
packet
size
right
if
you're
using
huge
packets
versus
smaller
packets.
That
number
is
going
to
be
different,
but
probably
not
vastly
different,
maybe
a
few
percent
difference,
but
you
know
this
is
one
of
the
reasons
why
we
want
to.
You
know
we
wanted
to
to
build
this.
B
Have
that
have
that
ability
to
make
it
modular
and
loosely
associated
with
the
host,
because
we
want
to
be
able
to
pick
up
this
encryption
and
apply
it
on
some
of
the
future.
The
smart
knicks
we're
going
to
support
in
the
future,
so
some
of
these
have
purpose-built
hardware
who's.
You
know
designed
specifically
to
aid
in
the
performance
of
encryption,
and
so
you
know
the
smart.
You
know.
For
example,
you
know
some
of
the
bluefield
chipsets
that
are
coming
out
that
that
are
part
of
various
vendors
nics.
B
We
want
to
make
sure
that
we
have
that
as
an
option
for
customers,
so
as
that
those
nics
start
to
become
adopted
more
widely
in
by
our
customers,
that
if
they
make
that
investment
that
they're
actually
getting
return
on
the
investment
for
the
nick,
they
want
to
be
able
to
offload
some
of
these
things
like
encryption
to
them
to
reduce
the
workload
on
their
on
their
hosts,
and
I
suspect
that
10
hit
will
be
dramatically
reduced.
If
you
do
that.
A
A
The
whole
smart
nick
thing
is
just
fascinating
to
me
right
like
we're,
starting
to
get
compute
on
different
layers
of
the
stack,
and
it's
just
like
my
my
affinity
for
arm,
and
you
know
just
small
footprints
of
compute
kind
of
all
over
a
single
server
or
blade
or
whatever
you're,
using
right
like
vm,
whatever
it
is
or
like
that,
I
think,
is
the
most
fascinating
parts
of
the
future.
We're
looking
at
right
now
as
a
as
technologists
so
yeah.
Those
smart.
A
B
To
fruition,
yeah,
yeah
and
yeah
speaking
of
smartnex,
you
know
there's
another.
You
know
road
mapped
item
we're
doing
too,
which
is
offloading
of
ovs
itself,
so
networking
in
general.
You
know
we
want
to
have
the
ability
to
offload
it
to
to
a
special
purpose-built
hardware
designed
specifically
to
improve
performance
and
so
obs
some
of
the
flow
calculations,
the
encryption.
These
are
all
very
natural.
Next
steps
in
improving
the
performance
of
ipsec.
A
Cool
and
then
there's
a
question
about
like
hey,
we're
trying
to
get
openshift
working
on
like
a
small
sys
like
a
like
iot
device,
raspberry,
pi
type
thing,
yeah
that'll
be
sometime
in
the
future.
We're
working
towards
that.
So
it's
you
know
trying
to
get
openshift
at
the
edge
is
a
pot
is
possible
now
getting
a
full
open
shift
cluster
running
on
raspberry
pi's.
B
Not
easily
yeah,
you
actually
can
you
can
there
are?
There
are
diy
kubernetes
solutions
that
run
on
on
pi's?
I'm
I'm
particularly.
You
know.
You
know
interested
in
that.
Some
of
that
myself.
I
look
around
my
desk
and
that
you
can't
see-
and
I
have.
B
For
having
that,
but
you
know
one
step
at
a
time,
and
you
know
we
are
really.
We
work
a
lot
with
upstream
community
to
enable
these
kinds
of
things.
But
but
of
course
you
know
we're
a
product,
not
a
project,
so
we
have
to
focus
on
on
the
really
big
enterprise
use
cases.
First,
yeah.
A
Exactly
but
there's
there's
work
on
the
the
small
iot
device
front
as
well
going
on.
A
So
mark
I
don't
want
to
take
any
more
of
your
time.
I
know
you
got
to
jump
to
another
meeting
if
you
want
to
break-
and
I
can
wrap
up
here,
that'd
be
fine
and
sounds
good.
Yeah.
A
B
Me
the
opportunity
to
talk
about
ipsec
and
if
anybody
has
any
questions,
I'm
happy
to
follow
up
with
them.
A
Yeah,
we'll
do
I'll
send
some
your
way.
If
there's
anything
appreciate
it
all
right
folks,
if
you
got
any
more
questions
fire
them
my
way,
I
can
definitely
get
them
answered
as
soon
as
possible.
Lots
of
enterprises
use
raspberry
pi
everywhere.
I
wow
that's
that's
awesome
and
both
crazy.
At
the
same
time,
I
feel
like
conan.
We
should
talk
more
about
that.
A
I
feel
like,
and
I
noticed
you're
in
the
discord
so
yeah
like
let's,
let's,
let's
have
a
cut:
let's
have
a
discussion
there,
and
maybe
we
can
get
some
more
ideas
around
what
you're
trying
to
do
and
how
we
can
get
there.
A
But
I
totally
agree
we
need
you,
know
lightweight
or
lighter
weight
footprints
for
open
shifts
on
certain
devices
for
sure
and
that
that
future
we
are
now
seeing
on
the
horizon.
That
future
is
very
much
in
in
the
coming.
So,
as
mark
said,
we've
got
to
address
the
larger
use
cases.
First,
right
like
whole
data
centers,
and
things
like
that.
But
getting
folks
out
to
that
edge
with
openshift
is
a
goal
of
ours.
So
yeah,
let's
work
on
that
and
I'll
leave
it
at
that.
A
This
has
been
the
ask:
the
product
manager,
office
hours,
we've
been
talking
about
ipsec
and
if
you
have
any
other
questions,
feel
free
to
reach
out
to
me
on
twitter
at
chrisshort,
or
you
can
check
our
discord,
which
I'll
drop
a
link
to
now,
and
if
you
can't
join
discord,
you
can
always
email
me
at
seashort
redhat.com.
A
So
thank
you
very
much
and
I
will
see
y'all
at
noon
for
an
openshift
commons
briefing
talking
about
centralized
policy
and
governance.
So
that'll
be
interesting
to
think
about
governance
and
policy
within
your
organization
and
how
to
do
it
with
openshift,
so
we'll
catch.
You
then
noon.
Eastern
1700
utc
have
a
good
one.
Everybody
have
a
great
monday
and
have
a
great
week
stay
safe
out.