►
From YouTube: Kubernetes WG IoT Edge 20220629
Description
June 29, 2022 meeting of the Kubernetes IoT Edge Working Group. Discuss internal group organization, group transition to CNCF, edge native whitepaper, new meeting cadence and schedule.
B
Least,
a
draft
you
know
yeah
yeah,
yeah,
I
I-
think
the
trouble
is,
if
you
rush
it,
it's
going
to
end
up
being
this
unilateral
thing
where
the
organizers
will
have
written
everything
and
I
think
that
what
happened
last
time
is
people
slowly
got
awareness
of
it
and
then
tagged
it.
You
know
they
joined
in
and
they
had
valuable
contributions,
but
that's
sort
of
the
way
you
get
a
best
outcome
to
not
I
I
think
we
have
to
Target
it
for
a
quality
level
rather
than
a
due
date.
C
D
B
So
you
know
what
happened
last
time
in
it
in
something
as
broad
as
calling
it
Edge
native.
What
you're
going
to
find
I'm
going
to
predict
is
people
will
hear
this
is
going
on
and
they'll
have
little
niches
they
want
to
get
in
this
paper.
So
you
know,
unless
you
can
keep
the
title
itself
very
narrow.
B
A
D
B
D
E
You
could
elaborate
here
today,
yeah,
it's
it's
it's
nice
to
meet!
You
we're
we're
new
members
of
cncf,
but
have
been
fellow
Travelers
for
a
long
time,
just
officially
joined
and
we're
looking
to
get
plugged
into
all
the
different
working
groups
that
make
sense
for
for
what
we
do
and
then
Chris
made
the
intro
and
quickly
put
the
meeting
on
the
calendar.
Glad
I
was
able
to
to
hop
on
over
here
and
start
this
initial
discussion.
Okay,.
B
E
E
Those
projects
all
came
together
into
the
LF
networking
umbrella
and
that
I
was
heading
up
marketing
for
the
umbrella
for
several
years,
so
pretty
familiar
with
cncf
have
participated
in
kubecons
and
have
given
demos
at
coupons
and
glad
to
now
be
in
a
position
with
this
new
role.
Looking
for
Arna
in
the
startup
to.
E
Sorry,
it's
about
three
four
years
old
and
originally
started
off,
offering
Consulting
service
services
for
the
onap
project
in
particular.
But
since
that
time
it's
we
we've
grown
Leaps
and
Bounds
and
we're
now
migrating
into
a
product
offering
of
Edge
and
5G
orchestration
life
cycle
management
and
closed
loop
automation.
E
B
B
What
wasn't
it
eventually
settled
into
a
definition
that
cloud
native
essentially
means
that
an
app
can
portably
run?
Oh
well,
let's
say
a
well-written
app
can
run
portably
in
the
sense
that,
if
it,
if
it
is
well
implemented,
it
shouldn't
be
able
to
run,
tell
where
it's
running
yet
run
everywhere.
The
same
way.
B
So
to
me,
if
I
had
the
guess
what
Edge
native
means,
my
guess
would
be
that
it's
along
the
same
lines
of
cloud
native,
that
we
have
some
sort
of
abstraction
fixture
in
place,
so
that
it
is
possible
to
provision
things
at
Edge.
And
perhaps
you
know,
cloudnative
originally
talked
about
apps
being
portable,
but
my
observation
is
that,
as
this
grows,
there's
more
to
this
than
just
the
applications
themselves,
there's
a
lot
of
collateral
things
and,
to
the
extent
we
can
make
that
portable
as
well.
B
That
would
be
fantastic
if
you
might
not
be
able
to
provide
such
guarantees,
but
if
we
could
it'd
be
great
and
if
that
is
our
definition
of
what
educative
means
I'm
in
favor
of
it,
but
I
think
that
one
of
the
first
things
this
paper
has
to
open
with
is
really
what
do
we
mean
by
Edge
native,
because
as
far
as
I
know
there
isn't?
You
know
there
isn't
a
well-known
definition
of
what
that
would
mean,
but
that
doesn't
mean
it
should
stop
us.
B
E
Well,
first
of
all,
I
think
your
approach
is
what
you
just
said
was
exactly
what
we
were
thinking.
There
is
a
lack
of
universal
definition
on
what
Edge
native
is
and
when
I
do
a
little
research
around
I
I
can't
find
anything
you
know,
there's
there's
mentions
of
it,
but
there's
no
consistent
usage
and
there's
no
kind
of
foundational
element
like
was
so
important,
with
cncf
to
start
off
with
what
is
cloud
native
to
develop
that
definition
and
then
the
industry
adopted
around
it.
E
This
topic
allow
for
comments,
feedback
and
participation,
but
be
The
Guiding
Light
to
Define
what
this
means
and
in
terms
of
how
we
Define
at
the
edge
I
think
it's
just
important
to
note
that
there
are
constrained
resources
that
developers
have
to
work
with,
and
they
might
not
be
immediately
familiar
with
with
how
to
do
that
in
a
cloud-native
way
seems
like
Edge
native
is
cloud
native,
but
with
extra
elements,
it's
like
a
yeah.
What.
B
I
I
don't
want
to
push
my
own
agenda
on
this,
but
be
open-minded,
but
what
do
the
rest
of
you
think
about
opening
it
up?
Beyond
applications,
because
it
strikes
me
that
some
things
like
device
management
really
are
not
applications
but
they're,
just
absolutely
essential,
and
the
original
cloud
native
definition
really
went.
The
direction
of
application,
support
being
portable
and
kind
of
you
know.
We
can
learn
from
what
has
gone
before
us
and
I
kind
of
am
leaning
towards
the
idea
that
we
don't
declare
this
to
be
application-centric.
A
Broader
infrastructure,
right
yeah,
because
that's
most
most
of
the
cloud,
the
cnci
projects
are
the
infrastructure
to
run
Cloud
native
applications
right,
but
but
I
think
I
mean
this.
Original
kubernetes
working
group
started
with
a
white
paper
that
was
never
never
finished
and
that
we
use
as
a
like
a
that's
where
we
we
never
discussed
like
what
edges
and
and
that
white
paper
were
used
by
different
people
to
put
their
ideas.
You
know
well.
A
D
Think
those
are
two
good
separate
white
papers
like
I,
think
keeping
the
scope
small
could
be
helpful.
Like
I,
like
the
line
Brandon
that
you
have
it's.
The
last
line
of
the
first
paragraph
I,
think
where
you
mentioned,
that
edge
native
is
a
superset
of
cloud
native
application,
principles
and
I.
Think
that's
helpful
to
say
like
this
is
what
you
need
to
add
to
the
Computing
Paradigm.
D
You
already
have
to
make
it
better
for
the
edge
like
enable
air-gapped
environments,
I
would
assume
would
be
on
there
disconnectedness
kind
of
storage
solutions
that
are
maybe
less
replicated,
because
you
have
more
constrained
resources.
Things
like
that
that
do
and
involve
infrastructure
but
they're,
focusing
on
the
application.
So
it's
even
though
the
infrastructure
needs
to
handle,
even
though
infrastructure
concerns
of
edge
native
may
be
less
resources,
maybe
less
storage.
B
I
actually
love
that
idea
of
maybe
proposing
that
this
is
all
about
what's
different,
so
we
don't
have
to
duplicate
things
that
really
are
the
same
with
Cloud
native,
and
that
might
be
a
good
folk.
A
more
focused
structure
for
that
proposed
kubecon,
talk
of
maybe
the
title
of
the
talk
is
what's
different
about
running
at
Edge.
You
know,
because
that
that
that
really
is
the
Crux
of
the
matter.
B
C
C
E
E
E
We
want
to
be
as
agnostic
as
possible
in
order
to
keep
that
initial
scope
very
small
and
to
also
be
completely
neutral.
Some
of
the
authors
we've
been
potential
authors
we've
been
talking
to,
or
fellow
Travelers
we've
been
working
with
for
a
while,
including
my
boss,
Amar
at
RNA
networks.
We
work
closely
with
Verizon
and
there's
an
Network
operator
representative,
ready
to
contribute.
I
think
that's
gives
weight
to
the
paper
and
also
surimi
adipale
was
long-time
Intel
contributor.
He
recently
left
to
join
aryaka
as
CTO.
E
This
happened
like
just
a
week
ago,
but
he
really
helped
Pioneer
a
lot
of
things
in
the
LF
networking
space
around
first
onap
and
then
increasingly
Emco
cluster
management,
orchestration
project.
So
those
are
the
folks
we
have
lined
up
now
ready
to
contribute
and
then,
of
course,
through
this
group
we
would
look
to
facilitate
other
authors
and
other
reviewers
as
well
for
distribution.
B
E
A
A
That's
the
whole
topic
to
discuss
how
to
to
cover
all
possible
use
cases,
telcos
and
and
the
industry
and
Retail,
and
things
like
that
with
different.
As
you
said,
different
superset
of
of
cloud
computing,
Cloud
native
applications
that
run
to
DH
so
for
for
telcos
networking
is
the
key
for
for
industry.
It
may
be
accessing
the
the
local
networks
and
and
devices
around
right.
E
Yeah
and
that's
that's
a
good
point
and
then
it
takes
us
back
to
our
how
deep
how
we
go
and
I
think
we
start
off
with
something
that's
relevant
to
all
those
use
cases,
and
then
we
as
we
go
down,
we
get
more
specific
as
needed,
but
if
we,
if
we
try
to
start,
you
know
comparing
a
Telco
use
case
to
a
a
retail
or
Smart
City
or
something
like
that
it
can.
It
can
quickly
spin
out
from
Beyond.
Maybe
what
we're
trying
to
do
here
initially.
B
Now
the
trouble
with
that
is
this
could
be
if
you
envision
this
being
a
couple
Pages
the
more
we
do
that
and
Branch
off
into
other
use
cases.
The
bigger
this
has
to
come
to
yeah
to
come
to
cover
it.
Exactly
that
doesn't
mean
we
couldn't
do
several
white
papers,
I
mean.
Maybe
we
do
the
broad
umbrella
one,
and
then
we
take
on
a
mission
to
have
individual
use
case
specific
white
papers
to
follow
I.
Don't
you
know
in
with
the
goal
of
getting
something
done
earlier,
though?
E
B
B
No,
that's
it
other
than
the
form.
If
you
own
this
document
now,
I
think
there
is
a
way
for
this
group
to
create
a
document
and
the
what
we've
done
before
is
we
share
it
with
the
whole
membership
list.
At
least
opening
up.
We've
never
had
a
problem.
Some
some
other
groups
in
kubernetes
did
where
you'd
get
trolls
who
go
in
trash
a
document,
but
in
theory
Google
Docs
lets.
You
revert
those
changes,
but
I
think
that
we
should
just
leave
it
open
for
at
a
minimum
comments.
B
E
That
sounds
good
and
maybe
based
on
what
we
talked
about
here
today.
We
could
introduce
your
suggestions
on
format
and
also
try
to
simplify
and
reduce
the
scope.
A
bit
maybe
reduce
the
amount
of
variables
that
people
would
have
a
ton
of
questions
or
opinions
about
as
well.
I
mean
I'm
all
for
transparency
and
I've
worked
in
open
source
communities
for
a
long
time,
and
I
also
know
that
you
know
you
have
to
be
prepared
to
handle
a
lot
of
different
side
conversations
and
yeah
ideas
that
come
up
around
something
like
this.
B
I,
don't
know
gaming,
for
example,
or
machine
learning
that
if
you
know,
we
need
to
allow
those
those
contributions,
but
if
we
do
it
in
one
open-ended
document,
we'll
never
finish
the
thing
and
it'll
get
bogged
down
so
that
if
we
just
simply
say
that
we're
going
to
link
to
these
specialized
things,
then
they
can
work
in
parallel
and
independently,
with
their
own
life
cycles
and
I.
Think
in
the
big
picture
of
things,
looking
I
had
two
or
three
moves
on
the
chess
board.
B
D
It'd
be
interesting
to
look
at
some
of
the
the
principles
down
at
the
bottom
I'm
curious
to
kind
of
talk
through
just
a
couple
of
those
to
see
what
that
discussion
would
look
like
in
a
larger
form
on
a
document,
so,
for
example,
principles
on
logging
is
part
of
the
edge
specific
concern
here
that
we
can't
immediately
send
logs
to
centralized
location
in
the
cloud.
Rather,
we
need
a
way
to
kind
of
tag
and
only
send
what's
necessary
and
aggregate
locally
upon
acquisition
of
the
logs.
B
Frankly,
even
in
regular
data
centers,
this
is
often
done
just
because
the
storage
cost
of
keeping
logs
can
be
pretty
enormous.
I
mean
that's
why
a
lot
of
vendors
of
these
logging,
Monitoring
Solutions,
sell
them
as
managed
offerings
so
that
they
take
on
the
the
nut
of
maintaining
all
of
that
storage.
So
I
think
this
is
likely
to
come
into
play
at
Edge,
maybe
even
more
so
that
the
the
logging
is
going
to
be
keep
recent
stuff
and
small
amounts
local,
but
plan
on
migrating
and
up
opportunistically
as
you
can,
but
I
don't
know.
B
This
is.
This
is
something
we
need
to
fill
out
in
the
white
paper,
but
a
perfectly
valid
topic.
Logging
metrics
observability
are
big
things,
I
think
Dion,
that
red
hat
originated
project
you
talked
about
in
the
slack
I
think
says
that
I
I
read
the
header
on
that
and
I
believe
that
it
is
aspiring
to
take
fill
a
role
in
some
of
those
too.
But
it
is
an
important
role.
B
E
D
E
E
D
Yeah
I
definitely
think
so.
I
think
people
are
more
and
more
having
to
build
their
applications
to
be
portable
from
the
cloud
to
the
edge
and
what
portability
means
there
is
quite
confusing
if
they're,
not
if
they
know
their
platform,
supports
that
affordability
still
as
an
application
developer.
What
do
you
need
to
keep
in
mind
if
there's
also
building
that
platform?
What
does
that
platform
need
to
keep
in
mind?
I
think
those
are
two
very
important
things
that
would
be
nice
to
have
a
paper
kind
of
outlining
those
principles.
D
I
think
Steve
made
a
good
point
at
the
beginning
of
like
infrastructure
versus
application.
Daehan,
you
kind
of
double
backed
on
that
too
of
like
are
we
drawing
a
line
in
here
and
I?
Think
that's
something
that
should
be
pointed
out
in
the
beginning
of
the
paper
of
Are
We,
considering
the
infrastructure,
or
are
we
just
talking
about
application,
best
practices
and
our?
What
are
our
assumptions
about
the
infrastructure?
If
we're
not
considering,
it
would
be
some
of
my
concern
on
scope.
C
D
Yeah
I'm,
just
wondering
like,
for
example,
caching
messaging,
is
that
the
application's
responsibility
or
is
that
the
infrastructure's
responsibility
so
think
like,
for
example,
key
veg
kind
of
modifying
kubernetes
for
Edge
scenarios,
where
it
has
its
own
like
Edge
core,
which
is
it's
like
AP.
It's
like
API
server
on
the
edge
for
caching
communication
to
the
API
server
on
the
cloud.
Is
that
an
application
responsibility
to
come
up
with
something
like
that?
Or
is
that
infrastructure
responsibility
and
let
the
application
just
continue
as
it
is.
A
Yeah
well,
I
think
it
can
be
both
right.
So
if
you
use
something
like
Cuba
cubers
infrastructure
for
me
right
so
and
it's
built
like
that,
you
don't
have
to
think
about
it.
But
if
you
want
to
to
write
what
you're
saying
here,
like
you
know,
agnostic
payloads,
that
that
can
run
in
qubit
or
or
vanilla,
kubernetes
or
k3s
or
or
whatever,
then
you
need
to
take
a
look
at
think
about
these
issues
on
your
own
as
an
application
developer
right.
C
D
And
I
think
laying
that
out
would
be
helpful
being
like
we're,
assuming
that
the
application
takes
on
all
these
responsibilities.
That
might
likely
not
be
the
case.
There
might
be
infrastructure
that
comes
in
to
make
this
not
a
requirement
but
to
let
Edge
native
application
act
as
a
cloud
native
one,
but
assuming
that
that
infrastructure
isn't
doing
the
work
for
you.
These
are
what
your
obligation
needs
to
keep
in
mind.
Yeah
yeah,.
A
It
means
like
I,
see
that
targeted
our
audience
here.
Are
you
know
developers,
but
also
the
Architects,
like
you
know,
put
these
problems
in
people's
minds
that
they
need
to
think
about
these
things
if
they're
building
h
native
applications
right
so
that
their
their
infrastructure
candles
that
internet
with
networking
for
them
or
not?
If
not,
then
these
are
the
things
we
think
they
should
think
about
it
and
maybe
propose
some
some
of
the
to
look
at
some
of
the
projects
that
that
are
dealing
with
that
problem.
Right.
D
Steve
is
heavily
involved
in
that,
like
runs,
it
opens,
it
closes
it
like.
Does
the
keynote
in
the
final
and
does
a
lot
of
the
selection
of
talks
for
it
so
he's
very
plugged
into
it,
and
we've
talked
about
this
working
group,
potentially
taking
ownership
of
it
and
kind
of
helping
drive
that
since
Steve's
so
plugged
into
it.
A
E
A
E
D
A
Yeah
I
mean
we
can
do
different
kind
of
things,
I
think
I
mean
we
never
had
like
a
preservo,
feather
sessions
or
or
or
or
some
you
know
these
kind
of
things
that
at
the
edge
day,
but
you
know
we
can
ask
for
it.
Definitely
so
so,
and
we
just
got
an
email
I
think
today
that
they
started
planning
planning
it
for
the
for
the
cubecon
North
America.
So
you
know,
let's,
let's
think
about
it
from
the
from
the
day
one.
How
are
we
gonna?
You
know
present
the
group
and
present.
A
E
Yeah
yeah
definitely
I
assumed
it
was
a
lot
of
the
same
players
as
were
in
this
group
and
on
this
call
but
yeah
nice
to
confirm
that
so
I
I
didn't
mean
to
completely
hijack
your
meeting
in
case.
You've
got
other
topics
to
get
to,
but,
from
my
perspective,
really
valuable
to
get
this
initial
feedback
and
maybe,
as
a
Next,
Step
Stephen
talked
about
creating
a
a
new
version
of
this
original
outline.
E
I
could
do
that
and
I
could
make
it
shareable
to
the
group
and
I
could
incorporate
some
of
the
things
we
talked
about
today
can
kind
of
eliminate
things
that
maybe
feel
a
little
too
detailed
at
this
point
or
just
put
a
qualifier,
you
know
to
be
addressed
in
the
future
and
if
I
could
get
that
shared
draft
back
to
the
three
of
you
for
input
and
then
we
could
than
when
you
feel
like
it's
at
the
right.
State
share
more
broadly
within
this
group
or
others.
E
A
D
C
E
D
I
think
that
all
sounds
great
I
think
it
would
be
nice
to
kind
of
figure
out
timelines
here
if
things
were
to
go
ideally
as
planned,
and
this
were
to
be
something
that
could
be
presented
in
Detroit.
What
would
the
timeline
be
so
like?
What
what
state
do
we
want
to
be
in
by
the
next
meeting?
For
example,
in
two
weeks.
E
Yeah,
unfortunately,
in
two
weeks,
I'll
be
out
on
vacation,
but
my
colleague
Amar
could
certainly
attend
yeah.
Maybe
if
we
get
an
outline
out
to
the
mailing
list
or
the
Google
group
sooner,
we
could
solicit
some
feedback
and
then
on.
The
next
call
in
two
weeks
incorporate
that
feedback
and
try
to
finalize
the
scope
of
this
original
paper
more
firmly
and
then,
when
looking
to
prepare
materials
for
events,
always
just
work
backwards
from
when
we
have
to
have
everything
already
I.
E
D
A
A
D
D
And
that
can
be
vague
too,
like
it
can
be.
The
Proposal
could
be
hey
where
the
proposal
could
be.
What
is
what
are
the
extra
properties
that
take
that
that
are
needed
to
make
a
cloud-native
application?
Edge
native
list
out
a
few
that
we
had
outlined,
talk
about?
There's
a
white
paper
underway
and
the
cncf
iot
edge
working
group
defining
this
come
learn
about
kind
of
the
rubric
for
your
Edge
native
application,
something
vague
like
that
could
be
probably
sufficient
and
eye-catching
enough
to
to
put
in
early
on.
A
D
Yeah
yeah,
so
it
sounds
like
we
have
two
new
docs
that
are
gonna
need
to
be
made
one
Brandon
for
a
new
one.
That's
gonna
have
the
iterations
that
we
discussed
and
new
access
rights
with
the
iot
Edge
working
group,
Google
group
that
day
on
sent
another
that
will
be
this
abstract
for
the
working
groups.
Talk
that's
focused
on
what
is
Edge
native.
E
C
A
So
I
just
figured
out
today
that
I
I
I
probably
won't
go
to
kubecon.
We
have
a
I,
don't
know
how
they
did
it,
but
there's
the
eclipse
on
it.
The
same
week
is
couponing
and
I
think
we
are
committed
yesterday
to
to
hackathon
there
with
a
with
a
Bluetooth
mesh
and
everything.
If
that
happens,
I
wouldn't
be
able
to
travel,
but
I
am
willing
to
help
with
the
with
a
presentation
and
and
and
the
in
the
paper.
A
C
A
D
Okay,
well,
we
can
have
up
to
four
speakers,
so
that's
something
we
also
want
to.
When
we
submit
this.
We
need
to
to
decide
what
four
speakers
I
know
from
past:
hybrid
coupons,
it's
kind
of
you're,
all
in
person
or
you're,
all
hybrid,
so
we
could
choose
to
all
be
hybrid,
and
if
we
wanted
it,
there
does
seem
to
be
larger
audiences
if
we
do
in
person,
but
you
know
it's,
we
should
be
flexible
with
these
times.
So
that's
something
we
can
also
discuss.
A
I
mean
you
know:
let's,
let's
see
how
it
goes,
you
know
you
don't
have
to
do
any
anything
special.
You
know
because
of
me,
if
it's
better
to,
if
you
all
guys,
can
be
there
in
person
and
that's
better
way,
that's
great
I'll
be
there
as
a
as
a
support
this
time
and
yeah
there'll
be
more
coupons.
So
don't
worry,
yeah.
D
A
C
C
A
C
I
mean
I.
Guess
this
video
wasn't
super
helpful
for
my
specific
goal,
which
is
fine.
I
wasn't
really
expecting
that,
but
yeah
I
think
if
any
of
you
are
able
to
help
me
or
just
give
me
insights
as
to
like.
What's
the
most
popular
records
running
in
kubernetes
around
the
edge
I
would
really
appreciate
that
we
could
talk
about
it
later,
set
up
a
meeting
or
something
but
yeah.
D
D
We
even
and
some
of
our
our
couple
previous
white
papers
talk
about
some
of
the
common
Edge
use
cases
and
some
of
the
applications
that
go
with
that
I
think
in
our
kubernetes
GitHub.
So
we
can
maybe
once
you
comment.
I
can
link
some
of
those,
but
that
would
be
a
great
one
to
kind
of
ask
the
whole
Community.
That's
in
the
slack
there
because
I'm
sure
there's
a
lot
of
answers
to
that,
and
it
sounds
like
ideally
you'll
get.
C
A
C
A
But
so
I
I
think
tracking.
The
the
working
group
is
good
because
we're
trying
to
bring
people
who
are
doing
interesting,
stuff,
interesting
projects
in
this
area
to
present
to
the
group.
So
so
that's
one
way
to
find
out.
What's
what's
new
and
hot,
but
I
also
think,
like
you
know,
tracking
the
progress
of
this
white
paper
might
might
be
super
useful
for
you,
because
that's
where
all
the
thinking
will
be
going
of,
of
defining,
what's
what's
relevant
and
what's
not
for
for
the
internet,
app
developments
right.
D
D
Great
so
I
think
on
the
transition
to
the
cncf
side,
just
an
update
there
I'm
reaching
out
and
trying
to
get
us
added
to
the
cncf
calendar.
We
are
currently
a
part
of
kubernetes
calendar,
but
it
doesn't
reflect
our
current
meeting
Cadence.
So
that's
kind
of
in
flux
at
the
moment,
but
hopefully
we'll
have
a
new
calendar
to
point
to
and
meetings
will
be
clearly
delineated.
There.