►
From YouTube: CDEvents Working Group (EMEA/AMERICAS) - June 13, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
Hello
trying
to
find
the
documents
real,
quick,
oh
the
hack,
MD
links,
are
broken.
C
A
Okay,
three
past
I
guess
it's
time
to
to
get
started
so
welcome
everyone
to
the
City
events.
Working
group,
yeah
I,
prepared
an
agenda
for
today
on
a
couple.
A
A
A
So
there
are
nine
projects
and
on
the
four
seats,
and
so
we
have
a
few
candidates.
Not
all
the
projects
submit
to
the
candidate
that
we
had
more
than
four
and
ml
is
running
as
the
CD
events
candidate.
So,
if
you're
eligible,
if
you
go
to
voting
link,
please
please
do
vote.
A
So
they
ask
for
updates
from
all
the
project
representative
and
the
project
representative
for
CD
events
in
the
Outreach
committee,
and
so
they
ask
for
some
physical,
yes,
a
slide
with
some
updates
from
all
the
projects,
and
this
is
what
I
proposed
and
I
just
wanted
to
share
it
here
and
see.
If
there
was
any
feedback
questions
comments
on
it,
that's
basically
a
show
description
about
what
City
events
is.
A
What's
new
from
the
last
two
releases,
video
with
two
and
with
zero
three,
so
we
have
tests
and
incident
events.
Initial
software
supply
chain
security,
the
Javas
Decay
now
is
available
in
maven
a
list
of
tools
that
we
are
working
with
so
Jenkins.
Of
course,
that's
cute
spinaker,
which
has
been
implemented,
texting
which
is
experimental,
Argo
and
Arbor
and
RC
status,
and
then
more
tools
that
express
interest.
A
So
we
have
collaborate,
various
collaboration
going
on
with
the
VSM
interoperability,
cncf,
app
delivery,
tag,
open,
ssf
and
the
more
recently
with
acid
interoperability,
interest
companies
so
Fidelity,
which
is
an
adopter
SAS,
Apple,
Ericson,
IBM
and
more
and
what's
next
connective
events,
visualization
supply
chain
security,
more
tools
and
adoptions.
So
that's
that's
what
I
add
in
terms
of
updates.
A
A
Great
yeah
I
think
it
it's
a
it's
a
nice
picture
of
the
project,
so
we
think
I
mean
we've
been
doing
a
lot
of
work,
so
I
think
it
shows
in
the
updates.
So
that's
good,
all
right
and
since
you're
here
Ben
I
I
attend
the
agenda.
I'll
just
move
it
up.
B
Yeah,
unfortunately,
I've
been
super
super
swamped
at
Apple.
My
calendar
just
cleared
up,
though,
however,
so
the
reason
why
I
wasn't
able
to
get
any
work
done
on
the
city
of
it.
So
we
actually
had
a
security
issue
that
I
needed
all
hands
on
deck.
Force
I
had
you
know,
so
that
was
that
was
priority
number
one,
but
that
was
solved
Monday,
so
that
was
about
a
week's
worth
of
work,
but
so
this
week
spending
all
my
time
on
on
CD
events
as
well
as
Spinnaker.
B
So
jillander
also
reached
out
to
me
about
Spinnaker
his
PR,
so
I'm,
taking
a
look
at
I'm
going
to
take
a
look
at
those
within
maybe
this
week
or
next
week,
and
then
the
plan
also
is
something
also
related
to
specifically
that
these
could
be
updated.
So
that's
that's
the
plan,
but
yeah
so
CD
events
for
the
links
I've
been
working
on
it,
but,
like
I
said
it's
been
a
little
sporadic
due
to
the
timing
strikes.
B
I've
I've
had,
but
it's
actually
getting
a
lot
larger
than
I
originally
anticipated,
but
I'd
rather
have
it
be
large,
detailed
and
then
you
guys
can
kind
of
like
nitpick
and
kind
of
figure
out
what
works.
What
doesn't
right
now,
so
the
section
that
I
have
added
it
kind
of
had
been
expanding
upon
is
called
client
apis
and
Link
Storage.
B
It
kind
of
goes
over
these
low-level
apis
that
I
haven't
updated
it
yet
so
I
just
I
spent
all
this
morning
working
on
that,
but
it
goes
over
the
client
apis
which
I
imagine
the
CD
events
SDK
would
use.
B
So
that's
kind
of
the
idea
so,
like
I
said
like
once,
once
I
push
it
up,
we
can
have
some
more
discussions
on
that
and
then
talks
about
Link,
Storage
and
like
the
possible
formats,
but
kind
of
leaving
that
up
to
the
I
just
kind
of
like
plugins.
If
you
will
like
I.
Imagine
like
we
want,
you
know
different
types
of
plugins
for
database
storage
types
like
you
know.
If
you
want
to
use
you
know
MySQL,
you
can
use
that.
B
If
you
want
to
use,
you
know,
Cloud
base,
you
can
or
yeah
you
can.
You
can
use
that
as
well.
You
know,
or
you
know,
there's
various
different
databases
that
we
can
just
you
know
say
as
long
as
you
adhere
to
this
format
or
whatever
you
can
you
can
you
can
get
sort
of
these
properly?
We
could
fetch
them.
B
So
that's
kind
of
the
plan
so,
like
I,
said
still
a
little
bit
of
work
on
the
client
apis
and
the
Link
Storage,
but
it
from
the
work
that
I've
done
on
it
just
this
morning.
I
think
I
can
have
something
pretty
close
to
being
ready.
B
You
know
soon,
I,
don't
want
to
give
you
a
time
because,
like
I
said
the
last
time
that
happened,
work
kind
of
like
intervened,
but
you
know
like
I,
said
it's:
it's
it's
getting
there
so,
but
I
I
could
definitely
say
it's
it's
going
to
be
rather
soon
so
I
don't
want,
like
I
said,
don't
want
to
give
you
a
hard
day,
but
it's
going
to
be
you
know,
I
would
say
on
an
S,
maybe
like
a
couple
days.
B
I
can
have
that
PR
updated
and
then
we
can
start
reviewing
it
but,
like
I
said,
if
I
end
up
missing
just
ping
me
and
I
can
kind
of
give
you
an
update.
Like
you
know,
hey,
you
know
something
at
work.
Kind
of
came
up
that
I
needed
to
address,
but
I
could
push
up.
You
know
what
I
currently
have
so
on
and
so
forth,
but
but
yeah,
but
other
than
that
you
know
things
are
going
well.
B
I
think
the
client
apis
and
leaked
storage
is
going
to
answer
all
of
Emil's
questions
that
he
had,
which
you
know
he
brought
up
some
interesting
points.
So
I
think
it's
going
to
be
good
to
talk
about
and
kind
of,
think
kind
of
the
thought
process
behind
that
so
so
yeah.
But
it's
kind
of
it's
kind
of
it's
definitely
getting
flushed
out.
It's
becoming
less
of
a
rough
draft
and
now
the
more
of
a
actual
proposal.
So
things
sound
good.
B
And
then
I
also
mentioned
so
this
is
also
something
from
elastic
meeting
that,
like
I,
said
due
to
Thomas,
writes
and
and
how
swamped
I've
been
I
wasn't
able
to
do
but
I
also
plan
on
getting
that
meeting
set
up
for
Jill,
Andrew's
demo.
B
I
think
that's
something
that
we
all
want
to
see.
You
know
on
us
being
Spinnaker
as
well
as
Apple
versus
other
candidates,
so
yeah
I'll
I'll
go
ahead
and
ping
some
some
folks
after
this
meeting.
Just
so
I
don't
forget-
and
you
know
just
kind
of
get
that
done
and
then
kind
of
see
where
the
interest
lies
and
then
start
thinking
about.
You
know
when
when
we
can
have
a
have
a
demo,
if
that
works,
for
you
julander.
D
Sure,
definitely
then
so
we
can,
we
can
have
it
demo
once
you
get
the
folks
who
is
interested
so
yeah.
A
Oh
yeah,
that's
great
yeah!
Thanks
for
that
that
that
really
I
think
it'd
be
fantastic
to
to.
C
A
Forward
with
that
side
of
thing
as
well,
Ander
has
been
doing
great
work
with
the
with
NPR,
so
I
think
yeah
having
a
demo
help
getting
more
reviews
as
well.
So.
A
Cool
all
right,
so
the
last
item
I
had
on
the
agenda
was
the
v04
planning
and
that
we
started
doing
in
the
last
couple
of
meetings
with
the
mill.
A
So
we
used
the
last
CD
events
working
group
and
also
the
Sig
event
meeting
in
the
afternoon.
We
didn't
have
much
in
the
on
the
agenda,
so
we
just
continue
with
the
planning,
but
we
haven't
finished
yet
so
I
was
blaming
to
continue
that
that
work,
but
maybe
before
we
got
into
that,
does
anyone
else
have
anything
they
would
like
to
to
bring
up
Adam,
jalander
and
any
updates
or
questions
or
things.
You
would
like
to
discuss.
B
One
thing:
so
this
is
more
this
thing
like
Fidelity,
you
know
with
the
adopter
it's
more
of
a
question
for
Fidelity,
but
if
you
have
any
contexts
under
this
might
be
nice
it'd
be
a
good
it'd,
be
a
nice
it'd,
be
good
to
get
some
information
on
how
Fidelity
is
using
CD
events
and
what
what
issues
they've
potentially
run
into
what?
B
If
they've
made
any
changes
to
any
specs,
because
I
I
haven't
seen
them
I,
don't
I,
don't
think
I've
seen
them
in
any
of
the
six
I'm
just
kind
of
curious,
like
where
they're
at
in
terms
of
being
an
adopter
like
what
sdks
are
they
using?
You
know,
you
know,
is
this
in
yeah
like
what
services
are?
Is
it
for
you
know?
Is
it
just
for
CI?
Is
that
for
both
cicd?
B
You
know
like
it
would
just
be
nice
to
know
these
things
and
kind
of
get
an
idea
of
like
the
level
of
adoption.
A
Sure
so
Fidelity
they
they
contributed
the
Jenkins
plugin,
so
they
provided
the
implementation
for
City
events
in
Jenkins
and
they
yeah.
A
There
are
a
few
folks,
Johnny
I
think
Evan
was
planning
to
join
today,
but
he
wasn't
able
to,
but
he
has
been
doing
some
work
also
on
the
python
SDK
yeah,
so
they're
just
kind
of
scaling
up
their
adoptions,
so
they
they
wrote
this
user
story
where
they
mentioned
what
they're
doing
with
Jenkins
and
City
events,
and
so
this
is
the
first
part
of
the
story
so
which
is
describes
kind
of
what
the
the
issues
that
they
have
and
how
they're
addressing
them
and
how
they
plan
to
integrate.
A
Cde
events
into
it.
So
I
just
put
the
link
on
the
notes
and
yeah
I
mean
if.
A
B
That
would
be
great,
I
just
want
to
know
the
level
of
adoption
more.
So
you
know
like
you
know
like.
Is
it
just
for?
Like
one
team
is
this
you
know
across
the
whole
Fidelity
company,
you
know
I
just
want
again
idea
of
you
know
kind
of
the
breadth
of
implementation
as
well.
As
you
know
what
technologies
that
they've
implemented
this
for
you
know
I
know
you
said
Jenkins
but
I
mean,
like
you
know
like
what
tool
chains.
B
Oh
there's
Evan,
maybe
he'll
he'll
know
so
yeah
like
what
tool
chains
you
know
like
Java
or
they
using
go.
Are
they
using
you
know,
or
maybe
it's
some
other
language
that
we
don't
have
an
SDK
for
you
know
you
know,
which
is
completely
possible,
so
I'm
just
kind
of
curious
about
those
questions.
More
of
the
technical
aspect
of
things.
A
C
A
Then
was
that
just
asking
just
asking
us
about
the
level
of
adoption
of
City
events
Fidelity,
what
kind
of
platform
it
is
used
with,
which
Technologies
and
so
forth
and
yeah?
Obviously,
since
you
just
joined
I,
was
wondering
if
you
wanted
to
pick
up
that
question.
I
was
just
sharing
the
the
user
story
that
was
published,
but
yeah.
E
B
E
Most
definitely
so
we
started
with
Jenkins,
because
that
is
what
tells
our
full
story,
and
so
our
pipelines,
you
know
Jenkins,
is
going
to
talk
to
artifactory,
it's
going
to
talk
to
various
platforms,
and
so
we
wanted
to
start
with
the
single
point
of
Truth
our
pipelines.
The
majority
of
them
are
triggered
by
a
commit
ID,
and
that
is
where
we
start
everything.
If
you
build
an
artifact,
we
want
to
track
that.
E
So
we
wanted
to
start
at
the
central
piece,
and
so
we
we
went
with
Jenkins
and
said:
okay,
we'll
adopt
CD
events
here
or
are
other
platforms.
We
haven't
integrated
them
yet
now
artifactory
they
are
starting
to
look
at
the
plug-in
or
not
they're,
starting
to
look
to
build
a
plug-in,
which
then
we'll
have
the
opportunity
to
probably
ingest
and
use
that
plug-in
internally.
But
right
now
we
just
wanted
to
start
with
the
main
Central
piece
which
talks
to
everything
and
that
was
Jenkins.
E
The
challenges
that
we've
had
is
versioning,
so
R
Jenkins.
You
know
we
don't
follow
the
latest
and
greatest.
We
like
it
to
go
through
the
vendor,
Cloud
bees
which
goes
through.
You
know
the
rigorous
process
of
testing
the
version
changes
and
so
sometimes
we're
a
version
or
two
behind
to
make
sure
that
we
follow
kind
of
the
cloud
bees
standards
and
so
sometimes
versioning
and
the
dependencies
that
also
played
a
little
bit
of
a
difference
and
how
we
had
to
navigate
this.
But,
overall
writing.
E
The
plugin
genius
doesn't
have
got
a
really
good
plug-in
documentation.
That
was
also
quite
fun,
but
we
have
some
awesome
developers,
Rory
I'm,
a
developer
who
is
extremely
smart,
and
so
once
we
got
through
that
and
got
through
that
adoption,
we
saw
a
lot
of
great
data
just
started
coming
in
and
once
we
figured
out
the
class
structure,
you
know
just
Java
classes
and
how
we
could
pull
that
information.
It
was
actually
really
helpful
and
information
we
started,
but
we
saw
a
lot
of
benefit.
B
Yeah
yeah.
That
is
definitely
answers
a
lot
of
my
questions.
So
one
thing
so
in
terms
of
Jenkins
right,
so
you
you
guys,
wrote
a
plug-in
that
will
send
CD
events.
So
my
question
is:
did
you
guys
have
to
change
your
architecture?
B
Did
you
guys
go
like,
or
did
you
always
rely
on
a
vet
bus,
or
did
you
go
and
follow
more
the
peer-to-peer,
because
there
you
know,
there's
two
ways
of
sending
CD
events
there's
the
event
bus
way,
and
then
there
is
the
you
know,
peer-to-peer
way
where
you
send
CD
events
directly
to
the
service.
Which
way
did
you
guys
end
up
implementing.
E
No
you're
good,
so
I
the
weight.
So
before
we
had
CD
events,
we
were
sending
data
to
first
off
a
Kafka
queue,
so
we
started
with
Kafka
where
we
would
fire
the
events
and
it
took
you
and
we
had
our
consumers
and
then
we
eventually
moved
to
not
kpl
Kinesis
or
whatever
it's
called.
E
So
what
we
did
is
for
ours.
We
wanted
to
keep
the
producers
simple
and
we
basically
package
up
the
cloud
event
and
then
conspire
it
to
a
queue
and
then
let
the
consumers
consume
it
from
there,
and
so
we
tried
to
keep
the
producers
simple
in
regards
to
the
event
that
was
being
created
and
just
fired
off,
and
so
we
wanted
to
kind
of
give
them
that
level,
and
so
before
we
had
seed
events.
E
We
were
already
doing
that
with
we
started
with
the
bucket
and
then
we
moved
to
GitHub,
and
so
we
started
building
it
from
there.
So
that
was
our
initial
architecture
and
we
didn't
have
to
change
that.
That
was
the
beauty
of
it.
We
wrote
it
in
a
way
where
the
endpoint
can
take
any
so
our
Kinesis
endpoint
can
take
the
source
information
from
any
artifactory
sonar
and
in
the
type
so
the
oh,
the
CD.
E
B
That
helpful
yeah
yeah
that
that
totally
makes
sense.
Okay,
so
you
guys
did
really
have
to
do
too
much
like
re-architecturing
because
it
seems
like
you
already
were
using
the
event
plus
design
there.
So
that's
actually
really
good
to
hear
so
in
terms
of
so
you
now
have
this
foresee
I
I'm
guessing
also
for
CD
I'm
guessing
you
do
it
for
both
in
Jenkins,
CI
and
CD,
and
then.
E
We
do,
but
more
specifically,
what
we're
trying
to
do
for
the
initial
one
is
collect
the
Onstars
and
on
complete
events,
we
wanted
to
get
both
ends
so
that
we
could
tie
so
we
use
it.
We
use
genes
on
a
kubernetes
instances,
so
the
Pod
hash
is
always
distinct
and
we
tie
all
the
events
with
the
pot
hash
and
we
always
want
to
collect
the
start
and
the
end
of
that
Pipeline
and
then
in
between.
We
have
our
task.
B
E
Absolutely
so
our
goal
is,
as
we've
moved
to
having
a
continuous
you
know,
deliveries,
it's
kind
of
industry
thing.
We
want
to
improve
the
developer
experience
first
off
with
like
audit,
so
right
now
you
know
developers
have
to
go
in
and
when
they
do
a
change
it
used
to
be
and
it
changes
to
her
department
and
the
maturity
in
their
pipelines
and
their
deployment
patterns.
E
But
you
know
that
have
to
submit
a
ticket
to
the
security
department
and
review
stuff
like
that
and
and
have
a
trail
for
if
audit
ever
came
in
and
wanted
to
review
their
changes,
and
so
our
goal
is
to
be
able
to
with
each
commit
ID
track
that
change
that
it
went
through
the
correct
scanning
that
it
went
through
the
correct
Gates.
E
So
we
have
certain
governance
Gates
that
we
like
to
use
and
then
tie
that
to
an
artifact
and
then
what
we
want
to
do
is
pull
that
information
from
the
various
platforms
that
we
do
use
and
kind
of
build
a
larger
picture
so
that
one
on
the
individual
developer
level.
They
can
see
okay,
this
artifact
that
was
deployed
that
went
through
all
the
right
steps.
I
can
track
it
with
my
commit
ID
through
a
pull
request.
E
I
can
see
that
this
went
through
all
the
correct
Gates,
and
so
now
the
audit
can
consume
that
and
see.
Oh
okay,
this
group
is
following
this
and
their
commit
IDs
are
going
through
the
formal
process
we
can
see.
They
have
the
correct,
pull
requests
with
two
approvals,
and
we
can
also
start
to
build
kind
of
we're
not
there
yet,
but
build
a
branching
strategy
to
understand
their
maturity
and
how
they
are
doing
releases.
E
The
other
big
thing
is
for
as
we
roll
up
to
managers
as
we
roll
up
to
like
VPS
who
have
several
products
under
them,
they
can
increase
kind
of
start
to
see
a
portfolio
of
how
matures
their
applications
are.
Maybe
they
have
an
application
that
only
gets
out
update
every
three
to
four
months
and
they're
like
why
am
I
paying
money
for
this
to
be
worked
on?
E
B
Cool
cool
yeah:
that's
that's,
really
useful
information.
All
right,
cool,
yeah,
I
think
that's
kind
of
like
the
primary
questions
that
I
have
is
just
the
breadth
of
of
what's
implemented
and
I'd.
Be
so,
are
you
guys
talking
specifically
with
artifactory,
to
get
that
Plug-In
or
like
what,
like
I,
guess,
who's
kind
of
like
seeing
that
through
yeah.
E
E
So
in
Jenkins
we
use
the
jfrog
CLI
and
from
that
we
get
our
artifact
Shaw
and
what
we
do
is
we
push
that
to
our
evidence,
store
through
the
pipeline
data
and
So,
eventually
we'll
want
to
collect
more
information
from
jfrog,
but
if
they're
already
working
on
the
plugin
for
CD
events
that
we
might
not
need
to
and
so
right
now
all
we're
doing
is
pulling
the
artifact
shawl.
Now
that
can
be
pulled
by
other
groups.
So
if
they're
making
artifactory
apis
to
check
on
it
and
collect
metadata,
they
absolutely
came.
E
B
E
The
artifact
Shaw
is
collected
in
when
we
execute
kind
of
like
a
shell
script.
When
we
execute
the
jfrog
CLI,
when
it's
uploaded.
Eventually,
we
would
want
a
plug-in
in
the
artifactory
service,
like
an
artifactory
landscape,
where
you
go
and
select
what
plugins
you
want.
We
would
eventually
want
to
move
to
that.
A
Up,
sorry,
sorry,
you
know
I
just
wanted
to
to
add
to
it
that
just
to
so
we
we
also
had
a
meeting
with
with
the
jfrox
product
managers
with
Fati
myself.
Jared
was
there
I
believe
and
so
to
present.
City
events
and
you
know,
make
a
case
for
City
events
and
options
within
artifactory,
so
yeah,
so
hopefully
that
that
will
help
and
I
mean
we.
We
had
product
Managers
from
the
art,
the
registry
side
and
an
artifactory.
A
They
also
have
a
pipeline
component,
and
so
they
both
expressed
some
interest
and
asking
questions
about
what
City
events
could
could
give
both
those
two
components.
Oh.
B
That's
really
good
information
Andrea.
So
are
you
guys
planning
to
have
another
meeting
with
them?
Because
if
you
could
include
me
or
someone
else
like
on
my
team
for
for
this
discussion,
because
we
are-
you
know
like
if
we
say
Hey,
you
know:
listen,
we
need
CD
events
in
artifactory,
I'm,
almost
100
sure
they
will
be
like
okay.
B
Let's
do
this,
you
know,
so
it
would
be
really
nice
to
be
able
to
give
them
that
push
to
start
that,
if
you
guys
need
it,
if
you
guys
feel
like
you
need
it,
but
it
would
be
nice.
You
know
if
I
could
I
can
help
kind
of
expedite
that,
if
possible,.
A
Sure
we
don't
have
a
specific
meeting
planned
right
now.
I
think
we,
it
was
one
of
one
or
two
weeks
ago,
and
we
said
okay,
maybe
in
the
next
two
or
three
weeks,
we'll
discuss
again
but
I'll
I'll
be
happy
to
find
the
channel
for
you
to
convey.
You
know
your
interests.
B
Perfect
yeah
that
sounds
great
because
like
if
we
can
just
get
an
artifactory
plug-in.
You
know
that
makes
you
know
Fidelity's
life
easier.
It's
going
to
make
our
lives
easier
where
we
can
just
drop
that
in
and
it
just
starts
working
like
that
is
ideal.
You
know
so
yeah
cool
good.
Thank
you
so
that
yeah,
it's
really
good
information,
but
but
yeah
Evan.
So
that's,
basically
the
gist
of
like
all
the
questions.
I
have.
B
So
thank
you
for
sharing
this
because
I'm
going
to
take
this
back
to
my
team
and
be
like
hey
listen.
This
is
what
Fidelity's
doing
you
know
we
we
can.
You
know
kind
of
mimic
the
same
idea
we'll
have
to
re-architecture
stuff,
because
we
don't
do
the
event
bus
system,
but
it's
something
that
we
can
do.
You
know
it's
just
gonna
take
a
little
bit
of
man
hours,
but
it's
definitely
something
we
we
plan
on
doing,
but
but
yeah.
E
Yeah
one
thing
I
would
also
recommend,
and
we
went
with
this
decision.
I
mean
it's
kind
of
standard,
but
it
is
once
we
went
through.
It
realized
that
non-relational
databases
I
mean
they
are
just
fantastic.
One
of
the
reasons
we've
had
success
with
ours
capability
using
CD
events
is
when
we
do
send
it
to
you
know
an
endpoint,
even
though
it's
generic
and
the
payload
is,
can
be
then
parsed
and
you
know
used
a
deserializer
and
all
of
that
or,
however,
you
write
it.
The
ability
to
have
different
tables.
E
So
let's
say
you
have
an
artifact
table.
You
have
a
pipeline
table,
you
have
a
code
scanning
table
and
then
to
section
that
out
and
then
have
the
ability
to
where
you're
not
limited.
You
know
you
have
your
primary
secondary
key
and
then
all
that
extra
data
that
really
makes
development
in
the
future
easier.
Because
then
you
can
write
a
simple
producer
that
allows
you
to
then
add
an
enhancement,
but
then
you
don't
have
to
go,
make
major
changes
to
any
of
your
tables
or
things
like
that,
and
that
has
been
really
beneficial.
B
B
We
don't
use
a
relational
database
right
now,
but
postgres
does
have
a
Json
B
column
or
a
Json
column,
so
we
could
just
throw
it
in
there
worst
case
but
but
yeah.
That's
that's.
Definitely
a
good
call
out,
though
it's
non-relational
dating
I'm,
a
huge
fan
of
them.
So
any
more
reason
to
use
them
I'm
all
on
board.
So
yeah.
E
B
Definitely,
okay
cool
yeah,
so
thanks
again,
I'm
gonna
definitely
bring
this
back
to
my
team
and
we'll
definitely
do
some
discussing
and
see
how
we
can.
We
can
help
with
or
think
about
doing
so
really
appreciate
it.
Of
course,.
E
B
That's
that's
fair
I,
completely
understand
that
yeah
yeah,
so
definitely
I'll
I'll,
definitely
ping
you.
If
I
have
any
questions.
You
know
it's
always
good.
You
know
to
like
kind
of
share,
like
you
know,
like
the
the
troubles
and
trials
and
tribulations
that
one
company
is
going
through
so
yeah
yeah.
Definitely.
A
Nice
yeah,
so
this
was
very
nice.
It's
very
good,
too
yeah
to
discuss
this
experience.
So
thanks
a
lot
David
yeah.
A
Yeah
so
I
think
we
we
have
still
some
some
time
left
in
the
meeting.
I
mean
the
one
thing
that
I
had
on
the
agenda
was
the
v04
planning,
but
again
before
we
get
into
that,
I
was
wondering
if
there
was
anything
in
particular
that
you
wanted
to
discuss
Evan
today,
I've
asked
everyone
else.
Well,
so
do
you
have
any
topic
or
any
specific,
update
or
questions
that
you
wanted
to
bring
up
today
or
otherwise
we
can
switch
to
the
planning.
E
Yeah
now
that
I
am
back
after
a
fun
month,
the
so
internally
for
the
like
seed
of
individualization
I
am
trying
to
get
people
internally
excited
to
kind
of
start
a
conversation,
so
I
mean
I.
I,
know,
you've
tagged
a
few
people
and
someone
had
a
great
post
a
few
weeks
ago,
I
just
haven't
had
a
chance
to
get
to
it,
but
now
I'm
gonna,
try
and
pick
that
back
up,
because
I'm
really
excited
for
the
visualization.
E
That
will
probably
start
seeing
more
activity
on
that
in
the
coming
week,
and
so
we're
trying
to
start
picking
that
off
getting
people
excited
and
other
than
that,
the
python
the
python
SDK
we
are
working
on
adopting.
Oh,
it's
been
a
few
weeks
pedantic
and
we're
almost
there.
We
just
got
held
up
internally
at
one
quick
change
that
we
needed
to
do
other
than
that
pick
back
up
where
we
went.
A
That
was
good,
so
do
you
have
a
feeling
how
far.
C
E
Yes,
I
have
that
code
ready
to
go
I,
have
it
on
an
laptop
right
here,
but
I
was
in
an
accident
and
never
just
push
it,
and
so
I
will
get
that
uploaded
and
the
automation
should
be
there.
I
have
like
you,
we're
still
trying
to
create
the
python
token
on
the
for
the
action
that
I
implemented
just
want
to
run
that
code,
and
then
we
should
be
ready
to
go.
I
just
need
to
get
that
uploaded.
A
A
Progress,
oh
maybe
another
question,
so
I
think
for
the
go.
Sdk
I
implemented
some
automation
so
that
when
we
have
new
version,
that's
back,
you
can
basically
run
50
code
and
it
will
update
all
the
classes
and
I
think
that's
something
that
the
Java
SDK
does
not
have
yet,
but
they
will
be
interested
in
doing
as
well.
A
So
yeah
I
was
wondering
if
that's
something
that
Is
On
Your
Horizon
as
well,
for
the
python
SDK
you
think,
or
is
it
something
that
is
auto
scope
for
you
or
is
it
something?
Maybe
we
should
try
and
find
a
common
solution
yeah
so
just
wanted
to
bring
bring
up
the
question.
I.
E
Think
that'd
be
a
great
idea,
so
I'm
not
working
as
much
on
the
Pediatric.
My
teammate
is
she
really
wanted
to
take
that
on
and
has
done
it
before
she's
an
awesome
python
developer.
So
let
me
get
the
release
in
and
then
I've
started
reading
the
go
SDK
because
that's
I'm
not
as
strong
as
go
and
that's
such
a
fun
language,
yeah
I,
would
love
to
start
implementing
that
if
that
is
kind
of
our
standard
for
our
sdks,
so
sure
that
could
be
my
next
task
after
I
get
a
release
automated.
A
Okay,
yeah
that'd
be
great,
I
think
there.
There
is
a
lot
of
value
in
having
that
because
it's
it
means
that.
Then,
when
once
we
we
work
on
a
new
spec,
we
can
just
you
know
in
a
matter
of
days
with
very
limited
effort,
make
a
new
version,
a
new
release
of
the
sdks,
as
opposed
as
if
it's
a
manual
process,
and
you
have
to
you.
A
E
I
think
that'd
be
great
and
let
me
just
I
love
automation,
but
it's
something
that
is
always
so
much
fun
to
do
so.
This
would
be
a
great
thing
that
I
would
love
to
play
with.
May
I
ask
I
know
what
like
I
said:
I've
been
out.
Is
there
balancing
the
work,
should
I
kind
of
do
50,
50
on
the
visualization
and
python
sdks
or
python
SDK
like
where
have
people
been
discussing?
If
there
has
been?
If
there
have
been
any
discussion,
then
I'll
figure
it
out
myself.
A
This
is
a
good
question
to
answer.
I.
Think
yeah.
Visualization
is
a
really
good
topic
as
well,
so
I
but
I,
don't
know
if
I
I
know
we
need
the
Java
SDK
for
for
Jenkins
and
from
Spinnaker
to
be
up
to
date.
A
I
don't
know
if
you
have
any
pressing
use
case
right
now
for
the
python
SDK.
So
if
I
add
to
choose
I
would
probably
say:
City
Event
visualization-
and
there
was
a
nice
very
nice
presentation
about
that
topic.
So
maybe
you
can
catch
up
the
recording
on
that,
but
yeah.
A
E
C
A
Cool
all
right
thanks,
so
just
wanted
to
to
show
the
the
rest
of
the
team
who
are
not
involved
in
the
discussion
on
that
zero
for
planning
what
we've
done
with
ML.
So
we
basically
set
up
a
0.4
tab
here
in
our
city
events,
releases
project
and
started
putting.
A
That
we
think
that
we
should
include
so
for
also
we
we
set
tentative
date
for
the
release.
Where
is
it
yeah
for
the
the
for
the
end
of
August,
with
the
reason
being
that's
I,
think
mid
of
September
is
going
to
be
the
diminished
Summit
in
Bilbao
with
the
open
source
Summit,
and
so
it
would
be
good
to
have
a
release
to
present
there,
and
so
we
said,
let's
put
it
a
couple
of
weeks
earlier
then
so
we
have
time
for
making
announcement.
B
A
A
We
created
this
View
and
then
we
started
going
through
everything
that
we
have
in
the
roadmap
and
we
have
done
that
and
then
everything
all
the
issues
in
the
City
events
org,
which
are
not
labeled
with
roadmap,
and
so
we
started
going
for
those
and
basically
trying
to
decide
which
makes
sense
or
feels
like
most
urgent
ones
for
0.4
and
also
doable
in
terms
of
of
time
and
so
right.
Now,
okay,
so
Administration.
A
A
Then
we
have
some
other
other
things.
Well,
maybe
some
clarification
on
the
sources
and
how
Source
field
is
used
in
the
events,
abbreviation
alignment
with
this
you
can
interoperability.
A
B
Hey
Andre,
if
you
go.
A
B
B
A
A
I
think
the
idea
is
is
to
document,
maybe
take
some.
My
hope
would
be
to
take
some
concrete
cases.
So
some
specific
cases-
let's
say
okay,
pipeline
events
generated
by
Jenkins-
what
the
source
would
look
like
passive
and
generated
by
test
Cube
what
the
source
would
look
like.
So
we
kind
of
set
some
recommendations
and
that
hopefully
gives
some
guidance
for
implementers
in
the
future,
both
of
the
producing
and
the
consuming
side.
Wow.
B
Yeah
one
thing
that
I
think
would
start
to
cut
you
off
there,
but
I
think
one
thing
that
I
think
is
crucial.
That
I
think
would
answer
everyone's
question
on
this
is,
if
you
just
had
a
diagram
of
like
Ci,
is
sending
this
event
you
know
or
to
the
event
bus.
What
is
the
source
you
know
to
show
like
what
is
the
source
in
that
regard
like
you
know
and
highlight
that
be
like
hey
the
source?
Is
this
and
it
points
to
this?
You
know
I.
B
Think
a
pitcher
would
really
help
kind
of
explain
that,
because
a
lot
of
the
times
like
when
I'm
reading
the
documentation
I'm
like
oh,
but
you
can
kind
of
like
take
it
like,
as
as
the
source
of
the
thing,
that's
calling
it
or
the
source,
like
the
thing
that
you're
calling
to
right
so
I,
think
I.
Think
just
kind
of
clarifying
that
in
in
the
image
would
be
really
really
helpful,
at
least
at
least
for
me
and
and
I
remember,
so,
to
kind
of
give
you
some
context.
B
Why
I
think
that's
important
when
me
and
a
couple
others
were
first
looking
at
CD
events.
We
actually
built
out
a
full
flow
diagram
on
a
whiteboard
to
kind
of
like
map
out
like
what
all
the
terms
meant,
and
it
wasn't
until
like
we,
we
mapped
some
things
up,
we're
like
okay.
This
doesn't
make
sense
because
of
how
this
rep
like
how
this
works
in
the
diagram
and
then
from
there.
B
We
could
kind
of
go
back
to
the
definition
and
we're
like
okay,
Source,
probably
met,
and
source
and
Target
were
the
two
that
that
didn't
make
sense
how
we
were
using
it.
And
when
we
went
to
the
when
back
to
the
definition,
we
were
able
to
reapply
that
reapply
that
def,
that
that
new
understanding
back
to
the
diagram
for
it
to
make
sense.
So
so
that's
kind
of
like
why
I'm
thinking
that
that
could
be
really
really
useful.
A
A
E
Go
ahead,
I
was
just
thinking.
This
is
great
I.
You
had
you
had
a
really
good
diagram
on
at
your
presentation
for
cdcon.
That
I
think
would
be
really
useful
where
you
were
showing
the
Jenkins
I
mean
that's
one
example,
but
I
can't
remember
which
side
it
was,
but
you
already
have
I
think
that
would
be
really
good
that
you
could
easily
just
import
that
kind
of
showed
the
flow
and
a
bit
of
the
body.
If
you
know
what
I'm
talking
about.
A
E
E
B
A
Yeah
I
was
planning
on
using
these
as
a
starting
point,
but
so
may
need
to
do
something
like
survey
days
and
maybe
zoom
in
in
different
areas
and
show
more
details
about
the
events
and
things
like
that.
So
maybe
I
should.
A
Just
reminder
for
me
to
create
an
issue,
and
there
is
also
one
item
from
area
ml,
sorry
to
Define
some
kind
of
conventions
for
the
event
names
to
mix,
make
it
user
easier
to
use
them
in
diagrams,
so
that
that's
maybe
it's
also
something
that
it's
a
good
fit.
A
The
the
other
thing
that
I
wanted
to
say
about
this
is
that
in
some
cases
there
is
a
yeah.
There
is
a
certain
degree
of
flexibility
in
what
you
can
set
as
a
source.
C
A
I'm
not
sure
how
strict
we
should
be
on
City
events
either.
Let's
say
my
example,
because
I'm
a
techno
maintainer
I'm,
always
thinking
about
techno
pipelines,
and
so,
if
I,
if
I,
have
an
event
sent
by
tecton
The
Source
could
be
protectant
instance
X
yeah
right,
but
it
could
also
be
namespace
a
from
this
tecton
instance.
So
you
can
you
can
go
as
you
know
it
could.
A
It
could
be
a
pipeline
X
from
namespace
y
from
instance
that
that
it
you,
you
can
have
different
granularity
from
the
source
and
I
think
it
depends
a
little
bit.
What
kind
of
aggregation
do
you
want
to
do
in
filtering?
So
if
you
want
to
see,
have
a
way
to
see
all
the
events
from
this
techno
instance?
But
if
you
care
about
more
granularity,
maybe
it
makes
sense
to
have
more
granular
sources
so
and
I.
B
Think
that's
where
the
confusion
stems
from,
though
I
think,
because
of
that
flexibility
and
which
I'm
not
saying
is
a
bad
thing,
but
I
think
what
we
should.
Probably,
what
might
be
a
good
idea
at
least,
is
I'm
more
for
having
strict
like
opinionated
like
this
is
the
definition
for
this
thing
and
if
you
need
more
granularity,
we
can
add
a
another
field
that
maybe
has
more
context
into
that
level
of
granularity.
B
So
that's
kind
of
like
where
I'm
at,
but
but
like
I
said
that
might
be.
This
all
might
be
solved
just
by
having
the
diagram,
but
that,
but,
like
I,
said
the
issue
when
I
was
reading.
The
definition
for
source
is
due
to
that
level
of
kind
of
ambiguity.
That
flexibility
was
what
kind
of
made
when
I
was
first
reading
it.
What
led
to
my
confusion.
A
D
A
D
Like
with
the
experience
of
Spinnaker
implementations
or
what
I've
used
the
source
is
so
the
execution
ID
with
the
URL.
So
that's
when,
like
you,
can
travels
to
the
the
pipeline
running
stage
directly.
So
that's
the
source
I
have
used
in
the
notifications.
When
you
are
sending
a
CD
event
while
creating
we
can,
we
can
set
the
execution
URL
as
the
source
so
probably
like
Ben
can,
or
someone
from
Spinnaker
can
come
in.
D
So
if
that
is
the
source
of
the
even
when
we
are
actually
ascending
from
Spinnaker,
but
one
thing
I
also
observed,
like
we
have
a
subject:
Source
also
right
like
source
and
subject
Source.
There
are
two
different
things.
D
Like
sometimes
it
can
be
similar
or
if
one
is
not
set
like
we
are
using
even
in
the
sdks
also
I
see
like
if,
if
one
is
set,
so
we
are
setting
a
similar
thing
for
the
next
subject,
source
as
well
yeah,
so
something
I
think
we
need
to
make
some
clarification
on
the
subject.
Source
versus
source.
B
If
we
can
get
rid
of
one,
that
would
be
even
better
because,
like
if
I
see
two
things
like
with
subjects
or
if
sources
already
hard
to
understand,
adding
subject
Source
on
top
of
it
is
just
gonna
make
it
that
much
more
difficult.
So
so
yeah
I,
like
I,
said,
maybe
you
know
when
you
make
the
diagram
and
you
start
to
visualize.
B
C
E
I
think
for
us
it
kind
of
comes
down
to
similar
how
I
guess
vinegar
did
it,
where
it's
a
distinct
ID
the
build
ID
where
source
is
always
unique.
It's
never
the
exact
same
Source.
If
I
remember
again,
that's
two-ish
months
ago
and
I
think
if
you
just
made
it
distinct,
always
distinct.
That
would
probably
solve
a
lot
of
this.
In
just
design
I
mean
it
removed.
The
generic
I
mean
it
can
be
generic,
but
at
the
end
of
it,
usually
at
the
end
of
the
URL.
E
You
know,
maybe
in
urban
code
deployment
or
Concords
or
even
usually,
there's
going
to
be
at
the
very
end,
the
unique
ID
or
that
build
ID
that
always
could
be
maybe
required
in
source
of
the
source
when
consuming
the
data.
So
if
we
have
Brokers,
it
doesn't
have
to
look
at
the
other
type.
You
know
you
can
parse
it
to
make
a
primary
secondary
key
to
index
it
later,
but
maybe
having
the
source
always
unique
could
be
the
standard.
I
guess.
B
Yeah
and
I'm
all
for
more
stricter
definitions,
I
think
flexibility
can
get
you
into
a
world
of
hurt
like
it.
It
seems
like
a
good
idea
at
first,
but
that's
why,
like
anytime,
you
see
a
new
language
like
getting
made
or
new
apis
they're,
actually
very
opinionated,
and
it's
usually
for
good
reason
and
I
think
you
know
not
to
say
make
it
completely
inflexible
right,
but
at
least
have
the
definitions
be
very
concrete,
like
and
and
what
everyone
was
saying.
A
Yeah,
yeah
and
I,
don't
think
the
intention
or
intention
was
never
to
specifically
be
flexible.
It's
just
as
far
as
we
got
in
terms
of
bandwidth
and
discussion
on.
A
So
we
we
started
with
what
we
we
get
from
kind
of
cloud
events,
so
we
kind
of
replicated
their
definition
to
start
with
and
and
their
definition
is
quite
Luxe,
but
I
totally
agree.
We
should
have
something
more
more
specific,
so
maybe
this
is
what
I
can
do.
Also
can
I
can
add
this
topic
to
to
the
agenda,
maybe
for
one
of
the
but
well
maybe
for
the
next
meeting
we
have
in
U.S
friendly
time
zone,
so
we
can
discuss
further
on
that
yeah.
A
Yeah
I
guess
well
probably
the
first
step
there
would
be
to
to
work
on
on
the
diagram.
But
if
any,
if
anyone
wants
you
to
take
a
go
at,
you
know
drafting
some
initial
ideas
of
what
this
we
should
try
and
you
know,
be
more
restrictive
in
which
sense
of
the
protocol
three
two
to
take
an
action
and
and
present
it
next
time.
A
B
Yeah
I
think
I
think
focusing
one
thing
at
a
time,
especially
this
is
kind
of
lower
priority.
It's
kind
of
like
under
you
know
just
getting
the
ambiguity
out
of
the
way
and
can
always
be
solved
later.
But
connecting
events
is,
you
know,
part
of
the
is
a
major
part
of
this
release
right
it's.
It
is
a
key
point,
so
I'd
rather
keep
focus
on
that.
B
But
definitely
add
this
to
you
know
somewhere
where
it's
in
the
backlog
to
you
know
so
this
doesn't
get
lost,
but
yeah
yeah,
I,
I,
think.
A
Yeah,
it's
it's!
Actually,
we
we
added
it
to
the
Milestone
0.,
that's
the
idea,
but
what
we
discussed
with
with
MLS,
that
the
reason
we
had
it
included
is
that
now
that
we're
getting
implementations,
you
know
Jenkins,
plugin
and
Spinnaker
and
test
Cube
and
we're
getting
more
and
more
tools
working
on
this.
If
we
don't
specify
this,
then
we
risk
to
get
to
a
situation
where
all
the
implementations
are
different.
E
A
Okay,
well
I
think
this
is
I
was
really
really
useful
discussion
on
this
topic.
So
thanks
for
that,
we
only
have
four
minutes
left
I,
don't
think,
that's
enough
time
to
to
have
a
look
at
the
issues
now,
but
I
just
wanted
to
show
you
at
least
the
list.
A
So
if
you
have
a
chance
to
review
this
list
of
line-
and
you
see
things
that
you
care
about-
that-
you
think
that
should
be
part
of
0.4
yeah,
please
like
them
or
bring
them
up
at
the
meeting
next
time,
and
we
try
and
we'll
we'll
try
and
include
them
in
there
in
the
plan
for
the
next
few
days
or
for
them
the
one
after
that.