►
From YouTube: Community Meeting, February 15, 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
Hey
everybody
today
is
february
15th
2022..
This
is
the
kcp
community
meeting
welcome.
If
this
is
your
first
time
and
what
we're
going
to
do
is
I'm
going
to
share
my
screen
momentarily
with
the
meeting
agenda
and
if
somebody
wouldn't
mind
posting
the
link
to
the
agenda
in
google
chat.
If
it's
not
already
there,
then
you
can
add
whatever
agenda
items
you
might
have.
A
Okay,
the
first
item
in
here
is
from
paul.
B
Yeah,
just
real
quick
general
announcement
for
folks
that
haven't
seen
it
before
we
have
been
planning
prototypes
in
this
project
view
in
github
we've
we've
spent
quite
a
bit
of
time,
closing
out
prototype
two,
so
we've
decided
to
retarget
prototype
three
for
march
18th,
for
closing
and
based
on
our
lessons
from
prototype.
2
we'll
begin
the
p3
demo
script
a
bit
earlier,
we're
going
to
try
and
start
that
on
march
7th
after
that,
from
the
end
of
p3.
B
All
the
way
till
the
end
of
april
is
when
we'll
target
prototype
four
and
that
should
get
us
back
on
the
the
monthly
cadence.
A
Thank
you
paul.
Any
questions,
comments,
complaints,
concerns
with
the
dates
and
the
changes
that
we're
looking
to
do.
A
Well,
if
you
do
have
any
or
want
to
know
more,
please
feel
free
to
reach
out
offline
or
async
or
later
on
a
meeting.
So
next
up
is
stefan.
C
Yeah,
I
want
to
point
the
eyes
on
two
documents
which
we
are
heavily
commenting
now,
maybe
just
click
the
first
one
we
have
been
working
for
more
than
a
week,
questions
around
low
level,
api
machinery
topics
and
what
they
mean
for
transparent,
multi-cluster
things
like
finalizers
thinking
of
annotations,
filtering
out,
some
of
them
owner,
refs
and
yeah.
I
see
many
many
keywords
you
probably
know
from
api
machinery.
C
C
Oh
yeah,
there's
even
more
content
I
haven't
seen
yet.
The
first
topic
in
here
is
workspace
types.
I
think
we
we
talked
about
that
in
different
occasions
already
before
that
we
have
to
support
something
like
that:
fmpr,
which
adds
this
type
like
there's
a
cluster
workspace
type.
It's
also
linked
in
inside
agenda.
C
I
think-
and
it
allows
basically
to
to
add
your
own
types,
the
typical
one
or
the
standard
one
is
universal,
so
universal
workspace,
which
gives
you
a
cluster
to
work
against,
basically
allows
everything,
so
it
should
be
available
everywhere
and
and
if
we
scroll
down,
I
think
we
wrote
it
there,
one
for
as
edges
in
the
middle.
That's
how
our
current
sketch
looks
like
when
this
object
is
in
awk
workspace.
C
So
initializers
people
will
remember
clayton
added
or
tried
to
add
that
to
kubernetes
long
long
ago
in
a
very
generic
way
for
all
resources.
This
is
very
focused
here.
It's
just
for
workspaces
and
for
that
reason
it's
much
simpler,
not
that
deep
in
the
api
machinery
in
the
moment
you
create
a
workspace.
You
have
to
wait
anyway
until
it's
scheduled
and
you
can
access
it.
So
it's
a
natural
way
to
to
attenuation,
as
I
say
as
well.
C
Yes,
the
blue
lines.
Here
I
think
we
will
talk
about
in
a
second
workspace
types,
so
the
universal
one
will
always
be
there,
but
the
type
object
might
be
missing,
so
you
can
always
use
universal,
even
if
nobody
specified
anything
and
you
will
be
administrator
in
that
and
there's
no
limitation
whatsoever.
So
that's
why
it's
called
universal
and
the
reason
for
this
talk
was
actually
to
add
those
blue
lines.
C
So
we
were
thinking
how
can
we
handle
or
how
can
we
define
authorization
for
workspaces
in
a
way
that
it's
extensible
in
different
dimensions
at
the
moment
in
the
prototype,
if
you,
if
you
run
that
we
have
a
bug,
set
up,
basically
it
it
checks
in
the
op
workspace
for
general
access
to
a
workspace,
and
then
it
checks
the
bootstrap
policy,
just
a
basic
cube
policy
in
some
org
workspace,
and
then
it
goes
to
the
local
workspace.
C
C
Of
course
we
want
to
generalize
the
hard
code
to
model,
that's
what
I
just
described,
what
we
have
now.
This
is
not
enough
item
two
here.
I
think
for
me
personally,
this
is
critical.
It's
it's
a
design
principle
or
goal
which
we
have
in
kcp.
I
think
which
makes
kcp
better
than
other
systems
where
you
only
get
namespace
access
and
have
very
limited
permissions.
C
Everything
we
build
should
follow
that
as
a
as
a
principle,
I
mean
there
might
be
exceptions,
but
everything
we
built
should
not
discourage
the
use
of
full
permissions
and
full
flexibility
for
users,
for
example.
This
means
you
should
be
able
to
install
cids
in
your
personal
workspace
and
everything
we
built
here,
even
if
a
workspace
serves
special
apis
like
database
objects
or
some
pipeline
system.
C
They
might
have
special
interests
to
protect
their
objects.
The
canonical
example
is,
if
you
offer
a
cid
for
for
consumers
in
many
workspaces,
you
don't
want
that.
The
users
can
provide
to
a
status
status
of
an
object
is
basically
reserved
for
for
the
operator.
For
the
controller
of
the
api,
and
even
if
the
user,
I
mean
principle
two:
if
the
user
is
admin,
he
should
still
be
under
the
control
of
what
the
third-party
api
provider
suggests
for
enforcers
wants
to
enforce
on
those
apis.
C
So
it
says
it
suggests
that
we
need
something
which
gives
the
third
party
provider
what
he
has
to
do
like
limiting
permissions,
but
at
the
same
time
allow
everything
else,
for
example,
and
the
last
one
platform
providers
also
want
to
restrict
possibly,
but,
as
I
said
before,
we
shouldn't
encourage
that.
So,
if
we
do
the
system
correctly,
the
platform
provider
will
probably
not
restrict
default
permissions
for
users.
C
C
D
Yes,
precisely
yeah,
if
you,
if
you
go
up
again
like
on
the
very
first
page
through
the
current
authorization
model.
D
So
what
we
have
thought
of
currently
is
that
the
user
facing
api
for
granting
you
know
course,
grain
permissions
to
users
for
workspaces
is
that
you
just
simply
associate
a
work
verb
against
the
workspace
content
subresource
and
grant
the
permission
against
that
verb
for
that
user,
and
by
doing
so
the
hard-coded
magic
happens
right
and
what
what
that
actually
means
is,
if
you
have,
for
instance,
view
permission
on
workspace
content,
what
happens
under
the
hood?
D
Currently
at
least
you
get
a
role
assigned
implicitly
and
that's
pretty
much
it
and
what
we
do
with
the
current
hard-coded
authorizer.
Is
we
associate
that
group
with
a
concrete
cluster
role
right
so,
like
concretely,
an
example,
like
some
user
foo
has
view
permissions
on
slash
workspace,
slash,
bas,
content
right
and
by
having
just
this
permission
expressed
by
a
binding.
D
What
currently
happens
is
that
you
just
simply
have
this
group
system
kcp
workspace
view
associated
with
the
user
right
and
from
then
on,
like
the
canonical
kubernetes
authorization
subsystems
take
n.
That
group
is
simply
bound
against
the
cluster
world
view,
and
thus
you
have
access
to
things
like
conflict
maps
and
workspace,
and
you
know
other
resources
that
are
implied
by
the
intrinsic
view:
cluster
role
inside
kubernetes.
D
Obviously
we
do
this
other
trick
that
we
explained
in
the
last
meetings
to
fan
out
to
the
organizational
workspace
and
to
the
current
workspace
in
flight
to
assert
if
you
have
those
permissions,
but
essentially
what
this
example
is
now
here
also
hard
coded
in
the
current
code
base
has
to
be
generalized
right.
So
if
you
scroll
down
a
little
bit
to
the
universal
cluster,
workspace
type
yeah
exactly
this
one,
the
blue
lines
think
verb
group
mapping.
The
basic
idea
is
to
make
this
declarative
what
we
currently
have
hard-coded
in
code.
D
So
what
I
just
described,
what
we
have
hard-coded
in
code
would
be
declared
in
this
cluster
workspace
type
of
name
universal
in
such
a
manner
right.
So
you
have
some
policy
and
that
policy
would
be,
in
that
case,
a
workspace
inside
this
policy.
Workspace
in
this
case
called
community
bootstrap
policy.
D
You
would
have
the
default
wall
bindings
right.
Just
what
I
mentioned
above,
like
the
view
role
binding
against
the
system,
kcp
workspace
view
group
right
and
to
declare
the
mapping
between
the
allowed
verbs
with
associated
groups.
You
would
have
this
field
which
we
didn't
know
yet
how
to
name
so
we
called
it
think
verb
group
mapping,
and
you
would
simply
have
this
list
of
verbs
colon
group
declared
here
and
also,
if
you
create
workspaces,
you
want
to
have
certain
default
verbs
implicitly
permitted
to
the
user
right.
D
C
Yeah,
just
just
one
comment,
the
things
we
wrote
down
here
they
look
complex.
Maybe
we
have
a
number
of
dimensions
to
to
specify
and
customize
things.
C
This
doesn't
necessarily
mean
that
all
of
that
gets
into
the
types
and
especially
not
in
the
beginning,
so
we
are
trying
to
to
find
dimensions
which
are
consistent
if
we
add
them
and
to
find
a
good
model
which
gives
us
possibilities
for
the
future.
So
it
doesn't
mean
that
everything
here
is
customizable
from
the
beginning.
That's
not
to
go.
C
Maybe
the
last
one
api
import
export.
Do
you
want
to
do
that.
D
Right
yeah
exactly
so,
there
was
one
last
bit
and
it's
a
thing
that
worries
me
a
little
bit
in
terms
of
complexity,
so
we
may
have,
you
know,
have
a
twist
on
it,
but
essentially
the
status
example
that
stefan
just
gave
what
you
could,
in
addition
to,
you
could
have
like
a
finer
gran,
finer,
grained,
declarative
model
of
associated
permissions,
not
only
on
the
workspace
level,
in
this
case
the
cluster
workspace
level,
but
also
on
concrete
api
exports
right.
C
Yeah
and
overwrites
in
the
sense,
this
is
basically
also
an
upper
bound,
so
everything
the
user
does
as
an
admin.
So
you
cannot
overwrite
that
he
cannot
give
his
himself
the
permission
to
update
status
of
a
kafka
resource
this.
Yes,
it's
it's
impossible,
because
this
one
just
overrides
everything
for
this
resource
right,
the
user
is
still
admin
for
everything
else,
but
not
for
this
one.
Not
for
this
object.
This
resource.
D
Right
so
my
worry
is
exactly
that.
So
therefore,
we
are
sort
of
like
asking
for
feedback.
Is
that
it's
sort
of
like
an
overlay
mechanism
as
well
right
so
at
least
in
kubernetes.
For
my
taste,
everything
is
pretty
obvious.
You
just
get
rolls
roll
bindings
and
you
pretty
much
have
a
good
view
on
what
permission
set
can
be
granted
right
here,
it's
a
little
bit
more
implicit,
so
maybe
we
can
find
a
better
model
yet,
but
at
least
this
catches
all
the
cases
that
we
discussed
so
far,
yeah.
A
I
know
I'll
certainly
need
some
spare
time
to
go.
Look
through
this
stuff.
I've
been
pretty
busy,
so
I'm
really
excited
to
see
what
you
all
have
gotten
started
working
on
thanks
for
sharing
and
as
always,
if
folks
have
thoughts
or
questions,
please
feel
free
to
chat
with
folks
in
slack
or
add
comments
to
the
doc,
and
I
think
it
was
posted
in
the
meeting
chat.
But
if
you
don't
have
access
to
these
docs,
you
can
join
the
kcp
dev
public,
google
group
and
you
will
get
access
to
all
of
these
stephan.
A
C
C
What
I
just
talked
about
again
in
the
workspace
object:
there
is
a
type
field
in
the
spec,
very
simple
and
in
the
pr
I
also
I
change
the
authorizer
to
actually
check
that
the
type
exists
so,
but
this
is
untested,
it's
really
just
written
down
to
get
those
types
in
yeah.
If
you
click
there,
I'm.
C
Okay,
so
and
there's
another
thing
inside
of
this
pr,
which
might
be
interesting-
that's
what
you
are
seeing
here.
Our
ambition
is
to
be
pretty
quick
in
making
workspaces
usable
right
for
early
adopters.
C
We
have
concerned
that
certain
things
of
our
original
workspace
object
are
not
I
mean
they
are
done,
sketched
out
somehow
implemented
partially,
but
we
know
it's
not
the
final
thing
and
for
a
reason
it's
we
want
iphone
one,
but
as
it
is,
if
you,
if
you
get
users
for
for
an
api,
basically
it's
set
in
stone
and
v1
alpha.
One
doesn't
matter
anymore,
so
the
idea
is
something
david
and
I
were
discussing
for
weeks
already,
basically
to
split
up
our
workspace
type
behind.
C
This
is
also
some
motivation,
which
clayton
said
many
many
times
everything
we
built
even
a
virtual
workspace
or
any
other
cube-like
endpoint
base
endpoint
base
url
is
called
a
workspace,
so
we
have
more
workspaces
in
those
which
are
backed
by
what
we
know
under
slash
clusters
who
in
the
api
path,
so
we
have
virtual
workspaces,
for
example,
we
might
have
others,
we
will
see
anyway,
so
those
two
motivations
are
behind
that.
So
this
pr
adds
v1
beta1
workspace
object,
and
here
here
you
see
it
very
minimal
super
minimal.
C
If
you
move
down
a
bit,
spec
is
empty,
spec
will
get
the
type,
but
nothing
else,
and
the
status
is
just
a
url
in
the
face.
So
there
is
nothing
about
charts.
There
are
nothing
visible
about
chart
movement,
not
about
what
else
that
we
have
all
the
fields
which
are
really
prototype
style.
That's
about
everything
is
left
out,
just
your
allen
face
and
when
you
go
to
the
virtual
workspace
that
david
implemented
and
you
create
a
workspace,
you
use
this
type.
If
you
lose
list
your
your
the
workspaces,
you
have
access
to.
C
You
only
see
those
fields.
So
it's
a
super
minimal
type.
We
are
confident
to
to
offer
to
users
even
early
stage
users
in
a
few
months
or
when
we
will
be
at
this
stage
the
object
behind
like
an
lcd.
It's
the
same.
It's
it's
it's
more
or
less
like
project
and
namespace
in
in
in
oak
shift.
Project
is
more
like
the
user
facing
thing.
Namespace
is
a
really
low
level
kind.
C
Both
share
the
same
key
in
absolute
one
of
the
one
is
a
projection
of
the
other.
That's
the
same
principle
here,
there's
another
reason
we
want
that.
I
mean
quality
of
the
types
and
confidence
is
one
thing
leaking
information
is
another.
I
think
in
a
multi-cluster
setup
of
kcp,
where
we
we
basically
target
service
providers
internally
in
companies
or
software
service
providers.
They
don't
want
to
leak
all
the
details.
C
C
Okay,
david.
C
Very
quick
last
thing
we
will
add
very
soon
organizations
organizations
will
be
just
another
workspace
type
in
the
sense
we
have
just
seen
here,
and
there
will
be
a
good
workspace
which
holds
organizations
those
I
mean
those
workspaces
of
the
organization
type,
that's
a
follow-up,
so
everything
here
is
basically
preparation
for
this
step.
So
also
expect
that
the
admin
workspace
will
hopefully
soon
go
away.
E
No,
I
I
think
it's
okay,
maybe
just
one
point
about
the
you
know
inherit
from
that
currently
exists
in
the
in
the
existing
workspace.
I
assume
that
it
was
not
added
there
because
it
would
be
quite
soon
replaced
by
you
know:
api
bindings
and
api
imports
and
stuff
like
that.
Yes,
so
obviously
we
would
not
not
even
have
to
you
know,
create
a
workspace
with
the
import
from
value,
as
today.
A
All
right,
thank
you,
stefan,
so
moving
on,
I
created
a
couple
things
here
so
last
week
I
spent
most
of
the
week
working
on
fleshing
out
the
prototype
2
demo.
So
I
got
a
whole
bunch
of
commits
in
here
that
largely
if
you
go
look
at
what's
in
here
and
you
look
at
the
script
file
for
prototype,
2
I've
gone
in
and
tried
to
put
together
what
I
think
is
hopefully
a
pretty
good
flow
in
terms
of
like
clearing
the
screen.
A
So
it's
not
just
like
one
run-on
of
command
after
command
after
command.
I
am
on
a
mac
and
there's
some
issues
getting
ingress
routing
through
the
vm
that
either
docker
or
podman
is
running
on.
So
I've
asked
joaquim
to
try
and
carry
the
torch
with
the
ingress
work,
and
what
I
would
ask
from
the
community
is
mainly
just
take
a
look
at
this
script
file.
A
Look
at
the
comments.
Look
at
the
flow
you
can
compare
it
to
the
google
doc
that
I
took
most
of
this
from
and
if
there's
any
changes
that
you
want
to
make.
If
there's
any
additional
text
that
you
think
would
be
helpful.
A
Let's
please
get
that
feedback
in
because
we
do
want
to
get
this
merged
and
closed
out
as
soon
as
possible.
I
do
recognize.
I
need
to
rebase
one
thing
which
I
will
do
today,
but
this
is
a
request
for
comments
on
that
and
the
other
thing
I
have
is
our
default.
Kubernetes
branch
and
our
fork
is
still
122..
Is
it
okay
to
update
to
123.?
A
C
A
Any
other
any
other
topics
for
today.
A
Okay,
well,
this
gives
you
about
30
minutes
back.
So
thanks
everybody
for
the
topics
today
and
we'll
see
you
next
time.