►
From YouTube: 2022-02-16 Workspace meeting
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
And
I
think
the
most
important
thing
is
how
we
proceed
with
backfilling
the
namespaces
table
and,
as
far
as
I
understand,
there's
an
issue
to
create
a
plan
that
needs
to
be
approved
by
database
team
and
the
infrastructure
team.
Because
it's
like
a
huge
change
and
it
can
be
a
huge
burden
on
the
system.
B
Yeah!
Sorry,
for
the
being
later.
B
Yeah
so
starting
at
the
beginning,
I
guess
I
I'll
try
and
give
an
update
on
what's
going
on
some
of
the
good
good
news,
and
not
so
good
so
yeah
on
the
locking
we've
got
dmr
merged,
which
is
great,
so
thanks,
yeah,
big
thanks
to
jan
alex
and
and
to
for
the
help
to
song
so
yeah.
B
The
good
thing
is
that
now
this
kind
of
unblocks,
the
backfilling
of
the
like
the
full
migration
of
the
project,
namespaces
that
one
the
other
good
thing
is
that
that
mr
was
approved
by
database
maintainer.
B
B
The
biggest
concern
that
was
raised
with
the
fixing
of
the
locking
on
the
main
spaces
is
the
fact
that
we're
using
that
private
api.
So
that's
not
super
safe.
I
I
guess
everyone
knows
the
risks
or
whoever
was
involved
in
the
decision
and
the
way
forward
is
to
try
and
move
off
of
that
private
api
as
soon
as
as
we
can
and
not
hold
out
forever.
B
So
my
next
thing
will
be
to
create
a
follow-up
issue
just
to
be
able
to
track
the
fact
that
we
need
to
move
off
of
that
private
api
as
soon
as
we
basically
backfill
project
name
spaces
that
will
probably
involve
more
discussion.
B
It
can
be
a
wider
topic
in
the
sense
that
once
we
have
project
name
spacing.
Basically
we
can
say
that
everything
is
a
namespace.
So
do
we
need
to
change
the
project
creation
workflow
at
all.
Do
we
need
to?
B
We
live
still
rely
on
their
workflow
like
having
different
uis
every
different
user
experiences,
but
then
we
need
to
somehow
handle
the
case
that
you
create
a
project
namespace,
but
but
the
project
itself
is
not
created
and
the
main
part
of
that
being
probably
the
repository
is
not
being
created
like
I,
I
didn't
think
through
all
of
that,
and
there
is
a
lot
of
moving
parts
there,
because,
like
projects
have
a
lot
of
tools,
I
don't
know
if
those
need
to
be
migrated
first,
in
order
to
change
the
workflow
but
yeah.
That's
that's.
B
That's
the
longer
term
term
fix
that
will
not
involve
that
private
api
that
that
kind
of
puts
us
at
risk.
If
somebody
unveils
project
decides
to
remove
it
for
any
reason
or
change
it
so
yeah
the
yeah.
So
that's
the
great
news
now
the
the
describing
the
path
forward.
B
B
I
need
to
test
it
on
staging
see
that
the
errors
that
we
were
seeing
there
are
gone
or
like
way
way
way
smaller
than
we
used
to
see
them
then
test
that
on
production,
and
only
after
that
can
we
go
and
do
the
actual
back
feeling
just
because,
once
again
we
need
to
make
sure
that
we
can
create
project
name
spaces
when
a
project
is
created
before
we
do
the
backfilling
or
otherwise
we'll
need
to
run
this
full
big,
huge
migration
once
again,
which
we,
I
don't
think
we
want
to
do,
because
it's
fairly
stressful
as
it
is,
so
we
don't
want
to
do
that
once
again,
so
yeah
that
that's
the
process
there.
C
Yeah-
and
one
thing
I
just
wanted
to
mention
too-
that
some
something
we
can
do
is
enable
the
feature
five
for
staging
and
we'll
just
have
to
coordinate
and
let
the
pipeline
dri
know
since
they'll
be
the
first
to
kind
of
see
those
errors
if
they
come
up.
C
But
I
guess
one
question
or
concern
that
I
had
is:
if
I'm
not
mistaken,
I
thought
when
the
feature
flag
was
originally
turned
on,
it
took
it
was
enabled
for
about
a
month,
and
it
took
about
that
long
until
the
errors
did
start
to
come
up.
So
one
thing
I'm
curious
about
is:
if
that
could
happen
again,
if
we
need
to
have
it
on
for
that
length
of
time,
so
yeah.
B
C
Yeah
that
that
is
interesting,
I
don't
know
if
there's
some
way
that
we
could
like
yeah,
like
you
said,
though,
it's
only
for
a
two
week
period
to
see
if
that
those
were
like
coming
up
beforehand.
If
yeah
like
a
century,
has
something
like
that,
I'm
not
quite
sure.
A
Yeah,
that's
my
question:
if
we
are
there
like
century
logs,
that
goes
way
way
before
the
one
week,
kibana.
B
Cutoff
we
do,
but
only
for
the
group's
endpoint
for
some
reason
I
don't
see
this
problem
in
century
appearing
for
for
project
endpoint
and
I
I
don't
know
yeah.
Do
we
have
the
staging
like
sentry
for
staging,
because
I.
B
We
do,
we
definitely
do
yeah,
so
I
think
I've
looked
and
I
didn't
see
any
of
the
project
creation
exceptions
there,
although
they
were
in
in
kibana.
I
could.
I
could
see
the
exception
in
kibara,
so
I
don't
know
what's
that
about
with
the
centurion
and
project's
creation
endpoint,
maybe
we
don't
load
them
in
incentive
or
other
things.
I
don't
know.
What's
going
on.
B
I
guess
point
four:
it
is
then
yeah.
There
is
an
update
on
the
back
feeling
as
a
whole
because,
like
the
back
feeling,
michelle
asked
the
other
day
like
an
overview,
and
we
we
talk
a
lot
about
project
namespaces
backfilling,
but
there
is
kind
of
site
or
related
things
to
that.
Also
that
are
going
to
be
needing
backfilling
at
a
similar
scale,
I
would
say
perhaps
not
as
impactful
but
but
but
the
same
size,
although
one
would
argue
that
memberships
and
routes
is
pretty
much
as
impactful
as
as
the
namespaces
themselves.
B
So
on.
On
that
note,
we
yeah
I've
posted
an
update
and
as
a
summaries
that
any
book
feeling
that
is
strictly
linked
to
having
project
namespace
is
obviously
not
done,
because
it's
blocked
by
that.
But
then
there
are
parts
of
the
backfilling
that
are
related
to
existing
namespaces
and
mainly
like
groups
and
and
usernamespaces
that
do
happen
right
now.
B
I
think
we
we
have
this
migration
happening
for
routes
for
the
namespaces,
which
is
running,
and
I
I
know
there
was
an
update
from
someone
on
the
database
team
that
there
were
a
couple
of
failing,
well
a
few
hundred
failing
jobs.
So
we
need
to
look
into
that
I've.
I've
asked
for
some
ways
to
check
on
that
information,
because
right
now
that
information
is
only
available
to
database
maintainers.
B
So
it's
kind
of
hard
to
get
more
details
on
that.
Yet
so
yeah
those
are
kind
of
going
along.
But
then
once
we
have
the
filling
of
the
project
name
spaces
we
can
move
on
with
it
with
the
parts
of
the
with
other
parts
of
the
back
feeling.
So
like
I
don't
have
a
percentage,
but
I'd
say
it's
fairly
close
to
zero,
if
not
zero.
Just
because
most
of
the
stuff
is
dependent
on
the
project.
Namespaces.
A
One
question:
we
are
migrating
routing
routes
like
crafts
table
right
now
for
groups
and
personal
namespaces,
and
we
decided
to
do
that
right
now
to
like
spread
it
out,
not
backfill
the
whole
crowds
table
at
once,
because
like
we
will
need
to
backfill
the
routes
for
projects
as
well.
At
some
point,
so
I
think
this
decision
was
to
do
it
like
in
those
kind
of
batches
to
not
run
the
one
big
migration.
B
Yeah
it's
for
two
reasons.
One
is
what
you're
saying
to
kind
of
split
this
big
migration
into
two
parts,
the
other
the
other
reason
being
just
unblocks
us
and
doing
stuff
like
not
waiting
exactly
to
do
everything
before
well.
When
we
get
the
back
filling
down,
so
we
can
do
one
part
now
move
forward.
B
Slowly
so
and
then
the
other
part
will
will
will
basically
have
the
code
will
basically
have
the
experience
sort
of
to
do
the
the
migration
and
we'll
only
have
to
do
it
for
a
part
of
the
of
the
table,
which
is
probably
the
bigger
part,
because
we
do
have
more
projects
than
names
than
groups,
but
still.
A
Yes,
when
we
were
meeting
with
database
team,
I
think
back
in
november
we
had
this
agreement
that
before
before
launching
the
big
backfield
for
namespaces
table,
we
will
create
a
plan
how
to
do
it
and
how
to
roll
back.
If
necessarily
so,
just
like
my
friend
re
reminder
like
do
we
have
this
plan?
Are
we
working
on
this
done?
What's
what's
going
on
with
that.
B
Yeah,
I
think
I've
started
an
issue
right
away
at
that
time.
Unfortunately,
it
was
not
linked
in
the
I
just
noticed
today
was
not
linked
in
the
epics,
so
I've
linked
it
to
the
epics
but
yeah
the
discussion.
They're
going.
That's
basically
what
landed
us
on
using
the
batched
migrations,
where
we
have
like
more
control
over
the
running
the
migration
itself.
We
can
pause
it
if
anything
goes
like
wrong.
B
So
to
say
we
can
pause
the
migration
at
the
level
that
it
is
and
then
decide
how
we
want
to
proceed
further
on
start
deleting
records,
because
well
what
we
didn't
want
is
is
have
the
deletion
automatically
when
you
kind
of
want
to
stop
everything,
because
that
can
add
even
more
contention
to
the
database,
because
it
adds
more
rights
and
more
stuff
going
on.
So
this
kind
of
gives
us
control
to
pause,
evaluate
and
then
see
how
we
want
to
move
forward.
B
So
I
think
that
was
kind
of
agreed
upon,
but
if
we
need
any
kind
of
formal
sign
off
or
formal
agreement,
yeah
we'll
need
to
take
them
on
with
with
them.
A
I
would
say,
like
it's
better,
that
we
like
being
the
database
team
on
this
issue
and
the
infrastructure
team.
They
need
to
know
that
we'll
be
going
to
make
a
lot
of
rights
of
the
database
at
once
and
like
to
be
aware
of
any
things
going
on
in
the
like
in
the
system.
A
B
A
For
database
team
definitely
alex
ives
and
for
infrastructure,
I
will
try
to
locate
the
right
person
to
ping,
but
I
think
the
database
team
is
a
like
first
stop
and
then
the
infrastructure
team.
A
Discuss
okay,
so
thanks
very
much
and
thanks
alexandra
for
this
big
update,
it
was
congratulations
on
on
the
emerging,
the
locking.
Mr,
I
know
it's
like
a
lot
of
work
from
you.
Yeah
fingers
crossed
okay,
so
have
a
great
day.
Everyone
and
see
you
next
week,
bye.