►
From YouTube: Community Meeting January 18, 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,
18
2022.
This
is
the
kcp
community
meeting.
Let
me
go
ahead
and
post
a
link
to
this
agenda
into
the
meeting
chat.
Please
feel
free
to
add
any
items
that
you
might
want
to
discuss,
given
that
I
did
just
create
this
issue
for
the
agenda
for
the
meeting
for
today
a
few
seconds
ago.
There's
nothing
yet,
but
I
guess,
if
anybody
has
any
topics
they'd
like
to
discuss,
please
let
me
know
or
just
start
talking.
A
If
not
one
thing
I
would
like
to
look
at
today
is
prototype
2
and
where
things
stand
with
the
open
issues
in
that
milestone,
but
before
we
do
that,
does
anybody
have
anything
they'd
like
to
discuss.
A
All
right:
well,
I
will
jump
into
looking
at
the
milestone
for
starters.
So
if
you've
got
any
ideas
for
discussions
feel
free
to
think
up,
so
I
am
going
to
go.
A
I
don't
know
we'll
go
top
to
bottom
here,
so
I
think
last
time
jason
had
said
that
he
wasn't
sure
if
we
were
going
to
need
this,
I
don't
believe
he's
available
today.
B
A
Yeah,
so
this
one's
also
assigned
to
json
I'm
going
to
skip
over
it
for
now
transparent,
multi-cluster,
p-cluster
health
checks
with
nobody
assigned.
C
A
All
right,
so
I
can
touch
base
with
him
offline,
transparent,
multi-cluster,
logical,
physical
cluster
namespaces.
This
is
all
are
also
json,
so
see.
User
can
add
a
second
location
deployed
at
moves
and
ingress
follows.
A
Okay,
this
one's
me
and
I
had
an
action
item
to
close
this
out
from
last
time,
and
I
did
not
so
I
will
follow
up
with
that,
because
I
think
pretty
much
most
of
this
or
all
of
this
is
done.
C
Yeah
we
we
had
a
sync
meeting
david
said
he's
on
it.
We
clarified,
so
it's
on
its
way.
D
A
Okay,
so
you
think
we
can
have
something
to
demo
next
week.
Do
you
think
we'll
be
able
to
have
it
either
done
well,
basically
done
by
the
end
of
the
month.
A
Okay,
multi-location
ingress.
This
is
also
joakim.
E
Yeah,
so
this
one
is
is
moving
forward
as
well
as
you
saw,
probably
in
the
in
the
demo
I
shared
last
thursday,
I
implemented
the
cubeconfig
subresource
on
the
personal
workspaces
virtual
workspace.
E
So
now
I'm
working
on
the
missing
part,
which
is
the
cubects
login
that
would
use
the
the
personal
workspace
here
to
our
workspace
and
also
the
config
sub
resource,
to
be
able
to
very
easily
switch
between
workspaces
and
then
be.
You
know,
be
able
to
integrate
that
with
standard
cube,
ctl
quite
transparently,
mainly
what
we
have
in
the
at
the
end,
something
along
the
lines
of
what
we
have
at
the
end
of
the
you
know,
exploration
document
where
the
workspaces
live.
E
Where
you
see
you
know,
cube,
ctl
workspace
use,
and
then
you,
you
directly
when
you
do
cube
ctl
get
any
object.
You
are
in
the
right
workspace,
so
awesome,
that's
where
sorry
that's
where
we
had
to
to
also
sync
with
searches
precisely
so
that
when
you
switch
to
a
given
workspace
with
the
cube
ctl
plugin,
then
the
airbag
that
is
applied
on
the
kcp
side
on
the
short
side
would
follow
the
same
rules
as
the
list
of
workspaces.
You
have
access
from
the
personal
workspace
endpoint.
A
That's
awesome:
could
you
please,
when
you
have
a
moment,
just
update
yeah,
what's
in
here,
for
what
we
plan
to
do
and
then,
in
terms
of
the
objectives,
are
these
all
still
relevant
and
applicable?
You
can
do
it
either
now
or
async,
but
I
I
would.
I
just
want
to
make
sure
that,
like
basically
when,
when
you
think
you're
done
with
the
code
that
it
matches
what's
in
here
or
we,
we
change
what's
in
here,
to
match
what
we
actually
are
kind.
C
E
E
B
E
That's
a
good
rip
it
apart
change
it
whatever
you
need
to
yeah
yeah.
I
I'll
comment
it
in
any
way
to
add
an
example
of
what
we
plan
to
have
as
common
lines.
Online
flow.
A
Okay,
so
I
will
check
in
with
joakim
and
jason
async
on
their
issues
and
I
think
we're
trending
in
the
right
direction
here.
So
thanks
everybody,
any
other
comments
or
discussion
on
prototype
2.
A
All
right
so
coming
back
to
the
agenda
page,
thank
you
again,
paul
for
putting
in
the
link
to
this
doc
here,
if
you
all
haven't
seen
it
before
it's
this
kcp
work
packages,
dock,
and
so
this
is
what
we're
looking
at
for
tentative
plans
for
prototype
three.
A
Should
we
walk
or
talk
through
them
right
now?
Would
that
be
a
good
use
of
time.
A
Yeah,
let's
do
it
all
right,
so
I'll,
just
read
off:
what's
here
from
a
demo
perspective
user
begins
journey
with
a
kcp
url
of
a
hosted
kcp
instance,
you
install
the
kcp
plugin
for
control
using
crew.
You
then
log
into
your
cluster
using
that
plugin
and
you
use
some
sort
of
oidc
authentication
such
as
github.
A
C
C
G
I
mean
so
like
maybe
let's
take
a
step
back.
Is
prototype
2,
going
to
be
able
to
move
an
application
across
a
stateless
application
across
locations?
A
H
G
C
C
So
we
have
in
the
document
that
joakim
started.
We
have
this
location
discussion
which
is
pretty
new,
and
I
I
doubt
we
we
have
that.
G
C
G
That
may
actually
be
a
better
prototype
three
target
I
mean
like
thematically.
It
might
actually
be
useful
to
write
a
theme
up
above
the
demo,
which
is
what's
the
actual
purpose
like
if
prototype
2
is
showing
the
api,
or
you
know
the
basic
api
or
multi-cluster
application
failure,
and
we
we
have
some
of
those
themes,
just
something
that
captures
the
overall,
probably
it'd,
be
pretty
obvious.
That
prototype
3
is
should
be
a
logical
continuation
of
prototype
2
anyway.
G
So
that
may
be
one
experience
wise,
and
maybe
this
is
like,
as
we
kind
of
get
some
of
these
scratched
out
going
back
and
reviewing
them
in
the
context
of.
Does
prototype
two
show
the
potential
and
just
someone
who
looks
at
that
and
you
walk
through
and
you
get
feedback.
Does
that
person
react
to
that
and
say?
Oh,
this
actually
showed
me
this.
G
That
may
be
another
set
of
inputs
for
the
prototype
3
demo,
which
would
be
the
things
that
we
show
someone
and
they
don't
get
it
or
they
don't
feel
that
it
shows
off
the
story
as
as
well
as
possible,
so
we're
finding
it
in
terms
of
maximum
impact
to
proving
the
point
which
was
a
prototype.
The
prototypes
have
that
goal
of
making
the
experience
clear
and
showing
the
possibilities,
without
necessarily
having
to
have
all
the
technical
details
completely
solved,
such
as
the
api
design
or
the
you
know.
The
full
capacity
for
movement,
for
instance,.
I
Yeah,
my
thought
is:
if
we
don't
move
on
stateful
workloads
like
in
the
prototype
3
stage,
we're
not
proving
anything
to
anyone
about
why
this
is
cool
like
from
a
real
running
real
apps
perspective.
I
think,
like
the
api
management
stuff
from
prototype.
2
is
interesting,
of
course,
but
does
anybody
feel
that
way
too?
Like
I
know,
stateless
is
easy,
but
we're
saying
oh
you're
gonna
get
ingress
that'll
move
around
and
then
you
can
deploy
stateless
workloads
and
have
no
disruption
like
that
is
not
exciting
to
me
at
all.
C
G
The
virtual
is
a
a
little
bit
of
the
virtualization
of
workspaces
and
a
little
bit
of
the
api,
and
we
hit
that
target.
Then
prototype
3
needs
to
really
catch
that
third
leg
of
showing
the
promise
of
transparent
multi-cluster,
and
maybe
it
doesn't
fully
require
stateful,
but
it
should
capture
the
the
the
promise.
It
doesn't
mean
that
those
other
things
don't
need
to
be
continued
to
be
refined,
but
it's
defined.
You
know
like.
We
need
to
actually
commit
a
significant
chunk
of
resources
to
hitting
that
bar,
but
I
would
probably
agree.
G
Thing
I
mean:
maybe
it's
the
do.
We
need
to
demonstrate
shard
movement
in
prototype
three
to
convince
someone
that
this
is
worth
doing.
Arguably-
and
I
think
this
is
rob's
point
is
demonstrating
the
core
of
transparent
multi-cluster,
which
is
stateless
and
some
element
of
stateful
that
you
can
read
and
believe
that
it
works
for
state
state.
Full
is
actually
the
thing
that
will
make.
G
All
of
this
useful,
like
a
generic
api
system
for
installing
global
apis
is
cool,
but
anybody
could
go
do
that
today,
there's
plenty
of
them
out
there
there's
a
thousand
startups
doing.
You
know
I
can
take
a
database
and
get
to
crud,
apps
and
websites
quickly.
G
The
the
key
innovation
here
is
we're
connecting
that
to
the
existing
workload
footprints
of
existing
kubernetes
users,
who
have
this
problem
today
and
by,
and
we
will
show
that
arc
from
what
they're
doing
today
to
this
new
system.
So
all
that
other
stuff
exists
to
support
transparent
multi-cluster
as
the
bridge
from
the
old
to
the
new.
F
G
G
But
that's
not
who,
but
I
guess,
maybe
that
that's
what
I
think
we're
kind
of
robin
are
kind
of
saying
in
a
roundabout
way,
which
is
a
way
to
build
a
control
plane
for
everything
is
a
super
cool
concept.
Prototype
2
showed
that
off
and
then
there's
a
there's.
A
ramp
down
period
like
prototype
2
should
show
that
if
we
don't
quite
show
that
in
prototype
2
or
we
take
feedback,
we
need
to.
G
G
G
2
covers
showing
the
potential
of
workspace,
virtualization
and
api
virtualization
finish
those
off
round
those
off
smooth
out
the
experience
based
on
the
things
that
we
did
in
two
and
then
lead
into
the
hit
that
core
of
showing
that
a
workload
can
live
on
a
cluster
but
not
be
bound
to
the
fate
of
that
cluster,
and
that
includes
stateless
and
stateful,
and
maybe
the
stateful
part
we
just
we
do
the
bare
minimum
there.
Perhaps
we
don't
need
persistent
volumes
and
that's
an
open
question.
We
can
work
through
those
questions.
G
So
maybe
maybe
that's
the
the
comment
on
cert
manager
does
hit
one
part
of
the
transparent
multi-cluster,
but
it
hits
the
it
hits
kind
of
a
it's
a
step
up,
and
then
you
gotta
show
the
meat
of
the
argument
so
you're
kind
of
making
the
leading
arguments
for
you
know.
You
start
with
the
idea
that
all
these
people
have
all
these
applications
that
can
live
together
and
then
you're,
showing
there's
real
benefits
for
the
high
level
constructs
in
those
applications
that
can
apply
in
multiple
clusters
and
the
certain
android
stuff.
Does
that?
G
And
then
you
lead
with
the
core
premise
of
your
argument,
which
is
an
application?
Isn't
just
those
high
level
concerns
it's
the
real
meat
of
a
workload
and
the
cube
workload
is
what's
being
targeted
and
you
can
see
this
demo
that
shows
off.
You
know
as
much
of
a
percent
of
that,
as
we
can
hit
to
establish
that
this
is
something
real
and
meaningful
that
benefits
all
cube.
Users.
I
C
G
Yeah
and
I'd
probably
say
like,
I
think
it's
important
I
would
probably,
if,
in
a
time-boxed
fashion,
showing
the
core
idea
of
movement
and
something
that
resembles
what
we
think
is
a
reasonable
technical
approach
like
and
reasonable
technical
approach
means
we're,
taking
the
first
stab
at
it,
showing
the
actual
movement
and
being
able
to
critique
the
actual
movement
is
far
more
important
than
the
act
of
registering,
in
the
assumption
that
the
vast
majority
of
users
will
never
go
through
that
ad
flow.
It's
not
that
it's
not
important
to
show
it's.
G
It
can
build
into
this
sequence,
but
if
we
spend
most
more
of
our
time
on
that
than
we
do
on
the
show,
then
the
end
result
to
an
end
user
is
cool.
I
can
add
clusters
to
a
multi-cluster
manager.
I
can
do
that
700
places
today,
like
what's
our,
what
is
the
unique
value
thing
that
kcp
ads
virtualization
api
flexibility
and
your
real
existing
cube
workloads
can
fit
in
this
larger
system.
G
Now,
maybe
that
another
question
then
to
ask
is
who,
after
prototype
three,
will
be
able
to
make
progress?
That
wouldn't
be
so
like
that's
kind
of
the
there's.
Some
implica,
like
some
of
the
stuff
here,
is
implications
that
lead
to
other
groups
being
able
to
try
these
ideas,
groups,
people
teams,
community
members
being
able
to
try
out
some
of
these
ideas,
some
of
them
in
so
that
they
have
their
own
dependencies.
So
they
can
go
say
like
hey.
I
tried
to
do
api
registration.
G
It
didn't
work
for
like,
for
instance,
like
app
studio
type
folks
who's,
the
user
that
we're
trying
to
make
happy
for
the
workload
side
who
needs
the
workload
stuff
to
be
in
at
least
a
basic
form.
So
they
can
try.
It
is
that
again,
maybe
like
blend
service,
like
somebody
building,
you
know
the
techno
pipeline
service
is
that
another
type
of
construct
such
as
somebody
who
could
show
off
like
a
fleet
management
right
running
mostly
homogeneous
workloads.
Is
it
the
end
user
for
a
sandbox,
trial,
kind
of
user.
A
Do
we
also
want
to
show
that
or
like
that's?
What
clayton
you
and
rob
were
saying
is
like
not
the
sort
of
thing
the
user
cares
about.
So
from
a
demo
perspective,.
G
So
it's
kind
of
one
of
those
things
that
requires
a
fair
amount
of
prep
work,
so
showing
some
meaningful
incremental
progress
is
useful.
I
guess
another
question
would
be.
Are
there
other
aspects
like
ultimately
sharding
is
there
to
deal
with
the
scale
characteristics
of
running
a
service
and
the
failure
resiliency
of
this
control
plane?
Are
there
other
aspects
of
control,
plane,
resiliency
that
we
would
need
to
demonstrate
that
maybe
are
different
from
the
sharding
stuff?
G
I
don't
know
like
I
like
kind
of
continuing
the
starting
stuff
to
where
we
know
whether
the
sharding
stuff
is
going
to
work.
Do
we
have
to
show
it
if
we
believe
that
it
works
versus
showing
something
more
compelling,
and
maybe
steve
like
I
mean
it's
also
like
it
just
seems
like
not
a.
F
F
G
Maybe
maybe
that's
getting
into
so
like
steve,
you
could
maybe
argue
that
what
you
described
is
we're
we're
focusing
here
on
virtualizing
teams
that
was
kind
of
prototype
one
and
two
and
virtualizing
teams
involves
workspaces
and
apis.
Now
we're
looking
at
virtualizing
the
physical
place
that
workloads
run
is
prototype
three
and
the
elements
of
it
lead
into.
You
know
if
you're,
if
you
don't.
G
G
Therefore
the
fourth
demo
or
fifth
them-
or
you
know
like
the
chain
of
reasoning
there
would
be.
I
want
to
show
operationally
that
the
control
plane
is
not
just
the
trivial.
I
can
write
a
bash
loop
that
runs
my
entire
company
like
because
that's
what
get
ups
can
do
today,
but
instead
we're
offering
something
new
which
allows
us
to
isolate,
separate
scale,
break
the
the
control
plane
problem
up
into
chunks
that
offer
defense
and
depth
or
resiliency
or
look
locatability
make
up
some
property
names.
So
that
could
be
that.
G
G
And-
and
there
may
be
an
argument
too,
which
is
if
all
of
the
use
cases
in
your
term
focus
more
on,
could
you
actually
go
run,
which
we
have
today
just
showing
two
of
those
key
concepts:
virtualizing
teams
and
locations?
G
It
can
take
a
little
longer
to
talk
about
the
virtualization
and
defense
in
depth
as
long
as
we're
making
progress,
perhaps
there's
another
set
of
things,
which
is
what
are
the
more
pragmatic
implications
of
the
the
basic
I
can
run
this
today
and
it's
it's
useful
and
resilient
enough
that
it
accomplishes
its
purpose
like
the
security
integration
or
you
know,
authorization,
etc.
We
can
make
some
arguments
around
those
elements,
the
the
realness
of
it
as
a
consumable
unit
for
someone
who
wants
to
get
those
first,
two
benefits.
I
C
C
F
G
It
is
to
establish
a
higher
better
value
in
the
term
until
people
accept
that
it's
higher
until
people
believe
that
it
has
no
value
right,
like
it'll
teach
us
things
but
other
we
could
have
done
all
these
things
individually
and
taught
us
it's
the
the
synthesis
of
those
three
goals
that
actually
makes
it
more
than
the
sum
of
its
parts,
and
so,
in
a
sense,
the
what
the
prototypes
are
trying
to
get
to
is
to
show
that
these
systems
work
together
or
that
these
systems
or
think
close
analogs
to
them
work
together
to
establish
the
value
proposition
once
you've
established
the
value
proposition,
you
have
a
whole
bunch
of
other
things
that
you
need
to
do,
which
are
just
the
very
iterative
like
keeping
going.
G
It
doesn't
mean
that
each
prototype
should
only
work
on
the
thing
that
shows
the
value
proposition,
but
it
does
put
a
very
large
weight
on
the
the
prototypes
are
supposed
to
be
thumps
that,
like
set
a
foundation
in
place
after
which
people
are
like
yeah
yeah
yeah,
I
get
it.
You
don't
need
to
explain
it
to
me.
I
can
see
it
or
you
know
we
go
and
refine
how
we
present
kcp
to
the
world
in
the
in
the
repo
project,
and
we
say
kcp
is
a
system
for
building
control
planes
over
kubernetes.
G
That
makes
it
super
easy
to
run
workloads
across
multiple
locations
and
lets
you
bring
in
and
extend
and
bring
together
all
the
elements
of
your
application
infrastructure
into
one
convenient
spot
for
tens
of
thousands
of
teams.
Like
that's
yeah,
we
want
to
get
that
value
proposition
and
be
like
and
then
run
the
demo,
the
demos
that
hit
the
thumps
versus
the
demos
that
show
the
other
pieces.
G
Once
we've
shown
the
thumps
or
once
we
have
those
like
those
those
big
once
you
have
those
pillars
set,
you
can
start
building
the
rest
of
the
house
and,
of
course,
while
you're
building
the
house,
you
know
you're
proving
out
this
idea.
You
do
need
those
other
elements
going.
So
I
might
say
maybe
there's
two
demos
or
there's
a
a
demo
and
then
a
a
sub
element,
and
maybe
we
just
we
have
one.
That's
the
focus
that
shows
kind
of
the
key
story.
G
We
don't
have
to
tie
all
of
the
elements
together
that
are
necessary
to
hit
the
next
thump.
So
I
I'm
a
little
I
don't
want
to.
I
want
charting
needs
to
make
enough
progress
that
we
understand,
but
we
also
may
want
to
spend
a
little
bit
more
time
on
showing
some
of
the
other
parts
of
the
ideas,
even
though
jumping
between
things
can
slow
us
down,
we
still
haven't
established
the
key
value
proposition
of
why
we're
doing
this
or
we
haven't
shown
it
we've
we
believe
in
it.
G
So
maybe,
like
another
f,
another
way
of
saying
that
was
like:
can
we
ruthlessly
go
through
the
demo
and
everything
that's
in
the
core
demo
has
to
have
a
reason
that
it
attaches
to
the
theme
to
make
people
believe
that
that
this
is
a
worthwhile
investment
and
the
stuff.
That's
that's
secondary
to
that
that
we
know
we'll
need
we
put
in
a
sub.
You
know
either
in
like
a
second
demo
or
we
hit
like
demonstrate
concept.
That's
that's
that
helps
establish
like
the
larger
framework,
but
stands
on
its
own.
G
Sharding
might
be
that,
but
I
just
I'd
like
to
see
a
demo
of
sharding,
but
I
don't
think,
as
steve
said,
a
user
doesn't
need
to
see
the
starting
demo
a
lot
of
the
underlying
virtualization
stuff.
Probably
they
don't
need
to
see
demos
of
all
of
the
underlying
stuff.
If
asked,
we
want
to
be
able
to
do
that
demo.
Maybe
that's
like
another
way
of
framing
it,
like
the
core
theme,
there's
deep
dive
elements
off
of
it
that
we
should
be
able
to
show.
I
A
Controllers
or
operators
and
have
them
act
on
the
entire.
You
know
across
organizations
across
workspaces,
which
I
guess
by
itself,
isn't
all
that
new,
because
you
know
without
workspaces
things
just
go
against
a
cluster
and
it's
fine.
So
I
think
this
is
more
of
a
scale
question,
but
I
I
do
think
it's
a
very
important
feature
and
one
of
the
main
things
that
interests
me
in
getting
kcp
successful.
So
I
would
like
to
highlight
it
whether
or
not
users
care
about
it.
F
G
Yeah,
the
operator
and
the
operator
is
really
a
detail,
so,
in
a
sense
like
this
is
kind
of
one
of
those
like
the
best
outcome
would
be
you
never
know.
What
provides
that
api?
That's
an
irrelevant
detail
to
you.
It
is
consumption
and
successful
and
we
can
go
peer
behind
the
covers,
but
like
we
don't
want
to
fetishize
the
operator
or
the
controller
is
literally
about
the
api,
and
that
is
actually
part
of
what
we
kind
of
said
is
cube,
sometimes
fixates
more
on
the
things
that
interact
with
the
system
than
the
api.
E
F
Right,
I
guess
it
sounds
like
we
have
at
least
like
three
of
these
right
like
so
we
have
like
the
like.
This
is
useful
to
a
user,
because
they're
thinking
about
apis,
this
is
useful
to
an
admin
because
of
this
resilience.
Movement
thing.
This
is
useful
to
like
a
kcp
admin.
Sorry,
and
then
this
is
useful
to
an
author
of
some
api
because
of
evolution
because
of
subscription
right
like
these
are
separate.
F
G
And
and
all
other
things
being
equal-
and
I
think
this
gets
into
like
how
deep
do
we
need
to
go
on
those
show
the
the
best
strongest
element
of
each
versus
showing
too
many
elements
of
each
so
like
api
evolution
is
a
deep
topic
late.
We
can
show
more
of
api
evolution
later
if
we're
reasonably
confident
that
what
we
show
now
has
the
necessary
foundation.
If
someone
asks
us,
oh,
but
you
didn't
think
about
abu
aka
evolution
of
like
aha
and
you
point
them
to
something.
G
But
if
you
labor
that
point,
you
lose
the
impact
of
what
we're
going
for,
which
is
consume.
As
steve
said,
I
think
steve
your
three
captured
it
pretty
well
consume
easily
a
real
benefit
of
the
virtualization
of
the
of
the
reel
and
then
the
the
person
providing
that
api
now
has
a
person
to
provide
that
api
to.
I
G
I
I
would
say
that
you
to
do
the
demo.
You
could
maybe
do
like
a
pan
and
zoom
style
with
starting
with
the
end
user
and
then
doing
a
pan
and
zoom,
but
I
think
it's
fairly
useful
to
split
them
up,
because
you
know
that
gives
us
an
opportunity
to
hang
additional
things
and
then
kick
those
additional
things
to
later.
Efforts
by
refining
each
demo
flow
to
the
key.
So
I
think
that's
pretty
useful.
I
All
right,
how
do
we
start
breaking
that
down,
I
mean:
do
we
want
to
do
that
here?
Do
we
want
to
do
that
offline.
A
Either
sign
with
me,
I
know.
A
David,
you
had
done
a
lot
of
work
on
the
negotiation
in
the
past,
so
if
you
are
willing
and
interested
maybe
take
a
stab,
it
doesn't
have
to
be
right
now,
of
course,
or
anybody
else
who
wants
to
try
and
come
up
with
a
an
outline
for
the
api.
A
All
right,
I
think
we
can
try
and
flush
some
of
this
out.
I
think,
and
unless
anybody
has
any
other
comments
on
what
we've
just
been
talking
about
I'll,
go
back
real,
quick
and
see
if
we've
got
anything
else
for
the
agenda.
C
G
Is
better
because
we
still
haven't
demonstrated
the
core
value
proposition
of
kcp,
which
is
if
things
in
the
demo
don't
show
the
core
value
proposition
of
moving
workloads?
Why
are
we
doing
them
and
if
we
need
to,
if
we
can
cut
and
accomplish
that
without
getting
in
depth,
that's
a
better
outcome.
Right,
like
until
transparent
multi-cluster
feels
transparent.
We
don't
really
have
a
bridge
to
justify
this
investment
and
it's
not
like
a
threat.
That's
like
a
like.
We
shouldn't
lose
sight
of
the
forest
for
the
trees.
G
C
G
Two
and
to
be
fair,
we're,
as
I
think,
as
you've
noticed
noted
early
on
stefan,
we
have
spent
a
lot
of
time
on
the
other
elements
we
did
the
early
design
for
transparent
multi-cluster.
We
have
the
dock
that
hopefully
ben
bennett
is
gonna,
is
cleaning
up
for
us,
which
is
the
set
of
workflow
things
that
we
just
expect
to
work.
Those
are
the
use
cases
that
establish
this
larger
theory.
G
A
little
bit
of
rotation
towards
that
and
accomplishing
that
goal
is
not
a
mistake
if
we
believe
we
have
enough
of
the
pieces
in
place
for
api
and
workspace
virtualization
to
keep
moving
to,
to
focus
and
rotate
a
little
bit
on
that.
While
we
gather
feedback
on
those
first
two
areas,
because
we
will
be
getting
feedback,
you
know
from
people
looking
at.
Oh
workspaces
and
apis
are
awesome.
G
Here's
new
use
case
x,
here's
here's
fix
y.
Oh,
we
can
put
that
in
place
pretty
quickly.
Can
you
tell
us
whether
you
think
you'd
use
this
independent?
Oh,
we
would
great
cool
while
we're
working
on
transparent,
multi-cluster.
A
Yeah
we
have
to
do
api
imports
and
exports,
which
would
replace
the
inheritance
that
I
did
for
workspaces.
A
C
G
Wanted
to
be
able
to
demo
on
the
side,
so
I
and
again,
last
year
we
touched
on
these
three
elements
we
touched
when
we
when
we
did
the
may
demo,
we
touched
on
the
three
elements
so
to
get.
If
we,
if
we
don't
believe,
we've
we've
evolved
and
added
some
new
ideas,
but
are
they
fundamentally
different
from
the
ideas
we
presented
last
year?
No,
so
then
it
would
be.
G
Can
you
show
in
convincing
detail
that
these
aren't
just
ideas
might
be
a
way
paul
of
framing
that
which
is
and
again
like
the
depth
of
the
idea?
I
know
this
is
like
everybody's
comfort
zone,
but,
like
you,
don't
have
to
write
down
or
do
everything
we
don't
have
to
have
it
all
be
working,
but
we
do
have
to
be
able
to
say
we're
confident
that
we
can
make
this
work
now
tell
us
whether
this
idea
works
for
you
by
trying
it.
If
you
can't
accomplish
those
like
try,
it
explain
it.
G
Try
it
or
explain
it
show
it.
Someone
can
try
it.
That's
the
bar
for
transparent
multi-cluster,
at
least,
and
some
of
this
could
be
like
if
we
spend
the
focus
and
we're
not
getting
there.
That's
an
input
to.
Perhaps
you
know
we're
looking
at
the
wrong
tree
or
we're.
You
know
we're
focused
on
the
wrong
part
of
the
problem,
so
that
may.
D
G
G
And
andy
maybe
like
to
correlate
with
that
exit
conditions
for
prototype
2.
when
prototype
2
goes
out.
Are
we
actually
is
anyone
actually
gathering
the
did
prototype
2
hit?
The
mark,
I
think,
is,
is
something
we
should
be
taking
into
account
as
we're
beginning
to
plan
for
prototype.
3
prototype
2
would
probably
be
the
first
formal
deliverable,
and
so
what
are
the?
What
are
the
expectations
from?
What
do
we
learn
from
it
and
how
does
that
influence?
What
we're
doing
next?
Are
we
iterating
on
the
virtualization,
like
what
feedback
do?
A
All
right
anything
else
come
in.
D
A
All
right
last
call
for
topics,
or
we
can
endearly.