►
From YouTube: Octant Community Meeting - October 28th, 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
A
All
right
welcome
everybody
to
the
october
28th
octane
community
meeting.
I
appreciate
everyone
taking
the
time
to
join
us
this
week.
I
I
mentioned
in
our
flat
channel
and
on
twitter
that
we're
doing
a
new
thing
for
this,
starting
with
the
community
meeting.
So
at
the
the
last
community
meeting
of
every
month
we're
going
to
be
doing
a
kind
of
like
end
of
month
review
where
we
talk
about
good
first
issues
and
getting
started.
A
We
will
reserve
that
for
the
end
of
the
of
the
community
meeting,
but
we'll
essentially
take
up
the
rest
of
the
a
lot
of
time
as
needed
to
kind
of
go
over
those
things
and
you
know,
add
labels
to
any
issues
that
might
be
good
candidates
talk
about
the
ones
that
already
have
labels.
You
know
organize
them
and
then
answer
any
questions
and
help
people
who
are
currently
trying
to
work
on
some
of
these
issues.
A
So
that's
a
new
thing
we'll
be
doing
so
if
you
are
interested
in
that,
hang
out
until
the
the
end
and
join
us.
So
with
that
I
will
get
started
first.
I
want
to
talk
about
the
progress
update
on
o16.2.
A
Slowly,
perfect,
that's
exactly
what
what
I
thought
might
happen.
So,
let's,
let's
see,
let's
just
go
back
to
here
and
instead
of
doing
that,
so
I
don't
feel
like
signing
in
again
we'll
go
to
there's
a
milestone.
That's
attached
to
that
zenhub
board!
So
we'll
go
ahead
and
just
pull
that
up
directly
and
get
up
here.
A
A
So
this
is
where
you
can
kind
of
find
the
the
status
of
those
things
yeah
we're
just
actively
working
through
these
expect
to
see
them
landing
sometime
this
week
and
then
probably
a
release
for
these
things
early
next
week.
If
there's
something
in
this
list,
I
I
encourage
you
to
go
to
our
github
issues.
Look
at
the
milestone
and
if
there's
something
in
here
that
you
think
is
a
good
candidate
for
dot
16.2
that
hasn't
made
it
in.
A
A
The
purpose
of
odot
16.2
is
to
kind
of
get
some
plug-in
fixes
in
place
for
plug-in
authors,
make
make
their
lives
easier
and
then
address
just
some
of
the
outstanding
bugs
around
anything
that
kind
of
crashes
octant
or
or
makes
it
not
render
stuff
to
the
screen,
because
it's
like
a
error
that
we're
not
handling
well,
that
is
that's
kind
of
the
goal
of
what
at
16.2.
So
keep
that
in
mind
when
you
are
going
through
and
considering
issues
for
it.
A
Is
there
anything
that
I
missed
with
that
sam
anything?
No
one.
A
So,
moving
on
to
electron,
yeah,
electron
gonna
be
electron,
and
so
we
are
sam
and
I
have
been
investigating
some
different
options
for
electron.
Looking
at
our
current
builder,
which
is
not
functioning
essentially,
is
in
its
current
state
in
master
and
so
we're
evaluating
kind
of.
Why
and
how
and
and
what
that
might
look
like
if
we
were
to
fix
that
in
place.
We're
also
kind
of
looking
from
the
top
down
like
okay.
A
What
if
we
take
a
clean
electron,
build
something
from
electron
builder
and
like
a
hello
world
shell
and
then
start
to
bring
our
pieces
into
it
and
create
like
a
known
good
state
that
way,
so
we're
exploring
the
different
ways
of
to
to
kind
of
make
it
good
like
we
want
to
avoid
just
wrapping
this
in
a
web
view
and
saying
and
calling
an
electron.
A
We
really
want
that,
like
native
feel
when
you
use
octant
once
it's
an
electron
so
we're
you
know,
slow
and
steady
on
this,
but
we're
we're
being
careful
to
make
sure
that
we
ultimately
we
do
what
we
feel
is
the
best
for
octant
and
the
best
for
the
users
of
octant.
So
I
don't
really
have
much
else
to
add
there,
except
that
it's
it's
still
in
progress,
we're
actively
working
on
it.
Sam
is
there
anything
you
wanted
to
to
add
on
to
that.
B
Yeah,
so
the
there
is
going
to
be
a
couple
of
interesting
things
that
I've
noticed
so
like
one
like
the
monaco
editor
we
talked
about,
there's
also
like
electron,
also
comes
with
its
own
api
for
key
bindings
as
well.
So
there
will
be
like
little
pieces
of
like
functionality
that
we
will
have
to
rewrite
so
it
there.
B
So
the
moved
electron,
it's
not
necessarily
tech
debt,
but
it's
we
have
to
consider
like
supporting
both
the
binary
and
electron
for
a
moment
and
possibly
even
both
forever,
but
we
just
have
to
be
aware
that
there
are
there's
there's
some
nuances
to
running
electron.
A
Yeah,
I
think,
that's
a
good,
that's
a
good
call
out
and
yeah.
I
I
think
we
mentioned
this,
but
just
to
in
case
people
haven't
heard
it
before
our
first
release
of
the
no.17
electron,
we're
going
to
essentially
ship
both
builds,
but
you
once
we
have
established
electron
as
part
of
our
build
pipeline
and
we
start
to
ship
it.
A
We
will
within
a
release
or
two
be
announcing
that,
like
the
the
console
version
is
going
to
be
going
away
and
then,
after
another
release
or
two
we'll
stop
shipping
it
so
just
kind
of
be
prepared
for
that
over
the
next
few
months,
it's
going
to
be
a
slow
process,
we'll
be
very
loud
about
it,
but
you
should.
You
should
know
that
it's
coming
yes,
it's
coming.
A
There
will
be
people
who
are
still
surprised
by
it,
and
we
know
that
and
I
apologize
to
you
in
advance
and
that's
it
for
electron,
so
the
community
survey.
This
was
something
we
mentioned
at
the
last
community
meeting
and
we
want
to
mention
it
again.
So
first
I
want
to
say
thank
you
to
everyone
who
has
already
filled
it
out
and
we
just
wanted
to
re-encourage
everyone
to.
If
you
haven't
filled
it
out
and
you
use
octant
and
you
like
octent
or
you
don't
like
octane,
go,
fill
it
out.
A
We
we,
your
feedback,
really
helps
us
make
octant
better,
and
so
we
really
appreciate
that.
We
know
it's
like
a
little
bit
of
time
out
of
your
day
and
we
do
really
appreciate
and
value
it
and
it
goes
directly
into
making
octet
better.
So
isha
did
you
have
anything
that
you
wanted
to
add
to
that.
C
No
just
wanna
echo
that
all
the
responses
so
far
have
been
super
helpful.
I
feel
like
it's
too
long.
You
don't
have
to
fill
out
the
entire
survey
like
almost
everything's
optional,
so
yeah,
it's
very
helpful.
If
you
have
a
little
bit
of
time
to
fill
it
out.
A
Awesome
yeah,
thank
you
and
isha
was
the
one
who
worked
to
create
that
survey
and
get
the
blog
post
up
that
you've,
seen
on
octan.dev
and
and
all
the
messaging
on
on
twitter
and
everything.
So
thank
you
isha
for
putting
a
lot
of
time
and
effort
into
kind
of
building
that
survey
out.
It's
been,
it's
been
even
the
response.
We've
gotten
so
far
been
really
great.
A
B
Yeah,
I
I
think
I
was
the
only
one
who
added
questions
to
the
document,
so
I'm
excited
for
bumping
it
up.
Unless
somebody
else
also
has
additional
q
a
maybe
on,
I
don't
have
a
youtube
stream
open,
but.
A
Yeah,
no
questions
on
youtube
or
slack
that
I'm
seeing
right
now,
so
we
can
move
on
to
these
sam
if
you
want,
since
you
put
them
in
there,
go
ahead
and
take
it.
B
Yeah
so
the
first
one
is,
and
these
could
also
be
in
the
form
of
issues,
but
I
thought
I
only
thought
of
them
this
morning,
so
maybe
during
the
community
meeting,
so
the
first
one
is
related
to
the
applications
view,
and
I
don't
really
know
how
many
people
actually
use
it
simply
because
it's
not
the
default
view
that
often
boots
up
into.
But
it's
effectively
this
view
where,
if
you
have
the
metrics
server
booted
up
it'll
tell
you
about
your
memory
and
usage,
but
if
not
it'll
just
be
of
under
donut
charts.
B
That
shows
which
pods
are
active
and
which
pods
aren't,
and
so
one
thing
we
could
think
about
doing
is
making
these
donut
charts
clickable
right,
so
it
maybe
we
could
have
it.
So
then,
if
you
were
to
click
like
an
orange
section
of
the
donut
chart
that
represents
like
pods,
which
are
currently
in
a
bad
state,
you
could
click
them
and
it'll
automatically.
B
Take
you
to
like
the
pod
table
view
well
with
the
filter
for
all
of
the
pods
that
are
currently
in
that
state
just
to
see
if
we
can
start
make
leveraging
that
application
view
and
make
it
a
bit
more
useful
and
eventually,
I
think
the
goal
is
to
move
away
from
our
default
overview
page,
which
is
just
a
list
of
data
grids
which
stops
becoming
useful.
If
there
are
a
lot
of
things
on
the
cluster,
so
I'd
say.
B
B
Yeah,
maybe
we
can
see
it's.
B
Let
me
spin
a
box
real,
quick.
D
While
you
do
that,
I
just
wanted
to
comment.
You
know
typically
a
chart,
so
we
don't
charge,
maybe
less
more
than
the
other
ones
are
not
used
as
navigational
elements,
but
in
this
case
I
think
it
might
be
useful
as
long
as
we
don't
too
too
many
a
bit
which
we
currently
don't
so
and
technically.
I
think
that's
that's
pretty
easy
to
do
inside
the
svg
components
we
used
so
so
I
I
think
it
would
be
kind
of
neat.
Actually.
D
We
also
had
a
request
for
tooltips
for
donor
charts,
and
that
is
different
thing.
We
can
explore.
A
Yeah
the
tool
tips
for
donut
charts
and
just
the
charts
in
general,
I'm
I
think,
long
term.
I
would
like
to
move
away
from
us
having
chart
components
and
move
towards
us
using
web
components
to
allow
people
to
embed
charts
great,
and
I
don't
know
what
that
looks
like
yet,
but
that's
like
my
because
there's
so
many
different
kinds
and
there's
so
much
different
like
like
customizations
people
can
make
to
a
chart
and
the
graphics
they
want
and
like
how.
A
So,
if
there's
a
way
that
we
can
make
it
so
that
you
can
just
use
an
octant
web
component
component
and
in
that
you
can
then
put
in
like
there's
a
props
that
gets
passed
in.
So
you
have
access
to
data
and
you
and
it
can
link
you
know
to
wherever
it
needs
to
link
to,
but
then
you're
just
using
whatever
chart
library.
You
want
to
use
that's
my
ideal
scenario.
I
don't
even
know
how
we
would
do
that.
But
that's
that's!
That's
something.
I've
been
thinking
on
that.
D
Yeah,
I
agree,
but
some
core
charts
like
that
is
a
probably
good
example
might
be
might
be.
Good
idea
to
you
know,
have
those
built
in
if
we're
nothing
else,
then
just
to
to
make
sure
the
we
have
a
common
user
experience
when
you
know
plugin
authors,
for
example,
use
them.
So
we
don't
have
a
huge
variety
of
different
visualizations.
A
Yeah,
I
think
I
mean
I
understand
that
I
think
I
think
we
can.
The
the
thing
is
like.
I
don't
want
to
pin
oct
into
some
chart
library
and
then
now
we
are
the
the
maintainers
of
this
chart
library,
because
it's
we're
heavily
invested
in
it
within
octant
right
and
especially
in
the
javascript
ecosystem,
where
chart
libraries
are
changing
all
the
time
and
there's
new
ones
and
some
some
go
away
and
and
like
I,
I
would
much
rather
say
like
here's,
an
octet
web
component.
A
Here's
great
examples
of
how
to
use
this
chart
library
that
we
recommend
with
it
and
then
later.
If
that
chart
library
gets
deprecated
or
stops
being
supported
and
whatever
then
we
can
just
be
like
hey.
We
now
recommend
this
one
and
it
doesn't
like
people
who
still
use
the
old
ones.
So
he's
the
old
one
and
yeah
the
the
like.
A
The
experience
between
various
plugins
would
be
different,
but
we
could
stay
consistent
with
an
octant
itself
and
make
sure
that
anywhere
we
are
doing
charts
as
part
of
core
we're
using
the
same
library
and
then
just
recommend
people
use
that
library
yeah.
That
makes.
D
B
Yeah,
so
the
my
metrics
server
is
hosed
from
testing
some
other
things
right
now,
so
I
have
to
use
the
storybook
just
to
get
an
example
running
so
essentially,
you'd
have
this
donut
chart
and
if
say,
one
of
the
pods
were
in
like
a
warning
state
or
if
it
were
just
being
deleted
whatever
right.
B
If
it's
not,
if
it's
not
running
as
expected,
it
would
be
orange
or
red,
and
so
we
reflected
on
a
segment
of
this
donut
chart
and
currently
right
now,
this
you
cannot
interact
with
the
stoner
in
any
way.
It's
got
it's
used
in
a
card
component
and
it's
got
links
and
it'll
link
you
to
a
resource
viewer,
and
so
the
idea
is,
let's
make,
let's
add
interactivity
to
this
donut
chart
and
so
yeah,
and
so
I
think
that's
the
reference
to
it.
B
It
also
you
know
we
could
also
even
think
about
this
as
like
doesn't
necessarily
have
to
be
a
donut
chart.
We
could
even
start
thinking
about
pie,
charts
and
other
type
of
interactive
graphs
that
might
belong
in
an
applications
view,
but
I
think,
having
that
level
of
interactivity,
but
but
keeping
the
view
more
generalized,
like
the
applications
view,
is
probably
something
we
want
to
do.
I
think
that
seems
to
be
the
right
path.
B
But
but
yeah
nothing,
I
don't
really
have
any
like
substantial
ideas,
yet
I
might
just
even
just
try
to
like,
for
example,
I
don't
even
know
how
to
link
to
a
table
with
a
filter
that
that
would
be
an
interesting
problem
in
itself
right,
because
I
don't
think
we
can
do
that
with
query
params
right
now.
So
maybe
maybe
we
can
like
figure
out
what
that
end.
B
State
should
be
to
save
a
little
bit
work,
but
in
the
meantime,
I'll
start
experimenting
with
with
this
idea
a
little
bit
cool.
So
that's
yeah.
So
that's
for
the
applications
feel
cool.
A
Yeah,
I
think
that
I
mean
I
like
I
like
I,
like
kind
of
where
the
like
the
vein
of
that
idea.
I
like,
where
it's
going
being
able
to
to
do
to
like
apply
the
filtering
of
a
table
server
side,
I
think,
would
be
something
that,
because
right
now
it
is
all
client-side,
so
that
would
be
useful
similar
to
how
we
filter
by
selectors
like
label
the
label
selectors
we
can
filter
on
setting
up,
table,
selectors
or
filters.
A
A
I
swear,
or
I
I
think
it
was,
but
the
nested
navigation,
like
you,
can't
link
directly
to
a
tab
right
now,
and
that
would
be
so
like
a
combination
of
those
two
things
like
being
able
to
filter.
What's
on
the
page
through
labels
and
table
filters
and
then
also
being
able
to
link
directly
to
a
specific
tab,
would
really
give
us
a
lot
of
freedom
in
like
what
interactions
and
what
things
do.
You
could
start
to
scope
things
down
to
like
when
you
click
this.
A
A
I
like,
I
like
so
just
think
about
like
those
larger
scenarios
like
that
as
you're
thinking
about
this
right,
like
yeah
it'd,
be
cool
to
be
able
to
link
from
applications
view,
but
like
just
more
generically
like
linking
to
any
view
with
any
set
of
things.
Filtered
and
selected
would
be
nice.
B
B
Question,
I
don't
know
if
we
have
the
yeah,
that's
okay,
we
don't
need
to
pull
up
the
notes,
but
it
is
the
idea
that
I
see
a
lot
of
requests
for
octant
being
in
cluster,
and
one
of
the
arguments
is
that
if
it's
in
cluster,
then
you
don't
have
to
distribute
octane
as
a
tool,
then
it
circumvents
like
yeah.
Just
people
can
just
log
on
to
you
know
just
log
into
it
and
then
point
in
the
cluster
and
just
have
a
dashboard.
B
C
B
Like
some
other
other
tools-
and
I
figure
well
what
if
octant
could
just
have
like
the
ability
to
create
a
console
like
similar
to
how
we
do
the
terminal
tabs
and
in
there
we
just
package
in
like
you,
could
create
a
pod
and
that
pod
can
run
a
container
that
already
has
cute
control
and
helm
or
whatever
the
tools
are.
B
So
then,
now
we
just
bubble
down
whatever
cluster
tools,
a
developer
might
need
into
some
configuration
file
and
all
they're
doing
is
just
using
often
to
just
spin
up
a
pod
and
because
they're,
it
already
has
access
to
the
cluster
with
acute
config.
Now
they
can
just
talk
to
the
cluster
with
it,
and
now
it
kind
of
solves
that
tool,
distribution,
problem
and
they're
incentivized
to
keep
octan
locally.
Now,
because.
B
Yeah
because
it
effectively
solves
that
class
of
problems
of
how
do
we
distribute
octant
for
them,
because
now
we're
saying
well
now
you
only
need
to
distribute
often
and
not
worry
about
the
tools
but
yeah.
So
I
wanted
to
see
if
people
had
thoughts
on
that
one
as
well.
I
I'd
say,
like
the
reason.
The
reason
I
say
like
octane
should
be
spinning
of
a
pot
is
because
I
don't
ever
see
like
I
don't
want.
B
So
the
better
way
is
just
to
make
that
configurable
to
begin
with
and
just
leverage
the
just
leverage
containers
where
possible,
and
so
then
now
we
just
we
probably
have
to
do
some
like
work
to
make
sure
that
whatever
the
cube
config
is,
can
you
know
is
accessible
to
that
pod
and
then
it's
usable
in
the
cluster.
But
I
think
that's
there's
potential
here.
A
This
is
a
fantastic
idea
like
having
a
like
a
yeah,
just
a
tools,
pod
that
gets
deployed
and
there's
there's
a
console
for
it
and
just
open
and
those
tools
are
connected
somehow
to
the
same
context
and
potentially
even
aliases
for
the
current
namespace
right,
like
you,
you
like,
when
you
click
open
you're,
just
in
that
context,
and
then,
when
you
switch
contexts,
maybe
there's
some
way
that
it
is
switching
context
as
well,
but
in
the
short
term,
just
a
kind
of
one
like
here's,
the
tools
and-
and
you
have
all
the
things.
A
I
think
this
is
a
great
idea.
I
I
I
want
to
use
this
now.
A
No
yeah,
I
think
that's
that's
my
feedback.
I
think
I
think
like
it
is
worth
thinking
about
this
and
and
and
and
just
I
think,
considering
how
we
would
do
it,
what
it
might
look
like
what
those
initial
set
of
tools
would
be,
because
I
think
it's
a
great
idea,
especially
as
we
move
to
being
an
application.
A
Where,
potentially
you
know
the
given
certain
options,
we
could
spin
that
up
on
a
local
machine
using
local
docker
versus
in
their
cluster
right
and
a
terminal
can
can
not
have
any
lag
between
like
going
up
to
apis
and
stuff
like
that
again
that
way
out
in
the
future.
This
is
a
great
idea.
B
Yeah,
I
think,
like
probably
the
goal
for
like
throwing
this
community
meeting
is
just
more
to
see
like
want
to
get
validation
of
the
atm
too
it's
sort
of
like
we
have
things
on
the
roadmap
already
so
like
it's
like
yeah,
it's
a
cool
idea,
but
I'm
not
sure
like
it
will
get
to
it
like
even
in
the
like
next
couple
months.
B
So
it's
like
if
this
sounds
like
something
we
want
to
do
or
if
there's
validation
for
it,
we
can
adjust
the
road
map
as
needed,
but
just
one
like,
I
think,
like
the
I
think
the
idea
to
come
across
here
is
that,
like
we
like,
we
have
things
that
we're
going
to
be
working
on
and
unless,
like
there's
a
compelling
reason
to
say
yes,
we
are
in
fact
going
to
do
this
and
we
want
this
now.
It'll
just
stay
a
good.
A
B
A
A
All
right
last
call
for
any
q
a
discussion
before
we
move
on.
Oh,
I
see
hey
just
mark.
I
was
watching
the
youtube
stream
hi
mark.
I
used
to
work
with
mark
many
actually
multiple
times.
I
worked
with
market.
A
All
right
so
now
we're
going
to
get
into
this
new
kind
of
thing
we're
doing,
which
is
this
end
of
month
review.
I
think
it's
actually
really
helpful
and
for
for
us,
as
well
as
the
community,
so
the
just
to
quickly
cover
the
goal
here
is
to
provide
help
and
answer
questions
if
you're
already
working
on
an
issue
add
more
context
to
issues
we'll
as
we
discuss
them
and
then
surface
and
label
any
issues
that
might
be
good
candidates
that
currently
aren't
currently
unlabeled.
A
A
Running
pods
running
on
each
node,
so
this
issue
was
actually
one
that
I
labeled
as
a
good
first
issue.
Let
me
let
me
increase
the
font
size
on
this.
A
A
It
is
one
thing
it's
kind
of
this
contained
piece
that
is
creating
a
whole
new
view,
specifically
around
what
happens
when
you
click
on
a
node
in
octant
right
now,
as
they
point
out,
you
can
do
a
cube,
ctl
describe
node
and
what
you
get
is
this
list
of
everything
that's
running
on
the
node,
including
resource
usage
and
right
now
in
octane,
when
you
click
on
a
node,
you
don't
get
that
you
get
a
screen.
That
is
not
very
helpful.
A
So
the
reason
I
like
this
was
because
it
it
it
touches
everything,
but
it
does
it
in
a
contained
way.
You
you're
you're
only
really
you're,
just
not
just
but
you
you
are
making
a
describer,
and
maybe
some
you
really
are
making
a
new
describer
for
for
the
nodes
and
and
how
we
how
we
display
those-
and
I
think
that
yeah.
I
think
that
this
is
a
good
one.
For
for
someone
to
take.
It
would
definitely
involve
some
hands-on
working
with
the
team.
A
You'd
have
to
learn
kind
of
the
front-end
and
back-end
apis
and
and
you'd
be
definitely
in
the
internals
package
dealing
with
our
describers
and
and
printers
and
listing
and
pulling
things
from
the
object
store
using
the
probably
the
the
the
cluster
client
that
we
have
inside
the
api,
so
yeah
this
this
is
this
would
actually.
I
think
this
would
be
a
really
fun
one
for
someone
to
do.
A
I
almost
did
it
on
on
the
weekend
like
almost
like,
but
I
was
like
we
should
save
things
like
this
for,
for
maybe
someone
else
to
come
in
and
look
at
them
and
do
them,
because
I
was
like
real.
I
was
like.
Oh,
we
could
do
this,
so
anyone
want
to
add
anything
to
this,
one
that
I
that
I
might
have
just.
B
Yeah,
it's
probably
if
anything,
there's
gonna
be
a
lot
of
typing.
I'd
say
like
prs
like
this,
that
modify
things
under
the
printer
typically
are
just
verbose.
B
So
for
anyone
who
is
thinking
about
picking
up
as
this
as
a
good
first
issue,
it's
I'd
say
it's
still.
It's
not
difficult,
but
they're
just
a
lot
of
pieces
to
think
about
so,
and
I
don't
think
we
have
much
like
a
lot
of
times.
We
probably
just
rely
on
people
to
discover,
I
guess,
like
they're,
the
two
pieces
right,
like
just
understanding
like
how
the
types
are
defined
and
how
to
use
client
go
and
then
also
like
understanding.
B
How
often
gives
things
to
the
object
store,
and
so
they
kind
of
have
to
learn
all
those
abstractions
on
their
own
before
being
able
to
work
on
an
issue
like
this,
so
maybe
there's
room
also
like
for
whoever
picks
this
up
to
help
improve
our
documentation
or
just
like
talk
about
what
was
difficult
about
getting
ramped
up
to
be
productive
for
this
issue.
A
And
then
the
next,
so
here's
one
this
one
was
opened
recently.
It
is
change
the
default
shell
to
bash
sam
pointed
out
this
interesting
approach
of
just
attempting
to
try
multiple
shells
until
one
works,
and
I
actually
think
that
is
a
pretty
good
idea.
Resource
wise.
It
doesn't
cost
that
much
to
just
go
ahead
and
try.
You
know
you
just
loop
through
a
handful
right.
Try,
maybe
bash
first
or
or
even
you
know,
could
even
add
in
z,
like
zsh,
is
becoming
more
common.
A
I
don't
know
how
common
it
is
on
containers,
but
it
is
becoming
more
common,
so
you
could
loop
through
a
set
of
standardized
terminals.
You
know
shells
and
then
you
know
go
into
the
first
one
that
works
and
just
kind
of
put
them
in
the
order
of
of
like
most
useful
and
yeah
the
effort
involved.
In
doing
this
really
it
looks.
A
I
followed
this
example
that
that
sam
provided
and
the
crew
plug-ins
and
in
a
similar
manner
to
looking
for
a
user.
You
could
do
it
for
shells.
It's
I
wouldn't
say
it's
complicated.
Where
we
do
terminal
sessions
like
where
we
create
the
terminal
is
it
can
be
grepped
for
easily
in
our
code.
A
It's
like
you
just
search
for
terminal,
you'll,
you'll,
start
you'll
like
find
a
lot
of
the
spots
where
we
do
our
terminal
creation
and-
and
you
can,
I
think
you
can
also
search
for,
I
think,
we're
hard
coded
sh,
I'm
pretty
sure
if
you
search
for
bin
sh
you'll
find
exactly
where
we've
hard
coded
it.
So
that
is.
D
So
I
I
like
that
approach,
but
I
have
two
concerns.
I
don't
know.
Maybe
we
shouldn't
get
into
that.
Maybe
we
should
take
that
offline.
I
I
was.
I
was
kind
of
hoping
we're.
Gonna
give
user
a
little
more
control
over
this,
because
you
know
I
I
like
the
idea
of
doing
the
like
a
search
and
and
but
to
me
that
sounds
like
special
option
like
auto
detection
of
the
the
one
that
they
can
use,
but
you
know
at
least
me
as
a
user.
D
A
Yeah,
so
I
can
give
a
little
extra
background
into
that.
Sam
can
too
same
because
sam
and
I
both
worked
on
the
first
iteration
of
terminals
in
octane,
we
had
the
ability
to
select
the
shell
originally
right.
Most
cases.
People
have
no
idea
what
shell
is
available,
so
they
would
be
like.
Oh,
I
selected
bash,
and
it's
and
the
thing
fails.
I'm
like
oh
well.
That
container
only
has
this
h
right,
they'd,
actually.
C
A
So
in
most
cases
they
actually
don't
know
what
shell
is
even
in
the
container,
if
there
is
one
at
all,
and
so
we
removed
that
and
just
defaulted
to
bin
sh,
since
it
was
the
most
common.
So
I
think
I
think
providing
a
selector
when
it's
when
it's
just
going
into
some
random
pod
is
less
useful
than
maybe
like
when
it
is
like
what
sam
was
talking
about.
Where
we're.
A
Having
like
this
octane
console,
then
that
I
could
see
having
a
preference
of
saying
like
we
have
these
three
shells
installed,
you
can
pick
the
one
you
want.
D
I
see
yeah
that
makes
sense
the
other.
My
other
concern
is
you
know,
just
since
we'll
have
to
do
that.
Every
time
it's
going
to
be
a
little
bit
of
latency
delay
there.
So
in
case
it
fails
right
at
the
first
one
so
right
but
yeah.
I
like
the
idea,
especially
now,
and
when
I
think
about
it,
you
know
based
on
that
cool
yeah,.
A
No,
it's
just
it's.
Just
no
yeah
they're,
just
saying
that
that
so
when
they
log
in
the
default
shell
is
sh.
Sh
is
limited
every
time
they
log
in
they're
having
to
switch
to
bash.
I
I
don't.
I
don't
know
that
the
the
the
switch
user
is
significant.
There.
I
think,
what's
significant,
is
that
when
they
drop
in
they're
dropping
in
in
in
sh
and
they
would
rather
drop
in
and
bash.
A
D
A
Yeah
I
I
yeah.
I
think
I
think
that
when
we
can
put
the
pr
up
and
then
ping
the
person
and
say
hey,
is
this
what
you're
hoping
for
so
this
one's
actually
in
progress,
and
we
just
wanted
to
show
that
it
is
in
progress
and
and
and
call
out
and
slidelin
slading
sladdin.
I
think
I'm
saying
that
right.
Thank
you
for
getting
started
on
this
issue.
If
you're,
I
don't
think
I
don't
think
they
are
around
right
now,
but
yeah.
A
This
one
is
a
good
example
of
a
good
first
issue
that
someone
just
picked
off
and
started
working.
So
thank
you.
That's
all
I
have
for
that
one.
I
just
wanted
to
say
thank
you
and
sam's
been
helping
with
that
one
and
I
think
it's
yeah.
C
B
Oh,
this
one
is
just
a
change
in
how
generating
protophiles
are
going
to
work.
So
currently
we
get
this
deprecation
warning
because
it's
missing
go
package,
and
so
I
haven't
really
read
through
the
docs
on
like
what
that
flag
is
supposed
to
mean
are
supposed
to
do.
B
I
think,
if
I
recall
correctly,
like
they're
like
the
package
names,
it
just
has
to
make
sure
that
they're
all
unique
between
the
generated
files
and
this
flag
just
makes
sure
that
you
are
using
unique
names
everywhere,
and
this
one
is
just
going
to
be
required
in
the
future.
So
we
just
want
to
stay
on
top
of
that,
and
just
not
have
our
photograph
generation
unexpectedly
break
because
of
an
upgrade
cycle.
A
Yeah,
I
guess
that's
a
good
first
issue.
I
don't
know
that
seems
seems
like
there's
some
intimate
detail
there
that
that
makes
it
matter.
I
I
you
know
what
I
that's
not
a
good
first
issue.
That's
our
like.
We
should
be
the
ones
doing
that
this
is
just
like.
Okay
go!
Do
our
go,
do
our
dependency
update
for
yeah?
Ignore
that
one
folks
we'll
do
that.
A
Sladyan
got
asked
said
they
would
like
to
contribute
to
this
one
as
well
looks
like
sam
responded,
so
I
think,
is
there
anything
you
want
to
add
to
this
one
sam?
It's
been
a
while
it's
back
in
august,
so
it's.
B
Yeah
this
one,
I
think
when
policy
rules
are
just
added,
I
was
being
lazy
and
just
added
like
a
set
of
dummy
rules
and
there
could
theoretically
be-
and
maybe
not
just
better,
just
better
coverage
across,
like
you
know
not
just
have
like
blank
strings
everywhere,
but
like
just
a
healthy
variety
of
various
possible
rules
and
making
sure
that
they
just
show
up
properly
on
the
front
end
as
well,
and
so
currently
right
now
it's
just
healthy
and
update
right,
and
so
we
can
just
take
some
more
examples
and
just
add
a
few
more
into
the
mix
just
to
make
sure
it's
good
but
I've.
B
But
on
the
other
hand,
I've
never
heard
of
anyone
saying
anything
about
this
piece.
So
it's
you
know
just
a
chore,
but
test
coverage
is
always
good,
so
yeah,
it's
there.
A
A
B
Yeah,
I
think
this
one's
closable
just
because
we
eventually
moved
to
just
a
plain
ghost
script,
instead
of
because
before
we
were
using
make
then
we'd
have
to
make
sure
like
the
windows
folks
had
make,
and
I
don't
know
they're
like
600
different
makes
you
could
install.
A
B
So
I
think
now
it's
just
they
should
have
go
installed
and
if
someone
is
working
on
this
repo
having
go
installed
is
a
reasonable
requirement.
Okay,.
A
And
that's
it!
So
that's
what
we
have
for
good.
First,
let's
just
review
our
help
wanted
real,
quick
and
then
we
can.
If
there's
any
issues
you
want
to
surface
that
haven't
been
covered,
that
you
know
about
we'll
do
that.
So,
in
the
help
wanted,
we
have
the
container
attributes
formatting
for
long
values
and
command.
A
Now
I
don't
know
that
we
have
a
clear
distinction
between
help
wanted
and
good
first
issue
as
of
right
now
like
this
might
be
both
I'm
not
sure
so
we'll
go
through
right
now
and
find
out
containers
attributes
for
yeah.
That
is
long,
that's
it's
and
then
it
and
then
it
pushes
all
this
out
of
the
of
the
card
and
then
yeah.
So
that's
not
great.
I
think
this
is
potentially
both.
I
think
it's
help
wanted
and
good.
A
First,
if
you're,
if
you're
good
at
css
and
styling
the
suggestion,
does
it
switch
to
a
vertical
table
for
everything.
C
B
Like
ross
gave
us
a
once-over
and
like
before,
we
were
actually
using
the
wrong
thing.
We
were
not
using.
We
were,
I
think,
yeah
we
weren't
using
the
correct
table.
I
think,
like
this
looks
vastly
different
today
now
and.
D
Right
yeah,
they
have
quite
a
few
places
where
we
don't
show
the
whole
thing
I
mean
so
what's
the
ideal
solution
so,
for
example,
this
one
container
wordpress
should
be
just
to
ellipsis,
probably
I
would
say,
and
tooltip.
A
A
I
mean
yes,
I
think
the
the
yes
things
can
be
improved,
but
I'm
very
tempted
to
say
that
this
this
original
issue
is
is
fixed,
like
the
the
original
issue
was
that
everything
is
is
pushed
out
of
out
of
line,
and
you
can't
read
it
and
it
doesn't
fit
into
the
container
they're
too
long
and
they're
not
displayed
correctly
right,
and
I
think
that
that
case
is
fixed
now,
just
based
on
the
current
octane
and
looking
at
like
this.
This
screenshot
here.
A
B
But
I
think
just
being
more
specific
with
the
issue
would
help
iterating
on
this.
A
Yeah,
so
when
I
I'll
I'll
mark
that
one
to
be
closed
out
and
I'll
comment
and
say
you
know
if
there,
if
there
are
further
improvements
that
you'd
like
to
see,
you
know
based
on
you
know,
if
you
have
more
feedback
and
further
improvements
based
on
how
things
look
now,
which
you
commented
back
in
march
same
after
after
those
commits
went
in
so
I
think
we're
in
a
good
spot
to
say,
like
here's,
here's,
the
updates,
let
us
know
how
else
we
can
improve
and
we'll
we'll
do
that.
A
Cool,
so
those
are
the
the
current
ones
that
we
have
labeled
do
you?
Do
you
all
have
any
issues
that
aren't
currently
there?
Unlike
that
you
know
of
off
the
top
of
your
heads.
I
know
we
we
just
started
doing
this
this
month,
so
probably
probably
have
more
for
next
month.
But
if
you
know,
if
you
have
any,
you
can
think
of
off
top
of
your
head
that
you
would
like
to
go
over
as
potential
good
first
issues.
We
can
do
that
now.
D
I
mean
some
require
a
little
more
help,
a
little
more
guidance
but
there's
if
for
everybody
out
there
interested
in
and
in
trying
to
help
us
and
trying
to
put
their
tools
in
a
northern
development.
I
I
highly
encourage
everybody
to
you
know,
take
any
issues
they
like
and
they
it's
close
to
their
interests
and
will
definitely
help
them
get
to
the
point
where
they
can
be
productive
but
but,
in
the
same
time
it.
D
I
think
this
is
a
great
exercise
and
we
should
keep
doing
it
and
not
only
doing
it
during
the
the
this
meeting,
but
also
when
we
go
through
the
issues
and
especially
on
our
planning
meetings
just
to
to
designate
good
first
issues,
because
that's
you
know
where
people
usually
start.
A
Yeah
yeah
and
that's
kind
of
the
I'm
hoping
that
it's
like
a
forcing
factor
right,
knowing
that
we
are
going
to
be
doing
this
at
the
end
of
every
month,
we'll
be
like.
Well,
we
better
have
something
so
we'll
have
to
we'll.
Have
that
in
mind
as
we're
looking
at
issues
but
yeah,
I
I
mostly
agree
with
the
the
sentiment
that
all
issues
are
good
first
issues
but
like
like
this
one
here
right,
streamer,
test
flake,
that's
not
a
good
first
issue.
Don't
don't
do
that!
A
I
guess
do
it
if
you
want
to,
but
I
wouldn't
recommend
that
as
a
good
first
issue,
but
yeah
we're
happy
to
help
you
get
as
deep
into
any
issue
that
you
are
interested
in
whether
it's
front
end
back
end
a
combination
of
both
but
yeah.
I
think
the
the
real
goal
of
the
good
first
issue
labels
to
to
try
and
identify
the
ones
that
we
feel
are
not
so
that
you
can
get
into
and
kind
of,
just
like
complete
as
this
one
piece
and
here's
a
here's,
a
deliverable.
A
So
yeah,
that's,
I
think,
that's
well
that
covers
that.
I
don't
really
have
anything
else.
Let
me
see
if
there's
doesn't
look
like
there's
any
questions.
Anyone
have
anything
else
before
we
wrap.