►
From YouTube: Container Registry deployments and migration sync
Description
Related to the following issues/MRs:
- https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/316
- https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43754
A
A
If
there
is
any
developer
around
when
that
happens,
and
these
issues
were
not
a
concern
so
far,
because
mostly
we
have
been
doing
one
two
at
most
registry
deployments
per
month.
So
it's
not
a
big
issue
to
to
have
that
and
most
of
those
were
minor
improvements
or
something
that's
strictly
not
related
with
any
functionality
on
the
api,
but
with
the
upcoming
database
for
the
registry.
A
A
We
bump
the
version
in
cng
wait
for
that
to
be
merged,
and
then
we
have
to
bump
the
version
in
kubernetes,
workflows
and
wait
for
that
to
be
merged,
and
then
someone,
I
assume,
picks
up
that
task
on
on
background
and
actually
rolls
out
the
new
version
to
the
various
environments,
and
there
is
also
note
of
observability
around
when
that
deployment
happens.
So
there
is
no
notification.
A
So
one
of
our
requests
was
around
automating
the
current
process
before
adding
any
of
the
database
logic,
so
automate
just
what
we
know
right
now,
which
is
a
process
that
we
have
been
using
for
months
and
once
once
that
would
be
stable,
we
could
focus
in
adding
additional
functionality
to
support
the
database
migrations,
which
will
be
the
new
factor
here,
but
from
what
I
understanding.
This
might
not
be
the
best
solution
or
it's
not
not
a
viable
solution.
B
Okay-
almost
there
almost
not
really,
but
there
are
a
couple
of
things
you
mentioned
that
I
do
need
to
address
and
that
will
direct
the
the
conversation.
I
think
you
know
in
a
direction,
so
you
mentioned
like
the
the
fact
that
developers
are
not
around
when
things
get
rolled
out.
You
mentioned,
especially
the
need
for
mitigating
fast,
especially
with
the
database
changes
coming
in
then
predictability
around
when
things
are
going
to
get
deployed
and
then
also
no
observability
around
when
the
deploy
is
going
to
come
so.
B
Before
we
can
even
talk
about
any
anything
like
that,
I
can
give
you
a
bit
of
history
around
like
how
deployments
looked
at
gitlab
of
gitlab,
even
prior
register.
Being
migrated
to
to
kubernetes
is
just
to
paint
you
a
picture
of
what
the
order
of
execution
was
of
certain
things.
So
I'm
not
gonna
go
in
deep
history
like
eight
years
ago,
but
let's
go
two
years
ago,
which
is
where
a
lot
of
these
stories
start.
B
So
in
order
for
us
to
remove
the
need
for
anyone
to
monitor
a
specific
line
of
code,
that
is
going
anywhere,
we
do
automation
and
then
what
happens
if
you
and
haley
might
not
like
you
rolled
things
out,
but
you
might
go
on
a
vacation
the
next
day
right.
It's
that's
why
you
want
to
remove
the
manual
integration
intervention.
The
mitigate
the
fast
mitigation
fast
mitigation
goes
down
the
route
of
reverting
quick.
B
It
doesn't
go
around
the
route
fixing
quick,
so
if
there
is
something
that
is
happening
in
production,
for
example,
that
is
not
something
that
you
want,
something
that
you
didn't
expect
you're
not
going
to
be
spending
those.
I
don't
know,
however
long
that
thing
lasts,
trying
to
fix
the
problem,
because
during
that
situation
you
are
likely
to
introduce
even
more
problems
because
you're
trying
to
rush
a
fix.
Instead,
what
we
do
is
write
code
so
that
you
can
easily
revert
it
back
or
as
easily
as
possible
right
in
registry
situation.
B
That
should
be
because
it's
a
new
service
that
should
be
done
from
the
start,
so
thinking
about
backwards
and
forwards
compatibility
is
really
important,
which
then
brings
me
back
to
the
point
one.
If
we
do
that,
then,
if
we
do
the
automated
qa
tests,
then
the
backwards
and
four
forwards
compatibility
gets
exposed
to
you
immediately
as
soon
as
things
go
into
into
pipelines.
Right.
B
When
something
happens,
that
is
something
that
we
shouldn't
necessarily
care
about
on
the
level
of
I
want
to
know
when
something
goes
in
production,
so
I
can
catch
a
problem.
It
should
go
down
direction
of.
I
want
to
know
when
something
went
in
production,
so
I
know
how
to
communicate
with
other
stakeholders
that
something
went
in
production
right,
and
this
is
where
you
we,
for
example,
in
gitlab's
case
in
gitlabrail's
case.
B
We
added
that
mr
widget,
that
you
see
like
probably
see
where
oh
this
was
deployed
at
staging
canary
production
at
this
point
in
time.
So
I
guess
that
is
the
the
the
whole
story,
and
I
think
I
was
trying
to
convey
that
message
throughout
our
discussions
and
that's
why
I
also
asked
about
the
container
registry
new
architecture.
B
How
are
these
deployments
going
to
look
like,
especially
with
database
migration
between
the
two
components,
because
then
you
have
two
squared
problems
right.
You
need
to
think
about
get
lab
rails
back
and
forth,
and
you
need
to
think
about
continuous
registers
back
and
forth
and
in
which
orders,
though
those
two
can
actually
happen,
and
if
you
like,
if
I
think
about
the
problem
and
how
we
resolved
the
the
complexity
of
this,
the
steps
were
very
clear.
B
B
How
do
we
quickly
mitigate
things
right
like
how
do
we
go
back
and
forward?
So
how
do
we
revert
quickly
and
then
the
tests
that
we
have
in
the
background
running
actually
expose
problems
xt
as
things
go
along
and
so
on,
and
so
on,
the
observability
part,
or
rather,
how
do
we
communicate
that
change?
That
goes
to
the
very
end
of
that
pipeline,
meaning
at
the
very
end
we
would
be
thinking
about.
B
How
quickly
can
we
do
that,
because
we
obviously
also
have
limited
amount
of
time
to
to
actually
address
everything
that
you
mentioned,
so
we
kind
of
focus
on
the
being
the
bigger
bang
for
our
buck.
So
sorry,
I
spoke
a
lot
and
I
feel
now
that
I
need
to
drink
some
water.
Does
that?
Does
that
help
at
all?
Does
that
give
you
like
the
context
and
do
you
have
any
questions
on
that?
One.
A
Yeah,
it
helps,
but
at
the
same
time
I
understand
that
there
is
a
wall,
a
lot
of
history
in
regards
to
the
gitlab
rails,
tooling,
processes,
and
all
of
that
that
probably
took
more
than
a
year
to
to
build
right.
Yeah
and
an
ear
is
not
exactly
what
we
have
in
mind
to
to
be
able
to
roll
out.
This
change
right
and.
B
I'm
not
saying
this
would
last
a
year.
What
I'm
saying
is
that
there
is
an
order
under
which
we
can
then
collaborate
and
do
this
faster.
So
if
you
create
right
now,
tasks
that
we
already
needed
for
the
past,
I
don't
know
how
many,
how
how
much
time
like
we
migrated
registered
to
kubernetes
without
that
visibility,
and
that
was
a
huge
risk
on
our
parts.
A
For
example,
you
mentioned
that
we
need
to
take
into
account
the
conciliation
between
the
registry
and
github
rails,
their
immigration,
so
they
play
with
each
other,
but
at
least
for
the
foreseeable
future.
Let's
say
off,
and
here
at
least
that
won't
be
a
problem,
because
we
won't
have
any
any
new
features
that
that
would
be
exposed
in
gitlab.
So
at
least
for
now,
we
can
iterate
and
leave
that
as
a
problem
for
the
future
step,
five
or
whatever.
B
Step
ends
up
being
right,
like
I
agree
with
that,
it's
more
about
I
want
to.
I
wanted
to
make
you
aware
of
this
situation
so
that
you
can
think
about
it
right
now
and
note
it
down
as
a
potential
problem
and
put
some
real
guards
around
it.
Right,
like
in
your
processes,
you're
a
small
team,
so
you
can
still
do
things
as
a
small
team
can
do,
which
is.
I
have
an.
I
don't
know,
issue
template
or
a
merge
request,
template
where
it
says.
B
B
A
B
I
would
I
would
first
reach
out
to
whoever
the
quality
counterpart
is
so
that
you
can
sit
down
with
them
and
work
through
the
requirements
that
probably
both
sides.
Both
you
from
from
package
team
and
also
quality
counterpart,
would
be
able
to
address
like
what
are
the
most
critical
parts
in
register.
Functionality
that
you
expect
will
be
changing
with
the
database
migrations
that
you're
going
to
be
introducing.
B
So
I
don't
expect
you
all
to
go
and
cover
register
with
all
of
the
tests
right
like
I
don't
know
whether
that's
even
possible,
but
we
need
to
think
about
the
class
of
tests
that
we
want
to
cover,
which
is
the
most
critical
user
phasing
test.
So
we
call
them
smoke
tests
for
everything
else
right
like
if
you
cannot
push
and
pull
from
gitlab
and
that
needs
to
reliably
fail.
That
can
happen
right.
So,
if
we're
thinking
about
registry,
probably
that
would
be
push
and
pull
to
begin
with
right.
B
B
We
can
discuss
how
those
migrations
will
run
and
we
now
have
the
backing
of
those
automated
testing
tests
to
decide
which
way
we
are
going
to
go
right,
like
that,
whether
we
are
going
to
go
very
basic
and
say
we
are
just
going
to
add
registry
migration
database
migration
at
the
stage
of
rails
migration.
Right
like
it
doesn't
matter
like
how
long
registry
runs,
we
can
just
run
those
migrations
or
if
the
changes
in
register
are
super
critical,
maybe
we
need
to
align
them
with
to
deploy
again,
I'm
just
painting
a
picture
here.
B
It's
all
about
the
order
of
execution
that
allows
us
to
open
up
more
of
these
discussion
points
and
like
do
things
quicker,
so
I'm
not
talking
about
a
year
here,
I'm
just
talking
about
a
closer
collaboration
that
will
shorten
that
time
as
much
as
possible,
but
it
has
to
happen
in
a
certain
order.
It
can
be,
let's
figure
out
the
migrations
and
then
will
write
tests
we'll
just
we
and
we
need
quicker
way
of
deploying
registry
to
production,
but
we
don't
have
the
test.
A
A
B
Quality
pipelines
are
there,
no,
that
that
would
be
the
expense,
not
significant.
Effort
like
there
would
be
effort,
but
not
significant
efforts,
and
as
long
as
you
give
us
a
heads
up
by
an
issue
that
you
are
starting
to
work
on
this,
we
can
put
that
into
our
backlog.
You
can
tell
us
like
you're
approximately
expecting
this
to
be
done.
I
don't
know
in
two
weeks
or
a
month
or
however
much
time
it
takes.
B
A
B
B
At
that
point
like,
if
you
think
about
the
timelines
for
delivery
of
all
of
these
things,
the
database
is
not
going
to
be
provisioned
overnight.
It's
not
going
to
happen
tomorrow.
Right,
like
there
is
work
that
needs
to
be
done
in
automating
that
or
provisioning
that
so
by
the
time
you
actually
get
the
full
database
that
you
can
use
for
this.
I
don't
know
how
big
it
is.
B
C
A
A
A
couple
of
a
couple
of
times
it
has
come
up
as
a
possible
working
group,
because
this
is
quite
a
large
change
and
after
this
work
we
need
to
start
working
on
deploying
it
to
production
and
then
my
rating
from
the
current
registry
to
the
new
one.
So
there
is
an
issue
for
that.
I
I
I
believe
you
actually
think
people
from
the
delivery
team
on
that.
We
also
bring
to
a
lot
of
other
people
to
review
it.
So
that's
another
concern.
Another
concern
that
we
have.
B
A
B
A
For
this,
for
this
effort
to
create
the
the
keyway
tests,
we
will
need
some
some
validation,
that
our
plan
is
with
the
delivery
expectations,
so
that
validation,
but
then
later
on,
when
the
registry
with
the
database
is
already
deployed
in
production,
we
will
have
to
start
the
migration
phase
and
that
will
probably
require
some
work
around
at
least
observability,
with
the
new
dashboards
to
track
the
price
operations.
And
all
of
that
so
I
would
expect
that
to
require
also
some
work
from
infrastructure.
B
B
B
Maybe
if
you,
if
you
have
like
the
the
start
of
the
project,
maybe
we
can
get
involved
then
and
see
whether
it's
necessary
to
actually
create
a
more
regular
sync,
whether
that's
going
to
be
a
true
working
group,
most
likely
right,
because
you
have
quality
counterpart.
You
have
infrastructure,
you
like
development,
probably
some
some
prioritization
from
product
as
well,
to
make
sure
that
you
can
move
forward
so
probably
would
need
to
be.
B
A
B
A
B
Okay,
so
I
want
to
give
you
just
a
link
just
to
see
like
what
kind
of
questions
infra
actually
asks.
You
are,
though,
in
a
good
situation
as
a
team
that
is
controlling
register,
because
a
lot
of
the
things
you
already
completed
right,
like
the
lab
kit.
Oh
my
god,
every
time
lab
kit,
for
example,
is
in
registry
right,
like
observability
registry
is
generally
good.
B
So
you
probably
won't
be
handling
majority
of
those
things,
but
I
can
give
you
the
link
just
to
have
a
general
idea
of
what
infrastructure
is
usually
interested
about.
So
that's
with
the
new
service
called
cass
and
that
service
didn't
go
infrastructure
got
asked
in
the
end
like
roll
it
out
in
production
was
the
ask-
and
we
had
a
lot
of
things
missing
to
do
that,
so
it
would.