►
From YouTube: Octant Community Meeting - March 4, 2020
Description
March 04, 2020
Agenda
Next release soon™, waiting on these:
Monaco YAML viewer
Logger interface moved to pkg
Terminal moved to tab
CRD links not working after context changes
Nice-to-have: Fix nightly in Github actions and remove drone
Upcoming priorities
Documentation
Component Unmarshaling (important to Plugins)
Electron Application
Resource Viewer
Navigation
Fluid
Octant In-Cluster
Office Hours:
https://calendly.com/wwitzel3/octant-office-hours
Open Q&A - add your questions here!
Is it possible, or on the roadmap, to group / organize CRDs in the navigation menu?
4 tekton and argo workflow and it was already too much.
Add your link here Andy!
https://review.opendev.org/#/c/710868/ – my update based on: https://github.com/airshipit/airshipui
Issue around creating and passing a dashboard to plugin functions for testing
the TestHandlers currently errors out with: register.go:94: Unexpected call to *fake.MockDashboard.List
A
Everyone
and
welcome
to
another
episode
of
the
Auckland
community
meeting
today
is
Wednesday
March,
4th,
2020
and
yeah.
Today,
we're
gonna
talk
about
the
next
release
with
a
bunch
of
new
features
and
our
upcoming
priorities,
and
if
you
have
any
open
Q&A,
so
any
questions
that
you
want
to
add
in.
Please
do
so
in
the
meeting
notes
that
I'll
share
here
in
the
chat
window.
I'm
gonna
share
the
agenda
as
well,
and
then
we'll
kick
it
off
here.
B
Yeah,
so
the
next
release
is
coming
soon.
We
just
have
some
outstanding
issues
that
we
want
to
make
sure
to
get
into
this
release
that
myself
and
Milan
and
Sam
have
been
working
on
we've.
We
actually
the
I
think
the
the
top
one
they're,
the
Monaco,
yemelya
I-
think
Milan
just
got
that
sorted
out.
So
that's
that
one
we'll
be
moving
forward.
I
know
that
Jordan
who's
on
the
call
here
was
working
on
the
moving
a
logger
interface.
B
Moving
that
terminal
to
its
own
tab
on
on
pods
is
one
that
we
want
to
just.
It
would
be
a
better
overall
experience
right
now.
The
the
current
implementation
leaves
a
lot
to
be
desired
with
how
it
jumps
around
and
needing
to
know
what
command
to
execute
and
things
like
that.
So
we've
actually
there's
an
out
there's
an
issue
which
I
don't
recall,
the
number
we'll
add
it.
I'll.
Add
it
to
this
document
as
soon
as
I
find
it
working
on
that.
B
Now
that
kind
of
outlines
our
new
approach
to
the
the
terminal,
yeah
it'll,
be
its
own
tab.
It
will
live
in
the
like
when
you
view
a
pod
or
to
live
in
there
when
you
click
on
it,
you'll
get
an
active
session
when
you
never
get
away
from
the
tab
that
sexual
remain
open.
When
you
may
have
the
gate
away
from
the
pod
session,
will
close
and
there'll
also
be
the
when
you
exit
out
of
a
session
but
stay
within
the
pod.
B
Your
backlog
and
your
scroll
back
will
stay
and
then
but
it'll
give
you
the
option
to
refresh
to
start
a
new
connection,
and
when
you
do
that,
it'll
be
a
brand
new
terminal
window
and
you'll
lose
your
scroll
back.
So
this
is
just
it's.
It's
a
it's
a
pattern
that
we've
seen
other
tools
that
have
terminals
use
and
I
like
it
better.
It
feels
better.
B
It
works
better
than
what
we
have
now,
which
is
kind
of
this
slider,
which
doesn't
always
slide
exactly
correct
when
you
resize
things
and
when
you
hit
the
execute
button,
it
jumps
and
skips
around
and
you
kind
of
have
to
know
what
command
exactly
you
want
to
execute
and
a
lot
of
people
don't
right.
They
just
want
to
shell
and
some
of
those
people
who
want
a
shell.
They
don't
necessarily
know
that
they
that
they
specifically
have
to
do.
You
know
/bin
/sh,
so
it's
it's.
B
It's
all
just
a
convenience
thing
so
hopefully
well
we'll
get
that
in
there
soon
and
then
the
CRD
links
not
working
after
you
switch
context.
Obviously
that's
something
that
we
just
we
want
to
have
fixed,
because
it's
a
annoying
problem
so
and
then
the
last
one
on
there
is
it's
not
really
it's.
It's
more
of
a
nice
to
have,
as
as
Sam
pointed
out,
is
just
moving.
Our
nightly
build
process
over
to
get
out
of
actions
currently
uses
drone
and
we'd
like
to
just
get
rid
of
that.
B
B
B
No,
no
there's
no
like
fixed
limit
I
mean
the
way
the
end,
the
new
interface.
The
way
it's
gonna
work
is,
you
can
only
you'll
essentially
have
one
terminal
open
because
they're
all
maybe
one
tab
so
but
yeah,
there's,
no
there's
no
limit
whatever
whatever
the
kubernetes
api
can
handle
is
would
be
the
the
theoretical
limit.
C
A
B
B
B
So
the
we've
had
a
couple
outstanding
issues
for
documentation
specifically
around
just
like
how
octan
works
from
a
from
a
developer
standpoint,
what
its,
how
its
systems
interact,
what
it's
like,
how
it
gets
information
from
they
from
kubernetes
api
things
like
that,
we
really
want
to
get
just
a
nice
initial
baseline
scaffold
of
documentation
in
place.
This
first
pass
will
not
be
super
in-depth
or
detailed,
but
it'll
be
enough,
so
that
there
isn't
just
some
blank
page
that
people
are
staring
at
wondering
how
to
contribute.
B
The
other
thing
is
the
component
on
marshalling
which
we
started
working
on
in
this
kind
of
this
last
cycle.
We
want
to
finish
that
up
address
the
rest
of
the
components
that
we
want
to
have
the
ability
to
unmarshal.
This
is
important,
because
if
it's
not,
if
we
don't
have
it
defined
with
on
marshalling
capabilities,
then
plugins
currently
can't
use
it.
So
we've
added
some
things
like
like
button
and
button
groups
and
some
other
components,
but
there
are
still
some
outstanding
ones.
That
I
think
will
be
useful,
mainly
around
forms.
B
Some
of
the
new
chart
stuff
that
we
have
in
place
that
we
think
plugins
would
want
to
be
able
to
take
advantage
of
so
this
is.
This
is
related
to
some
overall
improvements
to
the
plugin
interfaces
that
are
coming,
but
this
is
just
just
kind
of
a
get
things
up
to
parity
with
the
components
we
have
and
the
components
that
plugins
can
use.
B
The
next
thing
was
is
this
has
been
talked
about
in
the
past
previously
octant
as
an
application,
specifically
as
an
electron
application.
This
work
there
is,
there
is
a
currently
a
feature,
not
really
a
feature
branch,
but
there
is.
There
is
the
there's
a
Denali
package
within
the
octant
source
tree,
and
that
is
the
work
that
Brian
did
to
created
the
image
to
create
the
initial
scaffold
for
an
electron
application,
as
we
talked
about
before
the
importance
of
it
being
an
application.
B
Is
that
we
get
access
to
things
we
don't
have
access
now,
when
it
is
running
in
the
browser,
specifically
around
tight,
integrations
with
the
operating
system,
the
ability
to
upload
files
and
get
true
paths,
integration
with
notifications
and
being
able
to
have
better
menu
controls
within
octan
itself
are
all
things
that
we
gain
by
by
moving
it
to
an
application.
So
this
worked
what
was
started.
B
D
We
are,
they
are
actually
I'll,
just
say
it,
because
not
even
on
Wayne's
list,
Wayne
and
I
had
a
pretty
long
conversation
yesterday
about
running
octant
and
cluster,
something
that
we
resisted
just
because
that
it
makes
us
take
on
a
lot
more
lot
more
risk
inside
the
product,
but
as
Michael
Michaels
on
this
call
he's
asked
he's
asked
me
for
it
a
million
times.
We
knew
it
two
years
ago
that
this
was
gonna
happen,
and
there
are
some
things
going
on
just
in
the
community
and
I
VMware
itself.
D
We
still
want
this
app
because,
because
I
think
for
a
lot
of
use
cases-
particularly
the
like
my
news
case-
often-
would
be
amazing
as
an
app,
but
if
we
think
trying
to
be
inclusive
to
bigger
companies
as
well
I
can
see.
The
I
can
definitely
see
the
argument
for
running
in
cluster,
so
we're
gonna
be
weighing
both
of
these
and
trying
to
move
forward
on
both
of
them.
Yes,.
B
B
One
of
the
things
about
that
just
a
caveat
just
for
call
it
being
super
excited
about
it,
plugins
as
they
are
currently
known,
will
not
work
in
cluster
so
and
and
might
never
work
in
cluster.
There
may
be
something
along
the
lines
of
plugins
in
cluster,
but
they
won't
look
like
they
look
now
at
all.
So
keep
that
in
mind,
because
the
the
way
our
plug-in
system
works
now
that
it
would
be
that
you
just
can't
do
it
in
cluster,
so
hey.
E
C
B
Yeah
and
I
mean
we
know
that
from
a
lot
of
folks
like
like
18t,
isn't
the
only
place
but
yeah
exactly
like
many
many
people
are
have
this
issue
of.
It
is
much
easier
to
for
whatever
reason
they
trust
developers
to
install
stuff
in
a
cluster,
but
not
on
their
desktops
I.
Don't
know
why,
but
they
do
so,
and
we
understand
that
at
companies
large
companies,
especially
it
is
very
easy
to
it's
much
easier
to
get
things
in
cluster
like
that.
D
D
I
had
suggested
that
maybe
we
think
of
a
higher-level
plug-in
interface
so
that
if
we
were
running
it
in
cluster,
if
we
were
running
in
cluster
running
out
of
cluster,
at
least
the
application
octants
core
can
interface
it
with
it
the
same
way,
and
then
we
can
figure
out
a
way
to
actually
have
some
kind
of
plug-in
functionality
when
we're
running
in
cluster
it'll
be
totally
different
code
bases,
because
we
can't
exec,
we
can't
exact
in
the
cluster
but
I
think
they're
still
a
way
around.
It.
D
B
Yeah,
so
the
the
other
thing
we
want
to
focus
on
in
this,
this
upcoming
cycle
is
the
resource
favored
and
more
than
just
more
than
just
kind
of,
like
we've
been
doing
a
lot
of
incremental
UI
improvements
and
making
things
a
little
cleaner
and
tightening
up
some
spacing
and
things
like
that,
but
specifically
the
resource
barrier.
We
want
to
kind
of
approach
this
with
with
fresh
eyes
and
and
really
think
about.
B
How
can
we
make
the
resource
viewer,
the
the
the
core
useful
component,
that
that
it
is
and
in
making
it
drive
kind
of
your
engagement
and
usage
of
octant
through
the
resource
viewer,
because
I
believe
that
the
the
resource
viewer
itself,
just
in
itself,
right
now
is,
is
very
as
already
it's
useful.
Like
you
look
at
it,
you
see
color
codes,
you
see
status
marks
and
you
kind
of
can
add
a
super
quick
glance
and
get
an
idea
of
what's
happening.
B
What
we
want
to
do
is
we
want
to
take
that
a
step
further
and
want
to
tighten
up
the
UI
for
it.
We
want
to.
We
want
to
make
things
a
little
easier
to
navigate,
but
then
we
want
to
take
that
extra
step.
Oh
okay,
I
see
that
there
is
a
problem
here.
I
see
that
this
boxes
is
red
or
it
has
a
red,
has
an
X
on
it,
and
so,
when
I
click
that
now
I
have
actionable
things
in
in
the
status
around
these
objects.
B
That
I
can
go
do
or
that
are
that
are
indicated
to
me
around
what
the
problem
is.
I
no
longer
have
to
go
and
click
on
the
thing
on
the
pod
and
then
click
on
the
the
status,
little
heptagon
link
and
then
scroll
down
to
the
events
and
then
see
that
it's
in
back
off,
because
I
type
out
the
URL
right
like
we
want
that
information
to
be
right
there
in
the
object
status
that
like
quickly
accessible,
and
we
can
do
that.
B
We
like
we,
we
we
know
we,
we
have
the
events
we
know
when
we
have
these
errors.
It's
just
currently.
The
way
we
do
object
status
is
is
it
was
the
first
pass
of
object
status
and
it
doesn't
contain
all
of
this
extra
useful
information,
so
kind
of
taking
that
next
step
with
the
resource
viewer
to
tighten
up
the
design,
make
sure
that
the
way
you
navigate
it
and
the
way
you
interact
with
it
is
predictable.
D
So
really
this
comes
back
down
to
the
core
of
auxin
and
I.
Don't
even
know
what
this
answer
is,
but
really
I
just
want
you
to
go
look
at
the
screen
and
you
could
just
shake
your
head.
Yeah
I
get
what's
going
on
and
that's
it
you
don't
look
at
anything
else.
I
would
love
for
us
to
be
so
there.
So
that
point
where
we're
just
I
see
everything's
good
or
this
is
bad
or
or
something
in
between,
and
that's
the
gist
of
this.
D
At
at
displaying
their
graph
and
that's
kil,
ka-ki
a
I
and
then
there's
another
project
which
is
still
lead
on
the
visualization
side,
but
probably
not
only
one
from
the
cilium
project.
There's
a
project
called
Hubbell
and
someone
went
over
it
I
think
Jack's
Rosso
did
it
I'm
a
few
weeks
ago,
t
tik
where
he
actually
went
over
it
and
talks
about
it.
D
But
this
is
the
kind
of
things
I
want
really
what
I
want
for
people
of
users
of
often
is
that
you
shouldn't
have
to
feel
like
you're,
an
expert
at
anything
to
understand
if
your
workloads
are
broken
and
I.
Think
still
to
this
point,
we're
we're
still
have
to
know
a
little
bit
and
let's
see
if
we
can
beat
that
now,
I'm
done.
B
B
Jonas
my
mic
was
loud.
Is
it
better
now
to
the
horrific
okay?
Sorry,
maybe
I
was
just
talking
about
I
get
excited,
sometimes
I
start
yelling,
you're
excited
and
then
the
next
thing
on
this
list
is
navigation.
So
this
one
is
interesting.
It
I
we
had.
We
had
done
a
pass
on
navigation
and
I.
I
was
like
that
looks
great.
Let's
do
that
and
then
we
implemented
it.
Nico
and
and
Sam
Ross
did
a
design
work
on
it
and
then
Nico
and
Sam
went
implemented
it
and
then
in
starting
to
use
it.
B
B
The
one
problem
is
making
sure
that
there's
a
nice
distinct
break
between
the
modules
that
exist
within
octant,
like
our
workloads,
module
versus
our
overview
or
dashboard
module
versus
plugins,
which
are
modules
so
like
having
a
clear
separation
between
the
modules
within
octants,
so
that
users
understand,
when
you're,
using
octant
and
you're
in
the
workloads
module.
That
is
your
focus
and
the
content
area
is
focused
on
that.
So
and
then
the
other
piece
is
is
when
you
start
to
get
into
custom
resources,
and
this
actually
ties
into
a
question.
B
That's
in
our
open
queue,
it
Q&A,
em
and
custom
resources
are
tricky
because,
if
you've
been
on
any
any
cluster
of
any
size,
you
know
that
there
is
a
ton
of
custom
resources
on
there
and
when
you
start
to
put
them
into
a
list
and
a
nav
menu
on
the
left-hand
side,
it
becomes
untenable.
Pretty
quick,
you
put
4
TCR
these
in
there
and
you're
trying
to
navigate
them
and
they're,
truncated
and
they're
and
they're
ellipses,
or
whether
it's
any
of
it
and
you're
scrolling
left
and
right.
It's
it's
really
not.
It
doesn't
really
work.
B
So
we
are
gonna,
be
revisiting
navigation
and
try
to
find
a
good
solution
that
works
for
our
our
desire
to
have
the
the
octant
platform
distinct,
pushing
between
the
module
that
you're
currently
using
and
also
making
sure
that
things
like
CR,
DS
and
pull
and
custom
navigation
from
plugins
are
are
usable
and
and
work.
Well,
we
don't
know
what
that
looks
like
yet.
B
Ross
is
doing
some
some
investigation
into
this
and
and
working
through
some
different
designs
and
kind
of
taking
some
of
the
conversations
we
had
to
kind
of
generate
some
new
ideas
around
that
and
but
we're
gonna
work
on
making
this
something
that
is
useful,
even
when
you
have
lots
of
menu
items
or
large
clusters.
So.
D
B
D
This
being
realized
automation,
piece
of
software
and
I
noticed
this
right
side
and
what
I
liked
about
it
and
I
am
NOT
a
designer
at
all,
is
that
it
allowed
us
to
have
the
separation
because,
like
Wayne
was
saying,
whenever
you
have
modules
that
have
their
own
menus,
hierarchy
becomes
very
important,
but
we
still
don't
want
super
deep
hierarchy
because
that
becomes
unmanageable.
So
one
idea
that
we
have
is,
we
could
do
this
I,
don't
even
what
kind
of
menu
is
this?
What
would
you
call
this
thing?
D
F
D
B
A
B
Yes,
it'll,
look
the
same.
It'll
feel
the
same:
it'll
be
a
web
application
that
you're
running
cluster,
yeah
and
and
and
it'll
live
in
the
same
repository
so
like,
but
like
Achtung.
The
electron
application
that
we're
building
as
well
as
the
in
cluster
version
will
live
in
the
same
repository
they'll
be
in
octant
together.
D
And
and
keep
in
mind,
we
didn't
write
octant
to
do
this,
but
Wayne
is
less
sure
than
I
am.
But
there
are
definitely
some
good
integration
points
where
things
are
segmented
away.
The
way
that
we
actually
talked
to
the
cluster
is
segmented
away
from
mostly
app,
so
we
would
have
to
introduce
a
new
dynamic
client
type
thing.
D
So
we
can
talk
to
the
cluster
and
not
keep
everything
in
a
store
which
will
give
us
which
will
actually
make
us
lose
some
of
the
responsiveness
but
I
think
that
that's
a
good
trade-off,
because
you
don't
gonna,
want
to
have
50
users
using
octave
and
having
50
and
former's
times
how
many
of
our
objects
times.
How
many
ever
namespaces
you
have
I
mean
that's
I!
Guess
it's
a
really
dumb
numbers
really
quick!
B
And
then
yeah
as
long
as
they,
let
me
back
in
who
knows
these
days
of
travel
so
and
and
then
to
answer
the
question
that
was
asked
here:
is
it
possible,
is
it
possible
or
on
the
roadmap,
to
group
organized
CR
DS
in
the
navigation
menu?
So
right
now,
no,
it's
not
possible.
It
is
on
the
roadmap.
It
it
is
covered
under
the
upcoming
priorities.
Under
navigation
will
will
be
due,
will
definitely
be
doing
something
to
address
CR
DS
and
make
them
more
usable,
especially.
You
have
a
lot
of
them.
Some
and
that's
it.
B
Sure
yeah
yeah
I
can
do
that
so
in
an
effort
to
give
people
a
little
more
access
excited
of
some
folks
have
been
asking
to
do
like
some
parent
sessions
or
just
have
more
in-depth
conversations
about
octant,
not
necessarily
within
the
the
scope
of
the
community
meeting
here.
I've
created
some
office
hours
for
myself
that
that
folks
can
go
to
and
I
will
put
a
link,
I'll
put
a
link
in
here
but
yeah.
So
it's
it's.
It's
Thursdays
between
I,
think
I
setup
between
1:00
and
and
5:00
p.m.
B
Eastern,
Time
and
folks
can
go
in
and
and
reserve
a
slot,
and
just
can
ask
questions.
Ask
for
help
on
issues.
Talk
well,
they're.
Basically
anything
octant
related
I'm
happy
to
talk
about
it.
Help
folks,
if
you're
thinking
about
using
octant
at
your
company
or
whatever
it
is
that's,
that's
that's
what
I'll
be
there
for
so
I'll.
Add
that
to
this
to.
A
C
A
C
Have
a
a
general
code:
question
I,
don't
know
if
this
is
the
right
time
to
ask
them:
yes,
sure,
okay,
so
I'm
trying
to
do
some.
Some
work
around
a
mock
test
with
with
a
router
and
a
dashboard
and
I'm
having
problems
getting
the
mock
dashboard
to
actually
work,
because
it's
looking
for
a
list
method
and
the
mock
dashboard
that
I'm
handing
it
I
don't
think
contains
that
or
it
looked
like
it
contains
it,
but
I'm
kind
of
getting
twisted
up
in
circles,
because
I'm
still
new
to
go
and
very
new
to
octave.
D
C
C
B
B
E
B
Yeah,
so
not
right
now!
No,
we
are
addressing
that
soon.
When
we
look
at
navigation,
we
want
to
create
a
good
solution
for
CRT
navigation,
because
we
know
right
now,
once
you
start
to
get
beyond
just
a
handful,
it
becomes
pretty
pretty
hard
to
navigate
and
read
everything
and
see
it
also
yeah.
It's
it's
on
our
upcoming
priorities
to
kind
of
address
navigation
as
a
whole.
Yeah.
D
Jordan,
yes,
this
is
an
interesting
point,
so
I'm
looking
at
octant
right
now
and
I
have
K
native
and
contour,
and
then
this
other
FK
native
contour
and
one
other
see
Rd
and
my
cluster
here
locally.
There's
like
11
items
and
I
was
thinking.
Not
only
would
you
want
to
split
them
up,
but
K
native
is
very
judicious
and
they're
applying
of
CR,
DS
and
I.
Think
half
of
them
are
not
internal
like
they
probably
should
even
show
up
I
think
another
interesting
Avenue
for
this
wayne
would
be
we
haven't.
D
We
talked
a
long
time
ago
about
being
able
to
configure
the
UI
mm-hmm.
Maybe
I
don't
want
this
to
show
up
I,
don't
want
any
of
my
internal
ones
to
show
up
and
then
thinking
about
it.
It
is
in
the
same
thought
when
you're
thinking
about
grouping
or
something
like
that
as
well.
I
could
see
that
yeah
Canada
has
a
lot
of
CR
DS
and
most
of
them
are
internal
and
I,
probably
don't
care
it's.
How
key
native
works,
not
how
I
work.