►
From YouTube: Geo: User flow discussion for maintenance/read-only mode
Description
The Geo team is thinking about improving GitLab's support for planned failovers. This is a quick view of a potential user flow for a maintenance mode/read-only mode to enable a GitLab Primary node and Secondary node to fully sync as part of a planned failover.
See https://gitlab.com/groups/gitlab-org/-/epics/2149
A
A
So
what
we
try
to
just
quickly
lay
out
we
just
finished
our
POC
thanks
to
Valera
superpowers,
of
how
maintenance
mode
could
work
and
we
just
wanted
to
sort
of
draw
out
how
the
journey
actually
looked,
looks
for
a
Systems
Administrator
and
a
regular
admin
and
yeah.
Let's,
let's
maybe
start
at
the
at
the
at
the
start.
It's
usually
a
good
point
to
start
you
what
you
want
to
do
it.
A
So
the
first
thing
that
we
believe
would
happen
is
you're
a
Systems
Administrator
and
you
want
to,
for
example,
perform
a
planned
failover,
which
is
the
scenario
that
we're
particularly
interested
in.
So
the
first
thing
is
that
you
need
to
do.
Is
you
need
to
decide
on
a
time
window
right
when
you
want
to
do
that?
For
every
see
you
may
need
to
send
out
emails
right
because
you
may
end
up
having
a
specific
amount
of
downtime.
A
So
you
need
to
inform
your
users
we're
not
really
tackling
this
right
now
and
then
like
when
all
of
this
is
done,
you're
going
to
log
into
the
gitlab
UI
on
the
primary
node
you
go
to
the
admin
settings,
you
would
select
maintenance
mode,
you
schedule
the
time
for
for
maintenance.
You
could
also
essentially
activate
it
now,
that's
an
option
in
the
current
time,
but
you
can
schedule
the
time
and
then
you
have
to
actually
create
a
deploy
page
message.
A
So
the
first
thing
is:
if
you,
if
they
use
a
regular
software
developer
navigates
to
the
web
UI,
they
will
see
a
maintenance
page
and
we
should
provide
a
sort
of
a
default
that
actually
explains
what
is
what
is
to
be
expected
so,
like
the
obviously
the
duration
of
of
this
area,
the
reason
for
it,
which
is
in
our
case
of
plan
failover.
But
it
may
be
another
use
case
as
well,
and
we
should
explain
that
they
can't
actually
access
the
regular
web
UI.
A
At
the
moment
they
will
not
be
able
to
write
like
white
to
the
API,
but
they
can
still
read
it
and
they
can
continue
to
essentially
pull
the
data
down,
forget
but
they're
again
not
able
to
actually
perform
any
any
write
operations
so
from
the
command
line
software
developer,
they
can
still
clone.
That
would
work
when
they
push
any
changes.
That
would
fail
and
we
probably
need
to
provide
some
kind
of
message
explaining
why
they
can.
They
can't
do
that,
the
same
really
for
the
API.
A
So
that's
the
user
behavior
we
anticipate
in
the
beginning
for
it
and
then
for
our
planned
failover
essentially,
and
we
are
still
working
on
making
the
simpler,
but
essentially
what
would
happen
and
what
we
we
think
is.
You
would
enable
maintenance
mode,
and
now
we
can
essentially
wait
until
the
primary
and
the
secondary
are
fully
in
sync:
that's
something
to
check
on
the
Geo
administrator
panel.
It
would
still
need
to
ensure
that
you
have
backups
of
all
of
the
other
data
types
that
are
not
replicated.
A
A
The
new
primary
would
be
back
to
normal,
and
when,
when
we
do
this,
essentially
the
downtime,
the
proper
downtime
for
four
users
would
come
in
somewhere
here
right
where
we
are
promoting
the
secondary
to
the
primary,
and
we
are
swapping
out
addresses
at
that
point:
access
Macy's
for
a
little
while,
but
for
like
the
most
part,
you
know
users
should
be
at
least
able
to
you
know
like
clone
stuff.
They
won't
be
able
to
navigate
to
the
web.