►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Apparently,
that's
gonna
be
a
good
night
I'm
looking
for
that
hello
world,
alright,
so
for
those
of
you
don't
know
me,
my
name
is
Clayton
Coleman
architect,
/
openshift
I'm
worked
on
openshift
for
about
four
years
now,
I've
worked
on
Cooper
Nettie's,
since
it
was
started
and
to
me
it's
been
really
important
to
position
why
open
shift
exists
like
why
does
open
shift
exists?
We
have
Cooper
Nettie's.
We
have
dr..
We
have
all
of
these
tools
out
there
in
the
ecosystem.
What
do
we
create
open
shift
for?
What's
it
trying
to
accomplish
I?
B
Think
at
the
left
side
of
this
chart
as
it's
about
Cooper
Nettie's
and
the
right
side
of
the
chart
is
about
everything
else
that
isn't
Cooper,
Nettie's
and
so
open
ship
is
about
bringing
these
two
together.
It's
about
making
infrastructure
available
for
use.
You
know,
Chris
talked
about
this
this
morning
with
containers
and
what
container
what
advantages
containers
give
to
us.
Portability
is
really
important
right.
The
ability
to
run
something
on
your
laptop
and
run
it
in
production
was
the
original
promise
of
docker
and
I.
B
B
You
can
test
out
your
applications
and
then,
when
you
need
to
scale
you're,
just
running
the
same
application
everywhere,
that's
really
important,
but
on
the
application
side,
it's
not
just
about
running
applications
is
about
how
those
applications
come
to
be,
and
it's
not
just
about
the
what
it's
the
process
that
gets
you
to
that
point.
So
it's
packaging
and
deployment.
It's
a
config
driven
approach
so
that
you
can
define
your
applications
and
there's
lots
of
ways
to
define
config
right.
B
To
the
far
end,
which
is
you
use
it
to
build
very,
very
complex
applications
with
many
moving
parts
and
any
solution
that
has
to
span
that
is
pretty
difficult
to
represent
with
one
single
tool,
and
we
understand
that
and
we
try
to
keep
that
in
mind
every
time
we
design,
which
is
everything
that
the
really
simple
app
uses.
We
want
to
be
able
to
move
all
the
way
right
into
the
spectrum,
so
openshift
exists
because
OB
triptych.
B
This
is
a
separate
thing
from
communities
partially,
because
when
cooper
natives
was
started,
we
made
a
very
conscious
decision
that
we
wanted
Cooper
Nettie's
to
be
an
effective
Corps
for
running
applications,
and
we
wanted
to
deliver
it
as
fast
as
possible.
You
know
this
is
one
of
the
key
goals
of
the
communities
open
source
project
in
the
very
beginning,
which
was
actually
put
something
real
in
people's
hands,
and
so
we
looked
at
we
looked
at
what
criminales
would
be
an
application
run
time.
B
We
said:
well,
there's
a
ton
of
things
that
don't
fit
in
that
policy.
It's
how
administrators
deal
with
a
platform.
It's
how
you
keep
this
running,
it's
how
you
install
it.
It's
how
you
deal
with
all
the
existing
systems
that
you
have
in
your
enterprise,
already
authentication
policy
management
ldap.
These
are
all
things
that
are
required
to
be
able
to
run
not
just
a
10
a
platform
for
applications,
but
a
tentative
platform
for
applications,
and
so
we
worked
with
the
canaries
team,
we
kind
of
split
the
responsibilities,
so
the
open
shift.
B
You
know
engineers
work
on
both
Cooper
Nettie's
and
open
shift.
An
open
shift
is
really
everything
else.
That's
necessary
to
asterisk
on
the
end
of
application
platform
is
the
stuff
that
actually
makes
it
possible
to
run
applications
in
a
shared
environment,
and
so
that
focus
from
the
beginning
is
we
want
Cooper
Nettie's
to
be
usable
in
a
tentative
fashion?
We
want
to
optimize
14
software
development,
so
we
talked
about
you
know
the
12
factor
app.
B
All
I
do
is
push
code
and
applications
tick
through,
and
that
is
one
end
of
the
spectrum
and
for
a
lot
of
people.
That's
maybe
all
they
need,
but
on
the
other
end
of
the
spectrum
is
I
want
to
deploy
an
existing
application
and
Chris
alluded
to
this
earlier.
I
wanted
to
play
an
existing
application
onto
my
platform
and
I.
Don't
want
to
have
to
rewrite
it
in
order
to
do
that.
B
A
lot
of
people
run
external
build
systems
that
are
working
perfectly
fine
for
them.
They
don't
need
to
change
them.
We
want
to
adapt
and
be
able
to
run
the
applications
that
come
out
the
other
end
of
that
pipeline,
without
necessarily
forcing
people
to
change
everything
we
want
to
be
able
to
create
in
deploy
applications
in
seconds.
So
the
idea
this
is
it
everybody.
The
first
thing
that
you
see
when
you
run
docker
is
you
do
docker
run
and
you
give
it
an
image
and
something
starts
in
seconds.
B
We
want
to
be
able
to
do
the
same
thing
on
top
of
Cooper
Nettie's,
and
so
again,
when
we
started
Cooper
Nettie's
there's
been
a
lot
of
development
of
the
ecosystem.
Since
then,
there's
a
lot
of
new
ways
to
build
and
run
applications.
Everybody's
got
their
own
package
manager
today
and
our
focus
has
always
been
on.
We
just
want
to
make
it
easy
for
someone
to
see
a
list
of
things
that
they
can
consume,
that
someone's
made
available
for
them
that
actually
just
work,
and
so
in
open
ship.
B
We
have
the
concept
of
templates
over
time,
you're
likely
to
see
other
things
in
the
ecosystem
brought
in,
but
the
core
idea
is
I
push
a
button
and
I
see
value
and
I
see
that
right
away,
and
it
builds
on
top
of
the
things
in
Cooper
Nettie's,
but
there's
aspects
of
it.
They
need
to
be
taken
account
like
security
and
how
this
fits
into
the
rest
of
the
application.
Does
it
need
to
be
exposed
to
the
outside
world
or
not?
We
want
to
be
able
to
run
all
the
staple
parts
of
the
application.
B
That's
part
of
what
I'm
gonna
talk
about
today
and
we
want
to
do
this
easily
right.
Ease
of
use
is
really
important,
I'm
sure.
If
there's
some
people
here,
who've
used
openshift,
they
say
it's
very
complex.
There's
a
lot
of
moving
pieces
and
there's
this
balance
between
the
real
world
is
about
big
complex
applications
at
all
ends
of
the
spectrum
that
some
of
these
are
really
easy
to
use.
B
B
We
have
these
tools
that
you
can
still
get
the
ability
to
deploy
something
easily,
even
at
the
other
end,
and
so
our
goals
with
open
shift
is
to
keep
driving
in
the
community,
make
it
the
best
place
to
run
applications
provide
well
integrated
tools,
ensure
that
applications
remain
portable
to
any
environment
and
to
any
environment
means
Cooper
Nettie's,
but
it
may
also
mean
if
you
choose
not
to
use
Cooper
nighters.
You
want
to
take
your
applications
outside
we're,
not
going
to
try
and
lock
everything
into
Cabaye's.
B
We
think
Cooper
neighs
has
value,
and
we
want
to
make
it
easy
to
build
images
and
run
images
on
a
containerized
platform,
but
we
always
understand
there
will
always
be
edge
cases
in
all
of
this,
and
we
try
not
to
be
too
opinionated
about
the
environment
that
you
run
in.
We
think
that
Cooper
Nettie's
is
a
great
place
to
run
applications
and
we
think
openshift
is
in
a
better,
more
secure
place
to
run
applications
today.
B
But
the
end
goal
is
that
asterisk
for
environment
is
something
that's
containerized
that
runs
images
and
it
does
it
well,
so
you
don't
have
to
think
about
it
and
then
finally-
and
this
is
kind
of
a
this-
is
a
new
one
and
again
Matt
alluded
to
this
early
on
was
we
have
more
and
more
infrastructure,
more
and
more
clouds.
We
have
machines
just
sitting
under
our
desks
that
are,
you
know,
ten
times
more
powerful
than
a
supercomputer
from
20
years
ago.
B
All
of
that
capacity
is
just
going
to
waste
and
some
of
its
not
going
to
waste.
If
it's
powered
down,
but
the
idea
of
being
able
to
take
advantage
of
this
to
make
things
work
at
scale
to
be
able
to
test
big
complex
applications
easily,
which
was
very
difficult
before
the
more
you
can
buy
into
this
model,
the
more
you're
able
to
take
advantage
of
if
you've
got
a
cluster
and
it's
got
a
thousand
nodes
on
it,
maybe
I
can
run
a
thousand
nodes
in
my
application
and
see
what
happens.
B
I
may
not
need
that
now,
but
down
the
road
I
might
so.
This
is
just
standard
architectural
diagram,
openshift
I.
Don't
even
think
it's
really
that
important
for
what
we're
gonna
talk
about,
because
what
we're
talking
about
is
open
shift.
3-3
tie
developer
the
principles
of
where
we're
going.
The
highlights
were
on
the
infrastructure
level.
You
know
when
you
talk
about
the
system
and
down
of
running
applications,
containers
and
the
runtime
environment.
The
next
level
up,
which
is
making
sure
that
the
system
is
easy
to
administer,
is
secure.
B
Has
enough
policy
points
of
control
for
administrators
to
be
able
to
integrate
to
a
wide
range
of
processes,
and
then
the
developer
and
ease
of
use
on
that
platform?
So
I'm
going
to
talk
a
little
bit
about
most
of
these
and
again
this
is
open
shift
33,
which
was
released
in
September
openshift
34
is
coming
out
very
soon
now
open
shift,
34
has
an
even
longer
list
of
things.
Open
shift.
35
will
come
after
that,
and
this
is
really
driven
by
both
the
docker,
the
Cooper
Nettie's
and
the
open
shift
communities.
B
There's
a
lot
of
exciting
development
happening,
which
is,
it
seems
like
every
three
or
four
months.
You
just
get
a
whole
new
bucket
full
of
really
useful
features
that
solve
real
problems
and
that
to
me
that's
the
most
exciting
thing
about
working
in
these
ecosystems
is
there's
an
incredible
amount
of
people
working
together.
Diane
alluded
to
all
of
the
folks
working
together
to
build
containers
and
in
the
container
is
ecosystem,
there's
just
a
ton
of
new
stuff
that
every
day
we
find
a
new
way
to
bring
value
to
applications
and
developing
applications.
B
So
the
first
and
I
think
most
significant
from
a
developer
perspective.
Is
we
looked
around
and
we
said,
Jenkins
is
the
de
facto
developer
continuous
integration
tool?
Not
everybody
uses
it
right,
there's
lots
of
alternatives,
this
rich
ecosystem,
but
if
you
pulled
a
random
set
of
people,
maybe
I'll
just
ask
in
this
room.
How
many
people
here
use
a
CI
CD
system
as
part
of
their
pipelines?
B
Okay,
how
many
people
use
jenkins?
And
so
we
said
we
don't
think
the
jenkins
is
the
be-all
end-all.
But
Jenkins
has
some
of
the
same
value
that
some
of
the
tools
in
the
real
ecosystem
do,
which
is
it's
used
just
enough
places
and
there's
just
enough
people
working
on
it
that
there's
a
strong
community
that
has
a
solution
for
almost
everything.
B
There's
a
ton
of
great
documentation
out
there
and
jenkins
can
be
a
beast
sometimes,
but
at
the
end
of
the
day
we
understand
that,
for
the
most
people,
jenkins
provides
a
really
exciting
tool
as
part
of
some
of
the
work.
This
coming
in
jenkins,
it's
a
pretty
old
project,
but
Jenkins
is
really
the
Jenkins
community
has
embraced
the
idea
of
pipelines
and
building
concepts
in
Jenkins
that
really
try
to
fit
the
idea
of
taking
software
in
a
process
from
development
through
testing
to
rule
out
to
staging
to
production.
B
Not
everybody
runs
like
that,
but
that
we
felt
that
there
was
a
really
great
opportunity
to
integrate
just
enough
of
Jenkins
into
open
shift
to
make
it
easy
to
stand
up
and
deploy
a
Jenkins
cluster
to
be
able
to
use
it
on
top
of
this
infrastructure,
so
as
part
of
open
shift,
33
and
tech
preview
jenkins,
when
you
go
into
open
shift
and
you
launch
a
build
one
of
the
options
for
a
build
is
that
you
can
say
well
at
this
build
uses
a
Jenkins
file,
and
this
is
a
concept.
That's
been
edited
Jenkins.
B
A
Jenkins
file
is
really
a
lot
like
a
docker
file.
It
describes
a
process.
Docker
file
describes
a
process
for
creating
image.
A
Jenkins
file
describes
a
development
pipeline.
There's
a
lot
of
work
going
on
in
this
is
still
very
early
and
the
Jenkins
evolution,
of
course,
but
that
pipeline
is
really
the
idea
of.
I
want
to
say,
here's.
The
steps
I
go
through
and
I
want
the
infrastructure
to
make
it
happen
and
with
the
integration
with
open
shift,
the
Jenkins
that
runs
on
top
of
the
cluster
integrates
the
Cooper
Nettie's
plug-in
from
Jenkins.
B
It's
integrated
from
an
authorization
perspective
and
open
shift
34.
So
as
a
user
on
openshift,
if
I
need
to
get
access
to
a
Jenkins
instance,
I
can
press
a
button.
Jenkins
comes
up.
I
can
integrate
into
a
bill
on
that
Jenkins
instance
can
use
the
platform
securely
under
the
same
policies
and
controls
that
I
normally
have
in
that
project
to
build
and
run
apps
and
from
the
UI
we've
integrated
this
into
the
user
interface.
We
haven't
tried
to
replace
the
Jenkins
user
interface,
although
I'm
sure
there's
some
people
out
there.
B
Who
would
be
really
excited
about
that.
We've
tried
to
integrate
it
in
a
way
that
brings
to
a
developer
who's
thinking
about
how
I
go
from
beginning
to
end
a
snapshot
view
of
showing
what
the
most
important
process
so
the
UI
is
showing
a
set
of
builds
I
can
easily
take
an
open
shift.
Application
switch
it
over
to
Jenkins
to
use
Jenkins
just
by
putting
a
Jenkins
file
in
the
source
code
repository
and
that
I
can
define
an
arbitrary
complex
pipeline.
B
B
This
might
be
building
images,
it
might
be
building
war
files,
it
might
be
running
a
completely
custom
process,
it
might
be
running
ansible
to
publish
to
a
production
environment,
and
so
we
see
there's
a
lot
of
there's
a
lot
of
flexibility
in
this
space,
and
one
of
the
things
we'll
be
looking
at
over
the
next
few
releases
is
how
to
make
this
easier
to
consume
in
a
way
that
doesn't
necessarily
lock
you
into
any
particular
platform.
You
could
take
this
pipeline
and
run
it
to
on
another
koobideh
system.
B
It's
still
mostly
focused
on
the
operational
experience
of
running
cooper,
Nettie's
objects.
In
the
open
shift
console
we've
tried
to
focus
on
what's
the
flow
that
someone
takes
going
from
an
idea
to
production,
it's
pretty
familiar
concept
and
the
console
is
intended
to
make
it
easy
for
you
to
start
ideas
and
also
to
maintain
idea.
B
What's
going
on
run
into
production
and
depending
on
whether
your
production
environment
is
your
dev
environment,
it
may
actually
be
that
this
console
is
just
showing
you
you
a
personal
dev
tools,
but
if
you're
the
kind
of
team
that
splits
responsibilities
or
has
combined
responsibilities
across
both
dev
and
ops,
the
open
shift
console
is
really
focused
on
giving
you
just
enough
information
to
help.
You
decide.
B
What's
going
on
in
production,
so
integration
of
metrics
with
user
interface,
a
ton
of
new
I,
talked
about
push
button
applications
we've
really
tried
to
flesh
out
the
experience
of
I,
can
define
a
fairly
complex
application
and
offer
it
to
my
developers.
Those
developers
in
a
single
click
can
provision
and
deploy
it
and
extending
those
capabilities,
also
taking
images
from
the
docker
hub,
as
is
running
those
making
it
easier
to
bring
the
things
that
you're
already
using
together
in
one
spot.
B
It's
now
been
renamed,
so
I
would
call
this
stateful
sets
for
pet
services,
but
the
idea
is
the
idea
here
is
that
in
the
real
world
there's
two
types
of
applications,
there's
the
ones
that
don't
care
about
their
state
and
you
can
replicate
an
infinite
number
of
them
and
there's
the
ones
that
do
where
all
the
money
is
and
the
ones
where
all
the
money
is.
Is
that
might
be
your
database.
That
might
be
your
session
store.
B
That
could
be
a
message
queue
and
most
of
these
things
are
pretty
finicky
when
it
comes
to
you
get
it
wrong
and
everything
goes
dark,
and
so
one
of
the
goals
is
to
move
the
application
ecosystem
to
have
a
flexible
infrastructure.
You
need
concepts
that
make
running
services
with
state
easier,
and
so
you
can
use
the
existing
concepts
in
Coober,
Nettie's,
10
and
11
and
12
to
accomplish
this.
But
it
was
obvious
that
we
wanted
to
build
a
concept
that
fit
the
model
of.
B
There
might
be
one
of
me
and
there
never
should
be
more
than
one
of
me
and
I
need
access
to
a
database
and
I
have
a
network
identity.
I'll
talk
a
lot
more
about
this
I
have
a
talk
on
Wednesday
stateful
sets
at
q.
Con
and
I
will
go
into
much
more
detail
of
this,
but
at
the
basic
level
we
want
to
make
it
easy
to
run
databases,
message,
queues,
caches,
high
availability,
applications,
leader
elected
services,
on
Cooper
Nettie's.
B
To
do
it
naturally-
and
there
is
no
magic
here
so
I
want
to
make
that
really
clear
like
we
all
pretend
that
every
solution
that
comes
out
is
this
magic
solution
is
just
going
to.
Oh,
my
gosh,
I'm
running
a
h,
a
stateful
database
in
production
and
I've
got
three
levels
of
fail
over
and,
if
anything
happens,
on
my
infrastructure,
it
just
automatically
works.
That's
not
a
reality.
B
Because
if
you
have
10,000
databases
that
you
want
to
run
for
developers,
most
of
those
databases
are
probably
going
to
be.
In
a
you
know:
a
class
of
dev
policy
they're
not
very
important.
They
don't
need
to
be
tuned
to
a
high
level
but
operational.
You
want
to
make
sure
that
they
all
keep
ticking
over.
So
there's
the
large
scale
in
a
broad
swath
of
simple
stateful
surfaces.
B
But
then
there's
also,
you
know
and
I
wouldn't
recommend
doing
this
but
like
if
you
want
to
run
like
SI
p
hannah
or
something
like
that
on
top
of
openshift
we're
trying
to
build
the
primitives
in
place
that
make
it
easier
and
possible
to
run
those
safely
and
then
help
people
move
up
those
zones
and
it'll
take
time.
So
this
is
the
first
step
in
openshift
33
and
in
Coober,
Nettie's
13
and
there's
a
lot
of
exciting
work
coming
in
the
future.
B
This
gets
a
little
bit
more
into
the
guts
I
apologize
for
digging
two
down
in
the
weeds,
but
an
important
part
of
Coober
Nettie's
is
making
it
easy
to
run
applications
portably,
and
so,
if
you're
somebody
who's
working
with
docker
images.
Today
you
might
be
using
those
docker
images
in
several
different
environments
or
you
might
be
testing
those
locally
and
a
really
important
part
of
Coober
Nettie's
that
we
don't
talk
about.
B
This
is
really
just
the
idea
that,
just
like
secrets,
you
can
store
those
you
can
manage
configuration
as
part
of
the
platform
or
define
it
as
part
of
your
application,
which
gives
anybody
who
comes
and
looks
at
that
config,
a
better
idea
of
where
that
config
actually
comes
from.
You
don't
have
to
use
this
it's
a
tool.
It's
a
building
block
pattern
that
can
be
composed
into
more
complex
forms.
That's
tied
with
a
little
bit
with
what
we
call
init
containers.
B
The
init
container
is
the
idea
that-
and
this
is
kind
of
the
big
difference
between
you-
maybe
the
Cooper
Nettie's
mind
set
and
where
we
all
start
with
containers,
which
is
we
all
start
with.
Containers
were
like
great
I'm
going
to
earn
my
container
and
production,
but
with
cooper,
Nettie's,
and
one
of
the
really
important
concepts
was
the
pod,
which
is
it's
not
usually,
it
might
just
be
one
container,
but
sometimes
you
need
two
containers
together.
You've
got
a
container,
that's
your
web
server
and
a
container.
B
That's
your
node.js
application
or
you've
got
cash
service
co-located
with
all
of
your
web
services,
and
so
this
idea
of
putting
containers
together
is
something
that's
at
the
bedrock
of
Cooper
Nettie's.
It
means
you
can
ship
parts
of
an
application
independently,
so
you
can
ship
the
the
web
serving
differently
from
the
log
processing
and
in
it,
containers
are
really
a
way
of
adding
a
third
point
of
variation
there,
which
is
before
all
those
containers
start
up.
B
You
may
want
to
do
something
you
might
want
to
download
the
dependencies
for
your
application
on
demand
from
an
object
store,
or
you
might
want
to
check,
to
see
whether
your
database
service
is
actually
running
before
you
start.
Your
Java
legacy
enterprise
application
because
it
doesn't
do
so
well
when
the
database
isn't
running
when
it
starts
up,
you
might
want
to
generate
a
config
file
and
so
in
eight
containers
is
really
just
an
expression
of
we
want
to
make
it
easier
for
system
administrators
application
authors
to
pull
together
the
pieces
of
real
applications.
B
Chris
talked
about
object-oriented
programming.
Well,
it's
not
just
about
services
and
micro
services.
It's
about
different
teams
working
together,
so
an
Operations
team,
that's
building
its
building
monitoring
tools
or
building
log
processing
tools
from
the
data
team
that
sit
alongside
the
web
application
team
and
trying
to
bring
all
those
together
in
a
way
that
can
split
responsibilities
down.
The
middle
is
really
important
to
ensuring
that
you
can
run
all
these
different
classes
of
applications
on
openshift
in
Coober,
Nettie's
and
then.
Finally,
the
downward
API
is
just
another
way
of
saying.
B
I've
got
all
these
containers
that
are
running
legacy,
applications
that
expect
to
find
certain
files
and
certain
locations.
So
it
might
be
the
you
know,
an
Apache.
It
would
be
the
configuration
file
for
Apache.
It
might
be
a
database
configuration
file.
The
downward
API
is
really
the
mechanism
whereby
you
can
take
some
of
the
dynamic
nature
where
you're
running
stuff
and
put
it
into
a
container
that
doesn't
have
to
care.
So
this
idea
of
separating
out
the
application
from
knowing
about
its
environment,
it
looks
at
the
filesystem
at
see
some
files.
B
It
works
the
same
in
a
development
environment.
If
you
have
those
they
gap,
those
files
in
place
as
well
as
in
a
production
environment,
and
it
keeps
the
application
somewhat
decoupled
from
environment.
Again,
it
doesn't
stop
you
from
doing
more
complex
solutions,
using
tools
like
zookeeper
at
CD
to
share
config
across
a
large
fleet
of
applique
patient's,
but
it
does
offer
a
another
point
in
the
spectrum
of
flexibility
for
running
applications.
A
big
feature
that
came
up
in
openshift
33
was
a
beer
outing.
B
So
there's
lots
of
different
ways
that
people
do
rollouts
the
simplest
one
is
you
say,
I'm
going
to
shut
everything
down,
do
an
upgrade
and
bring
it
back
up.
That's
something!
That's
been
an
open
shift
since
the
beginning,
there's
a
slightly
more
sophisticated
version,
which
is
I
want
to
do
a
rolling
update
and
rolling
updates
work
for
a
large
percentage
of
software,
but
there's
always
some
wrinkles
in
that
process.
You
don't
really
get
a
chance
to
test
the
new
stuff
in
an
actual
production
environment.
That's
actually
really
important.
B
You
know
as
much
as
we
try
to
make
development
test
staging
and
production
all
look
the
same.
They
don't
can
guarantee
you're,
probably
not
running
oracle
on
your
laptop
and
so
those
sorts
of
setups
lead
into
some
more
sophisticated
stories.
So
blue
green
services
at
bluegreen
deployments
is
something
that
again
is
possible
in
cooper
Nettie's.
It's
gotten
better
Doc
and
better
examples
better
set
up
over
the
years
to
over
the
last
couple
releases
to
make
it
easier
in
openshift,
13,
we've
added
another
concept,
which
is
the
idea
of
a
beer
outing.
B
So
you
can
use
a
beer
outing
for
a
lot
of
different
things,
but
basically
it
means
I've
got
to
back-end
services,
one
of
which
might
be
the
official
supposed
to
be
running
in
production
and
I'm,
going
to
move
a
percentage
of
traffic
to
those
other
to
another
service
like
a
test
service,
or
it
could
be
something
like
I'm
testing.
A
new
version
of
my
software
for
end-users
before
they
actually
deploy,
and
so
a
be
routing,
is
just
another
tool
in
the
toolbox
of
real
operations.
B
Teams
have
to
deal
with
real
problems
around
big
complex
applications
and
this
reuses
again
all
of
the
cooper,
Nettie's
concepts
and
hopefully
over
time.
This
kind
of
stuff
will
make
it
into
Cooper.
Nettie's
we've
been
working
a
lot
with
the
crew
bearnaise
community
to
take
these
features
and
make
sure
they're
consumable,
but
for
the
for
the
foreseeable
future,
our
goal
is
to
make
it
as
easy
as
possible
to
split
traffic
to
deal
with
real
applications
in
place
and
to
work
them
through
the
system.
B
So
there's
been
some
work
as
well
in
the
image
registry
and
starting
to
run
a
little
bit
of
time,
because
I
have
a
tendency
to
talk
a
lot.
We've
made
a
bunch
of
integration
points
available
in
builds.
I
deluded
that
where
we
have
Jenkins,
but
we
also
recognize
that
people
bring
builds
and
tools
from
outside
the
ecosystem
and
want
to
make
them
easy
to
use
with
the
platform
so
with
open
shift.
33
we've
really
focused
on
just
a
lot
of
little
improvements
that
make
openshift
a
good
target
when
external
build
systems
are
targeting
it.
B
B
The
idea
of
how
you
deploy
on
the
platform
jenkins
pipelines
becoming
even
more
integrated
in
terms
of
security
and
reliability
and
control,
and
then
just
a
general
focus
on
ensuring
that
you
can
run
open
shift
from
the
simplest
possible
deployment
easily
to
the
very
largest
scales
and
to
do
that
with
a
complex
set
of
administrative
and
networking
integrations
as
well,
as
you
know,
meeting
individual
deployments
where
they
are
and
then
in
the
future.
I
probably
spend
like
three
days
talking
about
all
this
stuff.
So
there's
a
sneak
peek
for
this.
B
You
can
come
and
find
me
at
the
dev
summit.
There's
a
number
of
developers
and
engineers
from
the
open
shift
team
will
be
happy
to
talk
everyone's
ear
off
about
all
the
great
stuff,
that's
kind
of
becoming
in
the
future,
and
then
please
come
to
the
stateful
sessions.
Talk
stateful
sets
talk
on
Wednesday
if
you're
interested
in
running
production,
eyes,
denter
prize
applications
on
openshift
and
cooper,
Nettie's.
C
D
D
B
Sorry
so
geard
was
in
a
lot
of
respects,
an
evolutionary
step
working
with
docker
and
the
container
ecosystem
to
get
a
feel
for
what
we
wanted
to
do
on
the
host.
Most
of
the
ideas
from
geard
actually
ended
up
being
part
of
Coober
Nettie's.
So
we
took
a
lot
of
the
lessons
learned
in
dealing
with
node
level.
E
B
There
was
some
lower
level
primitives
in
Coober
Nettie's,
starting
in
11
and
12,
and
what
we've
tried
to
do
is
there's
kind
of
the
easy
stuff
which
is
the
web
load
balancing
and
then
there's
all
the
insane
software
out
there.
That
makes
very
specific
assumptions
about
how
it
can
be
load
balanced
and
so
in
cooper,
Nettie's
an
open
shift.
11
there
was
the
node
ports
concept
in
open
shift.
B
33
we
enabled
the
cloud
load
balancer,
which
basically
means
you
can
use
the
same
crew,
brunetti
service
load,
balancer
in
a
cloud
environment
and
say
you
know:
I
have
I,
have
a
service
that
needs
to
be
load
balanced,
that's
TCP!
Only
you
can
enable
that
in
cloud
environments
and
then
in
I
guess
it
was
33
and
33.
We
added
the
initial
work
for,
if
you're
running
on
bare
metal-
and
you
want
to
load
balance
a
service,
you
can
set
up
your
networking
so
that
you
can
do
transparent,
highly
available
tcp
base
load
balancing.
B
E
And
when
I
mentioned
that
when,
when
Clayton
refers
to
the
router,
we
ship
with
a
default
H
a
proxy
router,
but
the
router
is
one
of
those
pluggable
components.
Because
you
are,
we
know
working
with
number
of
enterprise
customers
that
not
everybody
is
going
to
make
the
same
choices
that
we
made.
So
f5
is
one
of
our
plugins,
and
now
the
work
we're
doing
with
ingress
upstream
is
making
that
even
more
pluggable.
E
B
So
in
three
three
there's
three
or
four
different
ways
that
you
can
do:
TCP
load
balancing
they're
not
done
through
routes,
though,
because
of
the
the
slightly
different
needs
of
TCP
load.
Balancing
and
some
of
the
documentation
is
still
in
the
process
of
being
improved.
For
that
it's
tough,
because
we
actually
want
to
do
that
through
ingress
in
Coober,
Nettie's.
So
I
think
as
a
timing
thing
it's
possible
today
and
you
can
use
all
the
same
Cooper
Nettie's
primitives
that
you
want,
and
we
also
have
added
support
that
makes
it
work
on
bare
metal.
B
F
B
You
can
define
firewalls
per
per
tenant,
basically
per
project,
and
that
will
block
outgoing
traffic
from
those
containers
and
you
can
set
up.
You
know
it's
a
white
listing
blacklisting
set
up,
so
you
can
do
whatever
you
want
for
that.
The
goal
in
34
is
to
enable
no
it's
all
right.
35
is
to
enable
ingress
policy.
So
this
is
the
work.
B
That's
been
done
in
Cooper
Nettie's
around
the
the
ingress
policy
object,
the
network
policy
objects,
the
goal
for
that
for
openshift
sdn
would
be
35
and
they've
already
started
working
on
most
of
the
pieces
of
that,
and
then
there's
a
story
coming
kind
of
over.
The
next
couple
releases
is
to
make
it
easier
to
use
vendor
sdn
solutions
that
may
already
support
network
policy.
So
no
there's
no
one
answer
it's
there.
Should
it
should
be
possible
in
33
to
define
exit
traffic
and
then
ingress
traffic.
E
Think
egress
policy
is
also
a
good
example
of
how
do
you
take
a
cloud
native
platform
and
make
it
work
in
a
traditional
enterprise,
IT
environment
right?
So
you
spin
up
all
these
services
on
goober,
Nettie's
and
containers,
and
they
need
to
talk
to
existing
services
in
your
data
center.
But
you
have
all
these
IT
rules
about
who
can
talk
to
a
particular
service
and
what
IP
address
or
IP
range
they
can
come
from
and
on
goober
Nettie's.
E
That's
a
lot
of
what
red
hat
works
on
right
and
these
are
problems
may
be
that
you
know
Google
wouldn't
encounter
in
their
data
centers,
but
we
encounter
it
every
day
in
the
data
centers
that
enterprise
customers
that
we
deal
with,
whether
it's
on
the
commercial
side
or
on
the
public
sector
side.
It's
kind
of
part
of
the
you
know
bringing
Kuber
Nettie's
to
the
enterprise.
If
you
will
that
Red
Hat
specializes
in.
G
Yeah
so
I
noticed
having
followed
up
and
shipped
of
course,
from
the
beginning.
There's
been
a
few
openshift
specific
features
like
secrets
and
security
context,
so
then
ended
up
getting
migrated
into
upstream
kerber
Nettie's,
and
I
was
wondering
if
you'd
talk
a
little
bit
about
what
the
process
is
from
on
the
Red
Hat
side
for
targeting
what
might
be
a
good
fit
for
Cooper
nineties
and
then
how
you
work
with
a
community
to
find
the
Cooper
Nettie's
community
to
figure
out
what
so.
B
10
mission
was
run,
containerized
applications
at
scale,
and
we
accomplish
that
and
the
core
openshift
30
goal
at
the
same
time
was
add
a
policy
multi-tenant
layer,
so
we
could
run
multi-tenant
containers
so
and
then
we
also
knew
that
we
had
a
whole
bunch
of
requirements
like
I
want
to
be
able
to
roll
updates
to
applications
as
crazy
concept.
I
know,
like
I,
have
to
update
my
applications.
B
That
was
something
that
we
added
as
part
of
open
shift
in
10,
because
it
was
not
time
to
do
it
in
cube,
there's
no
bandwidth,
and
so
now
what
we've
done
is
we
kind
of
work
through
this
processes?
If
it's
a
feature
that
will
benefit
everybody
in
the
entire
world,
we
try
to
put
it
into
court.
Cooper
Nettie's,
and
so
we
think
of
multi-tenancy
is
a
good
example
of
that
Cooper
Nettie's
has
to
be
multi-tenant.
If
the
core
isn't
multi-tenant
aware,
you
can't
really
end
up
having
security.
That's
partially.
B
Why
openshift
is
different,
is
a
different
set
of
source
code
or
is
built.
You
know
its
downstream
from
Cooper
Nettie's
it,
because
the
only
way
to
apply
all
of
that
security
policy
is
to
rebuild
cube
to
build
in
the
pieces
of
Cuba,
and
so
our
goal
is
to
actually
move
all
of
that
into
Cooper
Nettie's
over
you
know
several
releases.
Egress
policy
is
actually
a
good
example
of
experimentation.
B
As
these
features
make
it
into
cube,
it's
kind
of
insulating
people
from
that
that
cost
and
and
on
some
of
the
other
features
in
the
middle,
it's
actually
really
a
tough
choice.
So
a
good
example
is
the
Service
Catalog
work.
This
is
something
that
a
bunch
of
companies,
google
and
IBM
fujitsu,
and
I
believe,
some
pivotal
folks
involved
as
well
on
a
large
number
of
companies
coming
together
to
say,
cooper
Nettie's
needs
a
really
great
service,
catalog
concept
that
allows
you
to
pick
services.
B
So
you
don't
have
to
you
want
to
go
stand
up
everything
yourself,
but
you
can
consume
something.
An
IT
organization
is
provided
for
you,
that's
something
we're
from
the
very
beginning.
We
believe
the
best
place
to
do
that
is
in
the
Cooper
neighs
community,
and
it
may
not
actually
be
part
of
Coober
Nerys
core
it'll
be
a
key
extension
that
we
expect
most
people
to
run
with
that
was
kind
of
in
the
middle
kind
of
choice.
Yeah.
B
E
So
we
did
come
out
early
in
open
shift
with
concepts
like
routing
like
deployment
configuration
like
you
know,
authorization
that
didn't
actually
yet
exist
in
Coober
Nettie's
10
11
12,
but
then
we
worked
to
bring
those
upstream
and
in
bringing
that
upstream.
We're
now
committed
to
making
sure
that
our
initial
implementations
are
sort
of
subsumed
or
integrated
with
the
upstream
and
again,
our
commitment
is
to
support
this
over
multiple
years
and
multiple
risk.
I.