►
From YouTube: CNCF Serverless WG Meeting - 2019-05-30
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
All
right,
3
pass
Aaron.
Why
don't
you
get
started?
Let's
see
community
time
any
topics
from
the
community
that
people
want
to
bring
up.
A
So
you
guys
can
go.
Look
at
that
later.
If
you
want,
however,
I
did
want
to
leave
an
opportunity
for
people
who
were
at
coop.
Cons
had
mentioned
something
in
general.
If
you
thought
might
be
of
interest
for
the
group.
So
does
anybody
have
anything
from
coupon?
They
want
to
mention
that
might
be
of
interest.
A
Okay,
in
that
hearing
anybody
cook
on
China,
slides
it
out
available
yet
well
soon,
as
those
are
ready,
Catherine
I'll
make
those
available
to
put
the
group
to
review.
The
one
thing
I
do
want
to
mention
is
that
I
do
want,
if
possible,
for
you
guys
to
keep
your
end
points
up
for
the
demo,
because
I
am
planning
on
showcasing
the
demo
during
our
session
there,
one
of
one
of
the
two
sessions
there.
So
please
keep
your
endpoints
up,
so
we
can
run
the
demo.
A
There
I'd
appreciate
that
next
week,
on
Tuesday
I
believe
about
the
TOC
College
I
will
ask
about
the
criteria
for
going
to
incubator,
just
as
a
reminder
for
everybody.
That's
coming
up
and
I
will
ask
this
question
about
whether
there's
a
requirement
for
us
to
be
beta
or
certain
version
number
I.
Think
the
answer's
no,
but
I
will
confirm
that
with
a
group
all
right
on
to
PR.
Sorry.
Is
there
any
other
topic
people
bring
up
before
we
get
the
PRS.
A
B
B
C
D
A
B
B
B
A
Cool,
that's
sequin
backwards,
any
objection
to
it
to
approving
this
one,
then
nope
I
think
Brito.
Anybody
else,
alright,
not
hearing
any
objection.
We
can
approve
Thank
You
Jenna
for
that
alright,
now
Clemens
is
not
on
the
call,
but
I
did
want
at
least
bring
this
one
up
for
people's
attention.
A
Let's
see
so,
basically,
if
I
have
this
correct,
oops
to
me,
sir
I
had
to
come
it's
here
on
a
second.
So
basically
this
is.
This.
Pr
is
trying
to
address
the
problem
that
I
care,
who
it
was
from
Google
I've
been
Alan
mentioned
that
we're
putting
quotes
around
our
HTTP
headers
or
the
spec
requires
us
to
put
quotes
around
HTTP
headers,
even
though
we
don't
really
want
to
do
that,
and
what
I
believe
Clement
is
proposing
here
is
to
basically
at
the
spec
level,
one
level
every
phrase
of
the
right.
A
What
he
wants
to
do
is
is
define
a
string,
encoding
format
for
all.
There
are
different
types
and
then
say
for
things
like
HTTP
use,
the
string
encoding
for
those
particular
types
and
then
the
receiver
when,
if
they
understand
the
type
with
a
particular
attribute,
it
can
convert
it
into
the
appropriate
type
so,
for
example,
a
time
stamp
type,
for
example,
but
for
any
types
that
people
do
not
understand,
they'll
just
keep
it
as
a
string
and
then
pass
it
along
as
appropriate.
A
That
I
think,
is
the
basic
idea
here:
I
wanted
to
go
on
like
I
said:
I
want
to
put
this
out
there
for
people
to
start
commenting
on
it
and
then
think
about
it.
Obviously,
Clemons
will
do
more
it
speaking
of
it
next
week
when
he's
on
the
call,
but
I
want
to
get
people's
initial
reaction
to
it.
In
particular,
Scott
I
was
wonder
if
you
had
a
chance
to
look
at
this
one
and
think
about
it.
A
E
B
Yeah,
because
the
way
I
read
this
when
I
quickly
went
through,
is
basically
saying
it's
up
to
the
SDKs
to
understand
the
types
of
the
underlying
attributes
you
know
so
or
or
at
least
that
the
transport
spec
has
to
understand
the
type
system
so
that
it
can
move
stuff
that
wasn't
Ford's
based
on
the
name
of
the
attribute,
rather
than
explicitly
in
the
type
in
the
protocol
itself.
So
I
mean
I
I,
don't
quite
understand
how
this
works
for
extensions.
B
For
instance,
I
guess
I
need
to
read
it
a
bit
more
I,
don't
understand
how
an
intermediary
come
forward,
an
extension
without
losing
its
type
information.
Yes
and
I
also
don't
understand
how
an
intermediary
could
forward,
maybe
a
new
Rev
of
the
spec
without
losing
its
type
information.
So
that's
that
I
need
to
read
it
more
deeply.
Yes,.
A
So
I
Scott
correct
me
if
I
get
this
wrong
here,
but
I
believe
that
extension
for
the
unknown
extensions
or
basically
just
passed
around
the
strings.
So
there
is
no
type
information
whatsoever
if
you
know
about
them
yeah,
if
you
know
about
the
type
of
the
extension,
then
obviously
it's
just
like
any
other
attribute.
You
can
convert
it
as
part
of
the
SDK
or
application
code,
but
but
in
general,
own
extensions
are
just
strings.
Is
this
short
answer
I
also.
D
A
A
So
I'm,
not
gonna
like
ask
or
vote
or
anything
today,
but
I
do
want
people
to
to
be
prepared
for
potentially
voting
on
it
next
week,
because
I
know
that
I've
heard
from
more
than
one
group
of
people
that
they
would
like
to
try
to
move
the
spec
as
close
we
can
to
1.0
sooner
later-
and
this
is
one
of
the
the
biggest
items
was
lingering
for
us
to
resolve
so
I'm
gonna-
try
to
push
for
a
vote
next
week
at
people
we're
okay
with
that
anyway.
Tippy
knee
your
hands
up,
yeah.
F
I
thought
it
was
is
an
interesting
point
that
this
will
affect
how
extensions
can
evolve
and
also
how
conflicting
extensions
we'll
see
each
other
earlier.
If
you
would
have
had
a
conflict
in
the
type
you
would
have
noticed
in
the
type
now,
if
you
have
a
conflict,
it
will
just
thereby
form
string
in
the
next
in
the
next
extension
version,
or
if
you
have
conflicting
extensions,
that
expect
different
types
which
have
special
meaning
but
are
encoded
as
a
string
without
any
identifiers.
A
D
A
Ok,
you
guys
are
awfully
quiet.
Okay,
in
that
case,
please
take
your
time
to
look
this
over,
because
if
there
are
no
comments
or
concerns
before
next
week's
call,
I
will
ask
you
know
if
you're,
ok
with
approving
it.
So
if
you
do
have
concerns,
please
get
them
out
there
sooner
rather
than
later,
so
that
the
clowns
could
try
to
address
them
and
Scott
correct
me
if
I'm
wrong,
but
if
we
do
approve
that
one
that
resolves
your
PR
correct.
D
B
D
A
A
Yeah
and
to
be
clear,
I
believe
in
this
one
Clemens
has
has
that
a
chance
to
respond
to
my
message,
but
I
believe
the
interesting
thing
is,
if
you
have
an
extension,
that's
technically
defined
as
a
map,
it
will
appear
this
entire
Jason.
Looking
thing
will
actually
disappear,
the
string
they
will
not
actually
come
across
the
adjacent
object
unless
the
receiver
happens
to
know
it's
a
a
map
and
then
again-
and
you
know
converts
it
for
you,
but
if
it's
an
unknown
extension
it'll
just
get
passed
along
as
a
string.
That's.
A
G
A
Okay,
does
that
please
take
a
look
at
when
you
get
a
chance
and,
let's
say,
moving
forward,
this
PR
is
been
out
there
for
a
little
while
I
did
make
some
very
minor
changes
this
morning,
just
to
do
a
little
bit
better
alignment
in
the
difference
between
producer
versus
source
I.
Don't
think
it
fundamentally
changed.
What's
in
here,
I,
don't
know
how
I
throw,
but
in
chance
to
read
it
yet,
but
I'll
give
you
guys
like
just
about
a
30
seconds
or
so
to
redo.
This
see
what
you
guys
think.
A
E
A
G
I
mean
I
think
I
feel
like
it
might
be
good
to
be
clear
that
that
string,
you
know,
is
an
identity
space
for
event
sources
and
there
isn't
any
other
identity
space.
So
maybe
that's
part
of
the
source
attribute,
but
historically
that's
been
a
little
bit
loose
about
what
the
source
attribute
looks
like
and
how
that
maps
onto
systems
that
produce
events
yeah.
A
So
I
do
actually
call
it
out
right
here,
but
I
guess
what
I
could
do
is
take
this
part
of
the
sentence
and
move
it
up
to
the
top.
You
know
you're
clear
that
I'm
talking
about
the
same
event,
source
I
mean
the
same
attribute
source
of
Ag,
where
stores
have
to
be
value.
I
can
I
can
move
that
sentence
up
higher
and
make
it
clearer.
That
applies
to
all
cases,
not
just
this
one
paragraph,
okay,
I,
can
do
that.
A
A
Okay,
let
me
ask
this
question:
I:
do
want
to
make
the
Edit
evidence
suggesting
that
it
probably
is
a
good
one,
but
I
believe
that's
a
relatively
minor
change.
It's
basically
taking
this
type
of
this
stuff
that
I've
highlighted
basically
moving
a
little
bit
higher
to
make
it
clear,
I.
Think
it's
a
relatively
minor
wordsmithing
change.
Would
you
guys
be
okay
with
assuming
we
approve
it
now
with
conditionally
approving
this
with
that
change,
and
then
I'll
make
the
change
and
wait
for
one
or
two
LG
teams
offline
and
then
merge
it?
A
A
Okay,
thank
you
Rachel
in
the
okay.
Let
me
ask
the
first
question
any
objection
to
approving
this
with
that
wording.
Change
this
as
suggested
by
Kevin.
Basically,
taking
this
part
here,
I'm
gonna
get
up
higher
okay
and
any
objection
then
to
doing
sort
of
a
deferred
merge
based
upon
that
based
upon
the
edit
okay
cool.
Thank
you
guys.
Whoops
what'd
I
just
do
okay,.
A
A
So
Scott
I
want
to
pick
on
you
for
a
sec,
so
I
added
this
text
here,
basically
to
talk
about
the
role
of
event,
producers
that
are
separate
from
the
event
sources,
meaning
you
have
this
entity
whose
job
it
is
is
to
create
the
cloud
event
on
behalf
of
the
source
and
I,
basically
go
into
some
ramblings
about.
You
know
what
they,
how
they
should
go
about
doing
that
and
how
they're
not
necessarily
there
to
to
represent
themselves
they're
there
to
represent
the
event
source.
It's
just
the
source
wasn't
produced
in
the
cloud
event.
A
D
A
Okay,
well,
I,
don't
want
to
rush
this
since
Scott.
You
think
you
still
have
some
concerns
with
it.
So
let
me
just
put
this
out
there,
please,
when
you
get
a
chance,
please
look
at
this
and
in
particular,
if,
if
you're,
writing
a
better
phrase,
an
adapter,
something
that
will
take
an
event
from
an
event
source
and
convert
it
to
a
cloud
event.
A
Please
make
sure
that
there's
no
text
in
here
that
you
think
would
make
it
so
you're
now
violating
something
or
not
adhering
to
the
guidance
in
here
or
if
you
just
think,
I'm
just
way
off
base.
Let
me
know,
but
I
do
think
that
we
do
need
some
better
clarity,
because
I
think
there
are
some
people
who
have
different
expectations
for
what
event
producers
do
like
weather,
for
example,
whether
they
put
data
in
they're
representing
themselves
or
or
when
they
put
that
in
there.
A
E
A
So
these
are
the
only
PRS
that
I've
actually
tagged
as
0.3
I
believe
that
these
last
two
technically
should
be
closed
because
they
were.
These
are
the
ones
that
Christophe
proposed
I
mean
that
I'm
going
with
Clemens
size,
constraint,
PR
instead,
so
I
think,
once
we
resolve
Clemens
PR,
all
three
of
these
will
go
away.
So
really
the
only
PRS
we
have
open
for
2:03
is
the
type
system,
one
that
we
talked
about
earlier.
A
E
D
A
Do
me
a
favor,
since
we
have
a
little
bit
of
time
right
now,
I'm
not
I,
think
I
might
agree
with
Evan
that
I
mean
honestly
a
blocker
4:03,
but
I
think
we
can
look
at
that
offline
and
decide
that
obviously
I
think
it's
a
requirement
for
100.
Obviously,
but
can
you
take
some
time
right
now
to
elaborate
on
where
your
concerns
are
around
batching.
G
D
D
A
C
D
It's
a
cloud
event
issue
like
a
piece
of
middle
pretend
your
middleware
and
you
receive
a
batch
request
over
HTTP
and
your
job
is
to
forward
it
on
to
some
other
thing
that
doesn't
support
batching.
What
is
the
exact
operations
you're
supposed
to
do?
Let's,
let's
say
the
negotiation,
you
plus
stay
in
HTTP,
you
get
a
matched
request
and
then
you're
supposed
to
deliver
it
to
a
non
batch
client,
and
so
you
deliver
one
two
three
and
the
third
one
gets
an
error.
B
Queue
Jam
your
hands
up,
it's
interesting
because
I
I
remember
correctly.
The
only
thing
in
our
specs,
which
talked
about
error
codes
and
performance
is
the
web
hook.
Spec,
nothing.
Everything
else
is
so
very
agnostic
on
on
transport,
because
I
didn't
know,
I
had
a
similar
question.
What
does
this
mean
to
the
SDKs?
Do
they
have
to
support
batching
as
well?
I
I'm
I
understand
the
spirit
of
what
it
was
written
by
I
I
completely
get
the
problem
of
what
and
intermediaries
meant
to
do
when
presented
with
one
those
things.
What's
the
expectation.
H
D
H
H
H
Actually
my
larger
question
here
was:
if
we
ever
want
to
get
bashed
in,
like
you
know
in
the
spec,
then
can
we
make
assumptions
saying
that
the
spec
version
for
the
entire
batches
the
same,
and
so
it's
better
to
kind
of
have
like
this
metadata
object
and
then
the
batch
events
like
a
more
structured
way.
A
Here,
yeah
a
little
bit
easier.
So
let
me
ask
this
question
those
Scott:
do
you
have
an
idea
for
the
direction
you
would
like
us
to
go?
A
So,
just
out
of
curiosity
to
in
some
of
the
scenarios
that
Scott
has
mentioned,
how
did
you
deal
with
those?
So,
for
example,
if
there
are
three
different
events
patched
up
and
the
the
middle
one
fails
in
some
way,
how
do
you
deal
with
that?
You
have
three
general
responses
and
the
middle
one
indicates
some
sort
of
failure,
or
just
only
the
middle
one.
We
give
response.
A
A
B
B
A
A
Because
what
I,
really
want
to
say,
is
go
all
you
want
to
do
is
ask
for
volunteer
to
put
together
a
strong
and
proposal
of
a
direction
and
see
whether
people
agree
with
that
proposed
direction.
So,
for
example,
sky.
What
would
you
have
liked
to
have
seen
that
I'm
going
to
make
your
life
easier?
As
you
have
noted,
this
is
it
guidance
that
says
how
to
handle
responses
and
errors
is
that
is
that
enough
to
have,
but
I've
been
enough
to
satisfy
your
your
issue.
D
It
becomes
very
difficult
because
HTTP
purse
for
responses
and
and
batching,
so
you
need
to
accommodate
for
new
events
that
come
as
a
result
of
the
batch,
but
also
some
method
of
knowing
that
this
ID
was
act
in
the
batch
that
you
sent
it's
something
like
that
would
help
I
think.
But
it's
really
complicated
well.
A
A
Yes,
you
can't
send
it
out
to
both
directions,
but
I
was
thinking
more
along
lines
of
is
when
you
send
an
event
to
a
receiver.
There's,
no,
we
don't
have
to
define
an
ACK
right,
I
mean
cuz.
You
could
recite
back
with
the
202,
which
means
nothing.
Oh
then
I
got
the
message
right
and
there's
no
confirmation
that
has
been
processed
correctly
and
we
don't
tell
you
how
to
send
back
any
message
or
any
kind
of
indicate,
and
then
it
was
processed
correctly.
B
D
A
D
A
I
guess
that
maybe
we
need
clemens
on
here
since
it
since
he
wasn't
me
not
there,
but
I
interpreted
sentences
like
this
to
say
that,
yes,
crowd
events
can
be
transferred
over
AC
responses.
But
that's
not
quite
excuse
me.
The
same
thing
is
saying
that
that
an
event
that
we
are
defining
cloud
events
as
responses
to
cloud
events
so
resemble
the
request
could
have
been.
A
D
A
D
D
C
D
F
A
D
B
B
That
seems
to
be
very
much
left
to
an
STK
writer
as
to
how
he
wants
to
he
or
she
wants
to
represent
that
and
I
think
that's
where
I'm
struggling
with
this
as
well,
because
it
seems
to
me
that
if
I
was
writing
an
SDK
for
an
HTTP
transport,
I
could
choose
to
batch
stuff
up
and
send
it
in
one
operation.
Yeah
I
could
choose
to
do
it
asynchronously
or
synchronously
or
whatever
I
mean
I.
Don't
think
we
placed
it.
The
specs
don't
put
any
commentary
around
an
upstream
person.
B
A
Program
is
also
wondering
whether
this
is
with
the
right
words
whether
this
is
not
necessarily
our
problem,
in
the
sense
that
if
you
have
two
systems
today,
they're
trying
to
exchange
events,
especially
in
the
binary
format,
right
where
connivance
is
meant
to
just
be
extra
sprinkling
of
metadata.
It's
not
meant
to
be
a
complete
reformat
of
stuff.
So,
if
you
have,
two
systems
are
talking
to
another
and
they're,
transferring
events
back
and
forth
well
as
an
extra
metadata
to
those
events
and
that's
great
everything
works,
but
the
minute
if
I
got
batching.
A
If
the
current
mechanism
that
they're
using
to
transfer
those
events
doesn't
already
support,
batching
I,
don't
think
they're
going
to
add
it
because
of
us.
So
that
means
to
me
that
the
if
they're
going
to
do
batching
they
would
have
already
supported
it,
which
means
they
would
have
already
solved
this
problem
themselves
and
the
fact
that
there's
tagging
out
extra
metadata
in
there
with
the
cloud
event
attributes
is
almost
irrelevant
or
it
doesn't
impact
this
problem
space.
Is
that
make
any
sense,
except.
D
D
A
That
is
true,
okay!
Well
tell
you
what
I
don't
think
we're
necessarily
here,
but
I
think
the
lot
of
interesting
points
are
brought
up.
So
maybe
we
should
do
is
just
try
to
force
the
discussion
in
this
issue.
It's
got
opened
and
who
knows?
Maybe
you
didn't
that
result
would
be:
we've
really
removed
batching
and
say:
if
you
want
to
do
it
fine,
but
you
know,
use
whatever
batching
mechanism
you
would
have
included
normally,
even
if
you're
using
cloud
events.
A
But
if
there's
nothing
else,
I
think
to
address
God's
concern,
we
should
only
say
what
to
do
for
responses,
slash
errors,
and
maybe
the
answer
is
we're
gonna
say
nothing,
but
then
we
should
consist
ly,
say:
someplace,
we're
not
gonna
touch
that
subject.
I
just
want
something
and
I
just
want
people
who's
reading
or
reading
our
spec
and
primer
to
know
whether
we
purposely
chose
that
to
work
on
something
or
we
just
forgot
and
I.
Don't
want
them
to
think.
We
forgot.
Okay.
A
That'd
be
great.
Thank
you.
Jim
I
appreciate
that
okay
I
see
where
were
we
oh
yeah,
so
going
back.
Please
look
at
the
list
of
0.3
PRS
I
believe
that
there
is
my
list,
I
think
I
missing.
Let
me
know
other
than
that.
I
think
we're
at
the
end
of
the
agenda.
You
guys
just
have
lots
of
homework
to
do
in
terms
of
reviewing
stuff.
That's
out
there.
So
please,
when
you
get
a
chance
review.
Those
in
particular
clemens
PR
is
a
really
really
big
one.
Please
look
at
that.