►
Description
This is a sync meeting with infrastructure realm owners at GitLab discussing how to create company-wide standards for test and ephemeral infrastructure. You can learn more about our current iteration in the handbook at https://about.gitlab.com/handbook/infrastructure-standards.
You can read the transcript in the meeting agenda.
https://docs.google.com/document/d/1jdW-HxMKoTm75cZg5L0uXeoRhY0lHoValwXcnA7A6Zo/edit?usp=sharing
B
It
is
involved
with
you
know
the
you
know
why
I'm
touching
it
that
sort
of
stuff.
So
I
thought
this
would
be
a
good
good
opportunity
to
do
that.
I
threw
some
stuff
in
the
dock
of
what
I
think
we
are
doing.
That
is
there
for
red
penning,
not
for
me
to
read
off
if
you'd
like
to
pick
at
that
or
you
make
any
changes
now
would
be
a
good
opportunity
for
us
to
just
openly
discuss
that.
B
C
D
Not
too
well
just
from
past
experience
with
working
groups,
I
think
the
only
other
thing
is
like
there's,
mrs,
but
you'll
want
to
make
sure
we
have
the
right
executive
sponsorship
or
whatever
yeah.
I
assume
you
already
know
about
some
of
that,
but
yeah
making
sure
you've
read
the
pitfalls
there,
but
I'm
willing
to
help
find
that,
if
needed,.
B
B
B
D
B
B
A
B
E
B
I
did
also
invite
daniel
parker,
who
is
the
new
integrations
engineer
on
the
I.t
side,
to
you
know
kind
of
be
a
fly
on
the
wall.
He
just
joined
the
company
a
couple
weeks
ago
and
brian
suggested.
You
know
introducing
him
in.
I
did
have
a
conversation
with
him
a
couple
days
ago
and
was
very
impressed
and
he's
got
a
pretty
strong,
aws
background
as
well,
so
it
might
help
us
just
offset
because
we
don't
have
enough,
we
don't
have
amber.
I
think
you
would
agree.
B
E
B
Cool
well,
let's
jump
into
kind
of
the
highlights.
I
think
I
don't
think
any
of
this
is
new,
but
if
there's
something
that
we
want
to
remove
is
mostly
what
I'm
looking
for,
so
nothing
gets
published
in
the
handbook
that
we
don't
want
to
be.
There
is
my
ultimate
goal,
you
know.
Basically,
where
do
people
provision
stuff
out?
B
B
I
do
think
that
we
want
to
make
it
easy
on
security
ops.
So
when
something
does
happen,
all
the
scaffolding
is
in
place
and
to
support
the
efficiency
of
dealing
with
whatever
that
is
and
then
setting
best
practices
that
our
community
at
large
can
follow.
For
you
know,
service
accounts
not
being
enabled
those
kind
of
things
that
you
know
the
you
know.
Those
kind
of
you
know
the
top
ten
are
version
of
an
o
wasp.
If
you
will
is,
are
there
any
objections
to
to
that
piece
of
it?
B
Paul
and
I
had
an
interesting
conversation,
a
very
good
conversation.
We
had
some
interesting
questions
earlier
this
week
and
it
was
basically
the
jeff.
Do
you
want
to
be
an
sre?
You
know
full-time
type
of
thing
right,
because
what
we're
looking
at
here
is
basically
forming
some
form
of
new
sre
style
of
management
around
this.
What
that
becomes?
Let's
not
try
to
figure
that
out
right
now.
Let's
just
try
to
figure
out
what
the
the
scaffolding
looks
like
and
then
we'll
figure
out
the
details
after
that.
B
C
I
remember
exactly
what
I
said,
because
I
think
I'm
still
sleep
deprived,
but
really
the
the
crux
of
it
is
that
we
we
want
to
make
sure
that
these
are
that
everyone
has
their
own
little
wall
garden,
that
they
can
go
and
and
plane
and
do
what
they
want
to
do.
Whether
they
want
to
go
build
a
sand
castle
or
pee
on
that
sand.
C
Castle
is
totally
their
own,
but
at
the
end
of
the
day,
jeff's
putting
himself
in
a
position
where
they're
becoming
a
the
operational
point
of
contact
for
making
sure
the
service
functions
and
doesn't
function
until
we
get
to
a
point
of
finding
a
long-term
owner
for
this,
and
this
type
of
work
doesn't
fit
with
like
dave
and
the
and
the
quote:
unquote
actual
sres,
and
that
and
a
lot
of
that
and
that
tech
support
and
recognizing
what
just.
How
much
extra
effort
goes
into
running.
C
An
environment
like
that
doesn't
necessarily
fit
with
rit
ops,
as
it
sits
today.
So
having
to
put
expectations
on
to
people
who
are
are
using
this
tooling
and
deploying
using
our
stuff
need
to
know
that
this
is
entirely
choose
your
own
adventure.
It's
your!
It's
your
castle
to
burn!
We
are
not
here
to
help
you
troubleshoot
problems.
We're
not
here
to
do
anything
as
long
as
our
tooling
is
functioning
correctly
you're
here
to
do
what
you
need
to
do
as
long
as
it's
not
production.
D
D
My
feedback
on
that
is
like
part
of
what
we're
just
trying
to
set
up
is
the
foundation
like
the
folder
structure
and
things
itself
are
not
there's
not
any
tooling
with
that,
like
once
we
get
the
mechanisms
of
how
we
want
the
folder
structure
and
some
of
the
security
groups
laid
out
for
both
aws
and
gcp.
Hopefully
those
things
are
left
more
alone.
D
I
think
with
the
terraform,
tooling
and
other
things
after
that
and
enforcing
the
label
standards,
I
think,
maybe
the
other
model
so
where
I
was
starting
to
try
to
say
I
was
going
is
in
other
companies.
I've
been
at
it's
a
little
hard
because
it's
gitlab,
they
called
it
an
inner
source
model
of
this,
but
we're
open
source.
But
it's
like
this
is
the
tool
we've
helped
create
the
baseline.
For
now
everybody
can
contribute
to
it
to
help
us
manage
our
own
resources
better.
So
I
think
that
would
be
the
other
model,
maybe
to
keep.
D
D
C
Yeah,
I
think
I
I
completely
support
that
as
long
as
as
long
as
it's
not
manipulating
how
it's
act,
how
our
implementation,
in
relation
to
our
account
on
gcp,
is,
as
in
you
can
go,
make
a
terraform
change.
That
has
the
ability
to
manipulate
how
the
tool
and
the
meta
of
the
tool
functions,
but
not
how
that
tool
interacts
with
our
account
so
that
people
couldn't
find
an
mr
to
allow
them
to
go
use,
create.
C
D
Yeah
but
see
that's
that's
early
optimization
at
the
moment.
We
don't
have
that
guideline
from
the
company,
so
I
feel
like
right
now
we're
just
trying
to
implement
the
best
practices
of
the
obvious
turn
off
the
global
service
account
in
a
project
kind
of
thing
for
compromise
and
make
sure
we
enforce
labels.
Everybody
should
accept
that
and.
C
Yeah,
no,
I
agree,
and
actually
I
I
jump
into
this
and
later
on
is
a
lot
of
that
is
also
to
do
with
like
the
hard
and
soft
security
requirements
we
might
have,
so
that
we
don't
render
the
problems
that
the
red
team
has
already
picked
off,
like
the
ability
to
hop
between
projects
yeah
and
just
having.
How
do
we
implement
that
through?
I
am.
C
B
And
I
think
a
big
piece
of
it
as
well
builds
upon
you
know
we
were
talking
before
like.
Is
it
just
a
label
or
a
tag?
I
think
we've
all
come
with
consensus,
we're
far
past
that,
where
you're
in
the
account
or
project
isolation,
barrier,
there's
there's
no
way
around
that
and
as
we're
reading
and
seeing
more
what
I
don't
know
if
it's
google
or
amazon
I
want
to
say
it
was
google
said
you
guys,
are
pretty
sophisticated
compared
to
the
rest
of
the
industry
and
what
you're
doing.
D
B
And
what
I
would
like
to
do,
and
to
the
point
of
like
not
mr
something
to
a
terraform
module
and
have
it
affect
global
things,
is
end
up
with
I'm
going
to
call
it
tiered
terraforming
for
the
sake
of
discussion,
where,
basically,
you
have
your
global
terraform
and
that's
both
your
configuration
and
your
modules
and
basically
that's
control
in
the
top
level,
the
organizational
unit
type
of
stuff
to
like
you
know
what
is
what
are
the
realm
configs?
What
are
the
realm
management?
B
You
know
I
have
to
say
that
the
top
10
people
only
they
can
actually
touch
that
stuff
and
then
you,
their
second
level
down,
is
here's
all
the
projects
that
get
created
and
most
of
that's
going
to
be
automated
with
some
of
the
tooling
we're
going
to
build
right
now
that
tooling
is
going
to
have
access
rights
where
only
the
administrators
can
actually
hit
the
magic
button
to
make
that
happen,
but
it
is
again
a
protected.
You
know
module
library
of
terraform
or
whatever
other
additional
tooling
we
need
for
that.
B
B
We
automate
that,
through
the
octa
stuff
we're
building
with
the
web
ui
stuff
from
the
tooling
I've
been
working
on
there,
so
it
gets
them
into
the
right
place.
What
they
do
inside
of
there
to
paul's
point
is
here's
your
sandbox,
do
what
you
will
is.
We
then
have
a
community
library
of
terraform
modules
that
are
they're
your
gcp.
B
It
says
they're
your
omnibus
instance,
your
you
know
the
different
pieces
that
people
would
use
for
whatever
their
femoral
infrastructure,
even
if
it's
long
living
infrastructure,
but
here's
the
baseline
scaffolding
of
the
best
practice
for
a
hardened
environment
or
hardened
resource.
And
you
can
you
basically
manage
your
own
terraform
state.
We
just
give
you.
We
just
give
you
a
library
of
things
and
that's
where
the
community
and
the
its
open
source
signing
will
come
and
do
what
they
need
to
do,
and
it
just
affects
that
and
with
the
module
and
the
mr
is
we.
E
B
The
same
way
that
dave
correct
me
if
I'm
wrong
on
this,
but
my
understanding
is
that
even
for
gitlab.com
we
have
a
library
of
private
terraform
modules
that
are
all
version.
Controlled
terraform
supports
versioning
per
module,
and
if
you
don't
want
something
to
break,
you
simply
said
a.
I
expect
version
1.2.2.
B
D
B
D
A
B
So
just
the
concept
of
there's
a
community
library
of
terraform
modules,
and
then
people
can
use
them
or
not
use
them
or
do
whatever
they
will,
but
everything
that
manages
everything
up
to
the
point
of
a
gcp
project
or
an
aws
account
and
the
iam
role
for
the
user
that
gets
into
that
account.
We
manage
in
the
in
the
top
10
group,
if
you
will
or
whatever
that
that
you
know
the
administrator
group
is
another.
B
It's
a
separate
infrastructure,
separate
architecture
for
what
people
do
inside
of
there
paul
does
that
align
with
your
kind
of
security,
segregation,
yep,
okay,
davis,
based
on
some
of
that,
you
know
you,
you
look
at
it
from
the
analytics
side
and
the
cost
side.
You
know
the
labels
and
tags
obviously
would
get
applied
at
both
a
project
level
and
a
resource
level.
Maybe
a
combination,
maybe
not
depending
on
you,
know,
testing,
but
any
objections
to
that
overall
architecture.
A
No,
I
mean,
I
think
the
labels
are
the
important
thing
there.
I
guess
still
part
of
me
still
thinks
with
like
the
project
level.
Stuff
like
it
could
still
be
worthwhile,
though,
like
I
understand
the
current
setup,
you
create
these
world
environments
and
things
like
that,
but
I
can
see
you
know
someone
wants
to
use
a
service,
that's
not
included
in
terraform
or
something
like
it
could
be
useful
to
have
a
way
for
the
tool
to
like
spin
up
in
a
different
project.
B
D
D
Part
of
the
problem
that
I
was
trying
to
adjust
by
was
saying
like
when
we
give
everybody
that
control
what
it
gets
us
out
of
the
pattern
of
right
now
is
we
occasionally
get
these
access
requests
for?
I
need
a
service
account
in
gitlab
internal,
hey
infra.
Can
you
go
make
it
or
something
else,
or
some
other
project
like
that
or
we?
You
know
we
get
recently
dealt
with
the
question
from
the
distribution
team.
D
D
What
jeff's
got
in
place
on
top
of
that
is
octa
will
make
that
just
possible
without
me.
Right
now,
I
had
to
go
by
hand
assign
the
dev
manager
to
their
folder
as
the
folder.
I
am
and
then
there's
a
little
bit
of
work
to
do
that
by
hand
right
now.
We
automate
even
that
away,
but
inside
of
that,
then
they
can
make
their
own
project.
They
can
assign
service
accounts
to
it
and
other
things
the
terraform
as
jeff
mentioned,
gives
them
the
easy
button.
D
So
at
least
if
they
did
something
by
hand
that
still
gives
the
risk
of
they
could
compromise
their
whole
project
by
giving
creating
a
service
account.
That's
too
broad.
The
easy
button
at
least
conforms
a
little
bit
of
labeling
and
security
to
make
it
easy
for
people
who
are
like.
I
just
need
a
project
that
I
can
spin
up
a
git
lab
instance
then,
or
something.
A
D
Like
this,
no
no
yeah
this,
this
terraform
is
largely
again
like
kind
of
a
rewrite
of
the
group
projects
in
some
ways,
stuff
that
we
had,
which
is
like
here's,
an
easy
button
with
terraform.
To
make
me
a
project
where
I
can
go.
Do
what
I
need
to
do
in
that
after
there
or
those
after
and
or
backwards.
But.
B
It's
kind
of
it,
you
know,
I
just
say:
is
you
know
it's
going
in
into
gcp
consoles
power,
user
mode?
You
know
like
terraform,
we
give
them
all
the
tutorials
and
stuff
like
hey.
Give
me
the
ten
step
tutorial
to
get
an
omnibus
instance
running
with
three
runners
right.
We
have
that
so
terraform
is
optional.
It
is
simply
the
tooling
that
we
have
chosen
to
give
people
the
the
express
or
easy
button
version
and
do
what
they
need
to
do.
B
B
We've
granted
you
iem
rights
there
with
our
automated
tooling
at
the
top
level
right
and
that
what
that
really
does
is
that
whole
service
account
and
gitlab
internal
or
whatever
that,
because,
let's
let's
face
it,
we
have
our
most
of
our
engineers
need
administrator
level
access
to
do
some
of
the
cloud
infrastructure
things
that
we're
doing,
and
that's
where
this
just
limits
that
blast
radius,
so
they're,
not
exposing
everything
everywhere.
They
only
they're
only
affecting
them
right
and
the
only
thing
that
terraform,
you
know
if
people
have
opposition
to
using
it,
that's
fine.
B
They
set
up
10
minutes
because
I've
already
templates
it
now
I'll,
just
spin
it
up
spin
it
down
whatever
it's
terrifying,
apply
and
destroy,
so
we're
simply
for
those
who
have
matured
their
own
development
test
cycle
into
using
infrastructure
as
they
go
on
that
journey.
They
discover
some
of
these
toolings
the
same
way
back
in
the
90s
always
discovered
bash
scripts.
It's
the
same
concept,
so
yeah
we're
not
forcing
it
upon
them,
we're
simply
using
tarot
form
as
our
top
level.
B
B
Amber
circling
back
for
you
a
lot
of
this
automates,
the
access
request
process.
I
know
that
most
things
today
are,
you
know
they're
mostly
manually
performed
they
mostly
come
through
gitlab
issues.
We
can
automate
a
lot
of
this
with
kind
of
the
database.
You
know
the
web
application
side
of
it
and
the
octa
and
the
audit
log
etc.
B
Do
you
have
any?
I
guess
what
I'm
looking
for
is
things
like
audit
logging
concerns
oversights
approval
buttons
things
of
that
nature,
because,
ultimately,
what
I'd
like
to
get
it
down
to
is,
especially
within
the
engineering
organization
we
have
500
and
some
odd
people.
You
know
total
across
all
of
that
piece
of
it.
Do
you
have
any
problem
with
people
managers
approving
their
own
team
members?
E
E
We
want.
You
know
things
to
work
as
smoothly
as
possible,
but
two
even
with
our
ars.
Now,
essentially
the
people
manager
is
approving
it
like
I
don't
know
if
someone
should
have
access
or
not
most
of
the
time
you
know
based
on
their
job.
There's
1300
people
in
this
company-
and
I
don't
know
everyone's
job
or
role
what
they
need
to
access
for
that
role.
So
I
rely
on
the
manager
to
be
like.
Yes,
this
person
needs
it,
and
then
I
just
go
ahead
and
provision
it.
So
that's
essentially
what
I'm
doing
now.
C
It'll
it'll
it'll
change
what
their
security
profile
is
going
to
be
to
allow
them
to
do
certain
things
and
act
in
a
certain
way.
On
the
in
this
tool
and
more
likely
in
other
areas
of
gitlab
as
well
and
and
at
some
point
I
would
expect.
It
is
also
going
to
need
to
start
to
consider
whether
this
person
is
like
part
of
development
to
get
access
to
some
tooling
or
get
licensing
for
some
software
versus
someone
who's
sitting
in
sales.
E
C
E
Okay,
yeah,
I
mean
at
this
point
because
we've
been
so
understaffed
in
our
department,
we've
kind
of
been
relying
on
the
people
managers
to
like
make
those
decisions,
because
I
can't
sit
there
and
research
every
single
person
in
their
role
and
then
sit
there
and
think
about
well.
Do
they
need
access
for
this,
and,
like
I
mean
it,
takes
enough
time
to
provision
these
things
as
it
is
without
me
having
to
look
up
every
single
person
in
the
company.
E
B
And
paul,
what
are
the
things
I'm
working
on?
We
had
discussed
some
of
the
the
back
end.
You
know
the
database
model
side,
I'm
working
on
with
you
know
how
we're
going
to
provision
this,
as
I
do
all
the
authentication
roles-
and
I
am
already
inheriting
the
octa
divisions,
departments
and
groups-
is
we
can
do
the
security
group
mapping
to
it.
So,
for
example,
if
that
web
ui
says
hey,
you
know
so
jonathan's
my
manager,
right,
it
says:
jeff
is
requesting
access
to
the
sales
cs.
B
You
know
solution,
architect,
account
is
approved
yes
or
no,
and
there
is
a
profile
security
group
already
set
up
for
you
for
this
group.
Members
are
automatically
added
to
solution,
architect,
security
group
with
all
the
permissions
that
we
define
at
an
infrastructure
management
level
and
that
way
all
the
because
each
each
of
our
infrastructure
realms
in
each
of
our
infrastructure
groups.
We
then
say:
okay,
which
roles
are
allowed
to
access
this
and
which
ones
are
you
know
members
effectively?
So
what
is
the
member?
What
can
members
do
in
each
group
or
we
can
help?
B
We
can
roll
that
up
to
the
department
under
engineering?
What
can
members
do
under
any
group
in
engineering
versus
sales
etc?
So
we
can
do
a
lot
of
the
automatic
role
mapping
there
might
be.
An
initial
work
to
you
know,
identify
what
those
are,
or
you
know,
to
dave's
point
of
iteration
of
we.
You
know
we're
not
going
to
get
into
some
of
the
deeper
weeds
right
now,
but
we
can
say
that
you
know.
B
B
B
No,
I
don't
really
have
anything
to
add.
This
sounds
extremely
promising
and
no,
it
sounds
perfect.
Thank
you,
cool
good
deal,
so
dave.
I
want
to
circle
on
to
the
you
know,
what
we're
not
solving
and
obviously,
there's
a
production
elements
and
a
couple
other
things
and
davis.
I'm
sure
you
have
some
thoughts
on
this
as
well.
B
My
ultimate
goal
is
simply
for
production.
Stuff
is
make
sure
you
guys
are
happy
or
you
know
you
folks
are
happy
and
then,
whatever
labels
and
tags,
if
it's
something
eventually,
it
could
be
a
slow
migration
or
face
migration
to
being
able
to
use
them
so
that
davis's
reports
and
brooks's
reports,
you
know,
show
a
consistent
thing:
you're
not
having
to
do
different
things
based
on
different
labels
being
used
based
on
what
you've
seen
the
evolutionists
over
the
last
month
or
two.
Do
you
see
major
concerns?
B
D
No,
I
just
think
like
there
will
be
there
might
be
a
gap
in
between
how
we
handle
underneath
the
get
lab
sas
projects
applying
the
labeling.
It's
gonna
have
to
be
separate,
obviously
than
all
the
terraform
you're
doing,
but
I
I
feel
like
as
long
as
we're
taking
that
approach.
I
don't
see
problems
with
the
standards
we
just
may
have
feedback
once
we
start
to
try
to
apply
the
labels
and.
D
A
A
D
D
B
D
Yeah,
no,
absolutely
thank
you
for
using
the
right
word,
yeah
and
correct
me.
What's
what
I'm
thinking
of
is
like
the
infrastructure
realm
may
have
to
be
separate
for
a
bit
until
we
get
some
other
baseline
things
laid
out,
but
I'm
still
interested
on
that.
But
I
see
that,
like
that's
the
the
main
thing
for
us,
I
think
in
the
first
step
to
try
to
help
with
what
davis
is
looking
for
is
actually
just
doing
the
labeling
and
that's
all
very
meta.
A
D
C
Yeah,
I
was
we
were
we
were
talking
about
production
and,
like
you
were
just
mentioning,
like
the
impact
of
potentially
infrastructure,
space
and
and
ownership
that
this
is
more
of
a
conversation
that
I'm
going
to
take
away
with
dave
for
our
wednesday
meeting.
But
at
some
point
a
lot
of
the
stuff
gets
promoted
to
become
like
there's
a
lot
of
things
that
are
going
to
become
production,
tooling
or
production
service
or
production,
something
that
isn't
necessarily
gitlab.com
and
that
promotion
process
is
going
to
figure
that
out
and
also
to
figure
out
like
ownership.
C
This
is
totally
meta,
long
game
scenario
for
this,
but
this
is
a
conversation
that
I'm
I'm
already
dealing
with
with
security.
Automation,
for
example,
where
90
of
what
security
automation
is
going
to
be
doing
is,
is
going
to
be
more
than
happy
to
sit
in
this
demo
systems
work,
but
that
10
percent
of
work
they've
already
tried
to
prime
the
pump
and
dave
might
understand.
C
D
I
think
the
other
thing
I'd
add
to
give
you
the
specifics
on
that
paul
as
an
example
is
lean
and
the
people
ops
team,
where
she
created
the
nominator
bot
and
the
nominator
bot,
was
something
where
people
ops
originally
came
to
us
and
said
hey.
We
need
a
project
in
gcp
where
we
would
see
this
tooling,
creating
something
like
that,
but
the
nominator
bot
was
something
that
at
first
they
were
testing
and
is
now
a
production
for
the
company
thing.
So
I
would.
D
D
Is
there
some
sort
of
process
on
how
those
teams
in
their
projects
with
what
were
created
like
have
the
right
structure?
However,
like
my
side
point
on
that,
though,
is
still
wanting
us
to
continue
to
iterate,
like
let's
move
forward
with
what
we've
got
yeah
and
make
sure
that
we've
got,
I
feel,
like
we've
got
a
framework,
that's
flexible
enough
to
adapt
to
that.
B
And
you're
building
on
something
that
was
actually
my
next
meta-level
question,
and
this
is
part
of
the
iteration
like
the
fork
in
the
road.
We
can
go
left
or
right
right
now.
On
this
next
question,
the
engineering
dev
for
enge
dev
realm
naming
convention
that
we've
come
up
with
right
now
is
designed
for
teams
to
do
what
they
want
inside
of
it
and
simply
give
them
that
space.
Do
we
need
to
split
that
into
eng
dev?
You
know
sandbox
and
edge
dev
production.
D
B
C
Yeah
it
it.
This
bears
to
mind
like
just
needing
to
understand,
putting
putting
a
definition
around.
What's
truly
production
because
similar
to
the
conversation
we're
having
about
about
you
potentially
turning
into
an
sre,
is
having
expectations,
because
the
last
thing
I
want
is
one
I
don't
want
you
to
become
to
become
responsible
for
some
randos
team
thinking.
Their
tool
is
not
sitting
in
pride,
that
is,
that
is
sitting
in
demo
systems
and
the
second
one
is,
I
don't
want
dave
and
the
infrastreams
taking
responsibility
for
some
random
tool
that
that
someone
considers
prod.
D
Ford
security,
the
cert
team
coming
in
finding
out
that
this
had
production
data-
yes
right
because
yeah,
so
I
think
that
you
know-
and
that
might
be
just
clearly
stating
in
the
working
group
jeff-
that
there
is
no
sla
on
this
stuff
yeah.
You
are
responsible
for
your
sla,
like
there
is
no
team
enforcing
making
sure
this
stuff
is
available
so
and
no.
C
B
I
think
one
of
the
things
we
may
want
to
consider
in
a
future
iteration.
You
know
right
now.
We
have
a
trusted.
Working
group.
Here
is
basically
a
security
awareness,
training
for
infrastructure
production
type
of
you
know
owners.
So
you
want
to
be
a
system
owner
of
rando
tool
x,
right,
here's,
the
training.
You
need
to
go
to
and
get
certified
that
you're.
Now
managing
this,
you
have
your
own
sla.
You
have
here's
the
support,
here's,
the
security
qbr's.
B
A
A
B
Right,
I
I
did
put
a
placeholder
naming
convention
in
that
I
called
shared
services.
That
may
be
an
interim
solution
for
this
right
now.
You
know
we
have
it
kind
of
with
the
you
know
under
the
engine
infrastructure
realm
right,
there
is
the
shared
infra,
then
there's
the
shared
services
group
that
may
be
a
good
place.
What
we
may
want
to
find
out
is
do
we
need
to
do
that
under
engineering
development
as
well,
but.
E
D
D
B
Yeah
yeah,
so
we
can
go
down
that
road
and
amber.
I
think
this
is
where,
from
the
the
business
op
side,
this
is
going
to
show
up,
eventually
is
what
is
it
that
business
ops
owns
from
an
infrastructure
perspective
if
it's
serving
the
entire
company
or
does
the
you
know,
theoretical
infrastructure
team
get
formed
underneath
the
business
ops
right
and
that's
a
future
problem
for
a
future
day?
I'm
just
calling
it
out
as
a
eventuality,
but
I
thought
you
should
be
aware:
that's
a
possibility.
B
E
I
will
throw
this
out
there
that,
with
one
of
my
co-workers
leaving
a
few
weeks
ago,
we're
not
exactly
back
filling
his
position
for
another
systems,
administrator
we're
actually
going
to
be
hiring
for
a
systems
engineer,
and
that
might
be
something
I
know:
they're
they're
writing
up
the
job
family
now
to
get
it
approved,
but
that's
going
to
be
more
obviously,
engineering,
happy
person
who
can
handle
stuff
like
infrastructure
and
things
like
that.
So
I'm
not
sure
if
that
will
be
on
their
plate.
E
B
Yeah
and
eventually
we
can
iterate
that,
toward
you
know
global
coverage,
because
that's
the
big
thing
right
is,
you
know
what
does
our
on-call
thing
come
in
because
I
look
for
demo
systems,
I
mean
we
have
america
and
europe
coverage.
We
don't
have
asia
coverage
right,
and
you
know
one
of
the
things
that
we
should
probably
do
and
paul.
This
is
something
just
to
noodle
on
a
little
bit
is
at
what
point
from
like
a
security
incident
response
perspective
right
now
we
have
certain
engineers
on
call.
B
A
B
But
at
what
point
does
dave
this
kind
of
applies
on
the
sre
side
as
well?
Where
is
a
shared
sre
escalation
path
that
is
regional,
we're,
not
waking
someone
up
where
they
could
go
into
an
infrastructure,
owner's,
playbook
of
sorts
and
says:
hey
your
system's
a
problem.
Here's
my
my
10
steps
in
order
to
remediate
common
problem,
or
you
know
I
render
this
with
with
asia
all
the
time
is.
You
know
chris
moberly
runs
some
script,
you
know
and
then
it
pounds
my
system.
B
D
B
C
Okay
and
we
are
setting
the
t's
and
c's
very
early
on
as
we've
already
discussed
about
what
those
expectations
are
and
if
we
put
if
we
put
like
good
security
measures
in
place,
we're
talking
about
these
walled
gardens,
this
would
imply
ingress
and
egress
rules.
This
would
this
would
then
imply
that
chris
moberly's
scripts
can't
actually
go
and
smash
what's
sitting
in
that
environment,
because
that
base
configuration
shouldn't
allow
for
that.
C
If
someone
has
gone
in
and
made
the
exception
to
go
and
actually
extend
their
ingress
rules,
they've
accepted
the
fact
that
if
they
leave
something
that
is
just
flapping
out
there
in
the
wind
and
we
find
it
we're
going
to
turn
it
off.
Yeah
yeah
and
anyone
who's
sitting
in
a
production
state
here
is
going
to
say
tough.
D
D
So
what
I
would
do
and
picture
that
is
that,
like
trying
to
dive
deep
on
that
security,
for
a
second,
is
that
the
cert
team
still
is
probably
going
to
have
folder
level
owner
on
every
folder.
But
there's
only
going
to
be
a
limited
number
of
true
admins
at
the
top
of
the
organization.
That's
going
to
be
a
selection
of
management,
so
that,
like
those
for
for
not
that
that
way,
we
just
disallow
who
can
create
folders,
create
projects.
Try.
D
C
D
C
Well,
the
other
piece
of
it
is
is
that,
unlike
gitlab
internal,
for
example,
today,
where
you
can
easily
hover
around
to
anyone
else's
terrible
cesspool
of
a
box,
these
can
all
be
in
disparate
projects
where
they
don't
have
the
ability
to
spread
like
the
plague,
and
so
the
the
surface
area
of
attack
is,
is
substantially
lower.
And
so,
if
a
box
under
amber's
random
account
happens
to
have
like
open
reg
for
the
gitlab.com
instance,
we
largely
won't
care,
because
it's
just
that
one
box
that'll
get
hit.
C
B
And
I
think
the
the
cert
on
call
does
address
my
my
original
thing
and
we
can
also
use
it
where
you
know
the
temporary
access
type
of
deal
with.
You
know
the
infrastructure
is
these,
you
know,
cert
team
has
you
know
group
permissions
into
all
the
different
areas
right
type
of
thing
or
it's
granted
and
ungranted
automatically
based
on
the
cert
on-call
rotation
schedule.
Whatever
the
pieces
are
and
then
infrastructure
is,
you
know
dave
as
the
infrastructure
manager.
D
B
B
If
you
did
prod
and
test
dab,
that's
your
own
help
yeah
and
leave
it
at
that,
and
then
we
can
across
the
bridge
of
where
does
prod
services
live
with
a
future
iteration
right
to
your
point,
I
don't
think
we
need
to
change
too
much
of
this,
because
we
don't
have
an
infrastructure
team
dedicated
to
production
services
outside
of
gitlab.com
other
than
you
know
what
people
ops
runs
right
now
right,
but
most
of
their
stuff
is
sas
services
anyway.
So
well.
B
A
Yeah
no
flags
yeah,
I
think,
for
the
labels,
and
everything
like
the
important
thing
for
us
is
just
like
just
aligning
what
we're
labeling
these
demo
environments,
with
what
we're
planning
on
labeling
like
the
production
and
all
the
other
environments.
I
like
the
basic
for
all
the
basic
and
most
important
labels.
A
I
think
that's
really
just
the
most
important
thing
I
think
just
as
a
comment
I
think,
like
the
realm
labels
that
we've
been
talking
about,
and
maybe
also
team
labels
like
those
will
probably
be
the
most
like
we'll,
probably
iterate,
on
those
the
most
I'd
assume,
because
I
think
those
aren't
like
well
defined
within
the
business
itself.
So
I
would
imagine,
like
those
will
probably
be
the
areas
where
you
have
to
iterate
the
most
on
like
what
those
actually
look
like
yeah,
okay,
amber
any
other
thoughts
from
your
end
on
this.
A
B
B
Paul
is
there
anything
you
wanted
to
recap
just
kind
of
moving
down
the
the
sections.
I
think
davis's
point
on
your
water
realms.
We
can.
We
can
circle
back
on
because
I
think
there
is
some
iteration
there,
but
I
think
we
fear
like
who's
doing
what
we
don't
know
that
we
probably
won't
know
it
for
another
month
or
so
yeah
until
we
get
some
of
the
tooling
in
place.
C
No,
we
covered,
we
covered
everything
that
I
wanted
to
run
over
here
today,
and
I
think
we've
done
pretty
good
the
night
really.
The
last
thing
is
really
just
going
into
the
meta
about
how
we're
gonna
be
doing.
I
am
and
how
we're
gonna
make
sure
that
a
lot
of
the
integration
with
following,
like
the
integ,
like
the
octa
to
gcp
translation
for
good,
I
am,
is
really
the
piece
and
making
sure
things
like
the
service
account
mess
doesn't
take
place,
and
how
do
we
then
relate
that
stuff
to
the
security
policies?
C
We
want
to
implement
this
stuff,
because,
and
so
what
I'm
going
to
be
doing
in
this
is
from
what
it
sounds
like,
as
is
going
to
be
like
trying
to
figure
out
what
our
security
policy
is
going
to
be
and
helping
with
setting
expectations
on
this,
and
I
just
want
to
make
sure
that
I
know
the
right
flow
to
help.
Prepare
you
for
that
information
when
it
comes
time
to
need
it.
C
B
Yeah
and
we
can
work
more
in
our
one-on-one
syncs
on
the
details
of
that,
but
totally
an
agreement
there.
That
is
really
all
that
I
have
at
this
point.
I
do
have
a
handbook,
mr
I'm,
going
to
tag
everyone
here
for
approval
on
before
it
makes
its
way
up
the
executive
food
chain,
because
right
now,
sid
is
the
the
namespace
owner
of
the
handbook
for
this,
and
so
he's
gonna
end
up
seeing
it.
B
I
wanna
get
all
of
our
stamps
of
approval
on
it
before
it
makes
it
to
him,
but
yeah.
At
this
point
in
davis,
I
did
refactor
it
based
on
your
feedback
on
all
the
different
group
pages.
I
move
that
out
up
to
just
the
realm
level,
so
we
can
get
that
as
first
iteration
that
we
can
add
upon
it
as
needed
and
then
my
hope
is
over.
The
next
two
to
three
weeks
is
get
all
the
the
the
web
portal
type
of
data,
the
octa
translation
into
the
account
provisioning
in
terraform.
B
I'm
going
to
build
that
middleware
application.
Get
that
all
you
know
up
and
running
with
the
first
iteration
and
then
basically
start
a
proof
of
concept
with
a
couple
of
the
the
groups
that
are
in
there.
One
of
them
was
tagged
in
the
issue
for
the
the
quality
group
is
trying
to
do
some
testing.
I
just
want
an
account
to
do
it
in
I'll.
B
Do
it
with
obviously
the
professional
services
team,
it's
a
great
place
to
do
it
in,
and
then
I'm
going
to
do
the
sandbox
testing
with
the
customer
success
team
for
all
of
their
clusters
and
moving
some
of
those
over.
So
the
goal
is
by
the
end
of
september,
we've
done
a
beta
or
an
alpha
or
beta.
Whatever
we
end
up
calling
it.
You
know
across
multiple
departments
to
see
what
works
and
what
doesn't
and
then
start
bringing
all
the
other
team
owners
into
the
conversation
of
okay.
B
We've
got
this
we'd
like
you
to
start
kicking
the
tires
on
this,
and
basically
I'd
like
to
get
a
consensus
in
the
october
time
frame
of
yes,
it's
working
for
us.
Yes,
we're
adopting
this
here's
our
timeline
great
or
the.
We
have
some
limitations
and
it's
more
than
10
or
20
percent.
There's
some
serious
limitations.
We
can
know
those
are
and
prioritize
those
iterations
as
needed.
B
So
that's
my
hope
is
kind
of
taking
us
through
the
flows
to
build
a
tool
and
getting
people
on
board
but
yeah.
That's
where
I
stand
with
it
and
then
I'll
create
a
working
group
page
just
so.
It's
documented
in
the
handbook,
for
you
know,
preservation's
sake,
but
otherwise,
we'll
post
stuff
in
the
channel
as
we
need
to
paul.
What
are
your
thoughts
on
your
end
for.
C
A
C
A
B
Thank
you
all
right.
Well,
I
wish
everyone
a
great
day
and
I'm
going
to
go
through
and
transpose
our
call.
We
did.
I
didn't
take
too
many
notes
during
it,
but
I'll
transpose
the
the
discussion
topics
into
the
doc,
so
it's
there
and
we'll
go
from
there.
So
thank
you.
Everyone
and
have
a
great
rest
of
your
thursday.