►
From YouTube: Community Meeting, January 24, 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
January
24th,
not
25th.
Welcome
to
the
kcp
community
meeting
we
have
an
agenda
issue
in
GitHub
that
I'll
paste
in
chat.
If
you
are
interested
in
adding
anything
to
today's
discussion,
please
feel
free
and
I
see
that
we
do
have
some
discussions
that
were
deferred
from
the
last
meeting.
So
Nolan
do
you
want
to
maybe
recap
what
those
were.
B
Yeah
so
Mike
had
a
question
about
implementing
logical
clusters.
Upstream
I
know
there's
been
discussion
of
implementing
some
pieces
of
kcp
Upstream
that
weren't
really
accepted,
but
the
question
was:
if
we
could
get
the
logical
cluster
support
itself
implemented
Upstream.
Would
that
be
enough
for
kcp
to
maybe
not
have
a
fork?
And
then
Dan
was
asking.
C
Yeah,
that's.
The
answer
is
probably
mostly
so
a
yes,
but,
of
course,
logic,
clusters
is
a
big
ask
right:
it's
not
only
that
we
get
something
into
the
storage
layer.
It
also
means
that
we
have
to
touch
every
second
controller
and
these
are
generic
ones.
So
it's
a
pretty
big
ask
to
get
set
upstream
and.
A
There's
more,
we
also
have
changes
to
the
custom
resource
handling
that
maybe
we
could
make
some
changes,
that'd
be
palatable,
but
I
think
it
is
evolving
into
a
non-goal
to
try
and
get
all
this
code.
Upstream
like
we
can
work
with
the
fork.
Just
fine.
C
D
Yes,
so
the
question
part
of
the
question
here
is:
can
we
Factor
the
kcp
work?
You
know
if
we
only
get
the
Upstream
to
adopt
The
Logical
clusters,
not
workspaces,
not
API,
export
and
binding,
and
everything
else
just
The
Logical
clusters?
Yes,
that
does
involve
some
changing
clients.
D
Although
I
haven't
really
considered
how
smooth
and
easy
we
can
make
that
path.
You
know
I
I,
think
that
might
be
worth
discussing.
I
think
if
we
could
make.
Obviously
any
kind
of
change
Upstream
has
to
be
incremental.
D
So
if
we
could
come
up
with
an
actual
incremental
path
that
gets
to
logical
clusters,
I
know
it
has
been
discussed
upstreams
before
and
rejected,
but
the
the
idea
here
is,
although
they
reject
it,
other
people
keep
wanting
it.
You
know,
and
last
week
I
came
with
a
list
of
four
projects
or
use
cases,
TMC
edgemc,
Fabric
and
cross
plane.
That
all
would
benefit
from.
D
You
know
what
they
call
Upstream
super
namespaces,
so
yeah
I
think
we
could
conceivably
go
back
and
try
again
to
say
you
know
you
didn't
like
it
before,
but
now
that
there's
more
growing
uses
you
know,
maybe
we
can
actually,
you
know,
get
some
buy-in.
D
So
the
question
and
proposal
is
you
know:
could
we
go
with
a
proposal
to
get
just
to
Upstream
super
namespaces
or
logical
clusters?
You
know:
can
we
come
up
with
a
plan
for
incremental
making
that
move
incremental
and
if
so,
you
know,
would
that
make
it
so
that
kcp
did
not
need
to
maintain
a
fork
the
what
kcp
needed
could
be
done
externally
to
the
kubernetes
tree,
if
only
it
had
the
super,
namespaces
or
logical
clusters.
A
I
think
so
I
also
don't
have
concerns
maintaining
a
fork
like
that's,
not
a
problem.
So
we
anticipate
that
clients,
people
writing
code
against
kcp
with
multiple
like
multiple
workspace
aware
controllers
should
not
have
to
use
our
Fork
of
kubernetes
to
do
that,
and
that's
basically
the
the
Target
that
we're
aiming
at.
D
A
A
D
And
by
working
against
multiple
workspaces,
what
does
that
I
mean
we're
in
you
mean
work
in
a
workspace,
oblivious
way,
so
that
the
controller
in
some
sense
isn't
aware
of
workspaces?
No.
F
E
A
F
D
So
I
guess
the
the
real
motivation
was
I
was
trying
to
get
rid
of
the
fork
and
what
I'm
hearing
is
you
don't
feel
a
need
to
get
rid
of
the
fork
and
I
guess.
That's
that's
the
main
answer.
A
C
Yeah,
so
the
answers
we
got
were
pretty
dogmatic
and
we
don't
expect
space
for
logical
classes
if
the
adoption
changes
and
that's
what
you
describe.
Basically
that's
starting
to
change,
because
there
are
more
parkings
right,
cosplaying
and
Edge
and
so
on.
Maybe
this
has
in
impact
on
the
decision,
the
feedback
we
get.
That's
the
one
we
got.
It's
not.
D
Right
I
know
that
that
was
I
know
that
there
was
there's
negative
feedback.
My
question
was,
you
know,
as
you
say,
there's
increasing
demonstration
that
that
there
are
use
cases
for
super
namespaces
as
they
call
them.
So
my
question
was:
you
know
twofold.
You
know
in
part
if
we
got
the
super
new
spaces
part
adopted
upstream,
and
only
that
much
would
that
enable
getting
rid
of
the
fork.
A
D
A
That
would
allow
us
to
have
them
and
I
think
everybody
could
ultimately
be
happy,
but
it's
still
not
sufficient
to
get
rid
of
the
fork,
at
least
in
our
our
our
vision
or
what
we
expect.
So
we
will
do
that.
It'll.
Take
a
while,
we'll
see
what
happens,
but
getting
back
to
the
summary
of
of
my
take.
The
fork
is
not
a
problem.
D
Yeah,
it
wasn't
necessarily
going
short
term
I'm,
more
focused
on
the
long
term
and
I
think
we
already
know
that
if
we
propose
that
the
Upstream
maintain
a
generic
control
plane
that
can
do
super
name
spaces.
D
Already
asked
you
know
about
super
namespaces
right
and
the
answer
was
they
don't
see
enough
use
cases
to
justify
the
maintenance
cost
and
they
really
don't
want
to
take
on
anything
any
maintenance
cost
that
doesn't
benefit
the
kubernetes
project,
so
we
really
have
to
if
we
want
super
new
spaces,
even
in
a
generic
control,
plane
Library,
we
have
to
really.
You
know,
make
the
case
that
there
are
enough
compelling
use
cases.
A
Yeah
we'll
see
where
it
goes,
Ezra
you've
had
your
hand
up,
hey.
F
G
F
Oh
okay
and
looking
forward
to
anticipate
that
that
will
be
kind
of
a
regular
kind
of
yeah
process
right,
yeah.
A
B
F
C
It
gives
us
mostly
of
what
the
entry
is
to
do
for
what,
if,
of
course,
if
you
want
to
go,
the
direction
of
you
know:
custom
secondary
indexes
or
those
these
kind
of
things
or
no
more,
no
watch
cache,
we
need
entry,
but
entry
is
heavy
and
probably
at
the
moment,
not
superiority,
and
we
need
more
buy-in
Upstream
for
that.
I
think.
D
So
can
I
put
a
little
finer
point
on
that.
Have
we
asked
or
what
do
we
think
of
the
possibility
of
proposing
Upstream
a
refactoring
of
the
API
server
code
so
that
there
is
it's
you
know
today.
There
is
this
interface
internal
interface
that
Steve
took
advantage
of
we'll
refactor
to
really
expose
this
internal
interface.
That
looks
like
says:
there's
a
key
value
store
and
we're
just
going
to
use
a
key
value
store,
and
he
just
add
has
two
implementations
of
the
key
Value
Store
interface.
D
You
know
what
about
the
idea
of
a
another
refactoring
that
goes
higher
in
the
stack
in
the
API
server,
and
you
know
this.
This
interface
includes
stuff
like
the
functionality
of
the
watch,
cache
and
indexing,
and
so
on,
so
that
we
could
have
a
couple
of
implementations,
one
entry
and
one
out
of
tree
okay.
So
we
don't
have
to
sell
additional
maintenance
or
testing
Upstream,
but
we
can
maintain.
You
know
something
that
that
works
without
alternate
code.
D
It's
it's
without
a
big
without
any
more
alternative
than
necessary
right,
maintain
our
own
implementation
of
this
higher
level.
Internal
interface
for
us
for
storage.
A
I
mean
I
think
we
sh.
A
A
Okay,
is
it
all
right
to
move
on
to
the
next
topic?
A
Okay,
so
Andy,
you
are
asking
about
slack
channels,
yeah.
G
We
don't
want
to
pollute
the
Forum
kcp
with
our
PR
discussions
and
approval
requests
and
stuff
like
that.
So
we
were
thinking.
Maybe
since
the
the
regularity
of
that
type
of
thing
is
increasing
on
our
end,
we're
doing
it
more
or
less
in
a
vacuum
in
our
private
slack,
Channel
and
I
hesitate
to
put
all
that
information
into
form
kcp
because
it
would
be
I
think
a
bit
distracting.
So
I
thought
maybe
asking
and
approaching
the
assembled
Community
here
and
see.
A
G
A
A
Yeah
because
they
manage
them
in
in
git,
so
yeah
I
would
say,
I
think
that's
self-service
Andy.
If
you
need
help
finding
it.
Let
us
know
otherwise
we'll
just
assume
that
you're
on
your
way
there
thank.
G
D
No
I
I
think
I
can
explain
the
issue
here
and
it
gets
to
more
refactoring.
So
the
problem
is
to
use
API
exports
and
bindings.
We
need
to
use
this
tool
API
gen,
to
generate
the
API,
export
and
API
resource
schema
objects,
and
so
there's
some
other
project.
You
know
such
as
edgemc
or
some
other
code.
Repo
you
know
wants
to
use,
go
install.
D
You
know
you
would
think
you
could
use
go
install,
but
there
are
some
technical
requirements
that
go
install
and
you
know
it
boils
down
more
or
less
to
the
go.mod
or
the
thing
you
go.
Installing
can't
do
any
replace
directives,
that's
bad
news,
because
the
go.mod
did
kcp
has
lots
of
replace
directives.
So
we
can't
do
go
install
of
API
Jim
and
we
can't
even
do
it.
D
You
know
either
kind
of
like
an
independent
tool
or
in
the
context
of
the
edgemc's
go.mod.
Even
then
we
can't
do
a
go.
Install
of
API,
gen
I
think
that,
based
on
the
way
go
Works,
you
know,
I
see
only
a
few
kind
of
crummy
options.
One
is
edgemc
could
make
a
copy
of
the
API
gin
code
and
just
use
its
own
local
copy.
That's
a
really
crummy
option.
D
Another
one
is
the
the
make
file,
could
do
a
git
clone
of
kcp
and
build
the
API
gen
tool
and
use
that
that's
not
quite
as
bad.
It's
still
pretty
crummy
with
some
refactoring.
D
C
C
D
D
Looking
at
the
code,
it's
it's
just
one
main
file
and
in
terms
of
imports
you
know
the
bad
news
is
it
does
import
from
kcp
Dev,
which
I
think
means
that,
in
order
to
build
it's
go.mod
we'll
have
to
have
a
misdirective.
C
D
C
A
Sure
thing
and
then
we've
got
a
new
one
from
Lionel
I'll.
Let
you
describe
it
yes,.
I
So
so
here
is
use
case,
I'm
working
on
currently
right,
so
I.
It's
an
instance
of
a
general
use
case.
I
apply
this
to
a
Kafka.
So
as
a
service
provider,
I
have
a
bunch
of
Kafka
API
that
I
want
to
export
to
my
customers
and
when
my
customer
they
bind
to
my
API
or
service
I
want
to
generate
automatically
a
secret
for
them
right
so
that
they
can
access
the
the
Kafka
cluster.
That's.
E
I
Another
variation
of
this
use
case
is
I
want
to
create
first.
E
I
To
this
topic,
and
this
topic,
I
can
either
create
it
on
the
on
the
service
provider
side
or
on
the
customer
side
is
I,
don't
know
yet
for
that.
But
the
point
here
is
that
we
need
a
some
mechanism
to
be
able
to
create
some
objects
either.
H
I
It
a
bit
with
Stefan
so
I
understand
the
permission
claim
now
I
think
so,
which
is
about
permission.
So
that's
that's
going
to
help
so
I
guess.
The
question
is:
how
can
I
go
about
like
solving
this
problem
in
kcp.
I
The
first
question
is:
is
it
a
valid
use
case
for
HP
and
then
then
how
we
do
into
that.
A
To
have
it
generate
like
to
create
a
secret
when
The
Binding
is
set
up,
yeah.
D
You
know
Lionel
I,
wonder
if
you're
really
noticing
that
this
is
an
example
of
the
general
idea
of
a
little
more
General
concept
of
you
know,
creating
a
service
instance
and
I
wonder
if
this
is
something
we
should
ask
to
be
done
kind
of
at
the
user
level
rather
than
in
the
mechanism
right.
D
Could
you
design
it
so
that
that
you
have
an
explicit
object
that
says
this
is
a
service
option
instance
that
the
client
creates,
and
you
have
controller
that
reacts
to
that
service
instance
object
by
making
secrets,
and
in
general
you
know
whatever
else
is
needed
right.
So
if
there's
less
Demand
on
the
mechanism.
I
I
A
user
perspective,
the
only
thing
I
want
to
do
is
consumer
perspective
is
just
bind
to
a
service,
and
that's
it
right.
C
Yeah,
so
it's
a
valid
use
case
internally,
we
had
also
service
providers
who
wanted
that.
This
is
not
something
and
I
think
this
is
what
Mike
said.
It's
not
something
we
have
to
build
into
the
mechanism
like
into
the
core
apis.
C
This
can
be
built
as
another
controller
plus
CID
API
API
in
general
mechanism.
So
a
service
provider
will
create
an
object
describing
a
life
cycle
of
certain
objects.
Permission
claims
make
sure
that
the
controller
can
do
the
work,
and
this
could
be
built
just
as
an
add-on
on
kcp.
I
That
right,
okay,
sorry,
go.
E
Ahead,
sorry,
I
I
just
want
to
say
that
I
did
something
similar
for
so
there's
a
pipeline
service,
basically
you're
watching
API
binding
and
then
created
a
couple
of
resources
when
there's
a
stethoscope,
that's
on.
So,
if
you
want
my
temperature
as
a
code
resource,
it's
not
very
actual.
I
haven't
updated
a
few
months
now.
This
can
give
you
an
idea.
I
I
Yes,
yes,
but
maybe
like
it's
something
similar
to
the
concept
of
a
meta
controller
or
web
hook,
also
something.
B
C
Okay,
but
you
you
can
do
that
like
an
API
for
service
providers,
maybe
via
not
mature
service
accounts,
help
here,
but
we
don't
want
the
service
provider
to
write
something
it
must
be
generic
and
I
think
can
be
done.
I
I
can
I
can
take
a
look
at
all
these
right
and
prior
work
and
obviously
this
is
only
for
currently
I'm
describing
only
the
creation
part
of
it,
but
it's
the
whole.
You
know
life
cycle
management
of
these
secrets
and
these
subjects
what
happened
when
the
service
provider,
you
know
upgraded.
A
I
Of
things
right,
but
that's
that's
for
literary
okay,
go.
E
Yeah
I
just
want
to
see
that
you
could
use
also
something
that
I
like
to
build
to
generate
a
Discord
and
38.
It's
easy
to
use
for
any
service
provider.
Yeah.
I
But
again
yeah
100
sure,
because
this
is
skills
that
you
need
to
learn
so
yeah,
but
why
not
yeah
I
understand
this?
How
can
this
we
can
make
this
work
using
this
kind
of
Technology
test.
D
F
Okay,
yeah
I
I
didn't
have
some
sus
expression
to
this
I
think
it's
in,
because
I
encountered
that
on
completely
different
question,
not
related
to
initializer
or
service,
to
talk,
I
think
it's
a
general
trade-off.
We
have
here
where
we,
you
have
a
framework
and
on
the
other
hand
the
controllers
require
us
to
have
some.
F
You
know
real
cluster
running
workload,
cluster
running
something,
and
we
try
to
see
whether
we
can
push
more
and
more
stuff
into
the
framework
and
put
some
hooks
in
the
framework
that
will
allow
us
to
do
stuff
right
and
obviously,
on
the
other
hand,
you
want
to
maintain
the
framework.
As
you
know,
the
base
is
leaning,
so
that's
I
think
a
general
kind
of
trade-off
that
it's
delicate.
H
A
So
it
looked
like
we
had
a
link
that
Frederick
posted.
Is
this
the
example
that
you
were
talking
about.
F
A
It
is
okay,
so
final
check
this
out
and
I'd
say
if
you
have
questions
reach
out
to
Frederick,
and
if
you
want
to
have
further
discussions,
we're
always
on
slack-
and
we
can-
we
can
talk
about
this
next
week
if
you
need
to
as
well
thanks.
A
Okay,
here
we
are
so
that
was
the
last
one
in
here
before
I
go
on
to
issue
triage.
Does
anybody
have
any
last
minute
topics.
A
All
right
I'll
go,
find
it
hold
on
kcp,
jokes.
E
A
And
here
we
go
all
right,
so
the
first
one
is
asking
if
we
can
add
a
flag,
that's
like
dash,
n
or
dash
dash
namespace
to
be
able
to
switch
workspaces
on
the
Fly
using
Cube
control.
A
I,
don't
foresee
this
happening.
I
commented
that
we
could
maybe
have
some
sort
of
wrapper
around
Cube
control.
That
would
support
this,
but
given
that
we
can't
make
changes
to
keep
control
to
support
logical
clusters
or
workspaces,
I
think
the
the
only
options
here
are
either
to
close
this
as
we
can't
do
it
or
keep
it
open
to
see.
If
somebody
wanted
to
try
and
do
some
sort
of
wrapper
any
thoughts
from
the
community.
A
A
Okay,
I
know
that
this
update
controllers
to
use
the
committers
is
in
progress.
A
A
A
H
Yeah,
in
fact,
this
should
be
fixed
when
the
work
I
started
on
enabling
sharding
in
the
Sinker
and
then
in
the
deployment
controller.
Okay,.
A
You,
oh,
this
is
the
one
I
created
that
was
showed
up
next.
If
anybody
is
or
has
spare
time
and
would
like
to
investigate
any
flake
whatsoever,
I
will
gladly
donate
my
time
to
help
show
my
process
for
trying
to
figure
out
what's
going
on
when
something
is
flaking.
So
if
you're
interested
in
bug,
hunting
or
flake
hunting,
please
reach
out
to
me
or
anybody
else.
A
We
will
give
you
the
tools
and
knowledge
that
you
need
to
try
and
figure
this
stuff
out
and
and
getting
rid
of
these
flakes
helps
everybody
because
it
means
the
pull
requests,
get
merged
faster.
So
if
you
have
time
please
reach
out-
and
let
us
know,
yeah
I
will
take
this
one.
A
A
This
one
is
okay,
this
one
Lucas
are
you
working
on
this
like
I
know
we
have
some
stuff.
We
need
to
do
here,
or
is
this
just
next
or
backlog,
yeah.
A
And
we
just
talked
about
this
one
I'm
going
to
put
it
in
next
as
well.
If
folks
have
time
to
look
into
us
into
this,
that
would
be
awesome.
I
do
think
that
a
simple
go
mod
could
work.