►
From YouTube: Kubernetes WG IoT Edge 20200617
Description
June 17 2020 meeting of the Kubernetes IoT Edge Working Group - cross community discussion with OSF Edge Computing group
A
B
B
We
just
had
a
recent
developer
gathering
virtual
event,
where
we
were
talking
to
a
couple
of
communities
in
the
area
of
edge
and
were
kind
of
exploring
collaboration
opportunities.
So
I
think
the
idea
for
this
agenda
item
would
be
to
kind
of
introduce
the
osf
edge
computing
group
to
to
your
group
and
vice
versa,
and
basically
see
if
we
have
some
connection
points
and
some
areas
where
we
could
work
together.
B
Yeah,
so
I
just
dropped
a
link
to
our
wiki,
practically
all
of
our
stuff
is
there
or
available
from
there.
We
also,
I
will
dig
up
the
link.
We
just
published
a
white
paper
this
monday,
that's
practically
kind
of
summarizing
the
work
that
we
are
doing,
so
I
will
dig
up
that
link
too
and
and
put
it
in
the
chat
a
little.
C
B
B
However,
we
were
taking
a
closer
look
to
the
telecommunications
and
5g
aspects
of
edge,
because
that's
where
most
of
the
activities
happened
so
far,
but
we
are
not
exclusive
to
that
area
and
based
on
the
use
cases,
we
are
identifying
requirements
and
kind
of
trying
to
see
how
much
of
the
requirements
in
the
different
industry
segments
are
common.
What
kind
of
error
cases
and
scenarios
the
different
use
cases
or
well?
The
architectures
need
to
be
prepared
for
in
the
different
use
cases
and
based
on
our
learnings.
B
We
have
two
reference
models
and
we
are
working
on
building
reference
architectures.
Based
on
that,
we
started
with
looking
into
how
to
put
it
together
from
openstack
services.
We
have
a
kind
of
a
minimalistic
reference
architecture
view
and,
as
I
mentioned,
we
started
to
look
into
containerized
workloads
as
well
and
containerized
edge
sites
also
and
reaching
out
to
the
kubernetes
community,
where
the
experts
are
and
with
the
reference
architectures.
B
We
are
also
looking
into
testing
activities
so
kind
of
trying
to
figure
out
if
what
we
put
together
actually
does
work
and
does
the
job
or
not
and
along
the
way,
we
are
basically
sharing
what
we
learned
with
any
community,
that's
interested
in
it.
So
we
are
also
not
exclusive
to
openstack
as
a
as
a
technology
or
the
openstack
foundation
projects
as
projects
to
collaborate
with.
B
So
we
would
like
to
really
share
our
learnings
with
all
the
industry
and
anyone
who's
interested
in
it
and
also
work
together
with
with
those
individuals
and
organizations
where
it
makes
sense
and
where
there
are
some
connection
points.
I
can
really
quickly
introduce
those
reference
models
or
we
can
also
go
ahead
and
see
if
there
there's
any
questions
from
anyone
so
far
or.
A
B
B
I
also
dropped
a
link
to
the
recent
white
paper
that
we
published.
There
are
a
few
use
cases
in
there
too.
There's
a
5g
one,
there's
an
aquaculture
one,
shrimp,
farms,
an
industrial
iot
one
and
I
think
a
cd
and
a
content
delivery
network
one
in
it.
So
I
think
that's
a
kind
of
a
good
coverage
in
terms
of
industry
segments
to
which
we
had
some
access
to
so
far.
D
B
Yes,
we
started
that
activity.
I
think
what
we
need
to
do
in
some
extent
is
to
go
back
to
those
industry
segments
who
are
kind
of
catching
up
and
starting
to
deploy
some
infrastructures
as
well
and
see
if
we
can
get
some
more
details,
because
some
of
our
use
cases
are
more
detailed
and-
and
some
are
well
all
that
we
could
get
at
the
time
when
it
came
up.
B
But
the
goal
is
definitely
to
to
try
to
see
how
we
could
come
up
with
solutions
in
the
open
source
ecosystem
that
that
fulfills,
multiple
use
cases,
as
opposed
to
only
specializing
for
one,
especially
because
I
think
edge
computing
infrastructures
are
kind
of
going
organically
and
there's
the
operator
network
and
the
operator
network
will
be
shared
with
multiple
entities
as
well.
So
we
can't
really
say
that
there
is
one
entity
with
one
solution
and
and
that
works
for
them,
and
that
will
work
for
everyone
else
too.
B
Who
has
something
similar
and
those
are
those
will
never
be
connected
ever
I
think,
looking
into
stuff,
like
interoperability,
will
be
way
more
crucial
than
ever
and
just
kind
of
all
the
things
that
we
had
under
the
rugs
in
the
time
of
having
distributed
systems,
we
will
need
to
deal
with
those
when
we
are
having
messed
up
the
distributed
systems
and
any
help
with
this
activity,
or
if
we
could
do
that
together
with
other
groups.
I
think
that
would
benefit
all
of
us,
so
we
don't
have
to
do
all
these
exercises
in
parallel.
E
B
I
think
it
was
a
university
project
where
they,
where
they
started,
to
work
on
how
to
make
that
project
the
functionality
available
for
iot
devices
as
well.
So
it's
not
true
that
we
did
not
look
into
it
at
all,
but
so
far
our
focus
was
closer
to
the
ias,
layer
and
and
services
just
kind
of
trying
to
limit
our
scope
somewhere.
B
Well,
how
to
put
this
so
our
scope
was
never
exclusive
to
openstack,
but
we
kind
of
so.
If
you
look
into
a
typical
edge
architecture,
you
have
some
kind
of
central
data
center
or
cloud
or
some
some
bigger
entity,
and
our
view
was
kind
of
how
to
extend
that
big
cloud
out
to
the
edge,
as
opposed
to
focusing
just
on
the
edge
itself,
if
that
makes
sense
so
in
in.
In
that
extent,
so.
B
You're
saying:
well,
you
have
one
cloud
and
then
you
have
multiple
clouds
connecting
to
it,
so
I
I
think
our
extent
was
you
have
at
least
some
kind
of
a
blade
or
server
or
a
box
big
enough
to
run
infrastructure
type
of
services.
If
that's
openstack,
then
it's
openstack.
If
it's
not
openstack,
then
something
else
so
yeah.
F
F
And,
like
I
said
the
center
cloud,
provided
you
know,
orchestration
activities
with
respect
to
you,
know
synchronizing
performance
data
and
that
sort
of
stuff
and
and
and
in
in
one
of
the
I
work
in
the
starling
x
group
that
does
the
distributed
the
multiple
clouds
distributed,
type
architecture
and-
and
we
started
out
originally
just
with
kind
of
an
openstack
solution.
But
we've
moved
to
a
kubernetes
based
solution
with
openstack
containerized
on
top
of
it.
So
you
can
actually
have
a
distributed
cloud
as
a
distributed.
A
But
not
every
use
case
does
to
having
one
cloud
in
the
world
managing
dispersed,
kubernetes
worker
nodes-
and
we
had
a
group
from
this
sundew
project-
come
on
about
two
three
months
ago,
talking
about
that
in
a
university
research
environment
where
they
were
federating,
individual
cluster
nodes
from
people
who
had
resource
around
the
world,
but
centrally
managing
them,
and
that
project
was
kind
of
an
interesting
presentation
within
kubernetes
itself.
I
think
there's
an
independent
working
group
that
addresses
federating
kubernetes
clusters,
so
this
group,
maybe
isn't.
A
It
certainly
is
a
point
where
that
comes
up,
but
it
probably
isn't
the
only
one.
But
it's
an
interesting
topic.
The
I
looked
through
the
the
link
posted
and
I
I
noticed
one
of
the
challenges
it
said
you
were
taking
on-
was
load
balancing
across
geographically
distributed
hardware,
and
that
would
be
that
sundu
use
case
of
people
trying
to
use
kubernetes
for
that,
but
yeah.
I
think
there
is
a
lot
of
overlap
here.
A
A
few
of
the
things
I
saw
called
out
that
I'm
kind
of
curious
about
if
you
found
anything
because
we
haven't
had
any
speakers
here
or
people
address.
This
is
dealing
with
this
challenge
of
storage
out
at
edge.
You
know
it's
sometimes
when
you're
resource
constrained
and
dollar
constrained,
coming
up
with
resilient
storage,
good
enough
to
run
stateful
apps
and
cover
some
of
the
use
cases
of
you
know
getting
around
single
points
of
failure
are
kind
of
an
interesting
challenge
with
kubernetes
now
and
if
you've
come
across
any
ideas
or
solutions.
A
I
think
I
I
don't
know
I'm
personally
interested,
but
I
suspect,
there's
there
would
be
broad
interest
in
that
and
then
some
other
topic
that
came
up.
I
mean
your
challenges.
Talks
about
load
balancing
across
geo-distributed
in
kubernetes,
often
the
term
load
balancer,
is
kind
of
used
with
a
different
flavor.
There's
a
load
balancer
resource
in
kubernetes
that
in
a
public
cloud,
was
usually
the
way
that
you'd
publish
some
service
that
is
exposed
in
your
cluster
publicly
so
that
you
could
get
added
externally.
A
F
Sorry
go
okay,
I
was
just
gonna
say
like
with
respect
to
the
load
load
bouncing.
I
should
have
mentioned
that
yeah,
like
the
kubernetes
solution,
that
the
starlight
project
has
with
an
openstack
is
kubernetes
on
bare
metal,
so
yeah
you're
right
that
the
we
don't
have
a
good
solution.
Yet
for
like
load
balancing
like
we
don't
use
the
metal.
I
know
there's
a
metal
load
balancer.
I
think
in
kubernetes
that's
available
for
kubernetes.
F
B
A
It
was
popular,
but
one
of
the
issues
I've
heard
people
cite
is
that
it
was
started
by
kind
of
one
of
these
projects
where
there's
a
dominant
developer,
who
didn't
wasn't
doing
it
as
his
day
job
and
announced
that
he
was
walking
away
from
the
project,
and
I
think
that
has
caused
a
lot
of
people
to
be
a
bit
concerned
about
that
as
a
long-term
solution.
Yet
it
does
strike
me
as
extremely
popular
yeah.
F
Yeah,
so
we're
looking
for
one,
because
the
only
solution
we
have
to
that
is
is
really
like.
We
use
calico
as
our
cni
and,
like
you
know
how
I
haven't
done
it
myself,
but
you
know
how
you're
supposed
to
be
able
to
run
bgp
within
calico,
and
then
you
could
advertise
your
service
service
nets,
service,
subnets
or
whatever
acro
through
bgp
advertisements,
but
I
suspect
the
the
outage
times
would
be
slower
or
larger.
Yeah
these
times
would
be
larger,
yeah.
A
B
F
F
F
A
I
think
all
the
solutions
kind
of
that
evolved
out
of
the
virtualization
and
hypervisor
era
that
would
get
where
resource
is
like
a
half
rack
of
equipment,
that's
sort
of
a
solved
problem,
but
if
you
get
down
to
raspberry
pi's,
you
know
like
two
of
them
or
three
raspberry
pi's
running
these
software-defined
storage
solutions.
We
have
now
is
sort
of
problematic.
First
of
all,
they
might
only
have
gigabit
ethernet.
So
even
if,
in
theory,
you
could
make
clustered
storage
out
of
three
pies
running
that
over
gigabit
ethernet
is
going
to
have
really
low
performance.
A
You
know
like
way
lower
performance
than
even
a
rotating
media,
consumer
sata
drive
and
maybe
there's
better
solutions
now
that
some
of
those
tiny
boxes
are
getting
usb
3,
but
I
I've
yet
to
come
across
one
it.
Just
it's
an
interesting
area
to
me.
If,
in
your
project,
you've
ever
encountered
anything
that
deals
with
that
kind
of
really
low
budget
low
resource
thing
of
three
pies
or
three
nooks.
F
Yeah
no
yeah
we
haven't
got
down
to
that,
although
I
know
within
sterling
x
and
I
think,
even
within
the
edge
computing
group,
we
we're
interested
in
looking
at
kind
of
the
next
level
down
like
the
like,
the
you
know,
actually
device
level
edge
components,
but
we
haven't
done
a
lot
of
work
in
that
area.
Yet.
G
Now
I've
done
I've
done
osds
on
I
use
stuff
on
sbcs,
small
single
boards
and
actually
build
edge
level
clusters
that
way
using
stuff.
The
performance
is
not
that
bad
depending
upon
the
type
of
single
board
you
get
and
and
what
kind
of
storage
mechanism
you're
using,
but
it's
it's
and
it's
also
dependent
on
you
know
what
from
us
from
this
data
standpoint,
what
you're
trying
to
do
there.
G
So
in
our
particular
instance,
we
were
using
it's
basically
real
time
series
data
that
was
coming
back
from
sensors
and
it
was
it
was
more
than
and
because
of
our
architecture.
The
way
it's
designed
it
was
one
that
was
was
was
acceptable.
I
mean
it
was
it
wasn't
the
performance
bottleneck
at
all,
but,
like
anything,
your
mileage
may
vary
depending
on
what
you're
trying
to
accomplish,
but
we
have
done
that
and
we've
been
fairly
successful,
with
kind
of
remoting
stuff
out
to
the
edge.
G
A
I
suppose,
for
that
time,
series
data
and
sensors
another
way
to
address
storage.
It
isn't
storage
per
se,
but
using
kafka
is
both
a
combination
of
event,
driven
messaging
but
persistence
thrown
in
the
mix
too.
So
there
might
be
a
another
solution
for
that,
but
I
think
when
it
comes
to
storage
and
edge,
it's
just
it's
not
just
like
redundancy,
but
the
issue
where
these
are
unattended
locations
or
locations
where
you
don't
have
highly
trained.
A
I.T
personnel
like
put
put
a
kubernetes
cluster
into
a
fast
food
sandwich
shop
or
something
like
that,
and
even
though
the
storage
is
theoretically
redundant,
if
it
requires
an
expert
to
go
recover
it
when
a
device
fails
that
isn't
really
a
workable
solution.
So
you
know
there's
there's
aspects
of
this
that
beyond
just
the
performance.
G
A
E
I
got
started
with
with
working
just
with
usb,
so
you
just
kind
of
install
the
driver
and
then
you
give
host
access
to
the
whole
container,
which
of
course
is
not
the
let's
say
safest
thing
to
do,
but
it
kind
of
gets
the
stone
rolling,
but
yeah
the
fpga
thing
is
still
on
our
plate.
So
that's
basically
the
next
step
we
want
to
take,
but
I
don't
see
why
spi
should
be
any
different
than
usb,
so
it.
A
I'm
by
no
means
an
expert,
but
it
turns
out
I've
been
playing
around
with
this
just
a
personal
level
trying
to
get
home
automation
running
in
my
house
and
been
doing
this
for
all
of
two
weeks,
so
be
real.
Careful
about
what
I
say
because,
like
I
say,
I'm
definitely
underlying
not
an
expert,
but
I
am
running
a
home
automation
thing
called
home
assistant
in
kubernetes
and
at
first
I
tried
getting
it
running
in
standard
kubernetes
and
also
another
complication
I'll
point
out.
A
I'm
running
it
on
top
of
a
hypervisor,
not
bare
metal,
but
I
did
get
it
to
work,
but
some
of
the
problems
were
routing
the
I
o
I
was
using
usb
and
there
was
a
way
to
punch
the
usbs
through
the
hypervisor
and
on
up
into
a
kubernetes
cluster
node.
But
then
it
was
sort
of
felt
like
you
were
fighting
the
kubernetes
scheduler,
rather
than
doing
it
any
favors
because
it
really
had
to
be
on
one
particular
cluster
node.
A
That
was
hosted
on
one
particular
hypervisor
node
to
get
that
routing
to
go
through
and
it
did
work.
But
I
came
up
with
plan
b
that
seemed
to
work
better,
and
that
was
that
I
found
a
lot
of
packages
that
would
convert
these.
I
o
devices
and
definitely
usb,
is
in
there.
Z-Wave
was
another,
I'm
quite
sure
I
saw
the
i2cc.
A
I
saw
bluetooth,
low
energy
routed
to
first
mqtt
and
what
I
ended
up
doing
was
bringing
up
a
small
pie,
not
even
a
pie,
four,
but
an
old
pie.
Three
I
had
laying
around
with
you
know
kind
of
smallish
memory,
but
it
was
perfectly
capable
of
hosting
these
kinds
of.
I
o.
I
put
the
z-wave
interface
usb
interface
in
there.
It
already
had
built-in
bluetooth
and
the
software
to
take
that
I
o
and
publish
it
via
mqtt
to
a
mosquito
broker,
worked
fine.
A
In
fact,
I'm
hosting
the
mosquito
broker
on
the
same
pie
and
then
my
kubernetes
apps
that
deal
with
that.
I
owe
are
running
it
on
kubernetes
and
they're,
fully
flexible
as
to
where
they
run.
So
if
the
characteristics
of
mqtt
are
something
you
can
deal
with,
which
you
know
may
have
latency
challengers
or
bandwidth
challenges,
that
solution
seems
quite
workable
and
the
nice
thing
about
it
is.
I
found
just
the
biggest
problem,
wasn't
that
I
couldn't
find
examples
of
open
source
projects
that
published
and
dealt
with
these.
A
I
o
devices
and
gateways
there
were
just
too
many
of
them.
You
know
you'd,
look
for
bluetooth
solutions
and
there
had
to
be
a
dozen
and
it
felt
like
you
know,
one
that
was
obvious
and
great,
that
the
world
had
gotten
behind
might
be
easier
for
a
newcomer,
but
then
again
having
a
dozen
means
that
maybe
they
you
know
independently,
move
on
and
develop
so
not
criticizing
it.
A
H
B
A
D
I
think
that's
that's
a
if
nothing
else,
it's
an
opportunity,
specifically
on
the
iot
side
of
edge
iot
is
you
know
addressing
how
you
provide
maybe
universally
to
containers
within
a
kubernetes
deployment,
access
to
these
lower
level
interfaces
and
yeah
in
the
I
in
the
iot
game,
like
that,
you
know
any
any.
There's
it's
like
a
smorgasbord
of
devices
right.
So
all
you
know
every
little
sensor.
Every
little
thing
has
you
know
every
different
code,
every
language
environment
has.
A
Yeah,
I
think
the
the
container
world
with
iot
maybe
is
more
viable.
If
you
just
have
one
single
note,
because
you're
piercing
so
many
levels.
The
other
thing
I
didn't
point
out
it
not
only
was
that
you
get
tied
down
to
a
specific
node
on
kubernetes
or
on
a
hypervisor,
but
on
kubernetes
to
get
to
that
io
device.
You
had
to
run
in
privileged
mode
or
specifically
call
out.
You
know,
go
to
the
trouble
to
designate
what
devices
were
allowed
and
running.
A
Privilege
mode
is
maybe
going
to
be
troublesome
to
many,
if
not
most,
people
on
kubernetes
or
it.
Maybe
it
should
be
troublesome,
whether
it
is
or
not
with
it.
That
might
just
be.
People
aren't
aware
of
what
risk
they're
taking,
but
I
think
that
a
lot
of
these
I
o
devices-
you
know
the
home
ones
are
newer,
but
when
you
get
into
industry,
some
of
that
stuff
has
10
20
year.
A
They
do
typically
have
non-deterministic
deterministically
scheduled
workloads,
so
they
could
run
on
node
a
today
but
node
b,
an
hour
later,
and
that
is
problematic
if
those
deal
with
io,
so
the
gateway
is
kind
of
a
an
intermediary.
Is
I
I
think,
a
solution
as
long
as
you
have
enough
budget
space
etc
to
go
with
having
multiple
pieces
of
hardware.
I
I
That
we've
taken
with
the
eclipse
io
fog
project,
which
is
to
try
to
have
edge
microservices
that
can
be
instantiated
as
your
interface
layers.
We
have
one
for
gpio
for
your
common
pin
flipping
operations
right,
I'm
going
to
turn
on
an
led
or
this
type
of
stuff
or
trigger
an
actuator
and
we've
abstracted
it
away
to
a
rest
interface,
and
so,
when
you
do
need
access
to
the
gpio.
I
That
container
has
privileged
operations,
of
course,
right
to
talk
to
the
the
low-level
stuff,
but
the
way
it
exposes
it
up
is
actually
manageable
even
down
to
like
an
api
key
level.
If
you
want
to
give
microservices
the
opportunity
to
talk
to
it
or
not
talk
to
it
and
then
everything
that
you
do
filters
through
one
management
interface,
so
it's
possible
to
kind
of
keep
take
control
of
the
chips
we
haven't
done
it
yet
for
for
I
squared
c
or
for
spy,
but
there's
no
reason
that
it
couldn't
follow
the
same
pattern.
I
The
main
point
is
that
you
use
a
microservice
to
do
the
hardware
abstraction,
so
you
don't
have
these
microservices
running
until
you
need
them
and
lord's
mentioned
working
with
fpgas.
It's
like
the
same
thing.
You
want
to
flash
the
fpga
that
can
run
by
the
edge
agent
when
you
need
it,
and
then
it
gets
out
of
your
way,
but
not
every
edge
instance
needs
this
right.
So
you
have
a
bare
minimum
agent
and
then
it
pulls
down
what
it
needs
for
the
hardware.
Abstraction
is
kind
of
the
concept.
A
C
So,
back
to
the
topic,
I
I
like
the
two
two
groups
collaboration,
especially
like
sharing
the
use
cases
and
then
reference
architecture.
So
for
your
reference
or
you
can
watch
the
previous
coupon
talks,
they
addressed
some,
how
we
are
viewing
of
the
edge
computing
and
then
the
reference
architecture
or
the
technical
challenges.
C
So
from
personally,
I
would
really
like
to
hear
from
from
you
guys
like
what
are
the
key
technical
problems
you
are
trying
to
address
because,
like
I
think
from
today's
meeting,
I've
heard
several
things
about
highly
distributed,
load
balancing
or
like
how
do
you
like
manage
the
state
on
the
edge
devices
through
some
storage
or
something
like
this?
I
think
it
would
be
really
helpful
like
if
the
two
teams
can
collaborate
and
then
leverage
our
strength.
I
think,
from
an
openstack
perspective,
building
the
iaes
you,
you
guys
have
already
viewed
a
lot
of
expertise.
B
B
We
just
started
discussions
around
storage,
for
example,
so
we
were
thinking
about
the
block
storage
aspects
as
you
do
it
for
a
cloud,
and
then
we
also
started
to
look
into
object,
storage
and
just
kind
of
different
types
of
challenges
in
that
area.
So
I
don't?
We?
Don't
necessarily
have
a
lot
of
answers
to
those
questions
yet,
but
it's
something
that
we
just
started
to
look
into
as
well.
B
So
I
think
collaboration
in
those
areas
would
be
really
really
good
and
the
other
thing
that
I
think
we
could
also
talk
about
not
on
this
meeting
but
longer
term
is
if
you
do
any
type
of
testing
and
evaluation
activities
and
if
we
could
connect
those
in
some
extent
and
and
do
some
joint
activities
in
that
area.
So
kind
of
we
come
up
with
some
cool
ideas
and
see
if
they
actually
work.
B
H
So
what
I
wanted
to
say
say
earlier
is
that
I
think
this
cross
community
thing
is
great
and
and
what
we
should
try
to
do
in
in
the
next
six
minutes
that
that
steve
gave
us
is
to
figure
out,
what's
the
best
way
to
to
to
hold
the
future
meetings
and
and
and
and
how
to
continue
this
I
mean
it
was
a
great,
a
basic
introduction
and
and
and
and
the
general
discussion,
but
you
know
how
we
proceed.
What
are
the
next
first
step
we
can
do
and
when.
C
C
B
Yeah,
I
I
think
we
can.
We
can
definitely
do
that.
We
aren't
doing
a
lot
of
demos
lately
as
we
started
to
discuss
some
new
areas
for
us,
so
I
I
I'm
also
kind
of
wondering
how
we
can
follow
each
other's
activities
in
terms
of
maybe
have
some
more
participation
in
meetings
of
like
either
some
of
the
edge
computing
groups.
Members
are
are
joining
this
call,
or
sometimes
you
join
our
weekly
weekly
calls.
We
have
it
on
tuesdays.
I
believe
8
a.m-
pacific
every
week.
C
C
C
B
B
J
B
H
That's
the
main
one,
and
then
the
slack
channel
is
is
the
main
communication
channel.
So
I
think
going
forward.
We
can,
you
know,
just
keep
in
touch
and
and
try
to
think
from
time
to
time,
and
when
some
topic
comes
up
I
mean
we
can
always
use
some
of
some
of
our
slots.
For
your
slots
to
to,
you
know,
dig
deeper
into
into
a
specific
topic
right.
B
C
A
C
A
C
A
What
we
were
talking
about
was
back
before
kovid.
We
were
planning
on
having
a
meeting
of
users
at
the
kubecon
europe
event
and
we've
had
these
meetings
call
call
them
informal
birds
of
a
feather
at
the
kubecon
events
all
over
the
world
for
the
past
couple
years,
and
we
find
that
the
users
divide
up
into
kind
of
camps,
of
industrial,
iot,
telco
device
edge,
retail
edge,
etc,
and
they
have
things
in
common,
but
also
things
that
are
different,
and
we
were.
A
We
had
this
idea
that
we
wanted
to
conduct
a
survey
to
just
see
what
is
of
interest
out
there,
and
the
idea
was
that
we
can
get
the
cncf
to
send
out
this
survey
to
their
entire
mailing
list
and
see
what
responses
we
get
and
we're
trying
to
compose
a
survey
it.
It
can't
be
gigantic
because
then
people
won't
take
it.
You
have
to
time
box
it
where
you
can
honestly
say
in
the
email.
A
C
Yeah
sure
yeah,
thank
you
steve
for
the
background
I
think
like
a
given.
We
are
all
work
working
from
home.
I
I
somehow
feel
like
it's
it's
an
advantage.
We
got
some
advantage
to
a
lot
of
people
like
a
thing
hard
and
then
and
fitting
because,
like
in
the
conference,
people
are
like
interacting.
They
don't
have
much
time
to
fit
in
the
survey.
So
it's
a
good
time
like
for
us
to
like
collectively
know
what
people
are
thinking.
C
What's
the
refresh
people's
mind
like
or
collect
what
the
challenges
that
they're
facing
and
then
they
can
tackle
like
all
of
us,
can
tackle
the
problems
together.
So
that's
the
thought.
So
as
what
steve
suggested,
I
will
resend
the
survey
information.
Please
take
a
look
and
then
provide
your
input
and
feedback
and
then,
after
that
like
if
we
can
finalize
our
versions
into
the
cncf
yeah.
A
A
And
then
we'll
prioritize
them
and
hopefully
we'll
get
more
than
we
can
fit,
but
then
we'll
sort
them
out
to
get
the
best
ones.
Maybe
we'll
have
a
meeting
for
that,
but
when
cindy
puts
it
in
the
slack
channel,
if
you've
got
ideas
for
questions
you
you're
curious
about,
that
would
benefit
from
having
exposure
and
feedback
from
the
community.
C
C
B
A
A
I
C
K
A
K
A
A
C
A
A
B
Thanks,
okay,
I
just
wanted
to
say
it's
illegal
that
I
don't
see
greg
on
the
call
anymore
he's
from
the
starting
x
community.
So
if
there's
any
interest
in
any
details
of
the
project,
I
I
can
check
in
with
him
as
well,
so
that
he
could
come
in
and
present
or
find
someone
else
from
the
community.
Who
could
give
you
some
details
on
any
interesting
bits
and
pieces.
A
Okay,
that
sounds,
I
think,
we'll
take
you
up
on
the
offer.
If
that's,
if
it's
fair,
to
offer
on
somebody
else's
behalf,
maybe
you
can
confirm
but
yeah
our
group
is
off
operating
pretty
informally,
so
we
don't
want
to
really
be
gatekeepers
so
far,
we've
thrown
it
out
there
for
any
member
who
wants
to
to
put
something
on
the
agenda
and
it
hasn't
really
been
abused.