►
From YouTube: 2023-04-06 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
recording
has
started-
and
this
is
the
April
6th
2023
cross
plain
community
meeting
I
will
throw
a
link
to
the
agenda
document
into
the
zoom
chat
right
now,
so
you
can
join
us
in
the
doc
there
and
add
any
topics
of
your
choosing
to
it
so
that
we
can
get
to
all
of
them
today.
The
biggest
focus
by
far
today
is
going
to
be
the
discussion
we
have
scheduled
later
on
for
the
proposal
to
break
up
large
providers
that
Nick
will
be
will
be
leading
for
us.
A
So
that's
the
big
topic
today
and
the
one
that
we'll
be
reserving
the
most
time
for
I
think
we
will
have
plenty
of
time
for
it,
there's
not
a
like
other
items
that
are
heavy
in
the
agenda,
so
we'll
get
to
that
for
sure
and
have
plenty
of
time
on
it
all
right.
So,
let's
jump
into
Milestones.
We've
got
some
patch
releases
that
went
out
recently.
We've
got
an
upcoming
Big
1.12
release,
let's
jump
into
all
of
it.
So
on
Monday
we
drove
the
1.11.3
patch
release.
A
This
was
affecting
an
issue
in
composition,
functions
for
any
early
adopters
that
have
been
trying
out
that
Alpha
feature.
There
was
a
complication
with
it
being
able
to
run
with
a
newer
versions
of
sea
run,
specifically
starting
at
1.8.
So
this
there
was
a
fix
in
here
that
sorted
that
out
in
composition.
Functions
should
generally
be
running
in
most
environments,
again,
I
haven't
heard
any
feedback
since
the
patch
release
that
that
it's
not
working
for
folks.
A
So
this
should
unblock
I,
believe
you
know
a
fair
amount
of
further
adoption
and
feedback
of
composition
functions.
So
please
do
keep
all
that
feedback
coming
and
definitely
very
grateful
for
to
Andrew.
For
that
fix
to
to
get
composition,
functions
running
again,.
A
So
that
went
out
on
one
dot,
sorry
that
1.11.3
release
went
out
on
Monday
and
we
don't
have
any
other
upcoming
patch
releases
that
are
currently
scheduled
with
the
1.12
release
coming
up
soon,
but
we
will
keep
an
eye
on
any
issues
that
come
up
or
things
that
get
fixed
and
backboarded
and
do
a
release
for
them
as
needed.
A
So
here
we
go
for
1.12,
so
we
are
pretty
close.
Now,
let's
look
at
the
community
calendar
again
just
for
a
quick
visual.
So
we
are
pretty
close
now
to
the
the
the
feature
freeze,
so
feature:
freeze
is
two
weeks
before
the
scheduled
release
that
will
be
on
April
25th,
so
on.
Tuesday
is
the
feature
freeze,
so
we're
hoping
to
get
all
outstanding,
Feature
work
or
larger
scale
items
merged
in
and
completed
by
Tuesday
and
then
a
week
following
that
is
the
code
freeze
date
where.
B
A
In
between
future
and
fees
and
code
freeze,
we,
you
know,
will
focus
on
bug,
fixes
stabilization.
You
know
getting
things
generally
working
more
smoothly
and
that
will
be
the
focus
until
the
18th
and
then
after
that,
we're
hoping
to
just
bake
it
for
one
more
week
and
then
do
the
release
on
the
25th.
A
So
we
are
in
the
last
home
stretch
here
of
just
about
two
and
a
half
weeks
left
until
the
release.
So
let's
bring
up
the
release
board
here
and
then
I
guess
Jean,
I
guess.
In
that
context
we
can
talk
about
some
of
the
features
that
your
team
is
working
on
too,
but
we'll
look
at
those
on
the
board
specifically
right.
This
probably
should
be
bigger,
I
think
all
right,
so
big
features
that
we're
being
focused
on
for
1.11.
A
Sorry
1.12
here
were
observe
only
resources,
competition,
composition,
validations
and
plugable
secret
stores
were
three
big
ones.
I
know,
Jesse
was
also
focusing
on
package
signature,
validation
and
see
what
else
were
there?
Big
big
features
that
were
in
Focus
I
think
that's
about
it
and
there's
other
bug
fixes
and
stuff,
but
those
are
the
three
or
four
main
big
features
being
focused
on
so
I,
don't
know
exactly
who
is
on
the
call
here
for
the
engineers
that
are
we're
driving
these
features
but
Jean.
A
If
you
want
to
take
these
top
three
big
features
and
kind
of
give
us
the
status
updates
that
you
had
lower
in
the
dock.
We
can
just
do
that
now.
If
you
want.
C
Yeah
so
I'll
start
with
plugable
secret
stores,
so
the
functionality
is,
is
complete,
I
actually
just
realized.
We've
put
Essie
on
the
call
here
Esky.
How
about
you
give
that
update
on
Secrets,
though,
since
you're
the
developer
behind
it.
D
Yeah
sure
so
we
have
merged
all
the
core
functionality
in
the
cross,
plane
and
cross
play
non-time
replace
repositories.
What
is
left
is
we
need
to
consume
those
changes
in
the
provider
so
that
we
can
enable
the
functionality
on
that
level.
In
addition
to
that,
we
need
some
documentation
updates
and
we
have
one
bug
in
the
scope,
so
I'm
gonna
tackle
it
in
the
next
week.
A
I
said
Esky,
so
the
updates
in
providers
I'd
like
to
consume
it
or
use
system
functionality
is
that
is
not
necessarily
tied
to
the
1.12
timeline
right
that
could
be
done
on
divider
release
timelines
on
their
own.
That's.
D
Correct,
but
we
might
need
some
additional
PRS
on
Cross,
plane
or
runtime,
so
that
we
are
not
going
to
break
providers
when
someone
enables
the
functionality,
because
we
are
going
to
introduce
some
certificates
for
Mutual
authentication,
mtls
authentication
and
those
certificates
are
going
to
be
mounted
to
Providers
and
we
are
generating
them
in
the
cross
plane
in
its
container.
So
there's
some
kind
of
dependency
and
currently
I'm
working
on
make
this
upgrade
smoother,
and
we
might
need
some
changes
on
these
episodes
as
well.
But,
as
you
said,
it's
not
fully
dependent
on
code
free
site.
A
Got
it?
Okay,
thanks
thanks
for
that
update
then
Esky
that
sounds
great
and
then
John
I
was
looking.
I
didn't
see,
Hassan
or
Philippe
on
the
call
today.
So
if
you
want
to
go
ahead
and
take
the
updates,
then
for
those
those
two
features,
then
that
sounds
good.
C
Sorry,
it
was
me
today
so
on
observing
your
resources,
we,
finally
back
to
focusing
on
that
with
external
secret
Stores.
C
You
know
wrapping
up
and
we're
busy
with
implementing
the
functionality
and
object,
and
the
next
iteration
of
our
beneficial
providers
will
come
with
the
functionality
with
with
observe
any
resource
capability
when
it
lands
in
cross-plane
and
we'll
also
be
creating
documentation
to
to
show
how
non-upject-based
providers
can
can
integrate
the
functionality
and
I
believe
the
sun
is
also
planning
on
on
implementing
it
on
one
of
the
community
providers
as
a
reference
implementation
to
show
it
there.
C
So
we're
mostly
kind
of
like
just
in
the
in
the
kind
of
like
PR
review
phase
at
the
moment
for
wrapping
up
the
functionality
here
and
we'll
likely
be
able
to
wrap
that
up
next
week
and
then
move
on
to
documentation
and
then
on
composition,
validation.
So
we've
decided
to
split
this
into
three
phases.
C
The
first
phase
was
has
already
been
been
merged
and
kind
of
like
introduces
the
web
hook
as
well
as
some
logical
validation,
and
the
second
phase
is
where
we're
implementing
schema
validation
and
that's
currently
in
progress.
We
believe
that
we
should
be
able
to
get
that
in
time
for
1.12,
but
the
third
phase
is
unlikely
going
to
to
be
able
to
to
get
in,
which
is
to
do
with
rendering
validation.
C
So
we
will
have
composition,
validation
functionality,
but
there
will
be
more
to
come
in
further
releases
down
the
down
the
pipe.
A
And
John:
do
you
know
if
there
were
follow-up
issues
that
were
open
for
the
other
phases
like,
like
you
know,
rendering
validation
stuff,
or
is
that
all
still
going
to
be
captured
or
tracked?
You
know,
as
by
this,
this
parent
here.
C
A
Got
it
okay
and
then,
from
from
a
tracking
perspective,
though,
like
the
1476
just
leaving
that
open
until
everything's
done.
C
Yeah
that
that'll
kind
of
like
be
like
the
parent
issued
for
for
this
feature
we
might
want
to
consider
you
know,
closing
it
down,
there's
still
a
bit
of
discussion.
We
we
want
to
have
around
the
the
rendered
validation
there's
a
little
bit
of
uncertainty
still
about
about
that,
but
we
we
might
consider
closing
that
issue
once
the
schema
validation
lands,
and
then
we
can
open
a
new
issue
to
track
the
further
improvements.
A
A
All
right,
then,
we
are
back
to
the
board
here.
Let's
see,
then,
if
there
are
other
issues
that
folks
want
to
mention
here,
I
was
looking
for
the
issues
that
Hassan
had
open
around
exponential
back
off.
For
you
know:
creation
creation
scenarios,
as
well
as
update
scenarios
where
those
merged
and
completed.
C
A
Status
and
creation-
okay,
that's
fantastic!
So
both
those
being
in
you
know
core
functionality
for
1.12,
and
then
I
saw
I
think
some
open
PRS
for
consuming
like
those
new
predicates,
essentially
in
other
providers
as
well.
So
that's
that's
really
good!
That
I
got
a
dress
for
1.12.
That
was
definitely
a
concerning
issue
and
I'm
really
happy
to
see
that
taken
care
of
excellent
work
Hassan
for
driving
that
if
you
watch
the
recording
later
on
otherwise.
A
Know
I
said
that
Okay
cool,
so
are
there
other
things?
Bob
I
know
you're
on
the
call
here,
I
wanted
to
get
a
quick
check
for
you.
Did
you
make
some
progress
on
these
two
like
default
value,
supports
for
policy
stuff
or
compositions.
E
You
know
it's
it's
stuff
that
I'm
just
trying
to
finish
putting
together
so
that
I
can
actually
test
it,
and
it's
just
having
the
time
to
do
it.
I'm
hoping
to
get
to
it
this
weekend,
and
you
know
if
I
make
it
great
if
I,
don't
I
won't
so
yeah
I
would
love
to
have
these
I
would
love
to
have
these?
It's
just
a
matter
of
having
the
time
to
finish
it
up.
So.
A
Yep
totally
understood
is
there
anything,
that's
like
an
obviously
a
blocker
for
you
at
this
point
Bob
besides
time
like
did
you
need
like
a
decision
or
a
feedback
on
anything
for
the
implementation,
or
is
it
it's
just
time?
Is
time?
Is
your
the
only
enemy
here.
E
Yeah
I
mean
I'm
a
little
fuzzy
on
the
implementation,
only
because
I'm
not
real
familiar
with
that
kind
of
whole
section
of
the
code.
I'm,
basically
taking
you
know,
copying
an
existing
implementation
for
something
similar
and
and
doing
the
same
things
and
kind
of
hoping
that
that's
the
right
thing
to
do.
E
I
you
know
if
I
get
to
where
I
have
something
I
may
try
to
run
it
past.
You
know
see
if
somebody
can
take
a
look
at
it.
Just
tell
me
yeah,
that's
right
or
no.
It's
not.
A
Okay,
got
it
got
it
that
makes
sense.
Okay,
then
some
something
else
I
want
to
call
out.
Then
two
more
things
I
want
to
call
out,
so
Dan
has
been
focusing
I,
don't
know
the
status
of
it,
though,
and
I
think
he
is
tied
up
right
now
and
not
on
this
call.
So
Dan
has
been
focusing
on
some
improvements
to
the
package
manager,
most
most
specifically
and
I.
A
Think
most
urgently,
as
well,
in
my
opinion,
is
the
improved
revision
resource
ownership
transition,
so
you'd
install
the
new
version
of
a
package
and
then
the
package
manager
has
to
go
through
the
effort
of
assigning
the
resources
from
one.
The
old
version
to
you
know
being
owned
by
the
new
version.
Essentially,
and
so
Dan
is
working
on
some
improvements
to
that
and
I'm
hoping
to
see
those
in
1.12
as
well,
because
I
I,
guess
I
could
say
anecdotally,
but
I.
F
A
Like
I
have
seen
a
little
bit
more
issues
coming
up
around
upgrades
and
reliability
for
those
so
I,
you
know
can't
really
speak
authoritatively
and
have
a
lot
of
data
on
that.
But
I
feel
like
this
is
something
that's
coming
up
on
the
radar
more
and
having
some
improvement
in
the
reliability
and
being
able
to
have
smooth
upgrades
very
very,
very
consistently
is
something
that
I
I
am
definitely
interested
in
as
well
Jean.
A
Did
you
hear
anything
from
Dan
about
his
his
progress
on
on
that
work
in
the
package
manager,
or
is
that
a
bit
of
a
unknown
until
we
get
a
status
from
him.
A
Cool
hey,
Chris,
Christopher
I
saw
you
came
off
mute
for
just
a
minute.
There
did
you
have
a
comment
to
make
on
the
package
manager
fix
this
as.
F
Well,
we
we
had
a
lot
of
issues
in
the
past
two
weeks
with
the
packet
manager,
for
example,
if
you're
switching
from
Community
cross
plan
to
a
universal
cross
plan
from
outbound,
because
everything
was
breaking
in
our
infrastructure.
Regarding
this
thing,
so
we
had
a
lot
of
trouble
with
this.
So
I
was
talking
with
Dan
regarding
this
issue
and
we
operated
a
lot
of
issues
in
cross-plane
and
also
in
outbound
on
universal
trust,
plane
about
this
foreign.
F
F
An
issue
with
diversion
numbers:
what
you're
configuring,
if,
for
example,
in
in
community
cross
planning
using
version
numbers
like
1,
11,
3
and
in
Universal
cross
plan,
using
something
like
one,
eleven,
three
minus
up
dot?
Three,
something
like
this
and
if
you're,
switching
between
both
everything
breaks
up
in
your
configurations,
you
have
applied
in
the
cluster
and
then
I.
Don't
know
you
have
problems
with
double
entries
in
the
lock
and
then
everything
stops.
F
Working
across
plane
stops
running
providers
in
the
cluster
and
you
need
to
fix
a
lot
of
things.
For
example,
you
need
to
fix
the
the
the
the
owner
reference
for
all
the
compositions,
something
like
this
and
you
need
to
do
this
by
hand.
So
I
think
this
is
a
critical
issue
at
the
moment,
if
you're
switching
between
them.
A
Yeah:
okay,
then,
that
that's
good
validation
then
Christopher
that
that
provides
a
bit
more
concrete
data
points
to
the
anecdotal
one.
That
I
was
feeling
myself
that
this
seems
like
more
of
a
hot
issue
than
it
has
been
in
the
past.
A
Maybe
something
that
was
driving
like
a
recent
regression
or
if
there's
just
it's
being
stressed
more
in
scenarios
that
it
hadn't
been
stressed
in
before
I'm,
not
quite
sure,
but
that
you
know
your
experience.
There
does
add
more
support
towards
the
urgency
of
addressing
and
fixing
this.
A
So
thank
you
for
sharing
that
dude
and
then
the
so
I'm
getting
a
lot
of
feedback
as
well
from
folks
in
the
community
about
environment
configs,
where
you
know
folks
have
adopted
it
they're
using
it,
and
you
know
we
there's
a
set,
there's
a
number
of
things
we
we
want
to
do
there
to
further
mature
it
and
declare
it
out
of
Alpha
and
into
beta.
A
So
there's
been
a
lot
of
discussion
recently
in
terms
of
feedback
of
like
what
should
we
do
to
mature
this
to
Beta
and
I'm
hearing
a
lot
of
Engagement,
and
you
know
desire
from
a
number
of
people
to
continue
investing
in
this
and
you
know
so
we
could
take
it.
You
know
maturity
and
then
have
it
be
reliably
dependent
upon
in
more
production
scenarios.
So
I'm
feeling
like
this
is
becoming
more
more
of
a
priority
and
like
so.
A
The
current
phase
here
is,
you
know,
decide
like
we're
discussing
and
deciding
and
Max
is
providing
his
opinions
Etc
on.
What
exactly
should
we
fix
or
invest
into
you
know,
as
we
mature
in
the
API
I
think,
there's
still
some
some
some
debate
on
behaviors
such
as
you
know,
you
make
a
change
to
it
and
does
it
get
patched
only
in
memory
or
does
it
go
back
to
a
persistent
storage
of
the
environment
config
and
what's
the
expectation
there
so
there's
more
things
to
talk
about
I.
A
Think
and
I
would
like
to
see
investments
in
this
specifically
in
the
1.13
time
frame
to
to
kind
of
take
take
a
lot
of
these
and
in
mature
environmental
things,
because
there
is
a
lot
of
Engagement
there's
a
lot
of
adoption
of
it,
and
it
does
seem
like
something.
That's
pretty
valuable.
A
A
A
You
know
it's
a
good
experience
now,
if
you
want
granularity
of
what's
being
worked
on,
what's
the
status
of
it
all
that
sort
of
stuff,
but
if
you
just
wanted
to
you
know,
come
to
the
product
project
and
see
what's
on
the
horizon,
what
are
the
big
big
Investments
that
the
community
wants
to
make
Etc
so
I'm
going
to
be
spending
some
time,
I
started
on
it
yesterday,
a
little
bit
and
I'll?
A
Do
it
I'll
follow
up
more
today,
but
this
week
I
should
see
some
in
some
improvements
into
the
releases
board
there
to
give
it
a
more
roadmap,
feel
or
roadmap
view,
so
it
could
be
used
not
only
for
more
granular
issue,
tracking
and
Milestone
tracking,
but
more
high-level
roadmap
items,
for
you
know
more
future,
looking
sort
of
things
that
will
be
available
as
well
and
so
improving
the
discoverability
of
it
too,
like
linking
to
it
from
the
main,
readme
and
stuff
like
that,
so
that
this
becomes
a
more
useful
public
roadmap
for
the
project.
A
So
you,
you
should
see
some
improvements
on
that
as
well.
Coming
up
now,
keep
in
mind
that
that
won't,
it
will
be
in
the
intent
of
it
is
to
give
an
idea
of
where
the
project
is
going,
but
not
necessarily
making
you
know
harder
commitments
on
Yep.
This
is
this
feature
is
going
to
be
available
on
this
date,
but
more
giving
visibility,
Insight
discoverability,
all
that
sort
of
stuff
into
the
direction
of
the
project
and
the
general
priority
of
of
what
the
community
thinks
is
important.
H
More
of
a
more
of
a
question
that
very
much
relates
to
what
you
just
said
about
no
specific
dates.
My
understandings,
it's
it's
kind
of
going
to
be
like
a
filter
view
of
the
current
project
board
right
to
only
show
the
really
the
the
sort
of
status
and
ordering
of
the
the
big
ticket
items
right.
So
it's
not
really
gonna
have
any
dates
attached
to
it
at
all,
is
my
understanding,
but,
but
it
will
be
kind
of
ordered
by
what
we're
playing
work
on
first
is
that
is
that
accurate.
A
Yeah
yeah,
it's
so
exactly
like
the
GitHub
projects
you
know
is:
is
functionality
is
what
I
was
intending
on
using
where
it
would
be
another
view
into
the
same
underlying
data
source?
So
you
know
it'd
be
like
a
filter.
You
go
roadmap,
View
and
you'd.
See
oh
cool.
This
is
the
you
know
the
high,
the
the
big
ticket
items
and
the
ordering
General
ordering
top
to
bottom
that
they
would
be.
A
You
know,
attacked
in
and
then
potentially
you
know
like,
because
we
do
have
Milestone
values
as
well
like
we
have
some
clarity
on
yep.
We
want
to
do
this
in
1.13,
or
this
won't
be
done
until
1.14
type
of
thing.
If
we
have
that
Clarity,
then
you
know
associating
those
Milestones
with
the
tickets,
like
we've
already
been
doing,
would
be
part
of
that
view
as
well.
A
All
right
so
I
think
we
can
move
on
then
to
provider
releases
and
such
John
I
will.
Let
you
take
away
the
all
these
provider
updates
and
performance.
Everything
like
that
I
think.
That's
a
big
thing
to
talk
about.
C
Yeah,
so,
basically,
all
the
providers
they
accept
for
for
terraform
comes
with
the
the
latest
improvements
in
in
resource
utilization
in
up
from
upchet-
and
you
know,
we've
seen
some
validation
both
from
community
members,
but
also
in
our
outbound
product
of
the
improvements
that
it's
had
and
we
I
just
want
to
make
people
aware
that
the
a
the
provider
aw032.0
had
a
an
issue
and
we
actually
pulled
it
from
the
marketplace
because
it
could
lead
to
like
a
upgrade
trap
where,
because
of
an
upstream
fix
any
of
the
resources
that
that
had
the
word
Fleet
in
it
became
fleets
because
the
pluralization
changed
due
to
the
Upstream
fix,
and
we
kind
of
like
addressed
that
by
a
release
the
patch
fix.
C
For
that.
So
don't
look
for
0.320.
It
goes
straight
to
zero
three
two
one
yeah
and
then
I
saw
Yuri
was
on
on
the
call
there
was.
There
was
a
0.6
release
for
terraform
and
also
0.70
Yuri.
Do
you
want
to
give
an
update
on
that
quickly?.
G
Yeah,
the
latest
one
was
with
a
terraformer
c
support,
so
one
of
the
priority
reform
users
were
requesting
it
to,
from
a
perspective
of
support
of
a
private
from
registry,
to
pool
the
models
from
there.
So
the
former
C
support
propagation
into
probability
from
both
subset
problem,
and
there
was
also
I
think
reconciliation.
Loop
optimization
is
a
trade
Bob.
If
I
recall
correctly
inside.
E
E
Yeah,
the
there's
a
couple
of
things
we
no
longer
run
terraform
and
net
on
every
reconciliation
we
take.
We
generate
a
check
sum
of
the
directory
that
holds
all
of
the
state
information
and
if
nothing
has
changed,
you
know
we
regenerate,
we
still
regenerate
the
module
and
all
the
the
stuff
from
the
spec.
E
But
if
nothing
has
changed
in
the
check
sum
of
that
directory,
then
we
don't
run
terraform
init,
which
saves
a
considerable
amount
of
time,
and
then
we
run
terraform
plan
as
usual
and
then
we
also
did
pull
in
the
desired
State
change
event
filter
from
What
the
discussion
earlier
that
Hassan
had
worked
on.
A
Thanks
thanks
for
those
updates,
guys
I'm
sorry
I
was
fumbling
on
my
screen
here
to
try
to
get
into.
B
A
Like
release,
notes
and
like
GitHub
is
trying
to
redirect
me
to
sign
in
the
the
SSO
stuff,
so
I
was
I'm
here.
Now,
though,
just
as
you're
finishing
the
last
last
note,
there
Bob
so
I
used
to
release,
notes
and
then
Jean
did
you
have
any
more
to
say
about
yeah?
Did
you
want
to
go
over?
Also,
the
you
know
like
sizing,
guide
and
stuff
like
that
too.
C
Yeah
I
mean
we
can
just
make
folks
aware
of
it.
You
know
we
we've
done
a
lot
of
load
testing,
obviously,
in
a
very
constrained
environment
and
it
you
know,
your
mileage
will
will
vary
in
in
production,
but
we've
we've
been
able
to
validate.
C
You
know
like
kind
of
like
north
of
25
percent
Improvement,
and
we
saw
similar
and
more
improvements
on
outbound
side,
so
we
did
want
to
put
out
a
kind
of
like
just
a
rough
sizing
guide
for
where
things
are
right
now
with
regards
to
you
know,
if
you
want
to
run
the
the
outbound
providers
and
those
those
should
be
kind
of
like
considered
minimum
requirements
to
successfully
run
those
providers.
C
C
But
you
know
any
any
kind
of
like
one
of
those
levers
that
you
pull
could
have
an
impact
on
it,
and,
and
so
we've
also
introduced
some
observability
to
allow
you
to
to
observe
the
the
object
runtime
better
to
understand.
You
know
the
impact
of
of
these
things
and
Jared.
If
you
can
go
to
the
next
tab
there
that
you
open
the
monitoring
one
we've
given
some
guidance
as
to
how
you
can
go
about
having
a
look
at
that
in
in
grafana.
A
Awesome
Sean,
so
I
think
that
this
is
really
helpful
that
you
know
not
only
are
there
performance
improvements
to
the
code
base,
but
I
think
these
artifacts
or
these
documents
here
about
you,
know
a
sizing
guide
and
how
to
monitor
and
all
that
sort
of
stuff
is
very
useful
to
accompany
those.
Those
code
changes
there
so
that
we
can
stay
ahead
of
and
be
aware
of.
You
know
issues.
A
How
we're
progressing
and
all
that
sort
of
stuff,
so
those
are
very
useful
artifacts
to
include
as
well.
A
All
right,
fantastic:
if
folks
have
other
recent
provider
releases,
I
checked
the
announcements
channel
on
the
crossband
stack,
workspace
and
I
didn't
see
any
other
ones
since
the
community
meeting,
but
do
feel
free
to
add
more
viter
releases
and
links
here
in
the
agenda
document.
If
you
have
more
all
right,
so
I
think
we
talked
through
the
big
features
here,
oh
and
then
let
me
check
the
chat,
real,
quick,
because
I
think
there's
some
activity
going
on
in
there
looks
like
Nick.
You
were
addressing
Raul's
question
there.
A
Do
we
is
there
anything
we
want
to
bring
up
for
the
broader
discussion
or
leave
it
in
in
chat.
B
I'll
decide
so
sorry,
actually,
the
the
reason
I
brought
this
up
was
because,
in
my
in
my
team,
right
A
lot
of
people
get
confused
because
we
are
kind
of
in
process
of
migrating,
our
workloads
from
the
acknas
so
controllers
to
cross
plane.
So
a
lot
of
times,
people
are
confused
that
they,
they
think
that
the
cross
plane
providers,
especially
the
community
providers,
are
just
using
the
the
as1,
the
acks
and
and
it's
the
the
cross
clean
is
just
a
wrap
around
it.
B
So
that's
why
I
just
wanted
to
confirm
and
get
some
thoughts
around
it.
H
I
can
understand
why
folks
might
think
that
we
have
back
in
the
day
collaborated
with
the
ack
team
and
the
ASO
team,
so
both
of
them
have
experimented
with
with
various
level
levels
of
success
and
helping
us
generate
cross-play
providers.
So
there
are
no
Crossway
providers
to
my
knowledge
that
that
sort
of
wrap
those
tools
as
such,
but
they
are,
in
some
cases,
generated
from
the
same
code
generation
pipelines
as
those
tools
they
like
share
a
code
gen
pipeline.
H
Basically,
but
there
is
no
crosswind
relatively
unapinated
about
how
you
build
providers
so
taking
up
bounce
official
providers,
for
example,
they
do
not
use
SDK
or
ASL
or
anything
like
that.
So
it's
not
it's
not
really
like
a
a
standard
way
to
build
providers.
B
A
All
right,
great
yeah,
thanks
for
the
good
question
there:
okay,
so
yeah!
So
then
in
the
vendor
update
section
for
upbound.
Here
we
have
these
three
features
that
that
John
already
talked
about,
and
then
you
know
we
mentioned
before
we
started
the
recording
here.
That's
a
fair
amount
of
upbounders
are
at
a
little
launch
party
today,
because
we
had
a
fairly
big
launch
for
a
a
a
SAS
offering
around
crossband
and
what
we're
doing
with
our
bound
product.
There.
A
If
you,
if
you
want
to
get
into
that
there
but
an
exciting
week
for
a
pound
for
sure
we
can
roll
that
on
into
the
community
topics
section
for
content.
So
two
two
big
things
to
mention
is
that
we
did
finish
the
security,
the
fuzzing
specifically
the
fuzzing
security
audits
with
Ada
Logics
and
the
cncf.
A
A
If
you're
interested
in
hearing
more
about
how
the
fuzzing
security
audit
went
and
also
you
know,
the
security
we're
going
to
roll
that
into
a
security,
full
security
audit
with
the
same
Folks
at
adalogics,
you
know
brokered
by
and
and
supported
by
the
cncf
and
it
starts
on
Monday.
So
more
security
stuff
will
be
coming
and
that's
only
a
good
thing
for
maturing
the
project
and
then.
A
A
very
great
blog
post
as
a
guest
author
on
the
crossplay
blog
about
combining
cross-plane
and
Vapor
together,
and
it
was
a
very
natural
fit
for
you
know:
provisioning
Resources
with
crossblane
and
then
being
able
to
discover
and
consume
them
via
Dapper
and
for
your
clients,
developer
code.
A
So
definitely
a
useful
blog
post
and
a
practical
one
there
to
kind
of
give
an
idea
of
how
those
two
projects
work
together
in
harmony
so
definitely
interesting
stuff,
and
then
we
got
a
couple
other
interesting,
new
blog
posts
as
well
for
folks
to
click
into.
A
So
let's
keep
on
rolling
then
and
yeah,
oh
yeah.
We
definitely
want
to
have
more
time
for
for
this,
so
I
just
wanted
to
make
a
quick
note
that
you
know
vault
as
a
Secret
store
option
for
cross
plain.
Has
you
know,
as
he
was
talking
about?
A
In
general,
we've
created
the
ability
for
secret
stores
to
be
pluggable
and
to
be
external
to
the
cross-plane
source
code
tree,
so
they
can
have
their
own
shipping
mechanisms
Etc
and
so
vault,
as
an
implementation
of
The
Secret
store
for
crossblade,
was
moved
to
a
new
repository
and
outside
of
the
cross-plane
code
base.
A
So
the
internal
one
has
been
deprecated
for
now
and
the
expectation
is
to
start
moving
towards
if
you're
consuming
that
feature
towards
using
the
external
debuggable
version
instead,
so
there's
a
link
here
for
more
information
on
that
you're
not
directly
affected
by
it
in
this
release,
because
we're
just
marking
it
as
deprecated
in
this
release
and
then
in
a
future
release
we'll
we'll
remove
it
as
completely
once
you
know,
we
have
some
confidence
that
folks
are
being
able
to
migrate
on,
but
more
details
can
be
found
in
this
particular
link
right
here
all
right
and
with
that
excuse
me
with
that
I'll
turn
the
floor
over
to
Nick
to
start
walking
through
the
proposal
of
breaking
up
our
providers,
and
you
know
installing
fewer
crds
and
Fielding
questions
about
that
Nick.
A
H
All
right,
let's
see
that
trading
spring
yep,
you
can
see
it
all
right.
All
right,
I,
apologies
in
advance.
Everyone
I
am
not
a
morning
person.
These
meetings
are
always
at
my
morning,
so
I'm
still
waking
up.
So
apologies.
My
brain
is
not
working
as
well
as
it
could
be.
H
I'm
going
to
assume
that
folks
are
at
least
somewhat
familiar
with
the
problems
that
we're
facing
here
and
what
the
proposal
is
it
is.
It
is
third
most
reasonable
requests
to
follow
those
three
simple
requests:
crossblade,
if
you
want
to
pull
it
up
locally,
but
the
The
quick
summary
is
as
I'm
sure
many
of
you
are
aware,
cross
plane
in
particular,
cross-plane
providers
installed
a
lot
of
crds.
They
they
add
support
for
a
lot
of
manager,
resources
and
we
do
that
by
using
kubernetes
crds.
H
This
has
caused
issues
for
people
the
the
overwhelmingly.
As
to
my
knowledge,
the
the
most
impactful
issue
has
been
performance
issues,
I
think
the
the
kubernetes
API
server
and
tools
and
the
ecosystem
in
general
was
was
sort
of
built
with
this
assumption
that
you
know
maybe
the
one
day
there'll
be
like
50
or
100
crds,
or
something
like
that.
It'll
cost
to
not.
You
know,
thousands,
which
is
what
you
can
get.
If
you
install
a
lot
of
other
providers
in
particular
the
big
ones
you
can
see.
H
Actually
you
can
actually
kind
of
see
at
this
list.
This
is
not
necessarily
ignorative.
I
might
have
missed
some,
but
by
and
large,
there's
like,
let's
say
fewer
than
10
providers
that
actually
install
a
lot
of
cids
with
many
providers
in
the
long
tail
only
installed
two
three
crds
are,
you
know,
provided
territory
or
provided
help
by
the
kubernetes
provided
SQL,
where
Etc
all
of
these
ones
have
a
small
handful
of
CID.
So
it's
not
a
problem
for
all
providers.
It's
been
in
my
mind,
Explorer
provider,
scooping.
H
So
the
primary
issue
that
folks
have
faced
is
performance
that
we've
read
a
lot
about
this
that
is
linked
from
this
design.
If
you
want
to
look
at
more
detail
about
the
the
primary
performance
impacts,
the
CPU
and
memory
contribute
the
kubernetes
API
server
when
you
load
up
a
CID
at
one
point,
it
was
taking
about
four
bag
of
memory
per
CID
I.
H
The
other
issue
that
we've
seen
is
a
one
one
thing
that
makes
that
particularly
painful
is
that
most
folks
who
are
running
on
a
cloud
for
vendors
or
Cloud
providers
managed
services
like
gke,
uks,
AKs
Etc,
don't
have
any
control
over
what
the
size
of
the
control
plane
is,
and
most
Cloud
members
do.
My
knowledge
scale
their
control
planes
on
this
axis.
So,
for
instance,
a
lot
of
cloud
providers
will
actually
behind
the
scenes.
H
They'll
start
your
kubernetes
control
playing
that
are
pretty
small
and
then,
as
you
add
nodes
and
other
well-known
signals,
that
sort
of
imply
that
indicate
that
the
cost
of
doing
more
work
or
we'll
do
more
work
is
getting
bigger.
They'll
like
give
you
bigger,
bigger
nodes
and
more
and
more
compute
for
your
control
plane.
Most
smokes
don't
do
that
for
crds
at
the
moment,
with
my
knowledge,
so
often
the
control
plane,
it
kind
of
just
doesn't
know
that
it's
getting
loaded
and
starts
to
get
killed
and
you
actually
have
like
dropouts.
H
So
you
know
you've
hit
CPU
limits,
so
the
API
7
cop
respond
to
your
requested
five
and
things
like
that.
So
the
sort
of
client-side
problems,
sorry
server-side
problems.
There
are
also
client-side
problems
that
that
really
comes
down
to
everything.
I.
Do
that
you're
loaded,
you
can
think
of
as
another
endpoint
in
rest
API.
So
you
know
V1,
slash,
AWS,
RDS
instances,
V1
AWS,
slash
eks
clusters
or
whatever.
H
So
when
you
have
all
of
those
endpoints,
there
are
some
parts
of
the
kubernetes
sort
of
client
server
communication
patterns
where
a
client
will
go
and
hit
every
one
of
those
endpoints
to
discover
what
exists
or
if
you
do
something
like
hey
Google,
give
me
all
the
managed
resources.
The
way
that
Coupe
cuddle
is
implemented
like
okay,
first
I'm,
going
to
figure
out
what
manage
resources
are
so
I'll
ask
the
API
server
hey,
what's
Spanish
for
what's
the
API,
so
it
comes
back.
H
It
says:
hey,
there's,
there's
these
2
000
different
kinds
of
energy
resource
I.
Think
we've
got
also
great
I'll.
Send
it
HTTP
requests
to
every
one
of
those
2008
points
to
ask
visit
instances,
and
then
you
know
the
clients
will
end
up
rate
limiting
themselves,
arguably
unnecessarily
and
and
that
slows
things
down
and
it
just
results
in
a
poor
user
experience.
Basically,
we've
known
about
this
problem
for
a
long
time
and
for
a
long
time
our
position
on
it
was
an
idealistic
one.
H
It
was
kubernetes
should
be
better
at
this.
Basically,
like
the
community
should
not
have
these
performance
issues,
so
we
and
others
as
well
made
quite
a
lot
of
progress
on
updating
kubernetes,
but
it
wasn't
enough.
It
wasn't
enough
to
make
the
problem
go
away,
especially
the
rate
at
which
our
resource
coverage
is
is
increasing
in
cross-plane
and
the
other
thing
that
we
found
is
just
even
you
know.
H
If
we
fix
this
problem
100
in
kubernetes
1.27,
let's
say
the
the
performance
just
go
away
it
just
it
takes
a
long
time
for
every
you
know
a
cloud
cloud
providers
have
to
like
bet
and
test
and
carefully
roll
out
the
new
versions
of
these
kubernetes
components
and
they're.
You
know.
Similarly,
their
customers
need
to
carefully
roll
about
et
cetera,
et
cetera,
so
we
regularly
hear
from
people
hey.
H
This
is
really
painful
and
I'm
still
running
kubernetes
1.24
or
something
like
that,
which
is
you
know,
a
fairly
old
version
these
days,
but
books,
you
know,
understandably
like
I,
don't
really
want
to
have
to
update
to
the
the
absolute
latest
bleeding
age,
kubernetes,
just
support
or
obviously
out
anything
cross-plate
and
a
lot
of
time.
That's
because,
of
course,
you
know.
No
one
really
wants
all
these
cities,
basically
like
we're
playing
it's
totally
crds.
H
It's
it's
arguably
like
a
clean
and
simple
model,
but
but
it's
adding
you
know
hundreds
of
cids
that
folks,
for
example,
if
you
would
still
provide
AWS
it's
about
900
and
folks
really
want,
like
you,
know,
dependent
of
those
or
something
like
that
or
20
or
30
or
50..
H
So
we
started
to
look
more
seriously
into
ways
to
the
way
I
like
to
think
of
it
is
improving
the
ratio
of
installed
to
used
cids,
so
in
in,
like
the
perfect
ratio,
is
one
to
one
cids,
just
don't
get
installed.
Unless
you
actually
intend
them,
and
then
you
know
the
the
pull
ratio
is
like
you
know,
you
want
to
manage
only
RDS
instances
and
you
install
all
the
provider
AWS,
so
you
get
like
a
900
to
1
installed
to
used
ratio.
H
The
two
solutions
that
I'm
aware
of
that
we
walked
through
that.
Could
that
could
actually
help
with
this
one
thing
that
the
community
has
sort
of
landed
on
a
meeting
to
ask
people
for
a
long
time,
which
is
this
idea
filtering
or
allowing
you
to
configure
what
types
a
particular
provider
installs
and
the
other
idea,
which
is
what
I've
been
putting
is
that
we
break
up
providers
into
to
bring
up
the
big
providers
in
the
smaller
units?
Another
idea
that
I
won't
talk
about
too
much
here
was.
H
H
So
specifically,
what
I'm
proposing
here
is
that,
basically,
we
as
a
community
take
the
biggest
providers
and
we
break
them
up
by
APA
group,
so
taking
provider
AWS
as
the
somewhat
pathological
piece
here
because
of
the
biggest
provider
with
I
believe
the
most
API
groups
provide
AWS
would
stop
being
one
provider
with
900
crds
and
don't
let
this
number
is
gave
you
too
much
would
become
150
providers
each
with
a
smaller
amount
of
crdx.
The.
H
Let
that
number
scare,
you
is
I,
think
a
lot
of
people
say
150
they're,
like
wow.
That's
a
lot
of
providers
to
install
but
keep
in
mind.
You
almost
certainly
won't
install
most
of
those
with
everyone's
saying
I.
Don't
want
these
900
CMEs.
So
therefore,
you
probably
wouldn't
want
all
150
providers
that
provide
AWS.
H
Supercar
I
ran
a
poly
survey
survey
on
the
crossblade
slack
a
couple
weeks
ago
and
also
reached
out
to
a
lot
of
upbound
sort
of
folks
that
we
know
customers
about
bound
and
things
like
that
and
based
on
those
numbers.
H
Today,
the
average
customer
and
people
by
the
average
customer
folks
run
way
more
than
this,
but
the
average
customer
or
average
cross-playing
Community
member
uses
two
providers,
so
that
might
be
like
provide
AWS
and
try
to
help
or
provide
a
Google
and
provide
a
kubernetes
or
provide
Azure
and
provide
a
terraform
right
like
it's
not
really.
We
never
really
thought
that
folks
would
just
be
running
one
provider
and
that's
it
as
best.
We
can
tell
with
the
numbers
net
worth
we've
got
so
far.
H
Under
this
proposal,
the
average
Community
member
again,
the
average
some
people
would
run
fewer,
some
people
would
run
more,
would
be
running
about
10
providers
for
Servo
instead
of
running
to
the
provider,
pods
you'd
be
running
from
10
to
provide
the
parts
basically,
and
so
because
we'd
be
breaking
this
down
on
API
Group,
which
corresponds
mostly
to
cloud
provider
Service.
You
would
imagine
that
instead
of
provide
AWS,
so
you
might
install
provided
AWS
ec2
and
provide
AWS
eks
have
a
look
at
Google,
Azure,
et
cetera,
Etc.
H
Some
of
the
concerns
that
folks
had
when
we
first
started
discussing
this
covered
in
this
design
document.
One
of
them
is
references
between
resources,
quick,
quick
version
of
that
is
I.
Think
of
it.
As
long
as
we
continue
to
build
things
from
a
lot
of
repo,
those
should
be
okay
for
the
medium
term
or
the
short
term
and
medium
term.
We've
kind
of
already
decided
that
the
way
references
work
today
across
results
references
so
like
VPC,
ID,
ref,
PPC,
ID,
select
all
that
kind
of
stuff
is
not
ideal.
H
We
would
rather,
we
would
rather
move
towards
a
more
generic
solution.
If
you
were
already
card,
for
example,
reference
from
a
terraform
provided
like
from
provided
terraform
to
provide
the
AWS
or
provider
helped
by
the
AWS
we'd
like
to
solve
that,
we
think
that
this
will
go
away.
Basically,
another
one
was
promoter
configs.
We
believe
that
all
of
these
providers
can
share
provider
config
by
taking
a
dependency
if
they
provide
a
package
of
a
config
package.
H
I'm
not
going
to
go
into
detail
on
this,
because
I
want
to
give
you
all
time
to
chat
about
this,
and
finally,
it
was
the
compute
resources.
Our
pathological
pace
for
compute
resources
are
the
about
official
providers
which
do
use
terraform
under
the
hood
and
that's
pretty
resource
intensive.
We
do
actually
think
that
there
would
be
a
non-trivial
at
least
I.
Don't
know
how
huge
it
would
be,
but
there
would
be
an
increase
in
computer
resource
usage
at
first
under
this
proposal.
H
One
of
the
reasons
we're
not
super
concerned
about
this
is
because
we
just
believe
that
there's
a
ton
of
room
for
improvement
here
and
in
fact,
these
numbers
that
I
have
here
I
believe
already
out
of
date
and
we've
already
made
more
improvements
than
what
are
captured
here.
So
we're
not
too
concerned
about
this,
because
we
just
have
only
just
got
involved
by
just
provider
performance
at
a
compute
usage.
H
Part
of
the
reason
that
I'm
I'm
part
of
the
reason
that
I'm
proposing
bringing
up
providers
rather
than
filtering
is
that
I
believe
it
is
the
conceptually
simpler
thing,
especially
if
I
try
to
imagine
the
perspective
of
somewhat
new
to
the
cross-plating
community.
I
think
filtering
makes
a
lot
of
sense
to
people
who
are
already
advanced
in
power
users
who
are
running
these
providers
in
order
to
get
used
across
like
working
in
a
certain
way
and
have
a
problem
and
just
want
to
solve
it.
H
Some
of
the
challenges
that
we
get
with
with
CID
filtering
is
that
it
has
to
be
as
far
as
I
can
help,
and
you
know:
I've
been
working,
I've
been
like
leading
the
architecture
contract
for
four
years,
so
I'm
fairly.
Confident
in
my
assessment,
as
far
as
I
can
tell
you
would
have
to
build
filtering
into
both
across
plane
and
every
provider
that
wanted
to
support
adultery,
which,
to
start
with,
has
some
weird
things
of
like
quite
a
terrible.
H
H
Cross-Played
would
have
to
effectively
ask
providers
if
they
support
filtering
and
then
act
differently,
whether
you
know
you
basically,
otherwise
you
would
end
up
in
a
situation
where
you'd
be
like
hey.
Please
build
this
provider.
I,
don't
know
what
filtering
is
I'm
just
going
to
install
everything
which
is
not
a
great
user
experience.
H
I
believe
that
filtering
would
fundamentally
have
to
be
an
opt-in
system.
So
a
lot
of
folks
are
sort
of
saying.
Well,
filtering
could
be
opted
out.
Sorry
I
see,
there's
a
lot
having
a
chat
I'm
not
watching
about
some
people,
we'll
check
that
in
a
second
I'll,
stop
talking
in
a
second
as
well.
H
There
was
initially
this
idea
of
pig
provider
AWS,
for
example
the
default
Behavior
provider.
Alias
could
be
as
it
is
today
it
installs
900
crds,
and
then
you
can
actually
filter
it
down.
I
I,
don't
think
that's
a
great
user
experience,
because
Justin's
only
provide
the
AWS
will
break
a
small
class
database,
so
I
don't
think
the
default
experience
should
be.
If
you
don't
know
about
filtering
and
don't
opt
into
doing
filtering,
then
your
cost
of
breaks
so
I
do
think.
H
We'd
have
to
start
to
get
clever
to
basically
switch
from
all
things
being
enabled
by
default
to
All
Things
actually
being
off
by
default
and
having
you
opted,
and
for
that
to
not
be
a
breaking
change,
we
have
to
add
a
lot
of
intelligence
to
go
and
try
and
figure
out.
Okay.
What
are
you
actually
running
today?
Let's
automatically
enable
those
types.
What
do
your
configuration?
What
does
your
configuration
to
use?
Let's
enable
those
types
Etc
I
I?
H
An
interesting
thought
exercise
for
me
is
that
when
I
try
and
describe
the
to
approach
it
as
I
think
possible,
describing
how
filtering
Works
takes
like
five
sentences,
we're
describing
outbreaker
providers
works
or
something
like
that.
I
do
want
to
mention
as
well
and
I.
I,
don't
know
Chris
Farr
on
the
call
here
and
has
a
good
perspective
on
this
performance.
Isn't
the
only
reason
that
we've
heard
folks
want
to
break
up
providers.
I
can
say
three
reasons:
I've
heard
and
I'd
love
it.
H
If
we
could,
let
me
know
if
there
are
other
reasons
that
I've
forgotten
or
that
that
I'm
not
aware
of
yet
former
seems
to
be
overwhelmingly
the
big
one.
I
say
the
second
most
one
is
the
second
second,
most
prominent
reason
is
security
concerned
or
auditing
or
folks
who
effectively
want
to
turn
off
crds
as
a
defective
mechanism.
The
the
you
know,
remove
capabilities
from
providers
and
then
the
third
reason
is
is
a
little
bit
more
hazy.
H
H
All
right
cool,
so
so
I've
only
had
a
chance
I'd
be
reaching
out
to
folks.
That
I
know
have
been
affected
by
this
and
what
I
the
pattern
I
heard
so
far.
Basically,
is
that
folks
who
really
care
mostly
about
performance
or
we
were
just
like
I?
You
know
the
performance
impact
is
a
problem
seemed
to
be
feeling
pretty
good
about
about
this
proposal,
which
we
probably
will
eliminate
performance
problems.
H
H
Really
want
sort
of
really
fine-grained
control
over
what
types
are
enabled
I
believe
in
the
past,
you've
told
me
that's
basically
for
a
security
auditing.
Is
that
correct?
Is
there
any
other
I'm
gonna
read
them
there.
F
Yeah
that's
correct
and
we
can
have
a
talk
afterwards
regarding
this
I
have
a
few
answers
from
our
security
department
about
this
yeah.
That's
good.
H
Cool
all
right:
well,
let's
continue
and
I'll
get
a
chance
to
talk
about
one
later
Let's.
Let's
that's
a
good
idea:
let's
hold
that
and
I'll
open
the
stadium.
What
do
folks
think?
Does
anyone
love?
This
proposal
hate
this
proposal?
Any
any
questions.
F
If
you
want
I
can
add
something
so
I
I
added
overall
in
the
conversation,
some
thoughts
about
me
and
we
had
a
talk
today
in
our
club,
engineer
team
and
one
thing
we
we
talked
about
what
happened
if
we,
for
example,
splitting
the
big
groups
so
like
ec2
from
AWS,
compute,
gcp
and
networking
Azure,
also
and
different
providers,
because
at
the
moment
you
see
there
are
these
are
the
biggest
groups
so
like
100
crds
and
if
you're
splitting
them
again.
F
So
like
provider,
AWS,
ec2,
Transit,
Gateway,
ec2,
VPC,
something
like
this,
then
you
you
can
move
a
lot
of
crds
out.
You
know
because
normally
in
in
AWS
people
using
I,
don't
know
Transit,
Gateway
or
VPC
peering,
stuff
and
so
on,
and
you
can
filter
more
more
things
out.
If
so,
not
filtering,
but
you
can.
You
can
put
a
lot
of
things
back.
You
know
from
the
crd
perspective,
if
you're
splitting
also
the
big
big
group.
H
H
Didn't
mention
that
in
design,
but
it
is
something
that
we
talked
about:
I'm,
not
I,
I,
don't
personally
feel
super
strongly
for
it.
I'd
like
to
get
a
better
understanding
of.
Oh.
Let
me
put
it
this
way,
I'm
fairly,
confident
that
even
with
those
groups
being
large
each
of
the
groups
named
or
so
so,
one
of
the
one
of
the
issues.
H
What
we're
talking
about
just
for
everyone
is
that
each
of
the
biggest
three
Cloud
providers
have
sort
of
like
a
really
big
leaky
group
service,
so
ec2
in
AWS
maps
to
about
100
different
resources.
Google
has
a
similar
one
called
compute
and
Azure
has
one
called
networking
and
they're
all
about
100
resources.
H
I
I
think
for
purely
performance
reasons.
As
far
as
I
can
tell,
even
if
you
install
those
big
three
liquids,
so
the
number
I've
been
throwing
out
there,
which
is
not
a
very
exciting
number
and
I-
think
it's
actually
pretty
conservative
but
I'm,
saying
that
folks
will
start
seeing
issues
at
around
500
crds
installed
and
obviously
across
point
is
not
the
only
thing
that
drops
in
CID
there's
a
list
in
the
design
dock
of
a
couple
of
other
different
tools.
So
you
can
kind
of
wear
it
see
there.
H
You
go
like
cross
play
by
itself
without
provides
about
12.
I'll,
be
good
at
ASO
about
200.
Each
Kubota
well
always
do
with
14
I'm
sure,
there's
other
things,
and
it's
not
like
an
order
of
like
10
crds
we're
running
through
some
of
these
numbers.
I
tried
like
one
of
the
ones.
That's
somewhat
of
a
a
really
sort
of
pathological
concerning
case
would
be
doing
anything
multi-cloud
that
depends
on
these
big
three
providers.
H
So
at
that
point,
you've
got
to
install
the
Azure
networking,
AWS
PC,
to
add
to
Google
compute
sort
of
core
things,
and
that
gets
you
to
300
studies
kind
of
at
that
base.
H
But
then
you
know,
if
you
take
the
500
number,
where
things
get
wrong,
they
can
see
200
more
crds
that
you
can
go
and
install
before
you're
bumping
up
on
that,
like
very
conservative
number
that
I've
that
I'm
interesting
so
I,
actually
one
one
thing
we
could
look
at
is
potentially
in
future
keeping
that
as
another
Knob,
basically
breaking
up
those
big
things.
If
it
actually
pick
up,
the
problem
of
people
are
starting
to
pop
up
with
these
numbers.
H
Another
thing
that
I'm
sort
of
factoring
in
here
is
that
again,
this
very
conservative
500
number
is
today
and
work
on
fixing
the
performance
problems
that
we
see
is
not
going
to
stop
and
it
has
not
stopped.
We
expect
the
kubernetes
1.7
is
going
to
be
much
better
than
1.26,
for
example,
but
for
these
performance
issues,
because
there's
Folks
at
Google
or
the
folks
elsewhere,
who
are
slowly
chipping
away
at
these.
H
If
we
do
need
to
bring
the
security
issues
and
just
go,
we
could
break
them
up
further,
but
where
my
mind
starts
to
go
in
well,
if,
if,
ultimately,
what
folks
really
want
for
security?
Is
this
like
super
tight
granular
like
I,
really
don't
want
any
type
install
that
I'm
not
using,
then
maybe
there
are
other
options.
I
know
folks,
like
like
Chris
and
his
team,
already
kind
of
build
custom
builds
and
providers
and
when
I,
like
I'm,
not
I,
have
degree
in
security
but
I'm,
not
a
security
expert.
H
What
I
think
about
this
I'm
like
well,
maybe
I'd
like
the
code
to
not
be
there
at
all.
So
maybe
it
is
actually
better
to
like
build
my
own
custom
provider
than
just
her
office
crd
and
still
know
that
the
controller
code
is
is
kind
of
fire
there.
So
I
guess
what
I'm
saying.
Maybe
there's
there's
other
compromise
we
could
go
for
here,
but
I'm
also
at
the
same
time,
I.
Don't
think
it's
a
bad
idea
to
break
them
up
further.
It's
it's
not
off
the
tablet.
F
A
Real
quick
too,
because
there's
only
three
minutes
left.
So
if
you
have
a
comment
you
go,
you
definitely
go
ahead
and
grab
it,
but
I
wanted
to
make
sure
that
we're
winding
down
here
as
we're
getting
to
the
end
of.
C
The
session
I
think
the
Crux
of
The
Proposal
is
that
breaking
up
providers
means
we
can
keep
core
cross-plane
as
simple
as
possible
and
focused
on
its
its
core
Mission.
You
know
like
the
this
proposal.
Essentially,
you
know
pushes
the
problem
to
the
packet
to
the
to
the
providers.
You
know
to
package
yourself
in
a
way
that
that
is
smaller
and
simpler
to
consume
and
I
I
fully
agree
with
that.
I
think
you
know.
Like
the
filtering
approach,
you
know,
we've
had
a
lot
of
discussions
in
Germany
here.
C
There's
a
lot
of
implications
around
that
introduces
a
lot
more
complexity
to
to
cross
clean
that
needs
to
maintain
in
the
core
framework.
So
this
might
seem
like
the
less
ideal
solution
for
folks
who
want
that
one-to-one
ratio
of
of
installed
versus
used
but
I
think
it's
the
most
pragmatic
one
considering
everything.
H
I
will
say
that
that's
true,
like
I,
do
think
that
this
keeps
cross-playing
a
simpler
system,
but
I,
but
I
do
want
to
stress
I'm,
not
pushing
this,
because
I
think
it's
easier
for
cross-plate
maintainers
at
the
expense
of
the
community
or
anything
like
that.
I
actually
think
that
this
is
the
simplest
system
for
someone
who's
new
to
cross-player.
To
reason
about
in
in
the
first
place,
one
one
sort
of
test
to
that
is
there
aren't
any
new
Concepts
in
this
proposal.
H
If,
today,
if
someone's
using
the
cross-plated
community,
you
effectively
say
you
know,
install
the
install
the
providers
that
you
want
and
then
start
building
compositions
and
claims
and
all
that
kind
of
stuff
using
those
providers
and
under
this
proposal
let's
say
you
know,
the
world
has
changed
in
six
months
and
we've
done
this,
and
someone
comes
to
you
to
the
crosswind
community.
It's
the
same
thing.
H
We
say
install
the
providers
that
you
want
and
then
start
using
claims,
there's
no
install
the
providers
that
you
want
and
then,
if
the
providers
support
filtering,
make
sure
to
filter
appropriately
et
cetera,
et
cetera,
et
cetera.
What
what
sort
of
explaining
to
them
I
one
one
thing
that
is
still
a
bit
of
an
unknown
to
me
is
we.
We
have
obviously
very
strong
signal
that
people
care
about
this
problem
of
installing
fewer
providers,
but
we
don't
yet
have
a
great
sort
of
bucketing
of
the.
H
Why
so
I
think
I'll
feel
very
good
about
this
proposal.
If
you
know
the
majority
of
people
are
like,
oh
yeah,
you
know,
90
plus
percent
of
the
folks
are
like
yeah.
We
can't
really
just
perform
those
problems,
and
this
solves
that
if,
if
we
dig
a
little
deeper
and
it
turns
out,
it's
like
you
know,
60
40
or
40
of
the
people
actually
have
like
auditing
your
security
concerns.
It
would
like
really
really
really
need
to
not
have
pipes,
it's
all
that
they
don't
use.
H
Then
you
know
we
may
have
to
go
back
to
majority
board
here,
but
I
I.
Definitely
like
again.
This
is
the
maybe
the
other
folks
who,
but
maybe
this
is
something
that
Chris
and
I
should
just
talk
about
because
again
easier.
The
folks
that
I
talked
to
who,
who
really
has
detailed
answers
about
this,
but
where
I
tend
to
go
when
people
talk
about
sort
of
turning
official
security
purposes,
and
what
that
is
is
that
is
that
something
that
other
tools
do?
H
F
G
F
A
interesting
top
with
the
security
guys
today
regarding
this
because
you,
you
asked
this
question
and
the
question
was:
is
cross
play
now
built
for
kubernetes
things
or
is
cross
plan
built
for
external
API
things
you
know,
and
then
they
start
arguing
like
okay.
Then
we
not
wanted
to
talk
about
other
controllers
in
the
kubernetes
universe
because
they
are
built
for
kubernetes
resources.
You
know,
and
cross-plan
is
a
little
bit
different
from
the
security
perspective,
because
you
are
managing
resources
in
other
apis
or
in
other
clouds.
F
H
I
thought
that
might
be
the
case
and
I
kind
of
get
that,
but
arguably
kubernetes
is
going
and
you
know
running
a
container
on
something
in
your
Cloud
most
likely
and
it's
setting
up
a
service
and
a
load
balancer
most
likely
like
a
lot
of
operators
do
go
in
towards
the
cloud
that
aren't
displayed
so
I
I,
I,
I,
I,
I
kind
of
get
it,
but
also
I
push
back
a
little
bit.
I
think.
H
A
All
right
sweet,
so
we're
a
little
bit
over
time
now
so
I
kind
of
I
want
to
wrap
things
up
here,
so
their
this
proposal
is,
you
know,
open
right
now,
and
so
you
know
this
is
a
really
good
opportunity
to.
You
know
talk
to
Nick
the
author
of
The
Proposal
get
some
of
these
questions
answered
start
the
discussion
going
Harris
in
a
synchronous
fashion,
but
there
is
an
opportunity
you
know
for
for
a
bit
still
for
async
discussion
as
well
on
the
proposal.
A
So
if
you
have
comments
and
more
questions
and
stuff,
please
do
add
them
to
the
proposal.
That's
Linked
In
the
agenda
document.
It's
pull
request,
3939,
so
easy
enough
to
remember,
and
we
can
certainly
keep
the
discussion
going
there
as
well.
Bob
you
had
another
agenda
item
about.
Is
it
possible
to
decouple
package
dependencies
from
a
specific
registry?
Is
that
something
that
can
wait
till
next
community
meeting
or
we
can
keep
going
on
on
an
async
fashion
until
then?
Or
how
do
you
feel
about
that?.
E
A
I'll
put
it
on
the
backlog.
That
is
the
first
topic
there.
H
I
I
just
wanted
to
mention
on
the
on
the
sort
of
breaking
up
providers
proposal.
I
am
talking
to
a
bunch
of
folks
one-on-one
about
this.
If
I
haven't
reached
out
to
you
already
and
or
your
team
already,
and
you
are
feeling
pain
from
this
I
have
to
like,
if
you
prefer,
a
high
bet
with
conversation
with
me,
do
reach
out
and
I'll
try
and
make
it
work
out
and
I'm
out
a
lot
of
next
week.
But
I'll
do
my
best
to
set
up
a
call
with
you.
A
Awesome
Nick
yeah,
thanks
for
making
yourself
accessible
then
for
from
our
discussions
and
I
definitely
appreciate
the
way
that
we're
you
know
trying
to
socialize
this
discuss
this
listen
to
things
and
make
a
good
decision
here.
So
you
have
a
great
proposal
as
well.
Nick
you
know,
as
usual,
great
write-up
and
very
you
know,
thought
through
a
lot
of
the
the
cases
here.
So
this
has
been
really
good
and
thanks
for
sharing
this
with
us
all
right.
So
with
that,
let's
go
ahead
and
adjourn.
A
Let's
go
ahead
and
wrap
up
for
the
week
here
and
we
will
meet
again,
I
think
right
before
the
release
for
for
on
April
25th.
So
we
will
see
you
all.
Hopefully
some
of
you
in
Amsterdam
as
well
and
see
you
all
in
person
and
hang
out
at
kubecon
all
right
take
care.
Everybody.