►
From YouTube: Community Meeting, March 28, 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
A
So
if
you
would
like
to
add
anything
to
the
agenda,
please
feel
free
to
add
a
comment
and
we'll
go
through
from
top
to
bottom,
but
before
doing
that,
I
am
seeing
some
new
faces
at
least
new
to
me,
so
welcome
and
thanks
for
joining.
If
there's
anybody
who
would
like
to
introduce
yourself
I'll
pause
now
and
give
you
folks
a
chance
to
do
so,
no
obligation.
So
if
you
don't
want
to
you
don't
have
to,
but
if
you'd
like
to
say
hi
and
give
a
you
know,
10
second
intro
that'd
be
awesome.
B
Yeah
I
just
wanted
to
introduce
a
few
folks
from
that
I
work
with
at
upbound
who
are
joining
the
call
who
are
going
to
be
getting
a
little
more
involved
in
kcp
I.
Think
Jason,
blue
lot
and
Ben
are
all
here.
So
you
are
welcome
to
introduce
yourselves
but
yeah.
We're
all
excited
to
be
here.
A
Okay,
so
I'm
going
to
move
on
to
the
first
item
in
the
agenda
here
from
Andy
so
over
to
you,
Andy.
C
Yeah
I
just
wanted
to
know
in
general,
I
put
a
feeler
out
there
for
Paul
a
couple
days
ago
in
haven't
really
had
any
chance
to
synchronize
hook
up
with
him
on
on
this,
but
I
wanted
to
know
in
general.
If
we
have
any
caps
in
place
or
are
planned,
and
you
know
what
are
the
prioritized
components
of
kcp
that
we
we
think
we
see
moving
Upstream,
just
a
general
discussion
and
if
there's
other
important
pressing
matters,
then
obviously
you
know
we
can
put
this
aside,
but
I
thought.
A
Yeah,
so
to
date,
as
far
as
I
can
remember,
the
only
two
potential
caps
that
we've
discussed
authoring,
our
first,
a
generic
control,
plane
Library
cap,
and
this
would
be
a
library
that
both
kubernetes
and
kcp
would
be
based
on
upon
a
successful
completion
of
implementing
it.
And
it
would
be
generic
enough
that
it's
not
specific
to
pods
or
stateful
sets
or
any
other
workload
related.
Built-In
types
and
the
nice
benefit
for
kcp
is
that
it
would
reduce
the
amount
of
code
that
we
have
to
carry
in
our
Cube
Fork.
When
we're
rebasing.
A
It
wouldn't
eliminate
it,
but
it
would
get
rid
of
some
of
it.
And
then
the
second
proposed
cap
is
around
logical
clusters
and
making
that
a
concept
that
the
Upstream
API
server
and
API
machinery
and
storage
code
would
accept
and
support.
A
Not
for
TMC,
it's
just
the
technical
foundations
for
logical
clusters,
so
it
would
support
workspaces
in
kcp,
but
we're
not
necessarily
saying
we
we
want
to
upstream
workspaces
and
I,
see
Paul
just
pasted
a
link.
There
is
a
logical
cluster
repository
that
said,
Gloucester
lifecycle
has
created,
and
so
that's
the
The
kubernetes
sigs
Logical
cluster
repo.
A
That
repo
is
around
accessing
or
referencing
entities
that
live
in
different
logical
clusters,
where
maybe
two
logical
clusters
are
actually
two
distinct
physical
clusters
or
two
logical
clusters
are
the
way
that
we
represent
them
in
kcp
and
that's
to
support,
among
other
things,
controller
runtime,
but
from
a
kept
standpoint
when,
when
I
mention
logical
clusters
and
getting
support
in
kubernetes
for
those
that's
about
taking
storage
and
in
particular,
SCD
and
segmenting
it
so
that
or
partitioning
it
so
that
you
can
have
distinct
logical
clusters
inside
of
one
storage
mechanism
and
having
the
support
in
the
API
server
for
it
as
well.
A
Okay
in
terms
of
API
bindings
and
exports,
we
haven't
talked
about
trying
to
do
account
for
those
I
think
it
would
be
cool
if
we
did
but
I
think
we
probably
need
to
see
what
sort
of
appetite
might
exist
for
some
of
these
Concepts
in
some
of
the
other
sigs
Beyond,
just
API
Machinery,
because
things
like
logical
clusters
and
API
exports
and
bindings
are,
you
know,
they're
they're,
useful
things
that
you
might
want
to
see
in
sick,
multi-cluster
or
I.
A
Don't
know
so
I
think
trying
to
find
supporters
in
some
of
the
sigs
where
they
might,
these
features
might
be
used,
could
be
a
good
good
thing
to.
A
We
haven't
started
writing
any
of
these
caps
and
I
think
it
would
be
great
if
there's
folks,
who
are
interested
in
co-authoring,
either
the
generic
control
plane
one
or
the
logical
cluster
one.
At
some
point.
Some
of
us
will
start
working
on
them,
but
I
don't
have
a
timeline
right
now.
A
Okay,
cool,
so
Mike
you
want
to
status.
Update
on
the
rebase
to
126.
I
was
on
vacation
last
week,
so
didn't
make
any
progress
beyond
the
little
bit
that
I
had
done
before,
but
yesterday
I
was
working
on
preparing
a
126
Branch
with
some
back
ports
for
some
of
the
PRS
that
we
have
in
our
Cube
Fork
right
now,
based
on
124.,
once
I
have
a
126
Branch
with
a
good
set
of
backboards,
then
I'm
going
to
try
and
rebase.
On
top
of
it.
A
Okay,
sergius
over
to
you.
E
Okay,
thank
you.
Okay,
so
I
would
like
to
present
some
progress
on
work
that
I
have
been
doing
in
a
tool
called
acute
bind
and
I
was
a
little
unsure
if
this
is
the
right
Community,
because
we
don't
have
a
community
called
in
coupon,
but
we
have
one
in
kcp
and
both
projects
are
very
so
to
say,
you
know,
semantically,
similar
and
I.
E
If
you
want
Andy
I
can
share
my
screen
to
have
a
little
bit
of
a
guided
introduction,
because
not
many
or
maybe
not
all
of
the
listeners
may
know
Cube
clients.
But
since
this
is
the
kcp
community
call,
you
may
know
the
concept
of
API
exports
on
API
bindings
in
kcp
and
essentially
the
tldr
of
qbind,
is
take
the
same
idea
of
API
exports.
You
know
in
coupon
they
are
called
API
service
exports
and
the
concept
of
API
bindings.
E
Here
they
are
called
API
service
bindings
and
instead
of
using
latest
resource,
schemas
and
kcp,
to
describe
the
concrete
API
that
you
are
exposing.
We
are
using
good
old,
crds
and
qbind,
and
the
tldr
is
instead
of
having
kcp
to
be
able
to
export
and
import
apis.
You
can
use
your
stock
kubernetes
cluster,
that
is,
you
have
some
provider
that
maybe
kubernetes
and
side
note.
There
is
the
key
logo
here
for
a
reason
that
is
exporting
apis.
E
You
can
bind
to
those
apis
and
import
the
crds
inside
your
cluster,
it's
sort
of
like
a
consequent
continuation
of
the
sort
of
like
service
software
as
a
service-ish
idea
that
we
are
pursuing
in
kcp
and,
as
you
see
here
currently
in
coupon,
we
have
kubernetes
as
a
provider
reference
backend
implementation,
but
we
would
love
to
also
gradually
introduce
kcp
as
a
provider
API
provider,
because
you
know
KTP
is
very
good
at
providing
apis.
E
Hence
it
makes
sense
to
to
use
them
in
Cube
bind
such
that
you
can
consume
apis
that
were
exported
in
PCP,
also
insta
kubernetes
characters.
However,
we
have
to
do
a
little
bit
of
homework
and
if
you
want
to
know
more
by
the
way,
this
is
a
drawing
made
by
Stefan,
who
is
obviously
also
known
here
in
the
kcp
community.
If
you
want
to
know
more
about
binder,
is
a
very
nice.
E
A
little
bit
more
into
detail
on
what
coupon
is
all
about.
Having
said
that,
before
we
like
attack-
and
you
know,
do
all
things
and
also
add
a
kcp
provider,
we
have
to
do
a
little
bit
more
homework
because
the
current
you
know,
implementation
of
coupons
also
needs
a
little
bit
of
massaging
and
love
when
it
comes
to.
E
You
know:
full
usability
in
a
production-like
environment
and
most
notably,
if
you
are
used
to
kcp
the
process
of
binding
to
apis,
is
pretty
simple
and
you
just
have
to
set
up
a
couple
of
orbic
rules,
and
sometimes
it's
not
that
simple,
as
Steve
found
also
previously
funneled
previously,
but
essentially
you
are
scoped
within
one
system.
You
have
cope
within
kcp
and
within
the
orbic
boundaries
of
kcp
in
the
world
of
cubind.
E
It's
not
that
simple,
because,
on
the
left
hand,
side
here
where
you
bind
apis
is
one
kubernetes
cluster
and
the
right
hand.
Side
is
another
provider
cluster,
so
they
are
like
literally
very
many.
You
know
Network
boundaries
between
those
tools
and
we
currently
before
you
can
bind
any
apis
similar
to
what
you
have
to
do
in
kcp
with
orbit
bindings.
We
have
to
authorize
ourselves
in
front
of
the
provider
where
we
have
to.
You
know
pick
a
couple
of
apis
that
we
want
to
bind
against
and
there
is
a
you
know.
F
E
Will
spell
you
the
details?
It
will
not
go
through
all
the
details,
but
there
was
one
thing
that
was
implemented
in
sort
of
like
a
you
know,
initial
prototype-ish
way,
and
that
is,
if
you
invoke
the
coupon
command
line
interface,
that
is,
you
know,
a
regular
Cube
cuddle
plug-in.
It
literally
exposes
a
web
server
listening
on
localhost
and
it
blocks
until
you,
you
know,
executed
all
the
necessary
steps
on
the
provider
side.
That
is,
you
authenticated.
You
authorized.
E
You
pick
the
apis
that
you
would
like
to
import
into
your
cluster
and
after
all,
that
Machinery
is
done.
Literally,
the
browser
executes
a
callback,
a
302
callback
against
localhost
such
that
it
hits
your
blocking
Cube
couple
bind
web
server.
This
is
a
nice
initial.
You
know
implementation.
However.
Obviously
it
has
one
of
the
biggest
drawbacks
is
that
you
know
you
cannot
invoke.
The
cube
couple
bind
binary
on,
for
instance,
a
remote
machine
via
SSH
who,
because
you're
on
Local
web
browser,
cannot
reach
that
machine
and
the
Callback
would
lead
to
Nowhere.
E
The
other
drawback
is
that
we
have
to
transfer
a
lot
of
metadata
via
this
callback.
There
is
literally
a
cube,
config
generated
on
the
provider
side
and
a
lot
of
additional
metadata
that
has
to
squeeze
this.
You
know
a
request
parameter
back
into
this
callback
URL
and,
as
you
know,
you
know
there
are
limitations
in
browsers.
E
We
could
go
on.
We
would
like
to
improve
this,
and
you
know
what
one
step
that
we
want
to
improve.
This
is
what
I
you
know
called
a
poll
based
binding
process
and
also
without
going
much
more
into
detail
is
we
are
obviously
replacing
a
local
host
callback
with
State
on
the
provider.
So,
instead
of
blocking
until
you
finalize
the
process,
we
are
regularly
pulling
the
back
end.
Are
you
done
yet?
Are
you
doing
it?
E
It's
very
simple
semantic
and
when
the
user
finalized
the
whole
API
resource
selection
mechanism
and
authenticated
and
authorized
itself,
this
session
is
marked,
as
done
so
to
say,
and
we
get
a
success
on
the
cube,
cuddle,
yeah
client
side
for
those
who
are
a
little
bit
into
oauth.
The
one
interesting
concept
that
was
introduced
here
as
a
inside
the
proposal
is
the
concept
of
a
so-called
prudentialed
client.
E
If
anybody
is
following
the
oauth
2.1
spec,
there
is
a
new
type
of
client
that
I
took
inspiration
from
that.
Is
you
know
those
clients
on
our
public
lines?
They
are
not
confidential
clients
they
are
somewhere
sitting
in
between
that
is.
The
client
is
not
registered
our
priori
on
the
provider
side,
because
we
want
to
be
able
that
anyone
binds
to
us,
but
we
have
to
make
sure
that
you
know
if
one
client
create
a
decision
in
the
first
place.
You
know
not.
E
Another
client
can
just
piggyback
on
that
session,
and
that
is,
you
know,
done
using
a
simple
secret
mechanism
where
a
femoris
liquid
is
created
on
the
provider
side
and
then
all
the
requests
towards
the
provider
are
Edge
make
signed
such
that
you
know,
we
can
make
sure
that
the
requests
are
originating
from
the
same
client.
E
If
you're
interested
in
this
kind
of
jazz,
please
don't
hesitate
to
review
the
pr
that
is
on
the
coupon
side,
a
thing
that
I'm
proposing
there
is
I
created
a
docs
subdirectory
with
a
proposal.
Subdirectory
I
took
inspiration
a
little
bit
from
the
Thanos
project,
where
I
was
also
active
in
the
past,
where
I
was
created.
E
A
proposal
like
this,
so
what
I'm
just
telling
you
here
you
know
via
audio,
is
like
a
little
bit
in
more
detail
described
in
this
whole
proposal
here,
including
you,
know,
struts
and
stuff
like
this.
If
you're
interested,
please
take
a
look
and
again,
this
is
the
first
step
to
sort
of
like
make
coupon
fit
for
a
real
production
case
and
the
other
steps
will
be
to
have
kcp
at
the
back
end
and
also
things
like
permission,
claims
and
other
interesting
bits,
so
stay
tuned
for
further
updates.
Alec.
G
Yeah,
maybe
you're
doing
this
already
I
was
curious
if
you
considered
for
acute
bind
flow
with
the
provider
like
literally
just
using
oauth
oidc
yeah.
G
Say
that
is
because,
if
you
did
that
then
you'd
sort
of
have
a
kind
of
existing
threat
models
and
kind
of
buy
the
book
protections,
you
could
use
State
parameter
Pixi,
yada,
yada.
E
I
mean
we
are
not,
we
are
not
outside
of
oauth.
We
still
have
a
regular
overflow,
obviously,
on
the
provider
side.
G
E
Yes,
exactly
right,
like
we
have
a
little
like
I've,
been
experimenting,
a
lot
of
with
the
device
flow
that
was
introduced
by
all
off,
because
the
command
line,
Cube
cuddle,
binary,
obviously
there's
a
thing
that
is
or
will
be
invoked
on
remote
machines,
so
like
a
semantic
or
device
flow,
makes
kind
of
sense,
but
the
device
flow
was
sort
of
like
a
show
stopper,
because
the
device
flow
will
not
enable
us
a
user-friendly
way
of
taking
resources
in
a
browser
and
have
a
guided
selection
mechanism.
E
You
you
have
to
you,
have
sort
of
like
the
device
flow
authorization,
and
then
you
have
to
do
other
steps
on
the
command
line
binary
to
continue
sort
of
like
the
process.
Hence
the
idea
to
introduce
this
flow.
Having
said
that,
I'm
more
than
interested,
if
you
have
sort
of
like
ideas
or
brainstorms,
if
we
can
piggy
pack
on
the
device
flow
to
add,
you
know
other
interactive
UI
mechanisms
like
API
resource
selection
and
make
it
a
first
class.
G
Yeah,
it's
more
like
I
mean
if
you
squint
oauth,
is
really
a
communication
framework
between
three
parties
right
and
getting
yeah
and
that's
a
particular
privacy
properties
of.
H
G
E
You're
completely
right
and
I
was
very
hesitant
at
myself,
initially
so
I
just
squeezed
out
that
part.
That
is
interesting
for
us,
namely
sort
of
like
the
credentialed
client
semantics,
which,
by
the
way,
is
not
part
of
the
oauth
spec.
Yet
it's
going
to
be
like
in
the
successor,
2.1
and
that's
exactly
sort
of
like
the
thing
that
we
leave
here,
anyways
enough
of
oauth
authorization
talks.
That's
the
thing
that
I
wanted
to
present
again,
don't
hesitate
to
have
a
look
at
this
proposal
and
and
I'm
also
curious.
E
If
you
like
that,
like
process
itself
of
submitting
The
Proposal
here
and
once
it
is
submitted,
it
will
be
part
of
the
docs
subdirectory,
and
you
know
we
won't
have
the
problem
of
you
know
submit
having
lack
of
documentation
so
to
say:
that's
it
for
my
side,
any
more
questions
that
was
a
good
one.
Thanks,
I,
like.
A
Very
cool,
thank
you,
sergius
yeah.
If
folks
have
comments,
please
feel
free
to
add
them,
and
let
me
get
my
thingy
shared.
A
Me
just
a
second
there
we
go
all
right,
Steve,
you
are
up
next
with
cross
workspace,
identity
and
permissions.
H
Yes,
this
is
not
a
fully
hatched
topic,
but
I
just
wanted
to
make
a
comment
here
and
and
get
feedback
and
thoughts
from
other
people.
H
So
I've
been
poking
around
recently
in
this
workspaces
as
a
service
concept,
and
we
have
I
noticed.
We
have
a
couple
couple
spots
in
the
current
code
base
where
we
do
implicit
things
around
permissions,
because
we
have
one
cross
workspace
permission.
That's
to
bind
an
API
export
and
I.
Don't
know
that
as
a
project
we've
really
considered
whether
or
not
we
will
have
more
cross
workspace
permissions,
perhaps
David.
Actually
you
I,
don't
know.
If
there
is
one
on
the
do.
H
You
need
permissions
to
bind
to
a
sync
Target
I,
don't
know,
but
whenever
you
get
into
this
cross
workspace
thing
a
lot
of
other
functionality.
We
have
starts
to
break
down
so,
for
instance,
in
workspace
initialization
we
impersonate
the
owner
of
the
workspace
in
order
to
make
sure
that
we
can
only
initialize
it
to
a
state
that
you
could
have
otherwise
gotten
yourself
into
same
thing
with
permission
claims
on
API
exports.
H
You
know
we
had
this
bug
many
months
ago,
where,
if
you,
if
you
give
somebody
the
permission
to
bind
new
exports
in
your
workspace,
we
need
to
make
sure
that
the
ones
that
you're
binding
are
only
ones
that
you
could
have
been
bound.
You
know,
I,
think
our
approach
here
is
pretty
ad
hoc,
so
I'd
like
to
think
a
little
bit
more
clearly
about
this.
H
If
anyone
has
thoughts
on
Cross
workspace
permissions
that
they'd
like
to
see
or
systems
that
they
were
trying
to
build
that
require
cross
workspace,
permissions
I
think
that
helps
to
answer
some
questions
of
how
common
is
this
type
of
pattern
and
whether
or
not
we
need
this
to
be
something
that
end
users
of
the
system
are
also
configuring
or
if
it's
just
a
system,
specific
thing:
yeah,
I'd
love,
if
you
have
you
know
comments
here,
hit
me
on
Facebook
either.
One
I'd
love
to
hear.
E
Yeah
generally
I
I,
totally
agree.
Steve
I
think
we
have
at
least
two
precedences
now
the
first
one
is
the
API
binding
use
case.
Were
we
currently
impersonate
using
a
deep
SAR
request,
and
there
is
this
problem
that
we
solved
in
the
past,
where
we
need
to
somehow
present
ourselves
in
front
of
the
workspace
that
is
exposing
an
API
export
that
is
being
claimed
by
another
API
export.
So
we
have
ex
by
another
API
export.
E
So
we
have
effectively
two
workspace
hubs
and
the
user
that
is
executing
the
actual
binding
is
impersonated
and
is
then
anonymized
in
front
of
the
workspace.
That
is
exposing
a
claimed
API
export
right
and
that's
that's
sort
of
like,
like
even
like
a
multi-hop
use
case.
We
have
another
use
case
of
multicross
workspace,
authorization
and
Orbach
that
was
presented
recently
as
part
of
the
I
believe
API
lifecycle
initiative,
where
we
have
a
very
similar
topic
and
I
think
and
I.
E
E
The
bind
verb
on
your
API
exports
such
that
they
can
be
consumed
if
anybody
claims
an
API
binding,
and
that
is
a
very
you
know,
broad
permission
that
you
have
to
give
so
I
would
love
to
see
that
we
progress
on
making
a
solution
that
you
know.
Let
you
narrow
down
the
permission
to
only
those
users
or
service
accounts
that
are
really
interested
in
The,
Binding
right
and
also
solve
other
use.
E
Cases
like
the
API,
like
a
problem,
so
sorry
that
I
diverged,
but
I
just
wanted
to
mention
that
this
is
quite
a
complex
topic
and
I
would
like
to
have
a
unified
solution.
If
that's
possible.
Yes,.
A
E
H
H
Maybe,
sir,
you
and
I
can
work
on
jutting
this
down
and
we'll
post
it
as
a
discussion,
probably
or
something
and
I'd
love
to
hear
other
other.
E
Yes,
there's
even
a
second
documentation
which
I
created
previously
as
well
that
specifically
talks
about
API
bindings.
But,
yes,
we
can
reference
both
talks
and
I
totally
I.
Think
it's
a
great
idea
in
here
I
think
we
should
have
a
Consolidated
talk
that
references
all
the
use
cases
that
we
have
in
mind
and
tries
to
come
up
with
a
consulate.
A
Consolidated
Solutions
sounds.
H
And
do
you
have
one
other
thing,
yeah
just
yeah,
just
to
make
the
call
to
action
like
clear.
So
if
you're
listening
in
and
you're
trying
to
build
a
system
where
either
you
have,
you
have
a
cross
workspace
permission
connection
so
I
give
you
rights
to
do
something
in
my
workspace
or
if
you're
thinking
about
one
of
these
systems,
where
you
delegate
permissions
to
somebody
else
across
the
workspace
boundary.
Those
are
the
sorts
of
things
we'd
love
to
hear
about.
A
Next
up
Nolan,
you
added
a
oops
wrong
key
there.
We
go
a
call
for
feature
requests
for
release
0.12,
so
we
do
have
this
discussion
that
is
linked,
and
so,
if
there's
anything
in
particular
that
you
would
like
to
see
in
the
next
release,
please
add
comments
here.
A
If
you
look
at
the
Milestone,
it
purposefully
only
has
one
thing
in
it
because
we're
currently
working
on
that-
and
we
didn't
want
to
just
keep
punting
things
from
one
Milestone
to
the
next,
so
we're
trying
to
collect
ideas
and
then
we'll
come
back
either
async
or
in
future
meetings
or
both
and
start
to
put
things
into
the
milestone.
David
go
ahead.
I
Yes,
it
was
just
about
to
mention
the
question
of
saying
absent:
cable
resources,
the
so
what
was
mentioned
here
was
two
weeks
ago.
I'm
wondering
whether
it's
still
a
request
to
have
that
in
the
next
zero
to
twelve,
since
it
seems
that
the
priority
or
the
requirement
for
this
has
has
decreased.
So
maybe
it's
a
question
for
Paulo
or
Andy
or.
B
A
That
question
thanks:
Mike
go
ahead.
D
D
I'd
like
to
be
able
to
pick
up
work,
that's
been
done
since
0.11
ASAP,
you
know
I
I,
don't
want
to
I.
Don't
really
need
to
wait
for
anything
more
than
the
rebase
and
even
I
could
even
make
some
use
of
Works
before
the
rebase.
A
Okay,
did
you
have
specific
things
that
have
gone
into
the
main
branch
since
0.11
that
you're.
D
Looking
yeah,
there
was
a
bug
we
were
stressing
over
around
that
time
concerning
logic,
cluster
name
versus
path
and.
D
D
D
F
A
Okay,
all
right!
Well,
this
is
just
a
general
call.
If
you
all
have
comments,
please
add
them
to
this
discussion
and
I,
don't
see
anything
else
for
the
agenda
today.
Anybody
have
any
last
minute
topics
you'd
like
to
discuss:
William.
A
Just
need
to
review
I
I
didn't
realize
you
had
a
PR
until
we
talked
earlier
today,
so
I
think
I'm,
probably
not
following
the
repo
and
didn't
get
a
notice
or
something
so
yeah.
We
can
just
merge
the
pr
and
then
continue
to
add
more
as
new
stuff.
A
All
right
well
give
you
all
half
an
hour
back
so
good
to
see
everybody
thanks
for
the
new
folks
showing
up
Paul.
Did
you
have
a
comment,
or
were
you
trying
to
sign
off
yep
wrong
button?
Sorry,
all
right!
Thanks
for
joining
everybody,
see
you
next
time.