►
From YouTube: 2021-03-01 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
All
right
the
recording
has
started-
and
this
is
the
march
1st-
it's
march
now
2021
cosplaying
community
meeting.
The
biggest
news
going
on
right
now
is
that
the
v
1.1,
the
first
miner
release
since
the
major
1.0
release
is
happening
tomorrow
so
march,
2nd
the
release
1.1
will
be
rolling
out
and
dan
you've
already
got
some
steps
here.
Some
of
the
timing
that
you're
you're
planning
out
here.
Do
you
want
to
go
any
more
details
on.
B
That
no
not
too
much
the
the
main
thing.
It's
just.
A
B
We
should
probably
cut
a
cross
plain
runtime
release
today,
so
we
can
go
ahead
and
pin
that
and
I
have
down
at
the
bottom.
I
have
some
pr's
that
are
relevant,
but
this
is
all
for
now
got.
A
It
got
it
yeah,
I
don't
think
there's
been
major,
you
know,
features
or
anything
go
going
in
in
the
past
couple
weeks,
because
we've
been
on
a
feature
freeze
and
code
freeze
over
the
the
last
two
weeks.
So
I
don't
think
anything
too
big
has
gone
in
so
perhaps
some
of
the
main
feature
areas
don't
have
big
updates
since
last
week,
but
also
it
probably
makes
sense,
though,
to
kind
of
go
over
the
highlights
of
the
release
and
things
things
that
are
being
included
in
there
phil
and
dan.
B
Sure
yeah,
I
guess
that's
mainly
around
stuff-
we've
talked
about
a
few
different
meetings
now,
but
primarily
around
the
different
sources
for
credentials,
and
so
we
mostly
focus
on
the
credential
supplying
side
rather
than
the
connection
secret
output
side,
which
I
think
is
something
we'll
also
want
to
investigate,
moving
forward
as
well.
B
But
basically
this
enables
you
to
provide
credentials
and
via
methods
other
than
kubernetes
secrets,
which
is
definitely
something
we'd
heard
a
lot
of
community
members
asking
about
and
in
the
updated
docs
that
will
be
published
and
activated
to
the
latest
tomorrow,
we'll
have
the
the
vault
guide
in
there
and
that
sort
of
thing.
C
Cool
yeah,
so
for
the
provider
acceleration,
you
know
kind
of
work
continues
there.
There
have
been
some
enhancements
on
the
ack
side
that
I
think
mobility
is
kind
of
wrapping
up
and
we
have
a
vmware
provider.
That's
been
co-generated
by
casey,
that's
kind
of
an
experimental
mode,
not
sure
if
that
actually
kind
of
got
out
of
experimental
mode,
but
cure
attack
and
a
handful
of
others
are
interested
in
kind
of
kicking
the
tires
with
that
and
providing
early
feedback.
C
And
so,
if
that's
a
use
case
that
is
important
to
you,
definitely
jump
into
the
provider's
channel
and
just
let
casey
know,
and
you
can
get
some
of
those
early
bits
and
provide
provide
feedback
on
that.
On
the
composition
front,
I
think
nick's
online
and
so
nick.
Do
you
want
to
just
give
a
quick
update
on
what
you
know.
E
Yeah,
so
calvin
who's,
also
on
the
call
added
support
for
bi-directional
patching,
which
means
you
can
now
effectively
patch
in
reverse
of
the
the
way
that
you
could
in
1.0.
So
you
can
patch
from
composed
resources
to
the
composite.
E
I
believe
since
1.0
as
well
ben
agricola
added
patch
set
support,
so
you
can
now
sort
of
group
sets
of
patches
that
you
might
repeat
frequently
and
just
sort
of
refer
to
them
by
name
rather
than
having
to
repeat
them
a
bunch
of
times,
and
I
feel
like
I
maybe
added
a
feature
too,
but
I
don't
remember
what
it
was.
Oh
yeah,
so
I
added
some
machinery
to
allow
you
to
reorder
patches.
So
we
now
recommend
that
or
reorder
resources
or
resource
templates
within
a
within
a
composition.
E
So
we
now
recommend
that
you
name
your
resource
template,
so
that
allows
you
to
basically
insert
new
ones
in
the
middle
of
your
array
if
you
need
to
or
delete
ones
from
the
array
and
they'll
be
garbage
collected
as
opposed
to
sort
of
effectively
treating
it
like
a
like
an
immutable
array
of
templates.
F
A
Nick
do
do
you
think
it's
worth
updating
our
like
the
reference
platforms
that
we
have,
the
reference
configurations
to
kind
of
you
know
use
the
named
patch
practice
patch
set
as
well
too,
just
to
kind
of
show
off,
like
the
best
practices
around
that,
if
that's
the
way
that
we
recommend-
and
you
know,
updating
those
to
be
in
accordance
with
that.
E
That's
a
good
question:
how
often
do
you
think
that
people
use
those
as
references
documentation
is
all
updated
to
mention
it,
so
I
would
say
not.
I
mean
yes,
it's
a
good
idea.
Is
it
do
it
this
week?
Good
idea,
I
don't
know
yeah.
A
Fair
enough,
fair
enough,
oh
cool
yeah!
I
would
like
for
those
over
time
to
serve
as
not
only
as
practical
examples,
but
also
you
know
informed,
and
you
know
examples
that
are
well
aligned
with
our
best
practices
and
in
the
the
way
that
we
want
to
recommend
people
be
authoring,
their
own
configurations.
So
yeah,
probably.
E
We
have
do
we
have
sort
of
clear
ownership
of
those
at
the
moment
like
it
did.
Steve
jojo
has
implied
that
like
this
should
be
part
of
our
pr
flow
like
we
update
the
docs
and
things
like
that,
then
we
should
go
update
those
or
is
it
more.
A
No,
no
yeah
yeah,
it's
it
yeah!
It's
like
I'm,
maintaining
it
with
with
my
spare
time
and
that
that's
the
extent
of
the
ownership
currently
so
yeah.
It's
not
something
that
I
think
should
be
inserted
into
the
community
flow
of
you
know,
must-updates.
You
know
it's
like
part
of
cosplay
and
core
documentation
and
stuff
like
that.
So
I'm
yeah
I'll.
E
A
Myself,
you
know,
as
I
maybe
continue.
E
A
Yeah,
nice
yeah,
I
want
some.
I
want
the
fanciest
the
highest
level
of
fancy
I
could
possibly
get.
I
will
go
for
all
the
way
to
tottenham's.
Yes,
yes,
all
the
way,
awesome
cool,
so
1.1
going
out
tomorrow,
any
other
notes
for
the
1.1
release
or
features
included
et
cetera.
Are
we
playing
we're
playing
on
doing
a
blog
post?
I
assume
as
well
too,
to
kind
of
make
a
little
noise
and
summarize
these
features
in
a
in
a
nice
easy
to
read
format.
C
Yep
yeah
totally
so
that'll
be
going
out
later
this
week
and
then
just
a
couple
updates
and
some
of
those
other
bullets
there.
On
the
multi-language
front,
I
met
with
a
lot
and
basically
kind
of
working
through
the
the
ux
kind
of
generating
from
you
know,
crds
down
into
the
the
cdks
operator
that
basically
can
kind
of
run
behind
the
api
line
and
so
kind
of
looking
at
ways
to
kind
of
generate
scaffold
for
that,
and
so
that's
likely
to
be
our
go
forward
direction
on.
You
know.
C
Do
it
statically
at
build
time
or
you
can
run
it
dynamically
behind
the
kubernetes
api
line,
so
that'll
probably
be
our
direction
for,
for
that
there's
just
better
kind
of
code
gen
support
around
that,
but
that
multi-language
support
is
not
actually
going
to
be
in
in
1.1,
which
is
still
in
experimental
mode
in
the
cross.
Plane
cdk,
it's
repo,
which
you
can
try
out
today
and
there's
docs
and
stuff
on
that,
but
and
then
for
the
web
hook,
support
nick
or
dan.
C
E
I
think
he
just
got
a
design
wrapped
up.
Actually,
the
stuff
is
is
a
fair
amount
of
manual
labor,
so
he
made
good
progress
on
the
design.
There
is
some
stuff
that
we
we
need
to
figure
out
before
we
before
we
merge
that
but
yeah.
So
we.
F
E
D
E
Web
hooks-
and
I
think
we
need
to
figure
out
if
we
want
to
spend
the
time
to
actually
like
build
them
at
some
point,
because
we
do
keep
running
into
cases
where
we're
like
you
know.
At
the
moment,
dan
has
a
issue
with
gke.
That's
blocking
upgrading
a
that
sdk
and
a
solution
to
that
would
be
serving
two
different
versions
of
the
gke
api.
But
we
can't
because
we
don't
have
conversion
web
books
so.
C
Cool
okay
and
then
for
the
rate
limiting
and
the
back
off
dan.
Is
that
something
that
we
got
added
in
as
there's
like
the
more
customization
for
that.
B
Yeah,
so
we
we
changed
the
way
that
I
guess
all
met
the
manage,
reconciler
works
and
that's
been
updated
in
the
major
providers
right
now
and
that
we'll
make
sure
to
note
those
changes
in
the
release
notes
on
crossplane
runtime,
which,
as
mentioned
above
planning
on
doing
a
release
of
today,
so
most
of
the
the
major
providers
have
already
been
updated
and
that
can
just
be
kind
of
like
consumed
as
needed.
It's
not
like
a
breaking
change
or
anything
like
that.
It's
just
going
to
provide.
B
C
Cool,
that's
awesome
and
then
the
cluster
api
stuff
is
just
kind
of
a
long
running
thread.
So
that's
not
something
that
would
come
into
one
one,
but
any
updates
to
share
there.
B
Yeah,
it's
about
ready
for
a
demo,
so
I've
been
doing
the
live
streams
on
that
which
folks
can
can
watch
on
the
youtube
channel,
and
but
I
think
it
will
be
a
a
little
while
before
you
know.
We
we
officially
says
the
support.
It's
gonna
be
a
slow,
slow
roll
kind
of,
but
it
involves
adding
a
bunch
of
new
resources
to
provider
gcp.
So
folks
can
take
advantage
of
those
in
the
meantime
as
well,
whether
they're
using
cluster
api
or
not.
C
C
I
guess
more
specifically,
but
cool
awesome
yeah,
so
I
mean
and
we're
basically
still
really
focused
on.
You
know
stability
and
you
know
kind
of
having
a
good
post,
100
experience
and
whatnot.
So
a
lot
of
work
has
kind
of
gone
in
making
sure
that's
still
the
case
and
there's
been
some
like
docs,
fine,
tuning
and
kind
of
the
thing.
So
if
there
are
things
that
come
up
in
terms
of
what
can
be
improved,
definitely
let
us
know
and
happy
to
get
that
added
into
1.2.
A
Yeah
awesome
definitely
looking
forward
to
having
the
you
know.
First,
minor
release
go
out
now,
the
first
one
of
the
year.
I
suppose,
since
when
I
went
out
to
around
holiday
time,
so
very
excited
about
that
all
right,
then
we
can
move
on.
I
believe
to
the
community
topics
section
dan.
You
mentioned
that
you've
been
doing.
You
know
like
an
ongoing
series
of
live
streams
about
cluster
api
and
you've
done
one
for
gke
autopilot.
A
B
Yeah
as
long
as
we
have
something
that
would
be
relevant
to
to
show
on
there,
I
mean
it
doesn't
have
to
be
super
entertaining
as
anyone
who's
watched
recently
knows,
but
something
like
cluster
api
or
the
autopilot
things
are
things
that
are
relevant
for
a
broader
community
than
just
crossplane,
which
makes
them
good
candidates
for
for
doing
things
like
that.
The
cluster
api
stuff
will
probably
continue
for
for
quite
some
time.
B
So
whenever
I
have
the
opportunity
I'd
like
to
keep
doing
that
also,
if
there's
anything
that
folks
would
like
to
be
covered
on
one
of
those,
I
probably
will
not.
B
You
know
like
prepare
specific
streams,
because
we
already
have
those
with
bi-weekly
tbs
stuff
and
but
but
just
in
terms
of
like
things
that
I'd
be
doing
anyway,
happy
to
to
do
streams
on
that,
and
obviously
anyone
else
in
the
crosswind
community
is
also
welcome
to
stream
things
on
our
channel
as
well
just
ping
me
and-
and
we
can
get
you
set
up.
A
Yeah,
that's
about
like
the
consistent
content
coming
out
there
and
some
of
the
code,
the
the
the
gta
one,
the
rgk
autopilot.
One
was
super
interesting
because
it
was
like
you
know
you
were
adding
support
for
it,
as
their
support
was
rolling
out.
You
know
to
all
their
data
centers
and
users
and
stuff,
so
that
was
like
and
then
the
team
behind
it
was.
A
You
know,
engaged
and
active
on
the
live
stream
too,
and
they
were
like
okay,
the
docs
update
should
be
rolled
out
now
it
was
just
really
exciting
to
have
that.
You
know
kind
of
up-to-date.
You
know
very,
very
topical
and
current
addition
of
functionality
and
then
the
with
the
engagement
with
the
gcp
team
as
well
too,
was
really
really
cool
to
see.
A
I
think
all
right,
so
yeah
hashtag
we'll
keep
up
that
cool
work
on
live
streams
and
such
we
quick
update
on
our
lfx
mentorship
program.
The
linux
foundation
is
what
lfx,
I
believe
stands
for
the.
A
So
we
do
a
we're,
just
participating
in
a
mentorship
program
there,
where
we
had
a
couple
of
projects
that
were
open
for
applications
and
submissions
over
the
past
month
or
so,
and
we
reviewed
all
the
applications
and
selected
a
one
of
the
applicants
there
rahul
grover
for
the
project
of
our
end-to-end
integration
tests.
So
that's
an
area
that
we've
wanted
to
invest
in
for
quite
a
while.
A
I
think
we
have
some
good
ideas
around
but
having
raul
come
in
and
get
ramped
up
in
the
community
start
contributing
and
kind
of
take
some
of
the
early
foundations
of
integration
tests
and
end-to-end
coverage
and
all
that
sort
of
stuff
and
continue
to
take
that
further
and
invest
in
that
as
part
of
the
linux
foundation's
mentorship
program.
Here,
it's
something
we're
super
super
excited
about,
so
we'll
be
the
program
starts
today.
This
is
the
first
day
here,
so
we'll
be
working
with
raul
to
get
him.
A
You
know
ripped
up
and
welcome
to
the
community
and
support
him,
as
you
know,
as
he
as
he
needs
to
be
successful
here,
and
you
know
diving
into
this
feature-
and
you
know,
being
a
contributor
and
so
really
excited
about
that
for
a
lot
of
reasons.
D
A
On
some
of
these
calls
going
forward
as
well
too
a
quick
update
on
the
cncf
incubation
proposal.
So
I
we
now
have
a
you
know
enough
production
users
confirmed
to
and
consented
to
share
their
information
as
part
of
the
proposal.
A
So
now
that
we've
got
that
information
collected,
my
goal
is
to
finish
the
proposal
in
like
drafting
and
getting
some
feedback
from
the
team
here
itself
and
then
opening
it
in
the
technical
oversight
committee's
repo
and
in
the
cncfs
so
which
is
part
of
the
you
know,
formal
steps
for
the
process
there.
So
I
want
to
have
that
opened
up
by
wednesday,
so
I'm
taking
a
few
days
off
at
the
end
of
the
week
here
and
into
next
week.
A
D
A
All
right,
a
quick
note
on
the
crossband
community
day.
You
know
that
one,
the
this
this
upcoming
one
in
may
is
part
of
cubecon
itself.
It's
a
zero
day,
event
at
cubecon
and
it's
posted
by
the
cncf.
So
these
the
call
for
proposals
is
still
open.
Now,
we've
got
a
number
of
great
proposals
already
in
there,
and
this
the
end
of
this
week
is
the
oh
thanks.
Chris
looks
like
we
need
to
update
that
the
banner
there
on
the
crossfit.io
website
to
to
reflect
that.
A
We
still
have
until
the
end
of
this
week
to
get
some
get
a
proposal
in
there
to
speak
as
part
of
the
community
today,
and
we
are
all
more
than
happy
to
support
and
give
feedback,
and
you
know
provide
because
you
can
feel
free
to
use
project
maintainers
as
resources
to
to
drive
your
application
or
your
proposal
to
completion
and
in
a
state,
you're
feeling
good
about
happy
to
have
lots
of
folks
call.
The
call
here
talk
as
well
too
fill
any
other.
C
You
no,
it
looks
like
we're
starting
to
get
a
pretty
good
turnout
and
we're
looking
forward
to
the
event.
So
a
lot
of
awesome
use
cases
for
crossplane
and
always
good
to
hear
from
the
community
how
they're,
using
it
and
so
forth.
So
yeah
should
be
good.
A
A
Okay,
so
yeah
looking
forward
to
more
proposals
there
and
then
the
events
itself
in
may
is
gonna.
Be
it's
gonna,
be
great
all
right.
So
a
positive
update
on
the
docker
hub,
open
source
project
application
that
we
did
after
back
and
forth
there
and
being
initially
rejected.
I
got
the
cncf
involved
and
I
guess
there
was
some
confusion
amongst
the
the
people
running
the
open
source
program
there
at
the
docker
hub
and
all
cncf
projects
are
supposed
to
be
approved
and
allowed
into
the
program
there.
A
So
I've
got
confirmation
from
the
people
running
the
program
that
we
are
accepted
into
it
and
they
have
an
internal
service
ticket
opened
to
add
the
cosplay
namespace
to
the
allowed
list
of
of
name
spaces
that
will
no
longer
be
throttled,
they're
also
adding
a
feature
over
the
next
week
or
so
to
have
like
a
little
badge
or
some
sort
of
marker
on
your
docker
hub's
page.
A
That
says
that
you're,
a
community
project
or
an
open
source
program
project
or
whatever
the
correct
nomenclature,
is
there
so
it'll
be
clear
when
you
go
to
the
page
that
we
are
accepted
and
we're
part
of
that
part
of
that
deal
there.
But
I
hope
that
you
know
either
already
or
this
week
that
their
you
know
internal
service
teams,
get
that
completed
that
get
us
into
the
allow
list
and
able
to
be.
You
know
officially
part
of
that.
A
All
right,
any
other
community
topics,
things
to
talk
about
before
we
move
into
some
of
the
pr's
that
are
open
for
discussion.
A
Okay
cool,
then
we
could
hop
down
into
the
pr's.
It
looks
like
chris,
you
you
were
first.
D
For
it,
okay,
perfect,
so
the
issue
that
I
put
up
for
discussion
and
this
meeting
was
actually
an
older
one-
I
guess
not
not
too
old.
I
think
it's
from
september,
and
so
this
was
an
issue
created
by
nick
to
discuss
cross
plane,
supporting
arbitrary
kubernetes
resources
in
compositions.
D
E
I
think
we
probably
have
already
have
my
opinion
pretty
pretty
well
put
out
there,
but
I
I
did
want
to
weigh
in
the
summary
of
my
concern
here
is
balancing.
E
E
That
composition
wasn't
designed
for
composition
is
the
intent
originally
is
that
composition
would
be
something
that
would
be
used
to
compose
stuff
that
is
installed
by
a
provider
from
cross
plane
and
that
those
features
are
sort
of
somewhat
tightly
coupled
with
each
other
in
order
to
solve
a
specific
set
of
problems,
but
then,
by
accident
we
or
by
happenstance
we
happen
to
support
composing
stuff,
that
is
not
from
a
provider.
E
So
my
chief
concern
with
officially
saying
it's
cool.
We
will
we'll
support.
You
know
whatever
your
use
case
is
there.
I
mean
it
would
be
really
nice
to
help
folks,
but
I
think
we
do
need
to
be
conscious
that
that
somewhat
changes
the
mandate
of
the
project
right
it.
It
potentially
expands
the
scope
of
crossplane
from
where
this
project
that
helps
you
with
your
cloud
native
infrastructure
and
lets.
E
You
build
new
api
extractions
on
top
of
that
to
just
wear
a
composition
engine
for
kubernetes
and
that
can
have
definitely
subtle
implications
when
designing
things,
because
now
we
have
to
you
know
if
someone
comes
to
us
and
they're
like
actually,
I
have
I'm
just
using
composition
to
install
a
bunch
of
config
maps
and
I
don't
have
providers.
E
E
One
thing
that
would
and
we're
already
getting
some
of
this
on
this
on
this
issue.
But
one
thing
that
would
be
super
useful
here
is
just
get
more
sort
of
experience
reports
as
they
sort
of
put
it
in
the
go
community,
because
one
thing
that
I've
heard
and
talked
about
here
is:
if
folks,
I
think
a
lot
of
folks
are
wanting
to
use
composition
with
a
mix
of
cross,
plane
providers
and
other
things
which
is,
which
is
probably
the
most
compelling
use
case
to
me.
E
I
think
if
folks
were
using,
let's
say
composition,
just
for
like
all,
not
cosplaying
stuff,
you
know
no
providers,
one
one
approach
there
is,
we
could
just
walk
or
they
could.
Someone
could
fork
cross
plane
and
you
know
have
a
you
know,
a
side
project
that
was,
you
know,
experimentally,
taking
composition
and
and
building
it
out
for
for
that
use
case
sort
of
thing.
But
if
people
are
doing
a
little
bit
of
both,
then
maybe
it
makes
more
sense
to
build
that
in
our
project.
F
By
the
way,
if
I
may
actually
this
is
something
that
my
team
has
been
actually
trying
that
we
actually
fought
cross
plane.
I
witnessed
some
change
to
be
able
to
compose
arbitrary
resources,
because
we
actually
had
some
use
case
where
we
like
to
reuse
some
of
the
existing
operators
that
we
have
and
we
don't
really
want
to
be
rebuild
everything
trapping
we
cross
cosplaying
kind
of
in
cluster
resources.
So
I
mean
it
will
be
a
lot
of
work.
F
So
that's
why
you
know
I
keep
on
actually
getting
people,
at
least
in
ibm,
even
reddit.
They
leave
me.
You
know
this
composition
actually
is
very
valuable,
but
you
know
we
don't
really
want
to
rebuild
everything
as
a
cosplay
provider,
because
we
really
have
a
lot
of
investment
in
operators
other
things.
E
Yeah,
I
think
that
you
raise
a
really
good
point
with
regards
to
a
big
part
of
the
reason
that
people
want
to
do.
This
is
because
they
have
existing
software,
that
isn't
a
provider
and
we're
saying
everything
should
be
built
as
a
provider,
and
we
don't
have
a
good
patent
at
the
moment
for
taking,
let's
say
a
plain
old
operator
or
something
that
exists
there
and
translating
it
to
a
cross-plane
provider
yeah.
E
The
reason
we
want
to
do
that
is
because
you
know
we
talk
about
the
cross
plane
resource
model,
we
value
consistency,
we
value
people
coming
into
our
ecosystem
and
finding
that
one
resource
works
like
another
resource
sort
of
thing,
like
as
a
thought
experiment.
One
thing
that
I
think
here
is:
let's
say
we
open
up
composition.
We
say
you
can
use
composition
for
everything
and
then
it
it
devalues
the
need
for
providers
in
the
first
place
you
could,
then
you
could
then
take
another
step
and
say
why
have
all
of
these
providers?
E
E
So
you
could
start
using
composition
with
those
and
just
not
have
providers,
and
then
you
don't
have
a
package
manager
anymore
to
help
with
rbac
and
and
make
it
that
easy
you've
just
got
to
go,
handle
all
that
by
yourself
and
then,
if
you're,
using
multiple
clouds,
you're
now
going
to
learn
how
aso
works
and
you've
now
got
to
learn
how
comfy
connector
works.
I
guess
there's
a
there's.
E
Each
engine,
don't
feel
like
they're
part
of
a
cohesive
ecosystem
where
they
can
know
that
if
they're
using
ibm
resources,
you
know
they've
they've
taken
the
time
to
learn
the
tooling
of
crossplane
to
learn
how
to
use
this
tool
to
learn
how
to
use
this
ecosystem
they're
going
to
use
ibm
resources
and
they
work
one
way
and
then
they're
going
to
use
aws
resources
and
they
work
in
other
ways.
Sort
of
thing.
F
Well,
I
think
the
different
pieces
of
crossplane
the
way
it
is
designed
now
their
value
by
itself
right,
for
example,
providers
to
me
they
have
value
even
independent
of
composition
right
because
you
have
this
kind
of
homogeneity
and
this
way
to
provide
this
kind
of
high
fidelity,
declarative
representation
called
apis
in
a
very
consistent
way
that
I
haven't
really
seen
in
other
projects,
because
it's
true
there
are
operators
here
and
there
to
manage
some
infrastructure,
but
there
is
no
really
a
consistent
approach
where
you
say:
okay,
let's
install
this
provider,
and
now
I
actually
have
all
these
declarative
resources
for
the
cloud.
F
I
think
those
things
still
will
have
value
and
composition,
of
course,
is
value
by
itself
and
open
application
model
value
by
itself.
So,
yes,
it's
nice
to
have
all
these
things
integrated.
I
think
they
are
integrated,
not
very
nicely
it's
good
to
actually
use
all
these
things
together,
but
I
think
there
will
be
always
cases
where
people
want
to
use
just
providers,
so
just
won't
use
composition
or
just
want
to
use
or
open
application
model,
and
that
is
common
also
in
other
projects
in
cscf.
F
E
Well
again,
it's
it's
it's
it's
mostly
it
again.
I
guess
it
depends.
I
I've
been
guilty
at
times
of
optimizing,
maybe
too
much
for
the
maintenance
of
the
project
and
making
it
easy
to
grow.
Cross-Plane
sort
of
thing
and
again
you
know
from
an
architectural
standpoint
when
you,
when
you
decide
to
support
more
and
more
features
and
functionality
and
more
and
more
very
variants
of
things,
it
cuts
off
paths
that
might
have
previously
been
opened
to
you
sort
of
thing.
E
It
puts
you
into
a
box
where
you
then
have
to
say
okay,
I
have
to
factor
in
this
thing,
and
that
means
I
have
fewer
options
in
future,
but
I
can
see
that
this
is
something
that
folks
are
asking
for
a
lot.
E
I
I
think
that
this
is
probably
something
that's
going
to
come
down
to
a
steering
committee
decision
at
some
point
and
I
I
think
we
have
been
putting
it
off
for
a
while,
and
I
would
just
absolutely
encourage
people
to
to
do
what
I
think
most
of
the
people
on
this
call
have
already
done
and
and
to
you
know,
help
people
in
the
community.
Let's
get
a
ton
of
experience
reports
in
that
issue.
Let's,
let's
you
know
I,
where
there's
you
know,
I
think,
let's
keep
them.
E
You
know
super
specific
so
that
we
can
build.
You
know
people
like
I
want
to
build
a
tool
that
does
this
here's
my
here's,
my
context
for
it,
because
I
would
still
love
to
weigh
it
against
the
ability
to
easily
build
provider
abstractions,
as
this
is
sort
of
plumbing
here,
but
I
I
know
that
that's
a
bit
of
a
long
shot.
E
We
don't
have
a
really
good
way
to
do
that
at
the
moment,
so
love
to
be
able
to
keep
our
options
open
and
see
if
we
can
sort
of
find
a
way
that
is
consistent
within
the
cosplaying
community
to
to
solve
this
problem,
I'm
definitely
not
saying
we
will
never
open
up
composition.
I'm
just
saying
it
is
not
a
decision
to
be
taken
lightly.
In
my
opinion,.
F
So
I
think
that
a
composition
and
abstraction-
I
think,
what
I'm,
what
I'm
hearing
composition
extraction
from
an
architectural
standpoint
for
composing
kubernetes
resources,
would
be
quite
useful.
C
F
I
don't
know
whether
or
not
crossplane
is
exactly
the
right
place
to
do
it.
I
mean
what
I
could
see
would
be
that
that
abstraction
would
come
and
then
maybe
the
cross,
plane
composition
resource
would
be
a
duct
type.
That
would
be
under
that
in
some
fashion.
I
think
maybe
that's
I
don't
know
what
might
be
done,
but
I
mean
I
it
sounds.
It
sounds
to
me
like
probably
cross
plane.
Isn't
the
right
place
to
do
it,
but,
but
I
don't
know-
maybe
that's
something
the
community
needs
and
then.
E
F
E
A
better
understanding
of
these
use
cases
would
help
me
form
an
opinion
on
that.
I
need
to
go
and
reread
this
issue.
I
will
admit
I
haven't
looked
at
it
in
the
last,
maybe
one
or
two
weeks,
but
I
I
think
that
you
know
if
folks
were
sort
of
just
like
I'm,
you
know
like
say,
running
k
native
and
I
just
want
to
you
know
compose
all
my
native
things
that
starts
to
feel
like
it's,
not
really
part
of
cross
plains.
E
E
So
there
is
to
a
certain
extent,
I
don't
know
if
we
can
just
evolve
the
project
to
be
sort
of
a
general
composition
engine
or
we
might
but
like
that.
That
would
evolve
more
than
just
doing
it.
That
would
involve
you
know,
sort
of
repurposing
the
project.
C
And
some
of
the
the
factors
involved
were
like
providing
a
consistent
experience
across
all
the
resources
that
were
being
used,
and
so,
when
you
look
at
you
know
like
crrs,
when
you
look
at
like
consistent
status
fields
and
then
being
able
to
kind
of
aggregate
those
up,
there's.
Definitely
like
an
experience
component
to
that
where
we,
we
could
open
it
up
to
everything.
But
then
there
are
kind
of
these
like
ux
trade-offs
involved,
and
it's
definitely
something
that's
like
worth
further
discussion.
But
it's
not
a
slam
dunk
either
way.
C
So
it
does
require
more
discussion
and
really
appreciate
you
opening
this
issue
or
commenting
on
it
and
it's
something
that
we'll
definitely
discuss
more
and
appreciate,
appreciate
your
feedback
on
it.
D
Yeah,
I
guess
one
thing
to
add,
like
I
don't
think
the
user
experience
needs
to
necessarily
suffer
just
because
you
know
we
want
to
add
support
for
arbitrary
kubernetes
resources
like
right
now,
it's
already
possible
to
do
this
within
cross
plane
right
nick,
like
through
the
readiness
checks,
and
you
know,
in
the
current
system,
there
is
like
a
optimistic
default
that
assumes
that
the
resources
are,
you
know,
provider,
resources
right
like
they
check
for
status
fields
and
that
can
be
overridden
by
users
putting
their
own
readiness
checks
like
in
the
current
model.
D
E
I
know
this
is
an
example
of
a
controversial
thing
that
we
do
but,
for
example,
all
of
our
resources
from
providers
are
claustroscoped,
and
so
I
think
that
then
you
can
start.
You
know
when
you,
when
you
start
to
form
a
mental
model
of
how
things
work
in
the
cross-plane
ecosystem.
You
can
just
be
like
all
right.
I've
got
this
claim.
It's
name
spaced.
I've
got
this
xr
it's
claustroscoped
and
then
all
my
managed
resources
are
costly.
E
I
would
bet
that.
That's
almost
certainly
not
the
case
for
the
other
resources
that
people
want
to
start
composing.
So
then
things
like
relationships
between
resources
across
name
spaces.
Things
like
that,
like
start
to
become
just
it's
possible
and-
and
you
know
the
people
who
want
to
do-
it
probably
hopefully
have
some
understanding
of
this,
but
it
just
when
you
like,
I
feel
like
I
feel
like.
Maybe
the
thing
for
me
is
when
you
describe
what
crossblade
is
and
how
it
works.
E
E
You
know
if
we
were
going
all
in
and
we
were
gonna
say
that
you
could
use
composition
for
anything
like
I.
I
do
kind
of
think
that
maybe
forking
composition
might
be
the
way
to
go
there,
like
you
know,
a
separate
project
that
accounts
for
that.
You
know
we
could
keep
it
under
the
cross
plate
or
something
like
that,
and
you
know
call
it
see
how
much
it
seem,
how
much
it
diverges,
sort
of
thing,
call
it
an
experiment
and
see
how
it
works,
and
then
you
know,
look
at
up
streaming
stuff
there.
E
But
again
I
I
do
think
that
we
need
to
get
together
with
the
steering
committee
and
go
through
this
one,
because
this
is
a
pretty
it's
a
very
impactful
decision
on
the
future
of
the
project.
I
think
I
I
I
guess
you
know
part
of
my
fear,
as
I
say,
is
that
you
could
just
fragment
the
cosplay
ecosystem
sort
of
thing.
I
could
imagine
cosplaying
becoming
a
thing
where,
like
a
whole,
bunch
of
people,
just
don't
use
providers
and
maybe
that's
okay,
but
yeah.
A
Yeah,
if
any
any
folks
want
to
you
know,
weigh
in
with
some
more
information
about
their
use
case
and
their
expectations
for
this
functionality,
then,
on
this
issue,
1730
is
a
great
place
to
do
that,
because
you
know
when
taking
a
difficult
decision
like
this.
You
know
that
has
implications
and
then
also
by
its
nature,
inherently
has
a
lot
of
open-ended
possibilities
to
it
that
more
information
about
what
are
the
expectations
from
folks.
A
That's
that
are
looking
for
this
functionality,
and
you
know
one
of
their
use
cases
to
kind
of
take
that
all
into
account
is
very,
very
helpful.
So
it
might
be
to
add
more
comments
to
1730.
A
Okay,
cool
yeah,
so
looking
for
more
comments
on
17
30
for
anybody,
the
discussion
is
open.
There,
dan,
you
2166.
B
Oh
yeah,
okay,
so
I
just
I
just
mentioned
this
because
it
needs
to
go
in
today
and
be
back
ported
to
the
release,
1.1
branch
in
terms
of
review.
I
don't
think
it
should
be
too
extensive.
It
does
move
a
lot
of
things
around,
but
it's
mostly
like
renaming
and
slight
adjustments,
and
I
think
the
the
commit
order
should
make
that
pretty
straightforward
to
follow.
I
I
tried
to
do
my
best
to
make
that
pretty
digestible
as
a
reminder.
B
Folks
can
pull
down
this
branch
and
run
it
locally.
If
you
want
to
look
at
it
as
it
would
actually
be
rendered
in
the
docs
in
the
crossplan.github.io
repo,
you
can
see
the
the
steps
for
doing
that.
So,
if
you
want
to
see
it
in
that
format,
but
in
terms
of
actually
executing
steps,
these
are
already.
These
are
things
that
have
already
been
tested.
B
There
is
one
small
change
in
that
I
bumped
the
configuration
packages
to
say
greater
than
crossplane
1.0.
B
The
main
reason
for
doing
that
is
just
because
I
realized
the
crossplan.yaml
snippets
we
had
did
not
match
because
they
didn't
include
the
constraints
in
there,
so
that
that
shouldn't
change
functionality
for
folks
at
all,
because
anyone
using
this
documentation
will
need
to
be
using
1.0
or
later
anyway.
So
would
definitely
appreciate
some
review
on
that
today.
E
E
From
the
broad
community-
or
I
guess,
anyone
who
doesn't
work
on
cross
plane
from
from
day
to
day
who'd
be
interested
in
reviewing
that
I'm
happy
to
do
the
final
review
on
this
documentation,
pr
dan
but
I'd.
I
really
love
it
if
someone
else
could
take
a
pass
first,
that
could
be
someone
from
our
team,
but
I
think
it'd
be
super
useful
to
have
some
people
who
weren't
as
like
intimately
familiar
with
these
documents
to
sort
of
give
a
give
their
input
on
it.
A
And
something
that
could
facilitate
that
is
dan.
I
know
with
if
you're
making
changes
to
the
crosswind.ios
site
itself,
you
know
you
can
have
like
it
through
github
pages,
you
can
have
a
publicly
accessible.
You
know
page
for
your
fork.
Is
that
possible,
but
the
docs
changes
too.
Is
it
possible
that
someone
just
click
and
go
browse
and
see
this
experience
live
to
kind
of
help
reviewing
or.
B
Not
as
easily
because
that
fork
is
or
that's
facilitated
by
it
being
in
the
site
that
gets
rendered
by
netlify-
and
this
is
like
you
know
separate,
so
it's
not
actually
in
that
repo,
but
I
could
do
some
stuff
to
to
get
a
demo
out
there.
Probably
so
I
could
take
a
look
at
potentially
trying
that
out.
E
B
E
Wouldn't
spend
a
ton
of
time
on
that.
I
know
there
are
some.
You
know
some
some
oddities
with
regards
to
the
fact
that
we
use
html
to
like
render
out
our
tabs
and
things
like
that,
but
I
still
feel
like
people
should
be
able
to
do.
It
have
a
fairly
good
understanding
of
how
this
all
works
going
going
through
the
the
markdown
sort
of
thing.
I
guess.
D
E
B
Yeah
that
sounds
good
and-
and
like
I
said
I,
you
know,
this
is
something
that
was
supported
by
feedback
in
slack
pretty
unanimously,
at
least
in
my
interpretation.
So
I
think
folks
are
already
on
board
with
this,
and
it
is
things
that
have
been
tested.
So
we
shouldn't
be
too
worried
from
that
regard,
but
yeah
just
so.
I
I
think
that
it
could
be
a
pretty
easy
review
for
anyone,
who's,
interested
and,
and
that
would
definitely
be
greatly.
A
Appreciated
yeah:
this
could
be
something
I'm
interested
in
myself
dan
to
like
build
it
locally
and
have
you
know,
be
able
to
see
the
see.
E
Locally
for
for
context
for
folks
on
the
community
call
I
had,
I
guess
jared
and
I
now
have
slightly
different
roles:
upbound
with
slightly
different
responsibilities,
and
one
part
of
that
for
me
is
I'm
trying
to
find
a
way
to
keep
up
with
the
crossplane
community
without
as
deeply
reviewing
all
pr's.
A
I
think
this
would
be
a
big
help
for
the
the
experience
and
kind
of
getting
started
too.
That
was
it's
very
fun
to
see
the
tgi
kate's
episode
on
friday,
where
they
went
into
cross
playing,
and
you
know
going
through
the
user
guides,
and
you
know
looking
under
the
hood
and
stuff
like
that.
So
some
of
that
was
these
documentation.
Changes
here
are
more
confirmed
by
that
experience
as
well
too
kind
of
making
make
it
easier
to
get
in.
B
Another
thing
that
has
been
called
out
both
well
kind
of
by
tgik
and
as
well
as
by
some
folks
in
the
community,
is
and-
and
this
should
be
a
pretty
small
change.
I
don't
want
to
include
it
in
this
pr
or
maybe
not
even
in
this
release
by
tomorrow,
but
there's
been
a
couple
folks
that
are
like.
Can
you
please
show
how
you
could
do
any
of
the
crossplane
cli
stuff,
but
with
just
cube
control,
apply
which
is
what's
happening
behind
the
scenes?
B
So
it
would
be
good
if
we
could
add
some
expandable
blocks
that
have
like
you
know
the
provider
actual
object
that
gets
created
and
that
should
be
relatively
straightforward.
B
Yeah,
would
it
be
okay
if
I
share
my
screen
for
this
one
just
for
a
couple.
B
Cool,
thank
you
all
right,
so
this
actually
came
out
of
the
the
autopilot
stream
so
for
folks
who
didn't
catch
any
of
that
kind
of
stuff,
gke
added
a
new
feature
called
autopilot
where
they
basically
manage
your
node
pools
and
scaling,
and
everything
for
you
super
cool
feature.
One
of
the
things
that
we
wanted
to
show
off
is
how
fast
we
can
add
new
functionality
to
resources,
so
I
did
a
stream
I
camera.
I
think
that
was
wednesday.
I
believe
last
wednesday,
where
we
added
autopilot
support.
B
One
of
the
things
that
kind
of
papered
over
in
that
stream
is
that
it
required
updating
to
a
new
version
of
the
sdk
that
we
use
for
for
gke
and
a
number
of
other
resources
as
well,
and
so
that
actually
broke
the
gke.
Well,
it
removed
some
fields,
it
changed
the
api
for
gke,
specifically,
it
dropped
two
fields
and
that
would
be
tier
settings
and
enable
peer
peering
route
sharing.
B
B
They
have
some
pretty
well,
I
was
going
to
say
pretty
good
documentation,
but
I
actually
I'm
not
a
huge
fan
of
it,
because
I
don't
think
it's
super
clear
about
what
their
policy
is,
but
essentially
they
have
v1
v1,
alpha,
1
and
vue
and
beta1,
although
I
believe
they
don't
actually
support
an
alpha
api
for
for
gke,
but
these
this
is
confusing
because
they
use
the
same
terminology
as
kubernetes
versioning
conventions,
but
they're
actually
doing
something
different,
so
v1
beta
1,
as
you
would
guess,
we'll
just
talk
about
b1
and
v1
beta1
has
beta
features
at
some
point.
B
During
that
promotion
process
they
may
be
changed
or
mutated
in
the
way
they're
represented,
and
then
the
other
thing
that
we
obviously
learned
from
needing
this
update
was
that
v1,
beta
1
fields
can
just
be
dropped
entirely,
and
so
we
can't
really
have,
in
my
opinion
at
least-
and
I
added
a
comment
here
just
a
few
moments
ago-
that
kind
of
explains
the
situation,
but
as
initially
the
person
who
added
this
api,
I
think
that
I
probably
should
have
gone
with
just
using
the
v1
api.
B
Although
you
know,
if,
if
fields
were
not
breaking,
it
would
theoretically
be
better
to
use
v1
beta1
as
you'd
have
more
support
for
more
things.
Theoretically.
B
So,
but
if
they're
going
to
be
dropping
fields
from
this
or
changing
the
api
and
breaking
ways,
then
we
really
can't
support
this
as
a
v1,
beta,
1
or
eventually
a
v1
api
in
crossplane,
in
my
opinion,
so
the
proposal
here
is
instead
of
just
bumping
up
the
sdk,
so
we've
we've
previously
had
it
pinned.
So
we
didn't
have
to
do
this,
but
other
implementations
such
as
adding
this.
B
I
think
this
is
like
a
dns
resource
or
something
required
updating
which
would
drop
these
fields
as
well
as
adding
something
like
autopilot,
which
was
a
new
field,
would
require
dropping
these
fields.
B
So
what
I'm
proposing
here
is
we
instead
start
creating
beta
groups
for
each
of
the
different
apis
and
we
have
and
we
support
two
variations,
so
one
in
the
container.gcp.crossblind.org
and
one
in
beta.container.gsp.crossplan.io
and
the
beta
groups
are
the
types
in
the
beta
groups
that
we
always
keep
those
at
alpha,
because
we
really
are
not
in
control
of
the
field,
deprecation
policy
and
if
you
want
to
or
field
removal.
I
guess
for
that
matter
and
if
you
want
to,
you,
know,
upgrade
to
a
new
version
or
add
support
for
a
new
feature.
B
You've
got
to
be
able
to
bump
the
sdk
which
may
result
in
breaking
changes.
So
I'm
proposing
here
that
we
switched
to
using
the
v1
api
for
the
gke
cluster
type.
We
also
switched
to
using
the
v1
api
for
node
pool,
which
is
currently
alpha,
and
then
we
introduce
variations
in
in
a
beta
group
for
both
of
those
resources
that
remain
at
alpha
level
forever.
Forever.
E
So
I
I
broadly
think
that
that's
probably
the
right
way
to
go.
I
especially
stuff
that's
built
on
the
beta
api
in
in
terraform,
sorry
that
I'm
saying
terraform,
because
I
have
a
thought
that
relates
to
terraform,
but
not
only
stuff.
That's
built
up
the
beta
api
and
google
seems
like
it
like
you
say
it
can
never
be-
is
effectively
has
the
contract
of
alpha
apis
in
in
kubernetes.
E
So
so
my
only
thought
here
which
relates
to
that
terraform
thing
is:
they
literally
have
two
different
providers.
They
have
they.
They
handle
this
by
having
terraform
provider,
google
and
terraform
provided
google
beta.
I
don't
know
if
that
would
help
architecturally
or
code
wise.
I
could
see
two
things.
One
was
would
be
that
if
there
were
separate
providers
you
could
explicitly
you
could
install
both.
D
E
B
Yeah
yeah,
I
thought
about
that
too,
and
I
think
casey's
on
the
call
in
case
he
had
suggested
that
to
me
which
casey
and
move
off
it
got
some
really
great
feedback
on
this
last
week,
and
I
I
think
I
actually
maybe
didn't
follow
what
they
said
so,
but
they
had
some
good
feedback
that
could
potentially
be
better
options,
and
one
of
them
was
that
terraform
suggestion
where
they
have
two
separate
ones
that
you
know
a
couple.
That's
definitely
a
valid
path
to
go
a
couple
things
to
note.
B
In
that
scenario,
you
could
still
run
into
issues
with
updating
the
version
you
know
in
terms
of
like
between
beta
resources
right.
So
if
we
need
to
update
the
sdk
that
could
force
us
to
drop,
you
know
on
one
api
type,
that's
also
beta.
However,
those
would
all
be
marked
as
beta
one
of
the
things
that
is
also
a
consideration,
of
course,
is
that
you
know
it
would
be
maintenance
of
another
provider,
which
is,
is
a
non-zero
cost.
B
Although
I
think
that
every
day
our
maintenance
is
getting
better
in
terms
of
integrating
with
cloud
providers,
I
could
kind
of
go
either
way
for
some
reason.
I
feel
like
leaning
towards
having
one
thing,
but
I
don't
really
think
that
that
is
motivated.
I
I
don't
have
a
good
reason
for
that
right
now,
so
I'd
love
to
see
if
folks,
on
the
call
have
a
feeling
either
way,
I
mean
one
of
the
things
that
may
be
motivating.
This
is
that
this
resource
exists
in
this
provider
right
now.
B
Obviously,
updating
is
going
to
cause
like
having
to
do
a
lot
of
manual
changes
anyway.
So
I
think,
breaking
into
another
provider
is
really
not
that
different,
but
I
think
part
of
me
just
feels
like
I
want
to
continue
to
like
support
this
in
in
this
provider,
but
I'm
not
sure
that's
really
a
great
reason.
Yeah.
E
I
feel,
like
you
know,
there's
obviously
upfront
costs
of
forking
a
provider,
but
from
a
user
experience.
Another
thing
that
I
feel
like
would
be
potentially
confusing
is
so
so
my
understanding
is,
we
basically
can't
have
we
can't
just
you
know
say
that
this
is
the
v1
alpha,
1
version
of
of
this
resource
and
then
there's
a
vmware
beta
one,
and
we
have
a
web
hook
that
translates
between
the
two
of
them,
because
of
how
variable
the
the
google
v1
beta
1
stuff
is
our
alpha
stuff
right.
E
Also,
it's
kind
of
it's
two
different
apis
at
the
cloud
provider
level
sort
of
thing,
so
it
seems
like
the
right
thing
to
do
here,
is
to
literally
treat
it
as
a
different
kind
of
xr.
But
then
it's
going
to
have
the
same
kind,
and
it's
going
to
only
differ
in
like
does
it
have
beta
in
its
name
or
not.
E
So
another
thing
that
I
feel
like
would
be
kind
of
confusing
is
for
people
who
just
go
and
install
the
google
provider
over
the
fullness
of
time,
like
a
lot
of
resources
would
end
up
being
repeated
twice
and
it
might
be
easy
to
accidentally
use
the
beta
gke
cluster
when
you
don't
intend
to
use
the
beta
gk
cluster
or
to
interpret
that
by
kubernetes
semantics
of
being
like.
Oh,
this
is
the.
This
is
the
alpha
version.
This
is
the
so
I
do
kind
of
feel
like
breaking
it
out
into
a
whole
different
provider.
E
That
is
like
hey.
Do
you
want
beta
apis
for
google?
Like
then?
This
is
the
way
to
go,
especially
because,
as
far
as
I
know,
we
can
we
can
install
those
both
at
the
same
time
that
feels
like
you'd
be
making
a
much
more
conscious
like
yeah.
I
really
you
know
I
feel
like
we
could
position
this
as
like.
You
should
use
the
stable
one
unless
you
really
really
need
a
new
shiny
feature
that
you
want
to
try
now
and
you'll
be
going
for.
You
know,
you'll
get
alpha
semantics
for
that
sort
of
thing.
E
B
Yeah,
I
think
those
are
really
really
strong
reasons
and,
and
I'd
agree
with
that,
just
to
open
it
up
to
anyone
else
as
well.
Does
anyone
else
have
contrasting
or
or
agreeing
thoughts
there.
G
A
bit
about
the
the
separate
providers,
I
think
in
the
case
of
terraform,
you
tend
to
just
use
one
or
the
other.
So
if
you,
if
you
find
that
you
need
beta
providers,
you
just
kind
of
use
the
beta
provider
and
and
there's
not
really
a
downside,
you
know
it's
it's
mostly
the
same
thing.
Just
I
think
a
lot
of
the
google
beta
stuff
is
just
you
know.
Some
people
have
beta
access
and
get
resources
accessible
sooner
for
new
features.
G
B
Is
is
probably
not
going
to
be
an
issue
gotcha
yeah,
I
mean
one
of
the
things
in
the
short
term.
Is
we're
not
gonna,
like?
I
think
that
you
know
if
we
make
this
change
here,
folks
will
not
be
able
to
upgrade
their
provider
gcp
until
we
have
a
release
of
the
provider
gcp
beta,
which
I
mean
like
in
some
ways.
It's
fine,
no
matter
what
we
do
here,
it's
going
to
be
breaking
so
they
should
probably
stick
there
anyway,
but
initially
I'd.
B
Imagine
that
you
know
we
might
do
a
provider
gcp
beta
release
that
does
not
have
support
for
all
of
the
resources
that
are
currently
supported
in
provider
gcp
right
now,
but
having
the
option
to
use
both
at
the
same
time,
if
needed,
even
if
that's
not
super
relevant,
could
potentially
be
valuable
for
the
short
term.
G
Yeah,
I
think,
like
one
benefit
of
potentially
allowing
them
to
conflict,
is
that
it
could
make
the
migration
path
easier
like
if
you
started
out
on
the
non-al
non-beta,
and
you
realize
you
needed
some
beta
features.
You
could
just
like
you
know,
install
the
beta
provider
instead
and
all
of
your
resources
would
basically
work
the
same
way.
But
you'd
have
some
some
new
fields
available.
Yeah.
B
Well,
the
the
issue
is
like
there
are
equal
fields
with
like
different
names
and
stuff.
So
it's
not
just
like
you
know
you
switch
over
and
it's
like
an
expanded
api.
Like
that's,
I
think
that's
what
I
thought
it
was
actually
when
we
implemented
this,
but
that's
clearly
not
the
case.
So,
like
you
know
it
may
I
think
I
I'd
opt
towards
not
having
them
conflict
rather
than
trying
to
like
make
that
upgrade
path.
It's
going
to
be
hard
anyway,
smoother,
that's
just
my
two
cents,
just
as.
E
A
side
note,
we
have
a,
I
think,
I'm
in
a
meeting
with
the
config
connector
team
this
week.
Maybe
so
I
can
always
ask
them
for
tips
on
what
they
do
to
address
this
on
their
end
of
the
world,
because
I
obviously
face
the
same
issue
but
yeah.
There
is
a
tricky
thing
here
where
I
I
think
to
casey's
point.
E
If
it,
if
it
was
possible
that
we
could
just
say
these
are
mutually
exclusive,
you
can
only
install
one
or
the
other,
and
that
way
you
can
just
be
running
beta
and
then
switch
to
v1
without
changing
your
config
for
a
lot
of
folks.
That
would
be
compelling,
but
it
seems
like
it
would
require
surgery
potentially
anyway,
you
would
have
to
basically
be
sure
that
you
only
had
like
the
shared
set
of
fields.
B
Well,
I
guess
the
issue
is
that
they
don't
make
any
promises
about
that
so,
like
I
could.
I
have
context
of
one
resource
which
is
not
very
you
know,
representative
and
like
the
the
ability
that
we
could
run
into
the
issue
in
the
future,
because
there
is
this
sort
of
like
this
arbitrary
policy.
Yeah.
G
B
Yeah,
I
think
that's
true
one
of
the
things
that
that
is
a
bit
of
a
misnomer
that
I
just
want
to
point
out
in
that
pr
is.
It
looks
like
there's
a
lot
of
functionality
that
gets
added,
but
that's
just
because
we're
stale
on
the
beta
sdk.
So
so
I
think
you're
right
casey
that
you
going
from
beta
to
releases
is
likely
not
to
change
too
many
fields.
E
So
jared
and
I
need
to
drop
now
to
go
to
another
meeting.
One
thing
I'd
like
to
understand
is
how
how
urgent
is
this
you
know
is
this:
this
feels
like
a
kind
of
a
fair
bit
to
unwind.
Do
we
really
want
to
get
this
ready
so
that
we
can
ship
provided
google
tomorrow?
How
much
time
do
we
have
to
make
this
decision.
B
Well,
I
I
think
we
have
you
know
potentially
as
much
time
as
we
want.
I
I
don't
think
well.
First
of
all,
we
don't
need
to
ship
provider
gcp
tomorrow,
which
is
nice.
B
I
would
like
to
get
this
done
by
the
next
time
we
ship
provider
gcp,
which,
because
of
some
things
like
rate,
limiting
that
sort
of
thing,
I
would
like
to
be
not
not
to
be
too
far
from
now,
but
I
you
know
every
time
we
kind
of
like
release
before
we
do
this,
it's
kind
of
like
building,
potentially
more
users
or
more
places,
where
someone's
using
this
api,
that
we're
planning
to
change
slash
remove.
E
Yeah,
okay,
how
do
you
think
we
should
we
drive
forward
with
this,
like
it
seems
like
there's
a
couple
of
different
options
that
we
put
forward,
which
is
basically
support
them
both
in
the
same
provider,
support
them
both
in
a
mutually
exclusive
fashion
in
different
providers
or
support
them,
both
in
a
compatible
fashion,
I.e
under
different
api
groups
in
two
different
providers?
E
Do
you
want
to
maybe
just
in
an
issue
or
something
like
that?
Do
a
quick
summary
of
the
trade-offs
of
those
and
then
maybe
we
can
try
and
make
a
quick
executive
decision
by.
I
feel
like
we
can
maybe
do
this
async
or
set
up
a
meeting
to
force
the
function
sometime
later
this
week,.
B
E
B
E
A
Oh
yeah,
that's
the
last
issue.
We
had
our
pr
issue
to
discuss
there
and
that
is
the
conclusion
of
the
all
the
items
in
the
agenda
dock.
So
I
think
we
can
go
ahead
and
wrap
it
up
here
and
the
1.1
release
will
be
going
out
tomorrow
as
planned
thanks
everybody
for
for
showing
up
and
contributing
today
appreciate
it.