►
From YouTube: Repeatable Database Creation Demo (2021-07-14)
Description
https://docs.google.com/document/d/1jGZow42nbmSOuK0TDv9WUHt9jkpUHDrt7acNL0R9DWs/edit (internal)
A
Hey
everyone
welcome
to
the
roof.
First,
reputable
db
creation,
demo
meeting.
We
don't
have
a
lot
to
demo
or
really
anything
to
demo
since
it's
the
first
meeting,
but
I
just
wanted
to
kind
of
introduce
the
project
to
everyone.
I
think
I've
talked
to
everyone
individually,
so
maybe
you're
already
familiar
with
it,
but
and
maybe
discuss
a
little
bit.
What
we're
going
to
be
doing
with
this
meeting
moving.
A
Forward,
so
first
is
that
I
moved
the
scope
from
the
google
doc
to
the
parent
epic,
and
if
you
have
any
questions
about
the
scope
or
if
there's
anything,
you
disagree
with
just
let
me
know-
and
you
know
we
can
probably
change
this
as
as
we
go,
it's
not
like
it's
set
in
stone
or
comment
on
the
epic
number
three
just
wanted
to
set
up
some
goals
for
next
week.
I
want
to
close
out
the
planning,
epic.
A
I
want
to
create
a
kind
of
a
very
basic
pipeline,
which
will
be
just
the
scaffolding
of
what
it's
going
to
look
like
for
running,
terraform
and
ansible,
and
we
won't
probably
have
all
of
the
infrastructure
created,
but
at
least
like
to
get
like
a
couple
of
nodes
built
and
a
very
basic
like
no
op
ansible
run
just
so
that
we
have
everything
in
place
for
people
to
contribute.
Also,
I've
talked
to
everyone
individually
about
using
omnibus.
A
A
A
bit
it
sounds
like
what
we'll
do
is
we'll
do
a
quick
poc
if
we
run
into
any
roto
blocks,
or
we
think
that
there
are
good
reasons
not
to
zombie
bus,
we're
just
not
going
to
use
it
and
we'll
just
see
we'll
just
see
where
it
takes
us,
and
I
think
I
think
most
importantly,
the
reason
why
I
like
to
try
omnibus
is
because
I
think
it's
going
to
make
things
easier
for
us.
If
it
doesn't
make
things
easier
for
us,
then
I
don't
see
any
reason
to
use
it
for
the
demo.
A
I
just
wanted
to
show
that
we
have
the
project
created.
I
also
created
a
runbook
for
creating
new
projects
and
infrastructure,
since
I
had
to
go
through
this
from
scratch,
and
I
created
a
project
template
that
we
can
use
moving
forward
for
projects
and
infrastructure
that
sets
up
the
ci
jobs
for
mirroring
and
everything.
So
hopefully
that'll
be
easier
next
time
for
the
directory
layout.
I
I'm
pretty
much
just
going
to
copy.
A
Where
is
what
I
see
other
people
doing,
which
is
to
have
an
ansible
directory
in
the
terraform
directory
for
the
terraform
module?
I
think
we'll
have
to
create
either
our
own
base
module
for
the
instance
or
just
somehow
consume.
What
get
is
doing.
I
don't
think
we'll.
Another
option
would
be
to
maybe
create
this
module
in
the
modules
you
know
create
a
new
module
in
a
separate
project.
Does
anyone
have
opinions
on
this
like
what
to
do
about
like
a
base
module
for
this?
A
Do
it
should
we
create
a
new
base
module
in
the
terraform
modules
subgroup,
or
should
we
have
it
with
the
project
or
since
grant
just
joined
we're
on
item
number
one
under
the
demo
heading
and
talking
about
like
the
base
module
for
creating
the
instance?
I
know
that
g-e-t
has
this
like
base
module
that
every
gcp
reference
architecture
module
uses
which
just
really
just
like,
creates
like
a
very
basic.
You
know
linux.
You
know
linux
server,
so
any
opinions
on
that.
B
Give
my
thoughts,
if
you
want
sure
yeah
I
mean
I
mean
as
we
discussed
directly,
it
depends
on
what
you're
looking
to
do.
If
you're
just
wanting
to
set
up
a
vm
like
what
we're
doing,
then
you
probably
will
get
pushed
back
like
sid
has
got
a
bug,
bear
around
be
creating
effort
when
it's
maybe
not
required,
so
you
might
get.
You
might
get
some
pushback,
but
if
you're
doing
something
that's
different
and
unique,
then
you
have
justification
there
to
go
off
and
do
something
on
your
own.
I
guess
so.
A
Like
assigning
to
specific
subnets,
maybe
and
how
subnets
are
created,
we're
gonna
need
to
like
link
that
together.
So
I
don't
know
we'll
we'll
we'll
take
a
look
to
see
if
it's
possible,
I
think,
like
yeah.
I
agree
like
it's
bad
to
just
like
repeat
work.
That's
already
done,
but
there's
also
at
least
for
this,
like
base
server
module,
there's
just
not
a
lot
to
it
right.
B
B
That
the
the
issue
with
aws
is
a
little
bit
different
because
aws
literally
proffers,
you
must
have
this
x
number
of
subnets
for
kubernetes
classes
to
work
or
stuff
like
that,
whereas
in
other
cases
it's
just
it's
just
the
fear
of
being
too
opinionated
about
something
which
you
know
everyone
may
want
that
don't
have
their
own
design,
whereas
also
again,
it
needs
to
be
a
standard
subnet
design.
So
if
there's
something
along
those
lines
that
would
just
be
applicable,
that
would
be
common
sense
for
everybody
to
use.
B
A
That
sounds
good,
okay
and
the
terraform
state
and
environments
grant.
This
is
also
something
that
one
would
be
interested
in.
Your
input
on.
I
didn't
talk
to
you
about
like
what
you've
explored
so
far
for
managing
different
environments
and
debt.
I
guess,
I
guess,
forget
it's
sort
of
like
you're
not
having
to
manage
multiple
environments
yet,
but
maybe
oh
you
do
so.
Are
you
using
workspaces
for
that.
B
We're
actually
we're
kind
of
we're
we're
not
using
workspaces,
no
and
terraform
workspaces.
We
found
to
be
a
little
bit
more
limited
than
what
was
maybe
you
wanted
to
do
so
to
speak.
The
key
thing
with
us
is
that
we
have
set.
We
just
have
several
folders
for
each
environment.
That's
that's
what
we've
done,
because
I
think
I
found
that
cleaner
and
easier
to
work
with
for
your
workspace.
B
A
B
There's
the
debate,
the
top
level
conflict
that
gets
to
get
terrified
modules
will
will
consume.
But
if
you
want
to
do
workspaces,
yeah
that
that
would
be.
That
should
be
that.
I
don't
see
a
reason
why
that
would
work
and
for
states
we
made
get
before
git
lab
had
the
ability
to
store
terraform
states.
So
we
store
an
object,
storage
bucket.
B
B
A
A
B
Interface
between
that,
so
it's
a
perfectly
valid
option
for
you
to
explore.
If
you
want
to
go
down
that
road,
instead
of
having
to
create
an
object,
storage
bucket
each
time
I'll
bet
to
my
knowledge,
yeah
it's
per
project,
but
you
can
add
a
prefix
entire
form
that
will
store
the
state
in
a
folder
within
the
object
stores,
yeah.
A
A
Yeah
yeah,
maybe
we'll
just
do
that-
I
mean
that
that
puts
the
bucket
in
ops.
I
forget
if
we
created
a
terraform
bucket
in
ops
yet
for
the
gitlab
instance
there,
but
we
could-
and
that
also,
I
think,
is
better
for
keeping
your
state
file
in
a
separate
project
from
where
the
infrastructure's
running.
So
it's
probably
a
good
thing
to
do,
and
then
the
last
point
here
is
just
purine
and
subnet.
So
we
need
to
if
we're
going
to
appear,
ops
and
we'll
have
to
pure
ops.