►
From YouTube: 2019-10-15 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
15th
2019
crossplane
community
meeting.
We
are
in
the
middle
of
the
0.4
milestone.
We
released
0.3
a
about
a
month
ago
now
and
we
are
moving
towards
more
more
often
more
more
frequent
releases
of
the
crossplane
software.
So
we
are
working
on
0.4
and
we'll
talk
a
little
bit
more
about
the
schedule
later
on
here,
but
I
think
we
can
look
kind
of
at
a
high
level
here.
A
What
some
of
the
interesting
things
are
that
we're
focusing
on
for
0.4,
so
I
have
a
couple
useful
links
here
in
the
documents
we're
not
gonna
go
through
like
every
single.
You
know,
issue
on
the
board
or
anything
like
that,
but
these
are
just
helpful
links
to
help
keep
up
to
date
or
the
status
of
the
project
and
where
we
are
and
what
we're
working
on.
A
So
these
are
the
zero
for
the
epics
that
we
have
that
are
filtered
by
0.4.
I.
Think
that
some
of
these
we're
getting
started
on
and
0.4,
but
will
not
necessarily
be
completely
delivered
upon.
But
a
couple
of
important
ones
that
were
we're
really
focusing
on
is
when
we
can
dive
into
some
more
details
later
on
in
the
community
section,
but
the
support
to
integrate
with
Brooke
and
generally
other
on-premises
operator
based
kubernetes
solutions.
A
Dan
has
started
to
work
on
that
and
has
made
a
lot
of
good
progress
which
we'll
talk
about
a
little
bit
later,
but
that's
a
big
deliverable
or
a
high-profile
feature
for
0.4.
That's
making
good
progress
and
then
the
general
work
here
around
what
we
want
to
what
we
need
to
do
to
improve
our
release
process
and
improve
our
our
ability
to
actually
have
releases
go
out
on
a
more
monthly
basis
is
something
we're
spending
a
lot
of
time
on
is
well
good.
B
A
You
go
cool
yes
and
so
yeah,
that's
something
that
a
morphic
is
working
on
right
now
as
well,
is
that
we
want
to
get
to
a
stable
place
with
our
KPIs
and
our
experience
there
so
that
people
can
start
taking
it
at
Pensione
crossplane
and
have
a
bit
more
assurances
about
the
stability,
and
you
know,
ease
of
use
across
across
versions.
There's
markets,
doing
some
good
work
and
driving
are
the
shape
of
our
API,
the
metadata,
the
metamodel,
its
etc,
to
get
a
little
bit
more
stability
in
some
of
our
controllers
in
our
types
there.
A
So
that's
a
just
a
general
look
at
some
of
the
epochs
that
are
being
worked
on,
and
then
you
do.
We
have
the
links
to
the
boards
here
in
the
document
as
well
on
the
agenda
document.
This
is
a
I
believe,
updated
planning
document.
That
kind
of
helps
give
you
an
overall
high-level
view
of
what
are
the
objectives
that
we're
trying
to
deliver
on
and
like
some
links
to
the
issues
for
them
as
well.
A
This
is
not
an
a
strict
top-to-bottom
prioritization
order,
but
more
themed
a
little
bit
so
like
these
are
the
issues
that
will
help
be
able
to
move
towards
production
usage
for
for
consumers
or
the
community
of
crossplane
and
yeah.
So
these
will
have
links
to
each
one
of
the
high
level
epics
there,
and
basically
all
of
these
are
actively
being
made
we're
making
progress
on
all
of
these
right
now.
A
A
So
what
we
are
doing,
as
I
mentioned
before,
is
improving
our
release,
engineering
and
our
release
process
to
add
a
lot
more
automation
to
it,
and
you
know
also
just
workflow
process
around
it
as
well,
so
that
we'll
be
able
to
do
monthly
releases
so
0.4.
The
current
milestone
that
we're
working
on
right
now
there's
a
little
bit
more
discussion
to
be
had
about
what
the
exact
release
date
for
that.
But
it's
either
gonna
be
at
the
end
of
this
week
or
the
next
Friday
and
then
the
following
month.
A
C
Absolutely
so
I
have
been
working
with
one
of
the
developers
over
at
packet
and
we're
kind
of
building
off
the
demo
that
I
used
to
initially
kind
of
shut
the
packet
stack
and
we're
looking
at
moving
that
over
to
their
organization,
so
it
can
be
owned.
Then
the
full
lifecycle
can
be
controlled
by
them
and
that
sort
of
thing,
but
it's
it's
getting
pretty
close
to
a
state
where
it
could
be
a
potential
0.1
release.
For
that
stack.
C
A
That's
awesome
and
it's
good
that
each
one
of
these
individual
stacks
can
have
their
own
independent
release
schedule.
So
they
can,
you
know
0.1
release
can
be
done
at
any
time
completely
decoupled
from
you
know
across
play
and
0.4
or
0.5,
so
that
can
work
on
its
own
schedule
and
could
be
made
available
when
it
is
ready.
But
it's
good
to
see
the
development
work
in
progress
on
that
one
I
think
that's
really
cool.
A
Dan
you're
also
I,
looked
like
the
front
of
the
beginning
of
this
list
is
a
little
Dan
heavy
right
here,
but
you're
also
working
on
the
Hyuga
bytes
and
the
Brooke
stack
in
general,
and
you
could
bite
in
cockroach
TV
implementations
in
that
stack
as
well.
Do
you
want
to
tell
us
a
little
bit
about
how
that's
going
and
what
we'll
be
able
to
see
out
of
that
in
the
next
upcoming
release?
Yeah.
C
Absolutely
so
we
will
have
a
rooks
back
with
support
for
both
gigabyte
and
cockroach,
and
that's
just
about
ready
to
go.
It's
been
living
in
a
repo
on
my
account,
but
we
now
have
a
stack
rook
repo
on
the
crossbone
org,
so
I'll
be
submitting
a
PR
to
that
and
that
will
support
both
static
and
dynamic
provisioning
of
both
cockroach
and
you
divide
clusters
in
any
target
kubernetes
cluster.
So
you
could
provision
them.
C
If
you
had
the
rogue
operators
running
in
the
same
cluster
as
the
crosslink
control
cluster,
you
could
use
a
you
know
existing
cluster,
unlike
GK,
or
something
like
that
and
or
you
know,
I
can
even
an
on-prem
kind
of
thing
or
a
cluster
that
was
provisioned
by
crossplane
with
our
kubernetes
cluster
resource.
So
there's
a
lot
of
flexibility
there,
which
is
really
nice
opening
up
a
lot
of
different
kind
of
infrastructure
plans,
which
is
cool
and
that's
enabled
by
our
new
kubernetes
provider
type,
which
is
part
of
core
crossplane.
C
So
that
should
be
good
to
go
and
we're
looking
at
having
some
demos
around
that
as
well,
so
basically
having
a
target
cluster
where
work
operators
are
running,
you
create
either
you
gabite
or
cockroach
through
there,
then
you
deploy
a
kubernetes
application
alongside
that
into
the
same
target
cluster,
which
basically
consumes
that
postgrads
compatible
database.
So
there
should
be
some
cool
stuff
coming
up
here
for
0.4.
B
Sure
and
so
happy
to
announce.
We've
kicked
off
some
work
within
for
cloud
to
accelerate
the
integration
of
crossplane
into
get
lab
as
a
managed
service
it
can
deploy
to
your
communities.
Cluster
they've
signed
up
for
a
rather
aggressive
integration
timeline
to
get
into
get
labs.
12.5
release
in
November,
so
we'll
be
doing
a
kick
off
tomorrow
and
yeah
excited
to
see
that
work
come
together.
B
A
A
A
Cool
thanks
for
driving
that
initiative
Steve
to
be
able
to
find
someone
to
take
on
that
work
and
and
be
able
to
start
executing
on
it.
That's
a
they've
got
something
a
really
good
opportunity
for
cross
play
and
to
be
able
to
get
in
front
of
a
lot
of
the
users
of
the
give
get
loud
platform.
So
it's
a
great
opportunity
and
I'm
definitely
glad
for
your
efforts
on
getting
that
stacked
and
start
to
execute
great
cool.
A
So
Javad
is
not
on
the
call
this
morning,
but
he
had
done
a
fair
amount
of
work
recently
to
update
our
build
logic.
Build
sub
module
to
use,
go
modules
instead
of
using
other
venturing
tools
like
death.
We're
not
going
to
get
too
deep
into
this
because
it
can
get
a
little
technical,
but
I
did
want
to
bring
up
since
it's
kind
of
a
new
workflow
sort
of
thing
for
contributors.
The
crossbone
project
I
just
wanted
to
get
a
couple.
Questions
answered
here:
real
quick,
so
for
using
go
modules.
A
Now,
since
that's
the
all
the
stack
repos
I
think
I've
had
that
merged
and
then
main
crossplane
is
about
to
get
that
merged.
As
well
is
there
any
does
anyone
on
the
call
know
if
there
is
a
specific
migration
step
you
need
to
take
for
an
existing
locally
cloned
repo,
that's
already
using
a
vendor
directory
and
already
using
depth.
Do
you
have
to
do
anything
after
you
fetch
the
latest
changes
to
use,
go
modules,
I.
C
Know
one
workflow
that
probably
most
familiar
for
anyone
who's
using
depth
is,
if
you
use,
go
mod
vendor
so
basically
just
creating
a
locally
vendor
directory
again,
which
also
can
kind
of
speed
up
some
of
the
issues
with
using
IDs
with
go
modules
right
now,
I'm,
not
sure
if
divided,
if
you
run
make
vendor,
if
that's
still
gonna
run,
go
mod
vendor
behind
the
scenes
now.
But
if
not,
then,
if
you
just
run
to
my
vendor
locally,
then
you'll
have
that
same
familiar
directory
of
dependencies
there
and
the
other
makin
and
work
is
expected.
A
C
So
if
you-
and
it
might
even
if
you
already,
since
we
already
have
locally
vendor
directories
with
DEP
I'm-
not
sure
if
it
might
look
they're
like
that,
the
general
pattern
is,
if
you
have
vendor
directories
in
your
local
repo,
then
go
mods
will
look
there
first
and
that's
kind
of
like
the
purpose
of
go
mod
vendor,
but
I,
don't
know
if
you
already
have
a
vendor
directory
with
death
if
it'll
automatically
just
start
looking,
there
I
think
it
might
actually
but
I'm
not
100
century.
On
that
call.
A
Yeah,
my
hope
is
that
I,
don't
we're
not
in
a
state
where
we're
just
kind
of
reusing.
What
was
already
there
and
kind
of
like
in
a
odd
transitional
state.
I
would
like
it
to
be
a
clean
migration
where
the
new
workflow
is
commonly
used,
and
it's
consistent
and
normalized
across
everybody,
but
we
will,
if
I,
run
into
any
issues
with
it,
then
we
can
follow
up
on
slack
and
ask
Javad
for
for
some
guidance
or
support
on
getting
existing
locally
cloned
repos.