►
From YouTube: Kubernetes WG IoT Edge 20220824
Description
August 24, 2022 meeting of the CNCF IoT Edge Working Group. Discussion of draft of white paper on edge native principles.
A
Hi
welcome
to
the
August
24th
meeting
of
the
cncf
iot
edge
working
group
and
today's
meeting
on
the
agenda.
Currently
we
have
a
discussion
of
a
draft
of
a
white
paper
on
edge
native
applications.
I'd
anticipate
this
might
take
most
of
the
meeting,
but
we
might
have
time
for
user
nominated
additional
topics
if
you
want
to
add
those
to
the
agenda
and
notes
document
I've
put
a
link
to
that
document
in
the
chat.
A
If
you
join
blade
and
can't
see
it,
I
can
repost
it
so
I
posted
both
the
agenda,
notes,
Doc
and
a
second
link
to
the
draft
of
the
white
paper
with
that
said.
I
think
that
this
white
paper
discussion
has
been
driven
and
initially
proposed
by
some
other
people
like
Brandon,
who
I
see
here
and
Kate
has
been
very
active
on
it.
So
maybe
I'll
turn
over
the
mic
to
them
to
carry
on
with
this.
B
C
Yeah,
certainly
I'll
I'll
start
and
then
would
encourage
Amar
to
jump
in
to
fill
in
anything
else.
But
the
work
that
we're
doing
in
the
industry
around
Edge
is
embracing
a
lot
of
Cloud
native
Concepts
as
we
build
and
launch
our
our
products
and
and
solutions
and
select
open
source
components
to
to
build
those
those
with
and
through
that
process,
and
we,
we
noticed
specific
constraints
for
the
edge
around
resources,
real
estate
power
and
others
that
were
a
differentiator.
C
We,
we
felt
from
applying
the
usual
Cloud
native
principles
to
the
applications
that
we
work
with
when
designing
specifically
for
the
edge,
and
we
did
a
bit
of
a
research
looking
for
principles
driven
by
open
source
communities
that
spoke
specifically
around
Edge
native
environments
and
applications
and
weren't.
Seeing
a
whole
lot
of
information
wasn't
really
seeing
a
kind
of
a
condensed
principle
stock
that
we
felt
would
be
useful
for
developers
designing
for
these
environments.
C
So
that
was
the
Genesis
behind
the
outline
and
we've
got
a
lot
of
experience
with
Mech
applications,
and
so
we
brought
in
some
aspects
from
the
mech
world
and
the
standards
world
that
we
have
some
familiarity
with
and
wanted
to
to
tap
the
collective
knowledge
of
of
this
group.
Seeing
as
how
we're
new
members
of
cncf-
and
we
heard
about
that,
this
group
was
in
existence
through
chrisana
check.
C
So
he
introduced
us
and
wanted
to
tap
the
the
the
the
workflows
and
the
brain
power
here
to
bring
this
idea
to
the
Forefront
and
collaborate
on
an
outline
that
we
all
felt
good
about.
That
would
produce
a
new
asset
for
the
ecosystem
in
the
industry.
That
was
was
useful,
we're
not
trying
to
duplicate
or
recreate
the
wheel
or
try
to
do
too
much
in
this
first
outing.
C
But
maybe
with
that
in
mind,
we'll
we're
zeroing
in
on
a
scope
of
something
that
covers
these
Edge
native
principles
and
would
get
to
some
level
of
consensus
and
have
a
foundational
document.
You
know
from
the
auspices
of
the
cncf
that
we
can
share
broadly
with
the
industry,
starting
at
the
kubecon
event
in
Detroit,
and
then
maybe
building
upon
that
with
more
specific
use.
Cases
that
could
be
added
is
a
is
an
iterative
approach
to
developing
around
this
idea
so
that
that's
my
two
cents,
Amar
and
I
I
want
to
see.
D
Yeah
I
think
Brandon,
you
sort
of
covered
the
main
points.
I
think
the
only
point
I
would
like
to
add
is
I.
Remember
around
sort
of
2018
I
mean
right
now,
Cloud
native
is
extremely
well
understood.
Even
you
know,
cncf
has
a
definition,
but
there
was
a
point
in
time.
In
2018,
people
were
used
to
writing
applications.
The
virtual
machine-centric
way
and
I
think
the
cloud
Foundry
Community
took
initiative
in
terms
of
defining
what
cloud
native
meant
and
it
was
specifically
directed
to
developers.
What
does
it
mean
to
develop
a
cloud
native
application?
D
So
you
know
Brandon
and
I
were
talking
and
Ravi
from
Verizon
and
we
thought
hey.
Wouldn't
it
be
great
if
we
could
provide
that
same
guidance
to
developers
who
are
now
developing
Edge
Computing
applications
Mac
applications,
so
that
was
the
thought
process
and
if
we
can
get
the
the
weight
of
cncf
behind
us
and
sort
of
Define
The
Edge
native
application
pattern,
definition
I
think
it's
sort
of
a
win-win
all
around
so
that
that
was
kind
of
the
thinking.
E
Oh
sorry,
I'm
Natalie,
Fisher
I
work
at
VMware.
This
is
my
first
meeting
so
and
I
did
I
did
offer
to
review
the
paper.
I
wasn't
sure
how
far
you
guys
are
already
down
it.
So
I
didn't
want
to
be
like
I
will
take
this
section,
but
if
there
are
sections
that
are
open,
I'm
more
than
happy
to
contribute
to
them,
awesome
nice
to.
F
A
Sounds
like
sounds
like
a
good
idea
to
me,
like
maybe
don't
let
the
perfect
be
the
enemy
of
the
good
and
wait
until
we
have
the
whole
big
picture.
So
I'm
wondering
if
some
of
these
things
we
postpone,
we
can
have
a
a
category
at
the
very
end
of
the
document
where
we
move
things
that
we're
postponing
to
a
future
release
there.
So
we
don't
lose
them,
but
you
know
when
we
publish
them
we'll
cut
that
off
and
save
them
for
later,
but
yeah
I
think
that's
a
great
idea.
A
Another
thing,
Kate
I,
think
in
terms
of
process
is
I
made
some
comments
and
a
lot
of
people
commented
on
the
comment,
but
I
think
rather
than
have
those
build
up
in
perpetuity,
I
didn't
want
to
just
jump
in
there
and
just
make
my
own
edits
without
some
discussion,
but
maybe
we
can
periodically
have
a
discussion
and
close
out
these
comments
like
either.
You
know
if
somebody
suggested
something
we
accept
the
suggestion
or
we
kill
it
and
just
move
on
with
our
lives
and
rather
than
let
the
comments
continue
to
build
up.
B
A
F
A
Yeah
my
observation
I've
been
on
these
white
papers
a
few
times
and
if
you,
if
you
actually
have
to
do
PRS
to
check
in
a
markdown
on
GitHub
I,
think
it
slows
the
process
compared
to
a
Google
doc
and
the
comments
like
I
said
of
closing
out
the
comments
and
just
making
them
disappear.
There's
not
reason.
There's
not
really
a
way
to
do
that
on
GitHub,
so
I,
don't
know,
I,
I
sort
of
prefer
the
Google
Doc
myself,
but
I
could
go
either
way.
I'll
I'll
live
with
whatever
the
group
consensus
is.
A
Certainly,
as
it
gets
close
to
publication,
we
need
to
move
to
GitHub
but
early
stages,
where
it's
really
fluid
even
things.
You
know,
I,
don't
know
I
yeah
I.
My
vote
is
for
Google
Docs,
technically
I.
Guess
if
it
isn't
clear
from
audio
what
the
preference
is,
we
can
hoist
a
poll
and
make
an
have
an
official
vote.
B
Yeah
I
think
that
was
a
comment
you
brought
up
also
in
the
chat
Natalie,
so
Amar,
Ravi
and
I
are
presenting
these
at
kubecon
North
America,
and
so
we
want
to
have
the
principles
finalized
by
then
that
I
think
slides
are
due
mid-october
around
like
October
11th.
So
that's
when
we'd
want
to
have
kind
of
this
written
out.
We
ideally
would
love
to
have
the
paper
done
before
then
I
think
sometimes
it
could
be
really
helpful
to
have
a
solid
deadline
that,
like
that
to
push
so
I
would
say.
B
E
That's
good
for
me
as
long
as
you
guys
feel
comfortable,
especially
since
you're
doing
the
presentation
at
Cape,
con
I.
Imagine
being
able
to
finalize
the
draft
or
finalize
the
paper
itself
will
also
give
you
guys
a
little
bit
of
a
of
a
outliner
or
way
to
kind
of
also
link
it
to
your
presentation
as
well
for
sure
so.
C
A
I
think
it's
up
to
you,
but
I
think
it
should
be
fine
for
that
presentation
to
just
declare
that
what
you're
going
to
discuss
is
either
a
draft
or
a
release
candidate,
and
it
doesn't
have
to
be
like
an
official
release
1.0.
In
fact,
if
you
get
a
lot
of
people's
attention
drawn
to
it
from
your
presentation,
maybe
that
would
be
a
great
thing
before
declaring
it
the
official
release
of,
because
you
could
get
people
to
come
to
it
and
maybe
add
further
content
or
comments
or
whatever
or
valid,
just
simply
validate
it.
B
I
will
say,
I
think
even
if
it's
a
release,
candidate
or
draft
I
think
it
should
be
up
on
GitHub
right,
because
then
we
can
have
like
pull
requests
to.
Then
we
can
move
back
to
Google
Docs
to
iterate
and
point
people
there
to
contribute
to
the
next
iteration
or
kind
of
do.
What
Joel
was
saying
earlier
of.
Oh
here
is
our
table
of
our
principles.
B
Now,
let's
break
it
out
further
into
far
near
tiny
and
have
people
get
involved
in
the
next
wave
of
edge
application
principles,
but
yeah
that
sounds
good
to
me.
It
would
be
great
to
have
a
link
on
our
presentation
to
a
GitHub
merged
paper
and
I.
Think
that
would
also
provide
more
a
better
argument
for
maybe
making
the
definition
of
edge
native,
like
you
suggested
in
the
document.
Steve
cncf
has
a
definition
for
cloud
native
applications
and
this
paper
could
be
what
creates
The
Edge
native
application
definition.
Now.
A
The
acronym
okay
I
know
it's
Toc,
but
I
believe
for
the
cloud
native.
They
actually
voted
up
at
that
level
and
it
probably
should
be
done
again
rather
than
just
the
people
in
this
group,
but
we
can
make
a
recommendation
and
the
paper
itself
could
be
the
basis
of
that
recommendation.
You
know
somewhere
in
the
paper.
There
should
be
a
concise
definition
in
one
or
two
sentences,
just
like
they
have
it
for
cloud
native.
So
but
I
think
we
need
to
give
them
the
opportunity
to
approve
that
at
the
TOC
level.
C
That
that
sounds
good
yeah
I
was
just
going
to
ask
about
the
the
formats
and
doing
this
first
in
a
GitHub
repo
with
common
visibility
sounds
like
a
logical
step.
While
we
continue
to
build
consensus
and
get
sort
of
official
endorsement
of
these
principles
and
then
down
the
road
just
thinking
of
a
marketing
guy,
once
that's
further
established,
you
know
we
can
I
think
work
with
the
marketing
committee
to
announce
the
just
new
asset,
new
resource
available
and
put
it
into
I.
B
Awesome
I
think
we've
got
some
alignment
on
that
on
when
we
want
it
done
and
kind
of
how
we
want
a
definition
there
and
where
we
want
to
put
it,
do
you
want
to
go
ahead
and
move
to
kind
of
the
content
and
try
and
get
some
more
Foundation
there.
I
think.
The
first
thing
that
I
think
personally
would
be
good
to
discuss
is
scope.
B
So
this
goes
along
with
what
Joel
was
saying,
but
when
we're
talking
about
Edge
native
principles,
how
Edge
are
we
talking?
So
the
Linux
Foundation
put
out
a
white
paper
a
few
years
a
couple
years
ago
that
defines
the
edge
in
layers
and
they
Define
the
provider
Edge
as
being
kind
of
like
Telco
space,
and
then
the
user
Edge
having
this
range
going
from
smaller
form
servers
that
are
more
heterogeneous
to
Smart
iot
cameras
to
like
very
simple
MCU
class
sensors.
So
when
we're
talking
about
these
application
principles,
do
we
want
us.
A
D
D
B
B
So
we
have
kind
of
Provider
Edge,
which
is
more
the
network,
Telco
side
of
things,
and
then
we
get
all
the
way
down
to
constrained
Edge
where
you're
not
actually
running
the
workloads
themselves.
So
when
we're
talking
about
these
principles,
the
application
principles,
where
are
the
applications
written
to
run
and
I,
think
part
of
that
we've
discussed
the
line
that
we've
kind
of
discussed
previously
is
the
tiny
constrained.
B
Edge
is
not
a
part
of
the
principles
like
you
may
talk
about
how
your
application
May
interact
with
the
tiny
Edge
and
that
being
something
to
consider,
but
we're
not
going
to
talk
about
workloads
being
on
kind
of
this
smart
device
or
constrained
devices.
We're
mainly
focusing
on
like
the
smaller
servers
on
the
user,
Edge
and
provider.
Edge
is
what
we've
discussed
potentially
being
a
line
in
the
past.
A
Yeah
I,
don't
know,
I,
don't
see
a
reason
to
write
off
that
constrained.
Edge
I
mean
as
long
as
it's
software
that
somebody
has
issues
with
writing
and
and
maintaining
on
day.
Two
and
Beyond
I
think
that's
a
hard
problem
that
users
will
have
and
that
we
shouldn't
declare
it
somebody
else's
problem.
What
other
group
is
going
to
take
it
on?
If
we
don't,
it
could
be
that
in
the
initial
phases,
or
it
could
be,
that
we
observe
that
the
tool
set
that's
available
to
do
that.
A
Right
now
is
very
limited,
but
I
don't
see
a
reason
to
declare
it
out
of
scope.
I
mean
we'll
acknowledge
it's
its
existence
and
maybe
there's
very
little
available
to
cover
it
in
the
open
source
Arena
now,
but
I,
don't
think
we
have
to
make
a
declaration
going
out
to
perpetuity
that
it
just
gets
ignored.
D
So
I
think
the
key
is:
does
the
workload
include
management,
because
the
management
plane
I
agree
has
to
consider
the
constrained
device
Edge
as
well,
whether
it's
configuration
management
software
upgrades?
Even
if
we
consider
it
a
quote:
PNF
physical
Network
function,
there
is
a
management
overhead
but
from
let's
say,
I'm
writing
an
edge
Computing
application.
D
A
A
A
A
Don't
know
an
AWS
or
Azure
has
things
like
Network
switches
that
are
certainly
involved
with
the
problem
and,
to
some
extent
some
of
the
management
done
in
platforms
like
kubernetes
at
least
interact
with
the
things,
even
if
they
don't
do
firmware
updates
in
them,
and
it
is
possible
and
I've
seen
solutions
that
would
even
write
crds
to
attempt
to
use
the
kubernetes
control
plane
to
do
some
functions
in
them.
So
I
I
think
there
should
be
a
slot
for
them,
even
if
very
little
of
what's
currently
available
does
it.
G
In
my
mind,
constrained
devices
often
come
in
pair
with
with
the
smart
device
Edge,
so
their
their
work
side
by
side
and
and
yes,
something
that
we
are
working
on.
Is
you
how
to
provide
it
Continuum
right
so
so
I
I,
don't
think
the
principles
would
in
any
case
reflect
on
on
the
firmware
itself,
but
but
the
whole
the
whole
so
to
say,
communication
between
the
the
cloud,
some
workloads
on
the
on
the
you
know
on
the
edge
and
the
firmware,
but
certainly
can
be
discussed
right.
A
Yeah
so
I
think
that
the
solid
Point
here
I
see
that
I'd
make
based
on
the
document
that's
being
shared.
Now
is
we're
clearly
not
the
centralized
data
center.
There
might
be
gray
areas
as
to
where
the
transition
occurs
between
Cloud
native
and
it
being
Edge
at
the
regional
level,
I
mean
some
of
those
Regional
edges.
A
If
they're
they've
got
racks
of
equipment,
I
would
contend
that
those
are
more
likely
to
be
on
the
cloud
native
side,
but
you
could
have
you
know
I,
don't
think,
there's
likely
to
be
a
firm
black
and
white
line
between
where
that
boundary
is
under
all
conditions.
It
could
get
pretty
gray
in
the
middle
and
then
what's
Edge
is
everything
to
the
left
on
that
diagram,
even
getting
pretty
small,
but
as
it
gets
smaller
the
ability
of
currently
available
open
source
solutions
to
do
things,
for
you
might
become
more
limited,
but
we
won't.
D
A
Right
actually
I've
already
heard
and
seen
of
situations
where,
in
the
large
public
clouds
they
have
need
for
sensors.
You
know
like
okay,
air
conditioning
function,
monitors
and
things,
so
you
know
it
isn't
it.
It
isn't
a
clear
separation
of
these
things.
Often
the
oil
and
water
got
put
in
a
vessel
and
shaken
up
in
some
parts
of
it
are
all
over,
but
that
doesn't
mean
that
it
isn't
worthy
of
coming
up
with,
and
you
know,
best
practices
and
techniques
for
managing
the
edgy,
like
aspects
of
whatever
you've
got
going
on
so
yeah.
A
B
B
Do
we
want
to
continue
to
look
through
the
outline
to
make
sure
it's
if
we
want
to
change
anything
I
know.
One
thing
that
Steve
you
did
was
create
this
amazing
table
of
kind
of
edge
compared
to
Cloud
native
and
I.
Don't
think
we
have
that
in
the
outline,
so
it
might
be
nice
to
figure
out
where
that
should
live
within
the
outline
itself.
Yeah.
A
I
just
dropped
it
in
as
a
comment
and
I.
Even
though
I
created
it
I,
don't
think
it
belongs
where
I
put
it,
it
was
just
I.
I
saw
somebody
who
made
a
comment
that
I
thought
that
related
to
so
I
happened
to
drop
the
table
there,
but
yeah
I
think
it
maybe
is
worthy
of
its
own
section
later
in
the
document
after
we
introduced
the
subject.
A
A
Wants
to
take
lead
here
on
editing
the
document
right
now
to
get
it
over
with
you
know
your
your
idea
of
a
scope,
I
don't
know
if
there
was
even
a
section
for
that,
but
clearly
there
should
be
like
this,
whether
it's
called
scope
or
what
is
Edge.
That
should
be
at
the
beginning
of
the
document,
I
kind
of
think
that
the
table
and
just
FYI
just
this
morning
that
table
was
and
my
attempt
at
outlying
some
of
the
differences
between
Cloud
native
and
Edge
native
I'm,
not
sure
I'm,
going
to
contend
that.
A
D
So
maybe
I'm
thinking
instead
of
recap
of
cloud
native
principles,
we
replace
that
with
compare
and
contrast,
Edge
native
versus
Cloud
native
and
there
we
can
talk
about
similarities
and
differences
because
I
think
that's
more
useful
than
then.
To
recap,
I
mean
people
can
just
go
to
the
link
and
you
know
see
what
cloud
native
means,
but
this
is
this
is
a
unique
Insight
similarities
and
differences.
Yeah.
A
I
think
that
would
indeed
be
a
good
section
to
put
these
tables
and
me
personally
I,
like
tables
over
text,
because
to
say
the
same
thing
in
paragraphs
of
text.
We
would
make
this
such
a
long
document.
Nobody
really
reads
it
and
when
you
put
it
in
table,
forms
like
that,
I
think
I
personally
tend
to
read
those.
If
I
have
limited
time,
which
I
always
do
and
then
I've
also
found
in
other
papers,
they
often
end
up
being
reused.
A
B
My
only
wondering
is
I
feel
like
the
re.
The
compare
and
contrast
of
cloud
native
versus
Edge
native
may
be
a
little
redundant
compared
to
Edge
constraints,
so
with
Edge
constraints
that
section
we're
going
to
have
talked
about
a
lot
of.
What's
in
that
table,
I
wonder
if
we
move
the
table
up,
like
so
scope
with
a
paper
as
in.
B
What's
our
goal
of
this
paper,
what
is
the
edge
I
wonder
if
and
then
we
say
this
is
the
definition
of
the
cloud
notice
that
it
doesn't
mention
the
edge,
which
is
something
Joel.
You
pointed
out
in
the
cncf
cloud
definition
is
that
it
doesn't
mention
Edge
environments,
it
mentions
cloud
and
hybrid
environments,
it
doesn't
mention
Edge
and
then
go
into
this
table
like
okay.
So
this
is
the
cloud
this
is
The
Edge
and
then
add
go
to
the
edge
constraint
section
where
we
kind
of
dig
into
it
a
little
deeper.
A
D
And
we
could
even
mix
mix
the
two.
So
where
we
discuss
differences,
we
can
highlight
the
edge
constraints.
So
we
can,
if
there's
a
difference
in
terms
of
let's
say,
availability,
we
can
say
the
availability
in
the
edges
different
from
the
cloud.
For
this
reason
right.
It's
a
constrained
environment,
often
single
node.
D
C
F
Don't
know
that
I
digested
all
the
words
okay,
but
when
you
had
said
moving
that
up
made
sense
right,
I
being
newer
to
this
conversation,
it
doesn't
appear
to
me.
Is
that
there's
too
much
of
a
difference
between
Cloud
native
and
Edge
native,
it
seems
like
it's
an
extension
into
an
edge
environment
and
I
have
to
go
back
and
reread
the
cloud
native
definition
which,
by
the
way,
is
2018
and
so
four
years
that
could
be
due
for
a
suggested
update,
but
everything
every
everyone
was
just
saying
about
the
differences.
F
A
Another
I
I
like
you've,
moved
it
up
so
yeah.
Let's
try
to
do
as
much
work
as
we
can
in
in
this
meeting
of
actually
making
that,
in
addition
to
talking
about
it,
but
I
think
another
key
thing
for
for
getting
to
the
differences.
Some
at
least
the
summary
early
is
that
you
need
to
have
convinced
the
reader
that
there's
a
reason
to
even
read
this
white
paper
in
for
it
to
exist
yeah.
A
The
fact
is,
if
they
were
absolutely
identical
reading
this
paper
is
a
waste
of
time
because
they
presumably
Cloud
native,
has
been
out
there
for
years.
People
think
they
already
know
it.
So
really.
The
Crux
of
this
paper's
need
for
existence
is
those
differences,
so
yeah
getting
into
that
early
in
the
dock
is
probably
a
good
thing.
G
Is
not
only
about
the
the
applications
right?
It's
it's
more
that
we
should
explain.
You
know
what
are
the
physical
boundaries
and-
and
you
know
why
we
have
these
these
constraints
and
then,
in
the
later
section
we
defined
what's
actually
an
energy
native
application,
and
maybe
that's
where
we
we
can.
We
can
Define
after
we
Define
it.
You
can
say:
okay,
these
are
the
differences
right,
because
before
that
section
we
don't
actually
discuss
the
application
we
just
discuss.
D
A
I
think
maybe
we
should
roll
it
out
in
layers,
because
when
you,
the
fact
is
when
we
say
what
is
the
edge,
you
know
the
one
we're
choosing
to
use,
assuming
we
go
with
something
based
on
that
diagram
that
was
put
up
is
largely
geocentric.
You
know,
we've
declared
Edge
is
based
on
physical
location.
People
have
had
other
attempts
at
defining
Edge
based
on
you
know
the
amount
of
resource,
the
so-called
thin
versus
thick,
and
all
of
these
are
sort
of
valid.
A
Another
one
is
based
on
network
connectivity,
but
you
got
to
go
with
something
and
you
can't
be
non-committal,
so
I'm
fine
with
going
with
Geo,
because
the
fact
is,
the
Geo
thing
is
really
what
Cascades
down
to
cause
other
effects
like
lousy
network
service,
if
you're
way
out
there
at
a
remote
location
or
poor
physical
security.
Just
because
there's
not
many
human
beings
out
there,
particularly
those
that
you
are
well
trained
in,
are
have
are
trusted
by
an
organization.
So
starting
with
Geo
is
fine,
but
I
think
the
edge
constraints
section
needs
to
who
actually?
A
Maybe
it
should
even
open
with
a
reasoning
why
this
isn't
all
about
Geo,
but
but
many
of
the
aspects
of
geographic
location
cause
other
things
to
happen.
That
are
very
big
considerations.
When
you
do
this
and
then
we
outline
outline
the
edge
constraints
so
that
kind
of
flow
with
that
coming
after
what
is
Edge
I
think
is
okay,
but
we
do
need
to
get
to
it
before
really
the
whole
point,
as
a
close
is
best
practices
of
okay.
A
We've
outlined
all
your
challenges
and
things
and
all
the
all
the
tough
things
you're
taking
on
here
are
some
of
the
things
that
can
help.
You
get
your
job
done.
If
you
find
that
you're
trying
to
deploy
apps
and
services
in
these
Edge
environments
and
that
kind
of
thing
should
be
at
the
back
end
of
the
document,
I'd
say.
D
A
Yeah
I,
don't
know
the
edge
constraints
is
a
pretty
big
list,
so
maybe
that's
kind
of
does
mirror
in
its
own
section,
rather
than
trying
to
blend
it
into
the
other.
The
definition
of
what
I
think
is:
okay
on
its
own
I.
Don't
think
you
want
sections
that
go
beyond
a
few
paragraphs.
If
they,
you
know
it
takes
a
two
two
pages
to
put
all
the
content
there.
The
section
was
too
big
yeah.
B
I
think
we
can
reference
The,
Edge
constraints
section
in
the.
What
is
the
edge
section
say
that
there
are
these
constraints
that
are
specific
to
where
these
applications
run
and
reference
The
Edge
constraints,
but
have
that
be
elsewhere?
So
maybe
you
mention
a
couple
and
say
how
we're
going
to
talk
further
about
that,
but
that
still
brings
up
the
point
of
do.
We
need
to
move
Edge
constraints
up
before
this.
Compare
and
contrasts.
A
A
Now
we
could
still
expand
on
it
later,
because
the
table
really
is
just
bullets
and
it
doesn't.
It
doesn't
say
as
much
as
needs
to
be
said,
I
think,
but
we
could
maybe
cover
Edge
constraints
to
some
degree
in
that
table
of
differences
between
Edge
and
cloud
and
traditional
Cloud
native,
and
then
keep
it
in
its
own
section
again
later
that
deals
with
it
in
a
text
form.
D
So
I'm
I'm
thinking
of
the
common
Joel
made
early
on
this,
could
be
iterative.
I
do
feel
we
don't
want
to
make
the
white
paper
too
long.
So
maybe
maybe
a
table
tabular
list
with
you
know
a
bullet
explaining
each
constraint
is
good
enough.
We
could
follow
it
up
with
a
Blog.
That
then
goes
into
a
lot
more
depth
for
each
constraint,
or
we
could
do
another
piece
later
on
I'm
just
worried
that
if
you
go
beyond
five
or
six
pages
the
number
of
people
reading
it
will
drop
off.
G
B
I
think
Yeah
It's
tricky
because
we
haven't
discussed
what
an
edge
native
application
is
among
ourselves
either
like
is
that
a
geocentric
definition,
or
is
that
something
that
has
the
principles
we're
about
to
discuss
so
I
think
it
makes
sense
to
have
the
definition
of
edge
native
application
right
before
we
list
our
principles?
Yes,.
B
B
A
I
think
it's
because
there
are
like
three
different
Fair
ways
to
characterize
Edge.
You
know
based
on
where
geo-based
resource
based
or
network
connectivity
based
I've
heard
them
come
up.
You
go
to
a
network
conference
and
because
of
the
nature
of
the
conference,
they're
of
course,
going
to
choose
to
Define
it
based.
A
E
A
And
I
think
it.
No
one
would
discover
this
or
start
reading
it
if
they
didn't
think
they
were
interested
in
Edge
and
have
some
Edge
problems,
but
the
there's
Edge,
which
has
existed
really
for
my
whole
lifetime
right
I
mean
even
before
they
have
the
term
Cloud
native
there's
always
been
Edge,
but
Edge
and
Edge
native
are
two
different
things.
A
An
edge
native
is
maybe
a
cool
way
to
apply
technology
that
didn't
exist
10
years
ago
to
solve
some
of
these
problems,
and
you
know
really
The
Edge
native
aspect
is
the
Crux
of
why
this
paper
exists,
not
the
edge
definition
right
to
get
to
the
meat
of
what
will
be
in
here
and
of
value.
We
have
to
lay
a
foundation
of
you
know
what
our
definitions
are
and
things.
G
I
think
we
agreed
on
on
the
previous
meetings
that
we
have.
We
need
something
just
a
brief
brief
thing
to
to
give
people
a
context
of
what
we're
talking
about,
but
but
definitely
the
paper
shouldn't
be
about
definitions
of
the
edge.
So
in
that
sense,
maybe
we
can
merge
what
is
Agent.
Why
do
we
need?
Why
do
we
need
the
edge
into
a
one?
That's
yeah.
E
It
is
which
is
fine
right,
if
that's
the
case,
but
if
the
goal
here
from
what
Amara
was
saying
is
that
we
want
to
kind
of
keep
it
fairly
tight
and
short
and
I
don't
mean
necessarily
short
like
two
pages
but
like
shorter
than
30
pages,
then
it's
good
to
just
be
super
focused
on
what
we're
gonna
end
up
talking
about,
but
I
don't
disagree
with
explaining
what
the
edge
is.
The
question
is:
how
long
is
that
going
to
be.
B
B
Geo-Based
is
something
we
might
reference
more
given
that
the
LF
Foundation
has
that
definition
in
their
white
paper
kind
of
reference
that
and
say
they
Define
it
based
on
locations
which
is
usually
correlated
with
resources
and
network,
and
then
then
briefly
say
we
find
applications
spanning
in
these
areas
because
of
X,
Y
and
Z
reason.
That's
kind
of
answering
the
why
we
need
the
edge
and
then
just
kind
of
move
on
like
keep
it
fairly
short.
A
E
Yeah
because
then
at
least,
then,
the
majority
of
the
paper
can
focus
on
the
actual
topic
of
educative
applications
right,
I.
Think
it's
great
to
like
I
said
talk
about
like
what
is
Edge
and
kind
of
pinpoint
like
this
is
sort
of
the
direction
that
we're
trying
to
or
the
general
definition,
as
you
said
that
we
want
to
take.
But
you
also
don't
want
to
spend
like
two
or
three
pages
explaining
what
Edge
is
and
then
going
and
now
on
to
our
actual
topic
after
you've
read
two
pages
and
you're
like
oh,
my
God.
D
D
F
D
D
D
F
B
A
B
Okay,
great
so
then
we
have
I
think
we
can
remove
recap
of
cloud
native,
maybe
actually
never
mind
so
okay.
So
it
sounds
like
we're
going
to
spend
the
rest
of
this
meeting
kind
of
talking
about
outline
and
we
might
need
to
schedule
a
one-off
for
next
week,
potentially
to
actually
discuss
the
principles,
if
that
seems
reasonable.
D
A
B
A
A
B
A
B
B
A
B
G
A
B
Applications,
one
yeah,
yeah
I,
think
Edge
Nave
applications
could
be
as
simple
as
a
section
that
says.
Educative
applications
are
applications
that
are
interested
in
following
the
following
principles:
I,
don't
know
it
could
be
very
like
are
are
interested
in
thriving
in
the
edge
native
environment
and
we
describe
an
application
that
can
succeed
in
those
environments
as
one
that
follows
these
principles,
and
it
could
be
like
overtly
short
of
a
section
well.
A
Essentially,
I
think
isn't
this
more
like
a
scope
Declaration
of
what
it
is
and
in
terms
of
scope,
it's
pretty
open-ended
as
I
see
it.
You
know,
in
other
words,
could
be
any
language
any
framework
that
would
fit
it
or
be
appropriated
Edge,
where
it's
more
like
we're,
not
we're
not
eliminating
things.
We're
prepared
to
take
on
sort
of
almost
anything,
the
one
things
that
maybe
don't
make
sense.
Are
these
what
I
call
some
of
these
big
cluster
aware
applications?
A
G
A
A
A
Of
scope
so
and
I'm
I'm
not
disagreeing
with
this,
but
if
we're
inclusive
of
this,
if
application
could
be
an
end
to
your
application,
where
some
aspects
of
the
app
are
way
at
the
leaf,
Edge,
node
and
others
are
at
a
higher
tier
in
something
more
like
a
cloud.
That's
a
it's
a
valid
definition,
but
we
should
make
it
clear
that
that's
what
we're
declaring
to
be
an
application
that
it's
it's
anterior
to
the
point
where
some
of
the
tears
are
at
different
physical
locations
than
others.
D
I
I,
like
that
definition
and
the
reason
I
like
it
is,
we
could
take
an
inside
out
view
or
an
outside
in
view.
The
Inside
Out
view
would
be
an
edge
Computing
application
as
an
application
that
follows
these
principles
and
outside
in
view,
is
if
I'm,
a
developer
and
I
have
a
computer
vision
application.
Currently
it's
it's
sitting
in
the
cloud
it's
suffering
from
latency.
D
It
has
all
these
issues
that
that
I'm
not
able
to
really
I'm
really
not
able
to
optimize
it
and
now
I,
read
this
paper
and
see
that,
oh,
if
I
were
to
following
this
Geo
definition,
if
I
were
to
Able,
if
I
were
to
move
this
application
in
a
geographic
manner
that
spans
all
the
way
from
the
leaf
to
the
cloud,
I
I
think
they
on
you
said
it
better.
We
should
capture
it
I,
so
I
think
that's
a
more
outside,
in
definition.
So
that's
why
I
like
it
more
yeah.
A
I
think
you've
convinced
me
too,
and
you
know
going
too
small
declaring
it's
only
what's
on
edge,
really,
that's
not
an
application,
that's
where
we'd
be
declaring
microservice
components
and
that's
not
what
this
is
about.
This
is
about
whole
applications
with
multiple
parts
and
interconnects,
and
that's
where
the
thing
gets
interesting,
so
yeah,
yeah
I'm
in
favor
of
that,
but
I
think
in
this
agitative
applications.
A
We
need
a
very
brief
definition
that
this
is
what
we're
taking
on
we're
taking
on
the
end
here
with
multiple
locations,
along
with
attempting
to
address
interconnects
latency
issues,
and
you
know
the
whole
thing
yeah
and
then
maybe
once
we
lay
that
out
that
this
is
the
scope
of
what
we're
taking
on.
Then
we
can
move
on
to
the
principles
yeah.
B
So
we're
defining
an
application
as
the
entire
system
that
lives
across
all
n
tiers.
But
what
does
that
mean
for
a
principle
based
on
portability?
Are
we
talking
about?
Each
portion
of
the
application
is
portable,
or
are
we
so
and
is?
Maybe
portability
is
actually
not
so
the
principle
of
limited
portability
is
actually
one
that
we
were
discussing
of
how
and
when
we
make
that
discussion.
Is
it
that
each
part
of
the
application
is
tied
to
its
to
its
tier
in
a
way?
Is
that
what
we're
saying
well.
A
A
With
regard
to
geolocation,
however,
if
you
have
a
scale
situation,
what
portability
means
out
at
that
leaf,
node
device
Edge
is
I,
write
the
app
once
you
know
the
thing
that
collects
a
video
stream
I
write
it
once,
but
it
can
run
at
different
locations,
so
it's
portable.
In
that
sense,
you
know
re
portable,
meaning,
reusable,
and
maybe
the
different
locations
have
slightly
different
cameras,
slightly
different
compute.
Maybe
a
lot
different
compute.
You
know
ones
on
arm
one's
on
x86,
but
it
it.
A
D
D
So
therefore
you
need
to
be
portable
and
I
say
it
because
I
believe
it,
but
I
think
this
is
where
we
could
push
cncf
and
cncf's
sort
of
agenda
that
cncf.
If
you
follow,
if
you
live
within
the
cncf
set
of
projects,
then
automatically
you're
guaranteed
portability,
because
cncf
projects
are
not
specific
to
a
particular
Cloud
vendor
they're,
not
specific
to
any
one.
You
know
technology
vendor,
they're,
they're
sort
of
across
so
at,
at
least
in
my
mind.
That's
what
portability
means.
D
A
G
G
It
needs
to
to
be
on
the
leaf
nodes
and
things
like
that,
but
but
some
of
the
workloads
that
are
processing
data,
maybe
there
we
can
Define
that
those
those
services
are
relatively
portable
between
the
tiers
right
so
so,
depending
on
on
the
capacity
and
and
and
everything
they
can
be
on
the
on
the
near
Edge
or
living
in
in
the
cloud
or
or
being
on
on
the
on
the
leaf
nodes.
If,
if
they're
capable
enough
but
but
they're,
just
a
subset
of
the
terrific
are
are
portable
so
to
see.
B
So
I
think
we
did.
We
have
found
ourselves
tied
to
one
principle
kind
of
confused
by
and
that's
portability
so
I
think.
Maybe
we
can
all
like
think
a
little
bit
more
about
it
and
kind
of
highlight
that
Principle
as
being
one
that
we're
having
a
little
haziness
around
regardless
do
people
feel
I
started
moving
this
bullet
list
into
a
table
format
to
kind
of
keep
the
table
Vibe
going.
Are
people
good
with
that?
A
B
D
A
Yeah
so
let's
move
it's
a
great
discussion
and
before
the
next
meeting
they're,
certainly
let's
work
asynchronously
and
anybody
who
devotes
some
thought
time
to
this
subject
and
comes
up
with
ideas,
throw
them
down
in
the
document
as
comments
or
text
and
we'll
pick
it
up
at
the
at
the
next
meeting.
How
does
that
sound.
A
What
time
do
you
want
this
same
time
next
week
or
some
alternative
I'll
leave
it
up
to
you
just
call
the
meeting
in
the
slack
or
whatever,
because
I
think
it's
the
people
who
are
facing
the
kubecon
presentation
that
are
under
the
most
pressure
and
they'd
be
the
key
attendees
so
yeah.
Why
don't
you
propose
something
for
next
week
and
we'll
try
to
make
it.