►
From YouTube: Expanding Interoperability in the CD Ecosystem - Ishan Khare, Loft Labs & Mauricio Salatino, VMware
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Expanding Interoperability in the CD Ecosystem - Ishan Khare, Loft Labs & Mauricio Salatino, VMware
JW Grand Ballroom 3
Speakers: Mauricio Salatino, Ishan Khare
Building an inclusive ecosystem where you can connect different tools built using different technologies and languages is hard, as different tools tend to promote different protocols and similar but not the same architectural patterns. This presentation focuses on the CDEvents initiative led by the SIG-Events Working Group at the CD Foundation. During this presentation a new use case will be presented showing how tools like Knative, Tekton and Crossplane can work together by just relying on CDEvents, no custom libraries, no forced protocols, just a standard and reactive way to interconnect disparate systems that were created by different communities with different purposes. We have a demo in place that we're working on and would like to present it demonstrating the whole flow end-to-end.
A
All
right,
let's
get
started
this
is
this
is
going
to
be
a
pretty
fast
session,
I
would
say
around
expanding
interoperability
in
the
cd
ecosystem.
My
name
is
maurice
salatino
and
I
should
be
doing
this
presentation
with
ishan
kari,
but
he
couldn't
make
it
unfortunately,
so
he's
probably
watching
online
or
probably
will
watch
the
recording,
but
most
of
the
things
that
we
build.
We
build
it
together
and
he
did
a
great
job
in
preparing
all
the
content
for
the
demonstration
that
I
will
be
showing.
A
So
today
I
will
be
talking
a
little
bit
about
like
a
specific
use
case
that
we
try
to
build
in
order
to
start
demonstrating
different
use
cases
for
cd
events.
Cd
events
is
a
cd
foundation
project.
We
have
been
talking
about
that
project
a
lot
here
in
the
conference.
So
if
you
are
not
aware
of
the
project,
please
feel
free
to
reach
out.
A
Why
we
think
that
for
use
cases
like
this,
this
is
important,
and
then
I
will
spend
the
second
half
of
the
presentation
just
showing
a
demo
and
basically
discussing
all
the
challenges
that
we
faced
when
we
were
building
the
demo
and
also
what
we
believe
the
next
steps
should
be.
So,
as
I
mentioned
before,
my
name
is
maurice
latino,
I'm
at
salavoia
twitter.
I
do
work
for
vmware
as
a
staff
engineer
and
I'm
working
for
a
project.
A
That's
called
k,
native,
that's
very
on
the
kubernetes
space
right
like
so,
if
you're
in
the
kubernetes
space,
that's
something
that
you
install
on
top
of
kubernetes
to
make
your
life
easier,
and
I'm
also
you
know,
writing
a
book.
There
is
a
discount
code.
If
you
want
to
have
the
early
access
program,
if
you're
interested
in
this,
don't
you
don't
need
to
copy
that?
A
Just
ping
me
later,
and
I
will
give
you
that
again
and
what
I'm
looking
from
this
from
from
the
book
perspective
in
this
conference
is
just
getting
feedback
from
people
more
than
people
buying
the
book.
It's
just
more
getting
feedback
just
looking
at
the
table
of
content,
and
you
know
just
getting
back
to
see
if
that
makes
sense
or
not
yeah
the
book.
As
you
can
see,
it's
a
continuous
delivery
for
kubernetes,
so
it's
very
kubernetes
oriented
and
it's
only
discussing
kubernetes
related
projects
and
everything
is
open
source
in
there.
A
So
you
will
have
different
teams
that
can
just
go
and
request
different
environments,
and
we
should
provide
like
this
platform
that
basically
allows
you
know,
allows
them
to
self-service
and
just
go
and
request
for
environments
and
then
get
the
environment,
so
they
can
do
their
work.
So
you
can
see
at
the
bottom.
A
There
are
like
different
environments,
they
can
be
configured
differently,
but
at
the
end
of
the
day,
this
developer-
these
developers
just
want
to
you,
know,
be
able
to
deploy
their
applications
in
there
and
we
want
to
automate
all
this
process
right
and
if
we
want
to
automate
all
this
process
nowadays
with
open
source
projects.
Well,
you
need
to
use
a
bunch
of
tools
in
order
to
achieve
this
and
that's
kind
of
like
what
we
are
trying
to
show
here,
how
to
glue
together
different
tools
to
achieve
something
like
this.
A
So
what
we
wanted
to
build
like
initially,
is
like
this
platform
that
will
allow
people
to
request
environments
and
these
environments
will
be
created
and
made
accessible
for
them
to
work.
These
environments
are
not
just
kubernetes
clusters
per
se.
They
are
like
kubernetes
clusters
with
a
bunch
of
tools
installed
into
them,
so
we
don't
push
developers
to
play
around
with
kubernetes
and
install
things
that
should
be
provided
by
the
platform
and
because
we
don't
know
actually
how
these
environments
will
look
like
in
10
days
in
a
couple
of
months.
A
We
need
to
make
sure
that
our
platform
itself
is
expensive
and
we
can
just
keep
adding
more
tools
into
the
platform
to
add
more
crazy
automations
in
there.
So,
in
order
to
achieve
that,
we
need
to
basically
glue
a
bunch
of
different
tools
that
were
probably
designed
by
different
teams
in
different
ways,
using
different
concepts
all
together
just
to
achieve
that,
and
we
want
to
avoid
something
that
we
discussed
in
the
in
the
previous
panel.
We
we
need
to
avoid,
like
building
point-to-point
integrations
like
we
should
avoid
at
all
cost.
A
During
this
presentation
I
will
be
using
specton.
I
think
that
tekton
is
a
cd
foundation
project.
I
don't,
I
will
not
go
into
details
on
explaining
this.
It's
just
the
pipeline
engine
built
for
kubernetes
that
you're
installing
kubernetes
and
then
you
can
just
define
your
very
unopinionated
pipelines.
You
can
define
whatever
kind
of
a
plane.
You
want
it.
A
You
can
do
whatever
you
want
with
tecton,
so
it's
pretty
cool
and
if
you're
building
platforms
like
the
ones
that
I'm
describing
it
it's
very
handy,
I
will
be
using
crossplane
something
that
it's
not
so
familiar
like.
I
would
say
from
the
cdf
perspective
and
I
would
love
to
know
how
many
of
you
folks
know
what
crossplane
is.
A
Oh
wow,
perfect.
Okay,
so
for
the
ones
that
don't
know
what
cross
plane
is
it's
basically
a
tool
that
allows
you
to
provision
infrastructure
using
kubernetes
resources,
so
you
can
define
in
the
same
way
that
you
define
a
pipeline
in
tecton
or
a
service
in
kubernetes
itself.
You
can
define
cloud
resources,
let's
let's
say
an
s3
bucket
or
yeah,
or
a
kubernetes
cluster
using
a
kubernetes
source.
A
We
are
using
cd
events,
and
this
is
where
having
a
common
vocabulary
is
important,
because
we
want
to
make
sure
that
when
we
use
all
these
tools
at
least
we
have
a
common
understanding
of
what's
going
on,
without
looking
at
all
the
events
that
each
of
these
tools
are
generating
right.
So
you
can
imagine
if
you're
running
a
pipeline,
if
you're
creating
clusters,
all
these
tools
will
be
generating
events
in
different
formats
with
different
amount
of
information.
And
what
do
you
want
to
do
with
cd
events?
Is
you're
going
to
have
like
this
more?
A
You
know
view
across
the
board
of
what's
going
on.
We
want
to
implement,
as
I
mentioned
before,
like
this
idea
of
an
implementing
like
an
event
driven
integration
approach.
So
we
don't
build
point-to-point
integrations
between
the
different
tools
we
emit.
Events
like
want
to
limit
an
event
that
the
other
tool
can
understand,
and
then
they
can
react
and
the
main
reason
to
do.
A
It
will
have
k
native,
which
is
in
charge
of
receiving
events
and
routing
events
to
different
components,
and
it
will
have
tecton,
which
is
going
to
be
in
charge
of
orchestrating
these
other
tools
right,
like,
for
example,
receiving
an
event
and
then
just
triggering
a
pipeline
that
it's
going
to
install
some
resources
in
the
cluster
to
create
another
kubernetes
clusters
or
s3
buckets
or
whatever.
We
want
to
create
and
the
developer
what
it
will
get.
A
It's
a
kubernetes
environment
with
some
with
some
tools
installed
right
like
in
this
case,
we
are
going
to
create
an
environment,
a
new
kubernetes
cluster.
We
will
install
kn80,
which
is
something
that
you
install
inside
the
cluster
and
that
cluster
will
be
also
enabled
to
emit
events
to
the
platform
cluster
to
notify.
What's
going
on
in
there
right
again,
we
are
creating
multiple
environments
from
a
platform
cluster
and
we
want
to
be
able
to
see
in
one
single
place
all
the
events
that
all
these
things
are
generating.
A
So
we
kind
of
like
get
an
overview
of
what's
going
on,
so
the
demo
is
going
to
be
very
simple.
The
first
part:
it's
we
request,
like
the
developer,
will
create
a
request
for
a
new
environment.
We
will
wait
for
that
environment
to
be
created
and
then
the
developer
will
use
the
environment.
It
sounds
so
simple,
but
you
will
see
the
diagram
now.
It
becomes
quite
complicated.
There
are
a
bunch
of
things
that
needs
to
happen.
A
So
this
is
how
it
will
go.
I
will
just
go
and
create
a
request
to
the
platform
cluster
right.
This
request
can
be
anything
I
will
be
sending
an
http
request
with
the
cloud
event
to
the
you
know,
to
the
event
broker
in
this
case
that
it's
running
inside
the
platform
cluster,
and
then
we
have
a
component
in
tecton
that
basically
will
understand
this
event
and
it
will
trigger
a
pipeline
and
that
pipeline.
A
What
it's
going
to
do
is
going
to
install
some
resources
in
crossplane
that
basically
define
how
to
create
a
new
kubernetes
cluster,
as
I
mentioned
before,
I'm
running
all
this
stuff
in
google
cloud.
That
basically
means
that,
at
the
end
of
all
this
chain
of
events,
we
are
going
to
get
a
kubernetes
cluster
being
created
inside
google
cloud
right.
A
A
So
I
have
a
simple
call
request
here,
which
is
basically
sending
a
you
know
cloud
event:
http
post,
like
I'm
just
sending
that
to
this
url,
which
is
basically
where
the
canadian
eventing
broker
is
and
I'm
sending
just
a
cloud
event
encoded
in
an
http
request
with
some
payload
right.
It's
a
pretty
simple
stuff,
nothing
complex!
You
can
actually
create,
like
a
user
interface
like
a
website
or
like
a
portal,
to
actually
request
that
and
parameterize
what
you
want
to
create.
A
So
let
me
run
that
you
know
that
scroll
create
cluster
and
before
running
that,
let
me
run
this
command,
because
that
component
is
not
running.
Okay,
let's
run
that
so
I've
just
executed
the
request.
The
only
thing
important
here
is
k.
Name
telling
me.
I
got
an
event.
I
will
just
do
whatever
I'm
configured
to
do
with
that
event,
which
basically
means
I
received
an
event
and
then,
depending
on
who
is
configured
to
you,
know
to
to
consume
that
event.
A
I
would
just
forward
it
to
to
that
location
in
this
case
that
location
is
the
tecton
pipeline.
That
is
waiting
for
that
to
happen.
So
if
I
move
to
the
tecton
dashboard
here,
you
will
see
that
there
was
a
tecton
in
this
case
like
it's
just
the
task
that
was
created
and
it
run
a
bunch
of
stuff
this
steps.
Basically,
the
only
thing
that
are
doing
is
just
installing
these
crossplane
resources
that
I
mentioned
before
that
define
how
to
create
a
cluster
in
google
cloud.
B
A
I
just
automated
the
creation
of
that
cluster
by
using
crossplane
that
it's
configured
to
use
my
you
know
my
google
cloud
credentials
to
go
and
create
cloud
resources
again.
This
is
going
to
take
around
five
minutes.
Usually
it's
not
more
than
that.
So
now
we
can
just
sit
and
wait.
No,
not
not
not.
Yet
there
are
a
bunch
of
things
that
we
need
to
see.
A
First,
I
I
have
configured
all
the
events
from
all
the
tools
that
I'm
using
to
be
forwarded
into
like
a
single
place
here,
so
we
can
just
actually
see
all
the
cloud
events
and
you
can
see
that
this
is
a
fair
cloud.
The
first
cloud
event
that
I
manually
submitted
as
a
developer,
but
then
below
you
see
all
the
techno
events
that
were
created.
These
are
just
normal
cloud
events.
They
are
not
cd
events,
but
they
are
normal
cloud
events
that
techton
is
automatically
generating
and
sharing
you
know
with
the
ecosystem.
A
So
all
the
tools
can
look
at
these
cloud
events
and
react
to
them.
There
are
a
bunch
of
of
events
here,
depending
on
how
many
tasks
we
have,
and
you
know
how
many
steps
so
yeah
that's
going
to
basically
describe
the
pipeline
and
that's
fine.
We
might
be
interested
in
looking
at
all
these
low-level
events
or
we
might
be
able
to
just
filter
and
only
look
at
the
very
high
level.
A
Events
which
are
in
this
case,
expressed
by
the
cd
events
vocabulary
what's
happening
now
is
again
it's
the
cluster
is
being
created
and
we
have
created
another
component
here.
That's
the
time
to
go
back
to
the
presentation
I
have
created
another
component
here:
that's
called
cross
plane,
cd
events,
which
is
basically
a
small
controller.
That
allows
allows
us
to
monitor
crossplane
resources,
in
this
case,
like
this
cluster
resource,
that
we
have
created
and
check
for
when
the
resource
changes
the
status
right.
So
what
we
have
something
that
I
didn't
show.
A
So
it's
been
provisioned
crossplane
is
monitoring
this
resource
and
as
soon
as
like
this
resource
change
to
ready.
The
new
controller
that
I
was
showing
you
here
in
the
diagram
is
going
to
notif
notice
that
that
that
resource
changes
status
and
it's
going
to
generate
another
cloud
event.
As
you
can
guess,
we
are
going
to
send
that
cloud
event
into
the
broker.
A
This
cloud
event
in
this
case
it's
one
of
the
cd
events
that
is
included
in
the
vocabulary
in
this
case,
representing
that
the
new
environment
is
ready
to
be
used.
So
we
have
like
a
ready,
like
an
environment,
ready
event
that
is
going
to
be
dispatched
in
there
and
then
again,
because
this
is
just
an
event
router,
we
can
just
create
subscriptions
to
see
where
that
event
is
going
to
be
consumed.
A
In
this
case,
this
event
is
going
to
be
consumed
again
by
tecton,
and
we
will
just
trigger
another
pipeline
to
install
some
tools
inside
that
cluster
that
we
just
created.
So
the
loop
here
is
that
we
wait
for
the
cluster
to
be
ready
and
then,
when
it's
ready,
we
are
just
going
to
go
and
install
some
tools
in
there.
So
the
developers
don't
actually
need
to
go
and
install
tools
in
a
kubernetes
cluster.
We
can
automate
all
this
stuff.
A
There
is
no
need
to
ask
a
developer
to
install
stuff
and
then
just
break
the
entire
environment,
and
we
will
need
to
recreate
and
all
that
stuff.
The
things
that
we
are
going
to
install
in
there,
as
I
mentioned
before,
is
a
k
native
k
native-
has
another
module
that
it's
called
serving
that
it's
pretty
useful
when
you
are
the
client
creating
functions
like
serverless
functions
that
you
want
to
deploy
in
there.
A
So
we
are
going
to
install
k
name
in
there,
which
basically
will
allows
us
to
go
from
source
from
source
code
to
having
a
url
of
a
function
that
we
can
use
to
interact
pretty
quickly,
and
I
will
be
showing
that
in
a
bit.
But
more
importantly,
for
this
presentation
is
that
we
are
going
to
install
another
controller
there.
That
is
going
to
be
watching
k
native
resources.
A
A
You
can
see
that
the
cluster
is
created.
Now
it's
waiting
for
the
machines
of
the
cluster
to
be
ready.
So
we
can
start
actually
deploying
stuff
on
top
of
it.
My
expectation
would
be
that
oh,
this
is
look.
This
is
ready
already,
so
my
expectation
would
be
that
as
soon
as
we
get
the
environment
created
event
that
basically
means
that
the
cluster
is
ready.
A
And
if
you
are
building
a
platform,
probably
you
will
try
to
avoid
your
developers
doing
this
kind
of
stuff
like
going
to
google
cloud
to
connect
to
the
cluster,
you
will
just
provide
an
easy
way
to
get
the
credentials
for
connecting
to
that
cluster,
not
in
this
way,
not
using
the
gcloud
command
line
tool,
as
I
will
do
right
now.
So
if
I
copy
that,
basically
I'm
connecting
to
this
new
cluster
that
it's
that
was
just
created-
that's
pretty
interesting.
It
says
that
it's
still
not
running
and
the
kubernetes
apis
are
not
ready.
A
This
is
where
kind
of
like
live
demos
can
go
really
really
wrong,
but
it
seems
that
it's
there
right.
It
seems
that
it's
there.
It
seems
that
the
node
pool
is
still
not
there,
like
the
machines
that
are
in
charge
of
running
these
components
are
not
there.
That's
why
it's
pending,
so
it
hasn't
been
scheduled
to
to
a
node.
Now
the
machines
are
ready
and
the
container
is
being
scheduled.
Probably
the
container
image
is
being
uploaded
to
that
node
and
at
some
point,
when
it's
done
it's
going
to
actually
run,
which
we
should
wait.
A
It's
running
now.
So
now
the
the
container
is
running.
I
can
list
the
namespaces
here
in
this
cluster,
just
to
show
you
that
k
native
was
installed
right,
so
canary
was
installed
in
that
cluster.
This
cluster
didn't
existed
when
I
started
the
presentation
now
it's
up
and
running,
and
I
can
also
do
like
get
posts.
The
things
that
I
did
before
just
to
show
you
that
this
is
this
is
a
small
controller
that
basically
is
looking
for
canadian
resources
and
communicating
back
to
the
platform
cluster
whenever
we
deploy
a
new
service.
A
So
the
last
part
of
the
presentation
that
I
wanted
to
do
is
just
basically
build
quickly,
a
function
using
k
native,
so
I
can
just
deploy
something
into
that
cluster
and
see
in
the
platform
cluster
that
we
receive
an
event,
and
then
we
can
just
do
something
with
that
event,
in
order
to
create
a
function,
I
will
be
using
something
in
canada.
It's
called
canadian
functions.
This
is
the
project
that
I'm
working
on,
I'm
pretty
passionate
about
it.
A
A
I
can
open
this
in
my
in
my
id
here,
which
is
black
background.
Sorry,
I
will
just
try
to
make
it
bigger.
This
is
pretty
much
a
function
you
can
do
whatever
you
want
in
here
inside
the
function
connecting
to
databases
connecting
to
a
bucket
or
whatever
you
want.
In
this
case
we
are
just
going
to
return
a
string
here,
hello,
cdcon
right.
Let's,
let's
create
some
cd
events
right,
that's
pretty
simple!
A
You
can
just
create
a
function
here,
just
code,
your
function
in
any
language
that
you
want.
You
can
create
functions
in
java.
You
can
create
functions
in
rust
and
in
python
in
node.js,
in
whatever
you
want
and
then
just
use
func
with
build
packs,
in
this
case,
to
not
write
docker
files
to
not
write
jamal
files
to
the
deployment,
and
the
cli
in
this
case
is
going
to
take
care
of
all
the
steps
to
actually
do
that.
A
As
you
can
see
here
at
the
bottom,
it's
basically
saying:
okay,
yep
everything
is
ready.
I'm
waiting
for
the
service
to
be
ready
in
the
cluster
that
I
just
created
and
the
next
line
it
should
be
the
url
for
where
that
function
is
running.
So
I
have
a
new
cluster
that
was
created.
I'm
deploying
a
new
function
in
that
cluster
and
if
I
use
http
just
to
call
that
function,
I
should
be
able
to
get.
A
If
I
go
back
to
the
platform
cluster
or
this
scan
like
ui,
where
I'm
seeing
all
the
events,
I
should
be
able
to
see
here
that
at
some
point
I
received
like
service
deployed
event.
Let
me
see
which
is
probably
not
there,
it's
better.
If
we
see
it
here,
I
guess
so
here.
What
I
will
see
is
that
I
got
like
a
new.
A
You
know
task
executed
here
by
tekton,
which
is
basically
the
tasks
that
will
be
executed
when
a
new
service
is
deployed,
and
if
I
look
here
at
some
point,
I
think
that
I
would
just
find
it
like
a
service
service
deployed
event
yeah.
So
that's
kind
of
like
the
the
event
that
gets
generated
by
the
k
native
controller
that
is
running
inside
the
cluster
sent
back
to
the
platform
cluster
and
that,
basically,
is
what
is
triggering
tecton
in
this
case.
If
I
go
and
inspect
here
the
task,
I
can
see
that
I
think
that
yeah.
A
So
basically,
I
don't
know
if
it's
too
small
to
see,
but
basically
it
says
that
yeah.
I
just
deployed
this
this.
This
function
that
I've
just
created
right,
that's
pretty
much
it
from
the
demo
perspective.
I
think
that
I
have
like
three
four
more
minutes
and
I
want
to
talk
about
the
challenges
of
building
this
kind
of
applications
and
the
challenges
that
we
are
kind
of
like
facing
in
in
the
cd
event
space,
because
we
need
we
need
more
opinions
on
this,
and
I
think
that
that's
kind
of
what
we
are
looking
for
here.
A
So,
as
I
mentioned
before,
we
have
built
a
bunch
of
kubernetes
controllers.
This
is
kind
of
like
the
normal
way
of
how
you
extend
kubernetes
to
support
new
use
cases
in
these
cases,
like
the
controllers,
are
just
looking
at
resources
that
already
exist
in
this
case,
like
tekton
crossplane
resources,
we
have
built
captain
integration
as
well,
and
that
pushed
us
to
create
two
different
components.
A
So,
as
you
can
imagine
the
more
controllers
that
you
create
the
more
things
that
you
need
to
maintain,
and
usually
we
have
built
these
controllers
ourselves
like
projects
like
tecton,
for
example,
with
andrea.
You
know
they
build
it
in
inside
tecton,
but
for
crossplane
for
us
to
prove
to
crossplane
that
this
is
important
and
that
this
is
good.
A
We
will
probably
need
to
spend
some
time
something
that
you
will
find
when
you're
building
these
controllers
is
that
different
projects
have
different
ways
of
building
controllers
and
learning
all
these
ways
it's
pretty
hard
and
it's
pretty
time
consuming.
So
I
think
that
that's
something
that
we
should
not
be
doing
anymore,
at
least
not
for
now,
unless
like
projects,
will
take
this
task
on
their
own
of
integrating
cd
events
with
their
their
own
tools.
We
we
are,
we
know
for
sure
that
we
need
more
sdks.
A
We
have
like
a
go
sdk
and
a
java
sdk
is
coming
along
pretty
good,
but
we
need
you
know,
sdks
in
rust
and
python
and
node.js,
and
all
that
stuff
see.
The
events
are
are
currently
focused
on
on
the
meeting
events
side
of
things,
and
this
is
something
that
it's
becoming,
at
least
for
me,
something
that
we
will
just
need
to
figure
out
in
the
group
to
figure
out
how
we
tackle
actions
based
on
events
right
like
how
do
you
semantically
express
that
you
want
to
do
something
when
that
environment
gets
created
right
like?
A
How
do
you
specify
that?
How
does
that
look
like?
Does
it
look
like
you
have
an
event,
it's
more
like
a
request.
It's
not
like
an
event,
so
we
just
need
to
figure
out
how
that
works,
and,
of
course,
we
know
that
the
vocabulary
will
evolve
if
it's
being
used
right
like
if
we
are
implementing
different
things.
On
top
of
this,
if
we
are
not
implementing
anything
and
we're
just
talking
about
how
the
vocabulary
should
look
like
it's
pretty
difficult
to
to
make,
it
evolve
and
look
nice
and
support
more
use
cases.
A
While
I
was
building
this,
I
was
learning
a
lot
of
very
interesting
lessons
and
there
are
like
different
ways
of
integrating
things
in
in
kubernetes,
and
I
think
that
this
is
one
of
the
ways
that
I'm
I'm
really
leaning
towards.
So
instead
of
building
controllers,
like
the
ones
that
I've
showed
you,
I
will
be
more
focused
on
doing
more
like
a
functional
based
approach,
also
because
I'm
working
with
functions,
so
it
kind
of
makes
sense,
but
we
have
something
there
in
k
native,
which
basically
is
a
small
service
that
you
can
install
in
your
cluster.
A
That
will
look
at
all
the
resources
that
you
configure
this
component
to
look,
so
you
can
look
at
deployments:
services,
ingresses,
okay,
native
stuff,
crossplane
stuff.
You
know
tecton
resources
and
what
you
can
do
is
like
just
monitor
them,
and
this
component
will
automatically
create
cloud
events
for
you
whenever
it's
you
know
whenever
it's
getting
changes
right.
A
A
So
I
would
say
that
by
using
some
of
these
kind
of
hybrid
approaches
where
we
have
kubernetes
based
integrations
generating
cloud
events,
other
sources
generating
cloud
events
and
we
have
like
a
transformation
or
mapping
functions
to
our.
You
know
our
cd
events
will
make
it
more
easier
for
us
to
make
progress
while
we
wait
for
some
of
these,
you
know
other
organizations
to
adopt
this
kind
of
stuff,
so
I
think
that
that's
kind
of
like
where
we
are
currently
at
least
on
the
practical
side
of
implementing
these
things.
A
A
I
just
showed
you
using
this
approach
and
I'm
quite
confident
that
it's
going
to
take
me
the
tenth
of
the
time
that
it
took
me
to
build
the
other
one
where
I
needed
to
learn
about
like
three
different
ways
of
building
controllers
and
that's
a
nightmare,
and
I
don't
want
to
do
it
anymore.
So,
thank
you
very
much
again.
A
A
A
The
idea
is
that
they
are
just
going
to
develop
some
applications.
They
let's
say
that
they
are
starting
a
project
so
before
starting
a
project,
they
request
an
environment
where
they
can
start.
You
know
deploying
stuff
that
they
are
building
it's
kind
of
like
a
sandbox
thing
yeah,
but
it
can
be
whatever
you
want
right,
like
it
can
be
a
qa
environment
and
the
only
thing
that
it
will
change
is
the
tools
that
you
are
going
to
install
in
that
environment.
For
that
team
to
use
right.
B
A
The
good
thing
about
canadian
eventing
is
that
that
concept
of
event
broker
is
just
an
abstraction
and
you
can
actually
plug
in
different
technologies.
Behind
that
right
developers
will
just
send
events
to
that,
but
you
can
have,
for
example,
the
kafka
implementation
of
the
knee
eventing
broker
or
the
rabbitmq
implementation,
or
even
your
cloud
provider
specific
implementation.
If
you're
using
google,
you
can
have
google
pop
sub
implementation
there
right.
A
So
again,
I
think
that
I
thank
you
for
the
question
because
I
didn't
mention
that,
but
this
is
just
the
idea
of
whatever
you
can
use
whatever.
That
allows
you
to
route
cloud
events
and
just
create
subscriptions
to
see
okay,
who
is
interested
in
this
kind
of
event
and
then
do
whatever
you
want
with
it
yeah
any
other
questions.
A
B
C
A
Yeah
yeah
exactly,
and
I
think
that
the
idea
of
doing
that
of
doing
something
like
this
right,
like
let's
say
that
you
have
like
a
github
pull
request
event
right.
You
get
that
event
and
you
transform
that
to
like
a
cd
event.
That
is
called
change,
request
right.
The
advantage
of
doing
that
is
all
the
tools
that
you
build
on.
This
other
side
will
depend
on
this
generic
vocabulary.
A
B
A
You
can
do
this
like
by
creating
functions
in
this
case
that
just
consume
a
cloud
event
and
produce
another
one,
or
you
can
use
tools
that
are
being
created.
I
think
that
trigger
mesh
has
a
tool
called
bumblebee
that
is
open
source
that
basically
allows
you
to
get
a
cloud
event
and
automatically
transform
it
into
a
different
cloud
event
with
a
different
type
and
doing
some
transformations
on
the
payload
as
well.
B
B
C
A
Yeah,
so
that's
a
very
good
question.
We
are
having
a
workshop
on
friday,
where
I
think
that
part
of
that
workshop
will
be
trying
to
define
that
roadmap,
because
we
need
to
get
into
a
point
where
we
have
a
subset
of
events
that
are
stable
enough
for
people
to
start
consuming
and
with
that
we
will
just
need
to
have
like
the
right
sdks
for
producing
those
events
in
general,
creating
cloud
events
you
can
create
cloud
events
with.
A
You
know
the
cloud
events
sdks
and
that's
pretty
solid,
but
we
want
to
make
sure
that
the
metadata
for
the
events
and
the
vocabulary
can
like
make
sense
and
only
that
it's
it
will
take
a
lot
of
work.
So
yeah.
Thank
you
for
the
question.
It's
still
working
progress,
I
would
say
andrea.
Do
you
want
to
add
something.