►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
go
all
right
thanks.
Everyone
for
joining
us
today.
Welcome
to
today's
cncf
live
webinar,
managing
iot
devices
from
kubernetes
with
ocry,
I'm
libby,
schultz
and
I'll
be
moderating.
Today's
webinar
I'm
going
to
read
our
code
of
conduct
and
then
I
will
hand
it
over
to
kate
goldenring
software
engineer
at
microsoft.
A
A
A
Please
also
note
that
the
slides
and
recording
will
be
posted
later
today
to
the
online
programs
page
at
community.cncf.io
under
online
programs,
and
will
also
be
available
via
your
registration
link,
and
the
recording
will
also
be
on
our
online
programs.
Youtube
playlist.
With
that,
I
will
hand
it
over
to
kate
to
kick
things
off.
B
B
My
name
is
kate,
I'm
a
software
engineer
at
microsoft
and
I'm
the
maintainer
and
core
developer
of
ocari,
which
is
a
cncf
sandbox
project
and
beyond
that,
I'm
generally
very
active
in
the
open
source
community,
focusing
on
contributing
to
rust
and
kubernetes
projects,
one
that
you
may
know
of
is
crestlet,
which
is
another
cncf
sandbox
project
which
enables
running
webassembly
modules
on
kubernetes
itself,
so
feel
free
to
follow
me
on
either
of
my
socials,
but
today
we're
really
focusing
in
on
ocarina.
So
let's
talk
about
what
we're
going
to
talk
about.
B
What's
next
for
rockery
and
then
throughout.
This
presentation
feel
free
to
put
any
questions
you
have
in
the
chat.
We'll
have
plenty
of
time
at
the
end
and
we'll
address
all
those
questions
that
we
can
and
then,
at
the
end
of
all
the
slides
here
we
have
a
link
to
awk's
documentation,
so
that'll
also
link
out
to
our
github
and
other
resources,
such
as
our
slack
so
feel
free
to
navigate
to
there,
maybe
bookmark
it
explore
during
presentations.
B
So,
looking
at
the
motivation,
oftentimes
kubernetes
is
run
in
the
cloud
where
you
have
racks
observers
that
not
only
themselves
are
very
homogeneous
in
their
compute
and
resources,
but
also
their
environment.
It's
very
static,
however,
on
the
edge.
Not
only
are
these
nodes
themselves
very
heterogeneous,
so
they
support
different
amounts
of
compute,
but
also
is
their
environment.
So
you
have
all
these
tiny
iot
devices,
devices
think
mcu
class,
sensors
controllers,
etc,
and
not
only
are
there
a
bunch
of
different
ones,
but
also
they're,
constantly
scaling
up
and
scaling
down
and
oftentimes.
B
B
So
ocari
came
from
the
question
of
how
can
we
dynamically
leverage
these
devices
in
a
kubernetes
cluster,
when
these
devices
themselves
can't
run
kubernetes,
and
so
the
goal
of
ocry
is
to
create
an
open
source
standard
way
to
connect
these
devices
to
a
kubernetes
cluster
and
manage
these
devices
from
a
cluster,
which
is
really
why
awkry
stands
for
kubernetes
resource
interface?
It
aims
to
be
that
interface
that
abstracts
the
way
the
details
of
discovering
and
using
iot
devices
on
the
edge,
and
it
does
that
by
first
discovering
the
devices.
B
So
we
look
across
the
network
locally
on
the
device
or
attached
to
the
device
across
the
network
locally
on
the
node
or
attach
the
node
for
these
devices
and
then
for
every
device
that
ocari
discovers.
It
connects
it
to
the
cluster
by
creating
a
kubernetes
resource
to
represent
device,
and
then
we
have
a
controller
that
can
automatically
deploy
workloads
to
discover
devices
and
what's
unique
about
ocari.
B
Is
that
because
it
is
really
focused
on
the
edge
ocry
actually
means
edge
in
greek,
we
handle
those
occurrences
that
are
more
common
on
the
edge
such
as
devices
dynamically
disappearing.
Maybe
there's
a
loss
of
connectivity
to
the
device
or
devices
all
of
a
sudden
coming
online
and
ocry
will
see
that
it'll
remove
the
kubernetes
resource
we've
created
to
represent
that
device.
It'll
bring
down
the
workload
that
we've
automatically
deployed
to
use
that
device
and
then,
if
new
devices
come
online,
we'll
automatically
see
that
deploy
appropriate
workloads.
B
So,
like
I
mentioned,
there
are
a
lot
of
tiny
iot
devices
out
there
on
the
edge,
so
what
iot
devices
can
awkward
discover?
One
thing
to
note
is
that
iot
devices
do
not
need
to
be
modified
to
work
with
ocari.
Our
goal
is
to
not
run
anything
on
the
devices
themselves,
they're
oftentimes
too
small,
to
even
put
anything
on
them.
B
B
We
also
have
support
for
discovering
industrial
machinery
via
opc
ua
and
finally,
we
have
support
for
discovering
ip
cameras
via
the
onvif
protocol
and
that's
the
one
that
we're
kind
of
highlighting
in
our
demo
scenarios
today.
However,
the
thing
to
note
is
that
our
discovery
interface
is
fully
extensible.
It's
simply
a
grpc
interface.
B
So
if
you
wanted
to
add
support
for
discovering
a
new
set
of
devices
via
a
new
protocol,
all
you
need
to
do
is
implement
that
interface
and
that
discovery
handler,
which
is
the
implementation
of
that
interface,
can
run
in
its
own
pod.
So
you
can
simply
install
ocry,
vr,
helm,
chart
and
just
add
with
our
template
your
discovery
handler
and
already
you've
enabled
ocari
to
discover
a
new
set
of
devices.
B
So
originally,
when
ocarie
was
created,
we
are
really
focusing
on
device
use.
Specifically,
we
had
this
one
scenario
in
mind
where
ocry
would
discover
devices
and
deploy
a
long-running
pod
that
acted
as
an
information
broker.
So
you
can
imagine
say
we
had
some
of
say
we
had
an
ip
camera
you're
constantly.
This
is
example,
show
later
pulling
streams
of
frames
from
that
camera
or
say
you
wanted
to
constantly
be
monitoring
the
temperature
of
the
thermometer.
B
Those
were
kind
of
the
scenarios
we
were
originally
looking
at
another
one
would
be
a
protocol
translation
gateway,
so
maybe
you
discover
a
usb
camera
and
a
broker.
That's
this
long
running
pod
advertises
as
an
ip
camera,
and
so
out
of
this
came
the
term
broker
being
for
the
workloads
that
occurs.
Controller
automatically
deploys
on
your
behalf
to
discovered
devices.
B
We
added
support
for
deploying
kubernetes
jobs
to
discover
devices,
so
this
opens
up
the
world
for
more
management
scenarios
for
rockery,
and
so
those
are
kind
of
the
two
buckets
to
kind
of
focus
in
when
thinking
about
using
ocarin.
You
can
use
awkward
to,
of
course,
discover
devices
and
then,
beyond
that
you
can
use
operate
to
either
use
devices
kind
of
process,
information
from
devices
or
to
manage
devices
via
its
new
support
for
kubernetes
jobs,
and
so
we're
going
to
highlight
both
of
those
scenarios
in
the
end
with
our
demo.
B
So
in
this
scenario,
let's
say
you're
a
farmer
and
you
have
an
issue
on
your
farm.
You
have
some
coyotes
that
are
coming
in
and
eating
your
chickens
and
you've
decided
you
want
to
solve
this
problem
and
you
have
some.
You
have
some
I.t
background,
so
you
decide
to
set
up
an
iot
scenario
where
you're
essentially
going
to
install
some
ip
cameras
on
your
farm.
Do
some
inferencing
to
identify
the
coyotes
and
ultimately
alert
you
that
you
need
to
go
out
and
scare
away
the
coyotes
and
save
your
chickens.
B
So
you
decide
you
are
going
to
install
a
server
directly
on
your
farm
and
you're
optimistic
about
scaling
out
your
farm.
Maybe
you
think
you're
going
to
add
some
fields
or
add
some
chicken
coops,
where
you
might
need
another
server,
so
you
go
ahead
and
add
it
to
a
kubernetes
cluster
to
easily
scale
out
your
deployment.
B
So
now,
one
thing
to
note
is
the
only
information
that's
going
to
the
cloud
is
that
final,
alerting
information,
the
rest
is
being
processed
locally
on
the
edge.
So
we
do
the
same
thing.
We
deploy
a
frame
server
to
each
camera
manually,
configuring
exactly
what
camera
it
should
be
grabbing
frames
from
then
we
deploy
an
imprinting
pod
and
that
imprinting
pod
needs
to
know
how
to
find
that
gpu
and
connect
to
it.
B
This
is
all
doable
again.
It
only
took
four
steps:
that's
not
horrible,
but
what
happens
as
the
environment
changes?
What
happens
if
a
camera
goes
down
so
now
that
frame
server
may
be
erroring,
and
maybe
you
need
to
send
someone
out
into
the
field
to
fix
that
camera
to
get
that
server
back
running
or
maybe
you
need
to
manually
bring
down
that
frame
server.
B
B
B
However,
we'll
see
that
with
ocry,
all
you
need
to
do
is
three
initial
configuration
steps
and
then
the
environment
can
continue
to
change.
You
can
continue
to
scale
up
and
scale
down
your
iot
deployment
and
ocre
will
adjust
on
your
behalf.
So
let's
look
at
that
same
setup.
We
had
previously
but
you'll
note
that
our
first
step
here
was
installing
ocari
and
you
can
do
that
via
helm,
which
is
basically
the
package
manager
for
kubernetes.
B
It's
the
protocol
discovery
protocol
that
you
want
aucry
to
use
to
find
your
devices,
so
in
this
case
we're
specifying
onbiff
to
find
these
ip
cameras
not
depicted
here.
You
can
also
add
some
filters,
then
you
want
to
specify
what
broker
or
what
workloads
you
want
deployed
automatically
to
discovered
cameras.
B
B
What
you'll
also
see
is,
and
then
it
provisions
each
of
those
frame
servers
to
connect
to
a
specific
camera.
It
does
all
that
for
you.
What
you'll
also
see
is
this
larger
blue
box
that
represents
a
service
layer,
so
aubry
can
also
automate
the
creation
of
services.
It
can
create
services
for
each
device
or
each
broker,
and
it
can
also
create
a
service
that
contains
the
output
of
all
the
brokers
or
devices
of
a
configuration
so
you'll
see
here
it's
the
latter
one.
B
Speaking
of
the
inferencing
pod,
we
can
now
go
ahead
and
configure
ocry
to
discover
a
gpu
using
ocry's,
uw
discovery
handler
and
then
deploy
an
imprinting
pod.
So
this
is
just
another
configuration
after
applying
that
to
the
cluster
ocari
will
find
the
gpu
deploy
an
inferencing
pod,
and
now
we
have
our
entire
setup.
B
So
what
happens
as
the
environment
changes
say
you
add
cameras,
ocari
will
discover
them
and
immediately
deploy
frame
servers,
say
you
add:
a
node
aqua
will
detect
the
new
gpu
and
immediately
deploy
another
inferencing
pod.
So
you
can
see
the
environment
can
continue
to
change,
but
we're
only
going
to
have
those
original
three
steps.
B
So
this
really
illustrates
all
together
how
awkward
can
simplify
device
use
on
the
edge.
Let's
look
at
that
second
bucket
that
we
talked
about
which
was
device
management,
so
same
scenario
we
had
previously,
but
now
our
objective
is
to
not
only
use
the
devices
but
also
manage
them.
So
in
this
case
we
want
to
perform
a
firmer
upgrade
of
these
cameras.
B
You
can
see
we've
added
here
at
the
bottom,
the
firmware
version,
let's
say
they're
all
at
version
one
and
our
goal
is
to
get
them
to
firmware
version
two.
So
we
can
do
this
once
again
with
another
awkry
configuration
in
this
case
once
again
we're
using
onvif,
because
we're
discovering
the
ip
cameras
and
our
workload
now
is
going
to
be
a
job
with
a
specified
image.
That
is
a
firmware
upgrade.
B
So,
let's
zoom
in
to
what
that
green
box
was,
in
our
scenarios
being
awkry
and
look
at
its
architecture
a
little
so
ocari
has
an
agent
that
runs
on
every
single
node
in
the
cluster
and
a
controller
that
runs
on
the
control
plane.
The
agent
does
the
work
of
discovering
the
nodes,
sorry
discovering
the
iot
devices
and
creating
kubernetes
resources
to
represent
them,
and
the
controller
does
the
work
of
deploying
your
specified
brokers
to
the
discover
devices.
B
So
the
flow
of
this,
as
we
saw
the
first
step,
is
to
install
ocry's
first
custom
resource
definition.
It's
configuration
and,
as
you
mentioned
earlier
in
that
configuration,
you
specify
what
you
want
to
find
via
the
discovery
handler
and
you
specify
what
you
want
to
deploy
to
what
you
find
via
the
broker.
And
then
you
can
also
here
specify
some
services
that
you
want
automatically
deployed.
B
Once
a
configuration
is
applied,
the
agent
will
look
across
the
network
locally
on
the
node
attached
to
the
node
etc.
It
will
tell
the
discovery
handler
to
look
for
those
devices
for
each
device.
That's
discovered,
it'll
create
a
kubernetes
resource
to
represent
that
device
using
the
device
plug-in
framework,
and
it
will
also
create
a
second
custom
resource
definition,
the
instance
to
represent
that
device
and
the
instance
not
only
represents
the
device,
but
it
also
represents
what
nodes
can
see
the
device.
B
It
also
has
a
list
of
what
workloads
are
currently
using
the
device,
and
it
even
has
connectivity
information
in
it.
So,
for
example,
for
an
ip
camera,
it
would
have
the
ip
address.
Mac
address,
rtsp,
url,
all
the
information
that
a
broker
would
need
in
order
to
know
what
device
to
connect
to
then
the
awkry
controller
will
see
an
instance.
That's
been
created
for
a
device
and
it
will
deploy
the
broker.
B
One
thing
to
note
is
that
this
broker
and
this
diagram
we
put
the
word
custom
broker,
because
that's
really
what
you
bring
to
ocari
we've
created
this
platform
for
discovering
and
automating
the
deployment,
and
then
it
is
your
workload
that
we
will
deploy
on
your
behalf,
and
so
in
our
demos.
There
are
samples
that
we've
created,
but
this
could
really
be
anything
that
you
intend
to
do
with
a
device.
B
And
all
of
this
is
kicked
off
via
an
installation
with
helm
which,
as
I
mentioned
earlier,
is
the
package
manager
for
kubernetes,
and
we
can
break
down
this
installation
a
little
and
see
that
by
default,
the
awkward
controller
and
agent
are
installed,
and
then
you
can
additionally
set
what
discovery
handlers
you
want
deployed
to
each
node,
and
then
you
can
build
that
configuration
which
is
really
just
yaml
via
this
helm
installation.
So
you
can
give
it
a
name.
B
You
can
specify
what
workload
so
in
this
case
we're
specifying
an
upgrade
broker
and
you
can
even
set
this
setting
called
capacity
and
capacity
is
how
you
specify
how
many
use
a
device
at
once.
So
this
is
really
important
with
shared
devices.
So
say
you
have
an
ip
camera
that
four
nodes
can
see,
but
you
only
want
three
workloads
using
this
device
at
once.
You
could
set
this
capacity
to
three,
and
that
would
mean
that
only
three
nodes
could
use
this
device
at
once,
even
though
all
four
can
use
it.
B
So
we'll
have
these
two
ip
cameras
on
the
network
and
our
goal
is
to
discover
them,
and
then
we
want
to
use
them
via
a
streaming
application.
So
we're
going
to
deploy
like
in
our
first
scenario,
frame
servers
to
connect
to
the
cameras,
grab
the
frames
and
serve
them
and
then
we're
going
to
ultimately
have
some
application.
That's
going
to
consume
the
frames
from
those
cameras
and
display
them.
B
So,
let's
walk
through
what
that
looks
like
so
we'll
install
ocry
with
the
with
an
onvif
configuration
and
specifying
a
frame
server
broker
and
we'll
see
that
a
configuration
is
going
to
be
visible
in
the
cluster
and
then
the
agent
will
discover
the
cameras
and
create
two
instances,
one
for
each
camera
and
then
the
controller
is
going
to
deploy
those
frame.
Server,
pods
and
you'll.
B
Note
here
that,
even
though
there's
two
cameras
there's
four
frame
server,
pods
that
are
gonna,
be
deployed
and
that's
because
we're
gonna
set
capacity
to
two
so
we're
gonna
allow
each
node
to
use
these
cameras
and
the
reason
we
want
to
do.
That
is
say:
one
node
were
to
go
down.
It
creates
a
highly
available
scenario
where
the
other
node
is
still
processing.
The
camera
is
still
grabbing
frames
from
them,
and
so
our
application
will
constantly
be
getting
the
streams.
B
You'll
also
notice
that
we're
going
to
use
the
ability
to
automatically
create
services
and
we're
going
to
have
a
service
not
only
to
point
to
each
individual
camera's
output,
but
also
to
point
to
the
output
of
all
the
cameras
and
our
streaming.
Application
will
point
to
both
of
those
services
and
we'll
see
how
we'll
have
a
feed
showing
all
of
the
frames
from
all
cameras
and
a
feed
showing
one
feed
from
each
camera
as
well.
B
So
we'll
have
created
a
scenario
where
we
have
this
application,
that's
benefiting
from
the
work
offering's
done
and
then
we'll
take
the
scenario
one
step
further
and
show
how
we
can
use
ocry
to
manage
these
devices
and
perform
a
firmware
upgrade.
So
we're
going
to
install
another
configuration,
this
one's
going
to
be
an
upgrade
configuration
that
specifies
an
upgrade
broker
and
then
the
controller
will
ultimately
deploy
those
jobs.
That
will
do
an
upgrade
of
these
cameras
and
they'll
go
to
version
2.0
great.
So
now
we
can
jump
into
the
demo.
B
B
So
we
should
have
a
total
of
four
you'll
see
here
that
we
have
an
agent
and
deployed
to
each
node
and
one
controller
and
an
onvif
discovery
handler
deployed
to
each
node.
We
had
two
instances
pop
up
one
for
each
camera,
and
now
we
have
four
pods
those
frame
server,
pods
that
are
pending
and
about
to
start
and
you'll
see
once
they
started
now.
We
also
have
services
that
were
created
one
for
each
camera,
those
longer
services
and
then
one
larger
service
to
point
to
the
output
of
all
the
cameras.
B
So
all
of
that
was
immediately
created
via
r1
installation.
So
now
let's
go
ahead
and
visualize
this
with
our
streaming
application.
This
is
a
sample
application
we
created
for
demo
purposes.
The
only
thing
we're
changing
here
is
we're
specifying
we
want
to
use
the
onvif
services,
and
now
we
can
watch
and
confirm
that
it's
running
quickly
popped
up
and
now
we
want
to
access
this
application
locally.
So
we're
just
going
to
grab
the
port
of
it
and
do
some
port
forwarding
to
see
it
locally
on
the
computer.
B
B
And
once
this
installs,
it's
going
to
be
pretty
quick,
we're
going
to
immediately
see
two
jobs
created,
one
for
each
device
and
then
two
pods
created
that
are
part
of
that
job.
So
if
we
look
we'll
see
yep,
we
have
two
jobs
that
were
immediately
created
and
now
we
have
two
pods
at
the
bottom
there
that
are
pending
and
once
they
run
now
they're
completed.
So
that
means
they
successfully
upgraded
the
cameras
or
starting
and
upgrades.
B
So
as
can
be
expected
when
a
camera
is
upgrading,
it's
going
to
restart
so
we'll
see
that
our
stream,
we
don't
have
any
streams
coming
from
the
cameras
for
the
time
being
and
for
our
our
firmware
upgrade
suite
that
we
set
up
it
simulates
an
upgrade
by
doing
a
30
second
timeout
during
the
reboot,
and
it's
going
to
restart
the
cameras
and
increment
their
firmware
version.
So
we'll
see
that
these
are
going
to
come
back
online
there
they
are,
and
if
we
refresh
we'll
see
now
the
firmware's
at
version,
2.0.
B
B
B
You
can
use
do
with
ocarina,
so
you
can
specify
how
many
completions
the
job
needs
to
have
how
many
should
run
in
parallel,
how
many
times
it's
allowed
to
back
off
before
completely
terminating
and
failing
so
all
that
comes
out
of
the
box
with
kubernetes
you
can
do
with
ocry
and
that's
really
to
say,
like
awkari
is
very
com,
100,
kubernetes
native
we
support
and
run
on
all
kubernetes
and
do
what
kubernetes
can
do.
What
we
do
not
support
is
currently
is
more
of
a
managed,
rollout
and
kind
of
configuring.
B
What
how
those
jobs
should
be
deployed
themselves.
So,
for
example,
say
you
had
nine
cameras
and
you
wanted
to
upgrade
three
at
a
time.
We
don't
have
a
declarative
way
of
doing
that.
Currently.
What
you
could
do,
though,
is
what
we
didn't
show
is
in
awkwards
configuration.
You
can
specify
some
filters
in
that
discovery
handler
section,
so
you
could
use
opry
to
discover
all
nine
of
your
cameras
and
then
you
can
add
filters
to
say.
B
B
What
we
would
love
to
support
and
would
have
been
useful
in
this
demo,
is
showing
some
of
that
management
information
in
the
awkward
instance.
So
you
saw
that
we
had
to
show
the
onvif
device
manager
to
look
at
the
firmware
version
of
these
cameras.
Well,
it
would
be
great
if
all
of
that
information,
such
as
the
firmware
version,
was
in
the
operating
instance.
It's
well
itself,
along
with
that
connectivity,
information.
B
So
with
that
being
said,
that
is
the
content
of
what
I
wanted
to
share
with
regards
to
device
use
and
management
with
ocari.
If
you're
interested
in
learning
more
our
documentation
website,
there
docs.ocary.sh
will
kind
of
lead
you
to
all
the
important
resources,
namely
our
github,
our
slack
and
on
it.
You
can
find
some
demos,
so
we
have
our
signature
demo
is
it
helps
you
set
up
some
mock
usb
cameras,
discover
and
view
them
with
that
same
streaming,
application
we
showed
in
our
demo.
B
If
you
want
to
reproduce
this
demo,
including
the
mock
ip
camera
setup
and
the
firmware
upgrade
suite,
I
threw
together
a
hackmd
that
that
models
this
demo.
So
this
is
that's
at
the
bottom
of
the
slide
feel
free
to
check
that
out
and
we
may
move
that
to
our
documentation
site
and
make
it
more
of
an
official
demo
and
then
finally,
we
have
a
slack
on
the
kubernetes
slack.
B
It's
the
ocry
channel
and
we
do
monthly
zooms,
which
was
actually
this
morning,
so
next
month
feel
free
to
hop
on
and
discuss
there.
And
then,
if
you
want
more
of
an
overview
of
akri
another
introduction
we
presented
at
kubecon
europe
last
year
and
that
included
a
bit
more
detail
on
our
discovery
handler
interface.
So
if
you're
interested
in
what
does
that?
Grpc
interface
look
like
and
what
was
the
motivation
behind
it?
That
talk
would
be
a
great
reference
for
that.
B
Check
and
see
yeah
so
with
one
of
the
supports.
One
of
the
questions
we
got
from
james
liu
was:
does
awkry
support,
discovering
iot
device
devices
using
modbus.
So
currently
we
only
support
uw,
opcway
and
onvif,
but
modbus
is
definitely
something
we've
thought
about
supporting
and
there's
been
some
discussion
around
it
and
it
certainly
we
could
support.
So
if
that's
something
you're
interested
in
contributing,
please
check
out
the
link
that
I
showed
earlier
or
go
to
docs.org.sh
and
it'll
get
you
there
yeah
related
to
the
previous
question.
B
So
zerocomp
was
another
one.
So
yeah
we
have
someone
contributing
to
zerocomp.
They
kind
of
they
took
a
break
from
the
implementation,
but
they
got
really
far.
One
of
the
issues
we
had
with
ziracomp
is
so
zircon
is
essentially
mdns,
so
device
device
communication
with
a
discovery
service
on
top
of
it
and
that
discovery
service.
B
It
uses
the
hobby
demon
which
is
kind
of
bulky,
and
so
we
had
to
pause
on
that
implementation,
because
at
the
time
when
it
was
being
supported,
our
discovery
handlers
were
embedded
in
the
agent.
So
adding
support
for
zerocomp
really
bulked
up
the
size
of
our
agent,
and
so
we
paused
there,
but
now
that
our
model
is
extend,
we
have
our
new
extensibility
model
and
our
discovery
handlers
running
their
own
pods.
B
It's
a
really
good
time
to
circle
back
to
that
implementation,
that
pr
should
be
revived
and
if
you're
interested
in
reviving
that,
please
go
to
our
github
and
check
that
out.
It
would
be
good
to
get
some
more
momentum
behind
that
implementation.
It's
definitely
something
that
we
got
really
far
with
there's,
even
like
a
proposal
up
on
describing
the
motivation
behind
it
and
everything
on
our
documentation.
B
Thank
you,
tobias,
for
providing
the
hack
and
d
link
that
I
put
here.
Another
question:
can
we
deploy
the
different
application
pods
based
on
the
camera
property
or
capability,
but
okay,
great
so
say
that
you
have
different
cameras.
So
maybe
you
have
a
camera
at
your
house,
one's
at
the
front
door
and
one's
at
the
back
door,
and
you
want
a
different
broker
deployed
to
the
one
at
the
front
door
as
the
one
deployed
at
the
back
door.
B
If
currently,
with
our
onbiff
discovery
handler
the
information
it
gets
from
a
device,
I
believe
is
ip
address,
mac
address
and
application
and
camera
name.
So
if
you
were
to
name
your
cameras
differently,
so
maybe
you
named
all
the
cameras
that
needed
one
broker,
one
thing
and
all
the
cameras
that
needed
another
broker.
Another
thing
you
could
create
two
different
configurations
to
deploy
different
brokers
to
each
of
them.
Beyond
that
other
details
like
deploying
brokers
to
ones
that
had
oh,
we
also
have
scopes.
B
That's
another
thing
with
ip
cameras,
so
you
can
query
any
scope
on
the
camera
and
kind
of
filter
it
down
what
devices
you're
targeting
that
way.
So
you
could
add
a
scope
to
target
them
that
way
and
if
there's
anything,
that
our
discovery
handler
doesn't
make
specific
enough
that
you
would
want
to
add.
Like
extra
filtering,
that's
also
a
feature
request
that
you
could
add
on
ocari.
If
there
was
something
else
that
you
wanted
to
target
more
devices
that
were
more
specific.
B
Is
anyone
working
on
building
energy
management
applications
without
create
like
bachnet
or
bacnet?
I'm
not
familiar
with
bacnet.
Maybe
if
someone
in
the
chat
wants
to
add
more
context
there,
but
energy
management
application,
so
my
assumption,
based
on
what
this
question
is,
is
maybe
you
have
a
broker,
that's
monitoring
the
consumption
or
use
of
a
device
that
would
be
a
long
running
pod,
maybe
you're
doing
some
ml
there
to
kind
of
warn
you
hey.
B
This
device
is
using
too
much
energy
at
the
moment
or
just
to
kind
of
gather
data
on
energy
management.
I
could
see
that
being
a
scenario,
I'm
not
even
sure,
if
that's
what
you're
asking
about
since
I'm
not
familiar
with
bacnet,
but
would
love
to
hear
more
about
that,
and
maybe,
if
you
want
to
start
a
conversation
about
that
james,
you
can
add
an
issue
on
ocry
and
we
can
have
more
of
a
conversation
and
kind
of
look
at
it
more
in
detail
and
people
in
the
community
can
pitch
in
there
too.
B
Okay.
So
another
question
is
awkari
similar
to
digital
twin.
We
get
that
question
a
lot
you
didn't
read
too
much
into
ocari,
so
the
idea
behind
digital
twins
is
that
you
kind
of
create
a
representation
of
a
device.
So
you
have
a
device
and
it
has
all
these
different
settings,
or
maybe
the
digital
twin
states,
what
firmware
the
device
should
have.
Maybe
it's
states
we're
talking.
I
pre
camera
context.
B
B
Is
it
really
was
intended
for
static
devices
so
like
gpus
embedded
in
servers,
but
we
took
it
further
and
used
it
for
network
and
shared
devices,
and
because
of
that,
you
have
this
like
kubernetes
presentation
of
a
device,
and
that
leads
to
a
scenario
where
you
could
with
pods.
You
can
request
cpu
and
memory
and
with
ocry
enable
scenarios
where
you
can
request
an
ip
camera,
so
it
does
have
circling
back.
It
has
a
similar
feels
digital
twin,
but
there's
a
lot
more
kubernetes
to
it.
B
An
implement
do
you
happen
to
have
a
whole
implementation
list
that
support
the
discovery
interface.
That
would
be
great
to
have,
because
we
know
that
we
support
the
three
that
I've
mentioned
a
few
times,
but
I'm
not
sure
how
many
people
in
the
community
have
their
own.
So
I
think
some
people
have
worked
on
mqtt.
B
I
feel
like
there
was
another
one
that
I
hadn't
heard
of
that
someone
was
working
on
and
it'd,
be
great
kind
of.
You
know
how
there's
supported
kubernetes
clients
in
different
languages.
It
would
be
nice
to
have
a
list
of
like
this
is
what
other
community
members
are
providing,
but
we
don't
have
that
currently.
B
Does
ocry
implement
integrate
with
the
cd
solutions
like
rancher
fleet?
If,
yes,
can
we
claim
that
implementing
different
rollout
strategies
is
just
a
matter
of
configuration
in
fleet?
I
haven't
used
rancher
fleet,
I
would
imagine
k3s
as
a
rancher
product.
We
should
be
able
to
implement
integrate
with
it,
so
ocarina
can
run
on,
ideally
any
kubernetes.
We
run
all
of
our
end
tests
on
microcase
under
kubernetes
we've
tested
on
k,
zeros
aks
eks.
B
I
would
assume
it
can
run
on
ranchers
solutions
with
rancher
fleet
if
it's
continuous
deployment
solutions,
so
basically
you're
saying
have
rancher
fleet
do
the
work
of
the
deployment.
So
basically
the
ocarina
agent
could
do
all
the
discovery
and
resource
creation,
and
then
maybe
you
would
use
rancher
fleet
to
do
your
deployment
scenarios.
B
That's
that
probably
is
very
possible
and
very
powerful.
So
the
controller
and
agent
are
completely
independent
and
so
say:
rancher
fleet
had
a
way
of
watching
for
crds
and
taking
actions.
Based
on
that.
That
may
be
a
really
useful
tool
for
my
kind
of
honing
into
what
management
could
look
like
with
ocari.
So,
if
you're
interested
in
trying
that
out,
I
would
love
to
see
where
that
goes.
B
B
B
So
roadmap
another,
so
we
had
a
comment
about
ocari,
being
kind
of
like
service
discovery
with
kubernetes
yeah.
I
think
that
is
a
fair
summary
of
what
awkry
is
using
ocry
with
azure
digital
twin.
We've
had
an
issue
up
on
ocarie
with
that,
and
there
is
definitely
some
power
there,
but
we
have
not
taken
steps
towards
that.
Currently.
A
A
B
Okay,
great
last
question:
can
you
discuss
what
the
community
has
been
doing
with
ocry
and
in
pillars
or
production?
So
what
has
awkward
been
doing?
What
production
scenarios
have
been
used
with
ocari
yeah?
So
we
currently
were
a
pre-release,
so
we
don't
have
any
production
solutions.
A
lot
of,
what's
going
on
right
now,
is
in
the
research
space,
so
there's
research
communities
that
are
trying
out
ocarina
with
devices
and
a
lot
of
our
demos
are
kind
of
in
that
research
mode.
B
But
there
hasn't
been
production
scenarios
that
I'm
aware
of
right
now,
we're
kind
of
in
that
specking
out
phase
where
people
are
kind
of
bringing
their
ideas
and
looking
at
incorporating
ocari
it'll
take
a
little
bit
of
a
push.
Some
community
involvement
to
get
us
to
a
place
where
we
are
fully
release
ready
and
there
are
production
scenarios.