►
From YouTube: 2019-04-02 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
Event
that
I
know
of
is
that
we
want
to
get
to
1st.
Today
we
had
been
discussing
a
quarterly
release,
cadence
and,
with
our
lasts,
the
first
release
being
in
December,
then
you
know
the
March
timeframe
was
when
we
wanted
to
0.2,
so
we're
a
little
bit
behind
that
we
want
to
hurry
up
in.
You
know,
finish
off
that
milestone
and
converge
towards
getting
the
release
ready
to
be
hopefully
published
by
the
end
of
this
week.
So
I
took
a
passed
last
night.
A
Let
me
move
this
zoom
bar
thing
out
of
the
way,
I
took
a
pass
last
night
at
the
milestone,
and
so
here's
the
project
board
here,
but
let's
actually
look
at
the
milestone
itself.
So
these
are
the
remaining
issues
that
I
called
the
milestone
down
to
I
punted
some
items
out
that
had
been
in
there
that
were
no
longer
a
good
scope
or
a
good
fit
for
converging
on
this
milestone,
and
so
not
necessarily
in
this
list
here
is
everything
like
do.
A
We
need
to
do
every
single
thing,
but
at
least
they
are
items
that
I
wanted
to
have
discussions
about
as
a
community.
So,
let's,
let's
actually
start
at
the
bottom
here
so
I
believe
there
is
already
a
PR
open
for
using
a
consistent,
logger
across
all
controllers
and
that
may
have
even
been
approved
recently
as
well.
Yes,
this
so
the
pr
for
using
consistent
logging
across
all
controllers
has
been
approved.
Is
there?
Is
there
anything
remaining
on
on
this
PR
nic
in
Ilia.
B
A
A
Okay,
the
release
pipeline
I
kept
this
issue
in
the
milestone,
since
there
were
a
couple
of
manual
steps
that
needed
to
be
done
for
the
0.1
release
and
so
I
wanted
to
either
a
gets
automation
in
place
for
this
before
0.2
or
be.
You
know,
have
this
information
such
that
when
we
walk
through
0.2
release,
we
have
what
we
need
to
be
able
to
do
that
process
smoothly.
But
some
did
you
take
another
look
at
this
or
have
you
dug
more
deeply
into
this,
but
recently
by
any
chance,
I.
A
Okay,
that
sounds
great
and
I
can
I'll
be
happy
to
sync
up
with
them
too,
since
I'll
be
happy
to
run
this
release,
and
you
know,
get
everything
out
there
and
and
finalized
probably
do
a
blog
post
to
I
would
expect
to
get
a
little
bit
of
noise
about
the
release
too.
So
I'd
be
happy
to
sync
up
with
wittmeyer
about
that.
C
C
C
A
Okey
thanks
mussalam,
so
this
reconcile
riku
patterns.
You,
you
had
written
a
really
good
doc,
a
very
thorough
document
about
this
recently
and
I.
Do
I,
don't
it
you
know.
Even
the
implementation
is
in
scope
for
0.2,
but
I
just
wanted
to
sync
with
you
on
that.
You
know
if
that
document
had
been
converted
to
you
like,
like
a
full
design
markdown
or
what
the
status
of
that
was
no.
D
I
haven't
because
in
very
next
control,
I
was
working
on
already
diverged
to
some
extent
from
the
pattern
or
so
I
think
it's
still
living
document
I
will
update
it,
as
we
add
more
and
more
controllers.
For
now
we
slowly
organically
narrowing
down
to
the
pattern,
but
it's
not
nothing
yet
to
be
prescriptive,
got
it
figured
it
out.
Do.
A
What
can
you
go
ahead
and
please
add
a
link
like
as
a
comment
in
this
issue
to
do
that
living
document
so
that
the
community
can
reference
it
when
when
they're
viewing?
This
will
do.
Thank
you.
Oh
yeah
appreciate
it
alright.
So
then
this
is
not
gonna,
be
in
0.2,
so
I'm
gonna
go
ahead
and
remove
it
then.
But
thank
you
for
that
information.
Oh
yeah.
A
Go
so
this
this
issue
here,
my
original
vision
for
it
was
was
a
very
narrowly
scoped,
and
this
has
been
something
that's
been
bothering
me
for
a
while,
like,
for
instance,
I'm.
Sorry
when
you
go
to
our
documentation,
I
think
that
there
are
architecture
document
that
we
wrote
up,
but
it
explains
the
vision
and
some
of
the
more
you
know
the
justification
and
the
benefit.
And
all
you
know
all
this
amazing
content
about
crossplane
is
a
super
fantastic
document
and
I'd
like
it
to
be
more
prominent.
A
But
you
know
if
you
go
to
the
documentation,
it's
very
hated
and
where
it's
just
a
little
link
right
here,
you
know
that
links
to
it
so
I
would
like
it
to
be
more
discoverable
have
like
maybe
a
section.
That's
you
know,
architecture
or
vision
and
big
words
here
with
a
link
to
just
so
it
could
cause
out
more
attention
to
it.
C
A
Go
ahead
and
assign
that
to
you
then
Daniel
oops,
your
hash,
Dan
right!
That's
right
are
you?
Are
you
in
the
the
crossplane
organization?
I
am
NOT.
Oh
I
already
sent
you
an
invitation.
Man
we
I
definitely
want
you
to
be
on
that
so
I'll.
Send
you
an
invite
awesome
that
you
can
join
the
org.
Thank
you.
I
thought
you
were
already
in
it.
I'm
surprised,
I,
don't.
A
A
You
and
then
we
have
this
issued
in
Daniel
still
in
be
0.2,
milestone
about
as
your
resource
groups.
I
think
that
Ilya
sorry
Nick
had
given
another
round
of
feedback
about
a
week
ago,
or
so.
What's
the
status
this
and
you
it's
not
a
blocker
for
0.2,
but
you've
put
a
fair
amount
of
work
into
it,
so
it
might
be
nice
to
get
it
in.
What's
the
status
of
that
definitely.
C
So
yeah
it's
it's
fully
functional
I,
think
most
of
Nick
suggestions
were
just
like
kind
of
not
necessarily
bugs
or
anything
like
that,
just
kind
of
preferences.
So
some
of
those
probably
need
to
be
resolved
and
then
look
really.
The
main
thing
is
the
testing
isn't
complete
for
it
and
I've
kind
of
had
some
some
sprinting
to
do
it.
Work
recently,
so
I've
been
able
to
get
to
it,
but
I
think
I
might
actually
have
some
time
tonight.
A
A
C
A
So
just
yeah,
if
you
you
know
bites
tomorrow
or
the
day
after
you
know,
if
you're
not
able
to
kind
of
converge
on
this
and
wrap
it
up.
Just
leave
a
comments
on
that
PR
or
the
issue.
I,
guess
and
I'll
go
ahead
and
clear
it
from
the
milestones.
So
it's
no
longer
included.
There
sounds.
A
I
had
opened
recently
and
we've
had
a
bit
of
discussion.
I.
Think
though
I
guess
it
was
in
slack
is
where
it
was,
but
just
to
give
a
little
bit
of
background
on
this,
because
I
have
a
fairly
strong
opinion
on
this
one.
We're
currently
where
we
are
right
now
in
terms
of
the
quality
of
the
code
base
and
the
maturity
of
the
code
base
is,
you
know,
obviously
still
very
early.
A
We
need
to
have
the
tools
to
do
that,
and
so
we
do
a
very
good
job
right
now
of
you
know,
adding
events
or
status
conditions
to
the
to
the
kubernetes
api
objects
that
are
related,
such
for
instance,
if,
like
a
gke
cluster,
fails
to
deploy.
If
you,
you
know,
use
cube
control
to
look
at
the
details
of
the
gke
cluster
object
or
the
you
know,
good
kubernetes
cluster
resource
claim.
A
All
we
have
to
ask,
are
you
users
is,
do
you
know
cute
control,
logs
command,
a
single
command
did
static
and
doesn't
change.
You
know,
based
on
what
objects
are
in
play
and
we'd
have
a
single
place
to
look
together
at
what
the
issues
are
and
find
help
track
down.
Some
of
these
bugs
I
know:
that's
not
the
long-term
solution
that
we
want.
You
know
the
logs
are
not
necessarily
where
we
want
our.
A
You
know
the
information
to
be
captured,
but
right
now
it
feels
like
a
very
easy
consolidated
place
to
streamline
the
troubleshooting
efforts
that
we
do.
You
know
as
a
community,
so
I
don't.
Maybe
this
is
an
in
scope
for
really
taking
care
of
in
a
complete
way,
insert
a
tube,
but
I
know
that
you
know
when
we
put
another
release
out
being
able
to
easily
troubleshoot
or
reduce
our
burden
for
troubleshooting
as
a
community
is
what
goes
a
very
long
way.
So
does
anybody
want
to
weigh
in
with
opinions
on
this
issue?
A
D
Just
could
watch
I
mean
I,
think
probably
need
gonna
mention
something
and
you
could
force
the
logging
improvement
there,
which
I
think
will
have
ability
for
us
to
differentiate
in
different
levels
of
login,
specifically
debugging
in
debug
log
in
versus
production
run.
So
that
will
help
again,
depending
on
the
issue.
I
found
sometimes
challenging
to
four
locks
to
be
variables
and
in
a
sense
sometimes
where
boss
level
locks
could
be
even
more
confusing
aspect
of
it.
D
When
you'll
say
your
console,
it's
out
tons
of
repetitive
same
log
messages
and
it
fills
up
your
buffer
and
then
sometimes
you
can
say
what
do
you
see
in
the
log?
And
you
will
see
something
on
the
state
of
reconciler,
which
is
already
happened
10
minutes
later,
and
it's
probably
not
even
that
much
useful
but
again,
I
do
understand
the
importance
of
the
debugging.
B
The
the
PR
that
we
touched
on
earlier
adds
the
use
of
a
proper
structured
loggia
that
we
just
copied
a
pattern
from
the
controller
runtime
as
a
bit
of
a
separate
issue.
I
really
don't
personally
liked
the
API
of
the
logger
that
we
used,
but
I
think
that,
regardless
of
my
personal
opinions
about
how
logging
API
should
look,
it
makes
sense
to
use
the
same
patterns
as
the
controller
on
time
but
anyway,
so
that
that
does
is
really
mention.
You
give
us
the
ability
to
distinguish
between
debug
logging
and
regular
logging.
B
B
B
So
I
would
strongly
recommend
that
if
we
do
intend
to
turn
up
our
log
volume,
we
consider
doing
that
at
the
bug
level.
Rob,
there's
there's
a
there's
a
lot
of
pretty
good
thinking
out
there
within
sort
of
the
communities
and
necessary
communities
around
how
to
do
logging
and
water
appropriate.
What
is
the
purpose
that
I
would
further
suggest
that
if
we
have
some
tentative
III
I
think
that
realistically,
if
we
put
a
whole
bunch
of
logging
in
now,
we're
not
gonna
come
back
and
take
it
out
at
some
point
in
the
future.
B
A
I
think
that
you
know
to
be
to
be
very
clear
what
we
don't
know
how
what
I
envision
here
is.
Not
necessarily
you
know,
logging
of
you
know
like
sequential
steps,
necessarily
that
creates
a
lot
of
spam
for
when
actions
are,
are
undertaken.
What
really,
what
kind
of
what
I'm
envisioning
here
is
that
you
know
any
time
you
know
we
have
a
pretty
consistent
pattern
of
our
controllers
having
a
fail
function
that
will
add.
A
You
know
a
failed
condition
with
the
message
or
a
reason
for
it
and
that's
kind
of
what
I'm
thinking
would
be
the
thing
to
add
to
logs
of
when
there's
a
failure,
log
what
that
failure
is
to
so
that
it's
captured
in
a
centralized
place.
You
know
that
has
the
advantage
of
more
likely
than
not
it's
going
to
be
something
potentially
useful.
It's
not
necessarily
something
that
is
permanently
useful,
maybe
a
temporary
condition.
A
That's
true,
but
failures
tend
to
be
some,
you
know
tend
to
be
somewhat
useful,
but
it
also
has
an
advantage
of
it
being
easy
to
if
we
want
to
sort
of
clean
that
up
later.
On
that
you
know,
there's
a
standardized
place
or
a
process,
or
you
know
location
where
that
extra
logging
was
added.
You
know
it's
at
to
the
fail
function
as
opposed
to
sprinkled
throughout
you
know,
reconcile
loops
and
other
random
functions,
so
at
least
it's
easier
to
know
where
it
is
yeah.
I.
D
Think,
maybe
a
couple
worse
also
not
so
crossplane
is
kind
of
share
the
trade
of
classic
kubernetes
deployment,
the
transverse
pod
controllers,
and
so
it's
tempting
to
look
in
the
pods
to
investigate,
following
which
is
great,
but
at
the
same
time,
crossplane.
Application
is
also
a
kubernetes
application
synonymous
to
controllers
of
kubernetes
a
infrastructure.
D
The
close
analogy
I
could
make
saying
that
if
I'm
deploying
something
into
kubernetes
and
my
pod
is
failing,
probably
the
hubell
cubelet
log
or
controller
log
is,
from
the
last
place,
I'll
be
looking
at
I'll,
be
most
likely
interrogating,
kubernetes
api
to
check
and
start
as
a
failure
of
my
pod,
in
other
words,
describe
pod
or
look
in
the
status
fields
in
the
pod
or
deployment
and
so
forth.
While
I
do
understand,
if
I'm
adding
functionality
to
companies
itself,
it's
important
to
look
in
logs
of
those
controllers.
D
In
the
same
time,
I
kind
of
tend
to
treat
a
crossplane
as
a
kubernetes
entity
with
controllers,
so
I
do
understand.
If
user
needs
to
go
to
logs,
it
means
that
the
problem
not
doing
a
good
job
on
reporting
the
status
bag
in
the
primitives
that
we
are
creating,
on
other
words,
what
they
see
rd,
whether
it's
a
controller
somewhat
coming
sorry,
the
other
objects,
in
other
words,
users,
should
be
rarely
meeting
to
go
to
the
log
files
to
see
and
investigate
things.
D
A
We
are
doing
a
good
job
of
that,
but
there
is,
it
still
seems
like
there's.
You
know,
with
the
experience
I've
had
with
helping
users
troubleshoot
that
there's
this
gap,
it
maybe
it's
an
information
gap.
Maybe
it's
an
experience
gap
where
people
don't
know
to
look
in
these
CRD
objects
or
don't
know
how
to
find
the
right.
Crt
object.
It's
it's
still
an
experience
gap
there
and
maybe.
D
It
is
both
I
think
it's
educational
aspect.
We
can
educate
them.
How
to
do
this,
I
need.
When
you
submit
this
file,
you
can
easily
do
keep
detail
file
yet
and
the
same
file
and
you
create
all
the
status
of
all
the
artifacts
in
that
file,
but
at
the
same
time
it's
also
you're
right.
It's
a
user's
helping
us
to
debug
the
application
notice,
we're
debugging
crossplane,
in
which
case
logging
is
important
to
it
as
well.
So
I
see
both
sides
of
it.
I
feel.
B
Like
again
as
a
sort
of
earlier
I
mentioned
before,
we
have
the
ability
to
put
on
debug
log
in
so
I
would
have
no
problem.
Personally
with
having
very
you
know,
if
you
enable
debug
logging,
then
sure
I'll
put
all
the
errors
that
you,
like
I,
think
that
it's
it's
important
to
distinguish
that
a
lot
of
the
things
that
we're
talking
about
here
and
not.
B
These
errors
are
not
indicative
that
crossplane
is
broken
or
has
a
bomb
or
anything
like
that,
so
they're
gonna
be
showing
up
in
the
logs
and
all
it
is,
is
potentially
that
you
know
we've
hit
it
for
xx
while
trying
to
make
an
API
call
or
a
possible.
It
is
sent
wrong,
or
something
like
that,
so
it
gets
I
worried
that
if
it's
like
printing
out
error
statements,
it's
it's
gonna
be
confusing
as
to
is
crossplane
broken
or
have
I
just
done
something.
It's
probably
working
perfectly
fine,
but
I
have
configured
it
wrong.
A
So
is
there
so
the
the
we're
so,
as
stated
before,
we're
doing
a
good
job
of
capturing
these
failures
in
the
CR
D
objects.
Right,
so
was
there
something
cheap?
We
can
do
from
an
education
perspective
of
maybe
like
a
FAQ
like
a
frequently
asked
question
or
a
little
documentation
section.
That's
like
if
something
is
wrong
here
are
a
couple
of
pointers
of
you
know
how
to
get
the
in
like
extra
the
status
conditions
on
a
CRT
object
or
how
to
know
what
CRT
object.
A
B
The
way
that
I
would
address
this,
you
know
not
having
thought
about
it
that
much,
but
a
bit
since
we're
talking
about
at
the
moment.
The
way
that
I
would
address
this
is
do
add
the
logging
that
you
described
at
debug
level,
so
that
if
we
want
an
artifact
of
you
know,
hey
someone's,
like
I,
don't
know
what's
wrong
with
crossplane,
we
can
say:
please
enable
the
debug
flag,
send
us
your
logs
and
we
have
it
all
in
one
place.
You
know
I'm
all
for
super.
B
The
post
logging
in
debug
mode
I
think
that
we
do
need
to
add
some
kind
of
instrumentation.
That
is
not
just
what
we
don't
really
use.
Events
at
the
moment,
but
I
think
we
should
city
using
events.
I
think
using
events
and
statuses
on
objects
is
the
sort
of
kubernetes
pattern
to
do
this,
that
most
things
follow,
which
is
a
little
bit
tricky,
because
it
I
think
that
that
does
become
a
documentation
thing
where
we
sort
of
just
have
to
say
hey.
This
is
the
way
that
the
kubernetes
controllers
typically
do.
B
This
I
think
people
who
are
coming
from
deep
familiarity
with
Kuban
age
is
probably
used
to
doing
that.
I
personally,
was
this.
The
first
place
that
I
looked
when
when
trying
to
debug
things
so
I
think
that
may
be
yep.
Some
sort
of
documentation
would
be
a
good
pointer
there
just
to
be
like
hey.
This
is
how
this
works
in
this
world.
B
You
know
here's
how
you
can
get
this
data
and
I,
furthermore,
think
that
we
do
need
to
consider
having
some
kind
of
time
series
information,
like
your
error,
count
things
like
that
not
for
every
individual
error,
but
we
don't
have
any
observability
apart
from
logging
at
the
moment,
really
so
I
think
something
like
Prometheus
or
something
like
that.
How
binaries
would
be
I
think
useful
in
this
area.
A
Cool
yeah-
that's
yeah,
I
agree,
mostly
mostly
with
all
of
with
all
that
so
I
think
you
know,
potentially
so,
with
the
addition
of
log
of
you
know
a
new
locking
framework
that
allows
us
to
have
a
differentiation
in
logging
level.
A
You
know
that
that
will
be
a
help
here
to
be
able
to
log
more
for
Bhosle
we're
gonna
put
only
but
have
that
behind
a
debug
level
and
then
maybe
a
little
quick
section
that
we
can
refer
people
to
easily
about
you
know
looking
at
conditions
and
looking
at
events
etc
could
be
a
short
term
help
as
well.
Maybe
that's
just
how
we
approach
this.
For
you
know
a
quick
0.2
thing
to
make
the
experience.
C
A
A
A
Other
than
that,
we
already
discussed
the
adjective
resource
groups
PR
with
Daniel,
and
then
I
opened
a
pull
request
last
night,
just
for
some
things
that
I
had
run
into
some
experience,
issues
that
I
had
run
into
while
preparing
a
demo
that
we
gave
to
sig
apps
a
week
or
so
ago,
and
so
it's
a
simple,
pretty
fairly
simple.
You
know
pull
request
just
to
clean
up
the
experience
on
a
couple
things,
but
I
did
run
into
a
Jenkins,
build
air
that
I
have
not
seen
before
that.
I
wanted
to
have
to
make
that
bigger.
A
I
wanted
to
see
if
you
guys
had
had
no
knew
anything
about
this
or
run
into
this
before
so
it
looks
like
when
we're
building
the
docker.
It
looks
like
the
you
know:
the
go
binary
compilation
was
successful,
but
when
we're
building
the
container
image
we're
running
into
this
issue-
and
it's
it's
reproduced
a
couple
of
times,
it
seems
consistent
for
this
build.
Has
anybody
seen
this
type
of
issue
in
the
doctor
build
before
I.
D
The
lately
has
been
very
consistent:
I
just
actually
run
up
tests.
All
your
messages,
I
run
a
couple
of
times,
PRS
and
I
get
tripped
over
the
same
issue
like
noting
that
it's
probably
something
more
permanent
in
the
dependencies
we
use
in
an
attack
range.
Maybe
we
cannot
post
some
of
the
components,
but
again
we
need
to
probably
look
into
the
build
sub-module
I
have.
A
Thank
You
Ilya
I
I
have
a
very
hazy
recollection
of
this
issue
happening
sometime
in
my
past.
In
my
history,
I,
don't
think
it
was
I
think
was
in
Brook.
It
wasn't
in
crossplane
and
for
the
life
of
me.
I
cannot
recall
from
the
deep
depths
of
my
memory
there
on
what
the
core
of
what
the
the
root
cause
of
this
was
doing.
A
A
quick
google
search
for
it
was
almost
all
the
hits
were
around
like
mismatched,
like
carriage
return
line
feeds
like
line
endings,
which
doesn't
necessarily
make
sense
because
I
don't
think
our
docker
file
has
changed
it
all
recently.
I,
don't
think.
We've
touched
it
but
yeah,
it's
all
about
line
endings
in
Windows
environments
and
stuff,
like
that,
so
I,
don't
know,
I,
don't
know
if
we've
made
any
changes
to
our
Jenkins
build
environment
recently,
or
maybe
that's
changed,
but
that's
basically
everything
Google
was
telling
me.
It
was
around
line
endings.
D
A
It
okay
and
so
I'll
follow
up
in
either
with
Marv
or
Ilya
to
see
if
we
can
unstick
some
of
these
pull
requests
and
then
also,
if,
if
anyone
could
take
a
look
at
this,
pull
request
number
362
linked
in
the
agenda
notes
here.
That
would
be
great
because
it
cleans
up
a
couple
things
related
to
experience
40.2.
It
would
be
nice
to
have
that
in
there
okay.
So
that's
all
I
had
on
the
agenda
today.