►
From YouTube: CNCF Serverless Working Group 2021-04-15
Description
CNCF Serverless Working Group 2021-04-15
B
B
The
office
hours
so
I
we
recently
got
noticed
of
our
times
and
I
looked
it
up
to
make
an
entry
in
our
meeting
minutes
now.
It
seems
to
be
in
our
sv
reservation
process
with
the
linux
foundation.
You
need
an
account,
you
rsvp,
you
get
this
accept
it
and
then
yeah.
It's
like
like
a
shopping
basket.
Sorry,
I'm
a
bit
slow
now
yeah.
So
I
don't
like
the
process
of
office
hours,
but
it
seems
more
like
an
organized
one-hour
meeting.
B
A
A
A
A
A
A
A
Now
there
it
is
so
now,
if
I
hover
over
it,
yeah
see
it
knows.
That's
amazing.
I've
noticed
it's
getting.
It's
adding
some
interesting
features
like
that
recently
in
terms
of
spell
checks
or
autocorrect
and
stuff
like
that,
I've
noticed
some
everything
around.
Then
they
sneak
in
these
changes.
It's
kind
of
neat,
sorry,
I'm
easily
distracted.
Where
are
we
ginger.
D
A
C
B
B
D
A
A
A
A
A
Nope,
okay,
cool
moving
forward.
We
had
no
sdk
call
last
week
because
there
are
no
topics.
I
do
want
to
have
an
interrupt
call
this
week,
if
even
if
it's
short
so
please,
if
you're
doing
interop
stuff,
please
hang
on
the
line
after
this
call
ends.
We
need
to
have
some
talks
office
hours
still
looking
for
volunteers,
medwell
indicated
that
there's
a
process
involved
in
actually
signing
up
for
that.
I
was
gonna,
do
a
little
bit
of
investigation
to
see
what
that
involved.
So
thank
you
for
the
links
there
whoa.
A
Thank
you
scott.
So
anyway,
don't
need
to
do
anything
anything
there
other
than.
If
you
do
know
you
can
sign
up
for
one
of
those
particular
days.
It'd
be
great.
If
you
could
stick
your
name
here
or
just
let
me
know,
and
I
will
put
your
name
there-
we
do
need
some
volunteers
and
again,
if
you're
interested,
you
can
see
remy's,
slides
and
video
that
he
submitted
for
our
stuff.
A
A
F
F
F
Those
are
optional.
We
can
ignore
those,
we
don't
have
to
use
labels,
but
we
could
use
this
script
to
go
and
slurp
up
all
those
release,
notes
that
are
in
prs
between
two
hashes
it's
hard,
because
you
have
to
run
it
locally,
which
is
why,
if
you
go
to
the
next
tab,
over
k
native
has
adopted
this
github
action
that
we
could
go
and
copy.
F
F
F
But
basically
we
use
this
as
a
starting
point
to
write,
release
notes
for
releases
when
we
go
and
actually
do
releases,
we
need
a
dozen
every
six
weeks,
and
so
some
of
the
action
is
optimized
to
kind
of
look
up
the
hash,
the
two
hashes
that
we
should
look
at
and
then
it
extracts
using
the
kubernetes
script
that
the
code
block
and
that's
that's
that's.
Basically
it
there's
not
a
lot
of
magic.
F
A
F
Yeah,
my
my
only
hesitation
with
the
what
is
it
called
like
conventional
commits
is
that
it's
fairly
magical
and
you
have
to
remember
or
kind
of
understand
how
the
parser
is
going
to
work,
and
this
is
literally
just
anything.
That's
in
this
release,
notes
block,
gets
exported
by
the
tool
and
then
you're
free
to
go
and
edit
the
release
by
hand
to
make
it
look
pretty.
A
F
F
C
G
G
F
A
F
C
A
I'm
kind
of
assuming
we
don't
need
to
talk
too
much
about
that
in
the
sense
that
that's
sort
of
my
problem
in
the
sense
that
I'm
probably
going
to
be
running
the
release,
notes
I'm
just
trying
to
figure
out
for
the
average
pr
creator.
What
do
they
need
to
do
and
it
sounds
like
the
difference.
Is
this
section
versus
a
prefix
on
their
commit.
G
F
A
A
G
F
Scott,
so
if
you
go
back
to
maybe
that
maybe
the
first,
the
or
the
the
last
tab
that
has
the
result,
this
one
yeah
and
then
click
on
the
release,
notes
and
it
might
download
something
or
actually
sorry
expand,
release
notes
this
little
green
check
box.
If
you
click
that,
oh
there
we
go
and
then
expand
display
notes.
F
D
Yeah,
I
also
like
using
labels
for
the
different
categories
like
api
changer
bug
or
regression,
because
it
is
a
finite
set
of
stuff.
One
of
the
difficulties
I
have
with
the
conventional
commits
is,
I
don't
remember,
is
it
supposed
to
be
docs
or
doc
or
is
it
you
know?
Is
it
supposed
to
be
chore
or
source?
You
know.
I
just
don't
always
remember
what
the
tags
are
supposed
to
be
so
the
labels,
that's
a
nice
improvement.
I
think.
A
A
A
I
think
because
what
john
was
saying,
which
is
it's
nice
to
be
able
to
separate
out
the
commit
from
this
text,
especially
if
the
text
wants
to
get
needs
to
get
updated
later
on
after
the
pr's
already
been
merged
and
stuff
like
that
having
it
in
the
pr
itself
gives
you
that
freedom
to
wordsmith
it
later
and
tweak
it
or
even
you
know
right
before
you
actually
generate
the
release,
notes
right
at
the
last
minute
you
realize.
Oh,
we
we
renamed
something.
So
really.
We
should
update
the
release,
notes
everywhere.
A
A
A
Yes,
I
was
definitely
not
going
to
do
a
finalized
vote
on
the
call
here.
Rather,
if
we
choose
to
head
towards
the
release,
notes
thing
that
scott
is
presenting
here,
I
was
going
to
send
out
a
note
and
let
people
who
could
not
make
the
phone
call
get
a
chance
to
voice
their
opinion
and
obviously,
graham
would
be
one
of
those
folks.
F
The
one
caveat
I
will
make
is
that
the
the
release
note
tool
is
made
for
kubernetes,
so
it's
not
a
copy
and
paste
the
result
into
our
release.
Notes
it's
going
to
be
a
it's
a
good
starting
point.
We'll
do
some
minor
editing
around
like
you
can
see
the
you
know.
The
documentation
link
is
to
kate's
dot
io
things
like
that.
Right,
like
we'll,
have
to
change
that
stuff,
because
it's
part
of
the
script,
but
the
logic
that
the
script
does
wouldn't
have
to
change.
A
A
A
A
G
Questions
as
discussed
this
is
currently
headed
to
101,
but
we
probably
want
to
move
it
to
master
so
that
it
can
be
part
of
102
branch
when
that
is
cut,
I
think,
but
we
can
discuss
that
when
the
when
we've
got
the
meat
of
it
done
as
it
were,
none
of
the
changes
that
I've
been
making
have
changed
the
intended
semantics
at
all.
They've
just
been
clarifications.
G
A
A
Okay,
any
objection
to
approving
okay,
one
quick
question,
then
clemens
welcome
back
from
vacation
or
wherever
you
were.
Did
you
get
a
chance
to
look
at
this
because
I
know
you're
the
I
believe
I
remember
correctly.
You
were
one
of
the
original
main
authors
of
the
pro
hp
protocol.
Spec.
Did
you
get
a
chance
to
look
at
this
and
you're?
Okay
with
it.
G
I
I
would
be
happier
if
you
didn't
just
because
this
is
all
quite
sensitive
stuff
if,
if
we
get
it
wrong,
we're
kind
of
screwed,
so
I
I
would
be
very
happy
if
cleveland's
you,
you
could
look
at
it
in
the
next.
You
know
couple
of
days
and
if
we
can
get
a
tentative
agreement,
if
clemens
is
okay
with
it,
then
it
could
be
merged
in
a
few
days.
That's
absolutely
fine!
G
A
Branch,
do
we
want
it
in?
Oh,
yes,
thank
you
for
rendering
that
so
to
refresh
everybody's
memory,
oh
I
want
to
say
maybe
a
month
or
a
month
and
a
half
ago
we
agreed
that,
rather
than
rolling
out
brand
new
release
version
numbers
every
time
we
find
a
typo
we're
just
going
to
merge
those
typos
directly
into
the
latest
release
which,
as
of
right
now,
is
one
zero
one.
However,
we
agreed
that
anything
bigger
than
a
typo
should
warrant
a
new
patch
release
number.
A
G
Big,
I
think
the
next
one,
given
that
it's
to
do
with
the
primer,
so
is,
let's
say,
informative
rather
than
normative.
That
might
be
treated
differently,
and
maybe
we
need
to
be
update
the
governance
rules
to
decide
whether
the
primer
gets
special
treatment,
given
that
it's
informative
but
yeah,
okay,
we'd.
A
A
A
A
A
G
A
G
A
F
So
what
we
do
in
the
goling
sdk
is,
we
have
a
release,
1.0
branch
say,
and
then
we
make
patch
releases
off
of
that.
That
are
tagged.
So
it
kind
of
avoids
this
like
there.
We
would
have
a
version,
one
branch,
that
you
cut
a
patch
releases
off
of,
but
it's
a
little
different
because
it's
not
just
text
it's
code,
so
people
have
to
import
it.
So
maybe
we
maybe
we
got
a
free
foot
gun
here,
because
we
called
it
a
101.1
versus
a
the
1-0
seed
branch
that
gets
patches
and
maybe
tagged
with
releases.
A
So
let
me
ask
you
about
that
because-
and
this
is
more
of
a-
I
guess-
a
git
question-
I
don't
think
it's
a
github
question.
I
think
it's
a
good
question
when
you
did
that,
did
you
create
a
one,
zero,
a
one,
zero,
zero
branch
or
tag
or
j?
No,
you!
Actually!
I'm
sorry.
You
said
you
just
created
a
one,
zero
branch.
F
F
Is
we
make
a
release
dash
1.0
branch
because
we
want
to?
We
want
to
be
able
to
service
bug,
fixes
on
individual
minor
bumps,
but
we
don't
have
we
want.
We
want
to
like
figure
out
what,
where
it
was
branched
from
and
then
make
a
new
fork
and
all
this
other
stuff,
so
the
simpler
process
that
we
use
is
you
make
a
a
branch:
that's
labeled,
the
major
minor,
but
not
the
patch
right
from
that
branch.
We
label
the
the
patch
version
so
v1.0.0.
C
A
C
A
History
got
it
and
I
think
I
think
the
reason
I
ran
into
issues-
and
this
is
probably
my
own
mistake-
is
I
created
a
101
one,
one:
zero
zero
branch
and
a
one,
zero
zero
tag,
which
is
technically
legal.
It's
just
really
confusing
in
terms
of
which
one
you're
actually
referencing.
When
you
issue
a
command
and
you're
saying.
Basically
you
avoided
that
because
you
never
created
a
one,
zero,
zero
tag,
you
only
create
a
one,
zero
branch
and
your
first
tag
after
that
was
one
zero
one.
A
A
A
G
So
so
is,
is
it
simpler
just
to
put
it
just
to
go
on
to
master
and
I'm
very
confused
now
it
feels
to
me
like.
Maybe
our
default
branch
should
be
yeah.
I
I
would
support
they're
going
to
major.minor
as
a
branch
rather
than
a
branch
for
every
patch
release,
but
I'm
happy
to
make
as
many
pr's
as
we
want
for
the
moment
to
get
this
in
yeah.
F
I
think
the
final
thing
I'll
say
so
the
the
process
that
we
would
use
would
be
you
make
a
pr
to
go
into
the
mainline
branch.
So
in
this
case
I
think
it's
called
master,
make
the
make
the
pr
for
master,
and
then
you
make
another
pr
that
cherry
picks
that
commit
into
the
release
branch.
The
major
minor
branch.
F
It
would
be
two
pr's
yeah,
there's
no
way
around
that,
and
hopefully,
if
the
change
you
know
isn't
conflicting
with
the
cherry
pick,
then
it
just
works
out.
It's
a
little
bit
more
work
for
you
to
make
the
second
pr
targeting
the
major
minor
branch
if
there
are
conflicts,
but
I
think
the
process
should
always
be
all
big
changes
land
in
the
head
first
and
then
they
get
cherry-picked
into
the
release
branches
that
they
apply
to,
so
that
would
that
would
also
go
for
the
government
stocks
that
we
were
talking
about.
G
Yeah,
does
that
make
sense,
john,
I
think
so
so
for
right
now
I
will
create.
I
would
suggest
that
you
doug,
don't
merge
anything
at
the
moment.
I
will
create
a
version
of
this
pr
for
the
master
branch,
probably
as
a
new
pr.
I
seem
to
remember
that
retargeting
things
in
github
may
be
tricky.
I'm
not
sure
I
will
wait
for
that
to
be
merged,
then
pull
everything.
G
A
That's
on
our
to-do
list.
It's
just
like
we
were
waiting
for
the
github
to
have
the
right
tooling
in
place
and
now
that
they
have
it,
we
can
do
that
so
yeah,
right
cool,
all
right.
So
what
I
said
down
here
was
it's
been
approved
and
hold
on,
I
meant
to
say
john
john
appear
for
both
master
and
101
and
then
I'll
wait
until
that's
done
before
I.
G
A
J
A
I
don't
know
if
you
heard
it,
but
ins
right
as
you're
coming
online
clemens
made
some
like
groan
or
something
in
the
background,
or
is
that
a
wow
I
couldn't?
I
can't
tell
what
that
sound
was.
I
was
just
laughing
what
xml
I
thought.
Xml
was
like
wow
yeah.
That's
what
I
thought
I
heard.
I
thought
I
heard
a
wow.
Yes,.
J
J
I
didn't
notice.
No
sorry,
I
I
was
a
little
bit
too
subtle
there
and
actually
you're,
seeing
you're.
Seeing
that
pr.
My
attempt,
because
I
thought
the
conventional
commit
stuff
applied
at
the
pr
level
as
well,
so
I'd
actually
tried
to
make
that
work
anyway,
yeah
so
john
and
slinky,
and
I
I
think
somebody
else
had
left
some
comments
on
this.
There
are
a
couple
of
things
that
I
need
to
tidy
some
of
the
commentary
and
it
sounds
a
bit
redundant.
J
I
know
given
we're
talking
about
xml,
but
I
had
taken
a
very
terse
approach
to
this
in
an
attempt
to
keep
the
you
know
the
payload
payload
sizes,
down,
to
a
certain
extent,
it's
just
a
model
I've
used
in
the
past.
If
that
you
know
if
people
don't
like
that,
I'm
more
than
happy
to
change,
I
don't
think
that
should
prevent
anything
from
moving
forward
and
so,
but
I
think
yeah,
I
I'm
and
john,
you
know
feel
free
to
jump
in.
It
sounds
like
that
this
may
be.
J
That
might
be
a
discussion
more
in
this
group.
You
know,
rather
than
trying
to
just
go
backwards
and
forwards
on
it.
On
the
the
pr
structure-
absolutely:
yes,
yes,
so
there
were
a
couple
of
nits
which
I've
addressed
some
of
them.
One
of
them.
I
think
which
I
sort
of
got
my
head
around
is
my
my
mental
failing
on
xml
schemas,
and
that's
probably
because
it's
just
so
long
since
I've
done
one
so
there
are.
There
are
maybe
some
clarifications
to
do
in
the
schema
itself.
J
G
I
still
don't
quite
know
what
the
xsne
is
going
to
allow.
I
guess
what
I
probably
do
is
take
the
schema
and
try
it
against
a
bunch
of
xml.
So
I
I
think
the
only
bit
of
the
schema
that
I'm
uncertain
around
is
the
yeah
that
the
xml
element
that
includes
that
excess
any.
I
don't
quite
know
what
that
will
do.
Can
you
have
just
text?
G
Does
it
have
to
be
an
element
that
can
then
do
anything?
And
I
don't
know
what
that
ends
up
as
in
a
in
an
sdk
either?
I
kind
of
I
think
I
understand
the
overall
aim
to
be
a
little
bit
like
the
data
property
within
json
that
lets
it
be
an
arbitrary
json
token.
I
think
that
a
subtle
difference
in
xml
is
in
terms
of
what
what
that
can
be.
I
think
it
can
only
be
we
would
have
to
make
it
only
an
element
or
there's
no
sort
of
one
token
type.
J
I
So
so
the
choice
is
great
and
I
think
you
need
to
have
on
choice
you're,
making
either
a
bin
or
takes
txt
and
then
you're
doing
an
or
or
an
e,
which
means
you
don't
have
an
element.
That's
named
xml,
but
you
have
you
put
the
any
right
there,
because
that's
already
being
an
exclusive
choice
by
way
of
being
within
the
the
choice.
I
I
think
that's
how
I
remember
it
and
then
on
all
the
other
complex
types
just
for
our
future
extensibility,
because
we
might
be
adding
something
if
you
make,
if
you
don't
add
the
the
any
attribute
in
any
definition
there.
You
can't
expand
the
type
anymore,
so
so
we'll
basically
have
to
go
in
on
the
cloud
event.
For
instance,
in
the
complex
type
there
needs
to
be
a
an
enemy
at
the
end
of
it,
so
that
we
can
go
and
add
stuff
later.
G
I
would
have
expected
that
when
we
want
to
add
stuff
in
the
future,
we
modify
the
schema
to
say:
okay
now
this
is
allowed
and
it
wouldn't
be
valid
in
the
old
schema
and
it
would
be
valid
in
the
new
schema.
I'd
expect
that
to
be
okay
rather
than
we'll
just
allow
anything
and
it
might
take
on
some
meaning
later
on.
I.
I
Have
been,
I
have
been
on,
this
matter
have
had
exactly
that
stance
in
my
over
years
and
then
have
been
scooped
by
sam
ruby
that
that's
really
terrible,
and
I
should
be
doing
those
things
so
I
have
to
after
I
have
to
go
and
and
and
and
re-read
where
I
was
there
from
a
mental
mental
state.
But
I
am,
I
have
the
the
the
sam
ruby
perspective
of
be
very
permissive
of
what
you
allow
there,
because
that's
going
to
make
you
happier
in
the
long
run.
A
G
Right,
yes
and
we've
got
that
flexibility
for
extensions,
yeah
or
arbitrary.
Well,
it's
an
excellent
you
know.
Almost
any
xml
document
is
a
valid
cloud
event.
It
just
has
to
have
a
few
little
bits.
I
don't
know
I
I
tend
to
be
against
the
be
permissive
with
what
you
ex
accept
just
to
go
back,
because
I
suspect
that's
a
rabbit
hole
on
the
xml
element
in
the
cloud
event
data.
G
J
J
I
J
J
I
should
remove
that.
That
was
my
poor
attempt,
because
originally
I
had
specification
version
called
out
specific
explicitly
as
an
attribute
or
an
element
rather
and
then
I
mentally
went
oh
well,
there's
got
to
be
three
more,
but
obviously
that's
nonsense
because
it
could
be
any
three.
So
I
should
just
make
that
zero.
Basically
and
then
it
depends.
A
C
Yes,
so
for
me
I
tend
to
agree
with
the
performance
with
efficiency
discussion
but
like,
for
example,
the
attribute
names
should
map
this
back
so
like
spec
there,
for
my
opinion,
should
be
spiked
version
like
I
prefer.
I
prefer
that
we
cut
some
bytes
somewhere
else
by
like
keeping
the
consistency
of
the
attribute
names,
in
my
opinion,
important
so.
J
G
G
G
Something
has
to
be
one
or
the
other,
but
you
could
have
the
element
being
ce
instead
of
cloud
event,
and
you
know
really
really
compress
it
down
as
much
as
you
want
to
and
mandate
that
any
spec
implementing.
This
must
treat
them
the
same
way
and
you
specify
whether
you
want
the
verbose
or
the
concise
version
when
you
format
things
so
you're
asking
for
two
xml
schemas,
two
xml
schemas
that
we
would
keep
absolutely
in
sync
and
yeah.
G
J
I
I'm
just
putting
my
sdk
writer
hat
on
now.
I'm
I'm
trying
to
understand
what
that
means
to
an
sdk
slinky
might
want
to
comment
on
this
as
well.
I
mean,
essentially
that
would
mean
I
would
in
the
java
sdk
I'd
write
two
format:
providers
that
would
produce
different
formats,
but
both
consume,
produce
independent
formats
but
consume
both
formats.
Is
that
what
you're
saying.
G
A
Can't
raise
my
hand,
let
me
do
it
here.
I
I'm
leaning
more
towards
what
slinky's
saying
well.
I
can
definitely
appreciate
jim
your
desire
for
compactness,
as
somebody
who
almost
never
uses
tooling,
including
back
in
the
days
we
were
doing
soap
stuff.
I
never
used
the
whistle
to
whatever
generators
so
I
hand
coded
everything.
J
Right
yeah,
I
get
it
okay,
yes,
so
that
one
I
accept.
If
we
look,
maybe
look
at
the
the
actual
markdown
document
and
see
whether
the
produced
formats
or
the
examples
actually
look
actually
that
one
needs
editing.
Doesn't
it
because
that's
wrong
like
this
yeah,
so
that's
what
it
would
end
up.
Looking
like
this
seems
to
be
out
of
sync,
I
thought
I'd
push,
changes
that
synchronize
this
a
bit
more,
but.
J
Right,
so
this
is
what
I've
struggled
with.
I
could
add
those
we
would
still
end
up
with
a
bag.
I
think
to
hold
all
of
the
extensions,
and
also
I
I
guess
I
I
started
down
the
road
of
creating
all
the
different
element,
types
to
represent.
All
the
you
know,
value
types
that
we
pass
around,
and
this
did
I
just
refactored
it
into
one
flat
thing
yeah,
so
I
didn't
have
to
look
at
it
and
go
oh.
What
sort
of
element
is
this
you
know?
Is
it
meant
to
be
a
string?
J
Elements
yes,
yeah,
you
you
absolutely
can,
but
then,
when
you
get
to
extensions,
you
come
back
to
this
model
again
yeah,
because
now
it's
very
much
like
what
I
ended
up
doing
with
protobuf,
which
I'm
still
not
entirely
sure
I
was
happy
with
in
that
you've
got
two
different
models.
You
know
you've
got
a
model
for
an
attribute
that
is
defined
by
the
spec,
so
you
know
what
type
it's
meant
to
be,
but
then
you
have
these
other
attributes,
which
are
extensions
which
are
untyped.
I
Yeah,
but
that's
the
so
excellent-
has
exercise
tag
for
this.
So
there's
the
xml
schema
instance
namespace
and
the
schema
instance
spec
and
the
xsi
schema
instance
in
space
gives
you
a
type
system
that
you
can
apply
to
any
any
particular
element.
So
the
default
is
that
their
text
and
then
you
can
go
and
constrain
them.
You
can
constrain
it
further
down.
I
A
I
J
G
A
A
Fine,
well
it
I
like
consistency
and
the
fact
that
we
lowercase
everything
anyway
for
ours.
That
seems
consistent
to
it
here
too
right,
yeah,
okay,
yeah.
I
know
I
know
you
said
jim.
You
said
that
these
are
all
machine
readable
anyway
and
screw
the
user.
I
actually
like
the
idea
of
a
user
being
able
to
look
at
the
output
from
json
and
then
xml
and
be
able
to
say.
Oh,
I
can
naturally
see
the
mapping
back
and
forth
between
the
two.
J
Yeah,
well
I
mean
otherwise,
you
know
what
some
parts
are
meant
to
do.
How
does
it
know
whether
it's
looking
at,
I
guess
the?
What
we're
really
saying,
and
maybe
it's
what
clemens
was
saying
you
know
anything
after
data,
maybe
you
treat
as
an
extension
and
if
it
doesn't
match
the
the
model
you
have
for
an
extension,
then
it's
illegal.
G
I
would
be
reticent
to
differentiate
between
built-in
attributes
and
built-in
optional
attributes
and
extension
attributes.
For
the
same
reason,
we've
got
elsewhere
that
they
might
be
adopted
later
on,
so
the
ordering
I
would
prefer
to
see
all
attributes
come
before
data
and
include
type
information.
Where
appropriate.
K
I
A
J
I
I
J
A
A
A
Okay,
I
think
we
lost
everybody
who
we're
going
to
lose.
So
where
are
we
with
respect
to
actually
doing
testing
here?
To
be
honest,
I'm
getting
a
little
worried,
I
know
and
I'm
not
sure
I'm
not
going
to
imply
people
are
slackers
or
anything
it's.
I
know
everybody's
really
really
busy,
so
people
haven't
had
time
to
do
it
for
so,
for
example,
I
know
scott
wants
to
do
stuff-
and
I
picked
him
about
yesterday,
but
he
said
he's
really
really
busy
on
k-native
1.0
release.
A
I
So
I
can
say
that
I
don't
have
endpoints
published
in
this
document
yet,
but
I
have
a
implementation
that
is
wrapping
effectively
in
azure,
complete
azure
resource
core,
and
you
can
discover
all
the
events
that
are
being
raised
from
those
azure
resources
and
you
can
go
and
subscribe
to
all
of
them.
So
I
have
a
effectively
complete
shim
with
discovery
api
and
subscriptions
api
around
the
native
inventing
capabilities
of
event
grid.
I
So
that's
something
that
happens
have
been
sitting
has
been
sitting
around
for
a
while
now
and
I
just
haven't
been
able
to
go
and
publish
the
end
point
because
the
last
the
late,
the
last
work
is,
I
need
to
go
and
create
a
resource
group
and-
and
I
need
to
create
a
thing
that
actually
does
does
stuff
like.
I
need
to
go
and
have
a
you
know
create
some
some
blobs
and-
and
so
I
need
to
make
the
thing
active.
So
it
actually
raises
that,
but
it's
so
I
need
to
have.
I
I
A
But
what
does
it
mean
in
terms
of
testing,
because
one
of
the
things
that
we
talked
about
in
the
past
for
for
a
testing
perspective
is
to
get
a
little
bit
of
consistency
in
terms
of
what
people
can
expect
in
the
endpoints
itself?
So
will
you
be
able
to
have
discovery,
endpoint
services
that
match
some
of
the
stuff
we
talked
about
in
here,
yeah.
I
I
A
That's
that's
great
yeah,
because
I
need
to
do
some
more
work
on
mine,
but
I
think
mine
is
pretty
far
along
and
I
would
love
to
have
somebody
else
to
hook
up
to
and
start
chatting
with.
So
that'd
be
good.
We
can
maybe
sync
up
next
week:
yeah
cool,
okay,
anybody
else
in
the
call
want
to
chime
in.
I
don't
think
we
have
any
of
these
folks.
Unfortunately,.