►
From YouTube: CNCF Serverless WG 2020-09-10
Description
CNCF Serverless WG 2020-09-10
A
A
B
B
C
A
A
G
H
D
I
I
J
A
C
A
I
A
L
A
M
A
All
right
moving
forward,
not
too
surprising,
no
one's
volunteered
yet
for
kubecon,
north
america
clemens.
Since
I
see
you
join
now,
what
do
you
think
about
both
of
us
signing
up
and
we
just
said
in
the
same
video
we
did
for
the
previous
ones.
I
I
think
that's
a
brilliant
idea.
I
like
it
okay,
but
that
means
that
we're
both
then
signed
up
to
answer.
Questions
live
you,
okay,
with
that.
N
D
A
A
Yes,
it
became
very
easy
for
us
great
thanks.
Yes,
all
right
cool!
Thank
you.
Let
me
make
a
note
here,
so
I
will
send
in
the
thing
now:
okay,
timor,
since
you're
on,
did
you
get
an
invite
or
a
questionnaire
that
you're
supposed
to
fill
out
since
your
sandbox
project?
Or
do
you
need
to
steal
the
serverless
working
groups
slot.
A
J
A
C
A
A
Oh
yeah,
it
was
just
the
announcement
from
slinky
right,
so
that
was
it
java
sdk
2.0,
milestone.
2
is
out
there
all
right.
We
do
have
a
call
technically
right
after
this
one
talk
with
discovery.
Interrupt
please.
If
you
have
any
topics,
go
ahead
and
add
it
to
the
agenda
doc
or
to
that
lock
itself,
and
then
we'll
see
what
happens
all
right,
timor
anything
you
want
to
bring
up
from
the
surface
from
the
workflow
stuff
to
update.
J
A
A
A
A
Most
of
it
is
around
things
like
making
it
clear.
Oh
rather
than
talking
about
a
generic
api
section,
I
specifically
made
it
all
about
rest.
Basically
in
http
I
figured
we
can
add
other
protocols
later
on,
but
I
want
to
get
the
rest
one
out
there
and
whether
we
pull
this
out
into
a
separate
spec
or
keep
it
here
we
can
discuss
later,
but
I
wanted
to
fill
out
specific
details
so,
for
example,
make
it
clear
that
this
is
doing
a
get
on
the
services
talked
about.
A
Okay,
I
left
and
opened
it
to
do,
because
I
figured
that's
actually
a
little
bit
bigger
is.
How
do
we
want
to
handle
errors
right?
Do
we
want
to
define
a
standardized
response,
json
for
errors
and
stuff,
like
that?
We
probably
do,
but
I
don't
want
to
overload
this
pr
too
much,
so
I
thought
that
is
a
to
do
for
later
on
the
biggest
thing
that
I
want
people
to
think
about.
A
A
A
A
However,
in
both
cases
I
do
talk
about
returning
a
two
or
two
accepted,
meaning
the
the
endpoint
wants
to
do
an
asynchronous
update
or
create,
and
they
can't
return
something
quickly
enough
before
you
can
start
getting
before.
You
start
worrying
about
timeouts,
so
I
had
this
whole
big,
rambling
stuff
in
here
about
how
to
handle
asynchronous
updates.
A
So
take
a
look
at
that
in
there
because
I
do
have
a
whole
bunch
of
semantics
around
how
to
process
those.
I
don't
want
to
necessarily
bore
you
guys
on
the
call
here
right
now,
but
please
take
a
look
at
that
see
what
you
think.
I
try
not
to
make
it
too
funky,
but
let
me
go
ahead
and
pause
there
for
a
sec
since
scott,
you
raised
your
hand.
Q
N
A
A
I
don't
know
I
just
have
this
weird
feeling
that
that
there's
gonna
be
cases
where
people
say
you
know
what
I
need
to.
I
need
to
upload
something
into
this.
I
don't
have
another
endpoint
for
you
to
pull.
I
just
need
to
upload
some
data.
I
need
to
update
some,
you
know
somewhere,
endpoint
or
new
services.
A
P
P
P
P
A
And,
to
be
honest,
my
assumption
was
that
there
there
would
need
to
be
some
sort
of
security
mechanism
in
place
and
whether
we
talk
about
that
or
say
hey
it's
up
to
you
to
decide
that,
because
there
are
lots
of
different
mechanisms
out
there,
that's
up
for
you
to
decide.
We,
I
just
kind
of
figure
we
talk
about
that
later.
To
be
honest,.
H
Yes,
so
I
could
imagine
that
not
in
all
cases,
you
would
like
to
have
this
crud
parts
implemented,
because
in
some
cases
you
might
have
a
very
special
way
to
that.
You
have
already
existing
content
and
you
just
translate
it
and
make
it
discoverable
the
standard
way,
but
the
the
way
how
you
you
get
to
this
content
might
be
the
proprietary,
for
example,.
A
N
N
A
R
A
N
A
A
Okay.
So,
as
I
said,
I
didn't
want
to
try
to
force
this
through.
I
think
people
need
to
look
at
it
fairly
carefully,
so
please
do
get
a
chance
to
review
it.
As
I
said,
I
think
I
think
the
a
think
I
think
the
async
stuff
is
necessary,
even
though
it
does
feel
a
little
bit
complicated,
but
I
try
to
keep
it
as
simple
as
possible,
but
please
you
know,
look
at
that
kind
of
carefully.
N
N
You
can
do
we
can
return
the
retry
after
and
basically
tell
the
client
when
to
come
back
to
so.
Basically
someone
issues
a
request
to
you,
and
then
you
say
you,
you
basically
say
yup.
You
have
come
to
the
right
place
302,
but
I
just
can't
do
that
yet
so
you
give
them
the
location,
header
and
the
retry
after
is
you
tell
them,
come
back
in
five
seconds.
N
N
N
N
Okay,
so
you
can.
You
can
do
a
three,
so
you
can
do
a
307
with
a
location,
header
and
a
retry
after
and
that
mechanism
is,
is,
is
supposed
to
be
picked
up
by
the
client
and
for
the
client
and
to
do
the
request
again
to
that
location,
but
after
waiting,
the
retry
after
period
and
that
that
can
then
be
used
for
asynchronous
processing.
N
A
K
A
N
So
you
can
so
you
can
actually
do
a
there's
another
detail
there
in
that
you
can.
You
can
basically
preempt
the
client
from
sending
the
entire
request
to
you
by
coming
back
with
the
with
the
this
is
the
the
100
continuous
thing
that
is
also
in
http,
so
there's
all
kinds
of
nuances
where
you
can
go
and
trick
which
the
browsers
use
where
you
can
go
and
trick
the
the
the
client
into
into
some
into
some
behavior
that
then
in
the
in
the
end,
becomes
asynchronous.
N
A
N
N
N
H
A
A
Okay
and
thank
you
for
the
comments
you
guys
gave
already
appreciate
that
next
one
at
the
pr
okay,
so
this
one
was
based
upon
last
week's
discussion.
We
talked
about
needing
a
version
attribute
and
to
be
clear.
This
version
attribute
is
the
version
of
the
discovery
endpoint
metadata
for
this
particular
service.
It
is
not
related
to
the
version
of
the
service
itself.
A
Okay,
and
as
I
was
writing
this
up,
I
believe.
Originally,
I
wrote
the
version
field
and
I
called
it
disk
version
or
discovery
version.
Just
a
couple
of
reasons.
One
is
I
I
didn't
just
call
it
version,
because
I
didn't
want
people
to
get
confused
about
what
it's
the
version
of
right.
So,
for
example,
we
have
spec
version
down
here
means
cloud
event
version
this
version
here
makes
it
perfectly
clearly
to
me
that
this
was
the
discovery
version.
I
don't
know
if
you
want
to
like
the
word
disk.
A
We
can
call
it
discovery
if
you
want,
but
anyway,
the
point
here
is
it
starts
at
one
and
on
each
update.
It
gets
incremented
by
one
each
time,
so
it
just
continually
goes
up
relatively
straightforward.
Now
after
I
wrote
that,
though
I
don't
know
why,
but
I
started
thinking
about
it
and
realizing
you
know
it
might
be
really
nice
to
know
when
the
resource
itself
was
actually
updated,
and
so
I
thought
I
started
contemplating
whether
I
should
open
pr
to
have
a
timestamp.
A
A
Then
the
exact
value
here
on
the
discovery
version
technically
doesn't
matter
all
that
matters
is
that
it's
changes
and
you
can
do
a
simple
string,
compare
or
some
sort
of
compare
to
say:
okay,
one's
bigger
than
the
other.
Therefore,
the
bigger
one
is
always
newer
right.
So
that's
what
I
thought.
Well,
maybe
we
can
do
double
duty
and
say
have
just
one
field
called
updated
and
you
can
use
the
timestamp
to
determine
that
comparison
check
as
well
as
get
other
information,
meaning
when
it
was
actually
updated
in
case.
That's
the
information.
A
A
So
I
don't
know
if
I
put
this
in
there
or
not,
but
I
could
have
sworn
that.
I
put
it
something
that
said:
oh
there's
a
typo
there
that
said
that
the
time
always
has
to
go
up,
and
I-
and
I
thought
about
it
this
morning-
that
I
need
to
add
some
additional
statements
here.
That
says
exactly
because
of
the
clock
execute
problem,
that
the
server
side
is
required
to
guarantee
that
every
single
time
it
gets
updated.
A
The
time
value
always
goes
up
by
one,
because
it
is
technically
possible
that
if
you
had
this
thing,
you
know
sharded
out
across
different
backend
servers
that
one
server
is
really
really
slow
or
really
really
behind
for
some
reason
and
that's
the
one
who's
going
to
do
an
update,
so
it's
possible,
he
could
try
to
update
with
an
older
time
by
mistake
if
he
tries
to
take
his
current
time.
But
I
think
we
need
to
add
logic.
That's
that
says!
No.
A
A
P
G
P
N
A
A
N
That
seems
a
little
dangerous,
and
that's
only
because
updated
is
so
obvious
seems
to
be
so
obvious
what
that
is
that
nobody
might
care
to
go
and
read
the
particular
line
and
then
find
out.
Oh,
this
is
actually
a
version
right.
If
you
call
this
epoch,
then
it's
weird
enough
for
for
people
to
understand
okay.
So
this
is
where
I
need
to
go
to
put
the
put
the
value
for
when
this
was
updated,
but
also
has
an
extra
meaning.
N
P
Right
so
like,
let's,
let's
take
the
the
aggregation
case
and
the
there's
a
a
b
and
c
aggregating
and
we're
looking
at
c
and
a
changes.
It
does,
that
field
get
updated
at
a
and
b
and
c,
because,
like
the
intention
was
that
the
so,
if
a
adds
a
record
and
then
sets
the
epoch
version
or
whatever
it
is,
that
should
be
the
same
version
that
propagates
throughout
the
the
chain.
P
A
G
A
P
P
A
P
A
G
A
G
A
Yeah
the
the
fact
that
I
that
I
overloaded
updated,
I
thought,
was
an
interesting
trick,
but
as
as
clemens
pointed
out,
it
might
be
a
little
too
tricky
and
could
lead
to
confusion.
So
I'm
okay
with
dropping,
updated
and
my
mind,
is
now
in
the
in
the
phase
of
okay.
Do
we
want
it
to
be
just
a
number
like
this
disc
version,
or
do
we
want
it
to
be
more
like
a
time
stamp
like
epoch?
A
A
N
N
A
A
A
N
P
Yeah,
so
it
doesn't
have
to
go
up
by
one
because,
like
so
this,
my
my
thinking
is
that
the
similar
to
the
resource
version
kubernetes
and
that's
atomic
across
all
resources
in
sed.
So
it
goes
up
by
one.
But
it's
a
global
counter
and
every
resource
might
jump
by
hundreds
based
on
how
many
resources
are
inside
the
cluster
right.
A
A
F
N
N
P
A
R
P
A
N
M
A
A
P
C
A
A
N
N
N
Would
there
ever
be
a
case
that
a
an
extension
would
be
promoted
into
the
main
spec,
and
they
are
pointed
to
the
extensions
that
we
already
have
in
our
repo
and
if
it
turns
out
that
everybody's
using
we're
using
the
sequence
number
everywhere,
then
it's
possible
that
that
might
end
up
being
promoted
into
the
main
spec.
And
if
that's
so,
then
we
don't
want
to
break
everybody's
code
so
that
you
know
you
can
continue
to
use
this.
N
This
extension
and
you
don't
have
to
go
and
rewrite
your
code
to
use
the
newly
christened
official
embedded
extension
so
that
we
keep
compatibility
so
effectively.
All
the
arguments
that
we
went
through,
we
went
through
again
because
they
are
somewhat
difficult
to
fit
into
the
the
protostructure,
and
so
the
the
result
is
that
they
are
the
the
produce
spec
and
we
also
went
through
the
the
special.
N
I
also
explained
how
we
did
the
trick
with
data
underscore
basics
before
how
we
effectively
use
the
underscore
basics
before
as
an
attribute
indicating
that
this
is
a
binary
and
the-
and
this
is
if
this
is
reflected
that
that
duality
is
really
reflected
in
the
proto
in
the
protobuf
proposal,
by
having
a
binary
and
then
having
a
string
that
takes
the
same
role
as
effectively
a
single
json
string.
That
can
also
be
used
for
a
text-based
text-based
content
type.
N
A
A
A
C
A
A
H
M
A
M
Yeah,
but
but
I
think
this
is
a
bit
more
descriptive
than
that
I
mean
we
can
definitely
go
with
openid.
It's
the
same
thing
that
why
do
we
choose
open
api
aspect
where
there's
a
discovery?
If
we
aspect
so
I
believe
that
that
justification
holds
true
for
the
subscription
spike
as
well.
I
don't
know,
but
that's
just
an
opinion.
A
Well,
do
you
want
to
take
a
first
pass
at
writing
up
what
in
http
subscribe
would
look
like
sure,
yeah?
I
think
I
think
that'd
be
a
great
first
step,
because
because
it
seems
like
if
nothing
else,
that
would
be
useful
input
into
the
creation
of
or
not
the
creation,
but
the
what's
going
to
go
into
the
description
api
for
hp,
http
right
yeah
I
mean.
Does
anybody
else?
Think
I'd
be
premature
to
be
looking
at
that
klaus?
A
M
Question
so
from
the
subscription
manager
point
of
view
like
how
are
we,
how
are
we
going
to
start
implementing
this?
So
even
if
we
start
implementing
this
is,
is
there
a
mechanism
that
we
can
dynamically
pick
these
implementations
of
xyz
subscription
managers,
for
example,
if
we
switch
between
different
messaging
systems,
like
kafka,
not
same
qp,
do
we
create
relevant
subscription
managers
for
every
messaging
implementation?
How
does
it
work?
So?
I
would
like
to
outline
these
kinds
of
details
before
we
start
implementing
that
it's.
H
M
M
H
M
H
H
Here,
obviously,
these
are
cloud
events
subscriptions,
so
we,
I
think,
there's
also
a
section
describing
the
possible
filters.
So
far
we
just
have
a
very
basic
filter
dialect,
so
I
I
would
assume
that
there
some
additional
work
is
needed,
also
something
I
whenever
I
find
the
time
for
it,
we
wanted
to
do
some
more
work
on
so
far.
We
just
have
exact
match
or
prefix
suffix
filters
for
the
cloud
event
attributes.
M
A
H
A
A
A
A
It's
just
it's
so
difficult
for
me
to
think
of
the
kubernetes
api
as
a
subscription
api.
It's
isn't
it
the
same
here
I
mean
you
also
create
something
that
has
an
id
a
subscription
id.
I
know
I
know
it's
a
mental
block.
I
have
I
I
agree,
I'm
thinking
about
this
wrong.
It's
just
like.
I
couldn't
get
past
that
for
some
reason
in
my
head.
M
H
H
A
Let
me
ask
you
guys
a
slightly
different
question.
That's
maybe
why
I'm
I'm
struggling
with
thinking
of
the
k-native
stuff
as
a
subscription
api
are.
Are
you
guys,
assuming
that
when
we
talk
that,
when
we
actually
formalize
the
api
for
subscription
that
it's
going
to
look
more
of
an
rpc-ish
kind
of
a
thing,
or
is
it
going
to
look
more
like
kubernetes,
where
you're
creating
an
object.
M
A
A
A
It
seems
weird
to
me
to
force
the
user,
meaning
the
client
to
think
of
it
as
I'm
creating
a
resource
someplace.
I
understand.
Technically,
that's
exactly
what's
happening
all
right.
That's
that's!
Usually
what
every
implementation
is
going
to
do
it's
going
to
create
some
kind
of
resource,
whether
it's
a
formal
resource
or
just
an
entry
in
a
database?
A
M
Okay,
I
think
I
get
that.
What
are
you
trying
to
intend,
so
you
basically
imply
towards
the
central
subscription
broker,
what
the
workload
can
basically
query
or
request
and
show
its
intent
in
terms
of
subscribing
to
a
topic,
and
it
definitely
gives
you
the
relevant
details
about
how
the
messaging
system
can
interact
with
it
rather
than
creating
a
resource.
So
it's
mainly
like
requesting
a
broker-
let's,
let's
not
call
it
like
any
specific
messaging
white
broker.
M
E
A
I'm
not
sure
I
want
to
do
that
in
this
mod
in
this
spec
right.
I
think
I
think
we
clearly
needed
to
find
the
shape
of
whatever
thing
gets,
sent
back
and
forth
between
the
client
and
the
server.
I
agree.
We
obviously
need
to
define
that,
otherwise
you
have
zero
internal
ability.
However,
I
don't
want
to
necessarily
force
all
implementations
to
then
store
what's
sent
on
the
wire
into
their
backend
server.
They
could
choose
if
they
wanted
to,
but
they
should
also
be
able
to
translate
it
into
their
own
data
model.
C
A
What
I
want,
how
you
do
it
on
the
back
end,
I
don't
give
a
crap
but
here's
my
data,
I'm
just
going
to
center
over
a
chunk
of
jason
and
therefore
we
don't
have
to
fight
about
what
the
shape
of
what's
on
the
wire,
because
because
at
some
point
this
way
at
some
point,
I
think
scott
is
going
to
ask
for
a
status
and
a
spec
section
of
these
resources.
I
don't
know.
H
A
Yes,
yes,
but
I
I
everything
you
said
that
I
agree
with
klaus,
but
does
that
mean
that
we
have
to
actually
have
a
spec
in
a
status
section
simply
because
some
people
are
going
to
implement
this
on
kubernetes
right?
I
don't.
I
personally
wouldn't
want
that.
I,
unless,
unless
for
some
reason,
spec
and
status,
makes
100
perfect
sense
to
the
end
user
right
to
me
as
an
end
user.
When
I
look
at
a
subscription
api,
I
would
want
to
be
able
to
pass
in.
A
You
know
like
what
I'm
showing
here
on
the
screen
right,
I'm
going
to
pass
in
I'm
going
to
pass
in
some
information
about
the
subscription
right.
What
are
the?
What
is
the
filter
criteria?
What
is
the
bucket?
I
want
if
it's
a
cloud
object,
storage
right,
I'm
going
to
pass
all
this
information
when
I
turn
around
and
do
a
get
on
something
to
find
out
the
status
of
my
subscription.