►
From YouTube: Discuss Staging timeline for Sharding team (2021-10-05)
Description
https://docs.google.com/document/d/1O-ykLHFybv-JapZRRNy0FNqr-WXwP58aWiAMgLiegq8/edit# (internal only)
A
So,
item
number
one,
please
record
we're
recording
we'll
put
this
on
the
youtube
playlist
for
db,
provisioning
and
I'll
include
a
link
here
when
we're
done.
Number
two
is
mine,
which
is
just
to
discuss
the
timeline.
Craig
had
the
first
comment
here.
He
just,
I
think,
just
wanted
to
state
the
things
that
he
thinks
are
important
and
I
think
I
pretty
much
agree
here.
The
immediate
need
is
to
make
sure
that
we
have
this
patronic
cluster
configured
as
soon
as
possible.
A
On
staging,
I
don't
know,
and
maybe
fabian
I
guess
since
you're,
just
coming
back
from
vacation,
maybe
you're
not
fully
caught
up,
I'm
not
sure
what
the
urgency
is.
Maybe
dylan.
Maybe
you
know
like
how
soon
like?
Are
you?
How
or
you
know
to
to
what
extent
are
we
blocking
the
sharding
team
right
now
and
what
is
the
timeline
for
the
sharding
team
for
getting
this
cluster
available
on
staging.
A
C
All
right,
I
think
I
got
my
stuff
sorted.
Yes,
I
was
preparing
for
my
statement.
The
I
mean
it's
hard
to
say
we're
blocked
or
not,
but
we
have
a
rollout
plan
where
the
sooner
we
get
this
stuff
on
there,
the
sooner
we
will
be
able
to
start
testing
some
of
the
application
changes
we
yeah
getting.
Basically
getting
a
cluster
up
and
running
on.
C
A
Okay
and
yeah-
and
I
understand
this
first
step-
that
really
has
nothing
to
do
with
the
sharding
team
or
the
application,
because
we're
just
deploying
the
cluster
and
expanding
the
replica
pool
like
it's
not
like
you're,
going
to
be
connecting
to
a
new
database
endpoint.
Yet
in
fact
we
don't
have
the
changes,
I
think
in
omnibus
or
the
charts
to
support
that
anyway.
So
so,
I
guess
I.
D
A
The
priority
here
right
is,
I
think,
to
get
the
cluster
deployed
into
staging
just
to
make
sure
that
can
be
configured
properly
monitored
properly,
with
the
idea
that
we'll
soon
like
in
the
next
couple
weeks,
hopefully
be
able
to
give
you
guys
a
database
endpoint
that
you
can
use.
You
know
that
the
application
can
use
for
the
ci
table
right.
C
Yeah
and
like
even
additionally
to
the
other
running
and
monitoring
like
there's
the
setting
up
a
standby,
petronee
cluster
connection
between
this
new
cluster
and
the
existing
ones.
So
that's
also
something
that,
like
you,
know,
needs
to
be
tested,
can
be
configured
and
that
you
know
it
doesn't
double
the
latency
or
something,
and
that
might
be
an
interesting
fact
for
us
to
learn
that
a
standby
cluster
has
double
the
latency
of
the
main
cluster,
consistently
and
or
worse.
For
example.
C
B
So
I
just
tasted
this
from
the
agenda
from
yesterday.
I
was
not
in
that
meeting,
but
I
think
this
is
sort
of
the
high
level
goals
that
we're
hoping
to
accomplish
in
october,
which
is
provision
the
ci
cluster,
deploy
to
staging,
get
the
replication
going
and
then
test
our
application
changes,
and
so
I
think,
in
terms
of
timing,
I
you
know
if
we
want
to
account
a
couple
of
weeks
or
so
for
us
to
actually
figure
out
how
how
to
configure
the
application.
There
will
be
issues
with
this.
B
C
Yeah
and
phase
three
you
may
be
able
to
like.
We
may
be
able
to
hack
the
application
to
do
phase
three.
Even
before
there's
some
small
change
we
need
to
get.
But
then
you
know
we
could
probably
deploy
phase
three
on
the
application
for
a
subset
of
the
gitlab
deployments
in
some
way
to
read
from
cr
replicas.
So
all
these
things
we
can
do
to
take
smaller
steps,
but
yeah.
A
C
B
A
It's
all
we
use.
Actually
we
don't
use
omnibus
at
all
anymore
for
rails,
because
all
rails
deployments
have
been
moved
to
kubernetes.
The
only
thing
we
use
omnibus
for
are
pages
which
doesn't
connect
to
the
database
and
gitaly
which
doesn't
connect
directly
to
the
database.
So
we
need
to
make
sure
the
chart's
changing.
A
Me
because
I
think
it's
really
like
a
simple
yeah
it'll
be
a
simple
thing
to
do.
You
know,
so
I
don't
think
it'll
probably
won't
be
a
blocker,
but
just
something
we
need
to
make
sure
we
have
covered
okay.
So
on
to
item
2b,
I
just
wanted
to
cover
or
kind
of
summarize
with
the
work
we
have
remaining
for
the
repeatable
database
provisioning.
A
B
To
interrupt,
I
think,
from
my
perspective-
and
I
hope
that's
understood
is
like
I
I
think
for
us
the
main.
The
main
concern
from
the
sharding
group
is
really
about
the
like.
So
when
can
these
things
happen
in
a
way
that
makes
the
infrastructure
team
comfortable?
Overall,
I
don't
think
there's
any
requirement
that
that
we
use
ansible
or
chef
as
long
as
the
database
is
is
there.
A
Yeah,
I
guess
the
the
only
issue
I
see
potentially
is.
I
don't
know
how
long
we're
going
to
be
in
staging
before
we
move
to
production,
and
my
hope
was
that
we
could
be
using
the
repeatable
database.
Provisioning
thing.
You
know
soon
and
you
know
obviously
like.
If
we
do
it
in
parallel,
then
I
guess
we
can
switch
at
some
point
when
we
feel
comfortable
with
the
ansible
step.
A
Yeah,
I
think,
that's
possible
okay,
so
then,
on
to
item
number
c
so
alejandro,
I
think
you're,
probably
the
closest
to
this
right
to
the
registry
dbwork.
Does
this
like?
Does
it
hurt
you
to
kind
of
think
about
doing
this
again
for
a
new
petroni
cluster
and
what
is
your
best
approximation
for
the
number
of
days
it
would
take
to
just
do
staging
and
you
know
spin
up
another
set
of
vms.
You
know.
A
D
A
D
A
D
A
C
Is
there
is
there
a
summary
you
could
give
me
on
what's
different
about
the
registry
petroni
cluster
and
our
main
patrony
cluster,
because
I'm
familiar
with
the
architecture
we
have.
You
know
a
pg
bouncer
dedicated
host
that
talks
to
the
primary
and
then
the
pg
bounces
on
the
data
nodes
themselves,
I'm
familiar
with
that
for
the
main
database.
But
is
there
any
differences
with
registry
that
will
be
important
here
to
highlight.