►
Description
https://docs.google.com/document/d/1uvNxnPhV6FTETX3_X0-qzd-lIbif_AL_o94XZnaPpBA/edit (internal only)
A
A
A
A
I
put
a
lot
of
notes
in
the
agenda.
I
don't
think
we
need
to
walk
through
all
of
them,
but
I'm
more
curious.
What
you
know
alejandro
and
ahmad
I'd
like
to
take
your
temperature
on
where
you
sit
right
now
with
this
and
whether
you
think
we
should
continue
trying
to
invest
time
and
using
get.
I
know
that
we
trying
to
push
a
lot
of
changes
upstream.
B
If
I
could
change
get
so
yeah,
it
is
my
impression
that
we
could
just
grab
what
we
need
at
the
current
state
of
get
and
my
concern
initially
with
doing
that
was
losing
on
the
improvements
that
the
get
team
will
do.
But
what
I,
what
seems
to
be
my
impression
now
is
that
the
direction
they
move
towards,
it's,
not
the
one
that
we
moved
towards.
B
D
C
Like
I
said,
I
think
the
current
stats
like
say
we
do
focus
on
the
reference
architectures
and
we
do
focus
on
what's
most
usable
to
the
biggest
audience.
I
suppose
so,
like
you
say
when
it
comes
to
changes
that
you
might
need
which
are
for
dot
com.
I
think
we've
said
from
the
beginning:
dot
com
is
its
own
monster.
You
know
those
things
because
of
the
scale
and
size
that
it
is
they're,
not
necessarily
things
that
normal
reference,
even
50,
000
that
we
need
to
worry
about.
C
C
You
kind
of
need
to
do
it
yourselves
now,
because
you
know
if
there's
a
good
way
of
actually
keeping
some
of
it
up
to
date
would
be
nice,
but
certainly,
I
think,
there's
a
lot
of
changes,
certainly
just
reading
through
the
documentation.
Here
there
is
a
lot
of
changes
that
would
be
hard
for
us
to.
I
think
it's
just
hard
for
us
to
prioritize
or
like
say
keep
it
in
a
way
that
the
majority
of
cases
are
going
to
use.
A
Yeah,
I
think
this
is
going
to
be
more
and
more
difficult
as
more
people
use
get
for
reference
architecture.
I'm
not
sure
how
I
mean,
I
think,
like
it's,
a
charter
of
get
to
maintain
backwards
compatibility,
and
this
can
be
really
tricky
with
terraform,
because
terraform
is
not
a
very
good
tool
for
composability
like
when
you
have.
You
know
a
lot
of
a
lot
of
different
uses
and
it's
just
not
flexible
that
way.
So
yeah,
I
think
that's
going
to
be
a
challenge.
A
C
We've
started
having
that
conversation
a
little
bit
now
and
how
it's
going
to
affect
us,
and
it's
like
we
say
it's
one
of
those
things
that
over
time
can
just
get
worse
and
worse
as
well
as
well
as
well
for
us
actually
being
able
to
test
it
all.
So
it's
a
it's
a
big
thought
at
the
moment
we're
trying
to
correctly
work
out
how
to
do
that.
A
Okay,
so
on
item
number
seven,
I
kind
of
like
gave
us
the
options
for
moving
forward.
I
first
of
all,
I
think,
on
the
terraform
side
of
things:
we're
not
really
using
a
whole
lot,
there's
the
gcp
instance
module
and
then
the
wrapper
modules,
which
are
really
just
modules
that
reference
the
gcp
instance
module.
A
B
100
that
we
should
bring
stuff
to
our
project
because
we're
going
to
change
a
lot
of
stuff,
but
for
terraform
I
feel
less
strongly
about
it
like
because
it's
not
just
the
gcp
instance
model.
We
also
we're
also
using
the
reference
architecture
stuff
right,
which
provisions
the
number
of
bugs
of
p
events
and
the
number
of
patronage
boxes.
A
Yeah,
but
this
is
just
a
wrapper
right
over
like
it's
just
sets
up
variables
for
it's
a
it's,
basically,
a
wrapper
module
so
that
you
can
call
the
gcp
instance
module
multiple
times
right
now
it
is
yeah.
I
guess
I'm
wondering
how
this
will
work
with
with
your
nap.
Changes
like
that'll
have
to
be
done
in
a
way
that
makes
it
so
that
we
have
one
that
per
environment
where
one
that
per
cluster-
and
I
think
in
in
the
get
terms
that
would
be
like
one,
not
per
prefix
right
yeah.
Yes,.
A
A
A
Yeah,
I
don't
know
well,
okay,
so
maybe
it
sounds
like.
Maybe
we
should
just
continue
to
use
the
terraform
can
get
for
now
and
like
we
can.
We
can
check
in
again
in
like
a
week
or
so
to
see
if
we're
still
happy
with
that,
it's
so
easy
for
us
just
to
pull
it
out.
If
we,
if
we
have
to
so
and
we
can
use
our
integration
branch.
So
it
sounds
like
that's
what
you
prefer
for
now.
It's
just.
B
No,
I
was
actually
kind
of
agreeing
with
you
yeah.
Sorry,
I
didn't
sorry.
I
didn't
express
myself
correct.
Okay,
I
was
gonna
agree.
My
point
was
that,
because
the
nat
thing
is
better
implemented
in
the
get
project
but
the,
but
that
is
not
a
a
priority
for
the
get
for
the
quality
team.
Let's
just
bring
what
we
need.
Let's
just
cop
copy,
stop
importing
get
copy,
the
things
that
we
that
we
need
and
just
work
on
our
own
repository.
B
E
Well,
so
far
from
from
what
I've
seen
I
haven't,
really
I've
already
run
into
any
trouble
using
terraform
as
it
is,
as
it
stands
right
now,
so
not
sure
how,
in
the
future
how's
gonna
be
so
yeah.
I
agree.
We
should
wait
a
little
see
how
our
change
our
usage
is.
Gonna
differ
from
get
and
except
accordingly,
but
overall-
and
this
is
just
my
feeling-
I'm
not
really-
I
feel
the
indirection
of
using
get
behind
behind
the
scene
is-
is
a
bit
too
much.
E
No,
no,
no
actual
reason
behind
it,
but
the
the
things
that
you're,
just
the
level
of
indirection,
is
not
making
me
very
comfortable
like
when
I
need
I'm
just
seeing
a
few
maybe
later
on
when
we
have
the
actual
clusters
and
I
need
to
debug
what's
going
on
or
how
how
things
are
provisioned.
I
need
to
go
through
our
repository
first
and
go
to
get
see
how
it's
done
behind
the
scenes,
and
I
don't
even
know
what
gate
does
a
layer
behind
it.
So
maybe
go
back
to
omnibus
and
so
on.
E
E
A
Yeah
I
mean
I
get
the
I
get.
The
sense
so
far
is
like
where
we
can
use
get
or
for
very
simple
things,
but
if
they're
very
simple
it
almost
like,
doesn't
even
make
sense
to
use
get
because
we
can,
you
know
just
copy
it
locally.
There's
just
isn't
a
lot
of
configuration
for
the
things
that
are
more
complex,
that's
where
we
run
into
a
lot
of
problems
and
where
I'm
seeing
the
complexities
around
petroni
and
using
omnibus
for
petroni
as
well
like
for
the
console
server.
A
I
mean
obviously
like
this
is
fairly
straightforward.
Maybe
like
you
could
use
get,
but
then
again
there
isn't
like
a
whole
lot
of
logic
there.
It's
just
setting
up
a
really
simple
basic
instance.
Installing
the
package
and
the
template
is
not
very
big
like
it's,
you
know
there
is
there
isn't
a
whole
lot,
so
I
guess.
B
E
B
A
A
I
don't
think
we
need
to
touch
console
like
it's
working,
hopefully
like.
We
won't
need
to
make
any
changes
there
and
then
we'll
see
we'll
see
how
things
look
with
petroni.
I
think
I
can
just
demo
this
today
on
my
branch,
because
I
have
the
patrony
like
using
get
an
omnibus.
I
have
petroni
configured,
but
I
think
overall,
like
I'm
I'm.
A
B
D
D
A
I
don't
know
what
is
maybe
maybe
ahmad
you're
closest
to
this,
like
what
is
your?
What
is
your
sense
of
like
configuring,
patrony
outside
of
omnibus,
since
you've
done
this
already?
I
think
you
you
already
have
gone
through
this
since
we
wrote
the
petroni
cookbooks
or
maybe
that
was
you
alejandra,
I'm
not
sure.
But
what
is
your
sense
for
the
complexity
and
the
work
for
getting
this
working
and
ansible?
A
E
E
B
Just
to
offer
a
little
bit
of
pushback,
something
that
I
that
I
think
we
might
be
overestimating
is,
I
wouldn't
necessarily
see
if
we
use
patrony
with
omnibus.
I
wouldn't
necessarily
see
it
as
we
are
using
chef
like.
I
would
see
it
as
a
black
box.
You
just
fit
omnivorous
configuration
through
the
gitlab
rb
and
then
the
way
it
does.
It
is
not
something
that
we
directly
manage.
It
happens
to
be
through
chat,
but
it's
not
like.
We
are
integrating
chef
into
our
infrastructure.
B
D
B
Yeah
and
just
to
say,
with
regards
to
it
being
too
heavy
for
single
components,
I
think
that's
only
true
of
the
installation
right
like
once
it's
running,
if
you
have
all
the
other
services
disabled,
it's
not
heavy
in
execution
time.
It's
just
having
that
you
are
installing
the
whole
package
and
not
using
most
of
it,
but
when
you're
just
running
consoles,
it's
just
like
you
install
console
manually.
A
You're
right,
yeah,
yeah
for
sure,
and
I'm
I'm
just
also
thinking
in
terms
of
like
upgrades
and
well
mostly
upgrades
where
to
upgrade
the
console,
the
upgrade
console.
It
requires
pulling
down
this
800
megabyte
package,
whereas
if
we
install
console
outside
of
ambibus,
it's
it's
much
better
right
and
what
we've
seen
where
we
have
used
omnibus
in
this
way
is
that
we
tend
to
pin
the
packages
and
avoid
upgrades,
because
we're
always
worried
about
unexpected
side
effects
of
things
that
the
omnibus
does
that
we
don't
like.
We
it's
just
a
it's.