►
From YouTube: 2021-03-15 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
Oh,
I
was
on
mute,
okay,
the
recording
has
started
now,
so
we
can
go
ahead
and
get
started
if
you've
joined
in
and
want
to
add
yourself
to
the
attendees
list
here
feel
free
or
someone
else
can
can
grab
that.
A
But
let's
get
started
on
our
milestones
and
such
so
the
since
the
last
community
meeting
the
1.1
release
went
out,
so
there
is
a
blog
post
that
has
been
published.
That
kind
of
goes
into
some
of
the
details
about
the
1.1
release.
You
know
definitely
really
happy
and
of
like
the
community
effort
behind
that
and
some
of
the
the
features
and
advancements
that
went
in
there
from
you
know
a
full
full
set
of
contributors
in
the
community.
You
know
that
was
the
first
release.
A
I
think
we
did
on
our
the
eight
week
release
cycle
so
we'll
be
doing
that
same
sort
of
release,
cycle
and
cadence
for
for
the
next
release,
so
like
we're
working
towards
1.2
now,
and
so
I
think
dan-
you
added
in
here
the
you
know
the
sensitive
scheduled
release
date,
which
would
be
towards
the
end
of
april.
There
is
there
anything
else
to
add
on
that.
A
Dan,
or
is
this
the
thing
good,
okay,
cool
sounds
good,
so
yeah,
so
there's
a
helpful
link
here
too
around
the
the
upcoming
schedule
for
releases,
which
you
know
you
can
find
right
here
on
the
main
readme
page,
and
then
you
know
three.
I
believe
it's
three
releases
at
a
time
will
or
is
it
four?
I
can't
remember,
I'm
sorry
will
be
you
know,
maintained
which
are
eligible
for
for
matches
and
fixes
going
back
to
them
to
continue
servicing
them,
but
the
schedule
will
be.
A
All
right
so
we're
working
towards
the
end
of
april.
You
know
we
have
the
high
level
roadmap
was
defined
for
for
1.2
with
some
of
the
high-level
areas.
A
Here
I
think
so
something
I
I
want
to
want
to
do
here
is
in
this
meeting
is
be
focusing
kind
of
on
the
project
board,
and
so
I
would
like
us
to
you
know,
be
able
to
do
what
we
can
to
keep
this
up
to
date
in
terms
of
what
are
the
you
know,
the
areas
that
we
are
exci
have
accepted
into
the
milestone
areas
where
we
want
to
be
making
investments,
you
know
and
things
that
are
open
and
in
progress
and
closed
too
so
keeping
this
the
project
board
for
upcoming
releases
up
to
date
will
be
a
really
good
public
community
way
to
see
everything
that's
going
on,
what's
planned.
A
What's
you
know
what
we're
actually
doing
and
what
is
the
status
of
all
of
those
as
well
too.
B
B
Well,
the
point
that
was
part
of
the
motivation
for
those
of
us
who
were
not
bound
for
for
moving
the
meeting
around.
There
were
other
reasons
as
well,
but
if
we,
if
we
move
this
meeting
to
a
thursday,
that
puts
it
really
close
to
when
we
do
our
team
planning
and
we've
fallen
into
a
bad
habit
of
planning
internal
planning
open
source
stuff
in
our
private
meetings,
we
don't
want
to
do
that.
B
We
want
to
get
it
back
out
into
the
open,
so
part
of
that
was
was
hygiene
for
us
one
thing
that
might
be
good
to
do.
Maybe
the
next
meeting
would
be
to
discuss
as
a
community.
B
How
we
want
to
manage
these
boards,
because
I
don't-
I
don't
think
it
was
ever
really
something
that
there
was
a
public
conversation
about
how
we
wanted
to
sort
of
get
things
on
the
cross
plane
board.
One
example
is
that
we
put
things
like
design
documents
on
that
board
that
aren't
really
tied
to
a
particular
release
at
the
moment
that
just
represent
that
people
are
working
on
them.
We
have
we
only.
We
don't
have
boards
for
each
provider
for
releases
for
them,
for
example.
B
So
a
lot
of
provider
features
go
on
this
board,
even
though
we're
not
necessarily
shipping
providers
when
we
ship
a
release,
so
it
may
make
sense
to
do
a
session
to
to
figure
out
what
exactly
we
want
to
do
with
this
board
and
how
the
community
can
get
involved,
because
one
thing
that
we
want
to
keep
on
top
of
there
is:
we
need
a
process
to
discuss
what
goes
into
a
release.
You
know
what
goes
in
the
proposed
column
and
how
things
get
accepted,
and
things
like
that.
B
So
not
sure
if
myself
or
someone
else
should
potentially
put
together
a
proposal
for
how
this
might
work
to
inform
the
next
meeting,
but
something
that
I
think
would
be
good
to
have
the
community
weigh
in
on.
A
Yeah
that
makes
sense
and
there's
been,
we've
had
some
discussion
too
about
you
know
a
what
is
the
best
process
for
or
what
is
a
process
for
you
know,
proposing
changes
and
proposing
new
features
to
be
accepted.
A
So
I
think
that
we'll
want
to
continue
following
up
on
that
and
get
that
defined,
and
you
know
have
that,
like,
I
think,
a
key
thing:
there
is
the
accessibility
of
it
to
make
sure
that
the
process
is
easy
to
find
well
known,
easy
to
follow
enough
to
be
able
to,
you
know,
have
new
ideas
and
things
that
would
benefit
the
project
as
a
whole
and
the
community
of
adopters
around
it
to
be
able
to
you
know,
get
things
in
them
to
them
and
go
through
the
process
too.
A
On
that
to
kind
of
define
that,
and
then
we
should
continue
following
up
on
that.
B
Did
we
did
we
stop
that
publicly
jared
at
some
point.
A
C
A
Awesome
that
sounds
great,
then
yeah,
because
I
know
we
had
a
desire
for
that,
but
getting
some
traction
and
getting
that
kind
of
written
down.
So
we
can
iterate
on
it
sounds
fantastic,
so
we're
kind
of
early
in
1.2.
Do
we
want
to?
I
don't
want.
I
don't
want
to
go
over.
You
know
every
single
issue
in
this
board
here,
but
some
of
the
high
level
aspects
here,
these
all
move
off.
A
Here
now,
are
you
yeah.
D
Yeah,
a
lot
of
them
are,
like
you
know,
the
ones
in
in
progress.
I
think
all
of
them
are
review
reviewing
other
people's
pr's,
the
one
one
pager
pluggable
web
books,
that
is
a
design
dog
in
progress
and
the
pr
open
or,
like
you
know,
open
pr's
and
the
bugs
are
there,
and
I
haven't
had
time
to
look
into
them.
So.
A
Yeah,
I
think
that
then
like
this
board,
we
need
to
like
put
a
you
know
as
a
1.2
planning
process.
We
need
to
kind
of
get
this
board
up
to
date
so
that
you
know
the
areas
that
we
want
to.
A
You
know
be
committing
to
or
including
this
release
get
get
put
into
the
columns
here
and
then
we
can
start
tracking
them
as
we
go
through
the
cycle.
B
Yeah,
I
think
I
think
one
detail
is
that
unless
we
choose
to
add
a
new
forum
for
doing
that
or
find
a
way
to
do
it
async
that
this
meeting
is
going
to
be
the
place
where
we're
going
to
do
that.
There
are
no
other
dedicated
forums
at
the
moment
to
grouping
this
board.
A
Yeah
yeah
exactly
okay
cool,
so
what
are
so
the
high
level
areas?
You
know
that
we're
like
that
are
part
of
the
roadmap
here,
like
the
plugable
webhook
support
like
we,
you
know
what
you
have
the
design
going
for
that
already
and
starting
to
get
some
feedback
and
everything
on
that
right.
D
It's
it's
it's
I
I
haven't
opened
the
pr.
Yet
it's
interact.
A
Yeah
and
then
like
the
enhanced
back
off
cross-court
controllers,
that's
already
being
rolled
out
and
implemented
right.
C
A
Okay
and
then
move
off.
Do
you
want
to
provide
a
little
like
there's
a
whole
theme
around?
You
know
some
of
the
code
like
aws,
you
know
accord
generation
stuff.
Do
you
want
to
provide
a
quick
update
on
that
general
area.
D
Yeah
sure
we
have
a
few
prs
that
are
opened
by
the
community
and,
like
you
know,
I'm
reviewing
them
and
have
people
getting
them
merged,
and
there
are
also
a
couple
prs
in
the
ack
report
that
I
opened,
for
example,
the
reference
and
selector
fields.
D
I
think
one
of
those
pr's
got
a
review
from
jay
from
ack
team,
so
I
will
get
back
to
that,
but
yeah.
The
general
theme
is
that
we're
we're
continuing
to
add
new
resources
with
code
generation
and
we
are
enhancing
the
code
generation
pipeline
itself
is,
like
you
know,
more
more
parts
being
generated
automatically.
A
B
A
I
think
that's
fantastic
yep
and
then
also,
I
think,
a
big
update.
That's
coming
up
soon
is
the
vsphere
provider
as
well
too.
That
should
be,
you
know,
releasing
you
know,
hopefully,
within
the
next
couple
weeks
here
so
that'll,
be
part
of
at
least
the
1.2
time
frame
not
tied
to
it,
but
part
of
the
1.2
time.
A
Frame
cool
and
then
also
integration,
testing
is
an
area
that
is
getting
specific
efforts
on
now
as
well
too.
I
think
that
rahul
is
on
the
call
as
well
too.
We
was
going
to
introduce
rahul
later
on
here,
but
it's
a
good
time
now.
I
think
too
so
for
integration
testing
the
linux
foundation's
mentorship
program.
We
got
a
lot
of
applications
to
work
on
some
cosplaying
projects
through
that
mentorship
program
and
rahul.
A
Grover
was
accepted
into
the
program
here
and
he's
already
started
on
getting
ramped
up
and
he's
going
to
be
making
investments
to
improve
and
expand
the
coverage
of
our
integration
testing,
which
is
definitely
an
area
that
will
be
really
really
beneficial
to
everyone.
By
giving
us
some,
you
know
more
confidence
about
our.
You
know:
quality
from
commit
to
commit
ability
to
upgrade.
You
know
all
sorts
of
scenarios.
That'll
be
really
really
helpful,
so
rahul.
A
A
Rahul,
do
you
want
to
give
a
quick
update
about
some
of
the
stuff
you've
been
focusing
on
so
far
like
towards
the
you
know,
provider
upgrade
testing
stuff.
It's
just
a
quick
summary
of
that.
E
Yeah
sure
thing
so,
since
I
was
new
to
a
bit
golang
stuff,
so
first
of
all
in
provider
upgrading
testing,
I
moved
on
to
looking
into
github
actions,
so
I
had
explored
all
the
stuff
and
we
discussed
in
the
last
meeting
as
well
that
update
regarding
the
github
actions,
and
now
I
have
moved
on
to
moving
on
to
looking
into
the
github
tests
how
we
can
write
like
the
go
test
specifically
for
the
upgrade
testing
part
so
probably
by
tomorrow.
A
Awesome,
yeah
really
really
happy
to
have
you
here,
rahul
and
you
know
really
excited
to
see
what
your,
what
you're
making
over
the
next
couple
months.
A
Awesome
any
any
other
comments
on
the
1.2
efforts
that
are
kind
of
getting
getting
underway.
Here.
We've
got
some
more
more
work
to
do
to
kind
of
get
ramped
up
and
get
the
milestone
more
crisply
defined,
but
any
other
comments
on
the
early
efforts
here
from
1.2.
D
A
D
B
A
Cool
then
I
think
we
could
move
on
to
the
community
topics
section
here.
So
nick
you
kind
of
already
addressed
the
you
know
the
desire
to
to
move
the
meeting
to
a
thursday
time.
I
think
that's
that
will
be
good,
for
you
know
general
planning
purposes
and
getting
you
know
the
efforts,
you
know
more
more
organized,
I
think,
and
so,
as
nick
stated
there.
A
I
think
that
we'll
want
to
make
a
more
concerted
effort
to
use
this
time
to
be
planning,
and
you
know,
scheduling
or
figuring
out
work
items
etc.
Within
this
meeting
it's
kind
of
been
a
bit
of
a
you
know
the
community.
We
figured
things
out
and
we're
kind
of
just
talking
about
status
of
this
meeting,
but
I
think
getting
more
people
involved
having
to
be
a
more
transparent.
You
know
community
driven
visibility
process.
There,
I
think,
will
be
a
really
good
good
effort.
So
I'm
glad
that
we'll
be
doing
that.
B
D
B
Right,
because
that
would
be
you
by
next
thursday.
You
mean
not
this
week,
but
the
next
week
right,
yeah.
B
Or
something
like
that
and
announcements,
they
would
be
aware
that
we're
going
to
change
the
date,
so
I
think
we
can
pretty
much
merge
it
now
and
and
then
update
the
calendar
and
whatnot.
A
Cool
sounds
perfect,
all
right
dan,
any
updates
on
some
of
the
cool
live
streams
and
stuff
you've
been
doing
recently.
I
know
you've
been
doing
more
customer
api
live
streams.
C
Yeah
so
we
haven't
had
a
tbs
show
in
a
little
bit,
and
some
of
that
is,
we
are
going
to
get
that
set
up
alternate
with
the
with
the
new
community
meeting
so
like
like,
as
you
all
were
saying.
Next
thursday
should
be
our
first
community
meeting
and
we
want
to
do
tbs
on
the
alternate
weeks
from
that,
and
so
two
weeks
from
this
thursday
will
probably
be
our
next
tbs
episode
and
right
now.
The
tentative
plan
is
to
do
one
on
flux.
Folks
are
familiar
with
that.
C
It's
just
a
cncf
project,
kind
of
similar
to
like
argo
cd
for
git,
ops,
kind
of
workflows
that
just
went
to
incubation
and
the
cncf,
so
we
kind
of
want
to
celebrate
that
with
them.
So
that's
the
tentative
plan
for
that
before
that.
I
imagine
we'll
have
a
few
more
cluster
api
live
streams
as
we're
moving
towards
doing
a
community
upstream
cluster
api
community
demo
of
some
of
the
work
that
we've
been
showing
there,
but
those
will
most
likely
be
impromptu
as
the
as
the
past
ones
have
been.
A
Awesome
yeah,
I
think
all
those
episodes
are
super
awesome
dan.
So
thanks
for
the
work
we've
been
doing
on
those,
I
was
just
looking
for
try
to
grab
a
link
from
some
of
the
more
recent
ones.
I
found
it
now.
A
Okay,
cool-
and
so
we
already
introduced
and
welcomed
rahul
for
from
the
halifax
mentorship
program.
So
thanks
again
for
joining
us
happy
to
have
you
another
update,
then
on
the
incubation
proposal.
So
we
do,
we
got
the
responses
that
we
needed
and
some
production
adopters,
always
taking
more
anyone
who's
you
know
successfully
using
the
crosstalk
project
in
production
scenarios
or
even
not
just
still
evaluating,
is
fine
too
more.
A
You
know,
information
about
that
and
the
more
you
know
kind
of
awareness
of
adopters
to
the
project
the
better,
but
that
the
proposal
should
be
updated.
Sorry
should
be
submitted
any
like
very
very
soon.
I
think
the
kind
of
putting
it
together
is
the
final
touches
and
polish
on
it
and
should
be
updated
or
submitted
very,
very
soon
so
excited
to
get
that
in
there.
A
Okay
and
then
the
community
event
planning,
for
that
is
ongoing.
That
will
be,
you
know
a
zero
day
event
at
it's
pubecon
cloudnativecon
I
supposed
to
which
is
the
often
forgotten.
Second,
second
events
title
for
that
thing
so
may
4th
is
when
the
community
is
being
held.
We
got
a
good
number
of
proposals
submitted
for
it,
and
the
selection
committee
is
is
reviewing
those
now.
A
B
I
went
through-
I
I
think
as
of
yesterday
only
unless,
unless
folks
have
done
it
since
only
marching-
and
I
have
voted
on
everything,
but
it's
due
tomorrow
morning,
I
think
pacific
standard
time
we
had.
We
had
34
submissions
and
overall,
I
would
say
they
were
all
very
good.
They
we
had
to
the
student
committee,
not
the
committee.
Sorry,
the
review
committee
ranks
them
from.
B
I
guess
zero
to
five,
and
so
far
I
haven't
seen
anything
that
hasn't
been
on
the
high
end
of
that
scale.
So
I
think
it's
gonna
be
tough
to
filter
them
down.
If
we,
if
we
do
in
fact,
need
to
so
very
very
high
quality
submission
so
far.
A
Do
we
know
when
the
notification
acceptance
certifications
go
out?
What
the
timeline
for
that
is.
B
I
don't
know
off
the
top
of
my
head.
I
can
have
a
look
at
my
email.
C
Stop
your
head,
I
don't
think
so,
but
it
should
be,
I
think,
the
beginning
of
next
week.
It
might
be
that
early,
it's
either
the
beginning
of
next
week
or
the
following
week.
I
thought
so,
but
yeah
definitely
double
check
on
that
awesome.
B
B
It's
a
typo
yeah,
sorry,
I
presume
it
does
say
thursday
march
16th,
but
it
also
says
tuesday
march
16th.
So
I'm
guessing
it's
just
a
copy
paste
error.
So
this
is
my
guess:
that's
the
one
thursday
that
falls
between
us
making
a
final
decision
tomorrow
and
the
schedule
going
live
on
monday.
A
Thursday
march
18th,
it
is
awesome.
34
submissions
is
quite
impressive
as
well
too.
I
didn't,
I
didn't
know
my
submission
had
so
much
competition,
so
we'll
see
we'll
see
how
that
goes.
Then
I
won't
be
offended
if
I'm
not
selected,
I
only.
B
Gave
out
a
very
small
handful
of
five
out
of
fives
and
two
of
three
of
those
were
talks
by
one
particular
community
member
who
shall
remain
unnamed.
A
Nice
perhaps
they
are
on
this,
call
all
right
cool
and
then,
mr
mr
dan,
you
have
you
want
to
kind
of
walk
us
through
some
of
the
work
you've
done
around
the
new
member
onboarding.
From
recently.
C
Yep,
so
this
document
is
very
short,
but
it
describes
how
an
individual
in
the
community
can
request
membership
to
the
crossplane
org.
So,
typically,
we've
kind
of
just
done
this
in
an
ad
hoc
manual
way,
where
you
know
we're
trying
to
assign
an
issue
to
someone,
and
we
realize
we
can't
because
they're
not
in
the
org.
C
So
then
we
add
them
and
we
really
wanted
to
formalize
the
process
around
this
because
number
one
we'd
end
up
adding
people
who
you
know
weren't,
really
interested
in
contributing
long
term
and
number
two
there's
lots
of
folks
who
have
made
major
contributions,
who
are
not
part
of
the
organization
and
both
you
know,
from
a
logistical
standpoint
of
requesting
reviews
and
assigning
issues,
it's
nice
to
have
them
in
the
org
and
also
from
a
recognition
perspective.
C
C
You
do
need
to
request
sponsorship
privately
from
two
folks
that
are
already
in
the
crossplane
org,
and
they
once
you
have
this
issue,
they
will
sponsor
you
so
a
good
example
of
there's
a
closed
issue
now
of
rahul
actually
became
the
first
member
to
go
through
this
process
and
rahul
was
sponsored
by
jared,
and
I,
since
were
two
of
the
the
mentors
for
the
lfx
program
alongside
movavic
and
so
rahul
went
through
this
and
you'll
see,
there's
also
a
pr
that
closed
this
and
the
pr
actually
adds
a
manifest
to
the
repo
or
yeah
adds
to
the
manifest
in
the
repo
with
an
entry
of
a
github
org
membership
kubernetes
object.
C
So
the
idea
here
and
we
have
a
live
stream
where
we
go
through
kind
of
working
on
some
of
this
and
we'll
probably
have
another
one
soon.
The
idea
here
is:
we
have
a
crossplane
cluster
running
and
we
set
up
some
automation
here
that
when
a
pr
is
merged
that
modifies
this
manifest,
we
essentially
control
apply
it
to
the
cluster
provider.
Github
running
there
sees
that
in
the
controller
for
a
membership
is
set
up
to
check.
C
If
a
member
is
already
part
of
the
cross
plan
org
and
if
not
create
an
invitation
and
when
they
accept
it,
it'll
make
sure
they're
there,
and
so
in
this
case,
since
we
don't
have
that
set
up
quite
yet,
jared
went
ahead
and
added
rahul
to
the
org,
but
in
the
future,
it'll
all
be
managed
via
pull
requests
and
in
general,
some
of
this
automation
and
using
crossplan
to
actually
manage
our
org
is
something
we
want
to
move
towards.
C
So
you
can
imagine
some
of
things
like
if
we're
doing
enhancement,
proposals
or
or
pulling
issues,
you
know
into
a
certain
milestone.
Those
could
all
be
managed
through
a
pr
and
approval
process,
and
the
nice
thing
here,
for
instance,
is
adding
a
new
member
to
the
org
is
something
that
requires
a
steering
committee
approval.
So
when
I
opened
this
pr,
it
required
jared,
nick
or
bassam
to
come
in
and
approve
it
and
merge
it.
C
So
we
have
all
of
those
different
policies
that
are
stated
in
our
government:
governance
codified,
which
is
really
nice,
and
we
have
a
traceable
history
of
all
these
things
happening.
So
there's
lots
of
different
areas.
We
can
continue
to
improve
this
and
it's
cool
to
use
crossplane
to
dog
food
that
effort,
so
if
you're
kind
of
newer
to
the
community
and
interested
in
getting
involved
with
some
of
that
definitely
reach
out,
and
we
we
have
plenty
of
work
to
do
there.
A
Yeah,
I
think
that's
that's
one
of
the
things
I
mean
besides,
like
having
a
nice
process
to
join
the
the
organization
in
github
and
be
a
member
of
it.
I
I
think
it's
so
cool
that
it's
you
know
being
managed
by
crossplane
itself
right.
This
is
an
instance
of,
like
you
know,
cosplaying
being
a
controller,
and
you
know
extending
the
kubernetes
control
plane
to
manage
some
resources
outside
the
outside
of
the
control
plane.
A
So
I
think
that's
really
cool
to
be,
like
you
know,
declaratively,
adding
a
new
member
and
then
having
that
be
reconciled
with
the
github
api
to
the
members
to
the
organization.
So
that's
a
really
creative
idea
to
use
crossplane
to
be
managing
some
other
agency
out
in
the
world
out
in
the
world
there
so
kudos
to
dan,
forgetting
that
getting
that
going.
A
So
that
is
in
the
crossband
org
repo,
so
the
org
or
repo
underneath
crossplane.
There
has
the
issue
template
and
you
know
the
process
for
for
becoming
a
new
member.
If
anyone
is
interested
who
is
not
already
a
member
on
this
call,
most
most
people
probably
are,
though,
okay
all
right.
So
that
was
all
the
community
topics
here.
A
I
don't
see
specific
prs
in
the
just
to
discuss
here
in
this
section
so
before
we
move
on
to
the
optional
time
at
the
end,
here
we're
going
to
kind
of
dive
into
some
more
technical
details.
Maybe
kind
of
you
know
circle
around
on
some
of
those
for
a
bit.
I
wanted
to
open
the
floor
for
anybody
else
who
has
a
general
topic
or
a
topic
applicable
to
all
attendees
here
that
they
want
to
bring
up
before
we
go
into
the
optional
time.
A
Cool
well,
let's
do
that
then.
Let's
go
proceed
into
the
optional
time
here,
so
anybody
who
wants
to
break
off-
and
you
know
adjourn
from
the
meeting
here
and
and
not
stick
around
for
these
deeper
technical
conversations-
is
more
than
welcome
to
take
off
now.
The
recording
will
still
continue.
So
if
you
want
to
catch
up
later
on
then
you're
more
than
welcome
but
other
than
that
dan.
Do
you
want
to
bring
up
your
issues,
one
by
one.
C
Sure
so
the
first
one
here
is
one
that
we
discussed
at
the
last
community
meeting,
but
the
rfc
has
been
baking
for
some
time
now
and
I
think
there's
been
pretty
positive
feedback
across
the
board
to
go
ahead
and
get
this
done.
So
the
proposal
here
is
based
on
the
gcp
api
structure.
We
want
to
follow
the
same
path
that
terraform
has
done
with
their
providers
and
some
other
folks
to
consume
the
gcp
api
have
and
have
separate
providers
for
their
stable
apis
and
for
their
beta
apis.
C
And
essentially
you
know
you
can
look
at
the
proposals
here,
but
essentially
we
would
never
move
the
apis
and
provider
gcp
beta
to
v1,
because
there's
not
a
guarantee
of
stability,
which
is
an
issue
that
we're
seeing
right
now,
where
different,
different
resources
that
we
have
in
provider.
Gcp
have
breaking
changes
in
them
because
they
rely
on
beta
apis
and
so
an
update
will
break
at
them.
C
But
we
can't
update
other
resources
or
add
new
ones
because
we're
maintaining
this.
You
know
older
version
of
the
sdk
to
support
these
these
fields,
so
we'd
like
to
have
two
separate
providers
and
the
main
provider
dcp
will
only
use
their
v1
stable
apis,
so
this
will
involve
both
creating
the
new
provider
and
having
some
breaking
changes
to
provider
gcp
beta
for
provider
gcp
for
the
next
release,
they're,
not
huge
breaking
changes,
but
they
they
do
reduce
some
of
the
functionality.
So
we
definitely
want
to
communicate
this
well.
C
The
one
thing
that's
kind
of
been
up
for
debate
is
the
name
of
the
api
groups.
It
looks
like
both.
It
looks
like
now,
nick
and
potentially
move
office
said
as
well,
yet
to
use
beta
as
the
leading
indicator
in
the
group
name.
I
think
that's,
probably
fine.
I
kind
of
lean
towards
having
the
provider
name
gcp
beta
in
there,
just
because
it's
more
in
line
with
other
providers,
but
I'm
kind
of
indifferent,
but
I
guess
this
is
the
technical
discussion
time.
E
B
Concern
is
not
the
right
word.
The
main
thing
that
comes
to
mind
for
me
around
this
whole
thing
is
just
that
this
seems
like
it
will
be
a
breaking
api
change
and
it's
pretty
rare
for
us
to
make
breaking
api
changes
to
things
that
we've
marked
beta,
so
just
communicating
it
and
having
some
kind
of
documented
path,
maybe
to
to
go
from
folks
who
have
like
a.
B
B
Exists,
I
also
as
a
side
note
another
thing
it.
It
might
be
worth
if
we
haven't
already
doing
a
little
bit
of
research
into
like
what
would
go
into
the
beta
provider
because,
as
far
as
I
can
tell-
maybe
I'm
wrong.
But
I
was
looking
at
the
cloud
sql
api
the
other
day
and
I
thought
the
cloud
sql
only
has
a
beta
api
just
googling
this
now
to
try
and
because
that
seems
unlikely,
because
I'm
pretty
sure
like
terraform
makes
this
split,
for
example,
and
they.
C
Yeah,
I'm
fairly
certain
that
right
now
in
in
provider
gcp,
the
only
beta
api
we
depend
on
is
gke,
which
is
nice
because
it
reduces
the
churn
and
this
change.
But
let
me
verify
here:
yeah.
B
Oh
it
just
dessert
yeah.
I
wonder
how
that
works.
I
can
only
see
v1
beta
4
under
the
cloud
sql
admin
api.
Oh.
C
Yeah,
it
does
look
like
we're
using
v1
beta
4.,
so
that
would
be
an
interesting
one,
but
I
mean
I
presume,
if
it's
still
beta,
we
put
it
in
the
gcp
beta
1,
but
that
would
theoretically
involve
dropping
it
from
from
this
one,
which
feels
like
a
pretty
large
breaking
change.
If
we're
totally
dropping
it,
there's
nothing
to
replace
it.
C
B
C
C
I
think
the
next
steps
are
probably
first
setting
up
well,
it
sounds
like
that
we
want
to
you
know
when
we
make
the
breaking
change,
we
want
to
have
the
alternative
ready,
which
would
make
sense.
C
So
I
think
the
next
steps
are
setting
up
the
provider
g
speed,
beta
repo,
getting
it
bootstrapped
getting
some
of
the
current
types
that
are
beta
right
now,
which
would
be
gke
and,
potentially
you
know
the
cloud
sql,
depending
on
what
we
deem
there
and
and
then
once
that's
ready,
potentially
running
a
release
of
that
sooner
and
then
making
the
necessary
updates
and
and
provider
gcp
with
the
braking
changes.
C
But
yeah
that
that
could
be
a
way
to
go.
We
could
also
just
instead
of
like
literally
forking
on
github.
You
can
also
just
you
know,
push
the
origin
somewhere
else,
which
I
don't
know
if
it
might
just
show
up
kind
of
weird
if
it's
forked
in
the
github
ui,
but
it
doesn't
really
matter
also.
I
don't
know
if
we
can
fork
it
from
the
well,
it
had
a
different
name
so
yeah
whatever
we
can.
We
can
figure
that
out.
C
Cool,
I
think
we
can
go
the
next
one.
C
All
right
this
one,
let
me
pull
it
up.
This
one
is
one
I
opened
on
friday
and
asked
for
some
feedback,
and
lots
of
folks
gave
it
so
definitely
appreciate
that
I
did
feel
like
there
was
maybe
a
bit
of
confusion
about
what
exactly
would
be
exposed
here,
and
there
are
also
a
couple
of
different
design
decisions
that
I
was
hoping
to
talk
through.
C
So
I
I
think
that
nick's
response
here
about
putting
this
on
the
let's
see
on
the
external
connector
instead
is
definitely
a
good
way
to
go,
I
think,
being
able
to
configure
configure
it
at
both
the
provider
and
provider.
Config
level
is
good,
and
when
I
say
provider
I
mean
like
as
a
as
a
flag
to
the
the
entry
point
of
the
the
binary
I
you
know,
and
that
can
be
configured
with
the
controller
config.
C
I
know
there
was
some
talk
like
from
steve
about
putting
in
something
like
a
cron
schedule,
for
that
I
that
would
be
pretty
like
complex
logic
and
you
couldn't
necessarily
enforce
it
that
much
so
so
the
idea
there,
I
guess,
would
be
like
you
get
a
predictable
kind
of
number
of
you
know,
hits
on
the
api
that
that
you,
you
know,
deem
with
like
the
cron
schedule,
but
in
reality
what
this
value
is
being
talked
about
being
used
for
is
that
in
the
happy
path
for
each
resource,
how
often
we
re-queue-
and
so
you
know,
based
on
when
that
resource
was
created,
and
that
sort
of
thing
the
cron
schedule
doesn't
make
quite
as
much
sense
there,
and
so
I
think
the
you
know,
the
primary
use
case
would
be
in
in
the
happy
path
when
you
have
like
you
know,
a
ton
of
resources
or
something
like
that.
C
You
have
something:
that's
not
super
critical
to
be
synced,
frequently
or
if
it's
just
kind
of
like
a
kind
of
static,
static,
metadata
resource
like
something
like
im
or
something
like
that.
C
You
may
just
want
it
to
like
sync
once
a
day,
and
so
I
think
just
having
that
recu
after
value
exposed
or
what
we're
calling
the
poll
interval
right
now
exposed
and
then
still
using
the
the
back
off
that
we
implemented
for
the
error
path
would
be
pretty
good
one
other
thing
I
want
to
mention.
I
know
move
office
and
I
had
some
discussions
about
whether
this
should
be
exposed
on
the
provider
object
or
on
the
controller
config.
C
I'm
pretty
staunchly
in
the
controller
config
camp
I'd
say
because
putting
on
the
provider
would
bring
like
deployment,
slash
container
configuration
to
a
resource
where
we
currently
have
a
separation
of
concern
of
those
types
of
things.
Plus
we
don't
guarantee
that
every
provider
is
going
to
support
this
functionality
or
this
flag.
So
from
that
perspective,
I'd
say
control
or
config,
but
definitely
want
to
hear
move
office
and
other
folks.
Thoughts
on
that.
B
Before
we
sorry
move,
I
don't
need
to
cut
you
off,
but
before
we
before
we
dive
in
on
that,
you
know,
where
does
this
flag
go?
I
I
probably
I
want
to
make
the
comment
that
I
think
for
a
lot
of
folks,
especially
folks
who,
like
haven't
written
a
provider
or
deep
dive
to
provide
a
source
code
this
this
might
be
a
little
bit
of
a
peak
there's
one
part
of
that.
B
I
think,
means
that
once
we
do
start
exposing
this
setting
somewhere,
I
think
we'll
need
fairly
thorough
documentation
around
how
it
works,
because,
as
you
alluded
to
before
dan,
it's
not
sadly
as
simple
as
set
this
flag
and
cosplay
will
only
hit
your
api
every
n
seconds.
It's
it's
very
much
cosplaying
will
hit
your
api
per
resource
per
managed
resource.
It
will
hit
your
api
every
10
seconds
or
whatever
you
set
this
poll
interval
to
and
even
then
it's
only
in
the
happy
path.
B
C
B
Hit
your
api
more
than
this
frequently,
but
it's
it's
very
difficult
to
do
with
without
control
around
time
it
works.
D
Yeah
for
the
field,
I
think
we're
on
the
same
page
with
putting
it
to
provider
config
right.
C
Yeah
yeah,
I'm
just
I'm,
I'm
very
hesitant
because
any
sort
of
like
custom
customization
of
the
deployment
or
yeah
any
any
aspect
of
the
deployment
is
like
a
fairly
highly
sensitive
operation.
I
mean
installing
a
provider
is
as
well
but
you're.
Basically
saying
this
person
has
privileges
to
go
outside
of
the
same
defaults.
That
crossplane
sets
for
you,
so
yeah.
I'm.
A
C
Want
to
preserve
that
separation
of
concern
and
we'd,
you
know,
even
though
it
would
be
a
standard
flag.
We
could
say
like
if
you
say
you
know,
if
we
have
like
a
value
on
the
provider
or
poll
interval
on
the
provider,
object
that
would
be
passed
through
to
the
controller
in
form
in
the
form
of
a
flag
or
an
environment
variable,
or
something
like
that.
So
you
theoretically,
could
you
know
like
someone
could
have
a
provider
where
providing
that
flag
meant?
You
know.
C
Or
something
like
it's,
not
it's
not
like
a
really
uniform
thing.
So
yeah,
that's.
D
Yeah,
I
think
like
like
I
don't
really
like,
think
about
the
flag
or
like
no,
it
is
being
a
flag
or,
like
you
know,
some
other
mechanism
to
pass
in
the
conflict,
but
for
more,
like
a
from
user's
perspective
like
if
it's
something
that
every
provider
has,
which
is
the
case,
I
guess,
like
you,
know,
every
provider,
it's
an
api
and
it's
like
you
know
it
hits
them
with
a
frequency
because,
like
they
use
manufacturer,
so
it
could
go
to
provider.
D
Provider
package
like
we're
talking
about
like
the
default
not
like,
I
think
we're
we're
all
on
the
same
page
with
provider
config
only
what
to
use
when
the
field
in
provided
conflict
isn't
supplied,
that's
kind
of
like
you
know,
either
a
provider
package
or
a
controller
config.
So
I'm
kind
of
like
a
slightly
preferring
provider,
because
that
feature
is
basically
implemented.
It
has
to
be
implemented
by
all
providers.
B
Yeah,
I
think
like
it
could
be
because
I
am
too
deep
in
the
details
here,
but
I
I
forward
dad
at
the
moment
the
the
controller
config
is
the
type
that
we
use
to
configure
provider
controllers.
I
don't
think
provider
has
any
configuration
of
a
provider
on
it
at
the
moment.
It's
really
it's
dedicated
to
configuring
how
the
provider
has
installed
the
package-
subtle
distinction.
B
B
B
Conflict
level
is
kind
of
the
happy
medium
here
we
I,
I
could
be
very
personally
easily
convinced
that
if
we
start
exposing
a
way
to
override
this
at
the
provider
conflict
level,
that
we
don't
even
need
to
expose
a
flag
at
the
provider
level
to
set
it
as
well.
To
be
honest,
I
wonder
how
many
provider
configs
typically
get
used
in
the
wild
and
if
it
would
really
be
that
interesting,
just
say
like
the
default
is
some
say
default
and
if
you
want
something
different
put
it
in.
C
Yeah,
I
think
I
think
that
sounds
good.
I
mean
we
essentially
set
the
default
right
now
with
the
manage
reconciler,
and
I
you
know
you
have
to
use
a
provider
config
always
to
contact
the
api.
So
you
know
you're
gonna
have
to
create
one
anyway,
so
setting
it
there
for
setting
it
on
the
on
the
controller
config,
it
seems
like
the
provider.
Config
is
a
good
place
for
it.
C
I
also
like
it
because
movavic
pointed
this
out
lots
of
these
apis
if
you
like,
it's
per
account
rate
limiting
so
the
provider
config,
where
you're
actually
performing
authentication
and
stuff,
while
those
could
be
the
same
account,
it
kind
of
makes
sense
to
have
isolation
at
that
level.
So
I
really
like
that
model.
Yeah.
B
So
I
think
my
my
suggestion
would
be
personally
honestly
to
to
do
the
smallest
change
possible
to
start
with
and
then
gather
feedback
on
that.
So
it
sounds
like
that
might
be
an
adjustment
on
the
provider.
Configured
not
worry
about
making
it
configurable
at
the
provider
level,
and
it
it
seems
like
probably
the
the
first
step
to
this
would
be
making
whatever
changes
we
need
to
make
to
the
external
client
or
the
external
connector
api.
For
this
I
kind
of
want
to.
I
think
it
was
a.
B
I
think
it
was
a
fail
on
my
part
to
not
have
the
external
connector
returner
struct
in
the
first
place,
because
returning
a
structure
makes
it
easy
for
us
to
add
more
stuff
that
gets
returned
without
making
breaking
ibi
changes.
B
So
I
kind
of
want
to
make
that
cut
regardless
with
this
being
a
good,
a
good
time
to
introduce
that
change,
but
that
is
a
fairly
impactful
breaking
change
to
cross
playing
runtime.
I'm
not
that
worried
about
it,
because
you
know
runtime,
you
just
you
update
to
a
new
version,
but
it's
going
to
require
every
single
controller,
all
the
code
and
all
that
kind
of
stuff
to
go
and
update
to
this.
This
new
pattern.
B
I
believe,
though,
if
we
were
to
say
that
all
external
clients
need
to
add
a
new
interface
that
they
support
a
new
method
on
their
interface.
It
would
be
the
same
same
problem
so
yeah.
I'd,
probably
start
by
rolling
out
this
external
client,
external
connector
change
and
getting
focused
on
that,
because,
obviously
some
people
could
just
choose
they
don't
want
to.
As
we
were
saying
before,
like
we
can't
really
control
or
mandate
that
people
support
certain
things
on
their
provider
conflicts,
it's
mostly
just
a
sort
of
a
convention.
D
E
In
the
previous
issue,
or
for
the
provider
gcp
there's
an
issue
that,
if
someone
installs
both
the
providers,
the
beta
and
the
version,
one
that,
if
you
try
to
keep
that
it'll,
explain
the
resource,
then
cube
cuddle
will
pick
it
for
you,
instead
of
us
having
the
control
over
the
api
group.
So
that
could
be
misleading,
but
you're.
Hovering
over
dogsrt
reminded
me
that
that
won't
be
an
issue
for
across
the
end
users
like
this,
because
trust
me,
you
should
just
go
to
the
website
rather
than.
C
Yeah
yeah,
I
noticed
I
noticed
you
pointed
that
out
which
it
is
unfortunate
that
that's
the
behavior
of
of
cube,
cto
but
yeah,
I'd,
say
I'd
say
in
this
context:
it's
annoying,
but
not
like
something
to
to
make
a
design
decision
on
here.
A
Is
this?
Oh,
it
is
this
fix
going
into
1.21
or.
E
Yeah
the
discussion
is
going
on-
it's
not
like
they
mentioned
about
the
issue
here,
but
the
issue
is
still
on.
E
A
All
right
cool,
so
those
are
the
two
items
we
had
here
for
deeper
technical
discussions.
Anything
else
then,
before
we
wrap.
A
Up
all
right,
then
we
can
go
ahead
and
adjourn
and
we
will
make
the
change
to
move
this
meeting
to
the
next
thursday
slot
ten
ish
days
from
now.
That
will
be
the
next
time
that
we
meet
and
then
we'll
obviously
we'll
be
on
slack
and
everything.
Until
then,
thanks.