►
From YouTube: 2019-10-01 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
Okay,
the
recording
has
started-
and
this
is
the
October
1st
2019
crossplane
community
meeting.
The
first
thing
that
I
wanted
to
mention
today
is
that
since
the
last
community
meeting,
we
have
made
a
release
of
this
V
zero
dot.
Three
release
went
out.
I
think
it
was
a
day
after
the
last
community
meeting.
So
that's
definitely
a
celebration
and
a
success
there
for
the
whole
team
here
in
the
community
here,
so
we
wrote
a
blog
post
that
I
linked
in
the
agenda
document.
A
Here,
that's
kind
of
an
overview
of
four
things
that
were
in
the
release,
and
you
should
expect
to
see
more
blog
posts
coming
out
over
the
next
few
weeks
with
more
details
about
all
the
cool
features
and
accomplishments
and
things
that
we
were
able
to
build
in
the
0.3
release.
So
there
should
be
regular
blog
posts
coming
out
pretty
soon.
A
Okay,
it's
a
good
job
to
everybody
on
that.
We
also
ran
a
retrospective
event
about
the
0.3
release
and
we
made
that
public
is
well
so
that
the
entire
community
was
invited
to
that
and
we
shared
the
recording
in
the
Trello
board.
For
that,
I
should
add
links
to
to
that
in
here.
So
I'll
take
an
action
item
because
I
forgot
to
add
links
to
that.
A
Ok
yeah,
so
that
was
a
really
good
conversation
to
have
to
kind
of
assess
and
analyze
some
of
the
things
that
went
well
and
some
of
the
things
that
we
can
improve.
So
we
have
a
whole
list
of
action
items
and
things
to
follow
up
on
there
from
that
discussion
to
improve
our
process
and
to
continue
making
progress
on
the
crossplane
project
more
smooth
and
efficient.
A
So
normally
we
talk
about
the
current
status
of
the
current
milestone,
but
since
the
0.3
released,
we
have
started
work
on
some
items,
but
we're
also
in
a
bit
of
a
planning
phase
as
well.
So
I
wanted
to
talk
about
one
of
the
things
that
would
make
a
big
difference
here
in
the
next
release
is
that
we
have
been
discussing
increasing
the
release,
frequency
and
then
also
improving
the
process.
Around
releases
is
well
so
we
went
entirely
much
longer
than
we
would
have
liked
to
in
between
the
last
releases.
A
0.2
was
sometime
in
like
March
or
April,
and
0.3
was
in
September.
So
that's
a
good
number
of
months
in
between
the
releases
there
and
we
want
to
turn
that
around
completely
and
have
a
much
more
frequent
release
schedule.
That
has
a
number
of
benefits,
one
of
them
being
that
it
would
be
able
to.
We
be
able
to
get
new
features
and
new
things.
A
We
build
into
the
hands
of
users
in
the
community
more
frequently,
so
they
wouldn't
have
to
wait
as
long
to
go
to
get
an
official
release
or
a
drop
with
with
new
functionality
that
we
build,
but
then
also
a
big
improvement.
That
it
provides
is
that
it
would
decrease
or
lower
the
amount
of
stress
and
pressure
for
each
release.
A
Because,
if
we're
releasing
on
a
very
frequent
frequency,
then
you
know
if
something
doesn't
happen
to
make
that
released
and
it
can
catch
the
next
release
train
in
the
next
period
which
without
waiting
too
long
so
that
stress
of
that
pressure.
That
builds
up
for
doing
a
huge
release
that
submit
multiple
months
in
the
making
kind
of
dissipates.
And
that
would
be
a
lot
better.
For
you
know
the
health
of
the
community
as
well,
so
we're
getting
things
into
the
users
hands
more
often
and
making
it
easier
for
contributors
to
get
things
in.
A
So
it
seems
to
be
goodness
all
around
we.
One
thing
we
were
talking
about
is
what
the
frequency
of
that
should
be.
You
know
we
normally
run
things
on
us
on
a
Sprint's
basis.
Every
two
weeks
we
plan
out
what
the
work
items
will
be
for
that
sprint
and
execute
on
them.
We're
considering
doing
a
release
at
the
end
of
every
sprint.
Just
all
the
features
that
we
finish
in
that
sprint
go
ahead
and
cut
a
release
from
master
and
you
know,
keep
master
in
sort
of
a
you
know
golden
state.
A
There
were,
you
know
we
ship
entire
features
into
master
along
with
documentation
and
all
you
know
all
full
facets
of
the
features
completed
and
then
we'd
be
able
to
do
releases
from
master
on
a
very
frequent
basis,
maybe
even
every
single
sprint.
That
may
be
a
little
much,
maybe
a
little
overhead
with
that.
So
we
are
considering
also
doing
a
monthly
cadence.
A
So
that's
still
in
debate
a
little
bit,
but
one
thing
to
note
is
that
either
way
that
will
increase
the
minor
version
counts
of
the
cross,
plane
project
and
a
much
more
rapid
pace
than
it
has
in
the
past.
You
know
0.1
0.2
0.3
we're
kind
of
slowly
moving
through
those.
So
far.
If
we
release
every
sprint
or
every
month,
then
that
would
rapidly
go
through
0.4
0.5.
Those
minor
releases
much
more
quickly,
which
is
totally
acceptable
from
you
know,
from
a
semantic
versioning
perspective,
that's
the
right
thing
to
do.
A
It's
a
little
bit
different
I
guess
a
different
expectation,
then
we've
put
in
the
past,
but
that's
something
that
I've
are
perfectly
happy
with
in
terms
of
getting
things
out
to
users.
More
often-
and
the
thing
to
note
is
that
by
doing
minor
releases
of
0.40
fives
or
not
6,
that
enables
us
to
also
do
past
releases
in
between.
If
you
released
something
to
the
community-
and
we
find
a
major
bug
in
it
that
we
want
to
fix,
then
we
can
do
a
patch
release
evidence
you're
about
4.1
in
between.
A
So
that
seems
to
be
a
good
versioning
scheme
and
that's
a
follow
up
that
I'm
working
on
right
now
of
writing.
Excuse
me
writing
a
proposal
and
writing
that
up
about
what
our
release
process
will
be
and
how
we
can
also
increase
the
automation
to
make
this
more
a
more
of
a
pain-free
process
that
you
know
hit
a
button
and
the
release
goes
type
of
thing
to
reduce
the
overhead
for
it.
A
So
that's
that's
where
we
are
with
releases.
Phil
has
started
an
effort
on
planning
towards
the
cube
con
San
Diego
timeframe,
which
is
the
mid-november.
We
may
have
a
number
of
releases
in
between
there
before
San
Diego,
but
that's
about
the
planning
scope
that
we're
thinking
of
right.
Now
of
what
do
we
want
to
accomplish
to
be
able
to
show
off
it
cube
con
San
Diego
Phil.
Do
you
this?
Is
you
document
that
you
started
this
public
planning
document
here?
B
You
know
in
my
own
environment,
whether
it's
on
Prem
or
in
a
public
cloud
provider.
You
know
using
rook
I'm
in
the
same
way
that
I
would
provision.
You
know
an
RDS,
a
cloud
sequel
or
a
how's,
your
DB
and
so
kind
of
getting
that
consistent
experience
with
crossplane
and
so
super
excited
about
kind
of
the
initial
Brooks
support
coming
in
as
we're
moving
towards
production.
For
some.
B
So
it's
a
really
great
work
coming
and
set
seven
to
provide
consistent,
apply
of
a
few
control
chef
on
a
directory
of
the
animals,
so
that
I
can
create
my
entire
configuration
for
a
cluster
for
the
networking,
the
subnets
firewall
rules.
Everything
that's
needed
to
basically
spin
up
an
environment
that
I
can
deploy
applications
into
and
dynamically
provision
resources
on
demand.
So
so
that's
basically
kind
of
wrapping
up
now,
I
believe
and
then
we're
gonna.
B
You
know
continue
with
the
integration
examples,
also
in
terms
of
moving
towards
production
use
getting
to
stable,
v1
beta-1
api's,
so
that
people
feel
more
comfortable
taking
a
hard
dependency.
We're
currently
V
1
alpha
2
for
most
of
our
things
and
the
out
of
tree
stacks
and
then
the
entry
stuff
I
believe
is
12.
U
1
alpha
1
I'm,
not
sure
I
got
bumped
to
the
alpha
2
yet,
but
and
so
what
we're
looking
at
here
is
basically
solidifying
around
a
a
beta
level.
B
I
mean
your
dev
test
and
even
prod
environments,
and
so
this
will
be
the
basis
as
well
for
cogeneration
in
the
future,
and
so
I
probably
won't
get
to
cogeneration
in
the
cube
con
timeframe.
But
with
this
in
place,
you
know
we'd
be
able
to
to
do
that
not
much
more
easily.
So
so
super
excited
about
this
work-
and
you
know
Jared
mentioned
the
release.
Automation
for
shorter
release
cycles-
you
know
so
this
is,
you
know,
going
to
be
following
it
all
likelihood:
December
200
semantics.
B
You
know
where
you
have
like
major
minor
patch
and
so
you'll
see
the
version
numbers
likely
getting
bumped
or
more
rapidly
there
as
we're
releasing.
You
know,
minor
versions
with
the
ability
to
do
hot
hatches.
You
know
with
the
patch
release,
you
know
intra,
you
know
minor
release
side
of
a
time
frame,
so
we're
kind
of
trying
to
battle
in
we
want
to
do
releases
every
two
weeks
or
do
I
want
to
do
monthly
time.
B
You
know
there's
some
opportunity
to
make
the
experience
even
better,
so
ideas
like
trace
utility
for
enhanced
lugging,
better
visibility
into
all
the
error
messages.
Potentially
using
you
know,
events
and
Korea
days
things
like
resource
packs.
Where
you
can
have.
You
know
you
know
getting
started
templates
for
you
know
the
resource
classes
and
the
definitions
that
you
could
then
go
and
customize,
but
you
could
otherwise
keep
control
apply
that
directory
to
to
eliminate.
B
You
know
that
that
manual
step
then
so
looking
at
things
like
static
provisioning
examples
which
is
kind
of
a
under
touted,
you
know
capability,
the
cross
plane
provides,
which
is
that
you
don't
have
to
use
claims
and
classes.
You're
welcome
to
just
do
static,
provisioning
in
a
single
namespace,
and
so
oh,
we
got
a.
B
It
up
is
awesome
inside
of
like
a
progress
meter
and
then
a
buddy
system
for
new
users.
So
you
know
doing
some
some
brainstorming
and
yesterday,
and
you
know
for
for
new
users
and
contributors,
just
making
sure
that
we
have
kind
of
a
good
process
in
place
for
making
sure
they're
they're
paired
off
with
folks.
B
So
we
need
to
kind
of
circle
back
and
make
that
you
know
kind
of
work
with
the
enhancements
from
V
0.3.
And
then
we
have
a
new
major
initiative
underway
with
template
stacks,
which
was
really
focused
on
making
a
lot
easier.
Just
build
a
stack
today.
You
have
to
build
a
stack
with
with
queue
builder,
v2
and-
and
that's
really,
you
know
pretty
good
experience,
especially
if
you're
doing
like
custom.
B
B
We've
also
had
some
discussion
around
some
additional
real
world
apps,
and
so
concourse
is
one
that
keeps
coming
up,
basically
as
a
continuous
deployments,
the
SVD
type
tool,
and
so
you
know
being
able
to
deploy
that
and
so
that
people
can
use
it
in
their
environments.
We
felt,
like
would
be
a
great
working
example
that
could
leverage
a
lot
of
would
cross
plane
supports.
Today.
B
We
also
have
a
handful
of
lab
apps
that
we're
using
in
the
community
and
that
we're
going
to
start
deploying
with
cross
plane
and
ultimately
want
to
get
to
a
consolidated
top
ten
list
of
additional
apps.
So
if
you
have
your
favorite
app
that
you
would
like
to
see
supported
in
cross,
plane
drop
us
a
line
on
cross
playing,
slack
and
I
would
be
awesome.
C
B
B
That's
basically
managing
you
know
the
application
instances
in
an
environment,
you're,
really
upgrading
the
capability
of
your
control
plane
to
provide
lifecycle
management
of
that
app
and
so
stacks
versioning
an
upgrade
basically
just
formalizes
that
so
that
you
can,
you
know,
just
apply
and
an
upgrade
to
an
existing
installed
stack
and
then
it
can
handle
all
of
that
for
you
in
a
more
streamlined
way.
So
definitely
some
important
functionality
there.
B
You
can
go
into
your
auto
dev
ops,
home
chart
which
they
use
today
to
basically
deploy
continuously
into
these
connected
kubernetes
clusters,
and
then
you
can
just
and
in
there
today
is
just
one
attribute
called
well.
There
is
one
attribute
and
there's
a
lot
of
attributes,
but
it's
called
post
crest
enabled
and
what
that
does
today
is
basically
says
if
it's
such
a
true
it'll
deploy
an
in
cluster
container
for
Postgres.
But
it's
not
managed
it's
not
a
che.
B
It's
not
backed
up
or
anything,
it's
just
not
really
suitable
for
production,
and
so
it's
great
for
kind
of
you
know
like
a
dove
in
a
test
environment,
but
you
know
it's
kind
of
needing
something
more,
so
what
crossplane
will
add
is
the
ability
to
drop
in
to
additional
attributes?
So
you
can
say,
Postgres
enabled
is
true
and
then
Postgres
manages
true.
That
will
then
drop
a
crossplane
claim
into
that
at
projects
namespace,
so
that
post
crest
is
dynamically
provisioned
using
the
default
resource
class
in
that
project,
namespace,
and
so
with
just
one
additional
attribute.
B
I
can
now
get
a
managed
Postgres
instance
and,
and
that's
super
powerful
and
so
Neela
I'm
super
excited
about
it.
They
actually
want
to
use
it
for
their
own
purposes
as
well,
because
they
may
use
their
own
stuff,
and
so
this
would
be
useful
to
them
and
useful
to
their
customers
and
then
will
also
support
an
additional
attribute
called
Postgres
class.
And
so
then
you
can
actually
specify
the
specific
class
of
service
to
all
on
a
Postgres,
small
or
large
or
H
a
or
standard
that
type
of
thing
so
really
excited
about
this
integration.
B
Kind
of
highlighting
the
power
of
managed
service
provisioning
on
connected
kubernetes
clusters
with
crossplane
services,
yeah
and
then
down
below.
We
test
have
the
tentative
release
schedule.
This
is,
you
know
I
currently,
in
draft
status.
So
you
know
feedback
is
welcome,
but
kind
of
are
moving
to
this
faster
release,
cycle
or
kittens,
and
so
the
first
one
is
likely
going
to
be
two
sprints
so
before
0.40
and
then
moving
to
0.5-
and
it's
are
about
six-
we'll
see
how
that
that
frames
up.
B
D
A
List
and
some
really
cool
stuff-
the
team
in
the
community
has
definitely
grown,
though
so
there's
lots
of
Engineers
to
work
on
these
problems
here,
but
yeah
I
love
the
just
a
completeness
in
the
breath.
This
plan
here
there's
so
many
interesting
things
that
we'll
be
able
to
advance-
and
you
know,
move
the
move.
The
needle
forward
a
little
bit
so
I'm
really
excited
about
that.
B
A
Me
too,
all
right:
okay,
so
that
was
kind
of
a
state
of
where
the
project
is
with.
You
know
where
we
are
planning
in
what
we
want
to
include
over
the
next
couple
of
the
leases.
What
are
what
we're
thinking
about
are
what
these
process
and
everything
so
I
wanted
to
move
then
to
the
next
sections.
Here
there
are
a
couple
of
pull
requests
or
new
features
that
we
that
I
wanted
to
bring
up
just
to
get
a
status
or
see.
A
A
A
So
we
jawed
started
an
effort
to
move
us
from
using
the
depth
tool
to
manage
a
vintage
set
of
dependencies
to
using
the
new
go
module,
support,
that's
built
into
the
language
and
the
go
tooling
I
think
this
one's
been
open
for
a
little
bit
and
some
back
and
forth
on
that
one.
It
does
hoping
to
check
which
about
to
see
if
we
it
looks
like
we're
converging.
The
some
I
know
that
you
had
reviewed
this
recently
the
build
sub
module
to
start
supporting,
go
mods.
It
was
there
any
big
concerns
here.
B
It's
moving
along
and
just
there's
a
bunch
of
assumptions
that
to
build
this,
for
all
these
make
files
make
that,
unfortunately,
are
not
very
well
documented,
and
so
people
making
changes
to
kind
of
just
miss
missed
them.
So
we're
going
through
that
right
now
got.
B
A
C
C
So
that's
been
fun
and
I
encountered
that
with
crossplane,
because
when
I
tried
to
locally
go
through
the
same
process
and
switch
it
to
go
mod,
it
updated
the
version
of
the
go
tour
of
the
Google
client
library
to
some
newer
version
and
some
of
the
calls
that
we
were
making
had
become
deprecated.
So
you
just
have
to
be
I.
Guess
careful
about
that
interesting.
A
Interesting:
okay,
thanks
Marcus,
so
I
I,
don't
see
Moffat
or
Nick
on
the
call
for
the
mandatory
source
API
pattern.
So
we
could
perhaps
skip
that
but
Dan
mango.
Do
you
want
to
give
us
an
update
on
the
efforts
that
you
can
put
it
in
about
adding
support
for
Brook
and
in
general,
kubernetes
native
infrastructure
providers?
A
D
Definitely
so
there's
a
PR
open
which
link
there
in
the
dock
and
that's
a
design
document
for
terminated
and
structured
providers,
but
specifically
rook,
which
is
our
main
focus
here
and
then
kind
of
at
the
end
and
future
considerations.
We
call
out
how
this
may
apply
to
other
infrastructure
providers
that
are
kubernetes
natives,
like
rook
I'd,
say
the
most
significant
kind
of
large
impact
of
this
design.
D
Dock
is
implementation
of
this
kubernetes
provider
type,
which
is
one
of
the
first
things
outlined
in
the
dock,
and
what
we're
doing
is,
instead
of
only
being
able
to
well
right
now.
The
only
thing
that's
provisioned
on
external
kubernetes
cluster,
so
outside
the
crossplane
control
cluster
would
be
kubernetes
application,
resources
and
right
now.
The
only
way
they're
scheduled
is
by
matching
labels
to
a
cross,
plane
provision,
kubernetes
cluster,
so
there's
actually
a
a
cross
plane.
D
We're
starting
to
shift
that
a
little
bit
here
with
this
proposal
right
now,
we're
not
updating
the
kubernetes
application
scheduling,
but
it
will
likely
affect
that
in
the
future
as
well.
But
what
this
allows
us
to
do
is
just
as
you
think,
of
creating
a
provider
to
talk
to
GCP
or
AWS
or
any
provider
we're
basically
creating
one
of
those.
It
allows
us
to
talk
to
kubernetes
clusters,
whether
it's
an
external
cluster
provisioned
by
cross
client.
D
So,
in
a
cluster
running
anywhere
that
you
have
rook
operators
installed
in,
you
can
use
that
provision,
rook
resources
in
and
the
way
the
provisioning
works
is
you
know,
typically
with
a
more
traditional
cloud
provider,
you
would
create.
Let's
just
go
with
a
static
provisioning
example.
You
would
create
a
kubernetes
objects.
It's
like
a
cross
plane
concept
of
that
object,
so
maybe
like
an
RDS
instance.
D
The
controllers
for
that
and
the
AWS
stack
would
then
create
an
RDS
instance
in
AWS
and
reconcile
it
to
the
spec
of
that
resource
that
you
created
now.
The
concept
with
rook
or
any
other
kubernetes
native
instruction
provider
is
the
external
resource
is
actually
another
kubernetes
object,
a
rook
kubernetes
object.
So
on
the
example
in
this
design,
dock
is
with
a
cockroach
DVD
cluster.
So
when
you
create,
let's
say
once
again
with
static
provisioning,
you
create
a
cockroach
DVD
cluster
in
cross
plane.
D
Then
in
the
target
cluster,
wherever
that
is
where
the
rope
cockroach
DB
operator
is
installed,
it
will
create
a
rook
notion
of
a
cockroach
DB
cluster
and
then
it
will
use
rooks.
You
know
controller
logic
to
actually
create
that
cockroach
DB
cluster
in
the
target
cluster
and
then
the
reconciliation
is
happening,
is
actually
between
the
cross,
flane
concept
of
the
cockroach
DB
cluster
and
the
concepts
of
it.
So
it
can
get
a
little
bit
confusing,
but
essentially
it's
just
reconciling
CR
DS
against
each
other.
D
So
it's
actually
a
pretty
simple
workflow
and,
at
the
end
of
this
document,
there's
some
future
considerations
that
call
out
potential
to
maybe
kind
of
like
consolidate
some
of
this
logic,
because
it
would
be
similar
across
that's
not
necessarily
in
scope
for
this.
What
we
want
to
do
first
is
just
be
able
to
provision.
D
First
post
grades
database
objects;
they
can
satisfy
a
post
grades,
claim
and
cross-claim.
We
want
to
be
able
to
provision
those
using
rook,
and
then
we
want
to
expand
to
be
able
to
provision
all
native
resources
are
supported
by
rook,
so
that
could
be
many
o
object,
stores
set
edge,
FS,
etc.
Anything
that
rook
sports
we
want
to
provide
in
the
rook
stack
and
then
there's
also
some
ideas
for
potentially
building.
D
On
top
of
that
which
you'll
see
here,
I'm
talking
about
a
bucket
in
an
object,
store
and
rook,
we
definitely
want
to
support
that
in
the
future.
It's
not
a
native
I'm
saying
with
rook,
so
there's
a
couple
of
options
for
how
we
want
to
do
that.
But
those
are
one
there.
If
you'd
like
to
check
those
out.
A
Awesome
then
thank
you
for
driving
that
effort
they're,
something
that
you
know
many
people
have
been
excited
about
for
quite
a
while.
We've
been
showing
off
hints
of
that
functionality
for
a
while
now,
so
people
are
definitely
excited
about
that
scenario
being
able
to
not
only
provision
using
cross,
plane
resources
and
all
the
cloud
providers,
but
being
able
to
provision
resources
and
services
on-premises
as
well
for
new.
You
know
how
purposes
of
hybrid
scenarios,
so
that's
got
super
exciting.