►
From YouTube: Octant Community Meeting - May 19th, 2021
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
And
we're
live
all
right,
so
let's
get
this
screen
share
started.
Shall
we
all
right
hello?
Everyone
welcome
to
the
may
19th,
often
community
meeting.
We
are
already
almost
halfway
through
the
year
of
2021..
So
that's
exciting.
We've
got
a
few
things
on
the
agenda
today
and
then
we
can
do
q
a
as
usual.
A
So
I
think
what
we
can
do
is
just
jump
right
into
it.
Since
it
looks
like
we
have
a
pretty
light
agenda
today,
anyways.
So
the
first
thing
here
is
going
to
be
about
managed
fields.
Manage
fields
is
a
concept.
That's
been
added
into
kubernetes.
I
think
it's
118.
I
don't
have
that.
I
don't
remember
the
numbers,
but
the
most,
notably
if
you've
used
recent
kubernetes
versions.
A
Is
that
if
you
do
something
like
you
can
even
just
show
people
here,
let's,
let's
actually
open
a
new
terminal,
but
if
you
do
something
like
get
output
dml,
I
think
I'm
using
the
latest
client,
but
if
you
were
using
an
older
client,
that's
not
one.
Two
one
you'd
see
all
this
stuff
here.
All
these
like
managed
fields
and
you'd,
see
this
blurb
of
information
that
crowds
your
console
and
it's
useful
information,
but
essentially
they've
added
a
flag
to
me.
It's
now
going
away
by
default.
A
So
if
I
don't
use
this
show
manage
field
flag,
it
does
not
appear
so
now.
The
default
behavior
is
reverting
back
to
no
no
managed
fields,
and
this
starts
at
one
two
one.
So
this
is
a
very
recent
added
added
flag.
I
believe,
and
then
we
decided
that
octant
itself
should
follow
suit.
A
So
now,
if
you
go
into
our
yaml
editor,
it
no
longer
shows
the
managed
fields
and
instead
they're
moved
to
metadata,
and
now
you
have
cards
and
a
json
viewer
that
lets
you
expand
and
collapse
them
as
needed,
and
so
the
interesting
thing
here
is,
if
you're
wondering
what
managed
fields
do
they
are
essentially
kind
of
record
keeping
for,
like
the
last
thing
that
that
has
been
changed
by
given
object.
So,
for
example,
if
we
wanted
to
update
our
deployment
to
three
replicas
instead
of
two,
we
should
notice
yep
here.
A
The
cube
controller
manager
updated
this
five
seconds
ago,
and
it's
saying
it's
updated.
Our
metadata
and
our
status
fields
right
in
this
particular
case,
it's
probably
the
replica
field
that
was
updated,
but
of
course
it
also
updates
the
other
fields,
such
as
available
replicas
conditions
and
so
forth,
because
that
those
are
the
other
fields
that
are
involved
as
part
of
updating
a
replica.
So
that's
manage
fields
in
a
nutshell,
and
hopefully
we'll
make
our
gamble
editor
a
little
nicer
to
use
so
any
questions
about
that
or
managed
fields.
A
If
you
want
to
read
more
about
this
stuff,
I
think
I
linked
some
a
youtube
video
which
I
feel
describes
it
very
well
in
the
issue
and
then
there's
also
the
documentation
on
the
kubernetes
website
for
server
side
apply,
which
goes
into
more
detail
about
what
these
manage
fields
were
supposed
to
do
and
why
they
were
added
in
kubernetes
in
the
first
place,.
B
A
A
A
D
C
A
Glad
to
have
you
on
board
this
is
super
cool
and
for
those
who
are
tired
of
seeing
my
ugly
mug
week
after
week,
you
will
now
get
to
see
a
dedicated
community
manager
who
can
help
run.
This
show
for
often
and
just
generally
have
someone
to
handle
some
of
the
outside
engagements
as
well.
A
I
think
some
we
get
a
ton
of
queries
and
some
are
engineering
related
and
some
are
not,
and
so
it'd
be
nice
to
figure
out
what
are
the
some
of
the
non-engineering
side
of
things
that
octa
can
do
better.
A
Cool
right
well
and
let's
jump
on
to
the
last
item
on
the
agenda.
We've
got
a
demo
resource
viewer.
That
means
we're
talking
milan
here,
showing
object
properties,
so
I
will
hand
it
over.
A
C
Here
they
are
for
that
deployment
object.
For
example,
you
can
see
there
is
a
little
table
on
the
right
right
before
the
light
below
the
the
status
pane,
and
there
are
three
levels
of
those.
The
first
one
is
properties
that
are
displayed
for
every
single
object
and
those
in
this
case
top
four.
C
C
As
a
second
level,
each
resource
has
a
chance
to
add
its
own
properties,
so
deployment
is
adding
a
couple
of
those
and
then
third
level
that
you
don't
see
here
is
going
to
be
the
plugin,
updated
property
fields
for
each
object.
So
so,
depending
what
is
selected,
you
can
have
different
views
so,
for
example,
for
replica
set.
C
C
C
You
know
the
the
major
one
is:
what
is
the
most
useful
information
we
should
display
here,
and
I
try
to
choose
things
I
I
think
are
most
important,
but
you
know
I'm
definitely
open
for
discussion.
The
main
thing
I
don't.
I
think
this
should
be
a
place
to
display
the
few
most
important
properties
for
each
object,
especially
the
ones
helping
with
the
troubleshooting
and
diagnostics,
because
a
resource
viewer
is
is
very
important
in
that
you
know.
C
So
I'll
leave
it
to
that
and
if
you
guys
have
any
feedback
and
any
suggestions
what's
the
best
way
to
proceed,
this
is
pretty
close
to
be
ready.
So.
A
C
From
from
summary,
so
like
maybe
this
stuff,
I
think
we
still
need
to
display
information
in
multiple
places,
because
you
know
it's
all
about
context
and
the
when
you
are
in
the
resource
bureau
you,
your
context
is
like
you
know
this
whole
apology
of
your
of
your
deployment.
So
you
know
I
I
still
think,
especially
because,
for
example,
you
are
here
visiting
deployment,
but
you
may
not
be
seeing
deployment
at
the
moment,
and
this
is
going
to
change,
especially
here,
let's
say
in
applications
view
and
looking
at
something
like
this.
C
C
C
So
I'm
thinking
just
to
do
first.
Pr
with
this
make
sure
the
the
plugin
is
plugins
are
supported.
Plugins
connect
their
own
intro
here
and
then
do
that
as
initial.
A
A
Yeah
this
looks
awesome.
It
certainly
makes
the
resource
viewer
a
lot
more
useful.
That's
when
we're
stepping
through
each
node.
C
Right
and
I
think
it's
it's-
it's
really
important
now
you
know
I
made
a
recently.
I
made
a
change.
C
I
made
a
change
that
the
initial
selection
is
set
correctly,
so
I
think
that's
even
more
important
now,
because
you
know
when
you
open
that
view
it
just
it
just
hits
you
right
there.
So
you
know,
in
this
case
deployment
is
selected
and
immediately
after
you
hit
the
resource
view
or
the
the
properties
for
that
object.
A
B
Long
time
ago
there
was
an
issue
open
for
octant
to
make
the
resource
viewer
the
default
view,
which
I
think
is
eventually
what
we're
going
to
be
trying
to
do
with
the
applications
view,
and
this
having
these
details
present
when
you
load
into
the
resource
viewer,
I
think,
is,
is
part
of
that
path
like
without
that
it
wouldn't
be
very
useful.
So
with
that,
like
this
makes
a
lot
of
sense
instantly,
I
can
I
can
go
in
and
I
can
actually
click
through
those
things
and
see
the
details,
which
is
pretty
nice
great.
B
C
Yes,
yes,
plugins
can
add
items
to
the
bottom.
I'm
sorry!
I
don't
have
an
example
of
that.
No,
it's
making
sure
yeah
yeah
and
this
table
the
way
this
is
structured.
It's
it's
basically
description
and
then
the
component
that
shows
the
values.
So,
as
you
can
see,
that
can
be
either
I
mean
in
this
case
I'm
using
text.
Labels
can
be
linked
or
any
other
component.
C
B
And
then
can
you
click
on
pod?
One
more
time
sure
do
we
want
to
think
about
moving
the
lit
the
the.
B
C
So
in
general,
the
top
card
is
showing
the
stylus
and
the
bottom
one,
the
properties,
okay
so
and
puts
I
mentioned
that
pods
are
very
specific,
because
in
this
case
you
know
this
is
not
a
single
part.
This
is
like
a
port
group,
and
so
so
my
idea
was:
let's
solve
this
by
showing
properties
that
are
common
for
parts.
Basically,.
B
B
Comments
concerns
I
I
have
one
we
can
add
just
quickly
milan
and
I
started
talking
about
an
issue
already.
I
actually
like
milan's
feedback
on
it.
I
think
I
think
he's
got
a
good
like
the
direction
he's
going
is
right.
It's
the
auto-generating
of
breadcrumbs.
I
think
the
essence.
B
Is
milan
brought
to
the
point
that
we
don't
want
to
mix
history
and
hierarchical
navigation,
which
I
think
is
is
very
true.
We
don't
want
to
be
doing
that,
so
the
title
of
this
issue
will
probably
change,
but
what
we
want
to
be
able
to
do
is
provide
the
user
with
a
very
quick
and
easy
way
of
getting.
You
know
n
number
of
steps
back
to
some
place.
They
were
that
isn't
necessarily
part
of
the
hierarchy
that
they're
viewing.
B
So
you
know
the
the
scenario
that
I
outlined
was
like
you're
looking
at
deployments,
so
you
click
deployment
and
then
you
click
on
a
pod
and
then,
when
you're,
looking
at
the
pod,
there's
a
plug-in
that
has
a
link,
that's
generated
to
go
view
some
specific
detail,
then
you
click
that
link
and
so
now
you're
on
this
plugin
page.
B
Well,
now
I
want
to
get
back
to
the
deployment
right,
and
so
now
I
have
to
either
page
back
through
my
history
of
all
my
clicks
or
I
or
the
plugin
author
has
to
hard
code
that
the
hierarchy
to
be
able
to
take
me
there
easily
or
or
embed
some.
You
know
one
of
the
drop
down
options
into
our
into
our
our
navigation
list,
which
puts,
I
think,
puts
a
an
onus
on
the
plugin
authors,
that's
kind
of
unreasonable
and
makes
it
hard
for
users
to
get
back
to.
B
You
know
that
deployment
that
they
care
about
because
they
found
the
info
they
wanted.
So
the
idea
was
like,
oh
well,
we
could
auto
generate
the
bread
crumbs,
but
I
think
milan's
on
to
something
where
the
breadcrumbs
are
stay
defined
as
they
are.
But
we
provide
some
mechanism
to
some
intuitive
mechanism
that
allows
users
to
easily
navigate
through
their
history,
whether
that
history
was
some
resource.
They
were
viewing
in
one
of
the
octant
modules
or
some
resource.
They
were
viewing
in
a
plug-in
module.
C
It
already
has
a
back
and
forward
buttons,
but
I
don't
think
it
has
a
list
of
items
and
the
only
thing
we
that
we
need
to
do
and
to
to
support
both
of
those
protein
browser
and
electron
is
to
put
a
little
more
meaningful
titles
to
our
pages,
because
currently
all
of
them
are
obtained.
So
if
you,
if
you
press
and
hold
back
button,
for
example
in
octant
you'll,
just
see
tons
of
octane
entries.
B
Okay,
yeah,
that's
just
something
to
we've,
had
some
requests
for
this
and
I
think
it
makes
a
lot
of
sense
like
when
you,
especially
when
you
start
to
get
into
like
a
really
plug-in
heavy
environment,
where
you
might
be
clicking
from
one
plug-in
into
a
link
to
another
plug-in
and
into
a
into
a
link
of
an
octant
module
and
then
you're
like
I
want
to
go
back
to
I
want.
B
I
just
want
to
go
back
three
steps
and
I
don't
have
to
click
the
back
button
three
times
because,
like
yeah,
I
totally
understand
wanting
to
be
able
to
jump
around
quickly
and
yeah.
We
do
have
the
quick
switcher,
which
I
think
enables
some
of
that,
but
also
that's
it's
more
of
a.
I
would
say
it's
more
of
a
power
user
feature
and
and
probably
need
to
provide
some
nice,
some
nice
mechanism
to
do
that
through
the
ui.
C
Yeah
and
the
cool
thing
about
this
is:
it
adds
a
totally
different
dimension
in
navigation
right.
It's
it's
like
a
time
dimension.
You
can
go
back
and
forth
and
especially
if
you
are
working
with
a
lot
of
similar
objects,
it's
it's
really
useful.
Some
I
mean
I
use
that
button
quite
a
bit
in
in
when
I'm
working
in
octant,
and
even
now,
when
you
don't
see
where
you're
going
back,
it's
it's
still
useful,
but
it
would
be
even
more
if
before
paging,
some
other
script.
B
B
I
don't,
I
don't
think
I've
ever.
I
can't
remember
the
last
time
I've
clicked
I
just
open
a
new
tab
and
use
the
bar,
as
my
like.
Even
if
I
want
to
go
back
to
the
previous
page,
I
was
on,
I
literally
open
a
new
tab
and
type
in
the
url
of
the
previous
page,
like
I
don't
because
it
like
auto
it
fuzzy
finds
and
matches
now
and
stuff
so
yeah,
but
I
do
understand
why
people
would
desire
such
a
thing.
B
A
Yes,
I
think
slack
already
has
this
right
like
we,
we
really
just
like
fix
their
back
and
forth
buttons,
they're
we're
basically
building
that
there's
that,
like
a
clogged
icon,
yeah.
C
B
Yeah,
I
mean
I'll
be
honest.
I
didn't
realize
you
could
click
that
clock
until
the
first
time
we
talked
about
this
when
we
originally
talked
about.
We
can
have
a
custom
header
like
slack
and
then
someone's
like
yeah
and
there's
a
history,
and
I
was
like
other
there's
a
history,
so
maybe
a
little
more.
A
Cool
any
other
questions
comments.
We
linked
the
issue
here
on
the
agenda.
So
if
anyone
has
thoughts
about
this
after
the
call
take
a
look
at
2,
4
17.
A
All
right
cool
any
other
questions.
A
Nope
all
right!
Well,
if
not
thank
you
everyone
and
have
a
great
rest
of
the
day.