►
From YouTube: Octant Community Meeting - February 10th, 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
All
right
welcome
everyone
to
the
february
10th.
Is
it
right,
yeah,
octant,
community
meeting
so
exciting?
We
are
we've
done
it.
It
only
took
the
longest
release
cycle
in
the
history
of
auction,
but
we've
done
it
and
we
are
calling
0.17
essentially
ready
to
ship.
So
as
of
right
now,
the
this
was.
There
was
one
final
issue
that
I
just
recently
bumped
out
to
audit
18,
because
it
doesn't
actually
impact
the
running
of
octant.
It's
just
a
little.
A
So
it's
not
super
user-friendly.
The
issue
in
this
case
was
when
you
close
octan
for
the
first
time
and
you
get
the
prompt
asking.
If
you
want
to
minimize
to
the
tray,
we
would
show
the
alert
saying
that
the
it
had
lost
connection.
Well,
that's
because
in
that
exit,
prompt,
electron,
actually
suspends
network
traffic,
and
so
while
the
network
traffic
is
suspended,
the
websocket's
not
communicating
the
front
end.
Application
goes
oh
alert,
but
the
moment
you
make
a
choice.
Well,
in
this
case,
say
yeah.
A
I
want
to
minimize
the
tray
it
it's
continuing
to
operate
like
normal.
So
it's
it's!
It's
it's
a
it's
an
electron
specific
issue,
but
it's
not
a
blocking
issue.
It's
one
we'll
fix,
but
it
was
non-blocking,
so
so
yeah
shipping
117,
and
I
think
what
I
will
do
is
just
kind
of
start
up
the.
A
A
All
right,
so
this
is
this-
is
it
this
is
0.17,
looks
very
similar
some,
but
there's
some
important
changes
here,
so
I
think
I'll
just
walk
through
them.
Briefly
we're
going
to
be
doing
a
formal
treatment
of
this
as
a
blog
post
and
probably
upload
a
focused
demo
of
here's
octant
as
an
electron
application
to
our
youtube
channel,
something
like
in
the
five
minute
time
frame.
So
I
just
want
to
walk
through
this
quickly
to
show
some
of
the
new
things
and
what
you
can
expect
and
yeah.
A
That's
that's
kind
of
it.
So
with
that
I'll
get
started,
this
screen
looks
very
similar.
All
of
the
things
that
you're
used
to
like
being
able
to
hit
ctrl,
enter
and
and
use
the
quick
switcher
are
still
here
as
well
as
the
shortcuts
are
still
here.
So
things
like
toggling
the
theme,
the
navigation,
all
of
those
though
they
they
still
work
kind
of,
as
as
expected,
we
we
did
move
some
of
them
into
a
preferences
window
which
is
nice
for
folks.
A
A
Oh
okay,
so
we'll
show
that
in
the
formal
demo
that
ends
up
on
youtube,
so
you
can
through
here
you
can.
You
can
toggle
preferences
navigation,
expanded
collapsed,
did
that
work
hold
on
yeah,
so
remembers
so
like
show
labels
dark
light,
right,
click,
it
and
so,
and
that's
that's
persisted
through
launching
in
instances
of
the
application.
A
The
other
thing
that
we
have
now
is
when
you
start
octan
as
an
electron
application,
it
will
do
its
best
to
kind
of
remember
the
window
size
and
the
position
on
your
screen.
A
A
We
now
have
these
back
and
forward
buttons,
which
did
not
exist
before
so.
This
is
as
a
result
of
not
being
in
in
a
browser
anymore.
We
needed
some
way
to
give
you
the
ability
to
easily
jump
back
and
forth
now.
These
are
the
first
pass
of
them.
We've
talked
as
a
team
about
adding
here
where
you,
when
you
click
on
it,
you
actually
can
either
next
to
it
or
near
it.
A
There
would
be
a
way
to
actually
see
the
history,
so
you
could
kind
of
jump
easily
to
something
in
the
history,
so
that
that
is
something
that
we
are
considering
the.
Let's
see
all
of
this.
The
new
we've
demoed
this
before,
but
the
new
breadcrumbs
are
in
place
here
so
now
you
can
kind
of
switch
between
the
children
of
of
a
category
easily
through
the
breadcrumbs.
A
It
also
works
as
you
as
you
go
up.
So
all
the
way
all
the
way
up
to
stack.
We
can
easily
switch
between
things
like
deployments
pods
and
the
nice
thing
about
that
is
now.
If
you
do
want
to
say
okay,
I
want
I
want.
The
navigation
collapsed,
because
I
want
a
bigger
screen.
Don't
show
me
labels,
it's
still
really
easy
through
through
mouse
clicks,
to
move
around.
If
you,
if
you,
if
you're,
not
a
person
who
uses
like
the
the
control
enter
quick
switcher.
A
So
let's
see
that
is,
did
we
add
any
new
things
here?
No,
these
are
all
the
same.
So
for
those
that
don't
know,
control
forward
slash
will
open
up
a
set
of
keyboard
shortcuts
that
we
have
enabled.
So
you
can
what
else.
I
think,
I
think
that's
the
bulk
of
like
usage
features
and
what
and
what
has
changed
like
when
you
use
octane,
oh
in
the
menus
of
the
application.
A
We
you
can
do
view
logs
this
actually
won't.
It
might
work
for
me
right
now,
probably
not
yeah.
This
is
a
x
forwarded
window,
so
it's
it's
it's
running
on
a
linux
server
and
I'm
serving
it
over
x
windows.
So
normally
this
would
just
open
a
folder
that
has
all
the
logs
in
it,
as
well
as
any
temporary
files
that
that
octant
has
been
creating
and
I
believe
our
leave
our
state
files.
B
A
A
I
can
also
kick
off
a
windows,
build
and
show
it
once
it's
ready.
If
we,
if
no
one
has
it
currently
running.
C
Give
me
one:
second,
I
probably
don't
have
the
latest
preferences,
but
I
should
have
a
build.
Let's
see
how.
A
So
yeah,
so
I
think
that's
sam's
going
to
show
off
the
the
system
tray
icon
here
shortly,
but
here's
here
I'll
just
I'll
add
some
notes.
While
he
gets
that
pulled
up.
A
So,
as
mentioned,
we'll
have
a
blog
post
with
some
formal
treatment
of
this,
as
well
as
an
official
youtube
video
with
a
proper
end
demo
and
sam
you
just
let
me
know
when
you're
you're
ready
and
well
I'll
hand
it
over
to
you
or
you
can
grab.
A
A
There
we
go
so
as
you
see
there,
it's
got,
you
can
reopen
octant.
You
can
view
the
logs
right
from
the
system
tray.
I
think
we've
we've
mentioned
in
the
past,
but
the
idea
here
is
that
you
we
would
start
to
really
use
that
area
for
just
letting
you
get
to
things
quickly
as
well.
So
imagine
you're
deploying
a
bunch
of
resources
and
applying
new
yaml.
A
You
know
you
add
new
name
spaces,
something
like
that,
we'll
be
able
to
even
just
say,
like
open
octane
with
this
namespace
and
since
it'll
already
be
running,
it'll
be
able
to
make
that
action
happen
much
faster
than
cold
launch
since
octant
leverages
informer
caches
in
the
background
and
those
do
take
a
little
bit
to
get
warmed
up.
A
Okay,
I'll
take
that
as
a
as
a
moving
on
so
the
last
the
rest
of
this
community
meeting
we're
gonna
prep,
our
oh
dot,
18
at
least
at
least:
do
some
prep
for
it
and
there's
there's
three
items
of
focus.
One
is
missing
I'll!
Add
it
in.
A
A
We'll
call
this
endpoints
yeah
there
we
go
so
yeah.
The
three
main
areas
of
focus
40.18
are
going
to
be
plug-in:
api
fixing
our
current
state
of
testing
in
overall
octant
performance
performance,
specifically
around
the
startup
time
of
octant
and
the
time
it
takes
when
you're
switching
namespaces
to
get
the
data
refreshed
and
start
to
get
that
real-time
feed.
It's
it's
it's
too
slow
right
now,
there's
no
other
way
to
put
it
it's
painfully
slow.
A
I
was
telling
sam
this
the
other
day
that
I
was
watching
someone
gonna
use
octane
in
the
wild
and
they
had
pulled
up
their
new
namespace
and
it
was
taking
so
long
to
load
that
they
were
like
I'm
not
sure
if
it's
working
and
so
they
closed
octane
and
relaunched
it
and
like
I
was
like.
Oh,
this
is
a
disaster.
A
So
if
you
have
a
relatively
small
cluster
or
like
a
a
mini,
cube
or
kind,
or
something
like
that,
it's
really
quick
and
happens
fast,
but
you
get
on
a
larger
cluster
over
actual
like
internet
and
it
yeah
it's
too
slow.
So
we
we
have
some
ideas
around
how
to
fix
that.
Those
will
also
be
coming
in
as
part
of
without
18,
so.
A
With
that
here's
our
0.17,
as
you
can
see,
we've
it's
done
we're
calling
it
done.
49
issues
closed,
pretty
pretty
long
release
and
I'll
be
very
excited
to
click.
This
button.
A
So
moving
into
so
we
have,
we
have
two
basically,
two
projects
that
we
work
out
of
the
backlog
is,
is
just
kind
of
where
things
drop
in
and
either
get
groomed
and
sorted
and
incoming.
So
we're
gonna,
probably
as
a
as
these
as
odata
odot
18
progresses,
we'll
be
using
some
time
to
to
groom
and
go
through
that.
But
today
I
mainly
wanted
to
focus
on
what
we
currently
have
been
odd.
18
raise
anything
from
the
team.
That's
not
there!
A
That
should
be
kick
anything
that
is
there
that
shouldn't
be
and
and
start
there
probably
won't
have
the
time
to
get
into
just
straight
backlog
grooming,
but
we
can.
We
can
do
that
through
slack
and
and
at
the
next
meeting,
and
and
just
do
it
kind
of
async
instead
of
sync.
So.
D
Just
start
diving
in
one
sec,
are
you
sharing
your
screen
right
now.
B
D
A
A
I
was
going
to
capture
it
on
video
and
now
it's
gone
forever
anyway.
So
now
that
you
all
can
see
what
I'm
talking
about,
we
have
two
projects
that
we
work
out
of
backlog.
This
is
incoming
stories.
Each
one
kind
of
has
a
note
at
the
top
of
the
column,
so
these
are
new
incoming.
They
really
haven't
been
triaged,
yet
maybe
they
have
but
they're
they're
they're.
Very
they
need
more.
A
This
is
unsorted,
so
this
is
stuff
like
we
looked
at
it,
it's
it's
not
necessarily
ready
for
work
or
we
haven't
cataloged
it
yet.
So
it
just
drops
into
this
unsorted
long
list
bucket,
and
then
we
have
these
groomed
stories,
which
are
ideally
in
some
form
of
priority
order,
and
these
are
these
are
issues
that
can
be
grabbed
from
here
to
bring
into
the
project
for
the
next
release.
A
So
an
example
of
how
this
flow
is
gonna
work
is
is
when
we
release
soda
on
17
people
will
open
issues
they'll
land
in
incoming
we'll
triage
them
we'll
get
them.
You
know
groomed
and
then
we'll
open
a
new
project,
0.17.1
right
and
those
those
issues
will
land
from
the
groom
section
and
the
backlog
into
o.171
or
they'll
just
kind
of
go.
They
might
skip
that
process.
If
they're
obvious
right,
then
they'll
just
go
right
into
the
odot
17
1
project.
A
A
I
don't
know,
I
don't
think
we
have
just
stop
adding
features
and
then
and
then
we
won't
have
any
any
bugs
all
right.
So
we'll
get
started
just
looking
through
some
of
these,
I
think
probably
the
easiest
thing
to
do
will
be
to
pop
out
each
one
into
a
bigger
into
a
bigger
window,
so
we
can
look
at
it
also.
I
want
to
call
it
before
we
get
started.
The
order
of
these
is
kind
of
ad
hoc,
but
it
is.
A
This
is
relatively
in
priority
order,
based
on
the
input
we
had
from
plugin
authors
and
folks
previously,
and
also
just
our
general
like
desire
for
enhancements
and
fixes
and
dependencies
and
improvements,
so
order
is,
is
something
we
can
move
around
kind
of
at
will,
but
generally
these
are
yeah
anyway.
A
So
initialize
plugins,
this
one
is,
is
really
high
priority.
Actually
it
is
it
is.
It
came
around
back
in
0.16,
we
didn't
put
it
into
o17
because
we
were
so
focused
on
electron,
but
essentially
this
is
right.
A
Now,
when
an
octan
star,
when
a
plug-in
starts
up,
it
gets
a
set
of
state
if
it,
if
it's
the
first
time,
you're
launching
octane,
but
if
you're
reloading
a
plug-in
like
in
the
case
of
a
javascript
plug-in
all
that
state
is
wiped
away
and
there's
no
way
to
retrieve
it
on
reload,
so
that
you
can
make
sure
you're
using
the
right
name,
space
make
sure
you
have
the
right
set
of
labels
and
filters
applied
all
these
things
that
are
very
important
for
plug-in
authors.
A
So
this
one,
that's
why
this
one's
kind
of
at
the
top?
It's
been
hanging
out
a
while
and
and
it's
kind
of
a
critical
use
case
for
for
plug-in
authors.
A
This
one
is
the
the
next
one
down
which
is
15
12
is
is
directly
related
to
that
just
kind
of
broken
out
of
it
further.
The
13
is
about
that
initial
state
and
1512
is
more
specific
about
being
able
to
observe
that
state
as
it
changes.
So
as
you
change
your
namespace
as
you
change
filters
and
labels
being
able
to
kind
of
see
it,
we
have
that
for
namespaces.
Now
we
don't
have
it
for
filters
and
labels.
A
A
A
Oh
right,
okay,
so
currently,
when
you
generate
links
to
resources
within
octant,
there's
it
that
has
its
own
specific
path
and
and
on
the
front
end
we'll
we'll
do
set
content
path
to
set
what
view
should
be
being
used
for
for
a
given
link
that
you
click?
We
have
this
ability
in
the
javascript
plugin
api,
as
daniel
here
calls
out
to
actually
generate
ref
references
or
links
to
internal
resources
in
a
kind
of
an
easy
way
where
you
can
pass
in
the
objects
and
get
an
octant
link.
A
Essentially,
the
go
api
does
not
have
this,
so
this
is
about
bringing
feature
parity
between
the
javascript
api
for
link,
refing
and
and
the
the
go
api
now.
The
reason
this
is
important
is
it's
kind
of
two
there's
two
aspects
to
it:
one,
it's
just
generally
useful
for
plugin
authors
to
be
able
to
easily
create
a
link
to
a
pod
or
some
other
resource
within
octan.
A
But
two
we
have
a
an
epic
to
extract
the
the
our
hard-coded
modules
out
of
octan
and
turn
them
into
plug-ins,
and
to
do
that,
we
need
to
have
a
good
way
to
generate
links
to
resources
within
octant
like
so
it's
kind
of
a
blocker
for
that
work.
A
A
Okay,
and-
and
I
encourage
anyone
to
while
I'm
covering
these,
if
you
want
to
look
through
our
backlog
of
issues,
to
identify
things
that
you
might
want
to
see
in
order
18
or
you
think
that
are
that
that
you
know
aren't
currently
in
this
list
of
17
items
that
maybe
should
be
or
be
a
good
time
to
find
those
and
and
have
them
ready
for
for
conversation.
A
A
They'll
drop
out
of
the
call
updating
a
javascript
plugin
should
send
a
content
event
to
the
client.
A
Yes,
okay,
so
this
is
this
one
is
related
to.
I
believe.
A
Yeah,
so
right
now,
when
you
reload
the
javascript
plugin,
there
is
nothing
that
really
nothing
that
really
happens.
So,
if
you're.
Looking
at
your
imagine
the
scenario,
your
your
plugin
is
acting
as
a
module
you're.
Looking
at
that
plug-in
and
you
are
developer
and
you've
made
a
modification,
and
so
it
reloads
reloads,
the
plug-in
octane
does
the
content.
A
The
set
content
path
will
not
fire,
so
you
will
still
be
looking
at
kind
of
essentially
a
cached
version
of
the
old
plugin,
because
the
content
streamer
will
no
longer
recogni,
like
basically
there's
a
disconnect
between
the
path
you're
currently
on.
When
that
plug-in,
reloads
octane
no
longer
sees
that
as
the
path
it
should
be
serving
data
for.
A
So
if
we
trigger,
if
onplug
and
reload
the
current
really
any
any
page
should
do
this,
because
this
also
happens
with
can
happen
sometimes
even
with
with
nested
elements.
A
When
a
javascript
plug-in
reloads
dynamically,
we
should
send
a
message
to
the
client
so
that
it
can
do
a
a
set
content
path
or
when
a
plug-in
reloads.
In
the
background,
we
should
ensure
that
the
stream
generator
does
not
get
confused
about
which
content
path.
It
should
be
sending
content
for
there's
kind
of
two
ways
to
approach
this
problem.
There's
the
send
something
to
the
front
end,
so
it
can
update
its
content
path,
which
would
then
cause
the
stream
data
to
re-render
or
handle
it
all.
A
It
is
important,
especially
as
we
get
into
allowing
plugin
authors,
to
have
multiple
multiple
steps
or
pages
within
their
plugin
and
having
each
of
those
pages
potentially
be
changed
and
rendered
by
the
result
of
of
an
action
handler
will
want
some
way
to
make
sure
that
when
it,
when
they're
developing
these
things
and
things
are
being
reloaded
that
they're
not
sitting
on
stale
content
and
having
to
like
do
manual
refreshes.
A
So
this
is
definitely
more
of
a
dev
like
I'm
the
developer
of
a
plugin.
It's
definitely
a
quality
of
life
thing,
but
I've
run
into
this
myself
working
on
javascript
plugins
and
I
think
it's
considering
it's
opened
by
scott
who's
was
working
on
the
open
source,
k-native
javascript
plug-in.
I
think
it's
it's
a
good
one
too,
to
get
fixed
up.
A
All
right,
so
this
one
is
embarrassing,
this
one's
totally
my
fault,
and
it
is
the
dashboard
client
list.
Behavior
is
inconsistent
when
resources
are
not
available
in
the
cluster.
This
is
a
direct
result
of
me
trying
to
be
smart
and
say:
oh
did
you
try
to
make
a
call
and
we
got
an
error?
Well,
let's,
let's
just
return
an
empty
listing
instead
of
you
know
and
wait
for
a
period
of
time,
some
some
time
out
period
before
we
retry.
A
So
that
way
we're
not
spamming
the
the
api
with
with
requests,
and
so
what
we?
What
happens,
though,
is
that
the
first
time
you
make
a
the
first
time
you
make
a
call,
it
does
the
check
it
says.
Oh,
I
got
a
error
and
it
returns
you
the
error
and
then
the
second
time
you
make
the
call
it
goes.
Oh,
we
had
an
error
last
time,
here's
an
empty
list
and
it's
you
literally
cannot
write
code
that
is
predictable
against
our
like
list
and
get
any.
A
I
I
talk
about
it
here
anywhere.
We
do.
These
has
asset,
has
access
checks
and
then
return
back
an
empty
value
in
place
of
the
error
code,
we're
just
I
was
just
trying
to
be
too
smart.
I
was
like
well,
let
me
protect
the
plug-in
authors
from
from
this
thing.
A
So
this
is
really
important,
because
this
this
this
ties
into
and
actually
I
would-
I
would
argue
that
this
is
probably
the
most
important
issue
in
odot
18,
because
it
ties
into
api
consistency
and
the
ability
to
have
calls
that
can
be
replicated,
which
ties
into
the
ability
to
be
able
to
write
tests
for
things
and
like
how
to
mock
things
and
all
there's
all
of
these
other
things
that
happen
when
your
api
behaves
inconsistently
that
are
bad.
So
moving
that
one
to
the
top
any
questions.
A
A
A
Okay,
so
this
is
one
of
those
it's
I
would.
I
would
put
this
as
as
it's
in
the
sprint
low
priority
if
they
release
1.16
we'll
do
it
if
they
don't
release
it
in
the
next
like
during
0.r0.18
release
cycle,
then
obviously
can't
do
it
so,
but
yeah.
We
currently
use
this
tool
called
ricebox
and
that
embeds
some
assets
into
into
our
binary
and
there's
now
first
class
support
for
that
with
embedded
files
with
1.16.
A
A
A
Let's
see
okay,
so
next
one
up
is
configure
the
default
items
per
page
via
preferences.
Here
we
go
mulan,
it's
already
started
the
preferences.
They
shall
grow.
A
I
did
this
issue
is,
I
think
I
mean
we've
got
three
thumbs
up.
Two
of
them
are
us,
but
still
external
external
issue
and
thumbs
up
from
an
external
user.
I
think
this
is
a
good
candidate
for
something
that
people
probably
want.
A
I've
definitely
wanted
this
like
using
octet,
and
I
I
change
how
many
items
I
want
to
display,
and
then
I
move
to
a
page
and
then
it
reverts
back
and
I'm
like
no
just
show
me
the
same
amount.
So
I
think
this
is
a.
This
is
a
good
one.
It
is.
A
2018.
the
octa
client
should
auto
update,
we'll
be
able
to
do
that
now.
We
don't
exactly
know
what
that's
going
to
look
like
implementation
wise,
but
we
do
know
that
the
binary
that's
running
under
the
covers
of
electron
will
be
able
to
so
I'll
say
this.
Our
first
pass
of
this
will
not
be
a
live
update.
It'll
be
a
you'll
I'll
capture
this
as
some
ideas
so
thoughts
about
this
is
we
would
do
something
like
alert
user
there's
a
new
version,
they
can
say
just
know,
restart.
A
You
know,
download
the
binary
place
old,
one
restart
something
like
that.
That's
that's
like
very
I
mean,
there's
there's
some
details
there,
but
there's
some
nuance
there
that
we
need
to
get
figured
out,
but
our
first
pass
will
be.
You
know
we
say:
there's
a
new
version.
We
say
yes,
you
say
yes
or
no,
probably
a
probably
another
issue
for.
A
Preference
like
we
should
be
able
to
turn
that
on
or
off
some
people
might
not
want
it
to
be
part
of
this,
I
feel
like
yeah,
maybe
but
I'll.
Just
like
someone
can,
whoever
implementer
can
make
that
decision.
I
think
I
think
that's
fair.
A
So
what
we'll
do
is
yeah
alert,
yes
or
no
download
the
binary,
replace
the
old
one
and
then
restart
now.
This
gets
tricky
because
I
know,
unlike
the
case
of
windows,
for
example,
the
file
locks
on
the
system
with
the
running
executable,
you
can't
just
replace
the
running
executable
it
will.
It
will
not
let
you
do
it
so
we'll
we'll
have
to
do.
A
We'll
probably
have
to
do
some
type
of
mechanism
of
like
download
the
binary,
with
a
different
name
check
for
that
octane
update,
binary
on
startup
right
and
then
replace
like
replace
the
old
one
and
launch
the
the
update
and
then
delete
octant
dash,
update
or
you
know,
move
it
so
that
it's
that
has
the
the
octant
name
so
that
when
the
next
update
and
then
we
conversion
those
file
names
as
well,
we
could
also
yeah
there's
different
ways.
A
This
is
all
implementation
detail,
but
that's
essentially
our
first
pass
because
we
are
not
building
a
our
the
piece
that
generates
the
octane
stream
data
is
still
external,
it's
being
run
as
a
sub
process
of
electron,
it's
not
coded
in
in
node
or
embedded
right
into
electron.
So
this
is
what
our
first
pass
at.
Auto
updating
will
look
like,
and
this
is
also
very
exciting.
A
This
is
one
of
the
things
I'm
most
excited
about,
because
it's
just
like
the
rate
at
which
we
can
start
to
get
changes
to
people
will
rapidly
increase
when
we're
not
having
to
do
package
manage,
updates
and
make
sure
like
we'll,
be
able
to
fix
things
very
quickly
and
do
more
incremental,
smaller
releases
of
things.
Just
like
that
experience
you
get
now
with
using
any
other
tool
like
vs
code
or
slack
or
spotify,
or
any
anything
where
you're.
A
Just
like
you
get
these
trickling
of
updates
and
changes
that
just
make
your
life
better
and
you
don't
have
to
like.
Oh
it's
time
to
do
my
big
update
right.
So
I'm
excited
about
this.
This
is
this
is
gonna.
This
is
gonna,
be
great.
The
tie
into
that
is
huge.
The
tie
into
that
is
we'll
need
to
greatly
improve
our
testing.
As
sam
pointed
out
in
the
in
the
meeting
notes
the
fix
the
state
of
testing.
We
will
will
want
that
needed.
It's
a
necessity
for
auto
updating,
so.
C
Quick
injection
in
this
conversation,
so
a
lot
of
people
who
are
going
to
be
running
the
0.17
build
of
electron
on
a
mac
are
going
to
see
unidentified
developer
notices
and
you're
going
to
just
have
to
disable
that,
because
right
now
we
don't
have
any
of
the
electron
builds
signed
and
I'd
love
to
give
an
eta
on
it,
but
that's
kind
of
bound
by
vmware
constraints
and
out
of
our
hands
unless
we
just
want
to
create.
C
Like
you
know,
a
rogue
certificate
under,
like
you
know,
an
octan
specific
project
and
then
we'll
just
deal
with
it
ourselves,
but
that's
going
to
be
something
that
also
applies
to
auto
update,
because
mac
will
not
allow
it
and
there
is
a
possibility
where
we
get
into
a
state
where
auto
updates
are
enabled
for
say,
like
linux.
Only
or
window
linux
and
windows,
essentially
like
auto
updates,
might
not
be
available
at
the
same
time
on
a
given
version
for
different
operating
systems.
A
A
Okay,
I'll
make
a
comment
of
that.
Also
do
we
are
we
tracking
the
the
blog
post
work
right
now
anywhere
in
an
issue.
A
Okay-
I'll
just
add
it
to
our
meeting
notes
here,
but
I
think
it
would
be
good
to
specifically
show
screenshots
in
the
blog
post
of
what
it
looks
like
to
start
on
a
mac
with
the
unsigned
binary
and
how
to
launch
it
anyway,
because
there
is
this
extra
step
there.
A
All
right,
oh
this
one
yeah
this
one
has
been
so
this
is
create
an
error
viewer
component.
There
is
a
branch
that
that
brian
lyles
had
created
a
while
back
that
has
implemented
some
of
this,
and
then
there
was
a
branch
that
sam
and
I
worked
on.
A
What
feels
like
ages
ago,
where
we
did
the
initial
terminal
work
that
actually
includes
some
of
this
work
as
well,
which
is
what
do
we
call
this
component?
It's
the.
A
Yeah,
so
essentially,
what
this
is
is
a
bar
at
the
bottom
that
can
slide
up
and
contain
tabs
it's
floating,
and
it
follows
you
throughout
the
application.
A
This
is
so
currently,
as
you
know,
we
log
everything
to
text
files
and
with
the
electron
application.
There
is
no,
you
know,
stream
of
that,
so
you
have
to
go
to
the
folder,
grab
the
log
file
and
and
inspect
it
there
or
open
a
shell
and
manually
tail
the
log
file
in
the
shell.
If
you
want
to
see
like
real
time,
logging
output
as
you're
running
octan,
so
the
goal
of
the
air
viewer
component
is
two
things.
A
It's
basically,
we
want
to
be
able
to
surface
log
level
things
so
info
warning
debug
and
be
able
to
have
those
controlled
through
the
application,
and
then
we
also
want
to
be
able
to
surface
your
like
the
cluster
errors
that
you
might
encounter
right,
like
you,
don't
have
permission
to
do
this
thing
being
able
to
highlight
that
in
a
in
a
better
way
like
a
a
more
under
human,
readable
fashion
of
like
hey,
you
got
a
you
got
an
access
to
night
error
to
deployments,
like
your
user
doesn't
have
permission
to
them.
A
That's
why
they're
not
showing
up
being
able
to
like
give
you
that
context
as
you're
using
octan,
is
something
that
this
error
component
will
help.
Do
we
have
taken
a
couple
passes
at
it
previously
and,
as
I
mentioned,
there
was
a
branch
there
was
a
branch
in
that
brian
had
created
that
I
think
still
lives
somewhere.
A
That
kind
of
has
half
of
this
work
completed
and,
and
anyway,
this
work
has
existed
in
various
forms
throughout
the
life
of
octane,
but
it
became
it
was
something
that
we
knew
was
going
to
become
even
more
important
when
we
were
in
electron
application,
and
you
no
longer
had
kind
of
like
that:
immediate
access
to
the
console
output.
So
that's
what
that's
what
this
work
represents.
A
Probably
if
I
had
to
guess
I
would
say
this
would
end
up.
A
Yeah,
I
I
think
we
can.
We
can
do
the
first
pass
of
this
as
as
an
internal,
but
if
it,
if
it's
relatively,
I
I
think
if
we
talk
about
the
api
about
this
and
we're
able
to
make
it
something
that
is
easy
for
plugin
authors
to
leverage,
then
I
think
I
think
that
would
be
good.
A
The
extension
view,
like
I
can
think
of
especially
like
the
aqua
security
plug-in
right,
like
they
would
probably
want
to
be
able
to
just
like
send
new
alerts
or
new
things
into
the
into
their
own
tab
in
the
extension
view
and
have
like
the
little
badge
that
says,
like
you,
have
five
things
that
are
not
in
compliance
or
something
like
that.
So
if
we
can
give
that
to
to
plug-in
authors
on
the
first
pass,
then
I'm
all
for
it.
A
If
we
want
to
do
an
internal
version
first,
so
we
can
kind
of
figure
out
what
the
api
looks
like
and
and
what
the
edge
cases
are
and
maybe
how
we're
going
to
interact
with
it
and
then
later
expose
it
to
plugin
authors.
I'm
fine
with
that.
B
A
Okay,
octane.
yeah,
so
this
is
this
is
also
very
important
and
you
know
I
feel
it
does
feel
crappy
to
let
this
like
to
let
the
doc
stuff
go
on
for
so
long,
but
also
like
limited
bandwidth.
Things
like
that.
But
I
am
it's
one
of
the
it's
another
one
of
those
things
that
gives
me
that
similar
feeling
to
watching
that
person
close
octant
because
they
thought
there
was
a
problem,
but
it
was
just
taking
a
long
time
whenever
I
I
start
to
go
into
like
the
various
areas
of
our
docs.
A
I
feel
kind
of
the
same
way
like
we're
on
the
right
path,
we're
getting
better,
but
it
just
still
needs
that
investment.
So
this
one
is
very
specific:
it
came
from
a
person
using
octant
for
the
first
time
they
went
to
our
docs
page,
and
I
can
I'll
actually
just
show
it
here,
so
they
were
like
well
I'll,
go
to
the
documentation
and
they're
like
oh
getting
started
cool.
A
A
The
getting
started
is
like
here
in
this
content
and
it's
and
then
you
click
that
and
now
you
end
up
at
the
the
getting
started
page.
That's
on
our
storybook,
so
they're
100
correct
that
that
is
a
bad
experience.
A
It's
I
when
I
came
to
this
page,
the
for
without
like
after
they
created
the
issue.
I
landed
on
this
page
and
I
was
like.
Oh,
I
wonder
what
they're
talking
about
and
then
I
clicked
here
and
I
was
like
oh
yeah
and
that's
what
they're
that's
exactly
what
they're
talking
about
so
yeah,
just
we'll
we'll
get
that
fixed
up.
I
do.
A
I
do
think
that
overall,
our
this
storybook
site
and
having
our
docs
in
this
in
this
storybook
here
is
a
good
experience,
but
it
does
divorce
it
from
actin.dev,
which
maybe
we
don't
want.
I
don't
know
I
I
do.
A
I
do
think
overall
that
having
our
our
component,
documentation
and
user
documentation
is
maybe
a
mix
of
concerns
and
and
we
need
to
have
very
user-focused
docs
on
octan.dev,
like
you
run
octant,
here's
here's
here,
here's
only
the
things
you
care
about
as
a
user
or
a
consumer
of
it
and
keep
our
reference
site
very
developer,
focused.
B
C
Yeah
I
mean,
like
the
you
know:
the
git
book
part
is
probably
not
relevant
here,
it's
more
like,
if
we're
struggling
to
figure
out
what
the
content
should
be.
Let's
just
write
all
the
content
that
is
in
our
brain
and
then
we'll
figure
out
where
it
should
live,
just
break
this
into
smaller
sub-problems,
instead
of
just
letting
it
rot
over
time.
A
A
Proj
the
documentation
project,
which
actually
does
have
some
smaller
kind
of
bite-sized
documentation
issues
the
audit
one
here,
which
has
been
outstanding
for
a
while,
I
think,
is
the
one
that
will
generate
the
most
of
like
what
you're
saying
sam.
Like
here's
all
of
the
things
we
have
in
our
head.
A
Okay,
let's
get
those
created
as
as
small
issues,
then,
let's
just
write
that
content
and
that's
what
I
kind
of
did
with
like
the
ad
getting
like
ad,
getting
started,
plug-in
ad
getting
started
for
go
like
those
are
just
like
ideas
I
had
in
my
head
about
what
would
be
nice
and
then
we
can
write
it.
Stick
it
somewhere
and
then
organize
it
like
it.
Existing
is
better
than
it.
Existing
unorganized
is
better
than
an
ex,
not
existing
at
all,
and
then
the
next
best
step
would
be
to
organize
it
right.
C
Right
also
to
clarify
for
those
who
are
not
in
vmware,
I
wrote
a
git
book
specifically
to
onboard
luis
and
it's
open
source
and
it's
available
publicly,
but
it
wasn't
really
intended
to
be
an
official
piece
of
documentation.
Plus
you
know
if
it's
just
kind
of
like
a
private
thing,
I
get
to
be
snarky
on
it.
So
like,
for
example,
like
I
have
a
resources
page
that
just
says
google.com
right,
it's
got
like
we,
it's
not.
You
know
like
some
of
it.
I
just
had
liberty
to
have
fun
with
it.
A
I
know
I'm
I
am
that
all
the
time
so
like
it's
impossible
for
me
to
not
be
no
yeah
and
that's
actually,
but
it's
a
great.
It
is
a
great
resource
that
we
want
to
get.
We
do
want
to
kind
of
that's
the.
What
would
you
say?
That's
like
the
the
bleeding
edge
docs
branch
and
we're
gonna.
We
want
to
take
that
and
and
get
some
of
that
stuff
merged
back
into
right,
our
main
our
main
documentation.
B
Useful
one
of
my
pet
peeves
and
the
dogs
area
is
that
that
should
be
pretty
low
hanging.
True,
that
there's
no
issue
and
I'll
create
one
just
maybe
there
is.
We
should
really
move
the
help
to
the
electron
menu.
Now
that
will
save
us
some
time
in
the
header
and
kind
of
help
consolidate
that,
and
that
should
be
hard
to
do.
A
I
don't
think
there's
an
issue
for
that.
I
do
I.
I
thought
there
was
a
design
issue
specifically
around
redoing
the
whole,
like
the
whole
menu
bar
and
header
anyway,
right
like
just
making
it
right,
electron
native,
essentially
and
removing
the
you
know
the
file
edit,
whatever
menus
and
putting
the
what
is
it
called
the
three
stack
thing:
it's
called
the
not
sushi
kebab
kebab
menu,
I
think,
or
something
or
no,
maybe
that's
the
three
dots
there's.
B
A
A
I
don't
know
there's
no.
I
don't
know
this
one's
stupid.
I
hate
this
one,
but
it
would
be
good
to
to
figure
it
out
because
it
causes
test
flight
that
is
annoying
and
then
we
have
to
rerun
things
and
it
it
creates
uncertainty
and
doubt
around
around
our
test
runner,
which
we
don't
want.
So
this
definitely
ties
into
the
whole
make
improving
our
testing.
A
A
Sam
and
I
talked
about
this
one
currently
yeah,
let's
see
I'll
play
this
screencast-
probably
see
it,
there's
some
shift
that
happens
in
the
layout
of
the
resource
viewer.
This
is
due
to
the
fact
that
there
is
no
root
node
in
the
resource
viewer.
A
So
what
happens
is
there's
two
go
routines
that
run
one
is
in
pod.
One
is
in
service.
They
both
call
this
visit
method
and
essentially,
whoever
gets
there
first
ends
up
as
the
root
and
because
then
it
just
becomes
a.
What
order
are
you
in
in
the
in
the
list
that
we're
sending
over
the
stream?
A
So
we
don't
actually
flag
or
make
explicit
the
root
node?
So
this
is
just
about
okay.
What
what
is
it?
What
does
it
mean
to
do
that?
What
are
the
implications
of
doing
something
like
that?
Can
we
like?
Can
we
just
say
like
hey,
you're
the
root
and
it's
okay
and
we
don't
have
to
run
these
things
in
in
separate,
go
routines
or
do
we
run
them
in
separate,
go
routines,
but
with
some
type
of
of
sync
between
them,
so
that
they're
they're
more
dependent?
A
But
then,
if
you
do
that
you
kind
of
lose
the
the
concurrency
right,
the
yeah
you
lose,
the
concurrency
aspect
of
them
running
in
separate,
go
routines
that
can
get
their.
You
know
time
on
the
cpu
managed,
so
this
one
is
it
is.
It
is
super
annoying
when
you're
viewing
something
in
the
resource
viewer
and
it
all
of
a
sudden
flips
on
you,
like,
especially
with
larger
this
will.
This
will
happen
in
larger
resource
resource
views
as
well,
where
it's
like
it's
kind
of
spreading
across
the
screen.
A
You're
looking
at
and
all
of
a
sudden
just
goes
and
like
the
thing
you
were
looking
at
is
now
somewhere
else
and
you're,
so
yeah
pinning
that
down
would
be
good.
I
think
I
think
it's
it's
work
that
can
happen
independent
of
the
resource
viewer
design
work,
because
this
is
more
about
generating
that
that
that
tree
and
and
there
that
graph
and
pinning
you
know
what
the
root
is
and
and
making
it
deterministic
again.
It
comes
back
to
like
similar
to
the
dashboard
list.
Call
right
making
things.
Deterministic
is
important,
so.
C
Yet
currently
we
through
the
traversal,
say
synchronously,
which
is
the
problem
right
so
like
it's
very
difficult
to
think
about,
like
any
synchronous
traversal
of
a
graph,
but
there
isn't
really
a
reason
why
it
just
can't
be
synchronous
because,
like
the
what
is
the
biggest
possible
like,
even
if
the
graph
is,
has
a
hundred
nodes
right,
like
it's
still
supposed
to
be
relatively
quick
like
there
like,
there
is
an
expected
upper
bound
here
so
like
we
don't
have
to
make
this
asynchronous
if
it
makes
it
easier.
A
A
So
this
one
actually
came
up.
Scott
scott
rosenberg
brought
this
issue
up
when
he
was
testing
out.
The
nightly
builds
of
the
electron
application
so
currently,
there's
like
a
kind
of
a
this
is
when
you
upload
a
cube
config
when
you
start
octane
without
acute
config,
it'll
prompt
you
and
then,
when
you
upload
a
config
it'll
place
that
into
temporary
location
so
that
it
can
use
it.
You
know,
hydrate
a
a
cluster
client
and
use
it
for
the
for
the
life
of
octane.
A
The
problem
is:
is
that,
as
as
scott
pointed
out
here,
where
that
file
ends
up
going
is
is
difficult
to
to
find
out
and
to
get
to,
and
it's
yeah
it's
just
it's
just
cumbersome
and
it's
as
he
pointed
out,
it's
not
trivial
for
a
lot
of
people
to
find
it.
A
So
what
we
did
is
we
we
made
it
so
that
for
right
now
it
just
uses
that
when
you,
when
you
open
the
view
logs
folder,
that
same
folder
is
where
our
temporary
stuff
is
going
to
get
stored
in
the
future,
we'll
will
do
a
better
job
of
actually
having
like
a
proper
cube.
Config
management
experience
in
place,
and
so
this
issue
is,
is
essentially
going
to
be
the
epic
behind
okay.
What
does
cube
config
management
look
like
in
octant
now
that
we're
in
electron
land?
A
It's
not
necessarily
the
implementation
of
that,
but
it
is
the
start
of
of
that
research
and
thought
and
design,
and-
and
so
that's
why
it's
it's.
Why
it's
a
little
lower
in
priority,
because
you
know
it's
okay,
if,
if
this
slips
essentially
so
it's
like
well
put
it
lower,
because
if
it
slips
it's
okay,
but
it's
it's
something
we'll
want
to
work
with
isha
on
and
talk
to,
users
about
and
just
use
our
own
experience
of
like
what
would
be
nice.
A
What
what
is
what
is
useful,
how
how
should
how
should
config,
cubeconfig
handling
and
octane
kind
of
work?
More
generally,
maybe
extracting
that
behavior
out
to
its
own
package
that
then
octant
just
uses
and
says
like
we,
we
have
a
bunch
of
opinions
on
what
the
cubeconfig
lifecycle
looks
like
for
something
that
needs
to
use.
One
we've
captured
those
opinions
in
a
package
and
now
oxent
uses
that
package
to
do
its
cube.
A
Config
management,
right,
like
this
to
me
is,
is
the
is
kind
of
the
natural
progression
here
of
like,
instead
of
just
putting
in
another
or
about
to
be
a
time,
instead
of
putting
in
another
thing
that
just
like
pops
up
and
shows
a
user
whatever,
like
actually
taking
the
time
to
properly
address,
keep
config
management.
A
Yeah,
so
we
made
it
through
most
of
the
list.
We
are
at
time,
so
I
apologize
I'm
not
going
to
I'm
not
going
to
keep
the
meeting
going
longer
than
the
hour,
so
we
will.
We
did
make
it
through
a
big
portion
of
the
list.
A
If
there
are
things
that
you
would
like
to
see
in
audit
18
that
did
not
make
this
list,
please
add
them
to
the
markdown
doc
or
thumbs
up
them
in
the
issue
list
or
comment
on
them
raise
them
in
the
slack
channel.
You
know
all
the
ways
to
get
a
hold
of
us
and
if
you
don't
all
of
those
ways
are
on
octan.dev
on
our
community
page
so,
and
that
is
the
hour.
So
thank
you,
everyone
for
your
time.
I
really
appreciate
it
and
we
will
see
you
next.