►
From YouTube: Kubernetes WG IoT Edge 20200812
Description
August 12 2020 meeting of the Kubernetes IoT Edge Working Group - KubeEdge, IoFog and other topics discussed
A
A
With
that
said,
I
think
we
had
a
carryover
item
on
the
agenda
of
tina
talking
about
akraino,
but
she
isn't
here
yet
so
we'll
wait
to
see
what
happens
and
we
started
before
the
meeting
started
with
a
little
bit
of
sidebar
discussion
with
greg
about
the
concept
of
doing
using
kubernetes
he's
got
something
going
with
a
cloud-hosted
central
control
plane
trying
to
manage
things
out
at
edge.
Did
I
am
I
restating
that
right,
greg.
B
We
officially
started
that
yeah
we
have
a
yes,
an
independent
kubernetes,
well,
not
completely
independent,
but
a
central
kubernetes
cloud
in
the
kind
of
deployed
in
the
core
and
then
there's
edge
clouds
like
control,
plane
and
everything
that
are
much
smaller,
that
are
deployed
yeah
like
at
like
not
way
at
the
edge
but
kind
of
close
to
the
edge
for
yeah
providing
edge
functionality.
And
then,
in
theory,
what
we'd
like
to
move
to
is
to
be
able
to
also
have
those
you
know
near
edge
clouds
managing
you
know
far
edge
devices.
A
So
I
notice
yin
has
joined
the
call
and
he's
affiliated
with
the
cube
edge
project,
and
you
had
a
few
questions
about
it
before
the
meeting
started.
So
he's
actually
an
authority
on
that.
If
you
want
to,
if
you
have
any
questions
about
cube,
edge,
go
ahead
and
ask
him
because
I
think
if
he
might
be
driving
and
unable
to
talk,
but
he
might
be
able
to
answer
any
inquiries.
You
have.
B
A
B
C
B
C
C
So
in
the
cloud,
then
you
you
just
we
have
a
coupe
edge,
deploy
on
top
of
a
kubernetes.
So
basically
you
have
a
cloud
part
and
you
have
edge
parts
so,
instead
of
a
standard
kubelet,
so
we
modify
and
simplify
that
a
little
bit,
it's
called
add
core.
Then
you
use
edge
core
to
join
the
kubernetes
cluster,
our
edge
particle
cloud
core,
that's
basically
a
proxy
or
adapter
to
attract
or
process
all
your
requests
and
translate
to
the
standard
combination
api
to
call
api
server
register
on
the
etcd.
C
Basically,
from
the
user
point
of
view
is
standard.
Kubernetes
api,
you
just
use
the
cooper
control,
apply,
kuber
control,
deploy
or
kuber
control
logs
cooper
can
show
everything
we
just
support
standard.
Basically,
you
still
talk
to
the
api
server
and
so
nothing
changed
from
the
end
user.
For
the
operating
I
mean
devops
or
admin
of
combination
side.
What
your
view
is
a
standard
kubernetes
with
a
add-on.
A
Feel
so
bad
again,
because
I
sort
of
started
down
the
road
thinking
of
the
concept
of
cube
edge
being
a
distribution
myself.
So
maybe
the
documentation
isn't
super
clear
or
maybe
there's
old
stuff
out
there.
That
represents
it
wrong,
but
yeah
greg.
The
concept
is
that
you
get
some
kubernetes
distro
of
your
choice
and
then
you
can
layer
the
cubic
functionality
on
top
of
it.
So
that's
correct,
isn't
it
yet
yeah
you
choose
any.
C
A
C
C
C
C
C
B
A
No,
not
yet
okay,
but
well
wait.
Can
you
go
back
to
that,
drawing
so
below
that
red
dot
dashed
line
in
the
middle
of
the
slide
it
it's?
The
dividing
line
between
the
cloud
hosted
and
the
edge
hosted
so
below
the
line
at
the
edge.
You
do
have
a
container
runtime,
so
it
looks
like
it
does
run.
Containers
right.
A
C
C
B
C
B
C
B
Yeah,
actually
we
have.
We
have
two
embedded
os's.
We
have
one
that
is
like
a
carrier-grade
embedded
linux.
We
call
it
wind,
river,
linux
and,
and
it
it
can
run
kubernetes,
but
we
also
have
a
really
old.
Like
I
don't
know,
it
must
be
like
40
years
old,
embedded,
os
called
vxworks
and
it's
super
popular
and
like
it
still
makes
us
tons
of
money
and
and
yeah.
It
definitely
cannot
support
kubernetes.
A
So
again,
another
question
that
I
think
is
going
to
come
to
people's
minds
is
for
cube
edge.
There
are
going
to
be
some
edge
use
cases
where
you've
got
5,
000
or
way
more
than
5
000
nodes
out
at
edge,
and
I
believe
that's
the
upper
limit
on
of
you
know
how
many
cluster
nodes
you
can
have
in
a
kubernetes
deployment.
What
would
be
the
preferred
resolution
of
that?
If
you
had
to
deal
with
it.
A
C
B
Oh,
but
it's
okay,
so
it's
multiple
kubernetes
clusters
like
separate
control.
Planes
like
a
cluster,
is
a
separate
control,
plane,
masters
and
stuff,
but
it's
not
geographically
distributed.
It's
just
for
scalability
reasons
that
you're
using
multi-cluster
in
the
central
area.
There
that's
correct.
C
C
I
mean
architecture.
We
want
to
offload
all
this
to
the
central
cloud,
so
you
may
have
a
fat
kubernetes
cluster
deployment
in
your
central
cloud
to
solve
this
multi-cluster
problem.
But
I
don't
we
don't
want
to
do
this
because
we
we
thought
about
that,
but
we
think
you
need
to
synchronize
all
the
status
from
edge
to
volume.
Yeah.
C
B
C
Yeah,
that's
that's
yeah.
We
do
have
a
two
core
or
four
core
server
and
we
also
can
as
small
as
a
raspberry,
pi
or
even
smaller.
We
have
some
mips
lt
hubs.
They
deploy
our
edge.
So
does
we?
We
need
a
minimum
256
megabytes
to
deploy
containers
on
the
lg
device
edge,
but
if
you
only
have
1
28
megabytes
memory,
we
support
you
deploy
some
process
instead
of
containers.
B
C
B
Yeah
yeah,
okay,
okay,
I'm
just
kind
of
getting
the
the
ballpark
yeah.
That's
pretty
small,
because
because,
like
what
you
guys
were
describing
there
a
second
ago
was
basically
the
route
that
we've
gone
is
that
we
consider
our
edge
node
a
little
bigger.
So
we
actually
definitely
do
bigger
ones.
So
we
do
but
because
I
guess,
we've
taken
the
assumption
that
you
know
for
the
use
cases
that
we're
trying
to
address
the
edge
that
edge
node
will
be
bigger.
So
we
actually
deploy
our
multi-cluster
geographically.
C
B
Instead
of
centrally
like
yourself
but
like
I
say,
I
think
it's
probably
like
a
different
use
case
like
there's
some
use
cases
that
only
cube
edge
could
address
because
the
server
requirements
at
the
edge
are
so
small,
but
but
yeah
we.
So
we
do
the
multi-cluster
geographically,
but
I'm
kind
of
thinking
that
maybe
it
would
be
nice
to
have
an
option
to
kind
of
leverage
an
edge
node
as
well
as.
A
B
Yeah,
the
one,
the
one
that
the
smallest
one,
that
we
use,
because
some
of
the
our
customers,
all
of
their
edge
nodes,
are
single
server
clusters
like
master
and
worker,
know
it
all
on
one
server
and
we
use
the
I'm
not
sure
how
much
memory
it
has.
But
we
use
the
super
micros
that
have
the
single
socket
eight
core,
a
single
socket,
eight
core
dmd,
and
I
don't
know
how
much
memory
it
has,
though,
but
I'm
sure
it's
more
way
more
than
256
meg.
B
A
A
A
C
A
All
right,
yeah,
I
kind
of
think
the
trend
is
especially
if
you
look
at
I've,
never
heard
of
anybody
using
literally
cell
phones
as
a
platform.
But
you
look
at
cell
phones,
just
mid-range
ones,
and
how
many
cores,
how
much
ram
and
the
fact
that
they
do
often
have
gpus
and
they
should
be
refactorable
into
a
pretty
plausible
system
for
edge.
B
B
A
C
A
A
B
A
C
E
I
I
am,
and-
and
so-
and
I
was
just
I
was
just
thinking
so
if,
since
the
end
had
to
drop
off
if
greg,
if
you
want
to
continue
to
talk
about
hedge
architectures
here
we
can
switch
over
to
talk
about
eclipse,
io,
fog
and
and
compare
and
contrast
a
little
bit
if
that
helps
you.
But
if
there's
other
topics
that
people
want
to
have,
we
don't
have
to
hang
on
just
this
one
the
entire
time.
But
thank
you
steve.
I
am
feeling
better
and
I
was
just
overworked.
A
A
E
No
just
just
a
bit
because
you
guys
were
already
underway
when
I,
when
I
hopped
on,
but
I
saw
that
your
presentation
about
the
crds
and
honestly.
I
think
that
is
definitely
the
right
approach
and
steve.
You-
and
I
have
talked
about
this
kind
of
at
length
which
is
you
know.
Crds
is
the
the
right
mechanism
for
extending
kubernetes
to
be
aware
of
things
that
are
not
cubelets,
yeah
and,
and
so
that
so.
A
As
a
recap,
great
greg
started
saying
that
he's
affiliated
with
wind
river
and
that
he's
been
looking
or
actually
working
on
an
architecture
that
has
a
centralized
kubernetes
control
plane.
Trying
to
manage
devices
and
containerized
workloads
out
at
edge
locations
is
that
a
fair
representation
greg.
B
B
But
then
we'd
also
like
to
extend
and
yeah
I'm
kind
of
thinking
the
same
as
you
guys
send
through
you
know,
crds,
to
represent
devices
to
manage
yeah
devices
that
yeah
don't
have
a
cubelet,
and
you
know
you
need
to
talk
to
them
over.
You
know
various
iot
type
protocols
like
mqtt
and
that
sort
of
thing.
E
A
E
Okay,
thank
you
yeah.
I
don't
know,
I
don't
know
that
I'll
have
a
presentation
here
to
share,
although
if
you,
if
you
give
me
just
a
moment,
I
I
might
so
when
you
are
getting
out
to
the
edge
we've
already
mentioned,
you
know
this
kind
of
the
upper
limit.
Five
thousand,
you
know
five
thousand
nodes
being
where
you
start
to
think
that
you
know
this
is
known
to
break
down.
E
Well
before
that,
I
would
say
you
know:
5
000
devices
at
the
edge
needs
to
be
managed
a
bit
differently
already
you.
You
need
a
different
awareness
of
what's
going
on
there
and
how
those
devices
are
operating,
what
capabilities
and
stuff
they
have.
So
the
idea
of
eclipse,
io
fog
is
that
you
can
use
kubernetes
to
issue
the
commands
into
orchestrate,
but
it
has
a
different,
a
different
control
plane,
a
different
type
of
intelligence
for
working
with
the
edge
nodes
and
interpreting.
E
What's
going
on
there
and
that's
because,
for
example,
you
might
want
to
orchestrate
to
an
iot
gateway
that
has
an
intel
myriad
x.
You
know
ai
accelerator,
you
might
want
to
orchestrate
down
a
container
workload
that
is
different
than
an
iot
gateway.
That's
that's
basically
just
cpu
with
one
gig
of
ram
right
and
all
you
want
to
do.
E
There
is
put-
maybe
the
you
know,
a
protocol
adapter
or
something,
and
so
that
type
of
intelligence
about
what
the
edge
nodes
actually
can
do
and
what's
happening
with
all
of
them
that
that's
part
of
the
eclipse,
io
fog
project
and
then,
instead
of
a
full-blown
cubelet,
there's
a
specialized
edge
agent.
That's
called
io
fog
agent,
that
is,
is
very
lightweight
and
it's
it's
similar
in
in
weight
to
what
yin
was
describing
with
with
cube
edges
designed
to
be
on
devices
that
are,
you
know,
128
megs
of
ram
running.
E
You
know
a
simple,
simple
container.
You
know
on
things
that
have
a
couple
hundred
megs
of
ram
and
and
then
up
from
there.
Although
the
agent
pattern
is
suitable
for
implementation
in
in
anything,
including
microcontrollers,
that
just
have
firmware,
because
it's
a
communication
pattern
back
and
forth
and
then
the
agent
implements
what
needs
to
happen
on
the
edge
it
either
runs
the
containers
or
runs
the
serverless
functions
or
starts
the
starts.
The
python
script,
or
you
know,
call
us
the
library
whatever
it
is.
You
want
to.
E
This
is
not
in
contrast
to
the
concepts
of
bringing
kubernetes
to
the
edge
with
you,
know,
a
cluster
down
at
the
location,
but
it
is
in
contrast
in
terms
of
the
implementation,
just
assuming
that
it's
just
too
heavy
to
communicate
the
same
old
way
and
and
have
things
that
are
are
designed
for
the
edge
more
than
5000
nodes
is
not
a
problem
right.
So
it's
you
know,
tens
of
thousands
of
devices
is
what's
expected
because
the
the
communication
is
very
lightweight.
E
Yes,
some
form
of
of
io
fog
agent
on
the
device
is
a
requirement,
and
then
you
choose
the
the
run
time
that
you
want
for
like
containers
or
whatnot,
and
then
everything
that
you
have
all
of
the
ifog
agents
and
so
on.
They're
all
infrastructure
is
code,
so
you
can
kind
of
roll
on
and
off
edge
nodes,
etc.
B
E
Generally,
the
agent
usually
installs
on
top
of
things,
and
so
generally
it
is
the
the
end
user
of
a
device
that
that
wants
to
run
io
fog
and
put
it
on
their.
You
know
super
micro,
iot
gateway
or
their
raspberry,
pi
or
whatever.
Well,
the
nice
thing
here
is
that,
oh,
you
know
what
I
just
realized.
What
you
were
probably
asking.
E
That's
right,
yeah,
so
here
let
me
share
my
screen
and
see
what
I
I've
got
here:
frederick
you're
probably
going
to
laugh,
because
this
is
just
the
one
that
I
just
sent.
You
is
what
I
have
handy
world
this
week.
I
would,
I
would
never
dream
of
fluffing
it
at
you
anyway.
We
can
see
it.
Okay,
great
so
yeah,
let's
see
here
there's
this
is
probably
the
best
place
to
start
here.
So
it's
it's
our
it's
our
belief
and
our
meaning
mind
from
2014
and
sticking
with
it
that
there
is.
E
E
They
should
probably
stick
with
their
firmware
or
whatever
it
is
that
they're
they're
running,
maybe
they're,
rtos
and
and
everything
at
that
line
and
below
is
leave
it
as
it
is,
don't
make
changes
to
the
device,
let
it
speak,
the
protocol
it
speaks,
etc,
and
so
how
on
earth
do
you
integrate?
It
then
well
an
edge
compute
node
such
as
an
iot
gateway,
is
a
perfect
place
to
be
running.
E
They
can
be
very
lightweight
but
running
edge
processes
that
are
intended
to
do
the
interfacing
with
things
that
already
speak
their
own
language-
and
this
is
inspired
by
you-
know
the
some
of
the
the
industrial
iot
challenges
that
that
you
know.
We
all
know
when
you
step
outside
of
a
certain
you
know
protocol
if
everything's
opc
way
and
compliant.
You
know
it's
generally
good
and
then
and
then
there's
that
device.
That's
a
40.
E
You
know
40-year
running
device
that
everyone
still
uses,
because
it's
great
and
it
kind
of
has
its
own
bite
order
and
or
you
query
its
modbus
registers
and
you
can't
make
sense
of
it
fast
enough
up
in
the
cloud.
You've
got
to
take
some
action
at
the
edge
and
parse
those
bytes
and
do
something
with
it,
and
so,
in
my
view,
edge
computing.
A
big
part
of
edge
computing
is
moving
critical
processing,
that's
low,
latency,
etc.
E
Right
to
where
the
device
is
to
speak
its
native
language,
such
that
you
can
represent
it
upstream,
you
can
make
a
digital
twin
and
the
cloud
you
can
do
all
that
stuff,
but
something
has
to
talk
to
the
thing.
Otherwise,
everything
has
to
be
green
field
and
from
vendors
that
want
your.
You
know
your
agent
or
your
interface
or
speaker
protocol
perfectly.
E
That's
not
how
that's
not
how
the
bluetooth
sig
has
defined
it,
but
that's
what
I'm
getting,
and
so
how
do
I
deal
with
this
right
when
it
doesn't
work
in
the
app
anymore?
Now
you
need
something
at
the
edge
to
interface
and
interpret.
So
this
is
a
diagram
of
kind
of
like
a
little
bit
outdated
at
this
point
of
what
the
agent
does
and
how
it
you
know,
provides
stuff
on
the
edge
node
that
you
can
then
come
to
rely
on
upstream
from
here.
I
think
I've
got
this
in
something
like
there.
E
We
go
upstream
from
here.
This
is
a
really
outdated
diagram.
Is
you
can
use
kubernetes
to
do
the
orchestration,
but
it
will
go
through
the
ifall
control
plane
and
out
to
the
edge
nodes
as
as
in
a
very
edge
fashion,
and
then
the
stuff
that
you've
orchestrated
will
get
executed,
but
with
an
extra
layer
of
intelligence.
E
What
we're
still
working
to
do
and
and
trying
to
figure
the
right
way
to
do
it
and
gather
some
more
help
around
it
is,
is
really
leveraged.
Crds
in
from
kubernetes
such
that
and
an
io
fog
edge
is
not
even
about
extending
the
kubernetes
cluster.
It's
really
about
plugging
in
an
edge
that
can
be
managed
centrally.
E
So
you
don't
worry
so
much
about
what
resources
allow
you
to
run
kubernetes
at
the
edge
it's
rather
kubernetes
stays
recruitment
was
designed
to
stay
and
the
edge
is
an
edge
and
it
plugs
in
so
that
it's
completely
visible.
We
have
lightweight
version
of
this
today
with
eclipse
io
fog
that
you
can
plug
in
with
kubernetes.
It
doesn't
matter
which
just
throw
commercial
or
whatever,
and
but
we're
really
trying
to
figure
out
an
architecture
that
when,
when
you
look
at
it,
you
say
that
basically
can
fit
everything
I'd
ever
want
to
fit.
E
You've
mentioned,
you've
asked
greg,
ajax,
foundry
or,
or
you
know,
mqtt,
or
what?
What
do
you
have
going
on
at
the
edge?
And
I
think
the
answer
should
be
whatever
it
is.
You
pick
in
fact,
with
the
io
fog
control
plane,
it
can
be
whatever
we
automatically
deploy
upon
sensing
devices
that
register
you
know
as
a
certain
device.
That
speaks
a
certain
protocol.
E
So
if
you're,
you
know
looking
for
something
with
a
bluetooth,
low
energy,
we
can
we
automatically
deploy
an
interface
layer
for
that
we
can
deploy
the
mosquito
mqtt
broker
when
we
detect
the
devices
that
need
it.
But
then
what
if
you're
wanting
to
work
with
edgex
foundry
great
put
those
microservices
down
as
your
interface
and
then
what?
If
it's
something
custom
or
you
know
just
opc
ua
and
you
just
wanna,
you
know-
have
one
adapter
for
that
and
skip
all
the
rest.
That's
all
of
this
stuff
is
is
a
fit.
E
E
Yes
sure
sure
so
scupper
was
designed
to
move
arbitrary
traffic
safely
securely
and
dynamically
from
one
environment
to
another,
such
that,
if
you
had
whether
kubernetes
controlled
or
not.
If
you
had
a
cloud
environment
on
public
cloud
and
then
you
had
a
private
cloud
and
maybe
even
a
private
data
center
environment-
and
you
wanted
to
move
data
between
points
in
there.
But
you
wanted
those
points
to
be
registered
in
something
like
what
you
would
call
kind
of
a
central,
dynamic,
endpoint
registry.
E
This
would
be
normally
tricky
or
you
would
need
all
traffic
to
be
like
pub
sub
and
going
through
some
cloud
endpoint
or
whatever
one
of
my
favorite
protocols.
That's
really
undervalued
is
amqp
1.0,
not
talking
about
0.9,
I'm
talking
about
1.0,
the
kind
of
the
full
full
vision
amqp,
which
is
a
very
different
protocol
than
the
0.9.
That's
been
beat
up
all
these
years.
1.0.
E
I
was
like
okay
hands
down
best
thing.
I've
seen
great,
let's
replace
io
fog's
lighter
weight
version
of
this
which
it
had
for
years
with
with
scupper,
so
we
just
finished
doing
that
with
iphone
2.0,
which
is
which
is
now
generally
available,
and
so
what
that
gives?
You
is,
if
you
have
an
edge
location
such
as
a
cellular,
backhaul
driven
oil
field,
and
you
want
to
talk
to
those
iot
gateways
and
deploy
container
workloads.
E
Then
they
talk
over
that
cellular
back
call
to
the
iphone
control
plane
cool,
that's
easy
to
do,
but
because
of
the
way
that
fog
agent
was
was
built.
But
what,
if
you
want
to
move
the
actual
data
from
one
of
the
the
pumps
to
another
field
which
about
you
know
200,
kilometers
away
where
you
want
to
do
some
more
aggregate
processing?
You
don't
really
want
to
bounce
that
around
the
cloud
you'd
like
to
move
it
laterally,
and
so
it
definitely
wanted
to
be
secure.
E
So
this
layer,
7
network,
that
that
was
created
by
red
hat
come
you
can
use
it
separately,
but
it
comes
built
in
without
fog.
Now
you
can
just
assign
a
data
route
between
the
endpoints
that
you
want
to
share
data.
It
will
traverse
using
the
cellular
back
call.
It
will
traverse
the
the
internet
from
point
to
point,
but
it
is
logically
a
direct
peer-to-peer
connection
right.
Just
like
all
of
our
peer-to-peer.
E
You
know:
data
sharing
and
stuff
right,
traverses
the
internet,
but
it's
logically
one
point
to
another,
and
you
use
this
for
moving
data
all
around
the
edge,
but
you
also
move
it
use
it
from
moving
data
from
the
edge
to
the
cloud
and
from
the
cloud
back
down
it's
another
architectural
vision
of
mine
never
have
any
open
ports
at
the
edge.
Never
have
a
field
that
you
know
has
some
network
ports
open
for
you
to
attach
to
it.
E
E
You
know,
managed
at
a
much
higher
level
and
so
that
layer
seven's
perfect,
because
you
really
can
treat
them
as
part
of
an
application
and
so
in
this
diagram
here,
using
kind
of
it's
a
little
bit
like
market
texture
right
like
here's,
the
different
edge
environments
you
can
have,
but
the
basic
idea
is
that
the
data
flow
is
where
you
want
it
to
flow
and
the
control
signals
flow,
of
course,
up
to
the
the
outflow
control
plane.
You
put
that
control
plane
whatever,
so
you
can
keep
it
at
the
edge.
E
You
can
put
it
in
a
data
center.
You
can
put
it.
You
know
on
wan.
You
can
put
it
on
the
public
internet
public
cloud.
A
lot
of
people
do
that,
just
because
it's
easy
and
and
one
and
done,
but
I've
set
a
mouthful
and
just
want
you
to
know
that
there
are
ways
to
do
the
edge
that
that
you
don't
have
to
think
in
terms
of
federating
kubernetes
clusters.
But
rather
things
designed,
you
know,
as
we
call
edge
native.
A
Can
I
ask
you
to
fill
in
a
little
bit
more
detail
on
the
concept
of
using
scupper
here?
Does
this
take
on
the
you
know,
joining
protocols
from
one
physical
location
to
another?
I
gather
is
a
a
key
element
it
delivers,
but
does
it
attempt
to
dig
into
what's
going
on
over
the
protocol
and
also
put
up
a
layer
of
cataloging
of
what
that
data
is
and
means.
E
Or
it
does
not,
it
just
carries
the
traffic,
so
you
could
carry
like
streaming,
video
or
mqtt.
What
you're,
probably
talking
about
steve,
is
more
like
eclipse
hanno,
which
is
meant
to
be
managed.
Iot
data
streams,
in
which
you
have
an
understanding
of
you,
know,
hey
the
protocol
adapter
here
for
mqtt
is,
is
receiving
a
device
has
registered
and
it
is
authorized
so
now
I
understand
the
mqtt
data
stream,
frederick,
you've
unmuted.
Would
you
like
to
help.
A
E
That's
right,
yeah!
You
want
some
management
over
the
data
streams,
especially
for
devices
that
are
not
that
smart,
because
something's
got
to
add
the
the
understanding,
the
management
layer,
yep.
That's
we
are
working
on
a
grand
unified
architecture
with
all
of
the
folks.
At
the
eclipse
engineer,
working
group
and
the
integration
of
a
kliptano
with
io
fog
would
mean
it's
not
that
the
projects
then
only
work
together.
It's
rather
that
they
can
be
deployed
together
with
some
config
that
allows
them
to
already
stand
up,
but
freder.
E
F
A
F
But
yeah
I
I'm
certainly
excited
about
what
kilton
just
described.
You
know
at
the
end
of
his
of
his
intervention
about
the
potential
integration
between
io
fog
and
eclipse.
Oh,
no
because
oh
no
in
the
eclipse,
iot
portfolio
is
really
our
what
I
would
describe
as
our
message
routing
platform.
So
that's
a
highly
scalable
component
that
supports
multiple
protocol
inbound
and
then
we
transfer
everything
to
amqp
in
you
know
in
in
the
in
the
inside
network,
and
it's
already
been
proven
in
the
commercial
bush
iot
suite.
F
E
Yeah,
the
eclipse
honor
does
yeah,
it's
managed,
it's
managed
message,
streams
and
and
protocol
data
streams.
Yep
you
have
to
even
to
join
it.
You
have
to
have
some
some
authentication
process
for,
even
even
like
kind
of
like
dumb
devices
that
just
talk
mqtt
so
and
then
on
the
other
side,
the
access
to
it
is
is
restricted
controlled
as
well.
E
E
Oh
yeah,
absolutely
I
mean
it's
and
we're
enhancing
all
the
time
the
different.
What
we
call
security
plug-ins
that
you
can
use
to
address
different
concerns,
monitoring
the
network.
So
ie,
like
you,
know,
talking
to
the
the
the
I
o
fog,
compute,
node
and
watching
its
in
and
out
traffic,
that
that
is
something
that
you
can
add
in
such
that
the
agent
takes
responsibility
for
watching
itself
and
the
the
plugins
are
are
signed.
E
That
doesn't
mean
that
you
know
there's
not
ways
to
hack
right,
we're
working
on
that,
but
things
like
changing
the
file
system,
overloading
it's
its
network,
we're
passing
too
much
traffic
through
it.
All
of
these
things
abusing
its
apis,
cause
it
to
go
into
quarantine,
quarantine,
disconnects
it
from
the
virtual
application
network.
It
it
goes
into
a
different
state
where
it's
its
workloads
are
paused.
You
can
specify
that
they
get
shut
down
or
wiped,
but
the
most
important
thing
is:
it
stops
passing
traffic
around
and
send
some
signals.
E
This
is
going
to
be
a
work
in
progress
for
the
next
10
years
right
in
the
way
that
we
address
all
of
these
edge
security
concerns.
But
the
start
of
it
is
things
like
that,
so
cool
greg,
it
looks
like
you've
got
to
go.
Thank
you,
for
I
hope
this
has
been
a
good
brain
dump
from
several
sources
from
yin
and
regarding
cube
edge,
yeah.
A
Once
again,
this
was
sort
of
an
unplanned
one.
The
agenda
said:
we'd
do
a
crano
which
we
never
got
to,
but
I
think
it's
been
a
useful
meeting.
Nonetheless,
I'm
going
to
time
box
this
we've
got
two
minutes
left.
So
if
anybody's
got
any
final
things
they
want
to
throw
on
the
agenda,
please
step
in
right
now.
A
E
Okay
will
do
it
might
be
a
good
thing
to
actually
present
what
at
edgeworks
we've
been
building
with
eclipse
iphone,
which
very
widespread
edge,
ai,
smart
camera
stuff
all
on
the
same
principles
we've
been
talking
about.
Are
you
volunteering
to
do
this?
If
so
I
I
am,
but
maybe
maybe
maybe
next
time,
but
if
not
the
time
after
I'm
volunteering
to
do
it
soon.
Okay,.
F
E
A
Nice,
okay
with
that
said,
I'm
going
to
call
this
meeting
to
a
close
thanks
for
attending
and
we'll
see
you
at
the
next
one
on
the
europe
apec
time
cycle
in
a
couple
of
weeks.
Oh
also,
we
do
have
a
session
at
the
virtual
kubecon
europe
there's
paid
registration
for
that,
but
I
think
that
this
group
has
a
talk
and
there
may
be
other
things
on
the
agenda
for
the
kubecon
as
well,
so
check
that
out
bye.
Everybody.