►
From YouTube: CNCF TOC Project Presentation Meeting - 2019-03-12
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
A
A
Cool,
so
you
know
this
meeting
is
kind
of
her
first
kind
of
experiment
in
you
know
getting
through
the
backlog
of
project
presentations
and
proposals
that
we
have
in
kind
of
presenting
some
of
these
projects
to
the
TOC
and
wider
communities.
So
we
could
either
you
know,
accept
them
or
give
them
feedback
on
the
projects.
So
we
have
three
presentations.
Today
we
have
Creole,
Brigade
and
and
cube
edge,
all
applying
for
different
levels.
A
B
So
I
think
this
is
kind
of
well
there's
a
little
bit
of
president
of
things
coming
out
of
the
kubernetes
incubator,
it's
kind
of
an
odd
transition,
because
it's
already
been
in
a
incubator
for
some
time
and
used
in
production
by
not
only
companies,
but
also
projects
are
around
routing
around
it.
It's
been
in
its
it's
been
a
one-day,
unstable
and
tracking
with
communities
for
quite
a
long,
so
it
as
far
as
container
runtimes
go.
This
is
a
bit
more
of
a
pared
down
container
runtime
part
of
just
intrinsics
truck
infrastructure
underneath
kubernetes.
B
It
does
not
purport
to
make
additional
use
cases
and
accommodate
a
variety
of
different
interfaces,
and
otherwise
it's
really
a
very
tailored
and
infrastructure
to
kubernetes
itself,
and
with
that
you'll
see
the
releases
marching
cadence
along
with
kubernetes,
but
as
far
as
an
active
and
diverse
as
far
as
maintainer
and
adopters
and
contributors,
it's
a
very
lively
project.
So
it's
in
our
in
our
eyes,
it's
largely
needing
to
move
more
from
the
criminales
incubator
piece
into
a
sustained
project
itself
to
be
seen
seen
and
used
accordingly.
B
C
Under
the
next
slide,
I
have
added
an
architecture
diagram,
so
I
can
briefly
talk
to
this
there's
a
view
of
the
node
with
cryo
is
a
runtime.
You
have
the
cubelet
on
the
left,
talking
GRP
CCRI
API,
to
cry
on
the
right
and
for
implementing
the
two
services
we
have
these
libraries
called
containers,
image
and
container
storage
containers.
Image
is
something
which
is
specialized
in
moving
images
across
different
registries
and
formats.
C
Berettas
then
another
thing
is
for
networking
we
use
CNI,
so
any
CNI
compatible
plug-in
can
just
we
plugged
in
it
should
just
work
without
any
issues
and
at
the
bottom
you
see
the
container
storage
library.
So
that's
where
we
have
drivers
for
overlay
device
mapper
and
recently
we
are
working
on
a
new
LVM
driver
which
takes
away
pain
from
device
map.
I.
Think
it's
very
important
for
the
VM
based
container
runtimes
Sam.
Do
you
want
to
add
anything
about
the
cada
integration?
C
D
This
was
really
our
vehicle
into
you
into
communities
and
that
you
know
I
was
saying
that
really
led
to
the
current
runtime
class
work.
That's
being
done
at
the
signal
and
yeah
this.
This
was
a
really
nice
enabling
vehicle
for
for
quatre
containers
and
in
a
more
general
way,
for
really
integrating
virtual
machine
into
communities
as
a
first-class
citizen
and
being
able
to
expand
the
notion
of
runtime
to
to
a
much
more
generic
concept.
C
C
A
You're
happy
to
speak
more
like
we
could
open
up
to
questions.
You
know
I
linked
to
dev
stats
out
there
to
essentially
show
some
statistics
about.
You
know
Korean
and
kind
of
real-time,
but
as
I
understand
it
you're
requesting
a
proposal
for
essentially
toc
member
to
sponsor
a
vote
for
for
incubation
as
I
understand
it.
Correct.
A
E
Is
there
a
possibility
to
break
that
link,
or
is
it
even
feasible
to
break
that
link
so
that
one
of
the
reasons
for
asking
this
question
is
we
we
are
talking
about
in
the
signal
we
were
talking
about?
How
do
we
get
off
of
the
depends
dependency
that
we
have
on
docker
in
cubelet,
that's
baked
into
cubelet,
so
this
discussion
here
might
help
that.
Also
that's
why
I'm
asking
that
question
so.
B
C
Mean
like
we
are
using
the
CRI
API
and
the
tsuba
docker
was
the
docker
code
has
been
has
been
contributed.
I
mean
the
docker
integration
code
has
been
contributed
to
the
kubernetes
repo
itself
and
it
was
the
one
that
the
project
started
with,
and
so
there
might
be
some
assumptions
there
and
some
tight
coupling,
which
makes
it
hard
to
decouple,
but
in
case
of
the
new
CRI
Bay's
runtimes,
we
are
just.
C
B
What
do
you
mean
moving
the
G
RPC
stuff
out
so
somewhere
else?
Yes,
that's
that's
neither
here
nor
there
I
mean
if,
if
it's
moved
into
a
kubernetes,
PKG
or
you
know
whatever
kubernetes
CRI
api,
that
is
a
sub
module
that
commands
importance
and
cryo
importance
and
container
D
imports.
That's
that's!
After
the
after
the
fact
that
the
important
thing
just
is
really
it's
not
it
attached
at
the
hip
that
you
reference
is
part
of
why
the
CRI
was
invented
in
the
CRI.
The
kubernetes
exports
is
already
the
decoupled
implementation
of
that.
B
A
Think
we
have
time
for
maybe
one
or
one
more
question
otherwise,
we'll
we'll
move
on
to
the
next
presentation.
A
All
right,
we'll
send
a
you
know
afterwards.
You
know
with
this
presentation
and
get
some
feedback
from
the
community
via
the
mailing
list
and
see
if
there's
any
TOC
members
members
interested
in
pushing
this
for
vote.
Okay,
so
up
next,
we
have
Brigade
that
is
interested
in
in
the
sandbox
and
have
issued
a
thinker
proposal
this
morning
and
they're
gonna
present
today.
So
I
think
Michelle
is
on
the
line.
A
F
You
Ari:
this
is
everyone
good
with
this
yeah.
A
F
Thank
you
so
much
for
giving
us
time
here
today
to
present
and
brigade
I'm
michelle,
neroli
and
presenting
with
me
is
readiness
hi.
If
anybody
has
anything
in
chat,
I'll
check
it
at
the
end,
so
Brigade
is
enables
event-driven
scripting
for
kubernetes.
It's
a
lightweight
framework
built
with
kubernetes
native
objects.
Essentially
it's
an
in
cluster
runtime
that
interprets
and
execute
scripts
so
that
users
can
chain
together
containers
to
create
high-level
workflows
using
kubernetes.
F
So,
as
you
can
see,
this
is
here
we're
defining
like
a
job
and
that
job
contains
exactly
one
task,
and
so
its
task
is
to
run
the
test
on
github
push
event,
and
this
is
a
simple
example,
but
you
can
actually
create
multiple
tests
or
tasks
inside
of
a
single
job
and
you
can
define
multiple
jobs
inside
of
a
single
script
and
because
this
is
JavaScript,
you
can
use
promise
objects.
You
can
change
two
jobs
together
to
run
one
after
another
or
you
can
run
them
in
parallel
and
you
can
even
use
things
like
try.
F
Catch
blocks
to
deal
with
error
handling,
so
in
just
a
few
lines,
these
scripts
become
incredibly
powerful
and
robust.
We
chose
JavaScript
because
it
already
has
a
rich
ecosystem
of
tools.
It's
also
the
number
one
scripting
language
on
the
or
was
the
number
one
scripting
language
at
the
time
on
the
Red,
Bank
ranking
and
the
tayo
be
index,
and
you
can
leverage
any
existing
JavaScript
package
in
the
brigade
scripts
that
you
write.
F
We
often
refer
to
brigade
as
unix
shell
scripting,
but
for
kubernetes,
and
so
a
UNIX
shell
scripts
defines
the
workflow
around
executing
one
or
more
lower
level
system
executables.
Similarly,
a
brigade
script
defines
a
workflow
for
executing
multiple
containers
within
a
cluster
I'm
gonna
hand.
It
off
to
my
colleague
ready
to
explain
the
high-level
architecture
ready
to
take
it
away
right.
Yeah
thanks
well,.
A
F
So
there
are
several
different
use.
Cases
for
a
brigade
see
ICD
is
like
the
first
and
easiest
use
case
that
like
comes
to
mind,
but
we've
been
really
pleased
to
see
lots
of
different
Brigade
being
used
in
lots
of
different
ways.
For
example,
one
company
uses
Brigade
to
do
a
bunch
of
meta
testing
on
various
code
bases
at
regular
intervals,
so
they'll
run
language-specific
winters
do
code,
quality
assessments
and
some
security
scanning
and
then
they'll
notify
automatically
the
right
teams
if
they
like
find
something
that
needs
to
be
looked
at.
F
Another
company
uses
Brigade
to
build
weekly
roll
up
reports
by
aggregating
and
analyzing
data
from
lots
of
different
data
sources.
Another
company
uses
Brigade
to
process
image
data
and
the
last
one
that
I
have
listed
here
is
something
that,
like
the
whole
team,
has
been
so
excited
to
see.
There's
a
one
group
of
people
who
are
using
Brigade
to
spin
up
preview
environments
for
every
pull
requests
or
on-demand,
giving
developers
this
like
up-to-date
environment
to
do
experiment,
experimentation
and
testing
on
there's
a
blog
post
that
I
linked
in
the
proposal.
F
It
looks
like
really
interesting
this
this
use
case.
So
if
you
want
to
learn
more
about,
it
feel
free
to
check
out
the
pull
request.
We've
also
seen
several
different
projects
being
builds
around
Brigade,
so
we
have
a
related
project
section
in
the
repo
and
it
lists
a
bunch
of
a
bunch
of
projects.
There
is
someone
from
charter,
for
example,
who
built
the
gateways
for
a
bit
bucket
and
get
lab
kocchi
as
a
dashboard
that
was
built
alongside
brigade
core,
to
view
your
Brigade
pipelines
and
there's
just
several
others
that
you
can
check
out
ready.
G
Sure
so
we're
very
close
to
releasing
your
1.0.
We
hope
that
somewhere
around
this
week,
we'll
be
able
to
tag
Oh
together
with
the
one
point,
though,
working
towards
one
point
else:
we've
been
having
regular
weekly
community
meetings
that,
and
we
distributed
a
specific
community
in
the
brigade,
Renee
DS,
slack
Channel.
We
have
a
project
work,
that's
up
to
date
and
we're
tracking
work
items
and
that's
well.
We
have
the
entire
CI
4
Brigade,
built
with
we
gate
and
we're
dog
footing
latest
release
every
time.
G
As
for
the
road
map
from
now
to
somewhere
around
May,
we
we
plan
for
a
stability
period
for
non
and
non
breaking
changes
for
the
brigade
core.
At
the
same
time,
we
want
to
split
out
the
repo
and
have
separate
vehicles
and
release
cycles
for
the
gateways
and
other
projects
that
are
in
the
other
people.
At
the
same
time,
we
want
to
migrate
all
the
projects
to
Brigade
or
github
organization,
together
with
multiple
community
projects.
F
Awesome,
thank
you,
and
do
you
want
to
access
a
little
bit
about
what
we're
doing
and
within
the
cloud
Native
community
sure.
G
G
We
also
have
integrations
with
cloud
events,
which
is
a
CN
CF
project
for
defining
events,
team
us
and
we
actually
ship
a
cloud
events
gateway
with
Brigade
that
can
handle
crowd
events,
schemas
and
also
with
virtual
earth,
which
is
also
a
CN
CF
project
that
allows
us
to
schedule
Brigade
jobs
on
top
of
virtual
nodes,
so
that
you
don't
have
to
provision
infrastructure
for
your
bills.
As
you
can
imagine
this,
can
this
can
spin
up
endless
scenarios
very
in
half
serverless
pipelines
built
on
top
of
brigade
and
a
virtual
key
wet
I.
F
Thank
you
ready,
I
mean
sorry
last
night.
As
about
why
CMC
yeah,
we
think
that
this
is
gonna
be
a
really
great
home
for
us
in
terms
of
having
a
vendor
neutral,
IP
space
to
foster
collaboration.
F
We've
seen
a
number
of
end-user
companies
become
interested
in
brocade,
and
we
really
hope
to
get
time
with
the
end
user
community
in
the
CN
CF
at
large
to
get
some
feedback
and
just
present
what
we
have
and
see
if
they
have
any
any
additions
or
anything
for
us
to
to
look
at
we're
already
leveraging
existing
cloud
native
projects,
like
Friday
mentioned,
with
the
integrations
with
cloud
events
and
virtual
couplet
excu
bronies
native,
it
runs
in
kubernetes.
It
uses
home
charts
for
packaging
and
deployment.
F
So
we
have
kind
of
already
really
set
up
with
the
cloud
native
space,
and
we
want
to
continue
to
talk
about
interoperability
with
other
cloud
native
projects
and
integrations
and
getting
that
feedback
from
this
community
so
I'll
hand
it
back
over
to
Taylor
at
this
time
and
I'm
happy
to
take
questions.
Yeah.
A
G
Specifically,
we've
been
working
with
the
community
for
the
last
month
or
so
in
adding
arm
support
for
Brigade,
which
essentially
means
that,
as
long
as
you're
able
to
join
an
arm
note
to
your
kubernetes
cluster,
then
yes,
you
can
run
jobs.
You
can
run
Brigade
jobs.
On
top
of
that
note,
there's
there's
options
when
running
the
brigade
script,
where
you
can
pin
points
to
a
specific
subset
of
nodes
or
things
when
running
when
defining
the
job.
So
yes
it
could.
It
could
help
with
that.
Oh
soon,
thank
you.
I
Hello,
hi,
hello,
hey,
so
the
question
about
the
event
model,
so
you
folks
supporting
complex
event
model
such
as
you
know,
one-to-many,
and
you
know
the
or
is
that,
like
pretty
simplistic,
you
know
stringing
running,
you
know
job
sequentially!
Are
you?
What
do
you
have
plans
to
support
that
as
well?
So.
G
At
this
point,
one
Brigade
project
can
respond
to
one
event.
That
being
said
when,
when
the
event
is
handled,
you
can
spin
off
multiple
jobs
and
you
can
chain
them.
However,
you
want,
you
can
run
them
sequentially,
you
can
run
them
in
parallel.
You
can
get
him
essentially.
The
JavaScript
API
is
flexible
enough
to
allow
you
to
spin
up
jobs
in
any
way.
You
like.
I
Well,
I
think
my
question
was:
can
I
do
like
in
typical?
You
know
the
the
flow
you
know,
Process
Management
I.
Remember
we
used
to
have
people
who
stuff,
so
you
can
do
folks
and
join
then
those
kind
of
thing
do
you
have
plans
to
do
those
kind
of
thing
complex.
You
know
event
patterns
right
now.
We
don't.
J
J
G
A
great
question
we
actually
have
a
proposal
for
allowing
sidecars
engage
opting
in
the
pod.
We
decided
to
do
this
out
of
1.0,
mainly
because
of
the
lifecycle
and
fall
lifetime,
implication
that
would
have
and
we're
actively
working
with
the
community
to
understand
what
would
be
the
best
default
for
the
lifetime
of
the
pod
in
that
scenario,
but
yes,
we
will
definitely
want
to
support
sidecars
and
multiple
containers
in
pods.
Okay,.
J
A
Cool,
alright,
any
other
one
more
question.
Otherwise
we
will
move
on
to
the
next
one.
There's
a
proposal,
a
link
that
has
to
TSU
sponsors
already
I,
think
we'll
leave
it
open,
probably
for
another
day
or
two
to
get
a
little
bit
more
feedback
from
the
community
before
otherwise,
it's
already
not
the
freely
minimum
requirements
we
have
for
the
sandbox,
so
I
will
now
close
it
off
and
hand
it
off
to
the
next
speaker.
So
thank
you,
Michelle
and
rod
for
for
your
time.
A
A
K
K
Cooperage
is
a
kubernetes,
extended
infrastructure
for
IOT
and
edge
computing.
This
the
the
control
plant
cloud
worker
notes
attached
cooperage,
enables
orchestration
of
native
continued
applications
from
cloud
to
edge.
It
has
been
proven
to
be
valuable
to
real
customers.
The
uniqueness
of
courage
lies
in
the
following.
First
of
all,
the
agent
cloud
are
loosely
code
where
the
edge
site
can
autonomously
working
and
in
sync
with
the
cloud
kibosh
supports.
Bidirectional
multiplexed
network
communication
between
cloud
and
edge.
The
agent
running
on
the
edge
side
consumes
about
a
10
megabyte
memory
at
runtime.
K
The
architecture
is
based
on.
Kubernetes
is
highly
extensible
and
pluggable
one
basically
run
a
communities
cluster
cluster
from
the
cloud
without
knowing
where
the
edge
node
is
located.
Next
slide,
please,
before
we
drill
down
to
the
cooperage
architecture,
I
like
to
like
us
to
walk
through
some
of
the
edge
computing
use
use
cases
on
this
page.
You
can
see
two
pictures
which
are
read
very
relevant
to
our
daily
lives.
Think
about
often
times
we
have
to
make
go
into
a
parking
lot.
K
K
This
use
case
is
about
a
water
tank
system.
As
you
can
see,
there
are
three
water
tanks
geo-located
at
different
locations
on
each
water
tank.
There
are
sensors,
loves
controllers
and
through
the
communication
between,
among
all
the
controllers,
the
water
level
in
each
tank
and
the
pipeline
can
be
stabilized
and
balanced.
So
it
is
a
decentralized
architecture
without
the
edge
node
talking
to
the
cloud.
So
we
can
move
to
the
next
slide,
as
you
can
see,
and
similar
edge
computing
use
cases
here
is
our
view
of
edge
computing.
K
The
resources
and
devices
are
located
on
edge,
but
they
are
managed
from
the
cloud
applications
or
surveillance
functions.
They
run
an
edge,
but
we
won't
deploy
or
orchestrate
from
the
cloud,
as
you
can
see.
Essentially,
edges
are
extension
of
a
cloud
we
want
to
have
the
bi-directional
network
communication
between
edge
and
cloud,
but
the
come.
The
network
connection
between
a
junk
cloud
may
not
be
reliable,
and
then
the
class
ID
in
our
Comment
can
be
limited.
Think
about
the
edge
nodes
can
be
large
scale
as
well.
Based
on
that,
we
want
the
edge.
K
Node
can
have
some
autonomy,
so
business
can
run
on
the
edge
side,
local,
quick
and
reliable
and
then
plus
the
edge
nodes
can
be
decentralized
so
that
they
can
aware
each
other
communicate
with
each
other.
The
other
thing
is
about
the
heat
old
genius
uniqueness
of
the
edge
nodes
from
hardware
perspective.
It
can
be
a
Raspberry
Pi
or
a
server
machine,
and
then
it
also
like
from
the
IOT
device
to
the
edge
side.
The
protocols
in
between
can
be
very
diversified
and
the
scale
of
the
alt
devices
can
be
quite
different
as
well.
K
K
So
there
are
some
main
components:
let's
talk
about
the
action
edge
node
aside
as
a
mention
there
is
a
single
process.
The
HD
is
basically
a
very
light
weight
of
couplet
for
the
IOT
edge
computing
and
then
the
edge
carbon
cloud
hub.
They
use
WebSocket
to
build
the
bi-directional
command
our
communication.
Through
the
same
the
single
lung
connection,
the
data
all
kinds
of
data
can
be
communicated
and
then
the
edge
controller
basically
is
kubernetes,
extended
controller.
K
Eight
convert
all
the
parts
of
refer
all
the
relevant
part
know
the
information
and
convert
it
so
that
only
earth
the
targeted
metadata
will
be
communicated
to
a
specific
edge
edge
node,
and
then
you
can
see
there
are
two
data
storage
etcd
on
the
cloud
for
the
control
plane.
We
also
have
another
data
store
and
to
the
edge
side,
each
side
maintains
the
metadata,
but
on
the
cloud
is
for
the
whole
cluster
on
the
edge
side
is
only
the
metadata
targeted
for
this
edge
node.
K
Currently,
we
use
CQ
light
for
the
data
store
and
on
the
edge
side
to
fit
the
raspberry
pi
resource
constraint,
but
people
feel
free.
They
can
pick
any
other
cicles,
any
other
data
storage.
They
would
like
to
have
one
thing:
I
want
to
call
out
in
each
side
we
use
the
universe
framework
so
that
the
components
are
pluggable.
For
example,
if
you're
not
doing
a
IOT
standard
rules,
then
at
runtime,
when
we
launched
a
single
process,
you
can
configure
without
loading
the
device
doing
amputee
key
broker
broker
etc.
K
So
this
is
the
high-level
architecture,
and
then
we
can
move
on
to
the
next.
How
to
you
now
we
have
two
minor
release:
manual
version
released.
Her
LayCool
batch
is
having
an
end-to-end
solution
for
IOT
and
edge
computing.
It
build
a
fundamental
infrastructure
based
on
kubernetes
in
a
major
release.
On
top
of
the
other
currently
capabilities,
we
plan
to
build
some
data
plane
service,
mesh
security
guard
by
integrating
with
spiffy
and
spare.
K
We
also
building
the
device
management
API
using
kubernetes
CRD.
We
play
also
with
we
also
planning
to
evaluate
the
performance
and
scalability
and
later
on.
We
have
in
place
to
enable
monitoring
on
some
other
features.
Next,
please,
from
a
CN,
CF
and
community
perspective.
They
really
agree
with
the
CN
CF
vision
and
would
like
to
contribute
to
the
community.
As
you
can
see,
cooperage
is
based
on
kubernetes.
The
architecture
is
very
open
and
extensible.
It
supports
native
container
application.
K
We
presented
the
cooperage
three
times
deep
sessions
through
deep
sessions,
Nico
come
well,
I
was
presenting,
I
heard
a
lot
of
interests
from
companies
Academy
and
folks,
and
so
there
are
a
lot
of
needs.
People
are
working
on
idea,
edge
computing
which
go
batch
architecture
can
help
people
in
the
world
and
also
coverage
can
help
people
to
integrate
with
a
lot
of
other
sincere
projects,
for
example,
he
stills
buffet
project,
Prometheus
and
etc.
We
like
to
welcome
and
engage
more
people
to
make
more
innovations
and
I
think
another
thing
I
want
to
mention.
K
Kvetch
architecture
is
coloured
as
a
example
in
the
kubernetes
out
heel
edge
working
group
web
paper.
So,
in
summary,
we
think
who
edged
align
is
the
community
community?
There
is
the
needs,
the
architecture
is
open,
extensible
and
that
we
can
include
more
people
in
the
community
and
build
some
innovation
for
the
edge
computing.
And
that's
what
I
have
any
question
comments.
L
Cindy,
could
you
perhaps
talk
a
little
more
about
the
how
how
the
connectivity
between
the
edge
and
the
cloud
is
handled,
particularly
that
connectivity
is,
is
often
very
poor,
which
is
something
that
kubernetes
does
not
handle?
Could
you
just
explain
them
in
more
detail
about
how
that
is
dealt
with
sure.
K
So
from
the
edge
node
to
the
cloud,
there's
is
a
long
connection,
which
is
a
single
connection.
They
use
WebSocket
so
that
the
connection
can
be
viewed,
but
it's
initiated
from
the
client
from
the
edge
node,
because
when
they
configure
or
provision
the
edge
node,
it
knows
where
the
kubernetes
control
playing
API
server
is
located
once
the
connection
is
initiated.
This
WebSocket
is
a
pie
direction
of
nitrogen
and
then
the
data
can
be
flowed
from
and
to
between
the
edge
and
Claude
and
the
one
specialty
of
who
badge.
K
As
I
mentioned,
we
handle
the
network,
disconnection
and
reconnection
scenarios
in
case
the
network,
disconnected
because
on
the
edge
side
we
have
a
copy
of
the
metadata
for
the
edge
node.
Then
things
can
continue
continue
and
autonomously
working
without
even
without
this
connection.
But
once
the
network
connection
is
reviewed,
then
all
the
data
from
the
edge
side
can
flow
back
to
the
atom
to
the
cloud
or
vice
versa.
K
I
think
you
might
wonder,
like
you
know,
in
the
current
cornutus
architecture,
every
10
seconds,
the
coolant
has
to
report
the
heartbeat
to
control
play
about
its
liveness.
But
if
we
how
we
address
this,
is
we
use
the
tang
mechanism?
So
in
case
the
network
is
disconnected
the
action.
Node
will
be
tinted
accordingly,
so
that
new
deployment
won't
be
scheduled
to
that
edge
node,
but
once
it's
connected
it
can
remove
the
taint
and
things
can
continue
working.
K
That's
what
I
mean
by
the
action
node
and
cloud
are
loosely
coupled,
so
that
each
side
can
autonomous,
autonomous
autonomous
networking
and
also
when
the
network
is
reconnected.
It's
just
everything
just
worked
like
you
ran
our
kubernetes
cluster.
The
location
of
the
edge
node
is
transparent
to
the
user.
D
K
A
All
right
that
pretty
much
wraps
it
up
for
today,
so
this
is
a
bit
of
an
experiment
for
us
and
we're
gonna
continue
doing
project
presentations
once
a
month
on
the
second
Tuesday
of
the
month
at
8
a.m.
Pacific.
So
hopefully
this
was
kind
of
useful
folks,
helping
us
kind
of
get
through
the
backlog,
and
you
know
learn
about
some
of
these
projects
that
are
interested
in
joining
CN
CF,
so
other
than
that.
You
know,
look
forward
to
discussion
and
there's
some
proposals
already
out.