►
From YouTube: 2021-10-21 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
october
21st
2021
cross,
plane
community
meeting.
We've
got
a
lot
going
on
here
in
the
community
and
with
the
upcoming
1.5
release.
So
let's
jump
on
into
it,
and
so
typically
here
we
go
through
releases
upcoming
releases
roadmap
status,
type
of
stuff,
first
for
the
core
crossplane
project
and
the
providers
also,
and
then,
after
that
we
have
a
more
broader
community
focus
section
where
we
can
get
some
updates
on
things
going
on
in
the
community.
A
And
then
you
know
maybe
some
questions
answered
and
things
like
that
and
then
the
final
section
is
a
more
technical
focus,
so
we
can
go
through
like
specific
prs.
We
can
do
more
deep
dives
into
some
of
the
technical
content,
and
so
some
of
that
stuff
could
be
optional
and
folks
can
drop
off
if
that's
not
specifically
relevant
to
them.
But
that's
the
general
flow
of
the
of
the
agenda
here
that
we
typically
go
through.
A
So,
let's
start
with
releases,
then
so
1.5
is
coming
up
and
very
soon
in
the
release
date,
as
we've
had
planned
this
entire
time
with
our
typical
release.
Cadence
of
every
eight
weeks
will
be
october
26th,
which
is
next
week,
and
so
I
saw
muafik
put
together
a
the
release
checklist
issue
just
yesterday,
or
so
so.
We've
got
that
going
and
we
are
nearing
getting
ready
to
cut
to
release
and
do
all
the
steps
there.
That
process
is
pretty
well
defined.
A
A
I
don't
know
if
folks
that
other
folks
have
touched
it
here,
but
I
think
right
now,
it's
less
about
what's
in
the
release
and
more
about
what's
not
yet
finished,
or
maybe
things
that
we
need
to
put
some
attention
on
so
that
they
can
make
the
release.
I
think
that
you
know
we're
in
we're
in
a
code
freeze,
sort
of
thing
here,
but
let's
see,
if
there's
anything
outstanding
still
so
any
any
thoughts
on
that.
B
B
So
I
don't
think
that
will
make
it
in
the
custom
certificate
authorities.
I
give
that
a
review
today
and
it's
pretty
much
ready
to
go,
but
it's
a
fairly
large
feature
change,
so
that
also
won't
go
in.
Obviously
I
did
want
to
mention
a
1pr
but
I'll
bring
it
up
in
the
patches
section,
but
it's
not
mentioned
here
so
I'll
go
ahead
and
drag
it
in.
C
B
Okay,
perfect
yeah
I'll
defer
that
to
the
patches
section,
because
I
think
it's
a
larger
topic.
C
A
That
sounds
good,
then
yeah.
So
we're
probably
you
know,
heading
with
the
release
next
week
and
being
in
you
know,
code
fees
right
now.
We
don't
anticipate
major
things
still
landing,
but
if
anybody
needs
support
or
anything
for
the
release
for
next
tuesday,
then
we
should
definitely
raise
the
flag
and
raise
hands
and
we'll
get
together
to
to
make
sure
that
things
are
smooth
heading
into
the
release.
C
Yeah
we
haven't
really
made
the
decision.
Maybe
we
will
have,
we
will
have
the
supreme
planning
after
this
community
meeting,
so
there
we
will
decide.
One
thing
I
want
to
ask
daniel
last
year
so
that
the
second
one
under
to
do
promoting
control
going
to
be
one
better.
One.
Is
this
something
that
we
gain
like
you
know.
This
is
something
that
I
can
just
like
now
go
ahead
and
do
it
to
include
to
be
included
in
the
release.
B
I
don't
think
so
I
mean
I
like.
These
are
just
my
opinions,
so
you
know
it's
not
this
isn't
set
in
stone.
I
don't
personally
feel
comfortable
with
the
api
of
the
controller
config.
It's
very
widely
used
and
it's
fairly
effective
at
what
it
does,
but
it
concerns
me
that
it's
kind
of
like
a
catch-all
resource
right
now
that
feels
like
we're
just
kind
of
putting
stuff
into
so
I'm
definitely
in
favor
of
leaving
it
as
viewing
alpha
one.
D
B
D
Sorry
just
join
the
call
hello,
I'm
mostly
on
the
same
page
as
dan,
but
I
I
don't
think
this
is
urgent
at
the
moment,
but
maybe
some
time
in
the
time
frame
of
the
next
release,
as
in
the
one
after
the
one
on
tuesday
1.6.
D
B
Like
that
as
a
first-class
field,
not
sure
yeah,
I
think
that's
a
that's
a
great
point.
I
feel
like
that.
This
is
very
related
to
some
of
my
desire.
For
us
to
not
have
deployments
is
the
only
thing
that
can
be
spit
out
as
something
that
runs
a
controller
which
this
is
obviously
very,
very
tied
to
the
deployment
api
so
yeah.
It
might
be
good
for
me
to
open
up
some
issues
describing
that.
B
D
Tracking
it
specifically
yet,
but
also
thinking
about
a
similar
issue
for
composition,
revisions
to
promote
them
to
v1
beta
1,
so
that
or
just
tracking
issues
generally
so
the
stuff
that's
named
people
and
other
one
forever,
so
definitely
would
be
good
for
controller
config
as
well
to
get
community
feedback.
So
if
anyone
has
any
thoughts
on
it
or
I'll,
try
and
post
something
on
slack
afterwards
or
soliciting
soliciting
input
on
it
dan
have
you
captured
that
thought
about
the
variable
of
wanting
to
support
packages
that
aren't
deployments?
B
D
A
Yeah
so
yeah,
so
it
looks
like
then
we're
have
most
things
in
place
for
1.5,
and
so
we
will
be
running
that
release
next
week
and
if
there
are
any
further
thoughts
on
1.5,
then
we
can
go
ahead.
I
think,
and
move
on
to
the
patch
releases
that
dan
wanted
to
to
bring
up
here.
B
Yeah
thanks
jared,
so
there's
a
pr
open
that
I
will
have
updated
shortly
for
a
move
official
final
review
on,
but
essentially
we
had
an
issue
where
the
version
name
is
causing
problems,
because
when
you
supply
packages
that
you
want
to
be
installed
as
part
of
the
crossplane
installation,
the
naming
schema
takes
the
full
package
source.
So
that
would
be
something
like
crossplane
slash
provider
dash
aws
colon
v0.19.0
and
it
basically
normalizes
that
without
stripping
the
version
off
of
it.
B
So
what
that
means
is,
if
you
update
your
either
existing
cross
plane,
installation
with
a
a
helm
upgrade
or
you
upgrade,
to
a
new
cross,
plane,
installation
and
in
either
of
those
operations
you
change
the
version
of
one
of
your
providers.
We
don't
just
update
the
provider,
that's
already
in
place
whether
it
was
installed
previously
via
helm
or
not.
We
actually
go
ahead
and
bump
er
create
a
new
provider
that
obviously
has
conflicts
with
the
one
that's
already
there.
B
They
have
the
same
source
or
potentially
a
different
version
of
the
source
and
but
different
package
object
names.
So
what
this
is
doing
is
changing
the
way
we
name
packages
moving
forward.
That
would
be
a
breaking
for
anyone
who
is
updating
from
older
versions,
which
is
not
a
great
situation.
B
It
would
like
be
we'd,
be
introducing
more
breakage
while
trying
to
reduce
future
breakage,
and
so
but
it
seemed
like
a
fine
trade-off,
but
then
in
the
back
and
forth
here
on
this
pr,
you
can
see
some
discussion,
which
is
what's
going
to
be
implemented
and
will
be
backwards
compatible
of.
B
We
actually
now
check
to
see
if
there's
a
package
that
already
exists
with
the
source,
that's
specified,
so
we
get
the
lock
and
basically
create
a
map
of
that
and,
if
you've
specified
any
packages
in
your
home
install
we
check
to
see
if
they're
already
there
and
if
so
we
use
that
existing
object,
name
and
just
update
the
source
for
that
package.
So
anyway,
that's
that's
kind
of
strategy.
We're
gonna
go
with
there
because
that
is
backwards
compatible.
We
can
actually
do
patches
of
all
the
active
branches.
B
Something
to
note
with
this
is,
I
would
advocate,
despite
us,
being
in
code
freeze
right
now,
and
you
know
with
being
in
code
freeze.
We
already
have
a
1.6
branch,
so
merging
or
sorry
1.5
branch
so
merging.
This
will
actually
not
put
it
in
the
1.5
release.
Since
we
are
patching
back
to
active
release
branches
right
now.
B
I
think
it
clearly
makes
sense
to
go
ahead
and
include
this
in
the
1.6
release
as
a
bug
fix,
so
that's
kind
of
my
two
cents
on
it,
but
we
will
definitely
have
at
least
the
patch
releases.
B
D
That,
including
1.6,
is
my
release.
You
mean
1.5
right.
A
And
did
you
you
know,
did
you
have
any
concerns
around?
You
know
risk
like
regression
or
experience
or
anything
like
that
with
this
or
you
felt
pretty
strong
about
you
know
safely.
You
know
doing
a
patch
which
is
kind
of
before
1.5
actually
goes
out,
though,.
B
I
feel
pretty
good,
mostly
because
I'm
testing
it
really
thoroughly,
but
also
the
the
nice
thing
about
this
is
this
feature
and
some
of
the
the
revision
controller,
which
actually
basically
manages
the
lock
in
your
cluster,
were
developed
somewhat
in
isolation
and
what
I'm
doing
is
taking
the
same
scheme.
We
use
to
name
things
in
a
way.
B
That
means
that
we
will
just
update
sources
and
it's
the
same
thing
we
do
when
we
actually
check
for
dependencies
that
have
dependency
ranges,
I'm
just
reusing
that
machinery
in
the
installer
now.
So
it's
not
like
the
code
paths
that
that
we're
using
haven't
been
exercised
pretty
frequently
already.
So
that's
also
kind
of
like
reinforcing
my
confidence
and
go
ahead
and
including
this.
A
That
sounds
good
and
then,
and
then
also
like
around
the
case
of
somebody
has
1.4
installed.
They
you
know
they,
they
have
some
packages
installed
and
then
they
install
1.5
with
this
change
in
it
and-
and
it
doesn't,
you
know,
have
any
impact
on
existing
package
games,
etc
or
breaking
impact.
B
A
All
right,
okay,
that
sounds
good
and
thanks
for
keeping
us
updated
on
that
one
dan.
So
that's.
A
Cross
plane
related
stuff,
so
I
think
we
can
move
on
down
to
the
providers
now.
So
I
think
there's
a
big
update
to
be
made
around
the
terra
jet
project.
So
loft
do
you
want
to
give
us
the
updates.
C
Yeah
yeah,
so
one
of
the
big
news
is
that
the
we
have
cut
the
also
releases
of
the
two
teresa
providers
and
they
are
fully
exam
compliant,
meaning
you
get
references,
late,
initialization,
sensitive
field
handling
in
for
both
input
and
output,
connection,
details
and
every
like.
You
know,
good
thing
that
people
like
about
cross
playing
providers.
C
So
that's
the
that's
the
big
news
and
right
now
we
have
kept
those
providers
to
like
you
know
around
60
crds.
In
order
to
like
you
know,
get
community
feedback
and,
like
you
know,
let
them
try
to
break
those
resources
and,
like
you
know,
improve
them.
As
you
can
see,
the
first
of
this
was
actually
0.2.0,
but
now
they
are
like.
You
know,
zero
point,
two
point,
four
and
zero
point
two
point
two
which
were
released.
Like
you
know,
in
response
to
the
bugs
that
we
cashed
so
yeah.
C
I
would
like
to
invite
everyone
to
use
them.
Try
them
test
them
and
report
anything
that
they
would
like
to
be
changed
or,
like
you
know,
some
bugs
that
they
discover.
C
So
that's
that's
the
big
news
and
it's
the
third
bullet
point,
but
I'll
just
get
to
that
now
and
right
now
we're
planning
to
reach
200
coverage
in
the
next
two
weeks
for
those
two
providers,
meaning
that
aws
telephone
provider
has
765
resource
types
so
that
provider
tf
aws
will
have
765
crds
in
the
next
two
weeks
and
for
azure.
C
I
think
it's
around,
like
you
know,
650
or
something
so
that
has
like
you
know
some
implications
in
terms
of
scaling
the
api
server
and
we
will
like,
like
we
have
some
changes
on
the
wall.
You
know
for
crossplay
and
also
in
the
long
term,
we're
planning
to
patch
up.
We
were
planning
to,
like
you
know,
submit
some
upstream
patches
to
the
api
server
to
handle
that
many
crds
and
alpha
is
driving
the
whole
process
there.
But
at
the
end
of
the
next
two
weeks
we
will
have
an
option
for
people.
C
Like
you
know,
by
default
we
will
install
like
some
amount,
some
number
of
crds,
maybe
like
100
or
something,
and
you
will
be
able
to
choose
which
api
groups
you
would
like
to
install
we'd
like
to
be
included
in
the
installation
using
the
provider.
Object
that
way
you
will
be
able
to
like.
You
know
you
won't
have
to
have
a
cluster
with
like
no
800
crds
just
to
use
like
you
know,
10
of
them,
and
that's,
like
you
know,
already
a
problem
with
native
providers
as
well.
C
For
example,
I
remember
a
slight
message
from
a
user
that
they
were
installing
multiple
providers
and
started
to
get
client-side
throttling
for
all
of
them
because
of
the
discovery
client
and
how
keep
ctl
works
and
all
that
stuff.
So
it's
like
you
know
we're
kind
of
at
the
point
that
we're
we're
we're
making
it's
hard
to
process
yeah.
That
means
you
had
this
for
api,
so
we're
so
so
we're
kind
of
like
I'm
thinking
of
mitigations
there,
and
the
second
thing
is
a
guide
to
add
new
resources
available.
C
A
lot
of
people
ask
like
you
know:
how
can
we
get
started
with
tera
jet
and,
like
you
know,
like
you,
know,
hit
the
ground
and,
like
you
know,
implement
new
resources
or,
like
you
know
in
fact,
implement
new
providers
using
intellij,
so
we
have
added
hassan,
implement,
wrote
a
wonderful
guide
about,
like
you
know
how
to
add,
how
to
add
a
new
resource
to
provider
tf
aws,
so
you
can,
like
you,
know,
follow
this
or,
like
you
know,
just
read
it
to
see
like
you
know
what
it
takes
to
empower
to
include
a
resource
and
the
we
will
have
also
like
you
know
in
the
next
two
weeks.
C
Another
guide
that
will
let
you
create
a
telegraph
provider
from
scratch,
for
example,
where
people
ask
like
you
know:
hey
do
you
have
this
provide
like
cloudflare
provider,
let's
say
or
openstack,
especially
so
you
know
there
will
be
a
document
that
goes
step
by
step.
Hey
you
need
to
use
that
template
for
repository
and
then,
like
you
know,
take
your
step
to
bootstrap
the
provider
yeah
and
then
there
are
like
you
know
many
small
fixes
that
went
into
the
like.
C
You
know
these
branches,
so
yeah,
that's,
I
think,
roughly
the
summary
of
where
we
are
and
hopefully
in
the
next
community
meeting,
we'll
have
even
more
stuff
to
announce.
D
With
for
the
and
alpha,
I
guess
for
the.
D
Pr,
that's
open
to
filter
the
api
groups
that
are
deployed
by
a
provider.
Can
someone
please
open
an
issue
that
on
crossblade
slash
crossblade
that
describes
the
performance
reasons
for
doing
this?
D
I
saw
the
pr
was
open
yesterday
and
I
I
personally
have
the
context
of
I
think
what
is
motivating
it
happening
at
the
moment,
which
is
like
you
said
that
we're
seeing
discovery,
timeouts
and
things
like
that,
but
we've
discussed
again
out
of
band
on
slack
and
although
we've
discussed
other
potential
alleviations
for
that
discovery,
and
you
know
the
great
limiting
of
adding
crds
and
whatnot
and
then,
if
you
look
at
the
pr
that's
open
at
the
moment,
it
looks
back
to
issue
2122,
which
just
talks
about
irsa,
and
you
know
wanting
to
break
things
down
for
security
reasons.
D
So
I
get,
I
think,
the
there's
a
really
well
detailed
pr
from
out
there,
which
I
appreciate
but
like
the
actual
reason,
we're
doing
it
right
now
is,
is
not
super
well
captured.
It
kind
of
looks
like
we're
doing
it
for
authorization
reasons
when
in
fact,
I
think
we're
doing
it
for
performance
reasons
and
I'd
like
to
understand.
D
Given
that
we're,
we've
also
talked
about
some
other
options
that
might
work
I'd
like
to
understand
whether
we're
going
to
do
those
options
as
well,
like
you
know,
increasing
the
discovery,
client,
client,
side
of
qps
and
burst
and
rate
limiting
the
adding
of
apis
all
those
kind
of
things.
D
I
kind
of
want
to
understand
what
our
holistic
approach
is
here,
because
this
pr
sounds
a
little
bit
like
it
also
potentially
relates
to
some
of
the
stuff
that
dan
has
talked
about
in
the
past,
about
what's
the
word
like
sharding
or
provider
config.
So
I
just
want.
C
D
Sure
that
I
don't
work
kind
of
in
a
hurry
to
really
shift
these
territory
providers
and
block
ourselves.
But
I
want
to
make
sure
we're
working
cohesively
and
we're
sort
of
considering
all
those
different
variables.
F
D
Yeah
that
would
be
nice.
I
would,
I
would
probably
like
my
my
preference
would
be
definitely
if
we
just
had
an
issue
that
was
like
hey
we're,
seeing
these
performance
issues
when
there
are
a
lot
of
crds
and
as
well
as
linking
to
this
issue.
We
talked
about
some
of
those
other
options
that
we
had,
so
that
I
could
get
an
understanding
of.
You
know
why
we're
doing
this
one
first
as
a
solution,
are
there
other
solutions
that
will
also
do
as
well?
D
You
know,
like
the
rate,
limiting
and
all
that
kind
of
thing,
so
I
could
imagine
that
there
are
going
to
be
some
people
who
actually
do
want
to
have
hundreds
of
crds
and
like
have
them
available
and
we're
just
like
you
know.
Turning
some
off
won't
be
an
option
for
them
or
would
be
a
you
know
you
can.
You
can
run
other
tools
in
this
space
without
having
to
like
disable
parts
of
the
api,
so
definitely
be
good
to
understand
where
we're
going
with
this
longer
term.
F
A
Cool
sir
yeah
yeah,
thanks
for
that
upbringing
yeah
I
wanted
to
give
a
little
shout
out
to
helper
here
for
this
effort
here
on,
like
the
thoroughness
of
the
write-up.
Here
I
think
that's
it's.
You
know
it
helps
to
provide
the
context
at
least
of
what
is
enabled.
What's
the
experience
around
this
pr
and
then
also
the.
B
A
D
Yeah,
definitely
it's
a
it's
a
very
it's
something
that
people
should
take
inspiration
on
when
writing
pr's.
It's
super
handy
to
have,
though
you
know
detailed
user
experience
in
the
pr,
and
the
detailed
testing
definitely
helps
review
it
and
feel
confident
about
it.
A
Awesome
and
then
a
quick
question.
This
is
probably
a
dumb
idea,
so
I
recognized
that
first,
but
in
terms
of
the
example
yamls
is
there:
is
there
any
generation
that
can
be
done
for
those
not
necessarily
like
generating
valid
examples
with
with
good
values,
you
can
just
apply
and
run
but
like
generating
them
at
least
the
schema
of
them
of
like
generating
an
example,
yemen
with
all
the
required
fields,
so
that
it's
easier
for
a
human
to
come
in
and
be
like?
A
C
Yeah,
maybe
we
have
an
issue
regarding
their
generation
of
that
example.
Yeah
we'll
be
on
it
and
yeah,
but
like
the
rough
idea
was
that,
like
you
know,
there
are
some
repos
in
the
interest
in
terraform
providers
where
they
have
like
hcl
files
as
an
example.
So,
like
you
know,
maybe
one
way
it
could
be
like
you
know
to
convert
those
http
or
our
yaml
to
use
as
an
example.
But
I
don't
know
it's
it's
like
it's
not
like.
You
know
very
common,
like
even
like
you.
C
G
F
G
Yeah
so
like
we
can
just
dump
them
into
example,
folder
and
then,
like
people
can
just
fill
the
values
and
we
replace
them
with
the
field,
values
or
tested
values.
I
think
that
that
could
be
something.
C
They
could
be
like
commented
out
in
the
beginning
and,
like
you
know,
have
a
statement
up
there.
Like
you
know
hey.
This
is
like
you
know
the
base
yama
when
you
test
it
in
a
working
state.
Please
remove
the
commands
and,
like
you
know,.
D
C
D
C
Yeah
yeah,
we
haven't,
we
have
an
issue
like
you
know,
to
investigate
the
documentation
part.
So
at
some
point
we
will
have
those
dot
strings.
So
we
can,
like
you
know,
just
copy
the
same
thing
into
the
ammo
as
well,
because,
like
you
know,
after
all,
we
will
definitely
need
some
document
documentation
to
show
up
and
the
docs
is
that.
A
Awesome
yeah,
so
it
sounds
like
there's
some
possibilities,
then
for
bootstrapping
or
accelerating
the
effort
around.
You
know
getting
examples
in
as
well.
You
know,
obviously,
when
people
try
out
services
for
a
first
time,
then
you
know
from
the
community
then
contributing
the
example
that
they
used
to
get
to
test
it
out
and
is
obviously
really
effective
too.
So
that's
great
good.
Okay,
so
I'm
glad
there's
a
couple
different
avenues
there.
A
A
Let's
see
it's
a
quick
time
check
we're
about
halfway
through
the
hour,
so
I
think
we
yeah
just
keep
on
moving
along
here.
Let's
get
some
quick
updates,
then
on
the
major
cloud
provider
providers
and
and
then
we'll
move
on
past
that
so
aws
aaron.
Or
do
you
want
to
give
a
quick
update
there
on
some
of
the
progress.
C
Yeah,
I've
added
those
points,
so
I
can
give
a
quick
summary.
So
there
are
like
you
know,
incoming,
like
many
incoming
prs
to
aws.
Some
of
them
are
like
new
resource
prs,
as
you
can
see,
and
some
of
them,
like
you
know,
bug,
fixes
and
editions.
C
C
So
if
you
are
interested
in,
like
you
know,
being
a
maintainer
and
provider
aws,
we
would
definitely
appreciate,
like
you
know,
having
you
there
really
helping
us
with
the
prs
because
like
and
there
are
lots
of
pr's
and
because
again
we
have
the
ack
code
generation,
the
bar
to
add
a
new
resource
is,
like
you
know,
pretty
low,
and
the
awesome
comments
like
you
know
just
keeps
contributing,
but,
like
you
know,
in
some
cases
we're
not
able
to
keep
keep
up
with
that
pace
in
terms
of
reviewing,
so
I
would
like
to
call
out,
for
you
know
if
you
would
like
to
be
a
maintainer
in
that
people,
please
let
us
know
and,
like
you
know,
yeah,
that's
all.
D
Speaking
of
which
christopher
who's
on
the
call-
and
I
spoke
yesterday-
and
he
is
interested
in
becoming
a
maintainer
of
so
I
haven't-
had
a
chance
to
actually
respond
to
your
slack.
B
A
Wait,
that's
that
is
awesome,
yeah
and
as
moffat
was
saying,
that
is
a
great
way
to
get
involved
towards,
like
a
maintainer
path
is
just
adding
reviews
on
prs.
You
know
you
don't
always
have
to
contribute
code
immediately.
Providing
good
and
useful
and
insightful
feedback
is,
is
also
another
path
towards
becoming
a
maintainer.
So
that's
that's
always
really
really
helpful.
D
Yeah
definitely,
we've
we've
totally
seen
folks,
you
know
jump
in
and
start
you
know
giving
their
feedback
on.
You
know
you
can
approve
pull
requests
even
if
you're
not
part
of
the
org.
It
just
you
know,
isn't
binding
basically,
but
we
tend
to
look
for
that
and
you
know
we
look
for
folks.
Who've,
you
know
contributed
a
bunch
of
review.
You
know,
reviews
wise
or
just
opened
a
bunch
of
pool
requests.
Things
like
that.
So
totally
you
know
get
involved.
D
Typically,
we
will
notice
and
be
very
eager
to
have
you
help
us
out.
A
Yeah,
because
it
is
quite
appreciated,
absolutely
aaron
is
anything
else
you
wanted
to
add
for
aws.
A
Sounds
good,
let's
move
on
into
gcp,
so
hassan,
do
you
want
to
get
us
updated
on
gcp.
G
Yeah
sure
yeah,
we
don't
have
like
much
activity
on
provider
gcp
for
the
last
two
weeks
but
like
we
have
any
maintainers,
so
I
think
gabriel
is
already
in
the
call
I
guess
so
like
I.
I
would
like
to
thank
like
thank
you
for
your
all
of
all
of
your
efforts
and
like
really
appreciate
to
like
really
happy
to
have
you
as
a
maintainer
in
provider
gcp.
G
I
don't
know
like
if
he
wants
to
add
something
or
not,
but
basically
like
there
are.
There
is
one
new
resource
which
is
pops
up
subscription
and
also
some
other
minor
prs
merch.
They
are
mostly
fixed
fixes
in
in
readme
or
example.
So
I
didn't
list
them
here:
yeah,
that's!
Basically
it
for
provider
gcp.
H
A
Right
on
gabrielle,
I
would
love
to
see
that
effort
there
and
it's
definitely,
you
know,
helps
move
the
projects
forward.
There's
no
doubt
about
it.
So
thanks
a
lot,
awesome
and
so
I'll
pair
any
want
to
give
us
a
quick
update.
Then
on
azure
as
well
to
round
us
out.
F
F
You
know
which
introduces
a
set
of
arbic
related
resources
like
application,
service
principle
and
and
some
other
resources,
and
we
have
had
a
chance
to
do
the
initial
review
for
that.
So
those
are
the
basic
updates
from
the
provider
azure
site.
A
A
Okay,
so
that's
everything
for
releases
core
cross,
plane
providers,
so
we
can
go
down
and
move
into
the
community
topics
section
so
to
start
that,
one
out
quick
update
on
a
whole
bunch
of
content
over
the
last
couple
weeks
since
the
last
community
meeting
a
bunch
of
interesting
articles,
blogs,
live
streams,
videos
etc
are
now
available
for
your
consumption.
A
A
Add
a
little
color
and
insight
into
the
experience
on
that
one.
E
E
A
E
E
A
A
Good,
that's
cool
yeah.
That
was
that
was
particularly
particularly
good.
You
know
between
you,
two
that
was
like
really
good
feeding
officer
there.
I,
like
that,
a
lot
at
cubecon
we
did
a
crossband
office
hours
and
the
cncf
just
last
night
sent
along
the
recording
for
that
session,
a
lot
of
really
good
questions
from
the
community
and
thank
you,
everyone
for
helping
out
to
answer
those
questions
while
we're
moving
along
with
presenting
and
managing
all
that
a
lot
of
engagement
there.
A
A
So
just
the
one
that
the
cncf
itself
ran:
okay,
yeah,
that's
the
only
one
that
we
have
access
to
here.
That
I
know
of
at
least
yeah
and
victor
did
a
lot
of
like
five
or
six
maybe
office
hours.
Nobody
knows.
A
Yeah
it
was,
it
was
a
large
number,
and
so
that
was
really
cool,
seeing
a
lot
of
cool
topics
presented
on
and
and
the
engagement
there
too.
So
if
we
get
recordings
of
those,
then
we
should
certainly
publish
those
also,
and
then
dan
did
a
interview
with
the
new
stack
on
about
getting
the
project
to
incubation,
which
is
available
here.
Any
thoughts
on
that
one
dan
I
didn't
get
a
chance
to.
B
Yeah,
it
was
super
fun.
Obviously,
jared
did
most
of
the
work
around
incubation,
so
I
was
just
relaying
the
great
work
that
you
did,
but
it
was
cool
to
be
interviewed
alongside
constance
and
ted,
who
are
two
pretty
cool
folks
on
the
open,
telemetry
side
of
things
and
also
just
kind
of
like
compare
and
contrast,
the
experiences
of
the
projects
going
to
incubation
and
whatnot,
so
definitely
cool
to
do.
A
B
Yeah
I
was,
I
was
kind
of
close
to
the
cameras.
It
wasn't
the
best
arrangement,
maybe
you're.
A
Impo
imposing
awesome,
awesome,
yeah
thanks
for
doing
that,
dan
and
thanks
for
being
in
la
and
a
lot
of
a
lot
of
good
experiences
at
geek
on
there
and
then
there's
a
couple:
publications,
new
news
articles
about
cross
playing
recently
too
there's
one
from
tech
target.
Beth,
I
believe,
is
the
author
that
she
did
good,
pretty
good
insight
and
looked
into
some
interesting
things.
There
so
kind
of
a
different
angle
than
you've
normally
seen
write
up
some
crossbands,
so
that
was
pretty
cool.
A
To
see
link
is
there
dan
did
a
fantastic
blog
post
on
his
personal
blog
about
you
know:
packaging,
basically,
packaging
infrastructure
and-
and
you
know,
software
vendors
can
can
use
packaging
to
to
deliver
their
software
super
interesting
article
to
read
there
so
so
then,
vmware
and
amazon
both
have
blog
posts,
referencing
crossplane,
and
how
to
build
platforms
and
solutions
using
it.
So
a
lot
of
cool
write-ups
about
crossplaying,
a
lot
of
cool
stuff
going
on.
You
know
we're
getting
adoption
in
traction.
A
You
know
outside
of
just
our
community
here.
So
it's
all
really
cool
to
see
this
contents
here
so
feel
free
to
peruse
through
those
and
catch
up
on
the
latest
news
and
stuff
and
then
kubecon
north
america
was
last
week
in
la
as
we
were
just
talking
about
there.
Any
any
experiences.
Observations
insights
that
folks
wanted
to
share
that
were
attending
and
participating.
B
I'll
give
a
quick
update.
There
was
definitely
some
cross-plain
fans
there,
which
was
super
cool.
To
see.
To
be
honest,
there
was,
it
was
very
different
than
other
kubecons
in
that
it
was
mostly
like
maintainers
and
vendors
there,
so
there
wasn't
a
ton
of
like
selling
going
on
per
se,
which,
as
an
engineer,
I
obviously
like
that
quite
a
bit.
So
there
are
some
really
cool
opportunities
to
interact
with
other
projects,
though,
and
think
about
different
ways
that
we
can
partner.
B
One
conversation
in
particular
that
I
really
enjoyed
was-
and
it's
something
we've
actually
talked
about
doing
before,
but
was
with
oliver
gold
from
linker
d
he's
the
cto
over
at
buoyant
and
a
creator
of
the
linker
d
project,
and
we
had
a
pretty
long
conversation
about
their
multi-cluster
mesh
kind
of
solution
where
you
can
put
linker
d
in
two
separate
clusters
and
have
workloads
in
between
them
talk
to
each
other,
and
he
was
mentioning
that
they
have
a
lot
of
customers
who
say.
B
Oh,
this
is
really
cool.
I'd
like
to
be
able
to
do
this
across
geographical
regions
and
that
sort
of
thing,
but
like
it's
kind
of
arduous,
because
typically
software
is
packaged
in
a
way
that
it's
meant
to
be
installed
into
a
single
cluster
and
and
obviously,
in
this
case
right.
You
have
multiple
clusters
that
this
needs
to
go
into
each
of
them.
So
basically
each
time
you're,
stamping
it
out
right.
B
You
want
the
cluster,
and
then
you
want
things
inside
of
the
cluster
to
be
provisioned,
and
so
I
obviously
thought
that
was
a
great
use
for
crossplane
packages,
and
so
it
was
cool
to
think
about
what
it
would
look
like
to
have
a
configuration
package
that
did
kind
of
stamp
out
link
or
d
connected
clusters.
And
that
sounds
like
something
we
could.
We
could
definitely
do
a
cool
demo
and
actually
have
you
know
viable
use
cases
of.
A
Yeah
and
then
we
also
mentioned
the
office
hours
last
week
as
part
of
qcon
2..
That
continues
to
be
one
of
my
favorite
experiences
at
kubecon,
where
you
know
we
get
a
lot
of
folks
show
up,
there's
a
ton
of
really
cool
questions.
You
know
kind
of
makes
us
think
about.
You
know
some
of
the
things
we've
done
in
the
project
and
connecting
to
new
audiences
and
stuff.
So
I
really
really
like
the
office
hours
and
that
continues
to
be
one
of
my
favorite
parts
of
kubecon.
A
Now
so
yeah
there
were
a
couple
talks
at
coupon.
Also
that
were-
and
I
don't
I
don't
know
if
the
recordings
are
up
yet
they
may
be
already,
because
they
do
that
pretty
darn
quickly,
most
of
the
time,
but
a
couple
talks
that
we
were
kind
of
focused
on
crossplaying,
also
so
mauricio
from
vmware
did
a
talk.
That
kind
of
talked
about
a
few
different
tools
to
be
put
together
and
in
the
way
that
he
envisions
and
wants
to
see
software
delivered
now.
So
he
did.
A
He
really
really
gets
the
idea
of
crossplane
in
some
of
the
vision
there
and
some
of
what
dan
was
talking
about,
of
delivering
infrastructure
with
packages
and
and
things
like
that,
so
rare
seo
gets
it
and
it
was
that's
a
really
cool
talk
to
get
some
of
the
deeper
ideas
and
some
of
the
things
that
are
possible
today.
He's
got
a
demo
doing
it.
So
it's
not
just
vision.
It's
it's.
You
know
the
kind
of
the
higher
levels
that
you
can
reach
with
crossfade
functionality.
It's
really
cool.
A
The
google
folks
also
talked
about
various
ways
to
provision
and
manage
cloud
provider
resources
with
different
tools
in
the
ecosystem,
and
so
they
focused
on
crossplane
as
the
last
tool
in
in
that
arsenal
there.
It's
gotten
some
of
the
the
more
advanced
functionality
also,
so
that
was
a
really
good
talk
from
them
that
put
crossband
in
a
fairly
good
light.
A
I
think-
and
it
was
really
cool
to
see
the
google
folks
talking
about
it
like
that,
and
then
this
one
isn't
specifically
across
plain
focus,
but
it
was
a
lot
of
the
lessons
from
some
of
the
package
manager
and
you
know,
go
container
registry
stuff
that
we
do.
Do
you
want
to
give
a
quick
little
update
on
on
the
craziness
of
this?
This
talk
in
demo,
real
quick,
because
I
thought
it
was
insane
sure.
B
So
yeah
this,
this
talk
was
mostly
just
about
the
oci
distribution
spec,
which
is
what
so-called
container
registries
adhere
to
and
kind
of,
maybe
debunking
or
just
going
into
more
depth
about,
what's
actually
defined
in
the
distribution
spec
and
what
isn't
most,
notably
potentially,
and
so
it's
a
pretty
useful
resource.
I
gave
the
talk
with
john
johnson,
who
helps
run
gcr
over
at
google.
He
has
a
wealth
of
knowledge
in
that
as
well.
B
B
So
some
really
interesting
stuff
that
I
think
is
useful,
just
organizationally
for
for
folks,
and
then
we
finished
it
up
with
a
demo
where
we
demonstrated
what
a
registry
that
was
acting
as
a
chat
server
could
look
like,
so
you
could
basically
just
docker
run
a
container
and,
and
what
that
was
doing
was
basically
communicating
back
to
the
registry
and
every
message
was
actually
appended
as
an
upload
that
eventually
on
the
next
poll,
got
compressed
into
a
new
layer.
B
So
then
the
next
person
who
pulled
the
image
we
dynamically
append
that
layer
onto
the
image
and
then
serve
it
to
them.
So
you
can
get
your
whole
chat
history,
basically
in
the
file
system
and
then
you'd
connect
via
websockets
to
actually
do
the
chat
operations.
So
it's
kind
of
a
fun
thing
if
you're
interested
in
kind
of
like
misusing
registries,
if
you
will,
but
it
also
calls
out
to
some
of
the
decision
making
that's
behind
why
cross-plain
packages
are
the
way
that
they
are.
B
A
lot
of
folks
will
talk
about
oci
artifacts,
which
is
kind
of
a
common
trend.
Lately
we
do
not
use
oci
artifacts
for
crossland
packages
and
there's
some
justification
and
reasoning
behind
that
presented.
That
I
think
is,
is
fairly
compelling.
So
it's
worth
it
worth
a
watch.
If
you
are
super
bored
so.
A
Yeah
I
I
watched
that
talk
in
live
and
then
my
mind
got
exploded
a
little
bit
at
the
ends.
When
you
know
it's
like,
instead
of
doing
q
and
a
live,
they
just
used
the
the
chat
image
to
start
doing:
q
a
and
the
whole.
You
know
everyone
in
the
talk
was
interacting
off
platform
via
running
a
container.
It
was.
It
was
really
really
really
interesting,
really
surprising
too.
So
people
went
wild
for
that.
It
was
really
cool,
so
great
job
on
that
dan.
A
That
was
that
was
pretty
neat
anything
else
on
kubecon
or
observations
or
experiences
that
anybody
wants
to
share.
A
All
right,
then,
we
can
go
ahead
and
take
a
look
see
down
here
at
these
other
other
community
related
topics.
So
I
think
this
is
gabriel.
Did
you
add
this
one
on?
How
can
we
add
support
for
updates
on
identifier
fields
and
manage
resources.
H
Yes,
so
I
raised
this
issue
because,
when
I
were
developing
some
managed
resources,
there
are
some
fields
that
are
predictable
in
the
api,
for
example
in
the
name
of
the
field
of
the
resource,
but
for
cross
plane.
If
I
change
the
name,
it
doesn't
behave
as
expected,
for
example,
if
I
want
to
rename
a
github
repo
when
cross
plane
runs.
The
first
observed
methods
if
you
won't
find
the
repo
and
create
a
new
one,
because
it
will
make
a
get
request
with
a
new
name
and
not
the
last
name
and
change
it
later.
H
H
H
And
then
I
I
I
tried
to
propose
a
a
second
worker
around
so
but
I
don't
know
if
it's
good
I
and
is
my
comments
below
there
and,
I
said
to
add
an
annotation,
for
example,
a
lasting
name
or
something
like
this.
So
I
can
rely
on
the
annotation
and
not
the
status.
But
I
don't
know
if
it's
a
good
solution
and
I
would
love
to
see
your
inputs.
G
Yeah
yeah,
I
would,
I
would
just
like
to
add,
like
I
also
put
another
another
issue
next
to
it,
which
was
the
recent
issue
intelligent
but
like
based
on
the
discussions
we
had.
It
looks
like
this
is
not
something
terajet
specific
and
it
is
quite
related,
but
gabriel
is
asking
basically.
G
It's
a
similar
scenario
like
you
have
a
for
example,
you
know
a
v,
let's
say
you
have
a
vpc
and
then
you
have
an
external
name
assigned
and
you
go
and
delete
that
vpc
from
from
the
like
provider
and
then
crossplaying
creates
a
new
apc,
but
you
have
an
old
external
name
and
external
names
never
updated.
So
I
I
felt
like
this
is
like
related,
so
I
just
wanted
to
mention
before
we
dive
into
more
discussion.
A
Yeah
and
if
I
recall
correctly,
that
I
believe
nick
was
mentioning
somewhere,
I
don't
know
what
format
it
was
was
in,
but
nick
was
mentioning
recently
about
external
names
being
immutable
or
potentially
you
know
enforcing
it
down
that
path,
instead
of
explicitly
allowing
them
to
change
but
explicitly
preventing
them
from
changing.
So
I
think
there's.
I
think
this
is
a
broader
topic.
I
think
there's
a
lot
of
weird
implications
of
of
of
supporting
it
in
scenarios.
A
That's
that
you
might
not
have
the
right
information
to
make
an
informed
decision,
but
I
I
myself
am
not
completely
up
to
date
on
that,
so
maybe
nick
you
had
some
more
insight.
There,
too.
D
Sorry
folks,
I'm
kind
of
off
paying
attention
while
reviewing
other
documents
at
the
moment,
but
I
I
I
think
in
many
cases
external
names
tied
to
the
external
identifier
in
the
cloud
they
often
just
like
at
the
cloud
or
at
the
api
that
we're
abstracting
they
just
are
immutable.
Obviously
that's
not
the
case.
D
100
of
the
time
but
yeah
renaming
is,
is
a
little
tricky
right,
because,
if
you,
if
we
have,
if
we
have
the
name
of
the
thing-
and
you
say-
hey
change
the
name
of
the
thing,
then
we
would
need
to
somehow
remember
the
old
name
for
a
while
until
we
knew
that
that
name
had
changed.
So
I
I
definitely
think
that
this
is
something
that
warrants
you
know
an
issue
to
discuss.
You
know
warrants
warrants
further
discussion
before
we
like
figure
out
what
we
want
to
do
with
it.
D
E
It
might
be
it,
it
seems
to
me
like
this:
isn't
this
is
a
place
where
we're
violating
the
the
basic
idea
of
cross
plane.
We
are
allowing
someone
to
directly
edit
the
field
that
we
store
the
state
in,
and
instead
we
need
to
figure
out
a
way
for
them
to
communicate
that
they
want
a
state
change
in
the
spec
of
the
document
or
in
somewhere
in
the
resource.
That
is
not
editing.
The
actual
state
field
that
we
use
to
track.
F
So
in
a
similar
scenario,
let's
assume
that
you
have
a
terraform
configuration
and
either
by
importing
or
you
know,
just
applying
the
configuration
you
create
a
new
resource
or
import
an
existing
one
whatever
and
the
association
between
the
cloud
resource
and
the
configuration
entity
is
stored
in
the
terraform
state
right
and
if
you
delete
the
resource
cloud
resource
and
then
you
need
to
reassociate,
you
know
a
renamed
one
or
you
know
another
entity,
so
you
know
by
running
an
import
and
something
similar.
F
So
in
our
case,
for
example,
if
you
do
something
like
that,
if
the
cloud
resource
is
modified,
you
know
with
with
an
entity
other
than
crossplane,
then
that
reassociation,
like
you
know,
updating
the
external
name,
should
also
be
done
manually
right.
E
F
C
E
C
And
yeah,
so,
in
my
opinion,
the
renaming
feature
I
I
kind
of
think
of
like
now
closer
to
how
the
actual
like
like
in
the
beginning.
We
have
the
reason
we
have.
One
of
the
reasons
we
have
external
name
is
to
make
the
resource
identification
and
association
as
close
as
possible
to
the
kubernetes
api
object,
which
is
a
custom
resource.
So
that's
why,
like,
for
example,
by
default,
we
always
default
to
metadata.name
of
the
cr
to
the
external
name.
C
So
from
that
perspective,
I
am
kind
of,
like
you
know,
leaning
towards
having
users
recreate
the
whole
object
if
they
want
to
change
the
identifier,
for
example,
let's
say
in
in
deployment
that
it
creates,
like
you,
know,
parts
when
you,
you
can't
really
change
the
name
of
the
deployment
or
part,
but
if
you
would
like
to
like
create
a
new
pod
like
any
change,
essentially
triggers
a
new
creation
of
a
new
resource
and
will
be
the
new
name
and
all
that
stuff.
C
So
it
feels
like
you
know
if
we,
if
we
have
people,
recreate
the
resources
when,
if
they
want
to
like
rename
something
that
would
be
like
you
know
closer
to
how,
like
you
know,
parentheses
the
resources
at
the
high
level
and
at
the
level
from
technical
perspective.
C
I
think
it's
really
hard
to
be
able
to
capture
the
renaming
stuff,
because
there
are
also
references
that
are
resolved
one
time
and
also
it's
really
hard
to
like
you
know,
for
example,
let's
say:
10
resources
refer
reference
to
a
single
one
and
when
you
rename
it
the
whole
thing
changes
and
some
of
them
are
like
you
know,
reference
are
immutable
so,
like
the
whole
graph
of
the
resources
is
affected.
C
So
I
would
kind
of
lean
towards,
like
you
know,
having
people
recreate
the
whole
resource
if
they
need
to
change
the
external
name
for
one
reason
or
another,.
D
Yeah,
it's
kind
of
tricky.
It
seems
like
sorry,
I'm
catching
up
with
this
now
and
reading.
Really.
The
actual
issue
that
gabriel
raised.
My
guess
is
that
this
case,
where
an
api
even
lets,
you
change
its
unique
identifier,
is
pretty
rare.
It
sounds
like
this.
This
does
happen
for
resource
record
set
in
dns,
google
gcp
dns,
and
it
looks
like
looking
at
the
api.
D
What
happens
is
the
name
of
the
record
set
is
part
of
the
url,
but
then
you
can
do
a
patch
to
that
url,
including
the
name
that
changes
the
name.
So
presumably
that
would
be
you
know
the
url
would
then
change
it.
If
you
tried
to
repeat
that,
you
know
it
wouldn't
be
important
right.
If
you
tried
to
do
it
again,
it
would
fail
and
say
it
succeeded
the
first
time
and
now
the
url
isn't
there
anymore,
because
the
because
the
name
has
changed.
D
So
you
know
to
move
off's
point.
If
we
just
try
and
like
copy
kubernetes
semantics,
you
just
can't
change
the
metadata.name
of
a
resource.
That's
that's
not
allowed,
but
then
we
end
up
putting
an
artificial
constraint
on
this
education
api
where
we'd
say
you
just
can't
change
the
name
of
a
resource
record
set
in
place,
even
though
you
technically
could
with
the
api.
D
So
I
think
similar
to
what
alpha
was
getting
at.
If
you
look
at
how
terraform
handles
this,
they
have,
they
have
both
the
id
field
and
then
also
a
field
that
usually
just
duplicates
the
id.
If
I
understand
correctly
so
they'll
have
like
and
the
id
is
not
exposed
to
users.
It's
not
part
of
the,
like
user
facing
schema,
it's
an
internal
tracking
thing
in
the
state
right.
D
So
I
don't
know
like
one
alternative.
If
we
were
like
fully
rethinking
external
names
would
be
to
go
to
a
similar
model
to
terraform,
where
we
just
duplicate
that,
where
there's
both
like
a
name
field.
That
is
the
declared
state
of
what
you
want,
the
name
to
be
which
in
99
cases
out
of
100,
you
would
not
ever.
It
would
be
immutable
basically,
and
then
there
would
be
the
you
know,
external
name
or
external
id
field
which
was
like
what
it
actually
is
at
the
moment.
D
So
we
could,
you
know,
potentially
decouple
those
I'm
a
little
on
the
fence
about,
like
I
kind
of
want
to
find
whether
there's
you
know
how
many
more
cases
there
are
where,
like
this,
is
actually
possible
before
I'd.
You
know
want
to
fundamentally
change
how
external
names
work
to
handle
this
case
personally.
H
For
example,
in
my
company
we
are
developing
a
provider
for
azure
devops
and
every
resource
there
supports
the
update
for
the
name
so
for
every
managed
research.
We
do.
This
rely
on
this
status.
That's
one
of
the
problems.
If
you
want
to
give
this
provider
to
the
community,
because
we
would
need
to
change
all
of
the
managed
research
that
we
already
developed,
and
we
would
need
to
change
this
and
like
remove
the
feature
to
name
rename
the
resource
and
it
feels
like
the
cross
plane
is
always
trying
to
reflect
the
api.
H
But
in
this
case
I
think
it's
basic,
because
you
are
just
removing
a
feature
that
api
has
is
to
rename
the
resource
and
we
are
removing
this
because
of
the
limitation
of
the
this
mod.
The
way
I
was
trying
to
find
another
way
to
to
support
both
cases,
not
like
breaking
everything
from
cosplaying,
as
you
said
like,
if
you
need
to
do
like
the
form
that
has
this,
the
ig
farter
affirmative
for
the
api
is
separate.
H
So
it
won't
have
this
problem,
but
I
think
we
can
try
to,
as
I
propose,
maybe
some
notation
for
this.
I
don't
know
if
it's
too
bad,
I
don't.
I
was
just
trying
to
find
the
middle
the
case
that
won't
break
anything
for
cross
playing
and
once
remove
the
feature
to
rename
some
resources.
D
Yeah
yeah,
I
mean
to
be
fair.
I
think
what
you
just
described
is
how
it
actually
is
today
that
we
are
for
a
subset
of
apis
not
supporting
a
feature,
but
just
to
be
clear
that
wasn't
a
conscious
decision
that
we
made
it
was.
It
was
more
of
a
we've,
never
run
into
use
cases
until
now,
where
you
could
change
an
external
name
in
flight.
A
lot
of
the
time.
D
There
are
resources
where
you
can
change
the
name
or
the
you
know
the
the
human
presented
name
right,
but
then
they
also
have
some
kind
of
identifier
like
a
arn
or
something
like
that.
That's
actually
what
uniquely
identifies
them
that
you
look
them
up
by.
So
if
you
could
just
drop
a
comment
about
that,
azure
devops
use
case
on
your
issue
as
well
gabriel.
That
would
be
just
handy
to
have
you
know
more
supporting
data
that
you
know.
It's
not
just
resource
record
set
that
there
are.
D
You
know
other
other
cases
where
that
exists.
That
would
be
handy,
I
feel
like
you
know.
We
have
managed
resources
for
sql
databases.
I
feel
like
those
are
renamable
as
well.
So
that's
another
potential.
E
D
E
D
Have
typically,
we
don't
typically
duplicate
the
externally.
The
external
name
does
like
a
lot
of
heavy
lifting
right,
but
the
the
half
remembered
history
here
from
years
ago,
was
that
originally
we
actually
were
inconsistent.
We
had
some
resources
that
just
took
the
metadata
dot
name
of
the
kubernetes
resource
and
used
that,
to
name
you
know,
the
gke
cluster
or
the
record
set
or
whatever,
and
obviously
that
metadata
domain
is
just
fundamentally
immutable.
You
can't
you
can't
change
that.
D
D
And
at
that
time
we
had
resource
claims
working
a
different
way.
We'd
often
run
into
issues
where,
like
we
wanted
to
automatically
generate
like
a
gcp
bucket
or
an
s3
bucket,
or
something
like
that
you
had
to
like
somehow
set
like
the
name
field
at
the
spec,
and
it
also
just
like,
wasn't
predictable
like
it
wasn't.
You
know
the
name
field
wasn't
in
the
same
place,
every
time
everyone
had
to
go
and
like
read
for
each
managers
and
let's
find
out
which
field
was
the
name
and
then.
D
Furthermore,
we
had
this
case
with
a
lot
of
aws
resources
in
particular,
and
just
in
general
out
there
in
the
world,
there's
a
lot
of
apis
that,
just
like,
don't
give
you
a
choice.
What
the
name
is
that
you
create
the
thing
that
they
just
tell
you:
okay,
it's
unique
identifier
as
this,
so
it's
not
an
input.
It's
an
output
that
you
have
to
capture
so
we'd
like
to
address
all
of
this
by
adding
that
external
name
annotation,
and
we
explicitly
removed
the
name
from
the
spec.
So.
B
D
Well-Formed
or
compliant
kubernetes
cross-plate
resources,
rather
don't
have
an
external
name,
annotation
and
also
a
name
at
the
spec.
At
the
moment
they
just
have
the
external
name
annotation,
and
we
use
that
just
to
send
the
name.
D
You
know.
Maybe
that
was
a
misstep,
and
maybe
we
should
have
the
name
as
well,
but
there
will
be
issues
with
that.
You
know,
as
I
just
described,
that
like
folks,
want
to
set
that
name
or
influence
that
it'll
be
it'll,
be
tough
to
do
it
most.
People
kind
of,
as
my
bet
was
that
most
people
kind
of
just
want
the
name
to
be
set
to
the
same
thing
as
the
kubernetes
name
like
in
the
common
case,
which
can
be
done
easily,
with
with
the
external
name
annotation
but
harder.
D
So
yeah
there
there
isn't
a
great
way
to
do
this
at
the
moment.
I
think
you
know
the
the
lowest
touch
would
be
kind
of
what
gangrene
was
saying
right,
which
would
be,
I
don't
know,
maybe
we
add
another
annotation
which
is
like
you
know,
cosplaying
value,
slash
change,
my
external
name
or
something
like
that
or
new
external
name
right,
and
that
way
we
have
the
state
required
to
do
what
we
would
need
to
do.
So
you
know,
even
if
we
lose
everything
else,
we
have
something
tracking
the
al.
H
Yes,
what
I,
what
I
was
trying
to
propose
is
not
the
user
to
define
a
new
annotation,
but
the
the
the
operator
itself
is
going
to
create
the
notation
transparency
for
the
user.
So
if
I
do
a
get
request
successfully,
I
will
save
this
this
last
scene
name
in
annotation
and
then,
if
I
try
to
make
another
catch
request
in
the
future
that
fails,
I
will
try
again
with
the
last
one.
H
So
if
the
first
fails
and
the
second
one
succeeds,
it
means
that
the
first
one
is
actually
the
new
name
that
the
user
wants.
So
I
will
rename
the
resource
with
the
fails
name.
You
know,
because
if
we,
if
you
add
new
annotation
for
the
user,
to
feel,
I
think
it's
going
to
be
a
bad
experience
for
them.
But
if
we
do
this
invisible
for
them,
it's
going
to
be
like.
They
won't
even
see
this
happening,
because
it's
just
handled
by
the
cross
playing
the
operator
itself.
D
Maybe
we
we
would
have
to
with
the
implementation
of
the
managed
resource
reconciler.
I
I
don't
think
there'd
be
a
way
to
do
this
transparently,
because,
like
you
say
we
would
have
well.
D
I
can't
see
a
way
to
do
this
without
doing
updates
to
like
every
every
controller
right,
because
they
would
then
need
to
have
the
logic
to
try
the
external
name
annotation
to
get
the
thing
and
then,
if
that
fails,
then
try
again
with
like
the
backup
external
name
annotation
or
you
know
the
sort
of
last
observed
name
yeah
this
distraction-
I
I
don't
wanna,
I
don't
have
a
chilling
effect
on
this
conversation,
but
it
strikes
me
something
that
we're
probably
not
gonna
come
up
with
a
you
know,
a
really
good
design
on
this
call
for
it
sort
of
thing.
H
Yes,
yes,
what
I
try
to
do
is
because
this
this
provider,
refresh
devops,
is
private.
For
now
I
will
try
to
do
it
public
and
share
with
you
the
implementation.
So
you
can
see
what
we
are
doing
now
to
work
around
this
issue,
and
maybe
it
can
get
some
insights
for
new
proposals
to
resolve
this.
D
You
know
understand
again,
you
know
azure
devops
resource
record
set
like
what
kind
of
a
priority.
This
is
sort
of
thing,
because
I
think
anything
we
do
with
external
name.
While
what
you
proposed
is,
you
know,
probably
the
least,
impacting
most
most
sort
of
transparent
thing.
Anything
we
like
external
external
identity
is
like
a
pretty
cool
part
of
cosplay
right,
so
something
I
want
to
be
very
careful
about
making
changes
too,
but
I
guess
is
where
I'm
going
with
here.
H
G
I
I
would
ask,
like
you,
know
like
right
now.
I
think
there
is
no
way
to
change
the
external
name
in
in
return
to
methods
right,
because
there
is
no
such
a
field
like
we
have
in
create,
like
external
name,
changed,
or
something
like
that
like
if
we
add
that
field
and
for
for
those
hk's
resources,
if
we
have,
for
example,
a
spec
dot
name,
so
that
the
controller
itself
can
return
if
it
changes
the
updated
external
name.
G
D
I
I
guess
what
I'm
saying
here
is
like
this
is
like
a
fundamental
change
to
the
xrx
right,
so
we're
gonna
say
all
resources
need
a
spec.name
now,
as
well
as
a
spec.external
name,
that
changed
warrants
at
least
a
design
document
to
make
it
happen,
sort
of
thing.
So
I'd
like
to
push
I'd
like
to
I'd
like
to,
maybe
you
know,
take
this
conversation
and
maybe
move
it
into
into.
You
know
more
of
a
one-pager
or
you
know,
speculation,
speculation.
There.
D
There
was
a
reason
historically,
like
we
thought
about
having
a
spec.name,
I
believe,
and
we
ended
up
going
with
an
annotation.
I
forget
why
so
there's
probably
like
a
lot
of
history.
We
can
pull
together.
You
know
aaron
just
dm
to
me
and
I
think,
move
after
shared
an
issue
that
was,
you
know,
an
existing
discussion
about
what
we
want
to
do
with
external
name
and
again,
there's
there's
an
issue,
I'm
sure
we
could
find
where
we
like,
invented
externally.
A
Makes
sense:
oh
yeah,
thanks
for
bringing
this
up
at
the
first
place
gabriel,
and
it
definitely
does
require
some
more
more
deeper
discussion.
We
got
into
some
of
the
some
of
it
right
now
in
this
meeting,
so
that
was
a
good
start
at
it.
So
we.
A
Offline
or
indicate
have
issues
or
get
to
one
page
or
whatever.
It
may
be
right,
sweet,
so
we're
a
bit
over
time
now.
So
let's
go
ahead
and
wrap
it
up
then,
for
the
day
and
so
yeah
thanks
for
everybody
joining
in
and
all
the
updates
and
the
engagement
here
and
definitely
appreciate
it
and
we'll
keep
everything
continuing
on
github
and
slack.