►
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
The
first
point
is
we:
since
we
spoke
last,
we
actually
finished
some
of
the
cleanup
operations
following
decomposition
of
the
database
and
we
now
dropped
all
of
the
unnecessary
tables
in
the
CIA
cluster
and
in
the
main
cluster
respectively,
reducing
the
amount
of
data
very
significantly.
So
that's
that's
nice
and
complete
in
production.
This
was
only
mainly
different
by
Omar
and
executed
by
Omar
Rafa.
So,
thanks
for
doing
that,
it's
a
nice
nice
thing
to
conclude.
A
Awesome
all
right
and
on
the
on
the
second
one
we
haven't
spoken
in
some
time,
so
I
I'm,
going
to
try
and
provide
sort
of
an
overview
of
the
main
things
for
pods.
So
the
first
thing
is:
we
have
defined
the
first
architecture,
blueprint
for
pods
I.
Think
the
thing
that
we
probably
want
to
discuss
today,
maybe
most
is
the
iteration
zero.
A
You
can
check
out
the
blueprint
it's
already
in
the
docs
and
since
I
asked
you
to
read
this
we've
also
added
a
few
more
visuals
to
it
to
make
it
easier
to
understand
the
terms,
but
we
felt
that
it
would
be
easiest
to
Define
terminology
so
that
we
know
what
we're
talking
about
and
and
go
from
there
I'll
pause
here.
If
there
are
any
immediate
questions.
A
Cool
doesn't
doesn't
appear
to
be
the
case
right
now.
The
next
thing
is
based
on
the
blueprint
four
parts.
We
defined
a
proposal
for
a
stateless
router.
So
this
is
one
of
the
sort
of
key
things
that
need
to
be
figured
out
in
the
plot.
A
Architecture
is
how
to
loot
requests
to
the
correct
part,
because
now
users
have
access
to
organizations
and
top
level
namespaces
that
are
located
in
different
places,
and
we
need
to
figure
out
how
to
how
to
make
that
happen
and
Dylan
defined
a
proposal
here
and
then,
based
on
both
the
blueprint
and
the
stateless
router
proposal.
Camille
actually
implemented
a
proof
of
concept.
That
kind
of
shows
how
something
like
that
could
work
at
gitlab
already,
I,
don't
know
if
you
want
to
say
anything
in
particular,
you
come
here.
C
I
I'm
posting
a
link
to
what
is
actually
implemented
in
a
POC
I.
It's
not
exactly
that.
It's
more
like
this
is
how
it
resembles
the
the
behavior,
which
is
like
the
set
of
the
cluster.
The
compost
labels
with
users,
as
you
Steve
asked,
is
like
search
across
all
codes.
So
this
is
like
part
of
the
third
context,
but
in
organization
specific
data
are
local
to
airport
and
at
least
in
the
blueprints
that
we
considered
like.
C
We
consider
that
one
of
the
things
that
I
noticed
like
in
the
passports
Network
we
are
as
a
GitHub
as
organization.
We
wanted
to
control
some
aspects
of
the
user
profiles,
so
in
this
model,
let's
say
that
a
way
to
authenticate
would
be
Global
but,
for
example,
what
would
be
so
under
your
profile
would
be
local
to
organization
that
you
are
within
so
like
at
all
at
all
being
used
like
some
kind
of
verify
stamp
or
something
different
I.
Think
like
it's,
maybe
conceptually
similar
to
a
Discord
model.
C
Where
you
have
many
servers,
you
have
some
aspects:
configured
authentication
globally,
but
your
username,
maybe
not
specifically
username
context
of
GitHub,
but
some
like
some
personalizations
for
the
for
the
profile
are
local
to
a
given
server
such
organization
in
our
term
and
as
for
the
POC.
This
is
like
under
your
point
e.
C
This
is
how
we,
what
POC
kind
of
models
with
these
tables,
if
it
has
like
some
implications
that
cluster-wide
stuff
is
being
writable
everywhere,
but
I'm
also
exploring
a
more
permissive
architecture
that
writes
to
Cluster
are
asynchronous,
so
take
probably
more
like
a
regular
aware,
because
the
port
by
default
always
would
work
on
top
of
replica,
and
this
is
another
thing
that
I'm
exploring
exploring
Asic
rights.
D
I
think
it
so
it
it
answers.
Maybe
I
guess
the
the
technical
implementation,
like
the
thoughts
around
the
question,
and
thank
you
for
that
and
also
I
didn't
want
to
say
thank
you
for
the
video
that
was
so
so
helpful
for
this
I'm
gonna
I'm
gonna
watch
it
again
because
I
know
I
I
only
probably
absorbed
50
of
it,
but
but
thank
you
for
that
I
think.
D
Maybe
the
question
here
is
more
around
just
our
I
can
see
what
this
enables,
but
I
one
of
the
things
that
pods
overall
certainly
I,
think
the
thought
was.
It
also
enables
us
to
do
from
from
the
kind
of
customer
presentation
or
delivery
standpoint
is
to
offer
things
like
data
locality.
You
know
just
within
certain
regions
and
everything
and
so
I'm
just
I
don't
want
to
add
you
know.
D
I
know
we
don't
want
to
have
all
of
the
constraints
in
an
MVC
to
begin
with,
but
I'm
just
curious
is
our
thought
that
you
know
we
will
kind
of
cross
that
bridge
when
we
get
to
it
like
we'll.
You
know
we'll
when
we
want
to
add
that
in
there
we'll
figure
out
how
to
deal
with
the
fact
that
user
information
is
currently
stored
around-
maybe
we'll
maybe
we'll
add
some
features
to
to
restrict.
That
is.
C
If
I'm
wrong,
but
like
we
don't
have
like
a
farm
answer
like
to
your
question
right
now,
what
is
constitutes
like
user
data
or
Kali
team?
So
far
we
kind
of
look
at
projects
and
groups
being
like
the
key
information,
but
this
model
doesn't
prevent
us
from
saying
that
most
of
the
user
profile
is
local,
the
organization,
but
things
that
are
required
to
authenticate.
Maybe
like
your
username
and
your
email,
and
maybe
your
like
some
two-factor
authentication
token.
They
are
Global
because
of
that
model,
so
I
think
I.
C
It's
more
like,
like
a
legal
question,
the
last
product
question
what
we
actually
want
to
achieve,
because
I
don't
think
that
it
forbids
us
from
saying
that
maybe
user
sensitive
information,
like
my
first
name
last
name
location
and
things
like
that
they
may
be
local
to
a
specific
region
whereas,
like
this
authentication,
information
may
be
Global,
so
I
think
one
versus
another
doesn't
contradict.
And
but
we
don't
have
clear
answer
for
this
question
right
now.
Yeah.
B
At
that
I
I'm
not
sure
it's
right,
but
I
I
have
a
I,
have
a
strong
opinion
loosely
held
on
this
I
think
that
having
user
information
is
really
like
broad
thing,
so
we
should
kind
of
split
it
up
like
what
I
did
on
the
instance
and
which
projects
I
interacted
with
which
messages
I
got.
That
needs
to
be
local
to
the
Pod
like
you
cannot
have
that
in
a
shared
state,
the
kind
of
the
user
username
and
that
needs
we
need
to
prevent
conflicts
between
them.
B
If
you
look
at
the
and
the
amount
of
functionality
on
the
global
level
is
going
to
be
one
percent
of
of
whatever
else
is
in
what
is
then
the
functionality
that
is
in
the
pot?
The
pot
will
do
all
the
interesting
things,
so
you
want
to
make
sure
that
F40
trust
you
want
to
make
sure
that
you
make
that.
A
A
Gitlab.Com
is
already
gdpr
compliant
and
we
store
our
user
data.
We
just
need
to
make
sure
that
we
can
do
that.
I
think
data
locality
and
you
know
where
people's
code
resides
and
those
things
is
pretty
key
and
if
we
can
say
this
is
all
local
in
the
Pod
and
the
part
is
in
this
specific
country
or
legal
legislation.
The
EU
I
think
that
may
already
cover
90
plus
percent
of
the
use
cases
and
I
think
that's.
A
That
may
be
good
enough,
but
we
would
have
to
validate
that
before
we
do.
It.
E
B
B
We
Skippy
that's
not
good.
That's
the
complement,
I
think
it's
a
really
impressive
proposal
and
I
love
that
there's
a
proof
of
concept.
So
great
work,
I'm,
really
impressed
not
sure
I
understand
everything,
but
it
it
seems
at
the
same
time
both
the
boring
solution
and
to
have
to
be
quite
complicated
and
which
is
a
an
interesting
combination.
But
these
things
are
complicated
to
F.
B
Camille
I.
C
Very
concretely,
because
Shopify
is,
by
definition,
more
like
working
in
the
isolation
between
yeah,
but
I,
really
heard
like
a
various
different
Solutions
like
basically
like
the
solution
that
we
took,
and
something
like
to.
Consider
as
well,
is
like
that.
Each
set
of
the
Pod
infrastructure
is
specifically
designed
to
handle
the
specific
part
of
the
infrastructure.
C
Whereas
in
terms
of
the
solutions,
you
could
consider
that
yeah,
like
your
web
Fleet
of
the
Puma
servers,
can
process
requests
for
any
bot
as
long
as
it
knows
which
ports
to
process.
So
you
have
more
like
flexible
and
scalable
infrastructure.
C
Where
kind
of
you
kind
of
assume
that
you
maybe
still
have
like
at
least
like
sorting
hard
routing
layer
at
the
top.
But
as
long
as
you
sent
an
indicator
to
a
port.
C
Connect
to
the
given
database
given
object,
storage
whatever
and
sell
from
that,
so
either
it's
like
a
spike
in
the
usage
on
there
is
given
Port
is
handled
by
the
general
purpose,
Fleet
on
which
you
kind
of
switch
on
the
application
side,
and
this
is
I
think
what
they
kind
of
saw
with
this
website
data
or
like
this
kind
of
a
way
to
indicate
hey
just
patch.
This
data
from
from
this
particular
chart.
So
I
think
this
is
probably
the
main
reason
like
in
the
in
the
diagram
that
we
saw
to
like
this
block
diagram.
C
We
assume
that
each
Port
is
has
its
onset
of
the
infrastructure
elements.
It's
completely
separate
it.
It
occurs
on
its
own
up
to
the
links
that
we
defined
instead
of
saying
that
we
maybe
have
many
object,
storage,
many
postgres
menu
at
these,
and
we
just
have
a
like
a
single
kubernetes
Auto
scatter
and
make
it
what
make
each
of
the
Puma
to
switch
dynamically
between
them.
So
I
think
that's
probably
like
the
main
difference.
At
this
moment,
foreign.
A
B
C
Like
the
simplest
way
to
think
that,
like
you
pick
like
out
of
the
pot
a
web
puma
and
you
move
that
on
the
top,
basically,
this
is
like
the
simplest
way
to
think
that
about
that
the
same
you
take
it
for
the
site.
You
kind
of
put
that
on
the
layer
right
below
like
a
routine,
instead
of
this
being
in
the
context
of
a
bot.
B
E
When
I
got
that
I
had
a
question
about
the
diagram
and
the
the
Paw,
the
cluster
diagram
there
on
the
cluster
of
global
part
of
the
diagram,
it
says
we
have
a
global,
redis
and
I
was
curious
to
hear
more
about
why
we
have
I
can
understand
having
a
cluster-wide
database
but
I'm
just
curious
about
the
reddest
part.
C
I
I
specifically
named
user
sessions,
because
I
don't
think
that
we
have
actually
specific
usage
patterns
already
today.
This
would
be
primarily
to
cash
I
mean
to
serve
like
your
user
session
cookie
across
all
parts.
So
you
can
see
me
see
authenticate
whatever
routing
root
output
you
connect
without
having
to
authenticate.
C
If,
if
you
take
a
look,
there
is
like
a
redness
with
all
of
the
other
stuff
like
a
cache,
just
like
a
local
tripod,
but
since,
like
our
money,
is
like
sharing
sessions
through
redis
no
database.
This
is
why
sharing
credit
is
for
user
sessions.
C
C
So
think
about
that,
like
you
go
to
github.com
gitrapark,
which
is
like
on
the
port
100.
But
then,
like
you,
just
go
to
keycloud.com
my
personal,
which
is
on
pod
one.
You
don't
have
to
authenticate,
because
you
are
already
authenticate
against
the
cluster,
the
actual
authorization
to
access
given
resource
like
a
project
members
project
authorizations
database
table
is
stored
locally
on
this
spot.
But
since
you
are
authenticated,
you
don't
have
to
authenticate.
E
Okay,
I'll
have
to
talk
to
you
more
about
that
in
detail,
but
I
I
think
I
generally
see
you're,
saying
there's
some
Global
session
state
that
you
want
to
preserve.
Is
there
a
spot
specific
session
State
because,
for
example,
we
store
stuff
in
the
session
data
that
may
be
like
you
know,
dbr
issue
or
something
like
that?
C
Okay,
Pakistan:
let's
talk
about
it!
This
question
right
now:
okay,
I
I,
just
assumed
that
this
would
be
like
one
of
the
requirements
to
serve
some
aspect.
About
user
being
authenticated
I
did
not
look
deep
into
what
is
in
that.
It
may
be
exactly
as
you
say
that
some
of
the
data
will
be
local
to
airport,
but
like
General,
you
being
authenticated,
maybe
side
so
I
cannot
answer
that
in
more
detail
right
now.
So
thanks.
A
Well,
I
have
the
the
next
one:
it's
just
something
that
came
out
of
us
discussing
the
parts
proposal.
I
think
one
thing
that
is
pretty
Central
is
that
we
we
say
look.
We
can
group
top
level
namespaces
into
organizations
and
users
care
mostly
about
those
top
level
namespaces
inside
their
work.
They
don't
care
about
other
things
and
that
allows
us
to
say.
Okay,
we
can
put
these
things
on
the
pods.
They
don't
need
to
interact
across
different
paths,
and
that
makes
this
entire
architecture
viable.
A
Here's
the
illustration
of
this
and
most
organizations
that
are
on
gitlab.com
already
just
have
a
single
top
level
namespace,
but
you
know
somehow
have
multiple
gitlab
is
an
example
of
that
we
allow
people
to
have
more,
so
that's
sort
of
a
central
thing
that
underpins
the
The
Proposal
from
a
how
gitlab
operates,
and
in
my
view
this
brings
gitlab
a
little
bit
closer
to
a
situation
where
we
have
a
global
user
account.
People
can
interact
with
multiple
organizations
with
a
single
user
account
and
do
it
similar
to
Discord
and
I.
A
F
I
think
the
proposed
definition
of
an
organization
is
much
more
clear
than
the
definition
that
I've
scene
or
my
understanding
of
the
workspaces
concept.
I
also
think
that
it's
a
lot
it
it
meets
people's
expectations
and,
and
so
it's
easier
to
communicate,
but
I
I,
don't
think
that
we
need
both
a
top
level
organization
and
the
concept
of
workspaces
but
yeah,
that's
all
to
say.
I
I,
like
the
organization
Direction.
A
Yeah
thanks
for
this
I
will
sync
with
the
workspaces
folks
again,
my
current
understanding
is
that
workspaces
will
be
the
next
iteration
of
top
level
namespaces
and
bring
a
lot
of
admin
features
to
to
that.
But
I
also
have
to
follow
up
a
little
bit
because
I
agree
with
you
that,
if
workspaces
do
something
similar,
then
we
have
to
make
sure
we
are
we're
aligned.
A
I
mean
these
kinds
of
things:
they
they
make
a
ton
of
sense
to
me.
I
feel
they
would
make
the
overall
user
experience
significantly
better
and
I
think
they
also
align
with
how
organizations
think
about
you
know
they
are
the
interactions
with
gitlab
and
that's
what
they
would
also
get
if
they
were
on
a
self-managed
instance.
C
G
Oh,
it's
just
I
I
think
Enterprises
will
appreciate
the
further
isolation.
I
think
they've
been
making
a
lot
of
nips
and
talks
from
the
current
model,
but
it's
gonna
be
a
lot
of
sort
of
small
fixes
there
and
having
something
more
like
this
I
think
they
would
find
a
lot
of
value.
G
We'll
have
courts,
do
a
lot
of
validation
and
and
diligence
here
before
we
can
consider
it,
but
I
think
gut
feels
that
they
would
appreciate
it
and
it
might
simplify
a
lot
of
the
other
work
that
we're
trying
to
do
to
sort
of
provide
on
isolation
on
each
and
every
level
feature
as
opposed
to
a
more
holistic
approach,
but
and.
D
G
Also
blue,
simplify
pods,
but
yeah
you're,
trying
to
add
someone
to
a
group
but
trying
to
add
David
to
Santo
to
our
group
is
nearly
impossible.
You.
A
B
B
Yep
and
that
contained
all
their
things
and
I'd
love
for
maybe
a
Josh
or
something
to
kind
of
get
me
up
to
speed
and
how
this
with
parts
we're
now
talking
about
organizations
with
the
workspace
thing
we're
talking
about
workspace,
something
and
I
think
in
Billing
and
fulfillment.
We
also
have
a
want
to
aggregate
multiple
instances
into
one
account
or
something
like
that.
B
Cool
I
missed
that,
thanks
for
that,
and
then
maybe
Josh
can
have
a
quick
look
of
whether
there
should
be
a
link
to
that
fulfillment
project.
What
they're
working
on.
A
A
Awesome
then
thanks
everyone
for
attending
and
see
you
at
the
next
one.