►
From YouTube: Octant Community Meeting - December 9th, 2020
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
B
It's
done
soon
hello
and
welcome
everybody
to
the
octant
december,
9th
octane
community
meeting
it's
kind
of
a
small
agenda
today
I
know
there's
some
things
I
haven't
put
on
there.
Yet
that'll
make
it
grow
a
little
bit
but
yeah,
we'll
I'll,
get
that
pulled
up
I'll
start
sharing
and
we'll
we'll
get
we'll
get
started.
B
B
All
right,
everyone
can
see
that.
Okay,
let's
go
so,
let's
see
today
december
9th,
okay
yeah.
So
this
came
up
in
the
channel,
looks
like
oh
16.
This
person
was
still
trying
to
build
16.1
off
of
brew,
but
sam
pointed
out
that
the
upgrade
failed
with
oh
16.2
as
well,
and
apparently
there
was
still
some
old
artifactory
links
in
the
package
like
json.
B
I
have
no
excuse
for
this,
except
for
the
fact
that
it's
just
a
systematic
failure
by
the
team
to
properly
identify
the
artifactory
links
and
remove
them.
I
apologize
this
is
that
that
that's
silly
sam
is
putting
in
our
build.go
file,
we're
gonna,
just
grep
for
the
word
artifactory
and
if
it's
found
anywhere
and
we're
just
gonna
fail,
so
nothing
with
artifactory
shall
ever
be
merged
and
again,
assuming
all
things
come
from
pr's
and
go
through
the
github
checks,
which
they
do
so
we
will
be
cutting.
B
You
know
16.3,
to
fix
this
very
specific
issue
so
that
brew
installs
are
functioning
again,
it'll
be
no
other
feature,
except
that
it's
literally
just
to
get
this
artifactory
link
out
of
that
out
of
that
source
tree.
So
I
apologize
to
people
who
are
hitting
that.
Thank
you,
sam,
for
jumping
on
that
and
taking
care
of
it
and
we'll
get
that
out
today.
Question
mark.
C
Yeah,
I'm
just
doing
some
documentation
around
npm,
where
it
is
that
you
could
do
npm
ls
to
check
if
things
resolve
beforehand.
So
something
like
this
could
be
useful
to
just
check
if
the
environment
can
resolve
any
of
those
npm
links,
I'm
not
sure
how
it
works.
It's
still
working
locally,
even
with
the
vpn
off.
C
So
if
it
takes
too
long,
I'm
just
going
to
grab
for
the
word
artifactory
explicitly,
but
I
think
the
problem
we
want
to
solve
here
is:
can
we
build
octant
if
the
npm
registries
don't
resolve,
and
how
can
we
test
that.
B
Yeah,
I
think
I
think
in
this
case
I
think
just
grabbing
artifactory
and
well
specifically,
that
internal
url
for
artifactory,
like
if
that
exists,
we
just
shouldn't
it
shouldn't,
be
allowed
to
merge
in
because
that'll
never
be
public
and
it'll
always
break
if
somebody
doesn't
have
the
cash
sitting
there.
The
problem
that
I
know
about
the
npm
ls
is
that
if
you
have
cashes
and
those
could
be
in
various
places,
whether
it's
local
and
there
are
global
cash,
it
will
attempt
to
resolve
them
through
that
mechanism
as
well.
B
At
least
that's
my
understanding
of
it.
So
for
people
like
us
who
are
occasionally
on
the
vpn
and
occasionally
get
our
references
mixed
up
and
washed
with
this
artifactory
stuff
that
even
that
ls
check
would
be
insufficient,
but
I
guess
it
would
work
in
the
github
workflow,
so
yeah
either
way
it's
fine
as
long
as
it
whatever
makes
it
not
happen
again
is
the
is
the
thing
I
want.
So
that's
perfect.
B
And
the
next
one
is
sam
with
the
octant
plugin
for
timed.
I
will
I'll
stop
sharing
so
that
you
can
pull
up
anything
that
you
might
want
to.
C
C
A
local
host
all
right,
so
this
is
running
off
of
octane
16
2,
so
none
nothing
from
our
recent
merges
to
master
simply
because
there
are
some
new
issues
around
our
navigation
and
padding.
So
we
won't
be
showing
the
new
navigation
for
now,
but
I
think
this.
C
Of
the
results
of
last
week's
work
around
a
plug-in
for
kind
and
what
that
might
look
like-
and
this
has
been
shown
before
you
can
do
things
that
create
a
cluster
cluster
name-
have
like
a
highly
available
control,
plane
or
just
add
a
number
of
workers,
and
it's
got
some
victim
logic
for
versioning
and
I'm
not
going
to
create
a
cluster.
C
But
the
key
feature
here
is
that
you
can
have
feature
gate
flags
enabled
upon
creation
of
a
cluster,
so
you
don't
have
to
play
around
with
kind
configs,
but
the
new
update
that
went
in
to
0.1
was
a
good
0.000.1
or
the
pre-alpha
release
was
that
I've
added
a
link
here
and
this
kind
of
shows
your
local
docker
images
and
your
kind
images.
I
think
the
first
thing
you
might
notice
here
is
that
the
sort
here
is
still
somewhat
unstable
and
this
is
resolved
in
dot
17.
C
But
I
decided
to
just
leave
this
in
for
now,
simply
because
I
could
I
could
do
the
sorting
methods
by
hand
by
myself
to
guarantee
this
order,
but
it's
already
fixed.
So
theoretically,
this
should
once
we
upgrade,
I
can
cut
a
different.
I
can
cut
another
release
on
this
plugin,
but
effectively
how
this
works
is
that
you'd
have
your
kind
images
and
the
equivalent
of
checking
the
images
that
are
located
inside
of
a
kind
cluster
I
think,
is
docker.
C
I
might
have
had
it
yeah
docker
exec,
and
then
I
guess
it's
like
cri
container
runtime
control.
I
guess
images
and
the
reason
why
you'd
have
a
bunch
of
images
here
is
because
most
of
the
time
you
can
just
do
docker
pull
and
it
wouldn't
be
an
issue,
but
in
the
case,
where
you're
building
an
image
locally-
and
you
don't
want
to
put
it
push
it
on
a
registry
for
some
reason-
or
maybe
this
is
just
a
purely
local
workflow.
C
Sometimes
you
might
just
want
to
be
able
to
pull
the
image
into
the
cluster.
So
in
this
particular
example,
we
just
have
the
defaults
kind
images
loaded
in
here,
so
you've
got
some
rancher
stuff
and
things
related
to
control
plane.
But
if
I
say
I
wanted
to
just
load
a
local
nginx
image
in
here,
we
can
just
have
buttons
to
do
it
and,
let's
see
if
this
works.
C
Yeah
and
there
it
is
the
there's
a
little
bit
of
a
delay,
but
we've
loaded,
our
docker
nginx
1.192
into
the
image,
and
I
think
wayne
actually
put
in
like
a
little
loading
step
here
that
I
just
kind
of
omitted.
That
was
weird
too
yeah.
C
There's
a
load
except
that
I
own
yeah,
that
I
omitted
at
some
point
in
time,
which
I
could
probably
throw
through
back
in,
so
that
the
alert
syncs
up
a
little
bit
better,
but
the
equivalent
command
here
is
that
you
now
you
have
docker
io
library,
engine
x,
and
this
is
loaded
now
into
that
time.
Control
plane,
and
there
is
no
reason
why
you
can't
do
this
for
any
other
local
images.
C
So
if
you
do
doctor
images,
it
pretty
much
applies
to
anything
in
this
list
and
that
can
be
thrown
into
this
kind
registry.
Other
notable
things
are
that
we
used
some
docker
libraries
to
make
these
more
human
readable.
I
think
this
could
have
some
use
cases
for
our
own
presentation
of
sizes
within
octant
core
itself,
or
we
could
just
re-implement
these,
but
these
are
kind
of
nice.
We
don't
do
this.
Currently,
we
just
show
a
really
big
number
and
that's
that's
about
it.
C
I
think
it
might
be
cool
to
actually
have
these
like
directly
linked
to
the
url,
then
on
docker
hub,
if
it's
a
docker
dot
io.
So
there
there's
some
room
for
improvements
here,
but
you
know
gonna
play
around
with
it
see
what
you
think.
This
was
more
of
an
experiment
to
get
feedback
around
our
plugin
api
more
so
than
actually,
you
know
having
like
a
super
robust
uis,
but
I'm
happy
to
develop
more
time
into
that
plug-in.
If
there's
interest
on
it.
B
I
had
a
question
when
you
create.
Did
you
when
I'm
curious,
the
mechanism
that
we
have
for
octan
if
it
works
properly
like
it
should,
when
you
create
a
new
kind
cluster
using
the
plug-in,
does
it
automatically
show
up
in
the
lists
of
available
contexts.
C
So
yeah
it,
the
watcher,
picks
up
the
new
context
and
what
ends
up
actually
happening.
Is
that
kind
edits
the
cube,
config
and
then
optimize
its
own
file
watcher
and
then
it
picks
up
and
then
it
reloads,
but
the
experience
that
the
user
gets
is
that
they
were
actually
like.
Well,
one
kind
of
spinning
up
those
images
before,
and
so
it's
like
trying
to
put
together
the
conquest
in
the
background.
C
So
often
it
will
stay
on
the
old
context,
even
as
you're
creating
the
new
cluster
until
it
actually
modifies
the
cube
config
in
which
in
in
which
case
then
octane
will
show
like
octane,
is
disconnected
reconnecting
and
then
it
switches
context
automatically,
and
so
that's
one
of
the
ux
things
it's
and
that's
yeah,
that's
one
of
the
ux
things.
That's
probably
we
want
to
address
with
octet.
C
Is
that
what
happens
if
a
user
manually
modifies
or
user
tool
some
something
modifies
to
keep
config
while
often
is
running
because
it's
it
does
pick
up
the
changes,
but
sometimes
from
a
ui
perspective.
It
does
things,
that's
not
intuitive
or
even
disruptive.
If
the
user
is
viewing
something
and
all
of
a
sudden,
the
context
just
changes.
B
Yeah,
okay,
okay,
yeah
yeah.
I
think
I
think,
having
some
mechanism
for
for
for
plugins
that
are
creating
clusters
having
a
mechanism
to
say
like
go
ahead
and
make
the
switch
right
like
do
an
explicit
like
set
context,
call
or
some
something
that
that
says
like
yeah.
I
want
to
make
that
change,
but
then,
like
in
the
generic
case,
just
be
like,
you
know,
append
it
to
the
list,
but
don't
actually
change
what
I'm
looking
at
would
be
a
good
or
a
better
user
experience.
C
Yeah
and
there
this
isn't
specifically
kind
like
kind
has
a
issue.
That's
open
that
talks
about
this
a
little
bit
and
they're
effectively.
They're
saying
this
is
somewhat
the
standard
with
tools
that
do
things
to
keep
config.
So
that's
why
it's
like,
even
if
you
don't
want
kind
to
modify
the
context
by
default,
you
kind
of
have
to
do
some
like
hacks
around
it.
C
In
the
background,
so
I
think
the
best
way
to
address
this
is
just
to
make
octant
deal
with
this
case
a
little
bit
better,
rather
than
trying
to
do
hacks.
A
C
Yeah,
I
can,
I
guess
we
have
time
I
can
talk
about
this.
We
can
actually
go
to
the
code
and
show
you
explicitly
what's
happening.
So
if
you
go
into-
and
maybe
some
other
people
on
the
call
might
not
necessarily
be
interested
in
this
so.
B
C
Yeah
I'll
give
it
a
second
okay,
so
here's
the
code
for
plug-in
here's,
the
plug-in
code
and
really
when
we
generate
this
new
link.
What
ends
up
happening
is
that
we
take
this
thing
called
name
here,
and
this
name
and
yeah,
and
actually
this
is
also
kind
of
interesting.
C
This
name
here
is
just
the
cluster
name
right
so
like
if
it's
in
this
case
in
the
client
cluster,
we
call
it
kind,
we
can
call
it
any
number
of
things
right
contest
whatever,
but
what
ends
up
happening
is
that
if
we
want
to
go
to
this
link,
you
kind
of
see
it
go.
We
want
the
path
to
be
kind,
then
kind
right
like
this
is
the
kind
plug-in
module,
and
then
this
is
the
name
of
this.
C
Cluster
is
kind
right,
and
so
what
ends
up
happening
is
that
when
I
create
this
particular
view
in
a
plug-in,
I
don't
need
to
know
that
I'm
in
the
module
kind
and
what's
happening
now,
is
that
the
on
master.
Now
this
new
link
has
to
have
knowledge
of
this
first
initial
module
before
we're
actually
creating
links.
C
So
if
I
were
to
do
this
new
link
on
17,
it
would
actually
just
route
me
to
slash
kind
and
that's
going
to
break
the
existing
plugins,
notably
the
helm
plugin,
which
is
to
say
that
we
can't
do
that.
But
we
would
something.
D
C
In
the
meantime,
and
either
we'd
have
to
expose
a
method
that
lets
people
know
how
to
get
the
module
up
front
or
just
be
very
clear
that
this
is
happening.
A
Okay,
yeah,
that's
interesting
yeah
that
definitely
shouldn't
happen,
but
sounds
like
a
breaking.
Change
might
be
related
to
navigation.
B
Yeah
I
mean,
I
think
this
is
something
that
that
that
behavior
shouldn't
change
right.
So
I
agree
like
I
agree
with
milan
like
that.
This
is
not.
This
is
a
unintended
side
effect
or
something
that
that
we
want
to
make
sure
it's
a
regression.
It's
a
bug
and
we
should
fix
it
yeah
I'll.
Look
into
that.
C
Yeah,
I
think
it's
mostly
just
we
need
to
just
have
better-
and
I
don't
keep
saying
this,
but
we
want
to
have
better
testing
in
place
for
a
lot
of
our
plug-in
apis,
like
we
like
currently
right
now,
like
we're,
building
component.new
link
in
the
context
of
octant
core,
and
what
we
really
want
is
testing
from
the
context
of
a
plugin.
B
Yeah
yeah
that
yeah.
That
actually
leads
me
to
another.
Another
thing
that
I
can
talk
about
around
plug-in
testing.
I
was
thinking
about
this
idea
and
it's
literally
just
an
idea
in
my
head,
but
but
I
was
I
was
walking
yesterday
and
I
was
like
you
know
we
have
this
javascript
runtime
for
the
go
runtime
I
I
don't.
I
haven't
quite
figured
it
out
yet
I
don't
know
how
we
would
do
it,
but
we
have
this
javascript
on
time,
and
that
is,
if
you
look
at
how
the
code
is
structured
right.
B
It
like
instantiates
this,
this
in-memory
javascript
runtime
it
loads
the
javascript
code
in
and
then
it
and
then
it
executes
go
like
code.
That's
mostly
in
our
package
folder,
like
public
go
code,
we
could
very
likely
create
a
command
that
was
like
the
javascript
plug-in
test
executable
or
something
like
that
that
took
in
you
know
the
the
plug-in
as
like
the
the
post-compiled
plug-in
as
a
as
a
input
and
then
a
set
of
javascript
tests.
B
So
we
could
basically
make
a
test
harness
for
the
javascript
plug-ins
that
would
use
the
actual
runtime
that
we're
using
right
like
so
you
would.
You
would
do
something
like
go
run,
build.go
you
know,
and
and
and
then
you
would
do
like
you
know,
build
js
test,
runner
right
and
then
the
plug-in
test,
runner
and
you'd
have
that
binary
and
that
binary
would
take
two
things
in
the
plug-in
and
the
test
you
want
to
run.
B
And
then,
if
we
had
something
like
that,
we
could
probably
pretty
easily
make
you
know,
like
helpers
or
ui
extent,
like
code
extensions
for
vs
code
or
something
like
that.
So,
like
oh,
the
test,
runner
is
there
here's
and
like
it
would
just
automatically
take
your
js.
B
You
know
your
underscore
plug-in
underscore
test
js
file,
which
would
be
there
in
in
your
plug-in
project
right
that
we
scaffold
out
with
with
yeoman
and
have
a
test
runner
for
for
at
least
for
javascript
plugins.
I
don't
the
the
go.
Plugins
are
a
little
trickier
because
it's
it's
not
just
built
up
in
memory
and
executed
against
the
code.
There's
an
actual
grpc
element
to
it,
but
there's
probably
in-memory
grpc
servers
where
you
can
like
satisfy
the
endpoint
and
and
do
all
sorts
of
testing
so
anyway.
B
I
think
it's
something
we
definitely
need,
especially
for
what
we're
going
to
be.
Considering
like
this
is
plugin
api
1.0.
We
have
to
be
able
to
get
these
plugins
under
test
and
and
leverage
it.
So
that's
something
that
I've
been
thinking
about.
A
Right,
it's
only
gone
just
enough
yeah
that
that
makes
a
lot
of
sense.
I
you
know,
I
almost
feel
that
part
of
the
releasing
1.2
should
be
one
of
the
things
we
need
to
do
before.
That
is
to
build
a
test
harness
around
plug-in
api
without
that
we're
going
to
run
into
trouble
sooner
or
later
so.
B
Yeah
yeah-
and
I
think
we
have
a
discussion
happening
right
now.
This
is
kind
of
a
tie-in
to
that
on
our
github
discussions
around
converting
the
built-in
modules
that
ship
with
octane
into
plug-ins
and
having
them,
use
the
plug-in
interfaces
to
perform
their
work.
So
using
that
as
like
a
forcing
function
to
stabilize
our
plug-in
apis,
but
also
then
we
would.
We
would
also
have
to
create
some
mechanism
to
be
able
to
get
those
under
test,
because
we
can't,
obviously
we
can't
ship
them
without.
B
We
can't
just
delete
all
the
tests
we
have
around
it
and
like
yeah
they're
plugins,
they
don't
get
tests
like
we
have
to
have
to
come
up
with
some
mechanism
to
properly
test
them.
So
I
think
I
think
going
forward.
That's
going
to
be
the
kind
of
the
key
thing
that
helps
us
drive
a
lot
of
the
changes
and
improvements
for
the
plug-in
apis,
converting
those
modules
which
will
happen
after.
C
C
Something
yeah
so
electron,
I'm
a
quick
update
on
that.
So
I'm
doing
a
I'm
using
the
github
actions
for
the
electron
builder
and
pretty
much
the
pattern
that
I'm
going
with
is
that
the
builder
is
going
to
embed
a
binary,
and
I
think
I'm
having
some
weird
pathing
issues
and
really
electron
is
super
slow
to
build
on
my
workstation
and
in
ci
for
that
matter.
C
But
I
think
it's
gonna
be
kind
of
interesting
to
ship
at
the
moment
or
even
the
builder
at
the
moment,
simply
because
we
have
to
build
the
binary
for
each
particular
operating
system,
then
build
an
electron
with
the
binary
embedded.
So
it's
gonna
be
like
a
build.
It's
gonna
be
like
a
build
matrix
that
gonna.
C
You
know
we
built
the
binary
first
and
then
we
then
build
out
electron
and
for
the
first
pass,
I'm
just
going
to
have
it
just
built,
rebuild
the
binary
on
the
fly
and
then
and
then
just
do
it.
But
I'm
thinking
for
future
releases-
and
I
have
to
figure
out
if
this
is
possible
or
not.
C
But
we
would
have
an
electron
builder
ci
process
that
kicks
off
after
a
particular
release
or
yeah
or
even
just
after
a
particular
release,
and
what
ends
up
happening
is
that
it'll
pull
the
release
binary
into
the
elect
into
the
electron
builder
process.
C
So
then
we're
not
double
building
a
binary
or
hypothetically
just
rebuilding
something
that
already
exists
or
might
be
slightly
different
into
the
electron,
build
which
kind
of
leads
to
an
interesting
case
with
pull
requests
too,
because
we
kind
of
have
one
pipeline
where
we
want
to
have
the
binary
built
on
the
fly
and
another
pipeline
that
we
don't.
So
it's
something
that
I'm
thinking
about
long
term,
but
at
the
moment
I'm
just
going
to
stick
to
the
first
one,
just
everything
in
a
single
pipeline.
C
So
then
we
don't
have
to
think
about
complexity
yet
and
that's
coming
soon-ish.
I
think
it's
just
slow,
because
I
can't
iterate
quickly
on
it.
I
think
I'm
just
heading
into
either
padding
issues
or
just
bad
config
somewhere.
So
I'm
slowly
chugging
through
it.
B
Yep
that
sounds
good,
I'm
I'm
also
working
on
it
and
sam,
and
I
had
synced
before
I
was
out
on
vacation
and
a
lot
of
the
team
was
out
a
week.
Two
weeks
ago,
we
had
just
started
to
like
sink
on
getting
some
local
builds
of
of
electron
and
comparing
it
to
our
existing
electron,
build
system
and
then
using
that
to
kind
of
identify.
Okay,
what
are
the
entry
points
here
and
I'm
like?
How
do
we
want
to
build
this
thing?
And
and
how
are
all
these?
B
How
are
these
pieces
going
to
fit
together
because
currently,
there's
like
this,
this
stream,
rendering
piece
that
runs
and
then
there's
this
front
end
piece
that
you
know
our
stream
generating
piece
that
runs
and
then
there's
a
front
end
piece,
which
is
the
stream
rendering
element
right
and
so
like
getting
that
stream
generator
and
the
stream
renderer.
B
You
know
coexisting
in
in
a
single
binary
and
both
running
and
communicating
to
each
other
there's
various
ways
to
do
it,
which
is
there's
like.
B
We
now
have
access
to
things
like
the
internal
ipc
mechanisms
within
electron,
or
we
can
still
just
use
our
straight
hdp
mechanism,
which
is
what
we're
going
to
do
for
now
is
just
use
http
but
yeah,
so
so
getting
a
new
kind
of
getting
a
new
shell
around
how
we're
building
out
electron
and
getting
it
up
to
date
and
modernized
with
the
with
the
current,
like
best
conventions,
at
least
the
ones
that
we
can
find
and
then
once
that
build
is
happening.
Just
kind
of
outline.
B
B
I
don't
know
what
it's
called
we'll
call
it
a
sprint
we'll
do
like
a
but
like
a
focused
sprint
on
usability
and
interacting
with
octant
via
electron
right,
so
you'll
probably
see
a
whole
new
host
of
issues
that
get
opened
around.
B
You
know
all
you
the
back
buttons
like
we
need
to
add
back
and
forward
buttons
or
some
mechanism
to
support
that.
If,
if
we
find
that
they're
lacking,
maybe
modifications
need
to
be
made
to
like
the
breadcrumbs.
B
I
don't
think
so,
but,
like
you
know
things
like
that,
navigational
things
viewing
resources.
How
do
you
you
know
what
kind
of
mechanism
we're
going
to
have
in
place
for
like
I
want
to
reference
this
resource.
You
know
like
I
like.
I
want
to
go
to
deployments,
but
then
I
switch
contexts
and
I
want
to
go
to
the
same
like
path
right
like
right
now
you
can
do
manual
path,
editing
right,
you
could
just
say
like.
B
I
have
a
long
custom
resource
name
which
I
know
exists
across
multiple
namespaces,
so
I'll
paste
it
in
after
I
switch
the
the
context
or
something,
but
this
nuanced
things
like
that,
just
usability
things
is
really
what
I'm
getting
at
that
we'll
go
through
and
kind
of
identify
and
figure
out
and
make
sure
that
we're
all
those
get
addressed
before
we
before
we
ship
out
yeah.
I
think
that
covers
kind
of
our
current.
A
Approach
also,
probably
a
lot
of
things
that
you
can
gain
from
electron.
Like
you
know,
status
bar.
A
A
B
B
Yeah
notifications,
things
like
that,
like
yeah,
it's
exciting,
so
cool
yeah,
that's
all
I
have
to
add
there.
B
Last
item:
let's
see
no,
that's
it.
We
talked
about
everything
pia
did
you
have
anything
that
you
wanted
to
add
or
talk
about.
B
Great
okay,
which
meeting?
Is
that
actually.
B
Cool
yep,
okay,
yeah
so
expect
some
share
out
about
kind
of
the
higher
level
objectives
for
octant
and
like
like
alignment
with
our
roadmap
and
what
we're
going
to
be
focusing
on
as
we
move
forward.
Yeah
we'll
be
working
with
pia
to
kind
of
determine
some
of
that
stuff
over
the
course
of
this
week
and
hopefully
get
that
shared
out
next
week
or
the
week
after.
A
A
Hey,
since
we
have
some
time,
maybe
I
can
quickly
show
the
I've
been
working
on
how
to
show
the
breadcrumbs
with
a
lot
of
items.
Maybe
I
can
show
that
quickly
and
get
some
feedback.
C
Yeah
sure
just
quick
side
note
what
plug-in
meeting
or
is
that
just
not
relevant
to
me.
D
I
think
sam
met
when
I
said
I'd
like
to
learn
about
plug-ins,
that's
just
with
me
and
wayne.
A
All
right
so
yeah
we've
been
talking
about
breadcrumbs
quite
a
bit,
and
that
is
pretty
much
done
now.
It's
in
a
review
process.
A
I
put
the
pr
out
yesterday,
but
one
thing
that
didn't
get
addressed
here,
that
that
I've
been
working
on
since
is
you
probably
remember
at
some
point,
we
we'd
be
wondering
what
we're
gonna
do
so,
first
of
all,
yeah.
The
breadcrumbs
now
contain
the
drop-downs
when
they
make
sense
and
also
I
did
a
little
bit
of
work
so
if
to
limit
the
number
of
items
we
we
show
here.
So
in
this
case
I
currently
I
set
it
to
10.
A
If
there
is
more
than
10
items,
I
will
display
this
and
then
that
will
open
and
another
extra
items,
and
so
you
can
go
kind
of
go
back
and
forth
which
limits
number
of
items
we
show
in
this
case.
It's
not
that
bad,
but
in
some
cases
I
think
I
have
one
of
my
tests
is,
so
it
can
be
more
than
100
and
there's
definitely
not
the
upper
limit
of
a
number
of
items.
So
so
something
like
this
just
to
quickly
display
wasn't
so
easy
to
do.
A
With
clarity,
but
I
ended
up
just
limiting
number
of
items
we
show
initially
and
then
you
can
expand
that
so
in
this
case
you
can
expand
that
if
in
case
you
you
need
them,
I'm
sorry.
My
system
is
pretty
slow
with
zoom
going
on,
so
it
takes
a
while
just
to
render,
but
it's.
A
A
Yeah,
so
in
this
case
I
think
it's
120
items,
so
we
initially
show
only
10,
and
if
you
want
to
access
the
rest
of
them,
you
can
still
scroll
down
seo
under
20
and
also
reduce
it
back
to
the
original.
So
I
think
this
is
going
to
work
pretty
well
for
both
performance
and
usability
point
of
view,
but
if
you
have
any
feedback,
you
know
that
pr
is
up
for
review.
B
Yeah
I
like
it.
I
do
worry
so
I
was
using
the
pr
today
and
the
one
thing
that
I'm
still
a
little
worried
about
is
just
like
how
useful
like,
in
the
case
where
you
do
have
121
things
right,
like
the
effort
to
like
expand
and
go
all
the
way
down
to
the
bottom,
to
find
the
119th
one
that
you
want
to
click
on
seems
yeah.
B
I
don't
know
it
and,
and
like
I
was,
I
was
noticing
this
with
pods
too,
like
on
a
on
a
large
cluster
with
a
lot
of
pods,
where
you
have
hundreds
and
thousands
of
like
sometimes
thousands
of
pods,
you
expand
it
and
the
list
is
like
yeah,
it's
not
a
useful
list.
It
doesn't
really
help
me.
B
So
I'm
wondering
I'm
almost
wondering
if
we
want
to
like
try
the
the
sibling
approach
and
just
like
use
it
and
see
how
that
feels,
because
having
now
used
the
children
approach
it,
it's
really
great
when
there's
only
a
few,
but
it
quickly
becomes
like
I
don't
know.
I
don't
know
well.
A
A
It's
it's
basically
off
by
one,
if,
if
you're
thinking
in
in
a
in
a
sibling
approach,
but
there
is
still
the
same
amount
information,
so
I
you
know
what
this
does
is
just
make
sure
that
we
I
mean
how
often
you
have
that
many
items
and
how
often
you
just
want
to
access
it,
it
should
drop
down,
and
even
if
you
do
you
know,
maybe
there
are
different
ways
to
to
do
that.
Maybe
you
know
you
can
go
back
to
the
custom
resource
definitions
and
do
filter
and
search
there.
B
A
B
Our
I
mean
our
our
quick
switcher
works
with
custom
resource
definitions.
Doesn't
it.
B
B
A
The
result-
I
don't
know
yeah,
I
I
don't
think
that
belongs
honestly.
I
don't
think
that
belongs
stupid
at
times.
I'm
absolutely
with
you.
We
need
to
do
some
filtering
searching
and
you
know
we
have
this
filter
here
that
I
think
this
should
be
like
not
on.
This
should
be
general,
like
search,
filter
control,
and
I
talked
to
scott
at
some
point
about
that.
Revamping
that-
and
I
know,
they're
doing
some
things
on
tons
of
mission
control
as
well.
So
you
know
just
to
search
and
find
things.
A
Would
you
be
there
right
and
there's
secondary
navigation
item
too?
So
so
I
think
what
what
this
approach
does
right
now
is
just
limits
amount
of
data.
We
are
loading
initially
to
to
improve
the
performance
and
still
allows
you
ability
to
access
everything
else,
although
that
might
be
pretty
tricky.
Sometimes
it
still
should
work,
so
I
think
for
now
we
are
good,
but
I
would
definitely
like
to
add
the
search
at
some
point.