►
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
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
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
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
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
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
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
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
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
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
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
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.