►
From YouTube: Octant Community Meeting - June 30th, 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
Yeah,
as
far
as
I
can
tell
yeah
real
life
hi
everyone.
How
are
you
thank
you
for
joining
this?
Is
our
weekly
octane
community
meeting
today
is
june
30.
and
well.
I
appreciate
that
you
were
joining
us
here.
Remember
that
our
code
of
conduct
still
applies
for
these
meetings,
so
we
ask
you
to
please
read
and
abide
by
it
also
to
be
able
to
catch
up
after
the
meeting
and
keep
open
our
communication
lines
with
you.
We
ask
you
to
please
add
your
name
and
your
organization.
You
represent
to
the
agenda.
A
So
having
said
that,
welcome,
well,
some
status
updates
theme
is
growing.
We
are
you
know,
vmware
is
hiring
for
a
product.
Designer
role,
which
is
you
know,
seems
to
be
something
related
with
user
experience
and
design
for
for
the
product
itself,
so
it
looks
like
an
exciting
role
and
also
a
product
manager
for
for
often
so,
if
you
want
to
apply
of,
if
you
know
someone,
please
go
ahead
and
apply
for
it.
A
Okay,
now
for
the
updates
on
the
project
itself,
we
have
a
fix
something
that
liam
has
been
working
on
for
typescript
component
generation.
So,
if
liam
could
please
share
more
details
around
that.
B
Yeah,
so
just
just
more
visibility
into
how
the
overall
kind
of
plug-in
ecosystem
works.
B
So,
basically
often
you
know
kind
of
backbone
and
structure
is
all
and
go,
and
normally,
when
you're
creating
a
plug-in,
you
will
create
these
ui
components
in
go
and
then
they
will
be
sent
by
often
to
the
front
end
and
displayed
there,
and
we
recently
added
an
option
to
write
plugins
in
typescript
as
well,
and
we
actually
have
code
that
will
take
the
the
golang
ui
components
and
then
kind
of
transpile
them
into
components
that
are
accessible
from
typescript.
B
So
it
should
be
theoretically
an
automated
process
where
basically
anytime,
any
changes
are
made
to
the
go
go
components.
The
typescript
ones
will
update
accordingly,
and
then
we
have
procedures
in
place
to
update
the
package
on
npm
as
well.
It
turns
out
there
were
a
few
recent
modifications
that
actually
prevented
this
generation
from
working
successfully,
which
meant
that
using
the
latest
generated
type
code
was
not
possible
with
the
latest
version
of
octet.
B
So
finding
a
few
issues
and
fixing
some
edge
cases
in
the
component
generation
code
solves
these
issues
and
the
pr
is
currently
open.
But
all
the
tests
are
passing
so
once
it's
approved,
we
should
be
good
to
go
for
allowing
typescript
components
without
any
hassle
for
the
latest
version
of
octane,
which
is
going
to
be
pretty
useful,
especially
as
we're
trying
to
kind
of
expand,
plug-in
options
and
the
scope
of
octan.
C
Awesome
yeah
thanks.
That's
excellent
work
liam.
I
really
appreciate
that
and
yeah
that
yeah,
that's
it's
a
it's
a
good
one
to
unblock
a
few
people
as
well,
because
I
think
there's
some
people
trying
out
some
plug-in
stuff
on
the
the
latest
versions
and
the
causing
some
hang-ups
with
related
to
the
to
the
forums
and
the
components
so
yeah.
This
is
just
great
thank.
A
You
awesome
thank
you
liam,
so,
okay
for
the
next
point,
I.
C
So
I
put
this
here,
I
wanted
to
bring
it
up
just
to
discuss
and
see
what
people's
thoughts
were.
Essentially,
we
were
looking
at
cutting
an
0.22
for
a
target
of
july
13th.
We
wanted
to
do
a
set
of
have
a
set
of
key
discussions,
two
of
them
in
particular
one.
C
It
was
around
kind
of
clarifying
our
road
map
and
adding
some
more
detail
and
scoping
some
things
out
a
bit
better,
underneath
the
road
map
headings
and
then
the
other
piece
of
that
was
after
we
clarified
the
road
map,
we
kind
of
wanted
to
pick
a
sprint
goal
and
align
with
some
some
like
key
objectives
for
the
outcome
of
the
sprint,
and
we
haven't
been
able
to
have
that
meeting
yet
to
do
the
roadmap
clarifying.
C
So,
ultimately,
what
we're
stuck
with
is
like
kind
of
in
this
like
middle
ground,
where
we
have
some
good
issues
to
work
on
by
the
time
we
have
the
discussion
and
plan.
We'll
essentially
have
you
know
a
u.s
holiday
week,
plus
one
more
week
to
actually
like
land
on
the
13th.
So
my
thought
was
take
all
the
work
that
we
have
in
flight.
C
Now
the
things
that
we've
been
working
on
some
of
the
work
that
luis
has
been
doing
and
vikram
and
liam
have
been
doing
and
some
of
the
stuff
that
I
have
preparing
to
land
that
actually
have
some
public
api
changes
for
our
package.
Folder
call
that
get
all
that
stuff
kind
of
brought
together,
which
is
currently
being
tracked
in
our
o.
21.1
project,
which
was
going
to
be
a
bug,
fix
release,
bring
that
all
into
0.22.
C
Add
in
the
the
issues
that
scott
rosenberg
raised
last
week
as
being
important
to
him
and
then
call
that
kind
of
our
o
dot
22
release
and
and
cut
it.
When
the
current
set
of
bug
fix
issues
and
the
and
the
two
features
that
scott
had
suggested
were
completed.
And
then
in
the
meantime
we
can.
Then
we
can
take
that
time
to
to
kind
of
make
sure
we're
having
our
roadmap.
C
Clarification,
make
sure
we're
doing
a
sprint
goal
and
make
sure
that
all
of
the
effort
that
was
going
to
go
into
0.22
ultimately
ends
up
in
0.23.
C
But
we
don't
put
ourselves
in
a
situation
where
we're
trying
to
crunch
things
to
hit
the
cadence
I'd
rather
establish
a
normal,
healthy
cadence
of
releases,
and
if
process
that
needs
to
happen
doesn't
happen,
we're
still
able
to
release
software,
we're
still
able
to
get
good
features
in,
but
then
allowing
those
processes
to
happen
just
to
the
next
version,
because
if
we
have
a
the,
I
guess
the
point
is:
if
we
have
that
healthy
cadence,
then
when
these
processes
happen,
there's
a
natural
place
for
for
the
outcomes
of
those
to
land,
which
is
the
next
coming
up
release,
if
that
makes
sense
anyway,
general
thoughts.
E
I
wanted
to
say
yeah
release
all
those
changes
sooner
than
later,
because
I
want
to
consume
them,
but
I
don't
need
you
to
do
an
official
release.
So
I
could
just
you
know,
take
the
code
off
master.
It
doesn't
really
matter.
C
And
I
think
another
part
of
this
is
that
the
the
work
that
liam
is
doing
with
changing
the
with
the
upgrades
with
the
updates
to
the
typescript
component
generation,
as
well
as
the
updates
that
will
then
flow
into
the
upstream
library
for
typescript.
Honestly,
those
are
those
are
a
whole
version
step
that,
like
calling
those
a
point,
release
would
would
be
doing
them
a
disservice
because
there
are
api
changes
involved.
C
So
I
think
also,
this
kind
of
just
makes
that
managing
that
a
lot
easier,
we
just
get
to
tag
the
next
typescript
library
with
0.22
and
and
and
people
can
consume
it
as
a
whole
new
version.
So
that's
kind
of
factoring
in
here
as
well.
A
C
C
B
Oh
no
yeah,
I
I
just
real
quickly.
I
I
agree
with
wayne.
B
I
think
it
makes
sense,
because
preserving
kind
of
parody
between
octant
versions
and
the
all
related
you
know,
plug-in
utilities-
is
really
important
so
that
people
kind
of
understand
exactly
what's
compatible
very
quickly
and
yeah
honestly,
just
just
whatever
makes
more
sense
in
terms
of
making
it
clear
that
you
know
a
specific
version
of
octane
is
gonna
work
with
a
specific
version
of
the
plug-in
library
seems
pretty
important,
especially
because
it
hasn't
always,
you
know,
matched
up
and
even
now
with
the
0.21
release
of
the
typescript
plug-in
library,
some
things
are
not
working,
and
so
maybe
yeah
bumping
to
0.22
would
give
more
of
an
indication
that
some
of
these
issues
are.
A
I
don't
know
if,
if
you
wayne
wants
to
add
something
more
to
that
point
or
no
that's
clear.
Thank
you.
Okay.
Well
now,
for
the
discussion
points
we
have,
you
know
some
things
that
here
I
believe,
was
jamie.
What
did
he
hear
this
topic?
So
if
you
want
to
comment
something
there,
yeah.
E
Looks
like
wayne
pushed
something
like
today
or
yesterday
that
may
have
resolved
it,
but
yeah
when
we
we
wanted
to
bring
our
own
streaming
client
factory
implementation,
we're
kind
of
using
octane
as
a
library
and
as
soon
as
we
started
to
do
it
we
realized.
Oh,
we
can't
even
write
the
implementation
that
we
want,
because
one
of
those
methods
in
the
signature
contains
an
internal
type.
E
So
I
figured
this
would
be
a
time
to
be
like
hey.
I
can
think
of
a
few
ways
around
this.
It
seems
like
it
could
require
some
kind
of
structural
thing
or
exposing
a
bunch
of
stuff.
You
might
be
hesitant
about
so,
but
it
sounds
like
you
may
have
already
done
it.
So
maybe
you
know
yeah
pass
that
speaking.
Stick
to
wayne.
C
Sure
yeah
so
yeah,
I
I
pushed
up
a
new
p.
I
was
I
was
this
work
was
in
flight
for
the
last
couple
days.
I
had
to
rebase
and
refactor
some
stuff
based
off
of
the
streaming
websocket
interface
changes
but
yeah.
So
if
we
click
on
the
config
dash
interface
link
there,
that
is
bringing
that
whole
dash
interface
out
into
the
package
folder,
which
it
also
includes.
The
crd,
watcher
and
error
store
interfaces
are
now
out
into
the
package
folder.
C
C
So
it
was
pretty
safe
to
the
lifting
effort,
was
pretty
low
to
move
those
out.
It
was
more
of
the
updating,
the
all
of
the
tests
and
mock
generation,
and
things
like
that.
So
that's
there
in
the
in
this
pr.
If
you
wanted
to
take
a
look
at
it
and
try
it
as
a
branch
to
see
if
it
fixes
all
of
your
needs,
if
not
comment
on
the
pr
and
I'll
be
sure
to
adjust
or
fix
anything
that
I
might
have
missed.
E
So
daniel
from
my
team
is
on
the
call
I
don't
know
daniel,
are
you
there
does
this
address?
Does
this
make
sense
to
you.
F
Yeah
yeah
hi
ron
yeah.
This
is
basically
the
the
core
thing
that
we
needed
to
be
able
to
do
that.
There
was
also
because
the
actual
changes
that
we
need
to
do
to
our
custom
client
streaming
factory
are
very
small.
It's
just
so.
I
tried
to
basically
copy
paste.
The
current
default
implementation.
G
F
The
small
changes-
and
there
were
a
couple
of
methods,
as
part
of
I
think
it
was
websocket
client.
There
is
a
read,
pump
and
right
pump
methods
which
are
actually
not
exported
so
like
they
are.
They
start
with
lower
case.
That
will
be
a
small
change
that
could
also
help
us
with
what
we
need
to
do,
and
it
should
be
a
very
small
change.
C
Okay,
yeah
I'll,
if
you
can,
if
you
have
the
the
time,
it
would
be
great
if
you
could
go
to
the
pr
and
make
a
comment
and
even
highlight
just
the
the
specific
area.
C
I
I
know
the
read
pump
and
right
pump
area
that
you're
talking
about,
but
or
maybe
we
can
sync
up
later
and
go
into
the
details
of
what
it
is
you're
trying
to
do,
because
I
think
I
think
my
default
is
going
to
be
probably
just
duplicate
them,
because
the
implementation
detail
of
how
you
read
and
write
is
is
is
that?
But
if
the
methods
themselves
of
the
signatures
for
the
methods
need
to
be
exported
so
that
you
can
have
your
own
implementations,
then
that's
something
we
can.
We
can
do.
F
E
It's
gonna
say
just
you
know,
so
that
people
don't
feel
in
the
dark
to
quickly
describe
what
we're
trying
to
do.
Is
we
really
want
to
use
the
same
websocket
streaming
factory,
whatever
that
is
in
octane
already.
The
main
piece
that
we
want
to
override
is
the
creation
of
the
client
ids.
E
You
know
id
key
from
a
database
that
we
control,
so
otherwise
we
want
the
actual
websocket
mechanics
is
all
the
same
to
us.
It's
really
just
that
one
little
piece
of
taking
an
http
request
and
pulling
a
a
uuid
out
of
it.
A
C
Yeah,
so
I
was
hoping
to
have
a
demo
for
this.
I
you
know,
I
don't
follow
my
own
rules
and
I
was
fussing
with
it
just
before
this
meeting
and
it
broke
so,
which
is,
I
was
like,
I
can
add
one
more
thing
to
it:
it'll
be
cool,
and
now
it
doesn't
work,
but
I
will
say
that
with
minimal
effort
I
was
able
to
get
octant
to
connect
to
a
kcp
cluster
and
it
yeah
it
just
just
kind
of
worked,
which
was
was
pretty
great.
C
There
are
some
things
that
happen
during
startup.
That
octant
makes
some
assumptions
about
what
resources
are
available,
and
you
know
for
like
our
overview
pages
and
and
workload
pages,
you
know
in
kcp
by
default
those
things
aren't
there
until
the
cluster
has
synced
and
and
made
them
part
of
the
resource
list.
So
there's
there's
a
little
bit
of
I'm
going
to
write.
Basically,
the
outcome
of
this,
I
think,
is
positive.
C
I'm
going
to
write
some
issues
that
kind
of
cover
what
I'm
about
to
talk
about
now
and
then
we
can.
As
we
talk
about
our
roadmap
and
and
goal
planning
stuff,
we
can
prioritize
these
issues
and
and
look
at
potentially
using
kcp
more
in
depth
with
oxen,
but
the
the
second
line
there
yeah
the
assumptions
about
resources.
We
can
do
a
better
job.
This
will
tie
into.
Actually,
I
think
the
air
handling
that
stuff
that
luis
is
working
on.
Once
we
have
a
place
to
kind
of
display
errors.
C
We
can
then
capture
them
and
say:
hey.
You
know
that
resource
isn't
in
the
cluster.
C
We
tried
to
list
it,
but
it's
not
here
and
then
the
other
thing
is
that,
having
some
form
of
plug-in
to
deal
with
the
cluster
crd
and
the
negotiated
api
crds,
that
kcp
uses
would
actually
really
enhance
the
experience
of
using
kcp
with
octane,
because
you
would
be
able
to
just
kind
of
fire
up
octane
looking
at
an
empty
kcp
instance,
and
then
you
know
browse
or
paste
in
or
give
it
the
location
of
your
keep
configs
have
that
generate
the
the
cluster
crd
and
from
there
you
know
you
would
start
seeing
those
those
resources
sink
into
kcp
without
ever
having
to
like
step
out
and
run
things
on
the
command
line.
C
So
yeah
yeah,
it's
a
very
interesting
kind
of.
C
What's
the
word
I
think
they're,
I
think
they
they
they're
very
symbiotic,
so
the
I
think
we'll
continue
to
explore
it
and
they're
continuing
to
expand
and
add
features
and
so
yeah
anyway.
That's
that's
kind
of
the
outcome.
There
some
issues
to
come
with
some
detailed
kind
of
detailed
explanations
around
the
the
work
I
could
see
us
doing
to
potentially
back
end
kcp
with
octet
or
back
end
octant
with.
C
Kcp
jamie.
E
Yeah,
I
think
you
may
have
just
answered
it,
but
I
was
just
curious
about
whether
you
whether
there
was
an
opinion,
you
know,
you're
experimenting
with
kcp
is
you're
thinking
here
that
you
know
octant
folks
could
target
a
pre-existing
kcp
and
like
this,
you
could
sort
of
integrate
with
known
kcp
workflows
or
is
the
idea
that
you'd
actually
shrink,
wrap,
kcp
and
octane
ship
them
together,
like
octa,
would
come
with
its
own,
bundled
kcp
kind
of
thing.
It
sounds
like
it's.
The
latter.
C
Well,
it's
both
right,
so
I
think
the
first.
The
first
step
is
to
just
make
octet
work
well
with
kcp
when
someone's
using
it
right
now.
It
doesn't
because
of
those
assumptions
that
it
makes
so
and
this
this
is
a
broader
problem
within
octant
that
doesn't
just
impact
kcp,
but
it's
very
noticeable
in
kcb,
because
it
is
such
a
minimal
set
of
resources
that
are
there.
C
Octane
just
fails
in
really
interesting
ways
when,
when
like
basic
things
that
ship
with
kubernetes
aren't
there,
so
that
that's
like
the
first
step
and
then
the
second
part
would
be
yeah
to
shrink,
wrap
it
and
have
it
underpin
octant
as
the
essentially
the
the
cube
config
manager,
because,
right
now
we
kind
of
do
all
that
manually.
We
have
this
cube
config
context
thing
that
we
manage
and
watch
contexts
and
handle
it
all,
and
this
this
doesn't
even
have
to.
C
This
is
doing
all
that
work
for
us
and
it's
also
doing
the
work
of
syncing
resources,
and
it's
also
doing
the
work
of
you
know
pulling
the
you
know
refreshing
from
the
cluster.
So
there
it's
a
way
to
potentially
offload
a
lot
of
the
work
that
octant
has
baked
into
its
code
to
another,
to
a
piece
of
code
to
a
project.
That's
dedicated
for
that
purpose.
Essentially,.
E
Yeah,
it
sounds
really
dope
to
be
able
to
have
you
know,
rather
than
octense
sort
of
data
layer
being
a
cubeconfig.
It's
just
it's
a
kcp
server,
kcp
client,
a
ton
of
simplifying
assumptions
almost
in
the
business
of
becoming
a
kind
of
easy
describe,
that,
like
cluster
plug-in
being
like
a
a
ui
for
kcp
or
whatever
that
he
can
be
like
manage
kcp
and
attach
clusters,
and
you
have
have
a
clean
hugo
eye
to
do
it
with
that's.
That's
very
cool.
C
Yeah
and
one
of
the
one
of
the
added
benefits
we
get
here
too,
that
just
kind
of
like
I
was
noticing,
as
I
was
playing
around
with
it
is
we
also
can
get.
We
can
just
make
assumptions
about
what
api
calls
we're
allowed
to
make,
because
we
have
unfettered
access
to
the
kcp
cluster.
Now
those
clusters
that
are
configured
as
as
back
as
upstream
clusters
to
kcp
might
only
have
access
to
a
single
name,
space
or
access
to
a
single
set
of
resources.
C
Excellent
yeah,
so
that's
a
watch
out
for
issues
coming
up
around
this
they'll
mention
kcp
explicitly,
but
some
of
them
are
going
to
be
a
little
more
generic,
just
to
kind
of
fix.
More
of
the
systemic
issues
that
are
were
uncovered
by
using
such
a
limited
kubernetes
api,
but
and
then
a
couple
will
be
directly.
You
know
exploring
further
kcp.
A
That's
great
thanks
so
much
okay,
now
for
the
open
q,
a
I
don't
know
if
someone
else
from
the
team
or
someone
here
in
the
call
has
questions,
I
have
a
couple
of
them.
One
of
them
comes
from
a
conversation
I
was
having
with
one
of
our
users.
A
He
runs
a
consulting
firm
in
europe
and
he
was
mentioning
that.
Isn't
there
a
way
you
know
when,
when
I
start
octant,
I
would
like
to
filter
out
in
some
way
like
passing
some
configuration
file
or
or
some
other
way
to
filter
out
resources
that
I
don't
want
to
see
right
so,
and
he
mentioned
that
this
was
especially
useful
in
his
opinion
for
people
that
is
new
to
kubernetes.
A
My
opinion
is
that
for
you
to
filter
out,
you
need
to
know
what
do
you
want
to
filter
right?
You
cannot
be
really
new
to
kubernetes
kind
of
users
to
to
be
able
to
establish
a
proper
filter,
but
I
don't
know
if
that
will
make
sense.
I
promise
to
he.
He
couldn't
join
because
it's
it's
really
late
for
him,
but
I
promise
to
bring
the
question
here.
Would
that
make
sense?
G
A
Yeah,
I'm
not
completely
sure
of
his
use
case.
I'm
still
retrieving
more
information,
but
it
seems
like
he
managed
multiple
clusters
for
different
customers
right,
so
he
would
like
to
you
know,
bring
them
their
octan
already
configured
to
see
only
what
they
have
to
see
right,
not
rely
on
them
on
the
end
user
to
configure
filters
inside
of
octane,
but
just
having
the
tool
filter
out
from
the
beginning.
A
C
G
C
Both,
I
think
I
think
the
second
thing
you
described
right
to
me.
That's
a
set
of
you
know
you,
you
configure
either
a
name
space
or
some
form
of
r
back
for
a
user
and
and
then
you
hand
them
that
cube
config
when
you
hand
them
octants,
and
so
all
they
see
is
the
things
you
want
them
to
see.
The
idea
of
not
displaying
like
whole
resources
on
the
overview
is
kind
of
like
a
anti-goal
of
octan.
C
Like
the
goal
is
we
want
to
show
you
everything
that's
in
there,
so
you
don't
have
to
go
hunting
for
it,
and
then
we
want
to
make
it
so
that
when
you,
you
know
like
what's
a
pod
and
you
click
into
it,
you're
getting
a
summary
in
some
detail
that
kind
of
helps
you
understand
and
you're
also
getting
some
search
terms
that
can
help
you
go
google
and
and
learn
more
about
these
things
so
like
not
showing
them
wholly
is
just
kind
of
probably
not
something
we
would.
C
We
would
do
but
having
the
ability
to
say,
like
here's,
a
set
of
of
filters
that
I
always
want
applied
when
I
start
octant
and
adding
that
to
the
preferences
or
here's
here's
a
you
know
we
already,
you
can
already
set
a
default
namespace.
You
can
already
set
the
view
so
like
take
me
right
into
the
deployments.
C
A
I
was
using
the
supply
ammo
window
and
I
don't
know
I
don't
know
if
that's
only
for
me,
but
when
I
hit
here
apply,
I
have
a
confirmation
at
the
top
of
the
screen,
but
I
don't
know
if
I
just
turn
my
face
a
couple
of
seconds
or
minutes
and
move
back.
A
C
Yeah
I
mean
it's,
we
have
an
open
issue
for
it.
It's
a
long-standing
portable.
D
C
Thing
within
octant,
you
know
the
the
yeah
there's,
not
a
we're,
hiring
a
product
designer
okay.
C
This
is
definitely
one
of
the
reasons
we're
hiring
a
product
designer
they're
right
now,
it's
like
we
can
dismiss
it,
but
then,
if
you
like,
we
have
no
great
way
of
signaling
that
the
alert
we
sent
was
success,
warning
or
error
right.
So,
if
you
mis
dismiss
by
default
on
apply,
you
may
be
dismissing
when
there's
an
error
and
then
you're
losing
the
content
of
the
apply
ammo
window
right.
So
we
currently,
we
just
kind
of
chose
to
leave
it
up
and
you
get
the
alert
in
the
back.
C
That's
like
behind
the
shadow
and
yeah.
It's
not!
I
agree
with
you.
It's
not
great.
It's
definitely
something
we
want
to
improve
and
make
better.
I
think
this
is
also
when
we
get
into
like
rich
error
handling,
something
where
you
could
apply
this.
It
would
dismiss
it.
The
server
would
respond
and
say:
hey
that
failed
and
then
in
the
air
reviewer.
C
C
Like
in
an
image
name
right,
that's
one
an
example
where,
like
image
name,
is
only
a
certain
set
of
characters,
so
yeah
you're
right,
it's
a
bad
experience.
That's
all!
I
guess.
That's
all.
I
can
say.
G
Yeah
status
status
is
historically
a
really
difficult.
Ui
issue
ask
anybody
from
microsoft
who
worked
on
like
file
download
status.
You
know
you
have
19
days
left
30
seconds
17
days
a
minute
and
a
half
like
this
is
historically
just
problematic
and
difficult
to
do
so.
Yes,
I
think
it
should
be
addressed
and
it
will
definitely
create
some.