►
From YouTube: Octant Community Meeting - April 1, 2020
Description
April 1, 2020
Agenda
Released 0.11.1
https://github.com/vmware-tanzu/octant/releases/tag/v0.11.1
Bryan Liles - Domain Driven Development
Open Q&A - add your questions here
A
Hi
everyone
and
welcome
to
this
week's
episode
of
the
octant
community
meeting
today
is
April
1st.
We
don't
have
any
prepared
April
Fool's
jokes,
but
if
you
come
up
with
some
during
the
meeting,
please
share
with
the
rest
of
the
group
per
usual
I'll
share
the
agenda
here
in
switch.
We
can
see
what
we're
talking
about
and
if
you
have
anything
that
you
want
to
add
into
the
agenda,
please
do
so
as
well.
B
Yeah
thanks
Janice,
so
we
cut
a
goat
out
11.1,
which
is
just
a
bug,
fix
release
that
fixed
this
some
issues
where
people
were
unable
to
load
the
page
when
there
was
pending
PBC's.
There
was
some
Jason
serialization
issues
that
were
fixed
up
as
well
as
some
tooltip
adjustments.
Some
fixes
for
actually
running
the
commands
from
our.
B
Build
go
file
and
because
of
the
update
to
angular
9,
and
we
also
fixed
the
the
tabs,
not
loading
because
of
the
external
services,
so
just
a
few
things
that
were
preventing
people
from
actually
being
able
to
load
octave.
So
we
recommend
that
everyone
go
ahead
and
create
to
the
lace,
release
and
I
want
to
thank
Milan
and
and
Sam
and
Jordan,
who
all
contributed
those
those
fixes
in
a
short
period
of
time.
So
I
appreciate
that
that's
kind
of
that's
the
mean
that
that's
all
we
had
for
the
for
talking
about
release
stuff.
B
The
only
other
thing
on
the
agenda
for
today
was
Bryan.
Liles
was
gonna.
Do
some
discussion
about
domain
driven
development,
specifically
around
some
of
the
engineering
we're
going
to
be
putting
into
hawked,
and
it's
going
to
help
separate
out
the
different
domain
spaces
within
act,
and
it
allow
us
to
you
more
easily,
no
more
better,
allow
us
to
better
engineer
octant
to
work
both
as
a
local
application
as
well
as
in
cluster,
and
make
it
something
that
is
easier
to
test
him
and
just
more
robust,
so
Brian.
C
C
Does
it
all
forget
again,
but
I
stayed
on
it
this
week
and
I
wanted
to
talk
about
what
octave
is
now
and
and
like
Blaine
said
why
we
would
be
thinking
about
the
architecture
of
auxin
a
little
bit
more
so
auxin
started
about
in
September
of
2018
and
Sam
was
here
actually
he's
the
only
original
to
menteng
member.
Besides
me
that
was
around
for
this
and
what
we
didn't
know
at
that
time
is
really
the
shape
of
the
problem.
C
We
were
solving
so
because
originally
octant
was,
can
I
figure
out
what's
going
wrong
in
my
cluster,
and
so
we
set
out
to
do
that
and
and
then
we
got
acquired
by
vmware.
There
are
changes,
and
then
we
found
that
we
wanted
to
add
more
features.
So
there's
more
changes
and
we
went
you
know
friend,
is
doing
things
more
changes,
and
actually
we
saw
this
opportunity
that
we
wanted
to
take
a
while
ago
to
run
octant
and
cluster
as
a
as
an
option.
But
the
way
our
octant
is
architected,
it's
pretty
hard
to
do
that.
C
We
use
these
things
called
informers,
which
means
that
we
keep
a
cache
of
what's
in
your
cluster,
at
least
for
namespace
and
memory,
and
that's
not
gonna
fly
whenever
we
run
it
in
cluster.
So
we
wanted
to
make
these
changes.
But
the
hardest
piece
of
this
change
is
that,
where
do
you
start
I'm,
not
saying
that
octane
is
a
hairball
that
is
messy
and
can't
be
extended,
because
I
know
we're
still
extending
it
to
we're
still
extending
it.
But
a
problem
we
finding
is
that
oxygen
is
pretty
much
hard
code.
C
It's
run
in
one
way
and
there's
a
lot
of
coupling
that
we
were
able
to
get
away
with
over
there
over
the
last
year
and
a
half,
and
now
we
get
Sun
tea
set
and
the
naive
way
would
be
in
this
go
in
there
and
do
it
go
in
there
and
just
rewrite
the
whole
thing,
and
when
will
we
be
done?
I
have
no
idea
so
instead
wanted
to
actually
do
some
software
engineering
here
and
apply.
This
concept
called
two
main
turbine
development.
C
There's
a
really
thick
book
about
it,
written
by
written
originally
like
17
years
ago,
and
it
talks
about
these
concepts
for
organizing
software
and
what
I'll
do
for
over
the
next
minute,
or
so
is
explain
how
we're
actually
going
to
use
this
rockton.
So
what
is
octant
right
now?
It's
a
web
front-end,
it's
a
pretty
complex
web
front-end
and
then
there's
a
back-end
as
well,
and
what
does
that
backend
do?
Well,
it
talks
to
the
cluster.
It
generates
components
that
can
be
viewed
in
the
front-end
and
it
updates
the
stores.
Internally
it
does
things.
C
It's
there's
no
way
that
we
can
do.
You
know
ten
to
twenty
to
a
hundred
two
hundred,
fifty
Meg's
of
storage
per
user
of
octant
and
cluster.
The
one
were
running,
so
what
we're
gonna
have
to
do
now
is
we're
pulling
it
all
apart
and
some
of
the
high-level
changes
that
are
made
are
there's
gonna,
be
some
concept
of
logins
and
then
our
store
right
now,
which
is
basically
just
a
facade
in
front
of
Informer's.
C
We're
going
to
have
to
replace
we're
going
to
add
another
one
and
the
next
one,
and
this
will
probably
just
be
on
hit
the
cluster
in
real
time
and
for
this
app
to
work
and
single
user
and
multi
user.
We're
going
to
have
to
push
a
lot
of
the
a
lot
of
the
implementation
details
even
further
down,
because
at
a
certain
point
you
don't
actually
need
to
know
this.
When
I
query
the
cluster
I
need
to
know
what
my
client
is
and
then
I
need
to
know.
C
When
how
I
can
query
using
the
store?
I,
don't
need
to
know
what
the
stores
backing
is
and
and
really
the
store
doesn't
have
to
carry
about
the
Custer
car.
So
we
probably
should
be
couple
those,
so
this
is
so
you're
gonna
see
some
work,
I've
started
it's
actually
it's
a
it's.
A
large
project,
I
committed
a
PR
this
morning
that
I
actually
already
got
merged
where
I'm
starting
from
the
beginning,
which
is
when
we
boot
octant.
We
have
this
thing.
It
used
to
be
called
developer
when
we
first
created
it.
C
C
This
will
actually
make
octave
so
much
easier
to
extend
and
some
of
the
features
that
are
taking
awhile
like
more
robust
plugins,
nor
bus
components,
more
fidelity
and
our
workload,
viewer,
more
fidelity
and
our
proper
loot
Ector
will
be
easier
because
it'll
be
easier
to
test
an
easier
to
implement.
So
that's
a
that's
my
discussion
of
what
we're
doing
right
now,
or
at
least
what
I'm,
what
I'm
spearheading.
D
C
Yeah,
it
actually
is,
and
and
I'm
they're
gonna
have
to
have
some.
You
know
we're
gonna
have
to
have
some
guidelines,
so
the
first
commit
that
I
did
where
we
broke
out
the
front
end
and
the
back
end.
Handlers
I
introduced
this
new
concept
of
options
and
it
actually
still
works
the
exact
same
way
matter
of
fact,
I
copy
and
paste
most
of
the
code
I
just
moved
it
to
a
different
place
and
then
put
a
different
interface
in
front
of
it.
So
Tim
to
answer
your
question:
is
that
long
term?
C
No,
we
won't
have
to
have
a
long
term.
Refectory
branch
will
be
able.
We
should
it's
going
to
take
a
while
we're
not
to
be
able
to
get
it
done.
It's
kind
of
this
is
actually
probably
going
to
be
like
I,
don't
know
two
months
plus
of
work
just
to
really
get
it
right,
but
we'll
be
able
to
do
it
in
line,
and
we
shouldn't
break
anything.
D
D
C
C
We
were
doing
this
in
Ruby
or
Python
or
JavaScript
yeah,
I
would
probably
say
yeah,
but
because
we're
doing
it
in
typescript
and
it's
it's
pretty
you
see
when
a
type
is
it
calls
anymore.
We
actually
shouldn't
have
any
duplication.
Things
might
be
in
a
weird
place
for
a
while,
like.
Why
would
I
call
it
that
way,
but
we
won't
actually
have
a
duplication
and
actually
solves
another
big
problem
that
we
had.
That
kind
of
slows
us
down
is
that
in
certain
places,
oxen
is
complex
and
hard
to
test.
C
B
So
then,
that
frees
us
up
to
then
start
to
actually
change
those
things
behind
the
scenes,
and
we've
created
this
new
interface
for
the
various
components
to
talk
to
each
other
through
so
once
we
and
then
we're
pushing
we're
trying
to
make
sure
that
all
of
our
interfaces
that
involve
communicating
across
domains
are
getting
pushed
up
into
the
package
folder.
So
that
way,
we
can
get
rid
of
this
deep
nested
generating
of
mocks
and
have
all
of
our
mocks
generated
from
the
single
location.
C
Yes,
and
actually
this
so
there
are
some
other
benefits
so
at
being,
where
I
still
I
still
watch
over
octant
and
I'm
still
every
once
in
a
while
out
there
on
a
PR
for
something
but
another
project
that
I
have.
We
wanted
to
use.
Octant
and
I
wanted
to
write
a
plug-in,
and
now,
as
I'm
doing
all
this
is
actually
so.
It's
all
selfish
for
me,
I
want
this
to
be
more
organized,
so
it's
easier
for
me
to
extend
akhaten,
so
I
can
actually
show
what
I'm
doing
and
I
could
talk
about
this
piece.
C
We're
I'm
looking
at
things
like
other
open
source
process
like
Tecton
I,
know
that
their
developers
have
been
kind
of
vocal
and
our
issues
and
and
then
also
like
operator
framework
from
Red
Hat,
and
what
I
would
like
to
do
is
put
create
interfaces
around
all
of
those
and
and
make
us
give
them
give
these
things
the
real
goodies
that
they
deserve.
So
it's
actually
really
selfish
time
doing
all
I
want
it.
So,
let's
it's
gonna
happen
and.
C
That's
what
I'm,
looking
at
more
as
a
plugin
author
I
mean
as
I
see
things
that
I
fix,
like
I
just
submitted
a
PR
for
store,
create
up
need
to
create
stuff,
so
it
has
to
happen.
So
this
is
why
this
is
there's
lots
of
benefits
all
the
way
around
for
these
things,
and-
and
this
ties
into
now
that
we
have
create
and
that
math
to
change
something
too
much.
C
But
Wayne
did
a
lot
of
good
work
and
getting
the
Monaco
editor
in
there,
and
now
that
we
have
a
way
to
create
now
guess
what
all
of
a
sudden
this
Monaco
etiquette
editor
becomes
pretty
cool,
and
now
you
can,
we
got
a.
We
have
actually
think
about
how
we're
going
to
employ
it,
but
being
able
to
create
optics
and
update
optics
is,
is
a
pretty
exciting
place
for
us.
C
Yeah
and
I
just
want
to
say
that
this
is
a
I
didn't
never
knew
this
project
would
turn
out
like
this
cuz
I
had
no
idea
actually
being
think
about.
It
said
it
was
gonna,
be
this
thing,
and
and
now
you
know,
one
sock
sent
runs
in
cluster
and
run
standalone
and,
and
we
have
the
ability
and
I
have
the
ability
to
add
things
pretty
quickly
now
I
get
very
excited
about
octave,
because
Wow
will
be
able
to
do
all
sorts
of
things.
C
B
C
C
We
have,
and
we
have
like
a
couple
handfuls
I,
probably
like
four
or
five
handfuls
of
octave
components.
Right
now,
and
you
know
they
are
layouts
and
they're
buttons
and
there's
forms
and
there's
summaries
and
and
other
things
in
text
fields,
and
the
problem
is,
is
that
whatever
we
create
will
never
be
enough?
If
I
literally
will
never
be
enough?
C
I
know
this,
and
people
are
asking
for
things
like
graphing
components
and
who
knows
what
else,
because
for
any
opportunity
display,
you
might
just
need
something
custom
that
just
makes
you
what
you
need
to
do,
look
good
and
so
on.
Someone
suggested
web
components
and
over
the
Christmas
break
so
we're
in
April.
Now
so
three
months
ago,
three
and
a
half
months
ago,
I
sat
down
and
I
looked
at.
How
did
web
components
and
first
of
all
is
it
will
work?
C
The
second
part,
but
the
hard
part
with
web
components
is
this
I'm
a
web
component
encapsulate
some
HTML
on
a
page
and
that's
fine,
and
we
could
actually
make
that
work.
But
the
problem
is:
is
that
now?
How
does
it
look
like
the
rest
of
the
page,
because
I
don't
want
to
put
us
in
a
place,
it's
kind
of
like
what?
What
graph
AMA
did
you're
not
going
to
see
a
whole
bunch
of
funny-looking
gravano
plugins
out
there?
C
They
all
look
kinda
like
Ravana
and
I
want
to
make
sure
that
we
have
kind
of
the
same
thing.
So
what
we
need
to
do
well,
we'll
need
to
make
our
we'll
need
to
make
our
style
sheets,
at
least
our
style
sheets
available
to
the
web
component
and
we'll
need
to
do
it
in
a
standard
way.
But
then
again,
we'll
still
need
to
give
the
flexibility
of,
let's
say,
a
a
plugin
that
wants
to
actually
have
its
own
component
wanting
to
give
it
away
to
serve.
C
So
what
we
need
to
do
is
we
need
to
solve
those
problems
and
I.
Actually
I
have
in
front
of
me
right
now.
I
have
these
notes
on
it.
I'ma
create
an
issue
around
that
and
I
would
love
some
some
feedback
on
what
that
is
because
I
think
actually
having
disability
having
this
ability
to
display.
Literally
any
content
inside
of
octant
in
a
in
a
safe
way
would
be
a
big
boon
and
I
think
it
would.
It
would
go
far
for
plug
in
authors
and
yeah.
So
that's
that's
one
thing.
C
So
the
next
thing
is
like
unplugging
authors.
Now
that
I
actually
spend
a
lot
of
time
with
often
plugins
I
tell
the
story
that
I
literally
created
the
option
plugins
over
a
weekend,
because
and
why?
How
hard
could
this
be?
And
it
wasn't
hard,
but
it
wasn't
easy,
so
it
got
us
to
the
point
where
we
could
do
it,
but
the
problem
is
in
its
highest
back
it's
what
I
was
originally
talking
about
the
coupling
we're
using
the
go
plug-in
stuff
from
half-court.
It's
it's!
Okay!
C
Than
they
are
right
now
there
there
are
really
are
no
places
that
assume
that
it
is
a
binary.
But
did
we
make
some
assumptions
about
plugins
that
we
probably
should
not
and
and
then
we
also
don't
pass
enough
information
back
and
forth
between
the
plug-in
and
often
so
it
kind
of
makes
them
a
little
bit
cumbersome
to
use
and
in
third,
we
have
like
the
the
absolute
minimum
of
a
support
library
for
plugins
and
which
means
you
can
write
everything
you
want.
C
You
want
to
write
up
a
low-level
I
think
I
still
think
we
should
try
something
a
little
bit
higher
level
and
that
probably
that
would
not
be
an
opt-in
itself.
So
if
you
wanted
to
write
a
go
plug-in
for
opt-ins,
we
probably
would
create
another
project
where
it's
just
a
library
that
allows
you
to
to
do
that,
so
we
can
still
have
our
low
level
API
and
then
one
more
last
thing
of
plugins
and
I.
Think
I
might
have
told
Wayne
about
this.
So,
like
I
said,
we
were
using
hash
to
court.
C
Plugins
that's
kind
of
neat,
but
I
was
thinking
of
other
ways
and
especially
when
we
were
running
cluster,
we
can't
run
we're
not
gonna
be
able
to
do
have
some
core
plugins
when
we
run
in
cluster
I.
Just
don't
I
just
can't
see
the
security
model,
I,
don't
see
what
multi-user
and
all
that
I
don't
see
how
it's
gonna
work.
So
I
was
thinking
of
other
ideas
for
plugins
and
there
is
literally
no
document
about
this.
I
think
I
just
told
Wayne
and
he
probably
think
he
said
I
was
crazy.
C
Are
you
kidding
me
I'm,
a
crazy
look,
but
one
thing
I
was
thinking
I
doing
in
octant
is
embedding
a
Python
interpreter
interpreter,
and
why
would
you
buy
Python
well
because
I've
written
interpreter
and
I've
written
a
compiler
and
it's
hard
work?
So
what
I
want
to
do
is
find
one
that
could
already
I
can
easily
embed
in
a
go
app.
So
we
really.
We
have
two
options.
C
There
is
a
go:
lua
port,
that's
actually
pretty
good,
but
once
right
in
lua
and
then
there's
and
then
there's
the
google
was
a
call
this
day,
skylarks
our
arc.
One
of
those
two
which
is
most
the
Python
and
it
can
be
called
from
go,
they
actually
use
it
in
basil,
and
so
you
can
write
your
basil
stuff
and
in
Python
and
I
was
looking
at
it
and
thinking.
Well.
That
would
be
a
great
that's
a
great
Avenue,
because
we
already
get
some
of
this.
C
The
way
that
they
wrote
in
basil
gives
some
the
safety
that
it
doesn't
tear
everything
down,
but
it
still
gives
you
a
languages
familiar
and
so
that's
something
else
is
so
a
little
bit
out
it's
more
than
experiment,
but
once
we
get
our
plugins
stuff
behind
the
good
interface
that
it
would
be
neat
to
see
if
we
could
launch
another
plug-in
type-
and
it
would
be
this-
this
Python
variant,
which
is
interesting
because
now
we
can
get
to
the
point
where
I'm
comfortable,
offering
it
to
a
multi-user-
and
you
know,
and
also
it
should
be
a
lot
less
of
a
mental
burden
to
write
decent
Python
rather
than
go.
C
E
So
so
kind
of
speaking
along
some
of
the
those
lines
one
of
the
things
I
was
thinking
about
for
octant
is
you
know,
offering
a
SAS
capability
to
host
all
of
the
plugins?
So
if
someone
wanted
to
discover
all
the
plugins
out
there,
you
know
why
not
try
to
do
a
good
job
of
posting
them
on
our
website
or
putting
links,
or
maybe
some
money
search
Twitter.
What
if
we
actually
had
a
way
to
curate
the
catalog
and
by
cuted
I,
don't
mean
to
go
through.
E
You
know,
validation
or
certification,
or
anything
like
that
who
can
come
up
with
what
makes
sense
for
us
have
a
way
to
say:
hey
I
would
like
to
add
a
plug-in.
Let
me
search
what
plugins
are
available
and
have
a
way
to
the
plugins
to
register
contracts,
so
they
can
become
visible
there
and
it
pointed
it
to
github
page
or
some
other
means
of
consuming
or
integrating
the
plugin
bug
into
octant
I.
Think
that's
going
to
be
a
great
way
for
enabling
customers
to
visit
be
doing
what's
out
there.
E
So,
for
example,
you're
using
Trevi
and
like
if
we
asked
community
I
would
say
that
99.9%
of
them
don't
know
that
3
B
has
an
plugin
to
octant,
but
a
few
folks
do
if
there
was
a
way
for
them
to
find
it
then
they're
busy
for
them
to
see
okay.
How
can
I
recommend
my
view
of
the
cluster
with
additional
details
in
the
areas
of
security
or
networking
or
CI
CD,
or
something
else.
C
Yeah,
so
that
is
another
reason
why
I
wanted
to
do
Python,
plugins
I'm
going
to
say
the
biggest
reason.
The
biggest
reason
is
Python
is
compatible.
I
can
run
it
from
go,
then
I
don't
care.
What
the
target
architecture
is
because
right
now,
if
you
create
a
plug-in
and
the
plugins
are
binaries
for
your
operating
system.
So
if
you
really
want
your
plug-in
to
be
used
in
a
lot
of
places,
you
have
to
make
it
sure
it's
available
for
windows,
linux
and
mac
like
whenever
we
do
it
for
a
safe.
C
Then
it
becomes
more
interesting
because
now
we
can
actually
bring
in
plugins
as
their
source,
whatever
that
happens
like
and
we
can
program
in
the
octet
while
it's
running
and
we
can
manage
them
so
then
we
would
actually
need
something
like
some
sort
of
I
think
the
popular
term.
These
days
is
some
kind
of
hub
where
we
can
actually
either
register
them
or
get
them
right
from
github
or
or
whatever.
It
makes
sense
at
that
time.
But
I
I
do
think
that
that's
a
good
idea
and
and.
E
E
C
D
D
So
really
it's
not
embedding
it's
not
necessarily
embedding
a
Python
interpreter,
it's
having
a
RPC
bindings
wrapped
in
an
API,
so
it
doesn't
necessarily
need
to
be
a
custom
Python.
It
could
be
just
a
regular
Python
system,
shipped
Python,
with
the
right
libraries
for
interacting
with
octaves,
or
are
you
thinking
something
different
than
that?
No.
C
C
C
I,
don't
want
to
have
that
at
all.
We
should
be
able
to
it's
either
that
or
actually
tell
you
the
truth,
and
this
we'll
probably
get
some
booze
I
actually
wish.
I
could
find
a
good
JavaScript.
One
I
find
JavaScript
easier
to
write
the
Python.
Shame
on
me,
but
that's
that's
where
I'm
thinking
about
it
right
now
is
that
if
whatever
we
introduced,
let's
not
make
a
weird
problem:
weirder,
let's
MIT,
let's
actually
attack
some
of
the
things
that
we
had
where
plugins
are
cumbersome
and
not
the
easiest
to
write.
C
I
had
one
up
here
right
on
my
screen
right
now
and
not
easy
to
write.
The
second
thing
is
that
plugins
are
not
compatible
across
operating
systems.
Yeah
we
know
and
and
the
third
one
is
it
should
just
be
easier
and
so
that
that's
so
definitely
will
solicit
opinions.
Wayne
will
Wayne
will
be
soliciting
opinions
about
that
whenever
whenever
we
get
there,
but
that
will.
B
And
the
just
I
don't
know
like
you
can't
currently
write
a
plug-in
in
any
language
that
you
can
set
up,
G
RPC
for
it's
not.
We
don't
currently
have
all
the
stubs
generated
for
all
the
other
languages,
but
I
wrote
an
example
in
Python
that
just
uses
the
local
Python
interpreter,
but
so
Brian's
point
it
still
does
use
the
local
interpreter
and
it
so
you
might
be
defaulting
to
Python,
2
or
just
Python,
3
and
and
like
people
like
you,
just
your
the
whole
set
of
issues.
B
If
we
go
with
the
embedded
approach
plus,
it
creates
a
unified
language
for
plugins,
which
actually
will
evolve
into
a
richer
ecosystem
for
plugins,
because
now
everyone
has
to
share
the
same
code
bases
like
either
the
the
language
they're
writing
in
is
the
same
across
all
plugins
and
the
result
is
that,
then,
you
get
more
sharing
and
more
people
writing
like
libraries
for
building
plugins
in
the
language
that
people
are
building
plugins
with
right.
So
it
takes.
It
takes
some
of
that
away
from
all
the
different
like
landscape
of
go
Python,
Ruby
JavaScript
are.
D
C
Yeah
so
actually
I'll
say
this
is
not
a
Nirvana
I.
Think
you
put
this
in
a
better
location
because
it,
if
you,
if
you
think
about
your
imports
now
or
do
you
import,
you
can't
just
import
random
thing,
so
we're
going
to
have
to
it's
going
to
be
we're
going
to
probably
have
to
supply
our
own
standard
library.
If
we
do
this
and
say
you
just
can't
you'll
get
a
kubernetes
client,
maybe
we'll
get
you
you'll
get
a
cooper,
nice
client,
some
kind
of
web
client.
C
D
I
I'm
just
I'm
just
still
wondering
I'm
thinking
like
windows,
subsystem
or
Linux
subsystem
for
Windows
or
what
was
the
old
thing
called
I
can't
remember
the
district
cygwin,
something
like
that,
because
there's
just
such
a
rich
ecosystem
in
Python,
I'm
thinking
like
graph
manipulation,
libraries
or
numpy
for
for
visualization
or
any
of
those
things
and
I
think
it
would
be
great
to
offer
that
capability
without
having
to
do
it
ourselves.
So
well,.
C
Was
possible
yes,
possible
and,
and
that's
about
where
I
am
cool.
F
At
2:00,
true
one
more
things,
one
more
thing
in
Amex
I
think
it
would
be
really
nice
to
have
an
ability
to
I
think
the
way
the
plugins
work
now
is
heavily
back
and
based
so
they're,
mostly
gear.
So
you
can
change
it
the
model
it
can
define
your
front
and
through
the
through
the
way
that
data
is
passed
down
to
the
client,
but
it
would
be
nice
if
plugins
can
actually
modify
only
client
side
for
some
reasons.
F
So,
for
example,
you
know
if
you
just
want
to
have
your
specific
field-
let's
say
pardo,
add
some
matrix
or
whatever
just
collecting
the
data
from
the
server
side
and
then
that
just
changing
that
client.
That
would
be
a
good
thing
to
so.
So
it's
it's
there's
a
lot
of
trade-offs
in
in
all
approaches,
and
one
of
them
is
just
you
know,
trying
to
get
everything
together
and
show
information
where,
where
it's
accessible,
yeah.
C
Me
on
you
bring
up
a
good
point
and-
and
that's
actually
one
of
the
things
that
I'm
looking
at
now,
it's
like
alright,
so
we
do
the
Python,
but
let's
not
make
it
harder.
Let's
make
it
easier
to
do
those
easy
things
and
I
can
think
of
things.
That
would
be
like
really
easy,
like
I
want
to
add
a
field
to
status.
All
right
that
should
be.
C
That
should
be
pretty
easy
to
do
and
we'll
probably
need
to
come
up
with
a
list
of
things
that
we
think
just
should
be
easy
to
do
to
guide
us.
But
it's
how
you
to
treat
me
lon,
I,
thought,
you're
gonna
say
something
totally
different,
I
thought
you're
gonna
say
well.
Why
don't
we
do
as
him
and
I
was
going
to
say,
I,
don't
know,
cuz
I,
don't
know,
but
yeah.
E
C
Two
levels
here
so
there's
only
single
user
if
there's
only
senior
user
single
user
octant
the
the
plugins.
This
is
why
the
plugins
get
access
to
basically
kubernetes
crud
and
that's
it.
They
can't
really
change
anything
in
octave
and
that
and
that's
by
design
when
you
get
in
a
multi
user,
now
becomes
even
more
interesting.
I,
don't
know!
If
the
answer
is
here
yet-
and
this
is
another
reason
why
I'm
moving
scores,
Python
plugins,
because
then
I
can
make
sure
that
every
single
every
single
time
its
access
its
access
in
its
own
container.
C
So
not
you
know.
Not
only
can
you
touch
not
touch
octant,
you
also
don't
get
access
to
anybody
else's
user
information
because
it'll
only
be
you
in
there
but
Michael.
That's
a
good
point
to
bring
up
and
that's
why
we
need
to
actually
think
about
plugins
just
more
in
general
as
we
move
to
multi-user
and
what
a
security
look
like,
because
when
it's
only
single
user,
it's
easy
well,
what
does
can
the
plug-in
do
or
whatever
it
wants?
G
C
So
the
the
quick
answer
is
in
cluster.
If
we
run
this
in
cluster,
we
probably
won't
do
the
go
plugins
in
cluster
and
and
the
reason.
Why
is
because,
let's
say
if
we're
running
this
as
part
of
a
workload,
so
it's
in
a
pod,
the
the
semantics
for
exacting
another
binary
become
interesting
and
weird
and
I.
Don't
I
mean
we
couldn't
do
it
yeah,
we
literally
could
do
it,
but
every
time
we
want
to
change
a
plug-in
we'd
have
to
redeploy
oxygen
again.