►
From YouTube: Octant Community Meeting - April 14th, 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
All
right
we're
live
sweet
and
it's
1001,
so
we
can
get
started
hello.
Everyone
welcome
to
the
april
14th
october
community
meeting
time
flies.
We
recently
cut
the
19.00
release.
We
got
a
couple
things
on
the
notes
today
on
hackmd.
If
there
are
any
things
to
add
on
the
agenda
and
or
things
for
open
q,
a
please
feel
free
to
chime
in
and
at
the
same
time,
there's
also
a
youtube
stream.
That's
going
on
simultaneously.
A
So
if
try
to
periodically
look
at
the
chat
to
reply
to
things,
if
anything
comes.
A
A
I
think
we're
going
to
need
a
pass
release,
a
big
one
being
that
when
we
refactor
the
buttons
and
to
be
components,
we
copied
and
pasted
the
existing
monologic
from
the
button
group
templates.
So
there
are
scenarios
in
octet
where,
if
you
click
a
button,
it'll
pop
up
in
two
models
stacked
on
top
of
each
other-
and
we
don't
want
that.
A
But
this
ties
in-
and
I
discovered
this
because
of
some
perfect
work
that
that's
currently
going
on,
but
I
can
talk
about
that
when
we
get
to
the
last
bullet
point
and
the
next
one
is
also
client
state.
This
one
is
specifically
from
a
request
internal
to
vmware,
I
believe
yeah.
So
this
is
a
client
that
uses
a
private
struct.
I'm
going
to
expose
this,
and
I
think
this
is
just
that
testing
thing.
If
I
understand
it
correctly,
yeah
yeah.
C
So
this
is,
it
was.
It
was
discovered
by
a
team,
that's
building
a
plug-in
for
octant,
internally
and
but
yeah.
What
they
found
was
that
their
test
started
failing
as
a
result
of
the
client
state
changes
because
we're
using
internal
structs,
and
they
had
no
way
to
actually
be
able
to
mock
those
out
because
they
couldn't
create
instances
of
that
struct
and
we
weren't
providing
any
interfaces
to
override.
C
So,
ultimately,
you
know
it
was
it
didn't
break
them
from
the
actual
plug
any
plug-in
functionality,
but
we
want
to
make
sure
that
people's
testing
scenarios
are
working
well
in
functioning.
We've
had
similar
things
like
this
in
the
past,
with
the
logger
we
lifted
the
logger
interface
up,
so
that
people
could
knock
it
out
for
testing
purposes.
So
I
think
this
is
just
a
good
candidate
to
to
stick
into
191,
because
it's
a
compatible
change
doesn't
break
anything
and
less
people
write
some
better
tests.
A
A
All
right
cool
then
we'll
move
on.
I
think
it's
probably
not
too
ambitious
to
get
this
out
by
this
week,
so
we
can
do
this
and
this
should
not
change
our
20
release
cycle.
So
nothing
really
changes
here.
Just
two
small
fixes
all
right.
So
next
one
we
said
it
as
in
is
newly
added
as
an
approver.
A
That's
awesome
is
he
on
the
call
right
now?
Maybe
I
can't
tell
from
what
I'm
sharing?
Oh
okay?
Well,
that's.
A
We're
always
looking
to
add
more
approvers.
Looking
you
know,
one
of
the
things
about
an
open
source
project
is
to
have
a
healthy
team
of
maintainers
and
approvers,
and
so
we'd
like
to
be
growing
that
number
over
time
and
so
louise.
A
Thank
you
for
all
your
hard
work
so
far,
and
we're
looking
forward
to
continue
working
with
you
over
the
future
and
additionally,
general
call
out
is
that
if
anyone
is
watching
this
and
likes
to
be
contributing
to
octane
long
term,
there
are
some
guidelines
for
how
to
become
a
maintainer
and
or
how
you'd
like
to
go
from
a
contributor
to
a
maintainer,
and
we
have
the
sponsor
system
where
we
like
to
have
someone.
A
You
pretty
much
have
to
tag
your
sponsors
right.
Sponsors
must
have
close
interactions
with
the
prospective
member,
so
in
other
words,
we'd
like
to
see
some
activity
in
terms
of
code
contributions,
design,
even
docs
like
it,
doesn't
necessarily
have
to
be
engineering
contributions.
A
And
aside
from
that,
once
there
are
enough
people
wants
to
approve,
then
we'll
just
approve.
And
then
you
open
an
issue
against
the
octet
repo
mention
your
sponsor
sponsor,
says:
okay,
and
then
we
get
more
approvers
and
then
I
think
overall
here
the
goal
is
to
keep
increasing
that
number
and
also
to
have
sponsors,
especially
from
non-vmware
companies.
So
you
know
anyone
who's
listening
in
and
thinks
often
might
be
an
interesting
product.
A
Sci
project
definitely
feel
free
to
reach
out,
and
I
think
there
are
a
lot
of
good
opportunities
in
this
problem.
A
Space
cool
any
questions
about
the
how
we
get
new
approvers
maintainers
or
any
additional
questions
or
comments
about
that.
I
think
it's
just
approvers.
C
A
Okay,
approvers,
I
will
use
previous
yeah
because
maintainer
implies
other
admin
powers
on
the
report.
C
So
so,
like
being
able
to
like
push
a
release,
tag,
and
do
things
like
that
are-
are
a
separate
set
of
permissions
over
being
able
to
land
prs
and
merge
commits.
So
I
think
that's
that's.
Why
there's
that
distinction.
A
That
being
said,
I
I
think
there
is
a
end
goal,
or
at
least
not
an
end
goal,
but
like
a
near-term
goal
for
octage
to
have
to
change
that
governance
model.
So
we
definitely
do
want
to
maybe
become
a
cncf
project
or
try
to
have
contributors
come
across
for
like
multiple
companies.
So
it's
not
just
a
strictly
vmware
con
as
you
own
project
as
it
is
currently.
C
Yeah,
so
we,
the
the
the
team,
will
be
hiring
a
community
manager
soon.
I
don't
know
exactly
when
that
that's
currently
in
flight,
and
I
think
I
think
there
might
be
an
open
rock
that
I
can.
C
I
don't
know
if
it's
open
yet,
but
it
will
be
soon
if
it's
not
already
and
we
can
post
it
to
get
people
applying,
but
the
the
goal
there
would
be
to
grow
the
existing
community
on
the
non-vmware
company
side
and
as
as
you
see
from
our
current
community
membership
guidance,
we
only
have
an
approver
defined,
but
that
was
intentional
and
we're
like.
C
Let's
define
one
role
and
then
we'll
grow
those
roles
as
as
the
community
grows,
because
right
now,
there's
not
a
there,
wouldn't
be
a
huge
advantage
to
defining
like
five
or
six
roles,
considering
that
we
don't
have
enough
of
a
community
to
fill
out
those
roles.
So
the
reason
that
that's
kind
of
the
logic
behind
having
this
approval
role,
we
want
to
start
to
fill
that
with
folks
who
are
interested
in
becoming
approvers,
both
other
vmware
folks
and
non-vmware
folks,
and
then
we
would
once
we
have
a
established
base
of
non-vm
vmware
people
contributing.
C
Then
we
can
add
new
roles
that
start
to
add
extended
privileges
and
and
extend
the
way
we
govern
the
project
even
leading
into
us,
having
like
an
official
governance
model
if
necessary.
You
know,
as
sam
mentioned,
if
we
go
the
foundation
route
or
something
like
that,
so
yeah,
all
that
stuff's
just
in
flight
and
we're
working
on
it
and
encourage
folks
to
to
join
us
and
help
us
build
something
really
cool.
B
A
On
cool
alrighty
and
let's
move
on
to
the
next
one,
so
homebrew
this
one's
kind
of
embarrassing,
it's
a
bit
of
my
fault,
so
homebrew,
I
believe
since
0.17.
A
If
I
yeah
on
the
other
17
release,
when
we
migrated
to
go
116,
we
were
able
to
use
the
new
embed
feature,
and
that
was
super
nice,
because
it
let
us
cut
out
some
of
the
acid.
Embedding
libraries
and
we
can
just
use,
go
now
and
it
changed
a
few
things,
namely
in
the
pipeline,
and
we
fixed
all
those
and
we
fixed
some
of
the
ci
and
release
issues.
A
But
the
homebrew
formula
slipped
my
mind,
and
so
the
tests
were
failing
on
the
homebrew
formula
and
they
just
kind
of
sat
there
across
two
releases,
because
I
wasn't
aware
of
it
since
they
are
automatic
these
days.
A
That
being
said,
for
this
release
about
20,
we
will
have
a
brew
tap
for
electron
releases
and
brewtap
is
essentially
just
a
you
github
url
that
you
can
kind
of
add
attack
to
your
homebrew
you'd
like
on
the
command
line
and
don't
know
to
pull
from
specifically
that
you're
also
like
kind
of
like
a
ppa
for
ubuntu,
or
I
guess
I
don't
know
or
something
I
don't
know
not
with
some
other
package
manager.
A
But
the
idea
here
is
that
we
will
have
a
separate
repo
that
will
have
this
brew
tap
and
we'll
have
the
instructions
to
do
it
and
we're
going
to
start
pushing
the
installation
step
for
the
electron
release,
because
the
plan
at
1.0
is
to
stop
actively
maintaining
the
binary
web
server
model,
which
we
currently
still
have
and
will
continue
to
ship.
But
just
note
that
long-term
support
for
that
might
not
exist
after
1.0.
C
C
We
want
to
move
away
from
publishing
that
artifact,
that
and
and
only
be
publishing
electron
releases,
so
folks,
who
ultimately
want
to
do
custom,
uis
or
build
things
on
top
of
that
back
end
service
will
be
pinning
and
building
from
a
source
like
they'll
have
to
build
from
source
to
get
that
to
get
that
asset.
A
Cool
and
I-
and
we
can
definitely
just
like
talk
about
how
that
would
look
and
even
like
hypothetically,
even
that,
like
the
nightly
still
going.
Definitely
I
don't
see
that
they're
pretty
low
overhead
at
this
point,
but
if
someone
has
strong
opinions
about
what
you
know
about
what
this
might
should
look
like
definitely
call
this
out.
A
Cool
right
and
last
bullet
point
fully
moving
to
clarity,
five,
so
this
one's
kind
of
interesting,
we
did
move
to
clarity.
Five,
I
think,
last
release.
I
believe
that
might
be
the
release
before
that
they're
starting
to
blur
together
we're
re-adopting
the
two-week
cadence,
and
sometimes
I
can't
tell
the
previous
release
the
one
before
that.
But
we
are
using
clarity.
Five
and
one
interesting
thing
about
clarity.
A
Five
is
that
they
currently
have
a
set
of
angular
components,
but
they
also
introduce
a
sort
of
another
class
of
web
components
called
clarity
core,
and
there
is
some
overlap
between
these
clarity,
core
components
and
these
angular
components
like,
for
example,
like
icons,
forms
modals
like
very
commonly
used,
ui
components
and
the
road
map
for
this
is
interesting
because
they
the
project,
maintainers
and
clarity.
A
A
And
so
what
this
means
for
us
is
that
we
can
still
keep
using
these
angular
components,
which
we
do
pretty
much
everywhere
and
often,
but
they
will
no
longer
have
any
additional
support.
So
what
this
means
is
like,
if
clarity
has
an
update,
let's
say
they
update
their
icons
and
they
release
like
a
new
set
of
icons.
A
We
would
not
be
able
to
use
those
unless
we
move
over
to
those
clarity,
core
icons,
so
there's
a
lot
of
strategic
advantages
to
finish
this
adoption
of
clarity,
five
right,
it's
not
just
pinning
to
the
next
dependency.
A
We
are
going
to
have
to
update
the
vast
majority
of
our
components,
to
use
these
angular
components
wherever
or
use
these
core
components
wherever
possible,
there
are
going
to
be
a
few
places
where
we
will
still
have
to
use
these
angular
components,
but
I
think
overall,
like
long
like
long
term.
We
want
to
be
on
this
side
of
the
equation
here,
just
simply
because,
sooner
or
later,
we're
going
to
have
to
do
it
and
it's
probably
easier
to
do
it.
Now
they
talk
about
their
support
strategy.
A
What's
next-
and
there
are
caveats
to
this
as
well
like,
for
example,
if
some
of
our
like
you
know
like
moving
to
these
core
components,
will
definitely
break
styling
and
css
in
certain
places.
So
and
of
course
it
will
change
the
ui
somewhat
as
well,
and
because
these
are
web
components,
they
will
introduce
shadow
dom
and
those
are
somewhat
difficult
to
style.
A
If
we
don't,
if
they're,
not
if
they're,
not
quite
styled
kind
of
the
way
we're
used
to
so
we
might
have
to
make
some
compromises
in
the
ui
as
well,
but
by
both,
like
even
by
compromises,
I
just
mean,
like
things,
will
look
different,
not
not
necessarily
that
it's
worse,
so
it'll
it'll
be
some
work,
so
there
we
probably
should
make
a
bunch
of
issues
stemming
from
this
move,
and
this
is
also
probably
a
pretty
good
spot
for
a
lot
of
first-time
contributors
as
well.
A
If
us
people
are
interested
in
doing
some
of
this
move
as
well,
it'll
give
a
good
introduction
to
what
clarity
is
and
what
component
architecture
might
look
like.
So
that's
that
in
a
nutshell,.
E
Yeah
any
questions
yeah,
I
I
think
the
important
note
here
is
that
you
know
some
components
will
probably
never
be
part
of
the
cds
core
right,
like
a
data
grid
and
some
complex
components,
so
so
we're
gonna
have
angular
pretty
much
with
us.
I,
as
at
least
for
a
long
time
so
and
and
as
as
for
the
option.
I
think
we
need
to
start
that,
but
I
think
they're
still
fixing
some
issues,
especially
compatibility
issues
and
differences
in
our
layout.
Look
and
things
like
that.
E
So
I
would
caution
of
us
going
a
little
too
fast
on
this.
Maybe
it's
better
to
wait
a
little
bit
on
some
components
that
are
maybe
even
broken
at
this
point
or
looking
differently
or
hard
to
to
you
know
move
over
to.
Maybe
you
can
postpone
those
those
a
little
bit
but
yeah.
I
think
it's
definitely
created
yet
to
start
that
result.
A
Yeah
and
I
would
even
go
as
far
to
say,
this
is
a
perfect
situation
to
get
that
feedback
for
the
clarity
people
right
like.
If
something
is
hard
and
to
do
in
clarity,
five,
they
I'm
pretty
sure
they'd
be
interested
in
doing
it
too.
So
we
could
definitely
take
this
like,
depending
on
what
people's
bandwidths
look
like
right
now,
we
could
definitely
wait.
Wait
till
someone
else
figures
it
out.
We
could
be
very
active
or
passive
in
this
depending
on
how
how
we
want
to
take
it
but
yeah.
I
totally
agree.
A
Some
of
the
stuff
is
a
headache.
I've
already
started
looking
at
what
that
might
what
that
actually
means
and
yeah.
There
are
definitely
more
than
one
place
that
just
you
know
either
the
ape
the
documentation's
not
up
to
date
or
if
things
look
kind
of
weird-
and
I
don't
quite
know
like
if
it's
a
css
thing
or
web
component
thing,
so
there
yeah
so
like
definitely
like
where
we
shouldn't.
A
We
shouldn't
take
this
to
an.
D
Yeah
no,
that
question,
but
I
would
like
to
show
you
what
I'm
working
on
like.
I
did
a
sneak
peek
of
the
refactor
of
the
bottoms.
Now
that
you
mentioned
the
the
move
from
to
clarity
5,
these
were
milan.
Just
for
you
know,
I'm
trying
to
do
the
immigration
from
the
buttons
we
had
to
the
new
clarity
buttons
from
prioritify
doing
and
working
with
the
the
core.
D
So
I'm
gonna
share
my
screen,
and
I
want
to
to
ask
you
a
couple
of
questions.
So,
for
example,
here
you
can
see
like
the
different
styles
that
aren't
working.
For
example,
we
have
status,
we
can
have
like
success
info
danger,
the
disabled.
We
can
have
styles
like
outline,
solid
or
flat
things
like
that.
D
Part
of
this
is
because
we
have
like
our
default
button
from
for
optin
is.
This
type
is
like
outline
and
with
the
size
smaller,
and
this
is
actually
the
default
button
from
clarity
that
is
filled
a
little
bigger.
So
I
want
to
ask
you
guys
and
the
community
if
we
want
to
keep
like
this
as
our
default
bottom
or
we
want
to
move
to
this
one.
So
we
would
like
more
consistent
with
clarity.
What
do
you
guys
think.
E
C
Yeah
I
mean,
I
think,
the
size
I
think,
there's
there's
two
there's
two
ways
to
approach
it.
We
could,
we
could
have.
We
could
add
a
size
value
similar
to
what
we
have
for
icons,
which
lets
you
increase
the
size
of
your
button
arbitrarily,
but
I
think
our
default
size
should
just
should
stay
the
same
as
it
is
now
so
for
this
change
I
would.
C
I
would
keep
the
default
size
and
leave
things
as
is,
and
then,
if
we
get
a
request
for
somebody
saying
we
would
really
like
to
be
able
to
make
gigantic
buttons
or
really
tiny
buttons
or
whatever.
Then
we
can
extend
the
config
to
support
various
sizes
like
for
icons.
D
Yeah,
I
agree
totally
so
yeah.
As
I
said,
this
is
a
sneak
peek.
I
would
like
to
do
a
demo
the
next
week,
once
this
vr
is
merged,
to
explain
how
it
works,
because
now
we
can
have
combinations
of
styles,
for
example.
This
is
a
success
button
with
an
outline,
so
the
community
have
like
more
possibilities
of
styling
their
blueprints.
A
Yeah,
I
wonder
how
octets
would
stack
like
I
know
it
gets.
It
uses
clarity,
so
it's
already
probably
pretty
decent.
A
I
wonder
how
it
would
stack
up
in
an
accessibility
audit,
whether
or
not
we're
using
some
of
these
clarity
components
and
the
way
they
were
intended
to
be
used
because,
as
far
as
I
know,
no
one
actually
actively
checks
for
that
stuff
right
and
we
just
kind
of
added
we
kind
of
shim
in
a
couple
of
features
that
make
it
more
usable
for
screen
readers
and
such,
but
things
like
whether
or
not
our
default
button
sizes
are
large
enough
or
whether
or
not
it's
adjustable.
A
Although
we
can
eventually
add
like
also
like,
I
guess
like
like
electron
wide
integrations,
like
preference
type
integrations
where
we
can
like
make
all
of
octan
like
make
all
of
the
buttons
look
a
certain
way
or
make
all
of
the
fonts
look
slightly
differently
or
change.
Spacing.
I
think
that's
in
the
near
future,
so
maybe
yeah.
So
then.
Maybe
it's
a
long
wider
way
of
saying
things
are
okay,
exactly
the
way
they
are
now,
because,
even
if
someone's,
not
okay,
we're
going
to
give
the
tools
to
change
it
anyways,
I
I
did
some.
E
E
For
example,
one
of
them
is
navigation.
I
think
the
font
is
a
little
too
small
on
the
navigation,
but
most
of
the
most
of
the
things
are
pretty
good,
and
since
we
we
don't
require
compliance
right
now,
didn't
we
didn't
do
much
work
there.
One
thing
about
components
is
storybook
has
a
plugin
that
does
that
testing
for
you
automatically.
E
So
basically
you
can
edit
it
it's
like
additional
panel
right
for
the
knobs,
for
example.
Now,
so
you
could,
if
you
add
that
a
plugin,
it
will
test
accessibility
for
your
component,
basically
and
tell
you
all
the
all
the
problems
right
there.
So
I
think
that
might
be
something
I
should
probably
add
sooner
rather
than
later,
just
to
at
least
make
so
make
this
a
beer.
But
you
know
there
might
be
a
few
things
that
we
need
to
work
on.
A
Yeah
totally
feel
free
to
capture
some
of
the
stuff.
Also
on
the
get
at
issue,
we
can
definitely
add
it
to
a
sprint
as
part
of
a
regular
workload.
E
A
Cool
there
there's
nothing
else.
I
think
we
can
call
it
and
we'll
get
some
time
back
for
the
day.
A
All
right,
thanks
for
coming
out
y'all,
take
care.