►
From YouTube: Octant Community Meeting - June 9th, 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
are
live
on
youtube:
okay,
cool
hello.
Everyone
welcome
to
the
auction
community
meeting.
It
is
june,
9th
2021.
This
is
exciting
time.
It
is
starting
to
get
really
warm
and
the
sun
is
bright.
So,
let's
get
this
community
meeting
over
with
and
we
can
go
and
go
outside,
hopefully
all
right.
So
before
we
get
started
here.
Let
me
do
something
like
well.
Actually
this
is
fine
yeah.
Let
me
go
and
start
sharing
the
agenda.
A
Five
items
and
then
we've
got
a
sixth
one,
an
open
q,
a
which
we
will
get
to
so
we
let's
get
started
so
the
first
one
is
gonna,
be
about
the
release
and
a
lot
of
y'all
might
be
realizing:
hey
where's,
that
release
we've
been
saying:
we're
gonna
release
for
the
last
week
and
a
half,
and
so
just
to
give
an
update
for
everybody.
We
do
keep
the
release,
dates
on
the
board
here
and
we've
bumped
it
out
again
because
well,
six
ten,
but
anyway
it
is
currently
pending.
A
Two
pr's
we
wanna
get
these
two
merged
in
it's
one
is
the
streaming
interface
for
client
and
the
object
start
functional
option,
and
these
are
generally
not
going
to
be
impactful
to
anyone
who's,
not
working
at
vmware.
These
are
mainly
for
internal
things.
Currently
in
a
lot
of
projects
internally,
vmware
that
might
be
using
often
they
implement
their
own
streaming.
They
essentially
they
want
octane
to
be
a
websocket
manager
and
they
want
to
use
their
own
object
store.
A
So
this
is
just
to
get
them
off
using
forks
and
so
we're
waiting
for
these
to
be
merged,
but
if
they
don't
get
merged
in
a
timely
manner,
I
think
we
can
still
go
ahead
and
patch
and
adopt
one
simply
because
I
think
it's
not
worth
delaying
days
and
days
over
on
this
yeah.
So
essentially,
if
we
can't
get
these
merged
in
and
have
a
release
ready
state
by
the
end
of
the
day,
we're
just
going
to
cut
anyways
cool.
A
Any
questions.
Comments
concerns
no
okay,
straightforward,
we'll
move
on.
So
next
one
is
following
from
last
week,
we
talked
a
little
bit
about
whether
or
not
component
actions
should
be
a
thing
and
we
were
like.
Does
anyone
even
use
this?
And
you
know
a
week
later,
someone
files
an
issue
saying
it
doesn't
work
so
granted.
A
The
bug
was
already
fixed
by
the
time
this
issue
was
reported,
so
it
turns
out
that
people
do
use
this
feature,
and
I've
actually
talked
to
some
other
folks
at
vmware
who
are
building
plugins
around
this
pattern.
So
if
we
do
choose
to
make
this
go
away,
it's
not
just
ripping
the
band-aid
off
it.
It
will
involve
some
diplomacy,
so
that's
gonna,
be
that's
gonna,
be
something
to
think
about,
as
we
just
continue
to
decide.
A
If
we
ever
do
want
to
remove
this,
and
maybe
we
don't
think
we
just
leave
it
alone.
So
the
issue
is
two
five
for
one
for
anyone
who
might
be
interested
in
seeing
this
development.
A
One
all
right
and
for
anyone
who
wants
to
follow
up
on
this
or
has
a
strong
opinion
or
say
if
they
are
using
this,
please
do
call
this
stuff
out,
just
simply
because
it's
issues
like
these
that
ultimately
have
the
decision-making
power
behind
what
what
we
think
and
versus
what
we
do
all
right.
So
next
item
on
the
agenda
is
going
to
be
the
migration
to
node,
16
and
npm-7.
A
So
this
one
has
a
little
bit
of
context
to
it.
We
used
to
have
a
ton
of
ci
flakes
that
is
captured
in
this
essentially
like
this
error,
callback,
type
of
errors,
and
it's
very
cryptic.
If
you,
google,
for
the
specific
error,
it'll
say
like
there's,
even
a
doc
on
this
from
the
npm
folks
that
actually
talk
about
what
this
error
message
means
and
short
answer
in
this
paragraph
it
does,
it
could
mean
a
whole
bunch
of
different
things.
A
Anything
from
your
cash
is
invalid
to
just
upgrade
your
stuff,
and
so
the
prevailing
sentiment
here
is
to
upgrade
the
latest
version
of
npm
from
this
one
and
really
what
ended
up
happening
was
that
we
want
to
make
this
upgrade,
but
it
turns
out
the
move
from
npm
14
to
any
of
the
newer
or
I
guess
let
me
take
a
step
back,
so
you
can
technically
just
install
a
newer
version
of
npm,
but
because
we're
using
node
14,
it
uses
npm
six,
and
if
we
wanted
to
do
that
in
a
ci
environment,
we
could
force
an
upgrade
right.
A
We
could
just
do
like
vm
install
latest
or
whatever
version
pinned,
but
then
we
just
have
more
hacks
layered
on
top,
so
the
move
that
I
think
that
was
ultimately
decided
on
was
to
move
over
to
endnote
16,
which
ships
with
npm
7
by
default.
A
Now
the
problem
with
that
is
they
change
how
lock
files
work
specifically
with
pure
dependencies,
and
this
causes
problems
with
how
often
as
a
project
manager
dependencies
since
technically
octane
is
a
model
repo.
It
has
the
npm
components,
or
I
guess
it
has
the
it-
has
the
dependencies
from
what
is
needed
to
build
octant,
but
also
storybook
and
other
various.
I
think
also
like
the
testing
dev
dependencies,
so
it
all
just
ends
up
being
this
giant.
The
massive
dependency
file
that
is,
that
doesn't
migrate
to
the
new
lock
file
easily.
A
So
what
ends
up
happening
here
is
that,
even
though
we
technically
use
node
16
to
run
in
the
ci
environment,
you
can
still
use
the
older
node
versions
and
eventually
we
will
use
this
new,
lock
file,
2.0,
that
they
use
in
note
16,
but
we're
just
waiting
for
stuff
like
storybook
and
angular
to
catch
up.
A
That's
kind
of
it
for
this
one
and
it
from
the
week
that
we've
merged
this
and
looks
like
this
type
of
error
has
gone
away.
So
I'd
say
it
was
successful.
The
probably
there
are
still
some
flakes.
Although
less
prevalent
one
point
of
failure
being
this
upload,
artifact
action
occasionally
fails.
So
you
can't
assume
that
the
internet
connection
on
on
github
actions
is
always
perfect
and
of
course
we
have
the
nash
runner
test.
A
So
this
was
mentioned
a
long
time
ago,
but
our
dash
runners
technically
would
fail
if
you
enable
the
race
detector
and
go
to
run
these
tests.
So
this
is
something
that
we
will
definitely
want
to
fix
over
time.
But
for
now
at
least
the
ci
environment
is
less
annoying
the
to
do
is
we
can
now
hopefully
re-add
the
npm
cache
and
maybe
take
some
decrease,
ci
runtime
and
just
save
github
a
little
bit
of
bandwidth.
B
A
I'm
happy
so,
let's
move
on
to
the
next
one
I'll
try
to
keep
this
short,
so
this
one
is
going
to
be
about
awesome
and
I.
C
A
I
have
this
one
somewhat
called
up,
but
essentially
we
rewrote
the
dynamic
cache
to
use
namespace
and
formers
instead
of
the
old
one,
and
this
allows
octan
to
play
better
in
our
back
restricted
environments,
and
I
was
originally
going
to
demo
this
tanzu
developer
center.
They
have
a
lab
that
uses
octan
and
they've
upgraded
this
fairly
recently,
so
they
might
have
even
had
a
fork
and
rebased
over
the
patch,
I'm
not
sure,
but
but
the
core
idea
is
there.
A
So
if
you
have
something
like
an
environment
that
doesn't
let
you
do
something
like
get
deploy
well,
this
gets
lets.
You
get
a
deployment
in
this
particular
name
space.
But
if
you
do
something
like
all
name
spaces,
it
will
say
no
and
probably
something
like
cluster
scope
like
persistent
volume.
No,
they
get
crds
right.
So
there's
a
lot
of
things
that
you
can't
get
in
this
particular
restricted
our
back
environment
and
of
course
I
would
actually
show
you
that.
A
Well,
the
old,
the
old
lab
wouldn't
load
anything,
but
I
think
they
changed
something
about
this
environment
on
there
and
to
allow
it
to
work
now.
But
if
you
do
something
like,
let
me
actually
pull
this
binary
off
the
nightly
curl.
A
Often,
let's
download
this
new
thing
and
then
I
think
it's
like
supervised
visor
ctl,
stop
octant.
Let's
stop
there
octant
and
then
we'll
use
ours,
h,
mod
plus
x,
octane,
and
then
what
is
their
thing
to
run?
They
have
a
they
have
a
command
because
you
have
to
enable
a
bunch
of
random
variables,
but
let's
say
we
have
their
command
notice.
A
How
here
we
actually
show
okay,
we
can't
list
crds
again
right,
but
now
this
is
a
warning
and
as
a
result,
we
should
be
able
to
start
seeing
some
interesting
things
on
the
screen.
At
the
very
least.
So
now
we
see
our
secret
service
accounts
role
bindings
and
I
think
if
we
just
apply
the
lab,
it
will
show
us
okay,
client
database
and
now
our
deployments
and
other
things
or
whatnot
is
going
to
show
up.
A
So
that's
kind
of
cool,
and
you
know
you
can
go
to
our
deployments
and
we
can
kick
off
and
do
interesting
things.
But
if
we
do
something
like
custom
resource
definitions,
nothing
will
show
up
because
it
does
not
allow
so
that's
kind
of
how
it
works
in
a
nutshell.
So,
for
those
who
are
interested
in
learning
playing
around
with
this
slab,
I
left
a
link
in
this
environment
yeah.
A
I
left
the
link
here,
so
it's
still
going
to
be
using
the
old
octane,
but
keep
your
eyes
out
we're
hopefully
going
to
be
updated,
a
newer
version
of
octane
soup,
my
audio
just
cut
out.
So
let
me
go
back
to
my
put
it
there.
We
go
cool
any
questions
about
this.
One.
B
I
have
a
comment
about
previous
month
story.
I
I
had
some
microphone
issues
just
about
the
migration.
To
note
16.
I
mean
that
that's
also
really
huge
problem
that
we
had
for
a
long
time,
and
you
know
it
was
a
hard
problem
too.
So,
thank
you,
sam
for
working
diligently.
On
that
I
know
it's.
It's
been
a
pain
here.
A
B
So
you
know
thank
you
for,
for
you
know,
being
persistent
and
getting
this
one
to
get,
and
I
know
it
was
a
really
hard
problem.
It
was
took
a
long
time
to
figure
out
what's
the
proper
solution
and
it's
been
a
huge
pain.
You
know
just
looking
in
those
failures.
B
I
I
think
at
some
point
that
for
me
at
least
it
was
like
50
chance
of
failure,
build
which
dramatically
slows
down
the
workflow
and
stuff
like
that.
So
so
it's
great
to
see
those
pipelines
green
all
the
time.
Now,
honestly.
So,
thank
you
so
much
for
that.
That's
huge
deal,
for
you
know,
developer
productivity
and
I
think
at
some
point
we
should
definitely
switch
to
mpn7
to
do
the
new
format
new
new.
B
What's
the
right
name,
new
way
the
the
dependencies
attract,
but
I
think
angular
is
right
now
the
the
limiting
factor,
I
thinking
once
angular
switches
to
that
we
should
be
able
to
it's.
Like
you
know,
cards
falling
apart
and-
and
you
know
once
one
singular
goes
on.
Hopefully,
clarity
will
work
with
that
angular
version
too,
and
we
at
some
point
I'm
hoping
that
that
will
help
us
with
some
other
issues
we
are
having,
like.
B
A
Yeah
totally-
and
we
can
definitely
keep
capturing
like
what's
hard
about
this,
simply
because
if
we
go
into
our
web,
let's
see
package
dot
json,
we
can
see.
We
even
have
stuff
like
react
right
like
like
this
is
a
by
no
means
like
a
small
project,
and
the
only
reason
we
need
react
is
the
storybook,
and
then
we
also
have
like
there
there's
even
a
case,
a
strong
case
that
one
could
make
that
we
should
break
apart
from
the
monorepo
for
for
because
of
this
lock
file
starting
to
get
too
complicated.
B
A
Great
cool.
Well,
that's
yeah!
I
don't
know
if
I
missed
anything
my
audio
cut
out
there
like
midway.
Did
anyone
leave
a
comment
for
some
of
the
other
points
that
I
might
have
skipped
over.
D
A
Yeah,
linux
and
bluetooth
classic
all
right
resource
viewer
grouping
preview.
I
so
I'm
gonna
hand
it
off
to
you
then.
B
B
Okay,
so
here
I
have
a
this-
is
a
octane
running
as
a
app
inside
the
electron
and
on
the
right
side.
I
have
a
browser
with
the
latest
code,
and
this
is,
I
think
this
is
20..
B
Yes,
so
it's
a
release,
0
20.,
so
a
problem
we
have
with
the
resource
viewer
is
a
lot
of
resources,
especially
custom
resources
have
very
complex
diagrams,
like
this
one,
and
when
you
open
this
one,
it's
really
hard
to
to
see.
What's
going
on
there,
it's
a
basically
so
the
the
route
I
took
is
just
to
detective.
If
there
is
a
multiple
objects,
multiple
resources
of
the
same
kind,
just
to
display
them
as
a
one
box
and
to
make
them
expandable
to
show
the
details.
B
A
It
yeah,
if
I
recall
correctly,
it's
like
if
you
want
to
if
you
have
like
the
too
many
open
files
error,
I
forgot
how
to
see
how
many
are
currently
open.
But
let's
say
you
limit
or
something
where
you
can
bump
it
up
to
some
arbitrarily
large
number.
B
B
So
yeah
so,
instead
of
let
me
bring
this
to
so,
instead
of
showing
all
those
in
this
case,
there's
three
machines:
there's
a
cube,
admin,
configs
and
gcp
machines.
B
B
So
that
is
in
in
a
sense
how
this
is
probably
going
to
work,
I'm
still
investigating
other
means
of
grouping,
not
only
by
kind,
because
if
you,
if
you
look
at
different
into
this
you'll
notice,
that
there
are
some
clusters,
so
you
know
maybe
those
clusters
can
be.
Maybe
we
can
group
based
on
number
of
connections,
so
objects
that
have
many
connections
can
can
be
collapsed
and
then
expanded.
So
that's
another
way
of
doing
it.
B
D
I
think
it's
a
great
simplification.
Definitely
it
is
useful
to
collapse,
objects
into
something,
that's
a
little
bit
more
readable.
My
only
comment
would
be
that
that
that
collapse
mechanism
might
be
a
little
bit
small
to
be
identified
right.
That
would
be
the
only
thing
but
yeah,
but
I
like
it
a
lot.
It
definitely
makes
more
sense.
B
B
C
F
Yeah,
I
really
like
that.
Actually,
as
today
I
was
using
the
resource
vrm
cluster
api
as
well,
and
it
was
very
difficult
in
that
view,
right
there,
which
was
cluster
api,
is
great.
I
think
it
would
make
it
much
easier,
especially
for
that
use
case.
It
already
makes
it
much
easier
where
you
can
have
huge
amounts.
I
was
looking
to
data
cluster
with
400
machines
under
a
machine
deployment
and
the
resource
viewer.
F
B
F
Yeah,
no,
it
definitely
looks
great
on
my
side.
G
Awesome
yeah.
This
looks
really
nice
milan,
I
think,
for.
G
I
would
like
to
see
some
type
of
a
different
color
scheme
for
collapse
that
represents
kind
of
the
almost
like
the
the
the
health
or
the
status
as
a
collection,
so
instead
of
like,
instead
of
just
like,
maybe
similar
to
what
we
do
for
the
pods
when
we
show
their
individual
health
statuses
like
showing
some
type
of
artifact
like
that,
when
it's
collapsed
and
then
when
you
highlight
a
collapsed
node,
it
would
be
nice
to
have.
G
I
think
we
want
to
determine
what
what
is
the
summary
of
a
collapsed
node
like
like
a
collapsed
group
that
ends
up
being
useful
right,
because
just
just
writing
everything
out
in
a
big
long
list
in
the
object
status
ultimately
will
produce
the
same
problem
as
text
instead
of
as
a
graph
so
trying
to,
I
think,
some
just
off
the
top
of
my
head,
something
like
the
most
recent
set
of
like
error
events
or
warning
events
across
all
of
the
objects
that
that
are
in
that
grouping.
G
Or
some
I
mean
I
don't
know
exactly
what
it
would
be
yet.
But
some
useful
thing
to
say,
like
I
click
on
this
group,
like
I
look
at
the
grouping,
all
I
see
are
green
dots,
so
I
so
I
can
ignore
it
or
it
doesn't
have
any
dots,
because
it's
config
or
something
that
doesn't
really
have
status
to
it.
Or
I
look
at
the
group.
G
It's
green
dots
and
a
red
dot,
and
I
click
on
it
and
what
I
see
is
the
overall
status
and
then
like
a
link
to
the
unhealthy
one
or
something
like
that,
something
to
make
it
fast
to
like
take
it,
take
it
from
condensing
the
information
but
then
making
that
condensed,
information
now
useful
and
actionable.
I
think
it's
just
the
next
step
for
this,
but
so
far
this
is.
This
is
definitely
on.
B
The
right
track,
yeah,
absolutely
absolutely,
and
I
I've
been
thinking
you
know
the
one
thing
I
was
thinking.
If
this
is
collapsed,
maybe
we
can
just
list
the
pods
that
would
be
or
maybe
show
them
as
a
as
you
said,
as
a
as
like
a
tiny
hexagons
like
like
we
do
in
other
views,
so
like
a
bunch
of
those
small
dots
basically
and
give
summary
errors,
and
things
like
that.
I
think.
B
So
maybe
something
like
that,
I
think
this
is
really
important
for
diagnostics
and
troubleshooting
just
to
show
last
event
and
if
you
can
expand
that
to
the
whole
group,
that
would
be
even
better.
I.
B
Think
so,
cool
yeah.
Thank
you
so
much
for
all
the
comments
and
I
think
car
of
it
when
you
said
it,
it
should
be
a
little
more
discoverable.
I
think
you're
absolutely
right
and
I
think
you're
thinking
about
you
know
this
not
showing
up.
So
maybe
this
plus
sign
should
always
be
there.
It
should
be
a
little
better.
Currently,
it
doesn't
scale
well
as
well,
and
it's
so
I'll
I'll
be
improving
that
as
well.
B
G
Also
scott,
as
someone
who's
using
it
against
a
large
set
of
resources
with
cluster
api,
if
you
have
any
thoughts
on
like
what
type
of
summary
information
for
one
of
those
collections,
that
would
that
you'd
like
to
see
surfaced.
Please
yeah!
You
know
how
to
talk
to
us,
but
yeah,
slack,
channel
or
github
or
wherever.
Just
let
us
know
what
you
what
you
run
into
as
you're
using
it
that
you
think
might
be
helpful.
F
Yeah
definitely
I
will
give
some
thought
into
that,
and
especially
on
the
cluster
api
side,
where
I
have
a
bit
more
experience
with
the
larger
skill
things
I
will,
you
know,
send
something
out
on
slack
with
some
ideas
that
I
have
for
that.
That
would
be
awesome.
F
F
A
Cool
thanks
for
sharing
milan.
That's
awesome!
That's
why
vmware
pc
the
big
books
all
right!
So,
let's
see
well.
There
are
no
more
comments
on
resource
viewer,
we'll
move
on
to
open
q
a
so
we
got
one
q,
a
from
maybe
liam,
I'm
gonna
guess
it's
theo,
maybe
yep
it
was
me
yeah,
so,
okay,
so
injecting
custom
css
for
plugins
in
the
shadow,
dom
question
mark
yeah,
so
I'll.
Let
you
take
it
away.
H
Yeah
so
basically,
I've
been
working
on
some
plugins
recently
and
I
tried
to
fiddle
around
with
some
of
the
formatting
to
get
a
few
buttons
a
bit
more
spaced
apart,
and
this
was
despite
using
the
button
group
where
it
seems
like
there
are
also
like
a
few
side
bugs
there
and
I
figured
it
might
be
worth
investigating
whether
it
would
be
possible
or
worthwhile
to
add
the
ability
for
plugins
to
inject
their
own
css
for
their
components
at
like
a
plug-in
level.
H
So,
basically,
an
idea
I
had
is
that
there
would
be
somewhere
where
you
could
either
like
you
know,
include
like
a
css
file
or
just
like
a
string
of
like
css
styling,
and
then
that
would
automatically
be
applied
to
whatever
is
like
the
styles
in
the
css
file
or
string
will
be
applied
to
the
view
in
the
the
plugin
tab
for
the
specific
plugin.
H
Clarity
will
release
some
kind
of
component
and
then
we
will
import
that
clarity
component
into
octant,
and
then
we
will
make
a
few
modifications
for
it
to
be
available
as
a
plug-in,
so
it
will
take
a
while
for
those
changes
to
go
through
and
especially,
if
you're
using,
let's
say
the
the
typescript
plug-in
library
that
would
have
to
be
updated
as
well
to
to
reflect
the
new
changes
so
being
able
to
just
customize
things
yourself
without
having
to
make
a
fork
would
be
really
easy
and
convenient.
H
And
I
think
there
are
like
a
lot
of
additional
things.
You
could
do
in
a
plug-in
just
by
being
able
to
change
a
few
styles
around.
So
I
I
figured
I'd,
bring
it
up
here,
because
I
wanted
to
see
what
people
thought
about.
B
It
I
I
like
that
idea,
and
it
kind
of
goes
together
with
teaming
right.
B
So
maybe
we
can
start
exposing
theme
more
inside
the
plugins
and
you
know
start
start
there
and
after
we
do
that,
maybe
we
can
just
focus
on
on
a
like
a
smaller
objects
like
if
you
let's
say
you
want
to
override
some
properties
of
cards
and
apply
css
there
directly.
So
it
might
be
a
good
idea
to
to
play
with
it.
I
know
there's
some
quirks
with
the
with
the
shadow
dom
and
angular,
but
if,
if,
if
it's
feasible
or
definitely
something
we
should
explore,
I
think.
G
Yeah,
I
I
agree.
I
think
I
like
the
idea-
I
think
it's
I
know
theming
is
something
that
we've
kind
of
had
long
outstanding
as
an
issue.
I
can't
remember
if
it's
called
theming
but
there's
been
some.
I
I
can't
remember
the
exact
name
of
the
issue
off
the
top
of
my
head,
but
I
know
there's
been
issues
around
like
being
able
to
provide
a
custom
icon
being
able
to
override,
like
just
generally
they're
like.
G
Oh,
we
want
to
be
able
to
extend
this
component
override
this
component
and
some
of
those
things
ultimately
end
up
being
styling
changes
that
get
baked
into
the
component
itself.
I
think
lifting
some
of
that
style
out
into
a
predefined
set
of
overrides
that
we
allow
and
then
allowing
plug-in
authors
to
essentially
ship
a
css
like
a
css
set
of
overrides.
G
That
would
then
be
used
in
the
shadow.
Dom
would,
I
think,
provide
that
bridge
of
being
able
to
keep
control
over
the
overall
look
and
feel
of
any
plug-in
within
octane,
but
still
providing
plug-in
authors,
the
freedom
to
customize
and
and
make
things
a
little
more
tailored
to
their
use
cases,
but
without
being
like
here
just
go,
apply
any
css.
You
want
and
wild
west
it
so
yeah.
I
like.
I
like
the
idea.
D
Yeah,
I
did,
I
would
say,
we've
also
called
it
branding
before.
I
don't
know
if
you'd
see
it
as
an
issue
called
branding
but
yeah,
the
problem
has
always
been
the
wild
west
nature
of
it.
People
can
do
some
pretty
terrible
things
when
they're
allowed
free
reign
with
css,
so
there's
always
the
danger
of
just
making
the
application
not
unusable,
but
highly
inaccessible,
so
being
able
to
pare
down
kind
of
what
we.
D
What
what
is
themeable,
that's,
not
a
word,
but
anyway,
you
know
what
what
is
excuse
me
able
to
be
changed
and
what
isn't
but
yeah
it's
it's
a
great
feature
to
have
for.
D
B
And
I
absolutely
agree-
I
mean
it's,
it's
a
the.
The
biggest
problem
is
just
the
scope
right
because
with
css
you
can
target
pretty
much
anything.
So
the
the
trade-off
here
is
not
to
give
too
much
open.
So
you
know
if,
if
you
have
a
single
plug-in,
destroying
your
total
application,
look,
that's
that's,
definitely
not
a
great
thing.
B
So
if
we
can
find
a
good
way
to
target
specific
parts
of
the
ui,
I
definitely
think
that
would
be
a
good
idea.
I
mean
in
general.
I
have
no
problems
if
you're
asking
for
trouble.
You
know
if
you
put
hot
pink
background
on
your
plugin.
That's
fine!
If
you
want
to
do
that,
I'm
okay
with
that!
I
don't
mind
totally,
but
if
you,
if
you
put
that
same
hot,
speak
background
in
the
whole
octant,
that
might
be
a
problem
for
for
everybody
else.
H
Yeah
yeah,
I
think
yeah,
so
the
idea
would
be
to
just
have
these
styles
be
scoped
to
the
actual
component.
That
is
containing
all
the
the
elements
that
are
displayed
in
the
plugin
so
that
it's
kind
of
encapsulated
in
like
sandboxed,
and
I
I'm
pretty
sure,
that's
definitely
possible
with
angular.
I
know
you
could
do
it
with
vu,
which
is
the
framework
that
I
used
before
again
like
just
for
context.
H
The
the
very
minor
issue
that
was
that
I
was
trying
to
resolve
was
just
adding
like
a
tiny
amount
of
like
margin
to
a
couple
buttons,
so
even
like
minor
things
like
this
still
seem
to
be
kind
of
difficult
with
an
octane
and
can
make
an
application.
Look
really
like
a
lot
more
clean,
so
yeah,
that's
kind
of
the
idea.
G
Yeah,
I
think
the
only
my
only
concern
would
be.
We
want
to
avoid
if
there
are
things
that
are
generally
going
to
be
making
octant
better
with
its
own
ui,
as
well
as
any
plug-in
authors
uis,
and
we
want
to
make
those
like
the
new
default.
I
would
ge.
I
would
prefer
us
making
useful
ui
enhancements
and
improvements
as
the
default
so
that
everyone
benefits
from
them
and
and
having
overrides
for
those
explicit
cases
where
the
there
there's
there's
some
other
reason
to
to
change
the
the
style.
G
If
it's,
if
the
reason
to
change
the
style
is,
it
looks
better
this
way
and
it's
and
we
agree
as
a
group
that
it
looks
like
in
the
case
of
this
spacing
on
on
on
the
button
groups
like
that-
might
be
a
more
general
change
that
we
want
to
think
about
incorporating,
instead
of
something
like
that
as
an
override.
So
that's
just
something
to
keep
in
mind
as
you're,
going
through
the
exercise.
A
Yeah
and
liam
I
wanted
to-
and
you
probably
have
already
well-
you
might
might
or
might
not
have
seen
this
so
a
lot
of
these
clarity,
core
components.
They
have
tunable
parameters
that
are
available
through
here
as
well,
and
typically
these
are
predefined
by
clarity
and
they
have
their
own
documentation
and
such
for
this
kind
of
stuff.
A
So,
if
you're
injecting
a
custom
status,
I
believe
the
escape
hatch
for
web
components
in
general
is
to
essentially
you
create
a
style
tag,
and
then
you
append,
like
the
inner
html
of
that
style
tag
with
whatever,
like
basically
like
css
string
inside
of
the
cds
button
for
the
for
your
new
css
values
to
register.
So
like
that's
just
like
that's,
essentially,
what
makes
this
weird
or
difficult
is
that
it
kind
of
depends
on
the
component
like
buttons.
A
It
makes
sense,
but
for
something
that,
like
a
component,
that
octane
has
a
wrapper
around,
it
probably
wouldn't
need
such
a
complex
mechanism,
so
definitely
depending
on
which
component
that
you
want
to
stylize.
There
might
just
be
an
easier
way.
It
might
just
be
another
configurable
option
that
should
exist
as-
and
this
is
to
what
wayne
was
saying
earlier-
that
if
it's
a
better
default,
then
we
should
just
absolutely
have
the
tunable
or
just
have
it
in
our
base.
Css
files,
rather
than
having
to
make
it
complicated.
H
A
All
right:
well,
we
can
yeah
and
I
think
the
best
way
to
if
we
want
to
continue
the
discussion
is
to
open
an
issue
for
this,
and
we
can
all
comment
on
on
like
specifically
what
we
want
out
of
this
so
cool.
Well,
that's
anyone
else.
Have
any
additional
questions
comments
on
this
injecting
custom,
css
or
just
other
open
q,
a.
A
All
right
cool-
if
not
thank
you
for
coming
this
community
meeting,
super
productive
one
love
it
keep
it
up.
Everyone.