►
From YouTube: Knative Community meetup #5
Description
This meetup featured a demo by Mauricio Salatino @salaboy on "Cloud Events Orchestration with Knative and Zeebe".
A
A
A
A
A
C
D
C
C
C
The
name
comes
from
hack
in
kerr
kirkland
because
most
of
those
happened,
probably
at
matt's
house
in
so
that's
where
that
comes
from,
but
so
tying
that
back
in
the
ama
we're
like
hey.
Why
don't
we
start
having
these
virtual
hacking
hacking
days
where
we
can
just
come
in?
Ask
questions?
Maybe
not
even
hack
talk
about
cool
stuff.
So,
for
the
last
few
weeks
we've
been
having
those
and
folks
have
been
coming
in
asking
questions
talking
about
some
of
the
cool
things
they
have
built
and
so
forth.
C
So
we
thought
that
would
be
another
way
for
people
to
come
in
and
start
showing
also
on
what
they
might
have
built
so
matt
put
together
this
doc.
That
basically
says
he
shared
it
actually
and
I'm
looking
right
now
to
see
if
he
actually
posted
on
the
calendar,
but
there's
a
sign
up
sheet.
Okay,
if
you
want
to
go
ahead
and
come
in
and
and
show
you
where
is
you
can
do
that
as
well?
It
was
posted
in
general
I'll
make
sure
that
we'll
add
the
the
sign
up
sheet.
E
F
C
A
Awesome
and
or
maybe
do
more
than
one
if
yeah
like
evan,
is
saying
on
the
chat
great.
So
if
you're
in
europe-
and
this
is
too
late
for
you-
you
can
organize
a
european
version
of
this
and,
and
that
would
be
amazing,
great,
so
the
yeah
I
I
share
the
event
link.
That
is
a
link
to
the
calendar,
to
the
native
calendar
for
people
who
want
to
add
this
to
their
calendars,
and
if
you
have
any
other
information
that
you
want
to
share,
please
add
it
on
the
agenda.
A
D
Yes,
maria,
thank
you
very
much
and
thank
you,
everyone
for
joining
the
meetup,
this
presentation,
it's
about
that
about
orchestrating
cloud
events
and,
in
general,
the
main
goal
for
the
presentation
and
for
me
to
be
doing
this
here
is
just
to
gather
feedback
and
think
what
you
guys
think
about
what
I'm
building
and,
if
you
think
that
it's
useful
by
doing
this,
I
it's
like
a
poc
kind
of
thing
that
it's
kind
of
working.
Quite
okay,
I'm
just
trying
to
also
learn
more
about
gay
native
and
see.
D
How
can
I
contribute
and
by
just
creating
simple
applications?
It's
pretty
clear
to
me
that,
or
I
might
be
missing
some
stuff
or
some
stuff
that
we
can
create
in
order
to
make
like
you
know,
the
user
experience
a
little
bit
better,
not
on
the
native
stuff,
but
in
some
components
that
can
help
people
to
build
like
applications.
Basically,
so
let
me
try
to
go
over
the
application.
My
name
is
maurice
latino.
I
work
for
a
company,
that's
called
kamunda.
D
They
have
been
doing
workflows
for
a
long
time
and
I've
been
working
with
workflow
related
companies
for
the
last
10
years
or
so
so.
I've
seen
like
a
fair
share
of
implementations
of
applications
using
workflow
technologies
and
how
you
know
they
create
these
workflow
engines.
This
company
has
a
project,
that's
called
cv,
that's
the
one
that
I'm
going
to
be
showing
today
and
that
project.
Basically,
it's
a
cloud
native
reimplementation
of
what
we
traditionally
know
as
a
workflow
engine.
D
That's
quite
cool,
it's
adapted
to
you,
know
the
modern
infrastructure
and
I'm
also
a
learning
instructor
with
kubernetes
trainings.
For
that,
I'm
pretty
sure
that
we
are
all
familiar
with
kubernetes
by
now.
So
a
quick
disclaimer
here
I
will
be
running
a
live
application
running
in
a
remote,
kubernetes
cluster,
it's
using
web
sockets
and
native
cloud
events
and
a
bunch
of
other
stuff.
So
what
can
possibly
go
wrong?
I
would
say
everything
and
if
something
can
go
wrong,
it
will
go
wrong.
D
D
Let
me
go
to
the
application
and
the
application
again
is
simulating
that
that
idea
of
you
have
you
need
to
sell
tickets,
for,
let's
say
a
concert
that
it's
in
high
demand
and
you
probably
have
less
tickets
than
people
wanting
to
buy
the
tickets.
So
you
might
need
some
kind
of
queuing
system
in
order
to
be
able
to
serve.
You
know
in
a
first
come
first
serve
approach
right.
D
So
in
order
to
do
that,
you
will
need
to
have
some
kind
of
a
queue
and
you
will
start
queuing
customers
while
they
arrive,
and
in
the
moment
where
the
tickets
go
on
sale,
you
are
going
to
start
processing
that
queue
and
just
letting
a
bunch
of
customers
at
a
given
time
to
proceed
and
reserve
the
tickets
right.
If
they
manage
to
resell
the
tickets
in
their
session,
they
will
just
acquire
the
tickets.
If
not,
they
will
just
leave
the
tickets
for
the
next
person
in
the
queue
right.
So
this
is
basically
the
application.
D
What
I
can
do
here
is,
I
can
generate
some.
You
know
sessions
just
to
simulate
that
there
is
people
in
the
queue
here.
So
now
I
have
a
queue
with,
let's
say:
10
people
I
can
join
the
queue
in
there
and
I'm
now
10,
because
there
one
one
just
left
the
q
right
and
I
can
generate
more
at
the
end
as
well
just
to
simulate
like
a
normal.
C
D
Right,
like
I'm
there
in
the
middle
right
and
one
one
interesting
thing
to
notice
here,
is
that
I
will
be
refreshing
this,
the
state
of
the
queue
for
every
customer
using
websockets.
So
I'm
just
pushing
events
through
each
of
the
you
know,
customer
browsers
in
order
to
just
update
their
position
in
the
queue
right.
That's
just
a
thing
just
to
take
into
consideration
from
like
the
architecture
of
the
application.
D
So
what
I
can
do
here
is,
I
can
just
simulate
people
just
going
out
of
the
queue,
so
I
just
jump
towards
the
first
place.
Just
remove
that
and
now
I'm
in
the
in
the
beginning
of
the
queue
so
the
next
it's
going
to
be
my
turn.
I
can
wait
for
that
and
make
that
happen
and
again
I
will
be
just
notified
because
I'm
getting
a
websocket
notification
message,
saying
yeah
now
it's
your
turn.
D
Now
you
can
reserve
your
tickets
right
and,
as
you
can
see,
there
are
a
bunch
of
weird
ideas
there
that
represent
my
session
and
basically
will
validate
that.
I
am
now
you
know,
allowed
to
move
forward
into
the
process
of
buying
my
tickets,
and
here
you
can
just
select
the
amount
of
tickets
on
the
type
of
tickets
right.
D
Let's
say
I
just
want
to
reserve
two
tickets
and
as
soon
as
I
click
reserve,
the
main
idea
here
is
that
I'm
going
to
go
to
the
pool
of
tickets
available
tickets,
and
I
will
lock
in
this
case
two
for
my
reservation
and
those
tickets
will
be
locked
until
I
pay
for
those
tickets.
If
I
manage
to
pay
correctly,
then
the
tickets
will
be
mine.
If
I
do
not
manage
to
pay
correctly
and
for
some
reason
there
is
an
error
or
I
just
do
not
pay.
D
Those
tickets
are
going
to
be
automatically
put
back
there
into
the
pool
right
and,
as
you
can
imagine,
if
you
have,
you
have
a
payment
service
or
payment
system,
it
might
be
kind
of
like
a
third
party
payment
system.
So
as
soon
as
I
click
pay
here,
I
will
just
send
my
details
to
a
third
party
application
and
I'm
using
an
iframe
and
again
a
callback
in
order
to
verify
that
the
transaction
was
approved.
So
when
I
click
here,
I'm
just
going
to
a
third-party
application.
D
This
is
not
the
application
of
the
tickets
portal,
it's
a
third-party
thing
and
then
I'm
just
waiting
for
a
callback
to
come
back
and
say
that
my
transaction
was
approved
or
rejected.
It
was
approved
and
I
also
get
a
websocket
notification
saying:
yes,
you
can
continue
and
you
can
get
your
tickets.
So
that's
pretty
much
what
the
application
is.
D
That's
kind
of
like
the
normal
flow
of
the
application
and
based
on
this,
you
can
go
and
say:
okay,
if
you
want
to
architect
an
application
like
this,
you
can
use
like
an
event-driven
approach
right
and
if
you
use
an
event-during
approach.
Basically
what
will
happen
is
that
you're
going
to
be
meeting
events,
some
services
will
be
meeting
events
and
some
other
services
will
be
consuming
events
and
in
order
to
make
all
this
flow
happen
right.
D
So
these
are
kind
of
like
the
events
that
you
would
expect
to
have
in
these
kind
of
like
situations.
You
join
the
queue
you
exit
the
queue
you
reserve
the
tickets,
you
send
the
payment,
the
payment
gets
authorized
and
then
the
tickets
gets
admitted
right.
If
you
go
more
to
the
architecture,
this
is
kind
of
like
how
I
started
working
with
this
application.
So
I
created
four
different
services.
D
The
front
end,
which
is
interacting
with
web
sockets
to
the
you
know,
client
to
the
browser,
sending
messages
and
also
rendering
the
sending
the
html
for
the
website
a
ticket
service
that
is
in
charge
of
interacting
with
the
payment
service
and
also
to
emit
the
tickets
and
the
q
service,
which
is
in
charge
of
this.
You
know,
queueing
mechanism
that
you
saw
at
the
beginning
when
I
started
building
these
services.
D
I
started
saying:
okay,
let's
use
cloud
events
to
share
information
between
these
services
and
I
started
using
like
the
http
bindings,
so
sending
http
post
requests
between
the
services
and
at
that
point
my
services
needed
to
know
exactly
where
I
was
sending
those
requests
right.
So
from
the
front
end,
if
I
want
to
interact
with
the
queue
service,
I
just
need
to
send
a
post
request
to
the
queue
service
that
pushed
me
to
know
in
the
front
end
application
to
know
where
the
queue
service
was
right
and
you
can
quickly
do
that.
D
You
can
easily
do
that.
But
if
you're
building
a
more
real
life
application,
you
might
need
to
have
some
more
advanced
stuff
and
we
are
in
the
k
native
meetup.
So
I
don't
need
to
explain
what
k
native
serving
or
k
native
eventing
is,
but
I
started
looking
quite
heavily
into
canadian
eventing
in
order
to
implement
a
more
robust
solution
of
communicating
this
service
together
to
be
able
to
scale.
D
So
I
started
using
eventing
and
you
ended
up
with
something
like
this,
where
you
do
not
communicate
the
services
between
each
other,
you
just
you
know,
create,
send
messages
to
the
broker
using
a
channel.
I
started
with
a
memory
channel
and
then
I
switched
to
kafka
and
you
have
a
broker
where
you
just
publish
your
messages
or
your
cloud
events,
and
then
you
create
triggers
for
subscriptions
for
those
events.
D
So
different
services
will
subscribe
to
different
event
types
and
by
creating
the
right
you
know
subscriptions
and
by
publishing
the
right
cloud
events
to
the
broker
you
kind
of
like
implement
this
flow.
At
some
point,
I
needed
to
create
some
kind
of
a
checklist
to
understand
how
the
flow
was
composed
right.
It
was
something
like
this
I
said.
Okay,
the
front
end
needs
to
generate
like
generates
a
cloud
event
that
it's
been
pushed
to
the
broker,
and
then
there
needs
to
be
a
trigger
in
the
queue
service
to
consume
that
event.
D
To
do
something,
and
the
same
here
with
the
q
service,
when
the
queue
service
generates
the
customer
exit
event,
there
needs
to
be
a
trigger
in
the
front
end
to
be
able
to
consume
that
and
allow
the
customer
to
move
forward
right.
So
for
this
very
simple
scenario,
I
needed
this
checklist
and
it's
kind
of
like.
I
can
definitely
understand
it
now
and
it's
easy
to
build.
D
But
you
can
imagine
that
if
you
have
tons
of
triggers
and
tons
of
tons
of
these
subscriptions
and
tons
of
messages
being
generated,
it
might
tend
to
become
a
little
bit
more
complicated,
so
definitely
kind
of
like
my
first
experience
was
okay.
Yes,
I
know
how
to
build
my
application.
I
know
how
to
create
these
things.
D
The
idea
of
creating
triggers
on
top
of
the
broker
like
subscription,
based
that
you
wired
more
like
in
runtime,
not
when
you're
designing
your
applications,
so
your
services
doesn't
know
about
each
other.
It's
pretty
cool,
it's
very
declarative,
and
I
really
love
that
thing
from
from
kennedy
preventing,
but
it
becomes
kind
of
like
a
thing
like
how
do
you
visualize
how
things
are
being
connected
together
at
a
given
time?
What's
the
sequence
of
events
that
needs
to
happen
in
order
to
complete
the
flow?
What
happens
when
you
want
to
change
the
sequence
you
know?
D
But
how
do
you
understand
what
was
the
sequence
that
was
executed
yesterday
and
what's
the
sequence
that
it's
required
today,
for
example,
it's
hard
to
see
where
things
are
at
the
given
time?
You
need
to
implement
some
kind
of
like
your
own
dashboard,
to
understand.
What's
going
on
and
when
things
go,
when
things
things
go
wrong,
it's
also
difficult
to
understand
what
exactly
is
going
wrong
right
like
did
you
miss
a
trigger?
Did
you
miss,
configure
trigger
or
what's
going
on
right?
D
So
it's
good
to
know
that
gay
native
also
have
knd
flow,
which
basically
implements
a
bunch
of
things
about
a
couple
of
constructs
sequence
and
parallel
that
allows
you
to
start
defining
and
in
a
declarative
way,
these
kind
of
things,
and
it's
really
nice
from
these
concepts.
Again,
I
will
not
spend
time
explaining
these
concepts,
because
it's
the
canadian
meetup
that
again
you
just
defining
them
declaratively
and
they
also
start
doing
interesting
things
like
automatically
provisioning
channels.
D
You
know
this
important
sequence
of
events
or
how
to
process
on
a
cloud
event
against
like
different
services,
how
to
send
how
to
route
events
across
multiple
services,
which
is
a
really
interesting
idea,
and
that's
why
I
wanted
to
talk
a
little
bit
about
cv
because
cv.
It's
a
workflow
engine
and
it's
basically
designed
for
doing
this
kind
of
things.
So
there
is
an
overlap
there
with
k
native
flow,
but
this
is.
I
would
say
that
this
is
a
little
bit
more
high
level
right.
It's
not
the
replacement
for
that.
D
So
we
have
cd
here.
We,
the
only
thing
that
we'll
be
doing,
is
looking
at
the
events
that
the
application
is
emitting
and
what
we
can
do
is
we
can
do
the
first
thing,
which
is
understand
what's
going
on
right,
so
we
can
create
a
model
like
this
one,
the
one
that
I'm
showing
here.
I
can
show
it
into
this
other
application,
which
basically
the
only
thing
that
I'm
doing
here
is
I'm
mapping
a
high-level
view
of
what's
going
on
by
defining
this
model,
which
is
saying
every
time
that
I
get
a
new.
D
D
Right
by
the
end,
I
will
be
able
to
see
how
many
you
know
if,
if
I
just
look
into
a
dashboard
that
it's
showing
me
all
the
instances
of
this
model,
I
will
be
able
to
see
how
many
people
is
trying
to
buy
tickets
and
how
many
are
stuck
in
the
payment
section,
for
example,
and
that's
pretty
powerful,
because
when
you
have
like
this,
you
know
event-driven
applications.
You
might
end
up
having
like
lots
of
different
events
at
different
levels.
D
These
are
the
instances
that
I've
started
before
when
I
did
the
first
demo
and
I
had
like
20
instances
running
in
there
and
I
completed
one
of
the
flows
right
and
now
I
created
a
new
one,
which
is
the
one
that
is
here,
I'm
already
out
of
the
queue.
I
should
reserve
my
tickets
and
let
me
see
if
I
can
order
them
in
the
right
way.
So
this
should
be
the
instance
that
I'm
looking
at
right.
So
what
I
can
do
here
is,
I
can
just
reserve
the
tickets.
D
Let's
say
that
I
want
to
reserve
four
tickets
and
I
should
be
able
to
see
here
that
this
you
know
flow
it's
moving
forward
as
soon
as
it
receives
the
events,
it
will
move
forward
right
now.
It's
waiting
for
the
payment,
so
pretty
easy
to
visualize.
If
I
go
back
to
the
dashboard,
I
can
see
all
the
instances
that
are
running
like
with
a
quick.
You
know
quick
overview
exactly
where
my
customers
are
by
just
mapping
the
application,
the
application
events
that
are
already
happening
right.
D
That's
one
thing
that
you
can
do
with
cv.
Let's
move
to
the
next
one.
The
next
thing
that
you
can
do
is
you
can
take
one
step
forward
right,
usually,
I
tend
to
show
this
kind
like
diagram,
but
because
we
are
in
a
k,
n
meetup.
I
decided
to
go
a
little
bit
deeper
on
on
how
the
architecture
of
the
integration
works
and
it's
pretty
simple
as
well
right.
D
So
what
cv
has
is
here
something
that
I'm
calling
cloud
events
router,
which
is
basically
the
one
that
is
tapping
into
the
broker
for
my
application,
where
the
messages
where
the
cloud
events
are
being
sent,
it's
picking
up
the
events
and
then
forwarding
those
events
and
mapping
things
to
an
instance
of
the
workflow
engine.
The
dashboard
that
I
showed
before
it's
called
operate.
That's
the
yellow
box
there
in
the
bottom
and
the
workflow
engine
has
been
already
provisioned
and
it's
running
in
kamunda
cloud.
D
So
it's
not
running
in
the
same
cluster,
where
I'm
running
the
services
of
my
applications,
but
the
workflow
engine
can
be
provisioned
in
the
same
cluster.
If
you
need
to
do
that,
because
you
are
in
an
on-prem
solution
or
something
like
that,
and
because
of
this
collect
of
architecture,
nothing
stop
us
to
say.
Okay
now
we
want
to,
you
know,
create
the
triggers
for
notifying
the
cloud
event
router
about
the
events
of
my
application.
D
So
the
only
thing
that
I
needed
to
do
in
order
to
tap
into
that
broker
and
get
the
events
been
sent
to
the
workflow
engine
is
just
to
create
an
extra
bunch
of
triggers
just
to
send
the
normal
events
to
the
right
services.
But
all
the
events
also
to
the
events
router
that
I
have
right
and
the
funny
thing
is
that,
because
I
have
a
model
here,
that
it's
defining
already
the
interests
in
different
event
types
I
can
automatically
generate
those
triggers
dynamically.
D
There
is
no
need
for
the
user
to
create
these
extra
triggers
if
they
are
defining
models
that
are
interested
in
events.
Those
triggers
can
be
automatically
generated
and
deployed
into
the
cluster
for
automatic
forwarding
of
those
events,
and
that
takes
us
to
the
second
thing
that
you
can
do
with
when
you're
using
a
workflow
engine,
which
is
providing
a
lot
of
other
features
around
what
you
can
do
instead
of
just
visualizing,
you
can
start
decorating
and
enhancing
your
flows
right.
D
So
one
of
the
things
that
you
can
do
as
shown
here
is
you
can
start
adding
timers,
for
example,
for
time-based
notifications
and
something
that
is
quite
common
keeping
track
of
time
and
then
sending
notifications
or
executing
actions
after
a
certain
amount
of
time
happen
right.
So
let
me
go
out
of
here.
Just
go
to
the
model.
D
What
I
have
here
is
the
second
version
of
the
model,
and
what
I'm
doing
in
the
payment
section
is
basically
having
two
different
timers
one
timer,
that
it's
non-interrupting.
That
basically
means
that
I'm
going
to
do
something:
that's
not
going
to
influence
the
flow
of
the
application.
It's
just
going
to
in
this
case,
send
a
reminder
right
and
then
I
have
another
timer
that
it's
going
to
influence
the
the
flow
of
the
application
in
this
case,
and
it's
going
to
just
notify
the
user
that
the
reservation
was
timeout.
D
So
this
is
a
little
bit
more
aggressive
right.
This
is
going
to
do
something,
and
then
you
have
these
two
extra
boxes
which
are
basically
creating
cloud
events.
So
I'm
just
going
one
step
further
further
and
now
I'm
generating
cloud
events
from
the
flow
right.
So
if
I
zoom
out
and
if
I
deploy
this
new
version,
so
basically
what
I'm
doing
now,
if
you're
using
a
workflow
engine,
usually
you
have
versioning
like
built
in
into
these
tools,
so
I
can
deploy
a
new
version.
D
I
should
be
able
to
go
back
to
the
dashboard
and
see
here
that
I
have
a
new
version
deployed.
Let
me
see
if
I
have
a
new
version
now
I
have
a
new
version
and
I've
configured
my
application
just
to
basically
use
the
latest
version
all
the
time.
So
now,
if
I
have
a
customer
that
is
coming
back
here
at
the
beginning,
it's
coming
back
at
the
beginning
and
joining
the
queue
it's
going
to
start
using
the
new
version
of
the
flow
that
I've
described
here.
D
So
at
some
point,
if
I
refresh,
I
should
be
able
to
have
a
new
instance
coming
being
created
here
with
this
model
and
of
course,
it's
going
to
take
more
time
than
usual
because
it's
a
live
demo
right,
that's
how
it
works.
Yeah!
That's
really
interesting.
Let's
wait
for
a
few
more
seconds.
If
it
doesn't
appear
there,
then
I
will
try
to
start
it
again.
It's
not
appearing!
That's
really
interesting.
D
D
D
Now
I
need
to
pay
now.
I'm
here
now
remember
that
I
changed
the
model
here,
just
to
schedule
some
timers.
So
as
soon
as
the
workflow
arrives
to
this
stage,
every
10
seconds
it
will
be,
it
will
start
sending
a
notification.
That's
what
this
timer
is
saying
every
10
seconds
you
just
do
that
and
that
sending
notification
is
basically
creating
a
new
cloud
event
that
is
sent
to
the
broker.
D
So
any
application
can
be
picking
those
events
and
in
this
case
the
front
end
is
already
configured
to
pick
those
events
and
show
here
a
notification
right.
So
I
have
have
a
cloud
event
being
emitted
every
10
seconds,
it's
appearing
here
and
then,
as
I
mentioned
before,
I
have
another
cloud
event:
that's
going
to
be
generated
when
you
know
the
reservation
time
out
after
two
minutes,
and
we
can
see
that
if
we
wait
for
two
minutes,
we
are
going
to
be
kick
out
from
our
current
session
back
to
the
queue
right.
D
D
So
you
can
do
stuff
like
this
right,
so
you
can
have
more
complex
flow,
which
is,
for
example,
in
this
case,
using
a
soup
flow
here
that
it's
basically
saying
every
time
that
we
start
buying
the
tickets.
We
are
in
customer
buying
tickets
stage
or
milestone,
or
something
like
that
or,
like
you
know,
in
this
this
space
and
for
more
bigger
and
more
complex
flows.
D
That
makes
a
lot
of
sense
because
you
might
end
up
having
lots
of
events
being
emitted
or
consumed,
and
then
you
want
to
separate
them
in
different
stages,
and
it
also
allows
us
to
register
these
kind
of
boundary
events
that
basically
allows
us
to
say
no
matter
where
we
are
in
the
flow.
If
we
receive
one
of
these
events
customer
running
the
queue
we
will
just
exit
here
right
and
we
will
have
all
the
data
of
where
the
customer
was
when
they
decided
to
avon
right.
D
So,
as
also
as
you
can
see
here,
it's
like
we
are
just
not
listening
to
events,
but
we
are
also
generating
events
in
the
middle
of
the
normal
application
flow
right,
and
this
basically
having
these
kind
of
tools
that
allows
you
to
change
the
models.
Dynamically
and
deploy
new
versions
of
the
models
allows
you
that
flexibility
of
changing
and
adapting
to
you
know
changes
in
the
business
side
right.
D
D
So
it
might
be
interesting
to
create
some
kind
of
like
router
for
websockets.
That
does
that
automatically.
So
we
can
go
here
and
you
can
see
that
I'm
in
the
new
in
the
new
section
again.
This
here
is
highlighting
that
there
is
one
instance
in
this
section
and
if
I
go
and
generate
more
instances
here,
you
should
be
able
to
see
that
now
you
have
more
instances
being
created
there.
D
D
How
many
are
active,
and
also
I
something
that
I
didn't
show
that
I'm
planning
to
add
to
the
demonstration
is
incidents
so
finding
when
things
are
going
wrong
right,
maybe
getting
events
out
of
order
or
maybe
getting
something
that
I
was
not
expecting,
that
will
be
reported
here
and
we
have
some
tools
in
order
to
be
able
to
retry
or
to
resend
events,
if
that's
needed.
So
hopefully
that
makes
some
sense.
D
So
basically,
there
is
a
crd
type
that
takes
this
model
and
allows
you
to
declarative,
say
I
have
a
new
flow.
Just
you
know
applied
with
qctl
and
then
automatically
deploy
that
into
the
infrastructure.
Deploy
that
into
the
workflow
engine
generate
all
the
triggers
that
you
need,
and
then
you
know
just
allow
the
users
to
create
new
instances
of
those
things
and,
of
course,
that
operator
nowadays
is
creating
instances
in
your
infrastructure.
But
it's
part
of
the
plan
to
also
be
able
to
create
instances
remotely
on
the
software
as
a
service
approach
as
well.
D
So
that's
kind
of
like
one
of
the
things
that
I
will
be
working
on
in
future
iterations
next
steps
for
me
like
based
on
where
I
am
right
now.
It's
definitely
work
a
little
bit
more
on
those
templated
channels,
like
in
sequence
and
parallel,
so
I
just
want
to
be
able
to
replicate
the
same
experience
so
that
those
kinetics
you
know
native
types
have
that
idea
of
creating
templated
channels
and
kind
of
like
improving
the
mechanisms
on
how
I'm
doing
things
on
the
on
the
workflow
side.
D
That
needs
to
need
some
more
refinement
than
I
will
appreciate
any
feedback
around
that
workflow
engines
also
they
are
being
built
by
default
to
you,
know,
mix
and
allow
interactions
between
humans
and
systems
and
events
in
this
case.
So
what
I
want
to
add
to
the
demo
is
something
like
an
intermediate
step.
So,
for
example,
in
here
where
the
user
is
like,
there
is
an
admin
user
or
someone
that
needs
to
execute
some
kind
of
like
tasks.
That
requires
a
specific
form
and
a
specific
connection.
D
So
I
can
just
model
that
and
include
useful
interactions
in
here.
If
I'm
interested
to
do
that,
there
are
some
use
cases
that
make
it
more
clear
for,
like
you
know,
for
high
level
uses
and
again
the
thing
that
I
mentioned
about
web
sockets
using
stomp,
I'm
not
using
some
now
I
should
be
using
stump
and
also
I
was
looking
a
little
bit
into
our
socket,
which
looks
pretty
promising
so
kind
of
like
trying
to
understand
if
they
can.
D
If
it's
interesting,
the
canadian
community
is
interested
in
having
some
components
around
that
just
to
forward
cloud
events
and
just
to
being
able
to
build
these
more
organic
reactive
applications.
So
that's
pretty
much
my
presentation.
I
hope
that
I
didn't
spend
too
much
time
on
it
and
I
hope
that
I
give
enough
information,
for
you
know
for
getting
some
feedback
from
from
this
amazing
community.
A
D
Can
you
point
me
out
to
which
one
so,
for
example,
like
these
ones
like
the
payment
provider
yeah?
So
this
is
this
is
not
a
delay.
This
is
a
timer,
so
this
is
like
a
recurring
timer
that
it's
going
to
trigger
an
event
every
like
a
timer
definition
right
like
so
you
can
say
every
10
seconds,
just
repeat
and
generate
that
event
and
as
soon
as
that
event
gets
triggered
you're
going
to
execute
whatever
this
is
in
this
case,
and
you
can
do
any
number
of
steps.
D
Yeah,
that's
a
good
question,
so
in
general,
let's
me,
let
me
go
back
here,
so
that's
part
of
this
piece
right.
The
workflow
engine
will
solve
that
for
you
in
a
transparent
way.
You
don't
really
need
to
care.
Where
is
that
running
because
again
the
functionality
that
that's
providing
it's
just
the
timer
service?
It's
like
a
crunch
of
kind
of
thing
that
it's
transparent
for
you
and
how
it's
running
and
in
the
back,
what
is
happening
is
that
this
workflow
engine
is
not
just
a
single
entity.
F
D
I
think
that
that's
a
quite
common
requirement
for
building
applications
also
having
like
ways
to
schedule
timers,
so
I
would
say
yes,
these
components
are
already
implementing
some
of
those.
So
how
do
you
define
that
in
gay
native
as
well?
If
you
don't
want
to
use
these
components,
it's
a
very
good
question.
Yes,
I
could
think
that
it
might
be
a
good
stuff
to
have
I
hand.
D
D
D
C
D
G
Hi
mauricio:
do
you
have
any
any
feedback
on
how
you
learn
about
when
you're
getting
started?
Looking
at
the
documentation
of
k
native?
How
do
you
end
up?
You
see
brokers
and
triggers
versus
other
type
of
artifacts
and
kind
of
just
that's
a
summary
of
how
difficult
or
what
things
we
could
improve
in
that
area
of
guidance
on
how
to
understand
native
eventing,
better.
D
That's
that's
a
good
question.
I
definitely
reach
out
because
I
didn't
understood
some
of
the
bits,
but
definitely
I
was
surprised
on
how
easy
it
is
to
start,
for
example,
with
the
in-memory
channel
and
just
switch
to
kafka
and
how
transparent
it
is
in
general,
the
the
documentation
for
series
17,
it's
pretty
clear
to
me.
I
follow
the
steps
there
like
several
times
to
install
different
clusters
and
just
to
install
different
components
and
go
back
and
recreate
environments
and
with
that
kind
of
stuff,
and
it's
working
quite
good.
D
G
Of
events,
yeah
yeah
yeah,
we
are
we're
doing
release
stones
now
so
keep
in
touch
with
that.
With
that
with
the
imagine,
I
saw
that
you
were
using
in-memory
channel.
Did
you
look
into
like
if
you're
going
to
deploy
this
in
an
enterprise?
Having
persistence?
Did
you
look
into
what
other
type
of
channels
you
were
looking
into
experimenting
like
like
kafka
or.
D
Yeah,
so
the
application
now
it's
running
with
kafka,
and
I
did
that
so
I
started
with
no
with
no
eventing.
I
just
was
sending
cloud
events
between
you
know:
services
using
http,
then
I
switched
to
in
the
in-memory
channel,
and
then
I
switch
to
kafka
finally
just
to
test
that
the
abstractions
are
right,
which
is
something
that
yeah
I
wanted
to
just
test
by
myself.
I
didn't
believe
it
so,
but
it's
working
quite
good
so.
G
D
G
D
Feedback
is
on
the
websocket
kind
of
side
right.
I
need
to
do
more
research.
I
need
to
do
more
research.
I
even
had
enough
time
to
just
go
and
look
into
all
the
other
options
that
are
out
there,
like
all
the
community
projects,
but
I'm
really
interested
in
getting
that.
You
know
kind
of
websocket
router
that
allows
me
to
route
to
the
right.
You
know
client
based
session
cloud
events
that
will
be
awesome
if
it
comes
out
of
the
box
or
if
it's
a
community
extension
that
we
can
maintain.
G
Yeah
yeah,
okay,
so
keep
it
keep
in
touch
in
slang
and
the
dev
list.
Certainly
other
people
can
give
the
ideas
either
you're,
brilliant
your
own
or
you're,
using
a
cloud
provider.
For
example.
It
depends
how
you
want
to
maintain
that
state
and
how
to
traffic
those
events
yep.
So
I'll,
stop
there
for
vlan
and
get
more
questions.
C
I
don't
have
questions.
I
have
a
few
comments,
which
is
one
of
them.
This
is
really
cool.
It's
nice
to
put
a
face
to
a
slack
chats,
that's
awesome,
great
stuff.
I
I
really
enjoyed
the
demo
that
was
really
cool
and,
and
the
only
other
comment
I
was
gonna
make
is,
I
know
scotty
has
been
doing
a
bunch
of
work
with
the
web
sockets
with
with
the
sock
guys
and
the
big
mouths
and
all
the
other
bits.
C
D
C
A
G
They're
gonna
mute
just
just
a
quick
shout
out
that
we
are
are
trying
to
make
use
of
release
notes
as
a
as
a
global.
We
have
multiple
components
being
released.
I
cut
at
different
times,
but
we
we
are,
I'm
I'm
working
on
on
trying
to
get
a
that
drum,
beat
again
of
doing
release,
release
notes,
so
they're
they're
going
to
come
out
and
0.18
and
forward
so
check
out
the
the
website
under
blogs.
G
A
F
Yeah,
so
this
is,
this
is
totally
me
stealing
the
thunder
from
a
lot
of
other
people's
hard
work.
I
see
paul
and
ron
on
here.
Who've
put
a
lot
of
effort
into
this,
for
example,
but
there
are
currently
there's
currently
a
discussion
about
updates
to
the
k-native
governance
model
and
I'll
put
a
link
to
the
pr.
F
But
there
are
some
substantial
changes
that
I
think
people
are
mostly
pretty
positively
excited
about,
but
if
you're
interested
in,
how
do
I
get
involved
in
things
like
steering?
It
might
behoove
you
to
take
a
look
at
the
discussion
and
you
know
if
you
see
things
that
look
like
they
need
to
be
adjusted
or
need
some
attention.
The
the
concrete
is
wet
at
the
moment.
So
it's
a
good
time
to
for
us
to
get
things
right.
C
B
A
A
So
I
just
wanted
to
bring
you
all
back
to.
I
think
everyone
is
hearing.
Yes,
thank
you
all
for
joining
the
community
meetup.
Please
do
take
a
few
minutes
to
fill
out
the
survey
so
that
we
know
how
we
can
improve
this
and
I'm
going
to
upload
this
recording
to
the
creative
youtube
channel,
as
we
usually
always
do,
and
if
you
have
a
demo
idea
or
if
you
want
to
show
something
that
you're
working
on
please
reach
out
and
on
slack,
and
we
can
make
time
for
your
demo
as
well.