►
From YouTube: CloudEvents - v1.0 and Beyond - Discovery/Subscriptions - Doug Davis & Clemens Vasters
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
CloudEvents - v1.0 and Beyond - Discovery/Subscriptions - Doug Davis, IBM & Clemens Vasters, Microsoft
With the release of CloudEvents v1.0 the project has now expanded its scope to consider other potential pain points for the community. To that end, the group is focusing on Event Discovery and Subscriptions APIs in the hopes of reducing the friction of discovering which events are available from Event Producers as well as how someone can subscribe to those receive those events. In this session we'll quickly summarize, and review, the status of CloudEvents and then jump into the goals, design and status of the new Discovery and Subscription APIs specification being developed.
https://sched.co/ZewO
A
All
right
welcome
everybody
today,
clemens
and
I
are
going
to
be
talking
to
you
about
cloud
events
in
particular
the
the
status
of
the
cloud
events
project
and
where
we're
headed
in
the
future.
Hopefully
we'll
have
time
for
questions
at
the
end,
so
let's
go
ahead
and
jump
right
into
it,
because
we
have
a
lot
of
material
here.
A
So,
first
of
all,
quick
agenda
give
you
a
quick
update
on
where
we
are
with
cloud
events
project
and
then
very
quickly
jump
over
to
some
of
the
new
work
that
we're
doing
here.
So,
let's
start
with
cloud
events
itself,
so
not
going
to
go
into
too
deep
detail
here,
but
for
those
of
you
who
don't
know
what
cloud
events
is,
it
is
a
specification
for
defining
common
metadata
for
events
and
where
that
metadata
appears
and
the
messages
that
are
transporting
those
events.
A
Now
it
seems
very
simple,
they're,
a
very
high
level
and
it
is
but
we're
really
doing
this
mainly
to
aid
in
delivery
of
events
from
point
a
to
point
b.
This
is
not
about
defining
yet
another
common
event,
format
or
anything
like
that.
I'll
show
you
an
example
in
a
minute,
this
is
simply
about
aiding
in
the
delivery
of
events
across
middleware
to
its
final
destination
and,
most
importantly,
to
enable
people
to
do
that
without
having
to
understand
or
parse
the
business
logic
of
the
event
itself.
A
A
In
order
to
turn
this
into
a
cloud
event,
though,
you
add
a
couple
bit
of
extra
metadata
as
http
headers
in
this
case,
and
you
can
see
just
four
little
bits
of
metadata,
and
these
are
the
only
four
that
are
required.
The
spec
version
to
see
the
cloud
of
inspect
version.
That
is
the
type
of
the
event.
A
So
this
tells
you,
for
example,
whether
it's
a
crate
versus
a
delete
type
of
event
where
the
event
came
from
you
know
what
is
the
entity
that
was
sending
out
the
events
and
then
just
some
unique
identifier?
Okay,
now,
obviously
look
at
that.
It
doesn't
seem
too
exciting,
but
with
that
basic
information,
middleware
can
now
route
the
message
appropriately
to
make
its
way
to
its
final
destination.
Much
in
the
same
way,
you
can
actually
see
the
http
headers
doing
that
for
the
http
layer.
A
Okay-
and
I
said
it's
actually
a
very,
very
simple
concept,
but
with
that
one
little
extra
bit
of
information
middleware
can
now
be
inventing
agnostic
in
terms
of
understanding
the
business
logic.
All
they
need
to
do
is
look
for
these
common
bits
of
metadata
to
route
the
event
appropriately,
okay,
very,
very
simple
concept,
but
we're
hearing
lots
of
kudos
from
the
community
how
this
is
making
life
easier
because
they
no
longer
have
to
have
specialized
middleware
for
every
type
of
event
that
flows
through
the
system.
A
Now,
obviously,
the
final
destination
still
needs
to
understand
the
event
and
the
business
logic
to
get
its
job
done,
but
in
terms
of
routing
this
is
the
type
of
information
that
should
be
the
bare
minimum
that
people
need
to
get
their
job
done
now.
This
example
right
here
is
what
we
call
the
binary
format
just
adds
a
couple:
http
headers.
So
your
your
original
message
should
remain
basically
unchanged.
A
However,
there
are
some
people
who
wanted
to
have
everything
encapsulated
inside
the
body.
As
for
those
particular
cases,
we
actually
define
some
syntax,
for
example,
here
in
this
json
version,
where
we
actually
put
everything
into
the
body
itself,
but
you
can
see
it's
the
exact
same
data
right.
You
got
the
same
four
pieces
of
metadata.
A
The
content
type
of
the
data
attribute
when
the
data
can
hold
the
business
logic
right,
all
the
exact
same
information
now
the
content
type
of
http
header
level
obviously
tells
you
that
this
is
not
just
a
normal
json
object
or
json
payload,
but
it's
a
cloud
event
json
payload.
So
that's
how
you
can
distinguish
between
the
left-hand
side,
which
is
just
application
json,
which
is
binary
and
the
structure
side
on
the
right-hand
side,
which
is
application,
slash,
json
or
slash
cloud
events
station?
A
Okay,
so
that's
it
at
a
very,
very
high
level,
very
simple
thing:
we're
getting
lots
of
kudos
about
it
and
lots
of
different
people
are
picking
it
up
across
the
industry
in
terms
of
deliverables.
This
is
the
big
news.
We
did
go
1.0
fairly
recently,
so
yay
for
that
and
in
terms
of
what
we're
actually
producing.
We
have
different
specifications,
not
just
the
spec
itself
in
terms
of
what
the
metadata
is,
but
also
how
it
appears
in
different
formats
right
http
versus
amqp,
that
kind
of
stuff
different
encoding
right.
A
I
showed
you
the
json,
we
also
avro,
and
we
also
included
a
primer,
because
there
are
a
lot
of
technical
decisions
we
made,
which
don't
really
go
into
a
spec
itself,
but
we
wanted
people
understand
why
we
made
the
decisions
we
made.
So
we
created
a
primer
as
a
background
for
people
to
understand
some
of
the
decisions
we
made
and
some
of
the
design
choices.
Now
we
do
have
some
sdks
out
there
with
a
whole
bunch
of
different
languages,
which
you
can
see
on
the
screen.
A
A
B
B
So
what
we've
done
here
is
we're
not
very
prescriptive
and
that's
a
theme
in
cloud
events
overall
as
a
principle
that
we're
not
prescriptive
about
how
you
really
how
you
should
implement
your
service
and
there's.
No.
There
may
be
some
reference
implementations
of
these
things
down
the
road,
but
ultimately,
what
we're
defining
here
are
interfaces.
B
So
we
are
defining
this
abstractly.
A
data
model
that
defines,
for
instance,
here
in
this
in
this
way
what
a
service
is
for
discovery
and
also
defines,
and
that's
of
obviously
leaning
on
the
core
specification
that
we
have
cloud
events
and
that
defines
what
a
type
is
and
then
in
based
on
this.
We
then
define
a
http
and
a
grpc
api
that
we
have
today
in
the
drafts
and
we
might
have
further
protocols
such
as
amqp
later
so
we
define
an
interface,
and
when
you
implement
that
interface,
then
you
have
a
discovery
service.
B
B
That
service,
since
it
emits
events,
maintains
a
subscription
endpoint
and
really
what
the
service
description
here.
Does
it
just
enumerates
the
types
of
events
that
are
available
for
subscription
with
some
further
information,
and
then
we
have
a
type
collection
type
collections
really
for
the
reverse,
lookup
of
which
services
are
available,
and
this
is
an
interface
that
can
be
implemented
in
one
place
or
can
be
implemented
in
multiple
places,
and
it's
obviously
also
allowed
to
federate
those
discovery
services.
B
You
know
near
your
endpoint,
so
if
it's
required
to
subscribe
via
a
different
subscription
manager,
we're
going
to
get
to
that
in
a
second
to
be
able
to
deliver
those
events
into
your
into
your
respective
endpoint
that
you
have
and
then
that
sort
of
translation
can
also
be
done
in
that
discovery
model.
It's
not
expressed
it's
not.
It's
not
expressed
explicitly
because
the
interface
is
kept
very
simple,
but
the
flexibility
is
there
to
allow
this
next.
B
B
So
we
have
to
find
a
way
to
go
and
create
a
specification
that
acknowledges
the
existence
of
these
existing
protocols
like
mqp
and
mqtt,
which
have
built-in
subscription
notions
and
then,
at
the
same
time,
add
a
ability
for
protocols
that
don't
have
that
like
http.
To
also
allow
you
to
do
a
subscription
gesture.
That's
why
we
wrote
the
subscription
api.
B
The
subscription
api
specification
acknowledges
those
or
enumerates
the
subscription
facilities
that
exist
in
those
other
protocols,
supported
by
cloud
events
and
then
explicitly
introduces
an
api
which
can
then
be
implemented
using
http
or
can
be
implemented
using
grpc
or
implemented
any
other
protocol.
That
specifically
needs
this
to
go
and
effectively
manage
subscriptions,
and
for
that
we've
introduced
the
notion
of
a
subscription
manager
next,
so
the
subscription
manager
is
the
one
that
implements
the
subscription
api
and
the
subscription
manager
might
act
on
behalf
of
itself.
B
The
definition
here
allows
for
pull
delivery
style
where
you
are
effectively
having
the
subscription
manager,
maintaining
a
queue,
for
instance
on
behalf
of
the
producer,
so
both
of
those
things
are
possible
next,
so
those
were
effectively
complementing
the
the
the
mechanisms
that
we
have
today
in
cloud.
Events
by
you
know
closing
the
loop.
We
have
delivery,
something
that's
defined
now
and
now
we
have
discovery
and
subscription
that
we're
adding
to
it.
B
Familiar
with
with
what
json
looks
like
json
is
very
repetitive
and
puts
all
the
metadata
elements
and
the
type
information
kind
of
into
the
document
itself
and
there's
a
number
of
far
more
efficient
serialization
formats,
which
don't
do
that
and
they
keep
that
information
outside
in
in
schema
documents.
But
then,
once
you
use
that
the
question
is:
where
do
you
put
those
documents?
B
It
doesn't
simply
doesn't
make
sense
to
constrain
the
registry
just
to
cloud
events
use
cases
next.
So
that's
one
of
the
principles
that
we
have
is
at
the
bottom.
What
I
just
said
that
it
should
be
scenario
neutral:
it
should
also
be
protocol
neutral,
so
the
registry
data
model
is
abstractly
defined
and
the
http
binding
that
we
have
so
setting
and
receiving
message
schemas
via
http.
B
That's
well
defined
right
now
with
an
open
api
document,
but
the
the
registry
per
se,
the
the
data
model,
is
abstract,
find
and
we
allow
it
allows
protocol
bindings
and
we
certainly
anticipate
to
have
an
amqp
binding
for
this
and
hopefully
more
bindings.
That
somewhat
depends
because
it's
a
request,
response
model
and
request
depends
on
the
capabilities
of
the
respective
protocols,
but
grpc
is
also
certainly
in
the
cards
and
of
course
we
want
to
keep
this
as
simple
as
possible.
B
We
don't
want
to
turn
this
into
a
massive
metadata
store
with
super
powerful
capabilities.
So
there's
no
goal
here
to
rival
the
capabilities
of
apache
atlas
or
something
like
this,
but
really
is
like
you-
should
be
able
to
implement
this
registry
api
over
a
plain
file
system
or
a
cloud
blob
store,
and
it's
just
there
to
store
those
store.
Those
schemas
and
manage
those
schemas
in
the
simplest
possible
way,
while,
while
providing
the
core
capabilities,
we
need
next.
B
So
this
complements
the
event
delivery
model
that
I
just
talked
about
by
allowing
you
the
producers
to
manage
and
validate
or
someone
on
behalf
of
the
producers
to
manage
the
value
of
the
schemas
and
then
really
think
about
the
data
field
in
the
cloud
event
and
how
that
can
be
serialized
and
deserialized,
and
that
model
here.
What's
in
the
green
works
for
cloud
events
as
we
have
defined
it,
but
also
works
for
other
eventing
scenarios
as
well.
B
B
Finally,
the
structure
of
the
schemes
of
this
schema
registry-
we've
structured
this
such
that
there
is
a
notion
of
groups,
the
group
they
can
group.
So
a
schema
registry
is
split
up
into
groups.
Those
groups
can
be
by
application
or
by
some
other
criteria.
They're
really
also
there
as
an
anchor
for
access
control.
So
you
may
want
to
go
and
limit
access
to
schemas
by
groups
because
they
may
carry
important
secrets.
So
you
don't
want
to.
B
We
have
various
schema
versions,
starting
with
schema
version,
one
where,
if
you're,
adding
fields
or
if
you're
making
feels
obsolete,
but
you
don't
remove
them,
then
you're
still
within
the
same
bad
words
compatible
schema
of
generate
generations
line
of
generations,
and
that's
why
you
simply
add
schema
versions.
We
have
some
rules
for
how
to
add
and
manage
those
schemas.
So
it's
a
very
simple
structure
to
manage
effectively
schema
documents.
Next.
B
And
that's
where
we
are,
we
will
take
some
live
questions
in
at
the
end
of
this
presentation
following
now.
If
you
want
to
learn
more
about
cloud
events
go
to
cloud
events
io.
Our
specification
repository
is
on
github
on
cloudevent
spec.
That's
where
you
also
will
find
the
latest
versions
of
all
of
those
things,
and
we
also
have
weekly
calls
thursdays
at
12
p.m.