►
From YouTube: Content Addressable CRDs: Type Uniqueness Across Kubernetes Clusters - Daniel Mangum, Upbound
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.
Content Addressable CRDs: Type Uniqueness Across Kubernetes Clusters - Daniel Mangum, Upbound
Speakers: Daniel Mangum
As the Kubernetes extensibility story has evolved over time, the system has grown to more closely resemble a programming interface. As a result, more and more projects have standardized on Kubernetes, utilizing Custom Resource Definitions to define the schemas for interacting with the functionality they offer. However, defining higher level types outside the context of an individual cluster is difficult due to the fact that the unique identifier of a type – its Group, Version, and Kind – are not globally universal. In this talk we’ll explore a proposal for content addressable storage of type definitions for Kubernetes, inspired by the OCI distribution specification. The focus will be on the ergonomics of the system, how it compares to existing packaging and installation mechanisms for Custom Resource Definitions, and what future use cases could be enabled by aligning on a shared standard. Live demos will illustrate the full workflow and serve as inspiration for subsequent collaboration.
A
Let's
go
ahead
and
get
started.
This
is
a
a
fairly
jam-packed
presentation,
so
I
want
to
make
sure
to
jump
into
the
content
quickly.
I
do
promise
to
do
some
live
demos
at
the
end.
So
hopefully
you
all
can
finish
out
your
kubecon
with
watching
me
break
some
stuff,
but
I
appreciate
you
all
sticking
around
to
the
very
end.
A
A
So
I
generally
like
to
start
off
by
giving
you
a
bit
of
an
idea
of
where
we're
going
to
be
going
in
this
talk.
So
you
can
stand
up
and
go
catch
your
flight
if
this
doesn't
look
good
to
you,
but
what
we're
going
to
start
with
is
just
generally
talking
about
how
you
can
extend
the
kubernetes
API
surface.
This
is
likely
an
area
that
lots
of
you
folks
are
already
familiar
with,
but
we
want
to
set
that
that
ground
level
for
us
to
be
able
to
build.
A
On
top
of
then
we're
going
to
talk
about
two
aspects
of
programming
generically
that
are
important,
that
we
don't
really
have
in
kubernetes
today
and
that's
internal
versus
user-facing
types
and
programming
in
an
abstract,
cluster
sense
and
I
know.
Those
may
not
mean
anything
quite
yet
so
we'll
make
sure
to
define
those
terms
as
we
go
along
and
then
we'll
come
up
with
a
solution
for
these
types,
spread
across
many
clusters
and
round
out
with
a
demo.
So
starting
off
with
extending
the
kubernetes
API
surface.
A
There
are
a
couple
different
ways
to
extend
the
kubernetes
API,
but
the
kubernetes
API
comes
with
a
set
of
built-in
types.
You
can
really
just
think
about
these
as
endpoints.
If
you
want
to
think
about
a
rest,
API
server,
which
is
actually
what
the
kubernetes
API
server
is,
and
these
are
the
ones
you
know
and
love
like
pods
deployments,
Services
Etc
et
cetera
things
that
are
there
to
allow
you
to
do
the
core
job
that
kubernetes
was
created
for
which
is
container
orchestration,
and
this
is
usually
the
case.
A
A
So
you
can
add
additional
types
to
the
kubernetes
API
at
runtime,
so
we're
not
actually
modifying
the
code
base
of
the
API
server
right,
we're
adding
these
new
types
as
we
go
along
and
there's
two
main
ways
that
this
can
be
done.
First
is
API
server
aggregation,
we're
basically
saying
hey
kubernetes
API
server
I
have
another
API
server
over
here
that
can
serve
some
additional
endpoints
and
just
send
them
my
way
when
you
get
a
request.
A
The
next
is
custom
resource
definitions,
which
are
a
built-in
type,
a
custom
resource
definition,
type
that
allows
you
to
add
a
new
type
or
you
can
think
of
it
as
a
new
endpoint.
If
you
like,
these
are
both
valid
ways
to
extend
kubernetes
clusters.
Today,
we're
going
to
be
focusing
in
on
custom,
resource
definitions
or
crds
is
the
abbreviation
if
you're
not
familiar
with
it
custom
resource
definitions
are
generally
viewed
as
a
little
bit
simpler
to
use
and
they
can
also
be
integrated
in
more
environments.
Some
hosted
kubernetes
offerings.
A
A
If
we're
going
to
be
able
to
say
hey,
this
type
has
this
structure
and
can
be
validated
in
this
way,
and
also
has
this
Behavior
attached
to
it.
We
have
to
be
able
to
identify
it
relative
to
other
types
that
exist
in
the
case
of
kubernetes.
We
identify
types
by
group
version
and
kind
or
you'll
frequently
refer
here
at
referred
to
as
GVK
all
types
exist
in
the
context
of
a
scope,
so
they
have
to
be
defined
in
some
sort
of
namespace,
which
impacts
what
their
identifier
is.
A
This
key
this
there's
a
key
Insight
here,
though,
that
it
doesn't
necessarily
mean
that
they
can
only
be
instantiated
in
that
namespace,
depending
on
whether
they're
user
or
internal
facing
that
determines
whether
they
can
be
instantiated
outside
of
the
namespace
in
which
they're
defined
in
the
context
of
a
single
kubernetes
cluster.
Every
type
is
defined
at
the
cluster
scope
right,
it
might
be
able
to
be
instantiated
at
the
namespace
scope
or
at
the
cluster
scope,
but
the
type
is
actually
defined
at
the
cluster
scope.
There's
no
namespace
crds.
A
A
Further
kubernetes
doesn't
inherently
offer
type
composition,
but
as
we're
going
to
see
in
this
presentation,
projects
like
cross
plane
allow
you
to
bring
composition
into
your
cluster,
and
the
last
thing
here
is
that,
generally
and
specifically
for
the
purposes
of
this
presentation,
we
are
going
to
say
that
any
types
that
are
not
composed
of
other
types
are
referred
to
as
Primitives.
That's
whether
they're
built
in
or
user
defined.
A
If
we're
moving
towards
you
know
a
kcp
model
or
something
like
that,
you
could
view
all
types
as
user-defined,
perhaps
at
the
end
of
each
section,
I'm
going
to
do
a
quick
check-in
just
to
make
sure
that
we've
covered
the
high
level
points.
So
kubernetes
includes
some
built-in
types
which
can
vary
depending
on
implementation.
Kubernetes
allows
you
to
introduce
additional
types
at
runtime
via
few
mechanisms.
A
How
we
program
the
kubernetes
API
before
we
continue
on,
if
we're
going
to
add
a
programming
language
type
construct
to
the
kubernetes
API
and
be
able
to
use
that
to
do
more
powerful
things,
we
have
to
start
thinking
about
the
features
that
kubernetes
offers
to
us
to
to
implement
this
kind
of
functionality.
In
other
words,
if
we're
going
to
add
programming
like
features
to
the
kubernetes
API,
we
need
to
start
treating
it
like
a
programming
language
or
put,
in
other
words
with
great
power,
comes
great
responsibility.
A
Now
I'm,
not
saying
that
we
want
to
take
the
kubernetes
API
and
make
it
into
a
turing
complete
programming
language.
That
would
be
very
complex,
very
hard
to
observe
very
hard
to
debug.
So
we
don't
want
to
do
that,
but
we
are
bringing
in
some
new
functionality
that
adds
a
lot
of
capabilities
to
the
kubernetes
API,
and
so
we
need
to
consider
how
we're
going
to
be
able
to
manage
that
additional
complexity
or
additional
power
here.
A
So
we're
going
to
make
an
analogy.
This
isn't
a
Perfect
Analogy
but
I
think
it's
useful,
because
a
lot
of
folks
in
the
cloud
native
ecosystem
are
also
Engineers
or
engineering
adjacent.
So
we're
going
to
talk
about
another
place
where
we
can
Define
types
and
I've
kind
of
already
spoiled
the
surprise
here,
but
that
would
be
programming
languages
right.
We
Define
types
all
the
time
in
programming
languages.
They
may
be
strongly
typed
or
dynamically
typed,
but
there's
all
sorts
of
different
type
systems
that
exist.
A
So
how
do
we
Define
the
types
in
the
programming
language
well,
usually
via
some
sort
of
built-in
type?
That
offers
the
ability
to
Define
new
types,
and
this
sounds
pretty
familiar
right.
We
just
talked
about
how
custom
resource
definitions
allow
us
as
a
built-in
type
to
Define
additional
types.
So
what
does
a
very
simple
type
declaration?
Look
like
in
go,
for
example,
here
we're
defining
a
my
type
type
and
we're
just
using
it
as
an
alias
for
an
integer,
but
this
is
a
brand
new
type
right.
A
A
A
So
if
we
wanted
to
Define
A
user-defined
Primitive
type
in
kubernetes,
like
I
said
earlier,
we
will
use
a
custom
resource
definition,
which
looks
something
like
this,
where
we
give
some
metadata
about
how
the
type
can
be
identified
and
what
you
don't
see
here
is
the
schema,
the
organization
of
data,
the
validation
that
has
to
take
place
if
someone
wants
to
instantiate
or
create
one
of
these
types
in
our
cluster.
Once
again,
as
we
said
earlier,
custom
resource
definitions
are
always
defined
at
the
global
or
cluster
scope
within
a
single
kubernetes
cluster.
A
We
can
also
Define
higher
level
types
or
composite
types
in
programming
languages.
Once
again,
we
have
a
scope.
We
have
an
identifier,
we're
using
a
user
defined
primitive,
the
one
we
defined
earlier,
the
the
my
type
as
well
as
a
built-in,
primitive
and
composing
that
into
a
higher
level
thing
called
higher
level
type
here.
A
A
Lastly,
programming
languages
also
give
us
the
ability
to
Define
abstractions
in
go.
We
use
interfaces
to
be
able
to
do
this,
so
here
we're
saying,
there's
an
abstract
type
that
is
being
defined
by
an
interface,
and
here
we're
just
specifying
the
behavior
that
can
be
present
for
this
abstract
type
and
with
the
behavior.
You
have
these
different
methods
that
say
Hey.
This
is
the
the
signature
for
how
you
can
invoke
this
in
imperative
fashion
and
here's
some
data
that
can
be
passed
into
it.
A
It's
very
similar
to
a
crd,
a
custom
resource
definition
and
the
structure
actually
looks
quite
similar,
but
you'll
see
here
that
we
actually
Define
a
cluster
scope,
variant,
which
is
under
the
names
and
a
namespace
scope
variant
which
is
under
the
claims
here,
and
these
are
two
separate
types
and
individually
they're.
Not
actually,
they
don't
actually
have
any
Behavior
implementation
attached
to
them.
They
have
to
be
matched
to
a
composition.
Just
like
an
interface
and
a
programming.
A
A
Well,
let's
lay
out
some
ground
rules
to
start
off.
Both
are
primitive
and
composite
types
can
be
internal
or
user
facing
in
a
program
we
might
want
to
say
yeah.
We
have
some
some
higher
level
types
that
are
not
just
Primitives
that
are
introduced,
but
we
don't
actually
want
to
expose
them
as
part
of
a
library
API
or
something
like
that.
They're,
just
internal
they're,
helping
us
do
the
job
that
needs
to
be
abstracted
away
from
the
consumer
of
the
package
program.
Languages.
A
Allow
us
to
do
that
by
choosing
what
types
are
exported
or
made
public
or
made
part
of
our
API
service,
and
this
allows
us
to
divorce
the
implementation
of
behavior
from
the
interface
right.
You
you
all
the
time
interact
with
packages
or
libraries
or
things
like
that.
They
give
you
really
robust
functionality,
but
they
don't
actually
expose
all
the
details
to
you
right.
A
That's
actually
the
beauty
of
having
libraries
and
having
portable
code
that
you
can
move
around
and
we
want
that
same
sort
of
functionality
in
kubernetes,
so
kubernetes
does
not
offer
the
ability
to
say
hey.
This
is
internal
and
this
is
exposed
which
might
look
something
like
hey.
This
is
just
used
for
composing,
another
higher
level
type,
but
we
can
bring
that
functionality
into
a
kubernetes
cluster
via
convention,
and
you
could
actually
enforce
this
convention
with
web
hooks
or
something
like
that.
A
If
you
wanted
to
in
that
convention,
somewhat
controversially,
to
some
folks,
is
that
all
user
facing
types
are
namespace
scoped,
so
not
the
type
definition.
The
type
definition
still
exists
at
the
cluster
scope
right,
but
they
can
only
be
instantiated
at
the
namespace
scope
and
types
that
are
not
offered
at
the
namespace
scope.
Are
not
user
facing
right?
We're
not
expecting
users
to
to
create
those
they're
more
like
intermediate
types
to
be
able
to
surface
that
higher
level.
A
A
So
with
that
convention,
we've
kind
of
accomplished
one
of
the
goals
of
what
we
want
of
programming,
the
kubernetes
API,
but
there's
a
bigger
issue.
That's
really
more
important
and
even
more
relevant
for
this
talk
right,
just
being
able
to
define
the
internal
user
facing
internal
versus
user-facing
types
gives
us
the
ability
to
do
more
things,
but
really
the
problem
we're
trying
to
solve
is
that
outside
of
a
single
physical
cluster,
our
identifiers
of
types
in
a
kubernetes
cluster
are
mostly
meaningless.
A
So
what
I
mean
by
that
is,
if
you
put
a
manifest
in
a
git
repo-
and
you
say,
hey
everyone
on
Twitter
come
apply
this
to
your
cluster
now,
hopefully,
no
one
would
go
do
that,
but
someone
might
and
if
a
manifest
exists
in
a
git
repo,
it
doesn't
exist
in
any
cluster
right.
So
how
can
you
guarantee
that
a
a
type
identifier
that
is
unique
to
the
the
existence
of
type
definitions
within
a
single
cluster
means
the
same
thing
when
you
apply
it
to
two
different
ones?
A
A
A
So
that
means
that
if
you
go
to
my
repository
and
you
clone
it
and
you
build
the
project,
it's
either
going
to
fail
because
it
can't
find
that
package
or
it's
going
to
build
with
the
exact
same
content
that
I
Define.
It
should
right.
So
we
can
reproduce
that
behavior
in
in
different
places
on
different
machines
where
we're
compiling.
A
So
we
already
went
through
this
a
little
bit,
but
the
GVK
is
unique
within
a
single
cluster
right.
You
can't
have
conflicts
at
that
level,
but
they
are
not
unique
in
the
context
of
the
abstract
cluster.
Another
way
to
say
what
I've
been
saying
over
the
past
couple
slides
is
that
types
are
not
portable
right.
They
can't
be
moved
across
clusters
with
guarantee
that
the
syntax
has
the
same
semantics,
and
so
this
causes
some
issues
and
if
you're
Qui-Gon
gen,
you
might
say,
gvks
will
do
fine
and
I
would
say
no.
A
They
won't
before
we
actually
address
this
problem,
though
we
need
to
address
a
key
fact
of
types
and
that's
the
just.
The
data
structure
is
not
enough
to
separate
types
from
each
other
right.
You
could
have
two
types
of
the
exact
same
data
structure,
but
they
are
not
the
same,
and
why
are
they
not
the
same?
It's
because
we're
able
to
attach
Behavior
to
types.
We
saw
this
on
some
methods
earlier
that
were
defined
on
an
interface
and
when
we're
using
an
imperative
programming
language
we
attach
Behavior
to
types
and
we
call
it
explicitly
right.
A
We
instantiate
the
type
and
we
say
create,
or
we
instantiate
instantiate
the
type
and
say
do
something
right
in
a
declarative
programming
model,
which
is
what
we're
doing
with
the
kubernetes
API.
We
provide
the
system
with
enough
data
to
actually
call
the
methods
for
us.
So
in
the
crosswind
project
we
frequently
think
about
a
Reconciliation
Loop,
not
in
terms
of
just
constant
Loop.
A
But
in
both
of
these
environments,
you
are
attaching
behavior
of
the
type
with
its
definition
and
the
key
thing
about
not
even
being
able
to
take
a
type
and
saying
hey.
This
literally
has
the
same
structure.
The
same
open,
API,
V3
schema
is
that
its
semantics
are
dictated
by
the
controllers
that
are
reconciling
it,
so
we
need
to
actually
tie
the
behavior
of
creating
a
type
in
a
kubernetes
cluster
with
the
definition
of
its
structure.
A
So
this
is
just
an
example
of
how
we
might
attach
some
data
to
a
type
in
a
programming
language.
We
Define
an
operation
with
a
signature
here
we
might
provide
data
via
arguments
and
there
might
also
be
data.
That's
inherent
to
the
type
like
I
said
in
the
context
of
a
declarative
system,
we're
actually
just
providing
all
that
data
up
front.
We
say
here's
the
thing
that
I
want
to
happen.
You
perform
the
operations
system
and
and
make
sure
that
you
know
it
looks
as
I've
specified
here.
A
So
we
said
this
causes
some
issues.
The
fact
that
we
can't
do
this,
the
first
one
is
potentially
pretty
straightforward
and
that's
opaque
type
instantiation
when
I
create
an
instance
of
a
type
in
any
cluster
I.
Don't
know
whether
a
type
by
that
identifier
exists
right
and
that's
actually
a
great
case,
because
that's
going
to
get
rejected
by
the
API
server,
if
I
try
to
create
that
RDS
instance
type
that
we
saw
earlier
and
and
there's
no
type
by
that
GVK
in
the
cluster.
A
It's
just
going
to
fail
and
that's
that's
actually
a
pretty
good
outcome
for
us,
maybe
not
the
best.
But
it
is
a
good
outcome.
More
critically,
though,
is
it
could
succeed,
but
it
could
do
something.
I
don't
expect
at
all.
When
we
create
an
RDS
instance
when
we're
using
the
AWS
provider
and
cross
plane,
we
expect
that
it
will
provision
an
aw
or
an
RDS
instance
on
AWS.
A
You
could
also
say
that
it
does
literally
anything
else.
It
could
delete
all
your
infrastructure
or
you
know,
delete
all
the
pods
in
your
cluster
or
something
like
that.
So
we
need
to
be
able
to
actually
identify
that
the
behavior
that's
attached
to
the
type
that
we're
instantiating
is
the
one
that
we
want
so
here
in
this
case,
this
is
the
example
of
opaque
type
instantiation.
The
GVK
called
out
here
in
the
API
version
in
kind
Fields.
Essentially,
what
we're
saying
is
in
the
abstract
cluster.
This
doesn't
tell
us
anything.
A
The
second
issue
that
we
run
into
is
an
opaque
type
composition.
So
if
we're
composing
things
into
a
higher
level
type
like
the
composition
of
the
RDS
instance,
we
saw
earlier,
we
don't
know
whether
the
types
associated
with
the
gvks
in
the
composition
will
match
the
types
associated
in
the
users
cluster.
So
we
want
to
be
able
to
say
hey
if
we're
providing
a
package
of
abstractions
to
you.
We
want
to
know
the
Primitives
that
we
are
composing
are
what
we
tested
with
right.
A
So
here
once
again,
we
have
an
example
of
a
composition,
we're
composing
the
RDS
instance
here,
but
we
don't
really
actually
know
what
that
RDS
instance
is
so
checking
in
again
right.
We
haven't
solved
the
problem.
We've
just
created
all
of
these
issues
in
order
for
the
kubernetes
Manifest
to
be
portable.
There
are
type
definitions
cannot
be
tied
to
a
single
physical
cluster.
A
We've
said
there
are
multiple
levels
of
composition
within
a
type
and
that
their
dependencies
must
be
composable.
That's
what
we're
talking
about.
We
need
to
make
sure
that
that
RDS
instance
that
we're
assuming
is
present
in
the
cluster
is
the
one
that
we
expected
when
we
authored
the
composition-
and
that
was
all
we
did
in
that
section.
A
So
now
we're
going
to
solve
the
problem
right
and
we're
going
to
do
that
by
creating
globally
unique
types
or
types
that
are
unique
within
the
abstract
cluster,
and
we
don't
want
to
do
a
lot
of
work.
That's
already
been
done
before.
So,
let's
look
and
see
where
we
can
find
some
examples
of
global
uniqueness.
A
Another
place
where
we
see
it
frequently
in
the
cloud
native
ecosystem,
especially
is
with
oci
images
and
oci
images.
We
need
to
be
able
to
identify,
uniquely
because
they're
doing
a
pretty
sensitive
thing
right,
they're,
they're,
running
arbitrary
compute
on
or
they're
running
arbitrary
behavior
on
our
compute.
A
So
we
need
to
make
sure
that
when
we
actually
run
a
container
image
right
that
it's
going
to
be
the
one
that
we
expect
and
it's
not
going
to
mine
Bitcoin
or
do
whatever
your
favorite
malicious
thing
is,
and
so
oci
images
solve
this
problem
by
what
we
call
content
addressability
and
the
simplest
definition
of
content.
Addressability
is
that
we
ask
for
something
by
what
it
is
not
not
by
what
it's
named.
A
We
we
know
what
we
that
what
we
get
is
what
we
ask
for.
So
if
we
wanted
to
apply
this
to
kubernetes
types
or
if
we're
thinking
about
how
to
apply
it
to
kubernetes
types
which
one
of
these
systems
will
we
leverage
well
oci
Registries
are
already
ubiquitous.
You
can
probably
get
one
from
your
favorite
cloud
provider.
You
probably
already
have
one
internally
in
your
organization,
if
you're
of
any
sufficient
size-
and
if
you
don't
have
any
of
those
things,
you
can
actually
run
one
on
a
Raspberry
Pi
in
your
basement.
A
Oci
also
has
a
thriving
ecosystem.
So
there's
lots
of
tooling.
At
present,
it's
actually
growing
all
the
time.
There's
a
few
new
projects
that
really
hit
like
1.0
or
gain
maturity,
I
think
around
this
kubecon
around
the
oci
ecosystem.
So
we
can
leverage
all
that
tooling
and
all
the
work
that
folks
are
doing.
A
It's
also
constantly
improving
I
know
the
gke
team
released
something
about
image
streaming
at
some
point
this
year,
which
is
a
pretty
cool
concept.
Image
signing
has
been
a
Hot
Topic
in
the
Stage
store
community
and
broadly
in
the
kubernetes
ecosystem,
something
we've
actually
been
working
on
for
our
packages
in
the
cross
plan
ecosystem
as
well.
So
this
seems
like
a
pretty
good
solution.
Right
folks
already
know
how
to
use
it.
A
So,
let's
look
at
packages
as
a
reference
for
how
we
can
achieve
this
Global
uniqueness
for
types
Crossing
packages
are
are
referred
to
as
X
packages
and
there's
a
specification
in
the
cross-plane
documentation
for
what
this
means
is
basically
a
superset
of
the
specification
for
oci
images,
so
additional
constraints
on
oci
images.
They
come
in
two
different
flavors
providers
are
going
to
bundle
a
bunch
of
crds
as
yaml
into
an
image
and
then
they're
also
going
to
have
the
controller.
A
A
And
another
key
point
of
that
is
when
you
install
these
types
in
a
a
kubernized
cluster
where
crossline
is
installed
cross
plane
will
verify
that
only
one
controller
or
one
implementation
of
controllers
can
be
reconciling
a
type
at
a
time.
So
you
can't
just
bring
it
along
another
controller
and
install
it
via
a
cross
plane
and
have
it
also
Define
behavior
right.
The
Manifest
is
defining
the
only
behavior
that
is
applied
to
the
type
that's
in
the
same
package
as
it.
A
A
So
let's
look
at
the
two
problems
that
we
defined
and
look
at
our
Solutions.
So
solution
number
one
is
verified
type
instantiation.
This
is
not
something
we
force
upon
users,
but
something
you
can
do
with
something
like
an
admission
web
hook.
You
can
supply
additional
information
about
the
digest
of
the
package
from
which
a
type
came
and
validate
that
digest
when
you
actually
create
the
Manifest.
So
here's
an
example
of
putting
a
digest
and
a
package
reference
on
a
manifest
that
gets
applied
into
a
cluster.
An
admission
web
hook
could
very
easily
check
and
see.
A
Hey.
Is
this
package
already
installed?
If
so,
I
can
verify
that
if
it
came
from
Cross
plain
that
that
that
type
came
from
that
package
and
therefore
this
type
should
behave
as
the
person
who
specify
this
annotation
would
expect,
which
means
that
you
could
put
a
manifest
in
a
git
repo
and
actually
have
guarantees
around
when
someone
applies
it
to
their
cluster.
What
that
means
it's
either
going
to
fail,
or
it's
going
to
do
what
you
affected.
A
Second,
one
is
verified
type
composition.
This
is
something
that's
built.
Natively
into
cross-plane
packages
by
its
support
for
dependencies
crosswind
will
not
install
types
into
a
cluster
until
the
dependencies
of
the
package
they
came
in
are
satisfied.
So
here
we
have
an
example
of
a
package,
we're
actually
going
to
show
installing
in
just
a
moment,
and
it
has
some
some
references
to
dependencies
as
well
as
some
constraints
on
them
now,
in
this
specific
case,
we're
using
tags
right.
So
we
don't
have
full
content
addressability.
A
We
could
have
someone
intersect,
intercepting
our
DNS
resolution
right
and
giving
us
the
wrong
thing
back.
So
this
is
not
actually
achieving
it
fully,
but
the
reason
why
we
do
this
is
because
a
lot
of
times
humans
are
authoring
these
right
and
it's
kind
of
hard
for
humans
to
work
with
digests,
but
we
still
want.
We
don't
want
to
sacrifice
that
functionality
just
because
humans
have
some
some
difficulty
with
stuff.
A
So
our
problem
is
that
humans
are
lazy
or
perhaps
we're
incapable
sometimes,
but
the
solution
is
that
we
can
ask
for
things
by
name
and
then
verify
by
their
content
right
so
before
we
actually
do
the
thing
that
could
bring
malicious
behavior
into
a
cluster,
we'll
verify
that
the
content
is
what
we
expected.
So
in
crossfiting.
We
do
this
with
package
revisions,
where
you
can
set
a
manual
activation
policy.
That
means
that
when
you
install
a
package,
CrossFit
will
pull
it
down.
A
It'll
crack
it
open,
it
will
look
at
it
say:
okay,
these
are
all
the
types
that
are
going
to
get
installed
and
I'm
going
to
run
the
controller
image
that
is
associated
with
them
and
here's
the
digest,
but
it
won't
actually
do
it
right,
it'll,
wait
and
say:
hey
here's,
a
revision,
it
has
this
digest.
It
has
a
list
of
all
the
types
that
will
be
installed,
but
it
doesn't
actually
proceed
with
that
until
you
say
yes
activate,
you
flip
a
field,
and
you
say
this
revision
is
now
active,
so
you
see
the
digest.
A
You
say
this
looks
good.
This
is
now
active
and
running
and
ostensibly
it's
doing
what
you
asked
for.
Then
you
want
to
upgrade
to
a
new
version
of
a
package,
so
you
say:
I
now
want
provider
AWS,
V
0.19.
You
still
have
the
old
Revision
in
play,
but
you've
got
a
new
revision.
That's
been
created,
but
not
activated.
Yet
so
you
can
once
again
say:
okay,
what's
the
digest
here,
what
types
have
changed?
What
controller
is
going
to
be
run?
A
And
if
that
all
looks
good,
then
you
can
say
I'm
going
to
activate
that
one
cross
plan
will
automatically
deactivate
the
other
one
migrate
types
to
the
new
one
shut
down.
The
old
controllers
start
up
the
new
ones,
all
right.
So
we've
solved
our
problem.
Let's
actually
see
how
it's
in
action,
but
before
we
go
to
that,
let's
check
in
we
can
take
advantage
of
the
content
addressability
of
an
oci
ecosystem
by
packaging.
Our
content
in
oci
images.
The
packages
allow
us
to
expand
the
definition
of
types
defined
via
crds
to
include
Its
Behavior.
A
That's
associated
a
package
revisions
allow
us
to
present
a
human
friendly
interface
where
we
can
use
something
like
semantic
versions.
Without
sacrificing
verifying
using
content
addressability
and
with
that,
let's
get
into
the
demo,
I
have
one
minute
left.
So
this
is
going
to
be
a
very
fast
demo.
If
you
would
like
to
follow
along
I
will
post
on
Twitter
right
now
the
manifests
for
or
the
description
of
what
we're
going
through.
A
So
let
me
do
that
and
then
I'll
do
it
quickly,
I,
don't
know
if
anyone
else
has
seen
this
around
yet,
but
a
bunch
of
demos
have
been
failing
recently
because
Docker
Hub
is
limit
rate
limiting
the
kubecon
network.
So
that's
been
a
lot
of
fun,
but
we're
actually
not
using
Docker
Hub
here.
So,
ideally,
that's
not
going
to
happen.
A
All
right,
let's
see
if
this
this
seems
to
be
correct
here,
yeah
can
y'all.
Can
you
all
see
my
term
I
can't
actually
see
the
screen?
Does
that
look?
Okay,
bigger
smaller
good,
all
right,
so
I
have
a
kind
cluster
running
locally,
so
you
can
see
we
have
cross
plane
and
the
cross
plane
our
back
manager
going.
So
what
we
want
to
do
is
install
that
type
and
let
me
see
if
I
can
get
my
browser
up
here.
Okay,
it
looks
like
that's
working.
A
A
It
brings
some
xrds
and
some
compositions
so,
for
instance,
the
eks
composition
here
is
going
to
take
a
bunch
of
the
Primitive
types
supplied
by
provider
AWS,
and
it's
going
to
compose
them
into
a
higher
level
thing
that
represents
an
eks
cluster
if
you've
ever
created
an
eks
cluster.
You
know
this
is
very
painful.
So
now
you
can
just
have
a
very
simple
interface
and
we'll
create
all
these
things
on
the
back
side
for
you.
A
Configuration
install
all
right
that
looks
good
and
we're
going
to
see
a
package
get
created
or
actually
we're
a
little
slow.
So
two
packages
are
already
present,
so
we
have
our
platform
ref
AWS.
It
is
not
quite
healthy,
yet
it's
unknown
because
we're
waiting
for
our
dependencies
here,
but
you
see,
we've
already
resolved
one
of
our
dependencies
to
provide
our
AWS
and,
let's
see
if
our
other
one
has
come
along.
Not
quite
yet
I
was
having
some
issues
with
the
network
earlier,
so
we'll
see
if
we
experience
any,
it
looks
like
they
are
coming
along.
A
We
also
have
our
package
revisions.
We
have
one
for
each,
so
here's
the
digest
or
the
short
digest
of
the
configuration
package
we
installed
and
here's
the
short
digest
of
the
provider.
Aws
version
we
have
installed
and
you'll
see.
Our
revisions
are
numbered
as
well,
and
we
have
a
count
of
the
dependencies
that
we
have,
but
none
of
our
dependencies
are
quite
ready.
Yet
all
right,
so
it
looks
like
those
are
taking
a
bit
of
time
here.
A
So
it
looks
like
they're
just
about
there.
Provider
AWS
is
is
pretty
big,
so
it's
just
finishing
up
and
we
can
see
that
the
controller
image
there
is
already
running
for
provider
home,
so
We
snuck
in
a
quick
demo
there
I
know
this
was
kind
of
a
conceptual
talk,
but
hopefully
this
end
tied
it
together
a
little
bit
and
yeah
I'd
love
to
answer
any
questions.
Folks
have,
if
that's
permitted,
given
how
far
overtime
we
already
are.
But
thanks
for
being
here,
foreign.
B
A
A
Quite
a
bit
in
the
crosswind
community
is
hey,
can
I
just
say:
I
want
one
type
right
and
just
get
that
one
and
it's
Associated
Behavior,
even
if
we
did
something
like
that,
let's
just
say
just
the
RDS
instance
came
and
not
all
of
our
AWS
types,
which
they'd
actually
show
that
here,
but
we
can
see
that
we
now
have
lots
and
lots
of
types
present
in
our
cluster.
If
we
just
wanted
one
of
those
we'd
likely
still
say
that
the
binary
that's
able
to
reconcile
all
of
them
is
the
associated
Behavior.
A
Some
of
the
guarantees
that
the
cross
plane
package
manager
gives
you,
namely
that
one
where
we
only
let
One
controller
or
one
set
of
controllers,
be
reconciling
a
group
of
types
is
important
to
make
this
work
right
if
you
can
just
add
arbitrary
other
controllers
via
other
means
which,
by
the
way
you
can
do
if
you're
not
adhering
to
Convention,
then
you
could
in
theory,
do
this
without
crossband.
But
you
need
to
replicate
that
sort
of
behavior
crossbane
is
a
fairly
generic
project,
though
right
there's
kind
of
anything
you
can
do
with
it.
B
C
So
one
of
the
things
that
has
become
a
little
bit
difficult
about
managing
custom
resource
definitions
is
often
version
updates
and
migration,
and
so,
when
you
showed
the
example
of
like
oh
cross,
plane
will
go
from
I,
don't
know
AWS
18
to
AWS
19..
How
does
it
handle
crd
version?
Conversions
and
just
you
know
anything,
that's
a
composite.
So
let's
say
the
deployment
spec
change
like.
How
would
you
handle
that
that
we
can
start
with
that?
I
have
a
few
more
but
yeah
cool.
A
A
We've
also
had
folks
develop
tools
where
they
say
hey
if
I'm
not.
Actually,
since
we
have
a
big
bundle
of
crds
in
a
single
package,
they're
saying
hey,
if
I
don't
have
an
instance
of
the
crd
just
go
ahead
and
delete
it
and
let
it
get
replaced
with
the
new
version,
so
not
a
silver
bullet,
but
it
does.
Does
the
job
did
you
have
I
think
she
had
a
couple
more
yeah.
C
You
briefly
mentioned
that
you
check
to
make
sure
that
only
one
controller
modifies
a
given
kind
in
a
cluster
does
that
include
like
the
composite
like
types
inside.
Let's
say
you
have
a
deployment,
that's
wrapped
by
a
crd
like
how
would
you
differentiate
like
the
scope
of
responsibilities
between
controllers
or
how
do
you
identify
that
yeah.
A
So
only
cross
plane
will
touch
the
the
composition
process
right
now.
So,
if
you
defined
an
xrd
well,
for
instance,
you
can't
put
an
xrd
into
a
provider
package,
we
say
you
can
only
have
crds
and
those
web
hook
configurations
as
well
and
then
in
the
composition
package,
there's
no
actual
Behavior
coming
in.
So
if
you
do
everything
through
the
crosswind
package
manager,
there's
no
way
to
install
additional
controllers
that
can
manage,
like
the
the
xrds,
for
instance,
the
higher
level
types
it
would
strictly
be.
A
Let's
say
you
have
you
define
an
xrd
and
then
you
put
that
in
another
composition
right,
so
you
have
nesting
of
abstraction.
Here,
it's
still
cross-plane,
that
would
say:
hey,
okay,
we'll
take
the
highest
level
of
abstraction,
we'll
render
out
all
of
the
things
it
composes
if
another.
One
of
those
is
an
xrd
we're
just
rendering
out
again
until
we
actually
bottom
out
to
a
primitive
type,
those
installed
by
a
provider
and
then
the
controllers
for
that
will
start
reconciling
it.
Sweet.
A
Yeah,
so
I
would
like
to
see
this
become
a
more
standardized
thing,
whether
that
you
know
involves
lots
of
people
installing
cross-plane
to
be
able
to
do
this
with
arbitrary
things
or
it
becomes
some
sort
of
more
generic
standard.
I
think
I'd
be
fairly
indifferent
to
it.
I,
don't
necessarily
think
it's
something
that,
for
instance,
belongs
in
the
kubernetes
API
server.
A
However,
if
if
someone
did
want
to
have
that
discussion,
I'd
definitely
be
open
to
it,
but
we're
kind
of
generically
talking
about
the
concept
of
using
content,
addressable
types
here
rather
than
saying
you
know
this
implementation
specifically,
is
the
best
example.
It's
just
the
one
that
we
use.
That's
been,
you
know
useful
for
us.
So
yes,
if
there
is
an
opportunity
to
make
this
a
generic
standard,
I
think
that
would
be
great.
A
Exactly
and
and
the
providers
who
are
generally
thought
of,
as
you
know,
managing
external
infrastructure,
that's
typically
how
people
think
of
cross
plane
they're
not
actually
restricted
to
that
in
any
shape
or
fashion.
So
you
could
actually
have
a
provider
that
did
almost
anything,
so
it's
kind
of
just
actually
Patrick
packaging
types
with
controllers.
So
if
you
wanted
to
use
cross
plain
in
that
mode,
that
would
be
somewhat
unconventional,
but
not
restricted.