►
From YouTube: Octant Community Meeting - July 21th, 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
A
A
Yeah,
nothing
specific
for
the
status
section.
I
think
we
have
a
couple
demos
and
we're
going
to
be
talking
about
some
of
the
stuff
in
the
current
sprint,
so
kind
of
kind
of
rolled
into
the
rest
of
the.
A
I
mean,
I
think
it's
a
good
call
out.
I
think
that
the
the
we've
talked
about
this
before
in
past
meetings,
sin
and
something
that
I
think
it's
important
to
reiterate,
that
there
is
a
goal
to
have
three
clear
lanes
of
documentation:
user
documentation
on
octane.dev,
plugin,
author
documentation
on
reference.tab
and
then
core
octant
documentation
for
engineers
looking
to
extend
octant
in
the
github
repo.
A
So
those
are
the
three
kind
of
lanes
of
documentation,
and
I
just
want
to
make
sure
that
that,
when
we're
talking
about
these
things
that
the
the
work
that
that
that
we're
looking
at
aligns
with
the
work
that
you
are
wanting
to
have
done
david
and
like
the
work
that
we
need
to
do
so
I
I
don't
think
that
it
is
the.
I
don't
think
that
this
documentation
is
geared
for
the
user.
A
I
think
this,
the
the
stuff
that
the
luis
is
currently
working
on
is
geared
towards
the
engineer,
and
he
can
he
can
or
you
know,
speak
to
that,
but
I
think
I
think
that's
probably
that
might
be
the
confusion
point
with.
A
B
You
know
across
the
three
swim
lanes
and
all
of
that
my
concern
is
that
these
don't
necessarily
align
directly
with
the
you
know
our
new
way
of
releasing
and
that
we're
trying
to
stick
with
the
theme
of
object
status
for
this
particular
release,
and
so
within
those
goals
like
yes,
we
could
shoehorn
this
one
into
kubernetes,
updates,
subscription
and
documenting
that,
but
that's
also
still
kind
of
a
large
area,
and
so.
B
You
know
one
is
the
concern
that
the
questions
that
you'll
be
asking
to
the
maintainers
team
pulls
them
off
of
away
from
the
context
in
which
they're
trying
to
stay
for
this
release.
So
you
know
so
this
is
a
this
release
is
a
a
pilot
program.
B
Essentially
so
we're
you
know,
we're
doing
a
test
run,
and-
and
so
you
know
if,
if
someone
has
to
be
pulled
off
in
order
to
do
a
lot
of
work
around
architecture
discussions
around
this,
I
don't
know
how
much
that
impacts
their
velocity
and
and
that
I
guess
that's
one
of
my
concerns
and
and
also
just
how
detailed
this
documentation
is
going
to
be
and
how
useful
it's
going
to
be
and
whether
or
not
we
should
spend
some
time
kind
of
going
through
these
four
major
areas
and
whether
they
can
be
pared
down
a
little
bit,
that
the
scope
can
be
updated
to
something
that's
more
manageable.
A
Yeah,
I
also
want
to
say
I
I
think
that
you
have
an
excellent
point
david,
and
I
would
I
would
love
for
the
entire
team
to
at
one
point
set
a
theme
of
documentation.
A
Right
like
we
spend
as
a
team,
we
spend
a
full
two
week
period,
dedicated
to
improving
our
docs,
using
our
docs,
getting
with
end
users
and
sitting
there
while
they
use
our
docs
and
like
doing
all
of
the
things
that
that
need
to
be
doing
all
the
things
that
help
make
great
documentation,
and
so
I
want,
I
guess
what
I'm
trying
to
say
is.
A
I
think
the
continued
effort
that
you're
making
like
the
the
green
items
that
you
have,
that
you
can
kind
of
complete
on
your
own
love,
to
see
those
happening
and
also
you
are.
You
are
part
of
our
team.
You're
you're,
one
of
the
maintainers
documentation
is
a
core
piece
and
and
managing
community
is
a
core
piece
of
an
open
source
project
and
we're
so
happy
that
you're
here.
So
I
just
want
to
say
that
the
the
stuff-
that's
in
orange,
that
that
might
need
help
from
the
team.
A
We
have
a
documentation
project
in
github
and
if
there
is
not
create
one
and
if
there
is,
you
know,
feel
free
to
manage
and
organize
that
documentation
project
in
whatever
way,
helps
you
and
and
helps
you
organize
the
work
and
you
can
even
create
your
own
columns
in
there
of
like
needs,
needs
engineering
versus
like
I
can
do
myself
and
and
then,
when
we
go
to
you
know
when
we,
you
know,
with
the
current
theme
approach,
we're
taking.
A
If
the
team
ultimately
decides,
we
like
it
and
it
works
we'll,
regardless
of
if
it
does
work
or
not,
we
will
have
a
documentation,
theme
sprint
but
like
there
will
be
a
sprint
dedicated
to
that
so
and
and
we
can,
we
can
work
to
like
firm
up
a
date
too.
Instead
of
just
saying
like
we
will
do
it,
we
can.
A
B
A
Yeah-
and
I
would
say
for
me,
order
of
importance
is
as
as
users
than
plugin
authors
and
then
like
us,
as
the
engineering
team,
we're
last
we're
the
ones
who
who
have
to
deal
with
and
feel
the
pain
so
but
like
our
users
and
our
plugin
authors
should
not
so
so.
That's
also
how
I
would
prioritize
things
generally
around.
C
Yeah,
I
just
wanted
to
also
add
I
mean
kind
of
same
note.
I
think
it's.
This
is
really.
I
just
wanted
to
stress
the
importance
of
this,
because
in
a
lot
of
things
I
mean
we
know
that
a
lot
of
people
don't
care,
but
there's
on
the
other
side,
bunch
of
people
that
do
care
about
documentation,
and
I,
in
a
lot
of
a
lot
of
times.
This
is
like
making
a
break
it
for
for
the
option.
C
For
example,
this
morning
I
was
playing
with
a
go
library
and
documentation
is
terrible
and
I'm
like
do
I
really
need
to
use
this.
This
is
so
hard,
so
you
know,
I
think
we
have
a
lot
of
things
here
and
there
and
just
to
to
merge
them
together,
organize
it
better
and
make
it
more
targeted
towards
all
the
special
kinds
of
users
that
would
be.
D
D
Hello
soundcheck
all
right
sounds
good
okay,
so
I
wrote
this
as
an
intro
simply
because
this
is
a
feature
that,
even
though,
despite
being
on
a
major
team,
I
haven't
really
had
to
think
about
it
until
the
last
couple
of
weeks
and
then
even
further
back.
It's
been
broken
for
probably
at
least
six
months
now,
and
so
this
has
been
undiscovered.
So
it's
a
little
bit
digging
and
turns
out.
We
did
document
this
at
some
point.
D
So
the
interesting
piece
here
is
more
of
just
reinstating
this
and
just
doing
a
quick
intro,
so
it's
more
transparent
on
what
I'm
even
talking
about
in
the
first
place.
So
I
will
share
a
screen.
If
you
don't
mind
david.
D
All
right
here
we
go
so
this
is
our
reference.
Dot
octane.dev
and
this
is
under
plugins,
go
plugins
and
where
we
document
this
piece
of
our
public
api,
that
is
known
as
an
object,
status
response,
and
it
here
it
says
it
maps
to
currently
masterpod
summary
and
contains
a
list
of
details,
node
status,
and
this
is
old
actually
because
it's
been
further
expanded
and
changed
around
a
little
bit
and
in
fact
this
doesn't
exist
anymore.
So
this
is
to
david's
point.
D
We
need
to
not
only
write
new
documentation,
but
our
existing
documentation
is
already
outdated,
but
what
this
is
really
saying
in
a
more
high
level
and
the
easiest
way
to
talk
about
this
is
just
to
show
what
octane
is
doing,
and
this
has
changed
a
little
bit
since
the
code
was
originally
written.
But
if
we
look
at
this
object
status
response,
we
can
see
it
consists
of
mainly
three
things.
D
This
status,
something
called
details,
we're
just
a
bunch
of
sub-components
and
this
thing
also
known
as
a
property
which
we
can
talk
about
in
a
second.
But
it's
just
really
key.
D
There
key
pair
values
of
components,
and
so
often
has
this
thing-
called
an
object
status
and
it's
really
just
whether
something
shows
up
as
green,
yellow
or
red,
depending
on
the
state
of
the
object,
and
we
use
the
status
multiple
places,
notably
in
this
resource
viewer,
but
also,
if
we
just
look
it
up
in
general,
we
have
these
check
marks
on
our
tables
that
have
the
green
color
and
it
also
shows
certain
things.
Well,
normally,
I
would
show
the
change,
but
I
broke
the
build.
D
I
did
the
carnosine
of
changing
your
code
right
before
a
demo.
That
being
said,
it's
not
too
difficult
to
show
what's
going
on
here,
so
the
note
status,
if
you
have
a
plugin
you
could
have.
You
could
say
this
is
say,
for
example,
node
status.
Okay,
all
of
these
are
currently
in
the
state
of
node
status.
Okay
and
that's
internally,
determined
by
octan,
but
one
could,
in
a
plug-in,
make
a
given
pod
red.
D
For
reasons
right,
you
could
say
like
I'm
waiting
for
this
pod,
that
represents
a
database
to
start
up
first
or
I
want
to
make
sure
if,
for
example,
maybe
if
someone
didn't
apply
their
liveliness
probes
and
they
want
to
still
have
a
plugin
to
check
this,
they
would
be
able
to
do
that.
So
that
is
how
we
can
have
a
plug-in
theoretically
change
this
color
on
a
resource
viewer
or
on
a
table.
D
Now
we
also
have
the
other
two
pieces
which
are
details
and
properties,
and
these
are
a
little
bit
more
interesting.
The
properties
tab
is
something
that
can
be
shown
more
in
the
resource
viewer.
I
have
an
example.
That's
pulled
up
already,
and
I
also
have
some
json
pulled
up
to
show
what's
going
on
here.
D
Where
is
the
example
here
yep?
So
we
have
our
pod
and
we've
got
some
properties,
so
I
don't
know
if
this
is
very
visible
on
the
screen
here,
but
here
we
can
see.
We
have
six
properties
under
this
cert
manager,
pod
and
the
easiest
way
to
think
about
properties
is
just
a
key
pair
value.
So
this
is
a
key.
This
is
a
namespace
key
and
it
says
it's:
this
is
a
cert
manager.
D
This
is
created
key
and
this
is
created
28
days
ago,
and
then
this
is
a
link
component
and
what
we've
added
from
the
plugin
is
saying.
Oh,
this
is
the
id,
so
this
piece
of
information
comes
from
a
plug-in
and
not
often
and
here's
some
plug-in
specific
information,
and
so
one
could
arbitrarily
keep
adding
new
things
here
through
a
plug-in,
and
we
also
have
another
piece
in
details
clicking
up
here.
That
says:
oh
v1,
service
account
is
okay
and
we
can
see
here.
D
Something
like
pod
is
okay,
but
you
could
also
continue
to
extend
this
piece
going
back
to
this
details.
It's
it's
a
it's
essentially
an
array
of
components,
so
you
could
add
any
number
of
arbitrary
things
and
it
would
just
keep
piling
up
in
this
box
here
saying
it's:
okay
or
maybe
you
want
to
add
a
note
or
saying
like.
Oh
this,
you
know
remember
to
delete
this
or
hello
world,
or
you
can
say
hi
to
your
friends
and
so
on
and
so
forth.
D
So
this
shows
up
on
this
part
of
the
resource
viewer,
and
it
also
shows
up
in
theory,
on
these
check
boxes
when
you
click
on
them,
so
these
could
technically
grow
arbitrarily
large.
So
this
might
be
something
we
want
to
think
about
from
a
ux
perspective,
but
that's
really
it
about
this
object
status.
We
want
to
just
make
sure
this
feature
comes
back
and
make
sure
that
it's
transparent
on
how
to
use
it
and
when
one
would
use
it.
So
that's
about
it.
D
No
no
color
changes
today,
but
I
think
it's
fairly
straightforward
to
talk
about
really.
The
code
here
is
to
figure
out
how
to
reconcile
some
of
the
code.
Changes
and
we've
just
changed
a
lot
of
this
over
the
over
time,
and
I
believe
when
this
was
originally
written,
we
didn't
have
these
object
status
indicators
on
tables.
D
So
really
it's
just
about
saying:
let's
have
a
single
source
of
true
for
what
is
the
status
within
our
within
octane's
internals
and
making
sure
that
they're
being
overridden
in
a
sensible
way.
D
Okay,
so
state
so
state
could
mean
a
lot
of
different
things,
but
currently
right
now,
these
statuses
are
a
result
of
the
phase,
and
the
state
could
really
just
mean
anything
right.
So
this
is
what
this
is.
What
the
point
of
this
object
response
is
right.
You
could
write
arbitrary
code
to
change
this
to
say
instead
of
having
this
color
being
dependent
on
phase
now,
it's
anything
you
want
it
to
be
make
sense.
Thank.
E
B
My
question
is
just
around
when
you
hovered
over
pods,
the
tooltip
that
popped
up
was
blank
for
the
status
and
I
did
a
quick
search
on
the
issues
and
didn't
see
it,
but
I
could
just
be
searching
on
the
wrong
keywords.
Does
anyone
know
if
we
have
an
open
issue
for
that.
D
No
but
it'll
get
wrapped
over
pretty
much
as
I
go
through
this
already.
I
I've
this
is
fixed
on
the
dev,
build
I'm
using
the
latest
octane.
C
Yeah,
thank
you
sam.
I
think
that's
great
overview
and
I
think
one
good
point
that
you
made
and
I
kind
of
want
to
expand
on
it
is
we
have
those
components
around
in
different
places.
Like
you
mentioned
the
status
we
use
it
if
both
resources
are
in
tables,
but
I
think
we
need
to
think
a
little
more
atomic
way
of
using
them.
So
so
they
can
be
used
in
multiple
places,
for
example
like
properties
table.
C
This
is
currently
in
a
resource
you're
the
only
place
we
use
them,
but
there's
no
reason
we
shouldn't
be
able
to
use
that
some
other
pages
as
well.
So
we
we
need
to
think
a
little
more
about
how
we
display
properties
in
different
places,
not
sorry,
not
properties
that
the
whole
status
thing
in
different
places
make
sure
it's
uniform
make
sure
it's.
C
You
know
we
showed
the
same
this
information
in
in
a
in
current
context
and
then
in
the
same
way.
So
so
maybe
we
need
to
do
a
little
more
work
about
so
for
properties
table.
I
don't
think
that's
a
component
now.
I
don't
think
you
know
when
I
created
others.
It's
just
a
table,
I'm
adding
there,
but
it
may
be.
It
may
need
to
be
extracted
and
reused
in
some
other
places.
D
Yeah,
I
agree
that
definitely
we
don't
want
these
to
be
just
a
standalone
table
that
just
lives
off
here.
I
don't
know
where
else
would
go
off
the
top
of
my
head,
but
if
you
have
thoughts
on
it,
give
me
ping
and
we
can
talk
about
it.
A
Yeah,
let
me
pull
that
up
and.
A
Well,
maybe
I'll.
Oh
I'm
picking
one
yeah
okay,
so
this
is
this.
Is
this
demo
is
a
little
well
like
everything
kind
of
looks
the
same,
but
there's.
A
Neat
stuff
happening
here,
so
this
conditions
table
that's
being
rendered
on
the
screen
here
is
no
longer
type
specific
and
it's
only
rendered
if
conditions
are
present
for
the
object.
Following
kind
of
the
similar
pattern
of
events
where,
if
events
are
enabled
and
they're
present
or
sorry.
A
Then
we'll
render
a
table
for
them.
This
is
a
similar
idea.
If
can,
if
an
object
has
a
conditions
field,
whether
or
not
they're
empty
doesn't
matter.
If
it
has
that
status
conditions
field,
then
we
will
render
this
table
and
in
particular,
this
table
is
now
rendered
using
an
unstructured
object.
So
it's
not
typed.
What
this
means
is
that
this
this
create
conditions
view
which
produces
the
table
can
now
be
used
with
any
object.
A
Field
we
have
to
jump
through
a
few
bit
of
extra
hoops
here,
I'm
also
using
some
of
the
like.
You
can
see
on
my
my
time
stamp
right,
I'm
still
using
a
text
field,
even
though
we
have
a
time
stamp
field,
but
this
is
all
live
running
on
the
on
against
the
api,
so
it
parses.
A
A
A
The
key
actually
existed
before
we
attempt
to
try
and
access
that
data,
but
yeah
this
so
so,
there's
two
open
issues.
The
one
that
I'm
currently
working
on
is
adding
the
the
changing
the
the
conditions
table
and
adding
it
to
something.
I
don't
remember
what,
anyway,
what
is
that
I'm
trying
to
find
the
issue
anyway?
A
The
the
issue
is,
I
am
making
it
so
that
this
table
is
flexible,
similar
to
events
and
then
there's
a
follow-up
issue
for
this,
which
will
now
be
able
to
start
to
render
render
conditions
for
any
object
easily
now
because
it
takes
an
unstructured
type.
So
we
convert
our
type
in
the
case.
C
A
Be
present
on
crd.
A
Summaries
are
pretty:
oh,
let's
see
they're
they're
they're,
pretty
not
great
there.
You
can
see,
there's
not
much
happening
there,
so
this
will
now
have
a
conditions
table
which
will
be
useful
yeah
anyway.
That's
that's
the
full
thing.
That's
it.
A
A
Obviously
it's
only
for
for
one,
but
events
is
another
example
of
that,
and
I
think
it's
just
something
to
keep
in
mind
as
we
start
to
do
more
of
these
there'll
be
a
there'll
kind
of
be
a
a
natural
tipping
point
where
the
investment
is
better
to
just
go
ahead
and
and
do
it
across
the
system
than
it
is
to
keep
doing
them
individually.
F
Thank
you.
Thank
you,
so
much
cool
okay.
Now
last
one
was
an
open
question
in
this
issue:
2666
she's!
Basically,
here
you
know
clarification
on
the
version
support
kubernetes
version
support
on
octant.
F
D
Yeah,
it's
I
I
feel
like
it's
self-explanatory.
I
think
so
I'll
say
what
I
think
he
thinks
and
what
I
think
that
our
documentation
says
and
then
we
can
decide
if
it's
clear
now
so
often
is
using
the
last
three
versions
from
the
version
from
the
version
of
the
kubernetes
client
it
uses
so
currently
uses
1.19.
C
D
Now
I
think,
he's
saying:
octane
should
be
covering
the
last
three
versions
based
on
the
current
version
of
client
go
that's
released,
which
would
imply
that
we
are
much
more
than
three
versions
behind,
and
so
really
the
question
is
at
its
core
is:
when
do
we
bump
our
kubernetes
client
and
historically,
we
don't
really
have
a.
We
don't
really
have
any
strong
governance
around
that.
I
think
we've
done
it
just
based
on
if
we
needed
something
from
the
upstream
resolved.
C
D
D
That
said
as
well,
I
do
want
to
see
our
next
bump
to
be
somewhere
around
one
two
two,
because
that
just
makes
all
of
the
deprecated
kubernetes
objects
go
away,
and
we
would
never
talk
about
them
again
and
close
like
ten
issues
so,
but
that
also
has
further
discussions
around
like
the
like
the
ecosystem
in
general,
because
pretty
much
everyone
on
twitter
is
saying
things.
People
are
totally
gonna
break
as
soon
as
they
upgrade,
because
who
reads
passionates
right,
so
yeah,
that's
kind
of
where
we're
at.
A
Yeah,
I
think
I
think,
yeah
the
points
that
sam
made
here
are
great
reading
this.
I
think
the
fact
that.
A
Of
of
the
kubernetes
client
versions
makes
it
a
little
confusing
right
like
like
it.
It
shouldn't
it
the
the
version
of
of
octant.
Maybe
we
want
to
start
to
publish
what
kubernetes
client
a
version
of
octant
has
been
built
with,
so
that
it
is
easy
or
even
published
in
the
release.
Notes
that
this
version
of
octant
is
is
considered
to
be
compatible
with,
and
then
it's
the
client
goal
we
built
with
minus
one
plus
one.
A
So
I
think
I
think,
maybe
maybe
that's
what's
causing
the
confusion
here,
the
the
quick
because
and
I'm
I'm
inferring-
that
from
the
should
there
be
three
active
octant
release
branches,
which
is.
Is
that
to
me
shows
that
there's
some
confusion
about
what
we
mean
when
we
say
we
follow
and
plus
minus
one
policy.
The
interesting
piece
of
this
is
that
this
language
was
like
cargo
culted
directly
from
the
kubernetes
website.
We
just
changed
some
of
the
words
to
say
octant
instead,
so
it
was
like
using
their
language
but
yeah.
A
We
can
add
a
little
bit
of
to
our
tooling
that.
A
A
go
looking,
you
know,
you
know,
grip
the
rgomod
file
and
determine
what
the
client
go
version.
Is
that
we're
using
so
that
we
can
automatically
inject
that
into
the
release
notes.
So
if
someone
doesn't
have
to
manually,
do
it
or
something?
That's
that's
my
idea.
As
for
when
should
we
bump
that's
a
different
question,
so
I'll.
A
To
add
anything
about
our
support
matrix
for
client
go
and
kubernetes
clusters,
and
then
I'd
like
to
talk
about
when
we
should
upgrade.
C
I
think
it
might
be
interesting
to
to
increase
this
ability
of
this,
maybe
even
add
it
to
I
don't
know
about.
Let
me
show
the
octave
version.
Maybe
you
can
see
you
know,
built
it
client
version
x
and
support
kubernetes
versions.
C
A
Actually
yeah,
that's
not
a
bad
idea
and
having
that
as
part
of
the
because
then
it
would
be.
You
know
one
of
the
things
we
ask
for
when
someone
creates
an
issue,
is
the
version
of
kubernetes
they're
running
if
we
can
make
a
nice
little
snippet,
like
click
here,
to
create
an
issue
in
octant
that
automatically
populates
the
version
of
octant
and
the
and
the
client
it
was
built
with?
And
yes,
maybe
even
the
like.
If
we
can,
this
is
long
reaching
but
like
maybe
even
no.
A
A
But
our
kubernetes
client
and
the
client
go
it
was
built
with
and
then
when
they
add
the
version
of
kubernetes
they're
running,
we
can
instantly
see
like
oh,
hey,
you're
upgrading,
like
not
a
bug.
F
A
User
and
then
for
the
other
question
of
that,
sam
brought
up,
which
is
like
how,
when
do
we
upgrade?
I
I
think
that,
like
we're,
definitely
behind
right
now.
What
what
my
plan
to
make
this
policy
easy
for
us
to
adhere
to
was
to
be
essentially
minus
one
from
the
current
kubernetes
release,
because
their
their
support
structure
for
client
go
is
the
same
as
that.
So
if
we
were
on
121,
then
we
know
octant
is
going
to
technically
work
with
120,
121
and
122..
A
That
said,
the
122
update
is
is
is
likely
going
to
to
like
I'm
almost
I'm
almost
wanting
to
just
go
ahead
and
move
octet
to
122
and
see
what
kind
of
errors
and
things
fall
out
of
it
and
then
potentially
see
if
we
can
make
it
useful
for
folks
who
are
going
to
be
upgrading
to
122,
because
there
are
some
convenience
features
of
like
there's
like
some
some
things
you
can
do
to
auto
migrate,
some
of
the
resources
and
and
submit
update
the
resource
versions.
A
So
we
might
be
able
to
include
some
remediation
for
people
who
update
their
version
and
haven't
updated
their
resources.
If
we
were
running
on.
D
A
A
I
am
on
board,
with
with
moving
to
122,
for
the
next
release.
A
Yes,
and
and
not
for
this
one
that
we're
going
to
cut
now,
though,
what
are
we
on
now?
That's
that's
a
better
question,
because,
if
we're
still
on,
if
we're
not
at
least
on
120
we're
going
to
have
to
update
anyway,
does
anyone
know
off
top
of
their
head.
A
A
Okay,
yeah
so
we're
behind
yeah,
okay,.
F
A
So,
for
I
think
for
the
for
yeah,
I
think,
for
this
release.
Moving
to
120
121
is
a
minimum
we
can.
We
can
handle
that.
I
guess
we
can
have
a
discussion
about
moving
to
122.
F
An
an
upgrade
on
a
coordinated
version,
but
yeah
probably
we
will
need
to
discuss
that
and
that's
that's
interesting.
Thank
you.
So
much.
Okay,
any
other
items
topics
someone
would
like
to
discuss.