►
From YouTube: CNCF Serverless WG 2020-06-11
Description
CNCF Serverless WG 2020-06-11
A
A
A
A
B
A
A
D
A
Well,
welcome
if
you'd
like
to
be
associated
with
a
company,
because
we
do
track
participation
on
a
company
basis
or,
if
not,
if
you're,
just
an
individual,
but
either
either
way.
If
you
want
to
be
associated
with
a
company
just
either
added
it
to
the
agenda
and
your
attendee
list
here
next,
your
name
or
in
the
zoom
chat
and
all
add
for
you.
Yeah.
D
A
Thank
you
property
there,
okay
ray
are
you
there?
Yes,
I
am
excellent.
Oh
no,
that's
not
someone
else.
Go
flying
by
Oh
ginger.
A
A
D
A
D
A
D
C
D
A
Normal
either
no
microphone
yet
mm
all
right.
Some
of
them.
A
All
right,
3
after
why
don't
I
go
ahead
and
get
started?
He
actually
might
be
a
very
short
call
today.
So,
let's
see
Before
we
jump
into
anything
community
time.
Is
there
anything
from
the
community
that
people
would
like
to
bring
up?
That
is
not
on
the
agenda.
C
A
F
C
Is
my
first
meeting
and
you
know,
confluent
has
leveraged
the
cloud
events
as
a
format
that
we
use
to
send
our
audit
logs
for
some
of
our
new
features.
However,
we
got
some
new
efforts
that
are
ongoing
and
perhaps
kind
of
gonna
see
a
way
to,
hopefully
maybe
take
some
other
work,
we're
doing
around
schemas
and
looking
for
a
project
to
hang
it
on.
C
So
I've
just
started
to
take
this
on
and
so
I'm
kind
of
here
to
get
some
experience
but
and
hear
what,
where
everything's
going
but
mainly
may
would
like,
or
maybe
in
the
future
would
like
to
bring
something
up
as
a
potential
contribution
that
we
could
do
as
well
for
taking
things
further
in
the
future.
So
ya.
A
Know
welcome
in
case
you
haven't
noticed.
Clemens
from
Microsoft
has
proposed
a
scheme
of
registries
type
thing
since
you
mentioned
schemas.
You
may
want
to
take
a
look
at
that
one
see
if
that's
of
interest
you
there's
a
PR
open
for
yet
I.
Don't
think
we've
accepted
the
doc
yet,
but
I
expect
it
to
go
in,
but
there's
a
peer
I.
Don't
take
a
look
at
that
right
me
at
the
top.
Is
people
typing
up.
F
I'm
pretty
new
to
the
code
as
well,
so
I'd
like
to
introduce
myself
I'm
working
for
Adobe
and
the
technology
department,
and
we
are
very
interested
on
said
that
has
two
picks,
of
course:
related
war
on
product,
API,
sensibility
and
and
providing
some
value
on
top
of
that
of
all
different
products.
So
nothing
perranoski
here
and
we
are
really
interested
in
today
in
the
7s,
workflows,
specifications
and
so
on.
As
next
research
topics.
F
D
A
A
Okay,
normally
we
do
have
an
SDK
call
scheduled
right
after
this
one.
Whenever
this
one
ends
worst-case-scenario
top
of
the
hour,
however,
we
have
no
agenda
items.
So
if
you
have
something
you'd
like
to
bring
up,
please
add
it
to
the
agenda
before
the
end
of
this
call.
Otherwise
you
may
just
cancel
that
call,
but
there's
no
agenda
all
right
Marie.
Do
we
like
to
update
the
group
anything
going
on
relative
to
the
workflow
stuff
yeah.
B
B
So
we
have
moved
most
of
the
documents
there.
Also
thank
you
Doug
for
helping
us
with
setting
up
the
website,
so
we
have
started
that
as
well.
It's
service
workload
at
I/o
and-
and
we
just
have
initial
website
up
and
then
we're
working
right
now,
not
improving
it.
As
far
as
sandbox
project
I
was
told
that
in
the
next
meeting
that
the
cig
meeting
at
the
end
of
the
month,
they
will
discuss
this
and
make
a
decision
on
it.
So
we're.
B
To
to
seeing
seeing
what
the
outcome
of
that
is,
hopefully
is
positive
and
finally,
it's
kind
of
off
topic,
but
we
were
working
on
a
service
work
for
group
and
said
creating
some
t-shirts
with
our
logo
and
I
was
thinking.
You
know,
of
course,
with
cloud
events.
You
know
we're
being
tied
to
it
so
much
and
if
you
guys
are
interested
I'll
be
more
than
willing
happy
to
create
some
t-shirts
with
the
cloud
events
logo
on
it.
It'd
just
be
black
shirts
with
the
logo
with
the
white
text.
B
So
if
you
guys
want
to
somehow
we
can
set
up
some
sort
of
document
where
everybody
can
put
their
size,
preference
and
I
can
in
the
next
month
or
so
see
about
creating
those
and
shipping
them
out
and
it's
free
of
charge.
Of
course
everything
I'll
be
happy
to
do
that
for
the
community,
so
yeah,
that's
it.
That's.
A
A
A
E
A
E
A
A
A
G
G
There
was
one
of
those
suggestions
that
I
think
Alex
had
made
was
to
move
away
from
using
a
map
structure
to
using
a
repeated
field,
and
my
concern
I
was
gonna
put
in
a
PR
about
that
is
that
it
would
essentially,
if
I,
remember
correctly.
That
then
allows
you
to
would
allow
you
to
have
the
same
attribute
represented
more
than
once,
whereas
a
map
would
stop
that
happening.
G
So
that
was
one
comment
and
a
nacho
if
it
was
Alex
or
somebody
else
had
asked
around
you
know
formally
declaring
you
know
the
optional
attributes
that
we're
aware
of
and
I
believe
we
touched
on
that
in
last
week's
call
where
the
discussion
really
went
around
yo.
We
could
get
ourselves
into
a
situation
where
you
know
in
I.
Don't
know
V
1.3,
we
add
a
new
optional
field
and
then
the
the
schema,
the
v1
schema,
would
sort
of
be
a
little
bit
inconsistent.
G
Then,
because
you
have
some
optional
fields
that
were
formally
defined
and
some
that
you'd
have
to
access
through
the
map
or
or
through
repeated
fields.
So
the
decision
as
I
understood
it
as
the
group
was
to
say:
okay,
no,
let
let's
just
stick
at
the
the
major
version
and
and
declare
all
the
sort
of
required
attributes
that
we
know
I.
D
If
you
had
like
the
the
data
schema,
what
is
it
URI
and
actually
in
any
type?
It's
also
a
URI
where
you
actually
define
the
type,
so
it's
very
aligned
there
as
a
string
and
if
you
would
then
have
like
the
second
fields
like
a
binary
data,
where
you
could
put
anything
a
string,
a
binary
and
having
a
message
in
proto
encoding,
it's
kind
of
the
same.
It
does
really
really
much
well
with
any
time
yeah.
F
G
Yeah
I
mean
so
I
guess:
I
was
taking
my
lead
a
little
bit
from
and
I
understand
on
the
wire.
Obviously,
everything
is
a
byte
stream.
When
we
look
at
Jason
the
way
we
defined
the
json
schema
for
a
cloud
event.
You
know
we
allow
the
data.
If
it's
binary,
it
gets
encoded
into
the
base64
string
property.
G
F
G
We
sort
of
created
this
sort
of
acceleration.
If
you
know
you're
carrying
JSON
content,
it
just
sort
of
becomes
one
with
the
entire
structured
event
and
treat
it.
What
I
read
the
way
my
brain
was
going,
was
being
much
more
sort
of
rigid
in
in
the
spec
and
saying
no
you've
either
got
to
do
this
or
this
or
this,
and
it
becomes
very
apparent
what
those
contents
are.
You
know
just
by
you
could
introspect
proto
itself
and
say
well,
was
yo?
Is
the
field
of
byte
stream,
or
is
the
field
text
or
is
the
field?
G
You
know
a
proto
message
so
we
have
to.
We
don't
have
to
rely
as
much
on
the
optional
attributes
to
sort
of
make
that
stuff
work.
That
was
there
was
where
my
head
was
coming
from
in
that
one,
but
I'll
put
these
comments
in
the
PR,
but
would
you
buy
into
the
the
removal
of
optional
attributes
Alex?
Do
you
sort
of
see
the
the
rationale
behind
that
yeah.
D
G
G
I
mean
I
I,
think
I
understand
where
you're
going.
I
it's
much
more
in
line
with
a
sort
of
transport
header
in
idaho
HTTP,
you
know
AMQP
or
whatever
yeah
all
right,
so
Doug
I
think
the
takeaway
for
me
is
to
sort
of
tweak
the
my
commentary
a
bit
more
and
and
go
from
there
and
then
Alex.
If
you
can,
you
know
sort
of
take
a
look
after
I've,
tweaked
I'm,
not
sure,
there's
much
tweaking
to
do
now.
I
think
we
may
be
getting
to
a
you.
A
All
right
moving
on,
thank
you
Jim,
okay,
so
Klaus
is
not
here
today
and
I.
Don't
think,
there's
been
any
change
to
this
PR,
but
I
believe
it's
still
work
in
progress.
I
think
there's
still
some
discussions
about
whether
source
templates
should
be
on
the
service
level
or
on
the
type
level.
I
think
it
needs
been
the
type
level,
but
he
hasn't
moved
it
yet
so
I'm
not
quite
sure
where
his
thinking
is
on
that,
but
I
think
in
general.
Last
time
we
talked
about
this.
A
Everybody
seemed
okay
with
a
general
idea
of
having
some
sort
of
template
thing
in
there.
So
if
you
have
any
questions
or
concerns
about
this,
please
jump
in
on
the
PR.
I'm
gonna
try
to
nudge
Klaus
to
get
this
in
there
or
make
it
a
non
work
in
progress
thing
for
next
week's.
When
you
try
to
resolve
it
one
way
or
the
other.
Okay.
A
Next
is
the
one
item
we
actually
may
be
able
to
approve
today.
So
last
week,
I
showed
a
gist
that
I
put
together,
which
just
walked
through
a
very
basic
flow
of
how
I
thought
the
discovery
spec
was
supposed
to
work
with
the
subscription
spec
and
everybody
seemed
to
say
that
was
Lisa
heading
in
the
right
general
direction,
which
is
good.
So
what
I
did
is
I
turned
that
into
a
rough
draft
of
a
primer
and
start
talking
about
some
of
the
very
is
use
cases
of
why
we're
doing
we're
doing.
A
This
is
a
problem
for
both
the
discovery
and
the
subscription
spec
and
then
I
talked
about.
You
know
some
examples
some
example
workflows
and
stuff.
Basically,
as
I
said,
it
just
took
the
gist
and
turned
it
into
a
document
itself
as
a
start
of
primer,
I,
don't
think
I
introduced
anything
very
controversial.
At
least
now
we
have
a
starting
point
for
people
to
add
more
comments
and
text
here
to
help
you
know
expand
this
thing.
A
A
Okay,
now,
as
everybody
knows,
this
is
just
the
first
draft
so
that
we
can
lots
lots
of
changes
going
forward.
But
since
it
has
been
out
there
for
at
least
two
days
now,
is
there
any
objection,
then,
to
merging
this
as
a
starting
point
for
a
primer
that
we
can
then
edit
on
going
forward
with
additional
PRS.
E
A
Okay,
now
clemens
updated.
His
schema
registry
proposal
unfortunately
did
it
yesterday,
which
means
it
hasn't
been
out
there
long
enough
for
people
to
review
it
to
approve
it,
but
I
did
want
to
bring
it
up
here
too,
to
draw
it
to
people
to
tend
to
draw
it
to
everybody's
attention,
so
you
could
go
ahead
and
review
it.
He
made
a
lot
of
really
good
changes.
I
did
review
it
this
morning.
It
seemed
like
a
good
flow,
at
least
from
my
perspective.
A
What
I'd
like
to
do,
though,
is
offline,
is
poke
him
too,
if
he
wants
to
make
any
changes
to
make
them
before
next
Tuesday
so
that
we
can
possibly
approve
this
and
get
a
first
draft
out
there
in
the
repo.
If
he
makes
additional
changes
after
Tuesday,
fortunately,
we
probably
won't
be
able
to
merge
it
because
of
the
time
limit
type
stuff.
A
A
Spec
I
think
a
lot
of
it
is
just
more
clean
up
more
than
anything
else,
I
find
there
were
some
things
there,
a
little
bit
hard
for
me
to
follow
or
there's
like
some
duplicate
definitions
in
there
and
I
wasn't
quite
sure
whether
the
spec
was
ready
to
be
implemented.
Yet
from
just
reading
the
document
itself,
so
I
basically
sat
down
yesterday
and
went
from
front
to
back
modifying
everything
that
I
could
think
of.
A
That
would
make
it
easier
for
me,
as
somebody
want
inland
this
thing,
to
actually
get
my
job
done
as
I
said
it
just
put
it
in
there
last
night.
So
obviously
it's
too
soon
to
merge,
but
please
take
it.
Take
a
moment
to
look
it
over
when
you
get
a
chance,
as
I
said,
I,
don't
think
I
changed
very
much
from
a
semantic
perspective.
It's
more
just
more
clean
up
more
than
anything
else,
but
I'm
happy
to
answer
any
questions
now.
A
A
A
A
Okay,
in
that
case,
miss
little
check
any
last
chance
for
anybody
to
add
anything
to
the
SDK
call
Oh
Eric.
Do
you
wanna
see
something
I'm
here?
Oh
oh
I
missed
you
I'm,
sorry,
I
know,
I
put
you
on
the
list.
There
you
go.
Thank
you
Eric.
Okay,
any
topics
for
the
SDK
call.
Otherwise
we
will
end
this
call
here
and
skip
the
SDK
call
going
once
all
right.
We're
done.
That's
gotta
be
record
time
for
both
calls.
Then
all
right.
Thank
you.
Everybody!