►
From YouTube: Octant Community Meeting - Feb 26, 2020
Description
February 26, 2020
Agenda
Latest bug fixes and updates
Plugins can update summary sections #718
Plugin tabs duplicated #728
Status indictors #716
Logging epic updates #660
Azure Kubernetes Terminal
Azure Kubernetes Logging
Reminder, we have nightlies
https://github.com/vmware-tanzu/octant#nightly-builds
Proposal Review
Combined Logging #733
Open Q&A - add your questions here!
Dependency updates (Milan)
dep check during CI/Actions running
dev deps have lower concern
try to keep deps and transitive deps Apache2 and friends.
Issue #448 open to PRs? Guidance would be helpful
A
Hi
everyone
and
welcome
to
another
episode
of
the
octant
community
today
is
February
26,
2020
and
per
usual.
We
have
a
bunch
of
things
to
go
through
on
the
agenda
if
you
want
to
add
anything
to
the
agenda
as
the
discussion
topic
or
otherwise.
Please
do
so
I'm
sharing
the
agenda
in
the
chat
there.
If
you
have
any
questions
or
comments
throughout
the
meeting,
please
just
unmute
yourself.
If
you
have
any
anything,
you
want
to
add.
A
I'm
gonna
share
my
screen
here,
so
you
can
see
the
the
agenda
as
well
and
if
you're
not
talking,
please
make
sure
your
mute
it.
So
let
me
share
my
screen,
alright,
so
for
the
agenda
today,
we're
going
to
go
through
a
bunch
of
bug,
fixes
and
updates
talk
a
little
about
the
Knightley's
and
then
a
proposal
review
as
well,
and
we
do
have
a
open
Q&A
at
the
end
here
with
dependency
updates
from
me
all
right,
who's
up.
First.
B
B
It
came
in
as
a
request
from
quite
a
few
people
or
who
are
offering
plugins,
but
this
is
the
ability
to
update
the
summary
section
of
a
component,
and
what
this
allows
you
to
do
is
to
take
the
information
useful
to
your
plug-in
and
insert
it
into
the
summary
section,
such
as
links
to
other
information
or
call
to
actions
for
the
for
the
user.
So
Brian
was
in
in
the
process
of
working
on
a
plug-in
and
needed
this
feature
and
went
ahead
and
implemented
it
alongside
the
to
fix
that
Sam
did.
B
You
just
got
duplicate
plug-in
tabs.
We
were
holding
on
to
a
reference
of
the
of
the
OL
of
the,
so
we
were
looping
through
the
plugins
that
were
installed
and
we're
adding
the
tabs.
The
problem
was,
we
were
holding
on
to
the
reference
of
the
first
tab
that
we
grabbed
and
just
appending
it
over
and
over.
So
if
you
had
three
plugins
installed,
you've
got
three
plug-in
tabs
from
I
think
either
the
first
plug-in
or
the
last
plug-in
that
was
in
the
list.
I,
don't
remember
which
direction
it
was
going,
but
now
it
it
works.
B
So
Sam
fix
that
up.
So
now
you
can
actually
have
multiple
plugins,
adding
multiple
tabs
for
the
same
object
as
well
as
your
plugins
updating
the
summary
component.
So
this
is
this
is
a
really
useful
for
anyone.
Who's
writing
plugins,
especially
if
you're
dealing
with
the
built-in
objects
and
then
the
final
thing
that
is
a
new
feature,
is
the
status
indicators
for
text
components,
a
lot
of
our
as
Brian
mentioned
here
with
conditions.
A
lot
of
our
text.
B
Components
are
used
in
places
that
have
double
negatives,
for
example,
in
this
case,
there's
it's
a
positive
thing,
but
the
status
is
false,
so
being
able
to
put
a
success
or
I
think
okay
status
on
that,
so
it
shows
up
with
a
green
indicator
so
that
you
know
this
is
visually.
It
helps
kind
of
indicate
that
it's
a
it's
a
successful
thing,
we'll
probably
look
at
extending
this
and
changing
the
shapes
of
each
of
the
statuses
so
that
it's
not
solely
dependent
on
the
color.
But
for
now
it
is
just
a
just
a
color
dot.
B
We
covered
the
logging
updates
last
time
and
there
has
been
a
few
more.
We
have
fixed
the
the
the
logging
tab
under
a
juror
kubernetes
measure,
easure
easure.
I
guess
we
fixed
the
the
logging
tab.
There,
we've
added
some
case,
sensitive
filtering
output
for
the
regex
matching
on
the
search
box.
That's
now
under
logging,
milan
was
doing
that
work
and
then
we've
also
added
the
when
you
when
you're
searching
in
you,
you
use
the
forward
and
back
buttons.
B
C
Cover
pretty
much
all
a
year,
their
support
for,
and
seascape
codes
yeah
there
was
some
some
others
minor
enhancements
like
layout
of
the
search
window,
and
things
like
that.
So
I
think
this
epic
is
in
the
pretty
good
shape.
I
think
with
the
the
only
the
main
big
remaining
thing
is
the
one
we're
gonna
cover
is
the
combining
the
logs
and
making
sure
those
get
in.
Don't
talk
about
that
later,
but
other
than
that.
To
think
that
this
looks
pretty
good.
D
B
I
want
a
quick
call
out
as
a
reminder
that
we
have
nightly
builds
so
a
lot
of
folks
that
were
asking
when's
the
next
release.
When
can
I
get
the
that
fix,
that
you
just
put
in
that
fixed
my
thing
and
so
and
I
and
I
will
say
that
our
that
our
nightly
builds
though
they're
there
they're
not
always
going
to
be
perfect.
They
are
a
pretty
good
they're,
pretty
good
option
for
getting
early
access
to
octant
features.
We
are
our
release.
B
B
You,
okay,
so
the
the
next
thing
is:
there's
a
I
wanted
to
do
a
proposal
review.
So
this
is
something
that
we've
done
in
the
past
a
little
bit,
but
we're
gonna
start
doing
more
of
so.
First
I
just
want
to
give
some
basically
set
the
tone
for
what
a
proposal
review
will
look
like
on
these
calls
and
then
I'll
go
ahead
and
dive
into
doing
a
review
of
the
combines
logging
proposal
so
boring.
A
B
A
B
B
What
am
I
sharing?
Okay,
you
see
the
browser
window
now,
yep,
perfect.
Okay,
let's
go
here,
let's
go
here
so
in
our
controlling
guide.
We
have
this
section
that
talks
are
about
proposals,
and
so
we
are
gonna,
try
and
be
doing
more
of
this,
basically
any
consider
making
a
proposal
for
any
feature.
That
is
a
body
of
work
that
is
going
to
probably
take
more
than
even
just
a
day
or
two.
Then
it
probably
needs
a
proposal
and
needs
to
be
thought
about
a
little
bit.
B
So,
with
that
said,
a
proposal
review
during
these
community
meetings.
That's
essentially
going
to
be
mostly
a
one
way:
presentation
of
a
person
showing
you
all
of
the
work
that
the
end
and
thought
and
effort
they've
put
into
a
thing
and
allowing
you
to
go
to
their
polar
quest.
Read
it
further
and
then
have
comments
and
input
on
it.
B
We
are
not
going
to
have
really
a
lot
of
back
and
forth
on
proposal
reviews
during
this
meeting,
mainly
because
it's
the
first
time
you're
seeing
the
thing
from
a
person,
and
we
want
to
avoid
reactionary
opinions,
and
we
want
to
avoid
things
that,
like
Oh,
have
you
tried
this?
Did
you
think
of
this
like?
Maybe
they
have?
Maybe
they
haven't?
B
B
It'll,
be
you
presenting
the
thought
and
work
that
you've
done
to
a
group
of
people
and
then
they
will
take
and
do
their
work
to
go
comment
and
make
suggestions
so
that
I
just
wanted
to
set
it
up
so
that
people
kind
of
understood
the
how
things
are
kind
of
going
to
work
with
our
proposal
reviews
and
with
that
I
will,
unless
there's
anything
that
someone
wants
to
add
or
ask
about.
I
will
move
on
to
talking
about
combined
bargaining.
B
Okay,
so
combine
blogging.
This
came
up
when
we
were
working
on
the
logging,
epic,
and
it
was
a
feature
request
that
we've
had
in
the
queue
for
a
while.
The
idea
here
is
that
it's
the
ability
to
view
all
the
container
logs
for
a
given
workload.
Currently,
you
have
two
requests
each
container
logs
separately.
This
is
not
generally
a
workflow
that
a
lot
of
people
use
most
people,
even
when
they're
typing
cube,
CTL
commands
tend
to
just
default
to
all
logs.
B
A
lot
of
people
have
aliases,
so
it's
all
logs
and
then
they
use
their
command-line,
tooling,
grep
and
act,
and
things
like
that
to
filter
the
results
of
the
output,
to
limit
it
to
certain
containers
or
to
limit
it
to
certain
things.
So
that's
a
it's
a
very
common
pattern.
We
see
with
usage,
so
that's
something
we
kind
of
want
to
emulate
in
octant
the
so
the
goals
here
are
to
combine
the
logging
output
from
multiple
containers.
We
would
tag
mark
which
log
lions
are
from
the
container.
B
End
I
think
will
be
sufficient
to
handle
all
of
the
the
log
filtering
needs
and
that's
something
that
we
can
always
revisit
later
and
people
can
comment
on
when
they
go.
Look
at
this.
So
our
current
implementation,
so
our
existing
log
streaming
in
quotes,
is
done
via
log
endpoint,
with
a
JSON
request,
and/or
an
xhr.
B
There's
a
polling
mechanism
that
exists
within
our
current
implementation,
the
on
the
pod
log
streamer
and
it
pulls
every
five
seconds.
So
every
five
seconds
were
actually
reattaching
to
the
container
reopening
the
stream
consuming
the
whole
stream
and
then
sending
it
back
over
the
wire.
So
it's
actually
a
pretty
expensive
process.
The
way
we're
currently
doing
it,
so
the
new
suggested
implementation
would
be
that
we
would
create
a
sentinel
value
of
all
containers.
It
was
actually
recommended
in
the
original
issue
and
I
kind
of
liked
that
approach.
B
B
An
event
type
is
just
an
internal
type
representation
for
our
WebSocket
stream
and
and
we
use
those
so
that
we
can
subscribe
to
specific
events.
We
use
it.
That's
how
you
get
subscribed
to
the
component
data
that
renders
on
the
screen.
It's
how
you
get
subscribed
to
terminal
data
that
streams
into
the
terminal.
We
would
convert
the
existing
logging
mechanism
to
an
event
type
so
that
a
kid
that
log
data
can
be
placed
into
the
WebSocket
stream
instead
of
being
sent
out
over
a
standard,
xhr
JSON
response.
B
We
also
want
to
extend
our
existing
log
entry
to
include
the
container
log
or
the
container
that
the
log
entry
is
from.
Currently
it
just
has
the
the
log
line,
as
well
as
a
timestamp
field.
We
we
broke
it
out
into
those
two
fields.
It's
what
allows
you
to
toggle
timestamps
on
and
off,
when
you're
looking
at
the
log
viewer
in
octant.
This
is
this
will
be
adding
another
another
field
to
the
log
entry,
which
will
be
the
container
that
the
log
entry
originated
from.
B
B
We
will
wrap
each
of
the
container
log
streams
using
a
go
routine
and
within
that
we
get
back.
These
read
closers,
which
is
an
interface
that
allows
you
to
read
from
and
close
a
stream
go,
has
a
mechanism
built-in
mechanism
which
is
I/o
multi
Reader,
which
allows
you
to
concatenate
all
out
as
one
stream.
B
The
problem
is
is
that
we
need
to
be
able
to
identify
each
line
and
what
container
it
came
from
and
that
information
is
not
baked
into
the
the
logs
entries
that
are
returned,
so
we'll
have
to
kind
of
implement
our
own
multi
reader
like
function
that
contains
a
map
of
the
container
ID
and
the
reader
that
we
got
back
from
the
stream
call.
And
then
we
can
use
that
to
generate
that
log
entry.
That
I
was
talking
about
that
has
the
extra
metadata
of
the
container
ID
and
we
can
write
those
entries
onto
a
channel.
B
We
can
then
have
a
worker
loop
that
is
reading
that
channel
and
streaming
those
entries
out
to
the
WebSocket
client
on
the
front
end.
The
WebSocket
client
would
be
subscribed
to
that
stream,
and
then
it
would
place
those
entries
into
the
log
viewer
similar
to
how
the
terminal
works.
Now,
some
things
for
consideration
when
we're
doing
stream
aggregation
is
that
we
need
to
make
sure
that
the
worker
loop
itself
respects
any
context.
That's
passed
in
and
will
properly
cancel
out
streams
when
navigation
changes
or
the
the
application
is
being
restarted
or
closed.
B
We
also
want
to
make
sure
that
that
the
streams
themselves,
the
close
method,
is
being
called
on.
All
of
the
streams
should
something
like
context
switch
or
like
change
in
cube
config,
something
like
that
happens
on
the
front
end
we're
going
to
extend
our
existing
law
component
so
that
the
data
is
coming
from
the
WebSockets
surface,
instead
of
redrawing
the
component
every
time
right
now.
B
What
we
do
is
that
when
that
xhr
response
comes
in,
we
actually
redraw
the
entire
component
with
the
new
data
in
there
and
fortunately,
angular
hides
the
the
redrawing,
and
so
all
the
new
data
is
loaded
into
the
component.
But
it's
still,
if
you
look
at
some
of
the
timings
on
that
page,
it's
actually
a
fairly
expensive
process,
especially
as
the
logs
start
to
grow.
B
So
this
will
kind
of
move
us
away
from
that
and
and
get
us
into
similar
to
how
we
deal
with
terminal
data,
where
we
send
out
the
big
stream
of
log
information.
That's
there
and
then
you're
sitting
waiting
for
new
data
to
come
across,
and
then
I
touched
on
this
a
bit
earlier.
But
we
will
have
a
change
to
the
front
end
component
so
that
the
container
selector
is
defaulted
to
all
containers
and
then
you
would
also
be
able
to
it
would
turn
into
kind
of
a
multi-select
where
you
could
say.
B
I
only
want
to
see
logs
for
these
two
containers
or
I
only
want
to
see
log
for
this
one
container,
and
so
that's
the
current
set
of
proposed
changes
to
get
combined
logging
in
place.
This
is
the
last
issue
that's
outstanding
for
our
logging
epoch,
which
was
to
get
things
updated
and
more
usable
for
folks.
There
is
a
this.
Pr
is
up
right
now
and
publicly
visible
733.
B
You
can
comment
on
it.
Make
suggestions
reread
through
it
take
the
time
to
go.
Look
at
the
existing
logging
I
would
encourage
you
to
go.
Look
at
the
current
code.
I
put
some
snippets
in
here
under
the
streaming
abrogation
aggregation
and
actually
called
out
some
of
the
places
where
this
code
currently
lives.
B
B
Yeah
that
would
that
that
is
just
as
helpful
as
as
as
having
concerns
is
saying,
like
this
looks
good
yeah.
We
appreciate
all
of
that.
So
so
with
that
we'll
move
on
to
open
Q&A
Milan
had
had
dependency
updates
in
there,
but
I'm
actually
gonna
go
down
to
the
448
issue
first
and
then
I'll.
Let
Milan
take
the
the
dependency
updates.
So
I
wanted
to
address
this.
B
The
dashboard
still
not
embeddable
stuff
I
know
we
had
a
quick
conversation
about
it
last
week
and
I
see
that
I
see
a
and
Ian
and
Jordan
are
on
the
call.
So
yes,
so
I
I
will
want
to
know
what
your
current
experience
is
and
I'm
curious.
If
the
environment
variable
thing,
if
you're
able
to
look
into
that
more
or
if
you
hadn't
had
a
chance
yet
and
I
want,
and
then
we
can
go
from
there.
E
So
we
looked
at
what
we
currently
had
and
one
thing
that
would
make
our
lives
quite
a
bit
easier
is
being
able
to
in
our
main
go
essentially
where
we
run
airship.
Ui
is
to
be
able
to
execute
octant.
Currently
we
can't
do
that.
So
we've
run
a
command
line,
call
using
go
to
run
octant,
which
is
one
reason
that
we
were
talking
about
the
flags
and
the
environment
variables.
B
B
Okay
and,
and
so
ideally,
you
would
like
to
be
able
to
kind
of
call
that
Achtung
command
I
think
it's
in
command.
Go
or
command
mean
that
there's
that
octant
helper
function,
that
kind
of
bundles
everything
up
and
starts
and
just
like
kick
starts
the
whole
process
and
I
I.
Remember:
Gary
called
out
that
the
logger
itself
has
some
pride
feels
that
prevent
it
from
being
passed
in
because
you
can't
construct
one
to
pass
to
the
actual
run
command.
And
so
so.
This
is
circling
back
to
that
original
issue.
B
Yes,
we
can
do
this
and,
yes,
we
will
accept
PRS
on
this.
If
you
all
want
to
want
to
take
a
look
at
making
that
modification
to
the
logging
interface
I,
don't
see
any
problem
with
that.
Okay,
there
is
I
did
mention
if
you
go
back
and
look
at
the
the
comment
from
the
27th
I
do
want
to
make
sure
that
we're
not
exposing
our
internal
logging
code
but
we're
happy
to
make
the
actual
logging
interface
and
move
it.
B
E
B
C
Had
the
question
as
it
relates
to
our
dependency
update
policy,
I,
don't
know,
I
was
working
on
something
and
I
wanted
to
use.
Some
of
the
latest
features.
I
think
it
was
just
me
and
that's
that's
currently
three
point
five
and
we
are
still
on
two
point:
nine.
So
that
made
me
think
you
know
what
is
our
dependency
update
policy
Oh
from
the
update
and
it's
it's
probably
just
engineers
I
just
wanted
to
make
sure
that
you
know
I
would.
But
you
know
open-source
community
understands
that
maybe
provide
some
suggestions.
C
B
B
C
The
way
I've
seen
it's
happening,
usually
they're
kind
of
to
school
of
tilts.
Here
one
is
done
open
done,
bump
dependencies
so
frequently
just
treat
periodically
some
teams
even
do
it's
like
quarterly
or
monthly
whatever
and
there's
a
second
school
of
thought
that
says
well,
I
want
to
be
up
to
date
as
much
as
possible,
I
think
on
on
my
last
project.
We
even
had
step
in
pipeline.
C
That
was
the
tech
thing
that
some
of
the
dependencies
out
of
date,
so
that
gave
us
a
type
pipeline,
so
we
were
kind
of
forced
to
do
and
be
typically
kind
of.
Did
it
once
a
week
which
may
seem
a
little
risky,
but
in
actually
it's
not
that
much,
because
you
know
you
have
way
more
chances
to
test
things
earlier
and
pull
back
if
something
is
broken.
So,
but
you
know,
I
was
just
wondering
you
know
that
I
don't
want
to
hit
a
bump.
Something
did
out
having
brother
consensus.
B
Okay,
that's
fine
and
then
eventually
it'll
say
these
ten
are
out
of
date
and
it'll
be
like
okay,
so
like
I'm,
just
having
something
kind
of
in
our
face,
that's
not
intrusive,
but
something
that
is
there
that
we
can
own.
That
is
easy
to
refer
to
I
think
might
be
a
good
step
like
a
good
start
and
then
once
we
once
we've
tried
that
out.
B
We
can
then
look
at
look
at
like
gating
and
potentially
blocking
things
if
we
decide
that
we
want
to
be
more
like
on
the
update,
more
frequently
side
or
if
we
just
want
to
do
it
quarterly
side
or
whatever
like
but
I,
think
just
getting
something
in
there.
That
is
checking
was
a
good
first
step.
I
I.
F
F
D
I
also
throw
one
more
thing
into
the
ring,
so
I
think
in
particular
with
jasmine.
It's
a
dev
dependencies.
So
it's
a
lot
less
risk
than
something
that's
like
a
build
dependency
where
we
might
need
to
formalize
the
review
process
a
little
bit
more,
but
yeah
I.
Think
if
we
wanted
to
just
update
like
our
testing
framework,
it
should
be
fairly
low
in
back.
No,
it's
like
any
other
PR.