►
From YouTube: 2020-07-20 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
All
right
the
recording
has
started-
and
this
is
the
july
20th
2020
cross
playing
community
meeting.
Normally
around
the
middle
of
the
month.
We
do
a
regular
release,
a
regular
cadence
since
mid-month
releases
with
the
0.13
progress.
So
far
there
have
been
a
lot
of
work
on
designs
and
you
know
some
of
the
more
complicated
improvements
that
we're
tackling
like
the
crossband
agent
and
refactoring
package
manager,
etc.
B
So
I
believe
that
there
were
only
dock
changes
that
got
committed
into
the
main
crossplane
repo.
So
I
believe
we
had
talked
on
slack
about
pushing
or
skipping
the
this
mid-month
0.13
release,
since
there
were
not
code
changes
that
needed
to
be
pushed
out
from
the
main
crossplane
repo,
but
the
providers
do
need
to
be
released.
We
provide
our
aws
azure,
microsoft,
volleyball
et
cetera,
because
we
did
not
do
those
last
week
sorry
last
month
and
we
have
definitely
do
have
some
changes
of
lands
there.
B
A
Stuff
nope.
That
sounds
about
right,
I
think,
with
nick
out
and
you
and
movavic
on
later
time
zones.
I
could
see
those
going
out
tomorrow,
potentially
instead
of
today,
but
we
might
try
and
get
them
out
today
as
well
for
azure
and
alibaba.
I
don't
think
there
is
a
lot
of
changes,
so
I
have
a
pr
to
open
on
each
of
them.
That
updates
the
way
providers
work,
but
it's
it's
fairly
minimal.
A
So
we
could
look
at
those
a
little
more
but
aws
for
sure
has
a
ton
of
new
functionality,
and
I
have
mentioned
below
which
we'll
talk
about
a
bit
one
pr
I
want
to
get
in
there
and
then
I
think
gcp
is
pretty
much
good
to
go
so
those
should
just
be.
We
can
roll
those
out.
You
know
incrementally
over
the
next
day
or
so,
and
I
think
that
should
be
fun.
B
Yeah
that
sounds
reasonable,
that
there's
not
a
strict
requirement
of
timing
to
get
those
out
and
there's
not
a
strict
requirement,
necessarily
of
making
them
coincidel
or
together
time.
So
I
will
be
online
because
I
still
I
have
a
pacific
time
zone
meeting.
I
think
it
like
2
p.m
or
so
until
3
p.m.
Pacific
so
I'll
be
online
for
another
few
hours
easily
here
so
no
problem
I
can.
I
can
help
like
approve,
pull,
requests
and
stuff
as
needed.
Awesome
all
right.
B
Let's
talk
about
some
of
updates
status
updates
for
some
of
the
big
features.
I
don't
think
that's
as
nick
we
already
said
is
alive
in
montana,
and
I
don't
believe
casey
is
online
today
here
on
the
meeting.
So
is
someone
available
on
the
coach
generation
provider
acceleration
field?
Maybe.
C
Yeah,
I
can
just
give
a
brief
update,
so
you
know
casey
is
in
the
process
of
putting
his
design
dock
together
for
the
terraform
generation.
There
was
an
initial
kind
of
analysis,
feasibility
write-up.
That
was
done,
and
I
think
that
we
dropped
that
in
the
new
providers
channel
in
crossplane
slack,
so
you
can
basically
get
to
that
from
there
and
then
we've
been
having
you
know,
ongoing
discussions.
A
C
A
C
And
some
points
of
collaboration
that
we
can
have
around
that
so
so
that
provider's
channel
is
basically
where
we'd
like
to
have
that
conversation,
so
that
one
of
the
things
that
that
casey's
looking
at
is
in
addition
to
just
getting
out
the
the
terraform
provider.
Acceleration
is
actually,
since
that's
with
the
grpc
api
off
of
a
for
child
process
that
basically
has
the
provider
implementation
in
it.
C
Looking
at
creating
a
more
open
api
at
that
layer,
so
that
that
could
more
easily
plug
into
crossplane
providers
and
so
kind
of
working
through
what
should
be
in
that
open
api
at
that
lower
stateless
provider.
Layer
is
something
that
casey
has
basically
queued
up
for
discussion
in
that
provider's
channel
as
well.
C
So
welcome
everybody
to
to
join
that
channel,
to
share
notes
on
you
know
like
what
you
all
have
going
as
far
as
like
metadata
sources,
code
generation,
and
then
you
know
like
if
you
have
additional
requests
for
providers
or
cloud
services
that
are
needed.
I've
seen
some
discussion
over
the
weekend
pop
up
there
already
asking
about.
You
know
like
what
do
we
have
for
some
eks
resources?
C
You
know,
or
actually
ecr
rather
but
yeah,
so
really
excited
about
that
progress
on
multiple
fronts
and
yeah.
That's
kind
of
what's
going
on
with
codegen
provider
acceleration.
B
Awesome
phil,
thank
you,
and
did
you
say
that
the
providers
channel
on
slack
is
is
where
discussion
is
going
on
there.
C
Yeah
yeah,
and
so
we
just
created
that
you
know
like
last
week
before
that,
maybe
and
so
there's
a
lot
of
side
channel
conversations
going
on
at
the
moment
and
so
we're
hoping
that
we
can
kind
of
bring
that
together
into
that,
that
you
know
public
providers.
B
Channel
cool,
let
me
see
if
I
got
a
link
for
it.
B
B
So
it's
good
thanks
for
the
update
phil
and
if,
if
we
get
a
status
update
on
the
crossband
agent
as
well,
I
know
that
the
design
has
been
merged
and
move
off
is
working
on
some
implementation,
stuff
or
working
on
the
implementation.
C
I
don't
think
so
yeah,
so
the
agent
basically
design,
has
been
out
in
pr
for
a
while
at
merged.
Last
week.
You
know
we
got
feedback
from
various
folks
in
the
community
on
that
and
incorporated
that.
So
so
that
was
awesome
and
yeah
move
off
is
moving.
A
C
With
implementation
on
this,
and
it
looks,
looks
pretty
solid,
we
might
have
some
additional
follow-on
things.
You
know
for
basically
like
surfacing
the
connection
status
of
a
agent
in
a
map
cluster
to
a
standalone
crossplane
instance.
If
there
are
multiple
agents
connected
to
a
you
know,
a
single
name
space
in
a
in
a
control
cluster,
but
apart
from
those
you
know,
fit
and
finish
type
things.
The
the
core
of
the
agent
design
is
pretty
solid
and
just
move
ahead
with
that.
B
Awesome,
great,
and
so
is
the
the
agent
here
is
the
plan
to
keep
it
in
the
contrib
organization
or
like
kind
of
like,
while
it's
being
kind
of
proof
concepts.
You
know
worked
on
it'll,
be
here
and
then
we'll
move
it
to
the
main
org.
B
I
think
that's
something
we
should
probably
follow
up
on
is
to
my
knowledge
or
recollection.
We
don't
have
any
more
defined
process
for
moving
something
from
the
contrib
organization
to
the
main
organization,
and
you
know:
what's
the
criteria,
what
is
the
process?
That'd
probably
be
good
to
write
down
or
formalize
more
so
so
that
it's
you
know
more
clear
and
consistent
on.
You
know
we
can
have
a
good
answer
for
if
somebody
wants
to
move
something
into
the
org
main
work
that
that's
a
consistent
answer.
Yeah.
A
A
I
guess
that
kind
of
depends
on
what
the
bar
is
for
folks
getting
something
into
cross
playing
contrib,
because
I
know
we
want
to
be
relatively
flexible
with
that,
and
then
we
also
as
part
of
that
effort,
might
want
to
discuss
kind
of
like
an
enhancements
proposal
process
too
to
more
formalized.
You
know,
as
you
me,
as
you
have
mentioned,
there
have
been
a
lot
of
designs
coming
through
lately
and
they've
kind
of
just
been
ad
hoc
review.
A
Slash
approved,
and
you
know
the
process
for
each
of
them
hasn't
really
been
necessarily
consistent,
although
it
tends
to
you
know,
be
everyone
kind
of
gets
all
their
things
resolved
and
then
we
merge,
but
especially
in
terms
of
like
once,
we
have
a
1.0
offering.
B
B
Okay-
and
I
was-
I
was
laughing
too
that
while
we
were
looking
at
this
because
you
know
like
the
contrib,
you
know
re
organization,
you
know
with
like
a
lower
bar,
more
proof,
concepts,
incubating
projects
etc,
and
you
know
the
cross
pain
agent,
the
cross
plane
agent.
So
it's
like
it's
very
incubating.
A
Yeah,
so
so
the
pull
request
is
referenced
here
and
it's
honestly
a
little
hard
to
navigate.
At
this
point,
I
think
there's
like
160
comments
or
something
like
that,
which
you
know
makes
sense,
because
this
is
a
pretty
large
part
of
how
crossplane
is
going
to
work.
Looking
at
at
a
kind
of
like
production,
ready,
1.0
commit
to
an
api
level
so
as
part
of
the
review
and
that
which
it's
pretty
up
to
date
in
terms
of
things
that
have
been
generally
accepted.
A
A
So,
just
at
the
very
end
of
last
week-
and
this
weekend,
I
created
this
new
repo,
which
is
basically
testing
out
both
package
manager
from
like
a
controller
perspective
in
the
cluster,
as
well
as
the
cli
to
be
able
to
build
packages,
and
then
you'll
also
see
in
the
examples
repo
iteration
on
what
it
may
look
like
to
write
a
stack
package
which
would
be
kind
of
like
your
compositions
and
stuff
like
that
and
then
a
provider.
A
So
you
can
kind
of
see
some
some
different
layouts
there
and
then
also
in
the
design.
Folder
you'll,
see
notes.
So,
basically,
as
more
functionalities
added
things
are
tested
out,
you
can
kind
of
see
some
of
the
scenarios
that
are
run
and
and
how
that
will
kind
of
like
affect
usage
and
that
sort
of
thing.
So
hopefully
this
can
allow
us
to
do
things
like
get
feedback
from
customers
and
try
something
out
get
feedback
from
users
and
and
quickly
try
things
out
and
see
if
they
would
work
long
term.
A
It's
a
little
bit
of
a
difficult
situation
to
be
in
because
we
do
kind
of
have
this
package
system
right
now
that
we
are
reliant
on
and
we
kind
of
need
a
commitment
to
a.
I
guess:
a
a
solid
api,
v1
v1
beta
1,
if
you
will,
but
we
also
are
still
kind
of
like
trying
to
figure
out
what
what
all
this
needs
to
satisfy.
So,
thanks
for
the
star.
A
And
then
another
thing:
well
I
mean
it's
in
my
my
name,
so
I
felt
kind
of
weird
about
starring
it,
but
but
if
anyone
especially
folks
on
this
call
right
now,
if
you
have
thoughts
about
it
or
want
to
like
try
stuff
out,
please
let
me
know-
or
just
you
know,
drop
it
in
cross
playing
slack
and
we
can
like
kind
of
talk
about
what
that
experience
is
like,
and
maybe
even
you
know,
get
some
distribution
going.
So
so
folks
can
try
it
out.
B
And
did,
is
there
a
good?
Did
you
say,
there's?
Is
there
a
good
entry
point
here
for,
if
folks
wanted
to
try
out
this
experience,
or
you
know
think
about
what
like
an
existing
package,
they
have,
but
you
know
building
it
with
these
tools
instead.
Is
that
is
it
obvious
like
where
she
goes
at
examples?
You
said.
A
Yeah,
I
mean
examples
is
where
it's
kind
of
like
showing
some
things
that
would
work
right
now.
However,
so
there's
the
two
parts,
the
cli
and
the
manager
right
now
right
now,
the
manager
has
just
had
some
work
on
it
and
it's
still
pretty
rough,
but
the
cli
I'm
starting
to
look
at
things
like
linting
and
initialization
that
sort
of
thing
but
are
implemented,
there's
not
a
lot
to
do
with
it
right
now,
but
definitely
we'll
add
to
the
readme.
C
B
C
And
then
dan,
just
a
quick
question,
so
is
the
intention
to
get
like
stage
one
of
that
landed,
maybe
in
the
next
couple
weeks
or
a
week
or
two
as
far
as
the
design
dot
goes
or
like?
How
do
you
expect
that
to
relate
to
the
the
prototyping
you
have
going
on?
Do
you
think
that
that'll
yeah
just
explain
how
you.
A
I
think
I
think
I
mean
phase
one
and
like
kind
of
informs
or
is
informed
by
some
of
the
other
decisions
that
need
to
be
made
so
like
one
of
the
things
we've
been
talking
about
lately
is,
if,
like
providers
need
to
be
packaged
differently
than
stacks
or
compositions
in
terms
of
like.
Do
you
want?
If
you
have
stack
packages
that
rely
on
other
ones,
do
you
need
to
specify
the
providers
at
the
top
level
and
those
like
flow
through,
so
there's
a
couple
different
questions
there?
A
That
would
inform
the
api.
In
my
opinion,
that
being
said,
if
we,
if
you
know,
we
feel
good
about
it
and
want
to
go
ahead
and
implement
some
of
it,
I
think
that
would
be
fine,
but
I
am
a
little
hesitant
until
we
can
come
on
come
to
a
kind
of
like
conclusion
about
what
we
want.
The
user
experience
to
be
there.
A
B
Into
the
next
step,
stand
like
we're
still
trying
to
drive
the
design
dock
to
closure
right.
Are
there
what
they
actually
work?
Really
well
icon
get
lab.
Merge
requests
is
like
they.
They
have
like
a
checklist
of
unresolved
issues
that
they
continue
to
will
a
little
away,
and
so,
like
you,
have
a
pr,
mr
with
like
100
plus
comments,
you
know
you
can
easily
see.
What's
what's
still
left
there
do.
A
I
would
say
so
in
in
the
in
the
design
dock
there's
a
lot
of
like
unresolved
things
that
are
mentioned
there
and
issues
that
are
mentioned
that
need
to
be
addressed.
I
think
we
could
go
ahead
and
move
forward
with
merging
it
as
kind
of
like
this
is
still
in
draft
status,
but
partially
ratified
sort
of.
I
know
before
nick
headed
out,
he
dropped
a
comment
that
he
felt
good
about
kind
of
like
the
package
upgrade
mechanism.
A
You
know
as
as
far
as
if
we
want
to
move
forward
with
the
implementation
of
that.
I
think
that
the
the
rest
of
it
is
kind
of
important,
but
in
terms
of
just
like
getting
the
pr
in,
you
know
just
from
a
functional
perspective
and
review
perspective
and
then
following
up
I'd,
be
fine
to
to
try
and
move
forward
with
that.
B
A
B
Ratified
state
or
anything
like
that
cool,
well,
yeah,
it's
more
of
a
question
like
are
you,
do
you
feel
comfortable
and
able
to
you
know,
are
you
aware
of
the
remaining
things
and
you
know,
or
do
you
need
any
sort
of
guidance
or
help
on
on
driving
driving
them.
A
Yeah,
I
think
I
think,
I'm
aware
of
the
things
we
need.
Clarity
on
just
getting
clarity
probably
is
not
as
clear.
B
Thanks
dan,
okay,
so
that
is
the
status
update
section.
It
says
my
internet
is
unstable:
gonna
stop
the
video.
So
let's
move
down
to
the
next
section
for
communities
dan.
Do
you
want
to
give
us
an
update
of
the
latest
tbs
happiness.
A
Sure
yeah,
so
we
had
kind
of
a
hack
episode
this
week,
which
was
super
fun
where
marcus
who's
done.
A
lot
of
work
on
cross
playing,
came
on
and
he's
now
doing
a
lot
of
work
on
the
packet
side
still
doing
some
cross
playing
stuff,
though,
and
so
we
actually
in
the
48
hours
leading
up
to
it.
A
We
added
a
fair
amount
of
new
functionality
very
quickly
to
the
packet
provider
in
terms
of
networking
capabilities,
so
that
was
pretty
fun
to
be
able
to
do,
and
you
know
just
drove
maturation
of
that
provider.
So
that
was
good
and
then
we
showed
how
to
use
some
of
those
things.
So
we
have
some
assets
that
came
out
of
that.
A
They
are
still
working
on
quite
a
lot
of
documentation
and
such
around
that
so
we
were
actually
able
to
add
a
little
bit
of
documentation
based
on
the
the
problems
that
we
ran
into,
but
overall
was
just
kind
of
a
fun
look
around.
We
had
some
audience
participation
in
that
sort
of
thing,
so,
if
you're
interested
in
maybe
adding
a
new
resource
type
to
a
provider
or
bootstrapping
new
provider,
it
might
be
useful
in
that
regard.
B
Cool
that
was
a
fun
episode
too.
It
was
cool
to
see
to
see
marcus
on
there,
nice
any
any
hints
about
next
tbs
episode,
guests.
B
Right
all
right,
all
right,
cool,
okay,
then
the
next
section
here,
not
a
big,
no
update
on
since
a
distance.
The
the
update
from
last
time
was
that
we
were
accepted
to
the
sandbox
and
we're
actually
a
soundtrack.
So
that's
it's
not
going
to
really
top
onboarding
indiancf.
B
A
B
Yeah,
so
we
can
jump.
I
think
to
the
pr
here
pays
attention.
A
Yeah,
this
is
just
the
this
pr
has
been
open
for
a
little
while,
but
I
finally
got
it
kind
of
wrapped
up
this
morning.
This
is
for
node
groups
on
eks
and
basically,
what
I'm
just
mentioning
here
is.
If
anyone
wants
to
help
out
with
any
manual
testing
there.
I
know
jan
already
mentioned
that
he'd
be
happy
to
jump
in.
A
There
he's
already
helped
quite
a
bit
with
the
kind
of
control
plane
side
of
the
eks
implementation,
so
these
node
groups
are
coming
in
at
v1
alpha
one
because
they
are
a
new
type,
but
they
work
together
with
the
v1
beta,
1,
eks
control,
plane,
side
of
things
and,
if
you're
interested
in
what
this
looks
like
from
the
falco
tbs
episode,
which
is
number
19,
so
that
was
the
one
before
packet.
A
We
actually
used
this
on
just
a
fork
that
I
had
at
the
time
that
was
ready
to
provision
some
node
groups
on
eks
and,
in
my
opinion,
it's
an
easier
experience
than
even
like
eks
control,
or
something
like
that.
A
So
I
definitely
would
love
some
testing
on
there.
We're
going
to
try
and
get
in
pretty
quickly
here,
probably
in
the
next
24
hours
or
so
it
depends
on
if
move
office
around,
to
give
me
some
review
there.
But
I
would
like
that
to
be
in
in
our
coming
release.
A
I
think
it
should,
because
you
know,
without
it
you're
just
gonna-
have
the
control
plane,
components
which
is
still
useful,
because
you
can
spin
up
your
node
pool
separately.
If
you
want
but
yeah,
I
would.
I
would
recommend
we
wait
for
it.
I.
C
Agree
I
mean
we
have
folks
in
the
community
that
have
been
asking
for
this,
and
so
we
told
them
that
it
would
be
in
0.13.
C
So
if
we
could
hold
off
on
0.13
until
this
was
ready
to
land,
I
think
that
would
that
would
be
goodness
but
yeah
getting
it
out
later.
Be
nice
yep.
B
Great
okay
and
then
so
that
is
the
end
of
everything
we
had
on
the
agenda
document
for
the
core
meeting
group
here
before
we
move
into
the
option.
Second
time
section,
anybody
have
any
other
agenda
items
that
they
would
like
to
bring
up.
D
A
Yeah
for
sure,
so
it's
in
the
optional
section,
but
I
think
we
can
go
ahead
and
chat
about
it
phil.
I
know
you
were
kind
of
thinking
about
how
you
wanted
that
to
look
and
I'm
kind
of
doing
implementation
so
I'll.
Let
you
start
off
and
then
I'll
kind
of
like
pick
up
with
any
needed
prs
and
things
like
that
that
that
would
be
okay.
C
Yeah
yeah,
so
maybe
I
could
just
share
briefly
to
kind
of
maybe
set
some
larger
context
and
get
some
feedback
on
that,
and
then
that
might
help
inform
you
know
kind
of
the
discussion
around
the
specifics
around
that
home
chart.
C
So
so
in
terms
of
the
road
map
and
where
we're
thinking
about
you
know
moving
with
with
things
like
the
cross
plane,
connector
agent,
that
basically
kind
of
implements
this
new
pole
based
ux.
Is
that
that's
something
that
would
be
installed
as
part
of
this
cross
plane
application
operator
that
could
be
installed
on
the
target
clusters?
C
C
Yet
this
is
just
kind
of
like
the
current
thinking
that
it
would
be
nice
to
be
able
to
install
everything
as
a
bundle,
so
that
you'd
have
like
the
connector
agent
and
home,
and
you
could
just
install
one
crossplane
app
operator
home
chart
that
would
have
you
know
those
things
and
we
could
basically
like
flag
what
you
wanted
to
install
from
that
that
master
thing,
and
that
could
be
kind
of
you
know
just
the
unit
of
distribution
for
cross
playing
for
the
kate's
native
app
experience.
C
And
so
what
that
looks
like
in
a
little
bit
more
detail
is
just
having
the
app
operator
be
able
to
be
installed
on
any
number
of
the
kate's
clusters
and
then,
with
the
ohm
stuff
working
locally
to
that
cluster.
It
can
just
be
like
a
layer
on
top
of
the
requirements
that
you
would
create
in
that
app
cluster
as
well.
C
As
you
know,
the
standard
you
know
deployments
and
services
that
are
in
kubernetes,
for
that
so
wanted
to
kind
of
float
that
idea
by
everybody
and
if
we
thought
that
that
was
a
good
idea,
then
that
might
help
inform
kind
of
what
we
do
in
the
more
near
term
like
in
0.13
as
a
transition
towards
this
potential
end
state.
D
C
C
That
perhaps
you
know
we
just
have
like
the
master
builds
in
each
of
the
the
repos
for
that
and
then
the
cross
plane
app
operator
would
be
in
a
separate
repo.
That
would
basically
be
the
official
distribution
of
that
you
know.
That's
like
the
cross,
plane,
distribution
and
then
that
operator
home
chart
would
basically
just
have
flags.
That
said,
you
know
you
could
opt
in
or
out
of
any
one
of
the
individual
components
there.
D
Yeah
I
see
does
that
make
is
that
a
conflict
with
om
have
its
own
help,
helm,
charts.
C
I
don't
think
so,
so
I
think
that
ohm
can
still
have
its
own
home
chart,
but
just
for
like
the
the
dev
or
the
master
builds
and
then
like
for
the
official
distribution.
I
think
we
just
want
to
have
like
a
single
official
distribution.
D
C
B
Is
it
archer?
Is
that
a
reason?
What
is
the
the
reason
for
keeping
on
separate
from
the
core
cross
plane.
C
Oh
so
so
we're
moving
to
more
of
like
a
pole
model.
So
before,
basically,
we
had,
you
know
these
two
models
supported,
embedded
mode
where
you
just
install
cross
plane
directly
onto
a
target
cluster
or
an
app
cluster,
and
then
it
just
worked
locally
there
and
that's
like
for.
C
You
create
a
kind
cluster,
you
know
it's
like
a
great
like
onboarding
experience,
but
then
how
crossplaying
was
working
before
is
that
we
would
have
more
of
a
push
model
when
it
came
to
applications,
and
so
here
you
would
basically
have
a
crossplane
running
as
a
standalone
control
cluster
and
then
you'd
have
you
know
the
infrastructure
apis
there,
but
you'd
also
have
like
kubernetes
application.
C
We
had
like
a
wordpress
application,
which
was
like
a
package
type
which
would
install
there,
and
then
it
would
effectively
push
that
configuration
down
with
deployments
and
services
and
namespaces
to
the
target
cluster
and
configure
that
there
and
then
basically
push
down
the
connection
secrets
for
the
infrastructure
that
was
provisioned,
and
so
this
is
basically
just
you
know
like
a
push
model,
and
so
what
we
realize
is
that
it
would
be
much
cleaner
if
we
want
to
enable
you
know
this
consumer
ux
equally
across
all
of
the
different
existing
tools
and
workflows,
to
have
more
of
a
pull
model
where
you
would
basically
replicate
down
all
of
the
crds
for
the
infrastructure
requirements
onto
the
app
cluster
with
the
agent
there.
C
So
the
agent
would
basically
pull
those
crts
down
and
then
the
app
teams
could
just
create
a
single
yaml
file
for
a
requirement
for
a
database
or
a
cache,
and
then
that
would
basically
get
you
know,
pushed
up
to
the
standalone
cross
plane
and
then
the
connection
secret
would
be
replicated
down.
But
then
all
of
the
application
configuration
basically
then
was
done
just
on
that
app
cluster.
So
you
didn't
need
to
create
a
separate
kubernetes
application
and
you
know
basically
inline
all
your
resources
and
all
these
things,
and
so
it
dramatically.
C
Everything
and
made
a
much
cleaner
consumer
model
for
that,
and
so
so
with
that,
basically,
the
core
stuff
is
really
just
the
package,
manager
and
composition
and
so
package
manager
lets
you
install
providers
and
then
with
dan's
updates.
It's
also
going
to
allow
you
to
install
composition
based
packages
that
basically
have
you
know:
infrastructure
definitions,
requirements
compositions
in
there
and
then
that's.
A
B
A
C
I
guess
for
this
audience,
you
know:
it'd
be
okay
to
kind
of
pop
down
to
this
level.
That.
C
You
know
you're
going
to
define
your
infrastructure
definitions,
the
compositions
that
basically
provide
the
classes
of
servers
for
that
infrastructure,
api
and
then
the
publications
and
then
that
basically
makes
those
apis
available
into
one
or
more
name
spaces.
That,
basically,
you
know,
provide
like
a
multi-tenant
isolation,
boundary
for
that
and
then
whoever's
owning
the
app
clusters
can
just
install
the
crossplane
connector
agent
there
and
then
that
will
basically
pull
down
all
of
the
infrastructure
requirements
crds.
So
the
app
teams
can
just
create
that
single
yaml
file.
That's
like
I
need
a
database.
C
C
So
since
this
is
providing
the
like,
the
the
kubernetes
native
app
experience,
it
probably
makes
the
most
sense
to
have
ohm
and
the
connector
agent,
bundled
together
as
like
a
cross-plane,
kubernetes,
cross-plane
application
operator
that
you
can
just
install
and
then
pick
which
install
options.
You
want
here,
so
that
if
you
want
to
define
your
applications
with.
A
A
C
So
I
mean
if
that,
if
that
sounds
agreeable
to
everybody,
then
I
think
the
proposal
would
be
is
like
how
do
we
like
establish
a
stepping
stone
path
from
where
we
are
now
to
this
end
state,
and
so
I
mean
we,
we
could
potentially
create
this
cross-plane
app
operator
helm
chart
like
for
0.13,
but
that
seems
like
a
bit
of
a
stretch
like
a
you
know.
Maybe
it's
like
0.14.
We
get
that
so
I
think
the
proposal
for
0.13
would
be
have
that
same
type
of
sub
chart.
C
You
know
flagging
in
the
cross
plane
core
in
0.13
and
then
when
we
get
the
app
operator,
basically
as
an
official
package,
then
you
know
we
can
just
move
that
that
behavior
over
so.
A
C
Would
have
like
in
ohm,
you
know
a
single
like
master
channel
for
the
home
charts
built
off
of
you
know
for
each
each
commit
on
on
master,
and
then
you
know,
maybe
we
would
name
it
something
like
you
know,
ohm.
You
know
private
dev
or
something
like
that.
That
just
indicated
it
was
just.
You
know
for
kind
of
like
development
purposes
there,
and
then
we
would
be
able
to
then
include.
C
You
know
a
specific
pinned
version
of
that
into
the
the
cross
plane
primary
helm,
chart
in
0.13
and
then
move
that
over
to
the
crossplane
app
operator
home
chart.
Maybe
in
0.14.
D
Seems
like
to
me
that
we
still
don't
have
a
own
chart
yet.
Is
that
something
we
can
do
relatively
fast
or
it's?
It
has
to
tie
it
up
with
this
release.
Cadence.
A
I
I
think
we
can
go
so
you
know
when
the
when
it's
set
up
the
ohm
chart
is
published
on
every
merge.
So
I
think
we
can
go
ahead
and
get
that
going
and
there's
really
just
one
minor
change
that
we
discovered
when
trying
to
troubleshoot
why
it
wasn't
being
published.
So
I
think
we
can
go
ahead
and
get
that
chart
for
master
setup,
and
then
we
can
work
on
getting
that
integrated
as
a
subchart
as
part
of
core
crossplane
for
official
releases.
A
Yeah
definitely-
and
I
don't
know-
I
don't
know
when
1.13
is
going
to
come
out
at
this
point-
maybe
we
do
it
a
little
early
if,
if
we're
happy
with
this
path,
because
this
is
a
decently
significant
change,
but
I
definitely
think
like
this
kind
of
especially
the
the
ohm
master
chart,
I
think
we
could
go
in
like
today
or
tomorrow
and
then
in
terms
of
integrating
with
core
crossplan.
That
might
take
a
little
more
checking
just
to
make
sure
we've
got
everything
right,
but
you
know
very
soon.
C
Awesome
very
cool,
okay,
we'll
all
stop
sharing
and
then
turn
back
over.
You
jer.
B
Great
yeah,
thanks
for
sharing
that
phil
and
then
let
me
know
if
you
need
anything
from
me
in
terms
of
the
final
configurations
or
setup
for
publishing
the
master.
You
know
dev,
whatever
channel
of
the
chart.
A
Yeah
for
sure
I
think
the
the
one
thing
that
was
remaining
was
if
we
wanted
to
create
a
new
bucket
or
use
a
sub
path
of
the
existing
one
for
the
output
artifacts.
Did
you
have
an
opinion
on
that.
B
Yeah,
I
think
I
think,
just
using
the
existing
bucket
and
then
a
little
sub
path
into
it.
That
sounded
since
the
build
system
supports
that,
I
think
that's
the
least
resistance
and
also
fairly
reasonable,
as
well.
B
Awesome,
that's
great
and
then
also
too.
I
think
that
the
what
phil
was
presenting
there
in
terms
of
the
direction
we're
going
and
then
the
segment
of
crossplane
that
focuses
on
apps.
You
know
with
like
the
the
cross-plane
agent
being
able
to
provision
infrastructure
for
apps,
and
then
you
know
the
ohm
implementation
within
plane
that
you
know
absolutely
is
focused
on
apps.
I
think,
but
you
know
that
ship
having
a
release
vehicle
for
those
is
a
fairly
complete
story
on
the
application
side.
That
I
think,
makes
a
lot
of
sense.
C
Sweet
yeah
we're
super
excited
about
it
too,
so
I
think
it's
gonna
really
make
it
a
lot
easier
to
kind
of
consume
from
from
you
know,
kubernetes,
apps
and
stuff,
and
we've
been
getting
a
lot
of
really
good
feedback
on
it.
So
yeah
excited.
B
And
that
is
now
the
official
end
of
the
agenda
items
here.
Any
final
agenda
topics
before
we
adjourn
oh.
C
There
was
one
so
on
the
providers
channel,
I
think
mikko
was
asking
after
an
ecr,
managed
resource,
and
so
I
I
wasn't.
C
C
Cc
dan,
you
and
move
off
to
see
if
you
might
know
of
one
but
there's
issue
149,
which
is
kind
of
like
the
rapper
issue.
For
that
so
yeah
like.
If,
if
you
know,
we
basically
just
get
in
the
habit
of
like
dropping,
dropping
a
comment
on
149
with
a
link
to
like
a
new
issue
or
something
like
that.
That
would
be
awesome.
But
yeah.
We'll
definitely
add
that
to
the
list.
Ucr.
A
Yeah
for
sure,
I'm
fairly
certain,
we
don't
have
that
implemented
right
now,
but
I
imagine
it
would
be.
I
I
need
to
figure
out
from
niko
exactly
what
they're
looking
for
there,
whether
it's
like
actually
creating
a
new
repository
or
if
it's
you
know
something
related
to
running
containers
from
ecr,
so
I'll
definitely
check
into
that.
C
A
C
Yeah,
maybe
we
can
have
that
conversation
on
the
provider's
channel.
I
just
dropped
a
note
in
there.
So
yeah
be
good
good
to
know
what
his
use
cases
are.