►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
One
of
them
is
asking
if
the
registry
will
be
the
same
version
or
with
different
configurations
or
a
different
version.
The
answer
is
that
it
will
be
the
exact
same
version.
Actually,
the
version
version
running
right
now
in
production
for
github.com
and
also
for
self-managed
instances
that
are
up
to
dates,
do
have
all
of
the
database
metadata
functionality
built
in,
but
it's
all
disabled
by
defaults.
A
A
A
B
Sure
so
I'm
just
curious
as
to
what
the
face
scenario
is
going
to
be
like
since
we're
going
to
have
two
registries
in
operation
and
since
they're
going
to
be
talking
to
each
other
to
some
extent.
I
want
to
make
sure
that
when
one
fails
we
still
we
have
some
method
of
maybe
not
blocking
traffic.
I
don't
want
to
have
a
situ
if
possible.
Like
I
don't
know
what
the
face
scenario
looks
like
today,
but
say
the
new
registry
fails,
but
the
old
one
is
still
in
operation.
What
happens?
A
A
A
Those
that
want
to
push
or
pull
images
for
existing
repositories
will
not
be
affected,
so
those
trying
to
push
new
images
will
see
a
service
and
available
response
getting
back
to
them.
Something
that
we
can
do
is
that
we
can
try
to
proxy,
and
if
it
fails
with
a
service
unavailable
response,
we
can
serve
the
requests
on
the
current
registry.
A
C
Yeah,
I'm
I'm
not
a
huge
fan
of
the
idea
of
serving
falling
back
for
new
registries.
It
should
be
served
by
registry
2,
I'm
not
a
big
fan
of
falling
back
to
registry
1,
because
I
don't
think
we
have
a
way
to
reconcile
tags
which
are
going
to
change
over
time
with
that
as
well
as
since
most
of
the
registered
traffic
is
right,
traffic,
it
seems
like
we're
going
to
give
ourselves
a
you
know
this.
This
data
migrate,
this
data
divergence,
headache
for
not
a
lot
of
gains.
B
D
B
Any
need
for
us
to
consider
having
a
canary
deployment
specific
to
the
new
registry.
Currently,
we
already
have
a
canary
deployment
for
production,
as
is
where
I
think
jarvie
could
correct
me,
but
I
think
we
serve
five
percent
of
the
traffic
to
the
container
registry
right
now.
What
or
do
we
need
to
consider
a
canary
for
this
new
registry
configuration
I'm
leaning
towards
no
based
on
the
fact
that
this
is
specifically
for
migration
purpose
and
not
necessarily
serving
traffic,
but
clarification
is
always
useful.
A
A
I
think
from
a
functional
perspective.
I
think
that
could
be
useful
because,
as
we
start
moving
more
and
more
repositories
from
the
existing
registry
to
the
new
one,
we
will
see
the
traffic
on
the
new
one
increase
and
the
traffic
served
by
the
existing
one
will
continue
the
same
because
everything
flows
through
it,
but
the
traffic
that
it
actually
serves.
A
A
D
Registry
yeah,
I
mean
I
yeah,
I'm
not
sure
how
this
so
we
so
the
way
it
would
work
is
that
we
would
have
registry
to
to
put.
We
have
we'd
have
registry
two
deployed
in
the
canary
name
space
so
that
five
percent
of
traffic
going
to
register.gitlab.com
gets
routed
to
canary,
which
would
then
be
proxy
to
the
registry
2
installed
in
canary.
D
D
You
know,
with
the
configuration
options
enabled
we
would
deploy
that
to
canary
first
watch,
metrics
and
kind
of
see
how
it's
behaving
before
we
graduate
that
change
over
to
the
zonal
clusters.
So
I
guess
maybe
this
is
more
of
an
infrastructure
question
than
an
application
question,
because
this
is
really
just
about
improving
the
safety
of
of
deployments.
D
A
A
Odd
thing
is
that
we
won't
be
able
to
do
a
gradual
increment
by
percentage.
So
when
we
proxy
request
from
the
new
registry
to
the
old
one,
we
can't
do
it
on
a
percentage
base.
Why
is
this
because,
for
example,
image
uploads
are
concurrent,
so
if
you
are
pushing
an
image,
there
are
multiple
requests:
writing
different
blobs
to
the
registry.
A
If
we
did
the
percentage
based
routing,
we
would
probably
end
up
with
one
block
being
sent
to
the
new
registry
and
the
other
one
sent
to
the
old
registry,
and
that
would
be
a
major
problem.
So
the
way
that
we
thought
about
it
is
that
we
are
going
to
do
and
moving
forward
with
this
plan.
We
intend
to
do
it
based
on
the
your
uri
of
the
request,
because
the
uri
has
the
path
to
the
repository,
so
we
can
do
it
using
the
path
of
the
repository.
A
D
Okay,
so
if
that's
that
that
helps
with
the
gradual,
phased
rollout-
and
I
think
what
we'll
probably
do
is
want
to
do
like
gitlab
or
right
as
maybe
gitlab
org-
would
be
one
of
the
first
things
we
try
for
internal
or
maybe
even
more
restricted
than
that.
But
I
I
assume
that
would
only
be
for
the
initial
rollout
right
like
you
would
you
would
start
with
that
and
then
very
soon,
after
that,
you
would
use
registry
2
for
all
new
for
all
new
projects
and
then.
A
We
also
have
a
feature
flag
which
will
enable
us
to
continue
to
write
that
metadata
to
the
to
the
bucket
as
well.
In
parallel,
the
new
registry
won't
use
it,
but
if
we
need
to
sync
data
bike,
that
means
that
we
can
just
sync
the
lighting
in
the
bucket
into
the
old
one
and
have
the
the
old
registry
server
all
requests
for
repositories
that
were
created
in
the
in
the
new
registry.
D
D
Skybacker
is
that
all
you
have
for
five?
Yes,
okay,
honda.
Six
question
here
is
about
database
metrics,
since
we're
going
to
be
interacting
with
the
database,
whether
we're
going
to
have
something
in
prometheus,
we
can
use
logs.
Specifically,
we
we're
always
interested
in
seeing
db
durations,
for
you
know
for
any
interaction
you
guys
have
with
the
database.
We
get
this
out
of
rails
and
it'd
be
nice
to
see
this
from
the
registry
as
well.
D
F
D
D
D
D
So
my
question
here
is:
do
we
need
to
be
concerned
about,
and
we
often
will
like
deploy
to
the
regional
cluster
or
we
may
do
them
all
simultaneously,
but
it
really
depends
like.
I
don't
think
we
can
really
be
guaranteed
about
the
order
of
things,
and
that
sounds
like
it
could
be
a
problem
right.
I
think
the
worst
case
scenario
would
be
like
we
deployed
to
the
zonal
clusters,
which
has
registered
the
current
registry
and
it's
configured
to
point
to
registry
2
which
doesn't
yet
exist
right.
That
would
be
a
problem.
D
D
A
B
F
Yeah,
please
tell
me
if
my
internet
connection
is
breaking
up,
because
I
have
some
issues
right
now,
so
the
current
state
in
pre
for
registry
right
now
is
that
we
prepared
database
for
it,
and
I
also
set
up
a
console
node
so
that
we
could
give
access
to
developers
to
the
database
as
soon
as
we
add
them.
The
right
groups
and
the
question
would
be
which
developers
should
have
access
to
the
database
there.
F
But
today
I
just
tried
to
test
registry
and
pre,
and
I
saw
some
issues
there,
because
I
can
push
images,
but
I
don't
get
an
image
list,
for
instance
back,
so
maybe
you
should
first
make
sure
if
registry
in
3
is
working
at
all
before
we
switch
it
over
to
using
a
database
right,
and
so
the
question
is:
how
can
we
get
on
with
that?
And
also
when
should
we
do
the
switch,
because,
I
think,
just
talking
to
an
empty
database,
we'll
just
break
a
registry
right.
A
F
F
A
A
A
So
in
the
in
the
pre-pro
epic,
that
is
an
issue
to
import
the
data
from
the
existing
container
registry
into
the
warning
pre-production.
So
this
has
all
the
required
steps
to
do
the
first
deployment,
unlike
with
production,
the
pre-protection
registry,
is
tiny.
It's
like
one
gigabyte.
I
think
something
like
that.
So
we
can
just
import
the
light
in
a
one-off
operation
with
the
registry
cli.
A
So
the
only
thing
that
we
need
to
do
is
either
put
the
registry
in
gradle
only
mode,
remove
it
from
the
load
balancer
and
then
run
the
import
command
to
move
the
data
from
the
current
bucket
to
the
new
one
and
also
inside
the
metadata
database,
and
then
we
can
configure
it
to
to
use
the
metadata
database
and
and
to
use
the
the
new
buckets
so
before
this
we
will
have
also
to
create
a
new
bucket
for
for
the
registry.
I
don't
know
if
this
is
something
that
delivery
will
do.
F
B
A
We
can
also,
if,
if
it
takes
time
to
do
the
side-by-side
deployment,
we
can
also
do
the
same
one-off
migration,
offline
migration
in
staging-
if
we
want
to-
but
this
is
only
mean
for
us
to
be
able
to
start
testing
and
creating
the
dashboards
with
all
of
the
metrics
based
on
on
the
pre-production
deployment.
So
we
don't
need
the
side-by-side
deployment
to
to
do
that.
We
just
need
the
new
registry
to
be
updated
and
to
have
the
new
bucket
and
the
database
in
place
and
field
yeah.
B
B
A
A
So
that's
a
concern,
which
means
we
won't
be
able
to
see
much
more
than
we
are
already
able
to
simulate
locally,
which
is
us
doing
some
manual
tests.
So
I
was
wondering
if
we
could
somehow
fork
some
of
the
traffic
that
goes,
for
example,
to
the
dive
registry
into
the
staging
one.
For
example,
during
that
phase
I
know
we
have
a
lot
of
pipelines
building
against
the
dev
registry,
so
perhaps
we
could
have
a
period
of
time
where
we
would
switch
those
to
use
the
staging
one.
B
We
could
probably
try
to
figure
something
out.
Maybe
I
think
we'll
have
a
few
options,
whether
it
be
traffic
or
maybe
we
could
set
up
a
synthetic
like
ci
project
that
just
does
random
stuff
against
a
registry.
At
some
point,
if
we
don't
already,
we
should.
We
should
probably
have
an
issue
to
address
that
concern.
B
B
B
A
A
B
A
A
Okay,
so
I'll
open
up
a
few
issues
and
we
can
get
the
registry
operated
in
pre-prod
and
then
we
will
continue
discussing
whatever
is
needed
to
do
the
side-by-side
deployment
in
staging,
but
before
we
we
transition,
we
want
to
transition
from
pre-power
to
staging.
That
may
be
too
early
to
do
that.
Do
you
have
any
kind
of
estimates
on
how
long
it
will
take
us
to
get
the
side-by-side
deployment
working
once
we
are
ready
in
staging,
of
course,.
B
I
don't
personally
have
an
estimate,
but
you
know
this
is
relatively
decent
priority
for
our
team,
so
I
think
it's
once
we
get
pre-prod
going
staging
will
be
our
next
target.
So
as
soon
as
we
get
pre-pride
running
and
working
as
desired,
we'll
probably
just
make
sure
that
we've
got
all
any
closed
loops.
You
know
metrics
and
testing
procedures
nailed
down
and
issues
written
up.
I
think
we
should
be
able
to
start
that
work
pretty
much
immediately
after
that.