►
From YouTube: Pods sync Group Workspace and Group Pods
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
Thank
you
all
for
joining
I
wanted
to
talk
about
some
pods
questions.
A
Think
both
of
us
have
a
good
understanding
of
like
what
questions
that
we
have,
but
I
have
to
admit
that
I
have
done
a
poor
job
in
the
agenda
of
kind
of
trying
to
articulate
that,
but
I
think
it
boils
down
to
two
so
I'm
going
to
kind
of
get
started.
B
I
think
the
first
question
just
for
for
terminology
is
the
workspace
group
renaming
itself
and
the
workspace
to
use
the
term
organization,
because
then
we
can
just
talk
about
organizations
and
what
that
may
potentially
mean
but
treat
them
as
the
same
thing
and
talk
about
that.
That's
maybe
I
haven't
followed
up
on
that.
C
And
that's
in
the
works
I
mean
it's
pending
approval
from
David,
but
it's
almost.
We
have
received
some
feedback
around.
You
know
what
the
name
should
be
and
I
think
it's
pretty
final.
That
will
be
calling
it
organization.
B
Okay,
because
then
we
can
just
talk
about
organizations
for
the
rest
of
the
call.
We
don't
need
to
use
organizations
workspace
because
we
just
sort
of
assume
they're
going
to
end
up
being
the
same
thing,
but
we
don't
quite
know
yet
what
that
means
and
pods
has
maybe
different
opinions
to
what
it
should
be
compared
to
what
what
you
have,
but
just
to
to
make
sure
I
use
the
correct
terms.
Thank
you,
so
I
and
Camille
can
can
correct
me
and
bury
right.
B
We
as
group
pods,
are
interested
in
shipping
value
and
iterating,
and
we've
actually
thought
about
how
we
can
do
this
and
I've
linked
it
at
the
bottom
of
the
agenda,
because
there
are
probably
different
paths
that
we
can
take,
one
of
which
will
have
to
figure
out
this
concept
of
organizations
and
I'll
put
on
my
product
hat,
not
my
engineering
head
right
and
I.
Think
from
a
product
from
my
product
perspective.
B
The
problem
that
pods
introduces
is
a
problem
of
increased
isolation
where,
if
things
live
on
different
parts-
and
they
lived
on
one
thing
beforehand,
interacting
between
those
becomes
difficult
right.
That
is
the
problem
at
hand,
and
organizations
as
proposed
by
us
would
hopefully
solve
this
right
with
the
notion
that,
right
now,
if
customers
have
multiple
top
level
namespaces,
they
expect
that
they
can
interact
between
them.
B
I
think
that
is
pretty
much
as
far
as
we've
come
and
then
there
is
quite
a
bit
of
context,
I
think
between
like
how
to
maybe
get
to
that
place.
This
is
where
it
gets
complicated
and
maybe
more
engineering
focused
right
as
in
should
we
create
a
new
entity
like
in
the
database?
That's
called
organization:
do
that
or
will
we
turn
the
top
level
namespace
into
an
organization
and
migrate
through
that
I
I
have
no
answer
to
this
and
I
know.
B
D
C
Have
a
question
then,
on
that
Point?
Basically,
what
it
means
is
you're
solving
for
how
does
organizations
stay
contained
within
one
entity
in
your
container
or
whatever
we
are
going
to
call
it?
Are
we
going
to
call
it
organization
or
pods,
maybe
that's
or
later?
But
my
question
is
that
why
why
wouldn't
it
be
in
a
in
a
normal?
C
Why
wouldn't
they
be
I
mean
it
seems
like
a
very
obvious
requirement
from
a
client
or
a
customer
that
if
I
have
multiple
projects
that
we
are
running,
we
ultimately
want
to
be
able
to
isolate
one
thing
completely,
maybe
because
you
know
it's
too
early
for
people
to
share
on
that
or
you
know,
I
don't
know
for
whatever
reasons
right,
but
it
seems
like
a
very
obvious
requirement
that
any
any
kind
of
file
folder
structure
that
we
come
up
with,
ultimately
I,
don't
want
to
call
it
namespace
and
I,
don't
want
to
call
it
pods,
but
whatever
we
come
up
with
it
has
to
solve
for
that.
B
So
I
I
don't
want
to
say
if
this
is
obvious
or
not
right,
I
think
what
we're
and
I
think
this
is
another
thing
that
I
I
would
like
to
be
clear
on
I,
never
really
want
to
talk
about
pods
with
customers.
That's
the
pods
is
an
architecture
right.
It's
a
thing
that
underlies
our
ability
to
scale
ideally
like.
We
don't
ever
have
to
really
explain
this
right,
but
it
comes
with
certain
constraints.
B
B
If
they're
public
there's
a
I
mean
you
all,
I,
think
Michelle
and
gosia.
You
know
much
more
about
this
right,
there's
a
lot
of
complexity
in
our
permission,
models
and
all
of
those
kinds
of
things,
which
is
what
you're
actively
working
on
right.
But,
in
my
simplistic,
in
simplistic
terms,
I
think
what
Camille
said
is
right.
You
know
the
desire
is
to
be
able
to
say
this
is
everything
that
belongs
to
an
organization
similar
to
a
self-managed
instance,
and
it
can
live
on
a
single
pod.
D
B
The
guitar
yeah,
and
so
the
the
question
is
I,
think
what
we,
what
we
should
do
to
make,
that
more
acceptable
right
and
to
a
certain
extent,
that
has
impact
on
the
user
experience,
because
something
that
used
to
work
will
maybe
no
longer
work,
and
you
know
that
requires
an
explanation
right
for
for
users.
That
is
not
where
it's
part
right,
and
so
our
thinking
is,
if
you
have
an
organization
and
the
organization
is
called
gitlab
and
gitlab
is
a
private
organization.
B
The
user
expectation
may
be
that
everything
stays
within
that
organization
and
if
that's
true,
Parts
is
not
a
problem.
If
you
cross
boundaries
becomes
problematic
how
we
get
there.
So
that's
an
open
question.
We
have
to
to
figure
out
Ultra
and
I
think
there's
some
good
thoughts
on
the
migration
path,
but
that's
the
that's.
The
desire,
there's
also
a
one
use
case
specifically
for
organizations
that
want
to
remain
isolated,
not
so
much
for
open
source,
workflows
right,
which
are
different,
I
think
this
is.
A
B
A
B
We've
been
going
in
in
like
moderate
circles
and
ovals
around
that
for
for
some
time,
I
agree
which
it
like,
but
I
I
still
personally,
am
not
a
hundred
percent
sure
what
it
works,
but
is
would
constitute
that
isn't
an
organization,
and
now
a
workspace
becomes
an
organization,
so
they
may
just
be
exactly
the
the
same
thing
at
the
end,
at
which
point
it's,
maybe
not
as
problematic
right
but
I
think
the
desire
that
was
expressed
to
me
in
some
calls
is
that
we
may
want
to
have
customers
with
many
workspaces
and
we
expect
them
to
interact
between
those
workspaces
that
does
not
go
well
with
pods,
right
and
I
think
this
is
where
maybe
the
tension
comes
in.
B
You
know,
if
you,
if
you
say
well
what
you're
describing
is
the
same
as
a
workspace
and
a
single
workspace
is
a
single
organization.
Then
that's
fine.
My
assumption
is,
though,
that
those
things
should
by
default
not
actually
interact
with
each
other,
only
in
some
circumstances
and
in
controlled
cases
and
I
think
that
is
maybe
different.
Maybe.
A
I
think
we'll
get
into
that
in
a
minute.
I
think
that
applies
more
to
a
username
space
right,
like
as
a
user
I'm,
a
contractor
with
organization,
a
b
c
and
d,
and
now
I
have
to
figure
out
if
I
need
five
different
usernames
for
all
of
these
organizations
or
but
my
second
follow-up
on
this
was.
It
sounds
like
what
we.
What
we're
trying
to
accomplish
with
pods
is
going
to
break
things,
and
our
solution
to
it
is
going
to
be
organization
rather
than
organization
being
as
being
put
to
the
Forefront.
A
B
Is
a
solution
we
think
to
our
scalability
and
reliability?
Concerns
and
being
able
to
you
know,
offer
maybe
better
slas
at
some
point.
Pods
comes
with
problems,
one
of
which
is,
you
know
these
harder
boundaries
right
and
that
creates
issues
in
the
user
experience.
One
way
to
address
it,
we
thought
was
an
organization
which
may
also
be
a
workspace.
B
And
then
people
come
and
I
think
Mike,
Nichols
first
as
well,
and
then
people
said
like
well.
How
is
all
of
this
going
to
work?
And
you
know
what
we
can
do
or
I
can
do
and
come
here
can
do
better
than
me
and
say
like
well,
maybe
it
can
work
in
this
way
or
that
way
right,
but
I'm,
not
the
the
expert
on
figuring
that
out
and
that's,
but
we
we're
doing
something.
Potentially
that
will
impact
you.
So
we
want
to
make
sure
that
that's
understood
and.
D
D
It's,
not
that,
like
pods
break
for
a
king,
it's
just
it's
gonna
have
to
work
slightly
differently
and,
like
the
like,
I
documented
three
different
ways:
how
forking
could
work
in
the
new
model,
everyone
with
slightly
different
fundamental
design,
but
it's
also
like
each
of
these
design
in
case
of
some
Enterprises
actually
makes
sense.
D
What
we
are
doing
today,
because
I
feel
like
there's
like
a
lot
of
comments,
popping
up
about
against
the
type
of
the
interaction
and
technically
ports,
as
us,
like
a
forcing
function
of
isolation,
can
actually
make
it
a
better
experience
because
providing
more
isolation
and
metal
control
on
how
actually
like
the
the
source,
is
being
distributed
across
the
system.
So
I
I
think
at
least
how
I
see
that
it's
like
it's,
not
a
black
and
white.
D
It's
not
like
what's
break,
and
we
think
it's
actually
in
a
lot
of
cases
like
it's
a
forking,
forcing
function
to
reconsider,
how
we've
been
doing
stuff
and
it's
not
what
we've
been
doing
today.
It's
not
by
default
better
than
what
is
proposed.
I
think
like
the
the
ports
and
like
the
problem
and
isolation
kind
of
shows
that
there
is
like
a
bunch
of
stuff
that
we
can
do
better,
that
it's
like
because
of
the
how
we
run
project
like
we
just
must
check
for
the
customer.
D
Paying
businesses
is
probably
better
than
what
we
are
doing
today,
but
but
I
think
this
is
more
like
the
trying
to
to
understand
each
of
these
individual
topics
like
you
can
look
at
the
my
take
on
the
forking
model
and
there's
like
three
different
proposals,
and
we
have
examples
of
the
company
using
working
model
extensively
and
I
would
be
not
surprised
that
these
companies
would
really
want
to
control
all
Forks
where
they
are
kind
of
can
leave
and
kind
of
force.
D
That
folks
can
only
be
created
within
organization,
but
never
outside
of
the
organization.
It
may
be
different
workflow
to
the
open
source
which
you
may
want
to
copy
into
your
personal
stuff,
but
I
I
think
that
the
the
the
answer
to
that
is
not
like
ultimate
to
what
we
have
today.
So
sorry
for
this
country,
but
I
think,
like
the
pots,
is
more
like
a
forcing
function
to
reconsider
what
we
are
doing
stuff
with
the
isolation
and-
and
there
is
like
a
all
of
these-
things
can
be
solved.
It's
just
they.
C
C
Right
but
it
is
not
separate
from
organization,
it
definitely
falls
under
organization.
So
what
I'm
say?
For
example,
there
is
one
use
case
where
you
have
multiple
projects
going
on
and
you
have
contractors
working
on
them
and
you
need
to
share
those
projects
right.
C
So
that's
that's
how
I
understand
it
and
and
to
me
it
is
like
we
should
address
this
use
case
in
organization
rather
than
Fork
off
a
completely
new
thing.
B
I'm
not
entirely
sure
if
I
understood
you
correctly,
I.
Think
generally.
Yes,
if
you
imagine
sort
of
a
spectrum
of
isolation,
gitlab.com
right
now
is
completely
shared.
Gitlab
dedicated
is
completely
isolated,
pods
sort
of
Falls
a
little
bit
in
the
middle,
because
you
would
have
several
organizations
on
the
single
pod,
but
then
pods
are
largely
isolated
from
each
other.
So
it's
sort
of
a
spectrum
right
and
the
problem
that
we're
really
trying
to
address
is
that
we
know
that
we
won't
be
able
to
schedule
like
to
scale
gitlab.com
forever
right.
E
B
B
You
know,
and
that
we
don't
know
yet,
and
we
don't
have
all
the
answers,
but
one
of
the
areas-
that's
definitely
impacted,
is
going
to
be
your
your
group
right
and
that's
why
we're,
and
we
know
that
this
is
a
big
concern
that
we
that
we
raise,
that
we
need
a
solution
for
so
that's
how
how
that
happened.
E
C
The
call
so
I
understand,
then,
that
you
know
why,
so
to
take
a
step
back,
we
have.
We
are
talking
about
three
different
architectures
here
right,
one
is
gitlab.com,
another
is
gitlab
dedicated
and
then
there
is
gitlab
pods
foreign.
C
Are
you
saying
that
in
gitlab
pods
there
won't
be
any
groups
and
projects?
Maybe
this
is
a
hypothesis
right,
like
you
haven't,
figured
it
all
out,
I
understand
that.
But
what
what
does
that
pause?
Even
look
like
it
will
definitely
have
some
kind
of
a
structure
right.
What
does
that
structure?
Look
like?
Is
it
going
to
follow
the
same
thing?
That
organization
does
on
gitlab.com,
or
is
it
completely
different?
I.
B
I
I'll
encourage
you
to
like
just
to
look
at
the
blueprint
that
was
not
linked,
I
think
from
the
category
page,
but
on
a.
B
Know
it
would
look
like
something
like
this
right,
where
you
have
a
pod0
which
is
gitlit.com
and
then
many
pods,
which
are
essentially
instances
of
gitlab
with
all
of
the
infrastructure
component
and
some
shared
cluster
metadata
right
and
then
what
would
happen
is
you
would
be
able
to
have
something
like
this
here
right
where
this
is?
D
I
mean
like
it's
nothing
possible
to
share
data.
It's
gonna
be
hard,
so
it
was
kind
of
like
it
would
have
to
be
that
specifically,
for
example,
if
you
would
not
want
to
say
like
a
fork
between
Port
1
and
Port
10,
it
would
have
to
go
through
graphql
RP.
It
would
not
be
like
going
through
database
or
is
it
going
today,
so
it's
like
technical
limitations
like
like
technical
complexity,
how
how
you,
how
you
use
that
data
from
other
stuff,
so
it's
indicatory
of
heart.
It's
it's
not
impossible!
A
As
we
yeah
well
we're
running
out
of
time
and
I
want
to
close
this
one
out,
but
it's
as
we
talk
about
this
and
and
what
an
organization
looks
like
and
how
it
fits
within
a
pod
like
in
this
conversation.
What
I
would
recommend
is
that
a
workspace
is
an
organization,
the
workspace
group
or
managed
organization,
or
whatever
Can
collaborate
with
you
all
and
what
that
looks
like
and
how
that
works
within
a
pod,
but
even
just
based
on,
like
irvy's
summary
earlier.
A
A
When
the
name
change
goes
through
right,
because
we
already
changed
it
once
in
the
last
week,
but
gosha's
team
I
would
expect
would
be
the
dri
for
what
this
looks
like
how
it
fits
within
a
pod
and
how
it
works
within
ul's
architectural
blueprint.
B
Oh
thank
you
on
how
we
want
to
proceed
going
forward,
because
there
is
I
think
as
you've
all
noted,
a
desire
to
move
forward
right,
we've
laid
out
a
couple
of
proposals
or
Camille
has
so
all
the
credit
to
him.
One
of
them
is
about
introducing
organizations.
The
other
one
is
to
create
a
an
actual
pod
and
then
give
a
user
on
that
part.
B
The
ability
to
create
a
new
group
or
Project
without
introducing
an
organization
at
all,
it's
more
about
getting
a
part
up
and
running,
which
means
decomposing
user
tables
like
there's
so
much
work
in
this,
but
the
iteration
that
will
ship
out
of
that
is
going
to
be
very,
very
broken.
Like
many
things
are
not
going
to
work,
but
it
may
already
provide
some
value
and
it
will
certainly
I
think
highlight
if
you
had
a
pod-
and
you
don't
have
this
whole
organization
concept
worked
out.
B
How
would
that
even
look
I
think
it
would
make
it
a
lot
more
concrete
for
your
group
to
see
what
this
means
right.
So
this
is
I
think
some
something
that's
under
the
group
pod
control.
We
can
do
this,
but
this
is
completely
doable
in
parallel
to
conversations
about
organizations
and
how
to
do
it
right.
They
are
independent
from
each
other.
The
problem
that
I
have
to
be
very
Frank
is
this
is
coming
in.
It's
happening
is
potentially
disruptive
to
your
roadmap,
because
you
have
to
sort
of
have
that
discussion.
B
I
I
think
it
would
be
very
valuable
to
collaborate.
You
know
and
figure
this
out
and
do
it
in
parallel,
because
I
think
the
Pod
train
is
moving
and
we
will
have
to
figure
it
out
eventually
right,
so
my
desire
would
be
to
collaborate
very
actively
and
get
past.
All
of
this
naming
stuff
get
a
much
more
concrete
understanding,
but
I
think
pods
can
move
forward
with
the
creating
this
part
decomposing
some
things.
B
A
Okay,
thank
you.
So
much
I
think
we
didn't
cover
a
lot
in
the
agenda,
but
that's
okay,
I
think,
there's
a
lot
we
can
do
async
and
I
think
this
conversation
was
very
helpful
as
well,
so
I
think
in
terms
of
next
steps.
I
personally
would
like
a
link
to
what
you
just
showed.
A
If
you
all
move
forward,
I
think
that
this
the
organization
concept,
like
you
said,
can
be
parallel
and
if
you
have
a
pod
with
a
group,
if
you
have
a
pod
with
a
user
who
creates
a
group
and
that
that
may
just
be
an
organization
at
some
point
anyway.
So
I
think
that
that's
okay,
okay,
any
other
action
items.
C
And
just
as
a
follow-on
like
you
said,
Michelle
I
agree
that
Christina
and
Gosha
are
the
dris.
So
please,
you
know,
stay
in
sync
asynchronously
and
maybe
also
we
can
have
some
as
we
progress
like
we
can
have
some
more
sync
UPS,
to
kind
of
put
our
brains
together
to
understand
what's
going
on
and
how
to
not
step
on
each
other's
doors.
B
D
I
I
will
at
one
point
to
this
discussion,
ultimately
as
part
of
the
ports
and
very
early.
If
we
can
do,
we
want
to
dock
food
spots
for
gitlab
organization.
So
whatever
solution
we
came
up,
it
needs
to
also
answer
what
we
are
doing
in
somehow
Backward
Compatible
way.
So
we
can
migrate
ourselves
and
I
think
this
is
very
essential
design
expectation
because
GitHub
organization,
if
we
could
move
that
migrate,
that
away
it's
roughly
like
40
percent
of
the
capacity
on
github.com
right
now
so
Camille.
D
Github
Pages,
a
bunch
of
the
groups
so
I
think
like
the
internet,
is
like.
We
need
to
have
a
solution
that
do
pods
and
organization
in
a
way
that
we
can
be
like
a
very
first
dog
food
user
of
that
solution.
So
we
can
migrate
ourselves,
so
I
think.
Whatever
you
think
about
the
organization,
you
have
to
think
about
throw
dog
food
in
by
ourselves.
So
it
has
to
be
compatible
with
what
we
are
doing.
D
B
E
But
you
said:
that's
Christina
and
myself
will
be
the
duri.
We
also
won't
be
able
to
answer
all
the
questions.
For
example
forking
this
is
source
code
and
like
we
want
help
with
forking
sorry,
we
definitely
will
help
with
you
know
with
workspace
organization,
memberships,
all
the
hierarchies
that
we
can
cover.
There
are
also
a
lot
of
features
that
you
mentioned.
That's
probably
we
won't
be
able
to
cover,
so
that
would
require
cooperation
with
other
teams.
That's.
A
Okay,
well
I
want
to
thank
you
all
and,
like
I
said,
we
can
continue
this
async,
but
this
has
been
really
helpful
and
I
know.
You've
already
met
a
ton
with
everybody
all
the
time.
So
thank
you
very
much
for
making
time
yeah.