►
From YouTube: CNCF Serverless Working Group 2020-10-08
Description
CNCF Serverless Working Group 2020-10-08
A
We
actually
just
upgraded
to
google
mail
corporate
wise.
All
the
cncf
meetings
got
dropped
off,
oh
no,
it's
kind
of
funny.
Actually
it
was
like
hey
so,
but
it's
you
know
it
happens
when
we
it's
not
uncommon
when
mails
services
merge
or
change,
and
things
like
that
for
something
to
get
dropped
off
and
most
of
the
external
meetings
anyways,
that's
tmi,
but
so
I
had
to
go
back
and
read
the
notes
make
sure
I
can
get
in
correctly
yeah.
A
C
A
D
B
C
E
C
D
F
F
D
G
B
G
G
B
B
B
D
B
D
B
Don't
we
go
and
get
started,
it's
three
after,
let's
see
how
many
people
18.
all
right,
any
other
or
any
anything
from
the
community,
you
want
to
bring
up
right
just
a
reminder.
We
do
not
have
the
sdk
call
this
week
this
week
we
have
the
discovery
interrupt.
Call.
I
haven't
seen
anything
going
on
with
the
dock
itself,
so
that
might
be
a
quick
call
so
be
thinking
about.
If
there
is
something
you
guys
want
to
talk
about
there,
I
don't
see
tmr
on
the
call
and
I
don't
think
offline.
B
B
B
B
Given
the
spec
is
so
new,
I'm
inclined
to
say
let
it
in
and
we
work
through
pr's
to
fix
it.
I
did
implement
this
so
that
that
was
a
lot
of
the
driving
force
behind
some
of
the
changes
I
made
as
I
was.
As
I
was
doing,
the
pr
I
mean
to
be
honest.
If,
even
if
you
go
so
far
as
to
say
screw
it,
we
don't
want
to
do
imports
at
all
or
anything
like
that.
We
want
to
rip
it
all
out,
I'm
okay
with
that.
Eventually,
I
just
I
just
feel
like.
H
E
B
B
D
N
N
B
B
Use
this,
do
you
feel
comfortable
scott
us
merging
it
without
people
having
played
with
it?
Actually,
let
me
back
up-
that's
probably
not
correct
assumption
so
so
slinky,
you
wrote
this
up.
Have
you
actually
coded
it
up
and
verified
from
a
coding
perspective
that
everything
sounds
right,
of
course,
of
course,.
N
B
N
I
just
took
the
there
is
a:
there
is
a
sample
in
the
sdk
javascript.
If
you're
going
to
read
me,
I
wrote
it.
There
is
a
sample
in
the
sdk
javascript
that
already
basically
implements
this,
except
for
the
sub
protocols.
Part
and
I
implemented
the
subportable
spar
and
it's
like
five
lines
of
code,
so
cool.
N
M
N
M
Yeah,
well,
I
think
he's
sort
of
right.
I
mean
we,
we,
you
know
from
an
atp
perspective,
there's
a
web
hook,
spec,
which
sort
of
tells
you
you
know
how
to
handle
statuses,
and
I
assume
that
when
the
mqp
binding
was
written,
there's
sort
of
this
underlying
assumption
that
you
know
amqp
is
going
to
tell
you.
You
know
when
stuff
got
delivered
or
not,
but
I
think
does
that
need
to
be
made
clear.
That
is.
This
is
like
just
a
fire
and
forget
protocol,
or
am
I
overthinking
it.
N
M
B
B
I
think
I
opened
this
one
because
of
a
comment
I
think
scott
may
have
made
on
a
previous
phone
call,
which
is:
should
the
epoch
value
actually
be
global
and
not
just
specific
to
one
particular
service
so
that
we
can
do
something
like
query
a
discovery,
endpoint
and
say
give
me
all
the
services
that
have
been
updated
since
a
particular
epoch
value
and
obviously
that's
only
going
to
work.
If
you
have
sort
of
an
increasing
epoch
value,
that's
goes
across
all
services
and
isn't
just
local
to
one
particular
service.
B
I
actually
like
this
idea
a
lot.
I
don't
think
it's
a
huge
burden
because,
because
it
does
require,
even
though
it
does
require
some
sort
of
locking
or
consistency
mechanism
across
all
the
services,
I
don't
think
it's
that
big
of
a
challenge
for
people
to
have
a
an
ever
increasing
number
across
them
all.
But
what
do
people
think
good,
good
idea?
Bad
idea
need
more
time
to
think
about
it.
B
E
B
B
If
you
have
a
ring,
you
would
have
to
sort
of
synchronize
the
epochs
across
the
whole
ring
or
the
height
the
the
next
available
or
the
highest
epoxy
across
all
the
ring,
and
I'm
not
sure
that's
true,
because
with
the
pr
that
we
just
merged
of
mine,
of
the
mass
import
thing,
I
specifically
say
when
you
import
something
the
epoch.
Value
gets
reset
based
upon
what
that
de
wants
to
set
it
to
you,
don't
retain
the
epoch
value,
so
I
don't
actually
think
you
need
consistency.
Acro
of
epochs
across
all
of
the.
B
E
B
B
E
E
Yeah
well
so
to
give
more
context
for
the
group
what
I'm
trying
to
do.
What
I
would
like
to
do
with
this
sp,
the
two
specs
of
discovery
and
subscription
is
to
be
able
to
do
upstream
and
downstream
upstream
subscription
propagation,
so
that
I
have
a.
I
have
a
complex
system,
that's
delivering
events
with
subscriptions
onto
it
as
new
subscriptions
get
added
it
propagates
the
the
fact
that
it
there's
now
a
requester
of
a
certain
filter
downstream
to
the
upstream
producers.
E
E
O
E
K
B
E
B
B
How
useful
is
that
scenario?
I
thought
it
was
useful,
but
if
it's
too
difficult
to
do,
then
we
can
drop
it.
I
just
thought
it
was.
I
thought
that
was
kind
of
an
interesting
thing
to
do,
for
somebody
who
wants
to
sort
of
monitor
an
endpoint
and
they're
not
doing
it
through
a
moderate
discovery,
endpoint
but
they're
not
doing
it
through
notifications.
E
I
think
we
should
punt
on
that.
To
be
honest:
let's
get
it,
let's
kind
of
get
it
up
and
running,
and
then
once
somebody
comes
back
with
the
problem
of
hey,
I
have
this
discovery.
Endpoint
that
has
this
thousand
services
and
it's
too
difficult
to
understand.
What's
updated,
then
we
solve
this
problem.
B
Okay,
I'm
okay
with
holding
off
and
waiting,
so
we
can
do
that
all
right.
In
that
case,
one
of
the
other
ones
I
thought
was
interesting
was
from
you,
scott.
You
were
suggesting
that
it
might
be
nice
to
have
labels.
Does
that
throw
one
yeah
labels,
so,
for
example,
here
and
as
I
was
looking
through
the
issues
today
to
see
ones
that
might
be
of
interest.
B
It
dawned
on
me
that
this
is
having
horrible
flashbacks
to
buckets
for
extensions
in
the
ce
spec,
and
I'm
wondering
that
was
a
that's
a
terrible
name
for
them.
But
yes,
but
so
technically,
what
is
the
difference
between
this
label
versus
an
extension
of
the
top
level
called
prod
colon
widits
or
what
sets?
E
M
B
B
However,
if
you
look
at
what
how
they're
used
inside
someone
like
kubernetes,
in
particular,
annotations
and
labels,
are
kind
of
done,
the
same
way
where
people
use
them
to
sometimes
change
the
semantics
of
what
goes
on
behind
the
scenes
right
so
they're,
not
simply
a
tagging
mechanism
or
a
searching
thing
right.
Okay,
and-
and
that's
when
I
start
wondering
well,
okay,
you
know
at
what
point
does
who
sits?
B
How
do
you?
How
do
you
distinguish
whether
that's
just
a
tagging
thing
versus
a
semantic
thing
and
to
say,
oh
well,
you
shouldn't
use
a
label
with
a
semantic
thing:
it's
a
property,
then
it
gets
very,
very
fuzzy
to
me
between
the
between
the
line,
which
is
why
we
killed
off
the
entire
content
of
the
buckets
to
begin
with
in
the
ce
spec.
M
It
isn't
the
it's
I
I
get
the
difference
between
see.
I
don't
think
these
of
these
are
tags.
Anything,
that's
not
a
key
and
a
value
is
almost
like.
Well,
it's
a
pair
yeah
tags
for
me
are
just
a
list
of
random
things,
but
at
the
end
of
the
day,
aren't
these
only
of
value
to
the
to
anybody
that
has
to
understand
them?
They
don't
you
know
they
don't
need
to
have
value
for
anybody
else.
B
Right
this
is
this
is
one
of
the
things
that
keeps
right
through
my
mind,
is,
is
any
anything
you
anything
anybody
could
possibly
say
about
what
is
special
about
a
label
versus
what's
special
about
an
extension.
I
bet
someone
could
make
the
exact
same
argument
and
switch
it
and
say
no,
I'm
going
to
use
label
for
exactly
what
you
want
to
use
top
part
before
or
the
other
way
around.
M
B
M
I
There's
always
a
trade-off
to
this,
of
course,
because
then
you're
out
a
little
bit
in
the
wild,
but
it
gives
a
lot
of
flexibility.
That's
what
I
see
and
we
see
it
more
like
your
label
issues.
I
think
in
github.
That's
also
available
right
where
you
say:
oh,
this
is
a
bug
or
this
is
the
to
do
or
this
is
this
and
that
I
see
it
more
that
way,
that
more
in
the
way
of
a
tagging
thing-
and
you
use
it
to
group
or
something
like
that.
E
I
just
wanted
to
point
out
using
labels
and
annotations
and
kubernetes
to
be
stuff
that
should
be
in
the
spec.
Is
an
anti-pattern
shame
on
you
doug
me,
I'm
thinking
about
k
native
yeah.
We
use
it
to
turn
on
and
off
features
of
of
how
to
interpret
things,
but
really
it's
it's
not
a
great
pattern,
because
you
don't
get
there's
a
bunch
of
other
things.
You
don't
get.
E
If
you
change
the
label,
you
don't
know
how
to
compare
the
spec
and
you
don't
know
which
version
of
the
labels
is
reconciled
currently
and
which
one's
failing
is
causes
all
sorts
of
problems.
For
this,
I
think
maybe
a
distinction
we
make
is
that
as
you're
importing
things
you
don't
there's
no
requirement
to
persist
the
labels
from
the
downstreams,
so
those
labels
are
yours
to
be
able
to
understand
that
record
and
they're,
maybe
not
linked
to
the
epoch.
E
B
Okay,
okay:
well,
we
don't
have
a
pr
either
way
on
this
one.
I
just
wanted
to
get
a
sense
of
where
people's
thoughts
are,
because
I
got
to
be
honest
with
you.
I
still
see
them
as
being
no
different
than
extensions,
and
I
know
that
it's
it's
hard
to
think
of
it
that
way
for
some
people,
because
of
the
semantics
that
go
along
with
labels,
but
it's
just
a
name
value
pair
to
me
and
where
it
sits,
doesn't
matter
but
okay.
B
B
B
B
K
Yeah,
the
title
is
a
little
bit
misleading,
but
what
I
got
from
alex
collins
he
reached
out
to
us
and
asked
about
standardizing.
This
is
that
when
you
do
web
hooks
from
github
and
gitlab,
you
get
different
headers
set
that
try
to
authenticate
with
whoever
receives
the
web
book,
and
he
sees
this
across
different
kinds
of
event,
sources
that
they
are
getting
data
from.
I
think
what
he
wants
to
have
is
a
little
bit
of
a
unified
way
of
how
these
sources
are
authenticating.
K
But
the
interesting
thing
that
came
up
here
is
so
alex
collins
is
from
argo
and
argo
uses
an
event
gateway
at
talks,
cloud
events,
and
when
you
use
the
standard
webhook,
you
get
an
https
channel
to
your
receiver.
So
that
is
a
confidential
channel
and
you
can
use
the
jw
the
authorization
token,
the
bearer
kind,
with
a
java
web
token
in
it,
and
that
one
would
authenticate
with
the
receiver.
But
what,
since
they
are
introducing
this
gateway,
or
they
have
this
intermediary?
K
What
it
does
not
guarantee
is
that
from
the
producer
to
the
eventual
consumer
of
the
payload,
nobody
guarantees
that
the
the
content
is
not
messed
with.
So
this
is
something
for
which
you
would
want
a
message
or
payload
signature,
and
I
think
is
this:
problem
might
have
been
solved
with
the
use
of
the
authorization
jwt
url
in
github
and
gitlab.
But
what
we
don't
have
in
cloud
events
is
a
message,
signature
or
any
word
on
how
to
use
signatures
if
usable
from
transport
layers
or
whatever.
K
So
I
wanted
to
bring
this
up
and
ask
how
do
people
feel
about
message
signatures,
or
am
I
maybe
overlooking
something?
Is
there,
maybe
in
the
java
web
token
or
the
ndo
out
specification,
a
way
to
also
introduce
a
signature
that
would
a
signature
of
the
payload
that
is
of
the
the
the
data
transported
in
the
http
web
book.
M
I
I
know
it's
something
that
has
been
nagging
at
me
for
a
while
and
I
think,
there's
a
need.
I
I
I
can
understand
how
we
can
add
signatures.
You
know
when
we're
using,
I
don't
know
the
base64
encoding
stuff.
I
get
a
little
bit
concerned
as
how
we
would
do
signatures
in
json
sort
of
structured
mode.
You
know,
because
that
that's
going
to
be
a
bit
interesting,
but
I
think
it's.
I
think
there
needs
to
be
a
way
to
do
this.
Sort
of
signing
of
verification.
K
In
github,
you
actually
get
both
with
their
own
header,
so
what
they
do
is
they
sign
the
http
message,
payload
and
then
whoever
receives
it
can
check.
With
that
header
received
whether
the
signature
is
correct
in
gitlab,
you
don't
get,
they
get
that
they
only
send
a
token,
but
so
really
about
end
to
end
producer
to
consumer
message.
Signatures
I'm
not
sure
how
to
feel
about
this
either,
but
I
I
thought
it
might
be
an
interesting
topic.
K
There
is
java,
oh
sorry,
sorry
jason
web
signatures
and
it's
used
as
part
of
the
json
web
tokens
to
sign
the
json
the
web
token.
There
is
this
json
signature
standard
and
it
I
think
this
is
a
signature
that
works
on
json.
It
could
be
used
for
structured
mode.
The
only
thing
is
that
when
transport
is
what
is
it,
the
http
structured
transport
where
cloud
events
parameters
are
put
in
the
http
headers
you'd
have
to
recreate
the
json
structure.
First,
before
you
can
verify
the
signature,
it
might
be
a
bit
of
an
overhead.
E
We
so
in
canada
we're
doing
we're
looking
at
similar
ideas,
but
nothing
formal.
Yet,
but
basically
we
want
to
know
who's
who
is
authorized
to
receive
a
certain
event,
and
so
some
way
for
the
producer
to
be
able
to
say
I've
made
this
thing:
send
it
down
a
bunch
of
middlewares
and
the
middlewares
can
filter
based
on
subscriber
authorization.
E
Right,
it
seems
like,
I
think,
with
cloud
events
check.
Summing
might
be
not
a
great
pattern,
because
it
could
change
format
and
it's
still
technically
the
same
message
where
I
could
change
transports
and
it's
still
the
same
message
so
we'd
have
to
think
about
how
how
we
do
signing
for
for
the
consumer,
for
the
consumers
to
understand
a
producer
produce
this
variant
of
the
message.
But
we
allow
for
extensions
to
get
globbed
on
in
middleware
so
like.
How
do
we
deal
with
that?.
B
M
M
That
yeah,
yes,
and
I
think
that's
the
trouble
yeah
there
are
two
levels
of
there
are
two
levels
of
signing.
One
is
the
that
sort
of
envelope
enveloping
sort
of
construct
and
one
is
the
the
data
itself
and,
and
probably
they
need
to
be
done
independently,
because
I
don't
think
I
don't
think
cloud
events
needs
to
make
any
statements
about
how
you
choose
to
sign
or
secure
your
content,
because
that's
really
up
to
you.
But
it's
more
concerned
about
the
the
enveloping
aspects
and
the
attributes.
M
Right
so
they,
the
middle,
is
the
contract,
then
between
the
producer
and
consumer
and
the
intermediary
that
they're
the
ones
that
need
to
know
that
the
enveloping
wasn't
being
messed
about
with
and
the
the
data
is
always
passed
without
interpretation
or
trans
potentially.
And
if
you
want
to
transform
it
between
formats,
then
that
would
have
to
be
a
trusted
party.
And
then
your
relationship
from
a
signing
perspective
would
be
with
that
translator,
not
with
the
end
producer.
M
B
M
I
think
we
need
statements
about
it.
I
think
we
need
principles
or
something
around.
You
know
where
the
responsibility
lies,
if
nothing
else
yeah,
and
if
we
want.
If
we
want
to
ensure
that
those
cloud
event
attributes
have
not
been
messed
with,
then
we
will
have
to
address
it.
I
think
and
sort
of
formalize
how
those
should
be
signed.
I
B
And
getting
agree
interrupt,
I'm
just
having
flashbacks
to
my
web
service
days.
Right
I
mean
we
tried
to
create
these
web
server
specs,
but
everybody
wanted
to
do
security
slightly
differently,
so
we
created
a
framework,
but
there
was
zero
interrupt
but
hey
we
can
claim
interrupt
because
we
all
adhere
to
the
ws
security
spec.
M
But
but
I
mean
do
you
get
to
the
point
where?
Maybe
your
statement
is
simply
you
know
the
the
signing
of
the
payload
is
is
out
of
scope.
You
know
that
that's
somebody
else's
problem
and
you
have
a
trust
relationship
with
the
end
point
that
you're
delivering
events
to,
and
it's
that
trust
relationship
that
implies
that
data.
Those
headers
are
not
going
to
be
mutated
along
the
way
and
it
sounds
very
hand
wavy,
but
it
I
think
you
need
to
make
a
statement
one
way
or
the
other
and
say
it's
either.
B
C
B
C
O
Yeah,
so
I
remember
that
also
in
the
early
days,
I
at
one
point
asked
if
the
context
attributes
may
be
modified
by
intermediaries,
and
I
think
just
for
that
discussion-
we
introduced
the
term
intermediary
originally
and,
and
so
the
result
was
that
yes,
that's
possible,
and
if
you
want
to
allow
this
so
why?
Why
would
you
now
create
a
signature
mechanism
to
prevent
this.
K
O
O
So,
by
the
way
the
spec
has
a
section
about
security.
It's
just
mentioning
that
the
context
attribute
shouldn't
contain
sensitive
information,
because
at
that
time
we
I
think
we
we
always
thought
that
just
the
payload
would
be
encrypted.
But
it's
not
really
about
doesn't
really
touch
the
signature
topic.
K
E
Isn't
that
why
we
introduced
data
ref
so
that
we
could
delegate
encryption
to
a
second
party
just
in
case
some
stream
of
events
get
replayed?
You
get
this
trouble
of.
If
you
encode
the
key
in
the
in
the
cloud
event,
then
you
don't
understand
how
to
like.
You
can't
do
key
rotation
if
you
have
a
historical
event
stream.
K
M
E
B
B
Okay,
so
we're
almost
out
of
time,
but
back
to
the
issue,
is
there
somebody
who
actually
wants
to
try
to
take
a
next
step
on
this,
or
is
it
still
unclear
whether
you
want
to
do
anything
or
not
just
trying
to
figure
out
and
well
since
you're,
the
one
that
mentioned
this?
Does
somebody
actually
want
to
like
create
a
pr
add,
more
discussion
to
the
issue?
How
do
you
guys
want
to
move
forward
on
this.
K
O
O
Yeah,
I
just
remember
that,
while
preparing,
I
think
the
demo
in
for
for
barcelona
and
during
that
debugging
session
the
night
before
that
demo,
we
encountered
some
problems
and
it
was
originally
due
to
some
null
values
in
for
attributes,
and
then
we
had
that
discussion
how
to
handle
it
and
that
an
attribute
not
being
present
would
be
the
same
as
no
value
and
just
as
a
distinction
from
the
empty
value.
Of
course,.
O
M
B
B
M
N
If
you
pick,
for
example,
http
address
hp
address
cannot
be
empty
so
that
this
doesn't
apply
to
to
an
event
that
comes
from
http,
so
in
general,
in
the
sdks
like
in
golang,
we
don't
make
any
distinction
in
rust
and
in
java
we
make
the
distinction,
but
only
because
the
language
allows
us
to
do,
but
you
will
never
get
an
empty
attribute
in
the
raster
sdk.
For
example,
when
you
receive
the
event
from
http.
N
A
N
M
M
E
B
Okay,
so
I'm
going
to
call
time
on
here
because
I
apologize,
I
didn't
realize
it
was
after
the
top
of
the
hour
already.
So
let
let's
try
to
continue
the
discussion
in
the
issue
itself,
because
I
do
think
we
need
to
kind
of
resolve
this
one
way
or
the
other
is
a
little
bit
ambiguous
and
okay
bye
scott.
So
thank
you
all
for
joining.
I
guess
there's
one
whole
lot
of
in
here
before
we
let
people
go.
I
think
I
only
missed
one
person
asashi.
Are
you
there?
No,
they
left.
B
B
That's
fair
yeah.
I
didn't
have
anything
myself
either,
so
we
can.
We
can
just
cancel
the
call
okay.
In
that
case,
we
will
cancel
the
call.
Thank
you
everybody
for
joining
today
and
please
do
comment
on
some
of
the
issues
we
talked
about
here.
Try
to
get
a
discussion
going,
whether
you
want
to
close
the
issue
or
someone
wants
the
pr.
Please
try
to
get
some
discussion
going
all
right
and
with
that.
Thank
you.
Everybody
for
joining
I'll
talk
again
next
week,
thanks.