►
Description
Discussing a way forward in https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/16115
A
A
Any
questions
so
far
on
that
awesome.
So
I
wanted
to
set
up
this
meeting
because
we
had
some
async
discussions
on
the
issue
about
some
proposals
on
what
we
can
work
on,
and
things
like
that.
But
before
going
through
that,
I
wanted
to
ask
like
are:
are
we
creating
a
solution
for
a
problem
that
does
not
exist
like
do
do?
Do
we
actually
need
a
stable
counterpart
in
the
sense
like?
A
B
I
think
the
main
issue
we
could
solve
that
is
sort
of
a
a
lingering
time
bomb
is
the
lack
of
expressive,
specific
expertise
in
italy
on
the
infrastructure
team,
and
this
affects
incident
response
in
particular,
but
over
time.
I
think
it
also
affects
what
infrastructure
design
changes
you
make.
That
might
turn
out
not
to
be
a
good
fit
for
italy
simply
because
we
couldn't
articulate
it
well,
and
you
didn't
have
the
the
necessary
insight
to
to
take
it
into
account.
C
B
A
Iteration
of
having
stable
counterparts-
we've
tried
this
before
in
the
past,
but
with
a
lot
less
people
in
the
team
and
a
lot
less
focus
time
as
well,
because
we
only
recently
had
like
30
people
on
the
reliability
team,
and
now
we
have
kind
of
the
bandwidth
to
do
this.
So
we
don't
have
that
scope
at
the
moment,
and
I
think
this
is
one
of
the
first
iterations
to
do
that
so
yeah
agreed
there
excellent.
A
B
B
A
Agreed
yeah
and
we
can
also
have
like
a
voice
in
the
infrastructure
about
the
design
because,
like
I
saw
a
comment
on
some
prefect
merchant
was
one
day
and
I
was
between
matt
and
jakob
and,
like
matt,
provided
a
point
of
view
from
an
infrastructure
department
and
like
jakob
said:
oh,
that
makes
complete
sense,
but
I
didn't
have
visibility
around
that
and,
like
I
think
having
that
is
actually
what
can
solve
a
lot
of
problems
there.
So
I
agree
with
that.
A
B
We
had
we
had
a
long
internal
discussion
about
the
details
of
it
and
now
that
now
that
it
seems
feasible,
we
don't
think
there
will
be
major
blockers.
We
also
found
that
it
solves
actually
a
lot
of
problems
that
we
have
now.
Some
is
writing
up.
What
was
a
fairly
fragmented
discussion
on
an
issue.
Is
writing
a
design
doc
so
that
there
could
be
a
second
round
of
review
without
having
to
you
know,
piece
together.
The
information
yourself
got.
A
B
And
this
is
our
q3
and
from
then
on,
I'm
hoping
that
this
will
be
blessed
by
everybody
who
needs
to
bless
it,
and
then
we
can
go
and
implement.
The
pla
is
including
the.
How
do
we
iterate
towards
results
and
how
do
we?
How
do
we
actually
get
there,
because
I
guess
that's
also
at
as
hard
as
the?
How
will
it
work.
B
B
The
current
hope
is
that
it
will
mostly
be
by
osmosis.
So
as
we
upgrade
software,
the
plan
is
to
start
using
raft
like
keep
postgres
keep
everything
running
as
it
is
just
start
using
graft.
In
the
background
to
also
replicate
information,
and
once
that
works,
then
we
figure
out
how
to
switch
over
and
then
remove
all
the
postgres
and
that
this
would
efficient
effectively
take
all
the
single
nodes
into
a
single
node
cluster
situation,
which
aligns
very
well
with
our
goal
of
that
there
shouldn't
be
cluster
and
node
cluster.
C
Hey
sorry
still,
oh
god,
I
wanted
to
go
back
to
the
previous
point
quickly
and
just
on
a
on
a
higher
level.
Also,
maybe
give
a
little
bit
of
input
from
kind
of
the
scalability
side.
So
I
think
the
collaboration
has
been
working
pretty
well
between
guitar
and
scalability.
I'm
I'm
pretty
happy
with
that.
C
C
So
it's
very
much
within
that
realm,
but
that
leaves
a
lot
of
stuff
kind
of
out
of
scope
and
where
I
see
the
biggest
gaps
are
operational
tooling,
and
it's
already
hinted
at
a
bit
later
in
the
agenda.
We
can.
We
don't
have
to
go
into
the
details
right
this
second,
but
how
do
we
manage
our
italy
fleet?
How?
How
do
we
provision
and
rebalance
the
the
shards?
C
A
Yeah,
I
think
that
makes
sense-
and
I
agree-
that's
so
so
like
jumping
on
a
bit
on
the
proposals
for
projects
that
the
sr
team
can
work.
So,
for
example,
the
c
group
stuff
that's
from
what
you
just
described,
eco,
that
really
falls
under
the
scalability
team
rather
than
because
that
is
more
cpu
constraint.
Like
constraining,
cp,
cpu
usage.
Things
like
that
feel.
C
A
B
C
A
Awesome:
okay:
okay:
let's
look
at
the
time!
Okay,
15
minutes
left,
so
I
was
gonna
jump
on
to
like
how
can
the
sre
team
become
more
involved,
like
the
reliability
team,
specifically
get
more
involved
in
in
the
design
dock
for
for
bluster?
Is
it
a
matter
of
just
waiting
for
sami
to
write
down
everything
and
then
we'll
just
review
that
merge
request
or
is
there
anything
else
that
we
can
do
there.
B
B
A
B
A
Okay,
so
looking
at
the
current
projects
that
the
sra
team
can
work
on
like
for
this
quarter
and
the
next
one
coming,
so
it's
pretty
clear
that
support
for
getting
cluster
our
architecture
direction
as
number
one
priority
since
that's
gitalis
okr,
so
you
can
kind
of
tie
those
two
together,
there's
also
the
like
the
c
groups,
rollout,
that's
ongoing
and
I'm
curious.
If
like
should
the
reliability
team
pick
it
up.
A
I
know
rachel
raised
some
concerns
around
that
because
of
ramping
up
time
and
like
context,
switching
and
things
like
that,
I
I'm
curious
to
hear
andrew's
opinion
on
this.
Like
is
there
a
lot
of
work
still
left?
Is
there
like
a
big
amount
of
context
together
around
it?
Or
can
we
like
kind
of
pick
it
up
in
two
weeks
and
like
continue
the
work
with
the
guitar
team
to
get
that
ready.
C
A
A
C
C
A
B
Before
you
do
that,
I
have
a
meta
question
about
the
stable
counterparts.
I
want
to
make
sure
that
this
is
not
in
addition
to
all
their
regular
responsibilities,
because
then
they
still
have
the
full
scope,
and
it's
like
some
of
that
time
at
least
needs
to
be
dedicated
to
this,
so
for
them
to
be
efficient.
A
Yeah,
no
so
from
what
I
understand
from
can
both
me
and
calliope
are
gonna,
be
quantum
code,
full-time,
stable
counterparts
and
the
scientists
in
the
sense
that
any
issues
that
come
up
like,
for
example,
I
don't
know
c
groups
dot
and
the
rough
architecture.
That's
what
we're
gonna
start
working
on
next
week,
for
example,
cool.
That's
the
kind
of
commitment
that
we're
thinking
about
and
also
like.
Even
when
we
start
discussing,
like
I
don't
know,
ssh
access
for
digitality,
yeah.
B
A
B
B
A
Number
one
priority
for
disporters
to
be
getaly's
a
stable
counterpart,
and
if
that
means
like
giving
you
ssh
access
and
then
limited
or
in
a
safe
way,
and
then
that
would
be
our
p1
comp
and
helping
out
with
the
raft,
design
and
c
groups
rollout.
Since
the
c
groups
has
been
happening
in
waves,
kind
of
thing.
B
C
A
A
A
A
B
A
B
A
Do
that
okay
and
I'll
write
down
and
I'll
pick
with
a
proposal
of
the
things
that
we're
gonna
work
on
for
qt
q3,
which
would
be
rough
designs,
c
groups
and
potentially
ssh
access?
Unless
we
can
talk
about
this
async
unless
we
feel
like
rebalancing,
is
more
of
a
problem
than
ssh
access.
But
we
can
talk
to
that.
A
B
A
A
C
C
C
A
C
A
A
Awesome
so
thank
you,
igor
and
kaleopi
for
keeping
the
notes
up
to
date
on
the
agenda
up
to
date.
I
appreciate
that
because
I'm
terrible
at
doing
that
so
yeah,
I
think
we
have
a
clear
action
plan
for
now
just
to
continue
discussing
async,
especially
especially
on
priorities.
Is
there
anything
else,
that's
not
clear
for
anyone.