►
From YouTube: CNCF TOC Meeting - 2018-07-17
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
He'll
come
back
on
all
right,
so
if
we
go
to
slide
five
and
six
kind
of
agenda
is
fairly
brief.
Today
we
have
a
presentation,
community
presentation
from
the
Falco
project.
We
have
seen
discussions
around
the
community
backlog
about
coming
project
proposals
and
requested
due
diligence
from
the
community,
and
then
we
kind
of
have
an
open,
Q&A
session
so
slide
six,
a
really
an
important
call
from
community
kind
of
review.
The
upcoming
project
proposals
that
we
have
as
a
reminder,
open,
metrics
and
harbor-
are
both
going
to
be
entering
the
sandbox.
A
Soon
cortex
is
looking
for
an
additional
TOC
sponsor.
So
if
you're
interested
in
sponsoring
that
project,
please
reach
out
to
them
or
want
to
provide
them
any
due
diligence
go
for
it
on
that
issue
in
terms
of
backlog,
with
a
variety
of
projects
that
will
be
presented
to
the
TOC
soon
so
feel
free
to
look
and
go
through
any
of
those
links
of
those
projects.
Interest
you
slide,
seven,
oh,
go
ahead.
Someone's
gonna
say
something:
I
was
just
saying
that.
A
D
That's
mentioned
codex,
you
know,
we've
got
Ken
is
stepping
out
to
sponsor
I
think
the
delay
there
is
that
Brian
Cantrell
is
talking
to
the
cortex
community.
He
wants
to
do
some.
You
know
custom
DD
on
what
they
think
and
do
that's
talking
to
fresh
tracks,
Ravana
we've
works
and
Electronic
Arts
in
particular,
and
hopefully
that
will
lead
to
a
good
conclusion.
But
if
anyone
else
wants
to
have
a
loan,
please
please
get
in
touch
with
me
or
directly
with
Bob
cotton
from
fresh
tracks.
D
B
Sounds
good
and
we
can
do
a
demo
if
you
want
as
well
if
we
have
enough
time
so,
let's
go
ahead
and
jump
to
slide
number
eight.
So
what
is
Falco
so
pal
cos
an
open
source
project
it's
been
around
since
about
2016,
it's
basically.
What
it's
for
is
abnormal
behavior
detection
for
Linux,
based
containers,
hosts
and
orchestration
platforms.
The
industry
is
kind
of
settled
on
a
term
called
runtime
security
and
we're
seeing
more
and
more
competitors
and
other
projects
using
this
term
runtime
security.
B
So
the
cloud
native
paradigm
really
gives
you
a
lot
of
choice:
around
packaging
and
decisions
being
pushed
to
development
teams.
Kind
of
what
the
industry
has
settled
on
is
using
image
scanning
to
basically
make
sure
that
whatever
artifacts
are
being
pulled
into
a
container
image
that
we
know
the
provenance
of
those
artifacts,
but
then
also
are
those
artifacts
containing
some
known
security
vulnerability,
or
something
like
that
and
the
challenge
with
that,
while
that's
useful,
the
challenge
with
it
is.
Is
that
its
point
in
time
security?
B
So
when
the
scan
is
done
during
the
container
build
process
we
blessed
it,
we
know
that
it's
a
known
good
container,
but
once
that
container
starts
running
the
runtime
environment
often
isn't
immutable,
so
developers
can
have
scripts
that
run
that
make
changes
or,
for
instance,
you
know
kind
of
even
something
that
wouldn't
be
all
of
a
sudden.
A
developer
has
a
new
API
endpoint
from
a
third
party
that
it's
calling
out
to
that.
We
didn't
necessarily
know
that
it
would
be
making
that
outbound
connection
to
it
can
connect
it
can
catch.
B
You
know
stuff
like
that
as
well.
There's
also
resource
isolation
paradigms
as
well,
and
we
need
to
be
able
to
detect
those
breaks.
Downs
in
isolation,
Falco
is
kind
of
part
of
a
multi
layered
approach
to
security
that
we're
finding
that
to
become
more
and
more
common
in
the
container
Orchestrator
cloud
native
world,
and
we
think
that
having
multiple
layers
to
detect
these
types
of
abnormal
behaviors
are
really
important.
B
B
B
We've
had
about
3400
down
or
sorry
34,000
downloads
of
the
rpm's
themselves
and
over
900,000
docker
hub
holes
were
at
about
831
github
stars,
at
least
when
I
took
this
snapshot
of
these
numbers.
We
have
about
three
maintained,
errs
they're
all
from
Cystic
right
now,
and
we
have
about
16
contributors
as
well,
but
have
a
fairly
active
slack
channel
and
from
a
user
base
perspective
cloud.
Gov
is
probably
our
our
number
one
user
right
now.
That
at
least
has
talked
about
what
they're
doing
with
Falco
and
there's
a
few
links
there
in
the
presentation.
B
The
interesting
thing
about
cloud
gov
is
they're
using
Cloud
Foundry
and
what
they
did
is
they
basically
have
the
ability
to
detect
an
application,
that's
tainted
in
Cloud
Foundry,
and
then
they
wrote
a
little
go
program
called
gardiner
that
goes
and
talks
to
garden
the
container
runtime
engine
for
cloud
foundry
and
it
will
delete
an
application.
That's
been
deemed
as
tainted.
You
can
see
a
little
bit
about
the
growth
as
well
and
the
number
of
monthly
downloads
we're
seeing
lots
of
good
momentum.
B
As
you
can
see,
over
the
last
several
months,
we've
maintained
about
2,700
downloads
per
month
and
the
docker
hub
pools
are
trending
about
250
to
200
pulls
per
hour.
So
that's
anywhere
from
30,000
to
40,000
a
week
that
we're
seeing
as
far
as
downloads
are
concerned
for
the
Falco
docker
image
we
integrate
in
with
a
number
so
slide.
12
we
integrate
with
a
variety
of
different
projects,
so
kubernetes
rocket
container
DMC
in
the
NC
NC
F
space.
B
We
also
integrate
in
with
tools
like
our
own
open
source
tool,
assisted
mezzos
and
marathon,
as
well
as
Claude
ponder
as
well.
We
shipped
with
25
rules
around
container
best
practices
out
of
the
box,
and
you
can
kind
of
see
an
example
there
and
one
of
the
blog
posts.
We
wrote
around
collecting
security
events
from
kubernetes
and
those
pushing
those
back
into
an
afk
stock
and
allowing
you
to
build
kind
of
a
ascend
dashboard
that
shows
you
where
and
your
environment
rules
might
be
triggering
and
firing.
B
We
also
recently
shipped
a
bunch
of
default
rules
for
common
applications
as
well,
so
things
like
nginx,
Apache,
Etsy,
team,
kubernetes,
gke
and
so
forth
as
well,
and
those
are
available
of
on
our
github
repository
so
slide.
13
gives
us
a
little
bit
of
an
example
of
what
you
can
actually
do
with
Falko.
This
is
a
little
bit
of
a
proof-of-concept
that
we
created.
This
is
where
falco.
B
B
So
when
Falco
detects
one
of
these
behaviors
that
is
deemed
as
abnormal
will
publish
into
an
ATS
topic,
and
then
we
have
coup
bliss,
which
will
actually
go
and
pick
up
those
alerts
or
will
be
triggered
by
those
messages
being
published
to
Nats,
and
that
gives
us
a
lot
of
functionality
as
far
as
what
we
can
do
as
far
as
actions
are
concerned.
So
we.
E
B
B
E
E
So
here
we
list
some
of
the
projects
that
are
sort
of
you
know
complimentary
or
cover
may
be
other
aspects
of
connective
security
like
Angkor,
Claire,
inspect,
psyllium,
notary,
tough,
spiffy,
vault
and
so
on,
but
in
practice,
as
far
as
we
know
what
dudes
before
described
as
runtime
security,
we
believe
that
Falco,
at
least
you
know
in
the
cone
in
the
cloud
native
environment
is,
is
pretty
unique
as
a
tool
in
the
other
corner.
We
have
proprietary
tools
and
there
we
are
listing
some
of
the
commercial
vendors
that
offer
solutions
for
runtime
security,
in
particular.
E
The
first
one
is
Cystic
secure,
which
is
a
product
by
our
company
Cystic
and
which
actually
leverages
the
Falco
rules
engine
to
offer
its
functionality.
So
our
approach-
there
is
just
you
know,
build
a
layer
on
top
of
what
we
offer
a
completely
open
source
as
Falco
and
potentially
make
it
possible
for
other
entities,
opus
of
projects
and
company
to
do
the
same
other
tools,
aqua
security
to
his
log
strike
stack,
rocks
new
vector
again.
E
These
are
examples
there
there
is
more,
but
if
this
should
give
a
pretty
good
idea,
like
v15,
is
a
little
bit
of
forward-looking.
So
Dulce
showed
the
architectural
diagram
of
Falco
before
these
rights
as
a
few
blue
boxes,
which
is
what
we
want
to
add.
First
of
all,
in
terms
of
collection,
as
were
saying
currently,
Falco
essentially
consumes
system
call
from
our
own
kernel,
module
or
in
the
near
future,
EB
PF
scripts.
E
Ng
slide
16
is
a
bit
of
a
road
map.
This
light
is
pretty
dense.
Of
course,
I
won't
have
time
to
go
through
each
of
the
entries
in
these
lights.
In
this
light,
but,
let's
say
from
the
short
term
a
bunch
of
work
that
will
be
done
or
has
already
been
done,
as
you
can
see,
there's
quite
a
bit
of
shaped
in
terms
of
above
deployment
of
Falco,
so
making
it
more
seamless
and
better
integrated
with
both,
let's
say,
the
operative
operating
system.
E
For
example,
you
know
stuff
like
applications
like
nginx
or
a
proxy,
but
also
sincere
projects
like
kubernetes,
primitives
and
influency,
and
so
on.
So
the
ability
essentially
to
create
profiles
for
this
project.
So
when,
when
you
deploy,
falco
is
a
component,
for
example,
in
kubernetes,
there's
a
bunch
of
functionality
and
rules
in
Falco
that
can
harden
out-of-the-box,
kubernetes
and
all
of
the
components
of
the
kubernetes
ecosystem
and
also
a
bunch
of
rules
for
cas
compliance.
E
Longer-Term
kubernetes
integration
is
definitely
on
our
radar,
for
example,
the
first
bullet
Network
policies
is
one
that
we
think
is
particularly
useful
because
it
will
allow
to
evaluate
kubernetes
Network
policies
without
necessarily
have
at
least
an
initial
point
to
enforce
them
alert.
The
output
I
mentioned
that
in
the
previous
slides,
more
data
I
mentioned
it
in
previous
right.
Someone
that
I'm
personally
pretty
excited
about
is
baselining,
so
the
ability
for
Falco
to
do
its
detection
and
its
enforcement
automatically
by
learning,
essentially
the
environment
versus
having
to
be
configured
with
manual
rules
slide.
E
17,
is
about
licensing.
So
currently,
Falco
is
gplv2
mostly
for
historical
reasons,
because
part
of
the
stack
is
a
kernel
module
which
typically
requires
to
be
released
as
GPL
v2.
So,
as
a
consequence,
we
initially
like
for
cystic
release
our
stack
as
GPL
v2.
We
understand
that
these
can
create
concerns.
Our
plan
going
forward
would
be
moving,
keeping
the
kernel
part
as
GPL
v2,
because
or
at
least
with
it
licensed,
because
we
cannot
avoid
it.
Essentially,
if
we
wanted
to
run
in
the
Linux
kernel
but
move
the
open-source
part
move.
E
B
So
what
we're
looking
for
is
really
in
two
different
areas,
so
technical
collaboration
I
think
it's
really
important,
especially
in
the
open
source
world
that
we
start
talking
more
about
security.
I
know
some
people
in
the
industry,
such
as
just
has
done
a
lot
of
work
in
this
area,
but
I
think
we,
if
we
get
more
feedback
from
other
people
as
to
what
we
need
to
be
building
in
this
project,
would
be
very
helpful.
B
We
do
need
help
with
the
project
governance
process,
which
is
something
that
we
think
that
the
CNC
F
can
help
with
a
lot
integrations
for
event,
consumption
and
notifications.
And
of
course,
we
still
need
talk,
sponsors
to
enter
the
CNCs
sandbox
as
well,
and
then,
as
well
as
some
industry,
insights,
so
guidance
on
roadmap
and
future
integrations
and
guidance
on
the
security
paradigms
that
we
can
help
solve
as
well
and
I
did
notice
that
Brett
from
Cloud
Cove
has
joined
as
well.
F
Say
briefly,
if
people
don't
have
questions
Atlantica,
we
have
a
multi-tenant
cloud
foundry
base
installation
that
we
use
for
the
government.
Compliance
as
a
service
is
sort
of
the
main
reason
we
exist.
A
lot
of
the
compliance
in
the
federal
government
requires
people
to
understand
when
their
code
is
compromised
and
and
what
they're
gonna
do
about
it
and
although
it's
a
great
platform
in
every
other
way,
our
customers
are
kind
of
you
know
they're
running
their
stuff
in
containers.
They
don't
have
a
lot
of
ability
to
monitor
their
own
stuff.
F
So
we
can
say
it's
a
customer
response
ability
to
do
this,
but
there's
no
real
technical
way
for
them
to
accomplish
that,
and
as
soon
as
we
started.
Looking
at
I
thought,
though,
that
became
the
avenue
for
us
to
provide
this
for
our
customers
and
everybody
kind
of
read
the
big
sigh
of
relief.
So
we
try
and
be
open
sourcing
everything
we
do
and
we
were
not
finding
a
lot
of
other
good
solutions
for
doing.
This
is
the
first
one
that
we
came
across.
F
You
could
do
chain
of
custody
on
the
code
and
the
image
and
so
on,
but
once
it
comes
to
okay,
what
about
after
it's
running
there
wasn't
a
lot
that
they
could
do,
but
as
his
platform
rares,
we
had
to
handle
it,
handle
it
and
the
only
real
thing
that
we
found
out
there
that
was
open
source
that
we
could
use
was
with
Socko.
So
with
that
I'll
take
any
questions.
Anybody
has
about
how.
G
Composable
are
the
rule
sets
taking
a
look
at
the
example
that
was
linked
from
the
slides.
There
was
a
big
monolithic
file.
There
was
sixteen
hundred
lines
long
with
rules
for
lots
of
different
applications
like
to
Sandra
and
acted
in
queue
and
elasticsearch,
and
my
sequel
I
would
that
seems
to
significantly
reduce
the
value
of
a
container
platform
to
be
able
to
sort
of
run
arbitrary
applications
anywhere.
So
I
would
think
that
we
would
need
some
sort
of
mechanism
for
composition
that
an
application
could
bring
its
own
rule
set
with
it
yeah
possible.
Today,
yeah.
B
The
first
step
that
we
have
done
to
make
that
possible:
that's
just
creative
rules,
D
directory,
and
so
any
rules
that
are
put
in
the
rules.
D
directory
will
be
loaded
up
and
parsed
by
Falco,
and
so
that's
definitely
the
first
stuff
to
allow
applications
to
kind
of
bring
their
own
rules.
We
think
that
there
could
probably
better
ways
to
do
it,
but
this
is
one
of
the
reasons
why
we're
having
the
conversation
right
so
that
we
can
learn
and
understand
what
direction
we
need
to
take
the
project,
something.
H
E
Both
both
ways
would
be
great.
Wait
essentially
exactly
I
mean
our
ideal
motion
with
Falco
is,
is
you
know
it
really
gets
adopted
for
anytime
security?
At
this
point,
these
hooking
points
are
much
better
than
then
the
llamó
file
that
we
that
we
currently
have
and
make
it
of
course
way
more
powerful,
because,
especially
yes,
something
like
gracias
where
you
can
do
it
in
the
more
like
you
know,
organize
the
centralized
way
or
the
old
or
the
container
image
at
a
point
in
power.
E
H
But
like
gracias
or
whatever,
like
that's
not
as
standard
like
that's
kind
of
like
it's,
you
know
Google's
project.
So
what
I
was
saying
was
like
something
like
a
rules
for
security
needs
to
be
a
standard.
That's
pushed
upstream
through
o
CI
so
that
everyone
can
use
it
and
not
just
the
people
who
are
using
like
God
or
whatever
yeah.
G
I
think
I
challenge
with
that
is
that
the
tool
ecosystem
is
not
going
to
just
be
one
or
tool
to
things.
People
need
to
be
able
to
build
new
kinds
of
tools
and
have
those
get
deployed.
So
we
need
some
kind
of
mechanism
for
a
composition
of
new
specifications
and
new
tools
that
doesn't
require
just
going
through
a
centralized
body.
I
may
be
this
specific
thing
might
make
sense,
but
then
you
know
there
will
be
ten
other
things
that
don't
make
sense.
Yeah.
B
But
just
makes
a
good
point
about
having
it
at
the
OCI
layer,
because
at
that
point
it's
a
little
bit
more
controlled
and
out
of
the
developers
whim
weather.
If
those
rules
get
it
concluded
or
not,
and
it's
a
little
bit
more
active
enforcement
and
hoping
that
they've
attached
the
right,
crappiest
well.
G
E
Possible
yeah,
and,
by
the
way,
from
this
point
of
view,
you're
right,
the
yellow
files,
the
current
yum
yum,
all
approach'
falco
is
not
the
best
way
to
approach
this,
but
at
the
same
time,
the
engine
in
the
language.
These
are
just
essentially
a
generic.
You
know,
domain
language
that
is
based
on
on
system
call
and
the
pretty
simple
syntax,
and
from
this
point
of
view,
of
course,
our
goal
from
the
beginning
was
just
mostly
offering
something
to
you
know
like
describe
based
on
the
unity
that
we
think
is
pretty
close
to.
E
You
know
what,
at
the
system,
level
a
process
or
a
container
does,
which
is
system
calls
and
he's.
You
know
completely
open
and
already
used
by
other
tools
like
open
source
is
taken
by
by
several
other
tools,
and
just
you
know,
being
able
to
express
essentially
processing,
container
behavior
based
on
bed
and
at
the
point
that
can
be
used
yet
by
people
as
like.
A
format
of
description
that
can
also
be
orthogonal
to
our
engine.
You
know
could
also
be
enforced
in
in
other
ways.
G
E
I
E
Network
policy
is
a
very
good
example,
but
I
don't
know.
Other
examples
are,
for
example,
kubernetes
events.
You
know
that
can
be
used
as
the
source
for
decent
and
many
other
things
that
we
might
in
a
general
way.
Again.
This
is
a
general.
You
know,
approach
and
architecture,
it's
open
to
new
sources
of
input
and
were
working.
I
didn't
yeah.
B
And
right
now
you
can
actually
pull
back
kubernetes
metadata
as
well
as
muzzles
and
marathon
metadata,
as
well
to
say
applied
rules
to
certain
namespaces
or
pods
or
particular
deployments
inside
of
kubernetes.
So
we
do
have
that
up
functionality
to
be
able
to
talk
to
other
api's
and
pull
back
that
metadata
and
enhance
the
rule
set.
That
way
and.
I
E
So,
with
with
Falco,
specifically,
our
current
use
case
is
more
like
security,
and
you
know
monitoring
behaviors
from
the
security
point
of
view.
This
doesn't
mean
that
Falco
potentially
is
not
useful,
for
you
know
like
more
like
vanilla
monitoring
as
well,
but
honestly,
currently
we're
focusing
more
on,
like
you
know,
the
security
use
case
with
this
tool.
G
B
G
Okay,
I
suggest
taking
a
look
open
policy,
agent,
org
and
one
difference
in
in
the
way
is
supplied.
Is
it
OPA,
at
least
in
in
many
cases,
is
invoke
synchronously
to
do
authorization
checks
effectively
with
pretty
arbitrary
policies,
whereas
Falco
looks
like
an
asynchronous
detection
mechanism,
but
they
so
they
seem
complimentary,
but
maybe
some
of
the
rules
might
be
similar.
G
That
that
aspect
I
get
is
unique,
but
as
they
talk
about
applying
Falco
to
other
input
sources,
then
that's
where
the
essentially
there
are
some
potentially
some
overlapping
use
cases,
I,
guess,
events,
kubernetes
events
or
another
case
where
you
wouldn't
inject
it
into
the
authorizing
whether
the
event
exists
or
not.
It
would
be
a
detection
mechanism.
D
D
B
D
D
D
This
is
my
chance
to
ask
for
input.
We
have
a
governing
board
meeting
next
week.
It's
an
off-site
in
San,
Francisco
and
I
will
be
present
along
with
a
couple
of
other
TSU
members
such
as
Ben
Heineman,
I,
really
really
appreciate
it
if
I
felt
that
I
was
representing
the
TOC
in
practice,
as
well
as
in
theory
in
this
particular
case.
So
usually
in
these
meetings.
There's
an
opportunity
to
share
concerns,
ask
questions
of
the
GB
get
direction
and
generally
sync
up
on
things
level
set.
So
please
PLEASE.
D
This
is
an
appeal
for
your
input
on
things
that
you
would
like
me
to
discuss
on
your
behalf,
I'm
at
GB
next
week.
Some
of
the
things
that
are
concerns
for
me
are
listed
here.
So
I
think
that
you
know
we
have
an
ongoing
and
probably
never
ending
theme
around
making
projects
happy.
You
know
we
have
done
a
good
job
of
understanding.
The.
D
Our
projects,
the
particular
projects
that
I
think
we
can
help
the
most
and
should
pay
the
closest
attention
to
are
the
ones
which
are
already
quite
well
known
enough,
some
size
but
know
as
humongous,
given
etiquette,
and
so
some
think
me
up
here,
envoy
and
Prometheus
and
other
projects
that
sort
of
scale
or
heading
in
that
direction.
You
know,
if
you
know
the
principles,
please,
you
know
ask
them
this
is
this
is
a
chance
to
think
things
up
last
year
we
had
a
discussion
about
this
talking
about
envoy.
D
E
D
We're
talking
here
about
potentially
millions
of
people
I
would
be
really
really
delighted
if
CN
CF
or
a
foundation
that
could
serve
the
needs
of
all
developers,
not
a
small
subset,
like
some
other
foundations
of
that.
So
what
can
we
do
to
make
cloud
native
an
easier,
simpler
and
better
for
people?
Another
area,
that's
on
my
mind
at
the
moment,
is
now
that
we're
starting
to
have
any
users
in
the
tier
in
the
image,
CN,
CF
I,
think
there's
about
65
or
70
sponsoring
and
user
members.
D
What
is
the
TOC
one
from
M
users?
What
you
know
in
the
presentation?
The
sisty
team
specifically
pulled
that
out
as
something
that
they
would
like
to
hear
about
and
I'm
sure
that's
very
important
to
many
people.
What
are
the
right
ways
to
interact?
I
mean.
Obviously,
Sam
comes
in
sometimes
as
the
representative
of
the
end
users,
but
you
know
we
could
have
a
higher
man
with
level
of
communication.
We
could
start
with
identifying
areas
that
we
want
to
talk
about.
D
So
that's
important
to
me
and
then,
finally
and
I
think
perhaps
the
most
important
structure
you
know,
there's
a
lot
of
projects
coming
into
the
CNC,
F
and
I.
Think
it's
start
time
to
start
thinking
about
how
do
we
have
more
shape
to
what
could
otherwise
be
a
you
know,
horizontal
set
of
otherwise
identical
things,
so
you
know,
should
we
think
about
group
projects
and
having
more
focused
missions
and
around
groups
of
projects,
for
example,
security
security
is
a
very
big
theme.
D
This
year,
we've
seen
spiffy
and
spire
and
opera,
and
we
today
we
talked
about
Falco
and
there
are
other
things
in
the
security
space
you
know.
Should
we
be
forming
groups
around
security
projects,
whether
they
graduated
or
incubated
little
sandbox
doesn't
matter
and
having
separate
teams
go
out
and
get
together
and
work
on
common
questions
around
security,
same
thing
for
observability,
continuous
delivery
and
so
on?
You
know
not
just
orchestration,
of
course,
so
these
are
just
thoughts.
D
I've
been
having
and
I'm
also
particularly
concerned
that
now
that
Cuban
area
seems
to
be
adopted
by
a
lot
of
different
companies
and
maybe
kind
of
the
de
facto
Australia
of
choice
going
forward.
Are
we
going
to
seen
a
proliferation
of
things
that
run
on
top
of
a
kubernetes?
And
what
are
we
going
to
do
about
those
things
you
know?
Are
we
going
to
have
a
thousand
different
projects
that
do
machine
learning,
drone
and
control
IOT
server
smash?
You
know
fifteen
of
each
of
these
things.
What
are
we
going
to
do
about
that?
D
Because
it's
going
to
be
quite
a
massive,
but
not
careful,
so
those
are
the
things
that
are
bothering
me
I'm
sure
there
are
things
that
are
bothering
you
too,
including.
Why
does
this
Alexis
guy
shut
up
so
I've
created
a
document
which
is
linked
to
here
people
to
put
their
own
ideas
down
before
the
GD
meeting?
You
can
just
click
on
the
link
and
stick
stuff
in
there
and
we
can
talk
about
it
on
the
call.
We've
got
20
minutes
left
today.
B
You
know
one
thing,
I
would
add
to
your
point
about.
Do
we
need
to
have
you
know
the
idea
of
working
groups
towards
project
groups,
and
then
you
mentioned
security
becoming
more
and
more
of
a
topic.
I
think
something
that
would
be
really
really
helpful
is
to
have
a
cloud
native
security
landscape
and
being
able
to
understand
what
are
the
stack
of
open-source
tools
and
what
layer
in
the
stack
do
they
fit?
Are
they
infrastructure
security?
Are
they
runtime
secure?
B
D
D
We're
just
a
couple
of
people
then
implemented
and
I
think
that
that
kind
of
pattern
could
be
repeated
with
other
areas,
security
being
another.
We
have
already
a
rich
set
of
projects
that
cover
observability,
but
we
don't
have
a
way
of
bringing
them
together.
So
you
know
it's
just
implied.
It's
not
stated.
These
are
all
areas
where
we
could.
If
we
wanted
to
divert
attention
at
work
which
might
or
might
not
help
users
and
customers
and
all
of
those
good
things,
yeah.
D
G
D
G
C
Very
briefly,
I
wanted
to
mention
that
we
do
have
an
active
mailing
list
right
now
called
cmcs
reference
architecture
at
list
of
CN,
CF,
dot,
IO
and
maybe
Christmas.
Someone
could
type
that
into
the
chat
window,
but
Ken
Owens
has
been
orchestrating
our
efforts
on
making
some
revisions
to
the
landscape
and
so
we'd
love
to
have
more
folks
come
in
and
assist
us
I'm.
G
Yesa
speaking,
I,
guess
of
different
flavors
of
reference
architecture
is
something
that
I
think
would
be
very
helpful
from
end.
Users
would
be
for
them
to
describe
their
applications
and
how
you
know
at
some
level
of
detail
what
they
actually
need:
functionality,
wise
and
what
the
topologies
actually
look
like
and
how
they
map
on
to
our
existing
cloud
native
projects
and
where
gaps
might
potentially
be.
Certainly
that's
something.
I
always
find
very
useful.
G
B
D
G
And
then,
with
respect
to
structure,
this
has
come
up
in
a
number
of
the
discussions
about
potential
sandbox
projects
as
well,
but
figuring
out
how
to
organize.
You
know
we
have
four
Nettie's
obviously
has
a
big
and
growing
ecosystem,
and
some
of
the
other
projects
like
prometheus
and
odd
boy
are
starting
to
grow
their
own
ecosystems
as
well.
D
I
mean
I
think
the
discussion
around
cortex
highlighted
this.
You
know
the
Prometheus
team,
don't
have
their
own
sandbox
and
you
know
products
is
simultaneously
a
turbine
at
ease
and
a
Prometheus
sandbox
project.
So
obviously
you
can
take
advantage
of
the
CN
CF
sandbox,
but
you
know
we
can
do
that
with
a
few
more
projects
and.
G
I
yeah
in
terms
of
the
app
app
tools
I,
think
that's
worthy
of
a
longer
discussion.
I,
don't
know
that,
there's
a
way
to
necessarily
that
it's
necessarily
a
problem
for
lots
of
different
competing
solutions
to
develop
and
I'm,
not
sure
that
it's
preventable.
If
we
look
at
what
happens
in
JavaScript
frameworks,
for
example,
it
always
seems
to
be
another
new
one.
G
K
You
know
I,
don't
say
this,
so
this
is
Matt
Farina
here
in
kubernetes,
sig
apps
we've
been
talking
about
app
tools
lately
and
there
are
a
lot
of
gaps,
whether
we're
talking
about
debugging
things.
I
could
eat
a
bug,
something
what's
running
inside
of
a
container
right
and
there
are
a
couple
of
ways,
but
there's
a
lot
of
tools
like
how
do
I
test
something
offline
if
I'm
dealing
with
service
right,
if
it's
functions
as
a
service,
how
do
I
test
it
when
it's
entirely
offline
in
my
own
development
environment?
K
What
is
it
like
to
have
a
local
thing,
like
mini
cube,
plus
a
bunch
of
things
so
I
can
locally
develop
versus
developing
out
in
a
cloud
development
environment,
because
sometimes
I
can't
run
everything
locally.
It
just
takes
up
too
much
memory
and
resources.
How
do
I
deal
with
this
and
there's
a
lot
of
space
for
app
tools
here
and
and
I
would
argue
that
the
space
is
pretty
immature
right
now,
something
to
do
with
it,
but
yeah.
D
I
think
you're
right
I
was
hoping
to
be
on
the
cold,
so
I
want
to
ask
you
what
happened
to
the
work
working
group.
You
know
this
is
the
thing
where
we
were
going
to
try
and
figure
out
what
what
what
should
working
groups
do,
what
should
their
minimum
criteria
be
and
their
exit
criteria,
which
I
think
you
were
involved
with
I,
think
that's
part
of
this
discussion
because
we're
essentially
saying
let's
bring
this
together
with
the
fields
that
such
as
what
Brian
said
just
on
they
have
tools.
D
D
K
When
it
comes
to
so
it's
kind
of,
do
you
think
so
the
discoverability
of
tools
can
kind
of
be
a
problem
right
now,
so
getting
more
app
dev
tools
into
the
landscape
and
categorized
would
probably
be
useful
for
everybody.
Who's
searching
for
things
on
the
whole
working
group
working
group,
front
I,
think
Chris
was
the
one
who
was
handling
that
and
there's
an
open
poll
request
with
a
whole
bunch
of
stuff
in
it.
That
still
needs
to
be
worked
through
on
that.