►
From YouTube: OpenShift Commons Briefing #53: CI/CD with OpenShift and Diamanti Converged Infrastructure
Description
Topic: Continuous Integration with Openshift and Diamanti Converged Infrastructure
Speakers: Chakri Nelluri, Mark Balch from Diamanti
Diamanti solves the most challenging networking and storage requirements that organizations face when moving containerized workloads from development into production, especially when operational speed matters. While there are many ways to build and deploy applications, Continuous Integration / Continuous Delivery (CI/CD) is the clear path forward.
Diamanti’s converged infrastructure is purpose-built to serve developers and provides deep integration with Red Hat OpenShift Container Platform. The Red Hat-Diamanti combined solution supports containerized applications with rapid development-to-production rollouts and guaranteed high performance networking and storage resources.
A
A
B
Thank
you
so
much
Diane
good
morning.
Everyone
thanks
for
joining
our
webinar
ci
CD,
with
OpenShift
and
diamonte
container
converge
infrastructure.
This
webinar
is
being
recorded.
A
link
to
the
recording
will
be
sent
to
everyone
who
registered
today
so
stay
tuned
for
the
posting
in
a
few
days
following
today's
demo
of
OpenShift
and
diamonte
container
converge
infrastructure
will
discuss
the
kubernetes
open
source
project
and
take
questions
from
the
audience.
B
B
So
what
we're
going
to
be
talking
about
today
is
we're
going
to
just
do
a
quick
review
of
some
of
the
CI
CD
challenges
for
IT
and
infrastructure.
Chakri
is
going
to
take
us
through
a
demo
of
CI
CD
with
openshift
and
diamonte
container
converge
infrastructure.
Then
we're
gonna
have
a
quick
expert
insight
chat
about
the
kubernetes
extensions
for
networking
and
storage
and
then
we'll
open
it
up
for
audience.
Q&Amp;A.
B
This
is
a
really
nice
slide
or
diagram
that
came
out
of
the
open
shifts.
Blog
businesses
are
demanding
modern
applications
and
workflows
to
deliver
new
digital
services
faster
than
ever
container
technology
is
becoming
the
norm
for
delivering
these
services
heavily
disrupting
development
and
IT
operations.
Organizations,
while
containers
enable
faster
application
development
cycles.
It
ops
is
slowed
by
today's
virtualized
model,
with
multiple
layers
of
infrastructure,
rigid
complexity
and
high
costs.
B
It
ops
requires
a
robust,
proactive
approach
for
containers
that
aligns
development,
velocity
operational
service
levels
and
budgets,
so
CIC
D
touches
all
layers
of
IT
and
infrastructure
and
there's
a
tension
between
the
faster
development
cycle
and
existing
infrastructure
and
overhead.
So,
as
you
go
between
all
the
different
stages
in
the
application
lifecycle,
how
do
you
maintain
the
dependencies
between
those
and
that's
from
a
whole
application
perspective,
not
just
the
top
tier
of
the
application,
but
things
like
the
databases
and
the
backend
infrastructure.
B
B
Diamonte
is
the
first
appliance
purpose-built
for
containers,
we're
a
hyper-converged
infrastructure
that
brings
the
ease
of
traditional
hyperconvergence
with
the
unparalleled
efficiency
and
performance
of
bare
metal
containers.
The
first
thing
we
do
is
that
we
allow
you
to
accelerate
application
time
to
market
to
seconds.
We
do
this
by
automating
the
network
and
storage
configuration
and
management
plugging
directly
into
the
kubernetes
stack.
B
We
provide
guaranteed
real
time
service
levels.
We
do
this
by
isolating
the
compute
network
and
storage
resources
for
each
container,
so
that
we
can
provide
guaranteed
throughput
for
each
portion
of
the
application.
So,
when
you're
deploying
your
application,
there
is
no
concern
about
whether
there's
going
to
be
some
sort
of
a
conflict
or
a
noisy
neighbor
with
other
containers
running
in
the
same
cluster.
And
then
all
this
enables
you
to
consolidate
as
well.
We
can
routinely
run
at
90%
utilization
and
we
use
existing
network
infrastructure.
B
So
let
me
talk
a
little
bit
about
how
this
works
before
I
transition,
two
chakras
demo,
diamonte
automates,
the
deployment
of
openshift
apps
with
guaranteed
service
levels.
So
the
first
thing
we
do
is
that
we
allow
you
to
use
your
existing
openshift
and
kubernetes
applications
and
literally
what
that
means
is
that
you
can
import
your
existing
apps
and
containers.
The
only
thing
we
ask
you
to
do
is
to
tell
us
the
service
level.
Are
you
looking
for
high
performance?
Are
you
looking
for
best
effort?
What
do
you?
What
do
you
need?
B
We
just
need
to
know
what
the
applications
performance
requirements
are.
At
that
point,
you
can
define
your
network
and
storage
requirements
purely
through
software
and
through
open
source
interfaces
and
we'll
show
you
exactly
how
that
works.
At
that
point,
you
use
your
standard
openshift
in
kubernetes
environment,
to
deploy
the
application
we
automatically
plug
into
the
back
end
by
virtue
of
the
upstream
contributions
that
we've
made,
and
we
automatically
configure
the
network
and
storage
as
the
application
and
the
containers
get
deployed.
But
beyond
doing
that
initial
setup,
we
are
real
time
guaranteeing
service
levels.
B
We
then
put
on
top
of
those
network
and
storage
resources,
a
virtualization
layer,
but
this
virtualization
layer
is
at
the
PCI
bus
level.
It's
not
a
software
overlay,
but
it
actually
sits
physically
on
the
PCI
bus
in
a
controller
and
provides
each
container
with
its
own
dedicated
virtual
network
interfaces
and
virtual
storage
volumes.
So
the
container
sees
what
looked
like
to
be
bare
mental
resources
and
are
directly
accessible
and
mapped
into
each
containers.
Namespace.
We
then
round
out
the
appliance
with
performance
cues.
B
Each
of
the
network
and
storage
resources
for
each
container
is
supported
by
queues
that
are
unique
to
that
container,
though
diamonte
can
sit
in
the
data
path
in
real
time
and
prioritize
workloads
to
make
sure
that
everyone
gets
the
guarantees
that
they've
requested.
So
you
will
never
have
a
noisy
neighbor
problem.
You
will
never
have
someone
else
taking
the
throughput
that
you
expected
to
have
for
your
application.
B
B
All
of
this
is
connected
using
standard
10,
gig
Ethernet
networking
in
your
existing
data
center
environment.
There
is
no
forklift.
There
is
no
complex
network
topology
to
set
up
all
of
the
resources,
then
to
compute
the
network.
The
storage
resources
are
all
pooled
together
and
shared
across
the
cluster,
so
there's
workload
mobility,
a
persistent
volume
can
can
be
accessed
from
no
10,
then
no
then
to
node
15
whatever
you
may
want.
B
C
Hi
guys
good
morning,
then
one
time
I
made
the
demo
God's
Way
with
me.
So
why
do
I
have
old
here?
Yes,
I
have
a
two
node
diamonte
cluster
and
you
can
see
them
there
named
web,
not
one
and
maybe
not
two,
and
we
have
like
a
bunch
of
32
cores
available
in
each
of
these
systems,
and
we
have
64
gig
of
memory.
I
had
a
bunch
of
storage
and
I
ops
is
the
throughput
which
you
can
expect
from
your
hardware,
and
we
have
a
bunch
of
network
virtualized
network
network
switch.
C
We
can
network
adapters,
which
you
can
do
to
the
containers
and
we
have
a
bandwidth.
We
have
two
links
up
for
each
of
our
balls.
It
is
about
20
gig
and
you
have
a
bunch
of
storage
controllers,
which
is
again
the
virtualized
storage
controllers.
We
give
it
to
the
workloads
so
I'm
going
to
focus
more
over
here
on
the
right
cuts.
Openshift
can
do
it
amazing
and
cool,
see
a
CD
stuff
I'm
going
to
focus
more
on.
How
do
we
plumb
to
the
workmanship
layer
in
the
backside,
to
put
it
all
together?
C
C
The
first
thing:
what
we
do
is
we
define
our
own
network.
So
this
is
a
layer,
2
network
which
we
integrate
with
the
open
shape.
What
this
provides
is
kind
of
gives
you
an
ability
to
specify
a
separate
IP
address,
region
of
and
every
container.
So
when
you
spin
up
a
container,
the
container
will
pick
one
of
the
IP
addresses
from
theirs
and
the
old
way
of
traditional
way
of
doing
things
like
your
container
will
get
a
separate
IP
address
similar
to
your
host.
C
So
we
are
creating
a
network.
What
we
are
defining
over
here
is:
we
want
the
network
to
me
from
a
subnet,
172,
16,
20
hundred
and
I
want
to
use
a
small
range
from
the
subnet,
because
not
everybody
is
blessed
enough
to
get
a
computer
inch
of
the
subnet
all
the
time.
So
here
we
are
using
the
network
from
102
to
54,
ok
and
we
are
using
a
particular
VLAN
for
that
network.
C
C
I'm
going
to
create
one
more
volume
called
test
one
over
here,
we
created,
which
is
of
a
size
10
cake.
So
what
this
does
is
this
course
in
the
back.
End
comes
out
a
separate
volume
out
of
our
storage,
which
we
listed
in
the
cluster
status
over
here.
Ok,
and
it's
going
to
make
it
available
for
use
by
the
obesity
openshift
deployments
like
pores
and
replication
controllers,.
C
So
the
next
thing
is,
we
have
a
queue
as
templates,
which
you
also
call
the
puff
tears.
So
these
are
the
ones
which
actually,
in
queue,
the
up,
define
the
applications,
ability
to
request
the
performance
T
of
they're
interested
in
so
here
you
can
see
that
we
have
a
medium
best
effort
and
high-performance
tears.
So
what
this
means
is
that,
whenever
your
application
wants,
it's
always
guaranteed
these
resources
by
the
backend
hardware.
C
C
C
C
C
So
I
have
about
here
is
sample,
spared
I,
don't
want
to
go
through
this.
This
is
like
a
big
immense
file,
so,
but
what
he
does
is
it
goes
and
creates
a
bunch
of
koshkas
containers
and
it's
going
to
create
if
you're
familiar
with
coupon.
It
is
possible
services
so
that
that
is
the
endpoint
which
you
can
use
to
communicate
with
Postgres.
C
Before,
as
I
said
earlier,
we
have
like
it
high-low
and
best
of
high
medium
and
best
afford
performance
scales
already
defined.
So
now,
I'm
going
to
title
through
the
new
projects
in
hope
and
share,
or
here
we
will
define
the
new
project
called
board,
and
then
we
are
gonna
scale,
they're
going
to
create
four
of
them
using
the
new
project
goal.
You
can
see
over
here
I'm
creating
a
bunch
of
hospice
containers.
C
Initially
you
for
creating
the
container.
We
created
a
poster
and
volume
for
it,
and
then
we
created
a.
We
claim
that
volume
using
your
claim
and
then
we
created
a
bar
which
uses
the
volume.
So
we
kind
of
actually
defined
a
storage
in
our
lair
and
we
claimed
the
storage
and
we
are
asking
them
and
we
are
making
sure
the
post
space
is
actually
using.
The
storage.
C
So
we
defined
four
of
our
good
parts
over
here
for
hospice
containers
and
they
bonus
show
the
difference
in
the
actual
performance
they
get
from
our
back-end,
because
we
kind
of
guarantee
the
for
comment
for
these
different
classes
of
projects.
So
if
the
user
wants
to
have
their
own
high
priority
workloads,
they
can
use
these
performance
tiers
to
define
their
workloads.
C
C
The
four
volumes
actually
in
the
back
end
up
using
the
flex
volume
framework
which
we
added
to
the
kubernetes
and
then
the
kubernetes
claims,
which
is
a
traditional
way
of
doing
or
claiming
your
volume
in
open
areas
or
open
shape,
actually
binds
those
volumes
into
the
governor's
infrastructure
and
the
pods
now
I'm,
going
to
create
another
project:
silver.
Okay.
This
is
going
to
use
on
William
Q
as
clear
or
for
clear
again,
I'm
gonna
define
four
more
phosphorus
containers.
C
C
So
we
have
four
more
endpoints
for
the
post
based
containers
using
which
we
can
communicate
with
the
post
fence
parts,
and
you
can
see
the
decay
at
four
more
volumes
and
the
plane.
The
claims
claim
those
volumes,
and
now
we
are
going
to
create
another
project
branch
and
we're
going
to
create
four
more
of
them.
Now
this
is
going
to
use
the
best
of
our
queue
s-class,
so
the
best
effort
is
kind
of
like
a
typically
used
for
batch
jobs.
C
So
let's
say
that
if
you
want
your
applications
to
be
running
only
when
nobody
else
is
running,
so
that's
typically
when
use
and
abusing
the
best
effort.
So
the
idea
behind
this
is
what
de
Monte
provides
a
unique
value
to
the
infrastructure
is
actually
we
make
the
network
at
story
scale
elastic.
What
this
means
is
that,
if
I
have
a
best
of
two
want
to
run
your
bad
jobs,
you
can
keep
on
running
them
and
as
long
as
your
application
requires
the
resources,
it
will
get
it.
C
But
if
the
application
is
ideal
and
not
using
your
resources,
your
best
upon
jobs
or
the
branch
jobs
can
go
ahead
and
use
the
resources.
There
is
no
capping.
We
don't
inherently
do
any
capping,
so
we
kind
of
try
to
make
the
resources
elastic
so
that
you
can
always
extract
the
each
extract.
The
use
of
your
balls
for
all
you,
bad
jobs,.
C
C
You
know
we
can
see
that
we
have
portals
in
16,
hostess
containers
running
or
here
and
then
when
we
run
the
workload
against
them,
we
will
see
that,
like
they
get
the
performance
based
upon
their
performance
based
upon
the
performance
and
tears,
you
can
see
it
in
here.
The
OpenShift
console
refresh
you
see
those
projects
over
here
you
can
see
the
silver
over
here.
You
can
see
the
board
over
here.
You
can
see
the
tests
over
here
and
the
bronze
one,
maybe
hiding
in
the
top
the
going
over
here.
C
C
C
So
this
is
our
dashboard.
We
already
started
to
work
in
the
backend.
So
now
you
can
see
that
we
have
on
the
four
parts
which
are
using
the
high-performance
tier
they're
getting
around
like
a
fiscally
I,
ops,
okay
and
the
ones
which
are
using
the
medium
performance
tier,
the
lingering
in
the
middle
and
the
ones
which
are
the
low
and
the
best
efforts
they're
lingering
in
the
bottom.
C
So
what
this
means
is
that
if
you
have
high
performance
workloads,
you
can
define
a
high
performance
here
for
your
workload
and
they
are
guaranteed
to
get
the
eye
of
sister
requested
fir
and
if
you
have
any
of
the
workloads
which
are
running
the
robe
or
like
a
it's
trying
to
step
over
the
high
performance
parts,
they've,
never
bellowed,
and
we
do
it
all
all
of
this
stuff
using
the
performance
cues
in
your
hardware.
So
there
is
no
way
like
any
of
the
software
components
can
override
it.
B
B
He
would
be
really
interesting
to
get
your
perspective
on
how
how
the
the
kubernetes
project
has
evolved
over
the
past
year
year
and
a
half
to
become
more
flexible
for
network
and
storage,
so
I
think
the
first
thing
probably
it
starts
with
with
scheduling
figuring
out
where
to
put
workloads
across
the
cluster.
Can
you
talk
about
how
kubernetes,
extensible
and
extensible
scheduling
works?
Yes,.
C
Actually,
that's
one
of
those
nice
patience
to
the
existing
code,
governor
scheduler.
So
what
this
allows
you?
If
you
go
to
any
data
center,
they
have
their
own
unique
requirements.
When
you
want
to
share
you
know,
resources.
Some
people
may
have.
Okay,
rack
would
never
want
recovered
and
some
people
may
have
data
gravity,
and
some
people
may
have
some
other
unique
requirements
which
are
defined
by
the
enrollment.
What
this
loc
o
is
actually
LSU
right.
C
You
don't
plug
into
the
existing
scheduler
so
that
when
the
scheduler
decides
the
workload
deployment
of
the
workload,
you
can
actually
ask
you
for
the
hints
so
that
you
can
also
participate
in
the
decision-making
and
you
get
the
workload
deployment
in
the
actually
the
rag
or
in
the
system
you're.
Actually
looking
for
so
at
diamond.
What
we
did
is
we
actually
use
a
local
storage,
so
it
gives
a
little
by
using
this
extension.
C
What
we
do
is
we
actually
enable
data
gravity
so
that,
if
your
part
is
using
a
particular
volume,
you
don't
want
it
to
be
lying
somewhere
else
in
some
other
system.
So
you
want
it
to
be
running
on
the
same
node
they're.
Actually,
you
volume
it's
available,
so
we
try
to
like.
Okay,
we
try
to
hint
to
the
equipment,
is
scheduler
to
make
and
get
involved
in
the
decision
making
process.
C
So
all
the
workloads
in
most
of
the
dance
land
on
the
same
node,
where
they're,
actually
the
data
they're
durable
storage,
is
there's
also
used
for
other
purposes.
Like
let's
say
we
have.
Our
own
network
demand
and
network
is
limited.
We
have
a
20
give
of
the
network
and
let's
say
if
one
of
the
nodes
I'm
completely
used
up
my
CPU,
but
my
network
is
available.
If
I
want
to
my
so
my
storage
through
the
network
I
can
put
my
wall
or
somewhere
else
and
then
using
or
remote
storage.
You
need
remonstrance
protocol.
C
B
Answer
the
the
scheduler
extension
API
that
was
upstream
as
part
of
1.3
was
it
yes,
because
part
of
1.2
coubertin
is
monitor,
yeah
right,
and
so
then
we
we've
implemented
a
scheduler
plug-in
based
on
that
API,
yes,
and
and
other
people
could
do
the
same
thing,
it's
sustained
our
open
source.
Api,
yes,
got
it,
ok,
cool!
Second
one
I
wanted
to
get
your
views
on
flex
volume.
C
When
we
start
initially
looking
at
writing
the
one
pulling
into
the
kubernetes,
we're
actually
kind
of
like
covenants,
has
a
nice
collection
of
plugins
part
that
since
woody
was
always
tied
to
the
pub
and
is
recycled,
that's
one
of
the
primary
problems
we
had
and
if
you
want
to
have
our
own
like
we
are
a
startup
and
we're
continuously
innovating
or
future
lists,
and
we
need
want
to
get
time
with
the
kubernetes
recycle
so
that
we
can
enable
our
users
with
of
new
features
faster.
So
that
was
the
rationale
behind
you.
C
So
we
decided
that
we
will
be
a
flex
volume.
What
flex
volume
provides.
You
is
an
adapted
to
the
plugins
and
in
kind
of
extents
enables
you
provide
your
own
plugins.
Any
vendor
can
write
their
own
plugin
and
the
flex
volume
framework
will
call
your
plugin,
ok
and
everything
with
all
the
features.
What
you're
looking
for
you've
been
able
through
that?
So
it
gives
that
ability
which
none
of
the
plugins
inside
the
tree?
How
now
so
I've
seen
the
multiple
people
have
started
adopting
it?
C
So
the
amanda
was
the
one
who
pioneered
it
and
we
use
extensively
for
enabling
or
local
storage
and
also
the
data
gravity
and
all
that
other
cool
features
we
have
so
and
I've
seen.
Other
folks
is
again
like
the
bunch
of
vendors.
We
go
through
the
Flex
volume,
the
PRS
github.
You
will
see
that
there
are
a
lot
of
interest
in
it
and
we
are
actually
making
it
more
extensible
in
the
one
or
six
timeframe.
So
look
forward
for
more
support
in
the
Flex
volume
area.
B
Got
it
right
and
I
think
also,
even
whether,
whether
it's
a
small
company
or
or
a
big
company,
or
a
different
open-source
project,
the
ability
to
update
the
the
different
capabilities
for
flex
volume
without
having
to
read
the
entire
kubernetes
codebase
and
then
do
a
release.
I
think
that's
a
real
operational
benefit
because
you
can
take
updates
and
quickly
consume
capabilities
without
having
to
kind
of
do
the
fork
with
upgrade
of
the
entire
system.
Yes,
yes,
yeah,
excellent,
hey
one!
Less
thing
is
so
we
talked
about
scheduling,
talked
about
storage.
C
Cnn
is
actually
right
now,
I
think
kuru
is
was
the
one
who
actually
kind
of
pioneered
our
one
and
unproven.
It's
adopted
it
so,
and
we're
also
trying
to
use
the
same
and
then
come
back,
and
what
this
that
gives
us
that
gives
us
the
ability
to
pump
our
actually
the
hardware,
the
performance
which
we
talked
about
earlier
into
the
container.
So
and
we
are
the
only
guy
I
think
out
there
who
can
actually
view
a
10
gig
networking
directly
to
the
continuous
we
want
to
get
it
convenient
offer
your
container.
C
B
I
mean
the
way
I
think
about
it,
something
we
should
think
I
think
about
it
is
that
we
we
want
to
make
sure
that
openshift
and
kubernetes
users
have
kind
of
open
source,
plugins
and
api
is
that
they
can
use
to
basically
pick
their
best-of-breed
technology
choices.
Yes
for
infrastructure,
and
by
up
streaming
those
api's.
B
We
basically
create
a
living,
a
level
playing
field
where
everyone
can
use
the
same
api's
and
semantics,
there's
no
lock-in,
and
then
that
allows
us
and
others
to
be
able
to
take
our
network
and
storage
capabilities
that
are
at
our
hyper-converged
appliance
and
plug
it
directly
into
that
into
that
open
ship
kubernetes
step.
Yes,.
C
B
Well,
that's
great
hey!
So
for
anyone
who
wants
to
learn
more
detail,
love
you
to
reach
out
to
us
directly,
but
you
can
go
to
our
blog,
the
Montcalm,
slash
blog.
We
have
some
really
nice
blogs
that
that
shock,
read,
others
have
wrote
and
then
please
get
involved,
join
the
kubernetes
SIG's.
As
a
storage
sig
you
can
meet
chakra
there.
There's
a
network
sig,
there's
a
cluster
Federation
sig,
so
lots
of
good
things
going
on
and.
A
This
has
really
been.
You
know,
a
really
great
example
of
cross
community
collaboration
and
in
working
on
the
open
to
benefit
just
about
everybody
in
the
community
and
all
the
different
vendors
as
well
we're
trying
to
create
plugins.
So
it's
it's
wonderful
work
that
you're
doing
Chakri,
and
it's
much
much
appreciated
now,
I'm
wondering
if
there's
any
questions
online
and
and
yeah
I
ended
up
having
one
question
myself.
A
This
is
this
seems
to
be
a
great
solution
for
some
of
the
HPC
computing
requirements
that
I
keep
fielding
from
our
financial
stock
exchange
type
deployments,
and
this
I'm
wondering
if
you
you've
already
working
with
people
in
the
finance
sector
market.
You
know
how
this
is
working
out
in
comparison
with
other
solutions
that
are
out
there.
Yeah.
B
That's
a
great
questions,
again
Thanks.
So,
yes,
we
are
working
in
the
financial
services,
so
we
are.
We
are
deployed
in
financials
in
media,
in
communications
type
of
companies
as
examples
we've,
we've
talked
about
folks
like
NBC,
Universal,
mem
sequel,
specifically
around
financials.
There
there's,
obviously
a
large
volume
of
real-time
analytics
that
are
required.
Some
of
that
is
required
by
by
the
el
cajon
18
side
of
the
house.
B
Things
like
trading,
but
there's
also
a
lot
of
regulatory
overhead
that
financials
have
to
deal
with
since
in
the
last
few
years,
as
everyone
knows,
and
those
regulatory
requirements
continue
to
to
get
get
steeper.
So
basically
there's
something
called
risk
analysis
and
overtime.
The
financials
are
having
to
do
what's
called
intraday
risk
analysis,
which
means
that
beyond
just
checking
out
my
bank's
positions
at
the
close
of
trading
I
need
to
be
doing
that
throughout
the
day
and
those
requirements
are
getting
more
and
more
real
time,
as
as
things
go
by.
B
So
you
have
a
large
mountain
of
data
that
has
to
be
sifted
through
and
you
have
real-time
events
coming
in.
You
have
trades
and
positions
coming
in
on
a
real-time
basis.
Some
people
implement
that
as
part
of
a
real-time
data
pipeline.
There
are
lots
of
different
implementations,
but
they
all
have
in
common
that
they
need
to
be
able
to
quickly
scale.
They
need
to
deliver
performance
economically
and
containers
are
a
really
good
approach
to
that,
because
they
are
a
very
effective
vehicle
to
deliver.
B
Multi,
ten
and
high
throughput
applications
with
bare-metal
efficiency,
because
containers
can
give
you
direct
access
to
infrastructure
and
that's
something
that
we
that
we
specialize
in
so
we
are.
We
are
seeing
more
and
more
use
cases
of
things
like
database
services,
analytic
services,
real
time,
data
pipelines
in
financial
services
and
by
being
able
to
deploy
those
in
a
standard,
open
source
manner
where
we
can
provide
high
density
as
well
as
guaranteed,
throughput
and
processing
for
data
intensive
apps
and
that's
both
on
the
compute,
the
network
and
the
storage
size.
B
A
I
think
it's
actually
really
timely,
because
we
get
a
lot
of
that
around
you
know
is
kubernetes
ready
for
that
that
market
sector
and
I
think
you've
answered
it
in
yes,
and
he
amante's
is
something
make
that
a
reality.
So
that
may
be
a
good
one
of
those
deployments
might
be
a
good
topic
for
and
a
later
briefing
from
their
point
of
view
and
how
they're
using
it
in
deployment.
So
we'll
look
forward
to
the
pulling
within
that
use
case
and
exploring
that
a
little
bit
deeper.
A
B
A
Get
that
we
get
hang
on
for
that
a
lot,
especially
at
Red
Hat,
because
with
all
the
rail
and
Linux
and
cloud
stuff
that's
going
on
today.
That's
one
of
the
the
market
sectors
that
we
cover
off
with
open
shipping
and
being
able
to
bring
kubernetes.
So
that
is
really
a
game-changer
happy
to
do
that
with
you
guys
in
the
future,
I'm
looking
to
see
in
chat.
A
B
Definitely
does
so.
Basically,
we
are
all
standard
interfaces
and
the
the
the
questioner
may
know
that
openstax
has,
as
you
know,
very
close
integration
with
with
kubernetes
and
the
container
stack
by
a
magnum,
though
absolutely
we
are
able
to
work
in
that
environment.
I
mean
really
like
I
said
before
our
goal
is
through
the
through
the
contributions
that
chakra
in
the
team
have
made
around
scheduling,
network
and
storage
extensions.
B
The
goal
is
absolutely
to
be
able
to
have
a
standard
infrastructure
model
that
works,
regardless
of
you
know
what
what
type
of
application
you're
gonna
be
putting
on
whether
it's
OpenStack,
whether
whether
whether
it's
open
ship
on
OpenStack
right,
so
there
we
want
to
give
flexibility
to
our
users.
For
that.
A
That's
one
of
the
big
use
cases
for
open
ship
right
now
is
deploying
OpenShift
on
OpenStack,
and
everybody
is
over
at
the
OpenStack
summit
this
week
and
one
of
the
topics
we've
been
diving
into
and
in
the
past
briefing
was
about
deploying
a
thousand
nodes
of
open
shipped
on
OpenStack.
So
if
people
are
looking
for
examples
of
doing
that,
there's
some
great
blog
posts,
this
Google
a
thousand
nodes
of
open
shift
and
you'll
find
out
it's.
A
The
deployment
was
on
the
CNC
F
cluster,
and
so
we've
done
some
testing
on
open
ship
and
we're
just
about
to
do
some
benchmarking,
with
comparing
the
open
ship
deployment
to
bare
metal
on
the
same
CNC
a
cluster.
So
there's
some
interesting
work,
there's
some
great
work
that
Dell
has
done
around
an
opening
shift
on
OpenStack
reference
architecture,
so
making
it
all
work
together.
Seamlessly
the
human
acting
will
be
an
interesting,
interesting
use
case.
Yeah.
B
Thanks
so
you
know
one
thing
before
we:
we
close
that
I
wanted
to
make
sure
everyone
was
aware
of
diamantes
tried
before
by
offer,
which
is
a
limited
term
offer
for
qualified
users.
Basically,
we
can
help
get
your
application
on
to
kubernetes
and
open
shift
with
diamonte
container
converge
infrastructure,
and
let
you
observe
the
service
level
guarantees
in
your
own
site
for
30
days.
This
offer
is
available
to
users
who
have
an
immediate
production
need,
but
it's
for
a
limited
time
so
just
reach
out
to
us.
A
Well,
thank
you
very
much
mark
and
Jeffrey
Frick.
For
today's
briefing
we
look
forward
to
hearing
more
and
perhaps
presenting
a
couple
of
the
financial
use
cases
in
the
not-too-distant
future,
and
so
thanks
and
this
vlog
this
would
be
blogged
and
the
video
link
will
be
in
the
blog
early
next
week
and
we'll
send
it
out
again
to
all
the
folks
who
are
participants.
But
thank
you
very
much
for
today
and
we'll
look
forward
to
hearing
more
in
the
future.
Thank.