►
From YouTube: Crossplane Intro And Deep Dive - The Cloud Native Control Plane... - Jared, Matthias & Nic, Bob
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Crossplane Intro And Deep Dive - The Cloud Native Control Plane Framework - Jared Watts, Matthias Luebken & Nic Cope, Upbound; Bob Haddleton, Nokia
Speakers: Jared Watts, Nic Cope, Matthias Luebken, Bob Haddleton
The maintainers of Crossplane, a CNCF Incubating project, will lead this session that will introduce the project to new attendees, as well as dive into the finer details of Crossplane’s functionality and roadmap. We will explain how Crossplane enables you to compose cloud infrastructure and services into your custom platform APIs, and how best to get started building a platform of your own. We will take a tour through the key features included in the latest releases, what problems and use cases they are solving, and how you can adopt them into your control planes. Finally, there will be an interactive opportunity to engage with the maintainers, ask questions, and influence the future of the project direction.
A
All
right,
so
this
is
going
to
be
the
cross
plain
introduction
and
deep
dive,
but
I
got
a
bit
of
a
combination
of
material
here
to
hopefully
satisfy
all
different
folks
with
their
exposure
to
Cross
Plains.
So
far,
so
my
name
is
Jared
and
then
we
also
have
Nick
Bob
and
Matthias.
Here
we
all
contribute
to
the
cross-plane
project
in
one
way
or
another
all
right.
So,
let's
start
with
the
intro
stuff
here
first,
so
you
know
when
you
think
about
what
cross
plane
is
the
best
way
to
think
about
it.
A
Is
that
it's
a
framework-
and
you
can
use
this
framework
to
build
a
cloud
native
control
plane?
The
intent
is
that
you
can
do
that
in
a
declarative
way
that
you
don't
have
to
write
any
code.
You
can
write
code
if
you
need
to
you
know
to
do
more
custom
scenarios,
but
hopefully
you
can
do
this
All
in
a
declarative
way
and
end
up
with
a
cloud
native
control,
plane,
So
speaking
of
control
planes.
A
You
know
the
cloud
providers
they've
obviously
been
using
these
they've
been
building
control
planes
and
using
them
to
manage
their
infrastructure
for
years.
You
know
control
plane,
isn't
a
Brand
New
Concept,
but
now
with
cross
plain,
though
we're
hoping
to
enable
you
to
be
able
to
build
your
own
control
plane
and
put
your
own
opinions
into
it.
So
if
you
think
about
the
core
cross-plane
functionality
and
the
Machinery,
you
know
there's
two
major
extensibility
areas
to
it.
So
it's
on
the
back
end.
A
Crossway
is
extensible
to
be
able
to
basically
anything
that
has
an
API.
You
know
all
sorts
of
cloud
infrastructure.
Let's
say
you
can
teach
cross-plane
to
manage
that
infrastructure
in
any
environment.
So
that's
the
extensible
back
end
and
then
on
the
front
end.
You
have
a
extensibility
story
for
being
able
to
compose
together
infrastructure
and
then
surface
that
to
your
application
developers
with
your
own
abstraction.
You
know
to
expose
the
configuration
fields
and
knobs
that
you
want
to
and
basically
help
your
developers
have
self-service
abilities
to
provision
their
own
infrastructure.
A
All
right.
So
you
know
this
is
a
cncf
project
right.
This
is
the
maintainer
track.
This
is,
you
know,
it
is
a
community
project,
and
so
we
think
of
it
as
a
neutral
place
for
people
to
come
together
and
enable
and
move
forward
control
planes.
So
this
Project's
been
around
for
a
little
bit.
We
first
open
sourced
it
back
in
late
2018..
A
We
are
the
same
folks
that
created
The
Rook
project
as
well:
storage,
orchestration
for
kubernetes,
so
some
of
you
may
be
familiar
with
that
as
well,
and
then
a
little
bit
of
History
We've.
We
donated
it
to
the
cncf
at
the
sandbox
level
like
middle
of
2020,
and
then
we
got
to
the
by
the
end
of
2020,
where
at
our
stable
first
V1,
stable,
Milestone,
declared
it
ready
for
production
usage
and
then
by
the
late
2021
we're
at
the
incubation
level.
A
Just
last
week
we
released
our
latest
release,
which
is
the
v1.10
release,
so
the
Crossbay
Project's
still
moving
and
making
progress,
and
then
our
next
thing
that
we've
got
our
sights
on
is
sometime
in
early
2023.
We
want
to
be
moving
to
the
full
graduation
with
the
cncf.
We
will
need
your
help
on
that,
the
whole
community
and
ecosystem
and
we'll
talk
about
that
a
little
bit
later.
A
So
you
know
stats
numbers.
The
biggest
thing
for
this
here,
for
me,
is
the
number
of
contributions
for
people
right.
We've
got
lots
of
people
in
this
room
that
have
been
contributing
to
the
project,
writing
code,
opening
issues,
giving
feedback,
and
this
project
does
nothing
without
the
community
behind
it
all
right.
So,
let's
start
with
some
the
basic
functionality
of
managed
resources
in
cross-plane,
so
we
talked
about
you
know:
cross-plane
can
manage
any
infrastructure
in
any
environment.
A
An
example
of
this
here
is:
let's
talk
about
AWS,
so
AWS
has
something
like
I,
don't
know:
700
800
services
that
they
offer
they've
got
a
whole
lot
of
stuff,
a
lot
of
great
Engineers
building
a
lot
of
cool
stuff.
So,
basically
you
know
using
crossblain
you
can
represent
and
bring
all
of
those
Cloud
infrastructure
and
services.
Anything
with
an
API.
You
can
bring
that
into
the
kubernetes
control
plane
and
manage
it
provision
and
create
all
that
infrastructure
from
kubernetes.
A
So
you
know
networking
databases,
certificates,
cues,
caches,
buckets
whatever
all
that
sort
of
stuff
you
can
from
the
kubernetes
control,
plane
provision
it
and
manage
it,
and
so
how
do
we
do
that?
We'll
probably
like
you
expect?
We
represent
all
of
these
cloud
provider
resources
and
you
know,
infrastructure
Etc
as
objects
in
the
kubernetes
API.
So
what
we're
looking
at
here
on
the
screen
is
a
kubernetes
API
object
with
crossplane.
A
That
represents
an
S3
bucket,
so
you
know
just
like
any
other
kubernetes
objects,
such
as
a
deployment
pod
config
map,
whatever
it's
got
a
spec
where
that
takes
in
the
desired
State
all
the
configuration.
How
do
you
want
to
create
this
bucket?
You
know
you
can
specify
all
that
that
desired
State
and
the
spec
of
this
bucket
object
and
crossblane
will
make
that
happen
for
you.
Similarly,
you
know
with
oh
yeah.
So,
similarly,
with
you
know
the
common
shape
of
kubernetes
API
objects,
they've
got
a
spec
for
desired.
A
State
they've
got
a
status
for
some
of
that
actual
State
The
observed
State
too
right,
so
everything
is
going
to
be
represented
with
both
spec
and
Status.
So
we
observe
things
in
the
cloud
provider
apis
or
whatever
infrastructure,
crossbones
watching
and
then
surfaces
that
back
up
as
status
fields
and
then
just
like
many
good
API
objects
in
kubernetes
they'll
generate
events
as
well.
That
tells
the
story
of
that
infrastructure.
How
did
it
get
provision?
Okay?
Did
it
run
into
an
issue?
Is
it
operating
healthy,
etc?
Those
events
will
tell
you
the
story.
A
Okay
and
then
just
a
quick
implementation
detail
here.
So
this
probably
works
exactly
how
you
would
expect
it
to
work
as
well
so
you've
on
the
left
of
the
screen.
Let's
go
left
to
right.
You've
got
an
API
object,
a
manifest.
You
know,
whatever
that
represents
an
Amazon
RDS
database
and
so
you've
got
the
spec
there
you're
specifying
some
of
your
desired
configuration
desired.
State
you
apply
that
to
the
kubernetes
API
server.
A
You
can
do
that
with
Cue
control
apply
or
you
can
do
that
with
you
know,
get
Ops
methodology
but
flux
Argo,
whatever
it
gets
applied
to
the
API
server.
There's
a
specific
controller.
That's
you
know
for
Amazon
RDS,
that's
watching
the
API
server
gets
an
event
sees
that
somebody
is
requesting.
The
creation
of
an
RDS
database
and
then
it
uses
the
Amazon,
the
AWS
API,
to
talk
to
AWS
and
actually
make
that
desired.
State
of
an
RDS
database,
you
know
actual
makes
it
happen
in
the
real
world.
A
So
that's
a
bit
of
the
architecture
and
then
one
more
detail
on
that
is
this
Tech
stack
here
so
from
the
Autumn.
You
know
we're
building
this
is
building
on.
You
know
the
kubernetes
runtime
kubernetes
API
Machinery
right
and
then
you
know,
on
top
of
that,
the
controller
runtime
is
what
we
use
to
more
quickly:
accelerate
the
how
we
build
controllers
in
Cross
plain:
we've
got
a
lot
of
nice
functionality
there
that
helps
us
Implement
reconciliation
of
cloud
provider,
resources.
A
On
top
of
that,
we've
built
a
opinionated,
specific
cross-plane
runtime
that
helps
further
accelerates
the
implementation
of
controllers
and
Reconciliation
of
managed
resources,
cloud
provider,
resources,
infrastructure,
stuff,
you
know
within
crossplane
and
then
the
top
layer
or
all
the
controllers.
For
you
know,
RDS
dynamodb,
you
know
gke,
whatever
all
those
resources
they
each
have
a
controller.
That's
built
on
this
stack,
so
I'll
go
ahead
and
pass
it
off
to
my
colleague
Matthias.
Now,
to
talk
about
the
next
bit
of
functionality
in
Cross
plain.
B
All
right
so
so
far,
what
Jared
has
been
talking
about
is
getting
the
API
of
something
like
an
S3
bucket
res
instance,
what
you
name
it
also
other
Cloud
providers
into
your
system.
Then
the
next
level
is
that
we
want
to
compose
them
together.
So
we
want
to
enable
building
your
own
platform,
a
platform
API
right,
so
that
is
using
the
existing
granular
resources
and
composing
them
to
you
know
something
bigger
something
that
you
as
you
want
to
offer
to
your
developers.
This
can
be
for
multiple
clouds
right.
B
That
is
like
a
typical
example
and
it's
higher
level
apis,
and
these
can
be
any
anything
right.
That's
on
your
decision.
We
have
a
couple
of
examples,
but
I
guess
you
know
it's.
It's
also
up
to
the
community
to
come
up
with
good
examples
and
I
know
that
some
folks
talked
to
yesterday
is
like
oh
I.
Have
this
very
opinionated
version
of
it?
Like?
Is
anyone
interested
and
it's
like?
B
Yes,
we
are
interested
in
these
right
because
we
need
to
as
a
community
learn
on
how
we're
building
these
so
there's
you
compose
these
into.
You
know
higher
level
apis
and
offer
them
as
a
single
API
to
the
developer,
which
we're
going
to
see
in
a
second.
This
is
all
the
lucrative,
and
so
there
is
lots
of
yaml
fun.
B
So
conceptually
you
can
think
about
this,
like
you
know,
high
level
like
this
right,
we
have
like
these
managed
resources
that
Javed
has
just
talked
about
and
they
all
are
bundled
into
a
provider
right.
So
they
have.
You
have
this
AWS
provider,
gke
gcp
provider
and
Etc,
and
then
you
compose
them
together,
but
you
offer
this.
B
You
offer
the
API
with
an
xrd
and
the
developer
claims
it
with
a
specific
typed
claim
that
you
that
you
have
defined
so
just
as
one
example
right
so
a
developer
would
say,
I
would
like
to
have
a
small
postgres
instance,
and
this
you
know
is
defined
how
this
looks
like
in
the
xrd
and
here's.
We
have
a
like
specific,
AWS
composition
that
you
know
takes.
You
know,
configures
it.
How
you
as
a
platform
developer,
would
put
it
together.
B
B
You
know
with
a
usual
ways
of
doing
it
and
you
have
a
standard
open,
API,
a
V3
schema
where
you
define
on
how
this.
How
your
API
looks
like
on
the
composition
slide
is
then
is
like
okay.
How
does
it
actually
work
right?
So
I
said
like
as
an
example,
this
would
be
the
AWS
example.
So
you
take
the
list,
you
you
take
all
the
managed
resources
that
you
want
to
compose
into
a
high
level.
Api.
You
reference
the
xrd
that
your
that
this
composition
works
for
and
yeah
you.
B
You
get
all
the
compositions
all
the
managed
resources
together
and
you
need
to
propagate
information,
and
we
do
this
by
this
patching
mechanism,
and
there
you
have,
you
know,
ways
of
propagating
the
information
and
transforming
the
information.
This
is
the
current
way
of
doing
it,
and
Nick
is
going
to
show
in
a
minute
a
new
way
of
also
doing
this,
like
yeah
in
different
ways.
B
So
this
is
about
compositions
right,
and
these
are
the
two
things
that
you
need
to
do,
but
obviously
you
don't
want
to
do
all
this
by
hand.
You
want
to
use
existing
packages
existing
extensions,
so
you
know,
if
you
think,
about
extending
cross
plane.
There's
currently
two
ways.
Two
major
building
blocks
that
that
that
are
relevant
cross
plane,
as
Jared
has
said,
is
an
extensible
framework.
So
we
have
two
building
blocks
that
you
that
that
you
can
reason
about
the
first
one
is
as
a
provider
there's.
B
B
The
second
part
is
configurations
and
that's
where
we
are
using
existing
providers,
so
you
have
some
kind
of
dependency,
a
way
of
saying:
okay,
I
need
one
multiple
providers,
and
then
you
bundle
all
the
compositions
that
we've
seen
before
into
its
own
package,
and
that
way
you
have
like
a
single
Deployable
unit
that
you
can
hand
over
that.
You
can
reason
about
that.
You
can
collaborate
on
of
how
you
would
use
a
specific,
a
specific
API
and
how
you
know
share
that
share
that
with
others.
B
Now
both
both
packages
are
just
oci
images,
so
there's
a
spec
behind
it,
but
it's
basically
just
a
yaml
layers
and
an
oci
image
and
yeah
there's,
there's
a
nice
spec
around
it.
If
you're
interested
in
that
we've
got
a
pretty
good
provider
ecosystem,
we
have
many
providers
from
the
community
there's
you
know
daily,
there's
something
new
coming
and
we
have
just
launched
a
Marketplace
and
that
is
open
for
everyone.
So
from
about,
we
have
specific
providers
that
we
offer,
but
we
are
not
getting
this
in
any
way
right.
B
So
this
is
open
for
the
community.
So
if
you
have
a
provider
and
or
if
you
think
about
a
provider,
please
come
to
me
talk
to
me
we're
happy
to
help,
and
you
know
listing
them
in
the
marketplace.
Just
you
know
gives
the
community.
You
know
a
great
great
way
to
reason
about
these
find
these
and
collaborate
on
these.
C
All
right,
hey
folks,
I'm
Nick
senior
principal
engineer
at
upbound
and
a
long
time
cross,
plane
maintainer.
So
today,
I'm
going
to
talk
to
you
a
little
bit
about
a
new
feature
that
we're
hoping
to
land
in
cosplay
in
0.11,
which
I
guess
is
due
in
about
a
quarter
from
now.
We
just
released
0.10,
sorry
1.11
and
we
just
released
1.10.
C
C
C
Now,
as
Matthias
mentioned,
you
teach
cross-playing
what
to
do
using
a
composition.
Historically,
as
Matthias
already
touched
on,
a
composition
has
an
array
of
resources,
effectively
resource
templates
and
then
it
can
patch
and
transform
values.
Now
what
this
means
it
can
copy
values
effectively
from
the
instance
of
a
composite
resource
into
the
composed
resources.
So
in
this
case
we're
saying
crossblade
when
you
see
an
Acme
code
database.
C
What
we
really
want
you
to
do
is
make
a
cloud
SQL
instance
in
gcp.
Now
it
doesn't
have
to
be
one
resource.
It
could
be
a
cloud
SQL
instance
and
a
firewall
rule,
or
something
like
that
in
this
case,
we're
keeping
it
simple
and
then
you
can
say
all
right
cross
play
and
you
can
see
the
patches
towards
the
bottom.
There
take
that
storage,
gig
value
and
copy
that
into
this
other
path.
C
We
did
not
want
to
grow
a
DSL
in
yaml,
something
that
tries
to
compete
with
the
general
purpose,
programming,
language
and
speaking
of
someone,
who's
been
a
platform
engineer
in
SRE
for
my
entire
career,
I
kind
of
know
that
it's
really
easy
to
fall
into
the
temptation
of
oh
I
just
need
this
feature
from
this
language.
I
just
need
feature
X
or
feature
y
I'll.
Add
it
on
I'll
bolt
it
hard,
and
then
you
have
this
really
sort
of
incoherent,
weird
configuration
file,
so
we
decided
to
try
and
be
as
conservative
as
possible.
C
We
designed
this
for
relatively
simple
use
cases,
so
things
that
you
can't
do
today
in
composition
in
Cross
plain,
for
example,
includes
conditionals.
You
can't
say
if
this
input
then
make
this
resource,
otherwise
don't
or
do
this
patch.
Otherwise,
don't
you
can't
do
iteration
in
composition
today,
so
you
can't
say
if
there
are
five
resources.
Sorry,
if
the
spec
is
five
then
make
five
subnets
or
something
like
that-
that's
not
possible
in
Cross
Point
today.
C
So
our
idea
was
that
we
always
wanted
to
give
people
the
ability
to
use
their
existing
tooling
that
they're
comfortable
with
or
a
general
purpose
programming
language
that
they're
comfortable
with
in
order
to
do
more
advanced
composition,
use
cases,
so
this
kind
of
balances
no
code
with
low
code.
Basically,
if
you
have
a
simple
use
case,
it's
no
code.
You
write
one
of
these,
but
if
you
start
to
get
a
little
bit
more
complex,
then
we
really
do
think.
C
C
C
Now
this
can
be
mixed
and
matched
with
the
resource
template,
which
is
pretty
nice,
so
you
could
actually
do
both.
You
could
have
the
example
from
the
previous
slide.
You
could
say
I'd
like
you
to
just
make
a
simple
Cloud
SQL
instance,
but
then
maybe
I
have
to
go
in
talk
to
an
ipam
and
IP
address
allocation
service
to
figure
out
what
subnet
I
should
put
it
in,
or
something
like
that,
and
that's
something
that
you
can't
do
with
a
simple
yaml
file
in
composition
today,
but
you
could
do
with
a
function.
C
So
the
idea
is
this:
allows
you
to
decorate
your
existing
compositions
with
additional
functionality
or
just
replace
them
with
a
digital
functionality.
So
it
touches
on
a
couple
of
use
cases
it
touches
on
you
know.
Maybe
you
just
don't
like
yaml
very
much,
which
I
know
is
a
you
know,
a
pretty
common
thing
and
maybe
you'd
prefer
to
use
a
real
programming
language,
or
maybe
you
have
a
tool
that
you're
familiar
with
already.
Maybe
you
really
like
Helm
or
you
really
like
jsonnet
or
you
really
like
Q
Lang,
or
something
like
that.
C
You
would
like
to
use
those
to
do
your
your
composition
for
you,
but
you'd
like
to
do
that
server
side.
That's
that's
one
of
the
neat
things
about
crosstain
right.
You
don't
have
to
get
everyone
to
go
and
run
Helm
on
their
laptop,
for
example,
cross
playing
could
go
and
do
it
for
you
server
side
it's
behind
an
API,
so
people
are
still
your
developers
that
you're
supporting
still
make
an
API
call.
They
don't
they
don't
know
how
this
is
implemented
on
the
market.
C
So
this
is
a
bit
of
a
sneak
preview
in
how
we
think
that
these
functions
will
be
implemented.
Shout
out
to
the
folks
who
worked
on
krm
functions
in
customizing
kpt.
That
was
a
definitely
big
influence
here.
So
we're
following
a
similar
pattern,
where
we
think
that
it
might
be
different
kinds
of
functions
in
future.
C
For
instance,
you
could
imagine
a
webhook
function
right
that
just
you
know
basically
calls
out
to
webhook
and
says
what
should
I
do
to
compose
these
resources,
but
to
start
with
we're
thinking,
we'll
use
oci
containers,
the
idea
is
you
containerize
a
process.
The
process
takes
a
standard
input
on
its
standard
input,
actually
as
an
a
standard.
This
yaml
document
on
its
standard
input
and
then
can
optionally
mutate,
this
yaml
document
and
is
expected
to
return
it
to
standard
out,
and
this
allows
a
pipeline
of
functions.
C
It
allows
you
to
stack
them
effectively
with
each
one
mutating
the
the
state
of
the
world
you
can
see
in
this.
In
this
document,
you've
got
a
config
for
the
function,
which
is
basically
just
an
arbitrary
x-ray
or
krm
document
that
you
can
use
optionally
to
to
configure
your
function,
and
then
it
will
show
you
in
this
case.
This
is
kind
of
the
input
to
the
first
function.
So
it'll
show
you
the
observed
state
of
the
world.
It
says:
hey,
there's
this
composite
resource.
In
this
case
it's
called
an
ex
postgres
instance.
C
So
it's
got
20
gig
of
storage.
What
should
I
do
function
and
then
the
function-
it's
not
pictured
here
but
can
set
the
desired
state
of
the
world
which
looks
very
similar
to
this,
it
might
say,
set
the
status
conditions
ready,
true,
which
is
already
there
we'll
set.
The
status
conditions
may
be
ready,
false
and
go
compose
a
cloud
SQL
instance
by
outputting
that
returns
this.
So
let's
stand
it
out
then
cross
plain
sees
that
and
says:
oh
all,
right
I
need
to
go,
make
a
classical
instance
or
whatever.
C
C
Imagining
having
you
know,
CLI,
tooling,
sdks,
all
that
kind
of
thing
to
make
these
make
building
these
functions
easier,
and
we
really
hope
that
this
is
going
to
open
and
cross-plane
up
to
some
more
advanced
composition,
functionality
that
will
help
more
people
as
they
migrate
away
from
other
tools
to
cross-plane
be
able
to
do
what
they
need
to
do,
and
we
also
hope
it's
going
to
be
a
bit
of
a
Proving
Ground.
We're
not
we're,
definitely
not
saying
that
we
won't
extend
sort
of
patch
and
transform
style
composition
as
well.
C
But
the
nice
thing
is
with
this
in
place:
there's
always
an
escape
hatch.
We
can
take
our
time
and
we
can
grow
the
composition
language
as
it
exists
today,
slowly
and
carefully
and
intentionally,
and
meanwhile
people
can
still
do
what
they
need
to
do
using
these
functions.
So
we
really
hope
that
they're
going
to
coexist
together
well,.
C
The
first
version
of
the
container
Runner:
this
is
a
quick
illustration
of
it.
We
actually
think
there's
going
to
be
multiple
different
container
Runners
if
anyone's
worked
with
or
on
Argo
workflows.
You've
probably
seen
that
it's
surprisingly
hard
to
get
kubernetes
to
run
a
pipeline
of
containers
in
order
passing
input
to
to
passing
output
to
input
in
a
sort
of
fast
and
performant
way,
so
we're
thinking
that
cross
planes
going
to
ship
with
a
sidecar
container
that
will
actually
use
rootless
containers
to
run
these
inside.
It
run
little
Snippets
of
these.
C
These
sort
of
function
containers
inside
it,
but
we
do
imagine
that
this
is
going
to
be
applicable
situation.
So
if
you
wanted
to
go
and
build,
maybe
a
more
scalable
function.
Rather,
that's
you
know
secure
built
on
firecracker
or
G
visor,
or
something
like
that
absolutely
possible
as
well.
This
is
going
to
be
kind
of
just
like
the
the
default
one
that
ships
with
cross
planes
so
that
you
can
have
something
that
works
out
of
the
box
without
having
to
spin
up
a
ton
of
infrastructure.
D
I'm
Bob
Hamilton
I
work
for
Nokia
and
been
contributing
to
cross
playing
for
about
six
months
or
so
I
was
going
to
talk
a
little
bit
about
the
garbage,
collect
tuition,
processing
and
garbage
collection
issues
that
we've
run
into
and
some
of
the
work
that's
been
going
on
to
to
try
to
improve
this
area.
One
thing
we
found
is
that
managed
resources
can
fail
to
delete
and
you
you,
as
the
user,
the
claim,
the
person
that
put
the
claim
in
and
presumably
deleted,
the
claim.
You
may
not
know
that
that
deletion
failed.
D
One
thing
I
realized
we
didn't
talk
about.
Much
was
the
processing
of
you
know
how
you
create
things
well,
kubernetes
is
going
to
create
everything
that
you
tell
it
to
using
eventual
consistency.
It's
going
to
follow
a
path
of
resource
creation
that
is
undefined
and
undefinable
pretty
much,
and
it's
also
not
stored
anywhere.
So
we
don't
know
the
order
that
things
got
created
in
and
as
things
stand
today,
there
is
no
defined
order
for
deleting
resources.
D
D
So
the
resource
relationships,
real
quick
as
I
said
the
claim
is
namespaced.
It
has
a
reference
to
the
composite
object,
that
is,
that
is
associated
with
it.
So
when
you
create
the
claim
cross,
plane
we'll
see
that
claim,
and
it
will
create
an
Associated
composite.
That
composite
has
a
claim
reference,
pointing
back
at
the
claim,
as
I
said,
the
there's
no
owner
reference
there.
D
The
composite
then
creates
other
Composites
or
other
managed
resources,
as
you
tell
it
to
and
all
of
those
are
cluster
Scopes.
So
all
of
those
have
owner
references
that
point
back
up.
Eventually,
you'll
get
back
up
to
that
root
composite
each
one
of
the
types.
The
claim
composite
and
managed
resources
have
reconcilers
associated
with
them.
Those
reconciliers
have
finalizers
that
they've
placed
on
the
resources
to
prevent
them
from
being
deleted.
D
Cross-Plane
is
going
to
manage
the
deletion
of
those
resources
when
kubernetes
tells
it
to
so
just
as
an
example
of
a
default
claim,
processing
delete
processing-
and
this
is
this-
is
what
happens
today
and
we'll
continue
for
this
type
of
example.
When
you
do
Cube
control
delete
on
the
claim,
kubernetes
will
put
a
deletion
timestamp
on
the
metadata.
For
that
claim.
It
does
some
other
things
too,
but
for
our
purposes
that's
enough.
D
The
claim
reconciler
will
detect
that
deletion
timestamp
and
it
will
call
the
API
delete
function
for
the
composite,
because
again,
kubernetes
has
no
way
of
doing
that
directly.
The
composite
then
gets
a
delete
time
stamp.
The
claim
reconciler,
meanwhile
goes
on
and
finishes
its
work
right.
So
the
claim
is
now
gone.
Cube
control
delete
is
done
so,
as
a
user,
you
have
no
idea
what
else
is
going
on
at
this
point.
You
think
everything
is
deleted.
D
D
The
reconcilers
will
then
detect
those
deletions
and
do
their
appropriate
processing.
So
the
composite
reconciler
will
detect
the
deletion
of
the
composite.
It
will
remove
the
connection
details,
resource
that's
associated
with
composite,
and
then
it
will
remove
its
finalizer,
which
will
allow
the
object
to
be
deleted.
D
The
managed
resources,
the
managed
reconciler,
will
call
whatever
delete
function
is
associated
with
that
managed
resource,
whether
it's
a
delete,
VPC
or
a
delete,
ec2
instance
or
whatever
it
is
once
that's
done,
it
will
remove
its
finalizer
and
those
objects
can
get
deleted
and
that
all
happens
basically
at
random.
You
know
you
have
no
control
over
it
all
those
things
just
kind
of
happen
and
everything
goes
away,
which
is
great
until
you
have
one
or
five
or
ten
managed
resources
that,
for
whatever
reason,
the
the
far
end
of
your
API
can't
delete.
D
Maybe
somebody
spun
up
an
ec2
instance
on
your
subnet
and
didn't
tell
you
about
it,
which
wasn't
very
nice,
but
it
happens,
and
now
your
subnet
can't
be
deleted,
because
somebody
else
has
an
ec2
has
been
sitting
out
there
on
it
right.
That's
what
gets
you
into
this
situation
at
that
point,
you
have
two
choices.
Basically,
you
can
either
go
find
the
ec2
instance
and
delete
it
and
what
reconciliation
do
its
thing?
D
You
can
also
remove
the
finalizer,
but
I
would
not
recommend
that,
because
now
your
subnet
is
left
out
there
hanging
in
whatever
cloud
provider.
You've
got
so
that's
kind
of
the
an
illustration
of
the
problem
that
we
were
looking
at
in
1.10.
We
added
support
for
foreground,
cascading
deletion
and
I
want
to
qualify
that
a
little
bit.
It's
simulated
on
the
claim
side,
it's
implemented
for
the
composite
side,
the
claim
reconcile.
We
have
a
composite
delete
policy
that
we
added
to
the
claim.
D
D
The
other
thing
we
did
was
we
set
block
owner
deletion
on
all
the
controller
owner
references
so
that
foreground
cascading
dilution
will
work
the
way
we
expect
it
to.
You
can
delete
a
standalone
composite.
We
haven't
talked
about
it
really,
but
you
there's
no
requirement
to
use
a
claim.
You
can
Implement
you
can
instantiate
the
Composites
directly,
that's
entirely
a
user
decision.
D
The
the
other
piece
here
is
that
if
you
specify
the
cascading
foreground,
cascading
deletion
policy
on
a
claimed
deletion,
it's
still
ignored
like
it
is
today
and
that's
cause.
That's
the
owner
reference
issue,
so
the
same
example
that
we
just
ran
this
time,
we're
setting
the
foreground
composite
deletion
policy.
D
Same
thing
is
going
to
happen,
set
the
deletion
timestamp.
The
claim
reconciler
is
going
to
do
its
thing.
You'll
notice,
the
claim
stays
at
this
point
at
this
point.
You've
got
an
additional
finalizer
on
all
the
composite
resources,
anything
that
has
an
owner.
Reference
pointed
to
it
has
an
a
final
additional
finalizer
on
it.
The
managed
resources
are
going
to
go
ahead
and
delete
the
way
they
do
today.
D
The
composite
that
now
has
no
owner
references
pointing
to
it
will
also
get
deleted,
but
your
stock
mobile
managed
resource
is
now
going
to
block
the
deletion
of
everything
up
the
tree
behind
it.
So
now
your
Cube
control
command
doesn't
return.
Nothing
gets
deleted
until
you
go
in
and
you
fix
this,
and
you
now
say:
oh
I
have
a
stock
resource.
Now
I
delete
my
ec2
instance:
that's
blocking
my
Subnet
and
now
everything
Cascades
out.
A
All
right
sweet,
so
let's
go
ahead
and
start
closing
this
thing
out
now.
So
the
final
thing
I
wanted
to
say
once
again,
you
know
kind
of
reinforce.
This
is
that
you
know
this
project
is
nothing
without
its
Community
right,
and
so
you
know,
I
definitely
wanted
to
make
sure
that
we
give
some
opportunities
here
for
everyone
to
start
getting
involved,
there's
a
whole
bunch
of
useful
links
here.
You
know
the
main
website
is
crossblane.io.
You
can
go
there,
read
the
docs
get
the
quick
start.
A
C
There's
definitely
no
plans
at
the
moment
to
remove
it.
It
so
technically
anything
that
goes
into
cross-plane
as
Alpha
could
be
removed,
that's
kind
of
part
of
that
contract,
but
there's
no
intention
I
think
the
only
reason
we
would
remove
it
is.
If
we
added
it,
it
turned
out
to
be
a
terrible
idea
and
everyone
hated
it
or
it
didn't
work
or
something
like
that.
So
I
hope
it
stays
there,
but
no
contract
around
that
until
it
hits
V1.
Basically.
E
D
E
B
B
We
also
have
code
generation
as
I
said,
and
that's
this
code
generation
works
on
top
of
terraform
providers,
so
it
takes
an
existing
terraform
provider
and
creates
it
creates
a
a
cross-plane
provider
and
we've
we've
done
this
from
the
outbound
side
for
the
major
providers,
but
everyone
can
do
them
and
we're
seeing
this
that
others
are
also
using
this
and
the
way
that
I
try
to
think
about
it.
The
vision
would
be
that
the
crossband
provider
at
the
end
of
the
day
is
just
a
build
artifact
out
of
the
terraform
provider.
B
C
Just
to
just
to
add
on
to
that
real
quick
as
well,
the
specific
go
out
like
why
not
use
Azure
service
operator,
KCC,
ack,
Etc
et
cetera.
It's
it's
a
couple
of
things.
One
is
API
consistency.
Yes,
all
those
things
are
bounded
by
the
krm,
but
you
know
we
work
pretty
closely
collaborate
with
the
folks
who
work
on
those
teams,
because
we're
all
doing
similar
work
and
it's
great
to
swap
notes-
and
you
know,
KCC
just-
has
different
annotations
and
different
settings
from
from
ack
right.
C
So,
if
you're
using
multiple
providers,
it's
just
nicer
to
have
them
be
consistent.
I
think
the
other
thing
as
well
is
that
that
only
covers
the
big
three
clouds.
You
know
we
have
providers
for
GitHub,
gitlab,
SQL
terraform
to
run
terraform
tons
of
other
things
right.
So
if
we
just
said
you
could
maybe
make
the
case.
Oh
we'll
just
use
operators
any
operator
sort
of
thing,
but
this
just
becomes
really
inconsistent
and
it's
just
a
lot
for
cross-playing
sort
of
Administrators
to
have
to
understand
so.