►
Description
OpenShift Commons Gathering @ Kubecon/NA San Diego November 18 2019
Andrew Harrison (Omnitracs)
Brian Tomlinson (Red Hat)
A
B
We're
gonna
talk
about
today
about
how
Omni
Trax
was
able
to
implement
openshift
Eve.
A
lot
of
the
goals
been
working
on
for
the
last
year,
quick
history
about
our
company
get
the
Wayback
Machine
go
back
to
1983.
We
created
the
first
routing
optimization
system
for
the
short
haul.
In
last
mile
industry,
in
88
Qualcomm
created
a
system
called
Omni
tracks.
It
was
the
trucking
reporting
truck
transportation
reporting
in
compliance
system.
That
was
initially
the
acronym
we
we
developed
on
that
and
turn
that
crank
for
several
years
between
2006
to
2012,
Qualcomm
and
another
company.
B
Rode
net
expanded
their
dominance
in
the
market
and
in
2013
how
many
tracks
was
acquired
by
vista
equity,
at
which
point
we
we
in
2014
we're
able
to
merge
with
road
and
xrs
and
all
of
that
to
say
we're.
You
know:
we've
acquired
a
lot
of
companies
over
the
last
few
years
from
2014
to
2019,
trying
to
manage
that
M&A
multi-cloud
multi
environment
space
was
very
difficult.
So
in
the
last
year
we've
been
working
on
the
omni
tracks,
one
project,
the
first
unified
platform
of
all
of
those
all
of
those
various
systems.
B
All
those
various
companies
and
openshift
was
a
major
part
of
that,
and
our
tight
cooperation
with
Red
Hat
was
a
major
part
of
that
success
as
well
quick
piece
about
where
we
operated
in
most
of
north
and
south
america.
We
have
a
large
presence
in
brazil
and
in
canada
as
well
so
starting
out
about
just
though
just
a
little
over
a
year
ago,
what
we
had
what
we
were
building
on
most
of
it
was
on
VMware,
almost
4,000
VM
spread
up,
spread
out
across
a
mix
of
everything
we
had
VCF.
B
B
We
all
of
our
management,
all
of
our
project
management
style,
was
all
waterfall.
Had
these
huge
monolithic,
apps,
isolated,
tower
groups
that
didn't
communicate
well,
didn't
work
well
together
and
traditionally
had
people
in
them
that
wanted
to
collaborate,
but
the
the
mechanisms
weren't
there
and
and
everything
was
always
very
driven
towards
a
timeline
rather
than
a
goal
or
a
project.
That's
where
we
came
from
in
the
in
the
in
the
last
year.
B
One
of
the
major
things
that
we
did
was
switch
to
to
open
ship.
We
decided
to
containerize
everything
we
wanted
to
create
a
micro
services
platform
for
our
company.
We
chose
open
shipped.
Originally
it
was
3.11
that
was
available
at
what
was
available
at
the
time
as
soon
as
open
shift4
was
in
tech
preview.
We
had
it
in
our
in
our
environment,
I,
don't
like
making
decorative
statements.
I've
been
told
by
other
people
inside
Red
Hat
that
we
were
the
first
to
rolled
into
production.
B
Take
that
for
what
it's
worth
we
rolled
it
out
into
production
very
early
on
we've
been
doing
it
for
a
long
time.
In
terms
of
how
long
it's
been
in
existence.
Anyway,
with
openshift
311,
we
were
able
to
get
immediate
cost
reduction
because
we
moved
everything
out
to
AWS,
got
rid
of
on-prem
costs
immediately.
We
wrote
customizable
play
books
to
make
sure
that
everything
was
infrastructure
is
code
and
that
it
was
always
a
definite
and
repeatable.
B
We
were
able
to
provision
interact
with
new
infrastructure
that
way
we
reduced
our
environment
deployment
time
from
over
a
week
to
less
than
two
hours
and
we
trained.
We
had
a
real
total
transformation
in
the
IT
department
and
especially
in
our
organization,
our
team,
the
agents
of
change
from
the
traditional
waterfall
style
to
a
real
agile
methodology
which
greatly
reduced
all
of
our
release
times
and
everything
else.
When
open
shift4
became
available,
we're
currently
using
for
118.
We
have
four
to
two
in
sandbox
cluster
right
now,
which
is
kind
of
nice
using
the
UPI
installation.
B
We
reduced
our
deployment
time
from
two
hours
to
40
minutes.
We
were
able
to
manage
and
extend
the
cluster
farther
by
a
built
in
the
operator
by
built-in
operators.
We
had
a
lot
more
cost
reduction
from
by
using
the
core
OS
model
for
the
master,
node,
so
less
licenses
to
about
rel
nodes,
direct
line
to
architecture
and
design
teams
through
Red
Hat,
consulting
and
through
the
other
members
of
red
had
to
wear
our
team
and
further
maturity
of
that
agile
process.
B
A
So
one
of
the
things
that
we
ran
into
is
in
the
OpenShift
3
world
he
had
danceable
and
sometimes
I
would
take
hours
to
run.
There
are
a
lot
of
quirks
a
lot
of
moving
parts
because
you
had
to
accommodate
every
base
use
case
that
was
out
there
so
with
open
ship
for,
of
course,
you've
got
the
IP
I
and
the
UPI
installers
in
user
provided
infrastructure
and
the
installer
provided
infrastructure.
So
at
the
time
only
UPI
was
available
for
AWS.
A
So
what
we
ended
up
doing
was
so
what
we
ended
up
doing
was
we
took
the
UPI,
we
wrapped
it
up
in
ansible
and
our
first
pass
at
that
was
successful
and
worked
out
pretty
well,
but
then
we
decided
we
can
do
better,
so
we
ended
up
going
and
taking
our
our
ansible
playbooks
and
setting
it
up
to
be
modular
in
our
repo
and
everything
we
treated
it
just
like
any
other
software
projects.
So
our
infrastructure
is
treated
just
like
software.
We
version
it.
We
release
it
test
it.
A
Everything
operators
came
in
really
handy
with
that,
because
an
operator
workflow
is
real,
simple.
You
just
set
up
a
CR
and
off
you
go
so
we
were
able
to
greatly
automate
management
of
the
cluster.
We
actually
got
to
replace
a
bunch
of
our
playbooks
and
then
spun
up
a
few
new
ones.
We
ended
up
running
into
a
little
bit
of
an
issue,
and
that
was
with
getting
the
dev
team
set
up
and
everything
there
was
a
bit
of
a
learning
curve
on
openshift
for
for
them.
A
So
in
an
effort
to
you
know,
make
life
easier
for
everybody,
including
ourselves.
We
actually
built
an
operator
that
they
use
that
they
can
go
ahead
and
deploy
all
of
their
pipelines.
They
can
deploy
their
applications.
They
maintain
everything
as
infrastructures,
the
operator
reaches
back
into
bitbucket
and
will
look
for
changes
and
automatically
reconcile.
A
So
it
helps
facilitate
get
offs
in
that
way.
It's
currently
a
class
2
operator,
so
it
can
do
seamless
upgrades
and
we're
working
on
how
to
get
it
into
class
3.
But
the
cool
part
is
is
because
it's
an
ansible
operator,
the
developers
can
go
ahead
and
just
fork
it
and
make
it
service
specific
if
they
needed
to
or
they
can
just
use
the
generic
functionality
next
slide.
A
As
far
as
ansible
goes,
we
have
a
very
strict
model
and
our
team.
Basically,
if
it
doesn't
exist
in
ansible,
it
doesn't
exist.
So
we
spent
a
lot
of
time
getting
the
underlying
OpenShift
infrastructure
set
up
and
managed,
and
you
know
beforehand.
You
know
an
Android
can
clarify
on
this,
but
they
didn't
really
have
a
lot
of
automation
around
their
old
infrastructure.
A
We
can
go
from
deploy
gamal
in
our
main
repo
to
an
operationally
ready
cluster
in
40
minutes
now,
which
is
just
absolutely
amazing,
because
we
can
tell
the
dev
teams
hey
we're
standing
up
a
new
cluster,
go
ahead
and
tag
your
your
repos
now
and
by
the
time
you
know
the
clusters
up,
they're,
ready
to
rock
and
roll
yeah
and,
like
I
said,
we
release
our
infrastructure,
the
same
way
that
we
release
software.
You
tag
it
as
a
version
and
push
it
out
and
off
you
go.
We
really
stuck
to
an
operational
excellence
model.
A
We
really
tried
to
step
up
on
that,
and
you
know
we
incorporate
everything
from
half-court
vault
for
security,
stuff
and
secrets,
management,
Splunk
logging
and
all
these
different
things.
So
we
really
go
through
not
just
day
two
operations
but
day
two
through
30.
As
far
as
the
care
and
feeding
of
a
cluster,
the
operator
model
did
not
change
the
fact
that
we
still
needed
ansible
to
do
some
things.
We
templatized
a
lot
of
CRS.
B
So
yeah
and
then
so
today
you
know
we
had
that
slide
a
few
minutes
ago.
Talking
about
what
we
had,
it
was
that
the
spread
out
environment
very,
very
all,
over
the
place.
Today
we
have
everything
in
AWS.
All
of
our
infrastructure
is
set
up
there,
we're
using
artifactory
for
our
our
images
and
x-ray
to
scan
them.
We've
got
actually,
we've
got
Victor,
ops
integrated.
These
are
all
SAS
solutions.
We've
got
we've
we've
adopted
and
brought
into
the
to
the
mix.
We've
got
big
drops
involved
to
do
notification
and
alerting
to
our
teams.
B
A
B
Not
going
to
be
able
to
find
sres
to
work
for
each
of
those
scrum
teams,
it's
not
going
to
work.
So
we
took
a
different
approach,
we're
using
a
virtual
ops
approach
where
we're
embedding
with
these
teams
now
and
teaching
them
to
be
the
the
ops
part
of
DevOps.
They
are
going
to
be
their
own
sres
they're,
going
to
be
through
the
the
role
of
architecture
owner
they're,
all
team
lead.
B
They
will
have
the
ability
and
the
proper
permissions
in
openshift
to
spin
up
their
own
namespaces
start
their
own
projects
at
apply,
the
give
people
grant
access
to
them
and
all
of
that
so
really
allowing
them
the
ability
to
care
and
feed
for
their
own
play.
Oh
no,
no
Nerys,
but
at
the
same
I'm
giving
them
the
ownership
of
it.
So
now
when
they
are
building
their
pro
their
their
applications,
they
are
actively
thinking
about
the
Opera
Opera
operationalization.
A
B
A
hard
word
to
say
sorry,
actually
thinking
about
that,
they
you
know,
and
and
so
they
know
that
they
can
feed
it
into
their
logs
into
Splunk
and
then
get
that
information
back.
You
in
fact
your
ops
as
a
notification.
If
something
goes
wrong,
that's
just
it's
just
part
of
how
they
do
their
their
daily
job.
Now
we
again
incorporating
Splunk
as
well.
We've
got
hash
a
court
fault
as
our
secret
certification
secrets
of
the
certs
management.
All
of
that
ties
into
openshift
very
well,
that's
it's
all!
B
It's
all
very
seamless
assisting
was
something
we
adopted
early
on
and
because
of
being
so
far
out
in
front
of
the
edge
on
open
shift.
We've
had
a
little
bit
of
time
to
get
those
two
working
together,
but
we've
had
some
great
success
with
those
guys
and
they're
working
very
closely
with
us
and
with
RedHat
to
bring
those
bring
their
service
offering
to
us.
It's
been
a
good
journey.
So
far,
we've
got
Jenkins
inside
the
the
cluster
as
an
open
ship
plug-in
allowing
the
again
the
dev
teams
to
own
their
pipelines.
B
So
we're
not
sitting
back
having
to
manage
all
of
that.
They
own
their
own
pipeline
for
their
code,
which
has
been
a
great
thing
again,
taking
some
of
that
operational
burden
off
of
the
central
IT
team
and
dispersing
it
inside
their
own
team,
developing
that
of
getting
everybody
familiar
with
the
operational
part
of
it,
so
that
they
can
have
that
virtual
ops
rotation,
where
you've
got
one
person
out
of
the
tip
out
of
the
sprint
each
time
to
handle
that
for
them
and
not
having
to
come
to
us
every
time.
B
They
need
something
that
that
takes
us
to
oh
I'm,
sorry,
I'm,
sorry,
there
we
go
lessons
learned
one
of
the
things
we
learned
early.
Adoption
of
open
shift4
was
critical
to
our
success.
It
it
depends
on
how
important
being
out
there
on
the
cutting
edge
is
to
your
company,
though
it
caused
a
lot
of
headaches.
Early
on.
There
were
blockers
because
of
external
vendors
not
being
caught
up
with
the
the
technology
wave.
So
you
know
for
us.
B
We
were
very
much
looking
forward
very
much
understanding
that
we
were
going
to
be
doing
this
for
the
next
five
years
and
didn't
want
to
get
stuck
in
an
older
version.
So
we
we
took
that
risk
and
by
that
takes
us
to
the
second
point
being
very
tightly
coupled
with
Red
Hat.
While
we
were
doing
this
they've
been
embedded
with
our
teams
for
the
last
year.
They
are
part
of
our
team
as
far
as
I'm
concerned
right
now,
and
that
that
tight
coupling
with
them
has
been
very
key
to
our
success.
B
It
made
it
possible
to
overcome
the
early
adoption
issues
very
quickly.
It
drove
innovation
within
our
team
and
within
Red
Hat.
The
stuff
we
were
working
on
was
feeding
directly
back
into
their
development
to
bring
bring
open
shift
to
where
it
is
today
that
transformation.
We
talked
about
earlier
that
from
traditional
systems
administrators
in
an
operational
role
to
DevOps
engineers.
We
did
that
in
less
than
a
year,
the
guys
who
are
on
our
team
myself
included,
not
the
red
hat
guys
with
the
army
track,
guys
we
weren't
doing
this.
B
A
year
ago
we
were,
we
were
traditional
systems,
administrators
and
our
silos.
We
had
Linux
guys.
We
had
vmware
guys
Wentz
Network,
guys
now
we're
all
on
a
team
together
we're
all
doing
this
stuff.
Every
day.
It's
been
an
amazing
transformation
for
our
for
the
technology
working
in
and
for
our
careers.
It's
been
great
and
and
that
that
tight,
that
tight
partnership
facilitated
that
shift
very
easily
having
the
operators
available
to
us.
B
It
allows
us
to
offer
infrastructure
as
a
service
to
the
dev
teams
almost
immediately
almost
day,
one
reduced
the
need
for
a
very
large
team.
We
do
this
with
four
guys.
Speaking
of
I
was
the
guy
who
didn't
include
the
slide
about
my
team,
so
I
apologize,
I'm,
gonna
call
him
out
now.
I
want
to
thank
Daniel
missile
daemon
Hedstrom,
Don
Harrington,
the
and
Charles
berry.
Those
are
the
omni
trans,
guys,
Bryan
Karsten
class
own
Vadim,
Zaroff
Ben,
Bateson,
David,
Lewis,
Christian,
Colette,
C,
Madhu
Mari.
Thank
you
all
for
those
guys.
B
A
Yeah
I
mean
so
we
actually
learned
quite
a
bit.
We
learned
that
maybe
having
three
masters
and
three
workers
as
a
starting
point,
isn't
so
great.
So
there
were
some
tweaks
there.
We
learned
that
you
know.
There's
the
the
team
working
on
the
machine,
API
and
everything
for
AWS
you
people
are
awesome
because
that
helped
out
a
ton
I
mean
we're
able
to
scale
up
now
in
less
than
five
minutes
really
really
easily
yeah.
A
A
B
And
and
that's
and
that
touches
on
another
thing
is
not
just
you
know
this
this
this
this
partnership,
not
just
with
Red
Hat,
but
with
all
your
vendors
we
you've
got
if
you're
gonna
be
out
in
front
like
this.
With
with
the
the
latest
and
greatest
versions
of
open
ship,
you
have
to
have
good
relationships
with
your
vendors,
because
you're
going
to
be
going
to
them
and
saying
hey,
we're
doing
this
in
a
completely
new
way
and
I
need
you
to
help
me
get
it
working,
because
it's
not
and.