►
From YouTube: Community Meeting November 30, 2021
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
Hello
and
welcome
to
the
kcp
community
meeting
november
30th
2021
we're
going
to
skip
the
first
topic
on
the
agenda
and
maybe
we'll
get
back
to
it
later.
There
are
some
other
people
who
might
also
be
joining
us,
but
david
has
promised
us
a
demo
with
a
question
mark.
So
it's
not
it's
not
a
hard
promise,
but
has
invoked
the
word
demo,
and
so
I
think
we
should
take
a
minute
to
see
if
we
can
see
a
demo.
B
Yeah
yeah
the
demo
should
be
available.
Finally,
just
in
time
just
two
words:
first,
it's
about
the
work
on
virtual
workspaces.
I
started
looking
to
the
feature
which
is
based
on
a
given
user
name
or
user
id
gives
me
give
me
the
workspaces,
my
personal
workspaces,
or
also,
of
course,
return
the
list
of
the
workspaces
visible
for
a
given
organization,
etc.
B
So
this
is
based
mainly
on
virtual
workspaces
or
virtual
resources,
which
is
mainly
providing
to
the
end
user,
a
sort
of
workspace,
a
domain
you
know
but
implemented
as
code
and
usually
proxying
to
objects
that
are
not
here,
but
that
are
stored
on
some
chart
on
some
administrative
chart
of
works,
administrative
workspace
of
a
shot
something
so
it's
mainly
code
that
will
proxy
the
request
somewhere
else.
B
And
to
do
this,
I
started
a
generic
some
generic
code
to
build
a
vista
virtual
workspace.
Api
server
dedicated
to
a
group
exactly
like
openshift
api
server
is
built
thanks
to
stefan
and
exactly
like
it
is
built
who
explained
that
to
me
with
a
number
of
api
servers
delegating
to
to
each
other
and
each
one
managing
a
given
group
of
apis.
B
So
it's
the
the
work
I've
done
is
mainly
providing
a
framework
that
allows
us
building
such
virtual
workspaces
with
the
minimum
size
minimum
amount
of
code,
and
then
I
implemented
that
I
mean
started
testing
that
with
the
workspace
workspaces
to
get
the
list
of
workspaces
according
to
the
current
identity
or
group.
But
of
course
it
could
be.
It
would
be
exactly
the
same
and
could
be
useful
for
things
like
virtual
workspaces
for
api
exports
or
stuff
like
that
or
even
the
views
in
the
future.
B
C
B
I
assume
yes
so
here
I
have
a
kcp
server
running
and
then
I
have
a
second
api
server.
I
will
run
a
second
api
server,
which
I
called,
of
course,
this
api
server
I
built,
could
also
be
you
know,
added
into
the
main
kcp
process
or
collocated
with
any
other
process,
because
it's
an
api
server
that
can
be
set
as
a
delegated
server
for
another
one.
B
But
here
I
built
a
command
line
which
mainly
allows
you
starting
the
virtual
workspaces
on
standalone,
and
then
I
have
the
virtual
workspaces
and
the
workspaces
sub
command,
which
will
run
the
api
server
that
you
know
exposes
get
request
for
for
to
get
the
list
of
workspaces
for
a
given
user,
and
so
here
this
will
start
sorry
an
api,
a
dedicated
api
server
on
so
on.
B
Another
port,
of
course,
and
this
api
server
is
implemented
in
such
a
way
that
it
answers
not
at
the
root
a
slash
but
at
slash
applications,
slash
personnel.
So
exactly
what
we
aimed
virtual
workspaces
are
mainly
api
servers
with.
You
know
a
given
arbitrary
prefix
and
then
you
point
to
the
the
and
then
this
becomes
the
root
of
the
virtual
api
server.
B
So
if
I
run
that
in
fact
all
the
authen
exactly
like
for
the
openshift
api
server,
which
was
my
model,
the
authentication
and
also
authorization
is-
is
delegated
to
the
main
api
server,
which
is
kcp
here
and
now,
if
in
cube,
ctl,
okay,
now
if
by
default,
I
will
point
to
kcp.
But
if
I
do
this
here,
I
would
be
able
to
point
to
my
new
virtual
workspaces
api
server
that
can
be
collocated
or
separated
from
kcp
and
from
the
kcp
instance.
B
So,
of
course,
there
are
a
number
of
things
to
fix
still,
so
that's
why
I'm
in
tls
verify
insecure.
True,
but
anyway,
if
I
go
at
the
root
here,
I
can
see
that
I
have
no,
no,
nothing
in
fact
no
resources
at
all,
of
course.
But
then,
if
I
go
at
this
path
here,
services
applications
personnel,
then
I
will
see
that
I
can
find
my
objects
that
were
registered
at
this.
B
You
know
in
this
apa
in
this
delegated
api
server,
and
I
could
I
could
have
several
delegated
api
server,
one
for
workspaces,
one
for
api
exports
in
the
same
in
the
same
process,
in
fact,
in
the
same
virtual
workspaces,
command
line
process
here
and
so
now.
If
I
try
to
get
a
workspace.
B
Of
course,
here
I
just
implemented
a
dummy.
You
know
workspace,
rest
storage,
which
mainly
just
returns
a
fixed
workspace,
but
then,
in
this
code
we
would
easily
be
able
to.
We
will
be
easily
be
able
to
plug
the
management
of
the
workspace
index
cache
and
then
returning
and,
of
course,
pointing
to
the
shards
to
get
this
information
and
then
being
able
to
return
it
in
any
form.
We
want,
and
the
same
also
we
can
do
here.
D
B
B
The
next
steps,
mainly
for
now,
would
be
probably
so,
of
course,
trying
to
wire
that,
with
the
the
work
on
workspaces
that
already
steve
already
started,
with
the
workspace
controller
to
be
able
to
point
to
shards
and
get
and
get
workspaces,
even
if
we
don't
have
implemented
the
whole
workspace
index
stuff
and
caching,
but
that
could
at
least
give
something
a
bit.
B
That
would
look
like
feature
complete
and
and
not
not
a
fixed
workspace
and
then
also
I
was
thinking
about
workspace
requests
a
bit
like
you
have
project
request
and
in
in
openshift,
because
the
ide,
if
I
understand
correctly,
was
to
have
some
sort
of
self-servicing
on
workspaces
but
of
course
a
controlled
one.
So
something
like
workspace
requests
that
would
only
be
available
from
this
workspace
virtual
workspace
and
then
from
this.
That
would,
according
to
the
organization
of
the
user,.
E
D
E
D
To
have
a
request,
like
the
only
reason
reason
we
did
project
requests,
because
we
were
talking
through
the
idea
that
there
would
be
a
different
schema
but
like
in
a
sense
like
and
a
workspace
request,
isn't
terrible
like
namespace
and
project.
The
idea
of
like
I
want
to
get
a
space
to
work
in
and
create.
It
are
slightly
different
concepts
but
like
to
stefan's
point,
you
could
even
post
a
workspace
and
then
just
apply
different
validation
rules
and
say
yes,
sure
or
whatever
might
be
another
path.
Yeah.
B
We
could
have
a
create.
I
was
thinking
that,
for
example,
in
the
future,
in
the
workspace
you
might
have
some
informations
that
we
don't
want
the
end
user
to
have
to
bother
with
so
having
some
sort
of
you
know
minimal
workspace
requests
which
just
the
name
something
like
that
and
then
the
rest
is
derived
from
the
organization,
the
the
the
user.
This.
E
Is
a
discussion
I
think
clayton
called
it
consistent
set,
or
we
had
this
inheritance
in
the
api
draft
yeah.
I
think
everything
we
do
in
this
area
like
putting
something
into
a
workspace
workspace,
it's
instant
anyway,
which
should
be
instant
there
shouldn't
be
objects
created.
So
in
the
moment
you
create
the
object
of
the
workspace.
E
B
A
A
F
Oh
sorry,
I
didn't,
I
didn't
hear
it.
I
think
I'm
a
little
messy
this
morning.
I
was
just
confused
about
all
the
flags
on
the
command
line
from
when
you
were
starting.
The
virtual
workspace
api
server
and
I
was
wondering
how
like
was
the
that
url
you
were
hitting
the
personal
one.
Are
you
then
like
inspecting
the
auth
info
that
you're
given
and
then
like?
What's
going
on
there?
How
does
that
flow
work.
B
Yeah,
mainly
the
virtual
workspaces,
api
server
is
delete.
I
mean
it's,
it's
just
you
know
copied
on
the
openshift
api
server,
it's
delegating
authentication
and
authorization
to
external
cube
api
servers,
so
we
could
change
that.
I
mean
I
just
did
that
in
the
beginning
and
and
also
but
but
then
that's
why
you
have
three
parts
in
the
command
line,
because
we
have
the
main
cube
config,
which
is
the
one
I
would
use.
You
know
to
point
to
a
q
config
that
would
go
to
your
coordinator.
B
I
mean
if
we
can
call
it
like
that,
this
one
I
would
from
this
one.
I
would
get
all
the
the
list
of
the
workspaces
in
in
all
charts.
If
I'm
not
mistaken,
and
then
you
have
a
config
for
authentication
and
cube
config
for
authorization,
I
mean
that's
just
the
way.
B
Openshift
api
server
was
designed,
and
I
mainly
copied
on
that-
and
that's
quite
your
foods
because
useful
because
for
now
I
can
point
those
three
to
the
same
api
server,
but
I
could
point
also
authentication
and
authorization
to
a
kind,
a
small
kind
cluster.
You
know
where
I
define
the
users.
I
I'm
interested
in
or
something
like
that,
just
to
be
able
to
check
that
when
you
change
the
user,
the
behavior
is
different,
so
I
mean.
E
There's
something
there's
something
missing
I
mean
in
the
background,
there's
subject:
access
review
taking
place
this
doesn't
support
something
like
scopes
of
different
workspaces,
different
virtual
workspaces,
so
there's
a
lot
of
things
missing,
so
you
have
to
extend
this
concept.
This
request
subject:
exercise.
F
F
D
Here
there
are
two
useful
fundamental
patterns
which
is
abstracting
and
cutting
through
abstractions,
so
the
one
of
the
ideas
for
virtual
workspaces,
I
think,
is
about
allowing
us
to
to
allow
tight
control
over
what
comes
through.
But
that
means
that
that
component
has
higher
trust
on
whatever
the
delegate
is
right.
So,
like
you
can
read
all
namespaces
great
there's
something
that
can
read
all
namespaces
and
then
there's
the
argument
like
with
pushdown
and
all
that.
D
I
think
that
there's
a
separate
view
with
virtual
workspaces
that
could
be
the
hybrid
of
both
of
those
where
you
actually
are
transforming
an
input,
request
and
pushing
down
like
all
of
those
things.
And
then
you
get
two
layers
of
protection
which
you
can
double
check
at
both
layers.
That
has
some
nice
security
advantages,
especially
when
we
talk
about
like
what's
the
security
model
for
a
control
plane
that
controls
workloads
across
tens
or
hundreds
of
clusters
that,
like
we
haven't,
spent
a
ton
of
time.
Thinking
about.
D
D
What
would
that
look
like
like
a
lot
of
the
stuff
here
might
actually
be
super
useful
if
you
needed
to
do
on-the-fly
adaptation
or
you
wanted
to
expose
you
wanted
to
translate
apis
into
earlier
versions
or
impose
additional
defaulting
or,
like
you
know,
to
make
calls
to
things
like
opa
or
embed
cell
transformations.
So
maybe
it's
more
useful
to
say
the
more
use
cases
we
have
the
more
it
looks
like
a
rails
for
cube-like
patterns,
but
we
don't
have
a
ton
of
those
use
cases.
B
Yeah,
for
now
it's
it's
really
mainly
each
apis.
Each
api
server,
you
know
rooted
at
the
given
prefix
path,
is
related
to
a
group.
So
because
it's
you
know,
I
just
implemented
it
very
simply
so,
typically
for
virtual
workspaces,
where
we
could
return
any
type
you
know
of,
that
would
just
be
some
sort
of
proxies
on
other
api
server
that
could
return
any
type,
the
proxy
api
server.
B
D
It's
interesting
because,
like
that's
a
little
bit
more
the
minimal
api
server,
then
I
think
what
we've
done
on
the
other
stuff
for
minimal
api
servers
before
so
it
like
shows
a
different
angle,
minimal
api
server
that
I
don't
think
we
kind
of
planned
on
originally,
but
it
has
a
lot
of.
It
has
a
lot
of
the
same
ideas
and
value.
If
we
can
figure
out
like
what
use
cases
to
line
it
up
to
yeah,
it
doesn't
make
it
useful
there.
A
Sort
of
proxy
yeah,
stefan,
you
had
your
hand
up
and
then
put
it
down.
I
wanted
to
make
sure
either
your
question
was
answered
or
you
decided
not
to
ask
it
before.
E
B
A
Yeah
cool,
thank
you
for
showing
that
that
was
really
cool.
I
want
to
move
on
because
vince
is
here
and
we
wanted
to
talk
about
hello,
and
we
wanted
to
talk
about
the
oh,
I'm
not
presenting
anymore.
I
can
fix
that.
A
About
potentially
reusing
the
conditions
library
from
the
cluster
api-
steve
you,
oh
god,
everything's
too
crazy
steve-
you
opened
this
and
I
think
andy
also
had
comments
and
thoughts.
I
will
take
it
away
to
either
one
of
you
give
it
away
to
either
one
of
you.
G
Sure
I
can
hop
in
because
I
know
steve's
feeling
a
bit
under
the
weather.
So
for
those
who
don't
know,
I
spent
a
lot
of
time
working
on
a
cluster
api
in
the
past
and
vince
is
still
working
on
cluster
api
and
some
of
the
folks
over
there
wrote
this
really
awesome
library
for
working
with
conditions
and
unfortunately,
it's
specifically
typed
to
the
cluster
api
conditions,
struts
in
a
very
specific
go
package,
and
so
there's
a
question
or
some
thinking
around.
G
Could
we
do
some
code
generation
in
the
short
term
to
have
a
conditions
library
like
what's
in
capi
that
can
work
with
any
sort
of
condition
types
and
maybe
in
the
future,
use
generics
when
go
118
is
out
and
available.
So
that's
the
seat
of
the
conversation
and
vince.
I
don't
know
if
you
had
any
thoughts
already
or
any
comments
on
what
I
just
mentioned.
H
I
think,
like
so
I
mean
there's
like
the
two
components
that
we
have.
It's
like.
The
conditions
struck
selected.
The
interface
that
you
have
to
satisfy
is
in
our
api
group
right
now,
so
that
might
have
to
move
out,
and
there
is
the
package
under
util
which
could
also
move
up
into
its
own.
H
Maybe
repo
inco
module
so
separate
from
where
it's
today,
but
then
the
other
piece,
that's
missing
is
the
the
patch
helper
because,
like
we
do
use
control,
runtime
client
in
the
patch
helper,
like
it
takes
care
of
conditions
and
possible
conflicts
so
like
that,
like
it
needs
to
be
like
a
little
bit
more
thought
out.
The
first
thing
that
I
actually
thought
like
when,
when
I
saw
the
issue,
was
to
potentially
upstream
this-
I
don't
know
if
it,
I
don't
think
like
you
for
the
use
you
control
one
time.
H
Maybe
we
could
just
create
a
kubernetes
three.
Four
hundred
six
granny
six
repo.
D
So
vince,
that's
actually
so
two
questions.
One
have
you
looked
at
with
this:
have
you
looked
at
server
side
apply
yet
and
how
the
library
would
be
impacted
by
that
or
do
you
think
it's
covered
under
the
existing
patch
or
merge
stuff.
H
The
party
the
patch
is
done,
it's
a
custom
made
because
servers
that
apply
at
the
time.
I
don't
think
right
now.
Control
runtime
does
very
good
support
for
it.
Anything.
H
No,
we
have,
we
haven't
actually
used
use
that,
because
last
time
I
looked
like
controller
on
time
was
just
saying,
like
I
own
all
the
fields
every
time
you
issue
a
patch,
and
so
I
feel
like
that's
kind
of
like
what
everybody
does,
but
that
kind
of
defeats
the
purpose
right
and
the
other
challenge
was
that,
like
the
field
conditions,
it's
like
a
slice,
so
you
can't
say
I
own
a
specific
condition.
D
You
can't
say
it
because
the
type
should
be
the
same
as
like
a
name
discrimination.
There
should
only
be
one
condition
of
each
type.
H
That
yeah
that's
correct,
but
when
I
looked
at
it
like
the
owner
of
the
it's
the
owner
of
the
slice
right,
second,
not
each
condition.
D
You
can't
do
it
per
merge
key,
it's
interesting
because
I
swear
we
had
this
problem
in
another
spot
because
we
would
have
this
on
pods
in
containers.
It's
a
whole
bunch
of
them
yeah.
So
it's
kind
of
interesting
because
maybe
like
that's
something
that
did
get
or
or
maybe
as
a
giant
gaping
truck
hole
and
server-side
apply
that
everybody
just
hand-waved
across
it'd.
C
D
Good
to
know
for
sure
a
second,
like
you
know
it's
interesting
because
could
you
do
like
for
all
the
places
where
you
have
real
types?
Is
there?
Is
there
a
way
to
model
it
as
an
interface.
H
It's
already
actually
model
as
an
interface,
then,
when
you
define
your
own
conditions,
your
types
have
to
satisfy
the
interface
okay,
because.
D
We
very
early
in
cube.
We
were
like
we'll
use
physical
types
and
just
generate
everything,
and
then
we
found
more
like
a
lot
of
the
ugly
hacky
reflection
code.
D
If
we
could,
you
know,
I
think
it's
fine
to
think
about
as
a
library,
but
like
there's
part
of
me,
that's
like
this
is
conditions
are
pretty
fundamental
to
cube
I'd
like
to
make
the
case
that
we
need
to
take
conditions
more
seriously.
Like
certainly,
there
was
like
the
whole,
we,
you
know
a
couple
years
ago,
we're
like
well.
Maybe
we
won't
go
like
partially
due
to
cluster
api
and
k
native
feedback,
we're
like
maybe
we
won't
be
generic,
we'll
just
go
use
concrete
fields,
and
then
we
tack
back
and
be
like
they're
extensible.
D
They
allow
multiple
controllers
to
coordinate.
I
do
at
least
feel
like
we
have
a
little
bit
of
momentum
in
that
space,
so
I
would
like
to
see
something
closer
to
core.
I
guess
another
question
would
then
be.
Does
jason
the
point
you
brought
up
about
k
native
like?
Are
there
any
similarities
between
what
k-native
was
doing
with
the
duck
typing?
That
could
benefit
like
to
you
know,
get
allies
in
the
condition,
fight
and
join
together.
A
Yeah
I
mean,
I
think
these
are
the
only
two.
As
far
as
I
know,
these
are
the
only
two
like
reusable
intended
to
be
reused
packages
for
conditions.
If
there
are
others,
please
let
us
know,
because
I
think
it
definitely
makes
sense
to
upstream,
like
what's
the
word
for
when
you
upstream
and
merge
something
at
the
same
time,
this
and
k
natives
both
into
the
same
place.
I
don't
think
either
of
them
are
like.
I
don't
think
that
I
don't
know
neither
of
them
are
massively
better
than
the
other
one.
A
As
far
as
I
can
tell,
I've
only
ever
really
used
canadians.
I've
never
used
cluster
apis,
but
they
seem
roughly
the
same.
So
natives
works
by
embedding
this
their
status
type.
I
could
find
it
somewhere,
you
embed,
k-native
status
type,
which
provides
conditions,
and
then
you
already
get
all
of
the
interface
satisfaction
stuff,
because
you
embed
that
type.
That's
just
a
different
way
to
go
rather
than
have
is
this
vince.
You
mentioned
that
there's
an
interface
that
customers
have
or
clients
have
to
use
of
this.
A
H
To
use
this
util
library,
you
have
to
have
get
conditions
and
set
conditions
on
it.
The
client
object
is
the
control
runtime
client
object,
which
correctly
it's
just
a
runtime
object
and
meta
object
at
the
same
time,
because
you
use
them
all
the
time
together.
We
just
said
we're:
just
gonna
merge
these
two
into
an
object
and
control
runtime.
A
Yeah
sean,
you
have
raised
your
hand.
I
Yeah,
I
think,
can
folks
hear
me
yeah,
okay,
cool.
I
think
that
there's
also
a
conditions
library
inside
open
shifts
operator
sdk.
You
might
want
to
bring
those
folks
in
as
well.
I
think
that
they
were
doing
something
similar
to
like
the
embedding
or
any
or
something
like
that
and
making
that
work.
So
just
something
to
also
add
to
that
list
of
people
who
have
attempted
condition.
Libraries.
A
Yeah,
that's
that's
super
useful.
I
will
also
look
for
that
and
edit
too
somewhere,
I'm
not
sure
who,
on
the
k
native
side,
we
we
should
forcibly
volunteer
into
working
on
this,
but
we
can.
I
could
find
somebody.
D
The
there's
there's
a
separate
thread
that
this
made
me
think
of.
We
had
a
brief
discussion
like
unstructured.
Originally,
we
almost
got
close
to
doing
a
better,
unstructured
interface
library,
like
it's
kind
of
mucky,
a
lot
of
the
physical
types
like
the
cube
go
types
just
kind
of
like
involve.
D
We
never
actually
went
back
and
looked
at
like
ergonomics
on
it
deep
copy
and
conversion,
and
all
of
these
are
kind
of
what
is
the
next
practical
thing
we
need
to
get
to
that
next
step
and
survive,
but
interfaces
better
ergonomics
for
unstructured
that
feel
more
natural
and
then
the
stuff
that
service.
This
is
partially.
Why
I
brought
up
server
side
apply.
D
There
is
generated,
server-side
apply
helper
code
that
tackles
some
of
the
you
know,
go
and
set
individual
fields
right,
it's
kind
of
the
what's
it
called
fluent
style
for
that,
and
it
works
better
with
patching,
and
all
of
that,
because
you
can
define
your
function,
take
your
base,
object
and
say
set
set
set,
set
set
in
a
way
that
you
know
at
least
gets
at
some
of
those
natural
semantics.
It's
not
perfect
by
any
means,
but
it
feels
like
the
intersection
of
those
is
a
little
bit
of
like
the
general
problem.
D
Space
here
is:
we've
let
crds
and
go
types
kind
of
disperse
into
the
wild,
but
we
have
a
bunch
of
common
patterns,
we're
not
as
disciplined
about
the
core
patterns
that
we
use.
We
kind
of
let
them
mix
like
we
let
different
groups
building
in
the
ecosystem
or
different
sigs
or
different
projects,
try
them
but
doing
something
to
like
bring
them
back
in.
I
feel
like,
for
you
know
easy,
like
we're
going
to
be
dealing
in
at
least
even
in
kcp
land,
with
thousands
like
everything
is
going
to
be
an
unstructured
object.
D
You're
using
server
side
apply
you're
using
conditions,
and
then
we
start
thinking
about
stuff
like
oh,
I
want
to
add,
facets
to
objects,
dynamically
right,
adding
new
fields
or
stripping
fields,
or
you
know,
being
able
to
take
object,
a
and
combine
it
with
a
duct
type
b
and
get
an
object
c
that
you
expose
in
a
workspace,
and
you
never
know
that
there's
a
different
version
of
it,
like
that's
part
of
the
infrastructure,
a
lot
of
that
models,
some
of
those
same
things
of
if
we
can
get
to
some
of
that
together
like
and
find
use
cases
like
we'll
want
those
pieces
in
place.
D
So
I
I
think,
like
the
I
don't
know,
if
everybody
needs
to
change
and
that's
maybe
the
one
obstacle
here
is
like
we
got
to
climb
the
hill,
but
it
would
be
good,
maybe,
like
I
really
agree,
jason
like
trying
to
canvas
and
with
a
couple
of
groups
and
being
like
hey,
does
this
make
sense
to
have
in
core?
Can
we
get
some
basic
agreement
on
a
couple
concepts?
Nothing
here
is
even
really
objectionable
from
stuff.
D
We've
said
before
a
lot
of
times
is
who's
going
to
support
it,
and
you
know
who's
willing
to
you
know:
do
the
cigar,
sig
api
machinery,
six
cli,
sig,
sig,
sig,
dance.
A
Yeah
I
mean
the
the
nice
thing
about
duck
typing.
Is
that
it
doesn't?
Your
go
type
doesn't
have
to
conform
to
this
interface,
for
it
to
be,
you
know,
detectable
and
pickupable
as
a
as
a
thing
with
conditions
that
you
operate
on.
The
downside
is
that
it
duct
typing
works
by
like
json
marshalling
and
checking
for
the
existence
of
fields
which
can
be
slow
and
annoying
and
gross,
but
yeah.
I
know
for
a
while.
A
H
Yeah
I
was
going
to
add
to
what
plato
was
saying
like
the
the
challenges
that
we
have
with
the
intersectional
instructor
and
crds.
Is
that,
like
you,
don't
know
if
that's
if
it's
a
if
a
type
is
of
which
type
so
it's
like?
If
you
have
a
statistical
condition
in
there,
you
don't
know
if
it's
like
the
core
conditions,
it's
your
own
conditions
as
you,
as
you
mentioned,
it's
like
it's
just
json,
it's
like
you,
just
unmarshall
it.
H
If
there
was
a
concept
of
like
core
on
marshall
and
then
maybe
like,
we
could
start
with
that
x
cup,
I'm
jumping
ahead
but
like
if
you
have
like
an
x
kind
of
slash
annotations.
Like
says
these
are
the
core
conditions
and
they
do
respect
these
types.
Then,
on
marshall,
maybe
like
it
could
be
a
little
bit
more
smarter
to
get
that
information
back
so
that
you
know
what
it's
trying
to
do,
because
we
ended
up
regret.
Probably
all
the
project
like
I
did.
H
The
same
thing
ended
up
rewriting
like
a
lot
of
like
the
conflict
resolution
logic
for
conditions,
because
when
you
want
to
merge
these
these
conditions
together,
you
don't
want
to
lose
information
unless
there
is
a
conflict.
The
conflict
has
different
definitions,
because
when
you
pass
or
like
when
you
update-
and
there
is
a
conflict
on
the
or
like
I
guess,
when
you
pass
with
the
reserves
version-
and
there
is
a
conflict
in
the
research
version,
you
want
to
do
like
two-way
merge
of
those
conditions
and
then
reapply
it
to
see.
H
You
know
if
everything
went
smoothly,
but
then
our
problem
was
that,
like
a
different
controllers
could
write
like
kind
of
the
same
condition
sometimes,
and
so
how
they're
like
you
just
have
to
return
an
error.
So
that
was
the
specific
bit
that
we
do
have
in
our
code,
which
would
be
great
if
we
can
work
with
others
to
just
like
counter
a
solution
like
what
is
what
should
be
a
condition
in
kubernetes
and
how
we
define
it.
D
And
yeah
evan
was
the
person
I
was
thinking
of
as
well.
I
don't
know
how
much
time
you
spend
but
like
so
to
demonstrate
this
question.
You're,
absolutely
right.
Dems,
maybe
like
then
that
like
vince,
following
up
on
that
too,
like
a
lot
of
this
is,
can
we
come
up
with
a
reason
that
gives
us
a
strong
case
for
improving
this
across
a
bunch
of
places
at
once?
D
So
like
some
of
like
the
kcp
mindset
is
like
if
we're
abstracting
all
these
types,
we
want
to
make
sure
that
the
machinery
in
cube
is
really
good
for
crds.
It
gives
us
a
reason
to
improve
crds.
It
gives
us
a
reason
to
invest
if
a
user
gets
some
benefit
out
of
using
this
library,
like
a
controller
author,
because
it
makes
some
use
case
better
so
like
like
at
least
for
like
in
the
kcp
use
cases
which
I'm
just
like
going
through
my
head
here.
It's
the
are
you
scheduled.
Are
you
unscheduled?
D
We
want,
we
would
really
want
to
be
like
yeah.
Every
ui
could
just
go.
Look
at
the
scheduled
condition.
Oh,
your
type
doesn't
have
a
conditions
field.
What
would
it
take
to
get
you
to
have
those
that
also
leads
some
other
questions
like
you
know,
maybe
crds
should
start
like.
Maybe
we
should
start
thinking
about
like
what
are
the
things
that
everybody
should
have,
that
they
don't
have
on
crds.
That
could
be
options
for
crds
or
what's
something
that's
better
than
just
spec
status
split.
D
You
know,
we've
come
up
with
a
couple
of
other
things.
Like
you
know,
phase
is
definitely
something
a
lot
of
people
have.
I
doubt
there'll
be
one
common
thing,
but
conditions
is
like
if
there's
something
that
everybody
has
its
conditions
scale
is
another
one
that
kind
of
made
sense.
It
had
a
very
concrete
reason.
A
Yeah,
I
think
you
mentioned
also
that
how
do
we
handle
things
that
don't
have
conditions
or
don't
have
status?
I
think
most
things
do,
but
if
we
have
a
library
in
place
to
to
do
duck
type
condition
grabbing,
then
it
can
also
be
responsible
for
fallback,
like
I
think,
we've
talked
about
a
long
time
ago.
Writing
this
stuff
to
annotations.
If
we
can't
put
it
anywhere
else,
it
could
be
responsible
for
writing
it
to
an
annotation,
and
you
know
detecting
that
and
pulling
it
back
out
and
saying.
A
D
Go
types
are
really
fast
and
there's
nothing
in
the
middle.
So
a
lot
of
the
machinery
like
we
use
the
json.
We
use
the
json
patch
library
to
do
like
things
that
don't
have
anything
to
do
with
patching,
because
the
merge
algorithm
is
something
that
we
expect
as
part
of
a
behavior,
but
a
lot
of
like
jordan,
and
I
were
like
we
keep.
We
keep
going
back
to
serialization
libraries
because,
like
more
stuff
uses,
json
crds
are
still
slow.
D
We've
got
to
do
something
about
protobuf,
like
gogo
protobuf
at
some
point,
so
we've
kind
of
been
like.
Can
we
get
to
a
faster
json
implementation
that
everybody
could
use?
Go
cc
is
actually
one
of
the
few
that
kind
of
like
it's
basically
building
a
shape.
This
builds
a.
It
builds
a
little
virtual
machine
for
parsing
a
type
and
it
does
it
in
a
fairly
principled
way,
and
so
it
gets.
D
D
Unstructured
really
is
a
bit
of
a
mess.
It
may
be
that
what
we're
looking
for
and
we've
always
talked
about
this
with,
like
I
don't-
I
don't
think
anybody
here
was
even
working
on
cube
when
we
talked
about
this
the
last
time
but
smart
objects,
maybe
andy
remembers
or
staphon.
Maybe
this
is
something
we
talked
about
like
we
were
talking
about.
Runtime
object
in
cube
in
the
absence
of
generics.
D
There
is
a
lot
of
duplicated
code.
It
may
be
that
we
have
enough
of
a
use
case
now
to
say
like
maybe
we
can
align
that
with
you
know
a
better
unstructured,
a
faster
json
serializer
and
some
of
the
like
lazy
or
unlazy
typing,
where
you'd
want
to
be
able
to
say,
like
hey,
I'm
passing
this
unstructured
around,
like
what
type
is
this?
Even
if
I
make
some
change,
if
I
applied
a
patch
to
it,
is
it
still
valid?
D
A
A
Okay,
so,
and
we
would
also
like
to
make
it
easier
for
crd
authors
to
make
this
easy
for
us
by
having
there
be
a
good
conditions,
library
and
adopting
conditions
as
a
best
practice
everywhere
I
mean,
I
think
I
think
it's
already
a
best
practice,
but
everybody
defines
their
own
conditions
type
everywhere,
which
is
annoying
okay,
I'm
going
to
take
an
action
item
to
talk
to
evan
and
the
whoever
on
the
operator.
Sdk
team
is
working
on
that
condition,
stuff
and
probably
events.
A
I
will
rope
you
into
something
later
and
we'll
see
if
we
can
make
any
progress
on
coming
to
a
a
good
central
place.
For
all
of
this
I
mean
everybody
has
a
library
for
this,
but
everybody
hates
it.
So
we
should
all
just
have
one
that
we
essentially
focus
on
hating.
A
A
Are
people
see
is
that
working
okay,
yeah
I
wanted
to
give
an
update
on
some
of
the
last
week
I
went
over
the
namespace
scheduler.
I've
made
some
progress
on
there.
I
still
think
there's
a
couple
more
things
I
want
to
do,
but
thank
you
for
the
feedback
from
steve
and
andy
and
everyone
else
who
has
commented
we're
using
separate
queues
for
different
resources,
which
is
excellent,
we're
in
queueing
resources
instead
of
doing
it
synchronously.
A
That
was
very
nice
unit
tests
exists
and
even
pass,
which
is
amazing,
and
I
just
need
to
write
end-to-end
tests
and
clean
up
some
dependency
injection.
Otherwise
it
seems
like
it's
in
a
pretty
good
state.
Also.
I
think
we
talked
about
last
week.
I
don't
remember.
If
we
talked
about
last
week,
it's
been
a
whole
week
ago
that
we
were
adding
the
oicd
oic
oidc
flags
to
kcp,
so
that
we
can
support
oidc
authentication,
that's
in
or
sorry
that
is
proposed,
but
needs
a
rebase
on
some
of
steve's
improvements.
B
Yes,
that's
going
to
be
very
interesting
paired
with
the
virtual
workspace
stuff,
because
then
you
know
idc.
You
might
also
be
able
to
get
or
to
grab
some
attributes
of
the
user,
which
could
be
interesting
as
a
very
first
step.
You
know
to
implement
some
sort
of
the
user
belongs
to
a
given
organization
so
and
stuff
like
that.
Yeah.
D
That
that
I
think
that
is
a
that
is
an
area
where
we
need
to
like
the
we
need
to
be
looking
at
what
is
the
intersection
of
off
authenticated
attributes
and
workspaces
tied
to
use
case,
not
everybody's,
going
to
have
like
the
same
organization
structure.
But
if
we
can
get
a
close
enough
one,
then
you
know
doing
some
of
that
stuff.
D
A
D
D
I
have
this
role
in
or
whatever
it
was
assumed
that
we
would
go
into
that
at
some
point,
but
I
think
there's
some
modeling
questions,
which
is
the
context
that
you
do
that
in
you
probably
like
this
is
like
the
lesson
I
think
namespaces
and
projects
and
openshift
have
really
like.
If
you
want
to
cube
control,
apply,
helm,
apply,
get
op
supply,
you're,
looking
for
predictable
naming
with
rbac.
D
What
are
the
odds
that
you
can
apply
and
get
a
predictable
set
of
names
that
aren't
colliding
with
someone
else?
The
collision
aspect
is
one
of
the
most
problematic
from
a
like.
I
want.
I
want
a
list
of
everything
I
have
access
to.
That's
kind
of
the
use
case
of
like
people
have
granted
me
access
to
a
bunch
of
really
independent,
discrete
things
that
don't
really
share
any
overlap.
D
The
different
use
case
is,
I'm
deploying
you
know.
I
want
to
get
opsify.
Multiple
teams
deploying
you
know
a
full
like
micro
server,
so
I
want
to
break
that
up
or
split
it
together.
That
use
case
is
subtly
different
from
the
workspaces
I
have
access
to.
It
might
be
more
like
I
want
to
create
a
place
like
an
organization
or
a
container
for
all
my
workspaces,
and
then
I
want
to
be
able
to
do
cube,
control,
apply
and
get
the
same
names
there
so
that
I
have
reproducibility.
D
D
That
may
not
be
an
actual
use
case
right,
it
might
be,
and
how
would
an
organization
deploy
like?
I
don't
know
how
many
people
here
are
familiar
with
like
airship
and
the
work
that
was
done
around
openstack
and
telco
around
helm
and
all
of
that,
but
I
think
it
was
called
airship.
D
It
was
a
big
initiative
which
was
like.
Could
you
deploy
an
entire
telco
infrastructure
like
from
like
rand,
to
central
core
to
apps,
to
like
huge
swaths
of
you
know,
infrastructure
from
a
single
spot?
That
may
not
be
a
use
case,
but,
like
part
of
that,
big
idea
with
control
plane
would
be
like
if
you
could
get
it
big
enough
and
we
leave
those
affordances
in
place.
What
would
people
need
to
be
able
to
like
an
organization
admin
to
be
like
yeah,
I'm
going
to
deploy?
You
know
a
cloud-like
infrastructure
in
one
place
like
stuff.
D
D
Is
yolo
it
microservices
everybody
go
and
have
fun.
Call
me
when
we
get
a
security
breach
and
turns
out
we're
missing
the
processes.
There's
a
maybe
that
angle
is
like
hundreds
of
groups
working
together.
Maybe
that's
not
the
list
of
access
control,
but
it's
like
we
create
a
bucket
and
they
can
all
go
cube.
Control
apply
and
that's
a
very
good
use
case
for
virtual
workspaces
like
with
and
the
list
like,
I'm
in
an
org
I've
created
it.
How
would
I
get
into
that
or
I
might
need
a
different
like?
A
Yeah,
I
think
the
the
reason
I
wanted
to
push
on
more,
more
finer,
grained
access
control,
stuff
and
it's
probably
a
huge
diversion-
is
there's.
This
problem
in
google
drive
where,
if
I
want
to
share
a
doc
with
clayton,
he
doesn't
have
access
and
I
just
go
screw
it
I'll
share
it
with
everyone
at
red,
hat,
right
and
now
steve
when
he
opens
google
drive
sees
my
random
doc.
A
It's
not
sensitive,
it's
not
like
you
can't
see
it,
but
like
it
just
doesn't,
it
doesn't
need
to
be
in
his
face
when
he
opens
the
page.
You
know
so,
if
you
say
like
show
me
all
workspaces
for
which
I
have
any
amount
of
access
whatsoever,
you're
gonna
get,
and
maybe
it's
a
sensitivity
issue,
but
it's
also
just
like
a
spam
issue
like
I'm
almost.
B
Yeah
yeah-
and
maybe
maybe
just
one
point
here
in
the
demo-
I
did
the
the
idea
is
that
you
know
you
have
a
prefix
services,
slash
application,
slash
personal,
but
in
fact
it's
a
three-fold
prefix,
as
as
was
designed
initially
by
creighton
and
jessica.
B
I
think
it's
you
have
either
personal
organization
or
global
and
in
fact
it's
just
the
same
api
server,
but
that
will
grab
the
last
part
of
the
prefix
and
then
have
a
a
different
strategy
in
the
context,
so
that,
when
you
get
in
the
rest,
storage
to
to
get
the
list
of
the
workspaces
or
also
to
create
the
rules
would
be
different
and
the
way
you
would
and
and
obviously
the
authorization
you
know
rules
would
be
different
according
to
the
scope
of
the
workspace
list,
you
want
so
that
that's
how
at
least
I
envisioned
that
initially
in
this
virtual
world
space
does
it
make
sense.
D
Yeah
and
some
of
like
the
some
of
what
we're
kind
of
like
gonna
dance
around
is
like
what
are
we
actually
what
what
is
the
core
use
case?
We're
trying
to
enable
large
organizations,
lots
of
teams,
someone
being
able
to
deploy
like
not
just
a
whole
service
mesh
like
today,
you
could
do
get
ups
and
deploy
service
mesh
across
lots
of
clusters.
You
can
do
all
of
this
stuff.
You
can
break
each
your
teams
down.
D
You
can
give
them
policy,
you
can
do
what
would
like
thinking
through
the
mindset
of
I
can
easily
be
like
bulk,
apply
everything
or
I
can
look
at
it
and
say
you
can
bulk
apply,
but
then
I
have
a
parallel
set.
That's
like
oh!
This
is.
This
is
prohibited
right,
so
work
virtual
workspace
is
a
tool
for
that
as
well.
So
I
think
the
starting
point
is
where
you
are
as
we
go
forward.
D
D
Maybe
that's
in
code
for
a
certain
type
of
user
who
wants
to
create
these
like
and
and
run
them
in
their
org,
but
the
more
the
larger
case
would
be
the
yeah.
I
just
want
to
put
some
controls
on
and
be
able
to
impose
them
from
one
side.
What
would
the
virtual
workspace
infrastructure
need
to
look
like
you
know,
there's
lots
of
ways
that
we
can
approach
it
so
yeah
sure.
A
Cool,
so
with
the
last
few
minutes,
I
wanted
to
go
through
and
do
go
through
remaining
items
on
prototype
2
and
do
a
sort
of
status
check.
This
is
well
build
and
run
kcp.
F
D
A
Okay,
yeah
and
that's
that's
more
of
a
demo
of
minimal
api
server,
where
you
can
run
this
in
one
terminal
and
then
another
boob
that'll
get
you
know
whatever
and
see
that
it
works
great
easy
done
register
a
physical
cluster
with
kcp.
This
is
has
no
changes
since
the
last
time
we
prototyped
anything.
So
physical
cluster
registration
is
very,
very,
very
bad.
You
just
give
it
a
coupe
config
and
it
connects
and
installs
a
sinker
and
works.
A
A
So
that's
I
mean,
I
think
I
think
there
are
things
we
need
to
do,
but
that's
about
it.
The
synchro.
A
Yeah
now
that
I'm
reading
it,
I
agree
with
you.
I
thought
this
well
when
I
read
it
and
understood
it
before
reading
it
and
not
understanding
it,
it
sounded
like
a
workspace,
can
describe
the
set
of
physical
clusters
or
traits
of
physical
clusters
or
something
about
physical
clusters.
It
cares
about
scheduling
stuff
too,
and
that
is
taken
into
account
when
resources
in
those
workspaces
are
scheduled,
which
is
not
it's
not
currently
the
case,
and
it's
probably
more
on
me
than
on
you
and.
D
That's,
I
think,
it's
an
even
simpler
use
case,
which
is
any
workload
in
any
workspace
all
workloads.
Maybe
we
can
say
all
all
workloads
on
an
instance
of
kcp-
can
get
scheduled
to
one
of
a
set
of
clusters
as
the
bare
minimum
so
that
you
can
have
something
that
schedules
you
into
clusters
like
just
one,
not
not
end
user
configurable.
Not
that
would
be.
A
A
minimum
bar-
I
think,
in
that
case,
I
think
this
whole
section
doesn't
belong
and
register
a
physical
cluster.
It
belongs
in
transparent,
multi-cluster
below
yes,
because
this
is
a
this
is
your
description
of.
It
is
nothing
about
registering
a
physical
cluster
with
a
workspace
or
set
of
workspaces,
or
vice
versa.
The
administrator.
D
Can
set
it
up
so
that
a
set
of
static
physical
clusters
is
used?
Maybe
another
way
of
saying
that
and
the
only
thing
that's
needed
is
like
you
can
show
the
basic
demo
goal
of
like.
I
have
a
workload
on
a
cluster,
and
I
do
something
in
the
workload
you
know
it's
no
longer
that
cluster
yes
scheduled,
like
the
bare
minimum
of
that
idea,
is
what
was
intended
like
the
administrative
configuration
of
physical
clusters
such
that
scheduling,
does
something
useful
yeah
is.
F
A
F
D
F
D
Be
the
stepping
stone
to
the
next
step
would
be.
I
can
we
can
come
up
with
the
first
draft
of
what
location
looks
like,
as
maybe
a
administration,
so.
D
G
D
So
the
the
rough
is,
do
we
absolutely
have
to
let
an
end
user,
create
a
workspace
and
provide
a
new
cluster
for
prototype?
2,
probably
not,
but
I
think
it
would
be.
I
would
turn
that
question
back
around,
which
is
thinking
about
I'm
coming
to
prototype
2,
I'm
expecting
to
see
this.
Do
I
as
an
admin
or
something
need
a
physical
knob?
I
can
turn
to
show
that
or
do
we
think
that
the
demo
holds
together,
the
the
prototype
holds
together
and
shows
the
concepts
enough.
D
A
Here,
yeah,
because
this
this
point
is
about
registering
physical
clusters,
not
scheduling,
not
even
scheduling
stuff
to
it.
I
think
I
think
we
can
probably
I
think
we
can
demo
a
useful,
interesting
novel
thing
without
there
being
a
separate
concept
between
a
physical
cluster
and
a
location
for
now
for
this
prototype,
I
think
that's
something
we'll
want
in
the
future,
but
I
don't
think
we
need
to
do
that
now.
D
D
F
F
G
D
And
do
physical
cluster
is
and
actually
let's
let's
be
clear
though
physical
cluster
is
not.
We
know
that,
like
we're
going
to
change
it.
So
what
we're
saying
is
under
the
covers.
There's
physical
clusters
location
is
the
projection
into
the
workspace.
It's
okay
for
prototype
2
to
can
the
projection
into
the
workspace.
D
Unless,
because
we
already
knew
that,
we
we
didn't
know
exactly
how
to
represent
it
exactly
how
to
model
it,
I
think
it's
a
key
part
of
the
story.
Do
we
need
it?
Jason.
D
F
D
What
is
something
that's
going
to
feel
like
sorry,
probably,
this
would
be
my
guidance
find
something
that
feels
like
of
the
same
equivalent
heft
as
the
first
time
you
saw
cube
someone
delete
a
pod
and
saw
it
move
and
then
say
like
use
that
as
the
filter,
which
is,
this
is
half
as
exciting
as
that,
because
we
don't
have
all
the
move
stuff.
Okay,
but
when
we
add
the
move
stuff
it'll
be
equally
exciting.
F
A
E
B
Yeah
I
mean
yeah.
My
feeling
as
well
is
is
that
if
we
remove
the
location
abstraction
for
now,
then
we
nearly
have
what
is
required.
I
mean
currently,
the
cluster
controller
already
reacts
to
cluster
creation
or
removal,
and
even
the
initial
deployment
splitter
was
doing
the
required
stuff.
If
you
remove
the
clusters
in
the
demo,
I
did
some
some
weeks
ago
on
the
workspace
that
was
a
bit
the
same.
You
remove
on
one
side
and
then
everything
is
is
is
moved
to
the
other
to
the
right
to
the
other
place.
B
So
I
mean
it
seems
to
me
that
we
would
just
have
to
slightly
enhance
some
sort
of
schedule
that
would
annotate
the
you
know
cluster
annotation
accordingly,
but
apart
from
that,
we
have
all
the
rest.
It
seems
to
me
yeah.
I
think.
A
G
D
D
E
D
So
but
this
is
picking
a
shard,
we
only
have
one
shard,
so
we
picked
the
shard.
We
don't
need
to
pick
it
with
capacity.
So
I
think
that's
right,
but
there
are
two:
they
were
the
original
reason.
Those
two
were
called
out
and
this
was
in
the
more
the.
These
were
grabbed
from
the
whole
demo,
not
prototype,
two
like
the
the
the.
A
Okay,
I'll
go
through
and
clean
this
up
a
bit,
but
I
think
we
what
we
did
was
remove
the
concept
of
locations
as
an
abstraction
and
in
an
in
direction.
Things
will
just
physical
clusters
will
register
stuff
will
get
scheduled
and
moved
there.
You
can
delete
one
and
it'll
move
elsewhere.
That's
enough
makes
sense.
Yeah
syncer
will
run
with
minimal
permissions.
When
I
do
that
work,
workspace,
administration
and
tenancy.
How
do
we
feel
about
this
one
as
anybody.
G
G
I
think
I'm
on
my
third
or
fourth
iteration,
of
trying
to
figure
out
how
to
plumb
this
through,
but
I
think
I
maybe
have
an
idea
that
could
pass
muster
for
upstream.
So
I'm
working
on
that
right
now,
the
I
think
there's
still
our
back,
which
hasn't
been
defined
and
then
the
things
that
steve
is
working
on
around
this
workspace
scheduling
and
assignment.
A
All
right
is
the
point
about
a
workspace
being
typed
as
organizational
and
containing
other
workspaces.
That's
still
on
the
table.
F
F
G
I've
been
just
hacking
for
right
now
and
saying
all
workspaces
live
in
the
admin,
logical
cluster.
We
can
change
that
later,
but
it
works
for
now.
F
F
I
guess
I
just
wondered
like:
what's
the
like,
what
is
the
demo?
What
are
we
doing
with
the
organizational
type
of
workspace
like?
What
is
that?
I
guess
we
kind
of
do.
We
need
something
more
than
an
informal
understanding
of
like
this
is
where
api
inheritance
comes
from
and
other
workspaces
exist.
I.
G
Would
say
for
prototype
2!
No,
I
think
like
something
beyond
prototype.
2
that
involves
org
workspaces
and
more
more
than
just
basic
scheduling
will
pull
in
all
of
the
thinking
that
staphon
and
david
and
others
have
been
looking
at
around
the
workspace
index
and
real
sharding
and
the
architecture
there.
But
I
don't
think
if
you
go
back
up
to
the
demo
and
you
don't
have
to
scroll
json
but
like
looking.
A
E
G
B
Yeah,
but
that
maybe
that's
related
to
virtual
workspaces,
I
mean
it
seems
to
me
that
when
you
connect
you
just
get
you
you
just
get
into
a
virtual
workspace
and
then
either
you
can
create
a
workspace
that
will
finally
be
a
real
workspace
in
the
in
the
logical.
You
know
organizational
logical
cluster,
but
but
I
mean
from
the
it
seems
to
me
that
that
virtual
workspace
is,
I
mean
who's
whose
skeleton
I
showed
just
today
is
related
to
this.
F
F
D
Workspaces
for
an
individual
or
a
team,
the
organizational
workspace
is
the
meta
idea
and
not
does
not
have
to
be
concrete.
That
shows
an
admin
doing
some
things
to
enable
some
things
that
end
up
with
end
users
successful,
and
I
basically
andy.
A
The
root
workspace,
so
the
the
interesting
and
useful
and
emotionally
connecting
part
of
this
demo
that
we're
talking
about
is
an
org
admin
logs
in
somewhere
and
says
you
all
get
these
apis
and
now
somebody
logs
into
a
child
workspace
and
says:
oh,
I
have
these
apis
and
then
the
admin
edits
the
apis
and
the
child
says.
Oh
now
I
have
these
new
apis.
Thank
you
and
then.
D
Your
apis,
the
user
can
like
and
then,
when
we
get
into
api
export,
the
user
will
then
we'll
just
add
on
to
the
end
of
that,
and
then
the
user
overrides
those
apis
or
adds
their
own
api
or
consumes
an
api
and
so
more
workspaces
and
we'll
say.
But
what,
if
you
have
two
teams,
two
groups
of
teams?
So
I
think
that's
right.
E
F
F
D
So
there
is
going
to
be
a
working
group
that
takes
full
experts
from
here
and
mixes
them
with
experts.
Jessica
has
been
chasing
a
lot
of
that
with
ciam
and
with
app
studio,
so
at
a
very
high
level
use
case.
Yes,
implementation,
no
understanding
of
what
that
actually
means.
Knowing
that
we'll
try
to
get
that
going
soon,
steve.
D
A
Your
request
right
now
so
right
so
airbag
is
our
back
is
not
what
it
sounds
like
saying.
Clayton
is
that
arbeck
is
here
as
an
example
of
a
thing
that
an
admin
can
define
in
the
admin
workspace
that
child
workspaces
get
for
free.
Without
you
know,
zero
cost,
not
specifically
that
it
is
our
back
rules
specifically
being
defined.
D
I
would
say,
because
we
have
to
make
workspaces
zero
cost
and
the
default
cube
model
is
to
go
copy
and
create
all
this
stuff
and
we're
trying
to
really
hit
on
the
zero
cost
aspect.
What
we're
saying
is
in
order
to
even
just
make
our
back
basically
work.
We
need
to
do
the
bare
minimum
so
that
you
could
we'll
say:
okay,
an
admin
comes
in
and
then
gives
access
to
this
team.
What
does
that
even
look
like?
Does
we
have
to
have
that
for
prototype,
2,
negotiable,
an
admin,
because
there's.
H
D
Define
a
role
that
then
shows
up
that
shows
up
in
the
child
name,
space
or
edits
a
role
might
be
useful.
We
should
probably
scope
that
a
little
bit
more
down
to
the
minimum
of
that
intersection
of
well.
F
D
I
would,
I
would
probably
say
that
it's
just
for
right
now,
it
might
just
be
a
union
of
like
create
like
like,
like
have
like,
do
the
basic,
which
is
like,
maybe
for
a
workspace,
there's
just
a
shim,
our
back,
that
has
the
delegate
to
the
core.
Our
back
and
you
ask
decisions,
and
you
can
also
ask
the
parent,
like.
G
I
haven't
even
gotten
there
yet
so
like
what
I'm
working
on
is.
If
you
are
a
client
and
you
come
in
and
you
do
discovery
for
slash
apis
or
a
group
or
a
group
version,
or
you
actually
want
to
interact
with
a
custom
resource,
you
want
to
do
crowd
operations
on
it.
G
Then
your
url
will
include
a
logical
cluster
in
it,
which
is
your
workspace,
and
if
your
workspace
is
configured
to
inherit
apis
from
another
workspace,
those
will
show
up
in
discovery
and
you'll
be
able
to
do
crud
operations
on
those
and
they
will
be
stored
in
your
logical
cluster,
in
whatever
name
space
you
put
them
in
right.
D
And
the
r
thing
I
think
is
similar,
but
not
the
same
underspect
and
we
want
to
scope
it
to
the
minimum
that
shows
the
zero
cost
idea
and
then
allows
a
user
to
access
a
workspace
like
allowing
a
user
to
access
a
workspace
is
desirable,
but
we
could
always
walk
it
back
and
say:
okay.
Well,
we
didn't
actually
want
to
make
it
easy
for
users
to
go
for
an
admin
to
go,
give
access
to
a
workspace.
D
F
D
D
D
An
account
is
a
very,
very
hard
container
boundary
that
has
a
lot
of
useful
security
properties
to
large
organizations
and
multi-tenant
organizations.
Right
an
account
is
a
fifa
minute
of
itself.
Gcb
projects,
azure
resource
groups,
they're
a
little
bit
lighter,
but
they
still
share
some
of
those
hard
characteristics.
D
Maybe
we
want
every
workspace
to
have
a
role
binding
in
it
or
you
don't
have
access
to
it
unless
you
are
some
class
of
user,
because
that
kind
of
looks
a
little
bit
more
like
the
aws
account
model.
Alternatively,
maybe
we
want
to
have
something
on
the
workspace
object
that
says
this.
These
people
have
these
base
roles
and
those
can
never
be
taken
away
from
the
workspace
and
then
there
may
be
an
option
where
we
say
look:
hey
look.
D
The
admin
has
access,
I
don't
know
which
one
we
need
to
talk
through
it,
but
this
gets
into.
We
should
just
get
enough
of
a
direction
that
people
can
access
the
workspaces
and
create
the
objects,
as
andy
is
getting
at
and
do
the
rest
of
the
demo
and
it's
gotta
stay
close
to
zero
cost,
so
we
can
definitely
scope
it
down.
F
D
A
Organizational
policies,
but
the
so
centralized
organizational
administration
is
one
dimension
of
why
this
is
interesting.
The
other
dimension
is
it's
free
to
have
a
million
of
these,
which
is
differently
interesting.
D
F
D
Well
so,
but
there's
unique
properties
of
our
back
and
this
gets
into
like
web
hook,
authentication
like
the
unique
properties
of
our
back
is
it
is
an
additive
model
and
that
you
can
union
two
sources,
and
so
it
could
be
that
you
might
say
like.
Oh,
like
we
just
define
a
virtual
workspace
that
is
like
the
our
back
source
for
an
order.
Maybe
it
comes
from
the
org,
so
I
don't
know
what
we
don't
know
what
we
need
to
do
yet
there.
D
So
I'd
probably
just
be
like
we
want
to
get
at
the
common
elements
of
organization,
which
is
mostly
roles
or
the
ability
to
interoperate
with
things
that
you
add
right
like
adding
an
api
as
andy,
you
say
it
has
to
give
you
access
to
edit
that
api,
it's
kind
of
pointless
unless
you
don't.
That
is
a
point
of
zero
caustism
that
you
know.
D
D
A
Cool
we're
only
23
minutes
over
at
normal
time.
I
hope
that's,
okay,
deploy
an
application.
This
is
where
we
are
starting
to
show
scheduling.
Actual
stuff
number
two
was
about
registering
physical
clusters.
This
one
is
about
when
I
create
a
deployment
and
service
and
stuff.
Thank
you
for
flagging
this
steve.
We
should
get
rid
of
that
workspaces
when
there
are
no
physical
clusters.
A
Can't
seem
to
select
anything,
but
most
of
this
is
there,
with
the
namespace
controller
that
we
have
in
the
namespace
schedule
that
we
have
right
now.
Ingress
is
a
to
do.
I
don't
know.
If
I
don't
know,
if
ingress
is
going
to
be
more
difficult,
joaquim
is
is
tagged
for
the
english.
He
said
his
status
was.
D
A
Pr
out
there,
oh
nice,
but
the
other
two,
the
two
things
I've
highlighted
here
are
things
we
need
to
do
things
I
need
to
do,
but
have
not
yet.
I
think
those
are
fairly
shovel
ready.
I
just
need
to
go,
do
them
and
ingress
so
that
one's
that
one's
there
extension
of
two
yeah,
transparent
multi-cluster.
This
is
add
a
second
location,
disrupt
one
of
the
clusters.
It
moves
to
the
other
ingress
follows
this
is
also
in
the
same
way
something
the
name
space
name
space.
Scheduler
already.
Does
the.
A
A
I'm
not
supposed
to
be
adding
item
steve,
you
put
them
in
a.
A
Yeah
yeah,
including
health
checking
we
we
should
be
able
to
do
that
already
or
soon
the
shard
type
I'll
move.
A
Terrible
fix
that
later-
and
this
is
also
not
done
yet
but
relatively
straightforward-.
A
Okay
is
anybody
I
think
we
learned
some
things
doing
this,
so
that's
good.
I
wish
we
had
done
it
before
the
end
of
the
meeting.
Maybe
next
time.
A
Yeah
excellent,
all
right
does
anybody
else
have
anything
that
they
saw,
that
they
want
to
talk
about
or
anything
else.
A
All
right,
excellent
see
you
all
on
the
internet,
bye,
everyone.