►
From YouTube: OpenShift Commons Image Builder SIG #5: Legacy to Docker
Description
The team behind Unison, aka the Tremolo Security, Briane Bullock and Marc Boorshtein, will talk about their lessons learned containerizing/dockerizing Unison, their experiences using S2I and their experiences managing access to OpenShift with a demo of opensource identity management for OpenShift.
They’ll tell you where they found the best sources of technical documentation, what the obstacles were and how they overcame them.
Marc Boorshtein, CTO Tremolo Security
Twitter – @mlbiam / @tremolosecurity
We are planning on bi-monthly meetings depending on the group’s schedules and interests.
For the latest information on OpenShift 3.1 and available briefings, please visit http://commons.openshift.org or subscribe to the OpenShift Blog (https://blog.openshift.com).
The OpenShift Commons exists to provide a platform for customers, partners, developers and other open source technology initiatives to collaborate, share and accelerate the pace of innovation and adoption of OpenShift globally.
The OpenShift Commons represents a new open collaborative community model designed to facilitate communication and sharing of best practices, feedback and development across the many open source initiatives that integrate with OpenShift. The best way to get involved is to join the conversation today at http://commons.openshift.org
A
Well,
welcome
everybody
to
this
openshift
commons
image
builder
sig
meeting
we're
going
to
have
a
talk
today
from
mark
borshton
and
brian
bullock
of
tremolo
security
and
you've
heard
them
before
talk
about
open
unison
and
identity
management
on
an
openshift
commons
briefing
in
the
past,
and
I've
invited
them
back
here
again
because
they've
done
taking
the
next
step
and
they've
containerized
unison
and
open
unison.
By
that
we
mean
we
put
it
in
the
docking
container
and
use
the
tool
chain
which
is
source
to
image.
A
So
I
thought
this
would
be
a
really
good
way
to
start.
The
conversation
have
a
good
working
example.
We
had
one
a
couple
weeks
ago:
crunchy
data
did
one
talking
about
packaging
up
and
containerizing
postgres,
but
we're
continuing
to
see
and
learn
more
about.
You
know
the
different
aspects
of
packaging
up
your
service
so
without
too
much
further
ado,
mark's
going
to
introduce
himself
and
his
partner
here
and
we'll
kick
it
off
and
then
ask
any
questions
in
the
chat
and
at
the
end
of
maybe
20
30
minutes
of
talking
and
demoing.
A
B
B
So
really
quickly.
What
is
unison
and
open
unison,
so
unison,
is
our
commercial
product.
Open
unison
is
our
open
source
project.
Only
real
difference
between
them
is
that
unison
has
a
management
interface
and
what
we
call
virtual
appliance,
whether
it's
running
on
container
vm
or
physical
hardware,
whereas
open
unison
is
a
j2e
application
and
you
have
to
configure
everything
by
hand.
So
we're
going
to
be
focusing
mostly
on
open,
unison
from
a
demo
standpoint
today,
so
an
identity
management
solution,
so
that
means
user
provisioning.
You
know
what
what
do
your
applications
need?
B
Access
to
self-service
can
users
just
log
in
and
request
that
access,
rather
than
having
to
have
an
email
chain,
virtual
directory
for
integration,
sso
and
web
access
management-
and
you
know
we're
built
on
java-
and
you
know
really
the
key
difference
from
a
docker
standpoint
that
we
ran
into
when
containerizing.
These
systems
was
how
they
run
because
unison
is
a
standalone
server.
B
It's
built
on
top
of
undertow,
so
we
have
multiple
undertow
instances
that
all
run
in
one
jvm,
whether
you're
connecting
to
the
identity
provider
or
verse
proxy
for
web
access
management,
the
ldap
virtual
directory
or
the
admin
interface.
Those
all
run
on
different
ports
on
different
undertow
instances
on
one
jvm,
whereas
open
unison,
j2ee
web
application.
B
B
So
real,
quick
before
we
dive
into
the
specifics
of
how
we
built
our
source
to
image,
we're
actually
going
to
kick
off
a
source
to
image,
build
because
we're
going
to
be
downloading
all
libraries.
It
takes
a
couple
of
minutes,
so
I
don't
want
to
have
some.
You
know
dead
air
time
while
that
process
is
going
so
before
brian
kind
of
talks
about
what
our
source
to
image
build
process
looked
like
just
wanted
to
show
you.
This
is
a
github
repository
that
we're
using
for
our
demo,
and
this
github
repository
has
our
source
code.
B
B
But
what
I
do
want
to
point
out
is
that
we've
parameterized
everything,
so
this
one
source
repository
can
be
used
to
build
dev
test,
pre-prod
prod,
all
based
on
configuration
parameters,
so
things
are
in
source
control,
but
not
secrets
and
passwords,
and
then
just
to
show
you.
This
is
the
unison
config
file.
Again,
I'm
not
going
to
get
into
too
many
of
the
details
as
to
how
it's
configured
but
pointing
out
that
we
have
parameterized
that
as
well.
B
So
that's
that's
up
on
github,
and
so
what
we're
actually
going
to
do
is
before
we
talk
too
much
about
the
process
of
building
our
sourced
image.
I'm
just
going
to
kick
it
off,
so
we've
got
s2i
build
I'm
running
this
from
our
source
to
image
repository
also
on
docker
hub
or
I'm
just
excuse
me
on
github
and
we're
just
going
to
pass
in
that
git
repo.
B
This
is
an
image
that
we
have
hosted.
That's
our
builder
image
on
docker,
hub
and
brian's,
going
to
talk
about
that
in
a
second,
and
this
is
the
resulting
image
that
will
be
created
and
deployed
into
my
local
registry.
Now.
One
thing
I
want
to
point
out
here
is
that
this
is
all
running
against
the
local
docker
machine,
so
you
can
use
source
to
image,
to
be
able
to
create
images
that
will
run
on
any
docker
container,
not
just
open
shift.
C
Thanks
mark
so,
as
mark
pointed
out,
open
unison
and
using
in
general,
are
just
simple,
j2ee
applications
they're
deployed
as
a
simple
waterfile.
So
all
we
really
need
in
our
image
is
a
servlet
container.
We
are
relying
on
tomcat
for
that.
Of
course,
tomcat
requires
java
8,
which
is
also
in
our
in
our
our
builder
image.
C
So
our
image
contains
very
simply
java.
It
contains
comcade
and
it
contains
maven.
Our
builder
image
allows
users
to
to
pass
in
either
that
constructed
war
file,
that
open
unison,
constructed
war
file
or
a
a
github
repo,
which
is
what
mark
actually
has
done
and
when
he
kicked
off
the
command
moments
ago.
Passing
in
the
war
file
makes
things
a
little
bit
faster.
The
builder
image
doesn't
have
to
go
out
and
download.
C
All
the
all
of
the
required
libraries
doesn't
have
to
assemble
assemble
the
war
file,
but
it
also
requires
that
the
war
file
be
assembled
and
ready
to
be
passed
into
the
into
the
builder
image,
which
isn't
always
going
to
be
the
case.
Now,
that's
something
that
mark
and
I
actually
talked
about
at
length
a
bit
when
we
were
putting
this
together
and
something
that
we
actually
reached
out
to
the
openshift
commons
groups
to
discuss
when
we
were
putting
this
together.
C
Do
we
do
require
that
the
war
file
be
built
and
pass
that
into
the
password
into
our
builder
image,
or
do
we
allow
a
get
repo
to
be
passed
in
and
then
have
builder
image
assemble
that
the
community
was
was
was
very
responsive,
very
quick
and
very
helpful.
What
they,
their
biggest
suggestion
to
us,
was
to
take
a
look
at
the
wildfly
project
and
wildfly.
C
The
way
that
they
they
assembled
their
project
was
to
say,
if
you
pass
in
a
war
file,
great
I'll,
take
the
war
file
we'll
deploy
that
out
to
the
server
container.
For
you.
If
you
pass
in,
you
know
your
git
repo
great
we'll
package
that
up
using
maven
for
you,
so
we
followed
that
same
model,
like
I
said,
mark
has
passed
in
our
our
git
repo
into
the
builder
image.
B
Real
quick
before
we
move
on
to
the
next
slide
just
want
to
point
out.
You
know:
we've
been
talking
about
source
to
image
and
want
to
make
sure
that
we
define
what
source
damage
is.
We
have
a
bullet
here
at
the
bottom,
with
a
link
to
source
to
image
the
way
that
we
saw
source
to
image.
Is
it
allowed
us
to
provide
that
base
image
and
a
build
process
without
having
to
create
our
own
scripting
base
our
own
install
process?
B
It
gives
us
a
standard
where
we
can
now
say
hey.
You
know
we.
We've
got
the
baseline
image
up
and
docker
hub
and
brian's
going
to
talk
about
that
in
a
second,
but
actually
going
from
a
couple
of
text.
Files
of
configuration
to
a
running
open,
unison
instance
just
requires
that
one
command
and
that
that
was
immensely
powerful
for
us.
C
Yeah,
it's
great
to
point
out
thanks
for
that
mark
that
was
incredibly
powerful
for
us
as
mark,
as
as
mark
said,
using
containerization.
It
does
obviously
simplify
life
a
great
deal
but
using
source
to
image
to
go
directly
from
that
git
repo
into
a
running
configured,
open,
unison
image
is,
is
incredibly
powerful.
C
So
what
we've
got
laid
out
here
is
sort
of
a
simple
map
of
how
all
of
this
works
for
us,
our
starting
here.
I
guess
in
the
upper
right
hand,
side
of
this
this
image,
our
our
builder
image,
is
maintained
on
on
docker
hub.
It
is
built
from
the
official
centos
7
image,
that's
available
on
docker
hub,
so
any
time
that
centos
7
image
is
updated.
Our
builder
image
is
automatically
updated
by
by
docker
hub.
C
Our
docker
file
is
contained
in
a
a
github
repository
so
anytime.
We
make
any
changes
to
that.
To
that
builder
image,
although
infrequent
it
may,
it
may
happen.
Docker
hub
will
recreate
that
that
image
for
us,
so
that's
all
automatically
updated
on
on
docker
hub
over
on
the
left
side.
Here.
What
we've
got
is
is
we've
got
the
maven
central
repository
as
well
as
our
tremolo
security
repository
there.
C
Where
you
will
find
and
download
any
necessary
libraries
for
for
our
project,
the
reason
for
that
is,
we
wanted
to
to
to
provide
sort
of
ownership
or
some
some
level
of
accountability
right.
The
the
files,
the
libraries
that
are
coming
from
tremolo
security
can
be
trusted.
You
know
they're
coming
from
terminal
security,
they're
signed
by
our
ev
certificates,
they're,
not
just
just
available
up
there
in
in
central.
C
B
B
Yeah,
someone
decided
to
make
a
change
so
we'll
we'll
take
a
look
and
see
it
looks
like
somebody
changed
out
the
one
of
our
applications
that
we
integrate
with
alfresco.
So
we'll
take
a
look
at
that
later,
but
I'm
kicking
off
open
unison.
Now,
in
the
background,
takes
a
couple
minutes
start
up
so
go
ahead
and
continue
the
presentation,
while
that's
going.
B
So
we
talked
about
the
the
open
source
image
that
we
created
around
s2i.
Now
we're
going
to
talk
about
kind
of
some
of
the
issues
we
ran
into
in
creating
the
commercial
version
of
unison
inside
of
a
docker
image.
We
didn't
go
with
s2i
for
this
particular
route,
mainly
because
s2i
is
really
great
at
creating
a
static
image
based
on
configuration
files,
whereas
unison.
B
We
really
wanted
to
balance
the
the
ability
to
deploy
inside
of
an
image
but
not
lose
the
power
of
the
admin
interface,
and
so
we
wanted
to,
instead
of
maybe
breaking
things
up
into
microservices,
which
would
probably
be
the
more
orthodox
approach
for
a
new
app.
You
know
we
wanted
to
make
sure
that
we
were
keeping
it
as
simple
to
deploy
in
docker
as
it
is
on
bare
metal
or
vm.
B
You
know
on
if,
if
we're
starting
this
up
from
rel,
you
know
yum,
install
unison,
the
system's
up
and
running,
we
didn't
want
to
have
to
deploy
a
set
of
containers
just
to
get
to
that
same
point,
and
so,
as
we
started
looking
at
containers,
you
know
the
first
thing
we
did
was
we
broke.
The
first
rule
of
creating
docker
images,
really
bad
fight
club
joke,
but
you
know
don't
treat
containers
like
vms.
B
B
Not
quite
so,
we
ran
into
a
lot
of
challenges
with
with
that
first
methodology
of
well.
Let's
just
treat
it
like
a
vm
and
you
know
not
to
iterate
through
the
list.
Networking
was
a
big
issue.
Configuration
management
was
a
big
issue
in
security
as
well
as
how
do
we
maintain
that
simplicity?
You
know
it's.
It's
super
simple
for
us
to
deploy
on
a
linux
vm.
It
shouldn't
be
harder
to
deploy
on
docker,
so
this
is
kind
of
a
typical,
highly
available
deployment
for
unison,
pre-docker.
B
We
use
a
master
slave
model
where
our
configuration
is
all
text
based.
It's
all
xml
and
configuration
file,
and
so
we
use
a
push
model
where
a
master
knows
about
all
the
different
slaves,
and
you
want
to
make
a
configuration
update.
You
make
all
your
changes
to
the
master
you're
happy
with
it.
You
hit
a
button
and
it
pushes
out
to
each
individual
slave
well
that
doesn't
really
work
with
docker,
because
in
a
dynamic
environment
like
docker,
I
don't
know
where
the
ip
addresses
are.
B
I
don't
want
to
know
where
the
ip
addresses
are,
because
you
might
be
spinning
things
up,
bringing
things
down,
and
so
we
needed
a
more
dynamic
approach.
So
we
added
the
option
of
basing
everything
off
of
volumes.
So
we
said
all
right.
Well,
we're
all
only
reading
data
off
of
a
drive,
so
let's
just
make
the
the
push
mechanism
from
there
as
well.
B
So
we
say
all
right
when
you
spin
up
your
docker
containers,
whether
they're
pods
in
open
shift
or
kubernetes,
or
you
know
some
other
mechanism-
you
go
ahead
and
spin
it
up
and
everything's
off
of
a
shared
volume,
server,
don't
care
if
it's
you
know
sifs
if
it's
nfs
whatnot
and
so,
instead
of
having
a
network
call
to
each
slave.
We
put
a
marker
on
the
file
system
that
the
slaves
are
looking
for,
says
hey
time
to
reload
your
your
configuration,
so
we
we're
getting
the
best
of
both
worlds.
There.
B
We
had
some
other
lessons
learned,
you
know
really
around
security
and
and
that
volume
management
from
a
security
standpoint.
Great
resources
were
both
the
open
shift
documentation,
as
well
as
the
atomic
the
red
hat
atomic
documentation
guidelines
for
how
to
build
images
that
really
helped
us.
You
know
really
narrow
down
what
was
going
on
when
we
look
at
docker
hub.
B
You
know,
we've
we've
got
it
down
to
it's
just
one
java
process
now,
which
is
which
makes
the
management
much
easier
and
then,
from
a
persistent
volume
standpoint.
The
way
unison
was
originally
built.
Configuration
information
was
spread
across
five
or
six
different
directories
depending
on
what
you
are
configuring,
and
so
our
initial
run.
We
said:
okay,
you
you
deploy
on
openshift,
here's
the
mapping
for
each
of
those
volumes
and
you
needed
five
or
six
different
volumes.
B
Well,
because
an
open
shift,
you
can't
guarantee
the
mapping
from
persistent
volume
to
a
persistent
volume
claim
that
caused
us
a
lot
of
heartburn
with
the
with
folks
that
were
trying
to
use
the
system.
So
we
said:
okay,
we're
going
to
change
that,
so
that,
if
you're
running
on
docker
we're
going
to
put
all
the
configuration
in
one
directory
so
that
way
for
unison.
B
You
only
have
one
volume
point
and
we're
actually
going
to
expand
on
that
in
a
future
rev,
where
we've
got
a
package
format
that
you
can
download
all
of
the
configuration
into
one
file
and
use
that
to
bootstrap
a
new
instance.
So
we're
trying
to
figure
out
how
we
want
to
maybe
integrate
that
where
you
just
pass
in
a
url
of
the
bootstrap
dens
of
the
package
and
we
don't
even
need
a
shared
volume.
So
that's
a
another
way
to
get
around
that.
B
Let
a
user
log
in
for
using
their
centralized
credentials
as
active
directory
request
access,
get
approved
and
log
in
and
be
able
to
to
work
on
that
project.
This
is
actually
piggybacked
off
of
the
demo.
We
did
at
red
hat
summit
a
couple
of
weeks
ago,
so
we
have
a
mix
of
both
open
unison
and
unison,
all
running
on
containers,
the
environment
itself.
We
have
openshift
running
on
openstack,
both
of
which
are
running
on
rel,
as
well
as
red
hat
idm.
B
Those
are
all
being
managed
by
unison
and
open
unison
from
an
identity
management
standpoint.
Obviously
we're
going
to
stick
with
openshift
here,
openstack
and
rel.
You
know
maybe
another
episode
and
so
from
an
identity
management
standpoint.
We've
got
two
active
directory
for
us,
because
you
know,
microsoft
has
basically
told
everybody
since
2000
to
logically
break
up
your
active
directory
for
us.
So
we've
got
two
forests
for
different
sets
of
users.
B
Now
we
have
a
red
hat:
identity
management,
server,
active
directory
stores,
all
of
our
people,
our
humans,
our
users
and
red
hat
identity,
management
stores,
linux,
specific
attributes,
shell
ssh
keys
things
like
that
all
authorization,
so
all
of
your
groups,
as
well
as
service
accounts,
openshift,
has
kind
of
an
interesting
model
for
identity
management
where
it
it
really
outsources.
Most
of
it
and
there's
really
kind
of
two
ways.
You
can
add
users
to
authorized
users
to
use
projects.
B
The
first
is
to
manually
use
the
oadm
command
to
add
users
to
roles
inside
of
a
project
that
can
get
messy.
That
can
be
really
hard
to
scale
and
it's
almost
unmanageable.
Once
you
get
to
a
certain
level,
the
other
option
is
to
use
ldap
directory.
So
you
set
up
a
directory.
You
set
up
a
group
and
openshift
provides
a
synchronization
capability,
and
now
that
works
pretty
well,
you
know
the
the
impediment
there
is
that
you
have
to
manually
set
up
these
synchronization
jobs
they're,
not
real
time.
B
You
know
they're
periodic,
and
so
you
want
your
openshift
deployment
to
be
as
dynamic
from
a
security
standpoint
as
it
is
from
a
devops
standpoint,
and
so
we
actually
integrate
directly
with
the
openshift
api
so
that
when
you
get
provisioned
into
a
group,
we're
not
adding
you
to
a
group
in
the
directory,
we're
adding
you
directly
to
the
group
inside
of
openshift,
so
everything's,
very
dynamic.
You
define
one
workflow
or
set
of
workflows
for
your
projects
and
say
look.
This
is
how
the
approval
process
works.
B
B
B
So
this
is
scale
it's
scale
js,
it's
a
angularjs
application
restful
apis.
So
if
you
want
to
integrate
this
into
your
own
portal,
your
own
application,
we
fully
document
all
the
apis,
nothing's
hidden,
nothing
secret.
If
I
click
on
my
profile,
this
is
coming
directly
out
of
the
directory
and
openshift.
So
you
can
see.
I
already
have
access
to
three
applications.
B
So
the
first
thing
we
need
to
do
is
show
you
how
we
actually
request
access.
So
I've
got
this
open
shift
organization
set
up
and
I've
got
a
dynamic
workflow
built
and
what
that
dynamic
workflow
actually
does
it
talks
to
openshift
to
figure
out
what
projects
are
available.
So
when
I
click
on
this
and
this
loads
up,
this
is
actually
coming
directly
out
of
open
shift.
This
is
not
a
static
configuration,
so
you
see
I've
got
test
project,
test,
project,
2
and
test
project,
3.
we're
going
to
add
team
project
4..
C
B
B
So
this
is
pretty
standard.
These
annotations
and
and
and
annotation
in
openshift
is
specifically
designed
for
use.
Cases
like
this,
where
an
external
tool
that
wasn't
built
by
the
openshift
team
is
going
to
work
with
the
openshift
api.
So
it
lets
us
add
additional
data,
which
is
great
because
that
makes
our
product
work
really
well,
and
so
these
these
are
kind
of
your
standard
annotations
that
would
get
created
if
you
created
it
through
the
gui.
B
B
We
can't,
let
you
add
users
directly
to
projects
the
way
that
open
unison
figures.
That
out
is.
We
need
to
call
open
shift
and
have
openshift
tell
us
what
you
already
have
access
to.
That
mechanism
doesn't
exist
right
now.
So,
instead
of
trying
to
do
that
manually,
we
decided
to
stick
with
groups,
so
I'm
going
to
go
ahead
and
create
this
project
save
the
file.
B
And
then,
finally,
I'm
going
to
add
the
team
app
for
group
as
an
administrator
role
to
team
project,
for
which
is
the
project
I
just
created,
so
that's
getting
created,
and
so
I'm
here
in
request
access.
So
you
can
see
team
project,
2
team
project,
3
team
project.
I
click
on
this
again.
I
haven't
made
any
changes
to
open
unison
and
you
can
now
see
here's
team
project
four,
so
that
was
dynamically
generated
based
on
a
dynamic
workflow.
B
B
My
boss
is
giving
me
a
hard
time
wants
to
know
why
I
haven't
started
work
yet
well,
I
I
don't
have
access
yet
okay,
so
here's
an
example
of
a
report
that
we
can
do
of
my
open
requests,
so
the
currently
logged
in
user
I'm
requesting
access
to
team
project
four.
I
gotta
go
bug
this
other
map
mosley
in
the
other
domain,
so
I'm
gonna
go
ahead
and
do
that
so
the
other
map
mosley,
is
gonna
log.
B
B
Looks
good
so
I'm
now
on
record
as
saying
that
the
other
matt
mosley
should
be
able
to
have
administrative
access
to
team
project
four,
so
other
matt
mosley
has
gotten
that
request.
Now.
Here's
a
really
important
benefit
here
is
that
now
we
have
logs.
So
I
can
look
at
the
completed
approvals
for
today
and
we
can
see
team
project
4
that
the
request
was
made
and
was
approved
by
matt
mosley,
so
you
could
assign
just
your
auditors
or
just
your
security
folks
access
to
these
reports,
so
they
can't
go
approving
anything,
but
they
can.
B
So
if
I
start
you
know,
if
I'm
having
a
problem
logging
in,
I
start
saying:
hey,
I
have
access.
You
know
it's
not
uncommon,
for
users
to
forget
to
go
to
the
checkout
and
submit
things
you
know
for
support.
It's
really
easy
to
say:
well:
does
it
listed
as
a
role?
No
okay?
Well,
you
didn't
actually
ask
for
it.
B
So
now
what
I'm
going
to
do
is
I'm
going
to
log
back
in
so
this
is
my
current
access.
If
I
hit
refresh
will
come
up
yep
and
there
we
go
team
project,
four,
I'm
an
admin
and
I'm
able
to
start
you
know
but
doing
my
job.
So
we
actually
just
showed
a
complete
life
cycle
here
of
having
the
user
law
or
having
an
admin,
create
a
project
that
workflow
gets
dynamically
applied
to
that
project.
B
So
if
you
wanted
to
change
who
the
approvers
are,
etc,
you
make
the
changes
directly
to
your
openshift
project
and
this
can
be
dynamic,
so
we're
using
two
attributes
here,
but
you
know
you
can
put
anything
in
those
annotations
and
include
it
in
the
workflow.
So
you
want
to
add
extra,
descriptive
information,
additional
approval,
steps
that
can
all
be
driven
straight
from
the
project
yaml
file
and
then,
once
that
yaml
file
was
created,
user
was
able
to
log
in
request
that
access
get
it
approved.
B
A
B
A
B
I
ran
out
of
disk
space,
that's
not
good!
I
think
I
need
to
go
ahead
and
take
a
look
at
that,
but
interesting
not
really
sure
why
it
did
that
but
yeah.
So
that
was
a
local
problem
had
nothing
to
do
with
either
s2i.
We
we,
I
think,
ran
that
build
process
like
five
times
today
and
no
problem.
So
once
I
fix
my
laptop
I'm
sure,
it'll
work
right.
A
B
Whereas
for
us
the
management
ui
is
where
you
would
go
ahead
and
at
least
start
that
process,
you
might
be
importing
things
you
might
be
executing
against
it,
but
I
I
just
don't
know
that
s2i
would
really
have
helped
it
for
us.
You
know
what
we
have
thought
about
doing
because
and
we've
had
a
couple
of
folks
ask
this
is
you
know,
maybe
have
a.
B
Hybrid
approach,
where
they
love
the
idea
of
using
the
ui
to
build
the
config,
but
they
actually
want
to
use
open,
unison
in
production
because
they
don't
want
to
make
changes
on
the
fly
they
want
to
be
able
to
to
say
this
is
static,
so
I,
and
because
the
a
configurations
percent
compatible,
you
take
a
configuration
from
open
unison.
You
can
drop
it
into
unison.
B
So
you
know,
we've
talked
we've
talked
to
folks
about
saying:
okay,
well,
we'll
use
the
management
ui
to
generate
a
git
repository
for
you
that
you
could
then
use
the
source
to
image
as
part
of
your
deployment
process
so
and
especially
when
you
start
getting
into
open
shift.
That
makes
it
even
easier
because
then
we
can
integrate
with
builders
and
and
simplify
through
that
process.
So
from
for
our
commercial
side,
I
could
definitely
see
a
hybrid
approach
and
then
sourced
image
really
helps
us
out
with
that.
C
A
Perfect,
well,
I'm
not
seeing
any
questions
in
the
in
the
chat
right
now.
So
you've
done
a
really
awesome
job
mark
answering
most
of
the
questions
there
and
if
you
wanted
to
ask
more
questions
afterwards,
you
can
always
post
them
on
the
mailing
list.
The
openshift
commons
mailing
list
or
get
a
hold
of
mark
and
brian,
through
tremolo
security
on
twitter
and
via
email.
A
The
the
one
other
one
we
did
previously
was
crunchy
data
and
they
had
a
slightly
different
approach
because
they
did
containerize
each
of
the
each
of
the
tool
pieces
of
tool
chain.
So
they
put
prometheus
in
one,
the
logging,
another,
the
postgres
databases
and
others.
So
they
did
a
different,
a
slightly
different
approach.
I'm
not
saying
that
any
of
them
are
better
or
worse,
they're,
just
for
different
applications
and
different
processes
and
services.
You
need
slightly
different
things,
and
so
this
is
really
good
to
expose
this
use
case.
A
So
thank
you
very
much
for
coming
and
doing
this
and
everybody
for
joining
us
and
you're
a
little
silent
today
and
we'll
be
on
in
two
weeks
time,
with
another
image
builder
sig
and
tomorrow
there
will
be
an
image.
There'll,
be
an
openshift
commons
briefing,
an
introduction
to
big
data
by
members
of
the
apache
spark
team
here
at
red
hat.
So
we're
looking
forward
to
that.