►
From YouTube: CNCF Serverless Working Group 2020-08-13
Description
CNCF Serverless Working Group 2020-08-13
A
B
A
Okay,
all
right
yeah,
but
the
sdk
so
every
other
week
and
then
next
week
is
the
kubecon
europe.
Are
we
going
to
have
it
because
of
that?
Also.
B
That
is
one
of
the
questions
I
have
on
the
agenda
is:
do
we
want
our
cost?
Next
week,
cool
yep.
B
Yeah,
I
know
you
know:
there's
no
filter,
hey
vlad,
hey
doug,
hey,
hey,
jinger,.
E
F
B
Actually,
I'm
probably
gonna
get
myself
in
trouble,
but
what
the
hell,
so
you
know
how
scott's
continually
nagging
me
about
using
the
word
guys
right,
I
I
noticed-
and
I
don't
know
if
you've
noticed
this,
but
in
the
c
and
cs
slack.
If
someone
uses
the
term
guys
as
a
bot
that
will
slap
your
wrist
and
it's,
I
just
think
it's
kind
of
amusing
and
someone
actually
went
out
the
way
to
create
a
bot.
For
that
thing.
B
I
just
thought
it
was
amusing
and,
as
far
as
I
could
tell
it,
actually
pastes
a
link
to
different
articles
that
talk
about
why
it's
bad
to
use
the
term
right,
and
I
don't
know
how
many
different
articles
they
point
to
I've
noticed
at
least
two
different
ones.
It
points
to.
I
just
just
these
kind
of
things
amuse
me
is.
B
H
B
B
See
actually,
I
would
think
y'all
actually
could
be
offensive
to
people,
because
are
you
making
fun
of
southerners
right?
I
mean
it's
definitely
a
southern
term.
Yes,
absolutely
so
anyway,
we
could
go
so
many
places
with
this
conversation.
So
maybe
we
shouldn't
craig.
Are
you
there.
B
Hello
is
this
your
first
time
on?
I
can't
remember
if
we've
seen
your
ad,
I
might
have
joined
once
a
couple
back,
but
it's
been
a
while
so
looking
to
kind
of,
join
and
see
what's
going
on
in
the
community,
okay
I'll
look
later
and
see,
if
I
have
your
company
affiliation,
if
not,
you
may
want
to
add
that
in
there
mark
are
you
there?
B
B
B
B
B
All
right
couple
of
housekeeping
activities,
so
for
those
of
you
who
have
forgotten
next
week
is
kubecon.
We
are
currently
signed
up
for
three
different
activities,
at
least
from
the
cloud
event
side
of
things.
We
have
a
booth
at
3,
30
european
time
and
on
thursday,
at
1
15
european
time.
B
Looking
for
volunteers
to
I
know,
that's
both
those
times
are
going
to
be
really
challenging
for
west
coast
people.
Let
me
just
in.
Let
me
just
look
at.
B
Virtual
cubecon,
and
what
would
the
volunteers
have
to
do
so?
I
okay,
so
jinger
help
me
out
here
because
I
think
you
might
not
know
more
than
me,
but
I
believe
it's
basically
joining
a
zoom
call
potentially
having
a
presentation
ready,
not
necessarily
to
present
the
presentation
but
to
talk
to
it.
If
you
would,
if
that
would
help
you
in
your
conversations
with
people
who
joined
the
zoom,
call
to
ask
questions
about
cloud
events.
Is
that
a
fair
summary
jinger?
You
think.
H
Yes
and
they
can
be
whatever
you
want
them
to
be,
frankly,
it's
45
minutes
for
a
session
and
it's
open
for
any
of
the
kubecon
folks.
So
it's
just
like
having
a
maintainer's
booth,
but
it's
virtual.
So
if
you
want
to
present
something
or
show
a
demo
or
something
and
then
take
questions
or
whatever
that's
totally
up
to
you,
guys.
D
B
J
How
do
we,
how
do
we
get
access
to
those?
I
don't
know
yet
to
be
honest,.
H
I
I
actually
asked
this
yesterday
because
I
thought
maybe
I
missed
it.
The
information
I
got
was
they'll
be
sending
out
the
zoom
link
in
the
coming
days
is
the
only
thing
they
said.
No,
it
starts
monday,
so
it
better
be
soon.
L
Last
night
say
it
again:
sky.
I
got
my
email
last
night.
It's
there's
a
bunch
of
links
and
there's
a
bunch
of
rooms
on
the
cloud
native
slack.
M
B
B
I
mean
that's
right,
not
coupon
cod
native
coupon
cloud
events,
so
I
think
I'm
900
sure
those
channels
have
a
one-to-one
relationship
with
like
working
groups
and
stuff.
L
F
L
B
B
Thank
you
very
much,
okay,
so
the
other
thing
is
not
anybody
needs
to
do
anything,
but
we
do
have
the
cloud
event
session
itself.
I
assume
clemens
that
time
is
good
for
you
to
answer
questions
with
me
right.
Absolutely,
it
is
yep.
Yes,
oh
boy,
you
sound
excited,
okay,
okay.
Obviously
anybody
else
is
free
to
join
if
you
want,
but
it's
not
required,
like
the
booths.
B
You
know
I
have
to
have
other
people
there
clemens,
and
I
will
definitely
hang
on
that
one
for
sure,
since
we
are
I'm
sorry
what
it's
a
great
talk
too,
it
is
an
excellent
talk.
Yes,
we've
been
one
of
our
better
ones:
okay,
any
other
questions
or
comments
relative
to
the
booth
or
the
session
before
we
move
forward.
B
Okay.
Now
the
next
question
is:
do
we
want
to
have
our
calls
next
week?
I
may
be
wrong,
but
I'm
pretty
sure
none
of
these
sessions
at
kubecon
that
we're
doing
anything
with
overlap
with
our
regularly
scheduled
calls
so
like
we
can
technically
have
a
call
next
week
and
in
fact,
and
the
sdk
call,
but
if,
for
some
reason
people
feel
like
they
don't
want
to,
because
they're
really
busy
with
kubecon
activities
and
other
sessions,
they
want
to
attend.
B
B
Okay,
we
shall
do
so.
Thank
you,
everybody
all
right,
just
a
reminder.
Before
september
13th,
we
need
to
decide
if
we're
going
to
have
a
maintainer
session
for
cloud
events
or
serverless.
B
If
you're
interested
in
speaking,
please
reach
out
to
me,
do
not
be
shy
and
do
not
feel
like
you
have
to
have
a
ton
of
experience
or
anything
or
even
that
deep
knowledge
of
this
stuff,
just
if
you're
willing
to
talk
okay,
definitely
looking
for
other
people
to
speak
up
besides
the
regular
folks,
because
we
want
to
make
this
open
to
everybody
and
give
everybody
the
opportunity
to
talk
or
present
if
they
want
to
all
right,
give
us
a
reminder.
We
will
not
have
an
sdk
call
after
this
one.
B
This
week,
however,
we
will
have
a
discovery.
Interop
implementation
call
right
after
this
one.
Whenever
this
one
ends
okay,
timor,
anything
you
want
to
mention
relative
to
the
workflow
stuff
or
anything
going
on
with
kubecon.
K
Well,
yeah,
I
mean,
if
you
guys,
find
any
information
about
the
booth
stuff.
Please
include
me
in
that
as
well,
because
I'm
kind
of
clueless
completely
of
what's
happening
with
that,
but
other
than
that
yeah
just
preparing
for
kubecon.
As
far
as
specification
goes
we're
looking
at
unstructured
or
ad-hoc
processes
just
to
see
if
they
make
sense
and
also
some
sort
of
security
with
jason
webb
token.
K
So
if
anybody
here
has
any,
you
know
experience
with
jwt,
I
highly
appreciate
some
input
and
other
than
just
trying
to
figure
out
when
we
can
do
a
next
release
of
the
specification.
C
Yes,
he
talked
a
lot,
as
I
mentioned
the
last
time.
The
schedule
on
the
same
set
of
public
event
calendar
shows
the
the
service
workflow
is
still
bi-weekly
at
5
00
pm,
which
is
wrong.
I
guess.
B
K
I
looked
into
that.
Thank
you
so
much
and
thanks
for
yeah,
I
look
and
I
looked
in,
that
it
is
bi-weekly.
We
changed
that
recently
from
a
monthly
to
a
bi-weekly
reading,
so
I
think
that
is
correct.
The
time,
however
I'll
check
on
it,
because
when
I
look
in
the
calendar
looking
at
eastern
time,
it
looks
correct,
but
if
it's
wrong
oh.
K
C
C
C
N
K
K
B
B
All
right,
pagination,
so
again,
I
apologize
last
week
for
not
pushing
us
up
before
last
week's
phone
call,
but
I
don't
think
I
made
any
changes
since
I
did
update
it.
I
guess
the
only
thing
I
wanted
to
add
was
so
last
week's
I
think
was
last
week's
call.
B
We
had
a
very
very
brief
conversation
about
things
like
whether
we
should
use
offset
versus
next
versus
index
and
that
kind
of
things-
and
I
apologize-
I
completely
forgot
that
the
use
of
those
query
parameter
names
is
actually
implementation
specific
and
this
this
specification
actually
doesn't
mandate
what
you
use
it's
completely
up
to
the
server
side,
to
decide
what
query
parameters,
or
even
entire
shape
of
the
url
to
use
to
represent
the
next
chunk
of
data.
So
we
don't
actually
tell
people
what
they
do.
The
only
thing
we
do
specify
is
the
link.
K
B
Attributes
and
let's
show
an
example
of
how
they
appear,
so
they
appear
like
this
right,
so
we
say
you
have
to
have
a
link
and
you
have
to
use
the
link
header
and
then
you
have
to
have
to
have
the
url
followed
by
a
rel,
and
we
do
specify
or
point
to
a
document
that
says
next
and
previous
and
what
those
things
are
defined
as
but
in
terms
of
the
actual
values
in
here.
That's
completely
up
to
the
implementation,
decide
what
to
do
all
right,
so
you
can
do
whatever
you
want.
B
B
B
We
are
planning
on
doing
a
vote
on
this
one
today
unless
there
are
major
objections
or
major
issues,
people
find,
but
this
has
been
out
there
for
a
while,
and
we
did
talk
about
this
on
the
sdk
call
last
week
and
we
did
agree
that
we
do
want
to
have
something
at
a
global
level
across
all
sdks.
But
then
sdks
themselves
could
have
specific
tweaks
to
the
process
if
they
want
in
their
own
repo,
but
we
thought
it'd
be
good
to
have
a
high
level
process
across
all
of
them.
N
Well,
I
think
you
already
said
everything
I
just
that
on
the
initial
draft
I
may
I
brought
some
more
stricter
requirements,
but
then,
after
both
the
meeting
last
week
and
the
slack
discussions,
I
end
up
making
those
requirements
more
soft,
but
then
I
say
that
in
theory
sdks
themselves,
the
projects
themselves
can
decide
to
develop
more
stricter
requirements.
Atu
it's
not
specified
how
the
sdk
should
develop
those
structure,
requirements
right.
B
B
Yeah
and
give
everybody
on
the
call
just
30
seconds
or
so
just
to
look
this
over,
since
that
is
a
little
bit.
B
Excellent,
thank
you,
everybody
and
thank
you
slinky
for
your
patience
on
that.
Okay,
I
believe,
let's
skip
these
two
for
a
second,
let's
jump
down
to
the
third
one
jason's
streaming
proposal,
I
believe
on
last
week's
call.
We
were
asking
people
to
go
back
to
their
respective
organizations
to
see
if
there's
any
interest
in
this
json
streaming
thing.
Did
anybody
do
that,
and
would
anybody
like
to
speak
up
in
terms
of
what
they
may
have
discovered
or
found
out.
A
L
And
you
know
my
findings
still
stand
the
data
big
data
people
are
interested
in
this
kind
of
use
case
for
cloud
events,
because
they
like
the
the
fact
that
the
payload
is
decorated,
but
it
needs
to
come
in
faster
than
what
http
requests
can
do
and
batching
isn't
quite
the
right
thing,
so
they
would
like
some
sort
of
streaming
solution.
That's
cloud
event
based.
B
N
I
don't
remember
it.
I
think
there
was
some
discussion
around
what
should
be
the
record
separator
and
I
and
I
proposed
the
rslf,
which
is
an
rfc.
The.
N
There
is
another
topic
which
I
didn't
really
explored
is
that
we
might
make
this
compatible
one-to-one
with
server
sent
events,
but
server
sent
events
uses
a
new
line
for
echo
card,
so
maybe
this
is
worth
investigating.
I
don't
know
okay,
I
mean
for
me
it's
fine.
This
one
rslf
for
me
is
fine,
but
if
we
want
to
experiment
to
look
for
supporting
one-to-one
server,
sent
events
from
w3c.
B
Then,
okay!
Well,
it
seems
to
me
that
most
people
probably
have
not
given
this
a
whole
lot
of
thought.
So
I'm
a
little
bit
nervous
about
trying
to
do
some
sort
of
deeper
dive
discussion
right
now
and
I'd
rather
save
it
for
next
week.
So
people
can
go
off
and
you
know
review
this
as
a
homework
assignment.
Is
that
okay,
with
you.
D
And
so
I'm
wondering
so
there
are.
There
are
ways
to
do
this
with
http
hp2.
If,
if
you
want
to-
and
that's
like,
if
you
look
at
how
aws
kinesis
is
doing
its
its
delivery
of
multiple
events,
then
that's
something
to
look
at,
but
that
is
an
http
2
feature.
But
then,
if
you
really
want
to
have
streaming
of
of
json,
then
we
can.
D
Then
I
think
the
cleaner
way
is
to
say
we're
going
to
do
a
websocket,
binding
and
use
websocket
text
frames.
If
we
really
want
to
have
a
streaming
streaming
model
so
either
have
either
have
a
feature
that
explicitly
binds
to
hdb2,
and
I
just
didn't
have
my
glasses
on.
Oh
so
scott
said,
http
2
is
funny.
I
know
where
that
comes
from.
D
Or
we're
going
to
do
a
websocket
or
we're
going
to
do
both
because
http
2
obviously
is
incompatible
with
websockets,
but
but
instead
of
instead
of
doing
hackery
around
the
the
http
delivery
model,
I
would
basically
drip
just
drop
down
to
the
respective
transports
that
are
optimized
for
that
particular
use
case.
Because
that's
why?
Arguably
why
websocket
text
frames
exist
and
that's
also
why
this
this
eventing
feature
in
http
2,
exists
and
and
use
those.
L
I
have
a
moderately
popular
app
that
that
uses
websockets
to
stream
cloud
events
out
of
kubernetes
yeah,
and
that
seems
to
be
a
very
natural
match
yeah
I
I
would
love
like
an
actual
spec
to
follow
right
now,
I'm
just
pushing
new
line,
delimited,
json,
blobs
and
and.
D
They're,
if
you
drop
down
one
layer,
they're
like
pretty
much
every
websocket
protocol
allows
you
to
go
and
send
frames
like
this
distinct
frames
with
their
label
text
and
then
websockets
actually
does
all
the
the
limit,
the
delimiting
for
you,
where
you
don't
have
to
go,
do
any
parsing
at
all.
Oh,
that's!
Really!
D
Cool
yeah
I'd
love
to
explore
that
because
I
think
that's
the
cleanest
way
to
do
this,
where
you
really
want
to
have
a
torrent
of
of
events,
and
you
want
to
like
if
you
wanted
to
do
a
stock
ticker
with
that's
the
popular
example.
That's
why
I'm
mentioning
that.
So
you
you
connect
to
a
website,
and
the
website
is
a
stock.
D
It
has
a
stock
ticker
and
now
the
stock
ticker
wants
to
go
and
give
you
a
stream
of
events
that
you
can
then
go
and
dispatch
on
your
on
your
ui
and
you
want
that
to
be
to
be
cloud
events
then
using
websockets
is
exactly
the
right
tech
to
use
and
the
text
frames
are
exactly
there
so
that
you
don't
have
to
do
the
parsing.
N
D
I
mean,
but
everybody
supports
websockets
by
now,
like
the
there's
all
the
browsers
to
have
it
and
well,
the
browser
has
it
and
most
of
the
web
frameworks
support
websockets.
So
that's
that's
a
pretty
pervasive
thing.
Http
2,
I
agree,
is
something
that
is
more
like.
N
O
N
B
I'm
finally
exploring
that,
okay,
so
in
terms
of
next
steps
on
this
particular
issue,
it
sounds
like
we
may
choose
to
close
it.
Are
you
volunteering
francesco
to
to
open
a
pr
for
a
websocket,
binding.
N
B
You
meant
okay,
scott
scott
agreed
with
you
to
the
to
the
chat
so
yeah.
B
N
B
D
Well,
the
great
thing
is
that
websockets
already
have
has
that
with
you
define
the
we
will
define
here,
the
cloud
event
sub
protocol
and
the
so
protocol
negotiation
of
what
you
want
to
pick
up
is
already
in
in
web
sockets.
D
The
the
server
so
when
you
do
the
the
initial
so
there's
always
an
initial
discovery
request
you
effectively
do
a
get
on
the
on
the
server
and
that
will
tell
you
what
sub
protocols
it
supports
and
then
you're
going
to
be
offering
the
upgrade
so
there's
a
whole
there's
a
whole
handshake
that
everybody
does
so,
for
instance,
if
you're
using
inquiry
or
mqpt
with
websockets,
you
always
start
with
with
a
regular
http
request
and
then
the
server
says
hey.
I
can
also
speak
npp
and
then
you
go
and
upgrade.
N
I
I
wonder
if
we
can
maybe
a
misunderstood,
but
I
wonder
if
we
can
take
the
existing
web
book.
Spec
and
kinda
do
the
protocol
negotiations
in
there.
That's,
I
think,
that's
different.
That's
different!
Okay,
okay,
okay,.
D
I'm
still
trying
to
understand
that
yeah,
the
webhook
spec
is
really
just
for
delivering
events
kind
of
in
the
push
fashion
to
to
to
a
target,
and
this
is
really
here
a
a
way
to
establish
a
websocket
and
have
a
particular
a
particular
way
of
how
the
websocket
is
being
used,
which
is
we're
putting
we're
putting
a
cloud
events
into
into
the
text
frames.
D
And
that
might
actually
be
bi-directional,
because
there's
no
there's
no
reason
not
to
constrain
to
to
constrain
that
I'll
I'll
write.
An
email.
D
I'm
just
trying
to
I'm
just
I'm
having
a
schedule
problems
I
will
try.
I
will
try
to
make
it
to
to
summarize
this
mechanism
until
next
week.
D
Okay,
great
cool,
so
so
we
can
basically
just
to
educate
and
get
get
us
all
on
the
same
on
the
same
level,
and
then
we
can
decide
who
really
picks
up
the
pen.
So
I'm
not
going
to
write
a
draft
spec
with
the
most
of
the
shoulds,
but
I'm
just
going
to
try
to
summarize
in,
like
a
page
of
of
what
the
of
how
that
works
with
the
sub
protocol
stuff.
N
D
That
will
relatively
make
it
relatively
simple
to
go
and
implement
all
this
where
you
and
nobody
has
to
go
and
drop
down
to
the
to
the
wire
level
anymore,
to
go
and
realize
any
of
those
things,
but
to
have
a
formal
spec.
We
we
still
need
to
go
and
define
how
that
actually
happens
down
at
the
wire.
So
I
just
want
to
make
sure
that
we
have
both
those
things,
even
though
we're
we're
all
going
to
use.
Ultimately
we're
going
to
use
some
existing
pre-existing,
build
clients
for
this.
B
All
right
cool
all
right,
any
other
top
any
other
discussion
points
about
these
two
pr's
or
how
we're
done
yet
to
come
pr.
B
B
I
was
going
to
do
last
night,
which
is
scott,
opened
up
a
syntactical,
typo
type
issue
to
me,
and
I
wanted
to
see
if
we
can
just
get
that
out
of
the
way,
even
though
it's
under
the
two-day
limit,
I
figured
it
said
since
it's
just
typo,
we
can
do
that.
You
notice
that
we're
missing
the
required
protocol
field
in
the
sample
service
output,
so
I
think
that's
a
no-brainer
right
there
and
then
the
other
commits
is
just
he
did
a
random.
B
L
B
B
E
B
L
Yeah,
I
just
there's
a
hole
in
the
spec
around
the
callback
and
the
secret.
I
think
if
this
has
been
months,
but
I
don't-
I
don't
understand
how
to
do
the
out-of-band
get
but
also
deliver
whatever
secret.
There
was
supposed
to.
D
L
D
So
so
this
so
the
get
with
the
browser
client,
you
mean
yeah.
L
D
So
there
is
a
there's
a
for
if
you,
if
you
simply
have,
if
you're,
simply
building
a
website-
and
this
is
not
too
uncommon,
so
you're
building
a
website
with
the
simplest
possible
mechanisms.
D
It
is
possible
to
go
and
grab
affected
the
url
from
the
log
and
then
simply
do
a
a
confirmation
request
against
that
endpoint,
with
the
browser
to
sidestep
having
to
go
and
and
do
a
complete
implementation
of
that
handshake.
L
L
J
Was
doing
that
yeah?
Can
you
send
it
assign
that
to
me
and
I'll
take
a
look
at
that
and
I
have
to
think
about
this.
B
D
D
We
have
such
a
crazy
torrent
of
notifications
on
github
that
it's
like
the
pings,
and
I
can't
see
any
of
those
things
really
interesting.
Okay,
because
it's
just
too
much
I'm
enrolled
in.
I
don't
know
how
many
reposts
that
I
have
nothing
to
do
with,
but.
D
B
Okay,
so
we
resolved
that
one
that
one
okay,
so
scott.
Actually
let
me
ask
a
question.
Scott
opened
up
these
issues.
I
think
it
was
just
as
soon
as
yesterday
and
obviously
their
issues
are
not
pr,
so
there's
nothing
to
necessarily
vote
on
or
anything,
but
were
there
other
topics
people
wanted
to
bring
up
before
we
get
into
these.
B
Well,
I
kind
of
want
to
do
it
here
because
I
think
the
discovery
call
is
more
about
implementation
details
and
I
pulled
out
these
two
specifically
because
I
thought
these
were
more
spec,
related
questions
and
worthy
of
a
broader
discussion,
or
at
least
to
start
the
discussion
going.
If
that's
okay
got
it
yep,
I'm
ready.
L
Sure
I
I
am
in
in
implementing
this
in
looking
at
what
the
api
does.
I
think
that
the
types
endpoint
is
sort
of
out
of
place.
L
It's
because
it's
a
I
like,
I
say
it's
a
projection
of
the
data
in
the
services
web
hook.
It
strikes
me
as
slightly
unrestful
because
there's
two
ways
to
get
the
data
through
two
collections
and
when
you
do
do
the
aggregation
around
types
for
the
query.
You
group
services
that
have
similar
types
but
possibly
they're
completely
unrelated,
like
if,
if
two
producers
make
a
create
event,
one
is
a
pr
and
one
is
a
database
record
like
it,
doesn't
make
a
ton
of
sense
to
group
those
things
next
to
each
other.
L
So
my
proposal
is
to
drop
the
whole
endpoint
entirely
and
just
maybe
add
some
more
filtering
capabilities
on
service
endpoint.
So.
B
L
It
looks
like
a
specific
use
case,
convenience
method
versus
something
that's
required
for
the
implementation
and
I
think,
there's
nothing
that
stops
anyone
from
implementing
their
own
version
of
this.
But
I
I
don't
feel
like
it
belongs
in
the
specification.
B
Okay,
all
right
anybody
having
kristoff
you're
off
to
you.
Do
you
have
a
question
or
comment.
G
Yeah,
yes,
I
think,
but
maybe
we'll
discuss
even
more
after,
but
what
scott
said
I
think
he's.
I
do
understand
his
point
of
view,
but
in
that
case
even
the
pagination
should
be
out
of
that
spec,
because
that's
also
kind
of
selecting
some
implementation
on
the
side.
But
it's
hard
to
set
the.
Where
is
the
limit
between
the
norm
and
the
implementation
by
itself?.
L
Yeah,
it's
it's
an
interesting
point
right
like
I.
I
do
kind
of
feel
weird
about
defining
this,
an
api
in
specification
where
we
might
get
away
with
possibly
just
defining
the
payload
shape
so
that
we
can
serve
this
data
through
other
means
too,
not
just
restful
apis
kubernetes
right.
B
Well,
there's
nothing
stopping
us
from
separating
these
specs
out
right
having
a
http
rest
binding
for
the
core
spec,
which
I
think
I
think
would
just
it's
just
once,
at
least
in
my
mind,
it's
just
one
document
now
for
convenience.
It
may
split
later.
This
was
the
way
I
interpret
it.
I
think
I
think
the
overall
question
you
raised
scott.
That
was
something
we
needed
to
discuss
is:
do
we
want
to
have
more
than
one
way
to
get
back
the
list
of
services
right
because
we
have
the
to
do.
B
We
have
the
slash
services
endpoint
and
we
have
the
slash
types
and
they
return
very
similar
data
other
than
the
type
1
is
now
grouped
by
type,
and
I
believe
we
have
this
conversation
in
the
past,
where
people
thought
that
it
was
more
friendly.
Maybe
maybe
the
right
word
mushrooms
are
to
have
a
have
a
types
thing
as
the
searching
mechanism
for
types,
so
this
felt
whoops.
B
L
B
L
Yeah,
I
think
that's
right.
We
would
get
services
listed
and
have
an
additional
filter
of
of
some
sort
of
type,
and
we
can
determine
some
sort
of
fuzzy
matching
right.
L
B
O
Don't
wanna,
so
do
you
hear
me?
Yes,
I
do
go
ahead.
Okay,
so
don't
wanna
throw
the
conversation
off
track,
but
have
we
ever
considered
discovering,
based
on
any
arbitrary
attributes,.
O
L
Yeah,
that's
that's
exactly
where
my
mind
went.
I
think,
defining
this
types
and
the
pivot
table
around
type
value
to
service
mappings
is
cute
for
one
case,
but
I
assume
that
someone's
going
to
want.
L
B
O
Okay,
so
scott,
are
you
the
one
focusing
on
this
one
right
now?
If
you
want,
I
can
spend
some
time
with
you
working
on.
It's
certainly
something
I'm
interested
in
working
on.
B
G
For
me,
if
I'm
vocal,
it's
just
that,
I'm
still
trying
to
figure
out
where
it
goes,
we're
all
discovering
stuff.
So
I
don't
have
a
strong
opinion
in
either
direction.
B
Okay,
well,
we
have
time
to
think
about
it.
We
all
do
pr's
not
there
yet
so
we'll
see.
B
Okay,
in
that
case,
the
other
issue,
I
thought,
was
worthy
of
a
discussion,
even
though
it
doesn't
seem
like
it'd,
be
a
very
big
issue.
It
actually
kind
of
is
to
me
scott.
You
want
to
talk
about
this.
One.
L
Yeah
sure
so
the
at
the
moment
we
have
services
types
which
is
an
array
of
of
these
type
objects
and
internally,
the
type
object
claims
its
name
by
calling
itself
type
which
in
most
modern
apis
when
you
get
down
to
the
the
actual
object
that
talks
about
itself
it
it
says,
like
hey,
I'm
my
name
is
this?
Not
my
type
is
this,
so
I
think
that
type
that
is
highlighted
there
should
actually
be
called
name.
So
it's
name
and
description,
and
that
refers
to
the
type
object
of
the
cloud
event
type.
B
An
identity
comment
in
the
issue.
I
think
I
think
the
reason
we
went
this
direction
was
because
this
is
the
way
it
would
appear
inside
the
kataban
attributes.
The
same
way
all
these
would
appear.
I
believe
this
way
at
least
the
the
ones
that
do
line
up
with
cloud
events
like
data
schema
and
so
like
that
interesting
enough,
I
guess
yeah
these
these
two
anyway
right.
B
So
the
question
there
and
to
me
is
abstractly.
I
think
I
agree
with
you.
Scott
name
makes
a
lot
of
sense.
It's
just
from
the
consistency
perspective.
Would
people
prefer
to
see
type
here
and
then
type
is
what
appears
inside
the
cloud
event.
That's
the
only
thing
that
would
that
was
right
through
my.
K
P
Not
a
good
one,
I
thought
that
the
consistency
argument
held
a
little
weight.
I
liked
it.
My
kid
also
was
up
and
down
all
night
and
screaming
it
has
to
come.
So
I'm
not
totally
here.
B
That's
a
good
excuse.
I
like
that.
Okay,
anybody
else
want
to
chime
in
lance
as
it
has
an
sdk
gut
person.
You
may
have
some
thoughts
on
this
one.
M
B
Okay,
well,
I
picked
on
two
people.
That's
that's
my
quota
for
the
day
anyway.
Think
about
it.
Obviously,
it's
not
a
huge
pr,
but
it
is.
I
do
think
it's
kind
of
an
important
one,
because
it
it
does
kind
of
impact,
the
the
ux
side
of
things
slightly,
potentially
good,
potentially
bad.
Depending
your
point
of
view.
L
It
I
mean
the
the
name
of
the
cloud
event
attribute.
That's
interesting.
I
haven't
thought
about
that,
but
it
also
doesn't
apply
to
most
of
these
attributes
like
description,
schema
type,
schema,
content
and
extensions,
don't
apply
so
what
we're
really
talking
about
is
type
data,
content
type
and
data
schema
match
up,
but
the
rest
of
them
are
oddballs,
so
totally
true
and
then
in
up
up
above
service
has
name.
M
L
L
L
B
Yeah
something
to
think
about,
I
don't
know
okay
well,
anyway.
Everybody
please,
please
think
about
this
one.
I
do
think
we
should
probably
have
a
discussion
next
week.
I
don't
know
scott
if
you,
whether
you
want
to
wait
or
create
a
pr
or
not,
but
either
way
people
please
think
about
it.
B
B
E
Yeah,
I'm
here,
but
I
you
know
honestly,
there's
just
been
there's
been
a
lot
of
developments
in
the
service
serverless
world
this
week
and
I
was
just
dialing
in
to
see
whether
or
not
y'all
were
talking
about
them.
That's.
B
B
Okay,
cool
manuel.
B
B
A
B
So
trying
to
think
about
we're
going
to
talk
about
scott.
Let
me
pick
on
you
since
you're
the
latest
entry
into
the
implementation
side
of
things.
Is
there
anything
from
your
perspective
that
you'd
like
to
bring
up
aside
from
the
issues
that
you
opened,
or
I
guess,
if
you
want
to
talk
about
those
issues,
we
can
talk
about
those
too.
B
Right
was
there
anything
in
the
spec
that
you've
come
across
so
far
that
just
I
I
I
know
you,
you
noticed
lots
of
things
in
there
or
a
couple
things
in
there
anyway.
They
all
don't.
They
seem
relatively
minor.
So
far,
right
dude,
I
hadn't
you
didn't
raise
some
huge
objection
to
the
spec
in
general.
Is
that
a
good
sign,
or
do
you
think
you
just
haven't
gone
far
enough
along
yet
to
know
whether
this
is
a
piece
of
crap
and
we
need
to
revisit?
You
know
the
chord
design.
L
No,
I
don't
think,
there's
anything
majorly
wrong
with
it.
The
one
big
question
I
do
have
is
around
the
actual
rest
interface,
and
I
like
the
fact
that
we're
trying
to
define
what
the
payload
means
I
I
want
to
make
sure
that
there's
a
room
enough
to
implement
this
thing.
As
a
like,
a
crd
based
kubernetes
thing,.
A
L
B
Okay,
I'd
like
to
talk
more
about
that
at
some
point,
but
let's
get
to
the
other
stuff
first,
so
in
terms
of
moving
forward
here,
has
anybody
have
given
any
thought
to
how
we
might
do
some
sort
of
interop
testing
or
something
along
those
lines.
B
How
do
you
see
that
playing
out
from
a
client
perspective?
Is
it
is
it
then?
Each
person
would
like
maybe
write
their
own
client
and
talk
to
the
different
options
in
terms
of
end
points
like
they
talk
to
the
base
one
and
then
talk
to
the
aggregate
one
and
make
sure
they
get
the
same
information
type
stuff.
Had
you
given
each
link.
J
B
I
wonder
if
you
get
it's
like
you'd
have
to
it'd
be
kind
of
interesting.
If
you
actually
did
that
right,
where
maybe
each
one
only
added
like
a
couple
of
things
to
the
picture
and
after
a
while,
would
they
all
end
up
having
the
exact
same
set
of
data,
because
they
all
sort
of
synchronize
with
each
other.
L
Yeah,
the
I
think
the
chain
would
all
harmonize.
B
Yeah,
that
would
actually
be
kind
of
a
cool,
little
exercise
and
then
have
a
client
hit
every
single
guy.
You
know
or
every
single
point
in
the
ring
and
make
sure
they
all
return
the
same
data.
But
everybody
starts
out
with
different
data.
That'd
be
kind
of
cool.
L
The
code
that
I
wrote
is
is
a
very
super
basic
implementation,
just
reading
the
spec
and
writing
some
go
code.
It's
not
a
ton
of
lines
of
code
and
not
totally
not
intended
to
be
like
a
library
that
you
host
some
stuff
out.
I
was
just
reading
the
spec
trying
to
make
sure
it
makes
sense
to
me.
B
Well,
I
I
I
don't
know
whether
it's
goofy
or
not,
but
I
actually
really
like
this
idea
of
this
circular
thing
and
seeing
whether
they
all
sort
of
get
individual
con
a
consistency
state
across
all
of
them
right,
because
that
would
test
things
like
the
id
stuff
and
then
enter.
If
we
introduce
the
notion
of
well,
one
of
them
is
going
to
update
their
list
and
if
you
get
everybody
say
30
seconds
or
so
you
know
does
that.
Does
that
change
get
propagated
everybody
accordingly
and
then
you
know
delete
something.
L
Was
it
a
pr
or
an
issue
around
some
discovery,
changes
for
watch.
B
B
B
And
grant
just
to
pick
on
you
for
a
sec
in
case
you
joined,
hoping
to
do
the
sdk
call
we're
not
having
one
this
week.
It
would
be
it's
gonna
be
next
week
in
case
you
joined
for
that.
I
B
L
It
what
clemens
proposed
is
that
the
services
emit
cloud
events
based
on
changes
which
could
work,
that's
a
push
model.
I
was
looking
for
more
of
like
an
active
watch
model,
but
it's
interesting
that
would
that
would
definitely
do
what
we're
trying
to
do.
B
Yeah
well,
this
I
think,
what's
neat
is
this
circular
thing
could
help
reinforce
the
notion
of
whether
we
need
one
or
the
other
or
or
both
type
of
thing,
because,
as
part
of
the
scenario,
if
we
describe,
if
we
defined
it
as
one
of
the
one
of
the
guys
in
the
chain,
update
something,
how
does
everybody
else
find
out
about
it
right?
We
need
to
answer
that
question
and
this
would
be
a
good
way
to
force
it
or
force
that
discussion.
B
I
like
it
now
scott,
since
you
volunteered
for
some
stuff
earlier
today,
unless
someone
else
wants
to
chime
in
there,
I
wouldn't
mind
taking
a
first
step,
writing
up
a
very
rough
outline
of
what
this
scenario
doc
would
look
like
sure,
okay,
anybody
else
want
to
volunteer.
I
don't
mind
handing
out
somebody
else,
but
I
also
don't
mind
doing
it
myself.
A
I
actually
have
a
random
question:
doug
is
there
previous
details
on
the
discovery
spec.
A
A
I'm
actually
in
the
wrong
location,
never
mind
okay,
so
I
was
looking
at
a
different
segment
of
this
cool.
Thank
you.
Yep.
B
L
B
L
Well,
so,
let's
say
that
you
have
that
chain
situation
and
the
source
of
truth
updates
their
their
event,
but
then
they're
informed
by
the
the
their
other
ring
member,
that
the
source
of
truth
that
they
think
is
true,
is
now
coming
in
as
stale
data.
So
like
do,
maybe
we
need
like
a
resource
version
on
those
things
like
or
a
version
number
to
to
understand
what
like,
which
one
should
win
if
it.
L
B
I'm
trying
to
understand
how
that
would
happen,
so
in
in
your
mind,
do
you
see
one
node
in
this
chain
having
multiple
inputs
or
just
a
single
input?
So
it's
just
a
single
linked
list
or
circular
linked
list.
I
well
in
the
simple
case.
L
There's
just
a
circle
and
there's
three
entities
right,
if
so,
a
b
and
c,
if
a
is
a
source
of
truth
for
the
a
event
and
it,
but
it's
also
watching
for
changes
on
c
a
changes.
The
a
event
and
c
provides
the
previous
version
of
a's
a
event
to
a
now.
A's
job
is
to
go
in
and
merge
that
data
into
its
data
set.
So
how
does
it?
L
L
B
Yeah,
that's
this
almost
sounds
like
it's
getting
to
the
whole
category
of,
I
don't
say
a
new
spec,
but
it
definitely
is
a
section
in
respect
that
talks
about
how
to
do
this.
Aggregation.
L
Right,
yeah:
well,
it
could
be
as
simple
as
a
resource
version
or
or
a
version
number
right
like
or
an
updated
event.
Maybe
the
the
last
update
time
or
something
like
that
right,
like
I
think
version
numbers,
are
usually
simpler
because
it's
easier
to
implement
than
time
comparison.
A
B
Generic
resource
version
thingy,
okay,
something
to
add
to
the
mix:
yep:
okay,
cool,
okay.
I
like
this
a
lot
I
like
this.
This
actually
sounds
like
a
really
cool
scenario.
Okay,
anything
else,
people
want
to
bring
up
either
about
the
interop
scenario
or
about
next
steps
that
we
should
take
relative
to
our
our
respective
implementations.
B
G
I'm
kind
of
told,
because
I
really
see
two
different
kind
of
implementation
and,
like
probably
work
less
with
cloud
even
than
you
guys,
because
I
want
to
use
it.
But
it's
clearly
not
close
to
production
in
our
company.
G
But
when
I,
when
I
did
the
discovery,
my
thinking
was
like,
if
I
created
like
a
micro
services,
I
want
to
be
able
to
host
a
small
discovery
service.
So
basically,
then
people
can
know
what
that
micro
service
exposes
cloud
events,
and
things
like
that.
I
didn't
took
like
the
example
of
like
the
big
one,
which
is
basically
the
aggregator,
where
it
can
be
my
enterprise
discovery
system
that
will
aggregate
all
my
micro
services,
but
in
that
example,
as
a
developer,
my
thought
was
like
when
I
develop
my
micro
service.
G
L
So
in
in
my
exact
use
case,
I
work
on
k-native
eventing.
We
have
the
concept
of
a
broker
which
you
could
you
could
think
of
as
a
general
purpose,
like
kafka
or
nats
broker.
L
The
it'd
be
interesting
to
be
able
to
ask
that
that
broker
all
of
the
microservices
that
are
sending
it
events,
and
so
that
you
know,
there's
some
magic
under
the
hood
there
to
to
make
sure
that
the
microservices
all
serve
up
a
discovery
endpoint,
but
a
consumer
of
events
off
the
that
broker.
Don't
want
to
go
and
ask
every
microservice.
L
Do
agree,
I
don't
think
the
aggregator
is
going
to
be
a
very
common
implementation.
I
think
it's
only
for
these
very
special
broker-like
things
that
would
like
to
host
a
superset
like.
Maybe
they
don't
emit
events
themselves
at
all,
but
they
do
facilitate
the
aggregation
of
several
microservices
into
a
single
consumer.
G
Yeah
and
in
my
case
is
like
so
I
would
like
to
have
the
micro
service
that
exposed
like
a
really
basic
end
point
of
discovery,
which
basically
the
less
logic
I
have
the
better
it
is,
and
then
I
was
seeing
like
maybe
doing
a
small
open
source
product
that,
but
maybe
your
broker
may
can
make
it,
and
it's
even
better
for
me
that
will
be
like
our
enterprise
way
of
discovering
it.
So
then,
like
it's
our
single
point,
that's
where
you
go
and
when
you
create
new
micro
service,
they
kind
of
register.
L
I
think
we
still
need
to
figure
out
how
your
micro
services
tell
upstream
that
they've
they've
updated
their
catalogs.
G
G
Then
I
have
new
events,
but
when
I
do
that,
like
how
the
new
pod
know,
what
was
the
previous
pod,
it's
kind
of
to
to
know
what
kind
of
cloud
events
you
need
to
send
to
send?
That's
where
I'm
still
confused.
G
M
Well,
a
little
of
both
remy
the
the
discovery
spec
that
you've
implemented.
That's
the
pr
in
the
javascript
sdk
is
that
great.
K
G
G
I
don't
think
it
will
take
that
much
time
because,
like
the
whole
logic
is
already
there,
so
it's
not
like
crazy.
I
had
to
implement
the
uid
stuff
because,
like
so
same
thing,
the
uid
I
talked
with
dog
in
the
past,
like
it
was
a
bit
disturbing
me
because,
as
it's
kind
of
statically
linked
into
your
code
generating
the
uuid
was
kind
of
meaningless
in
that
situation.
G
So
what
we
agreed
is
like
to
create
a
uid
based
on
the
name,
which
is
a
specific
case,
but
because
again
it
makes
sense
when
you
have
like
a
big
discovery
service
as
a
standalone
product.
But
if
you
embedded
it
into
service,
then
you
don't
want
to
have
state.
You
don't
want
to
have
all
those
and
even
pagination
is
kind
of,
and
I
would
say
a
bit
annoying
to
do
it's
not
impossible.
G
It's
like
not
the
same
idea.
I
think,
but
I'm
happy
to
revisit.
If
you
need
some
updates
on
anything.
M
No,
I
was
just
curious,
but
but
I'm
also-
and
this
is
maybe
just
you
know-
unfamiliarity
with
it
on
my
part,
but
what
the
question
that
kept
coming
to
mind
for
me
was
well.
If
these
discovery
services
are
admitting
events
where,
where
do
they,
these
events
get
emitted
to
and
scott?
You
mentioned
the
native
eventing
broker.
That
makes
a
lot
of
sense,
but
obviously
that's
not
going
to
come
along
with
just
some
implementation
of
the
discovery
spec,
so
is
there
like.
I
guess
I
don't
know
to
me.
L
M
And
that
hook
that
registration
service
is-
and
I'm
sorry
I
you
know-
haven't
spent
enough
time
with
the
spec
to
be
to
know-
is
that
part
of
the
spec
or
is
that
something
that's
just
left
open
to
the
reader.
L
B
B
B
I
M
B
Actually,
what's
interesting
is
remy
your
your
comment
earlier
about
your
preferred
implementation.
Choice
of
you
know
just
a
single
discovery:
endpoint
for
one
or
more
services.
That's
back
there,
not
necessarily
part
of
this
whole
aggregation
thing.
I
actually
think
that
would
actually
be
an
interesting
twist
to
the
scenario
that
I
was
going
to
write
up,
because
we
could
have
obviously
a
circular
list
of
aggregators,
but
there
also
could
be
branches.
B
I
guess
might
be
the
right
word
of
just
one
offs
who
aren't
necessarily
participating
in
the
aggregation,
but
their
inputs
into
the
circular
aggregation
right
and
see
how
that
plays
into
it.
It
shouldn't
matter
but
it'd,
be
interesting
to
make
sure
it
doesn't
impact
anything
yeah.
The
topology
is
usually
called
the
ring
and
spoke
there
you
go.
Thank
you.
B
L
I
think
lance
has
a
good
point
around
like
how.
How
does
that,
if,
if
the
thing's
going
to
raise
events
like
what
does
that
really
mean-
and
one
option
could
be
that
we
we
implement
the
http
watch
api
and
it's
like.
If,
if
someone
is
interested
in
receiving
the
events,
they
the
the
consumer
of
those
events,
initiates
the
requests
and
it's
basically
a
hanging
get
and
when
an
event
gets
raised.
That
gets
distributed
to
all
the
clients
that
are
connected.
L
Difference
between
person,
first
of
all,
no
I'm
I'm
I'm
thinking
about
the
implement
implications
of
adding
these.
These
events
to
the
discovery
api
for
changes.
Okay,
I
think
we
need
to
solve
both
the
like.
How
do
you
know
the
consumers
of
the
the
changes
to
this
recovery,
api
and,
and
then
also
this
thing-
we've
picked
up
around
some
sort
of
like
resource
version
or
version
of
the
service
that
the
discovery
api
holds.
L
L
B
G
I
was
just
thinking
I
don't
know.
If
things
do
do
we
already
have
like
a
kubernetes
system
out
where
we
could
all
push
like
a
basic
functional
system
like
the
discovery,
the
subscription
to
understand
the
whole
cinematics?
Maybe
I'm
completely
off,
but
it
exists,
I'm
asking
stupid
stuff,
but
it's
just
for
me.
It's
the
same.
G
Suppose
maybe
it
exists
in
your
company
and
it's
just
me
lagging,
but
that's
for
me.
I
like
to
see
things
working
completely
and
for
now,
when
I
developed
it
discovery
service,
I
was
doing
it
abstractly
like
without
really
using
it.
So
I
don't
know
if
such
a
cube
that
we
could
share
altogether
or
exist
or
not.
G
Like
basically
one
place
where
maybe
a
cuban
is
because
I
think
then
it
might
be
easier
where
we
can
all
deploy
our
discovery
service
and
like
having
a
full
cloud
events:
environment,
working,
meaning
the
subscription
api,
the
kind
of
the
broker
so
either
the
kafka
or
whatever,
but
like
a
full
small
working
cloud
events
to
be
able
to
test
and
play
with
it
more
because
for
me,
it's
still
abstract
because
we
don't
use
it
in
our
company.
You
might
have
this
in
your
company,
but
I
don't.
L
G
L
M
M
Can
you
adding
eventing
to
that
is
just
a
few
crds
and
then
it
I
don't
know
I
mean
it
might
be
useful
to
have
some
images
and
a
couple
of
yml
files
so
that
we,
you
know
once
this,
these
things
come.
You
know
into
a
little
bit
more
concrete
form
so
that
we
could
easily
just
stand
something
up
locally
and
play
with
it
on
a
kind
cluster
or
something
like
that.
Just
a
thought.
M
B
G
K
K
M
This
is
the
excuse
me.
This
is
the
first
time
I've
attended.
This
particular
call,
and
I
only
did
it
because
you
said
it
was
happening
at
the
end
of
the
the
the
meeting
before
and
I
didn't
know
about
it
is.
How
often
does
it
happen?
Is
it
it
doesn't
appear
to
be
on
the
calendar,
but
this.
B
Right
and
we
we
just
decided
to
do
it
last
week
on
the
on
the
cloud
events
call,
so
you.
B
Yeah,
actually,
if
that's
something
we
didn't
talk
about,
should
we
assume
that
we're
going
to
do
this
on
a
regular
basis,
like
maybe
do
it
every
other
week?
And
you
know
one
week,
sdk
of
the
week
discovery
or
interop
testing
or
is
every
other
week
too
far
apart.
L
B
L
L
You
know
comparing
this
participant
list
to
the
cloud
events
call
participant
list
right
like
there's
a
lot
of
opinions
on
the
spec,
but
not
a
lot
of
fingers
typing
the
implementations,
yeah.
B
There
are
implementations
out
there
because,
when
I've
gone
to
talk
to
customers
about
other
subjects
and
cloud
events
just
happens
to
come
up,
I
hear
about
them
implementing
stuff,
you
know
and
they're
excited
by
it,
so
they
are
doing
stuff
with
it.
I
just
get
the
feeling
that
it's
more
just
proprietary,
homegrown
stuff-
and
you
know
they
they
just
do
whatever
they
need
to
do
to
get
their
job
done
and
they're
not
really
interested
in
interrupt
beyond
what
the
spec
says.
B
L
G
Remy,
yours
is
what
javascript
typescript.
F
M
Script:
it's
I
just
posted
a
link
to
the
pr
it's
in
the
sdk
repo,
which
opens
another
question
about
whether
that's
the
right
place
for
it
to
be,
but
for.
G
Me
it's
really.
If
it's
like
the
micro
service
discovery,
part
inside
the
sdk
was
not
for
me
the
wrong
place.
If
it's
the
full
aggregator
services
with
like
way
more
future,
then
it
should
definitely
be
another
repo.
So
I
was
thinking
almost
out
of
doing
it
twice.
One
smaller
like
that.
You
can
just
pack
with
your
service
and
like
a
bigger
one,
that
is
almost
a
standalone
product,
but
maybe
I'm
wrong.
B
I
Yeah,
I
guess
that
brings
up
a
good
question
so
is
like
the
discovery.
Part
is
that
is
that
part
of
the
sdk
spec.