►
From YouTube: OpenShift Commons Briefing #109: ElasticSQL on OpenShift
Description
NuoDB is an elastic SQL database for cloud- and container-based environments. NuoDB’s architecture is designed to natively deliver:
* Scale-out by adding more computers and accommodate gracefully when machines are yanked out
* Never needs to be shut down
* Hardware and software fault tolerant
* Multi-site operation for business continuity
* Automatic load balancing
With NuoDB, you can adjust database size and performance on demand – even across data centers or clouds – without sacrificing data integrity, transactional consistency, or the standards-based SQL interface your developers already know.
In this briefing, NuoDb’s Christina Wong and Joe Leslie walk us through standing up your own OpenShift Origin cluster on Centos and pull in NuoDB containers as part of the platform.
A
A
Hello,
everybody
and
welcome
to
another
open
ship
Commons
briefing.
Today
we
have
a
new
open
ship,
Commons
member
nuodb
who's,
going
to
give
us
an
overview
on
what
they're
doing
with
their
offering
and
talked
a
lot
about
elastic,
equal
and
open
shift,
and
how
to
do
all
that.
So
we've
got
a
couple
of
folks,
Collett
being
along
and
13
and
we'll
just
get
started.
So
thanks
Christina,
take
it
away
thanks.
B
Man
welcome
everybody
thanks
for
attending
with
me
and
I'm
its
briefing.
We're
really
excited
to
be
part
of
the
open
shift
common
community.
My
name
is
Kristina
Wong
I'm,
the
director
of
partnerships
and
product
marketing,
here
at
nuodb,
I'm
joined
by
Joe
Leslie,
our
senior
product
manager,
here
at
nuodb,
he's
going
to
be
giving
the
bulk
of
the
presentation.
However,
the
other
person
we
have
in
the
room
is
Ben
Higgins
and
he's
our
DevOps
engineer.
B
C
Thank
You,
Kristina
and
happy
Friday
to
everyone
and
yeah.
We
look
forward
to
presenting
nuodb
running
in
openshift
today.
So
a
good
chunk
of
our
presentation
is
going
to
be
a
live
demo,
but
we
are
going
to
run
through
some
initial
slides
just
to
introduce
you
to
new
ODB
and
who
we
are,
what
we're
all
about,
and
the
problems
we're
trying
to
solve,
feel
free
to
ask
questions
as
we
go
and
you
can
go
about
this.
You
know
interactively
and
have
a
nice
conversation.
C
So
yes,
that's
just
started
it's
basically
what
we
want
to
do:
introduce
no
DB
and
the
concept
of
the
elastic
sequel
database,
we'll
talk
through
a
little
more
detail
about
the
open
shift
and
container
integration
that
we've
built
and
and
then
we'll
go
right
into
demo
finish
with
some
QA
all
right.
So
let's
first
set
the
stage
a
little
bit
as
as
many
companies
today
are
seeking
to
to
move
to
the
cloud
already
in
the
cloud.
There
are
certain
challenges
and
nuodb.
C
C
We
want
to
ensure
that
we
can
run
our
applications
on
commodity
hardware
in
the
cloud,
but
it's
really
important
that
the
applications
have
this
scale
out
and
scale
in
right
want
to
be
able
to
extend
our
applications.
You
know,
deliver
more
transactional
throughput
when
needed,
but
at
the
same
time
also
scale
back
if
needed
and
all
the
while.
We
want
to
make
sure
that
our
applications
today
are
continuously
available.
Even
the
concept
of
high
availability
is
something
that's
not
quite
high
enough.
C
These
days
and
many
of
our
our
customers
come
to
us
seeking
zero
downtime
and
continuous
availability.
So,
in
order
to
achieve
all
these
in
the
world
of
sequel,
databases
is
there's
often
you
you
have
to
give
things
up
and
and
the
the
problem
that
we've
solved
at
nuodb
is
we've
been
able
to
deliver
a
a
true
sequel
database
that
is
anti
compliant
and
an
acid
transaction
property
consistent
in
an
environment
like
this.
So
you
can
leverage
your
existing
sequel
applications.
C
You
can
leverage
your
investment
in
the
people
that
you
have
and
the
skills
that
they
have
and
and
continue
to
run,
basically
in
a
sequel
database
environment
which
traditionally
ran
it
runs
well
in
a
scale-up
environment
right
we
just
we
can
add
more
memory,
more
CPU
and
more
storage,
but
very
difficult
to
provide
a
database
that
can
run
in
a
domain
of
hardware
where
that
hardware
exists
in
you
know,
across
geographical
regions
and
all
the
while
presenting
a
single
database.
So
that's
what
nuodb
has
accomplished
and
provides
as
a
product.
C
So
we,
if
we
continue
when
we
look
into
a
little
more
detail.
This
next
slide
shows
some
of
the
common
solutions
and
what
the
approaches
have
been
either
a
share
disk
solution,
which
you
know
these
can
be
very,
very
complex
and
an
expensive,
or
we
consider
clustering,
software
and
and
and
sharing
the
disks
and
here's
a
couple
of
examples
here:
the
Oracle,
RAC
and
db2
pure
scale,
but
there's
also
this
shared-nothing
or
sharding
approach,
and
these
also
have
their
challenges
requiring
applications
to
have
more
knowledge
about
where
to
get
the
data.
C
So,
while
there's
these
solutions
out
there,
none
are
truly
meeting
the
desired
requirements,
so
introduce
the
elastic
sequel
database
so
nuodb
and
effectively
what
we've
done
and
it's
here
in
this
architectural
diagram.
We
see
a
legacy
architecture,
which
is
you
know
much
like
I,
described
earlier,
sort
of
a
stack
of
processes
running
in
a
single
architecture
where
you
have
your
query:
processing
in
your
storage
in
a
single
server.
C
What
the
new
of
BiBi
architecture
is
done
is
it
takes
this
and
it
breaks
it
into
the
two
critical
components:
the
the
transactional
component
and
the
Storage
Manager
component.
So
these
transactional
components
are
pictured
in
green
and
we
call
these
transaction
engines
or
te
and
they're
responsible
for
servicing
the
application,
connection,
requests
and
sequel
requests,
and
it
is
a
an
in-memory
version
of
the
database
or
it
runs
a
durable
cache,
so
newbies
delivering
high-performance
sequel
transaction
and
when
the
application
runs.
For
example,
a
DML
statement
like
an
insert,
update
or
delete
needs
to
make
changes.
C
C
Scalable
in
that
you
can
create
redundancy.
So
should
you
lose
a
transaction
engine
or
lose
a
storage
manager?
It's
okay,
because
you
have
another
one
running
and
that's
that's
part
of
the
the
architecture
that
in
that
delivers
the
the
zero
downtime
capability.
So
these
storage
managers
as
well
these
as
I
mentioned
this-
is
the
durable
part.
So
this
is
the
D
and
acid
the
durable
portion
of
the
transaction.
So
once
that
transaction
is
committed
to
DES,
should
there
be
a
failure?
You
can
always
reliably
go
back
and
and
retrieve
that
data.
C
So
so
you
know
this
is
a
very
you
know,
very,
very
flexible
architecture,
and
it
deploys
nicely
across
datacenters
and
works
very
well
in
a
cloud
environment,
a
microservices
type
environment
where
you,
your
your.
The
database
is
comprised
of
processes
that
you
can
then
spread
across
a
domain
of
hardware
geographically,
ok,
so
here's
just
another
slide
that
diagrams
an
employment
climb
an
example
of
an
active-active,
true
master
master
model.
Where
we
have
a
multi-day
data
center
deployment.
We
can
see.
C
We
have
two
availability
zones
and
our
applications
are
being
serviced
in
both
zones,
and
we
have
you
know
some
number
of
transaction
engines
that
we're
providing
in
each
availability
zone
for
local,
quick
connectivity
to
the
database
and
then
you'll
notice.
They
have
each
has
a
copy
of
the
database.
The
Storage
Manager
present
an
on
disc
op
II
of
the
database
and
nuodb
also
allows
for
larger
implementations
to
effectively
fill
these
storage
managers
over
to
other
one.
So
you
can
have
a
single
large
data
set
Fanning
across
a
storage
manager.
C
C
C
This
is
where
we
get
this
elastic
concept
and
the
deployment
flexibility
we
talked
about
as
far
as
deploying
either
on
pram
or
in
the
cloud
and
a
hybrid
environment.
Nuodb
is
is
quite
happy
to
work
in
all
of
those
environments
and
across
those
environments.
At
the
same
time,
all
the
while
not
giving
up
the
sequel
semantics
that
so
many
of
our
applications
require
right.
C
Okay,
so
now
we're
just
going
to
look
at
some
of
the
details
about
our
openshift
integration
environment.
So
here's
a
diagram
that
shows
us
an
open
shift
environment,
sort
of
stack
diagram
showing
us
our
routing
life
layers
and
our
persistent
storage
layers
and
the
different
service
layers
that
lead
to
our
physical
and
virtual
private
and
public
environments.
C
We
see
that
you
know
we
have
the
master
section
with
with
the
application
authentication.
The
data
store
services,
scheduling
services,
all
of
the
pieces
that
are
there
part
of
the
Red
Hat
Enterprise
Linux
platform,
and
then
we
also
see
the
nodes
and
how
we
have
created
a
resilient
environment
where
we
we
run
the
the
application
and
the
nuodb
transactional
and
Storage
Manager
components
in
different
nodes
or
pods.
So
we
have
the
resiliency
and
and
that
redundant
environment
such
that.
Should
there
be
a
failure,
the
system
will
continue
to
process,
connections
and
sequel
requests.
C
You
know
smaller
databases
per
service
where
nuodb
services,
those
applications
and
then
through
a
query
set
of
Federation.
You
can
then
retrieve
the
data
across
those
different
applications
to
likewise.
If
you
would
like
to
then
roll
that
data
up
into
a
more
aggregated
view,
is
quite
simple,
then
to
to
do
that
and
and
effectively
create
a
single,
larger
logical
database
view
for
reporting
and
analytics.
So
no
DB
provides
that
flexibility,
so
you
can
have
dedicated
te
in
SM
to
the
individual
micro
services.
C
C
There's
a
little
more
details
of
the
different
pieces
that
are
involved
mention
the
open
shift,
OC
command.
This
is
you
know
how
we
can
self
deploy
and
manually
deploy
the
environment.
It's
you
know.
Basically,
you
have
your
choice
of
running
how
you
how
you
like
and
as
I
mentioned
early,
you
know,
kind
of
local
or
an
AWS
on
Prem
and
in
the
cloud
you
know
all
the
the
you
know
that
the
docker
run
environment.
C
Okay,
we're
going
to
get
to
see
all
this
in
action
today
in
our
our
presentations.
We
do
want
to
talk
a
little
bit,
though,
about
some
of
the
storage
and
how
this
is
working.
So
we've
got
and
federal
storage
to
storage
managers,
which
I
mentioned
earlier.
We
see
that
in
the
diagram
where
we
have
multiple
storage
managers
for
storage
redundancy
should
storage
manager
fail.
We
know
our
database
still
has
a
consistent
copy
available
for
our
applications.
C
The
persistent
storage
piece
uses
the
AWS.
You
know
ee
BS,
the
elastic
block
storage
and
for
the
Red
Hat
storage
solution.
The
CNS
storage
is
what
we're
using,
and
you
know
we're
we're
still
in
the
process
of
looking
at
other
storage
solutions.
We
want
to
make
sure
that
we
provide
all
the
storage
solutions
that
our
customers
are
seeking
to
use,
but
those
are
the
basic
ones
that
we're
offering
today.
C
The
the
last
point
is
an
important
one
just
so
we
understand
that
if
we
should
lose
a
container
that
the
new
container
that
comes
and
replaces
it
will
automatically
reattach
to
the
archives.
Therefore,
there's
no
need
to
resync
with
the
data
with
an
existing
full
copy.
Once
the
new
storage
manager
comes
into
play,
if
it's
already
in
a
full
working
copy
of
the
database.
C
C
This
is
something
we're
currently
working
on
work
in
progress,
but
we've
had
a
lot
of
requests
in
this
area,
and
this
is
a
really
exciting
piece
that
we're
looking
forward
to
deliver
that
the
system
will
auto-detect
effectively
when
to
balance
the
transactional
and
storage
manager,
components
of
the
system
of
basically
auto
scale
scaling
out
scaling
in
as
needed,
based
on
the
application
load
and
ensuring
a
certain
transactional.
You
know
transactions
per
second
and
ensuring
that
the
latency
remains
low.
C
B
C
C
Okay,
go
ahead
and
log
into
my
environment,
okay,
and
what
we
see
an
open
shift
is
we
have
a
new
ODB
deployment
and
let's
talk
about
some
of
the
pods
that
are
running
this
first
pod
is
called
the
admin
service.
This
is
a
very
important
piece
of
the
the
new
ODB
management
here.
It's
the
part
that
manages
the
domain
several
times
in
our
presentation.
Today,
we've
talked
about
a
domain
of
resources.
C
The
the
admin
is
responsible
for
managing
the
new
ODB
transaction
engines
and
storage
managers
on
the
host
that
it
it's
running.
So
within
its
process,
space
is
managing
that
the
nuodb
engine
processes.
It's
also
the
one
that's
responsible
for
load
balancing
as
the
connection
requests
come
in,
it
will
determine
a
te
that
meets
the
serve
serviceable
requirements
of
the
client,
for
example.
If
the
client
is
in
a
particular
region,
it
will
deliver
a
transaction
engine
in
that
region,
so
we
can
reduce
any
latency
while
connecting
to
the
database.
C
C
So
when
we
run
the
sequel's
and
various
things
will
be
running
from
from
this
environment
and
then
down
below
here,
we
see
the
actual
real
workings
of
the
new
ODB
system
that
the
two
components
we
talked
about
earlier-
that
the
transaction
engine
which
is
labeled
here,
as
in
a
te
and
a
Storage
Manager
that
piece
that's
responsible
for
the
durable
on
disk
copy
of
the
database
and
that's
pictured
here
so
so
far
we
can
see.
We've
got
a
very
basic
setup
right.
C
We've
just
got
one
pot
of
each
before
we
scale
out
this
environment,
we're
just
going
to
take
a
look
at
what
it.
The
system
looks
like
from
the
from
the
new
ODB
side,
we're
going
to
come
over
to
some
command
line,
prompt
and,
let's
take
a
look.
I'm
gonna
run
a
new
ODB
command.
It's
actually
the
one
that's
presented
on
your
screen
here
already,
but
let's
run
it
again
see
we
have
a
live
system
and
it's
showing
us
these
components
so
focusing
right
here
we
have
this
server.
C
Now
this
is
the
one
that
I
call
the
admin
service
and
we
see
that
it's,
it's
laughs,
its
liveliness.
It
just
checked
in
just
two
seconds
ago,
and
it's
state
is
active.
It's
the
leader
there
you
can
have
multiple
admin
services.
If
you
were
to
have
multiple
geographies
and
within
your
domain,
you
would
have
multiple
admin
services,
and
you
know
we
see
this
one
is
connected
here-
the
active
connected
and
running
our
demo.
Today
we
just
have
this
single
admin
service,
but
down
below.
We
also
have
a
demo
database.
It's
our
hockey
database.
C
C
C
Tire-
and
you
know
at
this
point
we'll
notice
that
it's
connecting
to
IP
address
104
right.
Obviously,
that's
going
to
be
the
case.
We
only
have
one
transaction
engine,
but
all
it
has
to
connect
to
I'm
just
going
to
move
this
one
over
a
little
bit.
We
can
see
over
there
it's
connecting
and
it
continues
to
process
application
connection
request
and
it
says
that
yep
I'm
delivering
them
all
on
on
104.
C
Ok,
so
so
now
that
we've
seen,
you
know
a
little
bit
of
how
it's
connecting
we're
now
going
to
create
that
hockey
database
that
I
mentioned
so
I'm
gonna
go
ahead
and
create
that
database.
So
we're
just
running
some
sequel
here
to
create
that
hockey
database
loading
up
some
player
and
scoring
data
and
some
team
data,
and
for
those
of
you
that
are
familiar
with
hockey,
you
might
recognize
some
of
these
names
or
where
we're
going
to
display
we're
gonna,
write
some
standard,
sequel
sequel
that
you
may
be
familiar
with.
You
know
traditional.
C
That
little
a
minute
runs
a
couple
of
sequel
statements
that
we
can
see
here
on
the
screen
right
running
some
standard
sequel.
So
for
those
of
you
that
might
wonder
well
what?
What
does
the
sequel
look
like
in
nuodb?
Well,
it
looks
exactly
like
the
sequel
you're
used
to
it
all
ANSI
standard
sequel
compliant.
You
know.
In
this
case
we
were
joining
from
clause
with
a
list
of
tables.
C
All
of
the
today's
common
you
know,
inner
and
outer,
join
and
left
joins
and
taxes
all
supported,
as
well
as
any
sequel
functions
that
you
run
in
common
database
products
like
my
sequel
and
Oracle
and
sequel,
server,
we've
taken
quite
a
survey
of
the
arithmetic
and
date
and
string
function,
and
we
support
most
all
of
them.
So
what
that
means
is
when
you,
when
you
run
a
my
sequel
statement
and
nuodb,
it's
going
to
be
quite
happy
to
run
a
new
ODB
without
changing
your
sequel.
C
Likewise,
if
you
run
an
oracle
statement,
maybe
you
were
using
oracle
concat
with
the
double
bar
and
nuodb
would
be
quite
happy
to
run
that
the
reason
that's
important
is
you
know
whenever
those
sequels
tend
to
cross
over
to
other
databases,
they
won't
work
right.
If
you
run
an
oracle
double
kink
at
against
my
sequel,
it's
not
going
to
work.
You
run
a
my
sequel.
C
C
This
last
one
here
shows
some
cumulative
all-time
scoring
goals
for
some
popular
players.
This
is
the
top
10
goal.
Leaders
out
there,
Gordie
Howe
he's
an
old-timer.
He
played
quite
a
long
time
ago,
Wayne
Gretzky
another.
You
know
familiar
name,
probably
for
many
of
you
and
we
can
see
there.
Their
goal
counts
right,
so
Gordie
Howe,
scored,
975
and
Wayne
Gretzky,
not
quite
as
many
940,
but
we
do
see
that
Wayne
Gretzky
has
appeared
three
times
as
a
seasoned
leader
in
goalscoring.
C
So
that's
just
some
of
the
data
we're
gonna
we're
gonna.
Look
at
that
in
a
little
more
detail
as
we
get
a
little
further
into
our
presentation,
but
let's
go
ahead
and
scale
our
environment.
We're
now
ready
to
go
ahead
and
and
go
back
to
our
openshift
environment
and,
let's
add
more
transactional
throughput
to
our
environment.
So
I'm
going
to
open
up
the
transaction
engine
pod
and
using
the
familiar
you
know
up
and
down
the
widget
spin
control
here,
I'm
gonna
add
three
more
transaction
engines.
C
We
now
have
four
transaction
engines,
so
if
we
go
back
to
our
environment,
we
can
go
ahead
and
and
run
that
same
command.
We
did
before
that
shows
the
domain,
but
now
we
can
see
instead
of
just
one
SM
and
1te,
we
can
see
we
have
a
whole
bunch
of
transaction
engines
at
all
up
and
running
and
ready
to
service
our
application.
So
if
we
go
back
to
that
other
sequel
statement,
where
we're
just
going
to
generate
a
lot
of
load
against
the
system,
each
connection
is
reporting
which
transaction
it
connects
to.
C
C
104,
so
we
see
that
they're
all
processing
actively
the
transaction
and
sequel
request
that
our
application
is
running
now.
What
we
can
also
do
is
we
can
have
some
fun
here
and
remove
some
transaction
engine
and
let's
watch
what
openshift
and
and
how
it
responds
to
that
sort
of
system
or
said
that
sort
of
event
will
see
that
you
know
openshift
is
going
to
enforce
the
database
and
quickly
replace
any
processor.
C
C
Thanks,
alright,
we
just
removed
a
couple
of
pots:
okay,
but
notice
all
the
while
to
the
left.
Our
application
continues
to
run
it's.
It
has
two
other
transaction
engines
running
and
the
other
two
have
already
been
replaced.
In
fact,
they've
been
replaced
prior
to
nuodb
reporting
that
the
other
two
have
been
removed.
Let's,
if
we
do
this
yet
so
we
do.
C
Can
see
it's
actually
in
the
process
right
now
of
those
two
being
removed
and
two
being
added
okay,
this
will
just
take
a
moment
to
update
and
we
can
see
there's
there's
three
so
so
it's
currently
working
its
way
back
to
four
there.
We
are
we're
now
hit
stable,
we've
replaced
two
of
them
and
we
have
four
running
and
we
can
see
our
new
one
70
and
71.
If
we
look
to
the
left
there
already
servicing
application
requests.
So
this
is
a
great
demonstration
to
show
how
OpenShift
enforces
the
new
ODB
database.
C
C
C
C
Dd
scripts
hockey
whoops,
that's
not
the
right
one.
You
get
Z
there.
We
go
okay,
all
right,
so
we
lost
that
window,
but
now
we're
back
okay.
So
now
what
we're
going
to
do
is
we're
gonna
we're
going
to
show
how
we
can
scale
the
in
storage
environment,
but
the
way
we're
going
to
do
that
is.
We
are
going
to
make
a
change
to
the
data,
we're
going
to
show
how
that
change.
C
Propagates
from
storage
manager,
Storage
Manager,
even
in
the
event
of
a
failure,
will
show
that
the
change
will
persist
in
the
new
storage
managers
that
are
being
created.
So
so
I'll
go
ahead
and
you
know
let's
walk
through
this.
So
let's
start
back
with
we're
going
to
run
that
that
previous
command,
let
me
get
that
command
back
for
us,
where
we're
going
to
run
the
hockey.
C
C
Howe
we're
also
gonna
update,
Bobby
Hall,
okay,
Bobby
Hall
is
another
old
timer
he
for
much
of
his
career.
He
also
did
not
play
82
games,
so
it'd
be
kind
of
interesting
to
compare
Gordie,
Howe
and
Bobby
Hall
against
Wayne
Gretzky
if
we
sort
of
equalize
that
they
all
played
82
games.
So
here's
a
sequel,
a
couple
sequel
statements
that
update
our
database
and
and
now
we'll
notice.
If
we
run
our
hockey
application,
we
see
that
Gordie
Howe
would
have
been
projected
to
score
over
a
thousand
goals.
C
Eleven
hundred
and
forty
three
goals
right,
if
you
notice
Bobby
Hull,
moved
into
second,
he
actually
moved
past
Wayne,
Gretzky,
okay,
but
for
this
part
of
the
demo,
what
I
really
want
everyone
to
focus
it
on?
Is
the
new
gold
count
for
Gordie
Howe,
eleven
hundred
and
forty-three,
because
what
we're
going
to
do
is
we
are
now
going
to
we're
going
to
scale
out
our
storage
manager
environment,
just
as
we
did
our
our
tes,
but
now
we're
going
to
scale
out
our
storage
managers.
Remember
right!
Now
we
have
one
copy
of
the
database
right.
C
C
We
scaled
up
our
storage
managers
right,
we
added
one-
and
here
it
is
right.
Here-
is
our
old
one.
On
IP
103,
we
out
now
have
a
new
Storage
Manager,
so
our
system
is
now
redundant
right.
We
have,
we
can
take
a
failure
on
any
process
and
know
that
we're
still
you
know,
processing
applications
and
still
storing
the
data,
and
now
we
have
two
copies
so
is
done
as
it's
made
a
copy
of
the
database
in
this
second
one
we're
going
to
go
ahead
and
kill
the
first
one.
C
C
Please,
okay
ouch
just
deleted
it.
Alright!
So,
but
we
know,
since
openshift
is
enforcing
my
environment,
that
it's
already
busy
replacing
that
storage
manager
with
a
effectively
a
second
new
one
right,
because
we
scaled
out
to
two
that
was
our
second
new
one
and
and
now
it's
replacing
the
first
with
which
effectively
is
a
third.
So
if
I
show
the
system
we'll
see
it's
already
added
it,
okay
and
it's
in
the
process
of
removing
the
first
one,
here's
the
first
one,
it's
still
showing
as
part
of
the
system,
even
though
we
know
it's
gone.
C
It
just
takes
a
moment
to
update
we're
doing
all
this
live,
but
we
can
see
now
that
we
already
have
our
system
enforced
again.
We've
got
two
storage
managers
and
two
transaction
engines,
which
is
exactly
what
we
asked
for
an
open
ship.
So
if
we
go
back
to
our
environment,
if
we
remember
that
update
was
made
to
the
first
storage
manager,
we
have
now
two
brand
new
storage
managers,
but
it
doesn't
matter
because
you
know
nuodb
is:
is
persistent
storage
so
we're
going
to
now
run
the
query.
C
So
what
we've
been
able
to
demonstrate
is
we've
been
able
to
demonstrate
nuodb
and
an
open
shift
environment
demonstrating
continuous
availability
of
you
recall
all
the
while
earlier
when
we
were
running
our
transaction,
never
did
one
fail,
even
though
we
were
removing
transaction
and
and
and
storage
managers.
The
applications
continue
to
run.
We
were
able
to
demonstrate
scale
out
as
well
as
scale
in,
and
we
also
demonstrated
the
load
balancing
portion
of
the
product
where
we
were.
C
We
were
using
round-robin
in
this
demonstration,
but
it's
probably
worth
also
mentioning
that
we
support
based
on
region
load
balancing
as
well.
So
you
can
prioritize
if
I
had
region,
let's
say:
I
had
regions
in
Boston,
New,
York
and
Washington
I
can
say
from
my
load:
balancer
I
want
to
connect
with
priority
Boston,
comma
New,
York,
comma
Washington,
comma
star.
That
would
mean
I've
set
a
priority
I'm
going
to
connect
to
a
te
first
in
Boston.
C
If
there
isn't
one
I'm
going
to
connect
to
one
in
New
York,
if
there
isn't,
one
I
will
connect
in
Washington
and
if
there
isn't
one
in
Washington
well,
you
know
just
give
me
any
one
that
you
have.
The
whole
idea
is
to
prioritize
or
veil
ability
so
that
this
the
applications
can
connect,
but
at
the
same
time
offer
performance
by
prioritizing
which
region
you
want
to
connect
to.
So
we've
showed
a
lot
today
of
nuodb
in
an
open,
shipped
environment.
C
Coming
back
to
our
OpenShift
main
console
and
again
we
see
we
have
two
storage
managers
and
to
tes,
just
as
we've
left
it
at
the
end
of
our
demo.
So
that's
about
what
we
had
prepared.
As
far
as
a
you
know,
a
Show
and
Tell
today-
and
you
also
wanted
to
you
know,
leave
some
time
for
any
questions
that
we
might
have.
A
This
has
been
a
great
and
I
think
for
a
lot
of
us.
This
is
all
very
new,
and
so
it
there
haven't
been
a
lot
of
questions
because
I
think
we're
all
just
digesting
this
I
wonder
if
you
can
go
back
to
your
final
slide.
You
said
you
had
some
resources
and
if
there's
a
place
where
there's
some
documentation
on
what
you've
done
with
open
ship,
was
there
a
blog
or
a
documentation,
page.
B
Or
no
I,
don't
I,
don't
believe
in
this
presentation.
We
do
have
documentation,
hey
I,
guess,
I
think
elected
to
put
that
in.
But
what
I
can
do
Diane
is.
Maybe
I
can
email
you
some
links
to.
You
know
where
you
can
find
our
Red
Hat
certified
container,
where
we
you
can
find
a
blog.
That
tells
you
how
to
deploy
any
way
to
being
open
ships,
and
maybe
with
your
with
the
blog,
we
can
include
that
information
that.
A
It
into
the
slides
that
would
be
great
I
do
we'll
add
that
up
and
we'll
upload
this
the
this
deck
and
that
there
as
well,
you
asked
a
question
or
you
you
should've
asked
for
suggestions
around
persistent
storage
and
I
know
there
are
lots
of
choices
when
you're
doing
four
six
volumes
with
open
ship.
So
there's
some
good
documentation
around
that
for
on
our
Docs
that
openshift
calm
around
types
of
persistent
volumes
that
you
can
set
up.
A
C
B
B
You
very
much
it's
very
helpful,
so
you
know
one
thing
that
I
would
like
to
hear
from.
You
know
as
people
kind
of
digest
a
recording
and
come
back
and
look
at
supplies
and
read
the
blogs
and
whatnot
yeah
I'd
love
to
hear
from
the
open
ship
community.
You
know
what
they'd
like
to
see.
You
know
next
and
the
time
of
the
demo
is
an
evolving
demo.
We
keep
adding
additional
features
and
functionality
in
the
showcase
various
different.
B
A
Other
thing
is:
if
this
demo
itself
I'm
fine,
it's
a
database
almost
where
it's
the
the
code,
for
it
is
in
github
that
they
could
run
the
demo
themselves,
but
sounds
like
there's
a
little
bit
of
setup
and
database
thing.
So
if
this
is
something
that
you
can
put
so
that
they,
if
somebody
wanted
to
play,
I'm
tried
and
doing
the
demo
themselves,
it
keeps
them.
B
Yeah,
that's
a
really
great
idea,
we're
working
on
something
that
what
people
can
actually
play
with
it
and
where
they
can
be
guided
step-by-step
through
a
demo.
This
particular
demo
would
be
difficult
to
put
up
on
github
to
show
because
it
uses
you
know
the
whole
enterprise
version
of
our
projects.
We
have
a
free,
Community
Edition
that
we
highly
encourage
to
go
to
download
and
play
around
with
so
we'd
have
to
we
adapt
the
demo.
To
that.
A
Know
it's
wonderful-
and
this
has
been
very
helpful
for
me
to
understand
what
you
guys
are
offering
and
I'm
sure
to
the
community
and
I'm
sure
that
all
the
solution-
architects,
inside
of
Red
Hat
as
well,
who
have
been
looking
for
a
solution
like
this
to
offer
so
and
lots
of
our
partners-
are-
are
interested
in
in
this
8
quite
hilarious.
For
me
to
see
all
the
old-timer
hockey
people
and
in
some
ways,
looking
at
sequel
again
feels
like.
Oh,
my
god,
they're
going
back
in
time.
A
But
it's
a
it's
a
great
thing
to
see
because
there
is
so
much
people,
so
many
people
out
there
still
very
actively
using
SQL
and
and
making
it
part
of
their
enterprise
offering.
So
this
is
a
really
helpful
thing
as
they
navigate
to
the
cloud.
So
thanks
for
your
time
today
and
I
will
get
this
up,
probably
the
next
day
or
so.
Depending
on
how
fast
the
video
editing,
though
I'm.