►
From YouTube: Kubernetes WG IoT Edge 20220921
Description
September 21 meeting of the CNCF IoT Edge Working Group. Presentation on Spin by Kate Goldenring. Spin is an open source framework for building and running fast, secure, and composable cloud micro services with WebAssembly. Continue discussion of the edgenative white paper draft.
A
So
hi
welcome
to
the
September
21
meeting
of
the
cncf
iot
edge
working
group
on
today's
agenda.
We've
got
one
item
that
was
a
late
ad
and
that
is
Kate
is
going
to
talk
about
using
a
an
open
source
project
called
spin
to
run
webassembly
applications
at
Edge.
Then
I
anticipate
we'll
move
on
to
discuss
this
group
Edge
native
white
paper.
That
is
linked
in
the
agenda
notes
document
and
we
might
have
time
if
somebody
wants
to
add
a
late
item.
B
Sure
and
Steve,
do
you
mind
passing
over
screen
sharing
too,
because
at
some
point,
I
can
kind
of
do
a
walkthrough
demo,
but
feel
free
to
hold
me
to
time.
I
feel
like
this
is
a
topic
that
we
can
kind
of
delve
into
longer
in
another
session,
but
essentially
Shan
threw
out
a
question
in
a
slack.
That
was
what
is
this
webassembly
on
the
server
thing,
and
how
does
it
relate
to
the
work
that
we
do
on
the
edge
I
recently
switched
companies
and
I'm
working
for
a
company
called
fermion?
B
B
If
you
think
about
VMS
created
this
first
idea
of
how
we
can
isolate
our
workloads
and
containers
being
the
second
wave
of
how
we
can
build
these
microservice,
architectures
and
webassembly
could
be
the
next
wave
of
kind
of
building
out
your
microservice
applications
with
server-side
webassembly
and
a
tangent
with.
That
is
the
reason
we
have
the
ability
to
run
webassembly
on
the
server
in
a
way.
That's
uniform
and
Community.
Based
is
because
of
the
webassembly
systems
interface,
which
is
there's
a
so
there
is
a
organization
called
The,
bytecode
Alliance.
B
B
B
B
We
actually
have
this
Matrix,
because
we're
kind
of
trying
to
track
which
major
languages
compile
down
to
webassembly
and
in
the
browser
versus
on
the
server
following
the
webassembly
systems,
interface
and
one
thing
that
we
try
and
do
is
put
Engineers
actively
on
building
up
the
ecosystem
around
certain
languages.
So
Java,
for
example,
is
super
close
to
getting
to
this
server-side
webassembly
and
Ruby
and
c,
and
things
like
have
an
ffi
interface
to
see
can
usually
compile
down
to
webassembly
on
the
server.
B
A
That's
my
that's
my
perspective
of
what
a
unicorn
is
and
the
web
assembly
principle
is
kind
of
operating
at
a
different
level
of
taking
an
application
pet,
compiling
it
down
into
a
form
where
it's
extremely
portable
and
getting
it
ready
to
run
on
some
kind
of
run
time.
That
would
run
it.
So
one
is
in
the
runtime
category.
The
other
is
in
kind
of
the
application
category
anyway
back
to
UK,
to
correct
me.
If
you
think
I
stated
that
wrong.
B
B
So
spin
is
something
that
helps
you
create
these
applications
that
are
consist
of
webassembly,
microservices
and
so
I
can
kind
of
quickly
run
through
a
setup
of
that.
If
folks
are
interested,
so
we
have
and
then
I
think
another
question
was:
how
do
you
kind
of
build
out
a
platform
or
an
application
with
this
and
manage
it?
B
So
I
can
show
for
me
on
a
spin
and
then
also
the
fermion
platform,
which
is
open
source,
which
kind
of
has
a
platform
form
as
a
service
visual,
so
you
can
see
which
of
your
applications,
which
of
your
microservices
are
running
and
kind
of
manage
them
a
little,
and
so
that
can
all
be
done
by
cloning.
The
installer,
the
the
Permian
platform
installer,
which
executes
microservices,
is
using
Nomad.
B
So,
instead
of
kubernetes,
nomad
is
the
orchestrator
here
and
essentially
a
task
is
kind
of
the
lowest
level
of
a
nomad
job,
and
that
task
will
just
call
down
to
spin,
which
is
a
native
binary.
That
will
then
execute
the
appropriate
webassembly
module
before
jumping
into
that
I'll
kind
of
just
show.
What
spin
itself
is.
B
So
all
you
need
to
do
to
create
a
new
spin
application
and
these
documents
the
documentation
for
that
is
kind
of
the
quick
start
here.
We'll
walk
you
through
all
this,
but
all
you
need
to
do
is
install
spin,
which
is
just
you
can
either
clone
it
and
install
cargo
or
a
binary
install,
and
then
you
can
then
pull
down
templates
for
what
kind
of
spin
application
you
want
to
make,
namely
like
what
languages.
C
C
B
And
then
you
can
make
a
path
based
off
of
the
spin
like
when
you
query,
then
you
can
have
different
paths
for
each
one
of
your
microservices,
so
we'll
just
have
this
be
at
the
root
of
the
URL.
But
if
you
wanted
to
have
multiple
different
webassembly
modules
that
can
be
spun
up
for
different
endpoints,
you
could
create
different
endpoints
for
that,
so
we'll
just
have
one
there
and
you'll
see
what
just
came
up.
B
Is
this
hello,
rust
project
and
a
spin
app
is
defined
by
a
spin.tomo
file,
and
so
this
is
essentially
saying
these
are
the
components
of
this
webassembly
application
and
each
component
is
its
own
webassembly,
module
or
microservice,
and
so
here,
when
we
quickly
spun
one
up,
we
have
one,
but
we
could
add
more,
and
this
is
just
going
to
be
invoked
whenever
you
hit
the
face
of
the
spin
end
point.
And
so
if
we
go
in
and
look,
this
is
what
was
quickly
generated,
which
is
just
a
simple
hello
world.
B
So
what
happens
is
when
you
hit
the
endpoint
spin
will
and
run
the
webassembly
module
invoke
this
hello,
rust
component.
So
the
key
here
is
that
in
microservice
architecture
today,
every
single
container
that
you're
running
has
a
server.
It
has
a
TLS.
It
has
all
that
built
into
it
and
it's
across
all
of
them.
Instead,
with
this,
sir,
the
spin
application
or
the
spin
sorry,
the
spin
binary
is
the
only
thing
that
has
a
server
and
it
is
invoking
these
webassembly
modules
when
it
gets
requests
and
calling
the
correct
one
and
passing
along
any
requests.
C
C
B
Spin
ran
that
webassembly
module
called
its
hello,
rest
Handler
and
then
got
the
response,
and
so
we
can
quickly
easily
change
this
and
we
can
also
add
different
components
to
our
application,
so
things
that
you
wouldn't
necessarily
think
were
options
in
the
browser.
For
example,
we
could
add
environment
variables
to
our
our
Tome
file.
So
if
we
wanted
to
or
local
paths
to
certain
files
that
are
locally
accessible.
So
if
we
wanted
to
set
an
environment
variable,
for
example,.
C
B
All
right,
how's
that
looking
did
I,
do
anything
mess
up
anything
there
I
think
we
might
be
okay
but
we'll
see,
and
then
we
can
simply
just
spin
build
spin
it
up
again
and
then
there
we
go
so
you
can
see
that
you
can
set
like
server-side
environment
variables.
We
could
also
set
a
path
to
a
local
file
that
we
could
be
changing
and
reading
and
writing
to.
B
So
those
are
just
some
examples
of
kind
of
the
microservices
you
could
build.
We
could
create
another
microservice
here
that
could
be
at
a
different
endpoint.
That
may
be
reads
from
that
file
instead
of
outputting
an
environment
variable.
So
this
is
kind
of
just
the
end
to
end
of
how
you
would
use
Spin
and
then,
if
you
wanted
I,
actually
I'll
just
pause
here.
Are
there
any
questions
on
this
so
far,
foreign.
A
B
B
A
I
was
wondering
at
Edge.
You
know
you
showed
this
kind
of
I'm,
seeing
an
IDE
and
the
ability
to
build,
but
maybe
in
an
edge
node
since
there's
no
people
or
operators
there
I
don't
actually
need
this
ability
to
build
anything.
I
just
need
to
run
it.
Does
it
emit
web
assemblies
that
really
at
the
edge
notes?
Then
you
don't
need
to
install
spin
or
is
spin
integral
an
integral
requirement,
just
because
it's
this
service
that
kicks
off
running
the
components
that
you
built.
B
Yeah,
so
you
wouldn't
need
to
necessarily
build
this.
You
could
just
move
over
this.
You
could
build
this
elsewhere
and
then
just
you
know
send
that
over
to
the
edge
so
I
like
thinking
about
the
idea
of
the
future
of
what,
if
you
pass
this
inside
the
body
of
some
sort
of
messaging
protocol,
the
module
that
you
want
to
run
immediately.
I
think
that's
a
cool
idea
around
webassembly
on
the
server,
because
these
modules
are
so
so
small
themselves.
So
yeah
you
wouldn't
need
to
build
this.
You
could
on
the
edge.
B
But
if
you
want
to
just
run
webassembly
on
your
servers,
you
could
just
load
a
webassembly
runtime,
so
we're
using
wasm
time,
which
is
the
supported,
webassembly
runtime
from
the
bytecode
alliance
and
then
just
run
your
webassembly
like
execute
your
webassembly
modules.
There
and
if
they're
long
lasting,
they
could
just
continue
to
live
there,
but
anytime
you
need
to
change
them
out.
You
would
just
need
to
manually
interact
with
the
device.
B
So
it
depends
on
the
language
you're
using
so,
for
example,
for
I'm,
like
we
have
a
chart
here,
I'm
pulling
it
up.
So
what
webassembly
on
a
server
has
a
concept
of
fuel
which
pretty
closely
aligns
with
CPU
usage
and
so
for
I,
actually,
don't
know
how
it's
converted,
though,
what
the
number
means
percentage
of
a
CPU,
but
on
the
memory
side,
for
example,
a
simple
rust
hello
world
is
about
these
numbers
and
bytes.
B
kilobytes.
So
if
it's
not
running,
then
there's
no
memory
being
used.
The
file
itself
is
128
kilobytes
when
it's
running
it
takes
about
a
megabyte
of
memory
and
then
the
latency,
which
is
I
think
what's
really
impressive,
is
how
long
it
takes
to
start
is
in
the
like
half
a
millisecond,
a
range
for
a
simple
rust
one.
B
It
gets
bigger
as
you
talk
about
other
languages,
so
go,
for
example,
is
about
double
on
all
those
numbers
and
C
plus
plus,
is
about
equivalent
on
all
the
numbers
as
rust,
but
uses
a
lot
less
CPU.
So
each
of
the
languages
have
different
benefits
to
it.
Let
me
see
if
they
have
other
ones
that
are
worth
mentioning.
A
B
A
B
So
this
is
something
that
might
be
interesting
to
look
at
too,
but
there
are
specific
scenarios
that
are
being
explored
for
the
iot
edge
space
yeah
right
now,
we're
trying
to
just
get
people
excited
about
webassembly
and
using
it
easy,
and
so
we
haven't
gotten
the
chance
to
explore
kind
of
putting
this
on
a
small
sensor
or
on
a
smart
Edge
nodes
and
seeing
what
happens.
But
it's
definitely
a
really
interesting
space
to
look
at.
A
Yeah
that
looks
cool
I
have
one
final
question
and
I
think
it's
probably
outside
the
scope
of
spin
itself.
But
you
can
tell
me-
and
I
was
just
curious
as
to
how
this
fits
into
the
existing
Cloud
native
or
Edge
native
packaging
and
orchestration
systems,
meaning,
like
I,
think,
I've
heard
that
web
assemblies
can
be
put
into
oci
containers,
for
example,
or
are
there
alternate
things
going
on?
That
would
be
perhaps
better
for
getting
these
web
assemblies
out
to
Edge
and
also
I
heard
you
mention.
B
B
A
lot
of
the
folks
offer
me
on.
Originally
some
of
them
worked
on
crustlet,
which
was
a
kubernetes
cubelet
written
in
Rust
and
I
also
worked
on
that
project
and
crosslit's
objective
was
to
enable
running
webassembly
on
kubernetes,
just
as
you
would
containers
so
it
made
it
so
that
effectively,
the
only
change
in
the
workflow
of
an
operator
would
be
in
the
Pod
spec.
B
The
oci
image
for
your
container
instead
would
point
to
a
webassembly
module,
so
the
open
container
interface
I
think
that's
what
it
stands
for
made
it
so
that
you
can
have.
It
doesn't
just
have
to
be
containers
that
are
referenced
from
these
oci
URLs
and
instead
we
also
could
package
a
webassembly
module
as
an
oci
image,
and
so
that's
how
acrosslet
worked.
B
Chrysler
became
increasingly
Hard
to
Handle.
There
was
networking
issues,
storage
issues,
all
that
had
to
be
implemented,
and
it
it
was
just
not
a
good
fit.
So
then
we
explored
what
it
would
look
like
to
use
Nomad
instead,
and
it
took
like
six
days
to
do
what
was
taking
months
in
kubernetes
and
that's
because
Nomad
has
an
idea
of
different
task
drivers
and
the
ability
to
essentially
call
down
to
a
native
binary
on
a
certain
task.
B
B
There
was
another
question
there
I
believe:
oh,
what?
How
then
do
we
package
these
webassembly
modules
so
with
fermion?
We're
using
an
open
source
project
called
bindle
and
bindle
is
another
way
of
kind
of
its
name
comes
after
bundle,
because
it's
a
way
of
packaging
up
applications
and
all
these
different
parts
into
one.
B
There's.
Some
good
talks
at
wasm
Day
from
a
couple
years
ago,
where
they
talk
about
a
comparison
between
a
a
silverware
drawer
and
a
bundle
and
how
you
have
all
these
different
things
that
you're
putting
together,
but
in
biddle's
versioned,
and
so
you
run
the
bindle
server
which
sits
there
and
receives
new
bundles
and
then
on
the
platform
side
of
fermion,
which
is
hippo.
It
will
then
pull
the
appropriate
bindle
and
serve
it
up.
So
yeah
bindle
is
almost.
A
B
Of
course,
and
then,
if
anyone's
interested
in
learning
more
about
webassembly
on
the
server,
there
is
a
wasm
day
at
kubecon
and
we're
gonna
be
giving
a
couple
talks
there.
And
there
are
plenty
of
other
folks
who
are
talking
about
kind
of
what
webassembly
on
the
server
means,
and
so
that's
always
a
fun
day
around
and
that's
kubecon
North,
America
and
Detroit.
In
about
a
month
now,
foreign.
B
B
So,
with
webassembly
systems,
interface
tejan
is
pointing
out
how
it's
still
pretty
young
I.
Believe
it's
like
only
a
couple
years
old,
so
there's
only
so
much
that
a
webassembly
module
in
the
server
can
do,
for
example,
networking
sockets
so
socket,
except
the
specification
for
that
I
believe
is
accepted.
So
for
the
HTTP
components
within
spin.
It
can
do
a
sorry,
sockets
not
accept
but
socket
send
it
can
do
so.
We
can.
B
You
can
build
an
HTT
component
in
Rust
that
can
or
request
I
guess
that
can
send
out
a
request
to
an
HTTP
server,
but
a
webassembly
module
itself
cannot
accept
requests
because
that
would
require
multi-threading,
which
is
not
supported
in
a
webassembly
systems.
Interface
right
now,
so
there
are
certain
things
that
are
not
fully
mature
yet,
and
that
is
one
of
them
is
I,
guess
receiving
requests,
but
it
can
do
outbound
requests
and
then
there's
a
lot
underway.
So
if
you
go
to
web
assembly.
D
So
this
that's
the
general
question
for
the
web
assembly.
I
have
never
developed
the
application
with
webassembly,
but
applying
the
web
assembly
to
the
HIV
devices
that
can
it
support
like
the
mission
critical
application
like,
for
example,
I
work
on
the
robotics
robots
and
autonomous
driving.
This
kind
of
stuff,
so
I
mean
like
there's,
always
trading
off
and
depends
on
the
use
cases,
but
you
know
like
in
general
what
what
would
you
say?
B
D
D
B
C
B
A
I
think
it's
common
that
you
wouldn't
translate
from
your
language
at
runtime,
right
I
mean
in
other
words,
if
I
chose
to
write
and
see
I'm,
not
shipping
C
code
in
text
down
to
the
location
where
it's
going
to
run.
It's
already
been
translated
to
byte
code
in
advance,
yeah
now
there's
a
second
step
that
is
optional
of
pre-translation,
and
that
is
byte
code
to
the
actual
object
code
of
the
specific
CPU.
You
know
an
x86
or
an
arm,
and
there
it's
potential.
A
Potentially
the
byte
codes
are
interpreted
at
runtime,
but
I
believe
there's
an
option
to
even
then
translate
in
advance
to
Native
object
code.
If
you
can
anticipate
what
the
actual
CPU
is
so
I,
don't
think,
there's
anything
about
webassembly
that
precluded
that
from
taking
place
a
second
thing
for
deterministic,
Behavior,
I
think
for
Mission
critical
things
might
be
things
going
on
related
to
garbage
collection
of
memory.
A
You
know
that
was
often
a
big
limitation
of
java,
which
was
a
run
anywhere
story,
but
the
garbage
collection
of
memory
often
turned
it
into
being
potentially
unpredictable
and
I.
Don't
know
I'm
not
a
Authority
and
don't
even
know
the
answer
on
where
that
fits
in
webassembly,
whether
it
even
tries
to
take
on
anything
related
to
memory
allocation
allocations
in
garbage
collection,
I.
B
Believe
someone
started
looking
at
what
garbage
collection
for
Wazi.
Is
there
there's
someone
who's
looking
into
that,
but
for
languages
that
do
just
in
time,
interpretation
they're,
those
themselves,
The
Interpreter
needs
to
be
compiled
to
webassembly
and
so
for
Java,
for
example,
they're
using
TVM
and
able
to
enable
webassembly
support
for
it.
So
there's
there's
a
lot
of
different
like
different
ways
that
people
are
making
lighting
this
up
for
different
scenarios.
A
A
The
purpose
of
this
white
paper
is
to
that.
We've
observed
that
you
know
the
cncf
has
had
in
place
for
over
five
years,
a
definition
of
cloud
native
me
as
a
a
key
aspect
of
actually
the
the
cloud
native
compute
foundation's
organization
in
terms
of
defining
what
cloud
native
means,
but
when
it
comes
to
running
applications
at
Edge
there's,
there
have
been
General
observations
that
some
of
the
principles
that
stand
behind
Cloud
native
still
pertain
to
Edge
to
running
applications
at
Edge,
but
a
number
of
them
actually
are
called
into
question.
A
You
know
the
you
know.
Some
of
the
things
like
the
illusion
of
a
limited,
scalability
and
elasticity
can
be
quite
different
when
you're
trying
to
run
an
application
at
an
edge
node.
So
this
white
paper
is
an
attempt
to
summarize
the
lay
of
the
land
and
maybe
see
if
we
can
identify
some
consistent
principles.
A
So
we've
been
working
on
this
white
paper
for
a
few
months
now
we're
kind
of
at
the
stage
where
we've
the
discussion
has
moved
down
to
this
section
that
has
a
title
of
edge
native
principles,
followed
by
a
table.
If
people
open
that
link
and
are
trying
to
follow
along
if
it's
useful
I
could
share
a
screen
as
I
scroll
this,
but
I
think
for
purposes
of
being
able
to
read
it,
especially
since
there's
comments,
it
might
be
best
if
you're
on
a
computer
to
open
that
link
yourself
and
follow
along.
A
Six
in
this
document
is
which
we'd
actually
anticipate
surviving
to
be
the
published
white
paper,
and
we
at
one
time
had
a
lot
of
comments
in
this
section,
but
I
think
coming
here
with
the
scope
and
the
what
is
Edge,
that
that
has
kind
of
been
resolved
and
quieted
down
lately.
Excuse
me,
let
me
meet
my
phone.
A
And
then
we
came
up
with
this
idea
that
we'd
open
with
kind
of
these
tables
that
describe
what's
similar
between
Edge
native
and
Cloud
native,
what's
different
and
then
after
the
tables
we're
going
to
move
into
a
text
format
of
getting
into
a
more
detailed
coverage
of
you
know,
kind
of
what
the
similarities
and
differences
are.
We
have
I
think
discussed
everything
up
to
here
and
we're
moving
on
to.
A
It
is
just
I
I
want
feedback
on
it.
It's
probably
too
long
and
I'd
rather
move
it
into
a
text
form
than
this
bulleted
list
kind
of
thing.
But
I
thought
I
put
the
ideas
there
at
least,
and
it's
rough
so
feel
free
to
have
at
it
commented
go
ahead
and
edit
it
delete.
It
add
to
it:
I,
don't
care
someone
else
added
these
comments
about
vendoral,
new
vendor,
neutral,
past
and
I.
Think
Dion
I
think
you
were
saying
last
time
that
you
were
going
to
add
something
about
use
of
context.
A
C
C
A
I
think
in
a
traditional
multi-tenant,
public
Cloud
environment,
if
you
were
actually
able
to
access,
I
o
devices
coming
in
whatever
server
was
running
your
application,
it
would
be,
it
would
be
considered
a
bug.
You
know,
kind
of
a
severe
security
bug,
because
I
I
think
that
that
might
actually
be
the
primary
thing.
A
That's
different
about
Edge
native
that
as
a
goal,
you
kind
of
need
to
have
that
kind
of
access
for
a
lot
of
these
Edge
applications,
but
in
a
traditional
Cloud
native
public
Cloud
environment
that
is
very
undesirable,
so
it
they're
just
Polar
Opposites
there.
In
that
regard,
how
you
do
that
securely
is
an
interesting
challenge.
I
mean
it
even
relates,
potentially
to
the
whole
thing.
A
We
talked
about
with
webassembly,
where
one
of
the
Leading
Edge
things
about
webassembly
are
coming
up
with
a
mechanism
to
safely
open
up
the
sandbox
for
a
web
assembly
running
at
Edge
so
that
it
could
get
to
the
outside
world
to
get
to
things
like.
You
know
that
they're
talking
now
about
file
systems
and
network
connectivity,
but
going
beyond
that,
there's
a
whole
realm
of
getting
to
physical.
I
o
devices
as
well.
A
Anyway,
I
think
this
document
could
actually
use
some
expansion
in
that
area
and
even
if
it's
just
a
statement
of
observing
that
this
is
heavily
in
transition,
and
these
are
some
projects
that
are
attempting
to
take
this
on.
Even
if
they're
not
complete.
Yet
it
would
serve
a
valuable
service
to
the
community
to
get
those
things
documented,
so
that
people
can
go.
Look
at
this
document
to
go
find
some.
You
know,
find
an
initial
starting
point
rather
than
to
have
to
open
up
a
search
engine
and
go
do
that
yourself.
A
Even
if
you
had
to
use
it
within
a
single
node,
you
can
get
that
to
work,
and
you
know
it
can
go
across
things
like
Docker
container
boundaries
and
things,
and
it's
something
that
maybe
10
years
from
now
will
be
looking
at
that
those
kind
of
techniques
as
Dark
Ages,
but
they
are.
It
is
something
you
can
use
to
get
on
the
air
today.
C
Yes,
so
I
played
a
lot
with
with
the
Bluetooth
lately
right
and
and
for
that
you,
you
need
an
access
to
to
actually
the
you
know
the
device
from
a
pod
or
a
container,
and
also
a
deepest
and
Linux.
So
those
you
can
mount
to
your
container
or
a
port
is
a
is
a
is
a
volume
Mount,
but
you
need
to
run
in
in
a
you
know,
privilege
mode
and
things
like
that.
A
B
And
I
think
we've
had
discussions
in
the
past
with
the
container
orchestrated
device
working
group.
That's
also
within
runtime
tag
about
this,
because
they
are
trying
to
make
an
orchestrator
agnostic
way
of
handling
devices
that
wasn't
specific
to
the
kubernetes
device
plugin
interface.
So
it
might
be
interesting
to
kind
of
pull
in
a
tidbit
on
that
as
well.
A
Maybe
we
can't
provide
the
answers,
and
this
is
this
is
an
area
that's
highly
in
transition,
but
we
could
at
least
document
it
as
it
exists
today,
with
a
few
pointers
for
where
you
could
go
to
learn
more
about
some
of
these
projects
and
Save
Somebody.
The
effort
of
going
on
the
search
engine,
Expedition
yeah.
B
I
think
our
only
caveat
there
is
which
projects
to
be
mentioned
and
which
ones
are
not
mentioned
like
it's
going
to
be.
Some
are
going
to
be
excluded
from
that.
We're
obviously
not
going
to
know
all
so
like
some
of
the
eclipse,
IO
fog
work
would
fit
in
that
discussion
about
orchestration
I
feel
like
is
what
is
the
criteria
for
what
we
mentioned
in
that
section
and
recommend
I.
A
Propose
that
we
have
a
caveat
overall
about
this
whole
document
that
we're
not
attempting
to
be
king
makers.
Here
we
don't
make
on
some
of
these
that
are
in
transition.
You
know
we're
not
even
going
to
attempt
to
be
nominating
a
favorite
and
if
people
have
something
they
can
show
up
to
the
meetings
and
get
if
they,
if
they
want
to
entry
in
here.
This
is
a
public
group
and
anybody
who
wants
to
can
add
it
I
think
that
we
should
just
have
the
people
who
are
contributing
note
anything
that
they're
aware
of
that.
A
You
know
they
would
consider
to
be
at
least
plausible
or
not
ridiculous
and
we'll
just
put
them
in
alphabetical
order,
rather
than
nominate
any
favorites
here,
but
there's
some
value
to
at
least
listing
some
of
them,
and
maybe
we
can
call
out
the
heading
on
that
list.
Just
says
that
these
are
some
we
won't.
We
won't
make
any
claim
that
this
is
a
comprehensive
list,
but
we
could
do
a
service
to
the
community,
but
at
least
calling
out
a
few
by
category
so
that
people
know
they
exist
and.
C
I
think
we
originally
it's
called
this
paper
to
be
short
and
and
and
I
was
thinking
with
the
host
interfaces
just
to
discuss
the
importance
of
it
and
and
yeah.
Maybe
you
know,
maybe
just
just
the
basic
but
I,
don't
know
how
how
much
space
do
we
have
in
in
the
in
this
paper
to
actually
discuss
these
topics
in
the
length.
A
C
A
B
Have
we
finalized
the
list
of
principles,
I
feel
like
we
had
one
left
that
we
hadn't
quite
discussed
and
when
have
we?
When
will
we
decide
that
our
list
of
principles
is
finalized?
Part
of
the
reason
I'm
asking
that
is
Amar
and
I
are
giving
a
kubecon
North
America
talk
on
this
paper
to
kind
of
give
an
update
on
the
status
of
it,
and
one
of
the
things
we
talked
about
wanting
to
have
finalized
was
those
principles
prior
to
it.
A
B
A
B
A
B
A
Fact
that
it's
a
draft
implies
that
these
are
subject
to
change,
so
I
think
I
think
just
take
your
best
shot
at
it
and
you'll
live
with
it
and
whatever
you
choose,
I
kind
of
have
a
feeling
that,
when
you
convert
this
table
to
PowerPoints
that
maybe
just
the
act
of
having
to
present
it
and
read
it
verbally
often
for
me,
results
in
cleaning
up
the
language
and
making
it
a
little.
Tighter
and
I
won't
be
shocked.
If
that
happens
to
you
and
if
it
does
go
ahead
and
alter
it
to
match.
B
Sounds
good
and
maybe
the
week
before,
kubecon
Amar
and
I
kind
of
shared
that
powerpointed
version
of
the
principles
for
a
final
thumbs
up
or
down,
but
also
we
talked
about
wanting
to
maybe
have
this
be
on
a
GitHub.
The
draft
version.
So
that
is,
we
only
have
a
few
minutes
left
in
this
meeting
and
I
I
would
propose
that
we
do
a
one-off
next
week
and
I
think
we
need
to
kind
of
find
a
way
to
start
getting
paragraphs
down
and
and
I
think
this
is
going
to
be
a
grid.
A
Let
me
let
me
throw
this
out
there
as
a
suggestion,
but
you're
the
one
who'd
have
to
do
it,
so
it's
kind
of
like
I'm
I'm,
throwing
work
on
you.
But
if
you
wanted
to
say
the
week
before
kubecon
or
the
next
meeting
before
kubecon,
you
could
go
through
a
dry
run
of
your
presentation
because
you
probably
want
to
practice
it
anyway.
It
would
be
my
guess,
especially
whenever
you
have
a
group
presentation.
A
B
Yeah,
definitely
more
than
happy
to
do
that.
I.
Think.
The
only
thing
I
wonder
is:
if
kubecon
has
a
little
bit,
they
like
the
presentation
to
be
saved
for
them
and
like
they're,
recording
so
I
think
we
would
do
something
like
just
talk
about
the
principles
or
something
along
those
lines
but
yeah,
regardless
of
that
I'm
curious
about
what
we
want.
Do
we
want
to
have
this
published
on
our
GitHub
before
that
or
do
we
want
to
just
link
people
to
this
Google
doc.
A
Yeah,
let's
decide
that
later,
because
you
know
we
in
the
early
stages
we
talked.
We
debated
whether
we
keep
this
in
a
Google
doc
or
go
to
GitHub
from
the
from
the
beginning
and
I
think,
there's
a
little
more
friction
once
it
goes
to
GitHub
of
doing
the
changes
where
you've
got
to
do
PRS
and
things,
but
yeah
I
think
that
at
least
a
static
version
of
the
draft
on
as
a
GitHub
doc
wouldn't
be
a
bad
idea.
E
It
might
also
be
a
good
idea
to
after
the
presentation
is
done
at
keepcon.
I
would
imagine
you'd
want
to
link
your
presentation
as
well?
Yes,
so
then
you
can
just
do
it
then,
and
then
also
maybe
just
add
your
finalized
presentation
at
that
point
in
time,
especially
since
you're
you're,
so
you're
basically
saying
that,
like
kubecon
kind
of
has
a
thing
about
having
like
basically
doing
almost
a
pre-post
prior
to
the
event.
B
Yeah
that
makes
sense,
I
think
it
would
be
nice
to
be
able
to
track
how
many
people
go
to
the
paper.
So
in
that
way,
it'd
be
nice
to
have
it
posted
before,
but
I
also
wasn't
thinking
about
how
we
might
want
to
include
the
talk
in
the
paper
kind
of
for
people
who
are
more
auditory
consumers
and
we
could
always
update
it
as
well.
With
that
link.
E
B
E
The
only
reason
I
say
that
is
because
when
I
was
at
our
at
our
company
comfort
for
VMware,
we
pretty
much
posted
everything
at
the
day
that
we
did
talks
so
like
if
we
had
blog
posts,
we'd
post
it
on
the
date
of
the
blog,
the
actual
presentation
was
done.
We
also
just
did
an
open
source
project
for
one
of
the
projects
I'm
working
on
and
we
announced
it,
and
then
we
made
sure
that
the
repo
went
live
on
the
day
that
we
announced
it
kind
of
like
that.
E
B
A
Oh
I
think
we've
reached
our
time
limit
on
today's
meeting.
So
thanks
everybody
for
attending
and
I
think
Kate.
Just
we
normally
only
meet
every
two
weeks,
but
I
think
Kate
is
calling
for
a
supplemental
meeting
one
week
for
from
today
to
continue
advancing
this.
So
those
of
you
interested
and
able
to
attend
we'll
see
you
in
one
week
and
the
normally
scheduled
meeting
will
be
in
two
weeks.
So
thanks
everybody.