►
From YouTube: 2020-04-27 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
April
27th
2020
cross,
flane
community
meeting.
We
are
nearing
the
finish
line
for
the
0.10
release.
We
are
a
little
bit
behind
here,
while
waiting
on
some
big
features
and
support
for
composition
and
further
ohm
supports.
So
we
pushed
the
release
back
a
little
bit
but
I
believe
the
thinking
is
that
we
will
be
ready
to
do
the
release
on
Wednesday,
which
is
the
29th
I,
think.
Is
there
any
any
updates
or
any
dissent
from
that
expectation?
Now.
A
A
There's
been
a
lot
of
work
from
the
community
for
some
pretty
important
stuff
here:
I,
don't
we've
been
kind
of
tracking
these
as
we've
been
going
along,
so
I,
don't
think
we
need
to
go
through
every
item
in
the
list
here
and
there's
some
further
agenda
items
later
in
this
meeting
in
which
we'll
go
over
some
of
these
important
stuff
here.
So
we'll
just
leave
this
as
it
is
I
think
and
we'll
keep
shooting
for
a
Wednesday
release.
B
B
C
B
A
Yeah,
that
sounds
reasonable.
Yeah
I
was
just
thinking
about
that
I
mean
we
don't
need
to
go
off
this
topic,
but
I
was
just
thinking
about
that
yesterday,
actually
of
I,
don't
really
one
of
the
things
that's
interesting
about
like
the
API
versioning
format,
you
know
alpha
beta,
stable,
etc.
Is
that
it
doesn't
do
it's
not
super
granular
in
terms
of
what
the
quality
level
is
like?
How
well
it's
tested
like
what
the
expectations
are?
A
It's
it's
kind
of
more
about
you
know
the
api
compatibility
sort
of
is
the
focus
that
we're
mostly
having
on
it.
So
it's
it's
interesting
that
you
know
you
can
have
like
two
things
that
are
like
a
V
1
alpha,
1
and
1.
Maybe,
like
you
know
very
crashy,
buggy,
not
really
working
and
the
other
one
is
click.
Oh
yeah.
It's
actually
pretty.
You
know
pretty
reasonable.
You
can
still
you
know,
kind
of
start
working
on
this.
It's
more
about
the
api
compatibility.
That
was
just
some
random
musings,
while
I'm
in
quarantine,
yeah.
B
I
was
thinking
about
a
similar
topic
again.
Did
you
go
into
any
depth
on
it
now,
but
one
thing
that
so
composition
has
been
mostly
melodic
and
myself
working
on
it.
One
thing
we
have
done
to
expedite
it
is
merge
piast
without
tests
and
say
that
we're
coming
to
fix
up
the
test,
the
next
PR,
which
is
not
usually
something
that.
A
A
Yeah
we
yeah,
we
did
that
a
little
bit
for
the
templating
controller,
so
you
first
get
it
off
the
ground.
It's
an
engine
for
that
and
I
made
me
in
a
comfortable
as
well.
We
opened
an
issue
to
track
adding
the
tests
to
getting
them
up
to
80%
code
coverage.
So
let
me
followed
on
with
later
later
pull
requests,
but
I
was
not.
It
was
a
bit
against
the
normal
standards.
Do
we
can
we
get
into
it
later?
Sorry,
we're!
Let's,
let's
stick
over
here.
Sorry,
so
that's
everything
for
0.10!
A
D
Provision
by
crossplane
and
service
functions
that
are
provisioned
by
k
native,
so
there'll
be
some
cool
stuff
there,
as
well
as
some
of
the
new
composition
and
OAM
stuff,
brings
up
some
more
topics
about
being
able
to
stitch
some
of
those
things
together.
A
little
bit
better,
so
should
be
some
really
cool
stuff.
There's
also
some
similar
patterns
that
we
share
in
terms
of
Arkin
architecture
and
how
we
build
controllers
and
that
sort
of
thing
so
we'll
probably
get
into
that
which
will
be
of
more
general
interest
to
the
community.
B
Workloads
are
basically
ways
to
take
something
about
c
IX
injected
in
to
see
how
why,
for
instance,
maybe
take
the
end
point
of
a
database
from
c
IX
and
ejected
into
deployment
why
it
was
a
really
good
conversation,
no
actions
from
it
yet,
but
we
did
decide
to
make
a
slight
channel
on
kubernetes
slack
and
meet
every
two
weeks.
So
if
anyone
else
is
interested
in
that
topic
feel
free
to
I,
guess
maybe
ping
me
on
on
slapping
exile
in
Cross,
Plains
laugh
and
I'll
make
sure
that
I
like
you,
the
relevant
details.
It.
A
B
This
there
was
I'd
seemed
like
there
was
quite
a
lot
of
commonality.
Oam
has
a
trait
injector
that
works
in
lis
to
bishops,
service,
binding
injector
and
then
Kay
native
had
something
similar.
There.
Crossplane
was
maybe
the
least
developed
in
this
way,
because
we
sort
of
just
give
you
a
secret
and
say
good
luck.
Here's
a
secret
learn.
B
It,
whereas
they
were
all
starting
to
think
about
how
to
actually
automatically
inject
that
into
workloads.
So
I'd
answer
your
question
today:
yeah
Alibaba,
K
native
and
Red
Hat
all
felt
pretty
similar
in
the
approach
they
were
taking,
they're,
not
identical,
but
close
enough.
That
I
believe
the
the
OpenShift
take
on
it
is
intended
to
be
sort
of
a
common
standard.
So
it
could
be
worth
us
looking
into
that
as
to
whether
we
just
use
their
operator
I'm
talking
cross
plating
to
do
that.
For
us
and.
A
All
right
yeah,
so
that's
the
bindings
discussion
there.
So
we
mentioned
this
in
zero
and
the
zero
to
attend,
update
that
a
lot
of
the
composition
work
was
coming
together
is
Nick.
Is
there
more
updates
for
everyone
on
the
call
about
like
what
the
what
the
scenarios
that
are
supported
are
or
what
the
expectation
of
things
you
can
do
with
the
0.10
release
and
composition,
yeah.
B
A
E
B
We
use
those
two
to
create
a
sort
of
actual
managed
results.
We
found
this
to
be
limiting
in
a
couple
of
ways
one.
It
is
very
hard
to
come
up
with
just
a
common
set
of
claims
that
work
for
everyone,
especially
if
the
claims
are
supposed
to
be
portable
across
clouds
and
things
like
that.
It's
difficult
to
come
up
with
a
common
set
of
fields
that
apply
to
every
possible
SQL
database,
for
example,
implementation
and
the
other
thing
is
that
often
we
want
our.
B
We
want
our
sort
of
primitive,
manage
resources,
sort
of
the
bits
that
you
compose
infrastructure
from
to
be
sort
of
quite
granular,
so
that
we
don't
hold
too
many
opinions.
For
instance,
when
we
give
you
an
azure
database,
we
don't
want
to
automatically
give
you
a
file
or
rule
as
well,
but
you
may
not
want
that.
You
probably
want
to
actually
pick
explicitly
what
you
want,
but
at
the
moment
we
can
only
have
one
claim
to
one
infrastructure,
maybe
I
called
one
managed
resource.
B
So
the
goal
of
this
conversation
design
is
effectively
to
let
you
some
of
the
names
are
going
to
change,
but
it
effectively
lets
you
provide
the
schema
for
your
own
claims.
So
if
our
claims
that
you
get
out
of
the
box
and
don't
work
for
you,
you
could
say
I
actually
want
my
the
claim
that
asks
for
a
my
sequel
to
be
called
my
great
company
sequel
and
have
fields
XY
and
Z,
and
then
you
could
describe
in
Amal
without
leaving
kubernetes
using
a
CR.
B
B
For
instance,
we're
looking
into
eventually
they're
having
it
so
that
if
you
edit,
your
could
be
called
clean
type
thing.
Those
those
changes
will
be
propagated
to
your
manage
resources
that
we
produce.
That
probably
won't
be
there
in
over
ten.
It
will
just
make
them
once
and
then
move
on
with
this
life,
but
the
bare
minimum
functionality
will
be
there,
so
we're
probably
gonna
release
it
a
little
bit
subtly.
We
probably
won't
make
too
much
fanfare
about
it,
because
we'd
like
another
release
to
to
polish
it
off
a
little
bit.
B
A
B
There
are
examples
in
the
Apple
that
you
could
probably
get
a
good
idea
of
how
it
works,
but
there's
no
explicit
paragraph
explaining
them
so
I
had
hoped
to
be
working
on
that
this
sprint,
but
we
ended
up
prioritizing
the
actual
draft
implementation.
So
the
the
design
is
probably
going
to
be.
It's
been
approved
by
Bassam,
it's
probably
gonna,
be
actually
wrapped
up
and
merged
after
listen,
BP
is
landed,
got
it.
A
Okay
and
then
I
was
also
hoping
to
get
a
quick
update
on
all
the
ohm
supports,
and
it
has
been
a
ton
of
work
in
that
area
is
well
and
I
know.
Some
of
the
Alibaba
folks
are
on
the
call
as
well
and
Microsoft
as
well.
Is
there
anyone
who
can
provide
the
entire
community
on
the
call
here
with
an
update
for
home
support
across
one.
D
D
The
post
res
database
in
cluster,
which
is
the
previous
configuration
so
we'll,
have
some
cool
demos
coming
with
that,
and
then
there's
also
some
tangential
work
for
kind
of
like
packaging
up
with
composition,
some
of
the
resources
they'll
be
consumed
by
that
so,
for
instance,
in
Azure
to
provision
a
database
and
consume
it.
You
have
to
set
up
a
v-net
rule
which
Nick
already
spoke
about
was
kind
of
blocked
by
this
one-to-one
claim
class
resource
relationship.
E
D
So,
basically,
last
week
we
have,
there
was
a
PR
merge
that
added
composition,
stuff
that
basically
didn't
have
the
right
permissions
added,
which
we
fixed
right
after
so
that's
what
was
happening.
We
were
running
a
locally.
The
cross
plane
pod
was
essentially
trying
to
list
type
that
it
wasn't
able
to.
So
that's
pretty
simple
fix
as
far
as
the
v-net
rule
stuff.
D
B
Thank
you,
yeah,
hypothetically
from
from
Azure
a
sign
of
things
to
take
cross,
plane,
I,
spin
up
in
Asia,
a
KS
cluster
and
Azure
post,
great
sequel,
server
and
then
deploy
flight
tracker
to
it.
I
believe
we
have
all
the
code
in
place
to
do
that.
We
just
need
to
actually
test
it
and
to
indicate
that
and
as
I
say,
some
of
the
code
needs
needs
work,
but
it's
functional
at
the
moment.
I.
E
B
B
So
that
means
we
might
be
able
to
demo
a
local
variant
of
this
where,
instead
of
deploying
the
flight
tracker
app
to
baku,
Nettie's
cluster,
that's
managed
by
cross-play
and
we
might
just
be
able
to
demo
installing
the
flight
tracker
app
to
the
cost
of
way
across
plane
is
running,
but
using
an
Alibaba
database.
Hopefully.
A
B
C
So
that's
it
in
a
nutshell.
I
just
want
to
make
everybody
aware
of
this
issue
so
that
if
people
have
ideas
or
I
just
noticed,
I
have
three
P's
and
approach
there.
So
any
you
know
I
think
you
might
contribute
to
this
comments
or
questions.
Let
me
know
and
keep
an
eye
on
this
issue
and
you'll
see
you
doc
coming
soon.
That's
it.
A
A
All
right,
let's
take
a
look
at
some
of
these
PRS
here
hashed
in.
Do
you
want
to
mention
this
one
here
I
took
I
took
a
full
pass
to
this
this
morning
at
least
and
provided
limited
like
glue
cuz,
it
looks
good
I
didn't
have
to
have
too
much
feedback
to
provide,
but
is
there
more
you
wanted
to
bring
up
on
this
one
yeah.
D
Well,
I
just
wanted
to
mention
kind
of
what's
happening
here,
because
I
think
it's
decently
significant
change,
yeah
the
impact
yes
and
it's
actually
been
updating
now
with
the
manual
testing
as
well.
So
essentially
we're
doing
is
when
you
install
a
stack
in
cross-language,
namespace
or
cluster
scope,
there's
eventually
going
to
be
a
deployment
that
comes
out
of
that
with
a
controller
or
multiple
controllers
that
are
watching
the
resources
that
are
installed
in
taking
action,
etc.
So,
mostly
you
think
of
providers
or
stacks
or
apps,
or
something
like
that.
D
So
when
those
are
installed
right
now
for
providers,
we
you
basically
package
up
and
installed
out
yeah
mul,
which
is
kind
of
like
a
template
for
a
deployment,
and
the
stack
manager
takes
that
and
then
does
some
modifications,
mostly
around,
like
naming
and
maybe
some
things
passed
in
on
the
stack
and
so
our
cluster
stack
install
and
then
that
gets
created
in
the
cluster
running
against
the
API
server.
So
issue
with.
That
is
that
you
could
pretty
much
potentially
do
anything
you
wanted
and
that
installed.
D
I
am
also
if
there
was
a
malicious
provider
or
something
like
that,
it
could
get
some
pretty
severe
access
to
your
cluster
and
get
like
root
access
on
your
nodes
and
that
sort
of
thing.
So
we
obviously
don't
want
to
do
that
and
it's
kind
of
a
security
concern.
So
what
we're
doing
here
is
by
default.
The
stack
manager
will
now
run
by
wiping
the
security
context
of
the
stack
deployment
and
it
will
set
a
variety
of
fields
that
are
described
in
this
PR
to
basically
allow
these
deployments
to
never
run
as
root.
D
There's
a
couple
of
kind
of
intricacies
around
that,
including
that
a
lot
of
containers
by
default
run
is
route
so,
for
instance,
a
lot
of
our
provide.
We
don't
explicitly
set
the
user
to
be
running
in
that,
so
they
will
try
to
run
his
route.
So
if
you
set
the
security
context
to
run
as
non-root,
then
the
container
is
just
going
to
fail
too
and
you'll
get
a
great
config
air
and
it
won't
run,
which
you
know,
maybe
maybe
that's
fine,
because
we
don't
want
them
to
run
his
route.
D
But
we
prefer
that
if
someone
did
not
configure
their
container
to
run
as
non-root
that
it
could
still
run
if
it
didn't
need
that
root
access.
So
essentially
we
set
it
to
user
100,
and
if,
at
that
point
it's
not
able
to
execute
its
normal
functionality
because
it
needs
root
access,
then
it
will
experience
issues
there.
But
this
has
now
been
tested
and
we
really
shouldn't
see
situations
where
we
need
root
access
and
things
were
installing
into
crossplane.
D
But
if
you
did
want
to,
you
could
always
pass
this
unsecure
pass
hole
deployment
flag
here
which
will
allow
you
to
kind
of
provide
arbitrary
deployments,
there's
kind
of
some
more
design
that
we
may
want
to
do
around
this.
But
this
is
kind
of
a
short-term
security
enhancement,
I
guess
so.
I
think
it'll
be
good
for
the
short-term,
the
the
primary
area
where
there
was
concern
around
this
was
in
the
hosted
cross
plain
scenario.
D
We
have
the
pass
in
some
information
to
be
able
to
connect
to
the
tenant,
API
server,
so
I
tested
that
out
this
morning,
I'm
provide
some
documentation
here
and
then
also
updated
your
design
dock
on
security,
isolation
Jarrid
with
changes
here
so
I
think
it'll
be
a
good
improvement
and,
in
general,
improve
our
security
posture
a
little
bit.
It.
A
D
That's
that's
one
of
the
reasons
why
I
added
run
is
user
part
of
the
security
context,
because
I
installed
provider
GCP
and
we
don't
explicitly
set
the
user
in
there.
So
it's
just
running
as
root
by
default.
So
but
once
we
set
the
user
to
1000,
then
it's
going
to
it's
going
to
still
xq
successfully.
It
doesn't
mean
root
access.
A
D
B
Her
she
and
his
team
have
been
working
on
a
ton
of
requests
over
there,
some
of
which
we
have
already
got
into
PowerPoint
ten.
So
thank
you
for
that
I.
We
we
now
have
dynamodb
table
support
in
cross
plane
and
we
also
added,
obviously
the
one
CashNet
groups
which
were
morbidly
missing
from
our
from
our
AWS
elastic
cash
support.
So
it's
now
way
easier
to
plumb
everything
together
in
elastic
cash
and
there's
still
a
couple
of
other
ones
over
there.
B
So
I
just
wanted
to
check
in
with
her
she
and
his
team
about
which
of
these.
We
should
try
and
prioritize
to
get
merged
by
Wednesday,
because
I
know
that
some
of
them
are
close
to
done
and
I.
Think
I
will
say
that
I
know
that
s3
bucket
and
cash
cluster,
probably
in
my
judgment,
necessary
to
get
in
4.10,
but
any
other
PR
in
this
list
is
up
for
grabs.
First
finish:
I.
E
Think
Silex
I'll
go
yes,
but
I
feel
the
I
am
one.
So
these
three
peers
are
essentially
the
high
fertility.
Implementation
of
I
am
getting
the
policy
the
user
and
the
attachment
together
that
one
and
the
network
resources
is
something
that
I
think
we
should
be
able
to.
But
Rahila
to
before,
on
that,
you
can
comment
on
this:
hey
yeah,
so
the
three
I
am
peers.
I
think
they
are
good
to
go
and
the
network
PR.
It
needs
a
realist
from
aster
and
the
new
reference.
The
pattern
which
I'm
actually
working
on
so
yeah.
D
I,
just
added
this
in
case
folks
want
to
talk
about
this.
It
may
not
be,
it
doesn't
look
like
we
have
too
many
om
folks
on
the
call,
but
this
is
kind
of
related
to
some
of
the
binding
stuff
we
were
mentioning
earlier,
and
the
idea
is
that-
and
you
know
me,
you
have
workloads
and
traits
and
traits
basically
modify
workloads
and
there
may
be
kubernetes
resource
types
from
other
projects
and
that
sort
of
thing
that
wants
to
serve
as
traits
and
if
we
have
a
strict
enforcement
of
having
this
workload.
D
Reference
field
that
we're
not
gonna
be
able
to
essentially
bring
arbitrary
crew,
nays
resource
types
and
allow
them
to
serve
as
traits.
So
there
is
some
ideas
around
this
being
floated
here,
but
I
just
want
to
bring
it
to
people's
attention.
It
looks
like
hong
jiao
actually
just
now
added
this
comment,
but
one
of
the
ideas
here
is
using
labels,
there's
also
an
existing
small
project.
The
trait
injector
that's
mentioned
there,
which
basically
introduces
a
different
object
for
doing
the
binding
of
resources.
So
this
is
just
something
to
keep
in
mind.
F
F
That's
kind
of
just
a
high-level
idea
and
another
thing
is:
we
need
to
find
a
way
for
any
trait
to
know
how
to
apply
to
the
workload
so
they're.
Actually,
three
things
there.
The
first
thing
is
portrayed
in
the
treat.
How
does
it
know
which
workload
it
is
modifying?
So
currently
we
were
using
the
workload
ref,
but
we
think
it
it
will.
It
will
violate
it,
like
the
new
rule
number
one
that
we
will
require
some
restrictive
CRTs.
F
The
second
thing
we
need
to
the
trait
controller
needs
to
know
is
what
sub
resources,
what
related
resources,
either
CID
or
or
native
once
it
is
I'm
modifying
that
part
is
also
missing,
even
even
with
the
workload
ref
review,
you
can
see
the
worker,
but
you
don't
really
know
what
it
is
really
modifying.
So
we
have
a
proposal
actually
I'm
going
to
write
a
proposal.
The
high
level
idea
is,
we
think
it's
a
good
place
to
register
that
in
the
workload
definition
currently,
the
workload
definition
is
pretty
much
a
shame.
There's
nothing
there.
F
We
feel
like
it's
a
good
place
to
put
the
registration
there.
The
registration
will
have
information
about
the
workload.
Basically,
when
you
have
a
say,
you
have
a
workload
CID
and
operator
and
when
you
want
to
bring
it
into
the
OEM,
currently
you
do
a
registration
which
is
put
workload
definition
around
it,
which
I
said
literally,
is
not
nothing
nothing
other
than
just
have
a
worker
definition
and
pointing
to
the
CRT.
So
we
are
thinking
of
in
that
worker
definition.
F
You
can
say
what
are
the
resources
you
generate
so
that
when
a
change
comes,
there's
a
second
way,
so
that
that's
off
the
second
problem
and
the
third
problem
is
how
do
you
get
to
that
information
from
the
trade
point
of
view?
So
from
a
trade
point
of
view,
with
whatever
information
you
put
here,
you
can
find
a
workload
of
CR,
but
you
don't
have
workload
definition
GRE.
F
That
part
is
missing
in
the
you
know,
in
the
om
kernel
or
in
definition,
I
think
we
have
I
had
ist's
I
proposed
something
before
and
Nick
thinks
we
can
just
use
name.
So
basically,
when
you
have
a
treat
CR,
you
find
it
below
CR
and
you
by
convention
you
find
the
workload
see
our
definition
CR
these
and
then
find
out
what
are
the
resource
of
resources
in
that
worker
OCR.
And
then
you
find
that
then
you
get
to
do
the
to
the
gate.
I
see
that
dance
kind
of
generic
generic
trait
recon
Sola.
F
That's
something
similar
that
I
basically
assume
that
the
name
of
the
the
name
is
the
same
and
it's
a
deployment.
You
just
find
it's.
Actually
it's
not
a
prominent
in
that
CR,
you
say
gave
me
the
sub
sub
resource
type,
I,
assume
its
name
right.
You
can
just
find
it
and
then
are
modify
it.
We
go
a
little
bit
step
further
that
then
they,
the
subtype
sub
resource
name,
a
list
of
sub
resource
names
and
GV
case-
are
in
register
in
the
in
the
workload
definition
and
we
find
it
and
then
do
the
through
race.
F
B
F
A
list
of
resources
actually
I
mean
in
density,
I
states
may,
if
it
has
multiple
ones,
they
may
have
problem.
So
we
will
allow
them
to
list
most
multiple
cell
resources
and,
and
then
that
detail
is,
we
will
leave
the
name
out
because
I
think
it's
hard
to
know
the
exact
name.
Sometimes
the
names
that
auto-generated
it.
So
we
are
just
going
to
list
all
the
things
that
is
and
with
this
GVK
and
use
their
own
a
reference
to
identify
if
it
is
something
you
source
of
that,
what
was
yeah
yeah.
B
That
seems
like
a
good
start.
I
have
some
questions
about
how
it
might
work
in
maybe
edge
cases
that
may
go
away
eventually,
but
like
at
the
moment,
for
instance,
we
have
the
local
and
remote
things
that
actually
create
different
types.
One
one,
the
same
workload
containerized
workload
will
either
create
services
deployments
application.
F
B
E
F
B
It's
definitely
labeled
there
there's
a
lot
more
machinery
for
filtering
on
that,
but
that's
when
I
was
talking
about
the
ones
have
anything
in
my
comment
a
few
days
ago,
my
main
thinking
was
labels
usually
mean
hey
there'll,
be
many
of
these
things.
It
kind
of
has
that
implication
so
annotations.
We.
F
B
F
B
Am
also
kind
of
curious
about
the
general
idea.
I,
like
you
know,
we've
already
said
that
workloads
are
things
that
you
can
bring
to
always
sometimes
where
clothes
will
be
designed
for
OAM.
The
CR
will
be
an
OEM
specific
thing,
sometimes
there
in
the
example
that
place,
but
here
there's
the
CD
cluster
from
the
longest
to
get
CD
operator
and
then
he's,
and
so
that
would
work
today
as
a
workload,
but
then
he
was
illustrating
potentially
he
views
density
backup
as
a
trace
of
that
workload.
B
One
interesting
thing
is
presumably
most
cases
where
that
would
work
with
the
existing
cos.
There's
already
a
reference
between
them.
I
would
imagine
that
you
know
the
SD
backup
needs,
so
what
that's
it
cluster
it's
backing
up,
but
it
kind
of
looks
like
it
might
just
take
endpoints
here,
but
I'd
be
curious
to
look
at
a
few
other
potential
cases
here
and
see
if
they
don't
worry,
just
have
a
reference
between
them
to
make
it
work
at
the
first
place,
yeah.
F
That's
another
thing:
I
think
the
whole
om
this
finding
jumping
basically
multiple
multiple
jumps
to
find
the
resources.
Only
if
I
said
the
trade
doesn't
know
what
the
workload
is
working.
This
is,
for
the
case
say
a
very
simple
kitchen:
menu
menu
trades
as
I.
If
this
works
I'm
going
to
change
the
whole
the
way
the
menu
trades
works,
is
it
just
want
to
apply
to
anything
a
lot
of
things?
Some
trains
are
really
specifically
aligned
for
one
type
of
worker.
Then
this
mechanic
doesn't
apply
here.
F
It's
optional
thing,
you
don't
you
don't
have
not
not.
Every
trade
helps
to
follow
this.
It
is
a
way
to
do
a
generic
way
to
eventually
another
go
for
the
sodium
is
we
want,
as
we
mentioned
before,
we
didn't
put
a
policy
there
yet
is
to
allow
a
tray
to
apply
to
multiple
or
class
or
workload.
Instead
of
some
traits
are
really
one-on-one,
but
some
traits
grow
out
traits
or
some
traits.
You
want
to
do
this
to
apply
to
it's
kind
of
like
inheritance
of
you.
F
Can
you
can
apply
to
something
that
you
don't
even
know
like
the
worker
doesn't
exist
yet?
But
as
long
you,
when
the
new
work
will
come
saying,
you
don't
have
to
change
your
trade
to
get
to
that.
If
that
that's
another
goal,
but
the
other
cases
that
you
mention
it,
the
trader
is
clearly
applied
to
certain
workload.
F
B
B
B
D
B
A
Cool
awesome
thanks
for
weighing
in
on
there,
so
that
was
the
last
issue
we
had
in
the
PR
section,
and
then
we
I
think
we
had
already
addressed
this
issue
here.
That
Casey
had
wanted
for
cogeneration.
So
I
think
that
was
everything
that
was
on
the
agenda
items.
Is
there
anything
else
that
this
group
here
wants
to
bring
up
for
discussion
before
we
adjourn.
A
F
Another
another
PR
is
about.
Are
there
some
discussions
about
CI
CB
and
the
test
in
when
I
was
doing
this?
When
I
was
doing
the
example
CRP
ours
on
the
cross
plane,
that's
om,
cognitive
run
Han.
So
any
thoughts
on
that
I'll
give
you
some
background.
The
background
is
I
I
I'm
not
familiar
with
cosplaying
current
CI,
how
CI
works,
but
I
kind
of
had
a
crash
course
on
how
to
set
up.
F
They
have
action
and
also
the
tests
I'm
using
what
kinko,
whatever
is
caught,
which
is
sort
of
ice,
seems
like
a
prevalent
one
so
I'm
using
that
on
the
OEM
run
cognitive
runtime
and
Nick
hi.
Some
thoughts
on
that
in
that
then
I
also
have
some
inputs
on
that.
I
just
want
to
bring
it
up
to
see
what
what
are
the
what's.
The
community's
take
on
that
I.
B
Could
address
the
ginkgo
thing
first,
because
that's
something
that
we
have
a
strong
repeat,
you
know
than
the
other
stuff
I
think
ginkgos
bit
of
an
interesting
one,
because
tube
builder
has
opinions
about
tests
and
they
happen
to
scaffold
out.
Ginkgo
based
tests
go
as
a
language
does
not
like
that
approach
and
I
tend
to
take
I
attended
personally
agree
with
go
so
cross
plane
today
has
no
ginkgo
tests.
B
I
think
we
originally
had
some,
and
we
just
said
no
we'll
just
use
the
standard
library
for
testing
and
there's
a
there's,
a
Google
tool
called
CMP
for
comparison.
We
basically
just
use
testing,
Doherty
and
CMP,
and
it
sort
of
does
the
trick.
I
would
prefer
to
keep
to
the
established
convention
and
not
reintroduced
ginkgo
tests.
I
can
send
first,
it's
it's.
It
is
subjective.
B
It
is
kind
of
a
personal
thing
I
can
send
through
some
of
the
you
know
that
the
government
includes
as
to
why
you
shouldn't
use
things
like
that
yeah,
my
preference
would
be
to
be
subjective
here.
I
think
this.
Is
this
an
interesting
thing
that
we're
all
subjective?
Sorry,
my
preference
would
be
to
be
consistent.
B
Yeah
I
think
there's
an
interesting
thing
that
we're
facing,
as
we
end
up
with
more
and
more
cross
plane,
repos
we're
eventually
going
to
hit
an
inflection
point
where
we
just
say
like
okay,
this
repo
is
robbed
by
that
team
and
that's
even
could
just
pick.
However,
they
want
to
write
tests
and
things
like
that.
B
But
while
we
have
a
relatively
small
group
of
us
all,
work
across
several
repos
I
think
that's
valuing
following
the
conventions
and
when
we
want
to
change
potentially
you
know
if
we,
if
we
really
love
liking
HOH
or
are
you
testing
library
I?
Would
love
us
to
sort
of
be
like
hey?
Let's
change,
testing
libraries
like
I,
said
as
a
conscious
decision
across
a
little
repos
sort
of
thing.
Well,
I
agree
that
we're
gonna
do
this
everywhere
and
then
stop
moving
in
that
direction.
Yeah.
D
One
of
the
things
that
I
mentioned
on
that
PR
specifically
was
so
this
PR
is
adding
integration
tests,
which
is
something
that
we're
pretty
light
on
right
now,
so
I
know
I
mentioned
on
there
Ryan
that
I've
been
working
on
some
table
based
integration
tests.
Basically,
so
I
will
be
adding
some
of
those
for
you
to
take
a
look
at,
and
we
can
kind
of
look
at
that.
So
I
owe
you
a
PR
on
that
repo.
F
B
B
Write
you
de
tested,
there
was
a
big
debate
about
what
the
right
way
to
write
you
to
test
is.
But
this
thing
that
I
just
put
in
the
chat
is
what
the
go
project
feels
about
uh-oh.
Sorry,
they
have
a
single
one
for
testing,
but
anyway,
yeah
I'll
send
a
thread
later
as
to
the
github
actions
and
how
we
actually
run
the
CI
CD
I'm
intrigued,
I
kind
of
think.
The
github
actions
make
sense.
B
Personally,
we
currently
and
historically
her
from
Jenkins
CI
CD,
but
the
Jenkins
instances
are
sort
of
owned
and
operated
by
a
bounded.
I'm,
not
sure
if
we
have
any
Garen
can
speak
to
this,
but
potentially
I'm,
not
sure.
If
we
have
any
process
to
give
people
who
aren't
our
parent
employees,
access
to
the
CICS
sister
updated
things
like
that.
Yeah.
A
That's
something
that
we
definitely
can
do
because
you
know
we've
had
a
fairly.
You
know
pragmatic
approach
to
productivity
of.
If
you
know
somebody
needs
access
to
improve
or
to
maintain
the
CIC
be
pipelines,
then
you
know
as
a
cross
plane
community
member,
then
that's
something
that
I
don't
have
a
problem.
Giving
access
to
yeah.
B
I
know
that
there
has
been
some
stuff.
I
am
not
sure
how
much
we've
talked
about
this
and
community
meetings
did
I
know
that
you
know
we
talked
about
potentially
as
part
of
moving.
Those
Jenkins
is
persist,
so
they're
not
in
the
amount
I
owe
domain,
and
things
like
that,
so
they
feel
like
more
community,
but
I
fear
that
sorry,
yes,
I
was
there
was
a
discussion.
B
So
I
think
there's
a
couple
of
things
here
like
we
also
use
a
get
some
module,
that's
on
to
the
upbound
github
log.
That
is
also
used
by
our
internal
engineering
projects.
I
think
there's
this
I
think
at
some
point.
Maybe
after
the
Oh
point
10
release.
Basically,
we
might
move
us
to
sit
down
and
think
about
whether
we
can
make
a
CI
CD
system
a
little
bit
more
community
friendly.
B
That
is
at
the
moment,
I
personally
agree
they're
not
strongly
tied
to
Jenkins
as
the
thing
that
actually
invokes
the
build
so
much
walls
that
I
don't
see
why
we
wouldn't
consider
moving
to
github.
That
gives
you
some
quite
nice,
yeah,
well
sort
of
based
sort
of
equivalents
to
the
Jenkins
file.
Basically,
I
started
experimenting
with
github
actions
as
a
way
to
write
out
linty
this
week
as
well.
So
there
are
decisions
that
I
think
you
should
look
into
it.
Yeah.
A
And
what
other
things
didn't
think
it
would
be
most
interesting
there
is
that
you
know
we
go
we
cross
compile,
so
we
do
Army
any
of
these
explore,
builds
and
I.
Don't
I,
don't
know
really
anything
about
github
actions,
but
that
would
be
an
immediate
thing
to
check
out
of
can
with
github
actions.
Can
you
end
up,
you
know,
doing
cross
compilations
and
for
multiple
architectures
and
stuff
like
that?
Yes,.
E
B
Yeah
I
think
it
could
be,
could
be
nice
as
well
to
maybe
get
a
few
of
us
to
get
together
and
maybe
likes
beautiful
design,
don't
care
anything
but
I'd
sketch
out
a
direction.
The
proposed
is
what
we'd
like
to
do
with
CI
CD.
That
way.
Folks,
like
Jared
and
basalt,
deep
experience
with
the
currency
ICD
system
can
call
out
edge
cases
like
that
and
just
make
sure
that
we're
ticking
all
the
boxes.
F
Yeah,
oh
boy
idea,
I
mean
I,
agree
with
all
these
just
because
we
wanted
at
least
from
om
standpoint.
We
want
to
attract
as
many
outsider
and
community
contributors
as
much
as
possible,
and
so
anything
that
is
standard
community
standard
feels
like
will
be
helpful
in
that
way.
It's
just
a
bad
one
for
that.
You.
B
Know
I
think
that
you
know
Jenkins
versus
get
always
you
know.
Jenkins
is
the
500-pound
gorilla
here.
Many
people
have
worked
with
Jenkins
before
so
it's
it's,
not
no
one
really
likes
Jenkins
in
my
experience
but
but
but
I
shoot
plenty.
People
know
it.
One
thing:
that's
nice
about
github
is
we
just
covered?
You
know
when
Ryan
was
I.
Think
there's
Lucy
I
think's
is
that
you
don't
have
to
separately
grant
access
to
Jenkins.