►
From YouTube: CNCF Serverless WG 2021-03-18
Description
CNCF Serverless WG 2021-03-18
A
Sorry,
sorry,
I
didn't
even
recognize
that
I
thought
I
was
just
going
from
one
thing
to
the
other
and
I
I
saw
the
notification
yeah.
Usually,
if
I
see
a
notification,
I
don't
jump
over.
It
then
I'll
forget
that
I'm
late
so
well
you're
much
more
prompt
than
I
am
at
least
for
this
one
you're
ahead.
So.
D
You
guys
done
with
all
the
crazy
frigid
weather.
E
Know
it's
funny,
you
should
ask.
It
was
starting
to
get
really
nice
like
last
week
and
such
and
then
this
week
we
got
down
into
like
what
felt
like,
like
almost
snow
weather,
and
we
have
a
rainy
day
today,
apparently
we
might
be
getting
hurricanes
or
tornadoes
or
something.
Today,
it's
like
crazy.
D
D
It
it
is
schizophrenic,
so
it'll
be
be
nice
and
warm
and
then
like
today
is
the
same
thing.
Overcast
and
you
know
we'll
probably
drizzle
a
little
bit.
E
E
Really
cause
I
gotta
know
from
somebody
saying:
hey
doug,
can
you
do
this
for
me
because
the
guy
they
normally
go
to
is
in
austin
and
he
heard
that
there
may
be
having
some
kind
of
weather
like
snow
or
something
on
there?
But
I
guess
maybe
they
were
mistaken.
G
E
Usually,
I
only
add
people's
names
at
the
end
when
there's
the
possibility
of
a
duplicate,
even
though
we
really
only
have
like
one
david
and
one
john
recently
they're
just
common
names
that
I
I
don't
run
into
it
too
often,
but
jennifer
you're
right.
We
only
have
one
jennifer
so.
F
F
E
C
E
And
lance
you,
you
will
come
off
mute
yet.
E
While
we're
waiting
last
time,
I
checked,
excuse
me
there
were
no
topics
for
the
discovery.
Interop
call
today.
So
if
you
have
any
go
ahead
and
add
it
before
the
end
of
the
primary
call,
otherwise
we're
going
to
have
a
very
short
meeting,
hey
scott.
C
F
E
Started
all
right
three,
after
let's
do
this
thing,
we
have
a
short
agenda
today.
All
right,
let's
see,
I
don't
think,
there's
anybody
to
nag
our
reminders,
our
ais,
okay,
community
time,
anything
from
the
community.
If
you
want
to
bring
up,
that's
not
on
the
agenda.
I
I
I
did
have
one
doug,
I
don't
know
if
it's
relevant
now,
just
related
to
the
correct
handling
of
let's
say
malformed
events
and
I
think
it's
applicable
to
sdk
writers
and
it
and
it's
come
up
in
the
context
of
an
issue
I
found
with
the
java
sdk.
So
I
think
we
need
a
bit
of
guidance
on
expected.
Behaviors.
C
Whatever
works
for
you,
okay,
cool
yep,
thank
you!
So
let's
do
this
actually
hold
on
whoa.
That's
not
what
I
meant
to
do.
E
All
right
moving
forward,
then
we
had
an
sdk
or
we
were
supposed
to
have
an
nc
call
last
week,
but
we
didn't
have
any
topics.
We
skipped
that,
as
I
said,
interrupt
discovery
call
this
week.
If
you
have
a
topic,
please
add
it
to
whoops
the
agenda.
Okay,
moving
forward,
I
guess
I
dropped
it
already.
I
don't
think
there's
anything
less
for
us
to
do
for
kubecon
other
than
remy.
E
I
know
you're
working
on
your
presentation,
so
when
that's
ready
we'll
make
that
available
for
the
group
to
review,
I
think
that's
about
it.
Unless
someone
can
think
of
something
related
to
kubecon,
we
need
to
mention.
E
Okay,
not
hearing
any
timer
anything
you
want
to
mention
from
the
workflows
back.
J
We're
just
still
preparing
for
the
next
release,
hopefully
this
week
and
also
working
on
the
slides
for
our
presentation
for
the
updates.
E
G
Now
tin
had
just
sent
out
a
reminder
that
it
was
do.
I
think
requests
were
due
in
today
right
either
today
or
tomorrow.
I
just
confirmed
with
her
that
she
actually
got
it
because
I
don't
know
if
they
copy
us
on
the
request.
So.
E
Okay
yeah:
I
did
notice
that
and
I
did
actually
double
check
with
them
as
well
to
make
sure
that
they
got
our
request,
so
I
think
we're
all
set
okay
cool.
Thank
you
all
right,
okay,
prs
and
stuff:
let's
go
ahead
and
jump
right
into
it,
so
slinky
europe
first,
I
haven't
noticed
any
updates
here
and,
as
we
talked
about
last
week,
we
were
hoping
to
get
this
one
merged.
E
K
Any
questions
for
next
week
yeah,
I
wanna
just
one
thing
that
now.
K
To
lionel,
and
I
will
work
on
the
grammar
using
the
antelope
format,
which
is
a
pretty
famous
format
and
yeah
while
developing
that,
if
we
find
any
issues
with
the
spec
right.
E
I
don't
see
grant
on
the
call,
so
let
me
go
ahead
and
bring
this
up
and
if
I
remember
correctly,
I
believe
we
talked
about
this
one
last
week
about
possibly
modifying
our
process
a
little
to
make
it
a
little
easier
to
call
out
significant
changes
that
are
worthy
of
a
what's
we're
looking
for
release
notes,
type
of
document
as
we
go
through
the
various
releases,
so
he
actually
made
some
changes
here.
I
think
we
could
ignore
that
for
right
now.
E
I
think
this
is
basically
the
bulk
of
what
he's
suggesting
here
is
to
use
the
the
this
commits
conventional
thingy.
I
think
lance
you
guys
use
this,
and
at
least
the
javascript
sdk,
I
believe,
yeah.
We
do
yep,
okay,
any
questions
or
comments
about
this.
A
E
E
All
right
cool
any
other
questions
or
comments
on
this
one,
the
other
changes.
I
think
this
is
just
indian
thing
to
clean
up
the
table
contents,
and
I
guess
you
just
want
to
do
some
linting
stuff
to
ensure
that
you
actually
follow
the
conventions.
I
think
I'm
not
sure
I
haven't
actually
looked
at
it.
E
E
I
added
this
sentence
here,
so
any
service
previously
turned
to
a
client
that
does
not
appear
in
this
result
can
be
assumed
to
be
deleted.
Okay,
so
I
think
I
think
that's
consistent.
We
talked
about
last
week,
which
was
you
really
have
no
choice
but
to
assume
it's
gone
and
granted
this.
This
has
nothing
to
do
with
the
case
of
you
get
back
some
other
error
condition.
This
is
you
get
back
to
200?
You
get
back
a
list
of
things
and
this
one's
just
missing
right.
E
How
do
I
actually
interpret
that?
So
this
pr
is
about
just
adding
that
one
sentence.
I
do
have
another
pr
which
I
think
may
need
more
time
to
think
about
which
deals
with
the
full
life
cycle
thing
that
we
talked
about
about
possibly
introducing
a
deprecation
type
feel
and
stuff
like
that.
But
this
is
just
about
handle
the
missing
entry
and
a
get
so
any
questions
or
comments
on
this
one.
E
Whoops
all
right,
so
this
one,
I
think,
might
require
a
little
more
thought,
especially
since
someone
made
a
comment
in
there
which
I
have
not
responded
to
yet.
So
I
think
it's
premature
to
merge.
Let
me
hide
the
comments
first,
all
right.
So
what
I
decided
to
do
here
was
to
take
what
I
do.
What
I
consider
to
be
the
simple
approach,
which
was
start
out
with
just
adding
a
removal
time,
and
the
presence
of
this
attribute
in
a
service
description
indicates
two
things.
E
One
is
that
it's
deprecated
and
two
obviously
specifies
the
time
at
which
it
will
be
removed.
It's
not
allowed
to
be
removed
before
that
time,
but
it
can
live
longer
after
that
time.
So
there's
no
guarantee
that
it
will
be
around
anywhere
after
that,
but
you
could
include
it
if
you
wanted
to
or
you
could
live
on
for
a
while.
E
It
makes
notes
the
this
definition
places
no
burden
in
terms
on
what
it
means
for
existing
subscriptions
right,
whether
they're
still
valid
or
not.
I
figured
we
could
talk
about
that
later
if
we
want
to
at
all
or
if,
if
we
even
want
to,
because
that's
a
whole
different
wall
of
wax,
basically
but
anyway,
that's
basically
it
for
the
initial
proposal.
I
put
forward
just
to
get
the
conversation
going
now.
There
was
a
comment
in
there
by
somebody.
I
remember
who
it
was.
I
guess
it
was
tom
yeah.
E
E
I
haven't
thought
deep
about
that,
whether
I
like
it
or
dislike
it.
I
just
think
it's
an
interesting
way
to
go
it
at
first.
I
was
a
little
hesitant
to
it,
but
then
I
realized,
that's
not
that
uncommon.
You
know
we
do
things
like
301
for
redirects
and,
you
know
say:
go
look
over
here
kind
of
stuff,
so
it's
not
weird.
E
I
just
got
a
little
worried
about
whether
that's
introducing
a
whole
new
layer
of
complexity
into
the
model,
as
opposed
to
just
a
simple
time
stamp
thing,
but
the
more
I
kept
thinking
about
the
more
I
was
warming
up
to
it.
So
let
me
go
ahead
and
pause
there
and
see
if
there
are
any
questions
comments,
how
people
feel
about
either
of
these
directions
or.
E
All
right,
let's
start
with
some
j's,
jennifer
and
or
jim,
because
I
know
jem,
you
you're
open
up
one
of
the
issues
and
jennifer.
I
know
you
spoke
on
this
before
in
the
past
either.
One
of
you
want
to
chime
in
here
have
any
thoughts
on
this
I'll.
Let
ladies
go:
first
there
you
go
jennifer
you
want
to
chime
in
or
or
not
you
don't
have
to
want
to
just.
E
E
Okay,
I'll,
let
you
dedicate
now
I'll
give
you
some
chance
to
think
about
I'll
pick
on
gem,
then
you're,
looking
for
any
possible
feedback
on
this
proposal
for
adding
a
removal,
deprecation,
removal,
time
and
possibly
a
pointer
to
an
alternative,
so
jem.
Any
thoughts
on
this
one.
I
E
I
don't
know
he
tom
did
not
say
I
was
kind
of
assuming
it
would
be,
obviously
something
unique
right,
so
it
could
be
do
we,
I
don't.
I
can't
remember
we
have
ids
in
here
right
so
yeah,
so
it
could
be
just
an
id
because
I
think
that's
the
only
thing
that's
guaranteed
to
be
unique
and
immutable.
So
that
might
be
the
obvious
answer.
But
to
be
honest,
I
haven't
thought
about
it.
I
E
I
E
E
E
D
Yeah
in
reverse
order
yeah,
I
think
the
unique
url
would
be
better.
A
question
about
the
alternative
piece
is
like
what
does
that
say
if
it's
there
or
not
there
like
what
are
the
guarantees
if
we're
making
it
optional
right,
it
is.
Does
that
mean
that
the
new
service
or
the
replacement
service,
or
whatever
this
alternative
is,
does
that
have
to
exist
before
the
end
of
the
time?
Does
it
is
it
only
going
to
exist?
After
is
the?
Is
it
completely
unspecified
like
what
are?
What
are
the
you
know?
D
Sort
of
it
might
not
be
guaranteed,
but
what's
the
expectation
in
the
in
the
model
here
for
having
that
good
questions.
E
Hardly
hardly
for
once.
Oh
my
okay,
I'm
trying
to
remember
what
was
it
just
the
guarantees
for
when
it's
going
to
be
available?
Were
there
other
questions
in
there?
You
probably,
I
would.
H
Say,
plus
one
to
the
like
being
really
clear
about
expectations
is
alternative.
Would
that
be
something
for
the
machine
or
for
the
human?
Would
it
be
like
if
you
see
an
alternative
you
as
a
human,
and
it
will
change
and
update
what
you
call
or
would
the
should
something
follow
the
alternative,
url
right.
H
Follow
but
like
use
that
url
instead
so
like
is
it?
Is
it
like?
What
is
the
expectation
around
alternative
like
alternative?
I
don't
know
that.
I
understand
exactly
what
I
and
I
know
it's
just
like
a
guidance,
but
what
what
would
be
the
recommendation
there
like?
If
how
would
we?
How
would
I,
how
should
I
interpret
alternative
right.
D
Yeah
and,
for
example,
like
well,
do
I
what
what
does
that
mean
around
discovery
and
subscriptions
do
I
have
to
like?
Is
it
well,
I
just
go
start
a
new
subscription.
Does
my
subscription
carry
over
like
there's,
there's
a
bunch
of
potential
assumptions
around
that
stuff
that
that
could
be
quite
confusing?
D
L
The
question:
how
would
I
deduplicate
across
those
two
potential
streams?
How
do
I
do
the
transition.
H
L
From
one
of
the
streams
to
the
other,
particularly
if
there,
if
it's
a
new
version
of
the
stream,
so
it's
maybe
offering
a
new
attribute
or
something
and
that
new
service
is,
I
don't
know
if
there's
version
and
service
change,
then
how
do
you
deal
with
anything
that
might
be
different
and
correlating
the
events
across
the
two?
So
let's
say
it's
a
bank
account
balance
change.
I
don't
want
to
process
the
same
deposit
twice
right,
so
I
need
to
know
how
to
identify
anyway,
that's
kind
of
the
space
yeah.
E
D
Just
to
be
clear,
like
all
of
these
questions
all
exist,
whether
or
not
the
this
alternative
thing
is
added
to
the
spec
right
there.
These
are
all
all
issues
around
timing
anyway,
it's
just
if
we're
putting
alternative
or
whatever
innate
spot,
we're
making
it
more
official,
so
we're
gonna
have
to
be
a
little
more.
E
Maybe
right
because
it's
also
possible
for
us
to
say
we're,
not
gonna,
say
anything.
Yes,
but
that's.
D
E
E
Okay,
clearly,
you
can't
merge
this
one,
so
I
guess
we'll
keep
moving
forward.
Then
there's
no
more
discussion
points
on
that.
One
all
right
now
clemens
could
not
make
the
call
I'm
wondering
if
anybody
had
any
thoughts
on
this
one.
Yet.
E
I
know
if
I'm
running
correctly,
I
think,
on
last
week's
call
there
was
some
leaning
towards
b
and
kind
of
being
a
bit
hand-wavy
about
the
fact
that
yes,
techniques
breaking
change,
but
we
can
consider
this
a
a
big,
a
big
mistake
that
we're
just
fixing
and
that
you
can
probably
get
by
with
maybe
a
1.1
instead
of
a
2.0
for
the
next
release.
But
I
wasn't
sure
how
people
thought
about
that.
So
klaus
did
you
wanna
yeah,.
M
E
E
E
F
I
Sure
and
thanks
just
a
really
a
convention
that
I'm
looking
for
clarity
on
so
the
scenario
is
that
I
sort
of
discovered
that
the
java
json
binding
you
know
in
the
java
sdk
was
not
sort
of
completely
in
the
spirit
of
the
specification
and
where
it
was
having
a
problem
was
in
its
handling
of
numeric
attribute
types.
If
you
look
at
the
cloud
event
spec,
it
says
that
only
integer,
you
know,
numeric
types
are
allowed
for
context,
attributes
the
the
jason
format
spec.
I
I
So
the
question
becomes:
what's
an
sdk
or
a
consumer
expected
to
do
if
it
receives
a
non-conforming
payload,
I
think
it's
more
of
a
potential
issue
for
maybe
jason
rather
than
the
protospec,
because
the
protospec
won't,
you
know,
by
its
very
nature,
doesn't
allow
you
to
create
attribute
values
that
are
against
the
specification.
I
But
theoretically
anybody
could
create
a
json
document.
You
know
by
hand
and
put
you
know,
define
an
attribute
with
a
you
know:
a
decimal
number
value
or
a
long
number
value,
and
so
the
question
becomes.
What's
the
handling
expectation
there
is
an
sdk
expected
to
coerce
that
to
a
string
or
is
it
meant
to
you
know,
ignore
it
drop
it,
and
so
that
that's
really
the
concern,
because
I
suspect
this
might
apply
to
other
sdks
as
well.
Probably
not
just
go,
not
just
java,
rather.
K
K
E
That's
cool
slinky
since
you're
in
multiple
sdks.
Is
that
the
way
all
the
sdks
that
you're
that
you're
played
with
operate,
they
reject
the
request.
K
Well,
numeric
the
numeric
thing.
To
be
honest,
I
think
in
sdk
we
don't
check
it
and
even
in
I
don't
know
I
I
need
I'm
to
to
look
at
it
again,
but
I
think
the
json
parser
in
sdk
code
doesn't
check.
The
american
just
accepts
every
kind
of
numeric
value,
and
maybe
it's
the
same
as
the
keras
too.
Okay.
E
What
do
you
guys
do
with
with
like
malformed
time
stamps?
Do
you
check
those
at
all,
or
would
you
reject
the
request?
No,
no.
K
The
these
are
partly
checked,
I
mean
if,
if
it
can't
pass
the
time,
stop
it
fails,
it
fails.
Okay,.
E
I
O
O
If
an
event
is
created
through
a
process,
if
it's
coming
across
a
wire
right,
if
an
event
is
coming
across
the
wire,
then
we
don't
necessarily
throw
an
exception
if
it's
malformed
as
long
as
we
can
parse
it
and
then
there's
a
validate
method,
that
the
user
can
call
to
validate
that
event
and
validation
will
cause
an
exception
to
be
thrown.
But.
H
O
Want
to
be
loose
about
what
we
accept,
because
we
know
that
some
event
providers
may
have
malformed
events,
and
this
actually
was.
This
happened
in
some
implementation
of
some
stuff
that
we
were
doing.
We
were
getting
some
events
from
camel
that
I
don't
remember
exactly
what
the
issue
was
like.
They
didn't
have
a
valid.
They.
O
Data
content
type
field-
maybe
I
can't
remember-
but
we
made
the
decision
to
be
loose
in
our
validation
on
receiving
events
over
the
wire.
But
if
you
create
a
new
event,
that's
malformed
or
has
you
know
bad
fields
directly,
then
that's
strict
validation
and
it
will
throw
an
exception.
D
Okay,
thank
you
and
john.
Your
hands
up
yeah
the
question
for
for
lance
since
you're
separating
this
validation
step,
like
sorry
so
is
validating,
doing
conformance
tests
or
are
you
separating
the
conformance
from
the
you
know?
Oh,
this
is
totally
missing
a
field,
and
things
like
that
like
is
there
a
model
there
that
we
should
try
and
support
across
the
board.
I
guess
is
the
question.
O
By
conformance
you're
talking
about
like
field
types
and
stuff
yeah
yeah,
so
we
use
a
json
validating
parser
called
ajv.
I
think,
and
so
we
feed
the
schema
into
that
parser
and
you
know
it's
based
on
on
the
existing
schema
and
it
it
does.
The
validation
based
on
type
yeah.
E
Just
curious-
and
this
might
be
a
great
topic
for
a
future
sdk
call,
but
should
the
sdks
be
somewhat
consistent
here
I
mean
like:
should
we
all
or
should
all
the
sdks
fail,
or
should
all
the
sdks
follow
the
javascript
model
and
be
you
know,
loosen
what
they
accept,
but
then
have
a
separate
validation
step
that
someone
could
ask
to
validate
it
and
get
an
error
message
back
that
way
or
is
or
should
sdk
each
sdk
make
its
own
decision
about
this?
N
Feel
like
it's
that
required
right,
like
javascript,
is
kind
of
known
for
being
slightly
more
loose
about
types
and
and
data
content
than
say
like
c
okay,
so
I
would
kind
of
expect
to
be
able
to
make
it
go
in
javascript,
but
absolutely
break
with
proto,
okay,
fair
enough!
Jim
did
you
want.
I
O
I
But
but
the
interesting
thing
is
that
the
the
json,
the
the
json
schema,
because
there
are
no,
there
are
no
attributes
that
take
in
values,
for
instance.
So
there's
no
constraint
in
that
schema
that
says
your
particular
field
must
be
an
integer.
I
think
that's
that
has
to
be
done
in
in
the
sdk
itself.
I
think
to
disallow
sort
of
creation
of
numeric
attributes
that
that
are
bigger
than
an
int.
I
I
N
Magic
client
pieces,
you
have
to
kind
of
drop
down
and
you
have
to
be
aware
of
what
which
protocol
you're
actually
using,
because
you're
gonna
have
to
go
and
produce
the
cloud
event
yourself.
K
Okay,
slinky
your
hands
up,
yeah,
sorry
for
interrupting.
As
I
said,
we
can-
and
I
think
this
something
that
can
be
applied
in
all
other
sdks
too.