►
From YouTube: 2021-12-16 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
december
16th
2021
cross,
plane
community
meeting,
so
we
can
jump
on
in
here.
I
don't
think
there's
a
ton
of
agenda
today,
but
we'll
dive
right
on
into
it.
A
So
first
thing
to
notice
here
is
that
for
v
1.6,
which
is
the
scheduled
upcoming
next
release
of
crossplane,
is
that
we
did
make
a
decision
to
postpone
that
until
after
the
holidays,
the
regularly
scheduled
release
was
for
sometime
next
week
when
there
will
be
a
lot
of
folks
in
the
community,
just
not
around
for
kind
of
a
holiday
quiet
period
there.
So
you
know
we're
encouraging
folks
to
take
time
away,
take
time
off,
be
with
families
and
regroup,
etc
or
whatever
you
need.
A
You
know
for
for
your
own
personal
choices,
and
so
we
will
pick
up
the
release
again
first
thing
into
the
new
year,
so
on
tuesday
january
4th
we
will
be
running
that
release
the
1.6
release.
Branch
has
already
been
created,
and
so
you
know
it
is
in
a
code
freeze,
state
there,
where
we
won't
be
taking
new
features,
functionality
or
complicated
changes,
but
critical
bug
fixes
and
maybe
documentation
fixes
and
things
like
that
are
still
on
the
table
for
the
1.6
branch.
A
So
that
means
that
the
main
branch
is
open
for
changes
working
towards
1.7,
so
main
is
open
and
ready
to
go
and
1.6
is
stabilizing
and
baking
right
now.
So
I
added
a
few
things.
I
noticed
that
we
weren't
doing
a
fantastic
job
of
keeping
the
1.6
project
board
open.
So
I
went
through
the
commits
from
for
the
1.6
branch
and
added
in
some
of
the
fixes
and
features
and
functionality
there.
A
One
of
the
big,
probably
bigger
things
to
call
out
there
is
a
the
focus
on
performance
that
nick
had
been
doing
and
and
others
as
well
for
for
crossband
in
general,
and
so
that
would
be
an
ongoing
theme,
but
there
were
definitely
some
performance
enhancements
and
improvements
that
you'll
be
seeing.
For
you
know,
reconciliation
and
and
being
able
to
you
know,
speed
up
and
parallelize
some
of
the
operations
there.
A
I
don't
think
that
any
of
these
issues
are
blocking
we're
we're
you
know,
provider
partitioning
sharding,
private
configs
is
definitely
not
included
in
1.6
the
proposal
around
the
provider.
Runtime
interface,
you
know,
that's
not
something.
That's
shipping
1.6
and
I
think
the
other
ones
here
are
small
ones
this
one's
docks
only
so
I
don't
think
that
any
of
these
will
block
the
release.
A
It'd
be
nice
to
get
some
of
these
stocks
fixes
in,
but
I
don't
think
that
there's
major
things
that
I'm
aware
of
that
are
still
blocking
the
release.
Anybody
out
there
have
big
things
to
mention
for
1.6
concerns,
blockers
obstacles.
Anything
to
call
out
here.
A
All
right
that
it
looks
like
we're
we'll
be
just
baking
in
the
1.6
branch,
then
over
the
holidays
and
yeah.
We
will
be
working
on
that
release
first
thing
in
the
new
year,
then.
A
All
right,
let's,
let's
take
an
opportunity
here,
then
to
go
ahead
and
just
bring
up
the
road
map,
then,
while
we're
at
it.
A
So
I
think
in
the
in
the
new
year
here.
I
think
that
we're
going
to
be
getting
some
focus
on
some
of
these
pretty
interesting
features
and
functionality
that
will
be
big
enhancements
for
the
project.
So
hassan
did
some
really
good
work
on
the
plugable
secret
store
being
able
to
use
alternative
stores
like
vault
for
for
storing
secrets
and
credentials
with
crossplane.
That
design
document
is,
I
think,
converging
and
getting
pretty
close
to
being
ratified
hassan.
Do
you
want
to
give
us
a
quick
update
on
on
where
that
is.
B
Yeah
sure
so
my
current
target
is
to
get
it
merged
until
end
of
year.
So
this
is
what
I'm
like
pushing
for
a
and
the
good
news
is
like
yesterday,
the
pr
is
approved
by
nick.
There
are
only
like
couple
of
nits
that
that
I
need
to
like
fix,
and
I
I
believe
it
will
be
merged
very
soon,
and
then
we
can
just
start
the
implementation
part.
C
Big
shout
out
to
hassan
the
the
major
delay
on
this
has
been
my
review
cycles,
not
hassan
in
any
way,
so
definitely
looking
forward
to
getting
that
merged
and
happy
to
merge
with
whatever
you
want.
A
Yeah,
that's
great,
I'm
glad
that
the
experience
there
has
converged
and
people
are
feeling
pretty
good
about
it,
and
I
think
it's
going
to
be
the
feature
itself
is
is
quite
powerful,
but
I
think
the
experience
around
it
is
I'm
happy
where
it's
landing,
also
so
great
great
work
on
that
for
sure
nick,
I
think
you
you
might
have
joined
while
I
was
talking
about
some
of
the
performance
work.
That's
something
that's
kind
of
big
on
the
roadmap.
A
Also,
do
you
want
to
kind
of
give
us
an
update
about
maybe
what's
in
1.6,
but
then
also
some
of
the
future
upcoming
things
that
we'll
be
spending
time
on
still
with
the
scalability
and
performance
related
stuff.
C
C
Let
me
swap
that
back
into
my
mind,
so
broadly
the
the
most
impactful
performance
changes
were
merged
into
crossblade,
core
1.6,
and
this
a
lot
of
it
just
has
to
do
with
performance
and
fairness
regarding
how
we
cue
reconciles
in
crossplay
cosplaying
core
now
has
a
configurable
amount
of
concurrency,
so
you
can
have
it
be,
reconciling
more
things
at
once,
if
you
would
like
to
the
default
and
the
sweet
spot
in.
C
C
So
I
believe
my
testing,
which
did
involve
having
the
scalability
changes
the
first
passive
scalability
changes
in
both
crossplane
and
the
providers.
It
was
orchestrating
brought
down,
in
some
cases,
time
for
a
hundred
a
burst
of
100
resources
to
become
ready
for
a
hundred
composite
resources,
fairly
complex
competent
resources.
Composing
like
three
managed
resources,
writing
secret.
A
lot
of
rights
to
the
kubernetes
api
took
the
time
for
them
to
be
ready
off
the
top
of
my
head.
C
I
want
to
say
from
something
like
18
minutes
to
like
30
seconds
or
something
like
that
for
a
for
a
burst
of
a
hundred,
I'm
sorry
for
100
about
three
minutes
for
them
all
to
become
ready
and
scales
up
to
like
bursts
of
a
thousand,
so
you
can
have
like
10
000
things
in
the
api
server
being
reconciled
fairly
fairly
easily.
Now
it
just
gets
like
a
little
bit
slower,
but
nothing
too
unmanageable.
C
The
the
big
delay
here
honestly
is
that
all
providers
need
to
be
updated
with
the
same
updates,
I'm
probably
personally
not
going
to
do
literally
every
single
provider,
but
I
would
like
to
get
the
generator
providers
updated.
The
big
three
aws,
google
and
azure
and
just
rolling
those
out
is
just
a
very
laborious,
labor
intensive
manual
process.
So
I
kind
of
have
draft
prs
open
for
all
those
that
I'm
going
to
keep
chipping
away
at
in
the
in
the
new
year.
A
Hey
nick
and
then
something
I
think
I
might
have
missed
in
that
was
so
you
know
the
some
of
the
like.
You
know
max,
reconciles
or
or
whatever
the
field
was
is
exposed
now
does
do
in
order
to
take
advantage
of
the
performance
benefits.
Do
folks
have
to
explicitly
set
a
configuration
value
or
is
it
you
know,
do
nothing
and
you
get
the
benefits
without
having
to
do
anything
explicitly.
D
C
It
is
exposed
as
a
norm,
and
I
did
some
testing
and,
as
I
say,
like
the
the
best
value
for
that
knob,
which
actually
could
just
it's
exposed
as
like
how
many
rectangles
per
second
do
you
want,
but
if
we
actually
found
that
out
to
a
lot
of
other
things
like
how
much
client
side
rate
limiting,
do
we
do
what
concurrency
is
allowed
and
also
how
many
cells
per
second
do
you
want?
C
We
also
wrote
a
unusual
controller
runtime
patent
for
reconciling
because
the
default
rate
limiting
or
reconciles
you
control,
the
runtime
doesn't
actually
record
so
it
doesn't
actually
limit
every
reconcile.
The
rate
limits
only
error,
only
certain
cases
anyway,
we
tested
anything
from
1
to
100.
On
that
knob
I
think
and
10
seems
to
be
the
sweet
spot.
You
don't
really
get
a
lot
more
performance
in
my
setup.
You
know
which
wasn't
expensive.
I
didn't
get
a
lot
of
gains
after
10,
so
I
set
it
at
10.
A
C
Yeah,
but
just
expect
it
to
be
slow
to
unless
anyone
wants
to
volunteer
to
help
out.
It's
just
me
rolling
these
things
out
and
it's
it's
like
it's
updating,
every
single
controller
and
all
these
things
to
have
this
pattern.
So
it's
probably
not
going
to
happen
super
quickly,
but
I
will
chip
away
in
my
spare
time
for
the
for
the
providers.
A
Nice
yeah
thanks
for
the
note
nick
and
then
I
think
also
there
is
a
desire
and
maybe
perhaps
more
priority
as
well
from
community
feedback
and
just
general
discussion.
We've
seen
in
the
ecosystem.
Around
crossplane
is
around
custom
compositions.
So
that
may
be
something
that
I'm
feeling
a
little
bit
more
of
a
sense
of
prioritization
or
urgency
for
that
one
to
you
know,
drastically
expand
the
I
guess:
functionality
and
surface
area
that
the
composition
machinery
is
capable
of.
A
So
I
think
nick,
if
you
want
to
add
another
comment
on
that,
but
maybe
not
nothing,
maybe
there's
nothing
beyond
that.
Hey.
We
think
that's
a
priority
that
we
want
to
address
in
the
and
then
next
year
really.
C
Yeah,
I'm
personally
eager
to
work
on
it,
I'm
slightly
guilty
because
I
do
want
to
get
those
performance
things
out
as
well.
I
don't
want
to
start
working
on
something
bigger
new
before
finishing
the
old
one,
I'm
personally
eager
to
get
a
get
a
more
of
a
fleshed
out
design
on
that
out
and
I'm
personally
going
to
have
more
bandwidth.
Hopefully,
we've
we've
hide
some
folks
that
are
bound.
So
I
have
a
bit
more
focus.
I
can
get
back
to
some
more
work,
I've
cosplayed!
C
A
Like
basically
is
my
first
thing
of
q1
well,
I
think
that
would
have
a
lot
of
benefits
and
then
I'm
also
hearing
a
lot
of
talk
and
discussion
and
feedback
too
of
you
know
better
integration
with
argo,
where
you
know
they're
like
conflicts
between
ownership
or
you
know,
status,
etc
of
how
argo
is
expecting
to
see
objects
and
how
crossblank
treats
them.
That
seems
to
be
coming
up
more
and
more
recently
within
the
community
as
well.
A
So
that's,
it
seems
like
something
that
priority
on
that
would
be
pretty
might
be
useful.
Also.
C
A
Should
we
add
that
I
it's
not
almost
yeah,
I
didn't
see
it
on
the
on
the
list
here
and
I
didn't
yeah
if
you,
if
you
want
to
go
ahead
and
put
it
on
roadmap,
I
think
that's
pretty.
That's
warranted
for
sure.
For
from
my
perspective,
I
know
victor
might
appreciate
that
as
well.
C
Yeah
with
regards
to
folks
to
work
on
it,
I
personally
have
to
say
I
really
don't
use
argo
cd,
that
much
no
dislike
for
everything
I
just
haven't
had
much
use
to
to
use
it
myself.
So
definitely,
if
there's
anyone
out
there
who
feels
like
they've,
got
a
strong
understanding
of
argo
cd
and
a
strong
understanding
of
crossplane
and
have
worked
on
cosplay
before
then.
That
would
be
an
ideal
candidate
to
to
work
on
this.
E
So
I
can
add
something
so
for
us,
we
are
using
very
extensively
flux
and
there
is
one
open
issue
in
cross
plane
for
case
status
that
we
so
that
flux
can
check
the
status
of
all
of
the
objects.
Is
this
also
something
you
want
to
focus
on?
If
you
looking
for
argo.
C
You
know
one
thing
that
that
does
bring
to
mind
is
that
effectively
yeah
part
of
the
problem
with
argo,
I
believe,
is
that
it
doesn't
have
any
concept
of
like
the
key
status.
I
believe,
if
I
understand
correctly
from
from
the
issue
that
was
raised
for
flux
there
is
this.
This
whole
case
standard
that
I'm
not
sure
how
well
adopted
it
is,
but
before
the
end
of
the
day,
it
kind
of
boils
down
to
if
there's
a
ready
status.
F
C
D
There
are
actually
two
two
issues,
at
least
that
I
know
of
one
is
the
status
you're
mentioning
which
I'm
guessing
is
a
smaller
issue.
The
bigger
one
is
that
it
we
cannot
use
claims
with
argo
cd
yeah.
So
now
I'm
curious.
Whoever
spoke
before
you
you're
using
flux.
Did
you?
Are
you
using
flux
with
claims
or
compositions?
I'm
just
trying
to
figure
out
whether
it's
the
same
problem
affecting
both.
E
Yes,
it's
it's
the
same
at
the
end,
because
I
know
the
guys
from
essentia
they're
using
argo,
we're
using
flux
and
at
the
end
we
have
the
same
problems
under
the
hood.
D
G
Can
you
guys
hi
sorry,
I'm
matt
first
time
I'm
joined
in
the
meeting
here
we
use
argo
heavily
and
we're
just
beginning
to
investigate
cross
plane.
Can
someone
describe
the
problem
with
the
claims
like
I
understand
the
status
issue
like
telling
figuring
out
how
to
tell
argo
that
a
resource
is,
is
ready
or
not.
I
get
that
one,
but
the
other
issue
I'm
unclear
on.
D
Yeah,
so
my
understanding
and
I
might
be
wrong-
is
that
when
you
create
a
claim,
a
claim
creates.
D
Creates
resources
that
are
not
children
of
that
claim
and
but
of
the
argosy
application
or
argo
city
things
that
it's
on
the
same
level
as
the
claim
says,
hey
you
never
defined
the
things
that
claim
created.
Therefore,
I'm
going
to
delete
it
and
the
only
way
to
avoid
it
is
to
prevent
targo
city
from
truncating
things,
which
is
on
the
long
run,
creates
other
problems.
D
So
basically,
I
think
it's
mostly
the
the
problem
of
hierarchy.
Targo
city
will
delete
everything
that
is
not
directly
specified
in
argos
city
application
or
a
child
of
that
something.
G
Oh,
so
I
have
seen
situations
where
a
you
know
resource
we
call
it.
A
meta
resource
is
created
and
that's
defined
in
your
in
your
helm.
Chart
and
argo
creates
the
meta
resource
and
then
that
meta
resource
tells
a
controller
to
create.
You
know
some
some
sort
of
sub
resource,
and
if
the
sub
resource
is
created
with
the
same
annotations
as
the
parent
meta
resource,
then
argo
is
what
happens.
G
Is
argo
believes
that
it
created
that
resource
and
that
that
resource
is
no
longer
defined
and
therefore
that
it
should
delete
it
and
the
pattern-
and
this
I've
seen
this
pattern
with
a
couple
of
other
controllers
and
it
my
argument:
is
this:
isn't
the
right
pattern
I
haven't?
I
haven't
gotten
this
far
in
testing
with
crossplane,
so
I
don't
know
if
crossplane
is
doing
this,
but
is
that
the
child
resources
should
not
automatically
have
the
annotations
from
the
parent
resources
like
you
don't.
G
G
It's
like
a
different
annotation
and
it
depends
right
like
I
can't
remember
the
controller
I
saw,
but
I
saw
what
ran
into
this
problem
recently,
where
a
controller
specifically
was
using.
G
You
know
the
kubernetes
dot,
io,
slash
app
or
app.kubernetes
io,
slash
instance,
whatever
they're
really
common
sort
of
like
helm,
specific
annotations
or
labels,
and
it
was
copying
those
to
all
the
child
resources
it
created
and
that
caused
this
exact
problem.
So
I'm
happy
to
I'm.
I'm
gonna
be
very
close
to
testing
this
soon,
and
so
I
can.
I
can
maybe
see
if
I
can
reproduce
that,
but
I
think
that
there
I
think
that
there,
if
that's
the
problem,
it's
it's
a
pretty
easy
fix
to
get
around
it.
C
Good
I'm
gonna
raise
so
I
went
to
go,
add
something
to
the
board
and
there's
actually
like
four
different
issues.
We
need
to
do
some
cleanup,
so
I
think
there
are
at
least
two
different
actual
issues.
The
status
and
the
child
resource
reaping
there
may
be
more,
but
I'll
I'll,
add
sort
of
a
parent
issue
that
just
tracks
that
we
want
everything
to
work
nicely
with
argo
cd,
because
a
lot
of
our
community
overlaps
with
city.
I
think
that's
something
that
is
going
to
be
interesting.
C
This
one
especially
the
status
stuff,
for
example,
is
whoever
takes
this
and
works
on
this
shouldn't
necessarily
be
looking
at
it.
As
how
can
we
adapt
cross
play
to
to
play
nice
with
argo
cd?
We
should
be
looking
at
both
projects
and
making
sure
that
we
can
make
them
work
well
together.
You
know,
as
argo
pointed
out
as
victor
pointed
out,
mr
agustini.
C
If
we
were
to
just
go
and
not
change
argo
cd
at
all
and
wanted
to
work
with
cosplay
managed
resources,
it
seems
like
we
would
need
to
go
and
customize
aggro
cd
to
know
about
literally
every
cosplay
resource
in
the
world,
which
is
thousands
of
growing.
So
I
think
the
status
thing,
for
example,
is
going
to
have
to
be
a
fix
in
our
ocd,
for
it
to
be
any
more
an
improvement
in
our
city
for
it
to
be
sustainable
in
any
way.
Based
on
what
I've
read.
G
My
understanding
on
this
right
is
just
that
argos
ships
with
a
bunch
of
default
rules
for
resources,
cert
manager,
other
common
resources.
That
clusters
have
where
it
can
sort
of
say.
If
this
string
equals
this,
then
we're
happy
in
the
status.
So
as
long
as
crossplane
resources
have
a
standard
mechanism
for
saying
they're
healthy,
it
should
be
reasonably
easy
to
do
that.
C
C
998
of
our
thousand
custom
resources,
they
have
a
status
condition
called
ready.
If
ready
becomes
true,
then
it's
ready.
So
it's
kind
of
surprising
to
me
that
that
seems
to
be
like
a
pretty
normal
pattern.
That's
the
case
status
thing
that
flux
is
looking
after.
So
all
right.
I.
G
G
It
soon
so
maybe
I'll
go
find
that
issue
when
I'm
done
when
I'm
when
I
get
to
that
point
and
I'll
update
with
whatever
my
findings
are.
C
D
Yeah,
that's
correct.
What
I'm
not
sure
is.
I
did
not
check
yet
what
are
the
what
was
previously
mentioned?
What
are
the
stand?
What
are
the
default
statuses
or
feels
that
it
is
looking?
D
Argo
cd
is
looking
at
right
now,
whatever
are
those
fields
that
it
is
looking
at
the
values
we
are
not
using
the
same,
no
matter
who
is
standard
nor
standard
stuff
like
that,
and
then
assuming
that
we
don't
change
anything
on
argus
on
cross
plain
side,
we
would
need
to
instruct
argosy
argo
cd
to
do
those
things
like
the
typical
example
would
be
deployment
right,
I'll
go
see.
This
has
special
rules.
D
That
say:
hey
is
the
number
of
pods
running
the
same
as
the
number
of
pods
that
were
specified
in
the
replicas
field,
or
something
like
that
right.
So
it
has
special
rules
for
certain
resources
which
would
be
nightmare.
I
don't
think
that
we
could
ever
do
that
right,
so
we
either
modify
our
cd
to
say.
Hey,
look
for
this
include
this
field
with
this
value
as
the
default
for
potentially
all
resources,
yeah.
C
D
C
Yeah,
I'm
not
yeah,
I'm
not
unless,
unless
one
arguably,
these
rules
are
at
the
moment
is
like
an
industry
standard,
I'm
not
super
keen
on
it.
We
can.
We
can
table
this.
There
is
a
standard
for
this
flux
follows
the
standard
we
follow
the
standard.
I
think
the
correct
way
is
to
get
aggressive
to
follow
the
standard.
To
be
fair
is
a
new
and
acid
standard,
so
I
can
see
that
they
might
be
reluctant,
but
we
should
at
least
have
a
conversation.
They
seem
to
be
friendly.
Folks.
A
Yeah
and
it
seems
yeah,
it
seems
like
yeah
we
are,
we
don't
have
all
the
information
we
have
right
now
here
and
then
matt
thanks
a
lot
for
contributing
to
the
conversation
here
and
you
know,
checking
things
out
for
despin
and
any
of
the
observations
that
you
find
and
sharing
will
will
be
probably
pretty
helpful
here.
Also
so
in
general,
for,
like
speaking
of
the
road
map,
there
is
a
you
know,
high
level
theme
here
of
you
know,
working
appropriately
or
effectively
with
get
ops.
A
You
know
cicd
systems
like
argo
and
both
flux.
Also,
it
seems
like
a
high
level.
Road
map
sort
of
thing
for
that
to
to
work
well
in
those
situations,
is,
is
probably
a
good
priority
for
the
community
overall.
C
Yeah,
I'm
going
to
keep
it
scoped
at
argo
cd.
For
now
I
don't
I
mean
I
know,
there's
really
just
the
big
two,
but
let's,
let's
tackle,
obviously
that's
the
one
we
hear
all
the
time
I
haven't
heard
too
many
people
complaining
that
flux
doesn't
work
with
us.
C
H
In
the
meantime,
does
this
mean
that
we
can
develop
a
patch
set
that
would
copy
the
annotations
needed
to
fix
that
claim?
Issue
victor
had
brought
up
so
that
we
just
we
can
go
ahead
and
advise
people
who
are
using
argo
cd
that
if
they
use
this
patch
set
the
correct
annotations
and
labels
will
get
copied
down
to
their
claim
generated
resources.
A
Yeah
and
I
think
I
think
we
have
to
yeah-
understands
kind
of
the
exact
root
cause
here
and
the
right
solution
here
that
we
can,
you
know
we'll
probably
design
outside
of
this
meeting
here
but
yeah.
So,
let's
so,
let's
keep
moving
with
roadmap,
though,
and
get
through
that,
so
we
can
move
to
the
next
community.
This
topic
section
also
dan.
You
said
that
you
had
an
item
for
roadmap
that
you
wanted
to
bring
up
to.
F
Yeah
and
I
apologize
for
not
getting
the
issue
created
before
this,
and
I
should
have
the
pr
open
as
soon
as
the
issue
exists
as
well,
but
I've
been
working
on
formally
defining
the
spec
for
the
x
package
format,
which
is
the
the
on
disk
format
that
we
use
for
for
crossline
packages
that
is
kind
of
a
super
set
of
requirements
for
oci
images.
F
So
I
just
want
to
mention
that
was
something
that's
going
to
be
a
priority
for
1.7
and
I'll
make
sure
to
get
an
issue
tracking
that
it
should
be.
I
think
I
think
there
will
be
some
changes
coming.
There's
actually
a
new
feature
in
1.6,
that's
related
to
this,
but
everything
is
at
least
now.
A
Awesome
dan
thanks
for
that
update
there
and
yeah
yeah
definitely
do
add
it
to
the
roadmap
here
when,
when
you're
able
to
cool
all
right
any
before
we
move
on,
then
two
providers
updates
there
any
other
comments
to
make
on
cross
plane.
Road
map
cross
plane,
future
2022
priorities.
A
All
righty
cool,
so,
let's,
let's
head
down
down
on
into
the
updates
on
provider
related
stuff,
we've
been
talking
about
core
cross
planes.
Let's
move
on
to
providers
as
well
provided
some
status
here
before
the
meeting
into
the
agenda
and
he
isn't
able
to
make
it
today.
So
we
can
talk
through
some
of
those
real
quick,
then
so,
in
terms
of
the
effort
we've
been
working
on
around
our
terra
jet-based
providers.
A
There's
a
couple
new
ones
there
that
to
announce
that
haven't
been
mentioned
before
so
we're
starting
to
see
some
more
community
adoption
in
being
able
to
generate
entire
providers
at
once.
So
we
have
a
new
linode
one
and
an
exoscale
one
also
that
are
linked
here
in
the
agenda
document.
If
you
want
to
check
those
check,
those
out
the
it
seems
like
with
that
pattern,
there
we've
got.
A
You
know
a
documented,
a
guide
about
how
to
generate
your
own
providers,
so
it
seems
like
they're
getting
some
interesting
adoption
there
and
I'm
hoping
to
see
more
of
more
of
this
opportunity
continue
to
be
taken
advantage
of.
So
that's
pretty
exciting.
There
is
a
new
set
of
releases
for
terror.
Jet
providers
base
providers
coming
out
tomorrow-
I
guess
so
the
end
of
week
here
now.
A
I
I
don't
know
the
details
of
this
note
here,
but
it
may
be
it's
self-explanatory,
so
we
are
doing
some
effort
to
kind
of
you
know:
they're
still
an
alpha
preview
sort
of
maturity
here
and
so
we're
doing
some
effort
to
get
all
of
the
groupings
of
the
resources
into
a
more
final
state
so
that
there
will
not
be
breaking
changes
later
on.
So
there
will.
A
It
sounds
like
right
now,
during
these
preview
stages,
we'll
still
have
a
few
breaking
changes,
meetings
around
refactoring,
etc
and
putting
them
up
into
a
state
to
be
to
be
mature
and
have
not
not
have
breaking
changes
into
the
future.
A
Yesterday,
there
were
two
releases
for
the
aws
provider
and
azure
provider:
the
0.22
provider,
aws
release
was
kind
of
a
bigger
one,
I
guess
bigger
than
the
patch
release
for
azure.
So
the
release
notes
are
here
and
encouraging
folks
to
take
a
look
at
them.
A
You
know
there's
some
some
new
resources
that
are
supported
some
several
resources.
Then
this
list
here
moved
from
alpha
to
beta
maturity,
also
so
a
lot
of
progress
in
aws
and
folks
on
this
call
here
too
specifically
contributing
to
that.
So
thank
you,
everybody
for
that.
So
do
you
read
through
the
release
resources?
Sorry,
the
release
notes
here
for
0.22.0,
and
that
is
available.
As
of
yesterday.
A
All
right
so,
let's
see
aaron
christopher
folks
that
are
in
aws
a
lot
any
any
notes
that
you
want
to
add
or
status.
You
want
to
go
ahead
and
share
here
for
a
provider
aws.
E
I
think
the
biggest
enhancement
for
us-
and
I
know
also
a
lot
of
for
essentia
deutsche
bahn
and
so
on-
is
our
enhancement
for
assume
roll
arms
that
we
can
use,
for
example,
injected
identity,
user
roles
and
assume
roles
in
other
aws
accounts.
E
Then
the
good
point
is
that
we
get
rid
of
using
static
credentials
in
the
providers,
so
this
was
the
biggest
enhancement
from
our
site.
I
think-
and
the
rest
is
special
thanks
to
aaron
and
and
co,
for
updating
the
code
generator
that
we
are
now
able
to
generate
more
resources
with
the
code
generator,
for
example,
in
ec2
area
and
so
on.
H
No,
I'm
really
excited
about
being
able
to
start
using
the
the
I
am
roles
and
and
the
cluster-based
authentication,
and
the
only
other
thing
with
for
me
was
the
big
one
was
finally
getting
onto
the
latest
version
of
the
aws
code
gen
and
getting
on
the
latest
ack
generator
and
getting
past
that
block
so
that
we
could
start
merging
more
quickly.
Now
that
the
generation
is
not
broken.
F
Yeah,
I
wanted
to
add
just
onto
that
that
christopher
did
an
incredible
job
on
the
I
am
roll
stuff
and
that's
a
feature
that
folks
have
been
wanting
for
a
long
time.
If
you
look
at
the
issues
in
the
pr,
I
think,
there's
you
know
tons
of
thumbs
up
and
hearts
on
it.
This
is
a
hugely
requested
feature,
really
really
high
impact,
so
the
the
impact
there
cannot
be
overstated
definitely
really
appreciate
that
work.
He
did
christopher.
E
H
And
then
yeah
aaron's
a.
A
Second,
that
too,
for
the
effort
on
you
know
getting
the
ack
code
generation
updated,
so
we're
moving
faster
now.
A
A
Place,
or
at
least
there's
a
good
understanding
of
you
know
being
able
to
avoid
you
know:
regressions
and
crossplane
related
functionality
in
upstream
ack
now
as
well.
A
All
right
alpera:
do
you
want
to
quickly
give
us
an
update
about
the
0.18.1
release
from
yesterday?
In
the
issue
you
fixed
there.
B
Yeah
sure
so
it's
a
you
know,
bug
fixed
release.
No
api
changes,
no
behavior
changes.
You
know.
As
you
know,
we
had
an
issue
in
provider
azure,
while
provisioning
aks
clusters,
we
were
getting
validation
errors
for
the
app
id
uri
that
we
specify
for
the
you
know
graphic
application
that
we
are
proving
provisioning.
B
B
B
So
we
had
at
some
point
experienced
similar
issues
with
the
postgres
sql
server,
also
on
the
azure
site.
So
we
applied
a
similar
fix
here
yeah.
So
this
is
for
it.
A
Yeah,
nice
and
I
know
a
number
of
people
that
have
run
into
that.
So
thank
you
for
getting
that
fix
in
there
and
then
released
yesterday.
Also
out
there
that's
fantastic.
Thank
you
all
right,
cool
and
then
hassan
quick
update
on
gcp
also.
A
I
thought,
are
you:
are
you
there
for
a
gcp
update,
yeah,
yeah,
yeah
yeah?
Sorry.
B
I
I
messed
up
multiple
monitors
so
yeah.
Basically,
there
are
not
too
many
updates
and
to
me
activity
in
provider.
Gcp
like
there
are
a
couple
of
like
open,
pr's
that
got
reviewed
and
waiting
for
reviews,
etc.
But
the
only
thing
the
only
change
that
we
had
from
until
from
the
last
community
meeting
is
that
new
resource
container
registry
resource
added
by
sergeant
as
his
first
contribution
yeah
that's
pretty
much.
It.
A
Yeah
awesome
and
then
congratulations
to
sergeant
then,
for
you
know,
you've
done
made
more
contributions
since
then,
but
congratulations
on
your
first
contribution
that
is
and
the
first
of
many
to
come.
Thank
you.
I
hope
I
hope
so
also
right
on
okay,
great
great
so
yeah
we
can
move
ahead
on
to
the
community
topics
section
now.
I've
got
about
20
minutes
left,
so
I
think
we're
maybe
a
little
tight,
but
we'll
we'll
see
how
this
goes.
A
So
quick
note
is
that
during
the
holiday
season
here
we
will
be
canceling
the
next
upcoming
community
meeting
here.
So
we've
got
that
already
noted
in
the
agenda
so
december
30th.
We
will
not
be
meeting
and
we'll
resume
back
in
the
new
year
together.
So
hopefully
everybody
has
a
great
holiday
season,
gets
to
recharge
and
you
know
spend
time
doing
the
things
that
are
important
to
them.
A
Okay,
cool!
So
we've
got
a
lot
of
good
links
in
here
for
content
related
to
crossplane
over
the
last
couple
weeks.
A
particular
note,
I
think,
victor
put
out
a
pretty
cool
video
of
the
old
chicken
and
the
egg
problem
about
having
a
you
know,
a
mandatory
cluster
and
for
your
crossplane,
and
where
is
that?
A
How
do
you
create
that
one
to
begin
with,
so
definitely
a
cool
resource
there
nick
had
written
up
a
really,
really
interesting,
write
up
on
you
know
things
we're
doing
at
upbound
and
around
creating
a
using
graphql
to
create
a
graph
of
resources
on
top
of
crossplane,
and
you
know
being
able
to
expose
higher
level
concepts
for
apis
and
experiences
built
on
top
of
it.
So
that's
pretty
cool
article
also
dan
did
a
deep
dive
onto
composition.
A
That
is,
you
know,
folks,
on
this
call
might
be
familiar
with
some
of
that
stuff,
but
probably
not
everything
that
dan
went
over
there,
so
that
was
super
useful.
Also
yeah
ani
anna
east
keeps
doing
cool
content.
I
love
having
her
in
the
ecosystem
and
community.
She
keeps
writing
some
cool
things
and
and
talking
incorporating
crossfade
into
the
stuff
that
she's
doing
so
that's
fantastic
and
then
dan
gave
maybe
an
unusual
talk.
He
went
to
the
risk
five
summit
and
talked
about
you
know.
A
Crossband
related
things
and
cloud
provided
related
things
with
with
risk
5
architecture
too,
so
lots
of
cool
stuff
there
links
are
all
here
available
in
the
agenda
dock
if
you
want
to
catch
up
on
those-
and
this
continues
to
be
one
of
my
favorite
sections
of
the
community
main
just
to
see
all
the
cool
stuff
that
we're
doing
and
people
in
the
community
ecosystem
talking
about
us
and
just
kind
of
the
project
continuing
to
move
forward.
A
So
I
love
this
section
here,
really
cool
stuff
to
talk
about
okay,
cool
and
then
I
wanted
to
call
attention
to.
There
was
what
I
thought
was
an
interesting
discussion
on
slack
about
how
you
can,
if
you're
a
current
terraform
user,
how
you
can
kind
of
slowly
migrate
over
instead
of
all
in
one
quick
shot.
You
know
start
kind
of
moving
some
resources
over
in
the
available
paths
we
have
in
the
in
the
crossfit
community.
A
For
that,
so
do
click
on
that
and
read
that
through
that,
if
you
want
some
ideas
around
migrating
from
terraform
to
crossplane,
I
think
muafik
added
this
particular
issue
here.
So
it's
a
request
for
comment
here.
If
folks
wanted
to
add
their
opinions
to
this
particular
issue,
I'm
not
up
to
speed
on
this
issue,
so
maybe
you
know,
nick
or
hassan
or
somebody
else
who's
commented
on.
A
It
can
provide
a
quick
high
level
summary
to
it,
but
this
is
a
request
for
comment
of
folks
that
want
to
provide
their
opinion.
This
is
the
the
place
to
do
that
here
on
this
issue.
C
C
Well,
just
it's:
it
is
an
important
thing,
but
it
is
a
naming
thing.
Currently
we
make
the
distinction
right,
so
we
build
providers
a
couple
of
different
ways.
They
share
a
lot
of
the
same
libraries,
regardless
they're,
all
sort
of
based
on
the
same
underlying
libraries
but
the
jet
providers,
the
ones
that
provide
a
hyphen
jet
hyphen
aws,
for
example,
versus
provider
hyphen
aws.
C
The
jet
signifies
that
they're
built
with
terror
jet,
which
is
a
code
generation
tool
that
will
build
a
provider
automatically
wrapping
a
terraform
provider.
We
have
thought
we
might,
we
say
jet
rather
than
like
terraform
or
whatever,
because
we
think
we
might
have
other
code
generation
tools
in
future
and
the
context
is
we
haven't.
We
have
a
small
handful
of
code
generation
tools,
they're
all
something
jet
aggregate
terror,
jet,
etc,
etc.
So
that's
the
slang
for
code
generation.
C
So
right
now
we
group
everything
separately.
We
have
a
distinct
provider,
aws
and
a
provider
jet
aws.
You
can
install
both
and
you
can
mix
and
match
them,
but
we
we
keep
them
as
separate
packages.
C
Part
of
the
argument
for
that
in
the
past
has
effectively
been
because
they're
built
differently
and
they
work
differently,
particularly
because
the
terror,
gen
ones
rap
terraform
and
are
actually
forking
a
terraform
binary
in
the
background
to
go
and
do
what
they
what
they
need
to
do.
They
probably
have
different
operational
characteristics
than
native
providers,
so
native
providers
are
calling
an
api
using
like
a
you
know,
a
go
sdk
typically
making
rest
calls.
C
Terrajet
providers
basically
translate
all
the
crossplane
config
into
a
terraform
config
for
terraform,
apply
it
past
the
output
and
reflect
that
in
the
status
of
the
resource.
C
We've
hypothesized
that
there
are
different
operational
characteristics
for
this
right,
like
just
the
performance
of
forking,
a
terraform
binary
versus
making
a
goggle
or
a
rest
call
viago,
and
also,
like
you
know,
error
handling.
You
know
it's
possible.
We
might
like
leak,
terraform
implementation
details
at
some
point.
We
hypothesize
this
without
tells
me.
It
doesn't
actually
happen
that
much.
C
You
know
there's
folks
on
the
call
who
would
know
better
than
me,
but
anyway,
where
I
think
move
up
is
going
with
this
is:
do
we
want
to
use
this
jet
signifier
when
there
isn't
anything
to
compare
it
to
so,
if
there's
an
existing
provider
aws,
we
call
the
the
jet
variant
provider
jet
aws.
C
If
we
just
started,
provide
a
fubar
tomorrow
and
we
used
tariff
jet
to
create
it
and
there
was
no
provider
foo
bar,
would
we
call
it
a
jet
fubar,
or
would
we
just
call
it
provide
the
food
bar
because
it
was
the
only
one?
So
I
think
that's
kind
of
the
the
main
thing
that
that
is
sort
of
suggesting
here.
A
Does
that
make
sense?
Yes,
that
does
make
sense
nick
and
thank
you
for
sharing
that
context,
so
yeah.
So
this
issue
here
once
169
is
linked
in
the
agenda
document
and
if
books
want
to
provide
a
comment
there,
then
please
do
that
in
the
get
up
issue,
so
it's
captured
all
in
one
place
there
all
right
so
dan
you
mentioned
this
pr
here.
I
think.
F
Yep,
so
this
is
a
a
very
small
pr
in
terms
of
what
the
actual
change
is,
but
it
potentially
has
has
some
larger
impact.
So
essentially,
what
this
does
is,
if
you've
ever
authored
a
provider,
you're-
probably
familiar
with
that
crossblind.yaml
that
has
the
provider
meta
package
type
in
there.
That
defines
what
controller
image
should
be
used
to
reconcile
all
the
crds
that
you're
installing
all
this
does.
Is
it
makes
that
field
optional?
F
So
previously,
if
you
omitted
that
field
from
the
spec
of
your
provider,
meta
crossplan.yaml,
it
would
fail
to
build
and
crossplane
would
fail
to
install
it.
That
was
by
design
we
needed
that
controller
image.
Now
that
is
optional,
and
if
it's
not
provided
we'll,
actually
use
the
same
image
that
the
package
is
to
start
the
controller
as
well,
which
gives
you
the
ability
to
kind
of
do
this
pattern
that
I
think
we're
moving
towards
and
could
potentially
simplify
some
of
our
provider
building
called
fat
packages.
F
If
you
will,
where
you
essentially
have
everything
for
the
controller,
including
you
know
the
binary
and
any
kind
of
runtime
stuff
you
need
in
there
and
and
then
you
also
have
the
package
contents.
F
The
the
obvious
kind
of
trade-off
with
this
is
that
when
crossplane
caches
that
package
image,
it's
going
to
be
a
lot
larger
than
it
was
with
just
the
yaml,
because
it's
got
the
binary
in
there
and
any
other
things
you
need,
and
so
this
is
kind
of
the
first
step
to
give
us
the
ability
to
kind
of
try
out
this
pattern
and
see
how
folks,
like
it-
and
you
do
you'll
see
in
the
testing
here
notice
that
you
have
to
bump
the
cache
size,
because
the
the
image
is
is
quite
a
bit
larger
in
the
future.
F
What
we'll
likely
do-
and
this
is
part
of
the
the
spec
that
I
was
mentioning
earlier-
that
that
I'll
be
adding
to
the
docs
is-
will
only
cache
the
package
image
contents,
even
if
the
image
is
much
larger,
there's
a
variety
of
ways,
we'll
support,
doing
that
via
oci
image,
annotations
and
that
sort
of
thing,
and
so
you
should
be
able
to
have
a
single
image
and
not
have
to
increase
your
cache
size,
basically
at
all
so
anyway.
F
This
is
the
the
first
step
towards
this
definitely
feel
free
to
try
this
out.
If
you
like,
it
could
be
as
simple
as
taking
your
provider
controller
image
and
just
if
you're,
building
with
docker
do
an
add
package.yaml
into
it
and
that'll
work
for
you
so
yeah.
This
will.
This
is
in
1.6
or
will
be
in
1.6
and
then
in
1.7.
A
Awesome
dan
yeah
thanks
for
sharing
that
and
further
context
around
that.
A
Okay
and
alphara,
I
think
you
kind
of
touched
on
the
sporadic
issues
with
aks
cluster
provisioning
already
when
you're
talking
about
the
18.1
release,
is
there
any
more
that
you
wanted
to
add
on
top
of
that
or
any
further
context.
B
Yeah
so
there's
quite
a
deep
discussion
in
the
issue
referenced,
so
I
don't
want
to
go
into.
You
know
too
much
details
of
it,
but
it
looks
like
you
know
the
way
we
provision
aks
clusters
is
prone
to
you
know
certain
race
conditions
on
the
azure
site.
I
have
you
know,
documented
my
findings
in
the
issue
for
interested
readers.
B
B
Have
attention
here
that
you
may
we
may
hit
some
furthest
products
that
I
observed
for
the
first
time
when
trying
the
0.18
release
so,
while
dating
it.
A
Yeah,
thank
you
for
calling
those
out
alpha
and
providing
the
you
know
details
about
the
behavior
you're,
seeing
and
you
know
the
potential
workarounds
and
ways
to
avoid
it,
and
you
know
how
it
could
be
a
inconsistency
issue
that
which
active
reconciliation,
eventual
consistency
can
eventually
solve
too.
So
it's
good
to
know
all
that
sort
of
stuff.
A
Thanks
for
writing
that
up,
okay,
cool
and
then
I
think,
steven
added
a
note
here
which
is
useful
to
everybody
here-
is
that
the
call
for
proposals
the
cfp
for
kubecon
next
kubecon
in
the
eu
is
the
deadline
is
tomorrow.
So
if
you're
thinking
about
getting
a
talk
in,
you
need
to
be
able
to
do
that
by
tomorrow.
I
think
it's
probably
midnight
tomorrow
is
how
they
normally
do
it.
A
If
you
want
any
feedback-
or
you
know,
commentary
on
any
cfps
you're
working
on
feel
free
to
share
them
with
the
community
and
we're
all
happy
to
provide
any
sort
of
guidance
or
potential
feedback
to
improve
them.
So
that
deadline
is
tomorrow,
be
aware
of
that,
and
that
sounds
like
a
fun
one
too,
because
I
believe
it's
in
valencia
in
spain.
So
that
would
be
pretty
cool
to
be
a
speaker
and
go
to
that.
One.
C
Jared
just
calling
on
that
just
said
in
chat
that
he
had
some
topics
he'd
like
to
bring
up.
A
Oh
sweet,
yes,
all
right,
then
this
is
the
the
time
for
those
topics
to
come
on
up.
Matt.
G
Perfect,
thank
you.
I
didn't
want
to
add
them
into
the
agenda
if
it
wasn't
the
right
place,
so
I
they're
they're
questions
but
they're
questions
that
I
see
lots
of
references
to,
and
I
haven't
seen
any
specific,
like
documented
answers
like
of
the
pattern
that
should
be
followed
and
I'm
I
get
the
impression,
maybe
there
isn't
a
pattern
yet
that's
why
I
wanted
to.
I
wanted
to
ask
about
that
in
terms
of
forward
thinking
here.
The
first
one
is.
G
When
we
start
thinking
about
creating
you
know
giving
our
developers
or
our
users
the
ability
to
create
cloud
resources
right,
s3,
buckets,
kms
keys,
etc.
You
know,
there's
this
question
of
okay,
I
can
create
the
bucket,
but
then
how
do
I
use
the
bucket?
How
do
I
access
it
right?
Well,
I
need
an
iam
role,
let's
say-
and
this
is
of
course
amazon
specific,
but
I
imagine
gcp
and
azure
have
a
similar
pattern
and
there's
this
there's.
G
Basically,
a
big
question
of
is
the
is
the
developer
required
to
create
an
iam
role
where
they're
granting
themselves
a
privilege
to
talk
to
a
bucket
based
on
a
name
that
they
expect,
or
are
we
creating
a
bucket
and
creating
a
policy?
That's
attached
to
that
bucket?
That
knows
the
name
of
the
iam
role
that
it's
going
to
grant
in
right
like.
Where
is
the
source
of
truth
here
and
I
you
know,
I
find
in
in
either
case
in
either
sort
of
world,
whether
you
do
it
on
the
iam
role
or
on
the
bucket.
G
There
be
there's
this
like
disconnect
and
big
area
where
you're
gonna,
where
you
can
make
mistakes
right.
You
might
not
know
your
iam
role
name
because
maybe
that's
programmatically
created
probably
is
you
may
not
know
the
bucket
name,
because
maybe
that
you
know
what
you
enter
in
as
a
bucket
name
is
then
mutated
and
additional
fields
or
data
are
added
to
it.
C
There
are
multiple
yeah,
the
composition.
Functionality
is
not
done.
Yeah,
you
know
we're
an
open
source
project.
There
is,
there
is
definitely
infinite
amount
of
improvement
to
be
to
be
done
to
it.
C
Your
specific
use
case-
I
I
don't
know
if
I
really
want
to
dig
into
it
in
the
time
we
have
left,
but
what
you
just
mentioned
sounds
like
something
that
could
be
done
with
composition.
Today
I
would
have.
I
would
have
thought
that
you
could
create
the.
I
am
roles
as
part
alongside
the
bucket
in
an
opinionated
fashion,
without
giving
developers
too
much
control
over.
You
know
they
would
theoretically
triggering
the
creation,
but
then
this
wouldn't
necessarily
have
to
have,
like
you
know,
full
control
over
over
all
the
commissions.
G
But
I
think
the
challenge
I
think
I
agree.
I
don't
want
to
solve
this
specific
problem
right,
I'm
using
this,
this
problem
as
an
example,
but
I
think
the
challenge
is
yeah.
I
can
create
a
composition
that
also
creates
an
iam
role,
but
then
that's
a
very
like
that's
a
very
specific
role
that
has
to
be
used
to
get
into
that
bucket
and
now
what?
If
the
person
has
a
bucket
and
a
kms
key
right
and
those
are
two
different,
totally
different
resources.
G
G
Basically,
it
feels
like
compositions
right
now
can
reference
a
bunch
of
other
components
within
that
composition,
but
that
I
don't
have
a
method
for
referencing
data
from
outside
of
the
composition,
and
so
I
feel,
like
my
current
answer,
is
going
to
be
that
they,
you
know,
developers
have
to
create
their
own
im
policies
and
then
use
sort
of
loosely
wild,
carded
resource
names
and
their
policies
which
we
don't
like
in
order
to
solve
it.
G
H
C
The
specific
the
specific
issue
of
you
want
to
compose
using
data
that
is
not
part
of
the
composition
is
already
exists.
Like
you
know,
are
you
on
explain
slack?
I
don't
know
if
I
can
find
it
in
time,
but
I
can
definitely
find.
G
A
reference
to
it,
yeah,
I'm
on
slack
deranged,
spelled
with
an
eye
cool.
C
For
you
there's
a
couple
of
things
right:
there's
one
is
adding
functionality
for
observe
only
resources
which,
in
the
terraform
world,
is
like
a
data
source
effectively
which
would
allow
you
to
say.
Okay,
this,
I
am
role
exists
and
I
want
to
refer
to
it,
but
I
want
to
declaratively
manage
it
necessarily
and
the
other
one
is
whether
or
not
you
have
an
observe
only
resource
but
yeah.
Sometimes
you
might
want
to
just
pull
in
some
data
from
a
conflict
map
or
something
outside
of
cross
plane
and
use
that.
B
C
Your
composition
and
then
this
is
all
wrapped
up
in
the
site,
not
not
necessarily
part
of
the
same
functionality,
but
then
the
the
question
we
always
ask
ourselves
with
with
composition
as
it
exists
today
is:
how
far
do
we
want
to
go
with
that
before
we
just
invest
in
custom
composition
and
say
it's
too
complicated
like
let's,
let's
you
know
build
this
into
the
custom
composition
idea
that
allows
you
to
just
go
use
python
or
the
typescript
or
whatever,
and
actually
just
like
start
describing
all
of
this
in
a
high
level,
which
I'm
not
necessarily
saying
we
will
solve
that
that
way,
saying
that
you
know
a
lot
of
these.
C
A
lot
of
these
ideas,
like
we
were
always
sort
of
doing
the
trade
off
of
like
the
idea
of
composition.
Originally
as
it
stands
today
was.
It
was
supposed
to
solve
very
simple
use
cases:
composition
as
it
exists
today,
is
not
supposed
to
be
like
feature
compatible
with
terraform,
let's
say
modules,
so
you
know
if
we
can
grow.
F
C
C
So,
if
you
can
see
on
the
road
map,
the
observe
only
resources,
one
is
there,
and
I
it's
possible
that
the
I'm
not
actually
sure
whether
the
the
data
source
is
what
is
on
the
roadmap
that
you
can
stuff
from
other
data
sources,
but
if
not
I'll
find
it.
B
I
would
just
ask,
like
you
know,
like
you:
can
provide
input
to
come
to
your
composition
with
with
the
parameters
in
claims
or
xrd's,
so
I'm
just
trying
to
make
sure
that
you
are
aware
of
that,
so
that,
like,
for
example,
you
can
just
get
the
name
of
the
like.
I
am
user
as
an
input
to
your
composition,
simply
in
the
like
spec
of
your
claim.
So
this
is
already
there,
and
maybe
this
this
is.
This
could
already
solve
the
problem.
E
So
I
can
also
add
something.
What
we
did
at
the
moment
is
also
to
create
this
provider.
Kubernetes
service
accounts
in
the
tenant,
namespace
and
label
or
annotate.
The
service
account
with
the
correct
iam
role
we
created
in
the
compositions,
and
then
the
tenants
can
configure
the
service
account
in
their
hand,
charts
for
example.
E
Then
we
exactly
know
that
the
service
account
they
created
has
the
correct,
set
it
up
role
or
policy
for
them,
and
our
point
of
view
is:
if
a
tenant
creates,
for
example,
s3
bucket,
then
the
tenant
is
also
yeah,
that
they
need
to
thought
about
what
they
configure
in
the
in
the
policies
and
so
on
yeah.
E
So
we
did
at
the
at
the
end
a
day
through
operation
that
the
security
guys,
I
will
tell
them
that
imrolls
and
so
on,
are
not
correctly
configured
yeah
and
then
they
need
to
do
something,
for
example,
in
24
hours
or
48
hours,
to
fix
the
issues.
Then,
because
we,
as
administrators
of
the
clusters,
are
not
able
to
validate
all
of
the
stuff,
they
did
in
our
classes.
G
Yeah,
I
think
that
latter
answer
is
well.
Actually,
both
of
those
are
are
sort
of
accurate
answers
in
terms
of
a
way
you
can
get
around
this.
I
think
they
both
introduce
the
thing
that
I'm
trying
to
prevent,
which
is
user
error.
You
know
and
users
needing
to
be
aware
of.
Okay.
If
I
create
my,
I
am
role
resource.
G
But
it
also
sounded
like
you
guys,
are
looking
at
this
sort
of
in
the
in
the
cross,
plane,
composition,
space
and
I
feel
like
it's
not
a
it's,
not
a
far-fetched
answer
to
introduce
the
ability
to
go
and
sort
of
have
a
user
pass
in
a
reference
to
another
object
to
get
their
iam
role
or
or
any
other
piece
of
data
like.
I
think
you
guys
are
thinking
about
it,
which
is
great.
I
do
want
to
find
that
issue
and
maybe
thumbs
up
it.
G
You
know,
or
you
know,
and
I'm
in
the
in
the
short
term.
We
can
of
course
do
that.
You
know
I
think
the
answer
is
going
to
be
passing
in
the
iam
role
name
and
we'll
just
deal
with
it
from
there.
G
It's
sort
of
opposite,
but,
like
let's
say
you
had,
let's
say
you
created
a
composition
to
create
an
iam
role.
Okay,
and
then
you
write
the
secret.
You
write
out
a
secret
at
the
end
that
that
has
the
name
of
the
the
a
the
full
arn
of
that
role.
Now
I
create
a
composition
that
allows
them
to
create
a
bucket.
H
It
depends
I
think,
on
whether,
if
you
pass
in
the
name
from
that
secret
into
your
composition,
it
would
depend
on
whether
the
resource
such
as
the
bucket
or
the
policy
supports
a
secret
ref
as
a
source
for
its
data
for
any
resource
that
does
support
a
secret
reference.
Instead
of
the
explicit
value
yeah,
you
can,
you
can
simply
say
here's
the
name
of
the
secret,
that
from
that
that
was
written
by
my
composition,
to
create
an.
G
Yeah,
I
think
that
latter
part
is
kind
of
what
you
what
you
ultimately
need
to
be
able
to
tie
resources
together
and
sort
of
allow
you
know
it's
allowing
the
service
catalog
approach
right
rather
than
rather
than
an
administrator,
who
understands
a
composition
and
understands.
I
know
their
iam
role
is
going
to
look
like
this,
so
then
I'll
create
their
bucket
and
I'll
pass
in
this
value,
because
I
know
that
those
two
will
look
together.
Trying
to
try
to
have
you
know
make
it
simple
enough
that
a
developer
can
just
say.
I
have
a
role.
G
I
need
a
bucket,
I'm
done
right
there
they're
connected.
I
don't
want
to.
I
don't
want
to
drag
this
on
too
long.
I
I
but
I,
but
I
very
much
appreciate
the
conversation
and
that
you
guys
are
kind
of
looking
at
it
and
we'll.
You
know
we'll
go
with
this.
The
stupid,
simple
answer
for
now
and
we're
just
passing
that
value
in
and
then
we'll
adjust
it
in
the
future.
C
I
I
dropped
the
two
issues
that
I
think
are
relevant,
or
at
least
two
of
them
in
chat
here
in
the
zoom
chat,
so
definitely
grab
those
before
the
ends.
A
I'll
put
those
into
the
agenda
doc
here,
also
so
that
they're
more
persistent.
C
Great
and
I
I
think,
given
that
all
of
this
conversation
it's
it's
worth,
either
opening
a
discussion
on
github
or
opening
an
issue
on
github
that
goes
into
more
detail
about
what
your
use
cases
are,
what
you
consider
the
solutions
and
like
what
you'd
like
to
see.
Instead,
that
way,
we
can
make
sure
that
you
know
we
at
least
have
those
use
cases.
When
we
look
at
these
issues,.
G
Yeah,
I'm
always
happy
to
do
this
in
in
a
github
discussion.
I
always
find
that
that
gets
makes
it
easier
to
get
other.
You
know
outside
opinions
and
and
make
sure
that
we're
not
we're
not
way
off
the
wall
or
crazy
and
what
you
know,
what
we're
hoping
to
do.
C
Yeah
sounds
good
yeah.
I
know
that
they
observe
only
resources
is
likely
to
be
a
priority
sometimes
soon.
At
least
we-
and
we
are
not
bound
here
from
our
customers-
that
that
is
something
that
we
want
to
offer.
G
Okay,
I
had
one
other
question
and
I
think
this
is
still
somewhat
generic,
but
my
my
example
will
be
not
which
was
and
I've
seen
this
come
up
a
few
times.
It's
a
and
someone
actually
posted
about
it
in
the
chat
literally
this
morning,
basically
trying
to
control
the
templatized
name
of
the
resources
that
are
created
in
the
cloud
you
know
by
your
provider,
but
right
now
it
seems
that
there
isn't.
G
You
know,
there's
a
way
to
explicitly
control
the
entire
name
and
there's
a
way
to
let
the
composition,
controller,
dynamically
generate
a
name,
but
there
isn't
kind
of
a
middle
ground
where
you
can
control
the
pattern.
For
example,
you
know
I
want
to
prefix
all
my
resources
created
by
cluster,
a
with
cluster,
a
dash
whatever
that
you
know
whatever
your
pattern
might
be,
and
you
know
the
question
that
somebody
asked
this
morning
was
like.
G
Is
there
a
pattern
for
being
able
to
use
generate
name
in
your
in
the
in
the
resources
that
are
being
created
by
the
composition?
I
was
thinking
about
it,
a
different
way,
which
was
you
know,
you've
got
combined
from
composite.
You
know
you're
from
field
path
as
an
example.
As
a
you
know,
one
variable
form
you
could.
G
I
was
thinking
you
could
have
another
one
where
it's
like
generate
a
uuid
or
something
right
where
you
could
have
like
you
know
you
can
com
compose
your
external
name,
the
way
you
really
want
to,
but
but
I
was
just
curious
if
there's
an
ongoing
discussion
about
this
right
now,
I
feel
like
it's
it's
I
we
have
to
control
the
name
entirely
and
but
you
know
deal
with
conflicts
or
we
don't
control
the
name
at
all
and
that
actually
makes
the
first
issue.
C
I
would
I
would
raise
an
issue
to
discuss
this.
It's.
It
should
be
possible
to
some
extent
already
right,
because
you
can
patch
to
the
external
name,
and
you
can
use
transforms
and
string
formats
and
things
like
that
to
templatize
that
patch,
but
you
know
we
have
had
like
a
random
string.
Generator
function
proposed
was
actually
kind
of
hard
to
build.
Surprisingly,
it
sounds
easy.
G
C
G
I
can
open
up
an
issue
on
that
that
that's
no
problem
yeah,
just
as
a
data
point
on
that
one.
C
That
that,
as
far
as
I
know,
this
is
like
the
second
time
it's
ever
come
up,
so
I
agree
that
it's
something
we
should
fix,
but
it's
not
something
that
we're
seeing
like
the
community
clamoring
to
to
get
done.
I
find
that,
like
certain
big
orgs
who
have
existing
policies
around
like
how
stuff
should
be
named
already
at
this
there's
other
two
or
three
folks
who've
come
to
us
with
that
so
far,
but.
C
Issue
and
I'll
turn
it
over
to
I'll
comment
on
it
and
with
some
other
like
functionality.
That
is
possible
today
with
regards
to
templating
the
external
name,
and
I
think
there
is
more
to
be
added
to
that
as
well.
G
Yeah
that
maybe
there's
a
temp,
maybe
there's
a
pattern
that
that'll
work
well
enough
for
us,
so
I'll
open
up
an
issue
appreciate
it.
Thank
you.
A
Issues
yeah:
this
is
a
really
good,
critical
thinking
too,
and
good
feedback
about
patterns,
and
you
know
how
best
to
enable
scenarios
that
are
important
to
you
and
and
by
extension,
like
more
of
the
community
also
so
this
is.
This
is
a
really
good
discussion
today
matt.
I
really
appreciate
that
man
all
right
all
righty
everybody.
So
let's
go
ahead
and
wrap
it
here,
then.
So,
thanks
everybody
for
joining
a
great
discussions
today
and
happy
2021,
and
we
will
reconvene
in
2022.,
see
ya.