►
From YouTube: Kubernetes IoT Edge Working Group: Edge Device Onboa... Steven Wong, Kate Goldenring, Kilton Hopkins
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes IoT Edge Working Group: Edge Device Onboarding and Management - Steven Wong, VMware; Kate Goldenring, Microsoft; Kilton Hopkins, Edgeworx
Integrating I/O and compute devices at edge locations requires automated processes to work at large scale. This session will cover open source tools that support device lifecycles, from secure onboarding and discovery, through monitoring, maintenance, and use in production. We'll survey CNCF, LF Edge, and Eclipse projects designed to extend the cloud to inter-operate with edge devices and I/O; for example, one CNCF project, Akri, discovers edge devices and exposes them as Kubernetes resources. The K8s IoT Edge working group focuses on using Kubernetes as a tool to support applications running on, communicating with, or using information gathered from edge devices. There are opportunities to contribute to the evolution of Kubernetes to better serve edge use cases. We will close with details on how you can get involved with the community effort to help this happen.
A
A
A
Finally,
we
believe
that
recent
technology
is
going
to
be
disruptive
in
edge.
It's
going
to
be
big,
really
big
and
you
can
be
a
part
of
a
community
that
changes
the
world
and,
at
the
end,
we're
going
to
tell
you
how
to
get
involved
devices
don't
just
have
a
purchase
price.
There's
an
added
operational
aspect
onboard
is
the
process
of
taking
a
new
device
and
initializing
it
to
begin
using
it.
A
A
What
you'd
like
is
to
use
existing
logistics
to
ship
a
newer
replacement
device
and
put
these
in
service
using
a
random
person
trusted
only
to
plug
in
the
power
and
network
cards
and
turn
it
on
no
logon
or
credentials
needed
secure
device
onboard.
Does
this
even
with
headless
or
keyboard-less
devices?
A
I'm
I
want
to
make
it
clear
what
problem
space
this
covers
and
whip
what
it
doesn't
cover.
This
is
intended
to
do
a
one-time
initial
update
or
install
of
software.
The
scope
is
the
software
running
after
a
boot,
so
from
the
os
level
on
up
through
a
container
runtime,
a
kubernetes
distribution
and
other
things
that
run
above
the
os.
I
suppose
that
if
you
had
an
executable
that
updated
firmware
without
triggering
an
immediate
reboot,
a
one-time
firmware
update
might
be
possible
too.
A
A
These
are
the
players
in
history
of
the
project.
Intel
originated
this
work
and
contributed
it
to
the
elf
edge
foundation.
Secure
device,
onboard
and
fido
device
on
board
are
two
names
related
to
the
same
thing.
The
fido
alliance
is
shepherding
the
spec,
the
lfh
lf
edge
org
is
publishing
reference
open
source
implementations
of
the
spec.
A
This
requires
a
manufacturer
to
host
a
couple
of
servers.
The
manufacturer
server
is
for
in-house
use.
The
rendezvous
server
is
used
by
device
owners
and
the
devices
themselves
after
a
sale,
and
when
this
happens,
the
use
of
that
rendezvous
server
is
limited
to
a
couple
of
brief
one-time
transactions.
A
There's
also
an
owner
server
not
shown
in
this
diagram
that
I'll
cover
in
a
moment
open
source
reference.
Implementations
of
these
servers
are
published
on
github.
They
might
not
be
sufficient
for
your
production
needs,
but
the
spec
is
open.
If
you
want
to
build
your
own,
I'm
not
going
to
cover
how
to
deploy
these
servers.
I
just
don't
have
time
to
do
it
in
35
minutes,
but
I'll
tell
you
that
docker
versions
of
these
are
out
there
and
I'm
going
to
present
a
demo.
A
That
already
has
these
things
deployed
and
I'm
not
going
to
show
you
how
they
were
deployed
after
a
device
is
made.
It
runs
code
that
interacts
with
the
manufacturer's
server
over
a
connection.
A
device
guide
is
generated
and
a
menu,
and
the
manufacturer
server
makes
a
record
of
the
new
devices
model
and
serial
number.
The
device
itself
records
a
crypto
hash
of
the
manufacturer's
key
and
the
address
of
the
manufacturer
operated
rendezvous
server
that
it
contacts
upon
first
powerup.
This
is
stored
in
a
tpm
or
other
form
of
restricted
operating
environment
on
the
device.
A
Now
for
demo,
you
could
leave
it
on
the
file
system,
but
that's
probably
not
a
safe
thing
to
do.
In
production,
I'm
going
to
be
doing
a
demo
using
what
I'd
consider
a
representative
edge
device,
a
dell
edge
gateway
5000.
This
is
a
picture
of
it.
The
actual
unit
in
my
home
lab
on
a
workbench
with
the
cover
removed.
It's
a
four
core
intel
atom
cpu,
with
eight
gig
of
ram
passively
cooled
with
an
m2
ssd
and
a
bunch
of
ports
suitable
for
industrial
io
devices
like
can
bus,
rs485,
serial,
etc
after
sale.
A
A
digital
voucher
for
the
device
is
generated
and
given
to
the
owner
in
the
voucher.
The
current
owner
is
at
the
end
of
a
chain
and
can
demonstrate
ownership
to
the
device
through
use
of
a
private
key.
The
device
squid
is
in
the
voucher
and
is
signed
by
all
the
owners
and
in
this
chain
the
manufacturer
is
first
in
the
list.
A
Remember
the
device
also
has
a
securely
held
hash
of
the
manufacturer's
key,
so
it
will
be
able
to
validate
the
owner
when
presented
with
the
voucher
after
sale.
The
device
is
not
involved
in
voucher
generation
during
this
generation.
It
can
stay
unpowered
sealed
in
a
box
until
it
goes
into
operation.
A
The
next
step
is
that
the
device
owner
calls
an
api
on
the
rendezvous
server
that
causes
the
rendezvous
server
to
host
temporary
name
lookup
service
kind
of
like
dns,
and
you
do
this
just
before
you're
about
to
power
the
device
the
owner
provides
the
device
grid
and
ip,
where
the
device
redirects
to
the
owner
for
configuration,
instructions
and
a
time
limit.
For
example,
one
hour
after
which
time
the
lookup
service
for
this
device
will
terminate
the
device
is
still
all
powered
off
here.
A
A
Also
observe
that
the
owner
is
disclosing
very
little
to
this
rendezvous
server
and
that's
intentional.
The
rendezvous
server
does
not
know
who
this
customer
is
and
the
ip
address
provided
can
be
a
temporary
one.
Perhaps
a
burner
address
rented
on
a
public
cloud
or
even
an
address
inside
a
private
range
that
that
device
is
going
to
be
able
to
get
to.
So
this
allows
a
retailer
that
doesn't
want
people
to
know
where
stores
are
opening
to
keep
this
information
private.
A
Finally,
the
device
is
powered
on
it.
First
contacts:
the
rendezvous
server
gets
quickly
redirected
to
the
owner
address,
which
is
where
an
owner
server
is
being
hosted,
and
then
it
connects
to
the
owner
server
where
it
gets
a
device
profile
that
drives
the
initialization,
the
owner
to
device
transactions,
support
mutual
establishment
of
trust
over
a
secure
channel,
followed
by
delivery
of
a
series
of
key
value
pairs
that
are
kind
of
open-ended
in
terms
of
how
you
use
this
to
initialize
the
device.
A
The
reference
implementation
for
the
linux
client
I'm
showing
here
is
pretty
simple:
the
device
gets
a
bash
script
and
executes
it.
This
connection
isn't
intended
to
support
bulk
transactions
of
large
blobs,
such
as
an
os
image.
Instead,
you
use
the
connection
to
set
up
credentials
and
instructions
that
would
allow
you
to
set
up
a
secondary
channel
for
delivery
of
bulk
artifacts.
A
So
this
is
a
recorded
demo
just
sped
up
a
little
showing
you
that
manufacturer
process
when
the
device
was
manufactured,
I
started
with
ubuntu
installed
docker
I
actually
to
accelerate
this
there's
a
published
docker
image
that
has
the
client
sdk,
so
I
didn't
have
to
build
it.
I
invoke
a
script
on
that
client
sdk
that
generates
keys
for
the
device
contacts.
The
manufacturer
server
gets
the
stuff
burned
into
the
tpm
module
and
makes
the
record
of
this
device
being
manufactured.
A
It
records
it
on
the
manufacturer
server,
so
that
was
an
18
second
video.
I
do
want
to
shout
out
to
anthony
lapena
of
portainer
for
helping
me
out
with
this
demo.
I
used
a
docker
container
that
he
built,
so
I
was
able
to
avoid
compiling
and
building
my
own
client
sdk.
You
don't
have
to
use
portainer.
I'm
you're
going
to
see
me
doing
this
in
this
demo
because
it
has
a
nice
gui,
but
the
open
horizon
project
also
supports
secure
device
onboard.
I
suspect
a
number
of
other
projects
and
commercial
products
do
too.
A
So
I'm
moving
now,
instead
of
videos
to
in
the
interest
of
time,
I'm
just
going
to
show
screenshots,
but
the
process
for
getting
a
voucher
is
pretty
quick.
You
can
look
at
the
one
liner
using
a
docker
container
here.
This
doesn't
have
to
be
the
device
and
shouldn't
be
the
device.
It's
just
you,
the
owner,
go
or
you
the
manufacturer,
pull
a
voucher
and
you
send
it
to
the
customer.
A
A
A
You
first
create
that
device
profile.
Like
I
say,
that's
a
bash
script.
If
you're
using
portainer,
they
keep
a
catalog
of
these.
So
you
can
reuse
one
for
multiple
devices.
You
press
the
button.
It
brings
up
an
in
browser
editor,
you
write
your
bash
script,
save
it
with
a
name
and
then
you
can
reuse
it
for
multiple
devices.
A
A
At
this
point,
we've
got
the
profile
ready
and
we're
ready
to
use
it
if
you're
using
portainer,
you
would
upload
your
voucher
as
a
customer
and
then
pick
a
device
name
and
choose
the
device
profile
from
a
drop
down
list.
Okay,
this
is
the
actual
device
on
board.
It
takes
about
25
minutes
to
bring
up
unattended
a
kubernetes
cluster
that
is
in
operation.
A
Obviously
I
I
I'm
speeding
this
up,
but
the
steps
are
the
ubuntu
upgrade
took
a
long
time.
I
intentionally
wanted
to
challenge
this,
so
I
installed
a
back
level
ubuntu
and
took
it
up
to
the
current
that
that
takes
many
minutes.
It's
now
downloading
cube
cuddle
and
the
kubernetes
distro,
it's
untarring,
the
distro
and
this
distro
happens
to
be
tanzu
community
edition,
because
I
work
on
the
engineering
team
for
that,
but
it
could,
I
think,
be
any
kubernetes
distro
appropriate
for
edge
micro,
cades,
k3s
micro
shift.
A
A
I'm
going
to
skip
in
this
recording,
showing
the
helm,
install
and
the
portainer
agent
install,
but
you
get
the
idea
if
you
were
watching
that
this
thing,
oh
and
by
the
way
this
is
headless,
but
what
I
did
hear
just
to
record
this
is.
I
did
not
auto
invoke
this
client
thing.
You
should
set
it
up,
so
it
triggers
on
device
boot,
but
I
left
it
manual,
so
I
invoked
it
in
ssh
and
was
able
to
get
this
recording,
but
you
don't
have
to
do
it
manually
like
that,
but
that's
what
this
showed.
A
So.
Finally,
we've
got
a
kubernetes
cluster
stood
up.
We
have.
We
want
to
use
this
remotely
without
going
there,
so
you
need
some
means
of
remote
managing
it.
Now
this
is
the
portainer
ui
that
has
a
nice
dashboard.
For
this
it
one
element
of
the
dashboard.
You
can
see
the
running
pods,
I
can
click
on
a
container
get
the
logs
out
of
it.
A
They
also
have
a
button.
You
click
to
get
a
cube,
cuddle
shell,
but
an
alternative
would
be
to
install
ssh
and
just
log
in
there
and
use
cube
cuddle
remotely
there
are.
I
want
to
avoid
giving
commercial
promo
appearances,
so
many
of
you
might
be
aware
that
there
are
commercial
offerings
made
to
manage
and
federate
kubernetes
clusters
at
scale,
so
those
are
out
there,
but
I'm
not
calling
out
any
names
because
it
moves
into
promo
territory
and
it's
an
open
source
conference.
A
B
Great
so
steve
just
talked
about
those
servers
that
are
on
the
edge,
but
oftentimes
around
these
servers
on
the
edge
there's
a
bunch
of
iot
devices,
a
variety
of
kind
gathering,
really
important
data.
So
the
question
becomes:
how
can
we
easily
deploy
workloads
to
access
these?
This
data
manage
these
devices
and,
in
the
kubernetes
context,
oftentimes.
These
devices
are
kind
of,
on
the
smallest
end
of
the
user
edge
so
they're,
either
smart
devices
like
ip
cameras
or
maybe
they're
constrained
devices
that
have
no
extra
compute
to
put
anything
else
on
them.
B
It
can
automatically
deploy
your
workloads
to
use
those
devices
and
it
was
built
in
rust
because
we
really
are
focused
on
those
small
edge
scenarios
and,
as
an
aside,
ocre
also
means
edge
in
greek
because
we're
in
the
kubernetes
world
looking
a
little
bit
at
the
details
of
this.
So
as
I
mentioned,
we
discover
device,
then
we
create
a
kubernetes
resource
to
represent
it.
So
what
that
means
is
in
your
pod
spec,
just
as
you
could
declaratively
request,
cpu
and
memory
requiring
that
that
workload
is
only
scheduled
to
a
node
that
has
those
resources.
B
B
So
once
you
add
a
discovery
handler
to
ocry
you're,
basically
extending
kubernetes
to
be
able
to
declare
request
a
new
set
of
iot
devices,
and
when
we
talk
about
workloads
that
are
deployed
on
the
edge
to
manage
devices,
they
can
kind
of
fall
into
these
two
categories.
So
the
first
one
is
device
use.
So
you
want
to
gather
data
from
these
devices.
Maybe
do
some
pre-processing
only
send
up
some
final
aggregated
to
the
data
to
the
cloud
or
maybe
you
want
to.
B
Maybe
you
want
to
just
quickly
do
some
pass
some
information
onto
a
new
workload
or
maybe
you're
doing
some
protocol
translation,
so
you're
gathering
data
from
a
usb
camera
and
translating
that
data
to
mqtt
the
other
category
of
ways
that
you
can
use
these
devices
on
the
edge
is
managing
these
devices
and
oftentimes
in
your
managing
devices.
It's
short-lived
single
tasks
that
are
performing
some
action
on
that
device.
B
So,
for
example,
maybe
you're
configuring,
the
frame
rate
of
an
ip
camera
or
maybe
you're
performing
a
whole
firmware
upgrade
and
in
kubernetes
terms,
these
kind
of
fall
into
the
definition
of
long
running,
pods
or
kubernetes
jobs.
So,
with
ocry
we
can
automatically
deploy
your
workloads
in
these
two
forms
are
the
kinds
that
we
have
current
support
for,
so
digging
into
that
second
one.
So
the
management
scenarios
I
wanted
to
walk
through
a
scenario
of
using
ocry
to
upgrade
the
firmware
of
ip
cameras.
B
So
in
this
scenario
we
have
a
two
net
cluster
on
the
edge
and
we're
going
to
say
it's
running.
Yes,
like
steve
mentioned,
it
could
be
any
of
these
distributions
that
are
made,
and
our
objective
here
is
to
upgrade
the
firmware
of
these
cameras
from
1.0
to
2.0.
So
the
first
thing
you
do
when
using
ocari
is
you
deploy
your
helm
chart
when
you
install
our
helm
chart,
you
can
also
install
a
configuration
and
that's
awkey's
custom
resource
where
you
say
what
you
want
to
find
and
what
you
want
to
deploy
to
what
found.
B
B
B
B
Great,
I
hope
people
have
been
able
to
hear
me,
but
we'll
probably
have
questions
great,
so
you've
applied
your
configuration
and
now
ocari's
agent,
which
runs
on
every
node
in
the
cluster,
sees
that
so
now
it's
told
go
look
for
these
ip
cameras
across
the
network
for
every
there's,
the
configuration
for
every
camera
that
it
discovers.
It'll
create
our
second
custom
resource
definition,
which
is
an
instance,
and
that
represents
the
device.
B
So
once
the
instances
have
been
created,
our
controller
then
sees
that
and
it
will
automatically
deploy
the
workload
you
specified.
So
now
we
have
our
two
firmware:
upgrade
jobs
that
are
deployed
to
the
cluster
they're
going
to
reach
out
to
these
ip
cameras,
firmware
upgrade
endpoint,
so
onvif,
it's
device
management
endpoint
does
have
a
do
system
firmware
upgrade
endpoint.
So
these
in
this
scenario,
those
jobs
are
just
going
to
reach
out
to
that
camera
and
signal
that
upgrade.
However,
not
every
iot
device
has
its
own
firmware,
upgrade
endpoint.
B
So
maybe
in
your
current
device
management
solution,
you
have
some
agents
that
run
on
your
nodes
on
the
edge.
Well,
you
could
just
change
your
workflow
to
be
that
your
job
that
we
deploy
on
your
behalf
reaches
out
to
your
local
upgrade
agent,
and
then
that
upgrades
the
camera-
or
maybe
you
have
one
upgrade
agent
across
your
cluster
or
it's
on
a
different
server
that
you
want
your
job
to
reach
out
to.
Well,
then
you
could
change
that
as
well.
B
B
So,
to
kind
of
summarize,
the
goal
of
ocry
is
really
to
be
an
open
source
standard
way
to
connect
clusters
to
your
cuban,
to
connect
workloads
to
your
iot
devices
and
manage
your
iot
devices
from
kubernetes
clusters.
But
in
order
to
become
that
cohesive
standard,
it
really
needed
to
be
as
plugable
and
extensible
as
possible,
and
I
mentioned
some
of
the
ways
we've
done
that
so
our
discovery
handler
interface.
It's
just
that
grpc
interface.
You
can
really
bring
anything,
including
your
own
proprietary
protocols.
You
can
extend
ocry
to
be
kind
of
a
generic
service
discovery.
B
If
that's
of
your
wish,
and
then
you
really
do
bring
your
own
workloads,
which
is
that
second
part
of
it
and
then
we're
really
interested,
as
I
kind
of
focused
on
these
management
scenarios
with
ocaries.
So
we're
really
curious.
How
are
you
bringing
in
your
own
current
device
registries,
your
own
certificate
store
solutions
for
iot
device
management?
Are
there
headaches
when
doing
that
with
ocry?
And
how
can
we
ease
those?
Because
those
are
some
really
powerful
solutions
that
we
want
to
make
sure
we're
supported?
B
So
that's
kind
of
a
call
to
action
to
let
us
know
how
we
can
help
there
and
some
resources
to
learn
more.
We
have
our
documentation
site
within
that
site.
We
have
a
demo,
so
you
can
it
even
helps
you
set
up
some
fake
devices
in
case
you
want
to
try
it
out,
and
then
we
are
at
cncf
project.
We
do
have
monthly
community
meetings.
We
have
our
slack
on
the
kubernetes
slack,
the
ocry
channel
and
then
once
again,
this
is
a
link
to
that
demo
of
ipcamera
upgrades
so
kind
of
stepping
back
again.
B
So
in
this
whole
talk,
we've
talked
about
first
provisioning
servers
on
the
edge
and
then
also
giving
these
servers
access
to
those
iot
devices
and
there's
a
variety
of
scenarios
that
fit
this.
There's
a
variety
of
devices
that
fit
this,
and
so
the
working
group
is
really
trying
to
build
cohesion
around
the
heterogeneity
of
the
edge,
the
cloud's
very
homogeneous,
the
edge
we
have
so
many
different
devices.
B
B
It's
an
add-on
sdo
doesn't
need
to
be
provisioning
kubernetes,
so
there's
really
edge
solutions
that
go
beyond
kubernetes,
so
our
working
group
is
transitioning
from
kubernetes
to
the
broader
cncf
as
a
working
group,
so
we're
going
to
fall
under
the
runtime
tag
and
we're
going
to
redraft
our
charter
as
a
part
of
this
process.
So
if
you're
this
piqued
your
interest-
and
you
want
to
be
a
part
of
that
process-
please
join
our
working
group
meetings.
Here
are
those
resources.
B
A
C
He
has
to
be
the
first
one
asking
yeah
how
these
all
collide
with
the
project
matter,
because-
and
I
saw
that
this
edge
node
somehow
collides
with
the
with
the
border
router
concept
there.
I
don't
know
if
those
border
routers
fall
and
behind
the
edge
node
that
you
are,
you
are
designing
in
this
working
group
or
or
it's
really
the
same
concept.
A
C
More
about
the
concept
of
of
of
the
the
item-
let's
say
the
the
node
or
the
edge
node
and
in
this
working
group
and
and
the
border
router
concept
in
the
project
matter,
project
and
connected
homeowner
ip,
and
they
are
also
working,
the
secure,
commissioning
and
onboarding
and
provisioning
of
the
devices.
And
I
guess
that
they
are
also
probably
basing
the
decision
in
the
fido
alliance.
But-
and
I
don't
know
if-
and
there
is
some
and
on
working
together
with
those
kind
of
people
or
or
not
or.
A
There
are
people
who
support
scenarios
where
they're,
what
they
call
air
gapped,
where
they
don't
connect
up
to
the
private
public
internet
on
purpose
for
security,
or
just
because
it's
problematic
right
now
that
spec,
I
know
for
the
secure
device
onboard
that
I
talked
about
kind
of
was
the
reference
implementation
sort
of
implies
that
this
manufacturer
server
is
out
there
in
public
that
at
a
location
you
can
get
to.
But
I'll
tell
you
one
way
around
that
is
in
my
demo
effectively
I
made
myself
the
manufacturer.
A
You
know
I
stood
up
my
own
manufacturer
server
and
in
that
case
I
could
have
had
the
whole
system
for
that
behind
you
know
within
my
organization's
confines
with
no
outside
access
whatsoever.
So
that
would
be
one
thing
that
I
believe
would
work.
But
if
you
go
read
the
spec
they
kind
of
they,
they
thought
they
initially,
I
think,
targeted
a
scenario
of
the
main
manufacturers.
You
know
dell
hp,
whoever
running
these
servers,
but
there's
no
reason
you
can't
just
get
one
that
thing
I
used
on
a
demo.
A
I
just
bought
on
ebay
generic
linux
box.
That
happened
to
have
a
tpm
module
in
it,
blew
it
out
and
essentially
remanufactured
it
by
starting
from
scratch
at
the
bios
level.
The
other
thing
that's
in
the
spec,
but
not
working
now
is
they
have
a
plan
to
implement
protocols
like
coap
for
devices
that
wouldn't
even
have
ip
connectivity,
but
I
don't
believe
that
that
has
been
implemented
right
now,
but
it
is
in
the
plan
and
if
you
were
really
eager,
you
could
probably
help
out
by
helping
build
that
out.
It's
been
architected
to
allow
it.
A
D
E
A
There
there's
no
reason
you
can't
have
that
be
part
of
the
owner
on
board,
so
the
spec,
where
the
device
connects
to
the
owner
server
exchanges,
key
value
pairs,
so
part
of
that
payload
could
easily
be
keys
certificates,
whatever
addresses
for
where
you
establish
secure
tunnels.
So
I
think
that
that
might
be
the
process
that
you'd
use.
E
D
A
E
But
it
was
wondering
I
mean
it's
a
problem
that
everybody
will
need
to
solve
at
that
point,
so
maybe
also
like
trying
to
bring
some
sort
of
standard
or
tools
that
that
maybe
you
haven't
covered
the
other
day
at
the
third
manager
project.
They
they
pointed
me
to
the
spf
project
that
maybe
could
be
interesting
for
this
yeah.
A
The
the
other
thing
is,
you
know
you
say:
oh
it's
easy
with
these
key
value
pairs.
But
if
you
look
at
a
threat
model,
you
really
probably
ought
to
put
those
into
the
tpm
module,
because
these
edge
devices
for
the
common
use
case
are
probably
not
physical,
secure,
physically
secured.
So
you
have
to
worry
about
people
stealing
them
breaking
into
them
undetected
in
all
these
scenarios.
A
So
you
you,
you
clearly
want
to
have
some
kind
of
tamper,
resistant
storage
in
there
to
hold
keys
and
things,
and
just
the
fact
that
you
got
these
key
value
pairs
didn't
get
it
into
the
tamper
resistant
storage.
But
if
you're
executing
a
bash
script,
presumably
you
can
come
up
with
a
means
to
put
it
where
it
needs
to
go
either.
You
know
tpm,
they
have
these
puff
modules
that
are
lower
cost
or
what
I
mean.
A
F
Thank
you,
guys
great
presentation
and
yeah
thanks
a
lot.
I
really
enjoyed
also
the
live
mic
on
board
during
the
session.
That
was
great
as
well
so
yeah,
I'm
coming
from
from
the
telco
space,
and
when
we
hear
about
edge
immediately,
we
go
into
our
5g
mech
solutions.
If
you
know
multi-access
edge
computing-
and
I
was
wondering
if
you
do
things
in
this
area
as
well
or
it's
totally
unrelated.
A
In
this
group,
we've
had
a
history
of
telcos
showing
up,
but
the
I
have
to
say
that
the
bulk
of
the
conversations
are
not
telco
specific.
There
are
other
other
groups
out
there
that
pretty
much
all
the
audience
are
telco
interested
so
and
even
within
telcos.
I
think
you
mentioned
mac,
but
software-defined
radio,
there's
there's
so
many
niches
in
that
stuff
that
I
think
it's
even
somewhat
forked
in
terms
of
you
know
where
those
things
go.
A
If
you
wanted
to
find
that
out,
it's
not
under
the
cncf,
but
I
think
that
a
lot
of
that
telco
conversation
they
have
so
many
things
to
worry
about
that.
Certainly
things
going
on
in
this
group
are
relevant,
but
it's
by
no
means
telco
focused.
This
group
is
pretty
broad,
covering
kind
of
the
gener
general
things
that
everybody
needs.
I
would
say-
and
historically
it's
been
general
things-
everybody
needs
related
to
kubernetes,
but
when
we
move
it
over
to
cncf,
maybe
we'll
go
a
little
bit
broader
than
that.
A
The
kind
of
the
latest
cool
kid
talk
that's
been
leaking
into.
Our
group
is
web
assembly.
Where
there's
a
lot
of
talk
web
is
like
a
cool
technology
that
is
kind
of
a
something
container
like
like
docker,
but
smaller
packaging,
tighter
sandbox,
lower
startup,
latency,
less
variability
in
the
latency
and
cpu
agnostic,
and
that
kind
of
is
we
being
a
member
of
this
group
for
years
it
it
kind
of
transitions
into
cool
technologies
as
they're,
evolving
kind
of
at
a
general.
A
F
B
A
They
didn't
anticipate,
doing
firmware
patches
like,
like
I
mentioned
in
the
talk
once
you
can
run
a
binary
if
you
could
get
a
binary
to
run
at
a
command
line
to
do
a
firmware
patch,
I
don't
see
why
it
wouldn't
work,
although
if
it
triggered
an
immediate
reboot,
it
would
probably
halt
the
rest
of
the
script,
and
that
would
not
be
desirable
in
terms
of
going
at
the
management
interfaces
that
are
built
in
or
the
boot
process.
No
it
doesn't.
D
A
D
D
A
So
far,
you
know
we
started
out
being
under
the
kubernetes
project,
so
kind
of
at
a
higher
level
of
a
stack
than
firmware.
I've
got
nothing
against
people
coming
in
discussing
it,
but
I
suspect,
there's
better
homes
for
those
talks
than
our
group.
I
don't
know
what
those
would
be,
but
I
we've
got
plenty
of
people
who
have
that
problem.
E
A
D
A
At
this
point,
we're
past
time
so
we'll
break
kate
can
probably
hang
around.
I
have
another
talk
I
have
to
go
to,
so
I've
only
got
a
couple
minutes
if
you
want
to
say
hello
and
set
up
a
meeting
later,
I'm
willing
to
do
that.
But
thanks
for
coming,
it's
been
great.
Like
I
say
if
you
liked
it
start
coming
to
the
working
group
meetings.