►
From YouTube: Cloud Foundry CAB Call recording Aug 2022
Description
Matt Royal from VMware gave a talk on RunWorkload and BuildWorkload which are both a part of Korifi.
Korifi, as you have all heard, is a Cloud Foundry interface for Kubernetes clusters. Matt is a regular contributor to the project and has agreed to share some valuable insights about the internals that power the tool.
Date: 17th August '22
Day: Wednesday
Time: 8 AM Pacific/11 AM Eastern/4 PM London
GitHub: https://github.com/cloudfoundry/korifi
Slides: https://docs.google.com/presentation/d/1RAWVT3sAkzfhcJiDLlSWmjGiVhQWaO6GOCGvevs1Bf0/edit?usp=sharing
A
B
B
B
Last
dates
for
cfp
submission
are
a
little
over
a
week
away.
We
have
about
10
days
to
go
so
if
you're
interested
in
submitting
a
cfp
to
the
cloud
Foundry
Day,
you
have
about
10
days
to
do
that,
and
we
all
typically
tend
to
do
this
in
the
last
week.
Last
couple
of
days
last
day,
what
have
you
but
we'll
send
out
a
few
email
reminders
about
this,
but
be
aware
that
the
last
date
is
quickly
approaching.
B
There's
also
a
call
for
volunteers
to
be
part
of
the
program
committee.
Another
program
committee
is
a
set
of
three,
maybe
four
individuals
who
are
part
of
the
CF
Community
who
get
to
choose
what
tracks
get
chosen
for
the
stage
at
Cloud
Foundry
Day.
So
we
have
a
an
expression
of
Interest
open
for
those
who
might
want
to
participate
in
that
I'm
going
to
leave
the
link
to
the
form
in
chat.
B
So
if
either
you
are
interested
in
joining
this
or
if
you
know
folks
who
might
want
to
be
part
of
this,
please
share
the
link
with
them
or
you
know,
fill
in
the
form
herself.
So
we're
definitely
going
to
need
to
incentivize
this
so
we're
thinking
of
a
few
ways
of
how
to
do
that.
But
anyhow,
if
you're
interested
in
being
part
of
the
cfp
committee
that
gets
to
choose
the
proposals,
then
please
do
fill
the
form.
If
you
know
folks
who
you
think
might
be
a
good
fit
share
it
with
them.
B
So
those
are
the
big
updates
that
I
had
so
today
we
have
a
matte
Royal
with
us.
Matt
joins
us
from
somewhere
exotic
on
the
west
coast
of
the
United
States,
so
he's
going
to
talk
a
little
bit
about
karifi
architecture.
So,
like
a
lot
of
you
folks
already
know,
karifi
is
the
cloud
Foundry
project
that
basically
aims
to
build
the
cloud
Foundry
experience
to
deploy
to
kubernetes
clusters.
We've
had
many
successes.
B
In
the
past
few
weeks
and
months
we
reached
a
couple
of
Milestones,
so
we
are
at
version
0
to
0.2
right
now
you
know
inching
our
way
towards
stability
and
towards
production,
Readiness,
slowly
and
steadily,
but
yeah.
So
obviously,
architecture
and
internals
are
a
lot
of
interest
to
many
folks
in
the
community
and
in
particular,
if
you
combine
like
the
cloud
Foundry
world
and
the
kubernetes
world,
it
makes
for
a
lot
of
interesting
discussion.
So
Matt.
Why
don't
you
kick
us
off
for
discussions
about
query
fee
internals
foreign.
C
I'm
in
San
Francisco,
as
Ron
said
it's
a
little
early
for
me,
so
I
apologize
in
advance
that
I
yawn
once
or
twice
but
I.
So
just
the
the
structure
I
had
in
mind
for
this
is
I've
got
just
a
deck,
just
to
kind
of
do
a
high
level
overview
of
the
changes
we
made
and
just
kind
of
give
us
some
structure
to
talk
about,
and
then
I'm
just
going
to
open
the
floor
for
questions
and
answer
any
questions
that
people
might
have.
C
C
So
some
of
the
ways
it's
different
is
you
know
we're
not
reusing
the
ruby-based
cloud
controller.
We
have
a
re-implementation
of
the
cloud
Foundry
API
in
golang.
We
aren't
backed
by
a
database
we're
using
custom
resources
in
the
kubernetes
API
to
represent
all
of
the
cloud
Foundry
nouns
and
it's
kind
of
a
bring
your
own
auth
situation.
So
you
know
anything
that
can
off
against
the
kubernetes.
Api
can
auth
against
karifi
no
UAA
anymore.
C
C
C
C
So
you
build
your
image
with
the
Capac
image
we
the
droplet
out
of
that,
and
then
we
run
your
app
instances
with
staple
sets.
The
the
work
we're
talking
about
today
added
this
new
abstraction,
these
new
abstractions.
Rather
these
new
the
build
workload
and
Formerly
Known
does
the
the
Run
workload
but
now
called
the
app
workload,
and
these
are
just
resources
that
include
all
the
information
you
need
to
implement
either
of
those
workflows.
C
C
These
sort
of
sub
projects
there's
a
Capac
image
Builder,
which
does
what
it
sounds
like
and
the
state
full
set
Runner,
which
also
does
what
it
sounds
like
now.
The
the
goals
of
this
work
were
to
basically
to
make
it
possible
to
to
plug
in
different
Behavior
right,
and
we
wanted
to
to
minimize
the
difficulty
of
doing
that
and
make
it
as
simple
as
possible
right.
C
So
that's
the
the
rationale
between
behind
putting
all
the
information
in
one
resource
and
having
using
that
kind
of
exclusively
for
communication
between
karifi,
and
these
alternative
implementations
also
want
to.
We
wanted
to
create
a
very
clear
separation
between
karifi
and
these,
so
that
we
didn't
have
to
know
the
details
of
the
underlying
architecture
for
how
you're
building
your
image,
how
you're
running
it.
C
This
is
some
where
we,
we
still
have
some
room
for
improvement,
but
we're
actively
working
on
it
and
in
the
short
term,
we
only
intend
to
have
on
a
given
deployment
to
have
one
component.
That's
actively
doing
the
building
one
components
that
act,
that's
actively
doing
the
running
in
the
future.
We
may
add
support
for
having
multiple,
concurrent,
Builders
and
Runners,
where
you
know
you
dynamically
dispatch
to
one
or
the
other.
C
C
So,
as
I
mentioned,
you
know,
we
use
custom
resources
for
all
of
our
our
nouns
instead
of
periphy,
so
we've
got
the
CF
build.
The
creation
of
that
by
the
API
indicates:
hey
we've
got
this
building
we
want
to
run.
It
turns
out
that
a
lot
of
information
goes
into
generating
a
build.
So
the
controller
part
of
karifi
correlates
all
the
information,
that's
necessary
from
the
build
itself
from
the
package.
You'll
get
the
source
location,
for
example,
from
that
any
credentials
that
need
to
be
in
there
from
service
bindings.
C
C
I,
don't
think
it's
worth
like
going
through
all
the
keys
necessarily,
but
we
can
just
do
a
quick,
quick
overview.
You
can
see
that,
like
for
the
the
build
workload,
you've
got
information
about
all
the
environment,
variables
that
need
to
be
available
in
you
know,
in
the
same
format,
you
would
have
on,
for
example,
like
a
pod
container
in
kubernetes.
C
You've
got
information
about
where
to
actually
pull
the
source
and
the
credentials
you
need
to
do
it,
and
then
the
status
of
the
result
gets
communicated
back
here
right
so
like
this
was
a
successful
build,
and
so
it
succeeded-
and
you
have
the
information
about
where
to
pull
the
the
image
actually
from
under
droplet
here
and
also
what
processes
are
on
and
which
commands
to
run.
So
you
know
this.
C
C
D
C
So
you
know
you
can
imagine
that
if
we
do
want
to
support
deployments,
we
can
write
an
alternative
Runner
that
just
has
the
logic
or
our
deployments
and
decide
not
to
deploy
with
the
staple
set
Runner
and
we've
pretty
pretty
cheaply
supported
a
different
workflow
without
a
lot
of
engineering
work.
So
that
was
part
of
the
thought
process.
C
A
To
remember
the
vision
document
I
think
that
we
had
I
think
even
before
in
starting
the
implementation
and
like
one
of
the
goals
of
this
new
project
was
to
make
a
specific
functionalities
pluggable
both
so
that
this
could
be
useful
to
as
many
for
as
many
use
cases
as
possible,
but
also
to
avoid
like
re-implementing
stuff.
So
one
thing
we
decided
is,
you
know,
authentication.
A
We
delegate
that
networking
we
work
against
well-known
interfaces
instead
of
providing
our
own
implementation
and
so
I
think
it
was
only
natural
to
do
the
same
for
for
runtime
for
building
I
can't
remember
if
there
were
other
interfaces
that
we
haven't
covered,
but
yeah
I
think
the
the
main
ones
were
networking
runtime,
building
off
so
yeah.
This
means,
because
if
you
can
build
with
all
sorts
of
backlines
and
can
run
stuff
with
all
sorts
of
packets,.
D
A
Yeah
so
I
guess
someone
could
Implement
a
builder
based
on
that
then,
oh,
like
just
more
simply,
for
example,
at
the
moment
we
don't
support
Docker
files,
but
like
another
Builder
could
just
build
based
on
dockerfile,
or
you
know
there
might
be
many.
There
might
be
many
use
cases
support
for
you
know
at
the
moment
we
support
the
specific,
build
packs
like
Cloud
native,
build
packs,
who
knows
tomorrow
and
some
something
new
comes
out.
That
is
interesting
or
better.
We
can
just
plug
it
in
yeah.
A
I'm,
the
default
implementation
uses
jobs
so
again,
Same
Same
Spirit,
like
the
default
implementation
uses,
kubernetes
built-ins,
tries
to
be
as
cheap
and
straightforward
as
possible
and
and
they're.
All
lots
of
this
is
at
least
inspired
by
the
previous
ABD
implementation,
so
we've
basically
replaced
the
mini
types
with
these
new
types
that
are
a
bit
more
I
would
say,
straightforward
to
use
a
little
bit
cleaner,
removed
some
craft
in
the
process
and
managed
to
also
get
rid
of
our
dependency
in
the
process.
C
C
B
We
can
probably
get
the
slides
out
to
folks
as
well,
so
I'll
follow
up
with
you
on
that,
but
in
general
thanks
for
the
talk,
it
was
really
useful
and
I.
Think
the
more
we
talk
about
these
architectures
and
some
query:
Primitives
the
better
territory
be
for
people
who
are
trying
to
build
an
understanding
about
the
project,
so
yeah
thanks
and
yeah.
Thank
you.