►
From YouTube: Building an Open Source Cloud - CodeConf 2016
Description
Presented by Elizabeth K. Joseph
Over the past several years companies around the world have starting using OpenStack and working with partners to provide internal cloud solutions. However, these solutions leverage proprietary components, from platforms developed in house to manage resources to working with vendors who come in with their own solutions. It doesn't necessarily have to be this way. Over the past year I've worked on two major projects that leveraged the official, open source Puppet modules for OpenStack to produce fully open source OpenStack clouds use for training and in production. The tooling is relatively easy to learn and in both cases the teams developing the clouds it were distributed. I'll be diving into the basics of both these projects, challenges the teams working on them faced and overcame, and how we've been able to work with the OpenStack project directly to improve the deployment story for all users.
About CodeConf
CodeConf improves the software community by providing a forum for thought-provoking talks and forging social connections. The fourth installment of the CodeConf series took place in Hollywood in 2016. This year's event focused on systems engineering projects, practices, and programs in the open source community.
For more information on this year's CodeConf, go to:
https://codeconf.com/
A
Alright,
so
I'm
here
to
talk
to
you
about
building
an
open
source
cloud,
I've
got
20
minutes,
so
you
won't
actually
be
able
to
build
one
by
the
end
of
this
talk
but
I'm
hoping
to
point
you
in
the
right
direction.
So
you
sort
of
know
what
tooling
you're
going
to
need
when
you
embark
on
this,
so
first
I'm
going
to
explain
what
I
mean
by
cloud.
So
you
saw
yesterday
with
the
Cooper
Nettie's
debt
demo.
There
was
a
Google
Cloud
and
then
a
lot
of
you
I'm
sure
very
familiar
with
Amazon
clouds.
A
The
idea
is,
if
you
want
to
stop
using
a
third-party,
you
can
start
building
a
cloud
internally,
and
that
is
what
OpenStack
is.
Who
here
is
familiar
with
the
OpenStack
project?
All
right,
that's
a
pretty
good
chunk
of
the
audience.
So
OpenStack
was
founded
in
2010,
which
makes
it
a
pretty
young
project
for
a
massive
infrastructure
project,
and
it's
still
it's
written
to
build
clouds.
It's
written
in
Python.
There
are
a
variety
of
reasons
for
that.
A
A
There
are
over
a
thousand
projects
in
the
repositories
that
we
maintain
now,
and
these
are
projects
that
allow
you
to
mod
early
module
early,
build
your
cloud,
so
you
can
add
networking
and
compute
sections
to
your
cloud,
which
are
pretty
standard,
and
then,
on
top
of
that,
you
can
do
things
like
block
storage,
object,
storage
and
then
add
a
bunch
of
different
things
like
databases
as
a
service.
Dns
is
a
service
and
the
number
of
projects
is
always
growing
in
sort
in
this
infrastructure.
That
sort
of
is
the
OpenStack
project.
A
There
is
also
this
vast
marketplace
of
vendors.
This
has
been
the
truth
since
pretty
much
the
beginning
of
the
project.
You
have
companies
like
my
employer,
a
hewlett-packard
enterprise
and
then
a
bunch
of
our
competitors
all
getting
together
to
work
on
this
project.
So
there's
a
huge
market
place
of
vendors.
A
Who
will
do
everything
from
telling
you
how
to
do
really
basic
stuff
in
OpenStack
and
being
just
on
call
if
you
need
some
help
with
your
deployment
through
actually
buying
a
data
center
and
pretty
much
rolling
in
and
installing
OpenStack
for
you
and
managing
it
completely?
So
you
have
a
lot
of
options
in
its
vendor
ecosystem,
but
when
I'm
here
to
tell
you
is
that
it
once
back
is
mature
enough
today
that
you
don't
necessarily
need
that.
A
Don't
tell
my
employer
so
a
little
bit
about
me
I'm,
as
the
introduction
said,
I'm
an
automation
and
tools,
engineer
at
HP
I
was
hired
to
work
directly
on
the
open-source
OpenStack
project.
So
we
in
the
team
that
I
work
on
we
run
the
infrastructure
for
the
project.
That
means
we
run
the
continuous
integration
system,
all
the
wiki's
and
the
bots,
and
the
ether
pads
and
everything
that
developers
interact
with
on
a
day-to-day
basis.
A
A
So
as
I
started,
sort
of
preparing
for
giving
this
talk
and
then
getting
a
deeper
understanding
and
some
of
the
projects
that
were
working
on
about
what
kinds
of
OpenStack
clouds
are
out
there,
I
was
able
to
interview.
Several
companies
who
are
running
OpenStack
in
part
of
this
was
sort
of
to
get
an
idea
of
what
sort
of
OpenStack
clouds
are
out
there.
What
components
people
are
using
another
part
of
it
was
that
in
the
OpenStack
infrastructure
team,
we
are
the
users
of
a
lot
of
clouds.
A
A
This
has
led
us
to
discover
a
lot
of
different
things
about
OpenStack
and
about
how
it
can
be
configured
every
vendor
that
we
work
with
provides
different
services.
Some
of
them
are
fully
open
source
and
part
of
OpenStack.
Some
of
them
are
proprietary
services,
the
DNS
that
we
use
a
proprietary
service,
but
my
sequel
database
as
a
service
tooling,
that
we
use
is
open
source,
so
different
companies
are
choosing
different
infrastructures
to
different
parts
of
the
infrastructure
to
build
their
clouds.
A
Additionally,
we
started
an
infant
project
so
that
we
would
no
longer
just
be
a
consumer
of
other
people's
clouds.
We
were
given
a
rack
of
hardware
by
HPE
and
said:
here's
the
rack
of
hardware
in
a
data
center,
you
can
install
opens
back
on
it
if
you
want
and
run
tests.
So
we
did
a
sprint
earlier
this
year,
where
we
actually
got
that
running
and
promptly.
They
moved
all
of
our
stuff
to
another
data
center,
which
was
in
Houston
and
flooded.
A
We've
sort
of
had
a
rough
time
of
our
of
our
infra
cloud
project.
But
the
point
is
we
actually
did
build
an
openstack
cloud
and
we're
getting
back
on
our
feet
there,
and
so
one
of
the
really
important
things
that
I've
learned
in
this
is
that
configuration
management
super
important
to
the
maturity
of
this
project.
A
So,
as
I
mentioned,
we're
not
going
to
completely
build
a
cloud
today,
but
I
do
want
to
put
give
you
some
pointers
and
things
you're
going
to
consider
if
you're
starting
to
build
one,
so
installing
OpenStack
used
to
be
really
really
hard.
Even
today,
the
install
documentation
for
OpenStack
doesn't
really
mention
configuration
management.
They
say
types
is
my
sequel
command
edit
this
config
file,
and
if
anyone
is
doing
that
sort
of
thing
in
production
these
days,
I'm
sorry,
you
really
want
to
be
using
configuration
management
and
tooling.
A
That
allows
you
to
never
ever
touch
the
my
sequel
command
line
ever
again,
which
is
a
lovely
tool,
but
in
production
you
really
don't
want
to
be
using
something
like
that.
It's
error-prone
and
you
really
don't
want
to
be
wasting
your
time.
Configuring
simple
things
like
my
sequel
or
a
queuing
service
or
Apache.
That
has
all
been
automated
for
you
already
and
there
are
lots
of
puppet
modules
and
lots
of
availability
out
there.
So
you
don't
have
to
worry
about
these
simple
things
anymore.
A
Also
early
days
of
OpenStack,
a
lot
of
the
configuration
tooling
was
proprietary
and
very
like
vendor
and
distribution
dependent,
so
you'd
go
to
a
company
like
red
hat
or
canonical.
Red
Hat
would
give
you
Red
Hat
OpenStack
canonical
would
give
you
12
OpenStack,
and
their
tooling
was
crafted
very
specifically
towards
those
different
operating
systems.
A
lot
of
the
tooling
early
on
was
also
proprietary,
so
you
couldn't
really
build
your
open
source
cloud
unless
you
are
willing
to
run
those.
My
sequel
commands
write
your
own
scripts
write
your
own
modules.
A
So
in
the
configuration
management
space
there
are
four
key
configuration.
Management
systems
are
now
in
the
OpenStack
tree.
I
mentioned
those
thousands
of
projects,
and
these
are
in
that
thousands
of
projects
collections,
so
I
gave
example
names
here
for
sort
of
what
you'd
be
looking
for
in
this
get
OpenStack
torg
list.
So
for
puppet
you
have
puppet
modules
and
they're
sort
of
names
with
puppet
and
then
the
service
name.
A
Your
chef
cookbooks
have
a
name
similar
to
this,
so
they're,
seeing
like
OpenStack
compute
rather
than
the
project
name
of
Nova,
the
ansible
playbooks
have
another
format,
juju
charms
yet
another.
So
once
you
pick
your
configuration
management
system,
you
can
go
to
get
that
OpenStack
that
org
and
find
the
components
that
you
want
to
use
in
your
cloud,
so
whether
it's
compute
or
networking,
dns
and
various
things,
but,
let's
be
honest,
installing
OpenStack,
it's
still
really
hard
having
configuration
management
is
really
only
part
of
the
story.
A
You
still
need
to
make
a
lot
of
decisions
about
what
your
cloud
is
going
to
do
and
who
is
going
to
do
that.
So
you
first
need
to
build
a
team.
This
team
needs
a
few
key
people
in
it.
You
need
some
really
strong
systems.
Administrators
who
know
a
lot
about
Linux.
These
people
need
to
be
able
to
dig
down
into
stack
traces
know
a
lot
about
networking
tools
so
that
when
networking
stuff
goes
wrong,
you
can
actually
talk
to
your
network
administrator
in
a
way
that
makes
sense
to
them.
A
You
need
to
be
able
to
read
log
files,
look
at
Python
bugs
and
stacked
written.
You
know
the
errors
to
then
talk
to
your
Python
developers
about
what's
what's
gone
wrong.
Ultimately,
you
need
to
know
about
scaling
and
coming
up
with
backup
plans
and,
in
general,
just
being
really
knowledgeable
about
how
to
build
a
large
infrastructure
that
has
a
lot
of
fault,
tolerance
and
people
are
really
depending
on.
You
also
need
some
network
engineers.
A
The
documentation
gives
you
a
few
options,
so
it
gives
you
a
few
demonstrations
of
things
you
might
want
to
do
with
networking,
but
you
have
a
whole
lot
of
options
which
I'll
talk
about
in
a
little
bit,
so
you
definitely
want
to
have
someone
who's
really
good
at
networking
on
your
team
who
can
make
intelligent
cisions
there,
the
next
one
I
learned
sort
of
the
hard
way
you
want
to
have
a
really
good
relationship
with
your
data
center
text
they're.
The
ones
who
are
there
with
your
computers
and
since
OpenStack
is
very
modular.
A
You'll
find
a
lot
of
your
services,
live
on
different
machines,
so
as
you're
working
through
that
getting
at
the
fault,
tolerance
up
and
making
sure
that,
as
your
system
is
fully
AJ,
being
able
to
contact
those
people
and
sort
of
know
who
they
are
rather
than
just
submitting
tickets.
It's
going
to
be
super
helpful
because
you
learn
that
you
sort
of
speak
a
different
language
than
the
data
center
text.
They
know
a
lot
about
hardware.
A
First,
you
need
to
decide
why
you're
using
this
cloud,
are
you
replacing
another
tool
and
what?
What
is
this
necessary
for
that?
Are
you
building
a
new
infrastructure
and
you
need
to
understand
from
your
users
what
they're
going
to
need?
For
instance,
you
need
a
lot
of
compute
power,
which
means
a
lot
of
processor
and
ram.
Are
you
processing
a
lot
of
data?
Do
you
need
a
lot
of
storage
space?
What
kind
of
storage
space
do
you
want?
A
You
can
have
either
one
or
you
can
have
both,
but
there's
going
to
be
costs
involved
with
these.
So,
of
course
your
boss
is
going
to
say
they
want
it
to
be
fast
and
reliable,
but
you
need
to
be
realistic
about
what
you
can
accomplish
and
what
actually
makes
sense
for
the
business
and
then
have
the
right
conversations
about
that.
So
you
can
plan
accordingly.
A
This
is
something
that's
really
hard
to
change
later,
but
it's
and
it's
really
hard
to
plan
for,
because
you're
not
really
sure
in
the
beginning.
What
you're
going
to
need?
Networking,
wise
and
OpenStack
has
so
many
options
for
networking
that
it
can
be
a
bit
overwhelming,
which
is
why
I
really
want
you
to
have
a
network
engineer
on
your
team.
A
Do
you
want
them
to
be
able
to
talk
to
each
other
directly
and
how
fast
you
want
them
to
be
able
to
talk
to
each
other,
because
that
will
change
how
you
do
your
internal
networking,
whether
using
open,
V,
switch
or
Linux
bridging
and
how
these
systems
talk
to
each
other
and
then
are
you
using
a
lot
of
physical
hardware
that
OpenStack
hooks
into
with
the
plugins?
So
do
you
have
a
bunch
of
switches
and
routers
that
you're
going
to
use
oh
pues
with
OpenStack,
are
using
VLANs
or
VX
lands?
A
This
will
be
a
huge
health
in
your
secure,
ready
profile
in
your
organization,
but
also
just
in
general,
like
reducing
the
burden
on
your
network,
I
mean,
if
things
don't
need
the
network,
you
shouldn't
give
them
the
network,
and
then
you
also
want
to
think
of
what
sort
of
backup
strategy
you
want
to
have.
If
you're
running
a
lot
of
compute
instances
that
are
only
processing
data,
you
probably
don't
want
to
back
up
those
instances.
Those
instances
will
be
treated
as
ephemeral.
You
can
kill
one
and
another.
A
One
will
pick
up
in
its
place
and
start
feeding
the
data
into
the
data.
The
data
store,
whether
it's
a
file
system
or
a
database.
So
you
don't
want
to
backup
your
instances,
because
that
would
be
a
waste
of
time
and
waste
of
resources.
You
do
want
to
make
sure
you
have
a
replication
on
your
databases
that
your
block
storage
base
has
some
sort
of
replication
process,
whether
using
raid
or
an
ass,
or
what
not
the
object.
Storage
component
of
OpenStack
has
fault
tolerance
built
into
it.
A
So
you
want
to
make
some
important
decisions
if
you're
using
object,
storage
about
what
kind
of
configuration
you
want
there
for
that,
you
also
want
to
think
about
where
your
backups
live
in
a
perfect
world.
We
all
have
our
backups
off-site.
So
when
things
go
wrong,
you're
not
really
in
trouble
in
a
huge
way,
but
you
have
to
consider
what
kind
of
bandwidth
you
have?
How
realistic
is
it
to
have
up-to-the-minute
backups
off-site
and
then
what
backups
you
can
have
on
site
and
transfer
them
to
pop
off
site?
A
A
You
also
want
to
consider
failover
you'll
need
to
think
about
how
you're
structuring
your
OpenStack
deployment
or
really
any
cloud
deployment
I've
seen
so
many
people
deploy
in
one
region,
so
it
whether
it
be
a
data
center
or
a
single
rack,
and
they
use
a
lot
of
the
OpenStack
default.
So
you'll
always
know
what
that
what
what
versions
are
sorry?
A
What
region
was
your
initial
verte
region,
because
it
has
all
the
default
names
in
it,
and
then
the
second
region
actually
has
like
region
two
names,
but
you
probably
want
to
think
about
this
before
you
is
all
the
defaults
on
your
first
region,
so
think
about
region
and
thinking
about
scaling
early
on.
It's
really
important
when
you're
trying
to
start
this
out,
there's
also
the
idea
of
having
automatic
or
manual
failover
again
in
a
perfect
world.
We
all
want
automatic
failover.
We
never
want
to
get
called
in
the
middle
of
the
night.
A
We
want
everything
to
work
perfectly
and
failover
automatically,
but
that
has
a
huge
cost
to
it.
Even
though
OpenStack
is
built
to
be
highly
available,
you
have
a
lot
of
fault,
tolerance
that
needs
to
be
checked.
You
need
to
make
sure
it
doesn't
get
split,
brain
like
not
knowing
who
is
the
master
between
your
regions?
You
need
to
do
a
lot
of
testing
so
early
on
a
lot
of
deployments,
end
up
being
quite
manual,
and
then
you
start
automating
the
really
simple
things
when
it
comes
to
failover
and.
A
I
wanted
to
spend
the
last
few
minutes
here
to
talk
about
contributing
to
open
source.
This
is
a
very
open
source
conference
here,
so
it
may
be
a
lot
of
repeat
for
a
lot
of
you,
but
in
almost
every
OpenStack
deployment
I've
seen
companies
want
to
do
the
really
simple
thing
of
just
patching
things
inside
of
their
own
infrastructure.
They
don't
want
to
deal
with
the
upstream
OpenStack
project.
A
They
just
want
to
patch
it
and
then
get
back
to
work.
I
think
we
all
know
the
technical
debt
that
this
causes,
but
it's
even
magnif,
it's
magnified,
even
more
in
a
project
like
OpenStack
opens
egg
is
huge.
It
has
a
lot
of
components
and
it's
developed
really
really
fast
by
these
hundreds
of
companies
who
are
working
on
it.
So
there's
a
release
every
six
months
and
a
lot
changes
in
those
six
months.
A
So
the
chances
of
your
patch
that
you
applied
in
the
version
that
you're
running
in
production,
applying
in
the
next
version
of
OpenStack,
become
smaller
and
smaller,
with
each
version
that
comes
out
and
significantly
so
in
a
project
like
OpenStack.
So
you
don't
really
want
to
be
carrying
all
those
local
patches
and
you
want
to
engage
with
the
community,
even
though
it
takes
longer-
and
this
is
going
to
be
hard
sell
to
bosses
because
they
just
want
to
get
your
get
their
work
done
and
say,
like
just
fix
it
and
move
on.
A
But
that
team
of
Python
developers
on
your
team
should
also
probably
be
the
ones
your
liaisons
to
the
open
source
project
and
OpenStack.
They
should
be
committing
the
changes
that
you're
making
internally
to
your
internal
product.
They
should
be
working
with
the
OpenStack
community
to
make
sure
that
features
that
you
have
in
OpenStack
and
that
you're
using
in
your
organization,
are
remaining
in
OpenStack
and
are
maintained,
and
that
may
mean
adding
more
developers
onto
it
to
work
upstream.
But
avoiding
this
technical
debt
is
a
huge
huge
thing.
A
The
other
thing
I'll
mention
because
it's
my
baby
and
my
project,
of
course,
I
work
on
the
continuous
integration
system
for
OpenStack
and
just
like
we
heard
about
rest
yesterday,
we
test
all
of
the
changes
before
they
land
in
our
git
repository.
This
has
been
important
to
us
from
the
beginning,
because
we
have
hundreds
of
companies
working
on
OpenStack.
A
A
lot
of
those
companies
are
competitors,
so
if
I
landed
a
bad
patch
and
I'm
at
HP,
the
person
over
there
who's
working
at
IBM
is
not
going
to
be
happy
really
like
when
competitors
stall
each
other
on
a
project
that
is
like
the
recipe
for
disaster.
So
we
want
to
make
sure
everything
is
tested
and
by
contributing
to
upstream
you
get
to
take
advantage
of
that
testing
infrastructure.
A
So
we're
running
a
bunch
of
continuous
integration
testing
on
everything
making
sure
everything
is
passing
for
the
basic
things
that
we
test
in
doing
unit
testing,
functional
testing
and
then
integration
testing,
so
that
even
if
you're,
just
working
on
a
really
small
component
of
OpenStack,
you
end
up
sure
that
it
doesn't
break
another
part.
So
you
commit
submit
code
to
say
the
compute
module
of
OpenStack
and
then
you're
like
I.
Only
work
on
commute
I,
don't
compute
I,
don't
know
anything
about
networking,
but
the
CI
system
will
test
it
against
networking.
A
So,
in
addition
to
all
the
robots
that
we
have
making
sure
your
code
is
good,
you
also
have
the
expertise
of
experts
in
the
community
who
are
reviewing
your
code
by
policy.
We
need
to
reviewers
to
review
your
code
before
it
can
be
approved.
So
you
have
two
people
who
know
about
scaling
who
understand
the
OpenStack
infrastructure
and
can
review
your
patch
and
offer
guidance
to
to
help
improve
that.
If
you
want
to
add
a
new
feature,
these
same
people
are
also
there
to
help
guide
you
to
what
makes
sense
for
the
OpenStack
project.
A
A
What's
going
on
in
this
review,
but
I
submitted
this
review
to
the
puppet
config
while
I
was
working
on
the
puppet
stuff
to
get
our
deployments
running
and
you
can
go
through
this
review
and
see
the
conversation
we
had
and
a
bunch
of
tests
that
were
run
and
they're
reporting
on
those
tests
so
I'll
be
around
at
lunchtime
and
the
rest
of
the
day.
If
anyone
has
any
questions
once
a
chat,
so
hello,
I'm
very
shy.
So
please
say
hello.
Thank
you.