►
From YouTube: CNCF Serverless Working Group 2020-07-30
Description
CNCF Serverless Working Group 2020-07-30
B
C
D
C
D
A
E
C
D
B
D
So
for
those
of
you
who
are
adventurous
in
two
days
time,
clemens
and
I
are
going
to
be
showing
our
cloud
events
presentation
we're
going
to
call
it
for
the
I
keep
calling
it
kubecon
china,
but
it's
actually
not
kubecon.
It's
one
of
the
cons
in
china
by
the
linux
foundation.
If
you
are
so
inclined
to
join
it's
the
time
zone
is
more
friendly
for
europeans,
I
believe
for
me
it
will
be
3
30
eastern
time
in
the
morning,
but
I
thought
I'd
mention
it.
D
A
D
D
D
All
right
moving
forward,
no
sdk
call
this
week.
We
do
have
an
agenda
for
next
week,
though
so
feel
free
to
take
a
look
at
that
and
comment
on
it.
If
you
have
anything
to
say
to
that,
I
think
grant
added
a
whole
bunch
of
items
there,
workflow
tim
or
anything.
You
want
to
bring
the
group
up
to
speed
on.
H
D
D
All
right,
in
that
case
oops,
I
think
I
already
have
this
one.
Unfortunately,
I
don't
see
scott
now.
Originally
he
did
have
a
change
in
this
one.
This
was
just
he
was
going
through
the
spec,
actually
a
couple
different
yeah.
This
is
just
to
discover
respect.
He
was
going
through,
discover,
respect,
there's
a
couple
of
typos.
He
did,
as
of
yesterday,
actually
had
a
slight
wording
change
in
there,
but
he
dropped
that
or
it
had
a
potentially
non-typo
type
change
in
there.
He
dropped
that.
D
So
now
it
is
just
technically
just
typos
in
here.
I
think
these
are
all
mindless.
Otherwise
I
would
have
reproved
it
didn't
have
other
change,
but
he
did
any
questions
on
this.
One,
like
I
said,
I
think
it's
just
typos
more
than
anything
else
like
subscription.
Url
is
probably
the
biggest
one
that
I
goofed
on.
D
D
D
D
D
I
believe
this
was
in
response
to
an
issue
that
grant
opened
where
there's
some
confusion
around
whether
batching
is
a
mode
versus
something
else.
So
this
was
his
attempt
at
trying
to
fix
the
wording.
Let's
see
if
I
can
get
the
key
changes
here,
so
I
think
there
are
two
main
changes
he
had
one
is
this
section
right
here
I'll
give
you
folks
a
chance
to
read
that
yet.
D
D
D
G
G
Well,
protocol
buttons
typically
use
binary
mode
messages
directly
on
the
wire
structure.
Mode
messages
are
often
embedded
in
the
envelope.
That's
that's
a
little
cumbersome
in
terms
of
wording.
Also,
I'm
not
sure
whether
you
know
if
you
have
a
structured
message
in
json
and
that's
the
json
object.
I'm
not
sure
whether
the
json
object
counts
as
an
envelope.
D
G
D
D
D
D
All
right
back
to
id
discussion
now,
I'm
not
going
to
try
to
speak
for
klaus
because
he's
on
vacation.
However,
I
will
say
that
in
a
private
slack
message-
and
you
might
have
to
trust
me
on
this-
he
did
say
that
he
understood
it
a
little
better,
because
he
was
looking
at
a
previous
specification
that
he
and
I
both
worked
on
called
the
service
binding,
spec
or
I'm
sorry,
open
source
broker
api,
which
I
think
has
a
similar
concept
in
there,
and
so
we
didn't
necessarily
come
right
out
and
say:
doug
you're
right.
D
This
is
wonderful.
He
did
at
least
say
he
understands
better
why
it's
needed.
So
I'm
not
saying
that
he's
endorsing
this.
Yet
he
got
he
could
speak
for
himself,
but
I
do
want
to
put
that
out
there.
So
I
did
go
through
and
make
some
changes
here.
Based
upon
last
week's
conversation
in
particular,
I
tried
to
make
it
clear
that
it
is
unique,
but
so
is
name
name
is
unique
for
a
slightly
different
purpose.
It's
more
human
readable!
D
It's
only
unique
within
the
scope
of
this
discovery
endpoint,
whereas
this
one
is
globally
unique,
so
that,
for
example,
if
you
wanted
the
same
one
to
appear
in
different
discovery,
endpoints,
you
can
be
guaranteed
that
the
id
is
the
same
across
them.
Let's
see
what
else
I
put
in
here-
oh,
I
said.
Typically,
it
is
defined
by
the
discovery,
endpoint
itself
or
the
one
of
the
components
behind
there.
D
I
didn't
want
to
make
it
a
hard
requirement
that
that's
true,
because
I
want
to
be
able
to
make
sure
that
people
can
do
some
sort
of
import
type
of
action
where
obviously,
then
it's
being
provided
to
the
discovery
endpoint.
I
thought
that
was
an
important
use
case.
Talk
a
little
bit
about
why
it's
meant
why
it's
there
at
all,
so
that
the
clients
can
have
some
consistency
in
terms
of
knowing
what
this
entity
is.
D
Excuse
me,
and
I
didn't
want
to
get
into
a
really
weird
race
condition
where
the
server
changes,
but
then
how
do
you
make
sure
all
the
clients
get
updated?
Does
the
server
have
to
support
both
the
old
and
new
versions
of
the
url
over
time?
It
just
seemed
easier
if
we
made
it
the
static
url,
be
the
uid
itself.
Now,
that's
not
to
say
if
we
wanted
to
support
both
the
name
and
id
that's
possible.
I
just
got
a
little
bit
worried
there,
because
what?
D
B
B
D
So
I
made
it
a
little
bit
clearer
that
down
here
you
can
search
for
it
by
name.
I
thought
matching
wasn't
very
descriptive
right
because
you
don't
know
what
you're
matching
out
so
that
okay,
let's
make
it
a
little
clearer
and
I
thought,
okay,
you
could
put
in
the
name
there.
So
here
you
can
find
things
by
the
human
readable
name.
If
you
want
it's
just
instead
of
a
slash,
it's
a
question
mark.
Basically
what
I'm
trying
to
say
there
right
so.
B
The
technical
thing
there
so
so,
then,
is:
is
your
model
basically
sort
of
akin
to
dns
right?
I'm
going
to
use
I'm
going
to
use
a
very
generic
label
to
use
a
different
term
to
go,
look
something
up,
and
then
what
I
get
back
is
a,
I
guess,
in
your
term,
a
static
url
for
the
lifetime
of
that
service.
In
that
discovery,
endpoint.
D
If,
yes,
if,
if
that
is
what
you
want
to
do,
because
even
though
it
vanished
yes
now,
that's
not
to
say,
obviously
if
someone
wants
to
store
in
their
data
store
a
url
that
has
the
query
parameter
thing
right,
so
services
question
mark
name,
equals
foo
they're,
welcome
to
store
that
as
well
and
that
way
they'll
you
know,
they'll
discover
even
faster
than
it's
gone.
You
know
the
url
store
is
up
to
them.
D
It
just
happens
to
be
mentally
linked
because
it's
version
one
versus
version,
two
kind
of
thing
I,
and
here
I
tried
to
talk
about
how
whether
they
use
a
new
id
for
that
or
they
replace
the
existing
one
is
an
implementation
choice.
I
don't
think
we,
as
authors
of
this
specification,
can
dictate
you
know
version
1
version.
2
must
be
completely
different
services
versus
no
same
service
and
you're
just
killing
off
the
old
one,
and
you
reusing
the
same
id.
D
D
F
D
D
D
D
J
D
J
D
D
E
D
Okay,
I'm
not
getting
any
objection
we'll
vote
on
that
one
next
week.
So
please,
when
you
get
a
chance
to
review
that
one,
and
that
is
technically
it
this
pr.
I
know
lance.
You
had
a
few
comments
in
there.
I
don't
think
they
were
controversial
necessarily,
but
I
know
slinky's
on
vacation
today,
so
we
didn't
get
a
chance
to
make
those
changes.
So
we
have
to
wait
on
that
one
but
of
the
other
prs
here.
D
Actually,
it's
I'm
still
reworking
the
pagination
one,
I'm
still
trying
to
absorb
people's
feedback
from
that
one,
so
hopefully
I'll
get
that
one
out
next
week.
Hopefully
I
think
these
last
three
might
be
from
slinky
and
he's
not
here.
Actually,
no,
I'm
sorry,
jim
you're,
a
protobuf
one.
Did
you
what's
the
status
of
that
one?
Is
it
still
sort
of
in
the
works.
J
D
E
D
D
What
do
you
have
in
mind?
I
don't
know
I
just.
I
just
feel
a
little
bit
bad
that
we're
focusing
heavily
on
the
schema
stuff.
I
don't
feel
bad
about
the
subscription
api
because
I
feel
like
we'll
get
to
that
once
we
finish
discovery
since
it's
a
natural
progression
yeah,
but
on
this
on
the
schema
stuff,
I
want
to
make
sure
that
you
didn't
feel
like
we
were
neglecting
it
or
something.
So
it
wasn't
something.
No.
G
No,
I'm
not
worried.
I
think
I
think
all
those
things
hang
together
in
in
a
way
and
if
we
get
those
if
we
get
the
discovery,
if
we
give
discovery,
love
now,
then,
and
then
look
at
this
registry,
that's
fine.
I
think
the
folks
who
were
thinking
about
implementing
schema
registry
were
already
reviewing
it.
I
don't
know
how
far
anybody
has
progressed
in
in
terms
of
implementation,
but
given
that
it's
july
coming
up
in
august
and
we're
still
having
people
on
vacation
etc,
I'm
not.