►
From YouTube: CNCF Serverless Working Group 2020-07-23
Description
CNCF Serverless Working Group 2020-07-23
C
Good
morning
vlad
it's
been
a
while,
where
you
been
yeah,
sorry
for
disappearing
without
a
train
I
retired,
and
I
started
with
a
lot
of
relaxation
you
retired.
Are
you
kidding
me
it's
my
third
time?
I
never
managed
to
stay
retired
more
than
four
months,
because
I
get
bored
how
long
it
takes
now
we'll
see
you're
so
funny.
A
C
B
A
B
F
A
B
F
B
H
H
B
J
A
Hello:
everybody,
hello,
okay.
I.
A
Oh
adobe
t-u-b-m.
B
Oh
interesting,
I
recently
was
looking
into
you
guys
for
some
video
stuff
interesting
all
right.
It
is
technically
time,
but
let
me
just
get
the
last
couple.
Folks
colin,
are
you
there?
I
am
good
morning
good
morning
I
coulda
saw.
L
B
B
Are
you
there
christian
gotcha,
all
right,
let's
go
and
get
started,
probably
gonna
be
a
short
call.
Anyway,
let's
see
what
okay
community
time
anything
from
the
community
that
people
like
to
bring
up.
That's
not
on
the
agenda.
B
All
right
not
hear
anything,
we
do
have
an
sdk
call
scheduled
for
this
week.
I
believe,
as
of
right
now,
there's
only
one
very,
very
minor
thing
on
the
agenda.
Can
I
say
something.
H
And,
and
and
ask
those
folks
who
who
are
who
joined
out
of
curiosity,
what
specifically
they're
curious
about.
H
J
So
basically
we
we
were
trying
to
at
hellofresh.
I
don't
know
how
many
guys,
if
you
know
hellofresh,
we
are
a
meal.
Kid
subscription
company,
that's
based
out
of
berlin,
germany,
so
we
had
a
we
had.
We
were
trying
to
tackle
a
problem
where
we
wanted
to
store
some.
Some
of
the
events
that
mobile
app
or
the
front
end
would
publish,
and
then
you
know
store
it
in
s3
or
somewhere
for
analysis
in
the
future.
J
B
All
right
cool
moving
forward,
then
we
do
have
an
sdk
called
schedule
for
this
week,
but
there's
only
one
minor
item
on
there-
probably
not
worthy
of
having
to
call
just
for
that.
Take
it
offline,
especially
since
it's
mine,
and
I
won't
be
able
to
join
the
call.
But
if
you
do
have
other
topics,
please
add
it
to
the
agenda
before
this
call
ends,
and
then
someone
else
can
run
that
meeting
since
I
won't
be
able
to
make
it
okay,
tim
or
anything
from
the
workflow
side
of
things.
D
Yeah
thanks,
as
far
as
what
we're
currently
working
on
we're
adding
extension
points
to
our
workflow
definitions,
such
as
kpi
and
simulation.
So
those
are
extensions
that
are
specification
provided
and
allow
you
to
add,
like
non-execution
type
of
stuff
like
key
performance
indicators
or
information
about
simulation
and
stuff,
like
that,
so
that's
as
far
as
working
goes
and
kind
of
like
just
shameless
plug.
Our
next
meeting
is
august
3rd.
B
Okay,
this
one
klaus
you're
still
not
convinced,
I'm
sorry,
it's
okay,
so
so
klaus.
It
seemed
quickly
wrong.
It
seems
like
you're
you're,
just
not
sure
we
actually
need
this.
So
I
guess
my
question,
for
you
is:
how
would
somebody
as
a
client
receiving
the
list
of
services
know
whether
in
any
particular
service
is
an
existing
one?
Just
had
all
its
metadata
changed
and
therefore
they
should
just
do
an
update
versus
it's
a
brand
new
service
by
the
same
name,
I
guess
so
you're
assuming
the
name
needs
to
be
immutable.
E
Yes
or
if
you
change
the
name,
then
it's
technically
a
new
service.
B
E
Okay,
the
alternative
would
be
to
generate
that
uid
inside
that
discovery
service.
But
then,
if
you
update
the
metadata
as
developer,
how
would
that
this
then
work
so
yeah.
B
So
you
said
something
interesting
there.
It
was
always
my
assumption
that
the
id
is
generated
by
the
service
itself.
It
would
not
be
something
the
user
would
explicitly
set
when
they
add
a
new
service
to
the
system.
E
Rephrase
the
question-
I'm
not
quite
sure,
I'm
following
okay:
how
would
that
work?
The
service
itself
generates
the
id.
B
E
What
point
would
then
the
uid
be
generated.
B
Right
so
it
gets
generated
by
the
system.
In
the
same
way,
the
the
uuid
is
generated
by
the
system
and
kubernetes
right.
It's
returned
to
the
users
when
they
query
the
system,
so
they
could
see
it,
but
that
would
be
the
way
they
uniquely
identify
it
right
because
I
mean,
if
I'm
the
only
one
that
thinks
not
being
able
to
do
a
rename
is
is,
is
crazy.
Then
that's
fine
I'll,
let
it
go
so
it's
just.
A
E
Uid
is
generated
and
identifies,
then
the
resource
in
the
context
of
that
specific
cluster
correct
and
that's
what
I
was
asking
before
in
my
previous
comments.
So
what
I
was
targeting
it
because
I
was
actually
looking
at
the
specifications
for
on
the
kubernetes
end,
how
they
define
the
uid.
They
have
for
resources.
E
B
C
But
sorry
audio
issues,
I
think
the
version
get
gets
bumped
like
for
an
update,
isn't
it.
I
might
be
wrong
on
this.
H
H
While
you
are
saying
you're
saying
that
you
hate
for
things
not
to
be
renamed
right,
and
but
this
is
not
renaming,
this
is
re-identifying
and
that's
that's
different.
H
So
I
agree,
I
agree
with
with
the
the
name
the
id
never
changing,.
B
H
B
Exactly
those
are
the
things
that
I
wanted
to
avoid,
because
because
these
I
mean
even
the
examples
we
give
here
for
name
they're,
not
exactly
unique.
In
that
sense,
right
I
mean
the
word.
Storage
is,
is
pretty
generic
right
and,
as
you
said,
someone
could
come
along
and
say:
hey,
don't
screw
up
your
existing
customers
because
they're
still
using
this
thing,
but
you
know
what
we
need
to
call
this
ibm
storage.
N
B
N
But
then
that
means
the
discovery
service
needs
to
have
something
to
store
to
store
it,
while
basically-
but
maybe
my
implementation
was
wrong,
but
my
in
my
implementation-
it's
just
driven
by
the
code,
so
I
have
nowhere
to
put
this
kind
of
generated
uid
in
or
inside
the
code,
or
I
create
a
json
next
to
your
code.
But
then
I
find
it
not
clean.
O
N
Yeah,
so,
basically
for
but
again
maybe
it's
because
the
way
I
I
didn't
understand
it
was
not
the
right
way.
But
in
my
opinion,
when
I
created
the
service,
I
was
able
to
create
to
expose
the
discovery
service
while
waiting
while
creating
the
service
by
itself,
and
so
the
discovery
service
is
stateless
is
just
inside
my
code
and
just
with
the
three
lines
of
code,
I
exposed
to
discovery
service
with
all
the
different
services.
B
B
N
B
N
B
J
B
N
But
because
the
uid,
like
the
code,
won't
be
able
to
update
itself
like
the
is
it
static
inside
the
code,
I
think
I
should
go
like
we
can
have
a
separate
meeting
on
that
and
okay.
I
think
we
need
to
prepare
the
demo
and
the
discovery
service,
so
you
might
understand
more
the
way
I
was
thinking
it
maybe
like
and
challenge
me
on
that,
but
I
will
like,
if
you
have
time
in
the
next
week,
you
know
we
can
probably
sit
down.
B
Love
to
understand
your
scenario,
because
I
don't
in
your
particular
use
case-
I
don't
think
id
is
any
different
than
name
at
that
point:
everything's
hard-coded
in
your
code,
so
I
don't
think
there's
any
difference
there,
but
yeah.
Let's
talk
offline,
better,
yeah
ryan.
Your
hand
was
up.
I
want
to
pick
on
you
since
you
were
going
to
say
something.
L
So,
just
looking
at
this
with
fresh
eyes,
I
don't
have
a
whole
lot
of
context,
but
what
is
a
little
confusing
is
the
first
two
sentences
of
the
description
are
a
unique
identifier
for
the
service
and
a
unique
identifier
for
the
service
for
both
name
and
id.
So
at
the
very
least,
if
we
move
forward
with
this,
we
might
want
to
clarify
the
difference,
and
I
know
it's
clarified
a
little
bit
technically
but
like
what
are
what's
the
intent
of
how
this
is
used
versus
id.
B
Gotcha
yeah,
I
can
see
that
being
confusing.
I
can
work
on
that,
but
I
still
think-
and
maybe
we're
not
going
to
come
to
a
resolution
on
this
call,
unfortunately,
but
I
still
think
we
need
to
to
resolve
the
overly
the
higher
order
bit,
which
is
should
name
be
immutable
right,
because
I
think
if
once
you
make
that
decision,
I
think
it
resolves
everything
else
right.
If
name
is
immutable,
then
we
don't
need
id.
If
name
is
mutable,
then
I
think
we
need
something
like
id,
but
I'd
like
to
get
a
sense
from
the
group.
B
B
B
P
N
B
N
E
Q
B
Q
Yeah,
for
me,
a
name
really
implies
something
which
might
change
over
the
time
and
and
this
uniqueness
of
a
name,
it's
gonna
be
hard
to
achieve,
I'm
not
sure
in
which
scope
you
were
thinking
of
having
a
unique
name.
So
I
I
I'm
in
favor
of
having
a
uuid
per
service
and
yeah.
As
we
know,
and
and
you
you
show
the
examples,
I
mean
storage
as
a
name
and
that
might
be
people
choosing
for
the
name.
Q
Just
this
simple
storage
and
then
I'm
pretty
sure
somewhere
else,
storage
will
will
pop
up
and
then
you're
really
confused.
As
a
as
a
client
and
user
of
of
these
discovery
services,
then
you
have
a
storage
there
and
the
storage
here
and
which
one
is
which
and
I'm
in
favor
of
an
id
okay.
R
John,
your
hands
up
yeah,
I
guess
I'll
say
the
same
thing
right.
The
the
changing
of
the
names
is
is
totally
different
from
from
a
a
hard
id
that
you're
going
to
use
and
rely
on
as
the
actual
identity
of
the
underlying
service
itself.
R
As
it's
a
lot,
I
guess
my
question
to
you,
doug
is
do
in
terms
of
the
what
some
people
call
the
life
cycle
of
this
thing
like
are
you
you
expecting
that
to
live
across
multiple
iterations,
or
do
you
envision
the
id
being
used
as
each?
You
know,
like
each
release
of
the
service
having
a
different
id.
B
That's
an
interesting
question.
My
initial
thought
was
it
would
oh
it
would.
It
would
be
the
same
across
versions
of
the
service
because
from
the
end
user
perspective
it
is
the
same
service.
Now,
if
a
producer
chooses
to
tree
version
one
and
version
two
as
completely
different
services,
then
then,
yes,
I
think
they'd
be
different
ids
and
the
fact
that
they
happen
to
share
the
same
base
name
and
they
they
differ
in
the
v1
versus
v2
part
of
the
name.
That's
just
an
interesting
site.
B
That's
just
an
interesting
bit
of
trivia
right
at
that
point,
but
if
they
really
are
separate
services,
then
they
get
different
ids.
But
if
they're
the
same
service
and
one
is
meant
to
sort
of
replace
the
other
one,
then
I
think
it's
the
same
id
right.
R
So
then,
my
my
suggestion
is
to
put
some
some
some
you
know
like
into
the
primer
or
something
like
that.
Some
clarification
around
you
know
those
that
variability
right.
Otherwise
I
mean
you
can
hear
in
people's
comments
right.
There's,
there's
different
distinctions
of
what
people
are
gonna
key
off
of,
I
guess
pun
intended
to
you
know
to
decide
what
their,
what
they're
actually
interacting
with
right
and,
like
you
say,
different
versions.
Different
people
have
different
models
of
what
versioning
is
and
whether
that's
significant
to
their
use
case
or
not.
B
I
Your
hands
up
back
with
my
naive
questions
again,
I'm
wondering
if,
if
the
use
case
we're
thinking
about
here
is
that
somebody
would
have
queried
the
discovery
service
in
the
past,
save
this
id
and
then
in
the
future,
we'll
be
coming
back
to
the
discovery
service
to
make
sure,
for
example,
the
url
hasn't
changed,
so
they
want
to
hit
this
endpoint
again.
I
B
I
mean
you're,
not
gonna,
I'm
not
the
actually,
whether
we
allow
them
to
query
by
id
or
not.
I
don't
know
that
my
my
use
case
was
a
lot
simpler.
It's
just
maybe
every
week
some
client
does
a
query
to
the
discovery
service
to
say
what
services
this
business
provider
offer
right
and
as
they
get
back
that
list,
they
need
to
know
for
every
single
service
they
get
back.
Is
it
a
new
service
or
do
they
just
update
the
metadata
on
existing
service
right?
And
I
don't
know
how
to
do
that
today?
I
What
you
mean
so,
if,
if
you
weren't
thinking
of
that
use
case
of
somebody
coming
back
to
find
out
what
the
current
url
for
a
specific
service
is,
if
the
url
for
a
service
changes,
how
how
do
we
expect
clients
of
that
service
to
figure
that
out.
B
Well,
I
think
that
does
fall
back
in
the
center
described,
in
the
sense
that
when
you
do
your
query,
you'll
get
back
the
list
of
services
you'll
be
able
to
identify,
based
on
based
upon
the
id,
whether
it's
in
a
new
service
versus
an
existing
service.
If
it's
an
existing
service,
then
you
can
just
do
a
diff
on
each
field
to
see
whether
it
changed
or
not,
and
the
url
is
just
one
of
those
fields
right
the
same
way,
the
list
of
types
might
change.
I
Okay
yeah.
Thank
you
yeah.
I
given
some
things
that
I
have
seen
around
naming
things
and
branding
and
whatnot
it.
It
certainly
seems
nice
to
decouple
this
into
an
id
away
from
a
name.
I
think
I
I
fall
into
the
camp
of
folks
thinking
that
yeah,
the
name
could
probably
change
here.
B
Okay,
so
tell
you
what
I
feel
like
we've
taken
too
much
time
on
this
one
and
I
definitely
don't
think
it's
ready
to
be
merged
in
any
sense
and
I'm
not
100
convinced
everybody's
on
the
same
page,
yet
especially
klaus
and
remy
and
stuff.
So
let
me
do
this.
Let
me
go
back
offline
and
thank
you
all
for
the
wonderful
feedback.
I
can
go
back
and
rework
it
some
more
and
we'll
revisit
at
some
point
later
and
maybe
it'll
take
another
three
weeks,
but
then
class
should
be
back
and
you
can.
B
It
won't
even
emerge
by
then
and
then
you
will
have
more
rounds
of
it.
But
at
least
I
feel
like
there
is
more
work
that
needs
to
be
done
on
my
side
to
help
clarify
some
things.
So
let
me
at
least
take
the
feedback.
You
guys
gave
me
and
rework
it
a
little
and
not
push
for
any
kind
of
decision
now,
because
I
think
it's
too
soon.
Okay,.
H
One
one
quick
observation
about
what
was
just
said:
have
we
defined
events
for
the
discovery
service?
Yet
because,
because
it's
like,
how
do
I
learn
about
something
changing
in
the
discovery
service?
And
it
strikes
me
that
we
could
obviously
use
cloud
events
to
notify
people
about
changes
in
the
discovery
service.
Just
a
thought.
S
P
B
All
right
so,
as
I
said,
I
think
we
probably
spent
way
too
much
time
on
this
on
this
call.
Any
last
comments,
though,
before
we
move
on
to
the
next
item:
okay,
cool.
Thank
you,
everybody
for
the
feedback
that
I
appreciate
it.
Okay,
I
don't
remember
who
opened
up
this
one
that
was
me.
Oh
there
you
go
cool
and
you're
on
the
call
you
want
to
talk
to
this
one.
Q
Yeah,
basically,
I
took
your
discovery
description,
including
the
change
of
the
id
and
created
a
open
api
description
of
this
api
of
this
discovery.
Api.
A
B
B
Okay,
so
I
guess
my
question
for
you,
thomas,
is
aside
from
the
id
thing,
which
obviously
is
easy
to
remove.
Do
you
think
the
rest
of
it
is
a
good
starting
point
that
we
should
try
to
merge
today
and
just
add
to
it
as
we
go
along
or
would
you
rather
do
some
more
changes?
First,
before
we
consider
merging
it.
Q
For
me,
I
think
it's
a
good
starting
point,
it's
also
executable,
and
but
it's
also
to
try
out
for
people
to
see
what
is
actually
the
return
or
the
the
responses
from
this
api
description.
Does
it
match
the
expectations
and
that
that
would
be,
from
my
point
of
view,
a
good
starting
point
to
afterwards
process
issues
or
further
change
requests
on
that
one.
But
at
least
we
have
a.
Q
Point
would
be
worth
to
to
merge
it
already
now
and
and
actually
the
description
I
took
over
from
from
your
discovery,
md
file,
so
it
should
actually
match,
except,
of
course
I
mean
the
id
would
need
to
be
removed
and
of
course
the
name
still
has
this
unique
identifier
for
the
service
in.
B
Right,
okay,
so
for
the
rest
of
the
group,
if
thomas
was
to
remove
id
because,
obviously
that's
not
in
the
spec
yet
for
the
rest
of
it,
how
do
people
feel
do
you?
Does
everybody
on
the
call
want
or
need
more
time
to
look
it
over,
or
do
you
think,
even
if
it's
a
little
bit
off,
it's
a
good
starting
point
and
we
can
pr
it
later?
How
do
people
looking
to
approve
this
today
minus
the
id
stuff,
and
if
you
need
more
time,
don't
hesitate
to
speak
up
just
just
want
to.
Q
What
do
you
mean
by
one
projection?
Sorry,.
T
Well,
one
of
my
one
of
my
goals
is
to
make
sure
that
the
discovery
api
can
also
be
hosted
inside
of
kubernetes.
B
B
B
B
Okay,
I
thank
you.
Lance
lance
says
it's
okay
with
him
just
to
check
this
in
now
or
merge
it
in
now.
Anybody
else
have
any
comments,
one
way
or
the
other,
because
I'm
inclined
to
to
let
it
go
in
and
then
pr
any
changes
that
are
me
are
needed,
but
I
don't
want
to
rush
it
to
people
one
more
time,
I'm
good
with
that.
Okay,
thank
you.
Remy!
Anybody
else
want
to
speak
up.
B
B
B
I
think
it
was
grant's
concern
about
structured
mode
and
how
it
structured
mode
versus
batch
mode,
and
there
was
some
confusion
about
whether
it's
they're
all
structured
or
different
modes
and
all
that
kind
of
stuff-
and
I
think
this
was
kristoff's
attempt
to
try
to
address
that.
Did
anybody
get
a
chance
to
read
this
or
have
any
commentary
on
it.
B
J
Q
As
far
as
I
remember,
the
discussion
was
a
couple
weeks
or
even
months
ago
that
in
binary
mode
it's
really
difficult
to
actually
batch,
because
if
you
look
at
the
example
of
http
in
binary
mode,
you
have
header
fields.
So
how
would
you
do
a
batching
of
multiple
events?
Q
B
I
think
everything
you
said
is
true.
Yes,
I
think
the
biggest
question
was
someone's
reading
the
spec
and
they
were
confused
as
to
whether
batch
is
a
structured
mode
or
whether
whether
batch
is
a
variation
of
structured
mode
or
whether
it's
a
separate
mode,
and
it
was
more
of
a
a
wording
thing
and
less
of
a
a
coding
thing.
I
think,
anyway,.
T
I
think
it's
a
coding
thing
too:
oh,
is
it
batched,
I
think
so.
My
my
take
is
that
batch
is
bundling
of
a
bunch
of
structured
messages
right.
So
it's
a
mode
that
wraps
another
mode.
It's
not
a
subset!
It's
a
it's
some
other
thing,
but.
B
Okay,
well
then,
I
I
would
strongly
recommend
that
you
read
it
because
I
think
if
I'm
incorrectly,
based
on
what
kristoff
said,
I
think
he
was
headed
in
the
path
of
saying
no
there's
really
only
two
modes
structured
in
binary.
But
then
there
are
different
flavors
of
structured
and
one
of
the
flavors
is
batched
and
I
suspect
that's
what
he
was
trying
to
say
here.
So
you
may
want
to
read
it
and
chime
in
there.
If
you
think
he's
he's
heading
in
the
wrong
direction,.
B
Okay,
there
were
two
other
prs
that
were
opened
they're,
both,
I
think,
relatively
new.
So
I
don't
think
we
can
technically
merge
them
from
that
perspective.
However,
I
just
want
to
double
check
on
this
one.
This
seemed
like
a
simple
goof
up
on
our
part,
in
the
sense
that
we
went
from
content
from
content
type
to
data
content
type.
We
just
forgot
to
change
this
particular
file
for
avro,
any
any
aggro
experts
on
the
call
or
even
novices
on
the
call,
I
think
clemens
you
might
have
you
have
some
experience
here.
B
I
don't
actually
think
it
changes
the
arrow
output.
I
think
it's
just
changing
the
cloud
event
type
itself
right.
This
is
just
a
simple
typo
fix.
First
right,
yes,.
H
M
H
H
B
B
Okay,
so
I
think
so,
as
I
said,
I
think
this
is
just
we
left
off
the
word
data
we're
doing
the
change.
Yes
correct.
So
that's
that's
just
a
bug.
Okay,
so
I
think
it's
the
typo,
even
though
it
was
only
opened
yesterday.
I
don't
think
it's
controversial
at
all.
Anybody
have
any
objection
to
trying
to
merge
this
now
then,
what
do
they
want
to
wait?
E
Yes,
I
thought
I'll
leave
you
something
to
discuss
while
I'm
on
vacation.
So
it's
just
you.
You
started
with
this
primer
a
few
weeks
ago
and
I
wanted
just
to
add
a
bit
more
to
it.
I
think
so
far
we've
been
mostly,
we
just
had
use
cases
in
there,
starting
with
consumer
ones,
and
so
I
thought
I
add
a
few
to
get
the
discussion
started
that
are
more
about
intermediaries
or
producers,
and
that's
what
is
in
here.
E
So
one
is
about
an
intermediary
that
has
somehow
to
provide
discovery
for
all
the
producers
it
stands
for,
and
so
it
has
to
somehow
aggregate
what
I
call
event
catalogues
of
those
producers
and,
on
the
other
hand,
producers
have
also
to
register
with
some
intermediary
or
that
provides
discovery
or
subscription,
and
that
has
also
to
happen
somehow-
and
that's
maybe
also
partially
what
I
had
in
mind
when
we
were
discussing
the
serial
id
thing.
So,
okay,
any
questions.
A
B
Klaus,
okay,
I
have
one
your
your
language
here
seems
to
imply
certain
things.
For
example,
you
an
intermediary
just
said
it
aggregates,
and
I
agree
with
you
that
it
can
aggregate,
but
I
it
you
could
have
intermediaries
that
don't
I
assume
right.
E
E
We
intentionally
separated
the
discovery,
endpoint
and
the
intermediary,
so
but
in
this
case
it's
the
case
that
the
intermediary
is
also
providing
discovery
and
subscription,
but
I
think
it
has
to
aggregate
in
order
to
well.
It
depends
how
it
is
built,
but
in
this
case
it
is
aggregating.
It.
E
E
If
it
gets
subscriptions
from
a
consumer,
it
has
to
to
route
those
subscriptions,
maybe
even
to
multiple
producers.
If
it's
a
something
like
a
wildcard
subscription.
B
Yeah,
I
guess
I
guess
the
reason
I'm
asking
these
questions
is
because
I'm
wondering
whether
so
I
phrased
this
right.
So
I
agree
with
you
in
general
that
you
can't
have
intermediaries.
That
makes
sense,
but
I'm
just
wondering
whether
that's
more
of
an
implementation
detail
or
whether
it's
something
that
a
consumer
actually
needs
to
know
about
or
whether
to
them,
there's
just
one
or
more
endpoints
out
there
and
whether
they
all
point
to
the
same
physical,
endpoint
or
they're.
B
You
know
the
subscription
endpoint
is
slightly
different
from
the
discovery,
endpoint
they're,
all
just
urls
and
the
the
client's
just
going
to
follow
the
urls
right
I
mean
we
need
to.
Does
the
client
need
to
actually
understand
the
notion
of
intermediary,
as
opposed
to
just
there's
a
bunch
of
urls
that
they're
getting
returned.
E
I
guess
that
maybe
the
the
things
we'll
discuss
here
if
this
spec
is
only
for
intolerability
between
consumers
and
something
else
or
if
it's
also
discussing,
for
example,
interoperability
between
intermediaries,
or
I
mean
also
looking
at
the
other
perspectives
on
this
eventing.
E
Maybe
so,
yes,
oh
yes,
and
we
had
this
also
when
we
were
discussing
discovery
in
the
smaller
round
and
that
time
we
were.
We
said
that
we
would
postpone
this
discussion
until
later
on,
but
I
thought
at
least
introducing
those
use.
Cases
now
couldn't
hurt
interesting.
Okay,
what's.
B
E
B
B
Okay,
so
I
think
this
was
soap
was
just
opened
yesterday,
so
it's
too
soon
to
merge
anyway,
but
obviously,
if
you
guys
have
any
questions,
please
open
up
issues
or
comments
in
the
pr
and
they
may
have
to
wait
for
a
class
to
get
back,
but
we'll
see
all
right.
Thank
you,
klaus.
Anything
else
you
want
to
mention
on
this
one
close.
B
Okay,
cool.
Thank
you
all
right
in
that
case,
technically
we're
at
the
end
of
the
agenda
for
anybody
that
owns
these
issues
actually
yeah.
So
I
I
need
to
rework
the
pagination
stuff.
I
think
the
rest,
the
other
four
are
owned
by
francesco,
so.
B
K
B
Please
review
that
when
you
again,
I
know
lance,
you
made
some
comments
just
a
few
minutes
ago.
So
thank
you.
B
Okay,
with
that
we're
on
to
discovery
or
interoper
on
the
discovery
spec
for
myself,
I
have
not
had
a
chance
to
do
any
coding
for
a
couple
weeks.
Unfortunately,
remy
is
there
anything
from
your
side
that
you
want
to
mention.
N
Yeah,
just
if
we
can
try
to
meet
during
the
week
helping
you
on
the
slide
to
try
to
find
a
slot
together,
it
could
be
great
to
do
a
workstation
yep.
B
K
T
B
I
gotta
comment
on
that
in
a
minute.
Yes,
but
manuel
go
ahead.
U
Yeah
I'm
still
checking,
but
I
think
I
might
be
interested
to
join
the
effort.
So
if
you
have
a
meeting
in
between,
please
count
me.
B
Yeah
we
haven't
planned
on
scheduling
any
meetings
yet,
but
that
might
not
be
a
bad
idea.
I
think
maybe
we
should
need
to
get
past
some
of
the
current
flurry
of
activity
that
people
are
doing
like,
for
example,
scott
mentioned
kubecon
and
stuff
like
that.
So
maybe
we'll
look
to
set
up
a
meeting
in
the
not
too
distant
future
to
get
everybody
on
board
and
use
that
as
a
forcing
function
anyway.
Slinky
here
hands
up.
Q
Yeah
just
to
add
to
that
one,
because
I
I
tested
the
open
api
spec
with
the
azure
api
management.
And
yes,
of
course,
you
can
just
echo
the
examples
which
are
in
the
specification.
But
if
you
want
to
have
something
like
returning
multiple
services
or
returning
a
specific
service
or
having
a
matching
thing,
I'm
not
sure
I
mean
I'm,
I'm
not
an
expert
in
in
sophisticated
generators
of
code,
but
I
think
there
you
still
need
to
do
some
coding
for
it.
P
B
B
Doug
you're
on
mute
crap.
I
was
talking
for
five
minutes.
I
apologize
that's
technically
the
end
of
the
agenda,
any
other
topics.
People
want
to
bring
up.
B
All
right
going
back
to
the
attendee
list,
like
I
mean
well,
jinger,
are
you
there.
B
Yeah,
not
a
problem
sanjay
you
there,
oh
actually,
he
dropped
off
and
someone
else
just
joined.
I
saw
it
where
was
it?
Somebody's
name
went
flying
by
a
second
ago
daniel.
That's
it
are
you
there?
Yes,
I'm
here
excellent,
all
right.
Anybody
else
that
I
missed
all
right
cool.
In
that
case,
I
think
we're
done.
B
B
I'm
inclined
to
okay,
anybody
else,
non-sdk
stuff,
you're
free
to
go
sdk.
Folks,
quick
question
for
you.
We
recently
created
this
email
address
so
that
we
can
receive
emails
or
sign
up
with
different
sites
for
doing
testing
or
build
stuff
and
stuff
like
that.
It
is
a
private
email
address
that
only
the
maintainers
have
access
to
somebody
suggested.
We
need
an
email
address
for
people
to
raise
security
concerns
about
the
sdks.
B
Any
objection
to
using
this
email
address
for
that
purpose.
That
way,
any
email
would
technically
be
available
to
all
the
maintainers.
I
would
just
add
a
plus
security
or
something
like
a
little
tag.
Thank
you
for
reminding
me.
Yes,
I
thought
about
that
earlier
today,
based
upon
the
other
conversation.
K
Thank
you.
Well,
I
would
to
be
honest.
I
think
it
would
be
better
to
because
you
know
the
security,
the
it's
for
each
sdk,
maybe
just
cncf
cloud
events
plus
the
name
of
the
sdk,
like
plus
rust,
plus
java.
I
think
it's
fine
for
security,
so
we,
for
example,
in
sdk
java,
we
can
say
for
any
security
concerns,
write
to
sincere
cloud
events
plus
java
gmail.com.
V
It
does
but
having
having
a
standard
having
a
standard
extension
plus
security
or
or
whatever
that's
specific,
I
think,
is
useful.
Otherwise
people
might
just
plus
you
know.
Oh,
oh,
I
think
it's
java,
sdk
slim,
they
say
plus
java
sdk
or
you
know
it
becomes
less
useful
for
filtering
purposes.
If
we
don't
have
like
use
this.
One
extension,
okay,.
B
B
T
Okay,
sorry,
I
have
one
really
quick
one.
Yes,
sir
may
be
too
I'm
going
to
ping
the
slack
channel
for
sdk
maintainers
to
contribute
samples
of
several
exercises
for
the
kubecon
talk.
So
look
for
a
slack
message
there.
T
I
need
to
work
that
out
and
then
I
had
so
I'm
sorry.
I
had
something
else
and
I
lost
it.
So
I
guess.
B
While
you're
thinking
the
other
thing
I
forgot,
I
was
going
to
mention.
The
previous
call
is,
since
you
mentioned
kubecon
clemens,
and
I
did
do
the
recording
for
kubecon,
china
and
eu.
It's
actually
the
exact
same
recording
we
just
use
it
for
both.
We
removed
the
location,
specific
information
of
our
charts,
so
it
could
be
reused.
I
believe
I,
if
I
did
it
correctly,
I've
loaded
both
the
presentation,
as
well
as
the
video
into
our
cloud
events.
B
Google
drive
thing
if,
for
some
reason
you
folks
can't
get
to
it
or
put
in
the
wrong
spot,
let
me
know,
but
I
think
I've
uploaded
the
right
one,
but
it
is
available
for
you
guys
to
look
at
if
you
really
want
to.
T
I
wonder
if
people
might
be
interested
in
a
clown,
a
cloud
events
cli
to
help
kind
of
send
and
receive
and
do
other
things
for
cloud
events.
B
K
Just
a
question:
how
how
does
it
differ
from
putting
that
code
for
the
cli
straight
inside
the
sdk?
Go
I
mean
you
could
do
that.
I
think
what
do
you
think
about.
T
W
Yeah
I
I
would
like
that
I
would
like
it
for
I
like
the
fact
that
the
conformance
I'm
bumbling
here,
the
the
cucumber
stuff
would
be
nice
to
have
as
a
a.
What
do
you
call
it
a
the
subrepo
in
the
sdks,
but
it's
got
all
this.
It's
got
the
cli
stuff
in
it
that
kind
of
clutters
everything
up
so
at
a
minimum.
I
would
like
that
stuff
to
move
into
another
repository.
T
Yeah
I
it
turns
out.
I
use
that
thing
all
the
time,
and
so
I'm
suggesting
that
we
take
the
code,
that's
there
and
move
it
to
a
cli
reboot
in
cloud
events
and
then
leave
the
conformance
as
just
cucumber.