►
From YouTube: Cloud Foundry CAB Call recording June 2022
Description
The agenda for the call is as follows:
‣ Korifi updates
‣ Korifi Architecture discussion
‣ TOC Election results
‣ Cloud Foundry Event
A
We
have
a
bunch
of
very
interesting
updates
from
the
community
so
for
those
who've
been
following
closely.
It's
been
a
year
since
we
elected
the
inaugural
technical
oversight
committee
and
we've
had
the
opportunity
to
conduct
the
first
election
to
fill
in
seats
that
we
are
now
starting
to
rotate
and.
A
A
B
Eric
malm
from
vmware
and
stephen
marker
from
sap
will
continue
on
for
another
year,
they're
still
on
the
on
board,
and
their
seats
will
be
up
for
election
one
year
from
now.
So
yeah
I'll
share
that
more
widely
with
the
community
later
today,
but
just
figured
we'd
give
you
an
update
on
that
now
so
congrats
to
everyone
who's
now
on
the
tlc.
A
A
A
Obviously
that
also
means
that
we
have
to
cram
in
like
a
lot
of
different
tracks
and
different
segments
to
the
event
which
we're
all
in
sort
of
the
planning
phase
right
now.
So
as
soon
as
we
know
the
date
and
as
soon
as
we
nail
down
some
of
some
other
logistics
about
the
event
itself,
we'll
be
sending
out
notifications
about
cfps
about
getting
some
papers
and
submissions
in
from
the
community.
A
A
A
A
A
A
B
I
know
we
should
know
great
confirmation
and
get
a
date
in
the
next
couple
of
weeks,
certainly
by
the
first
week
of
july,
so
really
look
forward
to
that.
It's
hard
to
share
a
ton
of
details
until
you
know
the
day
of
but
yeah,
I
would
recommend.
I
mean
I'd
love
to
see
if
any
people
come
as
can
so
I
would
recommend
you
know,
checking
out
hotels
sooner
rather
than
later.
B
A
A
A
We
sort
of
labeled
this
as
our
beta
release
and
we
put
some
pressers
out.
We
had
a
lot
of
social
media
information
out
about
this
and
we
ran
like
a
bunch
of
different
efforts
to
create
some
awareness
about
the
tool.
Now,
since
then,
a
few
things
have
changed
I'll
go
into
some
of
the
details
during
this
call
about
what
are
some
of
the
sort
of
big
changes.
A
A
A
This
you
know,
sort
of
is
like
the
main
diagram
that
represents
the
tool
itself.
So,
as
you
can
see
here,
it
illustrates
that
there's
you
know
a
client
that
actually
connects
to
the
service
and
then
this
service
is
basically
triggering
two
kinds
of
workloads.
So
there's
a
run
workload,
but
before
that
I
guess
there's
a
build
workload
which
actually
takes
the
code.
A
Does
the
conversion
into
an
image
puts
the
image
on
our
container
registry
it's
here
and
then
the
run
workload.
You
know
grabs
it
from
here
and
puts
it
on
the
container
runtime.
So
the
community
is
hard
at
work
documenting
all
of
this
information
and
building.
You
know
some
images
and
some
resources
that
people
can
make
use
of
to
understand
this
better.
So.
A
The
reason
that
I
wanted
to
bring
this
up
during
the
call
today
is
twofold,
a
obviously
to
communicate
the
architecture
of
gurifi
itself
and
b
to
see
if
you
know
there
are
folks
who
are
listening
here,
who
want
to
jump
in
on
some
non-code
contributions
and
learn
this
better
document
it
better
or
help
improve
whatever
documentation
and
that
we
have.
You
know
I
just
wanted
to
welcome
such
contributions
as
well.
A
The
architecture
basically
identifies
four
resources
here
that
are
of
you
know
more
significance
than
the
rest.
I
guess
so.
The
first
one
is
the
api
deployment
crd.
So
I
have
also
opened
like
a
canines
here
that
is
sitting
over
a
query
fee
somewhere
in
the
back,
so
some
of
these
things
you'll
be
able
to
actually
visually
see
and
verify
as
we
talk
about
them,
and
so
this
is
like
the
set
of
pods
that
are
running
as
part
of
a
curry
fee
deployment.
A
The
next
sort
of
big
piece
is
the
build
and
the
run
segments
of
the
whole
curry
fee
deployment,
and
both
of
these,
I
guess
anybody
who
has
some
idea-
I
guess
of
projects
such
as
k
native,
will
obviously
see
the
congruence
here
and
understand
that
there
are
very
similar
sort
of
steps
that
the
query
fee
team
takes
as
well,
so
the
build
workload
obviously
takes
takes
care
of
the
build
process.
Where
you
know
the.
A
A
Contour
is
the
ingress,
I
think
the
cf
for
kate's
project,
which
was
there
previously
made
use
of
istio.
I
think
a
lot
of
research
has
gone
into
why
car
and
consequently
envoy,
is
a
much
more
appropriate
solution
and
if
folks
are
interested
in
reading
a
little
bit
about
that,
I'm
happy
to
show
where
they
can
and
finally,
service
bindings
are
taken
from
the
kubernetes
project
as
it
is,
and
it's
basically
with
some
of
the
services
that
are
needed,
and
things
like
that.
A
A
So
is
is
a
slightly
more
in-depth
discussion
about
three
areas,
I'll
start
from
the
bottom,
because
it
represents
like
a
rather
significant
deviation
from
before
so
cloud.
Foundry
on
vms,
typically
used
droplets
and
they've
moved
away
from
these
droplets
for
corifi,
and
instead,
like
I've
mentioned.
I
guess
a
few
times
on
the
call
before
a
oci.
A
Compatible
container
image
is
what
is
exported.
This
oci
image
is
put
on
a
container
registry,
which
I
think
is
again
something
that
folks
are
quite
used
to
as
a
paradigm
when
using
docker
it
was
like
docker
hub
is
a
container
registry
and
you
could
download
images
from
there
and
then
use
them
for
deployment.
So
it's
maintaining
sort
of
that
same
workflow
and.
A
A
A
Piece
of
this
whole
architecture
is
the
way
multi-tenancy
is
being
implemented.
So
for
the
first
version,
a
significant
amount
of
effort
went
into
creating
I
using
hierarchical
namespaces,
which
is
again
a
kubernetes
sig
project,
so
hnc,
which
stands
for
hierarchical
name.
Space
controller
is
the
name
of
the
project
and
I
guess
hierarchical
name
spaces
with
what
are
known
as
sub
name.
Space
anchors
were
made.
Use
of
for
this.
A
So
I'll
go
into
some
details
now,
because
there's
no
sort
of
argo
space
in
this-
it's
not
visible,
but
that's
essentially,
where
I
expect
it
to
be
so
sub
name.
Space
anchors
made
it
possible
to
implement
the
cf
definition
of
an
org
spaces
within
the
orgs
and
so
on,
because
kubernetes
has
a
flat
sort
of
notion
of
name
spaces.
They
do
not
allow
nesting,
name
spaces,
and
so,
whereas
you
know
cloud
foundry
at
the
first
instance
of
the
first
step
itself
requires
an
org
and
a
space
within
the
arm.
A
It's
been
documented
in
significant
detail
here,
so
there
is
a
spike,
I
guess
much
more
than
a
spike
right
now
that
has
gone
into
creating
a
permissions
model
that
mimics
the
cloud
foundry
permissions
model
and
to
make
use
of
a
native
sort
of
cf
ish
controller
in
order
to
implement
these,
as
opposed
to
going
the
hierarchical
name
spaces
way.
So
this
document
has
in
detail
what
the
limitations
were.
A
So,
if
folks
are
willing
to,
if
folks
require
more
information,
you're
more
than
welcome
to
take
a
look
at
this,
so
I
guess
the
goals
for
this
migration
are
to
produce
something:
that's
more
lightweight
and
reliable,
while
also
reducing
the
dependency
on
something
that
you
know.
Another
open
source
team
is
working
with,
and
I
guess
the
third
rather
more
important
thing
here
is
about
authentication,
and
so
this
is
all.
A
This
also
represents
a
significant
deviation
from
how
cfcli
for
vms
actually
work,
so
corifi
makes
use
of
native
kubernetes
authentication,
so
anytime,
you
sort
of
want
to
log
in.
I
guess
I
could
demo
that,
but
anyhow
I
every
time
you
want
to
log
in
it
makes
use
of
the
same
interface
that
you
would
when
you
use
like
cubectl,
so
it
will
recycle
the
authentication.
A
From
the
kubernetes
cluster,
whatever
it
is
that
you're
using-
and
so
I
think
this
diagram
does
a
good
job
of
explaining
what
the
overview
of
the
auth
looks
like
and
there's
some
more
information.
But
if,
if
folks
want
to
again
learn
more
about
this,
so
but
then
what
I
wanted
to
highlight
is
it
it's
a
rather
significant
deviation
from
the
way
cloud.
Foundry
did
it,
and
even
from
the
way
that
cf
for
kids
was
doing
auth.
A
A
A
Using
image
formats
is
available
here,
and
one
of
the
reasons
I
like
to
refer
to
these
is
they
always
provide
like
a
context
from
the
cf
for
vm's
world.
So,
if
you're
used
to
like
bosch
based
stuff,
you
can
get
the
context
and
the
delta
is
also
highlighted.
Now,
like
I
mentioned,
here's
a
another
document
that
provides
the
reasons
for
why
the
team
picked
contour
and
envoy,
as
opposed
to
any
of
the
others
that
were
here.
So
all
of
these
are
also
documented
again
linked
from
the
main
sort
of
architecture.
A
A
That
is
that's
all
I
had
for
show
and
tell
if
folks
have
any
questions
comments,
feedback,
I'm
happy
to
take
them
on
there's,
also
like
a
bunch
of
other
resources
that
are
in
the
works
and
as
we
start
to
release
these
I'll
share
links
to
them
on
the
slack
as
appropriate,
but
yeah.
That's
it
for
now,
thanks
for
listening
and
I'm
happy
to
take
any
questions.