►
From YouTube: Octant Community Meeting - August 19th, 2020
Description
August 19, 2020
Agenda
- What does it mean for Octant to be 1.0?
- Plugin Update
- JavaScript API plugins will be receiving significant engineering investment.
- Go API plugins will be getting security related fixes only for the time being.
- New components will still work with both APIs.
- Web Component, component.
- Electron Application
- We will be investing in to fixing and adding the features needed to make Electron the default runtime for Octant.
- Octant moving to go 1.15 - reminder to run `go run build.go go-install`
- Need for speed
A
All
right
welcome
everybody
to
the
august
19th
2020
octant
community
meeting.
Today's
agenda
is
an
interesting
one.
We're
going
to
be
covering
kind
of
the
direction
of
where
octant
is
is
headed
and
it's
kind
of
summarized
that
we,
we
held
a
little
mini
octane
engineering
summit
early
this
week
and
we
wanted
to
use
the
community
meeting.
A
That
was
on
monday,
where
we
just
kind
of
talked
about
all
these
various
things
about
octane,
1.0
and
plug-ins,
and
the
electron
app
and-
and
so
we
just
wanted
to
summarize
kind
of
what
all
that
meant
and-
and
then
I
think,
we'll
be
talking
about
the
update
of
moving
octant
to
go
115
and
then
there'll
be
some
some
q
after
that,
so
to
get
started.
A
One
of
the
the
the
oh
kind
of
the
over
arching
idea
from
the
engineering
summit
was,
what
does
it
mean
for
octant
to
be
1.0,
and
the
consensus
that
we
landed
on
was
that
the
the
the
part
of
octant
that
really
needs
to
be
versioned
is?
Is
the
plug-in
api
and
so
octant
1.0
isn't
necessarily
any
set
of
specific
features?
A
It's
more
about
the
plugin
api
and
having
that
plugin
api
be
an
api
that
we
are
happy
with,
and
one
that
we
are,
you
know
going
to
be
supporting
and
ensuring
is
in
in
good
condition.
You
know
between
versions,
so
that
led
to
a
bigger
discussion
around
plugins
and
and
what
does
the
1.0
api
look
like,
and,
and
so
we
talked
about
the
javascript
plug-in
api
and
decided
that
we're
going
to
continue
to
that
initially
started
off
as
like
an
experimental
proof
of
concept.
A
It
has
since
started
to
be
used
for
plug-ins
and
is
it's
turning
out
to
be
very
a
very
nice
development
flow.
It
does
lack
in
some
things
that
the
go
api
currently
has,
but
we're
going
to
be
putting
in
some
significant
engineering
investment
into
the
javascript
plugin
api.
A
A
Brian
lyles
did
some
work
on
auto,
generating
some
of
these
components
and
then
we're
also
just
going
to
you
know,
increase
the
the
kind
of
the
usefulness
of
the
helpers
and
other
things
that
we
have
within
the
javascript
api
on
the
typescript
side
of
things
on
the
octane
side
of
things,
the
the
actual
api
that
we're
used
to
of
like
here's,
a
printer,
here's
a
object
status,
here's
a
tab
handler
those
types
of
things.
A
A
They
may
change
in
a
way
that
breaks
plug-ins,
but
we
will
be
very
sure
to
you
know
note
that
help
people
migrate,
ensure
there's
a
path
to
migrate.
If
we
do
break
things.
The
reason
I'm
saying
this
is
because
there
was
there's
some
discussion
around
making
sure
that
the
way
octant
draws
things
on
the
screen,
the
so
how
it
implements
its
modules
and
how
it
implements
its
describers
uses
the
same
api
that
plug-ins
use
right
now.
A
We
kind
of
sidestep
the
plugin
api
and
we
just
directly
pass
in
all
of
the
object
stores
and
and
the
websocket
clients
and
all
the
all
those
things
we
just
pass
them
directly
into
our
describers.
A
So
we
the
reason
we
want
to
shift
towards
making
octant
use
the
same
api
that
plug-ins
are
using
is
because
it
will
ensure
a
richer
set
of
features
becomes
available
for
plugins,
and
it
will
enable
octane
to
then
function
in
a
way
that
you
could
essentially
remove
the
core
view
like
you,
could
completely
remove
the
core
views
from
octan
and
have
only
your
plug-in
views.
If
you
wanted
something
like
that,
so
it
just.
A
It
provides
a
lot
more
flexibility
and
and
what
plug-ins
will
be
able
to
do
by
us
kind
of
dog
fooding
that
plug-in
api
for
our
own
internal
views.
Now
that
said,
that
means
that
the
go
plugin
api
will
continue
to
exist.
It's
not
going
to
go
anywhere,
it's
just
we're
going
to
be
putting
less
of
a
of
an
investment
in
it
for
the
time
being,
because
we
really
want
to
get
this
javascript
plugin
api
fully
fleshed
out
and
and
have
people
kind
of
moving
towards
building
their
plugins.
A
In
that
way,
there
will
still
be
a
go
plugin
api,
all
the
like
the
existing
go
plugins
will
still
compile
against
it
and
and
that's
likely
what
we
are
going
to
use
at
least
initially
internally
for
octan
is
the
is
the
go
api
for
for
the
internal
views
that
will
now
be
written
to
the
plugin
api.
A
A
A
So
you
don't
have
to
like
it.
We're
we're
not
fully
deprecating
the
go
api
with
four
plugins.
At
this
point
I
don't
know,
we've
talked
about
it
we
might
in
the
in
the
far
future,
but
if,
if
we're
going
to
we'll
make
that
decision
before
1.0,
but
as
I
see
it
right
now,
I
don't
think
that's
going
to
happen.
A
The
other
thing
with
plugins
is
we
really
want
to
get
some
form
of
a
web
component
component
in
place
and
and
what
that
means
is
being
able
to
send
up
your
own.
You
know
you've
built
out
a
component
of
you.
A
It
has
diagrams,
it
has
charts
whatever
it
is
right
being
able
to
then
use
that
in
a
view
in
octane
right
now,
if
octane
doesn't
have
a
component
baked
into
it,
you
either
have
to
do
some
really
like
you
can
do
an
iframe
and-
and
you
know,
hook
up
your
plug-in
to
an
external
api
that
does.
A
You
know
rest
calls
to
a
third
part
to
like
a
completely
separate
service
that
you
load
in
as
an
iframe
right,
and
that
that's
one
way
to
like
ship
data
and
have
it
show
an
auction.
But
it's
really
not
convenient.
It's
not
a
great
pattern.
So
we
would
like
to
enable
the
ability
for
plugins
to
be
able
to
build
out
this
idea
of
so
there's
web
compo
terms
are
so
overloaded
in
the
world,
but
there's
web
components
which,
like
are
these
javascript
runtimes.
A
That
can
run
in
a
browser
as
a
web
component
like
if
you
look
up
web
components
on
the
like
mozilla
right,
but
then
there's
web
component,
which
will
be
our
like
other
octant
components,
which
would
be
our
web
component,
which
will
be
the
config
and
json.
A
You
know
setup
that
will
generate
such
a
component
so
that
that,
when
we
say
web
component
it
it's
the
octane
version
of
a
web
component
which
may
be
implemented
as
a
browser
web
component
or
it
may
not
be
to
be
determined
if
we
don't
even
know
what
that
is
going
to
look
like.
Yet
it
may
also
be
something
where
we
just
allow
you
to.
A
We
may
say
something
like
you:
can
do
angular
components
and
you
register
angular
components
and
that's
what
we
support
right.
We
don't
support
free
form,
whatever
javascript
library,
you
want
components,
we
support
angular
components
or
something
like
that.
So
we'll
we'll
figure
that
out
as
we
as
we
go
along
the
the
next
thing
is
the
electron
application.
This
is
something
that
has
been
sitting
there
for
a
while
kind
of
gathering
some
dust.
A
We
talked
about
it
and
we
really
do
want
to
invest
in
fixing
and
adding
the
features
we
need
to
make
electron
the
default
runtime
for
octan.
So
you,
you
know,
you
double
click
it
and
you
get
you
get
a
nice
application,
no
more
proxying
via
proxying
the
view
via
the
browser,
so
that
will
be
coming.
We're
probably
gonna
phase
it
in.
A
I
don't
know
how
we're
gonna
phase
that
in
for
the
release
manager,
tools
like
chocolaty
and
brew,
because
we'd
either
have
to
do
it
as
a
separate
and
sam
might
be
able
to
answer
this.
I
don't
know
if
it
can
install
both
the
ui
version
and
the
the
console
version,
because
initially
we're
planning
to
ship
both
and
then
eventually
we'll
just
ship,
the
ui
one
or
the
electron
one.
I
should
say
they're,
both
ui
and
but
I
don't
know
how
that's
gonna
work
in
our
package
managers.
B
B
Have
to
just
end
up
switching
package
managers
all
together
same
thing
with
scoop,
so
we
would
probably
even
just
lose
support
for
scoop
altogether
and
I
think
chocolaty
is
fairly
flexible.
It's
nothing
should
change
there,
but
we
would
have
to
significantly
rewrite
the
powershell
scripts
that
pretty
much
right
now
just
download
from
github
releases,
and
it
might
have
be
a
little
bit
more
complex.
A
Okay,
yeah
so
we'll
be
figuring
that
out,
but
expect
to
see
that
coming
and
expect
to
see
some
changes
we'll
be
sure
to
clearly
communicate
kind
of
what
the
new
install
steps
are
and
what
to
expect
as
we
as
we
start
to
roll
that
out,
and
then
one
of
the
final
things
on
here
that
we
wanted
to
call
out
is
that
we're
moving
auctions
over
to
go
1.15
and
that
will
require
a
reinstallation
if
you're,
if
you're
doing
any
dev
work
for
octan.
That
will
require
reinstallation
of
the
of
the
tools.
A
There's
some
new
binaries
that
that
are
new
versions
of
binaries.
That
will
need
to
be
installed
for
everything
to
work
successfully.
So
just
wanted
to
call
that
out.
I
think
sam
or
scott
put
that
one
in
there
and
finally,
so
that
so
that's
the
did
sam
or
scott
any
questions
on
that
on
that
stuff
that
we
just
covered
there.
B
No,
nothing
stands
out.
I
think
we
probably
just
need
to
update
the
roadmap
with
this
information
in
the
github
repo
and
I
think,
there's
also
some
tangential
things
which
doesn't
necessarily
imply
1.0
things
like
runtime
performance
like
speed
or
even
just
adding
some
of
the
new
layouts
that
we
discussed
it
doesn't
have,
it
doesn't
fit
under
the
umbrella
of
1.0
or
it
doesn't
necessarily
have
to
be,
but
I
think,
there's
going
to
be
things
that
will
end
up
hitting
on
the
way
there.
A
Yeah,
I
think
that's
a
good
call
it
actually,
and
I
can
we
can
touch
on
some
of
that
quickly.
Right
now,
I'll
just
add
a
line
in
here
on
the
name
for
speed.
So,
as
sam
mentioned,
we
discussed
speed
and
and
specifically
that
octane
kind
of
renders
stuff
a
little
slow.
You
know
when
you,
when
you're
looking
at
a
large
cluster
with
a
lot
of
resources-
and
you
load
that
overview
page
it
is,
it
can
take
a
long
time
you
can
like
on
a
very
large
cluster
I've.
A
I've
had
it
take
upwards
of
20
seconds,
where
you're
just
sitting
there
watching
a
spinner
and
that's
not
that's,
not
acceptable,
and
so
brian
lyles
did
a
lot
of
research
in
this
area,
and
sam
has
done
research
in
this
in
this
area
as
well,
and
what
what
ultimately,
what
they
both
found
at
this
separately,
but
they
they've
kind
of
both
landed
at
the
same
place,
was
that
our
speed
issue
comes
from
the
front
end.
A
The
way
we
the
way
we
render
angular
stuff
and
the
way
clarity
renders
the
data
grids
specifically
is
kind
of
slow
and
a
data
gr
a
like
an
empty
data
grid
it
renders
in
like
10
milliseconds,
but
a
data
grid
with
data
it
instantly
jumps
up
to
about
100
and
then
any
other
data
grids
on
that
page
are
additive.
A
So
if
you
have
10
data
grids
on
a
page
that
all
have
content
you,
don't
they
all
don't
render
in
100
seconds
it's
because
they're
not
they're
not
being
rendered
out
in
like
a
multi-threaded
fashion
and
then
displayed
there.
This
one
renders
then
the
next
one,
then
the
next
one.
So
you
end
up
with
10
data
grids.
Taking
you
know
now
at
100
milliseconds,
each
year
at
a
thousand
milliseconds.
A
So
you
start
to
do
more
data
grids
with
more
data
and
they
they
can
get
very,
very
slow
and
so
we're
looking
at
some
solutions
around
how
to
do
those
faster.
There's.
There's
a
couple
ideas
oh
and
to-
and
this
is
interesting-
so
we
we
did
look
at
the
back
end
just
to
just
to
see
like
how
long
it
was
taking
and
when
you
make
these.
These
requests
to
the
kubernetes
api,
even
on
a
very
large
cluster.
If
it's
the
first
time
you're
making
the
request.
A
A
I
I've
I've
yet
to
see
a
request
even
on
a
large
cluster,
unless
it
was
general
api
slowness
take
longer
than
five
seconds
to
get
all
of
the
data
back
to
octan
and
then,
after
that
five
second
period,
there's
the
draw
phase
and
that
takes
15
16
17
seconds
and
then
once
all
those
caches
are
warm
and
we
have
that
set
of
data
octane's,
usually
returning
the
response
to
the
browser
in
a
second,
sometimes
a
little
less
and
then
on
small
clusters.
It's
it's
very
very
fast.
A
You
know
we're
trying
milliseconds.
So
the
fact
that
it
takes
five
seconds
to
get
all
of
the
data
back
and
then
three
times
as
long
to
draw
on
the
page
is
is,
is
a
problem.
So
the
one
of
the
solutions
was
potentially
write.
Our
own
data
grid.
That's
something
we're
thinking
about
another
one
is
make
it
feel
faster.
Basically,
you
know
load
the
data
grids
empty.
So
now
now
you
know
all
10
data
grids
take
the
when
you
load
them
empty.
Well,
it's
an
interesting
thing
when
they
load
empty.
A
If
you
put
10
empty
data
grids
on
the
page,
it
still
draws
them
in
order,
but
you
know
you're
10
milliseconds
each
so
now
it's
100
milliseconds
to
load,
10
data
grids,
and
then
you
can
do
it
like
a
set
timeout
or
some
type
of
callback
to
then
load
the
data
into
them.
A
Instead
of
this
long
wait
of
nothing,
no
response,
I
can't
scroll,
I
don't
even
know
what
is
about
to
happen,
so
so
that's
like
one
of
the
the
short
term
options
of
just
like
tricking
it
into
feeling
a
little
faster
and
then
also
the
potentially
this
kind
of
overlaps
with
writing
your
own
data
grid,
but
moving
from
data
grid
to
clarity,
table
and
then
implementing
three
features
on
clarity
table
that
would
so
just
to
scope
this
little.
A
We
know
the
the
specific
features
of
datagrid
that
we
need,
so
we
can
throw
all
the
other
ones
away
and
only
implement
the
ones
that
are
important
to
octan
and
by
using
the
table,
render
engine
and
then
implementing
only
those
things
that
we
need.
We
get
renders
a
lot
faster
tables,
even
tables
with
data
render,
in
the
same
amount
of
time
as
an
empty
data
grid.
It's
like
it
is
crazy.
How
like
browsers,
are
so
optimized
to
render
that
table
tag.
It
is
crazy
how
fast
the
the
they
render
that
stuff
so
anyway.
A
Cool
now
on
to
the
q
a
so
this
one
was
what
should
happen
when
someone
is
viewing
an
object
being
deleted.
A
So
there's
a
pr
currently
opened,
which
is
here
it's
yeah
here
it
is
so
what
this
one
is
doing
is
and-
and
this
will
give
you
some
background
and
then
we
can
go
into
the
discussion.
We
were
talking
about
this
briefly
at
our
stand
up
so
right
now
in
octet,
when
you
delete
a
resource,
what
happens?
Is
it
just
kind
of
redirects
you
up?
There's,
no,
you
don't
get
informed
that
something
has
been
deleted.
You
don't
get
any
anything
like
that.
A
You're
just
redirected
up
and
and
the
thing
you
were
looking
at,
went
away
and
depending
on,
where
you're
at
in
the
hierarchy
that
redirect
up
maybe
up
to
an
overview
page
or
maybe
so
like
it
can
be
very
jarring,
all
of
a
sudden
you're
looking
at
this
thing
and
you're,
and
then
it
gets
deleted
and
now
all
of
a
sudden
you're
staring
at
an
overview
and
you're
like
how
did
I
get
here?
A
So
the
idea
is
to
make
that
experience
a
little
more
gentle
and
kind
of
inform
the
user
of
what
is
going
on
that
the
thing
is
no
longer
there
and
there
was
some
discussion
going
on
back
and
forth
about
what
should
that
look
like
and
what
would
be
the
most
useful,
and
so
that's
where
we're
at
right
now.
So
I
I
think,
sam
you
might
have
added
this
question.
B
Yeah-
and
we
spoke
a
little
bit
earlier
today
at
our
internal
stand
up,
but
I
can
reiterate
the
information
here
so
the
special
case
about
this
one
is
for
pods,
where,
because
of
the
fact
that
pods
generate
a
new
name
every
time
when
you're
deleting
and
recreating
a
new
one.
Originally,
this
was
motivated
by
scaling.
B
B
We
might
have
to
handle
that
particular
case
differently,
but
I
think
generally,
I
think
the
the
404
page
should
be
sufficient
most
for
most
of
our
at
least
yeah.
For
most
of
the
other
cases,
I
think
the
other
one
might
worth
investigating
is
a
namespace
where,
if
you
are
viewing,
if
you
are
yeah
like,
if
you
are
viewing
a
or
if
you
were
actually
in
the
namespace
and
that
namespace
is
deleted,
where
does
that
bring
you
back
to.
A
A
I
think,
and
one
of
the
things
that
I
commented
was
that
I
think
that
plugin
should
have
the
ability
to
set
that
page
and
the
reason
is,
I
can't
type
and
talk
at
the
same
time.
The
reason
is
because
in
in
the
case
that
sam
is
referring
to
where
you
have
something
like
like
a
a
serverless
tool
or
like
k
native,
that's
scaling
things
down
to
zero.
You
could
a
k
native
plugin
could
implement
a
not
bound
handler
for
pods,
and
then
it
would
be
able
to
get
that.
A
It
would
be
able
to
know
that.
Okay,
I
this
pod,
that
I
was
that
that
came
in
or
maybe
it
wouldn't
be.
I
don't
know
because
it's
it's
the
pod
is
gone
right,
so
I
guess
it's
really
like
like
what
what
can
it
do
like
and
I
don't
know
enough
about
it,
but
maybe
it
could
go
into
the
history
like
into
its
eventing,
not
eventing
logs.
What
am
I
I
could
find
that
that
thing
was
yeah
events.
A
It
could
find
that
the
thing
was
used
to
be
a
part
of
it.
It
got
scaled
down.
I
I
know
that,
there's
the
there's
a
there's
a,
I
see
the
alerts
all
the
time.
A
I
just
don't
know
how
you
would
do
it
in
a
plug-in,
but
I
think
it
would
be
possible
right
to
say
like
I
handle
this
and
then
you
get
a
not
found
for
a
pod
v1
and
then
you
could
take
the
pod
name
and
you
could
go
look
up
previous
pods
and
from
a
service
like
or
all
the
maybe
you
can
find
it
somewhere
somehow
and
know
that
it
had
been
scaled
and
then
provide
a
useful
message
that
says:
you're
viewing
a
pod
for
service
a
it
has
been
scaled
down
to
zero
due
to
inactivity,
something
like
that.
A
That
would
be
cool.
Don't
I
don't
know
how
it
would
be
done,
but
it
would
be
really
cool
yeah
and
I
think
I
think
the
yeah,
the
404
page
or
not.
It's
really
not
404.
It's
not
found
it's
different,
404
like
page,
which
is
a
good
description
that
that
scott
was
working
on,
I
think,
is
a
good,
a
good
first
step.
It's
it's
generally
more
useful
than
what
we
have
now,
which
is
redirecting
up,
and
it
also
for
things
that
do
have
a
static
name
or
that
are
likely
to
have.
A
You
know,
be
deleted
or
recreated
you.
You
know
the
in
this
example
that
we're
looking
at
here
in
the
browser
is
a
config
map,
but
you
know
you,
you
create
a
config
map,
your
pod
says:
oh,
it's
wrong,
you
come
and
then
you're
in
some
other
tool.
That's
you
know
it's
it's
coming
from
github
or
somewhere,
and
so
you
go
make
the
commit.
You'll,
see
it
depending
on
the
tool
you're
using
it
might
delete
things
and
recreate
them,
and
now
you'd
still
be
able
to
see
it
right.
A
It
would
bounce
to
not
found
and
then
it
would
come
back
so
yeah.
I
think
that's,
I
think,
that's
useful.
I
I
like
this.
This
change
and
I
also
think
scott
did
a
did
a
thing
where
he
put
in
a
fun
random
octan,
so
it
just
fetches
octant
thing
from
wikipedia
which
I
think
which
I
like
a
lot.
It's
I
like
things
that
do
that.
So.
A
Yeah
yeah,
exactly
I'm
like.
Oh
that's,
it's
it's
professional
right!
There!
That's
nice!
It's
it's!
It's
caring!
You
know.