►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Path to GA, How-To Guide: A RabbitMQ Story - Gabriel Alejandro Freites Melero, VMware
Knative Eventing ecosystem's premise is to give a common framework to develop or introduce your applications to event driven architectures by using the resources defined on the specs on top of CloudEvents to achieve it. One key feature about this is that any messaging protocol can develop its own implementation of the Knative resources, so their users can start using the “knative way” in their projects. As one of the first contributing members of the Eventing RabbitMQ implementation, I know it can be challenging and not trivial to get to GA (General Availability), This talk helps by bringing a common roadmap, along with some common mistakes, stories and FAQ’s from our experience. At the end of the talk, attendees will learn: The big picture of Knative and how to connect all this pieces into your project The process for bringing their own integrations to GA How and who defines quality gates for GA and how to prioritize them How to make your components available through the Knative release process and documentation How to avoid common mistakes and strategies to solve them Gather quantitative and qualitative feedback from metrics and users
A
Okay,
hello,
everyone.
My
name
is
Gabriel
Freitas
and
I'm,
going
to
tell
you
a
little
bit
about
my
experience
in
the
open
source
by
integrating
a
project
like
Robin,
mq2k
native,
and
this
is
path
to
UA
how
to
guide
rather
than
Chris.
Sorry,
basically,
for
this
talk,
I
want
to
learn
a
little
bit.
What
is
K
native
and
why
isn't
it
for
this
integration,
but
rather
than
queue
so
I
will
explain
the
big
picture
of
K
native
and
how
to
connect
these
pieces
into
your
project.
A
The
process
for
bringing
your
integration
to
gain
native
this
talk
is
not
going
to
be
a
deep
dive
on
how
to
integrate
a
project
to
Canadian,
but
it's
going
to
be
a
summary
and
hopefully
a
useful
roadmap
for
people
that
want
to
integrate
or
have
thought
about,
integrating
something
to
get
native.
So
you
can
look
at
the
steps
that
I
had
followed
with
by
helping
with
integration.
A
A
So,
let's
get
started
first
of
all,
if
you
are
going
to
integrate
something
to
K
native,
if
worth
knowing
what
is
K
native
for
so
to
answer
this
question,
you
have
to
go
a
little
bit
back
in
the
times
and
why
is
kubernetes
something
that
we
use
today?
So
kubernetes
was
aiming
to
solve
an
issue
with
past
time-ups
that
they
were
hard
to
develop.
Distributed
systems
have
been
hard
all
along
the
time.
A
So
with
kubernetes
you
look
to
put
an
abstraction
layer
on
top
of
building
distributed
systems,
so
you
could
manage
less
complexity
than
to
manually,
manage
like
containers,
life
cycles,
containers,
Crashers
errors
and
all
of
the
changes
that
you
have
to
do
online.
On
a
distributed
system,
kubernetes
give
you
an
opinionated
way
of
doing
this.
You
have
to
do
it
by
yaml.
You
have
to
do
the
kubernetes
API,
but
it's
a
light
opinionated
framework
to
to
use,
because
you
can
extend
the
framework.
A
On
top
of
these
kubernetes,
it's
a
steel
heart.
You
can
end
up
with
Jamal
forests,
a
lot
of
yamas
a
lot
of
configuration.
The
report
it
could
be
a
complex
and
complex,
even
when
using
kubernetes,
so
K
native
is
again
an
abstraction
layer
that
offered
you
some
building
blocks
or
some
tools
to
make
your
system
a
little
bit
easy
in
the
kubernetes
world.
So
it
is
opinionated.
Yes,
it
is
opinionated,
but
again
it
tells
you
you
have
to
use
this,
but
you
can
extend
it
using
custom
resources.
A
You
can
use
this
xcc
integration
like
the
one
that
I'm
going
to
explain
today.
So
let's
explain
the
kinetic
pieces
and
how
they
manage
to
get
a
a
pretty
a
fairly
big
picture
of
the
cloud
cloud
native
state
into
the
pieces
that
they
separated.
Okay
native
devising
some
pieces
can
either
serving
that
offers
you
a
building
block
to
manage
your
workflows,
serverless
workflows
in
the
cloud,
okay
native
Eventing,
any
River
venting.
Let
you
give
you
the
building
blocks
to
build
your
event,
driven
architecture
using
the
k-native
way
that
is
Brokers
through
your
channel
subscriptions.
A
We
will
talk
about
that
later.
Canadian
function,
it's
again,
another
assumption
layer
that
you
hide
from
the
user
functions
reduce
the
complexity
that
serving
and
everything
have,
because
this
is
hard
citizen
can
get
a
lot
of
complex,
can
get
complex
and
complex
from
time
to
time.
So
functions
is
aiming
for,
simplify
even
the
connective
way,
and
can
you
rebuild
that
was
a
taked
on?
Was
a
evolved
part
of
canary
build
like
you?
A
So
Kenny
have
a
lot
of
pros
and
cons,
as
I
said,
one
that
you
can
see
as
any
of
them
is
Community
Driven.
Adoption
and
development
is
key.
Communication
consensus
is
necessary.
We
are
a
big
Community.
We
are
looking
to
thrive
and
to
get
bigger
and
bigger.
So
you
cannot
pull
the
project
to
the
direction
that
you
want.
You
have
to
communicate
your
ideas
and
look
for
people
that
are
wanting
to
support
and
help
you
by
implementing
them.
A
Oss
OSS
is
fun,
but
hard
open
source
is
fun
because
you
get
to
know
people
from
different
companies.
You
get
to
know
a
lot
of
brilliant
people
that
it's
going
to
help
you
that
in
other
way,
working
just
for
your
Enterprise.
You
are
not
going
to
to
get
that
opportunity,
but
these
people
is
also
rotating.
A
They
get
tired
of
the
project
they
get
involved
in
other
products,
so
the
hard
part
is
too
being
able
to
get
in
the
in
the
role
of
the
people
that
left
and
keep
going
with
the
community
as
you
as
you
do,
that
can
it
even
speak
and
complex
use
the
dogs
and
us
in
the
community.
Can
you
leave
this
by
no
means
on
a
small
project?
It
has
a
lot
of
moving
parts
and
it's
always
evolving.
A
So
dogs
and
Community
is
going
to
be
the
key
for
you
to
start
understanding
the
project
and
use
the
working
groups
to
align
and
get
the
right
context.
Kennedy
have
these
working
group
Concepts,
where
people
join
groups
to
work
in
a
specific
areas
of
creative,
it's
impossible
for
one
people
to
maintain
the
whole
K
native
ecosystem,
so
the
best
way
to
start
at
least
is
joining
the
working
group
that
you
are
more
interest
to
interested
in.
A
A
The
specification
dictates,
what
your
implementation
has
to
conform
to
or
what
your
implementation
has
to
look
like
for
other
people
to
see
basically
NK
native
I'm
going
to
focus
on
getting
Eventing
in
this
talk,
because
I
think
it
was
integrated
as
a
messaging
protocol
behind
the
K
native
Eventing
implementation.
So
the
specification
is
basically
a
document
that
tells
you
as
a
developer
what
your
integration
should
have
to
for
you
to
implement,
basically
and
for
a
user
perspective,
this
document
tells
you
okay.
This
is
what
you
have
to
expect
when
using
that
implementation.
A
So
if
you
don't
see
in
respect-
and
you
want
to
implement
something
that
is
missing
or
something
that
maybe
is
not
functioning
like
the
flag
example
that
one
of
the
folks
tell
those
told
us
in
the
in
one
pass
talk,
then
you
have
to
look
at
the
type
the
type
is
going
to
tell
you.
Okay,
your
object
should
look
like
this
should
Implement
these
methods.
This
is
a
way
that
you
that
you
should
start
your
implementation
on
this
and
maybe
change
it
in
the
way.
A
That's
something
that
you
just
have
to
start
doing
it,
and
then
you
will.
You
will
know
if
you're
in
the
right
path-
and
sometimes
it
just
does
not
exist
on
Canadian
event
and
so
in
Canada
living
in
general.
So
if
it
does
not
exist,
go
for
it
write
your
respects
and
write
your
own
types
for
you
to
start
implementing
your
your
integration.
A
Now
that
we
know
how
to
start,
let's
go
to
integration,
you
must
have
a
reason
behind
your
integration
with
K
native
this
way,
a
working
group
can
stand
behind
your
integration
always
communicate
what
you
are
doing
in
key
native.
You
can
think
that
you
have
the
new
great
idea
for
a
native,
but
maybe
a
seasoned
maintainer
is
going
to
tell
you
okay.
This
can
be
done
in
another
way.
This
is
already
something
that
we
discussed
with
and
once
so
communicate.
So
our
working
group
can
stand
behind
you
or
even
create
a
new
one.
A
As
a
function
example
understand
the
pieces
involved,
us
not
not
the
whole
picture,
just
what
you
need.
Basically,
when
you're
going
to
start
your
implementation,
there's
a
lot
of
things
to
look
in
Revenue.
We
just
have
to
look
at
Eventing,
but
even
then
we
didn't
look
at
the
whole
picture
of
the
ending.
Basically,
we
ignored
the
implementation
of
channels
and
subscriptions
in
favor
of
a
higher
level
abstractions
that
were
broker
triggering
resources.
A
So
basically,
event
in
Robinson
queue
does
not
have
yet
Channel
subscriptions,
because
we
wanted
to
offer
the
the
users
that
we
had
in
mind
the
filters
and
the
capabilities
that
the
program
trigger
and
sources
where
already
covering.
So
in
that
way,
we
we
went
to
an
initial
state
to
a
ga
State
more
quicker
than
than
it
was
implementing
channels
and
subscriptions.
A
Basically,
now
that
you
have
your
picture,
you
know
where
to
implement
it
and
what
to
implement.
You
need
to
create
a
Sandbox
repo.
Sandbox
is
a
part
of
getting
native.
That
gives
you
the
tools
to
create
a
repo
that
is
not
yet
in
the
K
native
core
core
repo,
so
everyone
in
the
community
can
start
seeing
your
code
and
checking
out
what
you're
doing
and
start
contributing
if
they
are
interested.
So
this
is
a
great
way
to
start
implementing.
A
A
lot
of
things
are
covered
in
the
readme,
so
I'm
not
going
to
go
into
details,
but
this
is
like
the
road
map
that
you
have
to
follow
to
get
your
implementation
going
and
the
community
to
start
talking
about
it.
So
after
you
create
your
sandbox
repo
you're,
going
to
start
with
the
testing,
how
do
you
tell
another
software
engineer
that
your
project
works,
and
not
just
by
by
your
words,
is
by
telling
okay
I
have
test
all
of
these
all
of
this
code
and
the
RSI
is
always
passing.
A
So
there
are
three
types
of
tests
that
I
found
that
they
were
key
on
the
gay
native
environment.
One
of
them
are
unit
tests.
The
usual
unit
test
that
you
do
your
code
e2e
test.
These
are
ways
to
to
test
a
scenario:
real
scenarios
by
remoking
all
the
dependencies.
But
can
you
have
a
lot
of
resources
on
how
to
write
e2e
tests
in
different
in
in
based
on
GitHub
actions,
using
different
Cloud
providers
or
or
Cloud
environments?
And
finally,
the
conformance
test?
A
If
you
remember
I,
told
you
about
the
specification
or
specs
conformances
are
the
way
to
tell
a
K
native
that
your
conformance,
your
specification
is
being
respected
by
your
implementation.
So,
basically,
if
you
have
any
specification
of
a
broker
that
you
have
a
function
that
you
have
to
implement
and
if
the
function
needs
to
return,
something
greater
than
zero
or
and
it's
correct
or
less
than
zero
to
to
be
incorrect,
basically
a
conformance
test
to
test
this
is
okay.
I
have
this
function,
my
function
is
returning
greater
than
zero.
A
Your
conformance
is
passing
in
the
other
case.
You
are
not
respecting
the
specification
of
that
a
specific
implementation,
and
this
is
what
lead
us
to
the
whole
picture.
Basically,
this
is
a
pipeline
or
multiple
pipelines
of
the
canary
parenting
site,
where
you
can
see
where
all
of
this
is
getting
in
the
in
the
picture
you
see
here
that
Downstream
test
is
something
that
I
haven't
explained,
but
basically,
K
native
is
an
upstream
Upstream
report.
A
Option
ecosystem,
basically
so
K
native
is
the
Ripple
that
other
repos
that
are
the
Integrations
or
other
external
ripples
depends
on
Downstream.
Tests
are
the
ones
that,
based
on
the
unit
test,
the
e2e
and
the
conformances
are
going
to
talk
a
native
okay,
something
is
changing
in
the
in
the
upstring.
Our
repo
is
breaking.
Now
you
have
to
tell
us
what
to
do
because
the
ecosystem
is
kind
of
breaking
up,
so
this
is
a
way
of
automatizing
the
whole
environment.
For
everyone
to
know
like
when
it's
a
new
release,
there
are
new
changes.
A
Your
project
is
still
table
a
stable
or
your
project
needs
to
to
adapt
to
the
new
changes.
It
is
something
that
is
maybe
it's
not
for
the
the
normal
project.
You
don't
have
to
have
an
ecosystem
to
to
start
your
integration
and
all
that,
but
having
this
is
key
for
an
ecosystem
to
be
stable
and
to
be
useful
around
multiple,
multiple
Integrations.
A
Now,
let's
go
now
that
we
know
a
little
bit,
how
are
things
handled
at
K
native
and
where
are
we
in
the
in
our
cycle
to
integrate
something
with
K
native?
Let's
hear
anything
rather
than
example.
Basically
what
we
wanted
to
do
is
to
integrate
problem
queue,
that
is
a
messaging
multi-protocol
machine
system.
A
Two
events,
because
17
on
underneath
uses
messaging
protocol
to
make
sure
that
the
events
are
getting
from
one
from
the
sources
to
the
things.
So
we
started
going
over
the
Canadian
rep
maturity
levels.
We
have
cleared
that
we
have
an
initial
state
of
projects
and
a
stable
state
of
projects
and
use
of
the
state
of
projects.
Rda
was
our
goal
to
make
the
project
useful
for
for
new
users,
so
we
started
defining
what
we
needed
to
implement
as
I
already
told
you
event
in
half
channels,
subscriptions
Source,
Brokers
and
triggers
and
also
flows.
A
A
Then
we
realized
that
okay,
documentation
is
key,
but
we
are
not
getting
the
right
kind
of
documentation
for
our
users,
so
we
started
building
POC
demos
starting
getting
rather
than
cured
to
the
Canadian
docs
talks
blocks,
and
at
this
point
we
started
to
get
user
to
user
and
to
give
us
the
feedback,
and
that
was
key
with
the
user
feedback.
We
documented
even
more,
and
at
that
point
we
were
happy
on
how
things
were
going
without
them,
but
we
were
not
quite
ready
for
declared
ga4wmq.
A
We
declare
usable
when
we
integrated
the
repo
into
the
release
project.
Basically,
it's
adding
your
report
to
the
to
a
demo
having
a
way
to
release
your
repo
in
a
GitHub
action
and
integrating
the
tests
with
the
candidate
release
process.
At
this
point,
this
was
our
architecture.
Basically,
you
have
the
broken
trigger
that
are
the
ones
that
receives
a
cloud
events
and
forwards
them
to
a
sink,
and
we
have
a
source.
A
source
receives
a
rapid
mq
message
and
forwarded
as
a
cloud
event.
A
A
This
was
our
responsibility
as
KS
grab
with
mq
expert
to
Define
this
architecture.
The
orange
bits
are
the
one
that
are
managed
by
driving
in
queue.
So
this
is
not
a
problem
in
key
native.
This
has
a
the
wrong
way
of
handing
errors
and
handling
the
messages,
and
the
green
Beats
are
the
one
that
we
had
to
implement
in
K
native,
the
basically
all
of
these
receipt
of
adapter
dispatcher,
the
dlq
dispatcher
consumers
and
all
that,
so
I
will
talk
a
little
bit
about
them
in
the
next
slide.
A
One
of
the
things
that
we
had
to
do
was
defining
quality
Gates.
If
you
remember
recover,
if
you
recall
what
I
just
said,
this
is
usable,
this
is
not
yet
ga
ga
means
general
availability
for
the
user
to
use
your
project,
so
we
needed
to
have
this
quality
games
that
we
need
to
to
achieve,
for
users
start
trusting
our
product
for
for
them
to
integrate
in
the
project.
So
what
is
a
quality
gate
is
basically
that
a
milestone
that
you
need
to
reach
to
get
your
project
into
a
usable
state.
A
So
at
this
point
we
were
implementing
things
as
they
were,
as
they
were
coming.
If
a
users
told
us
like
okay,
we
need
a
thousand
messages
per
second,
we
implemented.
This
is
failing
when
I
do
this,
and
this
we
were
like
fixing
that,
but
we
didn't
have
a
concrete
set
of
goals
that
led
our
implementation.
So
when
we
Define
the
quality,
Gates
was
really
a
game
chamber
for
us,
the
First
Quality
gate
was.
We
need
to
achieve
the
a
thousand
messages
per
second.
A
Second,
one
was
we
need
to
maintain
the
at
least
once
delivery
guarantee
and
we
I'm
saving.
Two
for
the
end
or
one
for
the
end,
that
was
a
user
of
us,
told
us.
Okay,
we
need
this
and
we
saw
that.
Okay,
these
need
to
be
ready
for
the
a
because
you
know
the
case.
We
are
not
ready
yet
focus
on
the
essentials,
setting
concrete
goals.
Let
you
focus
on
Essentials
and
errors
and
areas
all
sorts
and
areas
we
were,
as
you
saw
in
the
in
the
past
slide.
A
A
lot
of
things
were
agreeing
a
lot
of
things
where
our
own
work
to
integrate
with
K
native,
and
these
things
did
not
have
any
error
recovery
system.
So
you
have
to
be
careful
how
you
that
retries,
how
you
handle
when
you're
one
part
of
your
system
is
failing,
because
that
is
key
on
an
even
driven
system
for
it
to
be
useful
in
other
projects,
and
basically
user
issues
are
critical.
A
A
We
have
a
lot
of
data
available
to
us
thanks
to
the
routing
implementation,
but
some
of
them
were
not
key
for
our
da
announcement
like,
for
example,
how
many
bytes
are
we
writing
per
second
and
are
getting
forward
by
the
revenue
system?
That
was
something
that,
if
we
follow
that
metric,
we
will
be
in
the
wrong
path,
and
this
will
probably
will
take
us
three
or
four
months
more
than
it
took
us.
A
So
you
need
to
read
exactly
what
you
need
and
you
need
to
integrate
that
into
your
development
process
or
cycle
for
you
to
get
an
successful
project.
So
can
you
provide
provides
a
good
set
of
metrics
to
consider
and
start
there?
Basically,
if
K
native
is
measuring
that,
probably
all
of
the
projects
integrating
with
K
native
is
measuring
are
measuring
them.
So
there's
some
good
clues
of
how
and
or
what
metrics
you
have
to
use
to
start.
An
integration
with
K
native
also
use
your
quality
Gates
one
that
I
explained
it
before.
A
As
a
guide
for
your
metrics,
we
wanted
to
reach
a
thousand
messages
per
second,
that's
a
point
where
you
can
start
thinking.
Okay,
if
I
need
to
get
to
that
goal,
I
need
to
measure
something
that
is
relevant
for
that
rule
and
that
give
us
the
clue
to
set
two
or
three
more
measurements
that
we
had
in
the
in
the
metrics
have
a
clear
goal
when
benchmarking,
basically
or
benchmarks,
are
adapted
with
things
that
we
can
measure
and
show
it
to
the
users.
Okay,
this
is
working.
A
It
was
what
we
promised
and
in
every
release,
We
Run
The
benchmarks
and
update
the
images
for
the
users
to
know
we
are
still
getting
into
that
goal
or
we
surpass
it
for
them
to
be
short
like
okay.
This
is
key.
I
want
to
use
rabbitmq
because
they
have
these
X
throughput
and
they
are
maintaining
in
each
release.
So
it's
important
for
the
user
to
see
and
to
be
attracted
to
your
product
like
okay.
This
is
your
magic
marks,
and
these
are
the
guarantees
that
I'm
offering
to
you
and
also
log
certain
metrics.
A
We
will
logging
a
lot
of
stuff,
and
we
were
thinking
at
some
point
that
okay,
this
could
be
used
like
a
metric,
but
no
logs
is
an
event
that
is
happening
on
your
on
your
system
and
a
metric
is
like
a
snapshot
of
your
system
in
a
certain
instance,
so
be
careful
to
go
to
take
one
as
the
other,
because
at
the
end
we
realized
that
logs
were
throwing
us
off
in
the
from
path.
So
after
that
avoid
common
mistakes.