►
From YouTube: 2019-05-28 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
the
recording
has
started.
This
is
the
May
28
2009
teen
crossplane
community
meeting,
and
we
have
a
new
member
of
the
cross
planning
community
on
the
call
today.
Marcus
is
joining
us
today
and
is
a
research
upbound
hire
so
welcome
to
the
community
in
the
in
the
meeting
here.
Marcus
we're
glad
to
have
you
thanks
glad.
A
C
It's
it's
weird
to
have
something
like
that.
You
just
become
associated
with
it
and
then
there's
all
the
beard,
conversations
that
you
can
have
with
people
I.
A
Was
listening
to
something
recently
that
there's
apparently
a
cig
beard,
a
special
interest
group
beard
in
the
kubernetes
community,
which
I
was
kind
of
surprised
to
joke,
but
it
was
kind
of
surprised
spell
because
it's
not
very
inclusive,
but
there
does
exist
a
cig
beard
all
right.
So
let's
I
will
be
the
first
to
admit
here
that
coming
off
of
cube
con
Barcelona,
which
I
think
was
very
successful
and
we'll
have
a.
A
We
have
an
item
here
at
the
agenda
to
talk
about
coming
off
that
I
didn't
even
open
my
laptop
until
this
morning,
unpack
it
from
my
luggage
and
stuff.
So
I
am
running
a
little
bit
behind
and
trying
to
page
things
back
in
I
think
that
most
of
us,
some
of
us,
might
be
in
that
same
boat
as
well
that
we're
gonna
need
to
ramp
back
up
again
after
after
Barcelona.
A
But
the
so
in
terms
of
you
know
we're
in
the
0.3
milestone,
and
we
had
had
a
Genda
item
from
the
previous
meeting
to
kind
of
formulate
a
plan
and
kind
of
lock
down
some
of
the
themes
and
issues
that
we
want
to
tackle
on.
For
the
rest
of
the
milestone
and
kind
of
a
plan
for
the
milestones
coming
up,
we
need
to
still
approach
that
so
I'll
take
ownership
of
that.
A
Now
that
we're
we're
back
from
Barcelona
and
drive
that,
but
I
did
want
to
in
this
meeting
here
kind
of
solicit
some
feedback
or
brainstorm
ideas
for
what
are
some
of
the
major
themes
going
forward.
I
had
started
a
little
list
here.
Let
me
make
this
a
little
bit.
Bigger
too
I
had
started
a
little
list
here
of
just
the
top
of
mind
things
that
themes
here
and
so
those
are.
You
know
the
work
that
we
had
done
to
support
gitlab.
A
You
know
folks
worked
really
hard
on
that
and
put
in
a
lot
of
effort
to
get
something
functional.
You
know
it's
definitely
we
took
some
shortcuts
and
there
are
some
refactoring
rewrites
lessons
learned,
etcetera
from
that
that
we
want
to
incorporate
back
in
and
improve
that
support.
So
that'll
be
definitely
one
area
where
we
want
to
spend
some
more
cycles
on.
A
Another
area
is
increasing
our
surface
area,
so
the
various
resources
and
cloud
providers
and
environments
etc
that
we
support
it
would
be
good
to
get
a
better
understanding
of
which
ones.
Where
are
we?
Do
we
have
gaps?
Where
is
there
community
demand?
And
you
know
where,
should
we
put
some
further
investment
into
increasing
the
scope
of
our
surface
area
of
what
we
support
and
then
another
huge
one
that
we've
been
talking
about
for
a
while?
A
That
I
know
that
there
is
good
support
for,
amongst
some
of
the
core
developers,
the
project
is
to
increase
the
production,
readiness
production
quality,
to
drive
some
of
our
existing
resources
and
controller
support
to
being
able
to
actually
be
adopted
by
a
community
by
the
wider
community
and
start
getting
more
usage
in
traction.
The
last
one
I
had
written
down
was
we
had
recent
feature
support
for
extensions
to
be
able
to
extend
crossplane
with
new
functionality.
A
That's
built
out
of
tree,
and
we
did
an
initial
implementation
of
that
for
as
part
of
the
get
lab
support,
and
so
it's
fairly
bare-bones.
It
doesn't
support
dependency
resolution
or
upgrades
of
the
of
the
atom
tree
extension
controller
stuff.
So
I
think
that
would
be
some
more
work
that
we
want
to
continue
to
add
support
in
as
well.
Is
there
other
ideas
on
this
call
for
general
themes
that
we
want
to
be
tackling
and
the
rest
of
the
0.3
milestone
and
upcoming
milestones.
C
Yeah
I
think
we
talked
about
essentially
supporting
folks
that
are
running
existing
workloads
like
just
deployments
and
states
all
sets
and
replica
sets
without
using
complex
workloads
or
any
of
the
workloads
KPIs
in
cross
plane
and
making
that
a
priority.
So
single
cluster
focus
existing
workloads
being
able
to
use.
You
know
to
manage
services
that
are
exposed
by
cross
link.
A
C
A
All
right
I
will
take
a
first
stab,
it's
kind
of
probably
like
the
way
I'll
do.
This
is
X
updating
the
roadmap
and
we
could
have
more
discussion.
You
know
on
as
a
community
there
with
up
you
know,
adding
these
items
incorporating
them
into
the
roadmap.
If
there
are
other
items
that
people
finder,
you
know
of
importance
or
want
to
get
it
incorporated
in
as
well,
please
let
me
know-
and
we
can
definitely
include
them.
A
A
All
right,
so,
let's,
let's
move
down
to
the
community
topics
section,
so
it's
a
cube.
Con
Barcelona
was
awesome
that
that
was
really
fun
there
were
we
had
a
number
of
talks.
Ilya
gave
a
great
talk
about.
You
know
how
to
write,
reliable
and-
and
you
know,
production-ready
operators
and
controllers,
which
was
really
popular
and
had
a
lot
of
people
generated
a
lot
of
discussion.
A
lot
of
interests.
A
I
gave
a
couple
of
talks
that
were
focused
on
Brooke,
but
also
incorporating
crossplane
in
is
well,
and
there
was
a
whole
bunch
of
people
that
we
got
to
meet
and
talk
with,
and
there
was
a
lot
of
excitement.
A
lot
of
that
was
definitely
a
very
fun.
Experience
for
sure
was
anything
that
anybody
wants
to
share
about
their
experience
in
Barcelona
or
any
key
takeaways
or
observations
that
they
made.
C
So
there
was
definitely
a
lot
of
interest
in
that
and
then,
similarly,
there
was
a
lot
of
interest
in
people
wanted
to
do.
Clusters,
Multi
cluster
scenarios
and
so
I
think
we
got
really
good
validation,
I
Phil,
who
compiled
all
this
feedback,
maybe
maybe
when
he
gets
back
next
week
and
the
next
committee
meeting
we
can
kind
of
summarize
all
the
feedback,
because
we
got
feedback
could
be
incorporated
into
kind
of
future
plans
around
what
we
do
this
project.
C
A
Too
yeah
that
was
definitely
very
cool
too,
to
check
out
the
shockingly,
the
all
the
videos
recorded
sessions
and
talks
are
already
published,
so
all
the
keynotes
all
the
breakout
sessions,
all
those
are
already
on
the
web.
I
think
the
entire
conference
is
already
up,
so
they
did
a
really
good
job
of
getting
all
that
stuff
published
very
quickly.
So
you
too,
it
can
follow
along
at
home
and
watch
the
keynote
mention
on
I
think
from
Thursday
by
Bryan
Liles
in
his
talk
about
mentioning
cross
plains.
So
that
was
the
name.
C
Yeah,
though
the
only
other
thing
else
worth
mentioning
Crowley's
around
gitlab
and
I
think
we
did
like
two
two
demos
with
the
flap
one
was
the:
how
do
I
take
the
existing?
You
know
single
Buster
home
chart
based
get
lab,
I
mean
without
much
modification.
Have
it
used
cross
plane
to
use
things
like
post,
fast
and
Redis
and
buckets
and
everything
else
so
I
think
getting
that
to
be
more
production,
ready
fixing
all
the
issues
we
just
talked
about
is
important,
but
then
the
other
scenario
is
kind
of
a
layer.
C
Two
as
I've
been
describing
it
is
getting.
You
know
the
getting
get
lot
to
be
a
good
multi
cluster
application
on
on
on
cross
by
home
state
and
that
there's
more
work
to
do
here,
but
it's
also
a
super
concrete
use
case
for
us,
so
we
can
continue
driving
that
I
know.
We
have
an
early
attempt
at
it
with
a
good
luck
controller,
but
the
kid
live
team
itself
is
interested
in
kind
of
pursuing
the
next
there.
So
it's
just
this.
It's
super
concrete
to
see
something
like
get
lab
run.
A
Yeah
definitely
that
was
that
was
really
really
cool.
Seeing
that
come
together
in
you
know
the
early
support
that
that
we
were
able
to
pull
together.
That
was
great,
seeing
that
at
the
both
the
effort
and
then
also
the
fruits
of
that
labor
as
well-
and
it's
really
good
to
continue
to
have
the
grit
lab
team
interested
and
engaged
in
this
as
well.
So
that's
really
great
to
have
that
alright,
so
that
is
Barcelona
and
let's
we
can
move
on
to.
We
wanted
to
see
if
we
could
drive
a
quick
resolution
to
this
topic
here.
A
We
in
are
for
expediency
while
we're
rapidly
trying
to
finish
off
some
items
for
for
demos
and
such
in
Barcelona.
We
had
investigated
temporarily
disabling
some
checks
on
poor
requests,
and
so
when
we
started
some
discussion
about
re-enabling
those
again,
and
so
it
looks
like
there
is
a
skip
check
functionality
that
maybe
we
can
use
in
the
future,
but
there's
that
definitely
bring
some
questions
as
well,
so
Nick,
Emilia
I,
know
you
all
had
been
discussing
this
and
I'm
happy
to
weigh
in
as
well.
A
B
I
can
I
can
give
it
a
quick
shot,
so
obviously
in
perhaps
the
last
community
meeting
or
the
one
before
that
we
we
spent
some
time
debating
our
code
coverage
semantics
and
just
to
just
just
just
to
preface
this
conversation,
we
decided
afterwards
that
we
didn't
want
to
spend
too
much
time
debating
sort
of
code
hygiene
on
the
community
meeting
that
might
break
out
to
a
different
meeting.
So
if,
if
this
doesn't,
if
this
isn't
quick,
then
maybe
we
should
think
about
doing
that.
I.
B
Have
written
a
couple
of
manifestos
about
why
I
think
that
optional
checks
on
gitlab
have
a
very
bad
user
experience,
don't
know
if
any
of
them
are
easily
linked
to
from
from
here?
Maybe
maybe
this
issue
might
have
mentioned,
if
that,
so
what
we
decided
to
do
last
time
was
make
all
about
checks
mandatory,
including.
D
B
The
place
where
this
gets
the
most
awkward
at
the
moment
is
that
when
you
touch
code,
if,
if,
for
instance,
you
have
to
refactor
code
the
that
already
didn't
have
tests,
it
puts
you
on
the
hook
to
basically
add
tests
for
that
code
that
you
touched,
which
is
you
can
make
a
pretty
good
argument
that
that's
a
good
thing,
but
it
does
put
it
in
a
case
where
it's
like.
Okay,
this
code
is
broken.
B
B
One
thing
that
I
pointed
out
a
couple
of
times
is
that
I
get
snot,
it's
not
being
able
to
override
tests,
or
rather
it's
not
being
able
to
override
checks.
That
is
the
problem
that
I
have.
It's,
though,
is
the
fact
that
there
are
no
artifacts
when
you
override
the
checks.
It
does
there's
no
way
to
tell
whether
it's
appropriate
to
you're
not
required
to
add
any
context
when
you
do
so
you
just
like
it
just
provides
this
user
experience
where
we're
like
kind
of
maybe
in
some
circumstances.
B
We
would
like
this
check
to
pass,
but
unless
you
decide
not,
and
if
you
decide
not
just
do
it,
I
I
don't
have
a
good
solution
to
this,
like
Ilya
kind
of
makes
a
good
point
in
his
last
thing
there
that
yeah,
if
we,
if
we
get
code
coverage,
update,
you
just
hand
across
the
entire
code
base
and
everything
is
good
and
tested
like
once
we're
in
a
good
place.
This
season's
so
much
of
a
problem,
I
think
we're
a
family
from
there.
I
I
still
my
personal
preference.
A
B
I
call
you
so
I
can
do
total
coverage
and
coverage
on
diff
as
two
different
things
that
you
can
say.
We
must
have
80%
coverage
with
the
project
or
you
must
have
80%
coverage
on
your
death,
and
you
can
also
tell
it
to
do
coverage
based
on
different
semantics,
like
lines
versus
conditionals
things
like
that.
The
other
thing.
D
B
Just
wanted
to
check
in
on
I
had
thought
at
one
point
that
Sona
was
actually
just
using
goes
covering
semantics,
that
was
using
package
level
coverage
semantics,
but
the
last
time
I
checked
it
doesn't
seem
to
be
that
way.
It
seems
to
be
somehow
actually
figuring
out
the
lines
that
you
touch
there
and.
A
If
that's
the
case,
do
you
think
it
would
be
better
at
figuring
out?
You
know,
80%
coverage
only
on
things
that
you
actually
knew
code,
that
code
that
you
added
or
changed
as
opposed
to
you
know.
You
touched
this
package
and
therefore
you
know
it
didn't,
have
any
percent
coverage
and
now
you're
on
the
hook
for
it
that's
odd
yeah.
B
B
A
C
A
D
So
it
was
on
the
call
last
week,
but
I'm
not
sure
I
was
in
on
so
I
wasn't
sure
if
it
got
too
so
this
comes
out
of
and
slack,
there
was
some
discussion
with
for
hey
I
mentioned
in
the
PR,
who
I
believe
it
actually
works
on
Azure.
So
it
was
cool
to
get
his
input
and
have
him
looking
at
the
project
in
general,
but
he
was
concerned
about
when
I
created
the
resource
groups.
D
It
had
basically
a
you
know,
if
else
kind
of
checks
on
the
names
for
the
resource
groups
to
make
sure
it
adhered
to
the
Dodger
naming
conventions.
But
obviously,
if
those
are
change
in
the
future,
then
that
could
become
stale.
So
essentially,
what
this
is
doing
is
just
taking
out
that
test
and
just
handling
failure
on
creation
of
resource
groups
when
it
makes
the
call
with
a
sure,
go
library,
so
it
just
seems
a
little
bit
more
consistent.
D
A
I
think
that's
in
general.
It's
definitely
good
to
to
take
advantage
of
the
validation
logic,
that's
provided
by
the
cloud
providers,
since
that
key
is
up
to
date
and
the
thorah
tative
source,
as
opposed
to
having
to
duplicate
or
capture
any
that
logic
in
the
cross
plain
code
that
can
easily
diverge
or
go
stale
from
the
upstream
cloud
providers.
So
that
think
that's
a
good
idea,
cool,
yeah
and
Jorge
is.
He
is
on
the
at
regime
I'm,
not
sure
exactly
which
part
of
azure
he's
on,
but
he
is
part
of
a
sure.
A
Cool
that
looks
like
Nick
was
able
to
follow
up
on
that
just
recently,
so
that
work
looks
like
it's
should
be
ready
to
go
and
get
merged
into
master.
D
A
So,
let's
so,
let's
you
know
because
we
can
get
down
into
the
weeds
and
that
one
pretties
they
probably
for
sure,
let's,
let's
schedule
some
time
offline,
to
have
a
discussion
about
that
with
you
Daniel
and
and
continue
to
drive
that
there
is
your
schedule
pretty
pretty
open.
Or
do
you
have
any
known
constraints
that
wouldn't
work
for
you.
D
A
A
Do
you,
if
you
could
do
me
a
favor?
Could
you
start
a
little
slack
question
a
question
on
slack
to
see
who
wants
to
be
involved
in
talking
about
default
resource
classes
and
we'll
find
a
time
to
do
that?
Definitely,
thank
you
appreciate
it
in
for
sure,
alright,
okay,
yes,
so
that
is
the
end
of
here.
We
go.
That's
the
end
of
the
agenda
here.
Was
there
anything
else
that
anybody
wanted
to
bring
up.
A
Alright
sounds
good,
so
I
will
be
giving
a
talk
on
crossplane
on
Thursday
night
here
at
a
local
San,
Diego
meetup,
then
I'm
definitely
excited
about
doing
so.
Think,
that'll
be
good
to
continue
meeting
with
new
people
and
getting
feedback
about
crossplane
and
spreading
that
message
so
that
that's
I'm
looking
forward
to
this
week
and
otherwise
we
will
see
you
on
slack
and
github
and
we
will
meet
again
in
two
weeks.