►
From YouTube: Community Meeting January 25, 2022
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
Hi,
all
today
is
tuesday
january
25th
2022.
This
is
the
kcp
community
meeting.
The
link
to
the
community
meeting
agenda
here
is
in
the
chat,
I'll
paste
it
again
just
in
case
y'all.
B
A
C
Okay,
so
I
was
tasked
with
prototyping
some
initial
authorization
schemes
where
we
could
show
if
the
work
that
we
have
been
doing
so
far
and
effectively.
C
We
have
been
picky
packing
on
your
work
and
you,
while
you
were
location
on
the
scope
branch,
which
worked
great
by
the
way,
and
I
prepared
like
an
initial
document,
we
have
a
couple
of
more
user
stories
down
here
for
future
work,
but
basically,
for
the
sake
of
this
demo,
I'm
focusing
on
sort
of
like
three
simple
user
stories
so
to
say
like
if
you
have
a
user
one,
I
want
to
create
conflict
maps
in
workspace
once
I
have
edit
permissions
and
as
user
two,
I
want
to
view
conflict
maps
and
workspace,
one
as
I
have
view
permissions
and
there's
some
other
random
user.
C
If
I
don't
have
any
access
to
it,
I
can't
see
anything
basically
right,
so
this
is
pretty
much
what
I
would
expect
from
a
tenant
aware
system
like
like
kcp,
we
had
some
initial
brainstorms
and
huge
thanks
to
stefan
and
david.
We
had
a
couple
of
design
sessions,
pep
programming
sessions
and
all
of
this,
what
you
see
here
right
now
is
this
collaborative
effort
from
within
this
group.
C
The
basic
scheme
that
we
have
like
thoughts
about
is
to
have
like
three
basic
authorizers
that
work
in
to
kcp
similar
as
upstream
does,
and
that
one
is
what
we
call
a
workspace
content
voter.
I
will
just
describe
in
a
second
what
this
concretely
means,
especially
what
this
one
does.
C
It
basically
asserts
if
the
user
in
flight
has
basic
or
like
rudimentary
access
to
the
workspace
and
there's
some
initial
group
assignments
what
that
means,
I
will
get
into
it
for
a
second,
then
we
will
have
like
a
union
of
two
additional
authorizers
one
that
we
called
local
voter,
that
one
spans
out
to
the
actual
workspace
that
the
user
has
in
the
scope
and
the
request
in
flight,
and
one
is
the
organizational
voter
which
we
use,
something
like
as
a
bootstrap
policy
source
right.
C
So
when
you
look
at
this
like
from
a
higher
level
perspective,
I
hope
this
is
good
enough.
Let
me
share
maybe
the
concrete
window
instead.
C
I
think
this
should
work
better.
So
let's
say
you
have
a
cube
cuddle
and
it
does
some
basic
operation
like
conflict
map
could
be
anything.
So
we
have
a
concrete
scope
in
the
request
in
flight.
In
this
case
it
would
be
like
a
workspace
one
and
the
obvious
operation
would
be
get
config
map,
so
the
first
authorizer
that
would
kick
in.
C
Is
this
what
we
call
a
content,
authorizer
and
the
scheme
we
thought
of
is
that
it
makes
sense
to
separate
the
basic
orbit
rules
against
the
workspace
resource
type
that
is
working
on
the
resource.
Workspace
resource
object
itself
and
separate
the
concern
of
accessing
the
content
to
it
into
a
separate
object
rule
right.
So
what
this
content
authorizer
effectively
does
it
looks
at
the
scope
you're
currently
in
it
looks
at
the
workspace
resource
and
the
sub
resource
content
and
asserts
if
you
are
allowed
to
perform
a
couple
of
basic
verbs
on
that.
C
You
know
sub
resource
content
of
the
workspace
resource,
and
we
literally
you
know
just
for
the
sake
of
the
prototype
iterate
through
a
couple
of
artificial
verbs,
edit
view
and
admin
or
administer
it
should
be
like
spelled
out
as
a
proper
verb,
and
if
you
have
access
to
one
of
those
verbs
you
get
a
group
assigned
that
will
map
to
some
bootstrap
policy
inside
your
workspace
more
formally.
What
we
did
is
you
know
inside
this
organizational
admin
workspace.
C
We
have
a
couple
of
cluster
role
bindings
that
we
added
into
the
bootstrap
policy,
where
we
map
this
edit,
these
artificial
sort
of
like
kcp
groups,
edit
view
and
admin,
at
least
for
now,
to
the
stock
upstream
kubernetes
cluster
roles,
edit
view
and
admin.
You
pre
you
you.
You
know
that
these
are
there
by
default.
These
are
aggregated
roles.
So,
if,
if
the
user
in
flight
has
any
access
to
those
verbs,
it
gets
the
groups
inside
from
those
groups.
C
We
imply
the
cluster
roles
by
those
bindings
and,
depending
on
what
cluster
role
you
applied
against,
you
have
access
to
the
content
literally
to
the
content
of
of
the
workspace
right.
Those
rules,
since
this
is
a
union
authorizer,
maybe
some
of
you
who
know
a
little
bit
about
the
upstream
rbac.
There
is
this
concept
of
the
union
authorization.
C
Essentially,
it's
just
a
change,
a
chain
of
authorizers
and
it
takes
sort
of,
like
literally
mathematically,
the
union
of
those
authorizations
that
allows
us
to
sort
of
like
predefine,
a
set
of
rules
in
the
organizational
workspace
and
overwrite
or
augment
those
not
override,
but
augment
those
rules
in
the
in
the
workspace,
and
this
concrete
example
the
workspace
one
and
obviously
I'm
I
just
draw
this
here-
that
inherits
from
my
belief.
This
is
supposed
to
go
away.
C
They
inherit
from
the
relationship,
but
just
for
the
sake
of
the
demo,
to
show
that
there
is
a
relationship
that
the
workspace
one
has
an
organizational
workspace
in
this
case
admin
so
just
to
show
it
off
in
terms
of
a
demo.
Let
me
share
another
window,
then.
C
Literally,
what
you,
what
once
what's
once
all
that
code
merges
what
you
could
literally
do
right
now
is,
if
you
have
a
workspace
right,
so
I
just
deployed
this
workspace
and
you
a
cluster
role
right
and
this.
This
sort
of
like
cluster
role
declaration
is,
is
a
concrete
inclination
of
of
the
picture
that
I
showed
you
like.
I
just
called
this
cluster
world
workspace
one
editor
and
this
one
by
like
this,
one
binds
against
workspaces,
slash
content
and
the
contents
of
resources.
C
It's
just
an
artificial
one
that
we
invented
concretely
for
workspace,
one
against
the
verbs
edit
and
the
same.
You
know,
corresponding
you
have
a
workspace
one
viewer
that
binds
against
the
viewwork
verb
right.
What
you
can
then
do
is
you
can
create
a
couple
of
cluster
row
bindings
in
this
case,
just
as
an
example
workspace
one
editors
just
for
you
know
playing
around
with
it.
If,
like
the
urbex
subsystem
sort
of
like
works,
I
I
bound
it
against
team
one.
C
If
you
use
the
kcp
tokens
that
we
have
like
as
a
demo
here
team
one
is
a
group
associated
oops
with
the
user.
One
token
and
I
created
another
cluster
role-
binding
workspace,
one
viewers
that
binds
against
the
concrete
user
user
two,
who
has
the
viewers
custom
role
assigned
to
it
right
so
just
to
show
it.
I
have
this
example
here
where
I'm
pointing
against
the
workspace
one
with
the
user1
total
get
some
conflict
map
required.
C
We
can
create
a
conflict
map
boom
right
configmap
is
created,
since
user
2
is
assigned
to
the
view
role.
It
fails
to
do
so.
It
has
no
permissions
which
is
great,
but
obviously,
since
user
two
has
a
binding
against
the
view
role.
It
can
read
data
from
workspace,
one
in
this
case
config
maps,
and
we
have,
if
we
have
some
user
three
industries
user.
Three
token
right.
It
kind
of
too
essentially
cannot
do
anything.
C
When
you
look
at
the
code,
this
is
like
how
how
this
prototype
implementation
looks
like
right.
So
it's
a
regular
authorizer.
C
We
heavily
use
the
existing
orbic
authorizer
with
the
you
know,
listers,
who
have
the
scope
suffix
that
that's
exactly
the
work
that
andy
did
in
his
branch
and
again
like
we
pick
it
packed
on
this
branch,
and
this
is
sort
of
like
the
outer
shell,
the
outer
workspace
authorizer
that
I
showed
you
in
the
pictures
that
looks
against
the
organizational
workspace
in
this
case.
It's
just
hard-coded
admin.
C
How
it
works,
at
least
for
the
prototype,
and
I
believe,
on
master
this
is
not
possible.
You
will
just,
I
believe,
david
when
we
tested
this
just
getting
the
permission
or
permission
not
allowed,
so
this
is
just
to
show
off
that
we
can
do
some
delegated
authorization
that
we
can
have
some
initial
bootstrap
policy
present
in
the
administrative
workspaces
and
that
we
also
can
have
the
actual
workspaces
be
effectively
empty
and
just
you
know,
delegate
or
back
in
that
direction.
C
Obviously,
what
is
not
possible
here.
What
we
have
been
thinking
about
is
what,
if
you
have
some
cluster
roles
in
the
administrative
workspace
and
you
want
to
bind
against
them
in
the
actual
workspace,
that's
not
possible
because
they
live
as
in
two
separate
entities.
That's
one
edge
case
that
is
currently
not
covered
here.
The
second
edge
case
that
we
would
have
to
consider
is:
we
should
not
be
allowed
to
override
one
of
those.
C
D
C
Yeah
yeah
exactly
he
could
he
could
sort
of
like
override
permissions
that
the
admin
gave
to
him
right.
That's
the
concern
that
I
have.
D
D
And
exactly
right,
this
is
really
so
like.
This
is
useful
because
we
have
theoretical
about
like
inheritance
to
reduce
cost
and,
as
a
result,
we're
thinking
about
the
limitations
of
the
cube
our
back
model
as
it
applies
to
this
and
the
right.
It
is
now
the
right
time
to
say
good.
We've
learned
something
you're
familiarized.
Now
we
can
start
asking
the
next
questions,
which
are
what
use
cases
beyond
efficiency?
D
And
then
it
starts
like
we've
got
a
couple
of
these
noted
down,
but
it's
very
useful
to
say
like
okay,
now
you're
primed
now,
I'm
gonna
start
asking
about
edge
cases,
so
we
don't
have
to
do
it
all
here,
but
like
some
of
the
things,
I
think
maybe
like
a
follow-up
would
be
useful
and
say:
let's
try
to
get
some
basic
use
cases
that
we
think
would
be
relevant
based
on
what
you've
learned
ask
whether
they're
valid
or
not,
and
then
we
can
also
start
poking
at
the.
D
What
are
the
tools
that
we
would
need
like
inheritance
as
a
technical
thing
versus
union
of,
or
you
kind
of
have,
that
org
workspace
administrative,
tooling
mindset?
What
are
the
different
things
that
we
could
assemble
out
of
those
pieces?
What
are
the
gaps?
So
it's,
I
think
it's
a
good
senate
point,
which
is
pushing
when
I
was
poking
on
it.
C
D
I
think
was
a
lot
of
what
we
don't
have
to
have
all
the
answers,
but
like
is
there
a
general
primitive
in
inheritance
that
helps
people
think
about
an
organizational
layering?
A
workspace
layering
and
a
installation.
Layering
cube.
Has
that
cluster
and
work
namespace
scopes,
but
those
have
very
serious
limitations
in
terms
of
actual
security
isolation,
because
at
the
time
the
use
case
didn't
we
didn't
need
them,
because
the
point
of
acute
cluster
is
that
it's
a
single
homogeneous
security
domain
with
some
subdivisions
for
limiting
a
subset
of
the
permissions.
D
D
So
it's
totally
about
fair
question
to
ask
the,
but
the
general
question
would
be:
is
there
an
underlay
mechanism
of
inheritance
that
is
generally
useful
for
the
subsystems
in
cube
or
for
other
systems
such
as,
like
I
want
to
make
a
resource
appear
in
someone's
workspace
by
default,
such
that
watching
all
that
work,
or
do
I
want
to
have
a
virtualized
system
like
our
back,
where
we
have
to
build
that
in
for
each
concept,
so
you're
kind
of
teeing
up
some
of
those
important
questions
that
we
posed?
D
We
don't
have
to
completely
answer
here,
but
we
want
to
get
that
motion
thinking
about
it,
because
virtualization
is
a
virtualization
and
layering
are
both
important
for
the
perspective
of
reducing
the
friction.
People
have
when
they're
trying
to
set
up
systems
of
control
right,
not
necessarily
automatically
enables,
by
default
today,.
C
Plus,
I'm
just
realizing
the
the
whole
concept
of
the
union
authorizer.
In
addition,
on
top
of
inheritance
also
like
brings
a
connection
between
those
two
worlds,
so
we
even
have
to
consider
even
more
use
cases
just
by
yeah
having
something
like
a
union
authorizer
which
brings
in
together
completely,
if
you
say,
completely,
two
separate
units
of
of
security.
It's
already
like
a
dangerous
realm.
We
are
here
in
why
perspective
yeah.
D
There's
a
set
of
use
cases
which
we
will
we
don't
have
to
get
into
here,
but
they're
around
like
there
are
properties
of
cloud
accounts
that
are
very
desirable,
such
as
no
matter
what
someone
inside
the
workspace
cannot
exceed
cannot
do
certain
things
that
are
dangerous
and
no
one
from
the
outside
of
that
workspace.
Even
the
infrastructure
administrator
can
get
into
it
without
rooting.
The
system
right
so
like
think
about.
D
If
you
look
at
like
how
an
aws
account
is
structured,
there
is
a
conceptual
behavior
there,
which
is
even
aws.
Employees
do
not
necessarily
have
access
to
that
aws
account,
because
the
way
the
system
is
designed,
no
one
has
access
to
that
cube,
doesn't
really
have
that
property.
Today
there
is
a
question
as
a
use
case,
whether
we
do
it
and
getting
this
framing
is
like
what
are
the
systems
that
we
do
so
we'll
go
through
those
use
cases.
D
A
second
thing,
your
point
about
authorizer-
and
this
is
really
important-
is
there-
is
some
discussion
about
models
like
broader
our
back
identity
systems
like
reback
relational
ac,
going
on
through
you
know,
a
bunch
of
startups
out
there,
some
people
in
the
ecosystem.
Talking
about
you
know,
could
we
bring
the
zanzibar
style
models
and
there's
actually
an
active
discussion
going
on
and
folks
in
this
will
be
connected
to
some
of
those
groups
around?
D
Is
there
a
point
where
q
bar
back
kind
of
like
it
only
accomplishes
so
much
and
instead
of
programming
q
bar
back
when
we're
talking
about
sharing
and
inheritance?
We're
really
talking
about
those
relational
things
might
be
a
better
modeling,
given
the
limitations
so
having
all
the
limitations
in
your
head
is
extremely
useful.
C
Yes,
I
think
these
are
completely
valid
concerns.
I
mean
obviously
for
the
prototype.
We've
been
picky,
picking
on
what
we
have
today
right,
but
I
think
it's
a
totally
valid
question
to
to
look
at
zanzibar-like
use
cases
and
if
we
can
yeah
literally
go
crazy
in
the
permissions
model
for
for
kcp
as
well.
I
think
this
is
definitely
worth
exploring
in
the
next
iteration.
Yes,
totally
agreed.
D
Okay,
any
and
then
it
would
be
good
as
an
output,
as
you
all
are
going,
is
to
document
places
where
you
felt,
like
the
limitations
of
the
rbac
model,
were
showing
up
so
just
like
as
a
useful
goal
frame
it.
The
problem,
as
are
there
places
where,
while
this
is
a
concept,
can
we
familiarize
ourselves
with
the
reasons
why
it
might
be
limiting
as
a
as
an
input
for
what
would
be
a
a
cut
point
where
we
could
say?
D
Oh,
like
the
the
inherited
authorizers,
they
don't
actually
have
to
be
implemented
in
cube.
They
are
a
stand-in
for
a
future
replacement
of
the
external
auth,
whereas
within
a
workspace
we
do
have
to
honor
the
cube
semantics.
D
That's
a
good
boundary
within
the
workspace
because
of
the
that
we
want
to
bring
existing
cube
workloads
over.
We
have
to
have
roughly
equivalent
semantics
outside
the
workspace
we
do
not
and
so
going
through
and
starting
that
exploration
from
what's
familiar
and
how
you
could
reuse
the
authorizers
that
we
have
to
the
next
step,
which
we
plugging
in
or
potentially
just
saying
like.
We
would.
D
C
Yeah
again
yeah
great
points
thanks
a
lot
that
would
be
all
from
my
side,
and
I
think
it's
super
nice,
because
david
already
picked
this
work
and
made
virtual
workspaces
work
on
top
of
it.
I
guess.
A
That's
awesome
thanks
for
the
demo
that
was
really
cool
to
see.
I'm
looking
forward
to
getting
that
in.
On
top
of
my
pending
prs,
which
are
I've,
started
to
go
through
and
redo
the
commits
so
that
they
actually
are
a
bit
more
logically
ordered
and
not
just
giant
whip
commits
all
right.
Next
up,
we've
got
a
demo.
E
C
All
for
the
prototype,
I
all
ran
this
locally
on
a
local
kcp
instance,
and
I
just
created
a
workspace
chart
just
to
make
it
all
work
within
the
same
process,
but
once
your
pr
merges,
I
think
we
have
a
little
bit
more
stuff
to
do,
namely
to
get
the
organizational
workspace
right.
All
of
this
is
hard
coded
against
that
move.
Right
now,.
E
F
Thank
you
so
many.
I
try
to
gather
the
various
elements
there,
the
oauth
that
searches
just
showed
build
that
on
top
of
anti-scoping
and
then
also
include
the
personal.
You
know
personal
workspace,
virtual
workspace
with
the
last
thing
added
the
cubeconfig
retrieval
from
from
kcp
and
mix
all
this
also
to
use
a
new
cube,
ctl
kcp,
workspace
plugin
that
you
know
mainly
allows
managing
workspaces
in
a
much
nicer
way
for
the
users.
So
let
me
share
my
screen
here.
F
Do
you
see
my
vs
cone
yeah
great,
so
here
I'm
going
to
work
not
directly
pointing
to,
as
usual,
to
the
cube
config
generated
by
kcp,
but
just
to
a
basic
config
that
you
can
see
below
here
and
yeah?
Well,
I
didn't
yeah
clean
it,
but
I
mean
that
would
contain
only
this.
This
is
the
end
point
to
the
virtual
workspace
server
that
you
know.
I
point
to
the
personal
endpoint
that
will
show
all
my
workspaces
by
delegating
to
kcp
to
the
kcp
organization
organization,
workspace
and
so
based
on
this
cubeconfig.
F
I
can
do
my
first.
You
know
I
can
code
yeah
here.
Let
me
pass
that
use
the
cube,
ctl
kcp
workspace,
and
here
I
have
the
various
options
to
create
a
workspace
and
that
will
directly
point
to
the
virtual
workspace,
endpoint
and
post
the
right
rest
request
there
and
also
get
the
current
workspace
delayed
list
and
especially
use
which
is
somehow
similar
to
what
you
have
with
cubectl
config
use
context,
but
here
to
use
a
given
workspace.
F
So
if
I
try
start
creating
a
workspace
with
a
given
user,
so
here.
F
F
F
I
get
exactly
the
same
thing
as
what
you
do.
If
you
point
directly
with
cubectl
get
workspaces
on
the
virtual
workspace
api
server
url,
then
let
me
try
to
also
do
a
list,
but
with
a
different
user
and
of
course
we
can
see
that
personal
workspace,
endpoints
are
per
user,
and
so
we
don't
have
any
any
workspace
available
for
user
2..
F
F
Yeah,
I
can
see
that
now,
I'm
really
in
this
workspace.
I
can
obviously
check
the
current
context,
because
when
I
switch
the
workspace,
what
it
does
is,
it
adds
a
context
typically
something
like
that
here-
that
is
specific
to
kcp
and
points
to
the
right,
precisely
to
the
all
the
information
that
was
retrieved
from
the
virtual
workspace.
F
The
cube
config
of
this
workspace
workspace
11
here.
So
if
I
do
cube
ctl
config.
F
And
I
get
the
exactly
the
same
error
as
circuits
showed
us
previously.
F
I
just
cannot
have
access
to
the
secrets
in
workspace
11,
because
I'm
user
too,
and
I
don't
have
access
to
this
workspace
and
of
course,
if
we
look
in
the
corresponding
config,
we
can
really
check
that
user1
token
is
used,
so
I
can
really
access
the
workspace
only
from
the
user
that
created
this
workspace.
F
F
Workspace
just
with
the
typical
this
I
use
dash,
then
of
course
I
will
get
only
the
first
secret
that
exists
in
in
the
previous
workspace
and
just
last
thing.
I
will
now
create
a
workspace
for
user
two.
F
F
F
I
don't
know
if
there
are
questions
on
this
and
of
course,
then
there
is
the
cube.
Ctl
kcp
delete
to
delete
workspaces,
but
obviously
there
would
be
additional
work
because
for
now
you
only
delayed
the
workspace
object
itself
and
not
the
content
you
need,
so
there
would
be
some
work
there,
and
so
the
last
thing,
based
on
what
we
had
discussed,
is
sharing,
obviously,
which
is
not
down
for
now,
but
would
simply
require
adding
share
sub
resource
on
the
virtual
workspace
implementation.
B
F
B
A
Yeah,
you
can
basically
treat
it
as
an
opaque
url
that,
like
if
somebody
was
curious,
why
it
says
clusters
or
why
it
says
whiz
bangs,
you
know
whatever
it
is.
We
could
address
that,
but
it
it's
not
really
meant
to
you
know
it's
not
something.
The
user
should
care
about.
It's
like
when
you
get
a
url
to
an
elastic
load,
balancer
in
in
aws
like
it's
a
weird
weird
name,
and
it
represents
your
elb
and
as
long
as
you
know
that
url
you're
good
to
go.
F
Yeah
by
the
way,
sorry,
by
the
way,
what
I
showed
I
showed
cube,
ctl
config
current
context,
but
if
you
only
use
the
kcp
workspace
cubectl
plugin,
then
you
don't
see
those
names
at
all
I
mean
what
you.
The
only
thing
you
have
to
cope
with
is
the
workspace
name.
D
Sorry,
and
and
to
echo
amd
a
little
bit
here
is
like.
I
think
this
is
like
an
important
thing,
which
is
breaking
where
cluster
is
from,
like
the
idea
that,
like
oh
you're,
talking
to
the
cluster
itself
and
we're
going
to
have
existing
tools
and
existing
folks
with
that
mindset
who
won't
catch
that
and
like
that,
we
found
this
like
historically
too,
with
like
oc,
is
there's
value
in
abstracting
some
of
these
concepts
for
some
people,
and
then
other
users
are
going
to
come
in
and
be
like.
No,
no.
D
I
have
to
understand
what
this
url
means
and
things
like
that
kcp
plug-in
right,
like
that's
one
of
the
dangers
of
the
layer
above,
is
that
we
get
used
to
it.
We're
like
oh,
it's
obvious
but
like
to
someone
who
doesn't
want
to
have
that
layer
insult
and
just
want
to
use
cue
control,
they'll
come
in
and
they'll
say
like.
Oh,
that
doesn't
make
sense.
I
still
just
want
to
deal
with
cute
can
fix
and
for
people
who
are
mostly
dealing
to
a
single
workspace,
single
cluster
mindset,
it'll
be
kind
of
the.
D
We
need
to
make
sure
that
we
do
a
lot
of
usability
and
experience
work
on
people
in
the
cube
ecosystem
who
are
used
to
the
current
way
like
they
have
to
have
something
that
isn't
just
like.
We've
made
a
layer
that
hides
it,
they'll
need
to
break
it
down
right,
like
kelsey
doing
kubernetes.
The
hard
way
like
breaking
it
down
is
an
important
thing
and
then
we'll
have
our
useful
things,
which
is
once
you've
bought
into
that
or
if
you
care
and
you're
doing
a
lot
of
switching
you
buy
into
something
that
streamlines
it.
D
You'll
still
need
some
virtualization
to
go
from
a
single
place
to
a
bunch
of
places,
and
someone
has
to
discover
that
first
place,
but
you're
always
gonna
have
to
discover
that
first
place
so
like
this
is
an
important
part
where,
like
think
of
this
as
like,
as
we
ask
questions
and
people
ask
questions
like
rob,
did
about
like
what
does
the
url
mean?
We
should
be
saying,
like
oh.
D
We
have
to
keep
doing
it
and
the
longer
we
go
down
this,
the
more
comfortable
we're
gonna,
get
it
like.
Well,
it's
obviously,
a
virtual
workspace
implemented
using
inheritance
of
an
underlying
kcp
instance
and
people
will
be
like
and
they
don't
get
it.
So
maybe
that's
like
something
we
can
encode
into
like
the
work.
The
cli
docs
david
is
like
as
we're
talking
about
like
the
designs
of
these
things.
We
need
to
be
like
how
do
we?
D
D
It
always
exists
or,
like
we
pick
a
couple
of
other
examples
like
that,
the
you
know
web
browser
flow
and
then
the
the
streamline
flow
is
all
about
hiding
that
when
you
want
that
hidden
and
when
you
don't
want
it
hidden,
we
can
explain.
You
know
like
the
dns
names
that
we
pick
for
workspaces
in
a
service
or
that
we
would
expect
someone
who's
setting
this
up
for
their
own
environment,
we're
going
to
make
a
recommendation.
That
is
an
important
reputation
like
here's.
What
we
recommend
and
here's.
Why?
F
Yeah,
which
is
why
also
I'm
trying
to
manage
everything
by
putting
information
in
the
typical
cube
config
file,
even
the
previous,
I
think
even
the
previous
workspace
is
stored
in
the
cubeconfig
in
a
quite
you
know,
standard
way,
so
I
mean
you
can
find
back
everything
in
the
cube,
config
and
just
use
cube,
ctl
exactly
the
same
way.
E
I'm
interested
to
see
that
we're
using
the
personal
prefix
for
these
workspaces
in
a
started.
E
F
D
It
could
actually
be
two
different
services
fronting
or
two
different
implementations
of
proxies,
and
that's
something
that
the
option
it
depends
on.
I
think,
and
some
of
it's
going
to
be
like
a
scale
resiliency
so
like
we
really
haven't
as
long
as
we're
thinking
single
instance
and
like
explaining
it
we're
okay
and
at
the
moment
we're
like
hey,
we
want
the
shards
to
survive
all
other
infrastructure
failure.
If
we
have
that
hard
requirement,
we
probably
need
to
then
say:
okay.
D
E
D
That's
maybe
we
should
maybe
ask:
is
that
going
to
be
a
use
case?
People
want
to
like
name.
Spaces
are
not
fungible,
because
they're
intended
to
be
like
unique
identifiers
that
you
can
use
with
automation.
D
Can
make
your
own
views
up
and
then,
like
yeah,
you
might
have
15
different
personal
workspaces,
each
of
which
maps
other
names
that's
not
valid.
Yes,
we
probably
want
to
base
that
on
someone
saying,
I
really
really
want
to
be
able
to
rename
this
because
x
when
it
came
up
in
cube,
we
actually
concretely
rejected
it.
The
original
proposals
were
like
hey.
We
want
to
do
everything
a
unique
id.
This
was
kind
of
how
google
was
doing
it
internally
with
with
borg
identifiers
and
a
number
of
other
things.
We
said.
D
Actually,
we
think
there's
more
value
in
the
apply
flow
and
config
flow,
having
static
hard
names
that
mean
the
same
thing
and
if
you
delete
and
recreate
them,
it
means
this
that
kind
of
conceptual
way
existing
users
are
going
to
come
to
us
and
expect
it
so
like
having
a
remappable
thing,
also
changes
that,
and
so
we
want
to
be
able
to
like
okay,
the
cost.
The
benefit
of
re,
of
allowing
a
renaming
relatable
thing
is
worth
explaining
to
someone.
What
relabeling
is,
I
think,
that's
and
dns
like.
Does
that?
D
Really
nobody
has
to
explain
dns
dnsc
names.
That's
another
angles,
like
maybe
dnsc
names
would
be
enough
to
get
some
of
this
renaming
that
you
want
for
workspaces.
So.
F
If
you
create
a
workspace
one-
and
there
is
already
a
workspace
one
with
this
workspace
with
the
same
name
existing
in
the
org,
it
will
still
be
workspace
one
for
you,
but
the
object
that
is
the
corresponding
chart.
Workspace
that
is
created
in
kcp
would
be
workspace.
One
with
you
know,
suffix
something
like
that,
but
in
your
personal
list
of
workspaces
you
would
still
see
the
the
workspaces
as
with
the
pretty
names
that
you
gave
and
in
all
the
interactions
that
you
have.
You
manage
them
like
that
that
that's
in
yeah.
D
And
you're
you're
we're
making
traffic
so
like
we
probably
again.
This
is
kind
of
like
a
there's
going
to
be
a
what
we
call
a
widowing
function,
which
is
we
have
a
bunch
of
good
ideas.
Every
every
part
of
the
thing
has
to
like
we're
going
to
have
to
go
through
and
window
it
down.
So
maybe
like
that's
one
like
the
mapping,
which
is
like
we
should
make
a
case
for
and
against
in
the
design
dock
around
workspaces
and
say
a
use
case
justifies
this
a
flexibility.
You
know
some
flexibility.
D
We
believe
we
want
justifies
this
versus
its
conceptual
because
you
could
argue.
The
cube.
Config
already
gives
us
a
remapping
of
the
name
of
workspaces
and
so
dns
also,
so
it's
like
we
should
be
able
to
with
those
trade-offs,
you're
right,
steve
and
then
do
we
have
we
identified
a
canonical
design
dock
that
we're
considering
to
be
the
workspace
one,
or
do
we
have
a
couple
and
can
we
consolidate
down
and
give
it
an
adr
and
say
like
this?
Is
the
adr
for
workspace
api
and
the
set
of
features
supports.
D
Certainly
use
cases
trade-offs
like
it's
more
affordable
by
adrs,
use
cases
trade-offs
why
we
made
the
trade-off
and
what
does
it
connect
to,
and
then
that
will
help
us
populate
the
greater
connector.
So
that's
a
great
thing
to
do
for
workspaces.
D
Cool
demo,
it's
great
to
see
it's
great
to
see
like
all
the
flexibility
here,
because,
like
that
experience
of
you
know,
jumping
between
them
is
something
that
we'll
do
a
lot.
Admins
will
do
a
lot
end.
Users
will
do
at
least
once
and
then
maybe
we
need
to
like.
Maybe-
and
this
gets
kind
of
into
like
how
far
do
we
go
on
the
feature
side?
Maybe
we
just
need.
D
D
And
also
at
some
point
too,
some
of
these
when
you
start
making
sure
that
we're
distinguishing
between
idea
like
as
we
move
out
of
prototype
two
three.
Maybe
this
is
like
where
we
start
getting
more
formal
about
like
what
is
a
basic
api,
we're
gonna
test
in
isolation
and
that's
you
know
we
expect
to
work
for
a
long
time
which
parts
are
going
to
be
experimental
and
what
labelings
we
want.
Somebody
that's
like
another
topic
we
can
tee
up.
D
For
you
know,
discussion
and
follow-up
is
like
starting
to
break
things
into
levels
of
maturity
and
idea,
implemented,
idea,
basic
prototype
idea
and
then
something
that,
like
we're
going
to
start
carrying
forward.
A
A
All
righty,
we
don't
have
anything
new,
so
I
would
like
to
pick
back
up
real
quick
with
the
prototype
three
demos
here
I
don't
know
if
anybody
has
made
any
updates
to
this.
A
I
was
on
vacation
until
last
night,
so
I
have
not
been
checking
this
document,
but
I
I
know
from
talking
with
paul
earlier
today
that
we
do
want
to
just
reconcile
everything
here,
get
it
established
agreed
upon,
and
then
paul
has
graciously
volunteered
to
take
what's
in
here
and
translate
it
into
appropriate
github
issues
that
we
can
link
to
the
prototype
3
milestone.
So
does
anybody
have
any
comments
or
questions
on
what's
in
here
since
our
last
meeting
when
we
talked
about
this.
A
Quiet
bunch
today,
all
right.
Well,
maybe
what
we
can
do
offline
is
paul
you
and
I
can
go
through
and
talk
to
folks
in
individually
and
and
see
if
we
can
get
some
names
here
and
start
working
on
getting
those
tasks
created
in
github.
I
A
H
A
And
y'all
are
certainly
welcome
to
add
your
names
after
the
fact.
If,
if
you
don't
speak
up
right
now,
no
worries
the.
A
I
I
did
also
want
to
plug
something
that
was
mentioned
earlier
about
documentation.
Is
that
it's
since
we're
finishing
prototype
2,
it's
a
good
time
for
us
to
revisit
what
our
first
entry
experience
is
into
the
repo.
So
it's
a
good
time
to
revisit.
Maybe
our
readme
files
make
sure
we've
got
whatever
demo
we're
going
to
post
out
there
and
linked
well,
and
maybe
an
faq
to
address
some
of
the
questions
like.
What's
there
what's
not
there.
I
created
this
issue
for
that.
If
anyone
wanted
to
pick
it
up.
A
Yeah,
I
think
that's
a
great
idea,
paul.
I
know,
for
example,
meru
is
new
to
the
community,
so
meru
and
anybody
else
who
is
new
if
you've
got
some
suggestions
for
how
to
improve
some
of
these
things.
Those
would
be
certainly
welcome,
as
well
as
anybody
else
who's
been
around
for
a
while.
Let's
definitely
try
and
get
that
done
before
the
end
of
the
month.
A
So
I
don't
see
anything
else
over
here.
We've
got
about
nine
minutes
left.
I
think
it
might
be
a
good
time
to
end
a
little
bit
early
unless
there's
any
last
minute
topics.