►
From YouTube: Ecosystem Mass Integrations Discussion
Description
Discussion related to the epic for mass-integrations at the group and instance level: https://gitlab.com/groups/gitlab-org/-/epics/2137
A
You
well
so
welcome
to
the
discussion
around
mass
integration
at
group
level.
What
I
want
to
do?
I,
don't
really
want
to
talk
through
the
entire
issue.
It's
a
really
big
epic,
but
let
me
give
you
a
high-level
view
of
what
the
goal
here
was
and
what
the
purpose
and
background
for
it
is
so
integration.
A
I've
talked
to
a
bunch
of
users
who
don't
understand
what
they
are.
There
are
also
a
lot
of
people
who
are
unable
to
use
them
because
they're
only
available
on
self-hosted
they're
not
available,
forget
lab
comm,
because
they're
at
they're,
an
admin
only
feature,
and
so
all
of
the
goodness
that
you
can
get
out
of
service
templates
just
doesn't
count
if
you're
on
get
lab
comm.
So
there
have
been
some
requests
for
bringing
service
templates
up
to
the
group
level
and
rate
from
instance
to
group.
A
A
What
sort
of
looking
for
more
standardized
in
functionality
so
that,
if
someone
is
used
to
integrating
one
thing
right,
so
they've
already
set
up
a
slack
integration
once
I'd
like
it,
so
that
if
they
decide
to
create
a
group
with
a
bunch
of
projects
in
it,
they
already
know
how
to
do
that.
Integration,
because
they've
done
it
once
before.
At
the
project
level,
right
so
like
making
all
of
those
things
aligned
from
user
experience
or
point
I,
think
it
adds
a
ton
of
benefit.
A
The
other
thing
that
we
can
we
can
realize
out
of
this
is
if,
if
we
better
align
the
functionality
with
this
feature
across
these
different
chunks
of
abuses,
it'll
be
easier
for
us
to
stand
this
up
in
the
future,
and
there
are
a
couple
of
issues
that
are
open
right
now:
around
project
service,
X
and
project
service.
Why
don't
conform
exactly
the
way?
A
The
other
project
services
do
right,
so
I
kind
of
view
this
as
another
effort
to
like,
let's
really
dig
into
how
did
these
services
work
at
all
of
these
different
levels
and
while
I'm
not
saying
we
don't
need
to
do
we're,
get
lab?
We
don't
waterfall
in
here
right,
so
we
don't.
We
don't
want
to
set
up
a
three-year
roadmap.
A
Try
to
fix
this,
but
I
think
we
do
need
to
set
up
some
kind
of
a
Northstar
vision,
for
this
is
where
we
went
ahead
over
the
next
few
years
and
then
we
can
kind
of
once
we
have
that
set
and
we
understand
like
where
we're
driving
towards
then
we
can
iteratively,
add
things
and
change
things
as
over
the
next
few
quarters
and
years.
So
that's
the
context
for
why
I
wrote
this
and
I
will
say
in
advance:
it's
not
it's
it's
incomplete
and
that
I
did
the
integration
as
part
of
it.
A
I
think
there
needs
to
be
additional
description
around
how
to
handle
service
templates.
I
think
there
needs
to
be
an
additional
description
around
how
to
handle
web
hooks,
because
those
are
discrete
things
and
but
what
I
wanted
to
do
once
we
had
decided
to
have
this
conversation,
I
wanted
to
kind
of
wait
and
just
see
what
like
get
it,
get
a
pulse.
Checking
on.
How
do
we
feel
about
the
integrations
of
the
group
level
and
instance
level,
and
then,
given
that
feedback,
then
I
can
go
back
through
and
add
the
description
around?
A
What
what
do
you
serve?
As
templates
look
like
and
what
web
hooks
look
like
and
because
I'd
also
like
them
aligned
in
the
same
way,
but
I
didn't
want
to
triple
the
amount
of
content
when
we
hadn't
even
discussed
the
first
part.
So
there's
where
I
am
at
the
high
level
before
I
dig
into
kind
of
what
is
in
that
issue
and
kind
of
review
it
briefly,
and
do
you
have
any
questions
around
the
backgrounds
that
I
can
answer
or
anything
we
talked
about
or
about
diamond.
A
A
Are
yeah
okay,
so
service
templates
are
like
a
project
service,
so
a
project
service
by
the
way
and
I
have
a
note
in
there.
Like
my
first
note
on,
there
is
if
it's
been
brought
up
a
few
times
that
maybe
we
should
consider
rename
Project
services
to
just
integrations,
because
that's
confusing
so
anyway,
project
services
are
integrations.
That's
that's
how
we
integrate
with
things
and
a
service
template
is
like
a
project
service.
A
It's
stored
at
the
instance
level
and
when
you
have
a
service
template
created
for
let's
say
slack
all
new
projects
from
that
point
forward,
we'll
start
with
that
service
template
as
the
default
like
it
becomes
a
default
value
and
the
confusing
thing
for
some
people
around
it
is
not
to
dive
too
far
into
it,
but
part
of
the
problems
with
it
today
are.
It
only
applies
to
new
projects.
It
doesn't
retro
actively
apply.
So
if
I
need
to
change
those
settings
on
a
bunch
of
stuff
changing
the
project
service
does
not
help.
A
I
still
have
to
go
back
and
change
all
of
those
individual
impressions.
It
also
again
is
only
available
to
users
of
cell
phones
to
get
lab,
because
it's
an
admin
feature
anything
at
the
instance
level
is
unavailable
to
get
lab
comm
users
right,
which
is
a
significant
chunk
of
our
user
base.
The
majority
of
them
are
on
self-hosted,
but
there
are
still
a
lot
of
users
on
github.com
and
we
are
starting
to
see
some
people
wanting
to
migrate
towards
the
SAS
service.
A
C
I
also
have
like
a
small
question
sure
in
what
scenario
will
like
a
user
use
service
templates
on
Kayla,
calm
like
so
as
far
as
I
know,
like
the
pricing
model?
Is
it's
like
within
one
group
right
you,
you
only
want
a
group
which
is
active
in
one
company
and
you
can
configure
Group
group
templates.
There
I
mean
group
services.
So
when
we
didn't
you'd
like
service
templates,
is
it
to
mesh
at
multiple
groups,
I.
A
The
group
integration
yeah,
so
there
are
a
couple
of
group
integrations
but
they're
not
they
are
not
the
same
as
the
project
services.
So
one
of
my
goals
here
is
to
align
those
like
what
I'd
really
like
to
see
in
some
amount
of
time
again,
I
don't
know
waterfall
right
like
we're,
not
gonna
say
this
is
what
I
expect
any
year.
But
what
I
do
want
to
see
is
we
need
to
better
align
what
you
can
do
with
a
group
and
with
the
project,
because
I
think
the
user
assumption
is.
A
A
A
C
D
A
So
again,
like
the
idea
being
taking
all
of
those
things
that
are
available
at
the
project
level
and
then
moving
them
up
to
the
group
level,
I
think
would
be
really
valued
cool.
So
I
guess
that's
a
good!
That's
a
good
kickoff
point
and
let
me
eat.
Let
me
go
ahead
and
share
my
screen
just
so
we're
all
looking
the
same
thing
find
the
right
window:
cool,
okay.
A
So
again,
I
don't
want
to
read
through
this
line
by
line
but
I'm
gonna
kind
of
like
the
key
points
that
we
have
in
this
issue
and
the
key
things
that
I'm
thinking
about
and
then
what
I
want
to
do
is.
Let
me
kind
of
quickly
go
through
that
and
then
let's
kick
it
over
to
discussion,
because
I
really
want
feedback,
I
really
make
sure
but
I
also
I
know
Lieber
is
brand
new
and
Eileen
hasn't
been
super
looped
into
all
of
these
discussions.
A
So
I
want
to
make
sure
that
we're
all
on
the
same
page.
So
the
idea
here
is
today.
We
have
integrations
that
work
on
a
per
project
basis.
That's
it
the
goal
of
this.
This
overall
vision
is
to
take
that
same
functionality,
move
it
up
a
level
to
the
group
and
then
make
it
up,
move
it
up
a
level
to
the
instance,
and
the
advantage
here
is,
if
you've
got
an
instance
with
15,000
integrations
this
now
of
satan'
slack
right,
like
I've
integrated
15,000
projects
with
slack
today.
A
That
means
you
have
to
go
manually,
configure
that
15,000
times
by
adding
instance
level.
Integration
I
can
do
it
once,
which
is
huge
for
users
of
gitlab
com.
Maybe
I
still
have
15,000
projects,
but
they're
spread
across
20
different
groups.
Now
I
only
have
to
integrate
it
20
times,
instead
of
having
to
integrate
at
15,000.
Additionally,
beyond
just
the
creation
of
the
integration
and
we've
got
some
customers
who
do
things
that
are
crazy.
Like
rotating
passwords,
I
know
it's
nutty,
but
if
you
rotate
your
password,
you
have
to
go
change
that
password
15,000
times
right.
A
So
that's
a
really
big
pain
point,
especially
for
larger
customers
and
as
part
of
the
enablement.
That's
our
whole
goal
is
to
support
these
larger
installations.
So
what
I
want
to
do
is
take
that
and
migrate
it
up
to
those
those
two
other
concepts
and
then
I
also
want
to
create
an
inheritance
concept
so
and
I
know
I
really
want
to
talk
to
you
more
about
this.
Art
really
talked
a
little
bit
of
an
issue
and
but
I
really
like
the
idea
of
having
an
inheritance
model.
A
So
if
something
is
at
the
instance,
level
right
like
I
can
set
a
value
at
the
instance
level,
and
then
it's
inherited
up
to
the
final
integration.
So
what
that
means
is
I
can
set
a
default
value
at
the
instance
level,
and
every
project
on
that
instance
will
retain
that
value.
But
then
I
can
also
I
could
instead
set
an
additional
value
at
the
group
level.
So
in
this
instance,
right
I've
got
a
value
set
at
the
instance
level
I've
set
my
slack
username
or
whatever
my
slack
API
endpoint
at
the
group,
I'm
changing
it.
A
So
then,
the
actual
project
itself
will
reflect
the
the
lower
level
value
and
the
idea
here
being
that
this
kind
of
cascading
inheritance
allows
these
users
to
set
the
control
as
granularly
as
they
need
to,
because
you
can
set
it
at
any
level
and
then
it
will
automatically
populate
to
everything
below
it
and
then
I
think.
We
also
have
some
descriptions
in
here.
D
D
D
So
this
one
is
going
to
be
what
you
write
here.
If
you
have
this,
this
is
some
police.
We
have
these
or
these
right
so
a
for
me.
This
is
like
the
first
iteration
you
know
like
having
the
assistance
level
and
then
find
a
plural
level,
and
then
we
have
to
introduce
a
I'm
interest
50s,
because
this
is
we
are
lower
when
right
or
not
do
you
know
what?
But
then
we
can
introduce
the
new
level
configuration
so
basically,
what
we
are
going
to
is
to
check
it.
D
We
have
Freddie
11
or
guru
level
or
Eastern
instance
level,
but
the
problem
here
is,
you
know
having
so
groups,
then
I
need
to
track
what
we
don't
belong
to
what
other
group.
So
it's
not
going
to
be
like
that
straightforward
in
this
case,
a
to
know
exactly
you
know
like
the
tree
the
whole
tree
right,
but
this
is
like
a
very
high
level.
D
You
know
about
a
how
we
can
approach
this
from
more,
like
the
different
steps,
so
and
I
still
need
to
investigate
a
few
things
like,
for
example,
Hogwarts
the
API
access
level,
and
we
can
create
all
of
these,
not
with
the
UI
with
the
API,
and
also
what
happen
with
a
some
non-encrypted
tokens
that
we
have
for
some
services.
And
may
we
want
to
encrypt
this
before
we
start
to
introduce
a
more
configuration
of
some
services
that
then
we
have
to
migrate
them
to
encrypt
sure.
A
Okay,
so
what
I
want
to
do
is
this
is
great
and
I.
Also
thank
you
for
calling
out
the
high
level
overview
of
feature
and
consistency
on
UX
and
Lieber.
This
is
gonna,
be
huge
for
you
and
I.
Think
and
I
again,
like
I've
told
you
before.
Please
don't
dive
in
tomorrow
right,
but
I
think
there
is
a
ton
of
concern
that
I
have
around
creating
cognitive
overhead
between
like
I,
am
I
have
an
instance
setting
that's
been
set,
it's
being
inherited
by
the
project.
How
do
we
purply
show
that
right?
A
How
do
we
show
that,
where
you're
getting
that
data
from
or
what,
if
we
have
like
worst
case
scenario,
okay,
so
worst
case
scenario-
is
there
is
a
default
value
set
at
the
instance
there's
a
default
value.
That's
set
at
the
group.
That's
overriding
there's
another
default
value,
that's
being
overridden
by
my
sub
group
and
then
I'm
overriding
all
of
them
and
I'm
setting
my
own
custom
value
like
how
do
we
show
like
what
do
we
have
to
display?
Do
we
only
show
the
level
of
of
us?
A
Do
we
show
all
of
those
concerns
like
how
do
we
think
about
that?
So
it's
not
confusing
to
the
user
and
the
the
worst
possible
situation
is
the
user
opens
it
up
and
sees
like?
Oh
I
have
a
thing
configured
I
have
an
integration
set.
Where
does
any
of
this
come
from
and
then
like
nuke
it
and
you
know,
set
their
own
custom
flame-brain
so
like
we
need
to
be
have
a
lot
of
consideration
around
our
we
displaying
this
to
the
user.
How
are
we
informing
them
where
this
data
is
coming
from?
A
B
A
So
here's
my
take
I'd
love
to
hear
other
people's
opinions
and
I
think
we
should
focus
today
on
integrations
and
just
leave
service
templates
alone.
I
think
if
we
focus
on
integrations
get
the
project
integrations
lined
up
get
the
group
level
integrations
lined
up
get
instance,
level
integrations
lined
up,
then,
let's
reevaluate,
how
valuable
our
service
templates
I
think
one
ability
I
don't
want
to
I,
don't
want
to
call
this
canonical.
This
is
not
my
plan,
but
one
possibility
is
once
we've
got.
A
All
of
that
taken
care
of
what
service
templates
could
be
is
maybe
I
can
create
as
many
service
templates
as
I
want
at
any
one
of
those
levels.
Right,
for
instance,
in
group
right,
I
could
say:
I
have
five
JIRA
instances,
so
I'm
gonna
set
up
five
service
templates
for
JIRA
I'm
gonna
put
them
at
the
instance
level
so
that
a
project
owner
or
a
group
owner
can
just
go
like
oh
yeah,
that's
the
one
I
want,
but
it
becomes
it's
kind
of
like
how
we
do.
A
E
So
I
think
the
potential
conflict
I
see
what
that
is.
Is
this
idea
of
like
project
services
taking
the
override
value?
So
so,
if
I'm
understanding
correctly,
we
if
we
still
have
this
concept
of
service
templates,
then
we're
essentially
when
we
create
a
new
project,
we're
not.
We
are
seating
it
with
the
values
at
the
project
level
from
that
template,
so
that
it's
not
inheriting
from
from
the
group
or
instance,
level
done.
Okay,.
A
Correct
yeah,
so
it
would,
it
would
mean
that
we're
gonna
change
the
way
service
templates
work
slightly
and
I
think
the
reason
that
this
approach
works
today
is
since
service
templates
only
apply
to
new
projects.
It
would
be
the
migration
effort
would
be
as
simple
as
telling
customers
okay.
So
this
is
the
new
thing.
What
you'll
do
is
you'll?
Add
your
integration
at
the
service
level
or
the
group
level
turn
off
that
service
template
and
then
any
projects
that
you
don't
want
those
old
values
to
apply
to
you.
A
D
So
I
I
think
that
we
can
transition
from
templates,
distance
level
configuration
and
because
by
default,
unless
do
you
activate
something
like
configuration?
Is
deactivated
so
mm?
Let's
say
that
I
want
to
create.
Let's
say
that
I
have
a
service
template
right
now
right
and
we
transport
that
into
his
turns
11
configuration.
So
now
that
means
that
he
is
going
to
apply
to
an
employee
that
is
not
it
doesn't
have.
Any
configuration
is
going
to
apply
to
them,
but
they
for
me.
D
That
means
that
you
need
to
go
to
the
integration
and
activate
that
in
the
ratio
I
start
to
I
start
to
work
with
the
integration.
So
even
that
is
they
start
level
configuration
is
in
place,
is
not
active
for
anything.
Unless
you
go
and
you
activate
the
same,
you
know
so
you
can
transition
from
that,
because
by
default
everything
is
turned
off.
So
then,
if
you
want
to
have
it,
then
you
create
an
employee.
It
and
you
can
say
a
you
know,
like
use.
D
My
inherits
values
coming
from
the
group
of
the
base
times
or
I
can
write
my
own
point
on
properties
at
the
project
level.
So
I
think
that,
for
that
reason,
I
think
that
we
can
transition
in
that
place.
I,
don't
like
the
idea
to
have
two
different
things.
Do
not
like
that.
Then,
when
we
click
an
employee
at
that,
you
know
is
coming
from.
D
A
If
we
can
transition
service
templates
to
being
our
instance
level,
integration,
I
think
that
would
be
huge
and
then
I
think
it
can
be
a
let's
revisit
that
concept
later,
like
I,
think
that
what
we're
talking
about
here
is
a
much
more
powerful
tool
and
maybe
later
if
it
would
be
valuable
to
have
templates
like
great.
Let's
revisit
that
at
a
later
date,
like
I,
don't
I
think
that
the
ability
to
set
defaults
is
a
much
more
powerful
and
much
more
useful
to
our
users.
A
C
Justin,
what
do
you
got?
I
was
just
going
to
say
that
that
concept
out,
like
templates
right,
sounds
like
quite
familiar
with
like
like
apps
I'm,
not
sure.
If
you
know
like
slack
apps
right,
you
can
install
an
app
and
you
can
configure
it.
So
it
sounds
something
like
it.
So
maybe
eventually
can
become
something
like
that.
Just
a
thought,
but
yeah
like
we
can
think
about
it
later.
Okay,.
A
A
The
next
step
is:
let's,
please
help
me
figure
out
how
we
can
break
this
into
small
issues
that
we
can
start
scheduling,
because
I
think
we
can
kind
of
given
that
we're
all
on
the
same
page,
I
think
we
can
now
break
out
into
a
couple
separate
threads
I
think
that
Libra
and
myself
can
start
working
on
setting
creating
some
mock-ups
or
what
these
things
are.
Gonna
look
like
on
the
UI
and
I
think
we
can
start
figuring
out
how
we're
gonna,
refactor
those
services
and
I
guess
we
didn't
get
to
talk
about
it.
A
One
thing
that
we
do
need
to
know
I
do
think
it
makes
sense
to
probably
rename
it
from
a
project
service.
If
it's
going
to
apply
at
the
group
level,
it
doesn't
make
any
sense
to
call
it
a
project
service,
so
something
to
think
about.
If
anybody
has
a
better
suggestion
than
integration,
that's
fine,
but
I
think
we
probably
need
to
look
at
refactoring
that
any
last-second
additions
before
we
drop
cool
well.
Thank
you
all
very
much
for
your
time
and
I.
Look
forward
to
your
your
feedback.