►
From YouTube: Cloud Native Live: Crossplane Compositions
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Every
week
we
bring
you
a
new
set
of
presenters
to
showcase
how
working
with
how
they
work
with
cloud
native
technologies,
they'll
build
things,
they'll,
break
things
and
answer
your
questions
live
on.
Our
stream
join
us
every
wednesday
at
11
eastern
and
this
week
we
have
dan
magnum
here
to
talk
to
us
about
cross
plane
competition.
A
So
one
note
for
the
code
of
conduct:
this
is
an
official
live
stream
of
the
cncf
and,
as
such
subject
to
the
cncf
code
of
conduct,
please
don't
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
just
please
be
respectful
to
all
your
followers
participants
and
presenters
with
that.
I'm
super
excited
to
have
dan
on
the
show.
I've
heard
a
lot
of
great
things
about
crossplane.
A
B
Awesome
well
thanks
for
the
intro
bill,
and
I'm
super
excited
to
be
here
so
so
for
context
for
folks,
I'm
a
maintainer
of
the
open
source
crossplane
project,
which
is
a
cncf
sandbox
project
that
is
moving
into
incubation
or
in
the
process
of
doing
that,
and
I
also
work
at
upbound,
which
is
the
company
behind
crossplane,
the
crossplane
project,
and
so
last
week,
as
as
part
of
our
upbound,
offering,
we
had
a
big
announcement
about
our
new
our
new
product
offerings
and
one
of
those
was
the
first
enterprise
distribution
of
crossplane,
which
we
call
a
universal
crossplane
or
for
short
uxp,
which
is
what
I'll
refer
to
it
as
mostly
today,
but
around
that
right.
B
In
order
to
be
able
to
have
distributions
of
cncf
products,
you
have
to
have
a
conformance
program
which
basically
allows
folks
to
create
distributions
and
validate
that
they're
conformant.
So
a
lot
of
folks
are
probably
familiar
with
the
kubernetes
conformance
program,
so
our
conformance
program
is
similar.
So
today
I'm
going
to
talk
a
little
bit
about
that
conformance
program.
B
Well
well,
as
I
said
before,
we
came
on
air
definitely
feel
free
to
jump
in
at
any
point.
I
know
we
have
the
chat
going
here
so
so
ping.
Any
of
those
questions
off
me
or
feel
free
to
you
know
bring
up
your
own,
but
I'm
ready
to
go.
If
you
are
yeah.
A
Sure
do
you
want
to
kick
it
off
or
I
guess
maybe
the
first
question
for
people
that
don't
know
like
like
what
is
like
crossplane?
Can
you
give
like
a
like
10
second
overview.
B
Yeah
absolutely
so
a
lot
of
folks
come
to
crossplane
because
they
want
to
manage
cloud
infrastructure
from
the
kubernetes
api.
So
as
many
projects
and
organizations
that
have
been
on
this
live
stream,
we
extend
the
kubernetes
api
through
the
use
of
controllers
and
custom
resource
definitions.
So
the
initial
thing
that
folks
encounter
frequently
is
provisioning
infrastructure
via
kubernetes
api
types
right.
So
we
have
providers
which
essentially
give
you
the
ability
to
create
something
like
an
rds
instance
or
an
eks
cluster,
an
ec2
instance
on
aws
or
gcp
or
azure,
etc.
B
So
when
I
talk
about
building
a
platform,
really,
what
I
mean
is
creating
abstractions
on
top
of
these
granular
managed
resources
as
we
call
them,
so
you
may
have
the
ability
to
create
an
rds
instance
on
aws,
a
cloud
sql
instance
on
gcp
and
a
azure
sql
instance
on
azure,
and
what
we
want
to
be
able
to
do
is
for
infrastructure
operators
or
platform
developers
to
be
able
to
say
to
their
developers
within
their
organization.
B
This
is
how
you
create
a
database,
and
those
developers
are
really
not
worried
about
the
actual
implementation
details.
So
we're
going
to
go
through
that
actual
exact
exact
example
of
creating
a
database,
but
these
can
get
much
more
complex
and
we'll
talk
about
our
packaging
system
and
how
you
can
kind
of
build
and
share
these
different
abstractions.
B
Awesome,
so
I
have
a
number
of
things
that
we
can
show
today.
B
But
what
we're
looking
at
here
is
the
the
home
page
of
upbound,
and
this
was
just
launched
last
week
and
you'll
see
here
in
our
product
section,
the
universal
cross,
plane
uxp
is
kind
of
our
big
enterprise
distribution
that
we
just
launched,
but
we
also
have
a
registry
and
abound
cloud
components
as
well,
but
before
we
get
into
that
being
a
conformant
cross,
plane
distribution,
which
basically
means
you're
going
to
have
the
same
api,
both
syntax
and
semantics.
B
When
you
interact
with
uxp
and
crossplane,
you
can
actually
go
ahead
and
install
crossplan,
so
we're
just
on
the
crossplane
documentation
here
and
then
upgrade
to
uxp
using
some
of
our
tooling.
So
this
is
the
normal
flow
that
all
folks
go
through
when
they're
first
starting
with
crossplane.
They
typically
do
something
like
create
a
kind
cluster,
or
maybe
they
already
have
a
development
kubernetes
cluster
running
on
on
a
hosted
offering
and
then
they
install
crossline.
B
And
we'll
see
we're
spinning
up
a
1.20.2
kubernetes
cluster
here,
just
using
kind
locally.
I'm
sure
a
lot
of
folks
are
familiar
with
kind,
but
if
you're
not
it's
basically
a
a
way
to
run
kubernetes
and
docker,
as
as
the
name
would
suggest,
and
it's
just
a
nice
way
to
get
a
a
local
kubernetes
cluster
and
once
this
is
spun
up,
I'm
going
to
go
ahead
and
install
crossplane
and
maybe
we'll
talk
about
kind
of
the
different
components
once
that's
installed.
B
So
I
can
go
ahead
and
grab
this
helm
install
command
here
once
again
that
we
see
lots
of
folks
use,
I'm
actually
just
going
to
grab
this
portion
of
it
and
I'll
go
ahead
and
create
a
namespace
to
install
this.
In.
So
I'm
going
to
create
an
upbound
system
namespace
here
and
I
will
do
helm,
install
crossplane
and
I'm
going
to
put
that
in
the
outbound
system.
Namespace.
B
And
once
that's
installed,
you'll
see
we're
we're
using
crossplane
1.2.1,
which
is
our
most
recent
release,
and
if
we
look
at
our
pods
and
I'm
going
to
shrink
this
down
a
little
bit
just
so
folks
can
see,
it
looks
like
that's
still
large
enough.
Please
let
us
know
in
the
chat
if
it
needs
to
be
bigger,
but
you'll
see
here
that
we
have
kind
of
two
core
parts
of
crossplane
that
come
as
core
crossplane,
which
is
what
is
installed
via
home.
B
One
of
them
is
core
crossplan
itself,
and
the
other
is
the
rbac
manager,
and
the
reason
why
we
have
these
different
components
is
crossplane
actually
offers
its
own
package
manager
to
allow
you
to
install
extension
points
for
it
so
similar
to
how
you
can
install
controllers
and
crds
into
kubernetes.
We
have
packages
that
you
can
install
into
crossplane
in
the
form
of
providers
and
configurations,
so
folks
that
are
familiar
with
infrastructure's
code
tools
are
likely
familiar
with
the
concept
of
providers.
B
These
are
basically
things
that
just
give
you
the
ability
to
create.
It
looks
like
the
the
name
is
covering
the
bottom
line.
The
terminal
here
we'll
see
if
we
can
get
that
corrected
in
just
a
moment,
but
providers
are
are
basically
just
a
way
for
you
to
extend
cross
plans
functionality.
B
So
if
we
go
and
look
at
our
providers
and
I'll
go
over
here
to
our
documentation
site
make
that
a
little
darker
for
us,
we
can
take
a
look
at
something
like
provider
aws
and
basically
this
is
going
to
bring
a
bunch
of
different
crds
and
controllers
to
be
able
to
provision
these
different
things
in
kubernetes
and
once
those
are
installed
you
can.
You
know,
control
apply
your
rds
instance
or
something
like
that.
B
If
we
go
and
take
a
look
at
configurations,
which
is
what
we
actually
install
here
in
the
crossplane
getting
started
docs,
they
are
basically
higher
level
packages
that
declare
dependencies
on
providers.
B
So,
in
this
specific
configuration
that
we
use
in
the
cross
plane
getting
started
docs,
we
have
a
an
abstraction
for
a
postgres
sql
instance
and
then
backing
that
we
have
mappings
to
an
rds
instance,
a
different
configuration
of
rds
instance
where
it
creates
a
vpc
and
subnets
for
you.
We
have
a
cloud
sql
instance,
as
well
as
an
azure
postgres
sql
service
server
instance,
and
basically,
once
you
install
this,
the
provisioning
experience
looks
the
same
so
you'll
see
if
we're
using
aws
or
gcp.
B
The
only
thing
that
we're
changing
in
these
manifests
that
a
developer
would
actually
create.
Is
the
label
that
selects
to
them.
So
at
this
point
bill,
I
know
we're
kind
of
sprinting
through
a
lot
of
stuff.
Here,
trying
to
give
an
overview
of
crossplane
before
we
dive
into
how
upbound
cloud
works,
but
is
there
any
questions
that
have
come
up
for
you
or
any
parts
you'd
like
to
drill
down
on
further.
A
B
Awesome,
well,
I'm
not
going
through
installing
any
of
these
packages
right
now,
because
we're
going
to
upgrade
to
uxp
first,
so
I'm
going
to
go
ahead
and
show
that
so,
as
I
mentioned
before
as
part
of
our
announcements
last
week,
we
also
announced
the
cross
plane
conformance
program
with
the
cncf,
which
you
can
see
here
in
this
github
repo,
and
basically
this
defines
what
it
means
to
be
both
a
conformant
cross,
plane
distribution,
which
is
what
upbounds
uxp
is
as
well
as
conformant
providers
right.
B
So
what
makes
a
a
crossplane
provider
kind
of
like
valid
and
incompatible
with
other
crossplane
components.
So,
as
I
mentioned
before,
our
cross
plane
organization
here
has
a
number
of
different
providers
that
we
support
and
if
you
actually
hop
over.
This
is
something
some
folks
are
not
aware
of
into
the
crossblink
and
trib
org.
You
can
see
kind
of
in
development
providers
as
well,
so
you'll
see
things
like
github
github,
git
lab.
Excuse
me
new,
relic
things
like
sql,
ibm
cloud,
you'll,
see
things
like
digitalocean
github,
etc.
B
B
We
have
a
pretty
robust
community
around
crossplane,
so
right
now
the
main
providers
were
we're
kind
of
bootstrapped
along
with
the
initial
project
and
when
I
say
the
main
providers,
I'm
mostly
talking
about
the
big
cloud
providers.
B
We
also
have
a
number
of
other
ones,
as
you
saw
there
that
are
maintained
by
just
different
folks
within
the
community
and
really
anyone
can
go
and
write
them.
So
these
are
what
I'm
showing
our
example
of
open
source
providers,
a
lot
of
different
organizations
that
use
crossplane
actually
write
custom
providers
for
their
internal
infrastructure
systems,
so
they
might
have
some.
B
So
if
we
go
back
and
look
at
our
configuration
here,
just
like
how
we
have
these
mappings
to
types
in
provider,
aws
or
provider,
gcp
or
azure,
you
could,
you
know,
add
on
your
own
my
internal
infrastructure
system
and
create
a
composition
for
that.
And
then
you
can
do
things
like
scheduling
to
you
know
the
public
cloud
or
private
data
center
based
on
the
contents
of
the
workload
that's
going
to
be
consuming
the
database
or
other
infrastructure.
B
So
it's
really
infinitely
extendable.
So
I
guess
the
answer
to
your
question
would
be
that
anyone
writes
cross-plain
providers,
but
those
main
ones
are
maintained
by
the
crossplank
community.
B
So
providers
and
we
can
take
a
look
at
one
of
them-
are
our
most
popular
right
now
by
by
stars.
If
you
look-
and
I
think
by
image
pools
as
well,
would
be
provider
aws.
There
is
definitely
a
a
fair
amount
of
complexity
here
in
terms
of
it's,
like
you
know
anything
that
you'd
build
using
cube
builder
or
something
like
that,
but
with
some
extra
cross-plane
packaging.
So
you
can
see
there's
you
know
quite
a
few
api
types
here.
B
So
if
you're
just
getting
started,
writing
a
provider
might
be
necessary,
which
of
course
you
could
take
a
look
at
and
we
have
actually
a
provider
template
repo
here
which
allows
you
to
basically
just
do
a
one-click
create
from
this
repo
as
it's
a
template
repository.
So
that's
definitely
a
valid
way
to
get
started,
but
most
folks
are
our
infrastructure
or
platform
owners
who
consume.
B
You
know
things
that
are
already
defined
in
providers
and
in
that
case,
we'd
suggest
you
getting
started
with
composition
and
starting
to
define
kind
of
what
your
platform
looks
like
so
that's
kind
of
where
I'd
recommend
folks
go
unless
if
they
need
additional
functionality,.
B
Absolutely
so,
to
kind
of
like
continue
along
with
this
demo
and
show
what
conformance
means
first
of
all
I'll
say
that
we
have
a
a
plug-in
here
to
be
able
to
run
your
conformance
suite
your
crosslink
conformance
suite.
So,
for
instance,
we
run
this
against
upbounds
uxp
to
verify
that
it
is
a
conformant
crossplane
distribution,
and
this
is
just
like
how
kubernetes
does
it
as
well?
B
So
if
anyone
has
questions
about
the
conformance
program
or
about
what
it
means
to
be
a
conformant
provider
or
a
conformant
distribution
of
crossplane,
please
feel
free
to
reach
out
afterwards.
We'll
also
have
some
more
documentation
coming
for
this
in
the
coming
weeks.
B
So
with
crossplane
installed
in
our
cluster,
I'm
going
to
show
the
workflow
for
upgrading
to
uxp,
so
we
have
a
command
line
tool
called
up,
and
I
have
it
installed
here
on
my
local
machine
and
basically,
what
I'm
going
to
do
is
instead
of
doing
a
up
uxp
install
since
we
already
have
cross
plane
in
place,
I'm
going
to
do
an
up,
uxp
upgrade,
and
so
essentially
that's
going
to
say
with
whatever
crossplane
version
I
have.
B
I
want
to
upgrade
to
a
compatible
uxp
version,
so
one
of
the
restrictions
we
place
on
upgrading
to
uxp
is
the
ability
to
have
matching
versions,
so
we
version
uxp
and
a
schema
that
is
semantic
versioning
of
the
crossplane
version,
followed
by
a
a
uxp
iteration.
So
this
is
similar
to
something
like
gke
if
you've
seen
in
the
console
when
you're
picking
you
know
your
distribution
when
provisioning
a
kubernetes
cluster.
So
here,
as
I
mentioned
before,
we
have
the
1.2.1
version
of
crossplan
installed.
B
So
I'm
going
to
use
a
compatible
uxp
version
and
just
say
please
upgrade
to
that
and
it's
a
pretty
simple
operation
for
for
those
who
are
interested
in
the
technical
details
behind
the
scenes
we
actually
use
helm
under
the
hood
to
go
and
upgrade
to
uxp.
You
can
install
uxp
itself
with
helm
directly,
if
that's
a
requirement
or
if
you're
doing
it
through
a
cicd
pipeline
or
something
like
that.
B
But
we
also
have
these
additional
components
which
are
part
of
the
uxp
distribution
that
allow
you
to
do
things
like
connect
to
upbound
cloud
or
xgql
actually
gives
you
a
graphql
interface
into
the
crossplane
resource
model,
and
so
there's
there's
a
number
of
extra
components
that
you
get
when
upgrading
to
uxp
and
the
number
one
thing
is
the
ability
to
connect
outbound
cloud
so
I'll
go
ahead
and
hop
over
to
upbound
cloud,
and
we
can
take
a
look.
B
I
am
here
in
the
upbound
cloud
console
and
essentially
what
outbound
cloud
allows
you
to
do
is
create
what
we
call
control
planes.
So
control
plane
is
essentially
a
a
link
to
a
uxp
cluster
and
you
can
create
a
hosted
or
self-hosted
version,
so
hosted
essentially
means
that
we'll
spin
up
a
kubernetes
cluster
for
you
we'll
run
it
for
you,
we'll
install
uxp
there
and
we'll
give
you
a
a
friendly
interface
into
it.
We'll
also
allow
you
to
connect
via
cube
control.
B
If
you
like
to
you,
know,
be
able
to
do
any
operations
you
need,
or
you
can
run
self-hosted,
which
is
kind
of
the
the
big
feature
that
we've
seen
a
lot
of
customers
wanting.
They
want
to
be
able
to
run
uxp
in
their
data
centers
or
on
their
cloud
provider
and
connect
that
up
to
upbound
cloud
and
get
the
benefits
that
it
has,
and
so
today
we're
going
to
be
showing
off
this
self-hosted
ability.
B
Another
thing
I'll
mention
just
for
folks
who
want
a
bit
of
a
tour
of
the
bound
cloud
console
with
upbound
cloud.
You
can
have
your
personal
account,
so
this
is
this
is
my
personal
account
and
it's
kind
of
where
you
could
do
testing
and
development.
You
can
create
control
planes
as
well
as
repositories
which
we'll
take
a
look
at
in
a
minute
and
then
in
an
organization.
B
You
have
some
enhanced
features,
so
you
have
things
like
teams
and
users
the
ability
to
create
permissions
and
show
that
off
so
we'll
definitely
show
some
of
that
functionality
after
we
connect
up
our
control
plane.
B
So
if
we
look
at
the
self-hosted,
workflow
you'll
see
it's
using
this
up.
Cli
tool
that
we
released
another
thing,
I'll
mention
as
we're
going
through
this-
is
that
all
of
these
tools
are
actually
open
source.
So,
as
part
of
our
release
last
week
of
our
different
products,
we
went
ahead
and
open
sourced
a
lot
of
the
different
components,
including
uxp
and
the
upcli.
B
We
already
have
community
members
contributing
to
uxp,
and-
and
so
we
really
want
to
be
open
about
that,
and
we
can
talk
about
the
relationship
between
crossplane
and
uxp
further
on,
if
folks
are
interested
so
going
through
this
self-hosted
workflow
here,
I've
already
logged
in
to
my
abound
cloud
account
with
the
up
cli,
so
we're
gonna
run
this
control
plane
attach
command
and
then
pipe
the
output
to
uxp,
connect
and
I'll
go
ahead
and
type
that
in
and
we'll
talk
about
what
that's
doing
and
xp
here
is
just
short
for
control
plane.
B
So
we'll
call
this
cncf
live
and
I'm
going
to
create
this
in
the
dan
account
here
and
then,
like
I
said,
I'm
going
to
pipe
that
to
my
up
uxp
connect
and
what's
happening
here.
It
looks
like
I
left
off
attach
is
we're
basically
saying
to
outbound
cloud.
We
have
a
self-hosted
uxp
instance
that
we
want
to
connect
up
to
upbound
cloud,
so
please
basically
make
an
entry
for
us
to
be
able
to
connect
and
give
us
credentials
to
be
able
to
talk
to
outbound
cloud
from
the
from
the
cluster.
B
So
that's
what
up
cloud
xp
attach
is
going
to
do
it's
going
to
create
a
cncf
live
control
plane
and
give
us
a
jwt
to
be
able
to
pass
to
our
agent
to
be
able
to
connect
to
it
and
up
uxp
connect
is
really
just
to
help
our
method
to
get
that
secret
into
the
cluster
and
allow
the
agent
to
be
able
to
access
it
so
I'll
go
ahead
and
run
that
command
and
what
we'd
see
here
if
we
looked
behind
the
scenes,
is
take
a
look
at
our
secrets
in
the
upbound
system.
B
B
This
process
looks
different,
obviously,
if
you're
using
a
hosted,
control,
plane
versus
self-hosted
one
so
in
the
hosted
case,
we're
actually
spinning
up
this
kubernetes
cluster
for
you
installing
uxp
and
then
giving
you
access
in
the
self-hosted
case.
You'll
see
it's
it's
pretty
quick
right,
because
this
cluster
is
already
running
and
we
just
need
to
establish
communication
between
the
two.
B
B
In
this
case,
we
already
have
cube
control
access
to
our
cluster,
but
if
you're
running
hosted-
or
you
wanted
to
give
team
members
within
your
org,
the
ability
to
connect
via
cube
control
to
your
cluster,
we
have
some
nice
commands
to
be
able
to
do
that
using
your
upbound
cloud
account.
B
So
if
we
want
to
go
ahead
and
actually
use
this
for
something
we
can
get
started
by
going
to
browse
outbound
registry
and
bill,
I
wanted
to
give
you
another
moment
here.
I've
kind
of
been
keeping
an
eye
on
the
chat,
but
is
there
anything?
That's
come
up
that
you
wanted
to
chat
more
about
before
we
move
on.
A
No,
I
I
think
we
should
keep
going
with
the
demo.
I
have
a
couple
questions,
but
I
don't
want
to
drop
the
phone.
I
think
yeah.
I
think
you
got
this
momentum
going
now.
B
Awesome
awesome.
Well,
I
I
do
like
to
go
through
a
lot
in
these
demos.
So
definitely
feel
free
to
just
interrupt
me
with
anything
that
comes
up,
but
we
have
moved
over
to
the
registry
here.
The
upbound
cloud
registry
is
actually
just
a
an
oci
registry,
so
all
of
crossplane
packages
are
packaged
as
oci
images,
but
they're
kind
of
special
oci
images
and
that
they
are
single
layer
and
just
contain
a
yaml
stream
in
them.
B
So
maybe,
if
we
have
some
time
at
the
end,
I'll
actually
look
into
the
contents
of
these
packages.
But
once
again
I
mentioned
that
we
have
different
providers
as
well
as
configurations
and
configurations
can
declare
dependencies
on
the
providers
so
with
some
kind
of
like
extra
stuff
we
provide
in
the
upbound
registry.
B
We
allow
you
to
provide
metadata,
which
makes
these
this
different
information
about
the
packages
present
and
also
shows
things
like.
You
know
the
dependencies
on
providers
for
configurations
as
well
as
different
information
and
links,
and
that
sort
of
thing-
and
we
can
talk
about
how
to
do
that
in
a
bit.
B
But
I'm
going
to
go
ahead
and
go
with
our
getting
started
package
here,
which
is
a
really
simple
package
that
we
use
in
our
documentation
here,
just
to
get
started
with
uxp,
and
it
only
declares
a
dependency
on
the
aws
provider
and
it's
going
to
give
us
that
postgres
database
abstraction
and
a
mapping
to
an
rds
instance
that
we
are
looking
at
originally
in
the
crossplane
docs,
so
normally
with
crossplane
or
even
with
uxp
you'd
go
through
and
you'd
install
this
package
via
cubecontrol
and
our
crossplane
plug-in,
and
you
specify
you
know
where
that
package
resides.
B
Once
again.
Our
registry
is
just
an
oci
registry,
so
you
can
also
push
these
to
docker
hub
or
or
anything
like
that.
But
if
you're
connected
up
to
bound
cloud,
you
can
just
click.
This
run
an
upbound
cloud
command
and
whether
it's
hosted
or
self-hosted,
you
have
the
ability
to
go
and
install
this
into
your
cluster.
Via
this
nice
kind
of
ui
workflow,
you
can
select
the
version
that
you
want,
we'll
use
the
0.0.2
and
you
can
select
the
control
plane
it
goes
into,
and
so
what
we're
doing
right
now.
B
I'd
like
for
folks
to
think
about
this
as
we're
building
our
platform
right.
So
the
goal
here
is
to
not
give
developers
the
same
kind
of
interface
that
they'd
have
with
aws
and
have
them
need
to
understand
all
the
parameters
that
they
configure
on
one
or
many
cloud
providers
or
infrastructure
services.
B
So
I'm
going
to
select
this
cncf
live
cluster,
which
is
connected
up
to
my
local
machine
here,
and
it's
going
to
be
a
pretty
quick
installation
here,
because
it's
basically
just
creating
a
configuration
package
type
in
the
cluster
which
crossplane
then
reconciles
folks
are
familiar
with
crossplane
and
you'll,
see
that
it
specified
this
provider
aws
dependency
and
then
based
on
the
versions.
B
If
we
do
kgit
package,
which,
if
folks
are
familiar
with
crossplane
you're,
probably
familiar
with
this
command
you'll,
see
that
our
getting
started
configuration
was
created
once
again
I'll
make
this
a
little
smaller.
For
so
folks
can
see,
you'll
see
that
we
have
our
getting
started
configuration
as
well
as
an
appropriate
provider.
Aws
version
installed
and
you'll
see,
aws
is
ready
and
our
getting
started.
Configuration
is
just
waiting
on
all
dependencies
to
become
available
and
now
that
they
are
you'll
see
it
also
become
available
here
shortly.
B
Sometimes
it
has
a
blip
there,
but
you'll
see
they're
both
installed
and
healthy.
Now,
and
if
we
look
at
our
cluster
now,
we
can
take
a
look
at
our
crds
and
you'll
see
we
just
brought
in
a
ton
of
different
aws
crds,
so
installing
that
provider
is
essentially
going
to
bring
along
all
these
different
crds
and
controllers
to
reconcile
them.
You'll
also
see
that
we
have
some
crds
for
getting
started.
I
believe
is
the
org
here
or
they
might
be
an
upbound.
B
We
can
take
a
look
actually
because
I'm
gonna
show
you
the
source
of
what
we
actually
installed
here.
So
the
package
contents
are
actually
in
the
universal
cross,
plane
re
if
we
go
in
this
configuration.
This
is
all
that's
in
our
oci
image
here.
So
if
we
look
at
our
crossplan.yaml,
this
is
where
we're
specifying
our
dependency
on
provider
aws.
A
So
there
is
a
is
a
question
in
the
chat.
If
this
operation
fail
fails,
where
would
I
be
able
to
see
the
error
logs.
B
Yeah,
so
it
depends
on
kind
of
what
your
persona
is.
You
could
go
through
outbound
cloud
to
look
at
the
status
of
these
different
packages.
Also,
you
know
if
you're
more
savvy
on
the
command
line,
or
something
like
that
you
can
do
things
like.
Let's,
let's
show
the
events
here,
so
we
can
try.
B
Okay,
describe
our
configuration
here
and
just
like
any
kubernetes
resource.
If
you
spell
the
command
correctly,
you
get
events
on
that.
You
can
also,
you
know,
take
a
look
at
the
provider.
So
let's
do
the
same
here.
B
And
you
can
see
kind
of
the
different
step
it
takes
to
install
them
and
if
you
want
to
you
can
see,
we
have
these
different
revisions
which
basically
allows
you
to
roll
forward
and
backwards.
But
you
can
see
we'll
show
the
configuration
revision
here.
You
can
see
explicit
information
about.
Let's
see
configuration
revision,
you
can
see
the
information
about
dependencies
found
and
installed.
So
essentially
just
like
any
kubernetes
resource.
We
have
information
that
we
surface
there.
B
Also,
if
you'd
like
to
get
you
know
deeper
into
the
weeds,
you
can
look
at
the
logs
of
the
the
cross
plane
pod,
which
would
be
the
main
core
cross
plane
component
here
and
see
what's
happening,
one
of
the
other
things
I
wanted
to
point
out
here
as
when
a
provider
is
installed.
B
I
mentioned
all
those
crds
that
are
brought
to
the
cluster,
but
we
also
need
controllers
to
reconcile
those
and
create
those
externally.
So
here
you'll
see
our
actual
controller
for
our
provider
aws
here
and
this
pod
is
running
and
basically
watching
those
crd
types
that
we
installed.
B
So
once
again,
taking
a
look
in
the
console,
you'll
see
that
we
now
can
see
that
we
have
some
populated
information
here
in
the
form
of
our
providers
and
configurations.
And
if
we
look
at
the
provider,
aws
you'll
see
all
the
different
groups,
all
the
different
api
groups.
B
But
in
order
to
be
able
to
do
that,
we're
going
to
need
to
create
some
credentials
to
be
able
to
talk
to
aws.
So
the
way
that
we
provide
credentials
to
providers
in
in
crossplane
is
we
create
a
secret
with
some
credentials
in
it.
So
we're
just
calling
this
aws
credits
here
and
I
already
have
my
creds.com
there,
so
that
was
pretty
easy.
We
created
that
and
then
we
create
a
provider
config
which
basically
just
instructs
our
aws
provider.
B
So
I
already
have
our
config.yaml
here,
so
I
will
exactly
what
that
looks
like
it
looks
just
like
we
have
there
in
the
documentation
I'll
go
ahead
and
apply
it.
Another
thing
I
want
to
note
is,
since
we
named
this
default,
it's
going
to
be
used
as
the
default.
I
don't
specify
a
a
different
provider
config.
What
that
allows
you
to
do
is
basically
say
in
this
situation.
Use
these
credentials
and
this
one
use
these
ones
which
allows
you
to
point
at
different
accounts
and
sets
of
credentials,
and
that
sort
of
thing
all
right.
B
So
we
have
our
provider
config
created.
So
at
this
point,
we're
ready
to
create
any
of
the
abstract
types
that
we
defined.
So
let's
take
a
look
at
what
this
might
look
like
for
a
developer
who's.
You
know
deploying
their
app
via
helm
or
something
like
that
and
wants
to
be
able
to
get
a
postgres
database
to
interact
with
it.
They
have
a
pretty
simple
interface
here,
where
they're
only
needing
to
define
the
storage
size
behind
the
scenes
here.
B
You
know
saying,
for
instance,
if
this
is
created
in
this
namespace,
it
will
do
this
if
it's
creating
a
different
one,
it
will
do
something
else
that
sort
of
thing
you
also
get
to
define.
You
know
what
credentials
those
are
provisioned
with,
etc.
So,
once
again,
focusing
here
on
defining
what
interface
you're
giving
to
developers
to
you
know
provision
a
postgres
database
alongside
their
deployment
of
their
application.
B
So
I'll
go
ahead
and
apply
this
and
you'll
see
it
gets
created,
and
we
can
get
this
just
like
you
know
any
other
resource
in
our
kubernetes
api
and
you'll
see
it's
not
ready
yet
because
it's
actually
provisioning
a
number
of
different
resources
and
when
those
are
all
provisioned,
it's
going
to
create
a
connection
secret,
which
we
specified
as
db
con
here,
which
is
going
to
have
basically
all
the
credentials.
We
need
for
our
application
to
be
able
to
connect
to
the
database.
B
We
provision,
but
in
outbound
cloud
you're,
going
to
get
this
experience
of
being
able
to
see
this
and
how
it
maps
the
underlying
resources
in
the
cluster.
So
you
know
everything
behind
the
scenes
here
is
a
kubernetes
object.
So
if
you're
really
familiar
with
how
crossplane
works
and
how
you
know
different
things
interact,
then
you
could
just
use
cube
control
directly.
B
This
gives
a
really
nice
interface
for
that,
as
well
as
ability
to
do
user
management
for
who
can
create
what
so
you'll
see
here
that
when
we
look
at
our
abstract
type
here,
we're
going
to
get
some
nice
stop
light
status
around
whether
it's
available
or
unavailable,
and
since
it's
unavailable,
let's
take
a
look
at
the
different
components
and
see
what
may
be
preventing
it
from
coming
available.
So
you'll
see
here
that
we
have
our
subnets
and
vpc.
Those
all
look
good
to
go.
B
Our
security
group
route
table
internet
gateway
and
db
subnet
group
are
also
already
but
we're
waiting
on
our
rds
instance,
which
makes
sense
right
because
those
other
resources
are
kind
of
networking
components
that
get
created
immediately.
One
rds
instance
takes
a
while
to
come
up
and,
if
you're
wondering
where
all
these
came
from,
if
we
look
back
into
our
composition
here
for
the
package
that
we
installed
you'll
see
all
of
these
present
in
the
composition.
B
So
we
basically
said
that
abstract
type
maps
to
these
underlying
types,
so
they
get
created
directly
and
there's
a
lot
of
functionality
built
into
this
composition
model
that
we've
defined
that
allow
you
to
say
things
like
match:
controller
ref,
which
means
that
when
we
create
this
rds
instance,
it's
going
to
use
the
db
subnet
group
from
the
same
composition.
B
So
if
you
created
a
bunch
of
these
right,
you
want
your
rds
instance
to
be
provisioned
with
the
components
that
are
provisioned
alongside
it.
So
there's
a
lot
of
different
facets
to
composition
and
and
kind
of
the
schemas
you
can
provide
here
and
you'll
also
see
that
the
way
that
we
populate
from
the
abstract
type
to
the
underlying
types
is
we
say
from
field
path.
B
So,
once
again,
if
we
looked
at
our
postgres
instance,
this
storage
gb
field,
which
is
kind
of
like
an
abstract
representation
of
storage
right
there
might
be
different
parameters
for
different
types
of
databases
and
we're
mapping
that
to
the
allocated
storage
field,
which
is
essentially
what
aws
says,
is
a
parameter
to
specify
storage
size
for
an
rds
instance.
B
So,
as
that
comes
up,
we
can
once
again
see
kind
of
the
status
of
things
and
we
can
drill
down
lower
and
you
can
see
that
we
had
some
warnings,
but
we
also
got
to
the
latest
one
with
a
successfully
requested
creation
of
external
resource,
and
we
can
wait
for
this
to
come
available.
B
Once
again,
as
I
mentioned,
it
will
wait
until
the
abstract
type
will
wait
until
all
the
underlying
resources
are
available
and
that
secret
can
be
populated,
and
if
we
wanted
to
actually
look
at
these
directly,
we
could
do
something
like
kit,
aws
and
we'll
see
all
these
different
resources
here,
including
our
rds
instance,
which
is
not
quite
ready.
B
Yet
once
that
does
come
available
in
the
namespace
that
we
created
our
postgres
instance,
we
should
see
a
connection
secret
get
created
and
it's
not
there
yet
right,
because
it's
not
ready
once
it
is
ready
that
connection
secret
will
be
available.
So
if
you
reference
that
from
your
deployment
to
be
able
to
get
those
credentials
into
your
application,
to
connect
to
the
database,
you'll
be
able
to
see
that.
B
So
I
know
we
ran
through
a
quite
a
few
different
things
and
there's
some
some
some
more
stuff
that
I
could
go
through
here
to
show
off,
but
once
again
wanted
to
pause
and
and
give
you
bill
an
opportunity
to
ask
any
questions
or
anyone
in
the
chat
as
well.
B
A
B
Now,
well,
that's
high
praise
coming
from
dan
as
as
he's
certainly
a
big
name
in
the
in
the
cncf
community.
A
B
Yeah
absolutely
so
the
first
thing
I'd
say:
is
it
bundles
the
exact
cross,
plane
distribution?
That
upstream
is
so
those
components
are
going
to
look
exactly
the
same,
at
least
for
the
time
being
one
of
the
things
that,
if
you're
familiar
with
how
kubernetes
works,
you'll
see
similar
patterns
in
cross
crossplane,
we
build
crossplane
focusing
on
interfaces
rather
than
implementations.
B
So
what
I
mean
by
that
is
when
there's
an
opportunity
to
create
a
kind
of
plug-in
model
or
the
ability
to
support
different
functionality,
we
opt
to
go
for
that
plug-in
model.
So
with
uxp,
we
have
the
opportunity
to
kind
of
replace
or
put
in
our
own
implementations
behind
different
plugins.
So
an
example
would
be
composition.
One
of
the
things
we're
talking
about
right
now
is
being
able
to
support
different
composition,
engines,
there's
other
things
like
deployment
models
in
terms
of
how
providers
actually
get
provisioned
and
their
controllers
run.
B
So
there's
lots
of
opportunities
to
be
kind
of
opinionated
about
the
implementations
behind
these
interfaces.
So
that's
the
first
thing
today,
the
main
part
of
uxp,
that's
different
from
crossplane
is
the
ability
to
connect
it
up
to
about
cloud.
That
being
said,
it's
kind
of
a
a
open
point
right
for
us
to
be
able
to
add
in
new
functionality,
but
to
be
clear,
we'll
never
keep
functionality
out
of
crossplan,
and
we
don't
actually
even
have
that
prerogative
right,
because
crossland
is
a
cncf
project.
B
It's
not
run
by
upbound,
though
lots
of
the
maintainers
currently
work.
It
upbound.
It's
a
community
driven
effort
to
decide
what
goes
in
there.
So
really
uxp
just
gives
us
an
opportunity
to
say
we
think
this
is
the
best
implementation
behind
this
interface.
So
we're
going
to
use
that,
but,
as
I
pointed
out
at
the
beginning,
uxp
is
totally
open
source
as
well.
So
everything
that
we
just
deployed
in
our
cluster
is
present
in
this
repo.
You
can
go
and
see
what
we're
doing.
What
we're
adding
you'll
see
the
different
components.
B
You'll
see
that
we
actually
bundle
crossplane
into
the
deployment
here,
and
this
is
100
open
source.
So
you
know
in
terms
of
functionality,
it's
really
things
that
we
think
make
using
cross
plane
alongside
about
a
better
experience
and
and
the
different
things
around
security,
and
that
sort
of
thing
that
are
also
added.
A
Okay,
yeah
definitely
just
another
piece
of
fan
mail
here,
oh,
I
guess
sorry
not
for
you.
It's
from
the
chat,
so
eve
says
dan
is
definitely
the
best
cell
yeah.
B
A
B
Absolutely
well,
first
of
all
I'll
say
eve,
I
feel
your
pain.
That
is
definitely
something
that
is
difficult,
just
in
general,
so
outside
of
managing
your
cloud
provider
resources
with
kubernetes,
even
if
you're
just
doing
things
in
the
console,
you
know
click
op
style,
it's
a
hard
problem
and
there's
lots
of
different
moving
pieces.
B
What
I'd
say
about
that
is
what
we're
trying
to
do
here
is
give
the
folks
that
have
really
strong
expertise
in
those
areas
and
the
ability
to
troubleshoot
those
issues
we
want
to
give
them
ability
to
build
abstractions
that
make
developers
not
have
to
troubleshoot
those
issues
right.
So,
for
instance,
I
know
I
showed
in
the
beginning-
and
we've
touched
on
this
a
few
different
times,
but
in
this
demo
that
we
do,
we
opt
to
create
all
new
vpcs
and
subnets,
and
that
sort
of
thing
the
reason.
B
Why
is
that
that's
the
best
way
to
get
this
to
work
right,
we're
basically
provisioning
all
new
infrastructure
to
get
this
database
stood
up?
You
could
also
reference.
You
know
existing
subnets
or
or
an
existing
vpc.
You
know
and
provide
your
database
in
that
manner,
but
in
this
case
we're
opting
as
platform
builders
to
say.
We
want
to
give
you
an
all-in-one
solution
and
we'll
make
sure
that
those
different
components
work
together.
B
That's
not
to
say
that
you're
not
still
going
to
run
into
issues-
and
you
know,
there's
gonna,
be
credentials,
mismatches
and
that
sort
of
thing
and
that's
really
an
area
where
we
as
upbound
would
like
to
supply
additional
information.
So
obviously,
if
you're,
a
customer
of
the
company
or
something
like
that,
we
have
additional
insight
into
your
environments
and
that
sort
of
thing
at
the
level
that
you
you
ask
us
to
essentially-
and
so
we
can
do
things
you
know
like
evaluate
when
you
create
this
abstract
type.
B
For
instance,
how
does
that
actually
map
to
credentials
being
used?
So
how
does
it
know?
You
know
to
be
able
to
create
an
rds
instance?
How
does
it
have
permissions
to
create
all
these
different
resources?
So
you'll
remember
at
the
beginning,
we
created
our
provider
config
and
if
we
look
for
that,
we
should
be
able
to
see
it.
So
we
have
our
default
provider
config,
which
points
at
our
secrets.
Right.
B
You
have
a
a
whole
ecosystem
view
of
the
cluster,
then
you're
able
to
say
what
credentials
what
I
am
roles
and
permissions
does
that
secret
have
and
then
we're
able
to
trace
from
resources
to
get
provisioned.
So
from
that
kubernetes
object
to
the
granular,
managed
resources
that
come
out
of
that
and
then
see
what
kind
of
credentials
are
associated
with
that,
and
then
we
can
give
you
a
view
of
maybe
why
your
rds
instance
isn't
being
able
to
be
provisioned.
B
So
that's
definitely
a
key
problem
area
where
I
think
different
distributions
of
crossplane
are
able
to
address
in
different
ways,
but
it's
certainly
something
we
as
upbound
would
like
to
provide
greater
insight
into.
A
A
Yeah
there
you
go
we're
all
friends
here,
so
the
next
one
is
from
go
for
it
is
high.
Upbond
is
where
the
secrets
created
in
my
cluster
or
is
it
just
using
them.
B
So
this
is
a
great
question
and
another
another
case
where
kind
of
using
something
like
uxp
is
different
than
crossplane.
So
importantly,
upbound
is
not
using
your
secrets
or
or
accessing
them
in
any
way,
and
the
reason
why
is
really
all
we're
doing
from
the
bound
cloud
perspective
is
showing
you,
these
kubernetes
objects
that
you've
installed
via
a
bound
cloud
or,
or
you
know,
you've
installed
into
your
cluster
and
exposed
to
bound
cloud
what's
actually
accessing
that
secret
is
running
in
your
cluster
directly
right.
B
So
the
thing
that
needs
to
be
able
to
assume
those
credentials
is
our
provider
aws
controller
pod.
Here,
excuse
me
and
essentially
it's
the
only
thing
needs
to
get
to
it.
So
there's
no
reason
why
upbound
would
ever
need
to
touch
your
aws
credentials
or
something
like
that.
We
basically
just
need
to
make
sure
the
controller
is
running
and
you're
in
charge
of
putting
the
credentials
there.
B
That
being
said,
there
are
a
number
of
different
integrations
to
be
able
to
put
those
credentials
into
your
cluster,
so
I
know
on
crossplane,
for
instance,
we
have
an
example
of
I
believe
in
our
guides
here
using
vault
to
be
able
to
drop
those
credentials
into
your
pod
and
that,
basically,
is
just
controlled
by
how
you
install
your
provider.
So
there's
lots
of
different
ways
to
manage
your
secrets,
but
long
story
short,
no
we're
not
looking
at
your
abs
credentials
or
anything
like
that.
A
Cool,
oh
the
next
one
is
from
you
is
say,
thank
you
by
the
way,
please
bring
back
the
flake
finder
fridays.
Any
any
comment
about
that.
B
Absolutely
so
we,
I
think
we've
only
had
two
episodes
of
flight
finder
fridays,
which
is
definitely
less
than
we
wanted.
We
want
to
do
at
least
once
a
month
for
folks
who
aren't
familiar
flake
finder
fridays
is
essentially
a
kubernetes
community
show
where
myself
and
rob
kilty
go
through
and
talk
about
different
test
failures
in
upstream
kubernetes
and
why
they
happened
and
kind
of
walk
through
how
test
infrastructure
works
and-
and
you
know,
visit
some
different
parts
of
of
kubernetes
and
in
the
process,
rob
actually
messaged
me
this
week.
B
So
I'll
say
the
the
delay
in
episodes
is
100
on
me
not
on
rob
and
he's
certainly
pushing
me
to
get
those
back
going
again.
So
I'm
hoping
that
we'll
get
some
more
episodes
out
there.
As
always,
if
there's
specific
topics
you
want
addressed,
please
let
me
know
and
we'll
try
to
work.
Those
in.
A
B
Yeah,
so
this
is
a
great
question
that
a
lot
of
folks
have
so
one
of
the
things
that
crossplane
does
really
well.
Is
it
spins
up
new
kubernetes
clusters
right?
So
then
you
come
to
this
kind
of
situation
where
you're
wondering
if
crossplane
needs
to
be
installed
in
all
those
clusters
or
crosswinds,
just
used
to
manage
other
kubernetes
clusters
and
what
that
looks
like
one
of
the
things
I
would
point
to
is
in
the
cross
plane
docks
again.
B
We
have
a
new
guide
section
on
multi-tenant
crossplane
talking
about
some
of
these
different
models
and
how
you
might
want
to
set
this
up.
It's
also
really
useful
for
understanding
composition,
honestly,
because
that's
a
big
part
of
the
multi-tenant
aspect,
one
of
the
things
we
didn't
cover
here
today
in
terms
of
providers
and
maybe
I'll
I'll
briefly
show
it
quickly.
Is
we
have
providers
for
things
like
helm?
So
this
is
actually
one
of
our
most
popular
providers,
which
you
may
think
how
does
provider
helm
work
alongside
something
like
provider
aws?
B
If
you
want
to
do
something
more
complex,
like
maybe
spin
up
an
eks
cluster
and
then
deploy
a
helm
chart
into
it,
because
you
can
target
any
api,
including
the
kubernetes
api,
that's
entirely
possible
with
composition,
and
you
can
actually
build
these
compositions
together
and
create
higher
and
higher
level
abstractions
or
just
basically
take
the
different
pieces.
B
So
this
is
an
example
of
another
configuration
package
that
we
could
show
off,
but
this
cluster
abstraction
is
a
pretty
simple
schema
here,
not
a
lot
of
fields
where
you're,
basically
just
saying
the
size
of
an
account
of
the
nodes
in
the
cluster.
But
behind
the
scenes
this
is
doing
two
different
things.
One
of
them
is
spinning
up
an
eks
cluster,
which
has
quite
a
few
components
and
iam
roles
once
again
getting
back
to
eve's
comment.
B
We
want
to
make
it
easy,
have
the
right
permissions
set
up,
so
it's
creating
an
eks
cluster,
but
it's
also
creating
a
helm
release
for
prometheus
into
that
cluster.
I
mean
because
of
the
way
that
we
allow
you
to
reference
resources
between
different
cross-plane
compatible
resources.
You
can
say
wait
for
this
kubernetes
cluster
to
come
up,
but
the
the
user
basically
has
a
single
interface
that
they
did
actually
spin
up
that
cluster
and
install
things
into
it.
B
So
if
we
look
at
our
higher
level
composition
here,
we're
taking
that
eks
abstraction
and
that
services
abstraction
and
basically
pointing
the
services
one
to
the
eks
cluster,
so
you
can
really
do
a
lot
of
different
things.
With
this
composition,
like
in
this
case,
spinning
up
a
you
know,
a
kubernetes
cluster
with
prometheus.
B
You
could
also
spin
it
up
with
your
application
in
it,
so
that
would
be
one
model
of
of
doing
multi-cluster
right
where
you
have
kind
of
your
control
plane
on
upbound
cloud,
and
you
spin
up
other
clusters
and
from
your
control
plane.
You
put
your
applications
in
there,
including
you
know
your
database
credentials
and
that
sort
of
thing,
so
all
of
the
kind
of
infrastructure
provisioning
happens
from
a
single
cluster.
We
also
see
folks-
and
this
is
more
in
this
multi-cluster
multi-tenancy
model-
they
create
a
bunch
of
different
clusters,
so
that
could
be.
B
You
know
a
bunch
of
different
clusters
out
by
on
cloud
that
could
be
them
using
crosswind
to
spend
other
clusters
and
using
helm
to
install
crossplane
into
those
clusters
which
is
kind
of
a
meta
scenario
there,
but
something
folks
do
and
one
of
the
things
that
we
want
to
support
in
that
case
is
instead
of
trying
to
maintain
connection
between
all
of
these
different
clusters
we
like
for
you
to
be
able
to
treat
them
as
units
where
you
can
create
a
reproducible
platform
in
them.
B
So
you
know
it
was
as
easy
to
create
this
kind
of
abstraction
for
our
postgres
database
as
installing
a
single
cluster,
but
that
actually
brought
along
kind
of
a
lot
of
different
complexity
that
we
had
designed
behind
the
scenes.
And
you
know
this
is
probably
the
simplest
configuration
package
you
could
have
most
folks
who
use
crossplane
would
have
you
know,
potentially
hundreds
of
abstractions
here,
you'd
have
your
database,
your
cluster,
your
vm.
You
know
some
networking
stack
et
cetera.
B
Basically
anything
you
wanted,
because
these
are
packages,
oci
images
that
can
be
versioned
and
pushed
around
to
either
the
cross
point
or
the
upbound
registry
or
docker
hub,
or
you
know,
harbor
or
whatever
you
like.
These
can
be
installed
into
a
new
cluster,
so
to
get
a
a
same
platform,
so,
let's
say
you've
kind
of
defined.
What
your
heroku
looks
like
for
your
organization
to
reproduce
that
in
another
kubernetes
cluster
is
just
an
up,
uxp
install
and
then
installing
the
configuration
or
even
doing
that
in
a
single
step.
B
But
one
of
the
benefits
of
using
a
composition
is
your:
your
provisioning
happens
in
a
namespace,
so,
for
instance,
we
created
our
postgres
instance
in
the
default
namespace
based
on
that
namespace.
So
let's
say
you
have
a
one
namespace,
a
team
two
and
a
team,
three
namespace
based
on
the
namespace
that
the
actual
abstraction
is
created
in
you
can
control
how
that
mapping
happens
to
individual
managed
resources,
so
maybe
team
one.
B
You
want
them
to
use
specific
credentials
or
a
specific
aws
account
when
you
know
their
their
abstraction
is
created.
So
when
they
create
a
postgres
database,
it
goes
into
the
team.
One
aws
account.
B
You
can
actually
use
the
same
underlying
composition
and
just
use
things
like
our
patches
here
to
say
from
wherever
that
claim
was,
which
is
what
we
call
the
abstraction
from
whatever
namespace
that
was
in
use
the
provider
config
that
references
that
so
it
gives
you
a
really
powerful
abstraction
mechanism
that
also
provides
isolation
between
different
name
spaces
and
that
sort
of
thing
so
definitely
would
encourage
folks
checking
out
this
guide
and,
I
would
say,
to
kind
of
harp
on
a
bounce
functionality
there.
B
One
of
the
things
we
didn't
talk
about
too
much
is
the
user
management
aspect
of
this.
So
for
these
different
teams
that
you
have,
you
can
give
them
permissions
in
a
specific
control
plane.
So,
for
instance,
in
cncf
live.
I
could
give
this
view
editor
owner
this
actually
maps
to
rbac
in
your
cluster
as
well,
which
means
that
you
know
if
they
have
cube
control
access
or
a
get
ops
pipeline,
or
something
like
that.
B
B
So
now,
whatever
token
I
use
with
the
robot
account
that
we
added
is
now
going
to
have
that
type
of
access
to
the
cluster,
so,
for
instance,
instead
of
cube
control,
applying
my
my
postgres
instance
here
I
could,
you
know
put
that
in
my
manifest
that
I
commit
to
my
github
repository
and
it
gets
deployed
using
the
credentials
of
that
robot
account.
So
that's!
Actually
what
we
encourage
folks
to
do
mostly
is
to
use
a
git,
ops
workflow.
B
We
really
embrace
that
and
we
encourage
folks
to
use
git
ops
for
absolutely
everything,
because
then
you
have
versioned.
You
know
config
for
your
manifest
and
once
again,
if
you
have
that
stored
in
git,
it's
as
simple
as
installing
crossplane
and
installing
your
configuration
and
then
deploying
whatever's
in
that
github
repository
and
you've
brought
up
the
same
exact
infrastructure
you
had
as
before.
A
Yeah
cool,
I
love
the
shout
out
to
kidops,
so
we
have
about
like
three
minutes
left
here.
One
question
that
I
had
that
we
didn't
get
to
cover
earlier.
You
talked
earlier
about
kind
of
this
conformance
stuff.
So
can
you
tell
me
what
does
it
actually
mean
to
be
like
a
conformant
cross-plane
distribution
or
provider.
B
Yeah
absolutely
so
some
of
that
is
still
underway
right
now,
but
you
can
kind
of
go
through
the
instructions
here
to
understand
exactly
what
you
had
to
pass
to
be
considered
conformant.
B
We
also
have
things
like
provider
and
configuration
testing
within
core
crossplane,
so
that
would
do
things
like
create
a
provider
or
maybe
a
better
example,
would
be
create
this
configuration
and
make
sure
all
of
its
dependencies
get
resolved.
That
would
be
a
good
example
of
that.
If
you're
not
able
to
do
that,
then
you
wouldn't
be
a
conformant
crossplane
distribution.
B
And
then,
if
we
look
over
in
provider,
they
would
do
things
like
you
know,
make
sure
that
it
gets
installed
and
becomes
healthy,
make
sure
all
the
crds
that
it
creates
fit
the
cross,
plane
conformance
model,
essentially
all
of
the
crds
that
providers
in
crossplane
have
have
some
standardized
fields
with
sandbed
in
them,
so
just
different
conditions
and
the
status
and
that
provider
config
ref
and
that
sort
of
thing.
B
So
that's
really
all
this
is
checking,
and
you
can
just
run
it
through
the
the
plugin
and
it'll
make
sure
that
you're
up
to
date-
and
we
actually
have
quite
a
few
folks
that
are
already
interested
in
doing
that.
For
instance,
I
think
all
of
these
different
organizations
you'll
see
folks
from
each
of
these
orgs,
so
equinix
metal,
ibm,
aws,
azure
here
they're,
all
you
know
submitting
for
conformance
for
their
various
providers.
B
So
definitely
a
lot
of
interest
already,
and
then
we
also
will
be
submitting
our
uxp
conformance
results
here
and
then
you
know
other
folks
come
along
and
build
a
crosswind.
Distribution
can
also
submit
their
results
and
go
from
there.
B
A
Well,
I
think
this
has
been
like
a
great
show.
Is
there
anything
else
you
want
to
leave
the
audience
with.
B
I
don't
think
so.
The
one
thing
I'd
say
is,
you
know,
join
us
in
slack.crossplane.io
and
we'll
be
happy
to
answer
any
questions,
we're
very
active
in
that
channel.
So
we
definitely
encourage
you
to
come,
hang
out
and
and
definitely
subscribe
to
cloudnativetv
as
well.
A
Yeah
awesome
thanks
dan
and
thanks
everyone
else
for
joining
the
latest
episode
of
cloud
native
live.
It
was
great
to
have
dan
with
us
today
to
talk
about
cross
playing,
uxp
and
exciting
new
stuff
there.
We
also
really
love
the
interaction.
All
the
questions
from
the
audience
too.
So
thanks,
lucky
lordy
and
go4it
and
eve
for
joining
us
on
the
conversation
today.
Yeah
so
join
us
every
wednesday,
3pm
eastern
to
hear
the
latest
developments
from
obvious
community
until
next
week.
Thanks
everyone
bye.