►
From YouTube: GitLab Pods & CEO Sync
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
B
A
Hello,
everyone.
This
is
the
gitlab
pods
CEO
agenda
meeting,
so
we're
kicking
off
with
a
few
updates,
for
you
said
the
first
one
is
a
happy
one.
We
have
a
new
team
member
join
Rutger
who's
actually
on
the
on
the
call
as
well.
So
the
parts
team
is
growing
which
is
exciting.
A
Yeah,
the
the
second
one
said
you
remarked
last
time
that
it
would
be
useful
to
cross-link
to
other
areas
that
are
potentially
impacted
by
pods.
So
we've
done
that
with
that
Mr
there's
a
section
now
that
highlights
the
cross-section
impact.
The
summary
is
that
workspace
and
organization,
as
we
proposed
it,
is
essentially
the
same
entity
we'll
use
one
not
both
so
we're
not
duplicating
any
effort.
The
group
workspace
is
also
conducting
some
user
research
on
naming.
A
If
workspace
is
the
correct
term,
for
what
you're
trying
to
accomplish
we'll
hold
off
renaming
until
we
we
have
that
data
overall
I,
don't
think,
there's
much
conflict
between
the
groups
I
also
with
fulfillment
their
goals,
I
think
aligned
with
ours.
So
I
think
at
the
moment
you
know,
Parts
is
going
to
make
some
things
a
little
bit
harder,
but
we're
in
touch,
and
there
are
no
blockers.
B
A
B
A
Think
this
is
this
is
something
that
I
hope
they
can.
They
can
align
on.
I
know
that
the
remote
development
environment
is
also
doing
some
research.
Nothing
there
proposed
is
a
little
bit
more
IDE
like
so
that
may
take
the
term
workspace
I
think
that's
good
impact.
A
B
Sorry
for
having
a
question
later,
but
can
an
organization
is
an
organization
always
on
one
part?
Yes,
okay,
where
is?
Is
that
in
the
Mr,
because
I
don't
find
it
but
I
haven't
read
the
whole
thing.
A
It
is
not
in
that
Mr,
but
it
is
in
the
technical
proposal
in
the
definition
of
the
the
term
yeah.
So
it
is
a
single.
Let
me
just
grab
it
for
you.
Yeah
I'll
share
my
screen
pretty
quickly.
A
B
B
B
Is
on
one
part,
maybe
add
a
thing
under
five
that
one
part
can
have
multiple
organizations
yeah.
B
A
All
right
so
Camille,
you
may
have
to
keep
me
honest
here,
but
since
the
last
time
we
spoke
with
iterated
on
our
technical
proposal,
we've
taken
the
POC
quite
a
bit
forward
and
there's
a
match
request
to
actually
summarize
the
changes.
The
work
at
the
moment
is
mostly
on
the
routing
layer.
A
So
how
to
get
requests
to
the
correct
pod
and
two
of
the
findings
so
far
are
that
it
appears
to
be
more
efficient
for
a
router
to
explicitly
ask
a
pod
where
to
go
to,
rather
than
randomly
choosing
a
pod
and
then
what
that
entails
is
that
in
that
architecture
we
have
to
very
likely
rewrite
some
rails
Roots
because
they
are
ambiguous
like
for
example,
API
V4
jobs.
One
two
three:
four,
because
we
don't
know
where
that
thing
is,
and
so
that's
a
piece
of
the
word
that
we've
identified.
C
So
I
I
mean
this
seems
like
to
be
the
easiest
to
implement.
One
of
the
like
expectations
of
that
is,
like
every
pot,
can
basically
describe
you
where
the
given
resource
is
located
so
technically
in
the
at
least
in
this
architecture.
It
allows
you,
for
example,
to
have
epox
designated
specifically
just
for
that
purpose
to
not
load
other
reports
with
this
type
of
requests.
C
But
this
is
like
the
direction
that
we
are
right
now
trying
out
and
so
far
it's
kind
of
working
pretty
well,
with
one
caveat
that,
like
we
actually
have
to
classify
a
significant
amount
of
the
requests,
I
mean
endpoints
that
are
exposed
by
GitHub
price,
and
some
of
them
has
to
be
the
chance
to
be
really
fixable
too
to
where
they
like,
which
Bots
should
process
them.
C
D
Subdomains
here,
rather
than
rewriting
different,
you
know
routes
and
things
like
that,
and
that
I
know
that's
opening
up
different
can
of
worms,
but.
C
I
know
that
there
was
like
discussion
in
the
past
about
using
sub
domains,
but
I
think
the
current
idea
is
of
not
using
sub
domains,
it's
using
kind
of
providing
a
single
domain
github.com
and
everything
being
hidden
from
you
that
you
are
using
subdomain
or
any
port
and
basically
us
doing
as
the
heavy
work.
C
B
C
B
Say
I'm
very
supportive
of
not
using
sub-domains
every
single
time,
I've
done
that
as
a
developer.
It
ended
up
in
a
mess-
that's
probably
more
me
than
anybody
else,
but
it
it
just
introduces
so
many
other
weird
stuff
from
browser
storage
to
cookies,
to
whatever
I'm,
so
very
supportive
of
doing
it
in
the
in
the
path
Josh.
E
Yeah
I
was
just
saying:
I
would
imagine,
we've
considered
this,
but
instead
of
maybe
rewriting
all
these
areas,
if
we
could
just
like
prepend
a
pod
ID
to
the
front
of
a
job
log
or
something
like
that,
and
then
you
get
like
the
routing
by
default
or
or
something
then
you
might
not
have
to
necessarily
rewrite
all
of
them,
but
I
don't
know
just
I.
Imagine
you
probably
thought
through
sort
of
the
hacky
Solutions
there's.
C
They're
gonna
be
like
a
very
big
topic
ahead
of
us
for
the
Post,
because
we're
gonna
have
to
figure
out
how
we
want
to
indicate
the
user
that
is
crossing
boundaries
of
the
organization,
and
this
is
more
like
the
ux
problem
and
subdomains
make
it
very
clear
that
you
are
crossing
boundaries
of
the
organization
where
a
single
domain
github.com
makes
it
kind
of
harder,
but
we're
gonna
actually
have
to
figure
out
the
ux
research.
C
How
we
can
want
to
sell
you
that,
okay,
you
are
actually
passing
by
copying
this
thing
from
the
GitHub
Arc
into
your
persona,
or
something
that
you
should
be
aware
or
like.
You
are
clicking
this
link
and
it
moves
you
from
gitlab
org
to
your
other
organization.
So
we
put
a
lot
of
emphasis
on
the
strong
organization
installation.
So
we
need
to
kind
of
also
provide
a
very
good
feedback
to
users.
C
What
is
happening
and
when
so
at
this
moment
we
don't
know
yet
because
it's
still
pretty
early
and
it's
more
like
a
product
decision
to
figure
out
once
managed
workspace
figures
what
they
want
to
do
with
organization,
slash
workspaces
but
I
guess.
This
is
going
to
be
a
very
good
moment
to
figure
out
how
we
want
to
implement
that.
E
E
B
Oh
sorry,
which,
which
ones
are
there
yeah
make
sense
to
me
and
I
know
I
some
I've
read
a
paper
or
blog
post
somewhere
cloudflare
or
something
that
allows
for
kind
of
redirects
from
the
router,
but
they
still
also
allow
to
redirect
from
the
Pod
itself,
and
that
was
for
cases
when
the
I
think
it
was
when
the
routing
was
laggy
or
something
or
when
they
moved
something.
Maybe
they
had
stable
connections?
Maybe
the
routing
table
was
about
a
date.
B
I,
don't
know
what
exactly
it
was
or
stuff
in
Flight
it
was
pretty
pretty
elegant
design,
but
I
don't
have
the
paper,
sir.
No,
no
dice
there
Steve.
F
Yeah
I
was
gonna,
can
I
think
what
you're
talking
about
there
we
did.
We
did
this
before
at
the
last
last
place.
I
was
at
with
like
exactly
what
you're
talking
about
kind
of
a
laggy
lookup
table
that
we
would
kind
of
pass
through
updates
if
we
moved
organizations
from
one
pod
to
another,
but
then
the
the
routing
was
all
done
with
cloudflare
workers.
It
actually
wouldn't
have
to
be
cloudflare
workers.
No
there's
I
mean
a
lot
of
that's
cloudflare
elsewhere.
F
A
lot
of
clouds
were
kind
of
copying
the
worker
concept.
C
But
I
I
think
it
may
be
relevant
and
in
the
migration
process
of
like
organizations
from
Port
0
to
Port,
one
where
we
have
to
kind
of
switch
where
they
need
to
write
tool.
But.
B
C
The
migration
stuff
is
pretty
tricky,
but
we
got
through
that
in
one
of
the
future
meetings.
When
we
start
thinking
about
the
migration
and
I
I,
don't
know
if
you're
gonna
be
able
to
do
continuous
move,
I
have
or
like
two
other
but
I-
think
it's
yes
to
add
it
for
us
to
discuss
that.
So
I
would
make
sense,
but
it
happened.
C
So
different
number
four
is
mine.
We
had
this
iteration
one
that,
like
was
concluded
with
the
video
that
you
see
10
various
other
people
in
this
code
watched
I,
I
split
this
Mr
into
right
now,
iteration
too,
that
kind
of
purely
focuses
on
the
router
and
passing
bytes
approach
we
recorded
with
Fabian
some
early
router
POC
demo
is
just
shows
like
very
early
version,
but
these
are
currently
like
the
goals
for
the
PLC
of
the
iteration
tool.
C
We
actually
I
think
like.
My
primary
goal
is
like
to
try
to
get
as
much
of
the
GitHub
QA
passing
to
kind
of
get
a
sense
of
the
major
problems
and
how
to
fix
them.
So
we
could
start
documenting
them
and
do
like
a
third
assessment.
How
much
effort
is
gonna
require
from
development
and
infrastructure
to
run
that
because
I
think,
like
we
collaboratively
in
team,
agree
that
this
is
like
pretty
large
amount
of
the
work
that
we
have
to
do
any
single
country
more
complex,
the
the
composition.
C
So,
to
give
like
a
fair
assessment,
we
want
to
start
build
like
a
a
map
of
the
broken
things
based
on
this
Hands-On
fixing.
With
the
like
approach
that
we
took
for
the
POC
and
other
like
the
teams
to
evaluate
how
much
effort
it
would
take,
it's
still
not
gonna,
be
like
super
complete,
but
should
give
us
like
some
rough
estimate,
how
many
things
we
have
to
fix
in
order
we
get
like
the
iteration
one
in
the
production
where
maybe
we
can
move
I
mean
create
some
new
organizations
on
the
new
another
report.
A
A
A
Said
you
had
you
had
put
something
on
for
four
six
I'm,
not
sure
if
that's
still
relevant,.
B
Yeah
I
I
think
it's
it's
really
exciting.
What
we're
doing
here
and
I'm
really
enjoying
Camille's
Camille's
work.
A
Thanks
for
the
feedback,
I
think
it
is
exciting
and
yeah
we're
moving
in
some
direction,
which
is
cool.