►
From YouTube: 2019-07-23 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).
B
Awesome
so
it
is
July
23rd.
This
is
the
crossplane
community
meeting
I'm
sitting
in
for
Jared.
Today
my
name
is
Daniel,
so
I've
got
a
pretty
good
number
of
community
members
here
today.
B
Basically
right
now
we're
looking
at
a
lot
of
sort
of
restructuring
of
the
project
right
now
so
version
0.3
kind
of
started
with
a
technical
debt,
prioritization
effort
and
that
led
to
some
design
discussions
that
we've
been
having
on
various
pull
requests
and
such
and
and
that'll
be
reflected.
But
there's
a
lot
of
kind
of
inner
dependency
on
some
of
these
things.
So
I'll
start
by
saying
some
of
the
things
that
have
been
implemented
and
then
some
of
the
things
have
dependencies
on
each
other,
so
starting
out
default
resource
classes.
B
These
have
been
implemented
so
basically
for
the
generic
resource
class
kinda
they
have
right
now
you
can
specify
it
as
default
for
a
given
claim
kind
and
if
you
leave
out
the
class
reference
for
the
claim
it
will
default
to
the
resource
classes,
specified
it
as
the
default
for
that
claim.
So
this
is
functional
right
now
it's
been
merged.
That
being
said,
there's
probably
going
to
be
some
updates
to
this
because
of
a
desire
to
move
to
strongly-typed
resource
classes.
So
this
is
a
design
document.
That's
out
right
now.
B
So
if
we
looked
here
in
this
document,
a
little
bit
out
of
date
at
this
point
with
some
of
the
reviews
that
have
been
going
on,
but
essentially
what
we
want
to
do
is
move
from
all
resource
classes
being
of
kind
resource
class
to
being
more
specific,
so
something
like
RDS
instance
class.
So
it
would
be
strongly
typed
one
to
one
with
the
managed
resource
kind.
So
that
would
be
like
an
AWS
RDS
instance
or
a
Google
Cloud
sequel
instance.
The
classes
would
be
strongly
typed
in
that
manner.
B
However,
there's
some
issues
that
come
up
with
with
trying
to
default
with
that,
because
you
don't
know
what
to
watch
for
anymore
when
before
we
are
watching
for
just
the
resource
class
kind.
Now,
there's
an
arbitrary
number
of
kinds
that
we
could
need
to
watch
for.
So
there's
some
discussion
here
on
the
Nick's
provided
some
really
valuable
feedback,
and
essentially
the
main
thing
that
we're
looking
at
here
is
I'm
in
moving
to
these
strongly
typed
resource
classes,
where
there
could
be
an
arbitrary
number
of
kinds
of
resource
class.
How
do
we
do
that
defaulting?
B
So
the
initial
proposal
was
that
we
create
a
new
custom
resource
called
a
default
ur
or
we
could.
That
name
is
still
up
for
debate,
but
that
was
just
a
proposal
where,
essentially,
you
specify
a
resource
class
that
should
serve
as
default
for
a
given
claim
kind,
so
claim
clang
would
be
the
abstract
type.
Like
a
my
sequel
instance,
the
resource
class
would
be
an
RDS
instance
or
something
of
that
nature
and-
and
you
basically
just
by
those
things
together,
so
it
knows
to
look
for
that
kind
for
for
the
given
claim
kind.
B
So,
once
again,
looking
at
this,
we
can
see
a
little
bit
what
this
looks
like,
so
the
defaulter
would
say
something
like,
and
this
would
be
changed
to
kind
here,
so
it
would
say
something
like
RDS
instance,
class
name
and
namespace
for
a
given
RDS
instance
class
had
been
created
and
then
it
would
specify
what
its
default
for
so
on.
My
sequel
instance
would
default
to
this
RDS
instance
class
standard,
my
sequel
and
crossplane
system,
so
that
was
the
initial
proposal,
Nick
kind
of
countered
with
a
another
proposal
of
using
mutating
web
hooks.
B
So,
essentially,
in
that
proposal
you
would
need
to
create
a
different
mutating
web
hook
for
each
claim
to
class
tupple,
which
he
specifies
here
and
it
would
say,
basically
apply
this
default.
If
this
mutating
web
hook
configuration
has
been
registered
and
then
you
have
a
mutating
web
hook
controller
that
would
basically
make
sure
that
there's
only
one
mutating
web
hook
for
a
given
claim
kind.
So,
anyway,
there's
a
lot
of
background
there.
We
don't
want
to
get
too
deep
into
that
right.
B
C
The
I
won't
ask
about
the
medieval
book
configuration,
so
you
said
like
we
need
one
for
each
of
them
Ryan.
So
at
some
time
ago,
I
implemented
it
at
machine
map
book
not
imitating
one
but
I
think
hitting
is
also
too
similar.
So
as
far
as
I
remember,
it's
like
you,
build
a
server
and
you
create
a
leprechaun
figuration
and
specify
like
what
types
that
will
go
through
that
server
and
like
in
one
configuration
we
can
statically
specify.
B
For
sure,
so
that
that's
that's,
how
I
understand
it
as
well?
The
the
complexity
kind
of
arises
in
the
fact
that
you
could
potentially
have
an
arbitrary
number
of
types
that
could
serve
as
default.
So
every
time
you
installed
a
new
provider
that
could
provide
new
resource
classes
that
could
serve
as
default
for
a
claim.
Kind.
B
Right
and
and
that's
pretty
in
line
with
and
I've
linked
to
here,
you
can
actually
just
specify
that
in
queue
builder,
as
we
kind
of
do
for
implementing
our
CR
DS.
So
you
can
look
through
those
links
there
or
anyone
can
especially
this
one
right
here.
It
kind
of
shows
how
you
can
implement
a
mutating,
webhook
and
install
that,
but
all
of
that
kind
of
goes
back
to
this
overarching
discussion
around
this
kind
of
mono
repo,
vers
multi
repo
topic.
B
You
know
that
the
reason
why
we
have
to
have
that
sort
of
ability
to
support
an
arbitrary
number
of
default
resource
classes
is
because
there's
ability
to
install
resource
classes
at
any
point,
an
arbitrary
number
of
them.
So
this
discussion
here
affects
a
lot
of
different
things
and
one
of
the
most
pertinent
to
that
discussion
is
Nick's
PR
around
the
shared
managed
resource
reconciler.
B
So
if
we
want
to
take
a
look
at
that-
and
this
is
a
pattern
that
we've
kind
of
been
implementing
across
different
types
of
controllers-
so
we've
already
implemented
this
with
a
claim
controller
and
the
current
implementation
of
the
default
class
controllers.
Where,
essentially,
you
have
different
controllers
for
each
of
these
different
resources,
but
they
share
a
common
reconciler
pattern.
So
you
implement
something
like,
for
instance,
in
this
managed
resource.
B
C
Yeah
I
mean
like
pretty
much
is
just
summed
up:
I
mean
the
goal
for
this
PR
is
that
want
to
make
it
easy
for
the
collaborators
to
implement
their
own
controllers,
and
second,
is
that
we
actually
want
to
keep
the
like
the
construct
pattern
stable.
So
that,
like
we
know,
what's
happening
around
and
then
people
would
go
and
use
that
stuff,
but
also
you
know
it's
not
an
API
designed.
So
we
don't
really
limit
anyone.
C
It's
just
like
a
pattern,
so
yeah
I
think
like
like
after
one
or
two
rounds
that
will
be
ready
and
depending
on
the
like
mono
repo
mode
to
repo
like
in
case
of
motor,
but
we
will
probably
refactor
the
existing
ones.
The
controllers,
but
people
with
mono
repo
I
think
I
would
just
in
fact
a
few
of
them
and
then
later
on
visit
the
other
ones.
Absolutely.
B
I
think
there's
a
really
good
summary.
Thank
you
for
that.
I
think.
One
thing
you
said
that
was
really
important
about
this
PR
here
is
in
this
general
pattern
is
that
we
provide
a
standard
way
to
implement
controllers,
but
we
don't
it's
not
restricting
in
any
way
right,
like
you
said,
so,
if
there's
still
kind
of
custom
functionality
that
needs
to
be
implemented
for
a
various
you
know
set
of
infrastructure
resources,
we
don't
prohibit
that
from
happening.
B
We
simply
say
this
is
a
standard
pattern
and
we
really
increase
the
velocity
of
infrastructure
stack
developers
so
that
they're
able
to
implement
things
a
lot
more
quickly
if
they're,
following
that
kind
of
standard
pattern,
which
should
be
as
Nick
says
here
somewhere
in
the
PR,
for
you
know
around
80%
of
managed
controllers.
This
will
probably
be
the
pattern
that's
followed
and
obviously
that
could
evolve
over
time,
but
I
think.
B
Another
good
thing
you
brought
up
is
that
you
know
the
effort
after
implementing
this
will
kind
of
be
different,
based
on
how
we
go
about
splitting
the
repository
into
multiple
repositories,
which
I
think
is
sort
of
the
pattern
that
we're
settling
on
here
so
I
think
the
the
following
things
to
once
this
becomes
mirja
Bowl
and
gets
implemented
is
probably
just
split
out
those
repositories
and
then
implement
individually
in
each
of
those
which
shouldn't
be
too
different
from
implementing
them
within
this
single
rico
as
well.
So.
D
I
have
a
question
and
so
you're
saying
the
reason
for
multiple
repositories
just
because
you
want
to
be.
You
want
to
have
you
to
give
the
possibility
of,
like
writing
extensions,
not
necessarily
use
default
controllers,
but
then
why
do
you
want
to
have
a
like
a
different
repository?
We
ended
up
be
possible
just
like
having
the
same
repository
so.
B
Right
now,
for
instance,
we
have
you,
know
GCP
AWS,
as
your
on
this
repository
I,
think
the
real
reason
of
wanting
to
separate
them
into
different
repositories
is
that
it
kind
of
isolates
their
lifecycle
right.
So
there
may
be
an
update.
Let's
say
that
needs
to
happen
to
GCP,
or
they
may
be
moving
at
a
different
pace
than
the
AWS
project,
and
we
kind
of
want
that
lifecycle
and
workflow
separate
from
the
core
crossplane
implementation
and
then,
as
we
continue
to
add
more
and
more
providers,
it's
also
an
opportunity
to
say
hey.
B
D
Yeah,
it
makes
sense.
I
haven't
worked
with
github
repositories
before
but
like
I
do
remove
just
one.
One
thing
that
comes
to
mind
is
like
when
you
have
multiple
clusters,
usually
they're,
also
a
lot
of
like
overhead
work
that
you
have
to
do
compared
to
having
just
one
single
depositories
and
then
having
multiple
artifacts
coming
out
of
that
butBut
I'm.
Fine
I
would
just
like
I
think
it
makes
sense,
but
yeah
we'll
see
how
it
goes.
Cool.
B
Yeah
I
definitely
think
so
and
just
to
be
clear,
so
the
the
other
repositories
would
be
running
as
like
separate
binaries
that
are
installed
in
the
cross
plane,
but
yeah
there
would.
There
would
definitely
be
some
some
orchestration
involved
in
kind
of
like
maintaining
all
those
repositories,
but
I
think
that
you
know
the
goal
eventually
is
for
us
to
bring
more
people
in
and
have
those
be
opportunities
for
people
to
own
those
projects
and
infrastructure,
stacks
and
kind
of
grow.
B
The
community
in
that
way,
so
I
think
that
that
would
be
a
great
opportunity
as
well
I'd.
Anyone
else
have
questions
or
comments
on
this
pattern
of
sort
of
a
shared
reconciler
that
we've
now.
This
would
be
the
third
time,
we've
kind
of
implemented
this
pattern
into
crossplane
or
questions
or
comments
around
the
splitting
into
multiple
repositories
and
really
just
keeping
like
claims
that
abstract
portable
kinds
in
the
core
and
every
other
specific
kind,
that's
specific
to
any
type
of
infrastructure
implementation
in
separate
repositories.
Oh
I.
D
Have
a
follow-up
question
on
that
and
again
this
is
more
coming
up
on
me.
Understand
me
how
things
are
not
necessarily
giving
unit
directions.
So,
if
we're
using
multiple
repositories,
do
we
have
any
common
code
that
we
have
to
replicate
over
multiple
paths
stories
or
are
there
any
thoughts
of
like
them
using
a
shared
repository
or
they
get
packaged
to
be
able
to
write
extensions,
absolutely.
B
So
that's
a
good
point
and
that's
very
pertinent
to
this
actual
PR
right
here,
so
this
shared
resource
reconciler
and
it
may
be
useful
and
I'll
transplant
too
much
time
on
this,
because
it
is
the
community
meeting.
So
I
don't
want
to
get
too
deep
technically
in
a
single
issue.
But
if
you
look
in
here,
if
we
look
in
the
resource
package,
we
have
these
kind
of
shared
reconciler
here.
So,
let's
see,
if
we
look
here,
this
is
a
reconciler
that
is
shared
among
claims.
It's
a
claim
reconciler!
So
right
now.
B
Currently
this
claim
reconciler
is
implemented
in
various
controllers,
for
let's
say
like
an
AWS
bucket,
it's
calling
the
resource
new
claim
reconciler
here.
So
the
the
other
repositories
could
follow
that
same
pattern
right
and
import
that
resource
package
that's
currently
available
and
they
could
do
the
same
for
manage
resources
and
default
classes.
Isn't
that
sort
of
thing.
E
I'm
throw-in
a
comment:
I
also
think
that
it
helps
when
things
are
all
split
out
compared
to
what
everything
is
in
a
mono
repo,
where
we
only
have
these
golden
providers
available,
because
the
developers
will
tend
to
shake
to
take
short
cuts
that
are
to
the
benefit
of
those
internal
providers
and
when
and
when
you're
coding
everything
as
an
external
as
an
external
provider,
you
can't
take
those
shortcuts,
and
so
then
everybody
gets
you
know,
is
working
on
the
same
field.
I
know
it's
providers.
I've
worked
in
the
past.
E
B
I
mean
it's
a
great
point,
so
the
next
topic
we
have
here
is
this
one
pager
around
resource
usage
that
Nick
has
been
working
on
here.
This
is
pretty
extensive
and
it
has
a
lot
of
sort
of
touch
points
and
other
areas
that
we've
already
discussed
so
looks
like
Marcus
you've,
given
some
feedback
here
and
there's
like
I,
said:
there's
a
lot
of
different
things
in
here
that
affect
things
like
you
know.
Reclaim
policies
even
have
touch
points
and
the
splitting
between
repositories-
and
things
like
that.
B
E
B
Absolutely
so
I
think
in
terms
of
looking
at
this
as
a
sort
of
constructive
document
for
us
to
pull
things
from.
It
might
be
useful
to
break
it
down
further
and
I'm,
not
sure
that's
something
we
should
necessarily
do
this
meeting,
but
essentially
a
lot
of
the
the
discussion
in
here
is
about
isolation
of
resources
and
also
about
things
like
connection
details
and
secrets,
and
that
sort
of
thing
and
they're
all
separated
here
so
I
think
that
the
best
course
of
action
would
be
to
if
you're
interested
in
this.
B
If
you're
on
this
call
to
kind
of
look
through
here
and
maybe
pick
out
a
certain
area,
you
know
where,
where
you
see
a
particular
point
that
you
want
to
kind
of
contribute
to
so
resource
usage
is
one
resource
secrets
is
another
and
then
there's
kind
of
some
questions
in
here
about
what
what
needs
to
be
done
and
what
things
are
still
open-ended.
So
I
think
this
will
continue
to
evolve
over
time,
but
in
terms
of
tangible,
specific
work
that
goes
towards
it.
B
All
right
so
we'll
leave
that
one
to
be
investigated
further,
and
we
already
talked
here
about
kind
of
the
strongly
type
of
resource
classes
one-pager
on
those
what
I
brought
up
earlier.
So
it's
kind
of
right
now
it
looks
like
it's
a
discussion
between
sort
of
that
new
custom
resource,
the
defaulter
or
the
mutating
webhooks.
So
if
you
want
to
continue
to
that
conversation
hop
over
to
that
pull,
request
and
jump
in
on
on
me
and
nick's
conversation
there,
I
just
wanted
to
also
point
out
some
time
here
for
anyone.
B
Who's
been
kind
of
working
on
the
stacks
effort,
which
is
the
the
rebranding.
If
you
will
of
the
extensions,
would
have
previously
been
called
extensions.
So
you
can
see
here,
marcus
is
actually
going
about
and
doing
some
renaming
there
and
the
design
doc.
Is
there
any
particular
topics
within
the
stacks
realm
that
wanted
to
be
brought
up?
I
know
we
had
talked
a
little
bit
also
on
an
issue.
B
E
Go
over
some
of
the
things
that
were
considering
now,
so
you
mentioned
renaming
renaming
stacks
and,
in
part,
that's
because
they're
not
strictly
extensions
to
crossplane
that
they
can,
as
we've
seen
with
the
get
lab
application,
we've
seen
that
stacks
can
also
install
applications.
So
there's
some
thinking
right
now
about
whether
or
not
infrastructure
stack
should
be
separated
from
application
stacks
well,
along
with
the
security
ramifications
that
go
with
that
on
either
side.
There's
some
thoughts
about
what
cluster
scoping
versus
named
scoping
versus
namespace
scoping
of
of
the
stacks
themselves.
E
There's
some
thinking
around
the
one
of
the
primary
components
of
what's
taxes,
which
is
to
resolve
the
these
packages
or
the
dependencies.
So
if
we're
installing
get
lab
and
get
lab
requires
some
GCP
provider,
then
it
needs
to
know
to
figure
that
out
and
get
that
package
installed.
Also,
especially
this
also
comes
into
when
we're
talking
about
splitting
the
splitting
crossplane
up
by
provider.
E
There
are
additional
lifecycle
management
issues
to
consider.
So
what
happens
when
versions
of
of
a
stack
when
you
want
to
upgrade
a
stack
or
when,
for
whatever
reason
there
may
be
two
instances
on
the
same
stack,
whether
it's
an
infrastructure
stack
or
whether
it's
a
application
stack
that
may
need
to
coexist
in
the
same
in
the
same
space,
whether
that's
in
a
target
cluster
or
whether
that's
in
the
hosting
cluster,
where
you're
running
your
across
plane.
E
E
F
Yeah
I
can
I
can
chime
in
like
Marcus
was
saying
at
the
end,
we're
still
pretty
early
in
the
life
cycle
of
the
Stax
project.
I
would
think
of
it
as
we're
just
starting
to
to
spin
up
our
efforts
on
this,
so
it'll
definitely
evolve
over
the
next
few
weeks,
like
Marcus
was
saying,
and
we're
definitely
interested
in
hearing
any
input
that
that
anyone
has
on
what
they'd
like
to
see
or
what
would
be
useful.
A
A
B
F
D
F
F
B
So
there's
there's
a
number
of
places
that
I
would
encourage
you
to
look
for
that.
So,
first
of
all,
we
have
a
brief
overview
here
in
there
pause
trying
to
read
me.
But
the
specific
thing
you
want
to
look
at
in
terms
of
a
wide
spanning
architecture
overview
would
be
this
linked
architecture
document
here,
and
it
is
kind
of
the
original
kind
of
outlook
on
what
crossplane
should
be
it
able
to
achieve,
and
that
sort
of
thing.
F
A
B
E
I'd
also
point
out
that
design
directory
right
there
that's
been
to
me
and
figuring
out
how
a
cross
plane
works.
Whatever
a
new
design
comes
up,
it
goes
through
the
pull
request
process
and
goes
through
several
iterations
and
then,
after
that,
the
the
Docs
themselves
tend
to
get
updated,
as
well
as
as
the
project
has
evolved.
B
Absolutely
great
call
Marcus
one
thing:
I'd
say
here:
is
it's
important
to
look
and
see
what
the
status
of
each
of
these
documents
is?
So,
for
instance,
this
resource
reclaim
policy?
This
is
a
draft.
It
has
been
merged
into
the
repository,
but
it
has
sort
of
a
workflow
proposal
here
that
doesn't
necessarily
mean
it's
been
implemented.
It's
just
kind
of
something
that
was.
B
We
came
to
agreement
on
in
a
design
document,
so
these
are
more
about
discussion
around
technical
implementation,
things
so
they're
they're
a
great
place
to
learn
as
Marcus
said,
but
don't
take
what
whatever
they
say
to
be
the
truth
about
how
crossplane
currently
function.
Necessarily
we
do
try
to
call
out
in
each
of
these
when
we're
talking
about
this
is
what
we
currently
do.
This
is
a
proposal
for
the
future,
but
just
just
be
mindful
of
that
for
for
sharing
those
alright,
anyone
else
want
to
introduce
themselves.