►
From YouTube: Octant Code Deepdive - Octant Printers - Feb 12, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Really
meaning
piece
of
this
is
officially
well,
it's
still
happening,
but
the
actual
walkthrough
of
agenda
and
priorities,
and
things
like
that
is
done.
So
the
next
thing
we're
going
to
be
moving
on
to
you
is
a
technical
walkthrough
of
the
octant
printers.
Now
this
was
actually
we
have
some
folks
who
are
working
on
making
a
PR
for
PVCs
for
the
four
components
and
they
were
wanting
some
more
detail
about
the
printers.
A
So
I
would
like
to
start
Jordan
if
you,
if
you
wouldn't
mind
kind
of
giving
me
a
brief
like
what
like
do
you
want
a
high-level
walkthrough?
Do
you
want
a
code
dive
like
what
exactly
what?
What?
What
are
you
most
interested
in
around
octave
printers,
how
they
flow
through
octant
or
and
then
I'll?
Take
it
from
there
yeah.
B
Sure
so,
I
for
the
most
part
in
getting
these
persistence
and
volume
claims
linking
back
to
a
persistent
volumes.
That's
going
pretty
well,
and
the
UI
and
components
are
shaping
up.
I.
Think
the
biggest
thing
for
me
is
understanding
kind
of
how
these
printers
are
structured.
It
seems
like
the,
for
example,
a
lot
of
a
lot
of
them
have
like
a
config
and
status,
and
there
seems
to
be
kind
of
this
web
of
functions
that
that
it
crawls
through
to
get
those
components.
B
A
C
A
A
A
All
right
so
I
guess,
there's
there's
a
couple
parts
to
printer's
that
that
get
a
little
confusing,
so
I'll
start
off
with
a
little
bit
of
structure
around
how
octant
works
and
then
we'll
dive
right
into
the
printer
itself.
So
the
the
idea
behind
these
printers
is
that
they
represent
the
output
of
a
component
and
a
component
is
a
generic,
is
just
an
interface.
A
So
in
the
case
of
like
the
persistent
volume
claim
list
handler
printer
this
here,
what
it's
doing
is
is
it
takes
in
the
the
list,
object
and
it
just
loops
through
all
of
the
items
and
packs
them
into
this
table
component
and
returns.
That
out
and
that's
the
thing
about
printer
is
that
that
I
think
is
is
interesting,
is
they're
actually
very
simple,
because
the
only
responsibility
they
have
is
to
generate
a
component
object
that
represents
the
incoming
type.
A
So
in
this
case
it's
the
persistent
volume,
let's
claim
the
thing
you're
working
on
it's
a
persistent
volume.
So
so
the
the
role
of
the
printer
is
really
just
to
take
in
a
kubernetes
object
and
output.
The
visual
representation
of
that
object
has
components
so
internal
octant
components
and
then
later,
that
component
has
the
ability
to
be
marshal
to
JSON.
So
the.
A
B
Yeah
exactly
what
you're
going
through,
where
you're
kind
of
running
through
the
different
functions
here,
it's
the
part
that
I've
been
having
more
trouble
with
following
looking
at
examples
and
like
creating
the
individual,
Handler
and
okay.
It
makes
a
handler
which
has
functions,
that
it
has
a
default
function,
because
it's
following
that
interface
and
those
default
functions
call
other
functions
it
it's
kind
of
a
web
to
me
so
I'm,
trying
to
understand
why
it's
a
format
in
that
way.
Okay,.
A
A
A
A
That
knows
what
the
property
is
of
a
typed
object
when
we
don't
actually
know
the
type
of
the
object
yet
so
we
we
take
this
typed
object.
We
look
for
a
string,
that's
called
something
like
pod
or
PVC,
or
what
and
then
we
from
that
we
then
can
cast.
We
can
let
you
know,
use
use
actual
casting
to
our
reflection
to
convert
the
object
to
our
real
component
type.
A
So
the
reason
there's
all
these
layers
of
indirection
is
because
we
are
working
with
we're
working
with
concrete
types
in
a
generic
way,
and
that
is
just
a
that's
just
a
byproduct
of
go
being
statically
typed
and
us
wanting
to
support
at
the
exposed
interface
a
generic
component,
so
that
we
don't
have
to
have
so
once
once
we
get
out
of
the
once
we're
out
of
the
component
level
and
we're
out
of
the
printer
level.
Now
we're
now.
A
Everything
that
we
pass
around
is
just
a
component
interface,
and
so
that's
that's
why
we
have
all
of
these
layers
now.
The
PVC
one
specifically
is
is
one
that
has
a
lot
of
defaulting
in
it
and
I
think
that
can
lead
to
some
confusion
it.
It
takes
me
a
bit
to
kind
of
rock
it
when
I'm
looking
at
it
as
well,
but
the
main
part
so
like
all
of
this,
where
it's
just
like
default,
config
default
status,
default
pod,
less,
that's
all
there,
because
we
are
just
using
these.
A
A
A
A
D
D
Gymnastics
leading
questions-
sorry,
maybe
maybe
this
could
help
improve.
You
know
new
plug-in
contributions,
because,
if
folks
are
having,
if
you're
having
to
dig
through
to
understand
how
it
all
fits
together,
you
know
Jordan
obviously
had
some
the
same
issues.
I.
Imagine
there's
other
people
that
are
going
through
the
same
thing.
So
all
those
layers
of
indirection
can
definitely
like.
If
someone
is
having
to
get
out
a
piece
of
paper
and
draw
boxes
and
lines
to
figure
it
out
how
it
all
fits
together.
That's
probably
the
smell,
so.
A
So
I
mean
the
I
think
there's
two
different,
there's
two
different
things
we're
talking
about
here.
One
is
what
is
a
printer
and
how
does
it
work
and
then
two
is:
do
we
have
some
printers
that
are
complicated,
so
one
we
have
printers
that
are
complicated.
This
is
an
example
of
one
that
is
complicated.
A
Is
it
worth
the
time
right
now
to
refactor
this
specific
printer?
Probably
not.
The
other
part
is
what
our
printers
and
how
do
they
work,
and
that
was
the
initial
thing
where
it's
like
printers
can
be
as
simple
as
we
make
them,
whereas
what
what
a
printer
does
is
take
a
kubernetes
object,
turn
it
into
components
and
return
a
component.
So
while
I
agree
that
the
this
one
is
complicated
and
could
use
some
improvement,
we
have
others
that
are
newer.
A
That
are
examples
of
things
that
are
not
not
as
complicated
specifically
so
so
this
is
not
a
defense
of
anything.
It
is.
It
is
more.
A
cot
of
there
are
different.
We're
talking,
I,
think
we're
talking
about
different
things.
I
think
our
printers
themselves
are
not
complicated.
I
think
we
have
some
printers
that
are
complicated
and
it.
B
To
help
out
a
little
bit
here,
like
the
PVC
list,
Handler,
where
it
constructs
the
table,
was
super
easy
to
understand
and
replicate
for
PV
for
persistent
volumes
right.
It's
the
the
individual
handler
that
it
started
to
get
complex
so
just
want
to
understand.
If
that
was
something
that
that
needed
to
be
done
in
a
certain
way
and
if
there
were
pros
and
cons
to
it
or
if
it
was
just
a
complexity
thing
in
there
or
other
examples.
Yeah.
A
So
I
mean
the
the
reason
these
map
directly
to
the
to
the
areas
of
the
stream
that
they're
that
they're
updating.
So,
like
you
know,
you
know
if
you're
looking
at
at
a
at
a
PVC.
This
config
here
is:
is
the
config
box
when
you,
when
you're
looking
at
it,
and
this
status
is
the
status
box,
and
this
mounted
pod
list
is
the
mounted
pod
list
box.
A
The
I
agree
that,
like
like,
for
example,
this
config
here
right
these
functions,
these
public
functions,
they're,
easy
to
understand,
I,
I,
do
not
know
fully
I.
Think
I
think
this
is
this
pattern
of
passing
in
the
status.
Config
functions
is
really
just
a
I
mean
it.
Why
is
it
there?
It's
there,
because
it
groups
all
of
these
things
together
and
gives
you
the
ability
to
have
a
default
that
you
could
later
override,
I.
A
Think,
in
our
case,
we
aren't
overriding
it
anywhere,
so
we
don't
take
advantage
of
that,
and
also
in
testing
you're
able
to
pass
in
a
config
func
that
this
public
config
method
wraps.
So
the
if
you
spend
I'm
looking
at
it,
the
the
they
all
every
every
public
facing
method
here,
maps
directly
to
a
component
that
you
see
in
the
front
end
the
abstractions
that
are
there,
where
this
config
wraps
this
config
func,
which
is
part
of
this
struct.
A
Again
most
of
that
is
there
for
ease
of
replacement
and
testing.
It's
a
pattern
that
we've
used
in
other
places
where
it
doesn't
really
get
confusing,
because
the
the
out
there,
those
things
are
so
simple,
I,
think
what's
a
pod.
Is
it
good
so
like
pod,
is
a
good
example
of
one
that
was
refactor
and
cleaned
up
and
you
can
see
the
pod
list
handler
loops
through
items
creates
a
thing
I'm
going
through
this
quickly,
but
because
it's
similar
to
the
the
other
one
but
like
they.
A
D
A
You
are
looking
so
like
if
you're
looking
at
pod
or
even
or
PVC
is
to
go
back
to
that
one,
and
you
are
saying
oh
I,
wonder
where
the
config
comes
from
when
I'm
looking
at
a
PVC.
If
well
it
comes
from
this
config
month
and
then
yes,
there's
another
layer
here
where
you
have
to
go
out
and
say
like
okay,
here's
a
config
function
and
we
we
take
the
output
of
that
config
function
and
we
register
it
right
but
and
register
config
register.
Summary.
A
A
So
it
the
pattern
is
identical
across
all
of
the
printers
and
and
yes,
there
is
some.
The
interaction
is
sometimes
a
little
confusing,
but
I
think
that
it
is
not.
Oh
I
will
say
this
if
you
could
see
how
we
used
to
have
them
set
up
Sam
and
I
refactored.
All
of
these,
if
you
could
see
how
they
used
to
be
yeah,
there's
been
marked
improvements
in
in
the
current
way.
They're
done
there
and
I
can
I'll
expand
on
this
a
little
more
since
we're
here,
there
is
related.
A
D
A
Sure
check,
diagram,
I
think
there
might
be
an
old
one
floating
around
somewhere,
but
there's
nothing
published
the
the
I,
don't
I
think
I'm,
probably
just
doing
a
poor
job
of
communicating.
This
there's
not
really
a
diagram
for,
like
printers,
are
our
kind
of
a
stamp
like
this
is
a
public
function
that
produces.
A
These
methods
that
we
we
create
to
populate
config
status
or,
in
the
end,
in
the
case
of
PVCs,
the
mounted
pod
list.
The
beyond
that.
There
is
no
like,
like
all
of
this
I
love
like
wrapping
wrapping
the
config
func
in
the
status
func
and
passing
it
in
the
the
actual
object
and
the
options
so
that
we
can
register
it
like
that
piece.
There
is
just
our
convention,
yes,.
A
Most
of
these
just
have
like
a
pretty
like
one-line
register
config
registers
that
config
right
like
we
could
probably
do
better
around
these
public
interfaces.
So
that
way,
when
we're
dealing
with
printers
when
you
go,
and
you
look
and
you
say
well,
what
is
this
config
thing
doing
right?
Why
is
it
here
and
when
you
click
on
it-
and
you
end
up
here-
you
can
click
on
register
config
and
get
a
better
I
like
better
idea
of
what
what
this
actually
means.
A
I
think
that
that
is
that
ibly,
a
good
step
for
us
to
take,
but
the
the
actual,
the
actual
abstraction
here
is,
is
just
a
convention
that
we've
we've
decided
to
use
that
that
could
be,
and
these
these
don't
I,
guess
my
point
to
kind
of
help
out
Jordan
and
Andy.
It's
like
these
don't
have
to
be
a
struct
right.
A
It
doesn't
like
this
I
think
before
these
were
all
individual
functions
and
we
called
them
all
separately
in
this
long
list,
and
then
we
just
like
manually,
went
through
and
registered
the
conf
and
registered
the
summary
and
and-
and
so
it's
like
this-
it's
basically
huge
monolithic
function
that
that
was
the
same
size
as
this
file,
but
with
no
like
almost
no
break
in
in
in
the
flow.
It
was
just
like
this
one,
big
monolithic
method
that
did
everything
so
in
an
effort
to
get
rid
of
those
monoliths.
A
We
created
these
internal
interfaces
that
map
the
view
that
you
see
to
what
the
printer
is
generating
and,
again,
that's
purely
a
convention
that
we
that
were
following
so
in
the
example
of
like
your
the
the
PV
component
that
you're
working
on.
That
would
be
something
where
you
would
thought
you
would.
You
know,
I
would
recommend
doing
a
similar
thing
where
you
create
a
config
like
where
you
create
an
internal
interface
that
map's
the
public
areas
of
display
to
methods,
but
how
you
how
those
get
implemented.
A
You
know,
if,
if
you
don't
feel
the
need
to
have
this
struct
that
contains
all
of
the
config
funks,
with
the
object
that
it's
representing
and
pass
it
around.
You
know
the
reason
we
did.
This
was
because
we
could
implement
the
structs,
satisfy
the
interface
and
then
break
out
our
individual
methods
like
into,
but
these
these
smaller
chunks.
So
the
real
work
here
is
is
happening
in
this
method.
E
And
why,
in
the
where
I
had
the
most
problems
and
what
what
Jordan
was
actually
able
to
sell,
was
the
physical
volumes
weren't
coming
up
into
the
cache,
which
is
where
I
was,
which
is
I
tracked
it
down
to
that
point,
and
then
I
got
completely
lost.
Jordan
had
some
experience
with
the
Cooper
nutters
API
and
had
figured
out
that
the
data
wasn't
coming
up,
and
so
he
got
that
part
figured
out
too
so
I
think
some
of
that.
E
How
does
the
data
come
up
from
the
API
line,
wound
up
in
the
cache
and
then
is
referenced
by?
Something
like
a
printers
is
something
that
I
was
unable
to
figure
out
to
be
honest
with
them.
Yeah.
A
Yes,
so
I
think
that's
a
good
point
like
like
having-
and
this
is
actually
I-
did
a
little
when
I
had
a
zoom
with
Milan
that
we
can
share.
That
was
essentially
a
high-level
walkthrough
of
like
how
a
path
in
the
browser
window
flows
through
octant
all
from
how
it
gets
into
octant
how
that
is
turned
into
a
kubernetes
api
request.
How
that
API
request
is
turned
into
you,
its
flowed
into
a
printer,
how
those
printers
are
wrapped
by
describers
and
how
the
describers
return
content
into
the
generator,
which
then
produces
the
content
stream.
A
So
yeah
I
think
you're,
absolutely
right
having
like
a
high
level
so
that
when
something
isn't
happening
so
like
when
you're
writing
a
printer
and
the
value
you
get
is
empty
knowing
where
to
go,
because
when
that
value
is
empty
right
like
that
I
think
is,
is
something
that
we
can
definitely
make
part
of
our
narrative
documentation.
That.
F
So
if
you
are
returning
nothing,
maybe
octant
could
be
a
layer
of
telling
us
why
and
maybe
that
people
contributing
code
Ogden
shouldn't
need
to
ever
think
about
how
to
call
client
go
directly
and
they
just
just
provide
a
key
and
make
it
a
lot
easier
and
not
have
to
make
decisions
on
well,
which
kubernetes
client
they're
going
to
use
to
get
the
object.
They
want.
A
Yep,
that's
a
good
point:
Sam
yeah,
Sam
disc
of
'red
this
through
working
on
some
of
the
plugins
stuff
and
also
with
chatting
with
you
all
about
the
PD
stuff.
So
I
I
do
want
to
make
sure
that
that,
because
I
know
I've
been
jumping
around
and
covering
different
things,
I
want
to
make
sure
that
we
get
any
specific
thing
covered.
A
B
Yeah
I
think
you
definitely
helped
look
like
I
said
I've
been
following
through
some
of
the
other
printers
and
as
an
example,
but
I
wanted
to
make
sure
that
I
wasn't
just
doing
it
for
the
sake
of
doing
it
and
actually
doing
the
pattern
properly
and
understanding
why
it
was
being
used
so
makes
a
lot
more
sense
and
I
and
I
think
you
are
explanation
of
it
will
make
it
easier
to
kind
of
jump
around
and
look
at
where
the
actual
components
are
and
data
is
being
created
or
utilized.
So
thank
you.
A
Yeah
you're
welcome,
and
if
you,
if
you
continue
to
run
into
issues,
you
will
I
mean
your
you
have
been
reaching
out
and
we
really
appreciate
it,
but
yeah
continue
to
reach
out.
You
know
it's
art,
it's
literally
my
job
to
help.
So
it's
it's,
it's
not
you're,
not
trouble
and
you're.
Bothering
anybody
so
yeah,
I
I.
Think
I'm
gonna
create
an
issue
around
documenting
the
the
high
level
like
what
a
request.
However,
request
travels
through
octane
at
a
high
level
and
make
some
call
outs
around
I.
A
Think
it'll
probably
help
for
you
all
to
is
to
have
call-outs
around
what
these
things
mean,
because
we
we
have
like
describers
and
printers
and
modules
and
and
the
generator
and
things
like
that,
and
so
like
having
creating
some
definitions
for
that
language,
so
that
people
know
what
parts
of
the
system
do.
What
will
also
make
it
much
easier
to
navigate
and
and
determine
when
things,
but
when
things
aren't
working
determine
where
the
next
step
is
and
where
you
need
to
go
to
kind
of
make
them
work.
Yeah.
D
Does
it
make
sense
to
have
a
couple
more
like
defense-in-depth
type
bits
of
this
flow
so
that
you
can
actually
catch?
Let's
say:
unhandled
marshaling,
you
know
unknown
type,
either
through
log
messages
or
something
more
fatal
than
that.
A
A
Yeah
and
I
think
that's
that's
something
that
we
can
consider
I.
Think
the
first
step
is
just
a
technical
narrative
documentation
around
here,
you
you're
creating
a
new
component
1.0
and
you'd.
Literally,
it's
just
documentation
that
walks
someone
start
to
finish
through
creating
a
new
component,
because
there
are
going
to
be
new
components
and
kubernetes
that
that
aren't
just
CR
DS
is
going
to
be.
The
API
is
going
to
expand,
there's
going
to
be
new,
concrete
types
and
we're
gonna
want
to
support
them
and
being
able
to
easily
point
someone
to
a
guide
for
here's.
E
A
F
A
general
call-out
on
on
awesome
things,
thank
you
for
the
run
through,
but
also
is
there
something
that
people
just
want
to
see
more
often
like
just
community
kind
of
I,
don't
know
what
to
call
this,
like?
Maybe
community,
not
quite
live
clothing,
but
maybe
just
step
there's
is
like.
Is
this
particularly
helpful?
I
know
we
want
to
get
more
of
this
in
written
form,
but
these
are
kind
of
unique
I.
Don't
I,
don't
know
if
I've
been
around
a
lot
of
other
projects
that
do
this
regularly
well,.
A
E
That
would
be
that
that
would
be
fantastic
for
me
personally,
being
an
introvert
introvert
I
like
to
have
enough
rope
to
shoot
myself
in
the
foot
in
with
you
know,
so
the
amount
of
documentation
that
is
available
that
I
could
take
it
and
go
work
through
these
things
as
an
individual
means
that
I
would
probably
probably
be
less
likely
to
be
on
one
of
these
calls,
but
I
would
still
most
likely
go
just
so
I
could
get
that
information
reinforced.
So
maybe
a
combination
of
the
both
would
would
be
would
be
good
and.
B
For
me,
it
was
very
helpful
because
obviously
I'm
working
on
the
issue
but
I
think
another
thing
that
was
kind
of
the
highlight
is
while
talking
through
it.
We
had
a
couple
actionable
'he's
come
up
and
issues
that
we
think
we
can
create
around
making
documentation
other
things
better.
So
even
if
the
walkthrough
isn't
directly
helping
somebody
solve
an
issue
or
certain
community
member,
it
might
just
highlight
something
that
could
be
better
in
the
future.
If
somebody
jumps
on
it.