►
From YouTube: 2021-05-11 Community Meeting
Description
Our first community meeting!
A
Is
recording
going
now,
I'm
gonna
make
sure
I
get
the
screen
share,
working,
okay,
okay!
So
maybe
that's
even.
B
C
Thank
you
very
much
for
your
herculean
effort,
everyone
in
just
getting
this
thing
recorded.
Hopefully,
next
week
we
will
not
have
such
an
issue.
Welcome
everyone
to
the
first
kcp
community
meeting.
I'm
super
excited
to
see
so
many
people
excited
to
be
able
to
talk
to
people
about
this.
We've
been
we've
been
sort
of
working
on
it
behind
the
scenes
for
a
little
while,
and
I
can
finally
tell
people
we're
working
on
this-
so
that's
that's.
You
know
very
exciting,
even
justin.
It's
on
its
face.
C
I
wanted
to
do
a
little
bit
of
housekeeping.
I
think
we
should
probably
have
this
meeting
every
week
for
now.
I
think
we
should
do
this
meeting
every
you
know
every
week
at
this
time
over
time
we
might
decide
to
move
it
up
or
back
or
different
days
or
whatever,
we'll
probably
try
to
record
them
better
than
we
have
done
this
week
in
future
weeks
and
one
last
imploring
to
go
to
the
agenda
doc
and
sign
yourselves
in
and
let
us
know
that
you
were
here.
C
D
Yeah,
I
was
going
to
add
one
note
jason
as
we
went
through
so
a
couple
of
folks
who
really
did
want
to
attend
this
week.
Can't
and
part
of
this
is
we
were
kind
of
discussing.
You
know
what
the
structure
of
this
was.
We
felt
like
you
know
it's
not
a
project,
it's
definitely
not
a
product,
it's
more
of
a
prototype.
We
wanted
to
catalyze
discussion,
and
not
all
discussions
should
happen
here.
They
should
happen
in
the
right
places.
D
We
wanted
to
be
a
focal
point,
but
not
a
blocking
function
and
then
so
one
of
the
things
I
was
just
saying
this
before
there's
a
cluster
api
meeting
at
one
office
hours
chris
signs
on
the
call
we
were
going
to
jump
over
to
that
and
talk
about
some
of
these
issues.
Would
it
be
interesting
for
v
cluster?
D
One
of
the
thoughts
I
had
would
be
a
lot
of
this
is
folks
who
are
interested
can
come
here,
but
then
part
of
what
jason
and
david
and
myself
and
others
who
want
to
do
is
like
kind
of
go
off
and
find
things
and
bring
them
back.
So
we
can
summarize
and
look
for
opportunities
to
engage,
so
it's
a.
I
don't
know
if
I
call
this
a
spiderweb
attempt
to
try
and
tie
together
efforts
in
the
ecosystem,
but
they
definitely
don't
all
live
here.
D
C
Project
yeah,
michael
yeah.
It's
definitely
it's
definitely
you'll
you'll
hear
the
word
experiment.
One
million
times
you'll
hear
the
word
prototype
one
million
times
the
slack
channel
is
called
kcp
prototype
specifically
because
we
don't
want
to
make
it
seem
like
it's
more
mature
than
it
is
it's
not
very
mature,
so
yeah
and.
B
I
would
that
you,
you
would
find
the
word
hack
in
a
number
of
places,
also
in
the
code,
especially
in
the
in
the
kubernetes
fork
that
has
been
started
for
to
to
to
support
those
prototype
work.
Yeah,
that's
important,
of
course,
yeah.
Sorry,
I
mean,
because
the
whole
point
is
is
to
hack
some
things
that
can
you
know
showcase
what
we
would
need
to
to
go
further
and
what
also
could
be
very
beneficial
to
other
parts
of
cuba
and
it's
on
the
go.
B
C
For
now
yeah
for
a
good
time
for
the
word
hack
in
in
that
repo,
because
there's
there's
some
awful
awful
things
that
go
on
there,
so
I
think
I
think
that
the
there's
a
good
area
in
the
docks
of
sort
of
what
we,
what
we
intend
to
investigate,
I
wanted
to
go
over
those
at
a
high
level
and
we
can
drill
in
if
anybody
has
more
thoughts,
questions
comments,
things
like
that.
C
Thank
you
clayton
for
writing
those
docs,
because
that's
super
helpful
to
like
sort
of
focus
us
on
what
the
areas
are.
In
summary,
they
are
well
at
a
high
level.
Kcp
is
this
like
minimal
api
server,
but
it
doesn't
really
deserve
to
exist
just
on
its
own,
like
the
way
I
think
about
it
is
that
kubernetes
already
works
for
so
many
people,
so
we
have
to
oh,
my
god,
more
people
in
the
waiting
room,
auto
etc
in
the
account
that
has
the
ability
to
join
other
people
from
the
waiting
room.
E
All
right
we're
back
and
now
I
can
have
people
join
anyway
for
those
of
you
for
those
of
you
who
have
just
joined
this
meeting
is
being
recorded
and
there's
not
a
record
button,
because
we're
kind
of
hacked
it
up,
because
we
have
trouble
recording
through
the
record
button
which
didn't
exist,
but
it's
being
recorded.
If
you
object,
put
up
your
hand
and
or
leave.
C
Yeah
these,
these
sorts
of
hacks
are
the
things
you
should
come
to
expect
from
those
numbers
anyway,
yeah
the
the
the
minimal
api
server
is
interesting
and
cool
and
fun,
but
on
its
own,
I
think,
is
not
enough
to
motivate
the
changes,
the
sort
of
changes
we
have
to
make
to
upstream
kubernetes.
So,
even
if
those
are
overall
improvements,
kubernetes
we
need
to.
We
need
something
to
overcome
the
the
activation
energy
of
being
able
to
change
such
a
large
and
important
thing.
C
So
the
inve,
the
areas
of
investigation
that
sort
of
help
us
motivate
these
changes
are
multi
or
transparent
multi-cluster.
The
the
demo
that
that
clayton
gave
in
his
poop
con
talk
was
her
inconnect
keynote
was
sort
of
a
demonstration
of
how
you
could
talk
to
a
kcp
that
backs
that
runs
two
clusters:
two
real
clusters
behind
it,
give
it
a
deployment
and
something
talking
to
kcp
splits
it
into
two
deployments
that
run
on
each
cluster
that
demo,
it
mostly
actually
works.
C
I
think
we're
probably
maybe
eighty
percent
of
that
is
actually
backed
by
real
code,
maybe
maybe.
C
Yeah,
which
is
which
is
pretty
good
for
a
prototype,
pretty
good,
so
so
that's
sort
of
an
area
of
investigation
that
we
think
this
minimal
api
server
could
help
us
realize
another.
C
One
is
logical
clusters
to
be
able
to
say
you
know:
why
have
multiple
teams
share
one
cluster
that
they
can
all
you
know
our
back
keeps
them
from
being
able
to
talk
to
each
other,
but
our
back
is
incomplete
and
imperfect
and
crds
and
other
cluster
names
based
things
leak
across
these
namespaces,
so
logical
clusters
being
sort
of
a
higher
barrier
between
between
clusters
between
teams
sharing
a
cluster
is
another
sort
of
area.
We
expect
kcp
to
be
able
to
make
progress
and
benefit
users.
Sorry.
B
Yeah,
maybe
just
a
point
here
I
spoke
about
hacks
just
before,
and
and
especially
even
currently,
you
should
be
able
to
to
leverage
a
first
hacky
version
of
0d
tenancy.
That
means
that
across
logical
clusters
and
the
existing
kcp,
if
you
just
add
a
custom
resource
definition
in
one
logical
cluster,
it's
not
at
all
reflected
in
the
other
logical
clusters,
even
in
the
you
know,
published
api
resources
or
or
open
api
model.
B
So
we
we
already
have
serious
tenancy.
I
mean,
of
course,
that
should
be
implemented,
obviously
differently
in
the
future,
but
at
least
to
play
with
that.
It
should
be
possible
already
now.
C
Yeah
yeah
crd
is
a
a
very
good
example
of
a
cluster
namespace
thing
that
we
that
you
might
not
want
to
bleed
across.
You
know,
there's
effectively
one
in
regular,
vanilla,
kubernetes,
there's
effectively
one
version
of
one
version
of
each
version
of
a
crd
type.
That's
a
weird
sentence
that
that
is
immediately
applied
to
all
you
know:
name
spaces
across
the
cluster,
well,
with
david's
crd,
tenancy
mega
hack.
C
Now
you
can
sort
of
partition
a
a
real
cluster
into
many
logical
clusters
and
apply
a
crd
definition
to
one
logical
cluster,
but
not
all
of
them.
That's
the
that's!
The
second
area
of
investigation
and
sort
of
what
we'd
like
to
be
able
to
prove
out
the
third
one
is
just
to
be
able
to
use.
What
would
you
do
with
a
minimal
api
server?
What
would
you
do
with
a
kubernetes
cluster
that
didn't
have
pods
or
didn't
have
deployments
or
didn't
have
nodes?
C
And
I
think
there
there
are
a
number
of
projects,
both
both
silly
hacks
and
actual.
You
know
real
life
useful
things
that
intend
to
use
the
kubernetes
sort
of
reconciling
declarative,
reconciling
api
model
to
express
non-clustered.
Things
like
you
know,
go
create
a
slack
channel
for
me
and
when
I
rename
it,
I
express
that
via
a
spec
change
or
a
metadata
change,
and
it
applies
it,
reconciles
it
with
real
life
and
then
tells
me
how
that
goes.
C
I
think
there's
a
huge
area
of
people
already
doing
this
on
top
of
regular
kubernetes
and
sort
of
trying
to
hide
or
cut
out
the
the
pods
and
nodes
and
deployment
side.
What
would
they
build?
What
would
you
build
if
you
didn't
have
to
do
that?
If
we
could
just
give
you
an
api
server
that
we
could
that
looked
and
felt
like
kubernetes
but
didn't
have
all
of
those
pesky?
C
You
know
containers,
that's
sort
of
that's
those
are
the
three
areas
of
investigation
and
then
I
think,
there's
sort
of
a
fourth
meta
one,
which
is
what
do
we
need
to
improve
about
kubernetes?
To
be
able
to
do
any
of
these
things
like
some
of
them
are
going
to
be
cod
tendency
requires.
C
You
know
terrible
hex
in
the
guts
of
kubernetes.
We
would
like
to
experiment
with
those
investigate
them
figure
out
what
those
need
to
be
to
be
mature
and
accepted
as
kept
and
then
merged
as
code
and
then
make
those
changes.
That's
not
the
only
one,
there's
also
being
able
to
scalably
watch
a
ton
of
things
across
multiple
namespaces
of
multiple
clusters,
all
at
once.
I
think
we
know
that
watching
at
that
scale
doesn't
won't
work
today.
C
So,
while
we're
experimenting
with
all
the
other
stuff,
we're
gonna
come
up
with
stuff
that
doesn't
work
fix
those
things
upstream.
Those
things
make
kubernetes
better
leave
it
better
than
we.
D
Found
it,
and-
and
I
was
gonna
add
so
like
the
control
planes-
was
a
general
topic
at
kubecon.
There's.
Certainly
a
couple
of
analysts
and
I've
heard
this
comic
brothers.
D
You
there's
a
certainly
a
couple
of
there's
quite
a
few
red
hatters
on
this
call
who
were
in
various
areas
that
kind
of
redragooned
into
the
represent.
What
interesting
customer
problems
emerge
in
kubernetes
or
user
problems
or
community
problems
or
technical
problems
that
don't
quite
fit
cleanly
into
the
historical
version
of
kubernetes?
D
But
if
you
think
about
like
evolution
of
an
ecosystem,
what
are
the
things
that
we
could
do
across
the
board
that
make
everything?
So
it's
kind
of
like
building
up
jason's
point,
so
some
of
the
red
hatters
here
are,
you
know
I
saw
some
of
their
journaling
or
folks
that
you
know
was
specific,
like
hey
you're,
going
to
need
to
think
about
this,
which
problems
do
you
have
you
know,
michael
represents?
They
see
a
project
which
has
done
a
lot
of
work.
D
You
know
over
the
years
on
hub
clusters,
and
so
some
of
this
is
like
okay,
can
we
create
enough
momentum
of
ideas
of
where
this
would
go,
that
we
could
say
we
could
see
all
of
our
lives
getting
easier
and
trying
to
bring
that
together?
Are
there
folks?
Are
there
things
that
we
didn't
talk
about
from
folks
here?
Who
you
want?
We
had
a
couple
questions
on
issues.
Does
anybody
feel
like
they
want
to
speak
up
and
talk
about
what
they're
looking
for
what
they
need
and
goals?
E
I'd
like
to
bring
up
that
the
as
written
right
now
with
the
the
sort
of
primitive
sinker
whose
job
is
to
look
at
stuff-
and
it's
correct
me
if
I'm
wrong,
it's
not
just
crds,
it's
any
resource
that
I
can
define
here
and
sync
down
to
there.
Vice
versa
right.
So
with
that
controller
in
play,
what
this
looks
like
is
a
nascent
hive.
I
don't
know
how
many
folks
on
the
call
are
familiar
with
hives,
but
that's
effectively.
E
That's
one
of
the
main
things
that
hive
is
responsible
for
for
kind
of
being
above
a
bunch
of
buster.
You
know
a
bunch
of
physical
clusters
if
you
will
and
you're
able
to
define
a
thing
at
the
hive
level
right
and
put
your
resources
into
what's
called
a
sync
set
and
have
hive
go
in
and
sink
those
things
down
into
your
cluster,
which
is
seems
like
a
lot
like
what
the
the
current
poster
controller
is
doing
in
the
kcp
prototype.
E
That
being
the
case
like
I,
I
don't
know
whether
that
means
that
we
want
to
look
to
whether
kcp
ends
up.
You
know
they
playing
whether
we
want
to
replace
hive
with
the
kcp
ism
or
whether
we
can
use
kcp
to
do
stuff
to
hive
or
whatever.
But
I
do
think
that
it
means
that
a
lot
of
the
lessons
that
hive
has
learned
over
its
over
the
last
couple
of
years
could
be
well
well
taken
to
inform
the
direction
of
kcp.
In
that
regard.
D
Maybe,
and
and
michael
too,
like
in
acm
and
the
projects
there
and
you
know,
there's
a
lot
of
discussion
around.
How
do
you
copy
things
down?
Are
there
been
a
couple
community
projects?
It's
like.
I
have
a
cube
resource.
I
want
to
fan
it
out.
Certainly,
we've
gone
back
and,
like
all
points
on
the
config
spectrum
of
how
you
take
config
in
one
declarative
form
and
put
it
another
set
of
places
are
being
explored.
D
A
Yeah,
I
think,
there's
there's
also
the
recursion
of
it,
though,
right,
because
the
logical,
kcp
cluster
might
use
the
hive
project
or
open
cluster
management,
which
just
is
sort
of
including
hive
as
well
to
provision
a
cluster
against
a
chartered
cloud.
It
might
use
something
like
a
cross
plane
to
provision
a
managed
kubernetes
cluster
across
a
cloud
there
might
be
other
models
of
provisioning
as
well.
D
F
Poked
around,
but
I
don't
know
if
anybody
specifically
from
crossplane
is
here
yeah.
My
name
is
dan.
I
know
a
couple
of
y'all
and
and
I'm
a
maintainer
of
the
cross
plane
project.
We
definitely
noticed
this
at
kubecon
last
weekend.
We
we
do
some
things
like
this
internally.
I
work
at
upbound,
which
is
the
company
that
founded
crossplane
and
we
have
some
ideas
around
it
as
well.
F
One
of
the
big
things
you
know
from
our
perspective
is,
if
you're
stripping
out
you
know,
kubernetes
primitives
such
as
pods,
etc.
A
big
part
of
crossplane
and
and
some
some
similar
projects
as
well,
is
that
we
allow
you
to
you,
know,
spin
up
new
pods
in
the
forms
of
providers
right.
So
it's
not
just
a
static
set
of
controllers,
and
you
could
look
at
this
in
a
variety
of
ways
and
how
this
could
accommodate
that
model.
F
One
being
that
you
know,
each
of
those
providers
themselves
could
have
some
sort
of
bundled
api
server
right
and
they
could
either.
You
know,
connect
to
each
other
and
share
a
control
plan
or
could
have
kind
of
their
individual
ones
as
well.
But
I
think
I
think
what
that
leads
to
right
is:
there's,
there's
a
spectrum
of
use
cases
of
this.
F
So
one
of
the
things
that
I
I
guess
I
personally
and
I
won't
speak
for
everyone
from
the
crossland
project,
but
I
think
we're
looking
at
you
know
something
that
can
be
sort
of
like
a
framework
to
be
able
to
build
things
that
are
at
different
parts
along
that
spectrum
right
and
make
it
really
easy
to
fit
your
use
case
and
no
matter
what
sort
of
amounts
of
kubernetes
api
you
want
to
consume
in
your
given
project
and
someone
else
brought.
D
This
up
recently,
we
were
kind
of
riffing
on
there's
like
the.
How
much
of
like
cube
is
not
necessarily
built
to
be
reusable
necessarily,
even
though
it
was
kind
of
an
early
project
goal
we
wanted
to
carve
stuff
off.
It's
never
quite
reached
what
I
would
call
critical
mass,
where
we
like
made
a
hard
cut
line
and
david
and
a
few
other
folks
like
david
eads
and
jordan,
and
I
and
dan
smith,
and
a
couple
others
like
early
on
when
we
were
splitting
out
library
go
and
api
server.
D
D
D
So
a
subtle
part
here
would
be
if
we
can
get
like
five
use
cases,
the
kep
becomes
very
easy
to
write
and
then,
if
we
can
get
a
couple
of
people
to
help
because
cigar
machinery
would
bear
the
brunt
of
it
and
those
people
are
always
like
everything's
always
on
fire,
my
subtle
goal
would
be
like.
Can
we
bring
people
and
problems
and
use
cases
and
get
some
of
these
things
that
are
like
almost
over
the
edge
and
just
tip
them
over
the
edge
in
a
way
that
we
all
benefit?
D
There
was
another
point.
You
brought
up
too
that
I
think
I
was
going
to
ask
you
to
ask
others
if
they've
seen
the
idea
that
there's
different
sets
of
apis
so
like
cube
kind
of
has
one
set
of
apis
and
everybody
layers
on
their
apis
on
top,
and
we
it's
hard
to
write
good
apis,
but
when
good
apis
show
up,
it's
often
you're
mixing
them
with
apis.
That
don't
make
sense.
So
one
of
the
things
that
I
think
and
jason
brought
this
up
on
twitter
was
sets
of
apis.
D
That,
logically
makes
sense
if
we
could
come
up
like
coming
up
with
use
cases
for
it,
so
like
the
transparent
multi-cluster
for
me
was
like.
Could
I
co-opt
the
whole
cube
ecosystem
and
bring
it
along
right,
like
everybody
has
an
app?
Suddenly
all
your
cube
apps
get
more
useful
if
you
can
standardize
like
you
know,
and
carmada
and
others
have
done
this.
That
was
a
big
inspiration.
A
federation
v1
tried
to
do
this
and
we
hit
some
roadblocks
if
you
could
take
the
existing
cube
model
and
make
it
work
differently
or
mostly
with
high
fidelity.
D
What
does
that
look
like,
but
then
there's
a
completely
different
set,
which
was
jason's
focus
and
I
think
crossplaying
hits.
This
too
is
like
I
was
I
I
made
up
some
examples:
gorkham
who's
on
the
call,
and
I
were
riffing
like.
Could
you
do
a
heroku
style,
12-factor,
app
crd
and
a
mix
in
a
few
of
the
concepts
in
cube,
but
then
cut
everything
else
out,
so
you
might
have
secrets
and
configmaps
and
a
12-factor
app
for
something
like
a
heroku
deployment,
and
we
were
going
to
do
a
netlify
example
and
a
demo.
D
So
you
could
build
everything
you
wanted
and
the
word
cube
never
comes
up,
but
you
can
still
reuse
some
of
the
bits.
There's
been
one
like
infrastructure
or
management.
Are
there
other
use
cases
folks
have
thought
about?
You
know
daniel,
or
anybody
who
you're
thinking
about
different
groups
of
apis
living
side
by
side
for
different
personas?
C
I
think
even
I
don't
know,
I
don't
have
another
example,
but
I
think
even
being
able
to
present
a
set
of
like
that
heroku
12,
12
12
factor
app,
might
you
know,
be
a
controller
that
boils
down
to
pods
somewhere,
but
if
I
don't,
if
my
users
never
need
to
see
those
pods
or
care
about
those
pods,
I
can
hide
them
from
them
much
more
effectively.
C
If
that
api
is,
you
know
if
the
api
is
more
flexible
right
like
give
me
your
12-factor,
wrap
and
I'll
take
care
of
it.
Don't
worry.
What's
behind
you
know,
don't
don't
look
behind
the
curtain?
There
are
pods
back
there,
of
course,
but,
like
you
won't
be
able
to
see
them,
I
think
that's.
That's
sort
of
an
orthogonal
question
to
what
are
the
different
sets
of
apis
that
people
might
come
up
with
a
separate
question
is
a
separate
point
is
to
be
able
to
hide.
C
You
know,
sweep
stuff
under
the
rug
and
not
let
people
see
that
it's
actually
just
pods
at
the
end
of
the
day.
I
think
one
one
interesting
thing
that
that
dan
brought
up
was
also
the
and
it's
come
up.
It
came
up
on
twitter
in
a
couple
of
places
and
and
maybe
in
one
of
the
issues
was
sort
of
in
in
this
model.
You
still
need
to
run
controllers
against
this.
C
Somehow
right
like
like
it's
not
going
to
magically,
you
know
make
breakfast
for
you.
Without
somebody
doing
something,
and
in
kubernetes
it
it,
you
have
pods,
you
have
deployments,
you
have
things
that
can
run
right
there.
Next
to
it.
I
think
it
is
an
open
area
of
exploration,
and
I
want
to
see
what
people
do
with
it
to
be
able
to
figure
out
how
to
run
controllers
against
this
without
it
also
bringing
pods
along
with
it.
C
I
know
that
I
know
that
we've
talked
about
having
kcp,
be
a
library
that
you
could
just
embed
in
your
own
application,
or
you
know
embed
it
in
binary
or
daniel.
You
said
framework,
I
don't
know
if
we
want
to
have
the
framework
versus
library,
but
like
yes,
I
agree,
I
want
it
to
be
something
that
you
can
that
you
can
package
into
your
binary.
That
is
the
controller
so
that
it
is,
or
a
set
of
controls,
a
number
of
controllers.
C
I
know
that
there's
also
been,
I
think.
Kelsey
hightower
has
some
examples
of.
I
think
it's
admission
controller
web
hooks
that
are
external
services
running
you
know,
all
you
need
is
just
https,
that's
it
so
that's
another
sort
of
option
is
to
run
kcp
somewhere
and
have
it
call
out
to
other
controllers
running
you
know
anywhere,
but
now
now
the
question
is:
where
do
I
run
that?
Well,
the
answer
is
anywhere,
which
is
both
helpful
and
not
helpful,
yeah.
C
So
yeah.
I
think
I
think
that's
a
an
active
sort
of
question
I
have
for
people
as
we
go
forward
is
where
do
you
want
to
run
your
controllers
against
this?
Do
you
want
to
bundle
it
in
and
have
it
be
one?
You
know
one
binary
or
constellation
of
local
binaries
or
some
remote,
some
local,
some
third
option?
I've,
never
thought
of.
F
Yeah
that
I
feel
like
that
kind
of
getting
to
those
different
levels
of
exposures
of
api
concepts
you
were
talking
about.
I
I
generally
think
of
it
as
like
in
you
know,
cross-plane
world
right
where
we're
running
these
providers
for
folks,
but
they
don't
ever
see
the
pods
or
deployments
kind
of
like
you're
saying
so.
F
We
kind
of
have
this
sense
of
operator
facing
or
controller
facing
apis
versus
user
facing
apis,
which
you
know
I
don't
know
how
well
that
scales
across
all
projects,
but
at
least
for
us
there
is
a
pretty
strong
distinction
there
and
obviously
the
controllers
also
access
the
user-facing
apis
to
reconcile
them.
F
But
but
that's
been
a
pretty
good
breaking
point,
another
analogy
kind
of
since
I
guess
the
the
kcp
talk
last
week
that
we've
been
chatting
about
a
little
bit
is
kind
of
the
the
sequel
light
model.
If
folks
are
familiar
with
how
that
works
right,
you
can,
you
can
run
sqlite
alongside
your
application
on.
You
know,
on
a
single
box.
F
If
you
want
to,
you
can
embed
it
in
your
application,
you
could
run
it
on
a
separate
server
if
you
wanted
to
and
treat
it
as
more
like
a
typical
database
server
and
that's
kind
of
the
that's
that's
the
future
of
vision.
You
know
that
I
feel
like
we're
moving
towards
there
a
little
bit
where
it
has
that
flexibility,
and
you
know,
there's
actually
an.
D
Interesting,
a
wrinkle
in
this
too
so,
like
kind
of
thinking
about,
like
you
know,
where
do
you
run
this?
How
big
does
it
get
dude?
What's
the
cube
api
model
good?
For
so
there's
no
element
of
this
which
is
like?
Can
we
can
we
let
it
run
a
little
bit
and
see
what
problems
devin
and
I
were
kind
of
riffing
with
a
couple
of
other
folks
kind
of
if
you're
doing,
multi-cluster
with
cube,
and
you
want
to
run
stuff
on
across
those
clusters
the
transparent
multi-cluster
is
like.
D
Could
you
get
to
a
point
where
you
could
kind
of
most
of
your
cubs?
Just
don't
care
they
stay
resilient?
Could
you
come
up
with
apis
that
help
you
bridge
failure?
Domains,
michael
and
I
talked
about
this-
a
while
back
hub
cluster
that
hub
cluster
needs
to
be
reliable.
How
do
you
spread
your
hub
cluster?
Well,
obviously,
if
your
control
plane
and
your
flow,
if
your
high
cluster,
your
load
cluster,
are
separate,
you
can
do
things
at
different
levels.
D
D
Like
really
large
config
objects,
real,
really
large
secrets-
and
you
know
in
cube
today
you
just
break
your
secrets
up
we
like
source
code
and
like
serverless,
you
know,
there's
a
there's,
a
there's,
a
point
at
which
code
grows
beyond
a
couple
of
tens
of
k
and
it
transitions
into
the
git
realm
or
into
the
zip
file
realm,
or
you
know,
whatever
your
your
longer
term
storage,
but
like
a
lot
of
bringing
code
and
config
closer
to
get
together.
D
You
know
it's
like
what
are
the
patterns
in
the
ecosystem
that
we
could
enable
so
there's
at
least
a
thread
of
this
investigation,
which
is
like
super
high
scale?
How
how
efficient
could
you
make
the
api
server
and
how
could
you
set
up
the
incentives
so
that
everybody's
trying
to
make
that
more
efficient?
We
had
that
in
cube
right,
like
folks,
like
voitech
and
the
scalability
has
pushed
us
up
to
like
10
million
keys
or
whatever
ncd
has
some
hard
limits.
D
As
a
library
can
we
open
the
door
to
better
stores
or
to
scaling
more
efficiently
or,
and
this
isn't
covered
in
any
of
the
investigations,
but
it
is
something
that
I
wanted
to
suggest.
If
other
people
are
thinking
like
this
or
is
an
idea
we
could
get
at
too
late
over
time
is,
can
we
blur
the
lines
between
code
and
config
a
little
bit
more
effectively
from
a
declarative
perspective,
and
where
are
the
gaps
in
that
so
like?
D
D
Well,
maybe
that
block
base.
How
could
you
write
controllers
for
a
billion
keys
more
effectively
and
then
tie
them
back
in
not
everybody's
going
to
have
those
problems,
but
I
at
least
wanted
to
look
for
use
cases
where
you
start
getting
into
bigger
scales
and
not
everybody
will
have
those
but
control
planes.
Probably.
C
Yeah,
I
think
I
think,
that's
also
a
good
example
of
how,
where
we
expect
things,
we
end
up
doing
to
break
something
and
in
putting
out
that
fire,
we
should
also
fix
it
for
future
future
people
running
into
this.
There
was
an
issue
about.
I
want
to
call
it
out,
because
I
think
you
briefly
touched
on
it
and
I
want
to
make
sure
we're
on
the
record
about
it.
There
was
an
issue
about
sort
of
investigative
investigation.
Swapping
out
at
cd.
Is
the
data
store?
C
I
think
we
want
to
be
pretty
clear
that
that
is.
That
is
a
non-goal
at
least
for
now.
I
think
we
will
probably
have
plenty
to
do
and
and
plenty
of
mischief
to
get
into
without
also
swapping
out
ftp,
but
there
are
other
projects
in
the
ecosystem.
Looking
into
that
working
on
that-
and
I
think
we're
sort
of
we're
gonna
mess
with
silly
hacks
up
here,
they'll
mess
with
silly
hacks
down
here.
Hopefully
we
don't
make
any
silly
hacks
that
are
incompatible
yeah
and
as
a.
D
Library,
if,
like
you,
know
kind
of
getting
to
that
point,
I
think
you
know
if
we
have
a
library
or
a
framework
and
it's
easy
enough
to
compose
it
in
a
set
of
areas.
The
storage
interface
and
the
back
end
resources
is
absolutely
one
of
those
they're
actually
pretty
cleanly
decoupled.
Even
in
cube
today,
it's
all
the
gorp
necessary
to
start
the
server.
That's
not,
I
absolutely
think
yeah.
If
we
do
push
on
a
cap
for
like
library,
api
server
as
a
library,
a
part
of
that
should
be.
D
It
should
be
reasonable
for
you
to
explore
this
space
without
us
getting
in
the
way,
and
that
would
help
you
know
some
of
the
work
that
was
going
on.
You
know
thinking
about
like
what
k3s
went
through
and
how
wow
machinery
hat
on.
Don't
have
emotional
energy
to
go
chase
non
ncb,
but
if
we
can
open
the
door
for
others
to
chase
it,
and
we
have
those
clean
interfaces
that
actually
could
really
help
everybody.
C
Yeah
yeah
yeah
does
anybody
we've
been
we've
been
chatting
for
a
while?
Does
anybody
have
any
any
topics
burning
a
hole
in
there
in
their
head
that
they'd
love
to
that
they'd
love
to
bring
up?
I
think.
A
So
I'll
jump
in
with
just
one
like
as
I
look
at
the
project
and
look
at
the
the
goals
and
the
I'm
curious.
If
there
is
a
bias
towards
are
we
focused
on
developing
kcp
use
cases
that
make
the
experience
of
running
and
dealing
with
tendency
and
kubernetes
the
api
definitions,
et
cetera,
sort
of
thinking
about
people
that
are
running
and
managing
clusters
right,
certainly,
there's
a
value
proposition
that
with
logical
clusters
and
better
tenancy
that
it
would
be
easier
to
have
self-service
without
having
to
spin
up
entirely
do
physical
fosters
as
a
result.
A
A
Is
it
another
generation
and
I
don't
want
to
start
any
dogma
wars
either
way,
but
like
a
spring
cloud
like
thing
where
I
think
about
here's,
a
way
that
I
can
plug
in
my
application
logic
and
certain
aspects
of
authentication,
authorization,
storage,
etc
are
going
to
be
cared
for
on
my
behalf
by
the
framework,
and
I
can
just
go
and
build
an
app
which
provides
some
completely
non
cube.
Non-Container.
A
It's
I've
got
a
startup,
it
deals
with
widget
things
and
my
app
makes
it
easier
to
deal
with
widget
things,
I'm
kind
of
curious
on.
Do
we
see
a
bias
on
kubernetes
consumption
as
a
primary
motivator
in
goal,
or
I'm
an
application
developer,
who
doesn't
really
understand
all
the
kubernetes
or
containers
just
want
to
build
an
app
that
does
the
thing.
D
So
I'll
give
my
biased
opinion,
which
is,
I
would
probably
say
it's
the
former,
because
I
think
we'd
do
a
bad
job
at
the
latter.
Let's
go
because,
like
the
analogy
might
hear
me
rails,
could
you
use
kcp
to
do
something
like
rails?
Yes,
should
you
maybe
not?
I
do
think-
and
this
is
kind
of
like
a
problem.
D
We're
all
going
through
is
like
what's
the
right
end,
state
for
infrastructure
as
code
or
code
as
infrastructure
or
distributed
systems
assumption
with
the
idea
being
rooted
in
everybody's,
got
lots
of
kubernetes
clusters,
but
there's
a
lot
of
stuff
not
on
there.
That's
like
how
do
you
bring
the
world
together
with
acute
focus,
there's
a
flip
side.
Discussion
of
if
you
love,
declarative,
api
management
and
you
want
to
have
like
a
place
to
integrate
cube,
also
kind
of
does
that.
D
D
Maybe
but
I'm
a
little
bit
more
of
a
pragmatist,
there
I'd
be
interested
in
other
people's
opinions
here.
E
I'm
sort
of
hearing
conflicting
stories
there,
because
you
know
the
one
hand
you're
saying
we
want
to
be.
We
want
to
empower
people
to
do
things
with
this
without
getting
in
their
way
right
and
from
that
point
of
view
like
boiled
down-
and
this
is
happening
in
the
chat
as
well
like
boiled
down
you're,
making
a
thing
that
you
can
write
a
controller
to
that
will
reconcile
that.
E
Will
you
know,
use
cube
objects
as
an
api,
and
if
you
anything
you
could
write
that
controller
to
do
you
can
do
and
it
shouldn't
really
the
kcp
itself
shouldn't
be
shouldn't
its
architecture
shouldn't
affect
what
you
could
and
couldn't
do
with
that
controller.
C
Our
intention
is
for
kcp
to
be
very
flexible
and
for
it
to
be
able
to
be
a
foundation
for
reconciling
controllers
to
run
against.
Is
that
going
to
make
it
the
best
mobile
app
back
end?
Is
that
going
to
make
it
the
best
you
know?
Are
we
going
to
replace
postgresql
with
this?
No,
I
I
think
we
need
you
need
to
decide.
You
know,
based
on
what
your
needs
are
scaling
and
latency
and
developer
experience
all
in
a
balance.
What
what
the
best
back-end
for
your
thing
is
going
to
be.
C
I
think
the
api
model
and
the
storage
scaling
characteristics
are
really
good
for
infrastructure.
I
think
we
know
that
it's
pretty
good
for
infrastructure
and
there
are
some
ways,
some
other
different
definitions
of
infrastructure,
that
we
think
it
could
be
good.
For
all
of
that
being
said,
this
is
a
thing
we're
putting
out
into
the
world.
If
you
want
to
make
your
mobile
app
back
end
kcp.
We
also
can't
stop
you.
C
D
Maybe
yeah
distributed
systems
declarative
config
loops,
like
the
logical
sharding
of
problems
into
like,
because
I'd
say
you
know-
and
this
is
like
there's
a
bunch
of
theory
like
brendan,
and
I
were
riffing
on
this
a
couple
of
weeks
ago
when
I
was
chatting
with
some
of
these
ideas
with
them
brendan
burns.
But,
like
you
know,
one
of
the
original
ideas
was
like
there's
a
bunch
of
like
factors
that
come
together
in
cube.
D
The
controller
pattern
is
strong
in
a
set
of
domains.
The
declarative
api
model
is
strong
in
a
set
of
domains
and
the
config
loops
are
really
strong
in
a
set
of
domains.
D
I
I
wonder
if
maybe
what
we're
saying
is
like
we
should
have
like
a
diagram
or
a
way
of
discussing
this,
where
it's
like,
if
you've
picked.
If
you
have
two
of
these
three
problems,
kcp
may
be
useful
for
you,
like
infrastructure
and
distributed
systems
or
infrastructure
and
config
loops
or
config
loops
and
infrastructure
distributed
systems.
But
if
you
don't
have
two
of
those
problems,
maybe
this
isn't
the
right
thing
for
you,
you
know
and
having
some
kind
of
tease.
So
is
that
a
better
answer.
E
Yeah,
I
think
that
makes
sense.
I
think
that
the
next
question
that
leads
to
is,
if
your
use
case
doesn't
fit
two
out
of
those
three:
is
it
even
suitable
for
cube
at
all.
D
Yeah
and
we
don't
have
a
bunch
of
good
examples
written
down,
but
maybe
like
what
we
do
is
like
what
we're
kind
of
talking
about
here
is
like.
Can
we
frame
more
of
a
fundamental
like
what
is
kcp?
What
is
the
project's
goal?
What
are
the
the
bounds
in
one
of
the
docs
where
we'd
say
here's
an
example
of
something
that
doesn't
actually
really
fit
to
those
so
like
devin
and
I
were
riffing
on.
Would
you
model
an
identity
system
using
the
api
patterns
of
cube,
so,
like
cube?
D
Does
that
for
small
sets,
but
there's
big
boundaries
right,
like
most
organizations
that
have
100
000
million,
like
the
biggest
companies
in
the
world,
have
a
million
people
in
their
ldap?
Would
you
write?
Would
you
put
every
single
person
into
cube
as
an
api
object?
No,
would
you
put
everybody
who
has
owns
a
resource
on
the
cluster
in
there?
D
Maybe
would
you
model
the
nested
relationships
of
an
identity
to
group
system
in
a
cube-like
model,
maybe
not
for
things
that
have
nothing
to
do
with
cube,
but
maybe,
if
you
want
to
do
ad-hoc
teaming
of
our
back,
then
it
becomes
useful.
So
like
we
can
try
and
figure
out
ways
of
like
this
problem
doesn't
quite
fit.
This
does
and
then
evolving.
E
E
Yeah,
because
when
I
heard
I
heard
you
say
like
this,
this
problem
doesn't
suit
because
there's
too
many
of
them,
if
there's
a
million
users
in
your
ldap,
that's
too
many
cube
objects.
So,
like
there's
a
you
know,
right,
maybe
a
counter
example,
and
it
is
that,
and
the
reason
is
too
big
for
one
of
the
reasons
there
was
a
very
early.
D
Discussion
on
cube,
where
a
lot
of
us
were
coming
from
backgrounds
of
you
know
like
building
web
apps
building,
you
know
straightforward
rest,
apis
and
various
approaches
therein
and
brian
graham,
had
like
a
really
good
point,
which
is
he
was
like.
Everybody
was
tim,
I
don't
remember
but
like
if
your
problem
size
is
less
than
100k
or
fits
in
memory.
D
You
should
just
fit
yourself
into
memory
and
design
as
if
you're
going
to
reconstruct
state
and
reconcile
it,
because
the
reconciler
pattern
fixes
damage
and
a
lot
of
times
when
you,
when
you're,
trying
to
solve
problems
that
are
like
too
much
to
fit
in
memory.
Those
are
just
really
hard
problems.
No
matter
what
so
cube
kind
of
is
like
a
hundred
thousand
in
any
dimension
is
kind
of
its
limits.
That's
a
good
rule
of
thumb
for
a
lot
of
problems,
but
it
as
your
example
might
hold.
D
It
wouldn't
be
good
for
the
front
end
for
a
global
distributed
service,
but
most
people
build
global,
distributed
services
out
of
sharded,
back-ends
and
logical
chunks
of
less
than
a
hundred
thousand.
For
other
reasons,
can
we
overlay
those?
So
that's
a
very
useful
heuristic
eric.
Maybe
this
is
something
that,
like
we
take
as
like
one
of
those
action
items
out
of
this
meeting
is,
can
we
get
boil
this
down
into
something
and
get
some
iteration
so
that
people
can
can
orient
themselves.
A
And
you've
got
you've
got
a
dimension
there,
which
is
the
scale
side,
but
you've
also
got
a
dimension
there
of
does
your
particular
application
use
case
touch
some
aspect
of
infrastructure
right.
The
next
generation
of
infrastructure
management,
as
opposed
to
the
next
generation,
don't
use
the
exact
same
example
of
a
mobile
backend
right.
D
Yeah,
and
certainly
like
you
know
like
looking
at
like
terrible
like
terraform,
I
think,
has
a
lot
kind
of
bring
a
bunch
of
things
together.
You
could
look
at
one
way
of
looking
at
terraform
and
other
config
management
solutions
is
like.
You
can
represent
a
lot
of
config
and
you've
got
plugins
and
you're
combining
code
in
declarative
state.
D
Is
there
anything
we
can
do
different
with
cube
that
those
can't
today
so
that
those
two
work
well
together
or
are
there
problems
that
you
know
are
infrastructury,
but
most
people
just
don't
want
to
deal
with
it
like
moving
processes
across
machines
which
cube
does
how
do
we
delegate?
How
do
we
find
the
problems
that
that
surface
that
are
not
solved,
that
we
all.
C
C
I
think
I
think
one
thing
that
could
that
could
be
confusing,
and
I
think
we
should
do
a
better
job
of
describing
it
as
like.
The
goal
is
sort
of
you
know.
Kubernetes
is
this
today
and
we
want
to
expand
it
to
be
slightly
more.
C
That
doesn't
mean
we
want
to
expand
it
to
do
everything
right
like
that
is
that
is
a
recipe
for
failure.
We
want
to
take
the.
We
think
that
the
kubernetes
api
model
and
infrastructure
is
good,
and
we
want
to
apply
it
to
slightly
more
in
the
grand
scheme
of
things,
but
not
to
make
it
a
message.
Bus
or,
or
you
know,
file
system
or
anything.
C
I
bet
you'd
be
a
great
message,
bus,
I
I
don't
I
disagree,
but
we
by
all
means
try
right
like
part
of
this,
is
that
we're
gonna
make
it
flexible
and
you
can
do
whatever
you
want
with
it
come
and
come
and
tell
us
how
it
failed
or
how
it
succeeded
so
that
we
can
follow
you
or
never
go
down
that
path
ever
again.
So
we're.
D
G
Just
sort
of
a
thing
that
I'm
watching
and
we've
talked
about
a
lot,
but
I'm
I'm
coming
at
this
from
a
perspective
of
somebody
who
maintains
one
of
these
rights
and
maintains
one
of
these
sorts
of
applications
and
struggles
with
the
limitations
of
a
kubernetes
cluster,
and
I'm
I'm
just
watching
and
trying
to
understand
how
we're
going
to
evolve,
avoid
those
same
problems
we're
going
to
a
higher
level
which
has
the
same
sort
of
limitations.
You
know
everything
in
memory,
one
one
at
cd
and
these
sorts
of
things.
G
That's
something
I've
been
asking
about
a
lot
and
I'm
still
not
a
hundred
percent
sure
like
how
we
push
beyond
the
problem
we
have.
I
just
want
to
make
sure
that
I'm
not
heading
for
the
same
problem
up
as
another
layer.
D
I
will
represent
one
I'll
represent
one
audience
that
I
don't
know
is
fully
represented
here.
Certainly
almost
everyone,
I
know
who
has
multiple
clusters,
has
some
kind
of
self-service
planning
plotting
scheduling
that
mostly
falls
under
the
transparent,
multi-class
reference
of
michael
but
like
for
self-service,
but
I
do
feel
the
one
thing
that
everyone
struggles
with.
D
Is
they
when
you
build
a
platform
on
top
of
cubes
or
you're
building
like
your
app
platform
for
teams,
I
kind
of
wanted
to
get
to
a
spot,
and
the
idea
would
be
maybe
some
of
the
different
goals
kind
of
helped
make
this
better
would
be.
We
have
more
building
blocks
for
organizations
that
are
building
platforms
for
their
own
teams,
and
so,
like
you
know,
there's
different
audiences
that
everybody
has
cube
kind
of
is
in
one
particular
focus.
You
know,
there's
much
different
user
experience.
D
Focus
like
backstage
is
a
great
example
of
a
project
that
uses
cube.
It's
not
focused
on
cube.
Can
we
make
more
tools
and
libraries
available
that
kind
of
helps
collapse,
the
duplication?
So
I
don't
know
that
is
implicit
in
some
of
these,
but
it's
not
explicitly
called
out
that
helping
people
build
platforms
should
get
easier,
especially
for
large
sets
of
application
teams.
That's
just
personal
bias
that
I
come
in
with
with
my
red
hat
hat,
on
of
lots
of
large
enterprise
customers.
Everybody
has
this
problem
and
everybody
reinvents
the
wheel.
C
H
I
think
I
just
grant
him
from
from
my
point
of
view
being
here.
I
I'm
looking
at
kcp
to
understand
how
it
when
someone
brought
to
what
devon
was
talking
about
is
how
it
would
solve
issues
for
us,
at
least
where
we
run
an
operator
across
multiple
clusters.
That's
configured
with
a
relatively
same
with
relatively
the
same
configuration
and
storing
that
state
at
a
higher
level.
H
I'm
not
sure
how
bringing
that
configuration
and
the
state
up
one
level
solves
the
scaling
problems
for
us,
because,
as
we
get
you
know,
maybe
thousands
of
these
virtual
clusters
at
the
bottom,
like
I
don't
know
how
that
scales,
but
for
us
like
repeating
that
configuration
across
clusters
is
painful
and
it
seems
like
kcp
could
solve
some
of
those
answers
for
us,
but
yeah.
It's
something
that
I'm
here
to
at
least
see
how
this
evolves
and
see
what
problems
this
supports
for
us.
C
C
Yeah,
that
might
be
a
good
topic
for
a
future,
a
future
meeting
with
that,
with
with
zero,
now
zero
zero
minutes
left.
I
think
we
should
have
this
again
next
week.
Hopefully
we
have
ten
minutes
of
preamble,
trying
to
figure
out
how
to
record
the
damn
thing.
C
Thank
you
to
thank
you,
michael
for
recording
this.
I
will
collect
notes
put
them
in
the
issue.
If
you
have
any
comments,
questions
join
us
on
the
slack
meet
us
next
week.
I'm
excited
to
make
some
stuff
make
some
stuff
all
right
have
a
good
week.
Everybody
thanks
all
thanks
all
right.
Thanks
very.