►
From YouTube: Octant Community Meeting - November 4th, 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
november
4th
community
meeting.
I
actually
could
someone
else
share
the
the
agenda.
I
don't
have
my
normal
machine
that
shares.
It
is
giving
me
some
issues.
A
Can
zoom
in
one
more
perfect?
Thank
you
yeah,
so
this
we're
gonna
be
talking
about,
maybe
cutting
an
o17
instead
of
a
like
a
16,
we
are
gonna.
Do
a
little
update
on
the
user
survey
looks
like
we'll
talk
about
some
structured
log
stuff.
Sam
has
been
exploring.
This
go
leak
package
that
we
want
to
talk
about
a
bit
and
then
I'm
gonna
talk
about
this
access
review,
screenshot
that
I
put
in
there
something
I'm
exploring
with
a
change
that
I'm
making.
A
So
with
that,
we'll
start
with
the
first
item,
so
I
believe
sam
wrote
this
basically
should
we
cut
an
o17
instead
of
doing
a
16
bug,
fixed
release
or
a
bug,
enhancement,
release
and
just
say
that
electron
is
going
to
be
0.18,
I'm
open
to
the
idea.
I
I
don't
think
that
the
yes
master
has
a
lot
of
breaking
changes
in
it.
I
agree
with
that,
but
I
also
the
o
dot
16.2
label
that
we
created
and
gave
to
specific
issues.
A
All
those
issues
are
very
easy
to
back
port
into
our
o16
branch.
So
there
is
the
overhead
of
back
porting,
but
there
is
the
like
me.
The
problem
is,
is
like
oh
17
right
now,
as
is
is
not
ready
and
it
won't
be
for
a
while
we've
we
we
made
some.
We
introduced
some
known
debt
around
the
fact
that
we
were
going
to
assume
that
we
would.
The
next
release
would
be
an
electron,
and
so
we
would
have
to
either
revisit
some
of
that
work
and
make
adjustments
accordingly
or
yeah.
A
I
I
don't
think
things
would
work
very
well
right
now
off
master.
I
think
that
is
my
biggest
concern
with
doing
that.
C
Yeah,
I
I
I
agree
with
you
100,
I
kind
of
feel
we
should
stick
to
the
original
plan
and
the
changes
in
master
are
probably
a
little
unstable
at
this
point
and
also
you
know
doing
the
the
release
with
the
bra,
with
the
tag
just
focused
release
only
on
a
few
things
that
we
that
we
feel
are
like
a
point
really
is
not
not
a
major
release.
D
D
But
besides
that
one,
I
think
it's
really
just
if
there
is
anyone
who
is
waiting
for
something
that
is
currently
in
master
and
that
we
don't
have
it
tagged
on
16-2
I'd
like
to
see
that
call
it
out.
Sooner
than
later,.
A
Yeah
that
yeah
okay-
I
agree
with
that.
So
we
can
we'll
surface
that
in
the
in
the
slack
channel
as
well,
and
maybe
I'll
I'll
put
a
tweet
out
that
says,
like
hey
here's,
some
here's
a
list
of
go
through
our
our
unreleased
change,
logs
and
or
open
issues,
and
let
us
know
if
there's
anything
because
we're
going
to
cut
the
release
soon
and
I-
and
I
agree
with
you
on
the
forum
thing,
but
currently
right
now,
that
stepper
form
and
and
the
way
you
embed
forms
is-
is
just
broken.
A
So
the
fact
that
we're
changing
the
api
in
a
in
a
whatever
you
would
call
it
in
that
release
is
okay
to
me,
because
it's
not
usable
anyway.
So.
B
A
Okay,
so
we've
got
so
yeah.
I
guess
for
that.
The
item
will
just
be
to
make
sure
we
we
get
some
information
out
there
about
the
the
upcoming
bug,
fix,
release
and
make
sure
we
just
solicit
people
to
say
hey.
We
want
this
or
whatever.
E
Yeah
so
at
the
responses
have
stopped
trickling
in.
I
think
we
have
about
11
responses
so
far,
and
I
think
it's
like
a
good
point
for
us
to
like
stop
and
consolidate
and
reflect
on
like
what
we've
learned
or
any
insights,
and
so
hopefully,
by
like
next
week
end
of
next
week,
we'll
do
a
share
out
whether
it's
through
the
community
meeting
or
like
a
slide
deck
or
something
like
that,
but
expect
to
see
some
results
from
the
survey
soon.
A
C
I,
for
that-
and
I
ran
into
this
yesterday,
based
on
the
the
issue
opened
a
couple
days
ago,
but
pogba
sri
fushi,
and
I
mean
we
know
that
logs
are
pretty
complex
and
he
was
having
some
of
the
xml
tags
removed
inside
the
logs,
which
is
different
than
the
some
other
software
out
there
different
how
the
other
software
out
there
displays
that
so
I
kind
of
blindly
went
into
it
and
investigated.
Can
we
show
that
stuff
in
inside
the
lobby?
C
And
the
answer
is
yes,
we
can
it's
a
little
convoluted,
but
then
this
morning
I
kind
of
stepped
back
and
realized.
Is
that
they're
really
what
we
want
to
do
here,
especially
considering
you
know
what
we
discussed
on
our
meeting
that
we
had
a
few
months
ago
when
we
decided
that
structure
logs
are
kind
of
something
we
should
address
in
the
future,
so
I'm
and
in
this.
In
essence,
this
is
a
structure.
B
C
A
C
A
Yeah,
so
I
mean
I
I
agree
with
you.
I
think
that,
having
like
first
class,
support
for
or
structured
logs
does
make
sense,
there's
a
lot
of
of
tools
that
use
structured
log
formats,
but
I
also
think
that
the
error
in
our
general
logging
is
still
an
error
like
we
should
not
be
like,
even
though
yes,
that's,
that's
a
structured
log
format
that
we're
getting.
We
should
still
be
able
to
render
it
without
sanitizing
it
and
making
it.
You
know
so
that
it's
not
the
actual
log
file
coming
out
of
there.
A
So
you
know
in
a
case
where
something
has
html
tags
in
the
log
or
xml
tags
in
the
log.
You
know
those
should
still
be
rendering.
Even
if
it's
not
a
structured
log
format,
we
can
parse.
A
Not
a
temporary
fix,
I
think
our
sanity
we're
over
sanitizing
the
log
output
in
a
way
that
is,
is
not
rendering
correctly.
So
I
think
that
it's,
it's
not
so
much
a
temporary
fix
to
be
a
permanent
fix
so
that
because
right
now
any
any
tag
artifact
in
there
would
get
sanitized
out,
and
you
wouldn't
be
looking
at
your
actual
log
representation
right,
whether
it
was
a
structured
log
or
not.
A
C
It
would
be
good
to
address
this
at
some
point,
although
I'm
not
worried,
you
know
how
many
different
formats
are
and
how
well
we
can
process
them
and
especially,
I
think
the
hardest
thing.
The
structure
log
is
gonna,
be
just
collecting
the
log
samples
and
make
sure
we
support
all
of
them
because
there's
a
obviously
huge
variety.
This
looks
like
some
probably
java
generated,
maybe
jms
or
something
like
that.
A
I
think
it
does
deserve
some
research
into,
like
I
don't
know
a
lot
about
structured
logs
personally,
so
I
think
it
it.
It
does
deserve
some
research
into
like
what
are
well-known
formats
that
are
being
used.
If
it's
just
xml
and
json,
then
you
know
we
just
we
implement
the
ability
to
handle
those
two
types
of
formats
for
structured
logging
and
go
go
along
our
day
and
if
somebody
comes
along
with
some
very
specific,
you
know
structured
log
format
they
want
to
support.
A
Then
we
can
consider
it
at
that
time
but
like
if,
if
everything
we
find
is
either
using
json
or
xml,
then
I'm
I'm
pretty
happy
to
just
say:
let's
only
support
those
and-
and
you
know
deal
with
any
edge
cases
as
they
come
up.
A
All
right,
moving
on
to
the
detecting
leaking
go
routine,
so
this
is
sam
brought
this
up
and
it's
pretty
neat
package
from
the
folks
over
at
uber
there's.
A
This
go
leak
package
which
you
can
use
on
your
tests
and
it
will
detect,
go
leaks,
go
routine
links,
specifically
it's
pretty
pretty
neat
sam
and
was
showing
it
to
me
yesterday,
the
day
before
and
we
walked
through
one
of
our
existing
kind
of
testy
flight
testy
flakes
but
test
flaky
tests
that
this
was
able
to
drop
in
place
and
be
like
yep.
You
have
a
go
routine
leak
and
I
believe
I
believe
we
fixed
it
in
the
little
pairing
session.
We
did.
A
D
A
D
The
package
is
kind
of
neat
in
the
sense
that
you
can
add
a
little
defer
go
leak
and
you
know
catch
leaks
that
are
running
in
a
particular
unit
test
after
you're
done
running
it.
So
that's
useful
for
us,
but
the
other
piece
of
it
is
that
you
can
also
just
throw
it
on
main
and
just
kind
of
see
everything
and
I
think,
like
that's,
probably
something
we
want
to
think
about
long
term,
and
even
there
are
other
tools
like
I
think
I
don't.
I've
never
tried
pronouncing
this
out
loud
trough.
D
Maybe
there's
a
maybe
someone
knows
how
to
pronounce
this,
but
you
there
are
ways
we
can
like
measure
and
start
benchmarking,
often,
which
is
something
that
we
haven't
really
done
right
and
we've
had
issues
in
the
past
of
people
saying
like
I
leave
often
open
and
it
crashes,
and
sometimes
it's
a
front,
end
issue,
but
I
think
something
like
this
would
help
us
just
make
sure
that
we're
not
leaking
things
in
the
back
end
and
also
help
kind
of
make
some
of
the
other
issues
like.
D
I
leave
a
terminal
instance
running
and
now
my
cpu
usage
is
100,
and
hopefully
this
would
start
mitigating
some
of
those
issues
and
give
us
a
more
like
a
measurable
way
to
do
it,
and
even
just
for
like
for
this
example,
the
flaking
test.
It
gives
us
a
very
reproducible
way
to
catch
them
as
well.
A
Yeah,
no,
that's
excellent.
I
think
I
think
this
is
great.
I
think
yeah
expect
to
see
us
slowly
adding
this
throughout
our
current
test,
suite
and
and
within
within
octane.
I
think
it'll,
I
think
we'll
will
really
benefit
from
from
taking
advantage
of
this
package.
C
Yeah,
it's
awesome
thanks
for
doing
that.
Sam!
That's
really
huge!
Especially
I
mean
those
nasty
flicks
are
so
annoying
if
you
can
iron
them
out.
That
would
be
awesome.
A
So
this
is
I
put
this
here.
This
is
for
me
in
the
works,
so
I
I've
been
reworking
our
existing
access
control.
Specifically,
we
have.
This
has
access
check
that
exists
in
the
code.
I
would
share
it,
but
my
sharing
is
not
working
anyway.
It
it
there's
a
there's,
a
has
access
check
that
exists
in
the
code
and
it
what
it
does
is.
A
Every
time
we
go
into
object,
storage
before
we
make
an
api
call,
we
attempt
to
see
if
you
have
permissions
to
make
that
call,
and
if
you
do,
then
we
allow
it
to
go
through
and
if
you
don't,
we,
you
know
disallow
it.
The
the
main
thing
that
has
access
does
is
it.
It
has
a
cache
where
it
will
cache
the
result
of
that
check.
So
it'll
say
like
oh:
did
you
have
access
to
lists
deployments?
A
Yes,
you
did
okay,
we're
in
the
same
context,
same
name,
space,
all
right,
we're
just
gonna
go
ahead
and
make
the
api
request
and
assume
that
your
permissions
haven't
changed
and
and
generally
speaking,
this
this
works.
The
problem
that
we
run
into,
though,
is
that
when
access
does
change
or
when
you
start
to
deal
with
crds,
you
may
be
making
a
request
that
you
do
have
permission
for,
but
maybe
that
crd
isn't
installed
yet
and
what
you
don't
want
to
happen.
A
A
A
this
thing
doesn't
exist
in
in
the
cluster,
yet
error,
and
currently
we
masquerade
those
as
a
very
similar
thing,
and
the
result
is
that
if
you,
for
example,
make
a
list
call
using
our
object,
storage
through
a
plugin
to
say
list
all
the
custom
resources
of
a
type
of
a
certain,
you
know
custom
resource,
you
will.
A
First,
you
will
get
a
failed
error
like
an
access
to
night
error,
telling
you
that
that
thing's
not
installed.
But
then
on
your
subsequent
query.
You
would
get
an
empty
list
back,
and
so
what
happens?
Is
that
the
the
way
the
behavior
changes
from
call
to
call?
It's
not
predictable,
and
we
want
to
avoid
that.
We
we
do
want
it
to
be
predictable,
and
so
I'm
currently
refactoring
our
existing
has
access
code
by
deleting
it
all.
A
So
that's
one
way
to
refactor
something
is
just
to
delete
all
of
it
and
what
I'm
replacing
it
with
is
a
library
that
is
just
called
subject
access,
but
what
that
library
does
is
it
it
goes
out
and
it
attempts
to
get
all
of
the
subject,
access
that
you
have
for
a
cluster
and
finds
the
list
create
update,
delete,
verbs
that
you
have
for
each
resource,
and
it
does
this
when
you're,
initially
loading
the
namespace,
I've
managed
to
get
this
down
to
taking
just
about
400
milliseconds
and
in
the
scheme
of
of
like
startup
times.
A
It's
actually
with
the
has
access
checks
removed
from
the
api
calls,
octan
becomes
more
responsive,
so
so
the
net
benefit
is
that
overall,
the
system
is
more
responsive.
There
is
a
little
bit
more
startup
time
initial
startup
time,
but
really
that's
not
it's
not
something.
I'm
noticing-
and
it's
not
something
my
my
tests
are-
are
capturing
either
because
the
the
actual
time
to
like
get
the
browser
open-
or,
in
this
case
electron,
open
and
start
to
like
get
the
initial
screen
rendered.
The
subject.
A
Access
call
has
already
happened,
so
it
it
it's
actually
working
out
pretty
well,
but
the
so
with
that
said.
The
benefit
here
is
that
there's
been
a
long-standing
issue
opened
to
get
an
access
review
page
into
octant,
similar
to
what
you're
seeing
on
the
screen
now,
which
is
this
just
list.
This
is
not
completed.
I'm
I
just
took
a
screenshot
of
what
I
had
working
right
now,
so
this
is
cluster
scoped,
specifically
right
here,
but
yeah.
A
So
this
will
present
you
a
full
list
of
what
you
have
access
to
and
and
and
the
expectations
based
on
your
current
context
and
the
name
space
as
well
as
your
cluster
level
access,
and
so
the
that
feature
will
we'll
just
kind
of
get
for
for
free
because
we're
building
up
this
subject,
access
cache
at
the
start
and
then
anytime,
you
switch
a
namespace
that
cache
is
refreshed,
because,
obviously
we
want
to
want
to
make
sure
that
we
have
the
most
up-to-date
information
and
we're
not
trying
to
to.
A
You
know,
look
at
old
information
based
on
like
if
you
install
a
new
context
or
a
new
cube,
config
and
the
context,
switches
or
refreshes.
This
will
the
the
cache
the
access
cache
will
refresh
when
you
switch
a
name
space.
The
access
cache
will
refresh
so,
but
unless
you're
doing
those
two
operations,
the
cache
stays
as
is
and
and
we'll
just
assume
that
you
will
maintain
your
current
set
of
working
permissions.
A
So
the
the
only
thing
we'll
have
to
do
is
provide
a
way
to
allow
you
to
just
explicitly
refresh.
If,
if
you
need
to,
I
haven't
figured
out
exactly
what
that'll
look
like
yet
right
now,
you
could
just
switch
contexts
or
name
spaces
to
trigger
the
refresh,
but
we'll
probably
put
some
type
of
you
know
circular
arrow
button
somewhere
that
you
can
click
refresh.
C
A
Yeah,
so
there
there,
there
is
not
a
delay
that
I'm
noticing,
obviously
other
people
will
be
able
to
test
it
here
soon
I'll
be
putting
up
a
branch,
the
the
whole
process
of
like
what
we
do
in
octane
when
we
switch
namespaces
now
is
as
expensive
as
as
going
and
fetching
the
list
of
all
of
the
resources.
A
So
I'm
not
noticing
any
significant
delay
between
namespace,
switching
or
content
switching
and,
in
fact,
in
an
actual
benchmarking
of
using
the
browser,
networking
tab
and
like
go
timing
tools,
octant's
responding
faster
because
it's
no
longer
doing
hundreds
of
of
has
access
checks,
potentially
so.
A
All
right,
open
q
a
should
there
be
naming
conventions.
This
is
from
sam.
B
D
D
So
I
thought,
like
you
know,
so
I
take
the
vs
code
model
right
like
there
are
some
vs
code
plugins
that
have
this,
I
guess
like
non-descriptive
names
like,
for
example,
get
lens
right
like
a
little
plug-in.
That
basically
gives
you
a
little
like
helper
text
with
get
to
see
who
last
committed
what
and
it's
got
a
name
for
it.
So
I
thought.
Okay.
D
Maybe
there
is
something
here
to
either
well,
I
don't
want
to
like
come
with
something,
that's
clever
for
the
sake
of
just
being
clever
and
be
like
that's
funny,
but
at
the
same
time
like
I
want
to
see,
if,
like
we
want
to
start
thinking
about
these
conventions,
so
that,
like
plug-in
names
are
somewhat
plugins,
are
somewhat
discoverable
right,
so
be
like.
There
was
there's
this
octane
plug-in.
D
That
does
things
with
k-native
or
octa
plug-in
those
things
with
helm
and
we
don't
want
to
start
creating
a
scenario
where
future
plugins
all
have
funky
names
and
now
we're
like,
I
know,
there's
a
plugin
for
it,
but
I
don't
know
how
to
search
for
it,
because
it's
called
something
else.
So
I
I
think
maybe
the
core.
This
question
is
here
like,
for
example,
right
now,
at
least
like
through
the
internals
of
vmware.
I'm
proposing
to
call
it
kino
like
because
kind
is
kubernetes
and
docker.
So
I
thought
like.
A
C
A
I
so
from
like
a
so
there's
so
there's
two
there's
two
parts
to
this:
there's
like
the
vmware
part
like
vmware,
open
source
and
I'm
I'm
pretty
sure
that
anything
that's
generated
out
of
our
group.
That's
going
to
be
open,
sourced
and,
and
you
know,
under
vmware
repo
will
be
octant,
plugin
four
and
follow
that
naming
convention
this.
A
This
is
this
is
the
convention
that
was
used
for
the
octan
plug-in
for
k-native,
and
I
believe
it
is
the
convention
that
vmware
desires
to
use
for
plug-ins
that
we
create
just
from
a
legal
legal
perspective.
So
as
you
go
through
the
yeah
as
you
go
through
the
open
sourcing
process
within
vmware,
if
you
can
get
them
to
use
some
other
name
awesome.
A
If
not,
then
I
think
likely
that
I
think
most
of
our
stuff
will
end
up
as
octane
plug-in
four
and
and
generally
I
don't
think,
that's
a
bad
convention
right
like
like,
if
every
if
every
plug-in
out
there
used
that
it
becomes
very
searchable
and
it
also
like
you.
A
Yes,
it's
a
little
verbose,
but
you
know
exactly
like
octant
plug-in
for
kind
of
plug-in
for
helm,
octane
plug-in
4k
native
octane
like
it's.
It
creates
this
very
like
easy
sense
of
like.
Oh,
this
is
an
octane
plug-in
for
that
thing.
So
yeah
I
don't.
I
don't
think
it's
a
great
name,
but
I
don't
think
it's
the
worst
name.
I
think
clever
names
generally
are
worse.
A
C
A
So
yeah,
that's
I
don't
know,
that's
my
opinion.
I
I
basically
my
opinion
is
we'll
do
what
we
have
to
do
and
then,
but
it
might
be
good
to
to
encourage
a
convention
in
our
documentation
right
and
say
like,
and
we
can
think
about
that
and
look
at
what
other
plugins
are
currently
doing
and
and
just
say
like
like
here's.
Here's
here's
names
of
other
plugins
that
we
are
like,
like
as
the
team
we're
like
yeah.
We
we
encourage
plugin
authors
to
name
their
plugins.
This
way.
C
Yeah-
and
I
also
think
you
know
anything
that
helps
this
score
this
curve,
I'm
sorry
helps
discovering
plugins
easier
having
a
hard
time
for
some
reason.
Pronouncing
that
word
today
is
is
a
good
thing,
so
either
adding
a
tag,
or
especially
now
at
some
point
when
we
have
like
that
inside
the
ui
that
will
not
be
so
important,
but
right
now,
any
any
naming
convention
that
helps
user
discover,
octant
is
is
a
good
thing.
D
Okay
cool,
so
I
think
the
takeaway
that
I'm
getting
from
this
is
it's
probably
a
good
idea
to
just
stick
with
the
octane
plug-in
for
blank
model.
Just
so
vmware
will
not
push
back
on
the
ticket,
but
also,
just
I
think,
being
clever
here
doesn't
really
win
us
anything.
So,
let's
just
not
do
it.
A
Yep,
I
I
think
I
think
yeah.
I
think
I
agree
I
do
agree.
I
don't
think
I
agree.
I
do
agree
all
right.
I
think
that's
all
we
have.
I
just
want
to
say
thank
you
to
everyone
who
filled
out
the
survey
and
contributed
to
it
and
did
interviews.
It's
really
appreciated.
Thank
you
so
much.
Thank
you,
isha
for
pulling
all
that
together
and
and
getting
it
out
there
and
collecting
all
this
information.
A
C
E
It's
actually
still
open
all
right,
it's
still
open
and
you
can
find
the
link
on
the
website
or
in
the
hack
md
notes
from
the
our
previous
community
meeting.
Oh
all,
right
they'll
want
to
contribute
yeah.
A
B
B
A
All
right
and
that's
I'll,
put
it
in
and
put
it
in
there
too.
Okay,
I
put
it
everywhere
yeah,
I
think
that's
all
we
have
for
this
week.
We
will
we'll
we'll
get
some
stuff
together
around
solidifying.
A
What
o162
is
going
to
look
like
and
try
to
try
to
really
put
our
focus
and
attention
on
getting
this
electron
stuff
ready
for
ro
dot,
17.
so
yeah?
That's
it.