►
From YouTube: Octant Workflow Overview and Code Deep Dive
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
A
We
try
to
best
effort
within
reasoned,
prefer,
a
sink
over
synchronous,
so
updating
issues
and
tickets
and
creating
documents
and
and
making
sure,
recording
videos
and
sharing
those
out
when
we
do
do
synchronous
communication.
This
way
that
people
across
all
the
time,
zones
and
different
interest
areas
and
people
who
are
new
to
the
project
or
maybe
they
were
in
the
project,
then
left
and
then
came
back.
A
They
can
all
get
caught
up
on
information
and
get
that
get
those
details
as
they
need
so
we're
just
putting
effort
into
making
sure
that
we're
not
having
a
lot
of
kind
of
one-off
out-of-band
conversations
in
slack
and
then
never
updating
any
of
the
issues
or
documents
around
it,
because
it
can
be
a
nightmare
to
go
through
slack
and
kind
of
find
stuff.
So
our
workflows
is
is
really
simple
right
now
the
issue
represents
work
to
be
done
or
work.
That's
currently
being
done
see.
A
A
So
the
the
motivation
to
go
update
the
move,
the
card
from
one
column
to
another
in
Zen
hub,
is
generally
fairly
low,
but
we've
been
been
working
on
trying
to
make
sure
that
we
have
good
habits
there.
So
nothing,
nothing
unusual
there
in
our
work
out
makes
sense.
So
I
come
with
that
really
really
fast
I,
because
that
you
mentioned
you
already
kind
of
looked
at
everything.
So
were
there
any
specific
questions
you
had
about
our
tools
or
workflow?
No.
C
A
So
then,
I'll
move
on
I
I
want
to
so
I
made
this
list
and
I
kinda
wanna
get
your
feedback
on
it.
If,
if
this
seems
like
a
good
thing
to
cover,
then
this
is
what
I'll
walk
through
and
cover,
but
if
there's
something
in
here
that
you
are
really
interested
in
are
missing
or
feel
like
feel
like
you
don't
need
just
let
me
know
now
and
I'll
update
this,
and
we
can.
We
can
do
it.
A
The
oh
I
know
why
I
don't
because
I
was
switching
between
branches,
so
the
the
goal
of
octant
is
really
to
help
kind
of
developers
and
people
who
are
building
things
for
kubernetes
kind
of
get
visual,
my
dog
to
kind
of
get
that
visual
feedback
of
what
they're
doing
and
how
the
services
and
interactions
are
are
happening.
A
It
also
has
the
ability
to
kind
of
provide
you
with
details
around
how
things
aren't
working,
so
we
expose
things
like
the
logs
for
pods
and
the
status
of
individual
objects,
and
things
like
that,
where
you
will
be
able
to
see
through
our
resource
viewer
that
how
things
are
all
interconnected
and
if
there's
currently
any
errors
or
warning
conditions
around
those
objects,
that's
kind,
that's
kind
of
like
the
high-level
take
on
on
octant
Sam
has
anything
to
add
there
all
right.
Do
you
questions.
C
A
So
I
can
touch
on
that
a
little
bit
here
as
we
move
in
so
kind
of
like
the
ideas
around
octant.
So
öktem
is
kind
of
broken
up
into
these
two
pieces
so
from
right
now,
I,
don't
think
about
code.
Just
think
about
these
two
substances.
We
have
the
stream
of
data,
that's
coming
out
from
octant,
and
then
we
have
these
components,
and
so
the
stream
of
data
is
essentially
a
JSON
like
it's.
A
It's
JSON
marshalled
data
and
components
are
what
take
that
JSON
data
and
turn
it
into
what
see
and
interact
with
in
the
UI.
So
on
the
on
the
front
end,
it's
really
just
watching
a
data
stream
and
then
taking
that
data
stream
and
transforming
it
into
components
and
the
back
end
is
taking
watching
a
data
stream.
In
this
case
it's
the
kubernetes
api
and
it's
taking
that
and
it's
converting
it
into
those
components.
A
And
so
and
then
the
go-between
is
just
that
it's
marshaling
it
out
to
to
json
and
we
then
convert
that
into
the
visual
representation,
the
backend
that
is
watching
the
kubernetes
stream
and
then
converting
it
into
our
own
stream
of
components.
That's
done
with
go
and
the
front-end
that
is
consuming
the
stream
and
rendering
it
out
into
the
HTML
version
of
the
components
is
angular.
A
The
the
front-end
itself
to
the
best
of
our
ability
doesn't
actually
know
what
these
things
are
or
how
they
interact
with
one
another
word
that
they're,
even
it
has
no
sense
of
their
their
their
concrete
type
or
their
form.
We
we
just
create
a
set
of
generic
components,
and
then
we
assemble
those
components
in
a
way
that
the
the
front-end
code,
the
angular
code,
displays
them
how
we
want.
A
A
That'll,
be
that
application
centric
view
where
you'll
have
that
more
native
look
and
feel
and
a
knockin
will
be
just
a
an
application
that
runs
on
on
all
the
platforms
back-end
wise.
What
we
do
is
we
we
have
go
and
we
use
G
RPC
as
the
mechanism
for
communicating
between
the
server
and
the
client,
and
then
we
use
a
library
called
go
rice
which
takes
all
of
our
front-end
assets
and
packages
them
together
with
the
back-end
assets,
so
that
we
can
run
the
back-end
service
as
well
as
serve.
A
Point
binary,
I,
don't
know
exactly
what
that
what
that
wall
looked
like
as
we
move
towards
electron,
because
I
know
electron
has
some
mechanisms
for
packaging
and
tooling,
but
for
now
that's
just
those
are
the
electron
part
of
things
is
a
completely
separate
module
on
the
front-end
and
so
we're
we're
not
dealing
with
with
changing
how
the
executable
is
currently
built
at
the
moment.
Ok.
A
A
We
can
circle
back
to
the
details
on
go
rice
later,
if
that's
something
you're
interested
in
so
as
for
I
touched
on
this
I'm
going
through
this
stuff,
really
fast,
cuz
I,
don't
wanna
take
up
too
much
of
our
time.
But
if
you
want
me
to
slow
down-
or
you
want
me
to
cover
everything
more
in
depth,
just
please
call
it
out
now.
A
So
this
will
probably
be
the
last
section
that
I'll
that
I'll
get
into
before.
We
start
to
actually
like
look
at
some
of
the
code.
So-
and
this
is
this-
is
just
how
often
gets
information.
We
have
two
methods
that
we
use
to
get
information.
We
use
an
informer
which
is,
if
you're
not
familiar
with
informers,
it's
a
it's
a
part
of
the
kubernetes
api
and
allows
you
to
sit
and
watch
a
set
of
resources
or
a
namespace
for
updates
to
different
objects,
and
so
we
use
reef
informers
in
combination
with
a
dynamic
client.
A
So
when
we
don't
have
access
when
the
informer
does
not
have
information
so
that
the
the
cache
that
backs
the
informer
does
not
have
information
that
we
want.
Yet
we
will
then
use
the
dynamic
client
to
directly
connect
to
the
API
and
fetch
that
information.
Now,
while
we
wait
for
the
Informer's
to
warm
the
cache
I
see,
so
that's
that's.
One
place
where
often
gets
information
from
is
basically
direct
from
the
kubernetes
api
and
the
second
place
octant
gets
information
from
is
from
plugins
and
it
does.
A
It
gets
its
information
from
plugins
using
a
service
interface
that
we've
created
that
allows
plug-ins
to
subscribe,
to
associate
event
handlers
for
the
various
object,
types
within
kubernetes
or
custom
custom
resources
so
to
octant
once
once,
things
are
being
called
on
the
on
the
like
load
and
loaded
and
printed
into
the
stream.
There's
no
difference
between
information
being
fed
from
a
plugin
versus
information
being
fed
from
the
kubernetes
api.
A
Oh
sorry,
yeah
I
was
referring
to
a.
We
have
a
service
interface
in
golang
that
our
plugins
can
implement.
I
see
and
the
plugins
themselves
are
implemented
with
a
package
that
is
from
its
go.
P--,
it's
go
plugin,
it's
it's
from
its.
The
G
RPC
go
plug-in
module
from
Hoshi
Corp
and
essentially,
what
a
plug-in
is?
It's
just
a
long-running
process
that
octant
starts
when
it
starts
up
yeah.
It
starts
it
up.
A
So
now
we
get
onto
more
of
kind
of
the.
How
does
octane
display
information
and
there's
there's
three
kind
of
paths
that
your
request
takes
as
it's
going
through?
Octant
and
I
am
gonna,
pull
up
a
code
editor
here,
I'm
gonna
talk
about
it
and
then
I'll
kind
of
show
it.
So
the
first
part
is:
we
have
paths
and.
B
C
C
A
A
So
yeah
so
kind
of
what
happens
when
you
make
a
request
to
octant
is
the
first
thing
we
do.
Is
we
look
at
the
the
path,
and
so
this
is
where
this
is,
where
we
interesting
cuz,
I
I,
don't
actually
I
just
search
for
it,
because
I
don't
actually
know
all
of
the
all
the
spots
where
these,
where
these
things
happen.
A
So
we
have
this
this
path
mattress.
So
what
happens
is
the
the
request
comes
in
and
there
is
a
path
associated
with
that
request
and
we
take
that
path
and
we
break
it
down
into
its
parts
and
the
parts
the
parts
containing
1/8
you
generally
speaking,
milk
for
like
namespace,
scoped
things,
they'll
contain
a
namespace
and
and
the
name
they'll
contain
usually
the
resource
type
that
we're
trying
to
get
at.
A
All
of
that
information
in
the
path-
and
so
what
we
do
is
we
break
that
information
up
and
we
we
determine
what
the
actual
path
feel
like
the
matching
path
is,
and
then
we
use
that
to
go
and
get
the
object
from
kubernetes,
so
it'll
say
like
namespace
default
pods,
and
then
it
will
say,
like
the
the
the
container
of
the
pot
ID
and
we'll
use
that
information
from
the
path
to
then
start
the
process
of
describing
the
pod
and
then
later,
printing.
A
The
pas
the
describers
which
we
have
here
are
generic
enough
that
we
have
this
idea
where
we
either
we
either
describe
an
object
or
we
describe
objects,
and
then
we
also
have
some
things
customized
out
for
like
CR
DS,
and
so
the
way
these
work
is
that
they
they
take
in
so
after
path
matching
has
happened.
We
use
that
to
create
what
will
be
the
there's.
A
Yeah
here
we
go
okay,
so
this
is
the
generator
yeah.
The
generator
is
essentially
running
on
a
loop.
We
have
a
loop
that
calls
this
ugly
every
second
and
what
it
does
is
it
takes
the
current
content
path,
which
is
what
I
was
mentioning
before
it
passes
it
through
this
path.
Matcher
here
and
the
result
is
this
path
filter
and
then,
once
we
I
believe
that's
a
pass
filter.
Let
me
make
sure
yeah
path
filter.
A
So
once
we
have
the
path
filter
out,
what
we
do
is
we
then
use
that
to
then
query
the
the
kubernetes
api
to
get
the
object
or
objects
that
were
interested
in
and
the
way
we
do.
That
is.
We
have
this,
as
I
mentioned
previously,
we
using
formers
in
a
dynamic
cache
or
dynamic
client.
Well,
those
are
those
are
abstracted
way
behind.
A
Filter
and
we
load
up
all
of
this
into
the
fields
here,
and
these
fields
end
up
getting
populated,
Ed's
oz
mission
before,
where
things
like
the
namespace,
the
the
link
and
the
printers
and
all
of
these
things
that
are
going
to
be
used
for
this.
For
this
object,
we're
also
the
load,
object
and
load
objects,
factory
functions.
Those
are
what
these
are
just
encapsulations
around
fetching
an
object
from
the
API
they
take
in
the
desired
like
namespace
and
fields
and
then
wrap
the
get
and
list
methods.
A
So
that
way,
when
you
call
them
it's
just
a
single
function,
call
and
that
we've
we've
already
used
closures
to
kind
of
determine
what
the
what
the
arguments
are
call
and
then
yeah.
So
then
we
call
this
describe
which
the
that's
where
we
just
where
we
came
from
previously
and
describe
we'll
take
in
the
namespace
in
the
set
of
options,
options
again
being
determined
from
the
the
pass
filter
and
and
and
the
generated
fields,
and
it
will
then
produce
a
Content
response
now.
A
A
So
we
then
we
marshal
that
to
JSON
and
we
put
it
onto
the
stream
to
marshal
it
to
JSON
it's
the
object.
Describers
will
go
and
and
get
gather
up
all
of
the
different
tabs
and
and
information
that
we
have
and
the
result
of
that
is
then
those
tabs
will
start
to
call
all
of
our
printers
and
our
printers
okay,
our
printers
here
you
can
see
these
start
to
make
these
starts
to
make
sense
right.
B
A
Okay,
so
this
is
the
this
is
in
view
component
in
base
go.
This
is
kind
of
our.
This
is
why
it's
all
hand
wavy
and
hard
to
follow.
Sometimes
so
we
we,
we
have
a
set
of
types
that
we
define.
These
are
all
concrete
component
types
that
can
be.
This
is
the
this
is
essentially
a
list
of
anything
that
can
be
marshaled
or
run
marshaled
from
JSON
or
Marshall
to
JSON
as
well,
and
what
it
does
is
there
is
this
there's
this
list
of
concrete
types,
and
then
we
have
a
another.
A
A
Here's
a
good
example,
because
we
just
did
this
one.
So
we
have
that
list
of
concrete
types,
and
then
we
create
this
Marshall
JSON
function,
which
we
assign
it
this
metadata
type,
and
then
we
call
Marshall
and
what
that
does
is
there
is
a
metadata
object
and
or
metadata
printer
and
the
metadata
printer
takes
that
type
and
assigns
it
and
then
also
knows
how
to
ensure
that
the
type
of
it
gets
passed
on
to
the
rest
of
it's
the
rest
output
in
the
stream.
Sorry,
the
actual
JSON,
that's
getting
outputted,
and
to
do
that.
A
A
So
the
main
thing
here
that
I
want
that
that
I
think
it's
important
for
you
to
know
is
that
the
path
filter
creates
the
set
of
options
that
gets
passed
into
the
describer,
which
so
that
the
the
generator
is
being
called
the
the
the
generator
has
the
content
path
that
is
currently
being
viewed
that
creates
a
set
of
paths,
filter
options
that
then
get
passed
into
a
describer
and
the
describer
is
responsible
for
generating
all
of
the
tabs.
Let's
see,
if
I
can
that.
A
C
I
know
it
kind
of
makes
sense.
I
I
really
like
how
it
seems
to
be
really
extensible,
so
you
can
easily
add
the
different
types
and
what
may
help
and
I
may
try
to
do
that
on
my
own.
It's
do
it
because
I
like
to
think
about
visually,
so
I
may
try
to
make
like
boxes
how
things
are
connected.
It
may
help
me
and
if,
if
it
turns
out
it's
something
I'm
air
that
today
I'll
get.
A
Ya
in
like
one
like
something
you
could
do
just
in
that
and
kind
of
in
that
same
vein
of
like
trying
things
out
is
you
could
come
in
here,
I
mean
I'm
gonna.
Do
this
quick
and
obviously
I
know
that
I
have
a
lot
of
context
here,
but
in
object
that
go
in
the
describer
right
you
could
come
in
and
you
could
say
you
know
I'm
gonna,
I'm,
gonna.
Add
this
and.
A
A
Have
the
describer
output
that,
as
a
as
a
as
a
Content
response
for
the
tab,
and
you
could
then
see
that
that
kind
of
being
rendered
out
in
real
time,
and
that
would
give
you
that
would
give
you
a
good
understanding
of
of
how
to
work
on
the
backend
and
have
it
be
viewed
in
the
front-end.
Another
way
would
be
to
just
write
a
plug-in
plugins
give
you
kind
of
that
that
same
freedom.
But
you
have
then
your
your
kind
of
scoped
to
the
external
interface
that
we've
just
prescribed
to
two
plugins.
A
A
A
A
B
A
Yeah,
okay,
so
when
I
click,
this
start
port
forward,
what
happens
is
there's
there's
this
action
that
gets
that
gets
sent
and
the
way
this
looks
is
I
can
show
it
to
here.
Is
it's
really
simple
what
you
so
you
can
see
it
is.
It
is
there's
just
a
in
this
case.
The
payload
is
just
the
the
content
path
right
and
the
action
itself
was
sent
to
you
there.
This
right
there.
B
A
So
we
have
this,
this
perform
on
the
right
one.
So
we
have
this
perform
action
is
the
type,
but
really
what
happens
is
there's
this
payload
and
it
sets
the
action
and
it's
just
a
review,
start
port
forward,
and
then
it's
got
a
set
of
you
know
just
options
that
you
can
pass
in.
So
this
case
it's
the
pod,
it's
all
the
name,
the
port,
that
we
want
to
forward
to
etc.
A
So,
on
the
back
end,
all
that
all
of
that
is
is
all
this
is
to
say
that
on
the
back
end,
what's
happening
is
that
there
is
a
action
with
a
name
and
the
action
name.
Is
this
right
here
overview
a
forward,
slash,
start
port
forward
and
then
inside
the
action
handler
code
which
I
can
I
can
show,
is
the.
A
A
So
here's
here's
the
the
port
forward.
Actually
so
there's
this
action,
name
cool
and
then
we
have
this
handler
and
in
the
handler,
is
where
we
we
go
through
and
yeah.
So
in
this
case
it's
just.
We
pull
all
of
this
information
out
of
the
of
the
payload,
and
you
can
see
here.
We
have,
we
type
check
everything.
So
we
we
try
to
get
the
string.
A
We
try
to
get
the
string
kind,
the
string
name
name,
spaceport
ports
coming
as
a
unsigned
integer
and
then
once
we
have
all
of
that,
we
create
this
port
forward
request
and
then
we
call
our
our
validate
method,
which
ensures
that
does
more
checking
in
more
work.
But
the
main,
the
main
thing
that
was
happening
here
is
that
we
just
map
a
handle
function
to
ID
string,
and
then
we
register
that
with
octant
and
so
plugins
they
get
to
do
the
same
thing
they
it's.
You
know
for
a
plugin.
A
It
essentially
looks
like
plug
in
name
forward,
slash
the
action
name
right
and
it
registers
it
registers
that
action
with
octant
and
then
plugins
can
also
you
know,
have
custom
actions.
So
nice
things
that
get
triggered
in
that
way,
so
that
that's
really
all
there
is
to
actions
that
they're
not
they're,
very
useful
and
very
simple,
which
is
great
so.
A
So
the
action
handler
itself
is
what
is
what
does
so
once
once
octant
has
has
called
this
handler.
It's
up
to
the
it's
up
to
the
action
to
then
implement
what
it
wants
to
do.
So
in
this
case,
that
handle
method
is
really
a
wrapper
around
this
create
for
word
or
method,
and
this
create
forwarder
method
uses
the
kubernetes
api
to
make
a
port
forward
request.
A
All
octants
doing
around
actions
is
saying:
you've
received
a
request
and
here's
the
payload
and
then
what
what
you
do
with
that
payload,
as
as
the
action
is
really
up
to
you,
you
can
call
kubernetes,
you
could
call
some
third-party
service,
you
could
do
whatever
is
necessary
with
the
action
and
then
yeah,
and
then
it's
your
job
just
to
respond
back
with
like
okay,
I'm
handling,
this
or
or
no.
That
was
a
bad
request,
cool
and
it's
usually
assumed
so
actually
the
way
octant
calls
an
action.
A
Is
it
is
it
it
just
calls
it,
and
usually
it's
assumed
that
you're
going
to
return
either?
Yes,
this
was
a
good
request
or
no
was
a
bad
request
and
then,
if
there's
like
long
standing
work
to
perform
or
something
like
that,
you
would
generally
run
a
go
routine
to
that
information
out
and
then
use
an
alert
or
whatever
field.
You're.
Updating
in
the
you
I
would
then
later
have
any
type
of
status,
update
or
error
message,
or
things
like
that
and.
A
So,
let's
see
I
wanted
to
so
that
oh
and
then
plug-in
so
since
we're
talking
about
actions
and
plugins
I
you
can
go.
We
have
an
example
plug-in
that
I
can
go
over
real,
quick,
so
there's
a
few
plugins
on
github
that
folks
have
written
and
as
well
as
some
that
we've
created
just
as
examples
for
testing
things
out.
This
is
our
sample
plugin
that
lives
in
the
repo
with
octave
it
yeah.
Okay.
A
They
have
a
limited
surface
area
in
which
they're
allowed
to
interact
with
the
kubernetes
api
and
the
like,
where
they're
allowed
to
print
things,
but
how
they
print
things,
how
they
render
components.
How
requests
are
handled
internally,
how
they
perform
actions,
is
all
identical
to
things
that
are
internal
to
octave.
So
so,
by
kind
of
knowing
how
plugins
work
and
using
plugins
you
get
a
good
idea
of
how
octant
behaves
and
works
too.
You
can
call
didn't
really
get
a
sense.
A
I
think
the
the
feedback
loop
on
plugins
is
faster
because
you
can
write
a
print.
You
can
write
something
to
do
a
print
like
handle
like
create
a
new
tab
and
you
just
recompile
your
plugin
and
restart
octant,
and
it's
you
know
you
can
instantly
kind
of
see
that
your
your
component
is
rendering
how
you
would
expect,
or
your
card
is
doing
what
you
would
expect.
It's
a
good
way
to
get
a
feel
for
the
streams,
and
it
also
is
nice
because,
when
you're
looking
at
a
plug-in
stream,
let.
A
I,
do
the
one
of
the
benefits
of
using
plugins
is
a
way
to
kind
of
get
a
feel
for
octants.
Is
that
when
you
go
to
like
the
sample
plug-in
here,
when
you
pull
up
and
look
at
the
stream,
the
stream
is
much
it's
it's
much
smaller,
there's
not
a
whole
bunch
of
there's
not
a
whole
bunch
of
extra
information
in
it
yeah.
So
you
can
see
it's
just
the
stream
for
the
plug-in,
and
so
it
kind
of
lets
you
kind
of
explore
and
look
at
streams
without
having
all
of
it
at
once.
C
A
Plugins
can
register
what
they
support,
and
so
what
this
means
is
that
you,
you
take
like
a
GVK
for
a
pod,
and
you
say
that
my
plugin
can
support
either
like,
in
this
case,
printer
config
or
supports
tab.
What
that
means
is
that
if
somebody
goes
and
I
and
I
think
it'll,
it
would
happen
on
the
one.
I
was
just
showing
you,
but
what
it
means
is
that
if
someone
goes
to
the
plug-in
or
if
someone
goes
to
the
pod,
you
will
see
an
extra
tab
from
your
plugin
and
and
what
it
does
is.
A
Okay
and
then
you
can
go
and
do
extra
things
with
that
object,
or
you
can,
if
you
have
some
third
party
API
that
you
that
you're
using
to
map
data
from
from
this
object
type,
and
you
want
to
go
look
it
up
and
you
can
take
this
object
and
go,
do
and
fetch
that
information,
and
then
you
can
display
it
right
in
the
right,
in
the
same
view,
that
octant
is
using
to
display
the
information.
So
you
can
see
here.
A
I
have
this
extra
pod
details,
nice,
that
comes
from
a
plug-in,
that's
awesome,
and
then
on
the
summary
page,
this
right
here,
the
status
that
extent
that
this
comes
these
these
fields.
Here
they
come
from
a
plug-in,
hey,
come
on
and
you
can
see
if
we
just
look.
If
we
just
watch
the
screen,
it's
just
updating
that
that
timestamp,
that's
all
this
plug-in
does,
but
it's
so
this
is.
A
C
A
A
A
B
A
B
A
A
C
Maybe
just
one
thank
to
much
front
side,
so
maybe
just
if
you
can
show
me
how
the
components
UI
components
are
mapped
to
the
this
and
based
on
the
so
what
I
assume
you
have
for
each
one
of
those
cards
and
and
years
you
have
component
and
how
does
that?
Is
it
routed
to
internal
router
or
help?
What
defines
you
layout
in
the
screen?
Yeah.
A
Yeah
I
can
definitely
show
you
how
we,
how
we
do
that
it's
so
we
we
Bey,
we
basically
have
there's
like
the
main
route
of
the
app
which,
if
you
said
you're,
like
you,
said,
you're
already
familiar
with
angular.
So
we
have.
We
have
like
the
main
app
routing
here
and
the
the
main,
and
it's
a
very
simple.
A
It's
very
simple:
there's
nothing
complex
here,
okay
and
then
right
now,
Denali
is
the
electron
app
and
then
sugarloaf
is
what
we,
what
we
call
the
the
the
other,
the
current
web
version
of
octant,
so
the
components
themselves,
in
the
same
way
that
you
saw
there
was
printers
and
components
for
each
of
the
each
of
the
types.
We
also
have
that
on
the
on
the
UI
side
and
the
way
it
actually
gets
mapped
in
is.
B
C
A
A
B
B
A
Have
this
this,
which
I
don't
know
I,
don't
know
about
this
I,
it
works
I!
Think
there's
probably
there
must
be
a
way
to
not
do
this,
but
we
do
it
and
it
works
and
it
spits,
and
so
that's
the
purpose
it
serves
so
right
now
it
when
we,
when
we're
reading
data
off
of
that
stream,
we
look
at
that
metadata
type
and
then
we
go
through
and
we
switch
on
it
and
load
up
each
of
the
each
of
the
types
I
see.
C
A
Yeah
I
I
know
that
that
there
are,
there
is
potentially
some
conflict
with
the
angular
router
and
how
we
do.
We
rely
heavily
on
the
path
with
that
path,
matcher
and
pass
filter
to
determine
what
we
should
load
on
the
back
end
and
I'm,
pretty
sure
that
if
I'm
pretty
sure,
there's
some
complication
or
some
conflict
between
what
the
angular
router
thinks,
the
browser
URL
should
be
and
what
we
need.
The
browser
URL
to
be
to
approximate
load
components
go.
So
that
is
why
that
is
the
reason.
A
This
big
switch
statement
exists,
but
that
doesn't
mean
there
isn't
another
way
or
that,
and
it
also
doesn't
mean
that
this
is
the
worst
way
or
that
this
isn't
the
right
way.
It
just
means
that
I,
whenever
I
see
this
I
think
there
must
be
a
better
way,
but
I,
but
I,
don't
know
for
sure
so
cool
yeah,
and
so
that,
so
that's
how
those
that's
how
those
work-
and
we
have
I
was
gonna
show
one
more
thing.
It
is.
B
A
A
A
C
B
A
It's
not
that
much.
It's
just
there's
a
you
know,
there's
a
lot
of
JSON
and
a
lot
of
objects
and
a
lot
like
I'm,
pretty
sure
that
we
have
to
I.
Don't
know
this
is
true,
but
I
think
that
we
probably
every
time
we
receive
that
stream.
We
probably
go
through
this
whole
switch
statement
right
and
then,
as
it's
going
through
each
switch
statement.
It
goes
there's
no
update
here.
A
A
D
D
A
C
A
So,
on
the
go
side,
we
mostly
used
you
like
on
the
go
side,
it's
pretty
much
all
unit
tests
and
then
on
the
on
the
front
end
side.
We
have
a
lot
of
a
lot
of
our
unit
tests
on
the
front
end
side.
Our
bare
bones
like
make
sure
this
thing
compiles
and
doesn't
have
any
type
errors.
Okay,
they
don't
do
a
lot
of
exercising
of
the
unique
properties
of
any
of
the
of
the
components
we
have.
Some
that
do,
but
I
would
say.
A
Generally
speaking,
most
of
our
front-end
tests
are
very
much
the
minimal
requirement
to
say
you
have
a
test
for
that
component.
We
did
some
work
around
having
some
integration
tests
with
Cypress
and
they
we
need
to
revisit
it.
We
currently
they're
turned
off
because
we
were
getting
a
lot
of
intermittent
failures
and
a
lot
of
like
jitter
type
bugs
where
it
would
pass
one
time
and
then
not
passed
the
next
time,
and-
and
so
we
we
wanted
to-
we
recently
moving
to
github
actions,
and
so
we
wanted
to
kind
of.
A
C
A
Yeah
I
know
Sam
was
seamless
doing
quite
a
bit
of
work
around
that
and
so
I
think
that
I
think
collectively.
We
can
probably
all
come
together
and
figure
out
a
good
solution
for
end
to
end
stuff
and
I.
Think
I
think
another
part
of
this
as
well
that
Sam
and
I
discovered
is
we
were
going
through.
It
was
was
some
of
this
stuff
it's
hard
to
test,
because
it's
not
written
in
a
way
that
is
probably
the
best
for
front-end
stuff
so
like
there
are.
A
A
A
C
A
Now,
typically,
Sam
and
I
talk
to
each
other
and
we
say
hey.
This
is
what
we're
gonna
work
on.
So
we
have
a
weekly
community
meeting
and
that
weekly
community
meeting,
if
anyone
from
the
community
brings
up
issues
that
are
blocking
them
with
related
to
like
plug-in
developments
or
things
that
they're
trying
to
get
done.
We
usually
tend
to
prioritize
those
first
and
then
we
work.
A
And
then
we
combine
that
with
the
community
feedback.
So
as
for
like
what
you
really
it's
like,
there's,
usually
a
theme
of
like
okay.
This
round
we're
gonna
focus
on
plugins,
or
this
round
we're
really
focusing
on
bugs
or
this
round
we're
adding
new
features,
and
that
theme
is
generally
communicated
at
the
community
meetings
and
throughout
the
the
current.
A
You
know,
release
cycle
I
air-quote
release
cycle
because
we
are,
we
were
doing
like
a
two-week
release
cadence,
but
we
that
really
wasn't
as
important
as
it
was
to
kind
of
make
sure
that
we
were
releasing
either
new
new
high-quality
features
or
bug
fixes
more
than
the
cadence
itself,
like
people
really
didn't
care.
So
much
about
us
releasing
every
two
weeks
as
they
did
about
getting
either
a
new
feature
or
the
bug
fix
they
wanted,
and
so
we
have.
We've
introduced
nightly,
builds
which
people
take
advantage
of
now.
A
So
when
we
land
new
fixes,
people
can
go
download
the
latest
nightly
and
and
start
to
use
those
right
away.
The
convenience
of
octant
being
a
standalone
executable
where
you
just
double-click
it,
and
it
goes,
is
that
they
just
download
those
and
overwrite
their
existing
file
as
we
move
forward
with
making
octa
an
application
it'll.
A
Actually,
the
kind
of
the
external
release
schedules
will
even
get
a
little
more
fuzzy
because
we'll
be
doing
in
app
updates,
so
you
won't
like
they'll,
launch
their
client
it
and
it
will
get
an
update
and
fetch
it
and
then
it'll,
refresh
and
they'll
be
updated.
So
the
the
idea
of
a
like
structured
release
around
octave
is
gonna
be
focused
more
on
the
API,
so
the
specifically
the
plug-in
API.
A
B
A
Yeah
so
it'll
be
on
our
eleven
and
we'll
make
sure
that
we
we
highlight
the
fact
that
there's
braking
API
changes
to
the
plug-in
system
as
we
move
towards
1.0.
Our
goal
will
be
to
not
have
breaking
changes
to
the
API
and
only
for
very,
very
good
reason.
Would
we
and
we
will
also
there'll,
be
API?
Changes
will
be.
A
C
A
The
actual
octant
version
will
kind
of
become
fuzzy.
The
plug-in
API
version
will
become
the
the
more
important
thing
and
then
the
yeah.
So
we
do
try
to
release
like
we
will
probably
do
a
release
here
pretty
soon,
just
because
we
have
enough
committed
and
enough
updates
and
fixes
for
folks
that
it's
probably
worth
doing
one
at
early
next
week
and
but
yeah,
that's
kind
of
not
a
they're,
not
like
a
priority
with
respect
to
it
must
go
out.
It's
a
priority
with
respect
to
you.
What's
the
quality
of
it,
I'm
coming.
C
A
Chris
yeah
and
like
what's
in
it
right,
yeah
exactly
so
as
for
you
with
priority,
I
would
say
that
you
can
like
look
at
what's
in
this
print.
Look
just
if
you
look
at
this
end
hub
now
and
look
at
what's
in
the
sprint
backlog
and
kind
of
pick
any
of
those,
and
if
there's
not
a
lot
to
pick
from
right
now,
we
can
definitely
samer
myself
can
definitely
get
you
set
up
on
on
the
right
thing
I
I
I
can
just
you
know,
I!
Think,
there's
a
nothing
in
there,
though,
that
I.
A
Yeah
so
there's
there
some
and
then
and
then
also
the
back
I
would
say
we
we've
done
a
good,
so
our
sprint
backlog
is
all
immediate
things
that
we
know
we
want
to
work
on
now.
The
backlog
is
usually
things.
We
know
we're
gonna
work
on
soon
and
then
the
iceboxes
is
who
knows
things
things
go
from
the
ice
box
to
the
sprint
backlog
based
on
community
priority
as
well
like
we've.
A
A
A
mine
there
yeah
it's
pretty
random.
In
there
we
tried
it
so
Zen
hub
makes
it
very
hard
to
keep
stuff
sorted
by
priority
in
that
column
because,
like
when
you
drag
it
like,
especially
if
you're
like
mid
scroll
on
one
column
and
then
scroll
in
another
column,
and
you
want
to
move
it.
There.
Options
are
kind
of
the
middle
above
some
random
issue
below
some
random
issue
or
wait
a
whole
ten
minutes.
A
While
you
scroll
down
the
whole
list
it
it
may
be,
it
may
be
something
as
we
as
we
wait
like
when
we
get
through
the
rest
of
the
folks
on
the
team.
We
might
want
to
look
into
like
having
a
like,
because
I
assume
that
the
amount
of
bandwidth
we're
gonna
have
to
be
working
through.
Issues
was
gonna,
go
faster
eventually,
and
we
may
want
to
have
like
a
like.
A
We
may
just
want
to
use
ice
boxes
the
backlog
and
then
make
backlog
kind
of
the
prioritized
list,
and
then
sprint
backlog
would
be
the
immediate
and
then
and
then
do
something
where
we're
like.
We
only
ever
like
no
more
than
20
issues
in
the
prioritized
backlog
list,
because
there's
kind
of
no
point
in
going
past
that
there's
just
all
right.
You
know
like
your
prioritize
more
than
than
a
handful
of
issues,
and
eventually
the
priorities
don't
mean
anything.
C
May
have
a
bigger
team
yeah
make
sense
yeah
exactly
so
one
thing
that
don't
make
sense.
Thank
you
so
much
one
thing,
I'm
still
in
a
dark
is
maybe
done.
If
you
guys
don't
have
time,
you
don't
have
to
do
it
now.
Is
this
CRI
CD
how
you
do
that
and
release
they're
better
releases
things
like
that?
Yes,
it's
on
NPM
right!
No,
so,
okay,
so
yeah!
We.
A
Yeah
we
Sam
recently
just
did
a
bunch
of
work
of
converting
our
CI
CD
checks
over
to
actions
so
right
now
all
of
that
happens
to
github
actions.
There's
there's
the
we
do
our
linting,
our
we
verify
generated
code,
and
then
we
have
some
pre-flight
checks
that
happen
across
the
platforms
where
we
do
Mac,
Linux
and
Windows,
and
then
once
once
those
are
confirmed,
then
we
have
this
integration,
build
that
happens
that
ensures
that
all
the
assets
themselves
can
compile
together
and
and
curl
yeah.
A
So
or
did
we
renamed
it
I,
don't
know
what
it's
called
now,
but
essentially
there's
there's
there's
a
bunch
of
linting
that
happens
like
the
linting
happens
at
the
same
time
that
the
that's
the
cross-platform
proof,
preflight
checks
are
happening
and
then
the
same
with
the
verified
generated
code.
So
all
of
that
gets
run,
I
think
there's,
there's
I,
don't
know
twelve
checks
in
total
or
some
fourteen
fourteen
checks
in
total,
and
they
take
about
the
slowest
ones
take
about
seven
minutes
to
run,
but
they
run
in
parallel.
C
A
Yeah
the
standard
way
that
kind
of
work
is
to
fork
octant
and
then
to
you
it
as
a
PR
from
your
from
your
fork.
Okay,
occasionally
we'll
create
an
upstream
branch.
If
there's
something
that's
like
highly
collaborative
where
both
people
are
going
to
be
pushing
commits
into
the
same
branch
kind
of
a
rapid
pace,
then
we'll
then
we'll
create
an
upstream
branch
to
facilitate
that
process.
But,
generally
speaking,
we
we
work
out
of
our
own
branches,
cool.