►
From YouTube: 2020-10-26 Crossplane Community Meeting
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
Okay,
the
recording
has
started-
and
this
is
the
october
26th
2020
crossplane
community
meeting.
Let's
start
at
the
beginning
here
with
our
road
maps
and
milestones,
we
briefly
went
over
last
time,
the
0.14
and
beyond
roadmap
here,
which
is
in
this
presentation
deck
here,
I'm
hoping
phil.
Will
you
be
able
to
convert
that
into
like
a
pr
to
get
the
the
roadmap
in
their
repo,
updated
totally.
B
A
Like
that
but
yeah,
if
we
kind
of
went
over
it
last
time,
so
we
don't
have
to
go
into
super
detail,
but
let's
definitely
go
over
a
quick
summary
for
everybody
here.
B
B
Oh,
maybe
that's
slightly
out
of
order.
There
we
go
yeah,
so
you
know
we're
gonna,
try
and
get
in
early
november,
going
into
kubecon
composition.
C
B
V,
one
beta
one
likely
to
have
the
claim
update
propagation
bi-directional,
patching
may
or
may
not
make
it
composition.
Revisions,
I
think,
is
I'm
hopefully
going
to
be
in
and
it's
possible
we'll
get
all
of
this,
but
you
know
just
on
an
accelerated
time
frame,
given
that
the
0.13
was
like,
you
know
a
little
bit
later
in
october.
D
Just
just
a
note
on
that
as
well,
it
is
a
little
bit
I
spent
all
of
last
week
working
on
our
ci
cd
systems
unexpectedly,
so
it's
a
little
bit
more
tight
now
than
it
was
at
the
beginning
of
last
week.
B
Yeah
yeah,
no,
no
worries
yeah.
So
basically
you
know
this
is
the
release
before
the
candidate
100
release,
which
is
0.15.
So
anything
that
doesn't
kind
of
get
done
here
is
just
going
to
roll
into
the
next
monthly
release
for
december.
But
I'm
here,
if
we
just
kind
of
touch
on
the
package
manager,
you
know
trying
to
get
these
to
view
one
beta
one
as
possible
I'll
go
ahead
and
move
off,
oh
sorry
and
then
hardening
and
clean
up.
So
you
can
kind
of
see
what
we
have
here.
B
You
know
deprecating
a
handful
of
the
things
kind
of
as
replaced
by
composition
and
home
provider,
and
I
think
that
there
might
be
some
comments
about
like
how
we
can
potentially
improve
this
for
scheduling
and
some
ideas
around
that.
So
we
can
talk
about
that
later
provider,
home
moving
to
v1
beta
1,
and
then
we
have
active
work
going
on,
for
you
know:
adapting
the
ack
and
azure
aso
pipelines
to
cogen
cross
plane
providers.
B
So
jay
pipes
has
a
pr
or
a
branch
open
that
we're
collaborating
with
him
on
in
the
ack
project
and
then
similarly,
matt
matthew,
christensen
and
the
the
team
out
of
new
zealand
has
been
working
on
a
generating
crossplane
provider
out
of
the
azure
iso
cogen
pipelines
and
then
casey
is
working
on.
You
know
kind
of
cogening
for
clouds
that
don't
have
a
cogen
pipeline.
Predominantly
you
know
basically
using
the
stateless
terraform
providers
to
co-generate
cross-point
providers.
C
B
The
goal
here
is
to
get
to
90
plus
coverage
in
a
short
period
of
time
as
possible
and
attacking
this
from
from
multiple
fronts.
Ideally,
you
know
having
everything
you
know,
cogen
from
you
know,
to
create
a
native
provider
just
because
that's
going
to
have
like
the
best
possible
ux
dx.
E
B
Know
and
there's
a
handful
of
things
that,
like
terraform,
doesn't
support.
You
know
as
cleanly,
but
I'm
definitely
good
enough
to
get
us.
You
know
like
90
of
the
way
there,
even
with
terraform
providers,
so
super
excited
about
all
that
coming
together,
it's
unlikely
we're
going
to
have
a
ton
of
providers.
B
You
know
cloud
services
covered
with
the
code
genes
immediately
be
like
a
resource
or
two,
and
you
know,
and
then
we'll
basically
unleash
it
on
the
full
set
of
metadata
to
generate
after
we've
kind
of
proven
that
out
so,
but
it's
looking
really
promising
right
now
and
then
ohm
is
going
to
v1
beta
1.
B
So
just
kind
of
I
don't
know
if
ryan's
on
the
line,
but
you
know
we're
kind
of
working
to
kind
of
get
that
so
that
all
the
apis
as
we
go
into
our
one
hour
release
or
at
least
to
be
one
beta,
one
or
higher,
and
so
he.
B
On
that
and
that
he
was
just
looking
for,
you
know
a
way
to
provide
dual.
F
B
Support
for
you
know,
or
at
least
to
transition
from
the
production
use
of
that
that
they
have
inside
of
alibaba.
Today
of
this
on
v1
alpha
one
into
b1
bit
one
so
yeah
so.
B
14
0.15
just
super
briefly
we're
treating
this
as
a
v10
candidate.
There's
some
additional
things
here,
mainly
around
like
web
hooks
for
validation,
conversion,
multiple
api
support,
any.
B
Bit
of
hardening
that's
needed
and
then
any
of
the
you
know
stuff
that
gets
carried
over
from
the
previous
release
and
then
a
major
push
forward
on
the
providers.
Still
in
this
time
frame,
you
know
not
not
likely
to
have
more
than
probably
like
an
alpha
one
of
the
generated
apis,
but
it
will
be
generating,
what's
kind
of
currently
the
v1
beta
1
best
practices.
So
you
know,
even
though
it's
an
alpha
one,
we're
just
kind
of
introducing
at
that
level.
B
I
think
that
the
objective
is
to
generate
it
at
a
v1
beta
one
or
higher
quality
and
there's
a
quality
dock
that
I
think
move
off
and
been
working
on.
I'm
not
sure
if
that's
officially,
you
know
cut,
but
you
know
it's
been
hanging
out
and
dropped
for
a
while.
B
So
I
think
it's
largely
there
yeah
and
then
basically
just
taking
home
any
final
hardening
there,
but
it's
been
pretty
active
and
they
just
cut
a
0-1-1
a
few
weeks
back,
and
so
it's
looking,
it's
looking
pretty
good
on
all
the
fronts
so
I'll
take
this
jared
and
get
dropped
into
the
roadmap
md
here
in
a
second.
A
Sounds
great
phil
thanks
for
giving
us
that
update
and
for
making
the
changes
into
the
roadmap
in
the
repo
as
well
too,.
A
Sweet
so
with
that
roadmap
kind
of
high
level
there
we
kind
of
talked
about
some
of
the
focus
areas.
I
don't
think
there's
necessarily
a
need
to
dive
into
further
details,
unless
anybody
has
some
thoughts
or
specifics
that
they
want
to
share
about
some
of
the
focus
areas.
That
phil
was
giving
a
high
level
overview
for.
A
A
To
dive
into
there
and
then
do
we
have
any
more
thoughts
on
a
release
date
for
this,
changing
you
know
or
or
what
it
might
be.
I
think
we're
talking
about
sometime
in
early
early
november-ish.
B
Yeah
so
it'd
probably
be
around
november
5th
or
the
6th
just
so
that
we
can
kind
of
get
that
out
out
in
time,
for
you
know,
kubecon
and
enough
big
time
there.
So
that's
kind
of
roughly
the
the
time
frame
that
we're
looking
at
and
then
similarly
in
december,
if
we
just
kind
of
roll
that
roughly
a
month
forward,
I
think
december
4th
was
the
date
that
we'd
be
looking
to
shoot
for
for
the
0.15
or
really
the
1l
release
candidate.
B
B
I
think
there
is
an
intention
as
well
to
take
at
least
one
of
the
apis
to
a
v1
for
1-0
and
so
whether
that's
composition
or
package
manager,
both
we'll
kind
of
leave
up
to
some
of
the
decent
conversation,
that's
happening
in
the
slack
channel
and
see
which
one
of
those
is
looking
like.
We
can
go
to
v1
with,
but
it's
possible
that
we
could
go
with
both.
So
I
just
have
to
wait
and
see.
D
So
speaking
of
v0.14,
I'm
gonna
drop
something
in
the
pr's
to
discuss
all
the
need
attention,
but
there
is
likely
to
be
a
breaking
change
to
v0.144.
D
That
needs
manual
updates
to
get
it
working
this
out,
specifically
because
we
said
in
the
release,
notes
4.13
that
that
wouldn't
happen
so
stick
around
to
the
end
of
the
meeting.
If
you
want
to
hear
about
that.
B
Right,
yeah-
and
I
think
the
intention
has
always
been
that,
like
with
the
1-0
release,
that
you
know
we're
totally
committed
to
stable
apis
and
so
forth,
and
we've
been
moving
towards
that,
and
you
know
the
degree
of
confidence
is
going
way
up
and
as
we
kind
of
look
to
some
of
the
the
forward-looking
things
that
we
want
to
do
and
kind
of
you
know
forward,
enabling
those
you
know.
B
I
think
that
that's
kind
of
the
trade-off
like
accepting
some
of
those
changes
while
we're
not
get
to
1-0,
you
know,
might
might
be
bus
so
yeah.
We
can
wait
till
the
end
of
the
meeting,
but
definitely
for
1-0
making
sure
that
everything's
stable
that
people
can
take
a
hard
dependency
on
that.
A
E
Sure
yeah
chris,
is
actually
on
this
call
as
well,
but
we're
going
to
be
showing
off
some
of
the
work
with
the
quay
operator
and
cross
plane,
and
that
will
be
a
week
from
this
thursday.
So
should
be
a
good
one.
A
What
is
that?
The
normal
time
slot
two
dan.
A
It's
excited
to
do
that
and
then
I
think
this
rocco.live
that
was
like
the
day
of
the
last
community
meeting.
I
think
you
were
doing
it
later
in
the
day.
How
did
that?
How
did
that
turn
out.
E
It
went
really
well,
there
is
some
good
information
there
if
you're
interested
in
the
newer
features
in
crossplane,
we
walk
through
kind
of
like
creating
a
provider
installing
a
provider
creating
a
configuration,
etc.
E
I
actually
have
no
idea,
I
didn't
have
the
viewer
numbers
as
I
was
kind
of
the
the
guest
on
there,
but
I
could
definitely
circle
back.
I
think
that
there's
also
a
recording
of
it
on
youtube,
so
we
could
check
the
numbers
there,
but
it
was
on
one
of
those
restream
platforms.
So
it's
going
to
all
the
different
ones,
how
they
aggregate
there
cool
who.
A
E
Rocco.Live,
it's
david
mckay
and
he's
a
I
guess.
A
developer
advocate
kind
of
at
equinix
metal,
so
me
and
marcus
were
showing
him
some
of
the
equinix
metal
provider
stuff,
which
was
also
updated
as
part
of
0.13,
to
have
some
new
features.
A
Got
it
cool?
Well,
thanks
for
doing
that,
dan
all
right,
so
quick
notes
here
on
kubecon
north
america,
so
we
had
two
talks
that
got
accepted
there.
I
believe
that
dan
and
there's
a
stephen,
barely.
E
A
Mastercard,
I
believe,
I'm
sure
you
all
recorded
your
talk
and
submitted
it
on
time.
Last
week,
nice,
okay,
good
job
for
you
me
and
and
wonderflo
from
alibaba
and
andy
andy
as
well
too
is
participating,
did
not
finish
our
talk
recording
on
time.
So
we
got
an
extension
from
nancy
lancaster
and
our
deadline
is
end
of
day
today.
A
So
all
of
the
slides
and
demos
for
crossplane
are
done
and
recorded
into
clips
waiting
for
the
final
recordings
from
from
the
from
the
ohm
side
from
andy
to
be
finished
off,
so
that
we
could
stitch
it
all
together
into
the
final
product
and
upload
submit
it
today.
So
as
long
as
we
get
that
last
recording
from
from
andy,
then
should
everything
should
be
all
good.
A
But
and
phil
we
were
able
to
add
a
fourth
tutorial
exercise
there,
that
kind
of
walks
through
the
aws
reference
platform
and
installs,
and
uses
it
on
on
up
on
cloud
as
well
too.
So
that
should
be
an
exciting
demo.
A
A
So
we
last
time
we
just
kind
of
gave
like
an
introduction
overview
of
cross
playing
quick
demos
and
such
and
then
answered
any
questions
from
the
people
attending
the
office
hours.
It's
a
bit
informal.
You
know
it's
not
like
a
mandated
format.
It's
really
just
a
zoom
meeting,
zoom
presentation
that
you
should.
You
know
to
connect
with
the
community
and
and
to
have
a
better
format
than
the
booth
itself,
the
virtual
format,
which
is
not
ideal.
A
A
Cool
and
then
there's
a
aws
jck
first
co-generation.
Pr
up
did
anybody
who
added
this
or
wants
to
add
something.
F
Like
this
yeah
yeah,
so
we're
collaborating
with
jay
pipes,
who
is
leading
aws,
ack
and
risk
controllers
for
kubernetes
and
so
they're
generating
code
for
their
controllers
that
talks
with
aws,
and
this
is
like
the
first
pr
that
has
like
that
is
able
to
generate
a
pro
a
crosspin
provider.
Api
type.
So
what's
going
to
happen
like
in
an
ideal
case,
is
that
all
provider
aws
resources
that
ack
covers,
we
will
also
get
like
generated
from
there.
F
And
additionally,
we
will
have
some
custom
code
as
well
because,
like
they're,
like
you,
know,
some
crazy
edge
cases
in
those
apis
so
like
this
doesn't
have
any
custom
code,
ability
or
whatsoever,
but
like
in
the
future,
we
will
have,
like
you
know,
pretty
and
post
like
call
hooks
like
a
few
different
things
that
we
can.
F
We
can
add,
you
know,
custom
hacks
that
are
gonna
result
of,
like
you
know,
usage
and,
like
you
know,
maturing
those
controllers,
so
we
will
not
only
rely
on
the
generation
to
generate
code,
but
that
will,
like
you
know,
be
our
foundation
basically
for
the
providers
and
it
will
be
like
generated
by
aws
tool
here.
A
That's
awesome,
movavic.
You
know
it's
super
exciting
to
be
able
to
connect
into
the
cogen
pipelines
from
the
providers
themselves
and
you
know
have
like
a
you
know,
be
part
of
the
you
know
the
those
pipelines
that
get
the
first
class
treatment.
So
that's
amazing
was
there
a
lot
that
you
had
to
kind
of
figure
out
and
work
through
or
did
jay
kind
of
get
you
set
up
on
on
a
good
path
with
everything
you
needed
there.
F
F
I've
got
my
own
local
commits
for
actual
controller
code
generation,
but
this
first
pair
doesn't
include
that,
because
there
are
like
a
few
small
things
that
we
need
to
do
like
in
the
upstream.
So
this
is
like
a
very
lean.
Pr
that
is,
like
you
know,
adds
the
crossband
command
generates
an
api
type.
That's
available,
like
ecr
sns,
so
like
just
a
starting
point,
but
I
think,
like
in
the
next
weeks
we
can
expect,
like
you,
know
more
like
controller
code
and
like
covering
all
the
available
services
and
that
stuff.
B
F
Yeah,
so
the
I
think
the
the
missing
parts
are
right
now
the
ack
specific
things
like
there
are
a
few
things
that
we
need
to
change.
For
example,
we
have
the
spec
parameters
under
like
four
provider,
but
they
just
put
it
under
like
spec
and
that's
like
hard
coded.
So,
for
example,
I
have
a
pr
that
is
like
no
there's
allowing
like
customizing
those
things,
but
there
are
also
other
things
like
all.
F
So
we
need
to,
like
you
know,
make
them
more
generic
and
then,
like
now,
the
the
latest
apis
are
like,
like
modern
apis
are
kind
of
easy
to
generate,
but
for
older
apis
like
in
this
repo,
you
would.
You
can
also
see
like
broader
apis
they're,
like
all
sorts
of
hacks,
so
we're
so
so
we're
trying
to
basically
reuse
the
hacks
that
are
like
you
know,
put
in
here
for
those
older,
older
apis.
F
So,
like
you
know,
in
the
beginning,
we
will
have,
like
you
know
some
hand
holding
for,
like
you
know,
specific
resources
like,
for
example,
s3
or
sqs
like
vastly
different,
but
like
in
the
future.
I
can
expect
you
know
accelerating
adding
you
know,
services,
new
services
and
also
shout
out
to
casey,
like
I've
just
joined
like
a
few
weeks
ago,
like
one
or
two
weeks
ago,
like
he's,
been
driving
this
with
jay
thanks
to
casey.
A
All
right,
so
that's
the
end
of
the
community
topic
section,
so
we
have
a
couple
of
pr's
to
discuss
and
that
they
need
attention.
So
here
is.
It
looks
like
everything's
under
a
list
of
0.14
related
changes,
so
looks
like
dan.
You've
got
the
first
one
there's,
or
is
this
like
a
greater
topic
to
discuss
that
nick
was
bringing
up
earlier
I'll
give
the
floor
to
you
guys.
E
Yeah
I'll,
let
nick
talk
about
the
breaking
changes.
It
looks
like
he's,
got
him
grouped
pretty
well
there,
but
I
do
have
one
just
above
that
that
I'd
like
to
touch
on
real,
quick.
The
this
is
an
open
pr.
It's
currently
in
draft,
but
I'll
move
it
out
of
draft
today.
I
demoed
it
last
week,
but
essentially
right
now
with
the
package
pull
policy.
E
What
we're
doing
behind
the
scenes
is
whether
you
set
always
or
if
not
present,
any
time
the
package
manager
re-cues
or
reconcile
it's
going
to
check
and
basically
make
sure
that
the
digest
of
the
package
that
you've
have
installed
has
not
changed,
and
if
it
has,
then
it's
going
to
create
a
new
revision
and
whether
that
actually
gets
enabled
depends
on
your
activation
policy
being
manual
or
automatic,
and
we
don't
actually
explicitly
re-cue
the
package
manager
controller,
but
it
will
get
triggered
every
so
often
just
by
resyncs
or
if
the
status
of
our
vision
changes
or
something
like
that.
E
So
basically,
what
this
pr
is
doing
is
changing,
if
not
present,
to
be
the
default.
Well,
I
guess
it
was
already
the
default,
but
it's
it's
making
it
the
default
default
still
and
if
we
have,
if
not
present-
and
we
have
an
existing
package
revision
and
we
have
our
status
of
our
package
manager
available,
we'll
skip,
pulling
and
or
we'll
skip,
checking
the
digest
again.
E
So
we
won't
try
and
update,
and
if
you
lost
the
status
of
the
of
the
package
resource
provider
configuration
then
we
will
and
then
in
always
we're
actually
going
to
re-cue
a
reconcile.
E
I
think
it's
after
a
decently
long
period
of
time
like
five
minutes
or
something
like
that
and
we'll
continuously
check
the
digest.
So
if
you
wanted
to,
you
know
automatically,
have
your
packages
update
on
a
channel.
So
let's
say
you
had
it
tagged
to
alpha
or
something
like
that.
E
If
you
had
always
we're
gonna,
consistently
check
and
make
sure
or
see,
if
there's
a
new
version
available
and
go
ahead
and
create
the
revision
once
again,
its
activation
will
be
based
on
your
activation
policy,
but
for
most
people,
if
you're,
just
creating
the
provider
configuration
using
the
cli,
this
isn't
going
to
change
behavior
as
much,
but
it
does
expand
what
you
can
do.
So
it's
not
going
to
remove
anything,
but
it
adds
some
new
behavior.
A
All
right,
then,
nick
you
want
to
take
away
the
the
changes
for
0.14.
D
Yeah,
so
the
first
one
I
grouped
in
was
dan's.
I
have
a
good
idea
of
well,
maybe
not
a
good
idea.
I
have
an
okay
idea
of
what
that
is
so
dan.
This
was
just
that
we
correct
me
if
I'm
wrong,
but
there
was
a
field
in
0.13
on
providers
and
configurations.
D
So
the
package
types
that
constrained
what
crossplane
version
you
could
use
those
types
on,
but
it
wasn't
actually
honored,
so
it
we
didn't
actually
use
it,
so
I
doubt
anyone's
actually
setting
it
at
the
moment.
Hopefully
I
don't
think
any
of
our
examples
said
it.
So
I
believe
that
changed
from
just
cross
plane
to
cross
plane
version
or
something
like
that
dan
was
it.
E
Yes,
it's
version
is
now
nested
under
crossplane
and-
and
I
guess
so-
the
the
behavior
change
is
actually
not
breaking
right,
because
if
you
gave
it
the
exact
same
configuration,
then
you'd
get
the
exact
same
result.
However,
something
I
noticed
while
implementing
this,
it's
a
schema
violation
to
have
cross
plane
and
then
the
string
value
there
as
it
was
before.
E
So,
if
you
actually
try
and
install
a
configuration
or
provider
that
has
that
that
unhonored
cross
plane
field
there,
then
it's
going
to
fail
to
install
because
it's
going
to
be
not
recognized
by
the
parsers
valid
schema
for
the
meta
type.
So
in
that
regard,
a
a
existing
package
could
fail
to
install
now.
D
So
but
to
your
knowledge,
the
only
reason
someone
would
have
an
existing
package
that
had
this
field
set
would
be.
They
wouldn't
have
got
it
from
any
of
our
examples
or
documentation
apart
from
docs.crds.dev
right,
so
they
would
have
had
to
author
a
package
and
set
that
field,
not
knowing
that
it
was
not
actually
honored
by
the
package
manager.
Yet.
E
That's
exactly
right
and
if
you
and
similarly
since
it
won't
be
recognized
by
the
package
manager
now,
if
you
update
your
crossland
cli
and
try
to
build
right,
it's
also
going
to
reject
it
and
say
I
can't
build
this.
It's
not
a
valid
schema,
so
it
would
have
to
be
an
existing
package
in
a
registry
that
was
using
a
field
that
wasn't
honored
when
you
installed
that
it
would
say,
fails
to
install.
D
Okay,
so
what
I
would
what
I
would
like
to
do-
and
we
can
talk
about
this
well
I'll,
just
say
now
what
I
would
like
to
do
for
anything.
That's
a
breaking
change
in
this
release.
There's
there's
two
things
that
we
said
in
the
0.13
release.
One
was
that
we
felt
very
confident
in
our
apis,
and
we
strongly
suggested
that
there
wouldn't
be
breaking
changes.
Two
of
these
breaking
changes
that
we're
going
to
talk
about
now
are,
I
think,
fairly
minor
and
unlikely
to
impact
people
one
other.
D
One
of
them
is
likely
to
impact,
basically
all
users
of
crossblade,
and
so
the
other
thing
we
said
was
this
would
be
vio.13
would
be
the
last
release
without
a
supported,
upgrade
path,
so
supported
upgrade
path.
I
think
at
least
means
that
any
of
these
braking
changes.
I
want
us
to
have
a
documentation
section
on
upgrading
crossplane
that
talks
about
what
you
need
to
do
if
you
are
impacted
by
one
of
these
changes.
D
So,
for
example,
in
this
case,
you
know
that
you
need
to
go
and
update
your
packages
to
remove
this
field
before
you
update
packer
or
to
rename
this
field
before
updating
across
plane.
As
I
I'm
you
know,
I'd
love
to
hear
from
the
community
on
on
these.
If,
if
I
am
wrong,
but
my
suspicion
is
given
that
this
field
wasn't
doing
anything
and
wasn't
really
documented
anywhere,
I
doubt
that
many
people
are
setting
it,
but
if
they
are,
then
I'd
like
us
to
be
able
to
show
people
what
to
do
with
that.
D
So
I'll
go
out
of
order
slightly
here.
There's
two
other
pr's
both
have
to
do
with
the
composite
resource
definition
type.
One
was
once
migrating
us
to
v1
of
sorry.
This
is
v1
xrds,
it's
supposed
to
say,
v1
crds
one
was
migrating
us
to
use.
V1
crds
behind
the
hood
or
under
the
hood.
D
V1
crds
made
a
tiny
change
to
the
additional
printer
columns.
Setting
previously
they
had
they
had
a
field
called
jsonpath
and
the
additional
printed
columns
that
was
violating
api
conventions
had
json
and
uppercase.
They
changed
it
to
lowercase.
I
we're
planning
on
making
that
change
just
to
match
v1
crds.
So
if
people
have
been
setting
additional
printer
columns
on
their
xrds,
I
kind
of
again
suspect
that
that's
maybe
unlikely,
but
but
if
they
are,
then
that
is
going
to
be
a
small
change.
D
It
should
be
easy
to
update
the
other
one,
which
is
the
the
big
one.
That's
probably
gonna.
Have.
The
most
impact
on
folks
is
support
serving
multiple
xr
versions.
This
is
in
draft
at
the
moment
it's
still
being
tested
out
and
we're
still
gathering
community
feedback.
D
But
another
thing
that
came
up
while
we're
looking
at
v1
crds
is
that
currently
the
schema
of
xrd
supports
only
a
single
version
so
with
crds,
I'm
sure
most
of
us
on
this
call.
No,
but
with
crds
you
can
define
a
composite
resource
or
a
custom
resource
in
kubernetes
terminology
I
should
say-
and
you
can
define
multiple
versions
of
that
resource
and
those
versions
can
have
different
schemas,
so
you
can
have
your
beta
1
v1.
They
have
slightly
different
fields
in
them.
D
F
D
Do
that
xid
only
had
one
version,
which
means
that
there
would
be
no
path
to
support
multiple
versions
without
making
breaking
changes
to
that
api
in
future,
as
we
head
towards
v1
we're
actually
hoping
you
know,
I
don't
want
to
be
the
boy
who
cried
wolf
here,
but
we're
hoping
for
0.14
that
this
is
actually
the
final
form
of
these
apis
that
effectively
the
last
breaking
change
before
v1,
so
we're
hoping
to
bump
these
apis
all
to
v1
beta
1,
as
phil
mentioned
earlier,
and
once
we
do
that
it
becomes
much
much
harder
to
make
breaking
changes
for
us.
D
D
So
when
we
thought
about
it,
we
decided
that
it
would
be
better
to
make
a
breaking
change
now
in
order
to
support
serving
multiple
versions
of
an
xrd,
multiple
schemas
of
an
xrd,
so
your
exedy
can
be
at
v1,
beta1
and
v1
at
the
same
time.
D
So
specifically,
what
we
plan
to
include
in
v0.14
is
is
mostly
future
proofing,
because
we're
not
actually
going
to
support
conversion
of
xrds,
so
crds
there's
only
two
ways
to
support
conversion
in
cities.
You
either
say
I
support
multiple
versions.
They
all
have
the
same
schema,
so
no
conversion
needed
so
v1
and
v1
beta1.
They
look
exactly
the
same.
We
will
support
that
for
the
limited
use
cases
that
it's
useful
for,
but
the
only
other
alternative
is
go,
write
a
web
hook,
which
we
feel
for
the
xrd
experience
is
a
little
heavyweight.
D
So
as
of
this
release,
the
plan
is
for
us
to
not
support
web
hooks.
If
there's,
if
there's
a
lot
of
community
feedback
that
people
really
want
to
write
their
own
web
hooks
to
do
conversion,
then
it
would
be
easier
for
us
to
open
that
up,
but
we
we
hope
to
provide
a
better
user
experience
than
that
in
future.
So
long
story
short,
the
schema
will
change
such
that
instead
of
one
version
of
a
schema
in
xrd
in
the
type
composite
resource
definition,
you
will
have
an
array
of
versions.
D
It
should
be
fairly
straightforward
and
we
plan
to
document
the
plan
of
the
the
approach
to
to
translate
an
existing
c
x
id.
I
should
say
into
a
into
a
sort
of
v1
beta,
1,
x
id
and
hopefully
the
the
process
should
be
roughly
stop
cross
plane
temporarily
apply
the
new
xrd
crd,
the
one
that
defines
xrd
so
that
you've
got
the
new
schema
update.
Your
xrd
is
to
have
the
new
schema
and
then
start
crossplaying
again,
and
then
everything
should
be
updated.
D
So
it
should
be
a
manual
change,
but
it
won't
require
you
to
delete
your
infrastructure
or
anything
like
that
and,
as
I
say,
we
plan
to
have
this
documented
and
tested
so
that
you
can
sort
of
follow
the
steps
rather
than
having
to
figure
it
out
yourselves,
and
I
apologize
for
making
promises
about
not
making
breaking
changes.
But
as
we
say
we
are
getting,
we
are
getting
close
to
v1
when
we
will
be
holding
ourselves
to
that
much
more
strictly.
D
C
A
I
think
it's
really
good
there,
nick
that
you
know
the
steps
to
upgrade.
We
anticipate
well.
You
know
yes,
a
manual
step
to
upgrade,
but
we
haven't
really
even
supported
upgrades
in
the
past.
That's
already
a
step
forward,
that's
progress,
but
without
having
to
delete
or
recreate,
and
you
know,
delete
infrastructure
resources.
So
I
think
that's
that
migration
or
upgrade
step
there.
You
know
with
having
that
property
is,
is
very
good.
D
It
one
way
that
that
could
happen
would
be
that
we
would
just
delete
the
v1
alpha
one
apis
and
you
would
have
to
migrate
everything
to
v1
beta1.
With
with
this
release,
depending
on
how
we
do
it,
we
could
potentially
serve
both
versions
at
the
same
time
of
our
types
if
they
have
the
same
schema,
but
that's
not
going
to
happen
for
these
ones
that
have
broken
changes.
So
I
I
think
I
definitely
want
to
hear
from
the
community
how
much
of
a
pain
it
would
be.
D
B
And
one
of
the
things
you
know
to
to
think
about
is
that
we're
also
going
to
be
adding
support
for
the
you
know
the
conversion
web
hooks
as
we
go
into
one
now
so
going
forward.
You
know
we
will
be
able
to
support.
You
know
a
seamless
upgrade
strategy.
You
know
and
support
multiple
apis
at
the
same
time
so
that
you
know
you're
not
forced
to
just
cut
over,
but
in
this
interim
period
you
know
pre-1l.
B
You
know
we
feel
like
we
still
have
a
little
bit
of
flexibility,
but
going
forward
definitely
taking
that
super
seriously,
especially
after
we
get
to
1l.
But
if
there
are
there
are
things
like
nick
pointed
out.
You
know
that
folks
are
using
today
that
they
would
be
impacted
without
having
kind
of
a
cleaner
upgrade
path
from
0.13
to
0.14.
Definitely
reach
out
on
cross-playing
slack,
and
let
us
know.
A
And
a
good
test
case,
there
may
be
the
aws
reference
platform
that
we
have,
because
that
has
defines
a
number
of
xrds
in
there
and
you
know
making
sure
that
that
upgrades
smoothly
and
using
that
as
a
test
case
to
to
make
sure
our
migration
or
upgrade
plan
works
or
how
much
pain
there
is
associated
with
it
might
be,
might
be
a
good
test
case
to
use.
A
Cool
and
nick
did
you
already
drop
a
note
in
slack
about
this
as
well
too,
to
try
to
reach
more
folks
for
for
comments
or
opinions.
I
did
last.
A
A
Okay,
if
there
aren't
comments
further
comments
right
now,
then
we
can
move
ahead
to
the
final
section
of
the
community
agenda.
Does
anybody
else
have
any
other
topics
for
the
group
here
before
we
move
to
the
final
to
optional
segment
for
technical.
A
A
Okay,
cool
all
right,
so
let's,
let's
jump
into
the
final
section
here
and
note
this
one
is
optional,
then
we're
gonna
dive
into
maybe
some
some
deeper
details
around
some
of
these
topics
here
and
you
know
it
is
optional.
So
if
anybody
wants
to
take
off,
they
are
more
than
welcome
to
otherwise,
let's
get
the
conversation
started.
G
Sorry,
it's
talking
to
me:
how
are
you
doing
I
need
to
share
if
you
could,
let
me
share.
A
G
Okay,
so
just
a
rough
illustration
of
what
I'm
talking
about
so
basically,
I
want
an
orchestration
system
to
push
into
crossplane
and
you're
gonna
match
it
could
be
a
label.
This
is
just
an
example
where
I
have
a
label,
that's
abc
and
then
every
cluster
that
actually
has
that
label
that
service
gets
pushed
down
to.
So
here
you
can
see
these
particular
clouds.
They
did
not
get
it,
and
this
could
be.
You
know
two
clouds.
G
It
could
be
a
hundred
clouds
or
it
could
be
a
thousand
clouds
right,
but
it's
whatever
matches
that
selector.
If
you
will
or
label
I'm
also
open
to.
I
heard
the
last
meeting
you
guys
were
looking
at
opa
integration.
I
could
do
it
through
opa
as
well.
That
through
a
policy
would
be
actually
might
be
preferred.
G
So,
but
this
is,
I
mean
this
is
pretty
simplistic
right
now
you
do
a
one-on-one
one
resource
target
resources
to
a
service.
So
all
I'm
saying
is
that
I
want
a
service
to
actually
match
multiple
targets
based
on
a
label
or
a
policy.
D
So
tim,
I
know
that
you're
originally
looking
at
this
with
regard
to
our
workload:
functionality,
kubernetes
application,
that
kind
of
thing
that
is
slated
for
removal
in
v
0.14-
and
I
I
also
know
you've
been
talking
about
this
with
dan
a
lot
more
than
we've
spoken
about
it.
But
I
recall
that
we
we
mentioned
that
the
sort
of
the
tentative
replacement
for
the
kubernetes
application
functionality
at
the
moment
is
the
helm
provider
yep.
D
So
do
you
imagine
this
being
one
thing
that
I'm
not
sure
how
much
dan
has
talked
about
this
with
you,
but
one
thing:
we've
talked
about
in
the
in
my
team
is,
is
potentially
supporting
this
replicability
for
all
crossplane
composite
resources.
So
you
could
define
your
own
thing
that
happened
to
use
provider
helm
behind
the
scenes
and
the
that
there
was
maybe
a
you
know.
D
If
you
define
a
my
deployment
xr
you
could,
we
would
automatically
create
a
my
deployment
set
or
something
like
that
that
allowed
you
to
stamp
out
multiple
templates
of
those.
D
So
I
think
I
think
this
is
functionality
that
we're
interested
in,
but
I
don't
think
it's
functionality
that
we're
going
to
be
able
to
find
time
to
work
on
this
year,
at
least
our
bouncing
priorities
for,
for
other
things,
that
we've
got
going
on
like
the
v1
release
and
the
and
the
provider
acceleration
yep.
So
dan,
do
you
know,
do
we
do
we
have
an
issue
tracking
this
in
cross
plane
at
the
moment,
sort
of
this
specific
idea
that
we've
had
about
how
we
built
this.
E
I
don't
know
if
there's
a
specific
issue,
there's
some
with
related
content,
but
it'd
probably
be
good
to
to
have
one.
That's
that's
more
specific.
Another
thing
that
nick
I
know
you've
mentioned
and
both
tim
and
I
have
talked
about
a
little
bit,
is
basically
you
know
having
a
separate
controller
that
has
this
functionality
in
it.
E
They
could
operate
based
on
labels
or
something
on
resources,
so
that
could
either
be
at
the
composition
level,
where
you
know
you
label
a
xr
or
something
with
you
know
my
controller
slash,
replicate
and
then
the
the
target
label,
or
something
like
that,
and
that
controller
just
replicates
things.
It
could
be
almost
a
generic
thing.
E
It
wouldn't
have
to
be
specific
to
crossplane,
even-
and
I
know
that
we've
mentioned-
if
that's
something
that
we
could
get
some
folks
to
help
out
on
we'd
love
for
that
to
incubate
and
cross-flank
and
trip-
and
you
know
be
something
that
we
can
incorporate
into
the
ecosystem.
Without
necessarily,
you
know
trying
to
put
it
into
core
before
the
end
of
the
year.
D
Yeah
I
could
see,
I
could
see
this
being
something
definitely
that
graduated
to
core.
If
it
turned
out
to
be,
you
know,
work
well
and
and
sort
of
be
popular
with
the
community
like.
I
can
definitely
see
a
path
to
this
being
super
useful
functionality,
but
I
would
feel
I
definitely
feel
comfortable
right.
You
know
today
raising
the
issue
and
making
a
repo
for
it
to
be
built
in.
D
I
just
can't
commit
any
time
from
uptown
folks,
I
think
this
year,
so
we
could
definitely
like
put
a
shout
out
to
the
community
and
let
people
know
that
this
would
be
like
a
top
priority
if
people
wanted
a
sort
of
a
larger
piece
of
work
to
sort
of
to
tackle
and
get
involved
in
the
cosplaying
community
with
and
tim,
I'm
not
sure
if
there's
anyone
like
on
your
team
or
yourself
would
be
interested
in
helping
with
this,
but
definitely
be.
You
know,
welcome
if
it
was
the
case.
G
Yeah,
I
I
mean
I'll
see
what
time
we
can
come
up
with
the
problem
is.
This
is
just
one
aspect
of
a
larger
picture
that
we're
all
trying
to
get
done
so
yeah.
It
becomes
hard
to
find
the
time
so.
D
Yeah
understood,
I
I
do
think
it's
cool
functionality,
it's
just,
unfortunately,
where
down
to
the
wire
to
try
and
ship
1.0
at
the
moment.
So
I
really
don't
think
we
have
much
time
to
build
other
stuff
in,
but
post
1.0,
which
would
be
january
timeline
could
be,
could
be
feasible
for
us
to
get
some
time
to
work
on
it.
G
A
Good
cool,
so
it
sounds
like
you've
got
some
follow-ups
there
to
get
the
issue
opened
and
then
maybe
kind
of
socialize
that
issue
out
to
the
community
as
well
too,
to
see
if
there's
anybody
who's
interested
in
picking
that
up
or
running
with
that,
once
the
issues
opened.
D
Yeah
dan,
do
you
feel
okay,
you've
got
a
lot
of
context
there
or
dan
and
tim.
Do
you
want
to
sort
of
get
that
written
down
as
an
issue
that,
hopefully,
someone
could
sort
of
take
and
run
with.
E
Sounds
great
thanks
and
thanks
for
for
coming
to
the
meeting
tim
and
presenting
it's
always
helpful.
Obviously
we
talked
about
it
last
week,
but
it's
super
helpful
when
the
person
who
who
has
the
most
intimate
knowledge
of
it
is
able
to
show
up.
So
we
appreciate
you
taking
the
time
to
be
here.
G
No
worries
thanks
for
reviewing
it.
A
Awesome
yeah
thanks
tim,
really
appreciate
it:
okay,
dan,
you
wanted
to
talk
about
I'll
start
sharing
my
screen
again
too.
E
Yep,
so
this
one
has
some
pretty
good
conversation
going.
If
you
scroll
down
on
the
issue,
the
it's
actually
an
old
issue,
that's
kind
of
been
adapted,
but
I
appreciate
folks
jumping
in
last
week
and
providing
their
thoughts
on
sort
of
the
the
options
that
we've
defined,
but
essentially
what
we're
doing
is.
Obviously,
when
you
install
a
provider
into
your
cross-plane
cluster,
it
eventually
results
in
a
controller
starting
to
manage
the
crds
that
you've
installed.
E
There
are
various
scenarios
where
you'd
like
to
be
able
to
configure
the
deployment
that
actually
creates
that
controller
pod,
some
of
those
most
notably
where
we've
run
into
it,
is
with
iam
roles
for
service
count
on
eks,
which
involves
doing
some
annotations,
as
well
as
setting
the
fs
group,
which
is
related
to
how
the
service
count
token
is
mounted
into
the
pod.
E
So
there's
there's
a
variety
of
scenarios
essentially,
and
one
of
the
things
we've
been
trying
to
balance.
I
guess
is
the
security
concerns
of
being
able
to
configure
kind
of
like
arbitrary
workloads
running,
which
you
would
essentially
be
able
to
do.
E
If
we
gave
you
a
full
pod
spec
to
be
able
to
configure,
while
also
not
being
so
constrained
that
we're
constantly
having
to
add
new
fields
and
eventually
end
up
with
basically
just
our
own
representation
of
the
pod
spec,
because
obviously
that's
just
more
information
for
folks
to
have
to
understand
to
be
able
to
configure
things
correctly,
so
we'd
like
for
it
to
mirror
the
thing,
that's
actually
getting
created,
so
there's
kind
of
three
levels
at
which
this
can
be
configured.
E
And
currently
I
there's
some
disagreement
which
I'd
like
to
come
to
consensus
today,
if
possible,
but
the
first
level
is
kind
of
the
install.yaml
approach
we
had
before,
which
is
where
you
specify
it.
When
you
actually
package
up
the
image
and
say
please
deploy
it
in
this
manner,
that's
really
not
a
great
solution
and
that's
what
we
used
before
and
we
ran
into
issues
with
it,
because
not
everyone
wants
to
run
it.
The
same
way,
number
two
is
basically
configuring.
E
The
default
deployment
that
the
package
manager
uses
to
create
these
controllers
at
cross
plane
runtime,
so
you
know
either
pointing
at
a
config
map
or
you
know,
putting
something
in
the
file
system
or
setting
flags
et
cetera,
to
be
able
to
configure
what
goes
through
there,
and
the
third
way
is
to
have
something
like
a
pod
spec
on
the
provider
that
you
actually
create
the
provider
object
or
reference
from
that
provider
object
to
a
separate
resource
that
has
the
configuration
for
the
deployment
for
that
specific
provider.
E
So
we
think
that
three
is
probably
you
know
the
way
that
we're
gonna
have
to
go
to
enable
all
the
functionality
we
want.
The
issue
with
that
is
the
whole
idea
of
being
able
to
configure
sort
of
any
workload
to
run
in
a
cluster.
That's
a
highly
privileged
operation,
and
we
don't
know
if
folks
that
are
able
to
install
providers
into
clusters
should
have
also
the
ability
to
basically
create
arbitrary
workloads
likely.
We
don't
want
them
to
be
able
to
do
that.
E
So
the
way
that
we
could
introduce
security
is
at
step.
Two
basically
have
a
a
flag
or
some
sort
of
configuration.
That
says
I
will
allow
a
provider
configuration
to
happen
and
that
would
basically
just
say
to
the
package
manager
check
this
flag.
If
provider
configuration
is
enabled
we'll
use
this
pod
spec
that
was
provided.
E
If
it's
not,
then
we'll
just
use
the
default,
that's
a
little
bit
opaque
to
the
end
user.
So
that
could
be
a
little
confusing
that
sometimes,
when
you
create
a
provider
with
a
pod
spec,
it's
going
to
be
used,
and
sometimes
it's
not
depending
on
how
cross
plane
is
set
up.
It's
not
the
worst
experience
ever.
E
The
the
second
option
for
providing
some
sort
of
security
boundary
is
what
I
previously
mentioned,
and
I
think
movavic
proposes
it
here
is
having
a
separate
resource
that
is
referenced
by
the
provider.
So
I
think
I
believe,
we've
often
calls
it
controller
config
here.
So
this
is
a
good
idea
because
of
the
ability
to
create
our
back
specifically
on
this
resource.
So
you
could
basically
separate
the
privilege
levels
being
able
to
contra
create
a
controller.
E
Config
would
be
highly
privileged
because,
well,
I
guess
being
able
to
create
it
and
a
provider
would
be
highly
privileged
because
you're
able
to
configure
an
arbitrary
workload
or
some
subset
of
that
and
then
creating
the
provider
would
basically
be
constrained
to
the
controller
configs
that
exist.
So
basically,
the
administrator
of
that
cluster
is
saying
you
can't
create
arbitrary
workloads,
but
you
can
use
these
types
of
customizations
with
your
providers
when
you
install
them.
So
I
think
at
this
point
it's
mostly
coming
down
to
do.
E
I
know
nick
and
move
office
specifically
kind
of
brought
up
the
two
different
options
there.
So
if
you
all
have
thoughts
feel
free
to
to
bring
them
in
now,.
D
Yeah,
I
think
my
thoughts
personally
are
pretty
well
captured
on
the
issue
I
to
try
and
put
it
somewhat
succinctly.
I
lean
to
ward
making
this
configurable
on
the
provider
cr
itself.
D
I
lean
toward
probably
not
putting
in
a
full
pod
spec
template
and
rather
than
that
doing
something
sort
of,
maybe
it
might
evolve
toward
being
a
full
pod,
spec
template,
but
but
doing
it
on
demand.
Basically,
so
you
know
we
wouldn't
add,
we
would
add
just
the
basic
features
of
that
we
would
need
and
wouldn't
have.
I
don't
know
everything
that
a
pod
spec
template
has
unless
we
had
people
actually
asking
for
that.
D
I
do
think
it
should
be
optional.
So
I
think
you
shouldn't
have
to
tell
crossblade
how
to
run
your
controllers.
It
should
have
the
same
default
as
it
has
today
as
to
how
we
restrict
that
I'm
curious
as
to
how
many
people
have
that
use
case.
So
I
know
that
we
we
definitely
have
that
use
case.
D
We
we
run
up
our
cloud
which
hosts
cross
planes,
and
we
know
that
we
don't
want
people
who
submit
providers
to
about
cloud
to
be
able
to
configure
arbitrary
things
about
the
deployments
for
a
provider.
D
If
we
were
the
the
only
people
who
had
that
use
case,
it
might
be
feasible
to
have
a
separate
controller
that
restricted
this
or
to
use
opa
to
restrict
this.
But
if
this
is
something
that
you
know
the
rest
of
the
community
chimes
in
on
and
says
yeah
we
have
that
use
case
too.
Then.
I
think
it
makes
more
sense
for
crossblade
to
have
a
bespoke
security
configuration
for
this.
E
One
thing
to
mention
is
with:
if
we
use
opa,
you
know
you
get
that
kind
of
like
rejection
down
the
line,
because
the
provider
would
get
installed
in
the
revision
and
the
deployment
getting
created.
And
then
you
basically
get
a
failure
of
saying
you
know
this
deployment.
Well,
I
guess
you
could
set
the
opa
actually
on
the
provider
itself
so
yeah.
That
was
my
thinking.
Gotcha.
D
But
I,
but
I
presume
you
know
I
know
that
luke
sign
on
the
call
for
eve.
Even
for
customers
like
upon
cloud,
you
know
adding
opa
to
every
every
deployment.
Sort
of
thing
is
a
lot
of
extra
resources
to
be
to
be
running
for
every
cross,
plane
that
you
host
so.
F
Yeah,
so
I
I
also
like
write
my
thoughts
about
the
controller
config
approach.
I
think
one
of
the
besides
from
our
back
like
using
our
back
to
restrict
it
one
of
the
good
things
about
it
is
that,
for
example,
let's
say
I
have
a.
C
F
Irsa
but
like
maybe
a
different
config
for
irsa
like
two
of
them,
so
people
can,
like
you
know,
choose
one
of
them
like
without
going
into
the
views
of
like
you
know
how
irsa
works
or
not.
You
could
have
like
you
know
already
made
templates
like
hey.
You
just
need
to
put
your.
Is
it
this
account
id
here
and
when
you
deploy
to
eks,
you
can
just
choose
that
one.
E
E
Yeah
that
definitely
I
was
I
was
rewriting
the
authentication
doc
in
provider
aws
and
thinking
about
the
steps
there
that
definitely
is
attractive
from
that
perspective
that
we
could
publish,
along
with
provider,
aws
a
controller
config
right,
that's
like
if
you
like
to
use
irsa,
please
you
know
also
reference.
This
controller
config
yeah.
I
think
that's
a
very
valid
use
case.
I
think
in
any
hosted
solution.
You
would
just
give
no
users
the
ability
to
create
controller
configs.
E
I
guess
so
yeah
or
maybe
maybe
you
give
you
know
user's
ability
to
create
controller
config,
but
then
you
put
opa
on
that
and
you
can
have
you
know,
minimal
configuration
or
something
like
that,
so
that
could
be
an
option
as
well.
Nick,
do
you
have
any
thoughts,
since
that's
kind
of
I
guess
you
know
like
not
exactly
what
you
were
saying
in
some
ways.
Do
you
think?
Do
you
see
that,
as
kind
of
like
a
nice
abstraction
that
would
be
useful
to
folks.
D
Yeah,
I
think
that
allowing
people
to
point
to
a
predefined
configuration
is
compelling.
I
guess
you
could
it's
probably
worth
walking
through
it
a
little
bit
more.
I
think
it
makes
sense.
I
mean
you
could
you
could
have
a
set
of
predefined
providers
as
well
sort
of
thing
you
could
have
the
irsa
provider
and
the
non-irsa
provider,
so
there's
sort
of
different
ways
to
accomplish
that.
But
potentially,
if
crossplane
installed
a
bunch
of
controller
configs,
then
the
nice
thing
there
is
people
don't
have
to
necessarily.
D
D
I
need
to
think
about
it
a
little
bit
more.
What
I'm
wondering
is,
if
crossplane
publishes
a
set
of
these
controller
configs
behind
the
scenes,
with
the
hopes
of
someone
just
saying
give
me
an
irsa
one,
presumably
you're
gonna
have
to
say:
okay,
this
provider
has
like
a
reference
to
the
rsa
controller
config,
or
something
like
that
or
somehow
defaults
to
it
or
picks
it
or
says
to
go
use
that
one
and
then
so.
D
I
wonder
if
the
moving
the
complexity
of
moving
that
out
into
a
different
type,
helps
with
much
you
know,
given
the
people
would
probably
still
have
to
go
and
like
see
that
it
exists,
find
it
look
at
it
understand
what
it's
doing
or
something
like
that
it
could.
It
could,
like.
I
don't
know
it.
D
E
C
I
guess
I'm
I'm
still
kind
of
waiting
waiting
to
see.
C
I
it's
nice
if
it's
a
privileged
type
and
not
just
ad
hoc
config,
obviously
so
the
the
two
elements,
but
I
think
I
think
again
it's
it's
more
about.
You
know
what
what
people
need
for
configurability,
you
know
in
the
general
community.
We
can
always
find
a
way
to
harden
around
it.
I
feel
like
so.
E
Yeah
one
thing
that
would
be
nice
is:
if
we
use
a
separate
type,
we
could
potentially
make
that
alpha
and
we
wouldn't
be
introducing
new
fields
like
it.
E
So,
basically,
if
we
went
with
having
it
directly
on
the
provider
itself,
and
then
we
promote
that
to
v1
beta
1
or
v1,
we
don't
want
to
break
that
functionality,
but
we
could
theoretically,
have
you
know
a
separate
resource
at
alpha
and
say:
hey
we're,
dropping
this
and
we're
actually
going
to
put
it
directly
on
the
provider
now,
and
that
would
not
be
a
breaking
change
right.
It'd
be
strictly
additive
and
we'd
only
be
dropping
alpha
resource,
so
just
from
a
versioning
perspective
that
could
be
advantageous
as
well.
D
Would
we
have
a
default
one
of
these
for
each
provider,
or
we
just
say
if
there
is
no
default
one?
We
do
what
we
do
today.
Thinking
about
the
additional
complexity
of
now
when
we
reconcile
or
provide
like
I'm
wondering
if,
okay,
I
go
reconcile
the
provider,
do
I
have
to
every
time
go
and
like
also
get
a
provider
config
to
figure
out
like
what
to
do
with
that
provider.
E
Yeah,
I
I
think
you
would
have
to
in
the
case
of
a
provider
revision
reach
out
and
get
that
we
could
also,
you
know,
put
it
in
the
status
or
something
like
that
right
or
late,
initialize
it
or
at
that.
Oh,
I
guess.
One
thing
we
could
do
is
in
the
manager
controller
reach
out
and
get
it
and
then
create
the
revision
with
it
in
the
spec.
E
D
You
know
just
have
a
default
of
like
basically,
if
there
isn't
a
controller
config
or
whatever,
we
call
it
that
that
we
just
do
what
we
do
today.
E
Yeah,
no,
I
think
that
is
what
we
do
I'm
just
talking
about.
If
there
was
one
referenced,
what
we
would
do,
I
think
I
think
if
we
didn't
have
one
reference,
it
would
be
exactly
what
we
did
today.
I
don't
think
we
have
a.
I
don't
think
we
use
a
default
which
may
make
that
kind
of
irrelevant.
Anyway,
if
we're
almost
always
using
the
default,
we
wouldn't
have
to
reach
out
that
often
obviously,
because
we
wouldn't
be
reaching
out
for
anything.
D
Yeah
yeah,
the
point
of
making
it
a
separate
controller
for
or
a
separate
cr
for
for
api
stability
purposes
is
compelling.
I
like
the
idea
that
we
could
make
it
a
separate
one
and
then
see
how
that
works,
and
then,
if,
if
we
did
decide
at
one
point
that
we
wanted
to
make
it
a
first
class
property
of
provider
and
switch
to
that,
for
whatever
reason,
that's
that's
an
easier
change
to
make
than
pulling
it
out
a
provider
and
putting
it
somewhere
else.
D
Yeah,
just
just
keep
a
gut
check
on
it
as
we
go
with
implementing
data
if
it
turns
out
to
be
like.
Oh,
this
actually
is
like
going
to
make
it
more
complex
to
understand
and
implement
than
just
putting
the
fields
on
provided.
Then
we
should
maybe
double
check
it,
but
I
don't.
I
don't
have
reason
to
worry
about
that
being
the
case
too
much
cool.
C
A
Dan
I've
got
to
hop
off
now.
Can
I
go
and
make
you
the
host
to
finish
off
these
conversations
in
the
optional
period
here.
E
E
Guess
I
can
just
do
google
chrome?
Okay,
can
you
all
see
the
agenda
meeting
here.
E
Cool
all
right,
so
we
were
talking
about
this
before.
Basically,
the
idea
is
enabling
publishing
secrets
to
external
secret
stores,
be
it
vault
or
secret
manager,
or
something
like
that.
There's
kind
of
two
scenarios
here,
one
of
them
being.
E
If
you
write,
if
you're
comfortable
with
secrets
existing
your
kubernetes
cluster,
which
the
case
would
be,
I
provision
my
infrastructure
and
it
publishes
a
secret
which
is
fine
to
me
fine
with
me,
but
I
want
to
be
able
to
consume
that
from
the
external
secret
store.
So
we
basically
want
to
sync
that
kubernetes
secret
up
to
the
secret
store
and
then
likewise,
you
could
also
manually,
create
a
secret
and
have
it
synced
up
there
and
to
enable
this
we
could
have
a
fairly
simple
change.
E
That
would
be
non-breaking
to
add
the
secret
type
to
the
right
connection
to
secret
ref
and
manage
resources.
So
right
now
it
just
has
a
name
and
namespace.
So
we
could
add
the
optional
secret
type
right
now.
If
we
take
a
look
at
this
issue,
we
are,
we
write
it
to
connection.crossplan.a
view
and
alpha
one
secret
type.
So
my
idea
is
that
we
have
just
basically
any
type
that
you
can
write
to
and
then
we
could
have
controllers
for
the
various
secret
syncs
to
reconcile
those
secret
types.
E
So
let's
say
I
wrote
it
to
vault
dot,
cross,
plane,
dot,
io,
slash
v
on
alpha
one
secret
type.
It
would
create
a
secret
just
like
normally,
but
with
that
secret
type,
and
then
I
could
have
a
separate
vault
controller.
That
was
saying
you
know
I'll
go
put
this
in
the
in
the
external
store.
Essentially
so
that's
kind
of
the
the
first
stage
of
it.
The
the
next
would
be
not
writing
secret
at
all
right
and
maybe
making
a
request
to
some
sort
of
secret
back
end
or
something
like
that.
E
But
I
think
this
simple
change
could
enable
it
in
the
short
term,
but
it
is
additional
complexity,
so
always
want
to
consider
that
when
introducing
new
things,
I
I
think
we've
lost
a
number
of
people
from
the
call
at
this
point,
so
this
may
just
be
valuable
for
the
recording.
But
if
anyone
on
here
wants
to
weigh
in
you're
definitely
welcome
to
at
this
point.
E
Yep
sure
thing
casey,
I
know
I
know
you've
been
doing
some
work
with,
like
generation
related
to
references
and
maybe
connection
secrets
as
well.
I
I
don't
think
that
this
would
change
anything
materially
for
any
of
the
work
you're
doing,
but
just
you
know
wanted
to
run
it
by
you,
but
just
in
general
as
well.
C
I
assume
I'll
have
more
questions
when
there's
a
design
doc
for
it.
The
big
question
obviously
is
kind
of
how
you
manage
consistency
if
there
are
other
things
that
can
be
writing
back
to
these,
these
secret
stores,
but
I'll
kind
of
hold
off.
Until
I
see
what
you
got
in
mind,
gotcha.
E
Yeah,
that
is
something
to
take
into
consideration,
especially
how
we
like
gate
on
these,
because
it
would
essentially
allow
anyone
who
creates
any
managed
resource
to
then
write
that
connection
secret
to
the
external
store,
which
obviously
may
not
be
desired.
Behavior
so
yeah
we'd
have
to
look
at
that
all
right,
so
we
can
provide
some
more
information
and
probably
follow
up
chat
with
some
other
folks
about
it
as
well.
E
We
could
also
maybe
do
a
little
like
cross-plank
and
trip
work
on
that
if
we
want
to
get
that
going
a
little
earlier.
Last
thing
we
have
here
is
from
casey
and
I'll.
Just
let
you
take
it.
C
Okay,
yeah-
and
we
probably
want
to
have
this
conversation
with
the
full
group,
but
maybe
just
bring
it
up
now,
to
show
that
you
know
it's
something
that
we're
thinking
about
working
on.
If
you
just
want
to
develop
a
better
process
for
keeping
stakeholders
across
playing
in
the
loop
on
unbreaking
changes,
and
so
we're
considering
some
options
about,
you
know
different
approaches
for
release
prs
or
release
branching
and
kind
of
using
this
community
meeting
as
more
of
a
tool
to
synchronize
around
those
changes.
C
So
I
guess
stay
tuned
until
next
meeting
and
we
should
come
back
with
a
more
concrete
proposal
about
that.
E
Yeah
for
sure,
and
if
anyone
here
is
a
consumer
or
anyone
watching
the
recording
is
a
consumer
of
crossplane
and
there
are
ways
that
you
think
would
be
more
beneficial.
Obviously
I
think
you
know
simple,
like
change
log
and
that
sort
of
thing
are
very
important
and,
as
casey
said,
I
think
we're
already
making
a
non-standardized
effort
to
service
more
of
these
in
community
calls,
as
evidenced
today,
but
if
there
are
ways
that
you
say
this
is
how
I
typically
consume.
E
You
know
breaking
change,
information
from
other
projects
or
other
software.
I
consume
and
you'd
like
to
suggest
that
we
are
definitely
open
to
that,
and
so
please
feel
free
to
add
that
to
this
issue-
or
I
think
was
there
another
issue
you
had
casey
as
well.
I
couldn't
remember
or
is
that
is
that
the.
C
Other
one
maybe
you're
thinking
of
we
were
linking
to
the
point
14
release
issue
on
this
topic.
It's
like,
as
like
an
example
of
a
place
we
could
synchronize
around,
but
I
think
it's
the
only
one.
E
Cool
sounds
good
all
right.
Well,
I
think
that
we've
pretty
much
let
everyone
filter
out
here,
but
thanks
to
you
all
for
staying
to
the
end,
and
please
feel
free
to
mention
anything
in
slack
that
you
feel
like
wasn't
covered
here
and
have
a
great
rest
of
your
week
thanks
folks,
thanks
bye.