►
From YouTube: Cloud Foundry CAB Call March 16 2022
Description
Recording of the Community Advisory Board held on March 16th 2022. We hosted Onno Brouwer and the conversation was centered around Open Service Broker API.
What was the discussion about?
Onno and their team are using Cloud Foundry and Kubernetes along with OSBAPI. The Service Brokers allow their developers make use of services outside these platforms. Their (impressive) lineup of brokers include Concourse provisioning, Sharepoint connectors, PostgreSQL integrations, etc. They have a lot of success and the project itself is a wonderful technical accomplishment. Onno also has some questions that he would like to air freely. These include – activity around OSBAPI, alternatives, and others.
Who is Onno?
Onno is a senior advisor at Rijkswaterstaat in The Netherlands, where he operates their cloud native platforms since December 2015. Onno has over 25 years of software engineering experience, designing and building software in various languages and environments. His current interest cloud native applications architecture and design. Onno is an experienced speaker, and has presented internal workshops and trainings for topics such as Cloud Foundry, networking, traffic analysis, and security. Onno also held talks at past Cloud Foundry summits in Basel and The Hague, KubeCon, etc.
A
Good
evening,
everyone
welcome
to
the
march
edition
of
the
cloud
foundry
community
capcom.
So
this
is
a
monthly
sort
of
community
gathering
that
we
have
that
we
devote
to
specific
topics,
but
it's
more
on.
It
happens
as
we
go,
so
we
don't
have
something
very
concrete,
scheduled,
but
interesting
events
in
the
month
tend
to
surface
during
this
call.
A
So
just
a
few
quick
community
updates
before
we
move
on
to
like
the
mainstay
of
today's
call,
which
is
going
to
be
around
service
brokers
and
honor,
is
going
to
be
presenting
some
of
his
experience.
Some
of
his
you
know,
wins
and
just
spawn
a
conversation
around
service
brokers.
Today,
by
way
of
community
updates
the
cloud
foundry
foundation,
which
is,
I
guess,
chris
and
I
is
more
appropriate
way
to
put
it.
A
A
A
A
And
he's
here
to
you
know,
see
the
conversation
about
service
broker,
so
this
presentation
came
to
be
from
one
of
his
appearances.
I
guess
in
one
of
the
working
group
calls
and
he
wanted
to
like
chat
a
bit
about
service
groups
and
things
like
that,
and
I
thought
this
would
be
a
good
opportunity
to
bring
some
very
experienced
cloud
foundry
community
members
to
just
hear
what
he
has
to
say,
try
and
see.
A
If
we
can
answer
some
questions
and
we're
also
joined
by
marcella
and
ruben
and
eric
who
are
all
fairly
involved
with
the
service
brokers
stuff
in
the
past
in
the
present-
and
you
know
in
the
future
too,
I
guess
so
it
would
be
great
to
get
their
perspective
in
terms
of
you
know,
whatever
engineering
and
non-engineering
implications,
our
conversations
might
have
so
without
further
ado.
Oh
no!
The
stage
is
all
yours.
Okay,.
D
D
D
Okay,
let
me
see
from
the
beginning:
okay
yeah.
Well,
I
guess
maybe
some
of
you
have
seen
me
before
have
attended
at
three
sea
of
summits
in
the
past.
Basel
philadelphia
and
the
hague.
Dennark
also
did
a
presentation
for
two
out
of
three
and
last
year
also
first
time
attended
cubecon
as
a
presenter.
D
That
was
more
talking
about
how
we
used
open
source
within
alexanderstadt.
So
if
people
are
interested
to
know
more,
I
can
yeah
provide
some
links
to
the
presentation.
But
if
you
just
google
me,
then
I
guess
you
can
easily
find
it
in
the
playlists
yeah
how
this
came
to
be.
Actually,
this
is
a
slightly
adjusted
presentation
from
the
internal
workshop
I
organized
some
time
ago
for
our
cloud
native
application
team.
We
manage
both
cloud
foundry
and
kubernetes
platforms
within
regular
start
and
yeah.
Well,
as
everybody
knows,
you've
got
applications.
D
You
can
push
on
the
platform
but
yeah.
The
whole
paragraph
paradigm
is
something
like
stateless
applications,
so
you
need
state
stored
somewhere,
and
for
that
you
need
services.
So
I
decided
to
create
a
workshop
to
tell
the
new
people
about
yeah.
What
is
this
all
about?
What
is
this
marketplace
thing
everybody
is
referring
to,
and
how
do
you
manage
things,
and
especially,
how
do
you
introduce
new
services,
which
is
the
main
focus
of
this
presentation
and
well
topics?
Basically,
I
want
to
talk
about
cloud
foundry
and
community
services
yeah.
D
D
I
basically
wanted
to
make
sure
that
the
whole
team
would
be
kind
of
aligned
on
the
model
we
see
within
cloud
foundry
and
how
it
all
works
out.
Some
sayings.
I
had
to
learn
the
hard
way.
So
that's
why
I
put
these
slides
together
as
well
to
get
everybody
online
cloud
foundry.
Well,
as
everybody
knows,
who
has
ever
seen
a
cloud
foundry,
there
is
like
this
multi-tenant
setup,
where
you
have
organizations
which
is
like
a
ten
entries
in
the
cloud
foundry
environment
within
organizations.
D
That's
the
app
stack,
you
might
say
on
the
right
side
on
this
picture.
We
also
have
the
surface
deck.
The
marketplace
is
basically
a
collection
of
all
surfaces
provided
by
surface
brokers
and
each
surface
advertises
one
or
more
surface
plants
and
then,
of
course,
the
developer
doing
all
his
cell
servicing
the
famous
safe
push.
Experience
can
create
and
bind
surface
instances
to
applications.
D
D
D
D
D
Well,
everybody
who
has
worked
with
cloud
foundry
probably
already
knows
this,
but
for
me
the
the
contrast
between
cloud
foundry
and
kubernetes.
Well,
that
was
kind
of
new.
We
are
doing
kubernetes
for
a
few
years
now,
but
putting
a
surface
broke
on
kubernetes
and
how
that
would
work
out
what
would
be
the
equivalent
of
the
marketplace?
D
D
D
D
D
Proscenium
from
the
surface
plants
again,
a
developer
can
use
the
sv
cut
cli,
it's
a
command
line
tool.
You
can
download
with
a
similar
kind
of
experience,
as
with
the
cfc
li
to
to
create
and
bind
surface
instances
only
in
this
case,
we
don't
directly
bind
to
an
app,
but
we
basically
create
a
secret
which
is
exposed
to
a
bolt
and,
in
the
end,
that's
how
a
pot
an
application
can
connect
to
a
surface
instance.
D
D
To
to
yeah
to
do
to
build
service
brokers,
you
need
yeah
some
kind
of
standards.
Well,
anybody
who,
who
knows
the
open
service
broker
api
knows
the
website
knows
what
it's
all
about,
but
yeah.
Like
I
mentioned
in
the
beginning,
this
is
basically
to
get
the
team
up
to
speed.
I
gave
them
the
reference
to
the
the
page.
D
Basically,
service
brokers
manage
the
life
cycle
services.
You
can
create
them,
you
can
delete
them,
you
can
update
them,
but
that
all
depends
on
the
functionality.
The
broker
offers
not
all
service
instances
or
surface
types
can
also
allow
binding
apps
to
to
surface
instances.
That's
entirely
up
to
the
broker
which
functionality
is
actually
implemented.
D
D
D
D
D
Similarly,
when
you
create
a
surface,
you
provide
a
surface
a
plan,
an
instance
in
the
surface
catalog
on
kubernetes.
They
don't
really
talk
about
surfaces
but
but
about
surface
classes.
Well,
I
guess:
what's
in
the
name,
it
would
do
a
put
and
in
case
of
a
database,
for
example,
it
would
create
a
database.
This
is
just
an
example
of
one
particular
broker.
It's
entirely
up
to
the
broker.
What
exactly
happens
here.
D
Binding
and
unbinding:
well,
you
have
to
bind
surface
and
the
unbind
surface.
Well,
I
won't
go
into
reading
the
text
here.
This
is
all
I
guess,
obvious
and
well
known
to
everybody,
but
just
for
completeness
sake.
I
put
the
examples
here
what
the
database
might
do
if
you
try
to
bend
and
bind
an
app
to
a
to
a
database
and
what
what
would
happen
if
you
remove
the
binding.
D
D
D
Now
we
have
a
platform
and
we
want
service
brokers.
So
as
part
of
the
workshop,
the
students
had
to
build
and
deploy
their
own
broker.
Well,
as
everybody
knows,
with
foundry
cf
push
experience
yeah,
building
an
app
and
putting
it
on
the
platform.
That's
well!
You
take
the
repo
here.
I
clone
it
from
from
github,
for
example,
or
gitlab,
and
the
other
famous
safe
push
experience
and
then
assuming
there's
a
manifest
in
your
repo,
etc
and
all
set
up
properly.
Then
you've
got
your
running
app
in
our
case,
a
service
broker.
D
Then,
of
course
you
need
to
register
it.
The
naming
of
the
commands,
I
sometimes
find
interesting.
It
says,
create
service
broker.
Well,
yeah.
Okay,
the
broker
is
already
running,
I'm
basically
trying
to
register
it.
But,
okay,
it's!
I
guess
the
way
the
conventions
were
decided
and
then
also
after
you
create
it.
D
You
need
to
enable
access.
First
time
I
tried
this.
I
thought.
Oh
okay,
I
create
the
broker
and
now
it's
in
the
marketplace,
yeah.
It
was
in
the
marketplace
because
I
was
admin,
so
I
could
see
everything
and
then
the
dev
start
complaining.
I
don't
see
it
and
then
show
me
your
screen
and
oh,
it's
not
in
your
marketplace,
but
it
is
in
mine
and
then
I
had
to
learn
the
hard
way.
Oh,
you
need
to
enable
access,
otherwise
nobody
can
use
it,
but
that's
easy
enough
now
kubernetes
well.
D
This
was
for
me
where
the
real
learning
started.
Okay,
I've
got
the
repo
with
my
source
code
of
my
broker.
I
need
to
somehow
build
an
image
put
it
in
a
registry,
for
example.
However
harbor
so
I
found
a
nice
presentation
by
pivotal
about
cloud
native
buildbacks
and
I
thought
okay
I'll
give
it
a
try.
Basically
from
the
command
line,
do
pack
build
and
I
did
get
a
runnable
image
that
was
pretty
cool
because
it
was
the
very
same
code
source
code
I
used
for
building
the
broken
type
foundry
using
pack.
D
I
could
get
it
up
and
running
on
kubernetes
without
any
changes
in
the
source,
and
that
was
pretty
pretty
cool
and
interesting.
I
did
not
expect
it
to
be
that
easy
to
get
something
running
on
kubernetes
now
there
are
other
ways
of
doing
this.
You
can
use
automated
builds
but
builds
that
I'm
not
sure
how
to
put
it.
You
can
automate
the
building
process.
You
can
use
kpec,
so
use
kubernetes
itself
to
to
to
detect
changes
in
a
repo
and
build
things.
D
There
are
build
surfaces,
you
can
combine
it
with
concourse,
there's
multiple
ways
of
building
stuff
but
yeah.
For
me,
this
was
the
easiest
to
show
and
explain
about
what
actually
happens
when
you
build
a
container
image
using
cloud
native
buildbacks,
but
there
are
other
ways
of
doing
it,
but
of
course
we
still
need
to
put
it
on
the
platform.
D
D
D
That's
basically
in
a
nutshell,
what
you
would
need
to
do
to
get
a
broker
up
and
running
on
the
community
side
and
register
it
and
do
basically
what
on
the
cloud.
Foundry
was
a
much
easier
approach,
but
it's
not
unworkable.
But
to
me
it
looks
like
many
steps
to
to
execute,
and
then
you
already
should
know
what
you're
supposed
to
do
at
each
step.
The
first
time
trying
to
figure
this
out
took
me
a
while,
let's
say.
D
D
More
interesting
what
we
were
doing,
what
what
kind
of
brokers
were
we
building?
I
mean
the
marketplace
we
had
with
our
cloud.
Foundry
platform
already
had
a
lot
of
services
like
reddish,
rabbit,
mq,
mysql,
autoscaler,
scheduling,
spring
cloud
spring
spring
cloud
frameworks
and
stuff
like
that,
but
we
needed
some
some
some
some
customization
there.
D
D
We
had
a
proxy
which
could
talk
to
sharepoint
the
so-called
sharepoint
connector
to
proxy
applications,
traffic
to
sharepoint.
It
had
a
nice
gui
to
create
api
keys
and
link
applications
to
sharepoint
collections.
The
only
problem
was
nobody
wanted
to
manage
it
because
nobody
felt
they
should
manage
other
people's
applications,
so
basically
they
gave
it
to
us
like
hey,
guys,
you're
the
platform
owners.
You
take
care
of
this
thing.
D
Well
that
wasn't
really
not
what
we
had
in
mind.
We
want
we
promote
self-service,
so
we
try
to
let
developers
do
their
own
magic
without
involvement
from
the
platform
team
as
much
as
possible,
because
we
are
a
quite
small
team.
We've
got
hundreds
of
applications
running
and
we
can't
facilitate
each
and
every
app
developer
team,
so
we
try
to
promote
as
much
self-service
as
possible.
D
So
basically
we
built
a
service
broker
generating
those
api
keys
and
also
creating
the
sharepoint
file
collections,
because
before
we
had
this,
we
had
to
go
to
the
sharepoint
team,
create
a
ticket
and
let
them
create
file
collections.
So
basically
we
ask
them.
Can't
you
give
us
a
service
account,
so
we
can
automate
it
so
now
the
devs
could
self-manage
the
apps,
but
basically
the
end
result.
We
shot
ourselves
in
the
food
making
the
problem
from
the
deaths
managing
an
app
basically
making
it
our
problem.
D
I
think
in
the
end,
we
should
have
refused
to
take
this
kind
of
ownership,
because
the
proxy,
if
somebody
should
manage
it,
it
should
have
been
managed
by
the
sharepoint
team.
Not
by
us.
We
are
not
sharepoint
knowledge
holders.
We
we
we
use
sharepoint,
but
we
cannot
really
maintain
it
and
that's
in
general
applicable
to
any
kind
of
broker.
If
you
have
a
broker
delivering
a
service,
I
think
the
party
most
knowledgeable
about
how
the
broker
should
operate
and
be
managed
is
actually
the
team
managing
the
surface
being
broken
concourse.
D
D
D
Well,
we
started
odds
with
this
like
three
years
ago.
Four
years
ago,
20
well
yeah.
That's
almost
five
years
ago.
Already
at
that
time,
the
documentation
for
concourse
was
not
really
very
clear
on
how
to
create
and
manage
teams
and
how
to
access
permissions.
Who
can
do
what
and
now
it's
much
better,
but
at
the
time
it
was
like.
Okay,
maybe,
but
we
better
create
those
teams
automatically
and
let
the
broker
handle
it.
D
So
we
used
a
pre-existing
broker
and,
with
some
bit
of
tuning,
we
got
it
to
work
on
our
platforms,
basically
create
an
org
team
when
you
did
create
service.
So
if
your
orc
was
called
wm
water
management,
they
would
get
a
team
called
wm
on
concourse
and
they
could
log
in
with
cf
authentication
on
concourse
and
they
could
do
whatever
they
wanted
to
do.
D
So.
Anybody
who
had
developer
permissions
within
the
space
where
the
instance
was
deployed
could
manage
concourse
teams
could
couldn't
manage
their
own
team
and
could
manage
pipelines.
There
were
some
problems.
I
only
found
much
later.
I
found
out
about
much
later
the
default
permission
when
you
use
concourse
anybody
who,
who
uses
and
manages
concourse
probably
knows
already
this,
but
for
us
it
was
an
interesting
lesson.
Learned
default
permission
was
to
be
the
owner
of
the
team
which
allowed
any
member
to
change
team
permissions,
including
removing
themselves
from
access
to
the
team.
D
They
could
lock
themselves
out
or
even
delete
the
whole
team,
and
also
this
happened
to
us
at
least
twice
that
we
know
of
if
a
space
developer
sees
a
surface
instance
in
a
space
running.
All
by
itself,
with
not
any
apps
bound
to
it.
Oh
okay!
Maybe
I
watch
this
concourse
ci
service
instance
in
myspace.
It's
not
bound
to
an
app,
let's
delete
it.
Anybody
can
imagine
what
would
happen
there.
D
The
broker
says:
oh,
I
have
to
remove
the
team.
Okay,
let's
delete
the
team
from
concourse,
so
it
deleted
the
theme
and,
of
course,
deleted
all
pipelines
and
build
history.
So
yeah.
That
was
a
case
where
maybe
a
broker
ultimation
is
not
always
a
good
thing,
so
we
decided
in
the
end.
Maybe
we
should
not
use
a
conquest
broker
at
all
and
basically
find
another
way
of
doing
automation,
some
some
feedback
on
that
how
to
best
handle
this
kind
of
scenarios
would
be
also
very
much
appreciated.
D
D
So,
basically
we
moved
to
open
source,
my
sequel,
but
the
boss,
deployment
of
machik
mysql
using
mariadb
and
calera's
cluster
software
at
some
point
a
few
years
ago.
It
was
no
longer
being
being
updated,
they
moved
to
parcona
later
on,
but
there
was
not
really
a
broker
available
for
it,
so
we
were
kind
of
stuck
with
how
to
proceed
and
also
we
are
not
really
database
engineers.
We,
we
don't
have
any
dba
experience
yeah.
D
We
basically
know
how
to
build
a
query
and
stuff
like
that,
but
but
yeah
as
a
platform
team,
we
already
got
our
hands
full,
managing
cloud,
foundry
and
kubernetes
platforms,
and
we
decided
we
better
go
somewhere
else.
In
our
case,
a
postgres
was
the
main
database
technology
used
within
rxman
stats.
So
we
thought.
Okay,
let's
meet
this
up
with
our
database
team.
Let
them
provide
the
service
and
then
we
can
install
a
broker
to
connect
to
the
external
database.
D
Basically
deploying
a
database
is
easy.
I
mean
I
can,
for
example,
download
a
help
chart
or
an
operator
installed
on
kubernetes,
and
then
I've
got
my
database
up
and
running,
but
yeah.
Maintaining,
updating
it,
backup,
restore
monitoring,
there's
a
lot
of
stuff.
You
need
to
do
around
it
and
we
think
that's
best
handled
by
the
people
who
actually
have
knowledge
about
the
product.
D
Unfortunately,
or
actually,
fortunately,
I
should
say
there
were
many
brokers
on
the
internet
in
java,
golang
and
other
languages
available,
but
none
of
them
seem
to
really
do
what
we
wanted
to
do
in
a
cloud-native
way.
Manage
postgres
service
instances
allow
multiple
apps
bind
to
the
same
instance.
Sometimes
it
would
overwrite
credentials
if
we
tried
that
or
it
was
not
able
to
to
create
a
second
binding
at
all
or
ownership
of
database.
D
Contents
became
a
problem
and
one
user
went
away
another
one
showed
up,
so
we
had
to
talk
to
our
database
experts
and
find
out
a
way
to
to
make
it
work
for
everybody.
The
way
they
expected
to
work
and
also
some
use
cases
were
not
possible.
With
the
way
the
broker
was
functioning,
we
had
to
actually
add
state
tracking
for
applications,
because
some
use
cases
like,
for
example,
allowing
a
single
account,
a
single
binding,
you
might
say,
access
to
multiple
instances.
D
D
That
was
pretty
easy,
relatively
speaking,
implementing
the
correct
business
logic
actually
decides
what
a
broker
should
do
and
and
how
to
how
to
make
it
work
for
all
use
cases
that
that
that
that
took
most
or
of
our
time
to
to
get
this
completely
correct.
Let's
say,
and
ideally,
I
strongly
believe
that
ownership
of
the
broker
should
be
live.
Is
the
service
team
because
they
know
best
how
to
implement
this
kind
of
business
logic.
D
Basically,
we
have,
for
example,
a
multi-part
multi-site
setup
in
two
data
centers
with
both
production
and
acceptance,
and
we
also
have
a
test
environment,
of
course,
and
each
environment
gets
its
own
cluster,
its
own
database
cluster.
But
at
some
point
we
noticed
that
the
more
apps
land
on
the
cluster
we
run
out
of
connection
they
mets.
D
D
D
D
D
When
luke
and
eminem
look
at
the
website
for
the
open
service
broker
api
and
also
the
service
catalog
project
on
kubernetes.io,
they
don't
seem
to
have
a
lot
of
things
happening
recently,
especially
the
service
catalog,
which
is
basically
deprecated
using
kind
of
beta
implementation
of
api
calls,
and
after
we
would
upgrade
our
kubernetes
projects
or
clusters,
I
should
say
it
would
no
longer
work
for
us.
We
saw
people,
cloning,
the
project
and
making
their
own
fixes,
but
I
basically
I'm
wondering
like:
is
there
a
way
forward?
Is
that
still
healthy?
D
Are
there
other
solutions
popping
up
which
basically
outdate
or
make
these
solutions
obsolete?
That
would
be
my
main
question
to
the
community.
How
is
the
osb
ipi
and
how
is
the
service
catalog
projects?
How
are
they
doing?
Do
you
need
help
or
how?
How
can
we
make
sure
we
can
move
forward
with
this?
I
think
this
is
a
pretty
cool
technology,
but
yeah
I
get
the
feeling
focus
shifts
elsewhere.
E
Thank
you
for
presenting
this.
Oh,
no
and
hi
everybody,
I'm
rodrigo,
and
I'm
from
the
osb
api
team,
I'm
part
of
the
committee.
I
I
agree
with
you
that
not
I
can
talk
about
the
osp
part
and
if,
if
folks
have
more
questions
and
different
things,
we're
going
to
talk,
please
chime
in.
I
agree
with
you
that
nothing
has
really
happened
on
the
osb
space
recently,
but
I
can
guarantee
you
that
at
least
on
salesforce
I
worked
for
salesforce
previously
on
heroku.
I
can
guarantee
you
that
we
are.
E
This
is
how
salesforce
is
planning
to
move
forward
sharing
service
internally
and
I'm
really
curious
on
on
the
aspects
of
their
marketplace.
We
can
talk
offline.
What
I
can
say
about
the
osb
communities
is,
it
is
alive.
I
I
I
would
love
to
have
your
contributions
to
to
the
repo,
if
you
think
anything
should
change
on
the
spec.
I
I
would
be
happy
to
to
have
this
conversation.
E
I'm
I'm
working
with
marcela
to
to
get
back
to
a
triage
program
to
to
the
to
the
issue,
so
we're
trying
to
do
a
bi-weekly,
triage
and
reviewing
prs.
So
it
is
alive.
It's
just
not
it's
not
as
as
vibrant
as
it
was
a
couple
a
couple
years
ago,
and
you
are
right
that
people
end
up
moving
on
to
different
things.
E
What
I
can
say
about
the
service
catalog
is
that
people
end
up
implementing
the
their
own
version,
and
I'm
talking
about
companies
like
sap,
even
salesforce
heroku
had
its
own
version
at
some
point
because
of
the
the
limitations
we
had
on
on
the
service
catalog
project,
I'm
not
really
involved
to
this
project.
Marcel
I
mentioned
constantine.
I
had
a
conversation
with
constantine
before,
but
I'm
not
really
up
to
date
on
what
is
what
is
there?
E
E
D
Oh,
I
can.
I
have
some
questions
on
that
because
I
it
seemed
to
me.
I
don't
know
what
was
the
breaking
point,
but
when
I
look
back
in
the
history
of
the
cf
summit,
I
think
2019
that
philadelphia.
I
guess
that
was
to
me.
It
looked
like
the
one,
the
last
one,
which
kind
of
had
a
lot
of
content
related
to
osb
api.
I
found
a
lot
of
presentations
there.
A
lot
of
projects
like
like
I
saw
pivotal
presenting
something
like
okay,
this
marketplace.
D
D
I
forget
what
it
was
called,
but
that
project
seemed
also
to
have
discontinued
somehow.
So
it
was
to
me
like
oh
what
happened
to
all
these
interesting
ideas
and
and
talks,
and
when
I
try
to
look
back
and
find
the
projects
they
usually
seem
to
have
discontinued
or
archived
and
yeah
that
that
kind
of
surprised
me
here,
there
was
a
lot
of
good
ideas
out
there,
but.
E
I
agree
I
can
give
you
some
context
in
the
end
of
2019.
We
had
a
osp
api
summit
and
it
happened
here
in
new
york.
Some
folks
from
cloud
foundry
came
some
folks
from
london.
Some
folks
from
the
pivotal
office
was
here
too,
and
we
had
a
very
deep
conversation
about
the
future
of
osp
api.
This
was
end
of
2019,
beginning
of
I
believe
it
was
beginning
of
2020,
because
just
after
that
pandemic
hits.
So
this.
A
B
E
E
So
that's
one
of
the
reasons
why
this
specific
one
went
down
after
the
pandemic
as
well
because
of
the
the
conditions
people
end
up,
moving
to
different
teams
and
different
products,
and
they
left
the
osb
api
space.
I
I
continue
working
because
in
heroku
this
is
strong
to
heroku.
It
started
at
heroku,
basically
with
the
add-on
interface.
E
So
in
heroku
it's
it's
highly
highly
strategic
and
it's
same
for
salesforce
salesforce
recognized
that
and
it's
investing
heavily
on
this
culture
of
sharing
services.
So
I
think
we
can
get
this
back
back
again.
You
know,
if
there's
enough
interest,
I
I
saw
that
you
posted
on
the
osb
slack
channel
if
there's
enough
interest,
if
you
know
people
that
will
be
interested
in
even
joining
the
committee,
because
today
we
we
are
lacking
people
that
are
part
of
the
committee
that
can
approve
prs
that
are
responsible
for
issues.
E
D
D
E
Yeah
you're
right
this,
this
end
up
being
dropped
from
the
calendar.
We
we
switch
the
person
that
was
responsible
for
creating,
we
created
a
new
calendar
event
and
it
got
dropped
and
the
community
one.
In
any
case,
I
would
love
if
you
could
share
this
presentation
with
me.
I'm
on
that
track
that
you
you
sent
on
the
the
osp
api
is
lack,
and
I
would
be
happy
to
collaborate
with
you
async
and
and
talk
more
about
the
the
marketplace,
the
specification
that
I
have
in
mind
and
in
the
future.
E
Folks
from
the
call
I
intend
to
come
to
this
call
often
so
I
will
try
to
to
keep
attending
and
watching
what's
the
interest
on
the
osp
api,
how
people
are
using,
and
maybe
we
can
even
merge
the
efforts
on
this
call-
I've
been
in
contact
with
marcella.
She
understands
what
we
we
are
trying
to
do.
So
I
look
forward
to
join
more
often
this
call
cool.
E
G
D
H
H
A
H
D
Sure,
okay,
I
was
just
like,
is
it
a
coincidence
or
because
yeah
I
I
think
there
was
I
I
do
remember.
I
don't
know,
was
that
dr
nick,
who
had
a
talk
about
oh
yeah,
you
can
just
use
an
existing
cloud,
funnel
use
the
marketplace
and
just
hook
up
to
the
using
reusing
the
brokers
running
on
cloud
foundry
from
your
kubernetes
environment.
D
D
I
think-
and
I
don't
know-
maybe
it
was
just
me,
but
I
got
the
feeling
that
the
number
of
people
small
battle
in
philadelphia
already
philadelphia
to
me,
looked
like
a
huge
environment,
with
a
small
number
of
people
sitting
in
the
middle
middle
of
a
huge
room
and
also
no
more
t-shirts
being
handed
out.
I
thought.
Oh,
this
must
be
a
problem
of
lack
of
sponsorship
and
then
I
was
like,
oh
my
god
it
will
there
be
a
summit.
Will
there
be
a
summit
and
yeah
yeah
yeah.
D
H
I
We
we're
talking
to
the
board
about
some
kind
of
event
this
year
and
we're
not
quite
sure
what
it'll
be,
but
you
know
it
is
correct
that,
like
before
the
pandemic,
it
was
probably
decided
that
we
would
go
from
a
standalone
two-day
cf
summit
to
like
a
one-day
co-located
event
with
open
source
summit
for
coupon
and
so
we're
discussing
that
for
this
year,
because
I
think
you
know
pandemic
billing.
You
know
knock
on
wood
later
this
year.
It
might
be
time
to
get
back
out
there.
So
disgusting.
A
I
A
D
It's
not
the
same
yeah
I
really
meeting
in
person
that
doesn't
quite
compare
to
doing
virtual.
I
remember
last
year
I
did
a
q
com
the
first
time
I
did
a
virtual
presentation
like
this
and
then
I
thought.
Oh,
it
went
smoothly.
It
went
well,
we
had
to
pre-record
the
whole
thing
and
then
I
was
watching
the
recording
and
being
played
back
live
and
the
first
thing
my
wife
and
daughter
said
hey.
Why
are
you
rocking
your
chair,
you're
zooming,
in
zoom
out
your
camera?
D
D
I
I
D
C
It
won't
sparkle.
Well,
I
don't
know
if
I
was
aware
of
all
the
dlc
efforts
that
have
been
going
on
so
there
there
have
been
like
that.
We
have
now
there
half
year
ago
or
something
the
dlc
was
formed
with
members
from
the
sap,
vmware
and
cloud.gov,
and
they
are
from
working
groups.
So
we're
now
like
really
cleaning
up
the
whole
cloud
foundry
or
trying
to
identify
which
projects
are
actually
being
maintained
and
which
are
not
and
making
people
responsible.
D
There's
some
mail,
like
somebody
going
to
pick
up,
straddles
and
mills
like
that
yeah
and
I
I
did
join
a
working
group
meeting,
but
I
don't
I'm
not
sure
if
I
was
supposed
to
be
there,
but
everybody
gracie
allowed
me
to
join,
but
they
were
in
the
middle
of
reorganizing
the
whole
thing
on
how
we
are
handling
approvals
and
stuff
and
to
me
it
sounded
like.
Oh,
we
are
just
in
the
middle
of
reorganizing
things,
so
yeah.
C
H
F
A
Yep,
on
that
note
to
everybody
else,
who's
listening
we're
making
efforts
to
keep
the
community
calendar
up
to
date.
So
if
there's
any
meetings
of
interest,
please
do
visit
the
calendar
and
take
a
look
at
all
the
stuff
that
we
have
on
there.
And
you
know
everybody
is
welcome,
don't
be
a
stranger
and
yeah.
Thank
you
very
much
ono.
Thank
you
for
presenting
and
sharing
ideas
and
sort
of
you
know
respawning
interest
in
this
whole
services.
A
Efforts
like
like
ruben
and
all
of
the
others
mentioned
a
lot
of
work
is
going
on
and
cleaning
this
up
and
making
it
more
active,
and
you
know
generally
improving
the
overall
activity
around
these
things.
So
time's
up.
So
thanks
again,
everybody
for
joining.
You
know
see
you
next
month
on
the
same
call,
and
hopefully
we
have
an
interesting
presentation
then
as
well
bye-bye
thank
you.