►
From YouTube: Octant Community Meeting - January 6th, 2021
Description
Octant community meeting is held weekly. We discuss and talk about the current state and future of Octant, demo upcoming features and releases, and preview new ideas we are considering for Octant.
Meeting agenda: https://hackmd.io/CzaPxtmXT_SW8nEpdwvGzw?view
A
A
I
think
I
would
be
you're
gonna
be
prepared.
I
know
I
know
what's
happening
screen
share
there.
We
go
all
right
now.
That
should
be
visible.
The
folks
easy
to
read
yes,
good,
okay,
so
we've
got
some
couple
things
on
here
that
we'll
go
through.
I
want
to
actually
go
out
of
order
today,
because
I
want
to
start
the
bottom,
which
is
things
that
are
that
are
coming
up
so
there's
a
breadcrumbs
pr
which
is
currently
emerged,
no
yeah.
A
A
A
Let's
see,
let's
see
if
it
wants
to
share
my
passwords,
no,
it
doesn't
cool
good
beauty
of
a
password
manager.
You
can
see
this
anonymously,
but
if
you
are
logged
into
a
google
account,
it
might
ask
you
to
just
like
log
into
it,
but
nightly
builds
are
here
in
this
folder
they
get
published
nightly
the
so
the
next
one
will
be.
You
can
see.
There's,
however,
many
here.
A
A
I
encourage
people
to
use
these
and
check
things
out.
This
is
a
great
way
for
not
like
people
to
check
out
features
early,
but
also
plugin
authors
to
to
give
the
latest
versions
a
try.
While
we
continue
to
work
on
better,
like
testing
pipelines
for
plug-ins
and
api
changes
and
stuff
like
that,
so
that's
a
thing
that
exists
and
you
can
get
to
it
right
from
our
right
from
our
readme.
So
I
encourage
people
to
check
that
out,
but
so
breadcrumbs
are
there
there's
another
thing:
that's
coming.
A
A
That's
in
the
octane
binary,
even
though
the
electron
application
could,
in
theory,
just
have
the
front
end
assets
packaged
with
it
as
a
build
which
it
does
right
and
then
that's
accessed
through
the
the
asar
file,
which
is
another
binary
archive
of
the
front-end
assets.
So
it's
like
we
package
the
front-end
assets
twice
right
now
in
an
electron
build,
and
obviously
we
don't
want
to
do
that.
A
So
this
work
here
is
kind
of
divorcing,
those,
the
the
internal
kind
of
server
pieces
and
then
there's
some
other
work
that
will
further
divorce
the
actual
front-end
assets
from
the
octan
binary
itself.
So
then
we
will
have
this
electron
renderer
front
end,
which
is
using
all
of
the
front
end
assets
and
built
into
the
acr
and
we'll
have
this
octane
binary
back
end,
which
produces
the
octane
stream
that
the
front
end
will
render.
So
that's
where
this
works
going.
It's
it's
interesting.
A
Yeah,
so
the
from
our
team
support
wise.
We
will.
We
will
support
any
like
any
if
somebody's
running
kind
of
just
like
the
binary
piece
of
octant
built
from
source
and
they
run
into
bugs
or
issues,
obviously
we'll
we'll
support
those
but
like
when
it
comes
to
like
hey,
I'm
trying
to
deploy
this
thing
or
I
have
this
stack
set
up
or
I'm
doing
this
or
what,
like
that
stuff
that
we're?
A
We
will
obviously
address
bugs
and
things
that
come
up
when
people
are
trying
to
run
the
octant
back-end
in
a
way
that
isn't
through
the
officially
supported
electron
method.
But
as
for
configuration
and
deployment
support,
we
won't.
We
won't
be
investing
a
lot
of
time
there
and
we
won't
be
investing
a
lot
of
like
hey.
A
So
we'll
support
that
communication
and
that
api
to
the
to
the
level
that
that
we
can
right
and
and
make
sure
that
quality
is
high
and
and
things
are
functioning
there.
I
think
also.
If
someone
came
along
and
they're
like
hey,
I
really
want
to
write
like
a
t,
a
tui
like
a
pui
for
the
octant
stream,
or
I
really
want
to
write
a
custom
renderer
for
the
octane
stream
that
does
that
uses
vue.js
or
whatever
right
or
different.
A
We
would
probably
help
like
help
coach
those
people
and
help
them
figure
some
stuff
out,
but
wouldn't
actively
support
like
upstream
changes,
specifically
to
enable
new
custom
renderers
right.
We
like
we
would
be
like
you
have
to
work
within
the
api
that
we're
defining
for
the
the
level
of
rendering
that
we
need.
A
A
I
really
want,
like
someone's,
someone's
trying
to
write
a
custom,
renderer
and,
and
someone
else
is
doing
a
custom
renderer
and
they
both
need
the
same
thing
and
then
we're
like.
Oh
actually,
you
know
that
would
help
kind
of
make
each
of
those
things
easier
to
attain
and
be
a
benefit
to
the
project
as
a
whole
like
we're
going
to
do
those
things
right,
so
it
kind
of
open
an
issue
and
you'll
find
out
the
level
of
support.
A
I,
like
I,
I
hate
this,
like
that's
kind
of
the
best
answer
right
like
I
think
there
are
just
some
things
that
will
will
gain
more
traction
and
the
more
traction
they
have
from
the
community.
The
more
support
we'll
give
them
right.
That's
kind
of
our
model
right
like
if,
if
the
community
wants
it
and
needs
it,
then
we'll
investigate
it
further
and
figure
out
the
best
way
to
do
either
either.
Do
that
thing
or
and
enable
the
end
goal,
maybe
in
a
different
way,
but
still
enable
that
end
goal?
A
A
A
Agreed
all
right
changes
to
the
review
process.
Yes,
so
this
is
something
that
sam
brought
up
in
in
a
stand-up
meeting
that
we
had,
and
I
made
some
updates
to
the
contributing
doc
that
I
think
are
important
to
check
out
come
on.
There's
show
me
that
no
isn't
there
like
a
way
to
see
the
rendered
one.
I
don't
know,
maybe
I'll
just
go
right
right
into
it's
in
master,
I'm
gonna
just
go
there.
Sorry.
A
Specifically
around
reviews,
so
also
there
was
an
update.
I
covered
this
in
the
last
thing,
but
sam
was
so
kind
to
update
our
new
flow
for
using
github
projects
instead
of
xenapp,
so
that
is
now
captured
there
and
the
zenhab
language
has
been
removed.
So
thank
you
for
that,
sam,
the
review
process,
so
currently
the
review
process
is
very
well
not
currently.
A
Previously,
the
review
process
was
ad
hoc
and
it
was
just
kind
of
take
him
as
you
come
and
and
get
to
it
when
you
can,
and
there
was
no
like
real.
There
was
no
official
language
around
the
the
time
and
order
and
how
we
were
going
to
approach
these
things
with
that
said,
we've
always
done
a
fairly
good
job
of
trying
to
get
them
reviewed
within
a
day
or
two.
A
The
the
ospo
standard
set
by
vmware
is
two
business
days,
and
we
we
currently
meet
that
goal
on
average
for
all
of
our
prs.
It
takes
an
average
so
like
some
go
in
fast,
some
going
slow
and
it
averages
it,
and
it
says,
generally,
you
do
them
in
two
business
days,
we're
going
to
take
we're
going
to
take
that
a
bit
a
little
step
further
and
we're
going
to
say
that
we
want
to
avoid
prs
being
in
any
non-uh
pending
state
for
more
than
a
business
day.
A
The
the
motivation
here
is
is
twofold:
it's
one
just
to
make
sure
that
you
know
we
stay
active
and
engaged
with
with
like
no
one
coming
from
outside.
The
community
feels
like
that.
Their
changes
are
being
looked
at
in
a
timely
manner
and
that
their
their
voices
aren't
being
heard
when
they
contribute
to
octan.
A
The
fault
that
we
have
right
now
on
octant
is
that
our
master
branch
isn't
necessarily
always
ready
to
release
we
kind
of
work
towards
getting
it
suitable
for
release.
Then
we
tag
we
release
and
then
we
slam
junk
on
top
of
it,
and
then
we
tease
out
the
bugs
and
we
work
through
issues
and
and
at
any
point
it's
not
suitable
for
a
release.
A
We
have
to
either
like
cherry
pick
things
out
or
or
you
know
it's
just
you
know
it's
just
not
ready
and
that
and
that's
a
that's,
a
failing
on
on
kind
of
my
part
of
just
like
not
encouraging
that
process
throughout
the
the
team
and-
and
I
don't
follow
that
process.
So
this
new
process
is
going
to
encourage
us
to
kind
of
get
changes
landed
in
an
orderly
manner,
scope
the
prs
down
to
a
size
that
makes
them
reviewable
in
a
day
right
so
doing
more
foundational
work
of
saying
like
hey
this.
B
Yeah
quick
note:
when
drafting
some
of
the
language
for
this
up,
I
specifically
avoided
the
concept
of
code
owners
and
designated
reviewers
for
pieces
of
the
code
base
explicitly
simply
because
there
just
aren't
enough
people
to
do
that
and
our
team.
Currently
we
don't
really
make
that
we
don't
really
separate
out
that
part
of
the
code
base.
B
Yet
so,
like
you
know
like
technically
right
like
elon
could
be,
you
know,
specialization
might
be
front
end,
but
it
doesn't
exclude
him
from
doing
any
other
part
of
the
work
in
the
good
base
so
that
ownership
idea
isn't
necessarily
meaningful.
Yet,
however,
if
we
start
getting
more
people
contributing
and
or
I
guess,
if
we
ever
have
a
non-vmware
person
as
a
maintainer,
an
octane
or
sorts
of
that,
we
could
start
adopting
that
model,
but
we're
just
not
there
yet.
So
you
know
it's
left
a
little
ambiguous
on
purpose.
A
I
think
it
was
at
this.
The
december
23rd
community
meeting
was
the
printer
next
to
me,
very
loud
was
the
moving
towards
creating
language
that
says
exactly.
How
does
one
become
a
you
know,
a
member
like
an
official
member
of
the
community
and
a
contributor
and
a
reviewer
right
like
what
is
the
steps?
What
does
that
look
like
for
someone
who
isn't
you
know
essentially
being
paid
by
vmware
to
work
on
this
thing
right
and
having
clear
established
roles
and
guidelines
for
for
what
that
means
and
how
you
kind
of
achieve?
A
That
is
something
we
also
want
to
get
written
down
and
published
this
year
this
month.
That's
something
I'm
going
to
take
on
to
myself
to
kind
of
deal
with
and
do
so
that'll
tie
in
as
well.
I
think
I
think
I
would
love
to
see
this
start
to
include
language
about
like
sam
was
saying
about
owners
and
even
portions
of
our
code.
A
C
D
Yeah
that
was
me
excellent,
okay
yeah.
I
can
go
through
that,
so
we're
gonna
be
looking
into
how
we
can
make
the
plug-in
creation
process
better,
whether
that's
through
better
documentation,
creating
more
examples
and
what
we're
looking
for
is
like
specifics
on
what
exactly
could
make
that
process
better
it'd
be
really
helpful
to
interview
some
of
you
that
have
created
plug-ins
or
have
attempted
to
create
plug-ins
and
walk
us
through
what
were
the
pain
points
and
what
are
your
suggestions
for
mitigating
some
of
the
pain
throughout
the
process?
D
We
know
there's
some
stuff
to
be
worked
on.
There
are
some
open
issues,
but
we're
looking
for
like
a
higher
level,
higher
level
feedback
as
well
and
just
trying
to
understand
what
is
your
process
and
how
we
can
make
that
better.
So,
if
you
do
have
feedback
or
you've
attempted
to
create
a
plug-in
or
you've
built,
a
plug-in
feel
free
to
reach
out
to
us
I'd
love
to
set
up
some
time,
or
maybe
we
can
even
just
have
a
chat
and
slack
about
what
were
some
of
your
pain
points
and
what
you
suggest.
A
A
And
then
so,
when
I
saw
that
there
was
looking
for
feedback
on
plugins,
I
wanted
to
capture
some
of
the
things
that
I
just
ran
up
against,
trying
to
make
a
very
simple
plug-in
and
it
was
completely
frustrating.
So
I
was
like
I
was
like.
Well,
we
got
the
stepper
component
in
master.
Let
me
go,
let
me
go
pull
that
thing
in
and
just
try
to
use
it
the
api
for
it,
especially
maybe
not
especially,
but
when
using
it
within
the
javascript
plugin.
The
api
for
the
stepper
component
is
just
there's.
A
This
mix
of
it-
and
I
comment
on
it
here,
but
there's
this
mix
of
imperative
and
declarative
between
you
know
the
javascript
plugins
and
how
octan's
api
works
and
the
dependency
injection
that
happens
and
component
rendering
on
the
screen.
That
is
a
bit
head.
Spinning
right.
You
end
up
having
to
like
use
something
like
rxjs
to
really
to
like
capture
this
data
so
that
it
can
be
updated
from
your
action
handler.
A
And
so
then
you
can
do
this
like
declarative,
javascript
approach
and
to
me
the
solution
is
to
make
better
helpers
so
that
anywhere,
that
we
have
to
do
anywhere.
That
we
say
like
this
component
has
an
action
and
you
can
do
some
type
of
action
handler.
We
want
some
type
of
helper
within
our
typescript
library
that
just
makes
that
kind
of
intuitive
right.
Like
you,
you
set
up
your
action
handler
and
it
automatically
produces
a.
What
are
they
called
a
subject?
A
The
bottom
actually
produces
a
subject,
and
then
that
subject
can
then
go
and
get
used
anywhere
you
want,
and
whenever
that
action
is
hit,
the
subject
automatically
gets
the
new
action
right.
So
like
all
of
this
right
now
is
just
you
have
to
manually,
go
do
it
and
I
think
we
can.
We
can
ease
some
of
this
by
just
putting
those
helpers
into
the
typescript
library
and
then
the
second
part
where-
and
I
didn't
like
reading
this
back
now.
A
A
It
is
bad
in
in
like
it's
just
difficult
to
use,
especially
within
the
javascript
plugin
experience
like
like
when
you
write
a
go
plugin
with
it,
it's
a
little
better
because
all
the
go
plugins
use
this
imperative
approach.
But
when
you
do
this
declarative
approach
and
the
stepper
component,
it
just
feels
disconnected
like
I
I'm
having
to
think
about
these.
A
What
I
wanted
to
do
was
like.
Okay,
let
me
go
look
at
the
documentation
and
I
think
sam
brought
this
up
before
of
like
the
stepper
component
says
it
takes
a
form
like
a
steps
and
each
step
is
a
set
of
form
stuff,
but
the
form
stuff.
You.
Basically
you
go
to
the
clarity
website
and
you
look
up
like
oh,
what
are
the
form
elements
like?
Is
it
a
text?
Is
it
this?
Is
it
that
we
don't
actually
have
like
a
good
set
of
of
comprehensive
documentation
around
it?
A
We
have
examples
in
the
website,
the
the
the
storybook
right
and
those
are
but
they're
not
that's,
also
not
comprehensive.
That's
just
the
example
of
the
forms
that
we
put
in
there
and
the
and
the
requirements
that
we
put
in
there.
So
the
reason
I
brought
this
one
up
specifically
is
because
the
stepper
component
is
right.
A
Now,
the
first
real
entry
point
into
like
interactive,
I
want
to
create
a
form
capture
data
and
submit
it
that
isn't
just
like
big
blank
window
like
apply
yaml
or
it's
like
actually
guiding
the
user
and
helping
them
through
things.
So
I
really
want
to
make
sure
that
that
that
api
that
we
expose
when
we
release
like
when
we
release
this
out
into
the
wild,
which
it
already
is
technically
but
like.
A
C
C
What's
going
on,
so
I
think
this
is
a
great
time
maybe
to
go
back
and
do
some
manufacturing
and
redesign
those
interfaces
since,
as
far
as
I
know,
there
are
not
that
many
people
out
there
using
it
if,
if
anybody
so,
I
think
we
need
to
design
new
components
with
this
in
mind
and
in
the
same
time,
when
there
is
a
need
to
go
back
and
make
some
changes-
and
you
know
also
the
stepper
components
is
not
some
simple
serial
component.
So
quite
a
lot
going
on.
There.
A
Oh
thanks,
yeah,
yeah,
you're,
right,
milan
and-
and
I
wanted
to-
I
have
some
some
code
that
I
was
messing
with-
that
I'll
just
share
real
quick
that
I
think
will
also
highlight
what
I'm
talking
about
a
little
better.
So
like
this
is,
is
a
is
a
javascript
plugin.
Let
me
get
a
little
bigger
just
to
ensure
that
people
can
see
but
and
the.
A
This
here
so
like
this
set
namespace
right
is
just
an
action
that
comes
in
when
the
namespace
changes
in
octane
and
sure
yeah.
I
can,
I
can
say,
like
I,
handle
this
action,
and
then
I
have
my
action
handler
here,
but
you
can
see
like
to
actually
handle
this
action
in
a
way
that
I
can
use
it
other
places.
A
A
This
thing
that
then,
instead
of
instead
of
explicitly
checking
for
the
action
name,
maybe
you're
you're,
just
looking
at
like
like
you
you're
within
this
you're,
registering
action
like
maybe
it
returns
a
thing
that
takes
the
function
that
handles
your
the
action
right
or
something
I
don't
know.
I
don't
know
what
the
api
looks
like,
but
I
think
showing
this
code
kind
of
helps
express
the
point
of
like
you
have
to
ex
works.
You
have
to
expose
these
internals
of
rxjs
and
behavior
subjects,
and
you
have
to
know
that.
A
Oh,
I
need
to
use
a
behavior
subject
because
was
going
to
hit
my
plug-in
endpoint
on
a
refresh
loop
and
if
I
don't
use
a
behavior
subject,
it'll
just
overwrite
the
values.
Every
time
right
like
you,
you
have
to
have
this.
This
tacit
knowledge
of
like
how
octan
is
hitting
your
plugin
to
write
the
plugin
correctly,
and
I
really
want
to
get
that.
A
I
want
to
distill
that
into
a
library.
I
I
don't
want
people
to
have
to
think
like.
Oh
every
time
this
thing
gets
called
it.
I
got
to
make
sure
it's
or-
and
maybe
it's
just
the
documentation
thing.
Maybe
we
do
expose
that
we
say
this
is
how
you
deal
with
persistent
like
this
is
how
you
deal
with
values
that
you
want
to
persist
beyond
the
request.
Is
you
put
them
in
the
constructor
and
you
they're
they're,
they're
subjects
and
and
whatever
anyway?
That's
I'm
done
with
my
rant
on
this?
That's.
A
B
Maybe
the
plug-in
api
can
have
and
I'm
not
sure
how
this
might
look,
but
we
could
have
the
plug-in
api
be
responsible
for
some
sort
of
data
persistence
like
as
long
as
octane
is
running
without
plug-in.
You
can
actually
look
up
certain
values
and,
like
you
know,
arbitrary
values
like
almost
like
a
kind
of
like
a
remote
key
value
store
that
often
itself
is
responsible
for
which
could
be
an
interesting
idea.
I'm
not
sure
if
it's
you
know,
if
that's
just
a
hacky
work,
workaround.
A
Yeah,
no,
that's
I
would.
I
would
love
to
see
the
way
that
people
abuse
that
because
I
think
I
think
putting
like
hey.
It's
generic
key
value
store,
knock
yourself
out.
I
think
we
get
some
really
interesting
uses
of
and
it's
not
it's
not
an
awful
idea.
I
mean
it's
been
requested
in
issues
in
the
past
of
some
way
to
store
data
right
like
session.
What's
it
called
on
the
front
end
in
the
browser:
local
local
storage.
A
People
like
oh
it'd,
be
nice
if
plugins
had
access
to
local
storage
right
so
doing
something
like
that
right,
like
a
file
based
local
storage,
where
your
plug-in
here's
the
thing,
though,
we've
kind
of
sidestepped
that
and
have
always
said
you
can
do
that
now,
your
plug-in
can
write
can
create
a
folder.
It
can
write
data
there.
A
A
Don't
do
that
or
do
it,
it
might
be
cool.
I
don't
know
anyway
yeah.
I
think
I
think
you're
right
there's
something
to
think
about.
I
think
just
having
better
patterns
in
there,
though,
even
on
the
go
side
right,
you
run
into
this
on
the
go
side
as
well
like
one
of
the
first
things
people
always
talk
about
is
oh
how
how
do
I
every
time
it
calls
it
rewrites
the
stuff
I
have
there
and
you're
like
yeah?
Well,
it's
you
know
on
a
loop,
so
here's
persisted
outside
of
that
function
somewhere.
A
C
Yeah,
my
feel
too,
is
that
hoppers
would
go
a
long
way
here
and
you
know,
as
as
time
goes
on,
it'll,
hopefully
build
more
of
those.
So
maybe,
in
this
case
maybe
some
having
something
like
add
capability
that
will
you
know,
register
that
and
give
you
back
everything
you
need
do
do
all
the
things
in
the
in
the
background
and
give
you
back
everything
you
need
on
your
side.
Maybe
that
that's
a
good
starting
point
at
least.
A
A
Because
then,
you
could
have
interesting
long-running
things
right,
like
a
plug-in
that
is
literally
just
watching
for,
like
think
about
a
plug-in,
that's
watching
for
some
type
of
bad
thing
to
happen
right.
It's
just
like
sitting
on
a
prometheus
endpoint
watching
for
something
bad
to
happen,
and
then,
when
that
trend
happens
or
it
sees
it,
it
fires
an
alert
and
oct.
A
That's
like
that's.
Its
sole
purpose
is
to
to
fire
an
alert
and
then,
since
you're
running
often
on
the
desktop,
you
get
a
notification
in
your
notification
bar
right
like
something
like
that
would
would
be
hard
to
do
right
now,
because
I
mean
it
wouldn't
be
hard
well
yeah.
It
would
be
it'll
be
hard
to
do
right
now,
dude,
it
would
probably
work
because
you
could
just
run
your
own
little
go
routine.
That
was
you
just
have
an
empty
empty
api
for
your
content
and
then
run
a
go
routine
and
that
could
fire
the
alert.
A
A
A
We
want
to
make
sure
that
this
release
is
of
a
high
quality
and
not
not
breaking
for
people
and
and
generally
the
the
electron
experience
is
good,
so
we'll
be
hyper
focused
on
that
and
slate.
I
think
I
I
think
I
said
I
would
like
to
do
that
by
the
16th
or
something
like
that
and
then
january
somewhere
next
yeah
next
week
is
the
14th.
It
was
like
my
my
it
would
be
nice
to
you,
but
again
will
not
sacrifice
the
quality
to
do
that,
but
I
think
I
think
we're
close.