►
From YouTube: Octant Community Meeting - June 24, 2020
Description
June 24, 2020
Agenda
Plugin Discussion
Problems:
Must build binary for each platform.
No hot reloading.
No runtime discovery/registration.
DashboardClient is namespaced.
https://github.com/bloodorangeio/octant-helm/blob/master/pkg/plugin/views/root.go#L35
Delete Actions from Plugins
https://github.com/vmware-tanzu/octant/blob/master/pkg/action/doc.go
Idea: Public gRPC plugin interface
Ensure that writing to the gRPC interface with Go is just as easy as it is now with the integrated Go plugin library.
Export Go to TS gRPC?
Idea: Local plugins are TypeScript
It was attractive that the plugins could just be written in Go.
Ensure we don’t lose this ease of writing a Go plugin.
Idea: Provide a NamespacedClient and ClusterClient
Ideas about accessing resources
SubjectAccess rules/checks and API interactions.
https://github.com/wwitzel3/subjectaccess
https://github.com/bryanl/clientkube
Drafting a proposal, will have a PR up by EOW.
In-Cluster Challenges
Informers
Global Client
Global Plugins
Demo: no kubeconfig
Open Q&A - add your questions here
The current roadmap vs. where Octant is now has some drift, do we want to update that? When are we at 1.0?
Yes. Let’s update the roadmap.
We are still missing some of the core things that really will make Octant 1.0. Finalize plugin interfaces. Finalize resource viewer. Electron application. In-cluster.
A
B
B
There's
no
high
reloading
of
plugins.
So
if
you
make
an
update
or
change
or
want
to
install
a
new
one,
it
doesn't
do
that
right
now
you
have
to
stop
octane
there's,
also
no
runtime
discovery
or
registration
of
plugins.
So
when
a
user
does
put
a
plugin,
maybe
they
don't
have
it
already?
There's
no
way
to
do
that
and
then
currently
the
dashboard
client
is,
is
namespace
to
the
to
the
current
active
namespace.
So
there's
no
easy
way
to
get
a
cluster
level
like
do
cluster
level,
queries
and
and
get
to
cluster
resources.
B
So
some
of
the
ideas
that
we
are
thinking
about
doing
with
plugins
is
so
the
first
idea
to
kind
of
solve
this.
No
hot
reloading
and
no
runtime
discovery
registration
is
to
actually
make
the
plugin
grpc
interface
a
public
interface
right
now.
It's
currently
controlled
by
go
plug-in
and
it's
an
internal
interface
that
gets
created
and
established
between
octan
and
the
plug-in,
with
octane
kind
of
being
the
plug-in
manager
and
launching
that
plug-in
at
runtime.
B
B
There
would
be
no
requirement
that
they
would
be
on
the
on
the
local
machine,
even
so
that
that's
that's
idea.
Number
one
moving
through
to
idea.
Number
two
is
that
local
plugins
would
be
typescript
based
and
those
would
just
be
able
to
be
distributed
to
all
platforms,
because
they
would
just
be
in
typescript
and
again,
there
would
still
be
octant
management
around
these,
so
you
could
just
drop
in
your
typescript
file
and
octant
would
create
and
establish
the
all
the
necessary
grpc
things
to
facilitate
it.
B
Client
that
allows
things
like
querying
the
cluster,
for
you
know,
rbac,
stuff
and
node
information
and
things
that
you
can't
really
query
query
using
the
namespace
client
for
right
now
to
do
kind
of
that
type
of
thing.
You
have
to
create
your
own,
your
full,
like
client
from
config,
cube,
client
and
and
do
a
bunch
of
stuff.
So
we
want
to
enable
plugins
to
be
able
to
take
advantage
of
the
fact
that
octant
will
manage
all
of
the
client
for
you
and
it
will
create
the
client.
B
It
will
give
you
the
right
client,
depending
on
the
user,
and
it
will
pass
those
to
you.
So
you
can
execute
queries
against
the
cluster
we
want
to.
We
want
to
really
strengthen
that
interface
and
make
it
so
that
plugins
don't
need
to
go
out
and
create
their
own
clients
to
get
things
done,
and
so
that's
kind
of
the
high
level,
the
high
level
of
what
of
some
ideas
we're
floating
around
with
with
plugins
and
josh.
B
For
folks,
who
don't
know
was
the
is
the
maintainer
and
was
the
author
of
the
helm
plugin
for
octane,
which
actually
turned
out
to
be
a
very
popular
plugin
that
people
use.
We
see
a
lot
of
folks
using
it,
so
I
invited
him
here
to
kind
of
get
get
a
get
a
pulse
on
on
his
feelings
and
and
just
his
input
on
plug-in
stuff.
C
No,
I
I
appreciate
you
reaching
out
to
you
know
to
talk
about
this
stuff,
so
I
I
will
say,
like
part
of
what
was
very
attractive
to
me
about
developing
on
octant,
was
that
you
could
write
these
plugins
using
go
versus
like
a
typescript
type
thing
and
that
the
entire
front
end
itself
was
the
entire
front.
End
was
essentially
able
to
be
developed
using
the
go
language,
and
I
get
that
you
know
I
think
for
the
end
user.
C
They
don't
care
so
much,
but
as
like
a
as
like
the
actual
developer,
like
it's
just
an
enjoyable
experience,
so
I
didn't,
I
didn't
find
it.
You
know
dreadfully
painful
to
distribute
the
binaries
for
these
on
different
platforms.
So
I
know
that's
the
first
thing
you
have
in
the
problems
bullet
like,
but
I
get
how
for
an
end
user
that
might
be
challenging
unless
octan
had
some
sort
of
package
management
solution
built
in
the
hot
reloading.
C
I
think
that's
an
interesting
that
that's
an
interesting
topic
like
I
had
put
together,
and
I
know
like
wayne
and
sam,
like
I
shared
like
a
script,
I
had
that
did
hot
reload
did
hot
reloading.
Just
in
bash,
but
I
think
that
that's
something
that'd
be
cool
to
be
built
into
octane
as
well.
But
I
don't
think
that
that
really
requires
changes
to
the
way
that
you're
doing
plugins.
C
C
For
me,
it's
more
about
the
exposing
like
right
access
and
unnamed
space
calls.
So
maybe
the
grpc
interface
thing
would
be
something
that
helped
that
helps
with
that.
But
honestly,
like
I'm,
going
to
write
the
thing
and
go
anyway
and
I
kind
of
like
the
way
it
already
works
so
that
that's
all
I
have
to
add.
B
So
so
like
in
case
for
for
in
this
instance,
the
helm
plug-in
right.
The
the
only
thing
that
would
change
for
the
helm
plug-in
would
be
the
probably
the
main
call
where
you
calls
serve
right,
like
the
like.
Instead
of
calling
that
internal
serve
that
go
plug-in,
has
it
it
would
likely
be
some
serve
or
expose
or
register
thing
that
octan
has
right,
and
that
would
be
like
the
main
difference
there.
So
yeah.
Okay,
then
no,
that's
great!
That's
great
feedback!
I
like
I
like
to
so.
B
The
these
problems
were
were
from
some
other
plug-ins,
like
the
there
was
a
techton
plug-in
that
folks
are
working
on
that
they
opened
some
issues
against
the
octane
repo.
There
was
the
atrina
plug-in
and
there's
the
aqua
security
plug-in
and
your
plug-in
all
of
those
are
those
are
like
the
most
popular
octa
like
the
largest
octane
plug-ins
and
the
most
popular
ones,
and
so
that's
where
this
list
was
kind
of
compiled
from
and
the
dashboard
client
is
namespaced
one
on
18
was
was
the
one
that
I
extracted
from
your
issue
around.
C
C
C
C
Yeah,
so
you
can
see
like
this
is
I'm
listing
so
how
releases
are
stored
in
secrets,
with
a
specific,
like
you
see,
at
a
selector
owner
home
yep,
I
I'm
pretty
sure
that
that
was
listening
across
namespaces
last
time.
I
checked.
Okay,
obviously
like
I
know,
octant
has
that
drop
down
of
name
spaces,
and
it
would
be
helpful
because
in
helm3
you
can
actually
segregate
releases
by
namespace,
so
that
would
actually
be
helpful
to
have
namespace
client.
C
I
think
what
the
issue
is
like
if
you,
if
you
go
to
the
queue
or
the
issue
queue
for
this
plugin,
like
the
one
issue
I
opened
was.
I
want
a
button
to
delete
releases
and
then
it
would
also
be
nice
to
maybe,
like
you
know,
I
don't
I
I
don't
know.
I
know
it's
not
really.
I
know
octan
is
all
about
like
visibility
and
less
about
like
making
edits
and
changes
to
your
cluster.
So
maybe
we
just
drop
that
concept
but
having
any
type
of
write
access.
C
C
B
Yeah,
so
we
have,
we
have
delete
internally
to
octane.
The
dash
client
does
not
currently
expose
delete,
but
that's
something
that
we
can.
It
just
hasn't
been
piped
through.
So
that
is
something
that
we
would
be
able
to
pipe
through
to
the
public
interface,
so
that,
because
right
now,
I
think
we
have.
We
have
list,
get
update
and
create
and
create
was
the
most
recent
one
we
added
so
extending
that
to
support
delete
would
not
be
a
hard
thing
now
that
we
support
it.
On
the
back
end,.
C
D
C
B
Yeah,
thank
you
yeah
and
the
other
thing
I'll
I'll
toss
a
link
in
here.
So
we
extended.
This
is
relevant
to
what
you're
talking
about.
We
extended
the
ability
to
add
custom
actions
and
and
documented
an
example
of
doing
that
for
for
plugins,
obviously,
we'll
still
have
to
add
the
delete
call
to
the
public
interface,
but
this
this
would
allow
you
to
create
custom
custom
buttons
within
your
plugin.
That
would
perform
actions
awesome.
B
So
that
was
our
so
so
there
was
feedback
that
building
a
binary
for
each
platform
was
annoying,
and
so
our
solution
was
well.
Let's
find
a
agnostic
like
a
platform
agnostic
language
that
would
work
that
didn't
require
that
had
good
internal
support
within
golang.
So
we
could
load
up
a
full
runtime
for
that
inside
the
go
language
and
didn't
require
external
tooling.
C
C
I
don't
know
like
I
wouldn't
want
to
think
about.
I
wouldn't
want
to
write
the
typescript
myself,
but
if
you
could
develop
the
plugin
as
you're
already
doing,
and
then
you
can
maybe
have
like
things
that
convert
from
go
or
from
rust
or
whatever
thing
that
talks
grpc
into
a
more
distributable
thing.
That
could
be
interesting.
B
We
don't
want
people
who
are
who
enjoy
the
current
plug-in
experience,
because
you
can
just
write
plain,
go
you
don't
have
to
think
about
javascript
or
typescript,
you
don't
think
about
html
or
ui.
You
you,
the
components
you
get
are
the
components
you
render
and
and
if
you
like,
that's
it
right
it
just.
It
makes
a
lot
of
choices
for
you
and
that's
intentional,
and
we
want
to
keep
that
feel
because
we
know
that
that
is
what
attracted
a
lot
of
people
to
write.
Plugins
for
actin.
C
Yeah,
I'm
I'm
totally
on
that
page,
so
yeah
I
would.
I
would
hate
to
s.
I
would
hate
to
see
it,
go
away
from
ability
to
be
done
and
go.
It's
a
matter
of.
I
think
you
know
for
your
team
to
figure
out
how
to
better
distribute
these
things,
and
you
know
maybe
I'll
have
some
thoughts
after
the
call
and
I'll
reach
out
to
you
all
and.
B
B
Yeah,
so
the
the
next
thing
we're
going
to
be
talking
about
is
ideas
around
accessing
resources.
This
is
an
idea.
That's
been
going
around
for
a
while.
We've
been
trying
to
kind
of
determine
what
interactions
look
like
and
and
with
the
api
and
and
how
we
get
resources
out
and
how
we
don't
overload
apis
when
we
don't
have
access
to
things,
but
still
maintain
our
ability
to
reflect
things
in
real
time.
B
But
how
like
how
we
interact
with
a
client
that
how
we
have
a
client
that
interacts
with
the
cluster
and
so
we're
working
through
working
through
those
two
repos
and
working
through
some
various
ideas
around
what
the
current
api
supports
around
like
back
offs
and
what
you
can
find
out
through.
Subject:
access
rules
and
what
you
can't
find
out
and
kind
of
just
like
general
rbac
information
within
the
within
the
cluster.
B
So
I
I
think
I
have
enough
now,
where
I'm
going
to
be
drafting
up
a
proposal
that
will
end
up
as
a
pr
for
people
to
review
and
and
make
have
questions
about,
and
we'll
have
like
a
formal
document
to
kind
of
review
some
of
this
and
decide
what
maybe
the
best
approach
is,
but
but
the
general
idea
around
it
will
be
to
take
our
existing
has
access
checks,
which
are,
I
would
say,
slightly
they're
done
like
when
I
did
them.
I
did
them
wrong
like
they
were.
B
They
were
a
band-aid
to
a
problem
and
they
fixed
that
problem.
That
was
directly
in
front
of
us,
which
was
we
spam
the
cluster
when
we
don't
have
access
to
something,
but
they
didn't
really
like.
They
didn't
actually
they're,
not
like
an
actual
solution
to
this
problem.
So
so
the
existing
has
access.
B
We
can
then
use
that
same
call
that
checks
what
we
had
access
to
periodically
throughout
octan's
lifecycle,
to
see
what
we
may
have
gained
or
lost
access
to
as
we're
interacting
with
the
cluster
and
then
the
other
part
of
that
is.
We
can
then
we
can
use
actual
responses
from
api,
calls,
take
those
error,
codes
and
inspect
them
for
specific
types
of
accessed
access
errors
and
record
those
alongside
our
our
kind
of
list
of
permissions,
so
that
as
you're
actually
navigating
a
cluster.
B
If
your
permission
has
changed
and
the
client
has
a
new
set
of
access
and
we
haven't
run
our
refresh
yet
we
can
update
those
entries
in
real
time
and
notify
upon
receiving
those
errors.
We
can
notify
a
user
that
their
access
has
changed
and
now
there's
another
issue
in
octant
that
was
opened
quite
a
while
ago.
I
can't
remember
the
exact
number,
but
it
was
specific
around
being
able
to
list
and
show
what
you
had
access
to
in
a
cluster.
B
Part
of
this
proposal
will
include
the
interfaces
that
that
will
will
use
to
implement
the
viewing
of
what
resources
you
have
access
to
in
a
cluster,
so
keep
an
eye
out.
For
that
that's
going
to
be
coming
soon.
I
want
to
have
a
I
want
to
have
the
proposal
pr
up
by
the
end
of
the
week
and
for
those
who
don't
know
how
proposals
work.
We
have
a
document
in
our
repo
that
talks
about
them,
but
essentially
it
is
the
the
proposals
are
where
we
go.
B
We
have
our
longer
form
discussion
around
the
the
current
implementation,
where
it
lacks
the
new
presented
implementation
and
an
implementation
strategy
around
how
we
plan
to
execute
this
proposal,
if
it
once
it
gets
approved
so,
and
that
process
can
take
you
know.
Sometimes
it
goes
quickly
for
a
shorter
one.
Sometimes
it
can
take
a
week
or
two
for
longer
ones,
but
my
goal
is
to
have
the
actual
draft
of
this
up
by
the
end
of
the
week.
B
B
Cool,
so
moving
on
to
ink
cluster
challenges.
This
is
just
something
I
wanted
to
bring
up
for,
for
everyone
to
to
think
about.
Deploying
octane
cluster
is
something
that
many
folks
want.
It's
something
that
ultimately,
we
want
to
do,
there's
a
branch
with
a
proposal
that
has
a
file
that
says
n
cluster
proposal.
B
B
B
Config
generates
a
client
sticks
that
into
a
struct
and
passes
that
everywhere,
and
so
it's
it's
one
client
for
one
octane,
so
that
has
that
issue
has
to
get
resolved
and
then
plug-ins,
which
are
currently
global,
which
I
touched
on
a
little
bit
earlier
when
we
were
going
through
some
of
the
ideas
around
plugins.
So
that
is,
I
just
wanted
to
bring
those
up,
as
as
things
for
people
to
think
about
as
things
that
I'm
thinking
about
as
we
move
towards
getting
octet
running
in
cluster.
B
E
Yeah
I
mean
I
have
two
comments.
Yes,
so
the
first
one
is
I'm
looking
at
the
roadmap
right
now
and
we
haven't
updated
that
in
almost
a
year
now-
and
some
of
these
items
are
starting
to
drift
a
lot
from
what's
on
the
road
map
and
the
cool
part,
is
we
actually
hit
a
lot
of
the
targets
from
the
original
map?
E
B
I
I
think
we
can
create
an
issue
open
an
issue
for
that
and-
and
we
can
just
yeah
draft
up
a
new
road
map
and
as
a
group
we
can
kind
of
remove
some
of
the
items
that
well
I
I
don't
want
to
remove
anything
because,
like
you
said,
we've
achieved
some.
I
want
to
leave
them
on
there,
but
I
think
it's
important
to
to
yeah
to
make
sure
that
that's
up
to
date,
there
is
some.
B
I
agree
with
you,
there's
some
drift.
I
think
that
there
is
also
a
lot
of.
I
think.
The
current
road
map
has
a
lot
of
things
that
were
kind
of
like
there's
some
things
that
are
not
really
well-defined
but
they're
on
there
right
like
like
or
they're,
very
generic
right,
like
speeding
up
octane,
I'm
looking
at
it
now,
but
like
speeding
up
octan,
okay.
Well,
what
is
that
yeah?
Yes,
we
always
want
to
do
that.
All
right
like
yes-
and
I
think
things
like
that,
we
can.
B
We
can
probably
shift
out
of
there
and
probably
make
a
make
a
a
better,
more
well-defined
road
map
around
around
where
octant
is
now
so
I
think
I
think
that's
good
to
call
that
out
and
then
what
is
octan
one
1.0.
I
think
there
are
two
things
that
need
to
happen
before
we
call
it
octave
1.0.
I
think
one
is
really
nailing
down
the
plug-in
experience.
B
We're
contin
we're
like
we're
still
like
that
api
before
1.0
needs
to
be,
you
know,
ready
and
pinned,
and
I
think
that
having
a
better
the
the
resource
viewer
stuff
that
milan
is
working
on,
I
think
that's
an
important
part
of
1.0
and
making
sure
that
we
are
exposing
all
of
the
right
information
with
like
open
api
and
making
things
a
little
bit
more
actionable.
So
I
think
I
think,
we're
not.
B
D
B
B
Yeah,
so
actually,
I
think
all
the
things
I
said
are
on
the
roadmap:
yeah,
updating
it
to
to
kind
of
account
for
some
of
the
drift
and
maybe
maybe
just
rewording,
some
of
it,
so
that
it's
clear
what
what
some
of
those
things
mean
and
how
they
align
with
the
actions
we're
taking.
Now
I
think
it's
a,
I
think
it's
a
great
idea,
so
I'm
gonna,
I'm
gonna,
create
create
an
issue
for
that
right
after
right,
after
we're
done.
A
E
Hopefully,
fonts
look,
okay
cool,
so
we
want.
We
had
a
long-standing
issue
about
starting
opt-in
without
a
keep
config,
because
currently
right
now,
if
you
try
to
start
often-
and
if
you
don't
have
a
cube
config
in
your
cube
directory
or
have
said
something
in
your
config
octane
wouldn't
start
in
this
case
it
would
be
expected
to
start-
and
I
I've
already
pre-built
most
of
this
stuff-
and
I
know
we
ran
we're
running
over
time.
So
keep
this
short,
but
essentially
we've
shifted
the
internals
such
that.
E
Let's
say
I
change
and
I
move
this
dot
cube
directory
to,
like,
I
don't
know,
dot
cube
tests,
whoops
to
say
something
that
just
that
something
that
congo
won't
know
where
to
look
for.
So
in
this
case
I've
already
pre-built
this
binary.
What
will
happen
is
if
we
start
often
it'll
sit
on
this
loading
state
for
a
little
while
and
it'll
open
a
modal
and
it'll.
Actually,
just
hang
out
here
for
a
little
bit
until
you
can
manually
put
in
a
cube
config.
E
E
D
B
E
There
it
is
there,
but
the
front
end
is
not
cooperating
or
it
might
just
be
yeah
there.
It
is,
it
probably
was
probably
a
weird
caching
thing
but
yeah.
So
this
lets
you
have
that
have
that
intermediate
modal
state,
where
you
don't
have
any
of
this
managers
in
the
internal,
that
kind
of
requires
to
keep
convicted
all-star.
So
just
having
an
intermediate
state
is
super.
Nice
and
users
would
now
know
like
you
know
they
don't
have
to
like,
be
like.
E
Oh
I'm
trying
to
start
often,
and
then
nothing
happens
because
their
setup
just
isn't
quite
right,
so
it
just
makes
that
initial
experience
a
little
nicer
and
extends
for
often
to
feel
more
like
an
electron
app
where
it'll
boot
up
no
matter
what
your
system
state
looks
like
that's
pretty
much
it.
There
was
an
issue
a
long
time
ago
where
we
proposed
that
octan
was
going
to
be
able
to
create
a
cluster
through
cluster
api,
but
then
we
decided
not
to
do
it.
E
So
this
issue
was
less
useful
than
we
thought
it
would
be
originally,
but
it's
still
something
that
I
think
a
lot
of
users
would
find
useful
and
we'll
probably
add
something
like
a
file
upload
or
something.
So
you
can
like
browse
for
keep
config
from
the
directory
and
sort
of
just
add
to
the
user
interface
aspect
of
it.
B
Excellent,
thank
you
sam
yeah.
I
have
so
I
have.
I
have
a
question
and
a
comment.
So
the
question
is,
there
are
multiple.
I
you
didn't
demonstrate
it,
but
there
just
to
make
sure
I
understand
there
are
multiple
ways
to
provide
the
cube
config
currently
right
and
if
you
set
the
environment
variable,
it
will
automatically
detect
that
as
well.
E
B
As
well
as
pasting,
yeah,
yep
and
then
the
comment
I
have
is
that
so
this
is
the
the
reason
I
I
we
wanted.
This
work
done,
even
though
we
were
not
still
doing
the
cluster
creation
stuff.
Is
that
imagine
that
this
is
not
a
asking
you
for
your
cubeconfig,
but
this
is
asking
you
for
a
login
right.
This
is
this
is
the
same
steps
that
need
to
happen
to
get
us
closer
to
working
in
cluster
as
well.
B
E
B
I
think
we
should,
because
I
don't
think
we
currently
have
a
file
picker
component
and
so
that
pr
now
becomes
adding
a
file
picker
component,
adding
the
go
and
the
typescript
for
that
and
then
and
then
extending
the
interface
here
to
to
use
that
component.
So
I'd
rather
see
all
that
happen
in
a
different
pr
sure.
That's
right
excellent
nicely
done.
Thank
you.