►
From YouTube: Kubernetes SIG Instrumentation 20200123
Description
Meeting notes: https://docs.google.com/document/d/17emKiwJeqfrCsv0NZ2FtyDbenXGtTNCsDEiLbPa7x7Y/edit#heading=h.qpfxt91hdl2x
A
B
You
I'm
mark
cake,
I'm,
a
principal
engineer
at
VMware
and
I've
been
working
with
serverless
for
quite
some.
Quite
some
time
help
kick
off
the
server
list,
working
group
back
in
mid,
2017
I,
and
then
you
know
part
of
the
the
rationale
behind
that
was
well.
Public
clouds
had
serverless
offerings.
There
wasn't
really
a
good
understanding
about
what
does
that
mean
for
non-public
clouds,
and
so
what
we
wanted
to
do
was
get
together
a
bunch
of
industry
people
to
talk
about.
B
We
felt
that
having
some
level
of
common
eventing
I
am
by
by
common
eventing
I,
don't
mean
that
every
event
has
to
be
identical
across
clouds,
but
just
a
way
to
better
identify
what
the
event
is
and
how
the
transit
that
event,
and
so
we
kicked
off
this
effort
called
cloud
events.
It
was
part
of
the
service
working
group,
but
then
we
applied
for
that
to
be
a
CNC
F
project
itself,
and
it
has
now
made
it
to
incubation
stage
as
of
late
last
year.
B
All
right,
so
what
problem
are
we
trying
to
solve
with
cloud
events?
We
live
in
a
multi
cloud
in
multi
service
world.
You
know,
I
know
that
I
interact
with
multiple
public
clouds,
I,
you
know
being
from
VMware
I've
interoperate
with
private
cloud,
SAS
services
etc,
and
it's
not
always
clear
how
you
can
do
a
venting
across
between
these
clouds.
You
know
I
might
want
to
stitch
together
events
coming
from
a
SAS
service
going
into
my
public
cloud.
B
How
do
I
identify
what
that
is
in
and
be
able
to
handle
that
correctly,
and
so
really
we?
What
we're
looking
at
is:
how
do
you
transit
these,
the
actual
payload
of
the
event,
without
changing
it
through
different
types
of
routing
and
and
so
we
really
wanted
to
have
this
way
to
attach
metadata
to
events
for
that
for
the
transit.
B
If
you
look
at
what
events
are-
and
you
know
that
this
is
probably
well
known
to
to
all
of
you-
you
know
there
there's
some
occurrence
that
happens
and
it's
a
statement
of
fact
about
something
that
did
happen.
The
event
is
expressing
that
an
occurrence
in
the
in
the
in
the
context.
So
now
that
we
have
this
event,
we
need
to
now
deliver
at
some
place
and
then
some
action
will
be
taken.
You
know
it
could
be.
You
know,
sent
to
dev
Knoll.
B
B
We
have
you
know,
as
I
mentioned,
you
know,
one
of
the
things
that
kicked
this
off
was
all
around.
How
do
you
deal
with
functions
and
the
events
needed
for
those
functions,
and
so
we
wanted
to
be
able
to
better
specify
how
you
know
what
is
the
format
of
the
event
coming
into
those
systems
and
how
do
identify?
What
the
type
of
that
event
is
such
that
I
can
route
it
correctly
to
the
correct
function,
and
then
we
have
a
variety
of
different
needs
around
SDKs.
B
B
You
know
here's
another
diagram,
talking
about
the
complexity
that
we're
trying
to
help
mitigate
where
you
might
have
IOT
devices
that
are
sending
to
an
IOT
gateway.
That's
likely
going
to
be
going
over
MQTT.
You
know
how
do
you
get
that
event
bumbled
into
mq
in
order
to
now
deliver
to
that
gateway?
That
gateway
can
now
use
a
variety
different
formats
to
deliver
it
to
other
systems,
things
like
Nats,
Kafka,
HTTP,
AMQP,
and
then
from
there.
Those
systems
are
likely
intermediates.
B
B
And
so
that
you
know
that
the
bottom
line
here
is
that
cloud
events
is
trying
to
define
this
common
metadata
around
the
events.
It
is
we
understood
that
we
need
to
make
it
simple
enough,
but
expressive
enough
to
be
able
to
deal
with
different
form
of
formats
and
transports
to
to
be
able
to
move
that
event
through
systems
and
then
be
able
to
act
upon
it
when
it
when
it
finally
gets
delivered
to
the
consumer,
and
so
we,
you
know,
we've
tried
to
develop
both
the
specification
and
SDKs
to
facilitate
this.
B
So
if
we
look
at
you
know
what
is
what?
What
is
this
thing?
If
we
just
look
at
HTTP,
this
is
a
typical
HTTP
header
and
data
that
that's
being
sent
a
payload
that's
being
sent
along
with.
It
happens
to
be
application.
Json,
and
you
know
we
thought
about
this
and
went
you
know.
How
can
we
make
it
easy
to
adopt
cloud
events
by
just
adding
you
know
a
certain
number
of
required
fields
specifying
what
this,
what
the
specification
version
is,
so
that
we
can
now
be
able
to
decode
the
other
fields
correctly.
B
What
is
the
type
of
this
event?
And
this
is
a
new
item
and
it's
coming
from
you
know
bit
code
comm.
This
is
one
way
to
be
able
to
have
a
designation
of
that
type.
We
want
to
be
able
to
say
you
know
what's
the
source,
where
did
they
come
from
and
then
what
is
the
I
on
on
this?
Those
are
the
four
required
fields
in
order
to
transit,
a
cloud
event
throughs
through
these
various
systems.
Now,
based
on
this
information,
I
can
now
reason
about
it
by
saying.
Oh,
this
is
a
new
item.
B
B
I'd
say
that
you
know
it
depends
on
who's
implementing
it,
and
you
know
to
what
level
they
want
to
bundle
in
more
cloud
event.
Type
type
of
attributes
into
it
I
know
that,
from
some
of
my
implementation,
the
binary
format
is
fairly
easy
to
add
into
existing
event,
streams
that
are
using
HTTP
and
then
that
will
now
be
able
to
play
well
into
the
cloud
event
ecosystem.
B
So
we
have
a
variety
of
different
deliverables
that
we
put
together.
These
are
all
available
on.
You
know
in
the
github
repo,
so
we
have
a
specification
that
defines
what
is
all
of
the
metadata
that
that
we
think
is
needed
for
transiting
a
cloud
event.
We
have
different
serialization
rules
such
that
you
know
you
can
have
Jason
and
MTP
protocol
event
formats
and
be
able
to
now
serialize
the
event
into
that
format.
B
B
The
extensions
we
anticipate
that
there
will
be
extensibility
needed
for
special
purposes,
but
we're
we
we
we
feel
that
we
would
prefer
not
to
have
extensions
wherever
possible
to
make
it
more
interoperable,
but
we
also
understand
that
there
will
be
this
need
that
comes
up
and
I
think
there
might
be
a
couple.
They've
been
defined
already.
B
When
we're
looking
at
the
what
is
the
adoption
of
cloud
events,
there's
several
different
open-source
projects
that
are
using
cloud
events
such
as
Kay,
dedapper
and
Kay
native
eventing
is
using
cloud
events
natively
and
then
also
in
production.
Microsoft
Azure
have
built
cloud
events
into
their
event
grid
so
that
you
can
say
I
want
a
cloud
event.
B
As
I
mentioned,
we
exited
the
the
service
working
group
with
a
lot
of
different
ideas
about
what
should
come
next
and
we
have
brainstormed
on
a
lot
of
different
proposed
work
streams.
You
know
we
what
kind
of
packaging
cons
contract
do
we
need
function,
signature.
These
are
more
serverless
working
group,
but
they
also
stretch
into
cloud
events
as
well.
So
Packaging
contract
is
more
more
serverless
working
through
function.
Signatures
is
the
same,
but
there's
also.
How
do
you
discover
as
Anna
discover
events?
B
You
know
what
can
be
delivered
from
from
an
endpoint,
so
we
we
believe
that
we
need
a
discovery
or
event
registry
API
that
be
able
to
query
that
and
say
what
events
can
you
provide
for
me
and
then
a
way
to
and
then
an
API
for
a
subscription
as
well
to
be
able
to
now
say:
I
want
to
subscribe
to
those
events.
We
also
think
that
there's
needs
for
you
know
what
is
the
schema
of
different
cloud
events
that
might
that
might
be
useful
as
well.
B
C
C
B
B
Their
argument
was
you
know
right
now
you
have
this
declarative
API
in
kubernetes
being
able
to
you
know
why
can't
you
just
query
at
CD,
for
you
know
what
is
the
current
state
of
things
as
opposed
to
having
to
admit
these
events
that
will
be
out
of
sync
with
you
know
what
reality
is
today
or
you
know
right
now,
and
my
response
to
that
was
that
it's
really
intended
for
different
purposes,
that
you
know
what
what
the
events
are.
Our
statements
of
fact
that
you
know
this
is
something
that
has
occurred.
B
B
I
need
to
keep
track
of
everything,
that's
happening
on
it,
whereas
with
cloud
events
I
can
now,
if
there's
an
event
that
occurs
on
my
clusters,
that
can
now
be
transited
in
to
say
you
know,
filtered
and
then
into
say,
pager
duty
right,
and
so
you
want
to
you,
want
to
be
able
to
act
upon.
You
know,
use
actions
on
those
events
that
may
be
needed
needing
to
be
processed
in
external
systems,
not
connected
to
that
cluster.
B
C
And
so
I
shared
the
link.
That
brings
me
to
a
similar
battle.
I
have
with
Azure
teens,
who
don't
see
the
value
of
event-driven
things
or
cloud
events,
because
they
think
they
already
support
it.
With
its
the
day.
Thought
might
be
the
same,
but
it's
the
count
the
way
it
is
being
consumed
and
sometimes
they
differentiate
I.
D
Want
to
point
out
one
thing,
so
there
is
I
think
one
misunderstanding
about
naming,
because
kubernetes
events
have
totally
different
semantics.
What
the
event
that
you
are
describing
so
Brenda's
events
are
freeform
like
even
like
structured
lots
that
are
attached
to
to
kubernetes
over
the
sample
of
this
object
or
point
you
have
ponder
to
another
subject,
so
they
don't
have
guarantee
of
delivery.
They
are.
D
They
have
like
building
semantics
for
squashing
events.
So,
if,
like
something
is
unavailable
and
times
you
are
50
times,
you
don't
care,
you
tell
you
care
about
for,
like
the
latest
state.
Basically
you
care,
maybe
how
many
times
it
happened,
not
exact
time
when
it
happened
or
like
if
if
there
was
some
event
lost
in
between
so
my
like
my
what
I
wanted
to
point
out
is
that
when
you're
talking
about
cloud
events,
we
are
talking
about
introducing
a
new
instrumentation
into
paratus.
D
C
D
Events
typed
is
that
that's
changing
from
fever
I'm
not
talking
about
like
they're
mad
when
Reaper
I'm
talking
about
the
message
like
the
whole
idea
about
event,
introducing
type
basically
creates
like
framework
and
need
to
track.
Although
all
the
types
of
events
that's
commenced
can
generate.
Currently,
any
controller
can
generate
any
type
of
events,
and
no
one.
C
A
A
Pre
defines
what
logs,
like
some
some
application.
Will
log
I
think
the
in
some
in
some
way
the
events
API
is
actually
an
API
and,
to
some
degree,
is
actually
structured,
as
merged
said
I
feel
like
there
is
I
think
there
are
other
external
integrations
already
too,
like
right.
Kubernetes
events
into
elasticsearch,
for
example,
I,
believe
there's
a
project
by
hefty
Oh
called
event
router.
That
does
this
correct
me
if
I'm
wrong
with
this.
A
I,
don't
know
that,
but
I
think
it's
kind.
It's
feels
like
it's
roughly
a
similar
domain
and
so
I
think
I.
Think
I
could
see
the
value
for
something
like
this
I
think.
If
we
want
to
move
forward
with
something
like
this,
the
best
thing
to
demonstrate
value
would
be
to
write
such
an
external
integration
and
show
that
around
maybe
showed
here
at
second
cementation
meter.
You.
A
C
B
Sounds
like
you
need
to
energy
some
formalism
around.
Yes,
how?
How
would
you
be
able
to
specify
the
type
of
an
event
and
then
be
able
to
have
a
better
definition
as
to
what
that
event
schema
would
look
like,
but
with
it,
but
having
a
free-form
event,
which
you
know
I
think
you
said
that
it
looks
more
like
log
data
doesn't
seem
formal
enough,
for
you
know
the
type
of
system
that
kubernetes
is
built
around
I.
A
D
C
D
D
C
B
C
A
I'm
definitely
not
disagreeing
I
feel
like
I
feel,
like
maybe
the
events
as
we
have
them
are
too
raw
of
a
thing
to
build
cloud
events
around.
It
seems
like
maybe
maybe
cloud
events
is
more
more
suitable
for,
like
maybe
transforming
alerts
from
Prometheus,
let's
say
into
a
cloud
event
and
ingest
that
into
some
other
system
or
an
alert
that's
produced
by
elasticsearch,
based
on
the
unstructured
events
that
we
have
today.
That's.
C
True,
but
it
can
also
be
just
as
simple
as
hey
this
deployment
was
created,
hey
this
HBA
scaled
up,
HBase
scaled
down,
all
of
these
kind
of
things
and
I'm
pretty
sure
it's
already
possible,
but
it's
it's
not
really
easy,
and-
and
regardless
of
that,
there's
a
lot
of
fuelling
around
cloud
events
already
and
a
lot
of
integration.
So
yeah.
A
A
A
But
if
the
data
is
not
in
a
form
that
would
be
very
useful
to
integrate
with
cloud
events,
then
that's
the
thing
that
we
would
need
to
fix
first
right
and
if
that's
a
fundamental
thing
that
kubernetes
doesn't
want
to
change
and,
frankly
that's
something
that
we
would
also
need
to
discuss
with
Corinne
ADIZ
API
machinery,
because
we're
primarily
in
charge
of
instrumentation
itself
but
like
API
kind
of
things,
is
definitely
proven.
These
API
machinery,
territory,
yeah.
A
So
yeah,
my
recommendation
would
be
to
even
if
it's
not
perfect,
build
some
sort
of
external
integration
to
show
the
value
of
this
and
then
show
these
kinds
of
use,
cases
and
I
think
if
we
can
have
something
very
concrete
and
then
there
could
be
a
possibility
where
we
do
something
like
this.
Obviously
that
all
the
things
that
I
said
about
API
machinery
and
and
all
of
those
things-
people
there's
it's
not
just
this
group
that
can
decide
these
kinds
of
things,
but.
B
Yeah,
so
there
is
some
intermediate
steps
that
you
could
take,
which
is
say,
you're
attaching
to
functions
as
a
service.
We
did
this
around
vSphere
events,
which
are
not
cloud
events,
but
we
subscribed
it
to
the
vSphere
eventing
I
have
those
transited
into
an
event
driver
that
then
transformed
the
vSphere
event
into
a
cloud
event
and
then
forwarded
it
on
that
same.
B
Be
used
for
kubernetes
for
the
the
events
that
you
know
about
yeah
again,
and
then
you
could
prove
out
interoperability
with
other
systems.
The
usefulness
of
it
but
I
would
I
would
like
to
see
you
know
again.
How
could
we
build
cloud
events
directly
into
kubernetes
as
a
first
class
citizen
event,
stream,
yeah.
A
B
A
Was
saying
that's
how
we
could
have
someone
could
create
a
proof
of
concept
for
this
and
if
the
kubernetes
project,
based
on
that,
besides
this
could
be
of
value,
then
we
can
have
another
discussion
around
that.
But
having
said
that,
we
are
out
of
time
and
I
don't
want
to
keep
people
from
attending
to
their
other
schedules.
So
thanks
everyone
for
joining
today's
kubernetes
sig
instrumentation
meeting
and
have
a
wonderful
local
time
all
right.
Thank
you
for
considering
right.