►
Description
Consuming and Replying to CloudEvents - Pablo Mercado, TriggerMesh
The presenter will share their experience managing CloudEvents with Knative components, exposing common scenarios and focusing on possible CloudEvents consuming patterns. CloudEvent consumers range from very simple one way receivers to components that compose non trivial orchestrations, and each scenario might require different reply and retry strategies, some of them beyond Knative's reach. This presentation will describe some of those scenarios and choices to manage them.
A
A
So
this
presentation
is,
you
know,
there's
been
a
lot
of
smart
people
here
with
super
cool
topics
and
now
I'm
going
to
talk
about
replying
to
cloud
events,
so
I
feel
a
bit
like
the
underdog
here,
because
this
is
mostly
trivial,
but
I'm
going
to
focus
on
on
that
space
between
a
broker
and
a
sink.
If
I,
if
I
name
something
called
targets,
it
does
how
we
call
things
in
trigger
match.
So,
oh
yeah,
thank
you.
A
A
The
reason
for
this
is,
I
don't
know
if
people
here
follow
the
activity
around
kubernetes,
around
k,
native
there's,
a
new
task
force
called
kinetic
flows,
and
in
there
there
we
started
to
have
some
discussions
and
we
ended
up
with
two
different
initiatives
in
there.
So
one
of
them
is
a
k-native
as
a
streaming
platform.
So
a
streaming
platform
where
you
probably
want
to
do
analytics
on
on
your
events
on
a
time
frame
on
a
time
window,
and
then
you
also
have
integrations
kind
of
flows
and
there
you
want
to
have
something.
A
Maybe
that
will
be
in
the
end,
some
higher
order
object
and
when
you
have
that
you
will
need
to
do
translation
just
as
roland
did
now.
So
you
have
a
number
of
components,
they
might
be
parallel
or
not,
but
you
have
something
that
they
will
need
to
have
different
cloud
events
interacting
among
each
other.
A
So
if
you,
if
you
think
of
what
we
have
so
far
or
what
we
find
at
the
ripple
so
far,
you
will
see
this
ack.
Not
ac
should
be
familiar
to
all
of
you.
So
if
you
call
a
component
the
choices
for
a
broker,
if
that
is
answered
with
ack
or
not
sdk,
ack
other
than
just
saying
hey,
this
went
okay.
You
also
have
the
chance
of
producing
a
new
cloud
event,
but
with
not
non-ack.
A
You
could
produce
a
new
cloud
event,
but
it's
not
going
to
go
anywhere
so
a
trigger
mesh
and
also
at
this,
the
new
task
force.
We
we
are
facing
some
challenges
in
there.
So
let
me
introduce
the
first
scenario,
so
this
first
scenario
should
be
by
the
way
that
symbol
is
like
a
broker
or
channel
or-
and
in
fact
this
is
not
specific
to
k
native.
This
should
be
applicable
to
any
q
system
that
you
have
so
there
on
the
right.
A
There
should
be
a
component
that
might
subscribe
to
something
delivering
an
event
and,
if
you
say
ack
without
any
payload,
that
means
okay.
I
received
that
you
don't
have
to
repeat
that,
because
you
know
this
this
track.
There
might
have
delivery
options.
I
might
have
the
retries.
I
might
have
a
deadly
queue,
for
example.
A
So
what
happens
if
if
your
component
returns
a
non-ack,
so
those
retries
are
going
to
the
ones
you
configure
are
going
to
try
again
the
same
request,
the
same
cloud
event,
and
if
none
of
them
are
successful,
they
will
get
to
a
better
queue
in
the
end
okay.
So
this
is
super
trivial.
So
far-
and
you
know
there's
something:
we've
been
doing
at
trigger
mesh
for
more
than
a
year.
A
So
since
we
repeat
that
over
and
over
at
our
sinks
or
targets,
we
created
something
called
the
replayer,
which
is
a
library
that
we
need
to
revisit
now.
So
if
you
follow
here
all
these
ballots,
these
are
more
or
less
the
requirements
for
that.
So
this
is
highly
opinionated
and
super
interested.
If
you
have
a
different
point
of
view
here,
but
this
is
what
we
learned
so
far
so
kennedy
preventing
does
delivery,
so
you
could
think
more
or
less.
This
is
imperfect,
but
you
could
think
of
the
broker
as
being
the
postman
or
post
woman.
A
That
knocks
your
door
hand
you
a
letter
and
says
good
one.
You
say
you
open
the
letter
to
say:
hey,
I
don't
like
this
and
they
say
I
don't
know.
I
tell
you
with
the
letter,
that's
up
to
you,
so
you
either
say
ack
or
non-eck
so,
but
the
analogy
is
imperfect,
because
you
could
also
produce
a
new
one:
hey
pos,
woman,
here's
my
letter.
So
that's
that's
not
fitting
perfectly.
A
A
So
I'm
going
to
take
note
of
that
of
the
that
we
should
take
care
or
create
somehow
at
that
reply,
library,
that
we
should
be
making
sure
that
users
don't
use
at
least
the
same
type.
The
type
is
usually
always
in
the
in
the
filters
and
what
else
and
let
users
decide
if
the
response
cost
event
should
be
produced.
A
So
let's
say
that
you
have
a
sync
and
the
sync
returns,
something
it
creates
something
other
database
and
brings
back
with
how
many
bytes
that
the
size
of
the
new
record
but
you're
not
interested
in
that
and,
as
you
are
not
interested,
there's
no
component
listening
to
that.
So
it
could
be
nice
if
we
all
create
things
the
same
as
people
create
sources,
we
also
create
things
and
those
things
have
the
option
of
saying
hey.
No
one
is
listening
to
that.
A
A
So
what
happens
if
there's
an
error,
and
it
is
not
a
delivery
error,
so
the
cloud
event
gets
to
our
sync
and
our
sync
fails
for
a
different
reason:
credentials
the
credentials
are
obsolete.
So
what
should
we
do
that?
It
sounds
sounds
probably
good
to
to
send
to
let
it
repeat
maybe
three
times
because
the
delivery
option
says
that
and
maybe
it
will
end
at
the
letter
q,
but
it
will.
A
It
will
be
there,
along
with
the
non-delivery
staff,
other
errors,
and-
and
you
know
what
any
any
reply
you
get
in-
there
is
still
going
to
be
there.
It's
you
are
going
to
get
that
the
the
letter
sync,
the
original
event.
I
think
there's
a
good
reason
for
that.
So
if
you
get
some
some
other
thing
at
the
telethink
you're,
making
up
a
new
event
so
should
k
native
to
broker.
Do
that
sounds
super
opportunity.
I'm
not
saying
no,
but
some
super
super
opinionated.
A
We
are
saying
ack
in
the
sense
that
I
received
that
I
didn't
have
a
problem
with
you,
my
dear
broker,
I
had
a
different
kind
of
problem
and
then
we
recommend
people
to
create
a
new
type,
which
is
an
error.
So
we
can
check
what
happened
there
and
inside
there
we
should
have
a
structure.
We
should
have
a
schema.
We
always
use
so
that
if
we
want
to
put
it
somewhere
in
some
local
analyzer
on
some
automatic
tool,
it
could
be
digested
by
by
whoever.
A
So
this
is
more
or
less
a
summary
of
what
I
already
said.
So
only
ack
will
get
a
cloud,
a
cloud
event
response.
The
kinetic
code
will
discard
any
cloud
event
that
you
get
back
but
has
a
non
ack,
so
it
won't
benefit
from
creative
delivery
options.
Also,
it
won't
get
the
noise
of
a
kinetic
delivery
option.
So
that's
up
to
you
to
to
measure
and
act
on
in
consequence
so
and
the
development
hints.
A
We
already
said
this,
so
defining
error
type
and
schema
could
be
super
awesome
if
we
all
do
that
in
a
in
the
same
fashion
and
we
don't
have
a
trigger
mesh
error
and
then
red
hat
errors
bien
when
and
vmware
errors.
If
we
have
something
common,
that
could
be
super
awesome,
but
let
let's
give
us
some
time
then
including
the
original
cloud
event.
I
think
that's
a
good
idea,
but
you
know
what
that
cloud
event
contains.
A
We
don't
know
so
if
we
are
going
to
create
a
library
here
and
the
library
contains
medical
data,
your
medical
history-
probably
we
don't
want
that
to
to
be
in
there.
So
we
should
have
at
that
library
a
check
somewhere.
That
says:
hey,
please
anonymize
this.
Somehow
we
don't
want
this
data
to
be
there
and
then
obviously
let
the
user
decide
if
the
response
should
be
produced.
A
A
I
don't
know
if
you
can
see
this,
so
I
have
a
a
tool,
a
super
super
stupid
tool
and
not
very
professional.
I
hope
it
doesn't
panic
and
I'm
being
honest
because
I
I
was
touching
that
there
I'm
half
asleep,
but
I
have
a
a
broker,
a
car
pod
and
then
a
number
of
services,
and
there
those
services
are
syncs
and
they're
super
simple.
They
just
have
a
a
parser
of
how
to
reply.
A
So
I
don't
remember
if
I
have
this
deploy
so
okay
see
so
so
I
have,
I
think,
four
services
yeah.
So
you
have
those
databases.
I
don't
know
if
you
can
read
it,
but
I'll
go
one
by
one.
So
we
have
the
ce
receiver,
so
that
one
is
has
a
trigger
and
it's
listening
to.
I
think
it's
called
in
types,
so
it
has
a
filter
for
cloud
events
coming
in
there,
but
then
the
kind
of
load
that
the
sync
is
accepting
goes
like.
A
A
Okay
later
we
will
say
hey
every
time,
not
ack.
So
that's
how
we
are
going
to
test
all
these,
and
I
know
this
is
going
to
be
super
boring
for
people
here
used
to
to
write
targets,
and
so
sorry
things
or
so,
but
I
won't
be
long.
So
let
me
show
you
here
at
the
top
right
corner,
I'm
going
to
show
the
logs
for
the
receiver.
A
So
right
now
that's
empty
but
that
the
receiver
is
going
to.
If,
if
there's
a
any
response
from
them
and
there's
a
payload,
I
need
something
else
to
listen
to
that.
So
I'm
going
to
and
also
the
broker
has
a
little
sync.
So
I'm
going
to
put
there
at
the
right
that
that
letter,
sync
okay,
so
the
next
one
is
going
to
be
the
sync
that
is
listening,
that
this
the
data
sync
is
configured
with
so
k,
logs
c
e.
I
don't
remember
the
name
that
letter
sync
yeah.
A
User
blah
blah
blah
minus
f,
okay,
so
then
we
also
have,
as
we
see
we
also
have.
If
there's
a
so.
If
there's
an
error,
I
hope
it
gets
to
the
ksbc
and
on
sdk,
but
if
there's
an
ack
and
also
a
payload,
I
need
another
service
that
is
going
to
listen
to
the
to
the
responses
from
the
one
above.
So
I'm
going
to
put
that
one
here
and
that
is
the
ce
reply,
receiver,
so
log
c
e
reply:
receiver
use
a
container
minus
f.
A
A
A
I
have
an
a
cloud
event
for
you,
so
if
you
check
the
type
is
in
type,
is
the
one
that
one
at
the
top
right
is
listening
to
and
if
I
press
enter,
I
just
expect
you
see
the
info
in
there
in
blue,
so
so
blue
means
cool,
but
but
now
I'm
going
to
do
something
different
here
and
I'm
going
to
send
a
message
that
tells
you
hey,
do
not
accept
this.
This
is
going
to
be
an
error,
but
is
it
it's
a
not
ack?
It's
a.
A
A
Four
and
then
at
the
sink
we
got
the
original
type.
You
see
that
so
the
reason
for
that
is
because
the
broker
was
configured
with
three
retries.
I
think
three
seconds
away,
linear.
So
that's
what
you
get
and
yeah
all
this
is
expected.
But
now,
let's
take
a
look
at
this,
I'm
going
to
issue
the
same
command,
but
I'm
going
to
totally
mess
here.
A
A
A
You
see
you
get
you
got
this
ack
here
and
and
then
down
here
at
the
receiver
consuming
consumer.
You
also
have
the
new
event,
so
the
this
request
there
had
the
data,
another
action
with
ack
so
that
one
over
there
sent
that
here
you
see
the
response
type
is
the
one
this
was
listening
to,
but
this
is
super
trivial.
Okay.
This
is
expected
that
you,
if
you
reply
with
a
cloud
event,
it
will
get
back
to
the
broker
and
be
delivered
to
whoever
is
listening
to
that.
A
A
A
That
one
that
is
sending
ack,
but
with
error
type
and
there
you
go,
you
get
a
processing
of
the
event.
We
are
not
telling
candidate.
If
this
is
wrong,
we
are
sending
that
back
back
to
the
to
the
broker,
and
this
one
here
is
getting
the
the
error
and
could
be
processing
and
doing
some
automatic
analytics
or
whatever
or
trying
to
fix
what
went
on
and
if
you
are
curious
about
hey.
A
But
what
happens
if
I,
if
there's
a
a
problem
delivering
so
this
doesn't
get
in
the
way.
So
still,
if
there's
a
real
non-ick,
so
you
can
see
that
there
there
are
two
instructions,
so
the
first
one
is
if
the
retract
count
is
less
than
two
based
on
the
id
of
the
request.
But
if
the
request
count
is
less
than
two
say:
non-ack,
but
after
the
second
retry
send
action,
ack
and
also
this
error
type.
A
A
Check,
okay,
there
you
go
warning
warning
and
then
the
third
one
was
an
ack
that
got
in
here
as
an
application
error,
so
that
that
is
the
thing
that
we
are
doing.
I
don't
know
if
that
sounds
super
weird
to
you
or
not,
but
so
far
it's
the
only
way
we
have,
and
I
think,
if
you
think,
of
canadian
as
a
delivery
platform,
this
totally
fits
so.
A
If
we
move
a
bit
further
on
this,
when
I
saw
sebastian
demo
demon
the
landing
talk,
he
was
talking
about
correlations,
so
yeah
we
have
those
all
over.
So
if
there's
a
cloud
event
or
a
stream
of
cloud
events
that
this
one
matching
sync
is
reading
hey.
I
took
note
of
this
I'm
interested
in
this
data,
but
I
need
something
else
I
need.
So
there
are
the
orders
there,
but
I
need
the
list
items
for
that
order.
So
then,
there's
an
event,
sender,
saying:
hey!
A
Someone
is
going
to
need
this
data
put
that
back
in
the
broker
and
this
one
will
need
to
match
both
of
them.
So
we
will
need
to
do
some
propagation
of
ids,
so
there
should
be
some
ideas
over
there
that
are
matching
them
with
some
other
ideas
from
there.
So
this
one
is
able
to
do
that
matching,
so
we
will
need
to
provide
users
with
some
capabilities
for
for
propagation.
A
This
is
not
super
super
trivial.
To
be
honest,
because
if
you
think
about
that,
if
you
do
preparation
of
all
of
them,
you
could
end
up
with.
I
don't
know
how
many
attributes,
and
probably
some
of
them
don't
make
sense
if
you
have
a
super
long
workflow
that
you're
piling
up
all
your
attitudes.
So
what
we
recommend
here
is
to
have
some
kind
of
list,
or
maybe
some
regular
patterns
for
for
this
kind
of
this
kind
of
correlation,
propagation
or
attributes
propagation,
and
the
last
one
is
my
less
favorite
one.
A
A
A
So
probably
you've
delivered
the
already
the
cloud
event,
but
you
are
telling
back
here
that
this
wasn't
delivered,
but
that
happens
everywhere.
So
I'm
not
going
to
focus
on
that.
I'm
going
to
focus
on
on
that
component.
There
doing
rooting-
and
this
is
probably
a
nuance,
but
I
would
like
to
you
know,
brokers
if
we
create
or
educate
our
users
brokers
triggers
filters
for
me,
that's
my
preferred
mechanism
for
for
communicating,
but
we've
had.
We
have
companies
that
have
this
possibility.
A
A
This
is
just
what
I
mentioned
about
the
hey
that
sync
failing,
and
this
is
the
probably
the
requisites
we
have
for
revisiting
this
reply.
Reply
package
that
we
have.
This
is
the
summary
there,
some
some
more
and
probably
we
will
come
up
with
some
new
ideas
in
there
and
investigate
what
other
people
are
doing.
But
this
is
the
summary
you
know
this
doesn't
have
to
be
triggering
mess.
A
If,
if
we
at
the
community
think
that
some
other
people
will
benefit
from
that,
we
are
more
than
happy
to
bring
some
kind
of
wrapper
of
cloud
events
client,
where
you
can
have
all
these,
but
to
be
honest
at
this
stage,
is
super
opinionated
on
our
side,
but
we
are
sharing
it
here.
I'm
super
eager
to
to
know
what
you
think
about
it,
so
that
was
it.
I
don't
know
how
long
it
take.
I
had
25
minutes.