►
From YouTube: Service catalog discussion
Description
Discussion on the future of the Service Catalog in Infrastructure.
Notes (internal) https://docs.google.com/document/d/1x8g2a0SxOUMevHVKncFiAF0ucMp9liIBAaZth_Uu2m0/edit#
A
A
Okay,
first
item
I
wanted
just
to
follow
up
with
the
earlier
discussion
about
ownership.
I
know
Rachel.
You
discussed
this
with
Dave
and
decided
that
this
would
be
owned
by
scalability
for
just
a
little
bit
of
background.
You
know:
I
I
want
to
drive
some
changes
soon
to
the
service
catalog
to
help
one
like
just
have
consistent
labeling
for
services
right
now,
it's
a
bit
disjoint
and
to
I'd
like
to
start
making
our
work
more
service
oriented.
This
will
help
with
Team
assignments.
A
B
Oh
yeah,
just
to
just
to
confirm
so.
Yes,
Dave
and
I
did
have
a
conversation
and
we
seemed
an
alignment
for
scalability
to
take
ownership,
at
least
in
the
short
term,
I'm
always
open
to
having
further
conversations
later
on.
If
it
continues
to
be
the
best
place
to
store
it,
but
because
we
have
a
whole
lot
of
projects
that
hinge
on
having
good
service
information.
I
was
quite
Keen
for
us
to
own
that
so
that
we
can
move
forward
without
having
any
external
dependency
there.
A
B
A
C
B
A
That
sounds
great,
so
number
two
I
guess
this
is
a
maybe
a
question
for
Andrew,
because
I
think
like
what
I
kind
of
was
thinking
for
the
service
catalog
was
expanding.
It
Beyond
just
services
that
we
monitor,
but
also
like
being
tied
to
like
almost
like
all
the
work
we
do
like.
For
example,
if
we
have
to
do
a
gcp
project
reconfiguration,
there
would
be
a
service
for
that.
Maybe
that's
like
being
a
little
too
loose
with
the
definition
of
service
and
doesn't
work
well.
A
D
Know
what
do
you
think?
What
do
you
think
about
that?
So
we
already
have
gcp
sorry
GCS
in
the
service
catalog,
which
is
managed
service,
so
I
I
think
the
Precedence
has
already
been
set
and
I
think
that's
fine,
maybe
in
the
refactor
we
could
put
in
something
like
a
deployment
type
or
I.
Don't
know
like
naming's
high,
but
like
Cloud,
kubernetes,
VM
and
cloud
is,
you
know,
Cloud
managed
is
one
of
those
deployment
types.
D
B
You're
thinking
about
it
in
terms
of
like
these
are
the
things
that
the
teams
are
responsible
for.
This
is
almost
exactly
the
same
as
how
things
are
done
in
development,
where
they
have
a
file
that
represents
all
of
the
stage
groups
and
the
stage
groups
are
responsible
for
feature
categories.
So
if
we
had
something
similar
in
infrastructure,
which
is
these
are
all
the
things
that
we
support
feature
categories-
and
these
are
the
teams
that
are
responsible
for
those
things-
it
becomes
a
Common
Language
with
with
them
as
well.
D
A
D
Think
that's
already
the
case
in
there
I
mean
again,
like
the
I
think
what
happened
the
last
time
around.
Was
it
just
kind
of
exploded
with
too
much
stuff
and
I
think
we
should
use
that
same
sort
of
sense
of
minimalism?
So,
like
don't
break,
you
know
every
GCS
service
down
into
like
the
most
Atomic
elements.
You
know
we
end
up
with
like
70
cheese,
Google
services
or
something
like
that.
Do
you
know
what
I
mean
like?
A
Okay,
so
just
kind
of
these
comments-
yeah,
yeah,
I,
guess,
East,
Common,
Sense,
yeah
I-
think
that's
hard
like
because
okay,
but
I
I
like
this
but
I
I,
don't
know
how
to
implement
it.
I
feel
like
it's
going
to
naturally
expand.
We
did
an
exercise
at
the
team
off
site
where
every
one
of
the
managers
in
reliability
named
all
the
services
that
we
were
responsible
for.
D
So
there's
kind
of
a
related
but
sort
of
slightly
orthogonal
discussion
around
some
Services.
We
could
actually
basically
merge
them
together
and,
for
example,
you
know
Thanos
alert
manager,
Prometheus.
Those
are
all
really
our
observability
service
and
we
don't
necessarily
have
to
treat
them
as
I
think
we
do
treat
them
as
a
monitoring
service
already,
but
yeah
and.
C
C
Yeah
yeah
exactly
so,
we
might
want
to
go
on
a
team
level
rather
than
on
the
surface
level,
sometimes
like,
for
example,
the
observability
team
will
own
tunnels,
service,
primitive
service
and
whatnot
right
and
the
foundation
team
will
own
only
gke,
but
they
won't
own
gcp,
or
at
least
not
all
of
it.
If
that
makes
sense,.
B
Arranging
them
in
that
way
makes
it
very
easy
to
then
talk
about
things
like
ownership
and
what
what
level
of
ownership
is
required
for
things,
and
it
also
means
that
certain
you
know
the
same
way
that
in
the
product
organization,
each
of
the
feature
categories
has
a
certain
level
of
maturity
from
minimal
to
lovable.
We
do
the
same
thing
with
the
services
with
the
service
maturity
model,
having
it
everything
having
every
service
rated
from
zero
to
five
or
use
a
similar
language
to
product
as
well.
But
it
then
makes
this
easy.
A
C
D
D
So
I
think
there's
a
there's,
a
really
important
point
there
that
that
I
think
I
wanted
to
kind
of
put
in
at
the
bottom,
but
I
think
we
should
at
least
for
this
iteration
keep
the
structure
mostly
the
same
prune
it.
So
we
can
do
that
by
I.
Think
at
the
moment
it's
a
list
of
services
in
each
service
has
got
a
team.
D
So
if
we
wanted
to,
you
can
have
multiple
teams
in
there,
but
I
I
think
the
way
we're
going
is
we're
going
to
go
to
one
team
per
service
right,
and
we
can
do
that
with
the
way
it's
structured
at
the
moment.
But
if
we
completely
change
the
the
structure
of
that
yaml
file,
this
is
going
to
become
a
like
a
Stalingrad.
D
You
know,
there's
endless
number
of
things
that
are
going
to
have
to
be
refactored
if
we
just
trim
it
down.
Other
reason
why
it's
really
nice,
if
we
keep
the
structure
roughly
the
same,
is
that
is
that
the
reliability
teams
can
start
on
their
side
of
the
work
now
and
then,
when
the
scalability
teams
start
trimming
and
pruning
the
catalog
the
work
you
know
it
doesn't
have
to
be
redone
or
anything
like
that.
Those
two
things
can
actually
happen
in
parallel.
B
A
Yeah
this
is
where
I'm
a
little
bit
worried
about
the
explosion
of
services,
because
we're
using
Services
both
for
impact
and
like
root
cause
and,
for
example,
like
the
API,
is
probably
a
service
that,
like
that,
we
use
when
we
talk
about
like
an
incident
caused
impact
to
the
API,
but
that
probably
incorporates
all
the
teams
right
like
it
doesn't.
There's
I
wouldn't
assign
a
team
to
the
API
service.
C
That's
an
issue
that
I
opened:
that's
LinkedIn,
the
that
Andrew
LinkedIn.
The
main
issue
is
like
I
kind
of
like
that
issue
is
discussing
like
we
shouldn't
use
the
API
service
anymore.
We
should
use
the
feature
category
saying
like
hey.
This
route
ended
up
destroying
the
API
subject.
So
technically
it's
not
the
API
service.
It's
like
I,
don't
know
feature
category
like
the.
D
D
C
D
A
D
Is
already
there
is
already
well
there's?
Actually
the
opposite:
there
is
a
an
annotation
in
the
in
the
metrics
catalog
that
says
that
this
service
is
always
associated
with
this
feature
category
and
so
for
the
container
registry.
And
then
what
happens
is
that
when
that
fires
it
will
it
can.
You
know,
because
the
alert
manager
routing
uses
that
information
already.
It
will
look
that
up
and
then
figure
out
which
slack
channel
to
send
the
message
to,
and
so
I
think
that's
already
been
used
for
that
purpose.
Yeah.
A
A
This
single
source
of
Truth
for
services,
I
was
hoping
there'd,
be
kind
of
like
a
low
friction
way
to
create
a
new
service
that
would
also
enforce
like
some
of
the
minimum
things
that
are
necessary
for
the
service.
We
can
do
this
in
CI.
Of
course,
like
you
know,
you
just
submit
a
Mr,
but
I
was
hoping
to
make
it
lower
friction
so
that
we
encourage
like
services
to
be
generated
if
they're
necessary.
D
A
B
D
D
That
was
a
joke
of
course,
but
they
you
know,
they
managed
just
fine
with
with
with
you
know,
changing
that
document
there's
a
huge
amount
in
there
and
they
managed
to
do
that
with
with,
with
with
a
with
merge,
requests
and
and
they've
done
it
for
a
long
time,
and
it
works
pretty
well,
they
can
do
it.
We
can
do
it.
C
So
if
we
do
it
in
merge,
requests,
I
also
feel
like
it
should
be
within
the
runbooks
repository,
let's
say,
like
I
make
a
command
like
make
new
service,
for
example,
and
you
give
it
the
service
name
and
it
scaffolds
everything
for
you
and,
like
you,
can
see
like.
Oh,
this
is
all
the
changes
I'm
making
I'm
creating
a
service
I'm
creating
dslos
like
do
we
do.
We
need
slos,
for
example,
so
trying
to
hide
it
from
what
what
house
feels
too
much
of
an
abstraction
for
me
and
I
also
feel
like
Barcelona.
A
A
A
D
A
A
This
is
the
issue
I'm
tracking,
that
you
know
I,
guess
like
I'm,
probably
not
going
to
end
up
doing
this
work
Rachel,
but
I
want
to
at
least
establish
what
we
want
to
do
for
the
first
iteration
I
think
this
is
mostly
just
copying
from
Andrew's
thing,
so
establishing
new
mandatory
Fields,
because
the
there
are
mandatory
Fields
already
and
a
lot
of
them
don't
make
sense.
So
we
need
to
like
establish
what
they
are
use.
A
B
A
D
B
A
C
I
guess
ownership
is
an
overloaded
term
who,
what
do
we
mean
by
ownership
like
if
it's
developing
the
future
and
that's
you
said
racially-
you
even
went
into
a
lot
more
detail,
who's
on
call
performing
the
upgrades
and
doing
critical
changes
and,
for
example,
for
Italy,
let's
use
Italy,
for
example.
Right
now
the
ownership
was
under
the
utility
for
development
and
things
like
that.
But
for
operations
it
would
be
the
gitly,
stable,
counterpart,
I
guess,
but
they're,
not
just
the
only
personal
call
for
Italy.
B
But
the
thing
is
we
want
to
deliver
it
to
the
person
who
is
going
to
actually
do
something
about
the
warning
and
in
some
cases
that
warning
is
an
infrastructure
thing
like
add,
more
gitly
servers
and
in
other
cases
it
is
a
much
broader
thing
like
change
the
way,
you're
storing
data,
which
is
more
on
the
application
side,
and
for
us
being
able
to
figure
out
how
to
root
that.
It
would
be
helpful.
So
having
the
split
I
think
would
be
would
be
good.
C
B
Well
also
because,
at
the
end
of
the
day,
when
it's
not
done
on
time,
the
alert
is
going
to
land
up
with
the
reliability
teams.
The
the
driver
then
becomes
on
their
own
library
on
the
reliability
team
to
make
sure
that
they
beat
the
warning
that
the
Stage
Group
beats.
The
warning
I
mean.
Obviously
scalability
will
still
be
there
to
help
with
that,
but
we're
looking
at
so
many
different
services.
D
Examples
at
the
moment
in
the
Forum
is
owned
by
support,
so
I
mean
maybe
we
should
maybe
instead
of
like
which
I
don't
know
if
that's
correct
or
not,
but
maybe
if
just
thinking
out
loud
here,
we
keep
it
as
it
is
at
the
moment
where
we've
got
teams
in
the
teams.
Yaml
and
again,
this
kind
of
goes
back
to
keeping
the
structure
roughly
the
same,
and
we
have
the
service
catalog
in
service
catalog,
referencing
teams.
But
then
in
the
team
we
say:
team
type,
reliability
or
team
type.
B
D
A
A
A
A
I
thought
you
meant
I
mean
it
wouldn't.
Surprise
me
I
guess,
but
yeah
okay.
So
it's
not
done
right
now,
but
we
can
do
that
and
then
we
can
make
it
the
single
source
of
Truth
and
then
their
f
and
g
are
just
some
triops
and
I.
Think
I'll
move
this
from
out
of
the
out
of
this
first
iteration
issue,
because
I
think
you
know
reliability.
Team
can
do
this
later,
but
I
really
I,
don't
know
how
this
will
work
like
and
every
issue
have
a
service
label.
A
B
Sorry
I
was
just
crazily
typing
about
how
new
labels
are
created
in
the
system,
but
H.
This
was
just
to
make
sure
that
the
service
maturity
multiplication
still
works.
We
still
maintained
that
as
a
file
in
the
handbook,
and
we
want
to
produce
further
iterations
on
that.
So
as
part
of
the
first
iteration
of
this
work,
it's
just
making
sure
that
what
we
have
still
works
so
that
we
can
make
future
changes.