►
From YouTube: Cloud Foundry for Kubernetes SIG [May 18, 2021]
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).
C
B
D
E
A
At
least
the
background
looked
like
germany,
your
picture,
your
static
picture,
it.
A
Well,
the
last
time
we
could
travel
on
a
cf
summit
when
it
was
in
the
netherlands.
I
then
took
two
weeks
in
germany,
so
it's
the
most
recent
country
I
visited.
F
A
F
E
E
Yeah,
so
I
know
we've
been
talking
about
the
vision
for
cf
on
cage
stock.
I
think
we
we
finished,
making
a
pass
through
it.
E
So
there's
probably
some
background
work
that
we
could
be
doing
to
resolve
some
of
the
comments
there
and
capture
some
of
the
additional
context
that
we
generated
so
that
it's
not
all
hidden
in
the
comments,
but
I
thought
would
be
at
a
good
stage
now,
where
we
could
also
start
talking
about
some
potential
options
around
the
architecture
and
how
that
might
fit
into
usage
of
what
we've
had
in
mind
with
cf
for
cf
on
capes,
you
know
and
how
that
minor
might
not
align
to
what's
already
there
with
cf
for
gates
and
sit
alongside
qcf.
E
So
I
know
that
some
of
the
folks
that
we've
got
here
from
vmware
have
been
thinking
about
various
options,
and
so
you
know
what
whatever
they
think
would
be
useful
to
illustrate
or
discuss.
At
this
point,
I
think
would
be
great.
B
Cool
yeah,
so
I
think,
there's
maybe
jumping
in
here
like
sometimes
it's
hard
to
talk
about
things
without
having
like
diagrams
or
pictures,
especially
when
you
talk
about
architecture,
and
so
I
think,
like
one
thing
that
we
have
been
thinking
of
like
at
a
high
level,
is
you
know
when
we
think
about
like
sort
of
the
work
that
was
being
done
on
cf
for
kate's,
like
I
think
one
of
the
areas
that
we
were
trying
to
align
towards
was
having
more
modular
interfaces
and
that's
sort
of
in
line
with
what
we've
been
talking
about
in
the
cf
on
kate's
vision
statement,
and
I
think,
like
one
thing
that,
like
instantly
comes
to
mind,
is
like
what
the
work
that
was
being
done
around
like
having
route
crds
and
then
being
able
to
like
use
that
as
an
interface
to
then
like
plug
in
different
backing
implementations
for
like
what
you
wanted.
B
Your
ingress
solution
to
be,
and
so
I
think
you
know
looking
at
all
of
the
different
sort
of
goals
in
the
vision
dock.
It's
definitely
not
a.
I
think
one
of
the
key
call-outs
is
like
it's
not
necessarily
like
a
one-size-fits-all
solution
right.
We
want
to
really
make
it
so
that
it's
able
to
be
pluggable.
So
if
you
really
care
about
backwards,
compatibility.
B
Cool
yeah
so,
like
I
think
like
here
at
this
yeah
yeah.
This
calls
that
sort
of
what
what's
currently
here,
but
I
think
like,
what's
not
called
out
necessarily,
is
that
level
deeper
of
like
how
are
we
actually
using
like
each
of
these
different,
like
kate
solutions
right
so
like?
How
are
we
actually
using
istio?
B
How
are
we
actually
using
pocato,
and
so
I
think
the
key
to
that
really
is
having
custom
resource
definitions
like
custom
resources
as
the
interface
to
make
it
so
that
it's
more
plugable
of
different
solutions,
and
I
think,
like
particularly
like
we
have
been
thinking
about
like
what
would
that
look
like,
for
example,
like
with
a
cf
push
like
workflow,
like
you
know
what
like
right
now
when
you
do
a
cf
push,
you
know
you
get
a
lot
of
different
like
you,
have
a
lot
of
different
api
calls
to
cappy
and
a
lot
of
different
resources
are
created
and
so
like
what
resources
would
we
actually
maybe
want
to
map
to
like
kubernetes
resources
and
how?
B
How
would
that
look,
and
so
I
don't
know-
I
think
you
know
tim
put
together
this
diagram.
I
don't
know
tim
if
you
want
to
sort
of
like
go
through,
maybe
thinking
about
like
or
showing
like
the
workflow
for,
like
one
possible
approach
at
like
a
high
level
for
thinking
about
like
custom
resources
or,
if
you'd
like
me
to
go
through
it.
D
F
D
Good
cool
yeah,
so
this
this
little
exploration
we
did
like
combines
this,
like
crd
interface
approach,
also
with
like
a
thought
experiment
for
trying
to
eliminate
the
cloud
controllers
database
so
that
we
have
a
single
source
of
truth
for
where
we're
maintaining
state.
So
we're
we're
imagining
like
a
a
lightweight
like
reimplementation
of
the
cfv3
apis,
that's
like
backed
entirely
by
by
crds
and
for
simplicity's
sake.
D
We've
we've
basically
made
a
one-to-one
mapping
of
custom
resource
and
and
cappy
api
resource
just
because
it
makes
the
the
modeling
easier
to
understand
for
how
these
might
power
an
endpoint.
D
So
on
on
this
mirror
board
we've
we
start
out
with
a
a
user
using
just
a
like
vanilla,
cfcli.
It's
it's
not
aware.
It's
targeting
something
different
because
we've
implemented
the
same
api
contract
and
it
is,
they
are
pushing
in
their
app
and
applying
a
cf
manifest
and
that
we
have
like
a
manifest
controller.
We've
we've
modeled
this
as
separate
controllers,
but
in
practice
it
could
all
be
a
single
cf
controller,
with
multiple
reconciler
loops
that
watches
that
manifest
and
breaks
down.
D
All
the
like,
all
the
pieces
of
it
into
separate
like
route
crs
process
crs
and
and
app
cr
and,
like
I
said
these
are
all
like
kind
of
like
placeholders
like
you
could
imagine.
Instead
of
a
process
er,
it
directly
makes
an
irini,
l
or
pcr.
Perhaps
that's
that's
all
like
an
implementation
detail,
but
hopefully
this
is
like
showing
a
bit
of
how
this
might
work
and
then
because
the
the
v3
api
calls
are
so
granular.
D
We
kind
of
have
to
like
jump
through
some
hoops
when
we're
doing
this
so
like,
because
an
existing
client
expects
to
hit
like
four
or
five
different
api
endpoints
to
push
a
package
and
stage
an
app
having
these
individual
custom
resources
for
for
different
things
like
having
a
discrete
package.
Cr
makes
it
so
that
we
can
like
track
the
same
sort
of
of
the
cycle.
D
As
the
the
client
might
expect
so
so
like
here,
the
the
cli
uploads
like
a
zip
with
the
package
source
code
as
usual,
but
then,
instead
of
doing
like
the
normal,
like
blob
store
and
resource
matching
flow,
that
existing
cloud
controller
would
do
it's
going
to
convert
it
into
a
zip
file
or
it's
going
to
convert
it
into
a
single
layer,
oci
image
kind
of
like
we
do
in
ncf
for
capes
and
and
track
all
that
on
on
that
package.
Cr,
so
that
our
api
can
convert
it
back
into
the
like.
D
The
states
that
the
cli
might
expect
then
eventually
end
up
in
an
image
registry
like
that
part,
is
pretty
similar
to
what
goes
on
in
cf
for
kids
and
then
like.
As
you
can
see
here,
we
will
have
build
resources
and
droplet
resources
to
power.
Those
endpoints
and
these
like
in
this
diagram.
It
kind
of
is
similar
to
how
how
we've
done
it
in
cf
for
kate's.
D
But
you
could
imagine
this
being
like
yeah,
like
even
another
extension
point
where,
because
our
our
lightweight
api
only
cares
about
the
direct
like
build
and
droplet
resources
like
you
could
imagine
a
more
like
plugable
staging
implementation
here,
where,
where
you
like,
swap
out
the
build
controller
to
create
like
I'm
just
throwing
out
words
here,
but
like
tekton
stages
or
like
something
something
else.
D
So
this
is
where
we're
trying
we're
like
kind
of
viewing
like
opportunities
for
extension
points
just
by
granular
granularizing
these
a
bit
and
then
at
the
end
of
the
day,
once
you
have
a
a
staged,
droplet
or
image
whatever
you
want
to
call
it
these
days.
D
We'll
we'll
do
the
bookkeeping,
update
the
custom
resources
so
that
the
api
shim
can
return
responses
that
the
clients
like
cli
java,
client
et
cetera,
expect
and
and
it
will
deploy
very,
very
similar
to
how
it
does
in
cf
for
case,
but
without
a
database
or
a
lot
of
the
rest
of
the,
like
constellation
of
cloud
controller
deployments
running
so
like
we're,
hoping
that
this
will
be
a
lighter
weight
and
more
like
friendlier
implementation
for
people
to
experiment
and
stuff
yeah.
So
I've
I've
been
talking
a
lot.
F
I
think,
from
from
my
perspective,
like
the
whole
topic
of
deep
coupling
via
crds,
makes,
makes
total
sense
like,
given
that
things
are
running
on
kubernetes.
That
seems
to
be
like
the
de
facto
way
of
building
apis
right
and
then
like
it's
easy
to
envision.
How
one
could
then
kind
of
swap
out
one
implementation
of
a
controller
that
listens
to
the
creation
of
a
particular
custom
resource
and
kind
of
do
something
very
different
if
that
is
required
right
so
yeah,
I
think
that
that's
like
very
like
a
very
good
way
of
approaching
things.
F
I
guess
where
I
don't
have
a
feel
is
what
should
these
objects
actually
be
right,
and
I
think
you
spend
quite
some
thinking
already
into
like
what
granularity
could
these
be?
How
would
you
kind
of
represent
things
so
this
this
package
crd
seems
to
like
like
come
from
from
that
right
so,
and
I
think
that's
that's
very
valuable-
to
to
actually
spend
the
time
thinking
through
through
this
and
kind
of
coming
up
with
suggestions
on
how
those
custom
resources
should
actually
be
be
scoped
and
designed.
D
Yeah
and
that's
a
good
point
like
there's,
there's
a
lot
of
complexity
with
the
number
of
these
things,
and
not
all
of
them
are
strictly
necessary.
Like,
for
example,
you
could
collapse
like
the
build
custom
resource
and
the
droplet
custom
resource
into
a
single
one
like
the
droplet
could
be
like
the
actual,
like
the
status
of
that
resource,
for
example.
D
But,
like
others
like
the
package
at
a
surface
glance,
they
seem
like
they
could
be
unnecessary,
but,
like
over
here,
we've
done
a
deep
dive
into
like
all
the
calls
like
the
cli
makes
when
it's
interacting
with
the
package
and
there's
like
so
many
like
polling
calls
and
like
looking
for
state
of
a
thing
that
you
see
like
yeah
having
a
discrete
thing
for
this
is
actually
really
useful,
but
yeah,
but,
like
I
said
like
this,
is
like
for
illustration
purposes.
D
I
I
think,
as
we
actually
would
like
start
to
spike
or
like
implement
something
based
on
this.
We
would
find
opportunities
to
to
really
like
hammer
or
like
like
dive
in
on
what
the
right
abstraction
is
that
can
like
meet
our
needs,
but
also
not
be
like
super
super.
Complicated
because,
like
one
other
complexity
here
is
in
in
cloud
controller
today
like
these
are
all
tracked
in
a
relational
database
and
you
have
like
strict
relationships
between
them.
D
All
that's
easy
to
work
with,
but
these
all
are
still
related,
but
we
we
lose
the
the
strict
like
foreign
keys
and
everything.
So
there
probably
is
some
value
of
combining
them
just
for
atomicity
and
that
sort
of
thing.
F
And
from
from
your
perspective,
like
I
recall
discussions
around
in
an
ideal
world,
one
would
be
able
to
kind
of
either
use
the
cli
or
directly
create
and
manipulate
custom
resources
are
some
of
those
like
just
there
for
that
cli
use
case,
or
do
you
think,
like
everybody,
would
kind
of
create
also
these
custom
resource
type
so
to
speak
if
they
would
directly
interact
with
a
or
via
the
kubernetes
cli.
D
Yeah,
that's
a
good.
A
good
question,
like
my
my
hope,
is
that
people
who
want
to
interact
directly
like
may
use
a
higher
level
like
resource
that
we'd
have
like
either
like
an
app
manifest
one
or
or
some
some
equivalent.
D
That's
more
along
the
app
side,
and
I
don't
know
it's
it's
a
tricky
question,
because
if
you,
if
you
skip
intermediary
resources,
then
you
can't,
you
may
break
the
api
for
for
users
who
want
to
interact
with
that
app
with
traditional
cf
clients
so
like.
D
If
you
were
doing
pure,
pure
cube
cuddle
like
like
cr
manipulation,
you
could
totally
probably
skip
like
the
package
and
just
give
it
an
image
directly.
I
like
the
droplet
creation
state,
but
I
am
I'm
not
sure
how
that
might
look
for
for
the
api.
It
might
be
fine
it
like,
because
a
lot
of
those
resources
have
like
built-in,
like
pruning
and
expiration
anyway
in
cf
today,
but
but.
B
Yeah,
I
think,
like
the
the
nice
thing
about
this
diet
or
like
about
what
is
highlighted
here,
is
like
by
having
the
custom
resources
as
like
the
source
of
truth,
like,
unlike
all
of
the
previous,
like
cf,
like
cf,
for
kids
like
and
cf
on
case
projects
like
it
allows
you
the
ability
to
like
directly
manipulate
these
like
custom
resources.
If
you
want
and
have
like
direct
cuddle
access.
B
But
I
think
like
to
the
point
of
like.
Do
we
like
there
is
an
open
question
of
like
what
would
we
sort
of
want
to
set
up
as
like
expectations
for
like
the
user
on
like
what
they
want
to
manipulate
and
what
they
don't,
because
I
think
like
also
like.
Similarly,
when
you
look
at
like
a
lot
of
these
diagrams
and
like
we
look
at
like
what,
like
some
custom,
resources
might
actually
drive
the
like
creation
or
update
of,
like
other
other
custom
resources,
like
you
have
controllers
that
are
like
actuating.
B
It
like
updating,
status
fields
or
like
information
on
it,
like,
I
think
you
know.
Part
of
that.
Also,
then,
is
like
what
is
the
expectation
on
the
like
on
like
ownership?
References
right,
like
is
the
controller
actually
owning
the
update
of
that
object,
and
so,
if
somebody
tries
to
go
in
and
like
manually,
make
a
change,
will
that
be
clobbered
or
not?
B
So
I
think
like
we're
going
to
have
to
do
exploration
on
like
what
what
do
end
users
actually
want
to
be
able
to
manipulate
and
like
how
can
we
like
make
it
so
that
you
know,
maybe
they
can
use
the
api
or
the
cli
to
initially
set
up
all
of
their
resources
and
then
they're
like?
Oh,
I
want
finer
grain
control.
Is
there
like
a
flag
or
a
switch
where
they
can
say?
F
Yeah
also,
in
my
mind,
it's
probably
this
trade
off
of
like
do
you
want
to
have
a
system
that
works
optimally?
Well
with
like
the
cli,
or
do
you
want
to
have
a
system
which
looks
and
feels
nice
if
you
look
at
it
from
a
pure
kubernetes
perspective
right,
so
you
have
to
kind
of
somewhere
make
that
trade-off
between
those
those
two
extremes,
probably.
A
So
just
a
random
aside
thought
in
this
scenario.
Basically
everything
that
used
to
be
in
ccdb
now
and
ncd
has
some
crs.
Is
there
any
scenario
where
ccdb
would
live
on
as
like
a
caching
layer
for
logging,
metrics
or
something
like
moving
the
source
of
truth
to
etcd,
but
does
ccd
still
exist
somehow
or
something
similar.
B
I
think
this
is
where
you
get
like.
I
think
you
could
have
a
world
where
you
could
have
like
caching,
but
I
think
that
gets
that,
like
the
cost
benefit
of
like
how
do
you
actually
set
up
like
cashing
like
what
is
what
is
the
benefit
of,
like
you
know,
keeping
a
relational
database
around
for
that,
like
usage
versus
like
yeah,
like
the
engineering
costs
to
just
like
make
that
happen,
and
then
the
sustained
like
implementation,
like
cost
as
well.
A
Yeah
makes
sense,
I
guess
maybe
the
root
of
the
more
concerned.
Question
is:
what
is
the
difference
in
a
like
kubernetes
api
load
in
the
new
world
versus
the
current
world?
Is
it
wider
or
heavier?
What
do
you
think.
D
It
would
definitely
be
heavier
in
with
this.
I
and
an
open
question
I
have
is
how
how
much
can
we
like
leverage
like
just
like
in-memory
caching,
on
some
of
these
controllers,
to
to
mitigate
that
but
like?
D
But
the
fact
is
like
we
are
like
pushing
stuff
that
used
to
be
in
like
a
highly
performant,
like
like
my
sequel
or
postgres,
onto
a
lcd,
and
it's
it's
not
gonna
perform
to
the
same
scale
that
like
like
cf
or
vms,
used
to,
but
maybe
that's
okay
like
because
already
like.
D
We
we've
observed
that,
like
a
single
kubernetes
cluster
like
doesn't
run
the
same
amount
of
workloads
or
or
anything
as
like,
how
you
could
scale
diego's
cells
to
like
300
plus
cells,
and
that,
like
various
like
cluster
sharding
approaches
and
and
stuff,
can
be
a
mitigation
there
as
well,
potentially.
E
E
D
You
you
apply
a
manifest
and
you
can
get
one
back
out,
but
there's
nothing
in
the
database
about
like
called
a
manifest,
and
it's
it's
just
constructed
constructed
by
these
various
other
tables
as
needed,
and
it's
also
like
may
not
be
strictly
necessary
for
like
for
this
design.
We
just
felt
it
was
interesting
because
it
would
provide
like
a
one
one,
stop
cr
for
someone
to
like
declare
their
app
and
apply
it.
E
Feature
that
would
be
user
facing
for
people
that
would
end
up
just
using
the
crs
in
the
case.
C
B
B
It
sort
of
makes
this
like
the
api,
like
at
least
like
for
that
call,
could
be
like
very
straightforward,
but
also
creates
that
nice
interface
for,
like
somebody
who
maybe
is
like
more
comfortable
with
like
with
like
core
kubernetes
concepts,
to
just
directly
go
ahead
and
like
modify
the
app
manifest
cr
then,
like
feel
like
they
have
to
use
the
cli
or
api.
D
Yeah
like
and
for
me
like
one
of
the
really
nice
things
about
it
is
like
if
you
have
an
existing
cloud
foundry
with
an
existing
app
deployed.
But
you
don't
know
much
about
how
that
app
is
configured.
You
can
hit
the
generate,
manifest
endpoint
and
it
will
dump
everything
out
about
it
and
like
it
would
be
really
cool.
If
you
can
just
apply
that
or
something
similar
that
to
directly
to
to
one
of
these
and
see
it
deploy
the
same.
D
D
With
the
caveat
that
you
may
need
to
still
have
the
source
code
or
download
the
droplet
and
convert
it
or
something,
but.
E
E
Somewhere,
you
know:
did
you
cram
them
into
this?
This
degenerate
oci
image.
D
Yeah,
if
you
you
can
imagine
like,
if
you
have
permission
to
get
the
manifest
you
can,
you
can
download
the
droplet
and
and
convert
it
if
you,
if
you
wanted
to.
A
B
E
So
tim
in
the
in
the
diagram
of
resources
that
you've
got
there
like
there's
those
process
crs
with
those
maybe
like.
If
we
were
to
actually
try
to
make
this
get
realized
and
to
end
today,
like
I'm
guessing
that
irene
would
fit
underneath
that
as
a
way
to
implement
that.
D
Yeah
process
crs
this:
this
is
a
like
just
a
black
box
for
application
workload
crs
you
with
the
information
contained
in
these
three,
at
least
with
this
modeling,
the
app
the
process
and
the
droplet
cr.
You
can
create
an
ironing
lrp.
You
could
create
like
a
k-native
service.
You
can
do
what
you
want
with
it
and
like
these,
this
could
be
collapsed.
D
Maybe
it's
it's
a
little
iffier
because,
like
in
ncf,
an
app
can
have
multiple
processes
and
since
those
correspond
one-to-one
with
lrps
and
and
stuff
it,
you
could
combine
this
into
a
single
thing,
but
the
the
bookkeeping
gets
a
little
trickier
and
for
the
sake
of
just
the
diagram,
it's
it's
cleaner.
If
you
do
it
like
this.
B
Yeah,
I
think,
like
maybe
one
interesting
call
out
like
or
like
what
you
just
called
out
like
with
this
being
a
black
box,
is
really
important
of
like
just
because
like
like
the
cf
process.
Controller,
like
is
something
that
could
be
swapped
out
and
be
creating
like
any
could
be
directly
creating
like
resources
or
like
application
workloads,
but
just
as
easily
like
you
said,
like
could
be
like
actually
creating
like
an
irini,
lrp
cr,
and
then
you
have
like
the
irini
controller.
B
That
is
then,
like
you
know,
actuating
on
that
and
creating
either
stateful
sets
or
deployments,
or
you
could
like,
instead
of
have
a
different
cf
process
controller.
That
creates
like
the
k
native,
like
resources
and
then,
if
you
have
canada
deployed
on
your
cluster,
then
that
could
actually
actually
and
like
create
deployments
for
you
and
so
like
this
black
boxes
and
just
like
a
application,
workloads
are
created,
but
also
like
could
represent
like
additional,
like
resources
and
controllers
that
help
you
eventually
like
make
it
to
a
running
workload.
G
G
If
we
need
to
or
the
other
way
around,
we
can
use
the
lrp
the
the
way
the
lrp
resources
look
like,
which
has
been
informed
from
basically
being
it's
a
one-on-one
pot,
more
or
less
of
the
rest
resources
which
have
been
used
for
a
long
time.
So
that
could
be
a
way
to
request
a
starting
point
to
give
you
an
idea
of
which
information
is
needed
to
create
the
process.
G
D
Yeah
this
one
is
just
for
for
the
powering
of
the
apis.
It's
convenient
to
have
a
discrete
process
model
just
because
that's
where
the
desired
like
start
and
stop
state
of
an
lrp
actually
lives
on
the
api,
because,
like
for
an
app
all
of
its
processes,
can
be
like
mutated
independently.
D
But
yeah
like
you,
like
you
both
have
said,
though,
like
the
irene.
The
line
between
this
and
the
irony
lrp
definitely
gets
fuzzy
and
there
there
may
be
value
in
having
them
be
discreet,
things
or
or
combining
it,
and
maybe
the
lrp.
The
irony
lrp
becomes
like,
like
you,
have
controllers
built
off
of
that
and
that
those
can
either
be
the
irony
controller
or
like
other
ones.
But
it's
there's
a
lot
of
like
flexibility
here.
E
Right
yeah,
I
guess
in
in
terms
of
the
the
interfaces
that
we'd
been
discussing
in
the
vision
dock
like
we
could
still
end
up.
Having
like
the
irony
lrp,
be
the
you
know
that
that
interface
out
to
the
subsystem
potentially,
whereas
you
know
these,
these
green
resources
seem
like
they're,
much
more
closely
aligned
to
the
domain
model
that
we've
already
had
in
cloud
controller,
and
so
they'd
be
somewhat
more
user-facing
and
I
think
to
baron's
point.
E
F
F
D
Yeah
yeah,
that's
that's
it!
It's
basically
a
a
v3,
another
implementation
of
the
v3
api
that
we
would
like
build.
Iteratively.
Sorry
as
as
we
need,
but
it's
backed
completely
by
these
and.
E
And
and
just
to
be
clear,
like
we've,
we've
had
them
on
kind
of
just
a
you
know:
we're
we're
not
probably
picking
up
the
cc
code
base
and
manipulating
it
to
produce
that
this
is
probably
just
let's.
Let's
start
re-implementing
a
subset
of
cc
endpoints
and
whatever
other
services,
we
would
need
yeah
yeah.
F
I
I
think
my
my
thought
is:
could
that
work
also
somehow
benefit
the
bosch
managed
cf
world
like
one
thing,
which
would
be
probably
too
ambitious,
would
be
to
say:
hey,
let's
introduce
a
kubernetes
api
server
instead
of
the
ruby
based
cloud
controller,
all
right,
because
that
would
kind
of
probably
just
trade
one
very
huge
piece
of
technology
with
another
one,
but
like
the
the
pure
fact
that
there
is
like
a
cloud
foundry
api
or
the
subset
of
a
cloud
foundry
api.
Could
that
also
help
in
kind
of
slimming
down
the
the
bosch
managed
world?
F
G
Have
we
decided
that
this
is
going
to
be
like
a
brand
new
component
like
made
of
all
controllers
for
all
these
resources?
I
guess
so.
This
would
be
distinct
from
the
current
cloud
controller
codebase.
E
B
B
I
think,
like
I
mean
based
on
you,
know
what
what's,
what
we're
presenting
right
here.
I
I
at
least
like
do
you
see
the
benefit
in
it
being
something
like
new
versus
the
existing
like
cloud
controller
code
base,
mainly
because
I
know
like,
like,
I
think,
like
a
like
there's
a
question
on,
like
you
know
like
having
both
the
database
and
custom
resources
like
what
is
the
source
of
truth?
B
How
do
you
keep
that
in
sync,
and
then
I
think
also
when
we
talk
about
like
thinking
about
what
custom
resources
we
want
to
create.
You
know
we're
starting
by
thinking
about
like
what
are
all
of
the
objects
that
we
store
in
the
database
today
and
like
what
are
all
of
these
cloud
controller
concepts.
B
But
it's
like
I
think
tim
mentioned
earlier
and
like
we,
we
also
discussed,
was
like
how
could
we
maybe
slim
down
the
number
of
custom
resources
we
create
and
like
what
could
be
combined
and
what
needs
to
like
remain
a
distinct
resource,
and
so
I
think
that
you
also
run
into
a
challenge.
If
you
try
to
like
evolve.
B
The
existing
cloud
controller
database
to
support
both
like
cf
for
vms
and
also
like
cf
on
case
because
like
like,
because
you
know,
there's
an
expectation
on
like
what
resources
are
being
created
when
and
if
you
try
to
start
to
combine
them.
I
anticipate
you'd
run
into
problems
and
I
think,
like
also
just
generally
like
working
on
cf4
kates
and
making
changes
to
cloud
controller
like
I
think
engineers
on
the
team
have
found
that
to
be
a
pain
point,
and
so
I
think,
from
an
engineering
cost
perspective
as
well.
B
F
F
D
V3
and
and
any
like
v2s
that
are
required
for
that.
Okay,
but
yeah
I'll
know
eric,
were
you
going
to
say
more.
E
Yeah,
I
I
was
going
to
say
like
I,
I
thought
it
made
sense
to
focus
on
what
the
v7
cli
is
doing,
and
you
know,
as
you
just
mentioned,
tim
there's,
a
few
places
where
that's
still
relying
on
v2
endpoints,
I'm
guessing.
That's,
probably
not
the
case
for
some
of
those
like
app
centric
workflows.
E
I
kind
of
expect
that
to
be
all
converted
over
to
the
v3
endpoints.
At
this
point,
yeah.
D
Yeah
that
definitely
resonates
with
me.
I
think
it's
mostly
v3
at
this
point
and
like
the
one
of
the
nice
things
about
a
new.
A
new
like
component,
though,
is
whether
it's
v2
or
v3
at
a
certain
part.
That's
just
like
what
we
we
present
and
like
we.
F
Which,
which
actually
brings
me
to
to
the
question
of
obviously
there's
no
such
thing
as
like
a
service
or
a
service
binding
or
anything
like
that,
at
least
not
that
I,
I
would
have
seen
it
so
the
goal,
I
guess
for
the
initial
investigation
is
to
quote-unquote
just
push
an
app
that
that
doesn't
have
any
service
dependencies
right.
D
Yeah
like
this,
this
doesn't
touch
on
that.
We
we
have
thought
of
about
it
a
little
bit,
but
it's
I
don't
know
we
don't
have
any
good
like
diagrams
or
anything
of
what
that
might
look
like
at
the
most
basic
level.
You
could
imagine
that
services
just
get
converted
into
a
vcap
services
environment,
variable
block
on
the
app
for
for
feature
parity,
but
I
think
ideally
we'd,
like
to
like,
have
have
an
abstraction
there
like
either
this
like
kubernetes
service,
bindings
or
cloud.
B
E
Yeah
tim,
I
I
think
that's
that's
a
really
good
point
about
wanting
to
get
to
that
level
of
abstraction
that
that's
maybe
commensurate
with
what
we
have
in.
I
guess
probably,
the
v3
cc
api,
where
those
are
represented
as
as
distinct
entities,
and
then
you
know
we
could
keep
rejecting
them
as
vcap
services,
but
I
I
think
also
you
know
as
that
gate's
service,
binding
spec
has
been
emerging.
B
Yeah,
I
think
we've
been
focusing
like,
as
highlighted
by
like
what
we've
been
talking
about
so
far
in
these
diagrams,
so
much
unlike
the
cf
push
and
just
like
main
application
workflow.
But
I
think,
like
it's
definitely
like.
It's
definitely
important
to
also
be
thinking
about
services,
since
most
apps
rely
on
that,
and
so
like.
C
E
I
wonder
if
a
good
starting
point
for
that
could
even
be
like.
You
know
what
would
even
like
a
user-provided
service
instance
and
a
binding
to
that
look
like
then
we
could
probably
get
away
without
a
lot
of
the
complicated
machinery.
That's
currently
in
controller
that
interacts
with
all
of
the
actual
service
instance
lifecycle,
management
and
and
get
to
focus
a
little
more
nearly
on
the
binding
part
which
is
going
to
be
probably,
you
know
one
of
the
most
relevant
pieces
for
that
developer.
E
And
then
it
would
it
would.
You
know
it
certainly
initially
would
like
give
people
on
at
least
an
avenue
to
be
binding
those
services
in
a
more
structured
way.
Even
if
the
cf
api
tickets,
shim
isn't
handling
the
all
the
rest
of
the
service
life
cycle.
D
Yeah
and
those
services
are
part
of
an
app
manifest.
We
have
a
google
doc
somewhere
that
has
like
a
straw,
dog
implementation
of
that,
which
I
I
believe
they
we
just
had
it
like,
create
some
kubernetes
secrets
that
would
store
the
user
provided
service
and
then
they'd
have
a
label
or
some
something
binding
them
to
to
the
app,
and
it
like
at
least
conceptually
made
sense.
But.
C
E
Well
cool
this
is
this
has
been
really
great,
really
appreciate
getting
this
picture
of
what
y'all
have
been
thinking
about
for
the
last
little
bit
cool,
I'm.
E
D
E
D
All
right,
I'm
gonna,
share
again
there's
some
there's
some
boxes
over
here.
This
part
is,
is
definitely
a
little
fuzzier,
but.
D
We're
thinking
about
how
we
can
project
like
the
oregon
and
space
permissions
hierarchy
onto
kubernetes,
name
spaces
and
and
our
back
and
and
potentially
other
policy
mechanisms
like
again
a
direct
like
api
mapping
would
have
like
an
org
and
potentially
a
space
cr
and
like
you,
could
you
could
build
out
controllers
that
would
look
for
these
and
and
those
would
reconcile
them
and
make
the
necessary
name
spaces
and
and
are
back
as
you
assigned
user
roles
and
stuff,
but
like
you
could
also
perhaps
just
like
leverage
namespaces
directly
and
get
fancy
with
with
labels
or
or
use
higher
hierarchical
namespaces.
D
Once
once,
that's
ready
to
do
to
do
so,
we
haven't-
I
don't
know
it
would
be
nice
to
like
spike
out
some
of
this
probably
and
like
flesh
out
this
diagram,
some
more.
But
this.
This
is
how
we're
thinking
about
that
problem.
D
And
and
like
this,
the
existing,
our
back
will
work
well
for
things
that
operate
like
like
roles
that
are
like
okay.
You
have
full
access
to
like
this
app
because
it
is
within
a
space
you're
a
space
developer
on,
and
so,
if
you
are
like
in
a
name
space
that
corresponds
with
that
space,
and
you
have
our
back
that
says,
you
can
like,
create
and
update
that
app
like
that.
Will
work
fine
it.
It
gets
a
little
trickier
if
there
are
like
permissions
that
affect
a
sub
like
field
on
a
resource.
D
One
of
those
that
I
can
think
of
is
like
app
environment
variables,
like
certain
roles,
can
view
everything
about
an
app
except
as
environment
variables,
for
example,
so,
like
that
either
could
it
could
still
work
in
this?
If
you
just
like
modeled
that
as
a
separate
resource,
maybe
or
as
like
secrets-
and
you
don't
have
permission
to
view
those
secrets
or
like
we
could
use
like
open
policy
agent
or
something
and
and
get
fancier
and
say
I
I
don't
know-
I
I
think,
there's
there's
a
lot
of
options
there.
D
But
but
we
we
at
least
we
at
least
believe
that
if
we
can
model
get
a
name
space
corresponding
to
a
cf
space,
then
we
we
can
do
a
lot
of
what
we
need
to
do.
E
D
Yeah
like
to
be
honest,
separating
it
out
like
having
your
environment
variables,
be
a
secret.
That's
referenced
by
the
app
is,
has
a
lot
of
benefits
too.
Just
because,
like
assuming
you
set
up
your
secrets
right,
such
that
they're
encrypted
at
rest
and
stuff.
It's
probably
better.
You
have
that
in
a
secret
and
not
just
floating
as
part
of
the
app
cr.
So
I
I
think
there's
like
stuff
like
just
by
virtue
of
doing
things
correctly.
You
can
then
just
have
your
rbox
say
like
no.
E
You
know
telling
how
many
widgets
per
hour
to
make
or
something
and
but
some
of
those
you
know,
I
think
we
have
seen
end
up
being
more
confidential
configuration,
whether
that's
you
know
some
sort
of
authentication
parameter
to
a
service
or
something
like
that.
That
still
needs
to
be
encoded
as
an
environment
variable
because
it
doesn't
fit
into
the
surface
binding
model
cleanly
and
so
yeah.
That's.
E
E
E
F
E
Cool
yeah
thanks
thanks
again
for
sharing
and
for
putting
all
that
together
to
give
give
us
all
an
overview.
E
B
B
That's
when
you
discover
maybe
some
like
differences
in
like
expectations,
and
so
maybe
like
we
can
talk
about
like
you
know
what
we
think.
The
next
steps
are,
so
that
we
get
feedback,
but
we
also
keep
making
progress
towards
the
shared
vision.
E
Yeah
I
mean
maybe
some
things
that
would
be
useful
would
be
yeah.
I
know
we
we
were
talking
pretty
informally
and
just
going
over
the
mirror
board.
I
don't
know
if
it'd
be
reasonable
to
start
publishing
some
things
on
cf
dev
just
for
wider
broadcast
and
commentary.
E
Maybe
that's
that's
something
that
we
could
discuss
over
the
next
week
or
so
because
I
yeah.
I
think
that
that
is
then
getting
to
that
next
level
of
having
some
shared
artifacts.
That
would
encourage
that
discussion
and
then
alignment.
F
Maybe,
as
a
kind
of
more
mid-term
topic,
I'm
also
kind
of
putting
putting
quite
some
some
hopes
in
the
to
be
established
technical
oversight
committee.
So
I
think
like
when
we
published
the
vision
document.
I
came
across
people
who,
like
them
basically
said
where's.
That
document
I
didn't
even
see
it
and
so
maybe
like
a
more
formal
process
as
something
where,
like
things
are
more
visible.
F
So
I'm
kind
of
hoping
that,
like
via
establishing
the
toc,
such
discussions
could
be
also
kind
of
tracked
more
more
formally
in
the
future,
but
obviously
like
what
what
eric
said
for
now.
Publishing
the
the
artifacts
by
cfdef
is
obviously
the
right
thing
to
do.
E
F
E
Think
that
that
definitely
makes
sense
in
terms
of
some
process
that
the
forthcoming
toc
should
consider,
and
I
think
also
if,
if
anyone
is
interested
in
certainly
everyone
here
should
be
eligible
to
vote
in
the
toc
election.
But
if
you're
interested
in
serving
on
the
toc,
then
certainly
if
you're
from
vmware
talk
to
me
and
angela
and
well,
you
know,
I
think
the
voting
process
that
we
have
for
the
toc
seats
doesn't
mean
that
we
need
to
be
particularly
coordinated
in
nominating
those.
E
B
E
Yeah
there
there
is,
I
think,
it's
been.
It
hasn't
been
very
widely
publicized,
but
I
think
it's
in
the
cloud
foundry
org
at
this
point,
there's
a
cfar-proposals
repo
that
people
have
used
occasionally
to
try
and
track
and
coordinate
some
proposals
via
issues
that
are
related
to
the
cfap
runtime
I'll
drop
a
link
into
the
chat
so.
E
E
I
will
drop
a
link
into
that
in
chat
for
the
folks
here
it
has.
It
has
not
been
heavily
used.
Although
I
see
piali
created
an
issue
on
it
for
some
of
our
back
changes.
E
All
right,
well,
yeah,
sounds
good
for
next
steps
to
be
starting
to
put
more
thoughts
about
architectural
options
down
on
virtual
paper
and
to
be
circulating
them
yeah.
So,
okay,.