►
From YouTube: CDF SIG Events - July 3, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
C
B
B
Okay,
so
let's
see.
E
B
I'm
not
sure
if
I
mentioned
this
already
so
we
we
met
with
Steve
on
the
vsmi
with
ML,
and
so
we
decided
on
having
like
a
a
monthly
meeting
now
a
separated,
dedicated.
B
C
Is
still
Europe
based
or
because
the
time
is
kind
of
early,
not
the
time
complaining
but
yeah.
B
No
I
don't
think
it's
your
pace,
but
that
seems
to
work
for
him.
B
Yeah
other
attack
delivery
again
I'm
asking
to
the
big
audience
here.
If
anyone
wants
to
volunteer
to
drive
to
work
there,
and
we
had
some
discussion
with
the
tag
up,
delivery
about
about
collaboration
and
I
mean
one
of
the
ideas
was
to
to
make
a
City
events
based
version
of
potato
head.
But
we
need
someone
to
drive
that
work.
So
I
guess
that's
until
we
find
someone
who
has
time
to
to
work
on
that.
That's
where
we
are.
B
Is
done
a
lot
of
work
on
pipeline
observability?
He
was
presenting
a
session
about
that
lasts,
fall
in
Detroit
at
citycon,
SCD
Summit
there
and-
and
he
made
a
proposal
about
observability
and
observability
well
kind
of
cicd
semantics
in
open
telemetry.
B
And
put
the
link
here
and
that's
something
where
that,
in
the
back
of
our
mind
for
some
time
to
discuss
with
the
open,
Telemetry
community
so
yeah
we
joined
in
the
discussion
on
on
this
PR
and
we
we
plan
for
one
of
the
upcoming
CD
events
working
group
to
have
a
session
to
discuss
about.
That.
Probably
is
going
to
be
on
the
towards
the
end
of
July
25th
of
July
that
they'll
join
rcd
events
meeting
and
hopefully
we
can
bring
some
more
people
in
their
discussion
about
that.
B
B
Maybe
I
can
update
you
on
on
CD
bands
as
well
on
the
during
the
last
working
group.
We
we
had
to
chat
with
Ben
and
Emil,
and
then
we
had
an
extra
dedicated
session
before
Emil
one
on
holidays.
So
basically
we
are
working
on
the
on
the
feature
to
connect
events
and
yeah.
That
pen
is
driving
that
effort
and
is
that
some
conversation
within
Apple
yeah
his
made
the
proposal.
B
So
we
have
now
a
couple
of
review
cycles
and
hopefully
you
know
we'll
have
our
feature
I
hope
by
the
end
of
the
summer.
With
that.
C
B
B
B
D
E
E
B
No
worries
so
yeah
thanks
for
joining
today,
just
started
with
a
meeting
with
fatty
and
went
for
the
initial
updates.
B
Do
you
shall
we
maybe
do
a
quick
round
of
introductions
since
I
believe
you're
you're
new
to
the
meeting
I
can
get
started?
My
name
is
Andrea
fito
I
work
for
IBM
as
developer
Advocate
and
I'm.
The
co-chair
of
this
group
I
see
the
seek
events
and
also
maintainer
of
the
CD
events
project.
C
Yeah
foreign
thanks
for
joining
working
at
the
links
foundation
and
leading
the
contingency
Foundation
efforts.
A
G
A
F
Yeah,
thank
you
I'm
Samia,
seen
as
you
can
imagine,
kofundo
as
well
and
working
and
with
Laura
and
based
on
the
conversation
we
have
had
with
Andrea,
thanks
for
the
opportunity
to
to
better
understand
as
well
on
our
side,
CD
event
and
also
maybe
showcase.
What
Mike
rocks
can
do,
especially
for
cloud
event
and
maybe
some
low-level
stuff
and
see
if
there
is
any
opportunity
to
to
have
multiple
contribution
and
join
our
ecosystems
or
anything
related
to
your
project
and
and
what
we
are
doing
as
well.
H
Hey
folks,
I'm
Steve
Pereira
I've
been
working
with
Andrea
and
Emil
on
a
reference
architecture
for
interoperability
in
a
value
stream
management
context.
So
we've
been
sharing
notes.
We
have
a
regular
meeting
where
kind
of
using
them
as
a
sounding
board
and
and
borrowing
their
expertise
to
help
Define
a
scope
of.
H
Let's
say
arranging
and
and
incorporating
data
from
various
sources
to
put
together
a
a
large-scale
representation
of
value
stream
performance
slightly
beyond
the
scope
of
typical,
continuous
delivery,
but
but
very
much
aligned
with
this
group.
I
hope.
B
All
right
thanks
and
welcome
everyone,
and
just
as
you
so
as
you
know,
the
the
meeting
is
recorded
and
also
we
publish
the
the
recordings
on
the
city.
Foundation
well
seek
events
playlist
so
that
that's
going
to
be
available
there
and
yeah
I
mean
Lauren.
You
see
the
the
floor
is
yours.
If
you'd
like
to
present
and
stop
sharing
all.
F
Right
we
we
have
a
few
slides,
but
we
are
we
also
happy
to
to
to
Showcase.
You
know
what
microx
is
and
especially
for
cloud
event
ucg,
so
we'll
really
try
to
make
it
short
on
a
slide
deck
and
feel
free
to
to
make
it
as
interactive
as
possible.
Clearly
we
we
are
a
small
group,
so
that's
great
and
and
from
all
sides.
F
As
I
said
at
the
beginning,
we
we
don't
know
to
be
on
SCD,
even
very,
very
well,
but
we
notice
that
you
are
using
Cloud
event,
free
evily,
let's
say-
or
at
least
that
seem
to
be
something
of
very
important
for
your
product
and
that's
why
we
are
very
happy
to
Showcase
what
microx
is
and
what
we
are
doing
for
multi-protocol
apis,
which
include
Cloud
event
so
to
to
make
it
short.
You
know
the
next
slide.
Long,
please
Mike
rocks
is
job.
So,
let's
start
by
this
one.
F
Yes,
sometimes
we
assume
you
may
have
noticed
we
we
for
three
months.
We
we
are
walking.
We
are
Postman
employees.
In
fact,
we
join
a
program
which
is
a
postman,
open
technology
and
and
that's
was
a
giant
opportunity
and
it
is
a
giant
opportunity
for
us
to
be
fully
dedicated
on
a
product.
So
that's
what
we
are
doing
for
the
latest
three
months
and
this
group
invest
on
some
of
the
specifications
like
Json
schema,
open,
API,
async,
API
and
the
first
tooling
is
micro.
F
That's
that's
could
be
of
interest
for
for
all
conversation
as
well
and
then
regarding
Mike
rocks.
So
microx
is
a
pure
community
and
open
source
project
which
is
kubernetes
native,
where
we've
we've
been
jump
on
communities
since
day.
One
project
has
been
starting
quite
a
while
ago
to
be
honest
more
than
seven
years
ago,
and
the
latest
big
news
is
since
last
week
we
have
been
accepted
as
a
Sandbox
project
within
the
cncf.
So
now
we
are
on
on
the
cnci
foundation
and
happy
to
have
this
type
of
conversation.
F
In
order
to,
let's
say
see
the
type
of
interaction
we
can
have
and
and
see
the
type
of
contribution
we
can
do
all
together
the
open
source
way,
let's
say
and
then
just
regarding
Mike
rocks
as
a
tool
that
we
have
done
and
what
we,
what
has
been
designed
day.
One
is
clearly
to
create
a
bridge
between
company
and
Enterprises
owners
and
assets.
F
By
owners
we
mean
product
owners,
business
owners,
product
management,
team
and
so
on,
and
by
asset
we
we
mean
all
kind
of
apis,
because
clearly
microx
is
a
tool
by
developer
for
developer,
but
we've
since
day
one
we.
We
have
we've
really
focused
on
multiple
multi-protocol
approach,
because
we
clearly
think
that
within
Enterprise
you
know
a
single
API
does
not
fit
all.
F
So
that's
why
we
cover
such
a
diversity
of
apis
and
specification
and
and
from
you
know,
sub
UI
for
legacy
stuff
to
grpc,
graphql
and,
of
course,
a
lot
of
even
driven
system,
including
async
API
specification,
because
we
we've
been
the
first
one
to
to
contribute
to
this
to
async
API
in
order
to
include
example,
within
async
API
and
the
cloud
event,
which
is
where
I
would
like
to
do
a
focus
with
you
guys
and
and
see.
If
there
is
any
any
opportunity
to
to
go
further.
F
A
F
And
and
just
to
to
finish
that
and
and
then
on
that
point
and
then
long
will,
will
show
what
my
proxies
and
do
and
Technical
introduction
on
the
other
aspects.
But
what
is
important
to
understand
this
multiple
protocol
approach
is
clearly
fully
dedicated
to
API
mocking
simulation
and
testing,
and
we
have
a
uniform
approach.
It
doesn't
matter
the
type
of
API
and
protocol
you
are
using
and,
of
course,
as
we
are
kubernetes
native
you
can
be.
G
Also,
and
so
just
get
back
to
some
basic
use
case,
so
regarding
asynchronous
protocol
support.
Yes,
today,
we
are
supporting
eight
different
protocols,
so
really
want
to
embrace
the
diversity
regarding
yeah
the
different
protocols
that
are
used
within
large
organizations,
so
it
could
be
Kafka
broker.
It
could
be
hyperscalers
dedicated
Technologies
on
brokering
message
brokering
systems.
G
So
we
we
try
to
to
support
the
we
have
indeed
the
largest
supports
of
asynchronous
protocols
and
what
what
microx
is
actually
doing
is
the
first
use
case
of
microx
is
to
produce
some
kind
of
API
and,
in
the
case
of
events,
it's
to
prove
to
to
produce
events
without
having
to
code
them.
So
basically
it's
a
simulation
tool
and
it
allows
to
really
shorten
the
feedback
loops.
G
So
as
soon
as
you
get
the
ID
the
row
ID
of
what
kind
of
event
you
want
to
provide
to
your
consumers,
you
can
just
feed
my
Crooks
with
your
async
API
specification
with
your
Cloud
event
specification,
and
it
is
able
to
produce
messages
for
you
so
that
your
consumer
can
start
working
on
your
message
even
without
having
to
to
wait
for
for
days
for
hours.
For
they
can
start
just
right
now
and
we
can
begin
paralyzed
development.
G
So
this
is
the
first
use
case
on
my
proxy
and
the
other
one
is
also
to
reuse
all
these
data
we
get
by
ingesting
contract,
digesting
data
sets
and
so
on
and
being
able,
when
your
implementation
is
ready
to
validate
that
what
you,
what
you
provide
as
an
API
as
the
person
who
implemented
the
MPI,
what
you
provide
is
actually
a
conformant
to
the
initial
spec.
G
Cd
technology,
we
provide
different
plugins
for
for
git,
Labs
or
GitHub
actions,
and
we
also
have
taked
on
tasks
so
that
we,
you
can
launch
microcs
tests
within
your
CI
CD
pipeline
each
and
every
time
you
produce
a
new
release
of
the
software,
so
that
you
can
check
that
you
didn't
introduce
breaking
changes
that
you
still
confirmed
to
the
1.5
1.41.3
and
so
on.
Version
of
your
API
definition
or
event.
Definition
so
really
handy
to
yeah
to
to
secure
your
delivery
of
API
based
or
even
based
application.
G
Any
questions
so
far:
nope
yeah,
okay.
So,
regarding
the
the
async
API
stuff,
how
we
are
doing
this
with
micros,
we
just
put
the
emphasis
on
two
things:
contracts
and
examples,
because
most
of
the
time,
people,
let
tools
generate
examples
for
them,
and
we
ended
up
with
all
the
string
having
the
same
values,
all
the
Boolean
string,
values
and
so
on.
But
with
my
Crux,
we
we
really
want
to
put
the
emphasis
on
and
on
the
importance
of
examples.
G
So
we
use
the
different
examples
we
can
gather
from
contracts
for
Postman
collections
for
data
sets
you
upload
in
micros
to
turn
them
into
business
expectations
into
executable
specifications
so
that,
from
the
same
copies
of
data
sets
of
API
or
even
definitions,
we
can
mock
things,
but
we
can
also
test
things
one
once
the
the
implementation
are
available,
so
pretty
MD.
It's
the
same
data
sets
that
is
used
as
well
for
simulation
and
for
conformance
testing,
so
just
made
a
quick
Focus
here
on
the
async
API
stuff
regarding
CD
events.
G
G
Ahead,
go
ahead,
okay,
so
I
think
API,
basically
is
the
it
is.
The
can
be
seen
the
sister
specification
of
open
API,
but
just
for
yeah
for
event
driven
architecture.
So
if
you
look
at
the
anatomy
of
a
Sync
API,
you
will
see
things
that
are
very
analogous
to
open,
API.
So,
basically,
I
think
API
allows
you
to
Define
basic
information
about
your
your
API
and
the
event
driven
URL
designing,
like
version
metadata
description
and
so
on,
and
it
allows
you.
This
is
the
main
part
of
a
Sync
API.
G
It
allows
you
to
define
a
channel
channel.
Basically
is
an
endpoint
where
users
of
this
API
publisher,
consumers,
provider,
subscriber
whatever
we'll
use
channel
to
exchange
informations
in
a
synchronous
way.
So
basically
channel
channel
item
is
an
endpoint
that
is
a
first
described
in
an
abstract
way
and
then
can
be
bound
to
different
types
of
protocols.
So
there
is
a
clear
separation
between
the
abstract
part.
What
is
a
logical,
Channel
and
the
physical
part
that
defines
on
how
many
different
protocols
it
will
be
actually
made
available?
G
And
within
this
channel
you
may
find
a
definition
of
messages,
including
the
definitions
of
headers
and
payload,
and
within
these
messages,
obviously,
you
can
include
schemas.
You
can
include
Json
schemas.
You
can
include
Avro
schemas,
but
you
can
also
include
Cloud
event
schemas,
so
that
you
are
really
able
to
compose
and
to
define
the
the
the
food
sculpt
of
your
even
driven
architecture
from
message,
headers
and
payload
to
The
Logical
endpoints.
G
G
And
basically,
we
we
see
a
very
handy
way
of
combining
things
between
a
Sync,
API
and
Cloud
events.
So
basically
there
are.
There
is
two
way
of
doing
things.
You
can
embed
Cloud
events.
You
know
Json
schema
when
you
are
using
a
structure,
Cloud
events,
but
you
can
also
use
some
kind
of
trade
mechanisms
that
are
available
in
a
Sync
API.
G
Maybe
just
go
gonna
switch
to
a
small
demonstration
before
yeah
getting
to
some
some
question.
I
I
had
when
reading
about
City
events
and
the
intent
of
this
demonstration
is
to
to
show
you
how
easy
it
is
using
my
Crocs
to
provide
a
simulation
of
your
events
so
that
you
can
easily
have
new
developers,
starting
on
board,
setting
up
their
environment
and
starting
developing
their
components
without
having
to
yes
to
to
rebuild
the
full
blown
environments
that
is
actually
producing
Cloud
events.
G
Okay,
can
you
still
see
my
screen?
Is
it
okay?
Yes,
okay,
so
this
is
a
microxine
stems
and
as
a
it
was
introduced
before
by
a
by
a
scene,
micro
is
providing
the
same
uniform
approach,
whatever
the
the
kind
of
API.
So
basically
here
in
my
instance,
I
have
different
kind
of
API,
graphql,
grpc
or
even-based
API,
and
what
I'm
going
to
do
right
now
is
to
yes
to
demonstrate
how
new
API
definition
API
that
are
producing
and
the
events
can
be
easily
integrated
into
micro.
G
So,
let's
imagine
I,
don't
know
if
you
had
the
time
to
check
my
my
former
presentation
or
around
a
Sync
API
at
club
events.
But
let's
imagine
this
simple
use
case.
I
have
put
some
cameras,
some
video
sensors
into
my
my
garden
I,
want
to
to
detect
the
different
inhabitants
and
whether
they
are
entering
the
frame
or
exiting
the
frame,
and
so
I've
got
this
nice
demonstration
about.
Yes,
a
fictional
Cloud
event
right
here.
So
this
is
a
sorry.
This
is
an
animal
in
the
frame
event,
and
this
is
a
schema.
A
G
G
So
let's
start
with
this
simple
use
case,
and
we
can
see
I've
put
everything
into
a
Sync
API
specification,
so
you
can
see
how
this
two
things
can
play
together.
So
here
I
have
the
definition
of
of
a
channel
with
a
reference
to
an
animal
message,
a
schema,
and
you
can
see
that
this
came
this
schema
animal
message
is
actually
built
from
my
own
definition
of
animal
data
right
here,
but
it
is
also,
in
fact,
a
cloud
event
because
I
am
including
the
cloud
event.
G
Json
schema
as
well
here
so
making
some
analogies
with
your
Cloud,
your
CD
events,
definitions,
pretty
easy
to
have
this
kind
of
composition,
reusing
some
kind
of
change,
creative
and
creative
event
and
put
everything
into
a
Sync
API
specification
to
bind
everything
together
and
now.
I'm
gonna
put
this
into
my
microcene
sense.
So
there
is
different
way
of
fitting
in
my
Cox
instance,
and
why
one
way
of
doing
this
is
just
to
Define
importers,
so
importers
can
be
plugged
to
git
repository
and,
for
example,
right
here.
G
I
can
just
activate
this
one
force
the
import
of
this
git
Repository.
We'll
do
this
one
as
well,
and
here
you
will
see
I
have
my
new
animal
sensor
API.
That
is
we're
using
this
a
Sync
API
specification,
and
this
Json
schema.
I
just
showed
you
before
and
as
soon
as
Micron
has
discovered
this
new
specification
from
the
git
Repository.
G
So,
for
example,
let
me
just
check
I'm
gonna
consume
here
topic,
and
that
is
in
fact
a
topic
that
has
been
active
that
has
been
automatically
created
by
micro.
So
as
soon
as
you
get
the
definition,
you
stop
producing
mock
messages.
So
as
a
developer,
I
can
start
consuming
those
messages
without
having
to
wait
to
have
a
full-blown
environment
or
even
sensors
in
the
garden.
Sending
me
events
so
I'm
able
to
simulate
everything.
G
So
this
is
the
this
is
the
first
use
case
I'm
able
to
do
this
very
quickly
and
I'm
also
able
to
do
the
same
things
urine
using
the
binary
representation
of
cloud
events,
so
here
I've
got
something
that
is
a
bit
more
complicated
using
Avro
schema
and
Avro
messages
to
convey
your
events,
for
example,
and
you'll,
see
that
it's
working
exactly
the
same
way
and
this
time
the
different
Cloud
events.
Errors
are
mapped
onto
the
protocol
headers,
because
this
is
how
things
are
working
in
the
binary
content
mode.
G
But
technically,
this
is
also
kind
of
things
that
my
clocks
can
handle
very,
very
easily
transform
transporting
every
message
is
simulating
everyone,
messages
that
are
bind
bound
to
a
cloud
even
specification,
so
quite
easy
to
get
this
kind
of
simulation
very,
very
quickly,
just
one
second,
the
time.
G
Yes
with
the
different,
we'll
see
different
headers
right
here
and
you
can
see.
One
thing
that
is
very
interesting
is
that
my
clock
is
also
able
to
generate
some
kind
of
random
data
so
that
each
and
every
messages
event
that
is
actually
published
he's
different
as
a
different,
unique
identifier
as
different
timestamps,
and
can
we
use
yes,
some
some
different
data
sets
to
populate
the
message
with
different
data,
so
we
try
to
have
very
something
that
is
very
close
to
the
real
life
behavior
of
your
your
even
driven
system.
G
G
I
can
easily
try
out
and
test
using
microbes
that,
let's
rerun
this
test,
I
can
listen
to
a
Kafka
broker
to
rabbitmq
broker
to
whatever
and
check
that.
The
messages
that
that
are
produced
on
this
topic
are
actually
confident
regarding
the
specification.
So
what
microx
is
doing
right
here
is
that
it
connects
to
your
Kafka
broker
to
your
rabbitmq
broker,
whatever
it
listens
for
messages,
and
it
allows
you
to
validate
that
each
and
every
messages
you
received
are
actually
confirmed
regarding
the
specification.
So
let's
get
the
full
results
here.
G
So
it's
very
easy
with
Microsoft
to
to
distribute
your
let's
say
your
test
suits
your
test
certification
kit,
so
that
different
people,
different
vendors,
who
are
implementing
the
same
specification,
May
yeah
I,
may
realize
their
own
assessment
and
so
that
it
may
be
aware
if
they
are
correctly
implementing
the
specification
of
or
if
they
are
introduced,
breaking
changes
regarding
those
specifications,
so
I
think
as
a
provider
of
API
specification
or
even
specification.
We
could
be
very
handy
to
to
use
this
micros
to
links
to
do
use
this.
G
This
async
API
specification
to
to
convey
test
should
survived
the
different
isv.
You
can
Implement.
Your
spec
are
really
able
to
run
their
own
assessment
regarding
the
spec,
and
actually
this
is
something
we
we
try
to
to
Foster
out
on
the
community
as
we
we
launched
some
time
ago.
G
So
this
Hub
is
actually
directly
integrated
into
the
microxine
sense.
So
if,
for
example,
I
want
to
start
playing
around
with
open
banking,
apis
or
iot
related
apis
that
are
provided
by
firewire,
I
can
easily
install
this
into
my
microx
instance,
and
then
I
have
right
here
all
the
different
firware
API
ready
to
use
ready
to
play
with,
so
that
I
can
easily
start
playing
around
with
with
Fireware.
G
So
this
is
a
quick
overview
of
microbes
yeah,
try
to
put
things
together
right
here
and
just
to
give
you
a
quick
overview
on
what
we
can
do
with
a
sync
and
event,
driven
API
or
even
driven
architecture.
So
the
first
use
case
is
about
having
micros
producing
a
fake
mock
messages
on
your
broker
of
choice
here,
Kafka
broker
and
we're
also
able
to
interconnect
with
different
schema
registry
as
well.
So
micros
can
be
in
charge
of
publishing
your
your
schemas
to
to
some
schema
registry,
and
the
other
use
case
is
yes.
G
Checking
connecting
to
any
broker
in
your
organization
listing
for
events
and
ensuring
those
events
are
confirmed
with
the
specs
and
complement
with
the
schema.
Schema
can
also
be
located
into
any
schema
registry
on
the
provided
by
by
any
vendor.
So
we
will
try
to
have
this
pure
vendor
neutrality.
Regarding
the
the
different
protocols
and
the
different
connection,
we
provide
with
a
schema
registry
and
finally,
maybe
to
open
up
discussion.
I
was
thinking
this
afternoon
about
yeah
different
things.
We
can
do
together
with
a
combining
CD
events
with
micro.
G
B
Yeah
thanks
a
lot
yes
for
your
presentation,
yeah,
that's
yeah!
This
is
very
interesting.
B
So
I
mean
for
CD
events
and,
as
you
mentioned,
it's
okay,
we
have.
We
have
Json
schemas
and
the
Adas
that
the
specification
is
independent
from
the
specific
way
we
transport
it
The,
Binding
that
we
we
have
implemented
today
is
Cloud
events.
So
the
way
that
you
transport,
you
can
transport
City
events
today,
at
least,
is
on
cloud
events.
B
G
No
typically,
this
was
one
of
my
first
question
regarding
the
the
scope
of
City
events
and
I
was
wondering
if
these
bindings
will
will
come
later
on
with
the
specification
or
if
it's
something
that
will
be
just
supposed
to
be
the
concern
of
the
the
provider
of
CD
events
and
that
will
be
totally
left
out
of
the
spec.
How
do
you
think
things
regarding
the
protocol
binding
stuff.
B
B
So,
but
it's
it's
a
text
describe
description.
It
makes
sense
right.
So
it's
a
it's
a
text-based
specification
and
so
I
mean
if
we
add
a
way
to
describe
that
with
the
structured
machine,
readable,
possible
format
for
sure
that
that
sounds
like
an
interesting
option,
says
As
I,
understood
from
your
presentation.
I
think
IO
might
be
an
option
to
to
achieve
that
right.
B
So
that
that's
for
sure
what
one
interesting
point,
so
that's
something
that
could
allow
us
to
to
announce
our
current
cloud
binding
documentation
with
like
yeah,
with
a
schema
that
then
it
makes
makes
it
easier
to
you
know,
test
and
verify
the
the
other
thing
that
we
we
have
today.
We
we
are,
we
have
SDK.
So
we
are
writing
sdks.
We
have
an
SDK
and
go
one
in
Python,
one
in
Java.
B
So
what
we're
doing
we?
We
use
some
at
least
for
the
go
one
and
the
Java
one.
We
we
have
some
some
code.
We
use
some
kind
of
generators,
so
we
we
parse
the
Json
schema
and
then
generate
the
the
SDK
out
of
it
right.
So
one
limitation
we
have
found,
though,
is
that
I
mean
with
Json
schema.
We
can
basically
generate
the
Jesus
came
apart,
but
that
does
not
give
you
give
us
the
entire
SDK,
because
yeah
there
are
more
apis
that
we
need
to
provide
to
create.
B
The
CD
bands
create
the
city
event
bound
to
occur
as
in
Cloud
event,
format
and
parse
it
so
they're
like
there
are
more
apis
that
we
we
need
to
provide
that
what
we
can
generate
from
using
schema
and
then
yeah
I
mean
other
things.
Other
topics
that
then
discussing
or
started
to
consider
at
least
are
things
like
conformance
testing
that
you
mentioned,
and
we
are
right
now
we
are
going
through
we're
working
with
several
communities
for
adoption
of
City
events.
B
So
yeah
we
have
a
few
tools
like
Jenkins
stacked
on
Spinnaker,
the
harbor
registry.
We
are
working
with
the
Arcos
CD
Community.
We
started
working
with
flux
so
that
this
tool
can
produce,
or
in
some
cases,
consume
CD
events
and
yeah
from
what
you
presented.
That
I
think
it
would
make
sense
to
to
have
a
way
to
to
be
able
to
test
that
the
implementation
of
these
tools
is
conformant.
B
Yes,
exactly
we
are
still.
We
still
haven't
designed
exactly
what
a
conformance
implementation
is,
but
yeah.
So
that's
definitely
something
a
part
of
the
scope
that
we
would
like
to
to
achieve.
At
some
point.
G
Yeah
the
thing
that
is
really
interesting
regarding
cdk
is
that,
yes,
most
of
the
time,
people
do
think.
A
G
G
You
used
it
to
to
generate
the
1.2,
the
1.2
cdk,
and
so
obviously
there
is
a
very
low
risk
of
drift
in
that
case,
but
you
still
have
to
ensure
that
the
cdk
1.2,
for
example,
is
still
able
to
manage
to
handle
messages
that
are
that
has
been
produced
with
the
1.1
specification,
for
example,
and
this
is
this
is
a
kind
of
of
problem
where
microbes
can
be
very,
very
handy,
because
when
you
deploy
your
new
components,
your
new
cdk,
you
can
very
easily
test
the
conformance
regarding
a
list
of
specification
versions.
A
F
F
We
clearly
notice
that
most
of
the
time
specification
there's
great
specification
available,
but
it's
not
that
easy
to
to
to
have
more
adoption
and
take
care
about
the
people
who
are
going
to
use
it
and
have
a
a
broader
adoption
is
usually
you
rely
on
tooling
and
also
way
to
simplify
adoption
or
help
the
people
who
are
going
to
use
it
to
to
to
keep
going,
doesn't
matter
the
changes,
or
at
least
ideally
the
changes.
You're
gonna
introduce.
So
that's
why?
F
You
know
the
documentation
fully
in
a
fully
automated
way
for
you
and
then
you
can
keep
your
promise
with
the
consumers
and
take
care
about
the
evolution
of
all
this
stuff
and
and
changes
you
may
introduce
and
and
from
open
view.
That's
a
very
nice
and
smart
way
to
ensure
that
the
people
who
can
join
and
adopt
CD
events
can
can
keep
going
with
it
and
and
make
it
easier
from.
B
B
That
is
not
necessarily
consistent
across
the
sdks
today,
so
if
there
is
a
good
tool
for
that,
so
the
the
way
we
implemented
today
we
we
have
a
spec
repo
and
in
the
spec
repo
we
have
examples
so
which
are
Json
documents
with
valid
messages,
and
then
we
have
Jason
schemas,
and
so
we
kind
of
generate
the
SDK
from
the
schemas,
some
additional
apis
on
top,
and
then
we
use
the
SDK
to
produce
events
that
match
the
examples
to
make
sure
that
you
know
that's
that's
matching
but
yeah.
B
So
that's
all
kind
of
maintained
manually
today,
so
it's
some
automation
tool
there,
which
should
certainly
be
helpful.
The
the
other
thing
that
we
we
wanted
to
automate
at
some
point
is
the
generation
of
the
documentation.
B
B
So
it
would
be
interesting
for
me
to
understand
how
flexible
is
the
documentation
tool.
So
if
you
can,
how
can
you
inject
if
you,
if
you
can
use
it,
and
how
can
you
can
you
inject
extra
comments,
extra
data
into
it,
so
that,
when
you
ever
generated
documentation,
you
can
actually
use
it
as
a
reference
specification
or
not.
B
Interesting
for
you,
but
just
to
to
show
so
today
we
we
have
this
kind
of
specification.
You
know
you
see
it
like.
We
have
this
type
of
events
and
then
with
a
list
of
fields,
and
of
course
we
need
to
what
what
we
are
doing
today
is
that
we
maintained
these
tables
manually
so
that
we
make
sure
that
they
are
lying
to
what
is
in
the
corresponding
Json
schema.
B
But
this
is,
of
course,
error
prone
because
it's
a
manual
process,
so
every
time
we
make
a
change
to
the
specification,
we
must
update
the
schemas
and
the
table
and
make
sure
that
they
are
in
sync,
so
we
are
looking
to
bring
more
Automation
in
the
space
as
well.
So
I
don't
know
if
that's
something
that
PSN
carrier
specification
may
help
us
with.
G
There
is
some
basic
component
documentation
component
in
a
Sync
API,
but
we
embed
in
my
Cox
also,
and
it
can
provide
you
this
kind
of,
let's
say
automatic
documentation
generation
from
your
for
your
schema,
but
yeah.
The
the
the
hard
part
here
is
always
to
when
you
want
to
keep
yes
a
global
overview
of
different
specs
and
how
they
are
related
to
each
other.
Then
make
sure
that
when
you
change
one,
you
also
have
to
change
whatever.
Yes
at
the
moment,
I
think
API.
Documentation
does
not
solve
this
kind
of
of
issue,
but
yeah.
G
G
G
B
B
Yes,
thanks
a
lot.
Maybe
we
can
continue
to
think
also
on
slack
and
try
to
find
if
there
is
any
Next
Step
and
we
can
follow
up
on
this
presentation.
B
Yeah
so
I
think
there
there
are
some
really
interesting
potential
areas.
So
thanks
a
lot
thanks
again
for
for
coming
to
our
meeting
and
presenting
to
us
today.