►
From YouTube: Octant Community Meeting - Jan 22, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
welcome
everybody
to
the
January
22nd
octant
community
meeting
today
we're
going
to
cover
kind
of
the
update
on
ODOT
10,
which
is
the
the
next
release
coming
out
and
then
we're
going
to
talk
about
what's
gonna
be
happening
after
ten
and
then
we'll
get
into
open,
Q&A
and
questions
there.
So
I
think
some
of
our
after
all,
at
10,
will
answer
some
of
the
questions
that
folks
might
have
as
well.
So
all
I
am
going
to
nominate
Sam
to
go
ahead
and
do
the
ten
update
on
the
spot,
unprepared,
sure.
B
Sounds
good
so
the
biggest
feature
that
we're
looking
at
at
the
upcoming
oten
release
is
going
to
be
our
terminal
feature.
So
you
can
run
container
exec
and
we've
added
this
new
slider
widget
on
the
bottom
that
will
toggle
up
and
it'll
have
a
series
of
tabs
which
will
correspond
to
each
container
exec
command.
You
have
when
you're
running
often,
and
this
one
is
going
to
be
coming
out
fairly
soon.
I
think
here.
C
A
Fill
in
in
the
meantime,
Sam
did
some
great
work
on
the
the
port
for
adore.
The
old
port
foreigner
had
a
bunch
of
front-end
components
and
cross-cutting
concerns
and
things
that
that
weren't
necessarily
supposed
to
be
on
the
front
end
Sam,
went
and
refactored
all
of
that,
so
that
the
back
end
was
providing
all
of
the
information,
as
well
as
the
using
the
standard
set
of
components.
A
So
I
and
I
think
that
was
one
of
the
the
few
items
that
we
had
that
wasn't
just
using
our
standard
component
library
to
draw
stuff
in
the
in
the
front
end.
We've
also
moved
some
of
the
information
off
of
the
summary
tab,
specifically
the
metadata
information.
It
now
has
its
own
tab
and
you'll
be
able
to
view
that
separately,
mainly
the
the
driver
for
this
was
around
annotations.
A
They
can
get
very
long
and
they
would
push
a
lot
of
the
useful
and,
like
the
immediately
useful
information
on
the
summary
page
down
well
below
any
any
fold
that
you
would
have
to
scroll
for
a
while
to
get
to
it.
So
in
environments,
where
there's
heavy
use
of
annotations.
The
summary
page
is
now
a
little
more
usable
and
all
of
that
has
been
moved
to
its
own
tab
in
metadata
I.
A
A
We
created
a
new
error
component
which
ensures
that
that
formatting
and
things
like
that
are
not
messed
with
on
the
errors
that
get
rendered
out
so
they'll
be
easy
to
copy
and
paste
into
issues
and
easy
to
kind
of
read
and
parse
without
dealing
with
the
terminal.
So
is
there
anything
else
you
want
to
add
to
what's
coming
up
there,
Sam
yeah.
B
B
For
testing
purposes,
but
it
will
now
just
come
generated,
it's
checked
in
now,
so
you
don't
actually
have
to
generate
them,
and
this
will
be
updated
as
part
of
the
build
files,
but
as
officially
for
the
next
release,
they
will
just
come
as
they
will
come
versioned.
So
this
is
something
to
keep
in
mind
and
it'll,
be
reflected
in
any
note
files
or
homebrew
formulas
and
so
forth,
and
the
last
one
is
also
going
to
be
I.
Think
there's
some
work
done
around
the
K
logs
I
think
they
were
just
it's
more
of
octant.
A
A
And
deep
there
it
is
all
right
so
moving
on
to
after
o
dot
n,
so
we've
created
a
list
of
priorities
around
what
we've
seen
from
community
requests
and
I.
Think
as
we
go
through
these,
it's
going
to
cover
probably
a
lot
of
the
questions
that
folks
have
because
I
see
a
lot
of
the
faces
here.
Are
people
who've
created
some
of
these
issues,
so
one
of
the
priorities
after
a
lot
n
is
going
to
be
plug-ins.
A
That
was
just
kind
of
in
its
own
repository
and
didn't
have
octant
embedded
alongside
of
it,
and
that
proved
to
be
a
difficult
test.
So
I'm
we
are
all
working
on
making
that
interface
better
and
removing
some
of
the
leaks
of
the
internals
of
Occident
that
go
out
into
the
plugins.
The
downside
of
this
is
that
there
probably
will
be
some
depending
on
how
your
plugin
is
implemented.
There
probably
will
be
some
some
breaking
changes
to
the
API,
but
we
will
be
sure
to
deprecate
that
and
then
and
then
break
them.
A
Even
though
we're
not
in
a
1.0
release,
it's
it's.
We
usually
find
it's
not
kind
to
just
break
people
right
out
of
the
gate,
so
we're
gonna
make
some
fixes
in
the
next
release
around
plugins
and
the
interfaces
that
are
exposed
and
enough
and
make
sure
to
put
some
deprecation
warnings
in
there
for
things
that
might
be
going
away.
A
lot
of
those
are
going
to
be
your
some
of
them.
We
won't
be
able
to
put
warnings
in
for
because
they
are
there.
A
Things
like
we
are
accessing
fields
like
we're
accessing
properties
of
a
struct
directly.
Instead
of
we
didn't
provide
a
wrapper
interface
around
it,
so
we
will
be
able
to
provide
wrappers
around
those
and
in
those
wrappers
you
know
we
can
create
some
comments
and
some
and
some
documentation
around
it
to
kind
of
direct
people
to
using
them.
But
there's
just
because
of
the
way
we
did
some
things
deprecating
all
of
the
areas
that
will
will
break
will
be
a
difficult,
but
we
will
do
our
best
around
that.
A
So
the
other
area
that
we're
going
to
be
looking
at
is
documentation.
This
ties
in
with
plugins,
as
well
as
just
general,
use
documentation
right
now.
It
is,
as
someone
had
mentioned
earlier,
I
think
it
was
Andy.
It
is
difficult
to
get
started
in
octant,
especially
if
you
want
to
develop
against
core
oxidant.
There
is
not
a
lot
of
developer
documentation,
there's
not
a
lot
of
help.
A
It's
kind
of
we
just
kind
of
toss,
folks
in
and
expect
them
to
have
to
go
and
reverse-engineer
things
and
walk
the
code
and
figure
it
all
out
and
and
that's
not
very
friendly
and
not
very
accessible
from
a
get
people.
You
know
contributing
and
also
just
to
just
for
us
as
well
like
we
Sam
and
I
both
had
the
experience
of
coming
back
to
our
own
code
and
having
to
spend
too
much
time
walking
through
it,
because
we
didn't
have
good,
dev
and
API
documentation
around
things.
So
I.
A
You
can
expect
that,
probably
in
two
forms,
probably
in
a
more
guided
tour
on
the
octave
dev
website,
but
then
also
as
general
go
doc,
documentation,
BB,
auto-generated
and
the
go
doc.
Documentation
will
be
more
geared
towards
those
who
are
exploring
the
internal
API
and
developing
against
specific
areas
within
there.
A
And
then
the
external
high-level
overview
will
be
a
more
gentle
introduction
for
folks
who
are
just
getting
started
and
kind
of
do
some
high-level
overview
of
octants
and
it's
structures
and
its
runtime
and
just
how
it
all
works
and
fits
together
to
give
folks
a
general
idea
of
what
their
kind
of
the
architecture
and
the
approaches
that
were
used.
That
can
be
helpful
when
you're
just
getting
started
out
on
a
new.
A
D
A
Yeah,
thank
you.
I
definitely
will
be
doing
that.
I'll
probably
try
to
get
something
going
through
that
issue
that
I,
that
I
saw
that
you
created,
and
we
will
just
make
sure
that
we're
communicating
through
that
as
best
as
possible,
and
then
we
can
take
some
time
to
do
some,
some
zoom
meetings
as
well.
Wonderful,
thank
you.
One
of
the
other
things
we're
going
to
be
looking
at
after
ten
is
kind
of
converting,
getting
the
conversion
process
of
getting
hocked
and
moved
to
a
full
application.
A
You
know
things
that
things
that
folks
have
been
asking
for
and
things
that
we've
been
wanting
to
do
around
just
like
the
workflow
and
how
often
starts
up
and
and
how
you
start
using
it
and
and
what
kind
of
the
what
your
first
experience
is
with
it.
All
of
those
are
going
to
be
kind
of
complimentary
to
turning
octant
into
a
full
application.
So
expect
expect
a
lot
of
updates
around
that
as
we
go
forward
with
in
the
community
meetings
and
on
there's
been
some
issues
created
around
as
well.
A
That
will
keep
folks
informed
and
then
one
of
the
other
aspects
of
this
is
the
the
Monaco
editor,
which
is
the
same
editor
that
is
used
in
Visual,
Studio
and
other
tools.
We're
going
to
be
first
doing
an
integration
of
that
as
a
read-only
implementation
for
the
current
yeah
mol
viewer,
and
then
that
is
kind
of
going
to
be
the
starting
point
for
the
smart
editing
that
has
been
discussed
and
there's
issues
on
the
on
the
on
the
github
repo.
For
this,
that
will,
that
will
be
probably
one
of
the
stretch
goals.
A
Hopefully,
we
will
I
think
it
is
likely
it'll
get
in.
There
is
definitely
get
in
there
as
read-only
is
what
I'm
saying,
but
it'll
we'll
see
what
we
what
we
do
after
we
get
the
read
on
the
integration.
If
we're
able
to
get
some
context-sensitive
editing
in
place
and
it
in
the
next
release,
it
will
depend
and
it
will,
it
will
see
it's
basically,
the
answer
we'll
see
so.
A
So
that's
ODOT
after
10
updates.
There
is
a
question
here
that
kind
of
ties
in
to
the
plugins
section
so
providing
cube
context
to
plugins.
This
is
a
question
that
has
been
I.
Think
Josh
asked
this
question
a
while
ago
and
for
those
of
you
that
don't
know
he
authored
the
blood-orange
IO
octant
helm
plugin,
and
it
was
one
of
our
one
of
our
first
public
plugins.
And
so
the
question
here
is
about
the
helm.
C
Okay,
yeah
thanks
I,
yes,
I
just
saw
your
comments
and
edit
that
a
few
minutes
ago
is
there
a
recommendation
then
for
tools
that
are
rendering
in
client
go.
Is
there
any
option
for
them
to
make
calls
through
Clank
Oh,
or
are
they
just
essentially
going
to
have
to
refactor
things
to
use
the
octant
plug-in
API.
A
A
To
by
this
client
like
because
the
new
new
for
config
it
you
passing
this
rest
config
and
you
get
back
this
client
set
and
then
you're
able
to
kind
of
go
through
all
of
the
you
know,
discovery
client
at
the
auth
client
and
all
of
that
stuff
and
I'm
wondering
if
there's
a
way
that
we
we
can
create
it
to
satisfy
that
client
set
interface
for
for
plugin
authors,
so
that
they
can
get
a
client
set
interface.
That
could
then
satisfy
the
needs
of
the.
A
So
then,
instead
of
having
the
vendor
library
call
client
go
directly,
it
could
use
the
one
that's
get
that
gets
passed
in
sure
yeah.
The
problem
with
that
is
I.
Think
most
of
them
like
most
of
them,
have
it's
pretty
deeply
embedded.
It's
like
it's
like
some
setup
function
somewhere
that
calls
that
calls
to
fetch
the
client
and
then
returns
it
out
up
the
stack
and
then
uses
it
internally
and
many
many
libraries
don't
provide
a
way
to
override
where
the
client
comes
from.
C
Know
if
there
was
a
way,
if
there's
a
way
to
do
this,
I
could
work
on
the
home
side
to
to
basically
add
an
option
to
use
that
okay
yeah
right
right
now,
there's
really
not
like
there's
really
not
an
option
for
me
to
delete
helm
releases
without
copying
code
from
helm
and
changing
the
delete
calls
too
often
to
you,
cause,
I.
Think:
okay,
because
yeah
it's
all
kind
of
black
box
behind
a
delete
function
that
finds
the
resources
tied
to
the
helm,
release
and
then
deletes
them.
So.
A
Okay,
yeah
I
think
we
can.
We
can
work
on
this
some
more
and
try
to
and
try
to
get
away
that
we
can.
We
we
we
do
want
folks
to
be
able
to
not
have
to
run
out
of
band
processes
with
their
in
like
go,
find
the
cube,
config
and
then
take
the
subscribe
to
the
context,
change
function
and
then,
when
you
get
the
context,
changed
event
go
into
the
cube,
config
and
fetch
that
context
out
and
make
your
own
client
like.
We
want
to
avoid
books
having
to
do
that.