►
From YouTube: Kubernetes WG IoT Edge 20221130
Description
November 20, 2022 meeting of the CNCF IoT Edge Working Group. Edge Native Application Principles white paper follow up discussion. Drogue IoT Cloud presentation by Dejan Bosanac.
A
Hi
welcome
to
the
November
30th
meeting
of
the
cncf
iot
edge
working
group
on
the
agenda.
Today,
we've
got
a
few
items.
We're
going
to
in
one
of
the
speakers
is
running
a
little
late,
so
we're
going
to
invert
the
order
compared
to
what's
in
the
agenda.stock
we're
going
to
start
with
a
presentation
on
the
drogue
iot
cloud
by
Dion,
followed
by
a
follow-up
discussion
of
the
edge
native
applications
white
paper
that
we've
been
working
on
since
mid-year,
maybe
even
a
little
before
mid-year
and
then
finally,
I.
A
Don't
know
that
we
need
to
discuss
this,
but
I
put
an
item
in
the
agenda.
Note
stock
for
consideration
of
whether
we
want
to
cancel
a
few
meetings
that
occur
during
holiday
periods
around
the
world,
specifically
late,
December
Emperor
and
in
late
January.
There's
one
that
conflicts
with
the
Asian
Lunar
New
Year
celebration.
So
go
ahead
and
respond
to
that
poll.
If
you,
if
you
care
to
so
with
that
said,
let's
turn
it
over
to
you
Dion
and
you
can
talk
about
the
drogue
iot
cloud.
Great.
A
A
C
B
I
was
thinking
it
might
be
good
to
like
go
briefly
to
to
what
drug
is
maybe
15-20
minutes
and
then,
if
there's
an
interest,
I'm
I'm
more
than
willing
in
the
future,
to
do
more
demos
and-
and
things
like
that,
about
what
you're
doing
in
these
days
and
let's
make
this
as
interactive
as
possible.
So
if
anybody
have
any
questions
we
can,
we
can
talk
about
as
we
go,
so
the
whole
draw
guide
to
project
is
consisting
of
the
two
parts.
B
The
first
one
is
the
drug
device
and
it's
an
attempt
to
to
help
the
rust
embedded
Community
a
little
bit,
try
to
provide
more
libraries
and
and
building
blocks
for
for
building
IIT
applications
in
Rust
and
complementary
to
that.
We
wanted
to
to
provide
the
same
Community
with
with
or
iot
friendly,
apis
and
and
cloud
services
for
for
iot,
but
from
the
beginning.
Let's
just
make
it
clear
that
it's
not
only
related
to
to
the
rust
embedded
devices.
B
B
Basically,
trying
to
to
put
the
the
best
practices
that
we
outlined
in
in
the
in
the
in
the
white
paper
in
some
kind
of
a
working
blueprint
where
we
will
like
a
guitar
dog
food
so
to
say,
and
and
and
and
and
and
provide
an
example
of
how
to
actually
you
know,
write
and
and
run
and
manage
the
The
Edge
workload.
But
we
can
talk
about
it
at
some
other
point.
B
So
let's
talk
about
the
the
cloud
bits
next,
so
yeah.
The
idea
is
to
provide
the
whole
infrastructure
to
connect
on
one
side,
the
embedded
devices
and
on
on
the
other
side,
the
the
iot
applications
running
running
in
in
the
cloud
and
sorry,
and
in
order
to
do
that,
we
need
to
provide
a
a
little
bit
of
infrastructure
there.
So
this
is
nothing
particularly
new,
but
but
I
think
it's
important
to
to
to
do
this.
B
These
kind
of
things,
because
what
we
see
is
that
usually
people
all
are
creating
their
own
silos
over
and
over
again,
preventing
things
getting
from
the
idea
that
it's
it's
a
very
easy
thing
to
do
so.
I
I
need
a
mqtt
broker
and,
and
it
will
be
the
it
should
all
work
out,
but
but
then
then
things
get
complicated
and
and
you're
putting
more
more
and
more
work
into.
B
You
know
providing
infrastructure
instead
of
focusing
on
your
applications
and
and
and
things
like
that,
so
there
are
two
questions:
why
just
don't
we
use
the
the
regular
Cloud
stuff
and
the
question
being
answered
for
that
is
that
it's
usually
not
suitable
for
for
for
connecting
devices
the
same
way
as
as
we
connect
other
applications
and
that
we
need
to
cater
more
toward
the
iot
developers
in
that
area
and
for
for
other
way
around,
as
I
said
like?
Why?
B
B
And
then
you
know
controlling
all
this.
We
need
to
have
a
management
API
so
that
we
can
manage
devices
and
the
users
and
and
on
top
of
that,
having
the
appropriate,
CLI
and
and
the
console
that
people
can
use
to
to
to
manage,
manage
the
platform
so
and
yeah.
This
is
in
in
its
Essence
event-based
system,.
A
B
So
so
our
devices
in
the
cloud
exchange
events.
So,
as
you
said,
we
tried
to
to
normalize
these
protocols
so
that
the
so
that
devices
and
and
the
application
can
talk,
even
if
they
don't
don't
talk
the
same
protocol.
So
so
the
protocol
is
normalized
and
in
this
connectivity
layer
we
don't
touch
the
payload.
So
so
so
so
the
payload
is
is
is
not
not
done.
B
So,
for
example,
the
device
can
publish
using
mqtt
and-
and
we
can
consume
that
events
using
the
websocket,
but
but
the
the
format
of
the
events
will
be
always
the
the
cloud
event.
And
what
is
the
cloud
event
is
just
as
a
a
specification
that
that
allows
us
to
attach
certain
headers
to
our
payload
right.
B
So
here's
a
a
quick
example,
so
we
have
a
drg
CLI
that
we
can
use
to
to
communicate
with
the
management
API.
So
first
thing
that
it's
not
presented
here
is
the
two
unit
of
login
using
the
SSO
to
in
order
to
to
be
able
to
to
communicate
with
the
system.
And
then,
if
you
want
to
create
some
devices,
the
first
thing
you
need
to
do
is
create
what
we
call
an
application
and
that
from
the
like,
if
you're
coming
from
kubernetes,
that's
basically
a
namespace.
B
So
so
a
way
to
to
continue
to
to
organize
a
multiple,
multiple
devices
in
in
in
one
logical
group,
and
then
we
can
create,
create
and
our
device
inside
of
this
inside
of
this
application
right
and
then
we
can
manage
these
devices
and
and,
for
example,
set
a
password
or
or
our
certificate
for
device.
So
it
can
connect
connect
to
the
platform,
and
once
we
have
a
device
created
and
enabled
we
can,
we
can
start
playing
with
it.
B
Here,
you
can
see
that
the
drg
client
can
give
us
a
a
a
a
token,
a
better
token
that
we
we
can
use
to
connect
to
the
websockets
integration
endpoint
and
if,
on
the
other
side
we
start
start
publishing
events
or
as
a
as
a
mqtt
device.
From
the
other
side,
we
should
be
able
to
to
see
basically
a
cloud
events
coming
coming
through
the
through
the
web
socket
web
socket
client,
and
it
should
look
some
something
like
like
this.
B
So
that's
it
I
mean
it's
a
it's.
A
complete
so
to
say
connectivity
a
platform,
so
so
we
can
see
that
we
have
a
programmatic
device
management,
so
so
so
all
these
things
can
can
be
can
be
scripted
and
and
automated
all
all
the
system
we
see
here
and
how
it's
relevant
to
this
group
is,
is
that
it's
running
on
a
kubernetes.
B
There's
a
more
tweet.
We
also
have
a
a
a
a
a
nice
UI
console
where
you
get
all
the
information
about
how
to
connect
devices
and
applications
using
different
protocols.
You
can
manage
your
applications
and
and
devices
there,
and
you
can
do
some
basic
debug
debugging,
like
we
call
it
a
spy
tool
where
you
can
see
events
and
any
introspective
events
going
through
through
through
a
single
single
application.
B
Let's
call
it
like
a
serverless
endpoint
where,
where
events
will
fly
through
so
that
they
can
be,
you
know,
I,
don't
know
enriched
or
or
formatted
or
or
or
pre-processed
pre-processed.
Basically,
we
Define
a
gated
concept
for
our
devices,
meaning
that
one
device
can
act
as
a
gate
for
for
different
logical
devices.
B
So
by
having
a
change
events
coming
out
of
our
register,
we
are
easy.
We
can
easily
integrate
multiple
device
Registries,
for
example,
allowing
us
when
we
are
create
a
device
in
our
registry
to
to
act
on
on
that
event
and
and
do
something
in
other
registries
like
synchronize
things
with
the
with
the
things
Network
for
for
a
lower
event,
examples
or
or
synchronize
the
workloads
on
on
the
edge
devices.
B
You
know
if,
if
needed,
there
are
a
couple
of
more
more
side
projects
on
top
built
on
top
of
the
draw
Cloud
one
is
called
the
drug
azure
and
it's
basically
our
effort
in
providing
the
firmary
firmware
over
the
year.
Air
updates
and
it
defines
the
protocol
between
the
cloud
and
device
to
do
the
firmware,
updates
and
and
work
out
to
the
box
with
with
our
drug
device
Ras
framework.
B
These
additional
components
are
basically
just
additional
Cloud
applications
on
top
of
on
top
of
the
draw
Cloud
which,
which
could
run
in
in
the
same
in
in
the
same
kubernetes
cluster
or
in
the
different
different
funds,
and
we
can
talk
about
it
more
in
the
in
the
in
the
future.
So
this
is
it
I.
I
didn't
want
to
take
too
much
time
for
it.
B
So
these
are
some
some
of
the
the
useful
links
there's
also
a
link
to
to
a
Sandbox
that
we
are
hosting
so
so
that
it
can
be
easily.
People
can
easily
get
started
or
log
in
there,
with
your
a
GitHub
account
and
and
and
and
test
it
out
and
as
I
said,
like
I.
Don't
want
to
hijack
these
meetings
for
for
for
for
this
topic,
but
but
whenever
there's
an
interest
and
and
there's
there's
there's
some
free
space,
we
can.
D
D
B
C
B
B
Never
is
Miss
Cloud
iot
platforms,
and
we
have
a
direct
app
that
we
support,
but
but
we
have
an
open,
open
issue
to
work
on
supporting
multiple
different
dialects
and
maybe
even
providing
a
custom
dialect
for,
as
you
said,
a
brown
deployments
of
devices
that
ex
mqtt
devices
that
are
expecting
already
a
kind
of
existing
the
topic
schema
or,
or
something
like
that,
so
so
the
basically.
The
idea
of
the
cloud
is
to
provide
like
a
data
plane
between
the
devices
and
the
applications.
No,
no
matter
the
Technologies
used
so.
A
C
A
Uses
parts
of
that
for
all
I
know,
but
the
the
quora
project
goes
from
low-level
devices
up
through
gateways
and
feeds
things
up
to
Applications
using
standardized
protocols.
Many
of
them
seem
the
same
like
mqtt
and
I.
Think
Kura
supports
Kafka
as
well,
but
I'm
wondering
why
you
saw
a
need
to
do
something
new
and
what's
different.
One
thing,
that's
obviously
different
to
me
by
the
way
is
the
use
of
rust
versus
Java
yeah.
B
B
B
A
lot
of
microservices
in
Java
takes
a
lot
of
resources
because
every
Java
process
will
be
like
you
know
to
250
mix
or
500
Megs,
and
then
you
have
a
try
to
scale
the
scale
that
it.
It
really
blows
up
a
lot
and
it's
not
easy
to
to
to
provide.
So
it's
okay,
if
you're,
trying
to
provide
a
a
cloud
scale
solution,
but
but
you
wanted
to
do,
do
something
that
it
will
scale
to
the
cloud
but
also
be
able
to
for
people
to
to
use
on
their
their
boxes
and
and
okay.
A
B
B
A
C
B
A
B
We're
using,
but
what
was
also
cool
using
rust.
We
were
able
to
create,
like
a
server
binary,
so
basically
wire
up
the
all
these
micro
services
without
any
containers,
just
wiring
it
up
in
in
pure
rust,
connecting
to
external
Kafka
to
external,
postgres
and
and
I
think.
The
key
talk
are
the
only
three
components
that
that
we
are
not
not
providing
and,
having
like
a
very,
very
small
binary
that
you
can
even
run
on
a
Raspberry
Pi
with
a
with
the
same
with
the
same
functionality.
A
A
A
B
A
E
Okay,
great
thanks,
Senator
Stephen,
thanks
Dion,
for
that
got
a
few
points
here
that
I
just
wanted
to
cover
off
with
the
group
about
the
paper
and
how
we
evolve.
It
so
would
welcome
a
discussion
around
these.
These
points
that
were
shared
in
the
agenda,
but
some
things
that
came
to
me
top
of
mind.
Now
that
we've
gone
through
kubecon
and
have
gotten
some
initial
feedback
around
the
paper.
E
The
idea
was
to
keep
it
a
draft
status
for
a
while
until
we
had
the
chance
to
collect
feedback
from
the
community.
So
I
wanted
to
ask
the
group
and
Kate
NMR
specifically
about
any
feedback
they've
received
and
any
changes
that
have
been
made
to
the
paper
on
GitHub
and
how
close
we
are
to
maybe
calling
this
effort
done
for
now
and
as
we
think
about
where
to
evolve
it
in
the
future.
D
I'm
pulling
up
the
presentation
feedback
now,
but
they
haven't
cncf
hasn't
released
to
us
the
feedback
that
they
calculate
of
our
session
in
general.
So
we
don't
have
any
of
that
feedback,
but
we
did
send
out
that
put
in
that
QR
code
asking
people
for
feedback
for
the
working
group
and
whether
they
wanted
to
participate
in
the
white
paper
and
last
I
checked
our
last
meeting.
We
didn't
have
much
but
I'll
check
that
now
and
see
what
our
latest
status
is.
E
C
E
E
All
right
so,
while
Kate
pulls
that
up
and
shares
what
we
maybe
have
in
terms
of
feedback
now,
I
guess
I
can
also
pose
the
the
follow-up
question
is
to
once
this
feedback's
Incorporated.
If
we've
reached
a
point
where
we
can
call
this
effort
largely
done
for
now,
you
know
I
think
with
ongoing
projects
like
this,
we
have
to
find
a
logical,
stopping
point,
or
at
least
stop
a
milestone
where
we
can
say
these.
These
are
our
principles
and
I.
E
Don't
know
if
these
need
to
be
officially
reviewed
or
blessed
by,
let's
say
the
the
TOC
of
cncf
or
other
I
think
it's
maybe
up
to
us
to
make
a
recommendation
on
hey.
This
is
our
our
our
principles
document
and
from
here
we're
going
to
do
other
things
with
it.
Maybe
with
the
caveat
that
it's
still,
you
know,
living
and
breathing
in
can
change
over
time,
but
just
to
mark
this
is
a
milestone
of
being
done.
D
So
I
guess
the
first
of
all
for
the
feedback.
We
only
have
six
responses
from
our
QR
code
that
we
put
out
for
the
presentation
and
the
one
that
really
pertains
to
the
paper
is
that
we
asked
what
Edge
principles
interest
you
the
most
and
I
was
I'll
paste
it
into
the
the
notes
after
this,
but
essentially
infrastructure
and
platform
management
is
what
people
are
most
interested
in,
followed
by
application
management
at
scale.
D
So
the
idea
of
management
at
scale
that
broader
theme
is
the
one
that
people
are
most
interested
in,
which
makes
sense
because
we
come
from
kubernetes
community.
So
it
makes
sense
that
that
is
where
people
are
drawing
interest
external
device.
Connectivity
is
third
place
which
pairs
in
well
with
the
presentation
deihan
just
gave.
So
how
do
we
connect
with
those
iot
devices
that
are
around
your
platform
or
your
scale
infrastructure?
D
So
I'll
share
that?
But
it's
only
six
responses,
so
I
don't
think
we
can
make
large
conclusions
from
that,
but
I
think
we
can
keep
promoting
this
survey,
which
is
what
we
have
been
doing
so
every
announcement
we're
kind
of
tagging
it
to
it.
So
I
think
we
can
continue
along
those
lines,
but
I
don't
think
that's
giving
us
any
feedback
on
the
paper
itself.
D
E
Yeah,
that's
a
good
question
and
it's
currents.
The
for
the
first
step
is
just
going
to
be
to
acknowledge
that
this
paper
was
created
and
they're
gonna
talk
about
it
on
the
next
marketing
committee
meeting
a
week
from
today,
just
as
a
a
win
of
something
that
the
community
has
has
achieved,
but
that's
just
internal
to
really
that
marketing
committee
other
options
for
us
after
that
point
are
promotions
within
Cube
weekly,
which
is
a
newsletter
adding
it
to
the
cncf.
E
They
I
asked
about
format
and
they
didn't
respond
yet
to
that
particular
point,
but
I
can
bring
that
up
on
the
next
call
and
inquire
as
to
what
might
be
optimal
there.
From
my
personal
perspective,
it's
it's
probably
easier
to
share
this
more
broadly
in
a
in
a
more
consumable
way,
if
it's
in
some
form
of
a
PDF,
whether
that's
cncf,
branded
or
other,
but
I
can
I
can
raise
that
question
in
particular
about
them
and
see
what
they
might
recommend.
E
As
of
this
date,
then
I
think
that
might
cover
us
from
the
sense
of
you
know,
being
open
to
to
potential
changes,
sometimes
down
the
road
but
I
think
if,
if
we
are
able
to
achieve
a
PDF
that
would
that
would
help
us
reach
a
broader
audience
and
get
more
eyeballs
on
the
the
principles
than
we
otherwise
would
have.
But
if
that
somehow
turns
problematic,
I
think
we
could
divert
to
just
using
the
the
GitHub
URL
instead.
But
it
would
be
interesting
to
see
where
that
lands,
foreign.
D
So
it
sounds
like
we
have
through
cncf
marketing,
at
least
one
Avenue
for
promoting
it
and
the
question
becomes:
are
we
ready
to
promote
it
and
so,
regardless
of
whether
we
put
it
in
a
PDF
form
or
it
stays
on
GitHub?
We
do
need
to
decide.
Is
this
done
and
we
can
still
add
that
word
of
revisable
to
it
or
first
edition
or
whatever
words
we
want
to
add
to
it,
but.
C
D
Question
is,
is,
is
the
text
in
a
place
we
want
and
from
my
personal
opinion,
I,
don't
think
we've
had
anyone
who
identifies
as
an
editor
come
through
and
read
it
head
to
toe
and
say
this
flows
I
understand
this
I've
never
looked
at
this
before
and
it
it
makes
sense
and
I.
Think
having
someone
do
one
or
two
or
you
know
always
more
the
merrier
do.
That
would
provide
a
lot
more
context
to
that.
C
E
I
certainly
could
be
one
of
the
editors
happy
to
have
other
community
members
participate
as
well.
You
know,
I
I
did
give
some
input
during
the
the
creation
of
the
doc,
certainly
but
yeah.
If
we've
got
license
now
to
to
do
a
final
review
and
have
a
hey
last
chance
to
make
this
as
good
as
it
can
be
for
now,
I'd
be
happy
to
read
through
it
again
with
with
that
lens
and
and
make
suggestions
in
a
in
a
Google
doc.
C
A
Just
throwing
an
ID
out
there,
but
another
opportunity
to
get
feedback
might
be
to
run
it
by
somebody
in
the
press.
Like
say:
Alex
Williams
of
the
new
stack
to
see.
If
he
can
take
a
read
and
tell
us
honest
opinion,
is
this
ready
for
a
promotion
or
you
know?
Is
it
more
like
a
draft
where
we
should
wait
for
the
second
edition
somebody
like
that
is
probably
in
a
great
position
to
give
us
a
good
review,
because
the
fact
is
the
people
who
worked
on
it
sort
of
have.
A
Okay,
if
this
item
is
over,
I
did
drop
another
note
in
the
agenda
on
whether
we
should
consider
canceling
upcoming
meetings
during
the
holidays.
So
there's
a
link
in
the
agenda
notes:
I
put
it
in
the
chat
for
those
who
joined
it.
Maybe
if
you
joined
late,
you
didn't
see
it,
but
I
took
a
brief
glance.
The
poll
is
public.
So
as
soon
as
you
vote,
you
can
see
the
results
and
it's
leaning
towards
cancellation
of
the
one
on
December
28th
and
the
others.
A
Look
like
they're,
leaning
towards
keep
the
meetings
on
the
other
period.
I
put
up
for
about
is
in
late
January.
The
Lunar
New
Year
is
a
big
thing
in
Asia,
so
often
people
take
a
a
week
off
of
work
during
that
period,
though,
since
we
canceled
the
aipac
meeting
cycle.
Maybe
this
is
simply
an
issue
of
those
people
aren't
attending
meetings
anyway,
because
the
time
is
inconvenient
but
we'll
at
least
put
it
out
for
a
poll,
because
it's
the
right
way
to
do
it
rather
than
autocratically
deciding
on
our
own.
D
A
A
You
know
already,
the
cncf
does
a
the
cloud
native
landscape,
which
was
has
been
phenomenally
useful
and
popular,
and
during
a
meeting
earlier
in
the
year,
I
dropped
a
spreadsheet
I
think
you
can
find
it
somewhere
deep
down
in
the
agenda.
Now
it's
for
people
to
list
their
projects
and
I
think
I've
had
there
might
be
over
50
of
them
in
there.
A
Now,
in
that
spreadsheet,
it's
been
one
of
the
things
I'll
I'll
complain
about
is
that
I
gated
access
to
that
document
by
membership
in
this
group,
but
I
think
I've
had
at
least
20
people
who
didn't
join
the
group
or
logged
in
under
a
different
ID
than
the
one
they
used
to
join
the
group
to
get
access
to
the
document
and
it's
kind
of
a
nuisance
to
keep
granting
those
manually.
So
if
somebody's
just
newly
discovering
it
please,
you
have
added
Authority
using
your
group
membership
but
I
think
next
year.
A
A
A
D
A
We
may
have
to
have
people
spend
some
time
to
just
go
I
think
we
can't
expect
that
all
the
projects
out
there
have
even
heard
of
this
spreadsheet.
So
really,
what
we
might
have
to
do
is
get
some
volunteers
to
go
up
there
and
spend
a
few
hours
to
go,
collect
things
and,
frankly,
I
think
there's
a
lot
of
projects
out
there
that
are
sort
of
you
know
the
way
open
source
projects
go.
Sometimes
they
have
their
moment
in
the
Sun
and
then
just
kind
of
have
people
lose
interest
in
it.
A
Yet
there's
still
value
in
listing
them,
because
people
might
want
to
have
a
comprehensive
place
to
go
to
go,
get
everything
that's
out
there
and
decide
for
themselves
whether
projects
are
some
projects
are
more
healthy
than
others,
and
even
projects
that
go
unhealthy
sometimes
did
work
that,
given
that
they're
open
source
is
worthy
of
just
doing
a
cut
and
paste
to
move
them
on
into
whatever
you
know,
whatever
the
successor
project
is
anyway,
just
throwing
that
out
there
for
an
activity
for
next
year.
I
don't
expect
it's.
You
know
that
at.
E
A
D
E
A
E
A
E
B
E
D
A
Yeah
my
position
would
be:
let's
wait
until
we
get
at
least
a
a
list
that
we
think
is
at
least
a
third
of
the
things
out
there
before
we
go
that
that
direction,
because
until
we
have
stuff
to
put
in
the
landscape,
I
I,
don't
think
we
want
to
go
plan
it
out
just
the
act
of
collecting.
This
will
maybe
help
us
categorize
this,
because
I
think
one
of
the
issues
here
is
that
once
we
get
this
list,
we're
going
to
find
out
that
each
of
these
projects
takes
on
a
different
Mission.
E
Yeah
and
as
we
get
further,
we
can
plot
what
the
the
landscape
might
look
like.
We
will.
We
need
categories
both
on
the
X
and
Y
axis,
we'll
put
the
project
logos
and
then
there's
a
question
of.
If
we
put
company
logos
onto
there
as
well
and
then
the
actual
building
will
take
a
while,
because
I
know
you
need
SVG
logos
of
everything
and
the
company
logo
records
are
at
least
pulled
out
of
crunch
base.
A
Okay,
we're
nearing
the
end
of
the
hour
it
tentatively
based
on
that
poll.
It
looks
like
we'll
have
a
meeting
in
two
weeks,
so
if
anybody's
got
any
agenda,
item
ideas
or
something
go
ahead
and
edit
them
into
the
document,
because
we
we
could
have
just
a
you-
know
random
birds
of
a
feather
meeting,
but
if
somebody
has
got
something
they'd
like
to
see
presented,
let
throw
that
idea
in
there.
D
I
I
just
had
a
quick
question
to
finish
out
the
agenda
for
Amar
and
Brandon.
I
was
curious
that
last
bullet.
How
perhaps
to
make
principles
of
the
paper
more
tangible
I,
just
want
to
make
sure
I
understood
what
what
you
all
were
suggesting
there
I
slash
actionable
in
the
future.
What
is
an
example
of
one
of
those
things
you
were
thinking
there.
D
That
makes
sense
that
same
presentation.
It
looks
like
looking
at
the
decks
they
gave
at
kubecon
as
well,
so
that
was
really
good.
I
really
enjoyed
it
and
found
it
very
interesting
and
liked
how
they,
the
12
Factor
app.
They
kind
of
used
that
as
their
framework,
so
I
thought.
That
was
a
really
good
presentation
as
well.
So
yeah
highly
recommend
looking
at
the
slides,
okay,
well,
I
just
wanted
to
make
sure
I
understood
what
you
all
were
getting
at
there
before.
E
A
One
final
thing:
I'll
add
before
we
close
the
scale
conference
that
I'm
an
organizer
of
is
held
in
Los
Angeles
in
March.
It's
actually
Pasadena
rather
than
Los
Angeles,
but
it
does
have
cfps
open
till
the
end
of
the
week.
It
has
a
two-day
track
that
is
being
designated
as
a
kubernetes
community
day
that
covers
Cloud
native
talks,
and
it
also
has
an
iot
track.