►
Description
NOTE - we are aware Derick's video is missing from this clip. We're sorry about that, and will be sure to fix for next week's recording.
Broadcasted live on Twitch -- Watch live at https://www.twitch.tv/nrelabs
A
A
A
A
A
A
A
A
A
A
A
It
was
great
when
we
launched
it,
but
these
things
tend
to
stagnate
over
time,
so
I'm
I'm
working
on
those
I
want
to
I
want
to
share
an
update
on
on
some
some
conceptual
diagrams.
That
I
think
will
help
actually,
with
with
the
conversation
that
you
just
touched
on
there,
like
the
the
relationship
between
and
every
labs
and
antidote,
and
all
that
stuff,
so
I
think
that'll
help
and
then
there's
another
tool
that
the
savvy
among
you
probably
already
know
about.
A
But
but
we
haven't
really
done
any
marketing
around
it
like
we
haven't,
talked
about
it
because
it
because
of
a
few
of
a
few
things-
and
that
is
the
the
validation
tool
for
first
syringe,
which
is
one
of
the
backend
component
and
I'll
get
into
what
what
that
means
and
why
you
care,
but
in
but
but
before
I
touch
on
any
of
that.
What
is
there
any
from
a
community
perspective?
Derek?
Is
there
anything
you
want
to
touch
on
before
we
dive
deep
into
the
weeds.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
We're
gonna,
if
we're,
if
we're,
if
we're
not
careful,
we're
very
soon
we're
gonna
have
a
lesson
on
tabs
bases
like
that's
what,
if
that's,
what
the
less
it
is
gonna
be
it's
gonna,
be
two
people
contributing
arguing
with
each
other
over
code
and
they're
just
going
to
commit
the
results.
I
have
to
learn
from
somehow.
A
A
A
A
A
A
Yeah
yeah,
that's
fair!
In
fact,
I
can
answer
that
last
one
pretty
easily
in
a
bit
of
murder
for
a
while
and
I
actually
have
made
a
good
dent
in
one
of
them,
because
they're
all
fairly
large
I
just
haven't
finished
yet
so
we'll
I'll
sort
of
highlight,
what's
been
done
and
what's
currently
in
progress
and
effectively
just
reiterate
that
I'm
working
on
getting
them
merged,
but
before
that
at
least
share
my
screen
I
want
to
I
want
to
show
diagram
very
briefly
for
those
that
have
seen
me
present
on
NRA
lads.
A
You've
probably
seen
something
like
this,
and
it's
modified
it
briefly,
because
I
in
lieu
of
a
more
a
more
I,
just
I,
literally
just
hacked
this
existing
diagram
into
place,
to
show
what
I
wanted
to
illustrate
and
I'll
be
I'll,
be
putting
something
a
little
more
formal.
Looking
on
the
on
the
docks,
but
basically
I
wanted
to
highlight
the
relationship
between
the
curriculum
in
the
platform.
A
So
when,
when
toad
talked
about
how
we've
open-sourced
all
of
the
tooling
and
all
of
the
all
the
software
behind
behind
what
makes
entering
labs
work,
he
what
he's
referring
to
there
is
is
these
platform
elements.
We
have
a
piece
of
software
called
syringe
which
sits
behind
the
scenes.
Doing
things
like
scheduling
lessons.
So
when
you,
when
you
call
up
a
lesson,
there's
actually
an
API
that
gets
called
Matt
API
belongs
to
syringe
and
then
syringe
says:
okay.
A
Well,
it
looks
like
you're
looking
for
less
than
eleven
and
I
see
in
in
the
lesson
definitions,
I've
been
configured
with
I,
see
that
lesson
11
requires
you
know
three
vqf
X's
in
a
utility
container
and
it
needs
to
be
configured
this
way
and
there's
all
kinds
of
lesson.
Details
that
are
in
are
in
those
lesson,
definitions
and
what
it
does
is
it
turns
around
and
it
pushes
it
sends
API
calls
to
kubernetes
to
make
all
of
that
stuff
work.
A
So
that's
what
syringes
and
then
antidote
web
is
effectively
what
you
would
expect
in
a
traditional
like
HTML,
CSS,
JavaScript
web
front-end
kind
of
application.
So,
with
a
slight
modification
that
there's
a
little
bit
of
Java
behind
the
scenes
that
runs
in
a
servlet,
you
don't
see
that,
but
it's
it's
what's
required
to
make
the
the
SSH
terminal
in
the
that's
in
the
that's
in
the
browser.
A
Guacamole,
that's
what's
required
to
make
that
work,
but
with
a
vast
majority,
vast
vast,
vast
majority
of
the
logic
is,
is
all
front-end
Java
and
then
you
know
your
your
typical
HTML
and
CSS
stuff
I.
Think
there's
like
20
lines
of
Java
I
wrote
as
little
Java
as
possible,
as
was
required
by
the
project
guacamole,
so
most
of
that
stuff's
in
the
front-end
anyway.
Those
are
the
two
component
there's
a
few
other,
like
really
smaller
components
that
we
use
in
that
from
a
platform
perspective,
most
of
which
are
optional.
A
Like
we
do
some,
we
do
some,
like
you
know,
TS
DB
stuff
like
within
flux,
but
like
that's,
not
required
for
the
platform.
So
the
main
two
components
are
here:
syringe
and
init
at
web.
So
when
we
talk
about
the
platform
antidote,
what
we're
talking
about
are
these
two
components.
We
use
this
term
antidote
to
describe
the
open
source
platform.
It's
it's
behind
the
scenes.
It's
really
an
umbrella
term.
A
It's
meant
to
encapsulate
anything
that
goes
into
this
platform
that
makes
the
platform
work
now
you'll
you'll
notice
that
the
curriculum
is
actually
a
separate
tier
to
this
and
I
spoke
about
this
in
the
network
field.
Day
presentation,
I
did
where
I
showed
these
slides
a
few
month
or
two
ago,
almost
at
least
a
months
ago,
where
I
highlighted
the
fact
that
the
curriculum
is
actually
separate.
A
What
we've
done
is
we've
disaggregated
the
the
curriculum
so
that
it's
not
baked
into
the
platform
itself
and
I
wrote
a
blog
post
on
this
well
over
a
few
months
ago,
a
few
months
before
NFD.
In
fact
talking
about
the
idea
of
doing
curriculum
as
code,
which
sounds
super
buzzword
II.
But
it's
actually
true.
What
we've
done
is
we've
taken
the
abstraction,
that's
offered
by
syringe
and
and
allowed
folks
to
describe
lessons
in
simple
text
files.
A
So
there's
a
yellow
file
that
you
use
to
describe
a
single
lesson
and
then
there's
a
whole
bunch
of
other
files
that
are
required.
Based
on
what
you
have
in
the
lab,
like,
for
instance,
you
know,
you'll
need
a
lab
guide,
which
is
a
markdown
file.
You'll
need
some
Juno's
configuration
files
if
the
device
that
you're
configuring
is
Juno's.
Of
course
things
like
that.
A
So
there's
a
bunch
of
things
that
are
required
in
those
in
those
lesson
directories
but
they're
all
text
files,
there's
no
like
database
that
you
got
to
interact
with
or
GUI
that
you
got
to
drag-and-drop
things
around.
It's
all
stored
and
get,
and
the
cool
thing
about
that
is
what
we've
done
is
we've
we've
we've
put
up
a
you
know
in
the
antidote
repository
we've
put
up
a
set
of
lessons,
and
you
know
every
lesson:
CNN
re
Labs
is
in
that
directory.
And
what
worked?
What
we're
doing
is
we're
calling
that
NRI
Labs.
A
That's
what
NRI
Labs
is
it's
a
directory
that
contains
all
of
the
lessons
that
you
see
in
NRA
labs,
because
really
what
this
is
is
is
NRI.
Labs
is
really
a
curriculum.
Yes,
it's
a
website
and
it's
sort
of
the
canonical
like
it's.
It's
the
way
that
who
were
proving
out
these
concepts.
It's
the
sort
of
the
the
the
the
the
golden
showcase,
I
guess
of
of
of
the
antidote
platform,
but
it
really
is
just
that
NRI
Labs
is
really
just
one
curriculum,
that's
possible!
A
You
could
build
your
own
totally
separate
curriculum
with
its
own
resources
and
own
lessons
and
own
collections
and
all
kinds
of
stuff
like
that,
and
just
simply
put
it
into
this
fight
this
space
that
energy
labs
would
normally
fill,
and
it's
it's
built
into
syringe
to
allow
you
to
do
that,
and
so
I
want
to
highlight
that,
because
we're
gonna
be
actually
moving.
Some
things
around.
A
You
know
we,
if
you're
using
NRA
labs,
it'll,
be
transparent
to
you
it'll,
if,
if
you're
contributing
to
energy
labs
it'll
be
a
little
different,
but
it
won't
be
that
bad,
where
we're
actually
gonna
be
giving
the
NRA
labs
curriculum
its
own
repository,
because
right
now
it's
sort
of
sharing
a
repository
with
a
whole
bunch
of
infrastructure,
tooling
and
stuff
like
that.
So
we'll
be
moving
things
around,
and
this
is
way
in
the
future
weeks.
A
At
least
so
I'll
be
will
be
sending
us
some
detailed
information
on
what's
moving
where
that
way,
if
you're
working
on
a
PR
or,
for
instance,
for
the
curriculum
you'll
know
what
to
do.
But
this
is,
this
is
what's
been
on
my
mind.
A
little
bit.
I
want
to
move
these
things
around
a
little
bit
so
that
they
make
a
lot
more
sense
with
how
they
actually
work
in
the
real
world.
A
A
A
A
Yeah
I
mean
the
the
the
way
that
I
would
the
way
that
I
would
talk
about.
That
is
like
if
you,
if
you're
using
something
like
story,
becomes
a
little
easier
because
you
don't
have
to
automate
joining
when
you
scale
up
a
cluster,
you
don't
have
to
automate.
You
don't
have
to
do
anything
yourself
by
by
virtue
of
automation,
to
join
those
new
nodes
into
the
cluster.
A
It's
all
handled
for
you,
whereas
in
this
realm
you
kind
of
do
because,
because
GCE
doesn't
have
any
opinion
on
how
the
VMS
are
actually
configured
it,
just
it
just
has
an
opinion
on
on
that
they
exist
and
that
they're
sized
appropriately.
So
that
could
be
automated.
You
can
say
certain
things
like
you
know,
hey.
If
my
you
know,
if
I
CPU
a
you
know,
it
goes
over
a
certain
a
certain
amount.
For
you
know,
cluster
cluster
wide
yeah
and
I
mean
cluster.
Just
like
a
cluster
of
VMs
cuz
again
in
GC.
A
A
So
these
are
this:
is
that
and
I
the
the
n
see
that
n
is
for
the
namespace,
so
in
our
in
our
kubernetes
cluster?
This
is
what
we
recommend.
People
do
if
they're
deploying
it
themselves.
We
have
all
of
these
all
of
the
pods
deployed
within
namespaces,
so
the
prod
namespace
hosts
the
production
instance
of
antidote,
which
is
what
you
see
when
you
go
to
any
labs.
We've
got
an
Ingenix
ingress
controller,
which
monitors
all
of
the
ingress
rules
across
the
cluster
and
makes
changes
accordingly
in
routes
routes,
routes
web
traffic.
Accordingly.
So
that's
that's!
A
Actually
what
you?
What
you
hit?
It's
a
set.
It's
actually
the
second
load.
Balancer
you
hit
when
you
go
to
the
site.
The
first
one
is
a
Google
load
balancer,
but
that's
mostly
a
pass-through.
The
way
we
have
that
configured
is
just
simply
send
all
traffic
to
the
hood
to
the
kubernetes
cluster
and
then
the
next
thing
that
receives
the
traffic
is
this
ingress
controller
and,
unlike
I
said
we
have
some
optional,
optional
things
here,
like
pure
fauna
and
influx
DB
for
some
stats
tracking,
but
that's
not
required.
A
A
Mm-Hmm
yeah
yeah
based
basically
yeah
correct.
The
real
difference
between
them
is
that
is
that
a
pod
doesn't
just
it
usually
does,
but
it
doesn't
have
to,
in
fact
all
of
our
pods.
If
you
look
at
the
syringe
pod,
for
instance,
this
is
a
pretty
common
way
of
doing
this
and
I
think
let's
do
instead
of
get.
Let's
do
a
describe.
A
You'll
see
that
there
is
one
container
here
called
syringe
and
you
can
see
that
it's
configured
with
a
bunch
of
environment
variables,
just
like
you
would
be
able
to
do
like
if
you're
running,
docker,
locally
and
and
the
image
that's
running,
is,
is
a
MATLAB,
slash,
syringe
and
then,
of
course,
the
release
tag
because
we're
doing
things
in
a
CI,
CD
kind
of
fashion,
which
is
good.
So
that's
all
expected,
but
if
you
go
above
that,
actually
you'll
see
get
clone.
A
A
A
A
Yeah
sure
so,
the
and
and
I
think
this
is
actually
a
really
segue
how
behind-the-scenes
and
and
makes
everything
really
makes
everything
work
I
mean
the
web.
Front-End
is
cool,
but
the
if
we
were
to
point
to
a
thing
and
say
like
this
is
the
brains
of
antidote
like
it
would
definitely
bridge
the
vast
majority
of
the
logic
of
how
everything
works
is
in
syringe.
A
So
you
don't
have
to
actually
do
that
if
you're,
if
you're
a
user,
but
you
send
the
API
call
in-
and
it
says,
hey
I'm
going
to
spin
up
a
lesson
and
all
these
things
happen.
It
has
fairly
strong
opinions
on
how
those
lessons
should
be
formatted
it.
What
what
we
actually
do
behind
the
scenes
is,
you
can
see
that
we're
running
G,
RPC
and
then
rest
on
top.
A
very,
very
common
way
of
deploying
REST
API
is
at
least
these
days
within
a
go
based.
A
Application
is
to
define
that
API
as
G
RPC
instead
of
rest
and
so
like
there.
It's
it's
not
always
that
way
like
there's
a
lot
of
folks
that
just
build
rest,
only
API
is
first
for
go
applications,
but
an
increasingly
popular
way
of
doing
it
is
to
to
build
your
API
in
G
RPC,
instead
I'm
using
something
called
protobufs
which
we'll
get
into
and
then
use
a
small
sort
of
project
called
G,
RPC
gateway
to
effectively
proxy
between
HTTP
and
G
RPC.
A
A
We
have
a
pup,
we
haven't
published
them,
but
but
you
know
if
people
want
to
integrate
directly
with
the
syringe
API.
Certainly
that's
something
we
can
look
into
publishing.
We
just
it's
just
something
that
we,
if
you
want
to
see
the
swagger
Doc's,
you
certainly
can
see
them.
You
just
have
to
compile
syringe
yourself.
We
haven't
like
published
the
result
of
those
those
Doc's
anywhere,
because
again,
the
vast
majority
of
people
don't
really
integrate
with
the
syringe
API.
A
They
call
it
via
the
web
front-end
that
they're
simply
interacting
with
but
we'll
see,
we'll
see,
we'll
see
if
there's
interest
there.
Certainly
the
the
tooling
exists
so
anyway,
the
reason
I
bring
all
of
that
up
is
not
to
about
the
disk
or
you
know
horrid,
like
super
confusing.
Looking
diagram
I
just
wanted
to
call
attention
to
the
fact
that
everything
in
syringe
is
modeled.
So
when
you
talk
about
things
like
lesson,
definitions
and
I'll
just
bring
the
next
slide
up.
You
can
see.
This
is
a
lesson
definition.
A
Yeah,
what's
that
it's
an
image,
I'll
just
go:
let's
go
to
a
real
one,
pick
two
food!
There
we
go;
okay,
that
might
be
a
little
too
big.
So
if
we
go
to,
let's
see
lessons
lesson:
12,
I'll,
I,
love
to
pick
on
lesson
tall
first,
one
in
the
directory
and
I
know
that
it's
the
J
snappy
one
by
memory,
I,
don't
dream
about
energy
labs
at
all
a
little
better.
A
So
this
is
a
lesson
definition.
So
it's
just
one.
This
is
just
the
actual
lesson
definition
for
the
j
snap
ulis.
You
can
see
that
there's
a
lesson,
a
lesson:
ID
categories
tools,
it's
the
the
category
that
we're
working
with
it's
a
moment,
optionally.
You
can
specify
a
lesson,
diagram,
there's
a
whole
bunch
of
other
metadata.
You
can
specify
and
then
inside
the
lesson.
A
You
also
want
to
specify
things
like
what
kind
of
end
points
there
will
be
they're
all
there
will
be
utilities,
so
things
like
little
Linux
containers
that
have
tools
that
you
want
to
execute
scripts
and
things
of
that
nature
devices.
So
these
are
our
V
key
effects,
devices
the
difference
being.
What
syringe
will
actually
do
for
devices
as
opposed
to
anything
in
the
utility
section?
Is
it
will
use
napalm
to
attempt
to
configure
those
devices
for
each
lab
that
you
go
to,
and
so
as
a
result,
and
in
order
to
know
how
to
do
that?
A
There
needs
to
be
in
the
lesson
director
here
stage:
one
configs
you'll
see
vqf
x1,
dot,
txt
the
effects
to
dot,
txt
and
so
forth.
So
all
of
those
things
need
to
be
there
each
one.
Each
each
lesson
guide:
oops
I
lost.
Where
was
shoot
there
we
go
each
a
lesson
guide
is
here
as
well
in
in
each
lab
directory,
and
you
can
also
see
you
can
also
see
that
there
are
a
few
other
files
in
the
directory
acquired
but
they're
just
part
of
this
lesson,
so
you
can
put
them
in
there
again.
A
The
cool
thing
about
the
way
that
we've
built
this
in
the
backend
is
every
every
pond
we
spit
up.
We
clone
the
entire
lesson
directory
into
that
pod,
and
so,
if
you
wanted
to
interact
with
something
in
the
lesson
you
just
simply
put
it
in
the
repo
and
it'll
be
made
available
to
you
at
runtime,
which
is
pretty
cool
so
anyway,
it
all
starts
with
this
lesson
definition.
So
everything
everything
that
you
need
to
declare
a
lesson
definition
is.
It
starts
with
this
syringe
ml
file.
Now
it's
not
just
limited
to
that.
A
For
instance,
like
I
said
there
are
a
few
things
here
that
are
not
required.
Like
tags,
that's
actually
not
or
not
a
required
field.
Lesson
diagram,
also
totally
optional.
You
don't
have
to
specify
that.
However,
a
lesson
ID
is
very
much
required,
as
is
the
lesson
name.
Even
there
are
a
few
other
things
that
are
required,
and
then
there
are
a
few
other
like
kind
of
second-order
requirements
like,
for
instance.
This
is
one
thing
that
I
that
I
made
sure
to
validate
or
recently,
if
you
have
devices,
not
all
lessons
have
network
devices.
A
Some
of
them
are
just
simple
Linux
containers
that
you
use
to
like
learn
how
yam
will
work.
So
not
everything
has
this.
So
having
devices
isn't
required,
but
if
you
do
have
devices
in
your
lesson
definition,
then
you
absolutely
need
to
have
configurations
for
them.
Because
again,
what
syringe
will
do
in
between
every
lab
is
it
will
see?
Oh
I
have
a
VQ
fx1
I
need
to
go.
A
A
So
what
we've
done
is,
if
you
look
at
the
syringe
repository
I'll
show
you
a
little
bit
behind
the
scenes,
but
this
is
not
something
you
need
to
know
to
run
this.
We
defined
everything
in
protobuf.
So
if
you
look
at
the
lesson,
death
dot
proto,
you
can
see
the
the
lesson.
Definitions
fields
are
all
here
and
we
do
some
basic
validation
here
like,
for
instance,
the
tear-filled
has
to
be
one
of
these
three
values:
local
PTR
and
prod.
A
There
are
a
few
other
things
like
minimum
lengths
has
to
be
at
least
ten
things
like
that.
That's
really
easy
to
validate
we're
using
a
project
that
lyft
built.
Incidentally,
to
do
that,
so
that's
pretty
cool,
but
beyond.
Just
that
simple
validation.
We're
also
doing
those
other
validation
steps
like
making
sure
that
making
sure
that
every
network
device,
these
specify
has
a
correspondent
config
for
every
for
every
lab
that
you
want
to
spit
up.
That's
not
something
we
can
capture
here.
We
have
to
actually
write
code
to
validate
that.
A
However,
you
know
running
the
server
version
of
syringe.
Isn't
something
you'd
normally
would
want
to
do
on
your
laptop,
because
you'd
have
to
configure
a
whole
bunch
of
other
stuff.
You
know
where
you
know
put
point
me
to
kubernetes.
You
know
point
me
to
a
whole
bunch
of
other
things
that
you
need
that
you
need
access
to
in
production.
A
What
would
be
cooler
is
if
we
could
run
that
same
validation,
logic
locally,
as
opposed
to
requiring,
like
the
whole
server
deployment,
that
the
syringe
D
requires,
and
so
we've
had
this
tool
called
sy
our
CTL
for
a
while.
Actually,
but
again,
there
haven't
been
a
lot
of
usefulness
outside
of
really
mean
just
because
mostly
was
what
sy
our
CTL
been
doing,
is
managing
the
state
of
syringe.
So
it's
more
of
like
a
behind-the-scenes
tool
for
really
for
me
or
anybody
else
that
wants
to
run
their
own
version
of
syringe.
A
All
I
have
to
do
is
type
sy,
our
CTL
validate
and
then
the
lessons
directory
and,
as
you
can
see,
it
imports
all
of
the
lessons
in
that
directory,
and
it
says
you
know
all
the
text
and
lesson
files
imported
successfully.
So
you
have
confidence.
Let's
say
this
is
your.
Let's
say
you
fork
the
antidote,
repo
and
you're
working
on
a
contribution.
You
want
to
know
that
your
lesson
was
imported
successfully
without
without
errors
and
so
you'll
be
able
to
see
that
here,
you'll
see
that
hey
look
all
the
lessons
have
imported
correctly.
A
A
A
A
Is
it
won't
just
crap
out
it'll
just
skip
a
lesson
that
failed
the
validate
that
way
when
we're
running
a
production,
we
don't
you
know,
we
don't
have
to
have
everything
perfect,
it'll,
it'll,
just
simply
discard
any
lessons
that
fail
to
validate
and
it'll
continue
to
start
with
the
lessons
that
is
successfully
validated,
but
you
can
scroll
up
and
you
can
see
the
output
says:
hey
configuration
for
device,
vqf
x1
for
stage
1
was
not
found
and
I
should
be.
I
should
be
outputting.
A
A
A
Okay,
hopefully
I'll
remember
what
that
means
so
anyway,
the
the
the
reason
this
is
valuable.
It.
Let's
say
you
go
down
the
path
of
like
looking
on
trying
to
contribute
a
lesson.
Very
often,
what
will
happen
is
like
yeah.
Of
course,
we
still
have
self-medicate.
We
talked
about
that
on
the
first
stream.
That's
that's
valuable!
There's
the
this
isn't
meant
to
replace
anything
that
self-medicate
does.
A
The
problem,
though,
is
is
that,
in
order
to
know
that
a
lesson
has
failed
you,
you
absolutely
have
to
spit
up
self-medicate,
which
again
you
you
totally
should
before
you
submit
a
pull
request,
but
when
you're
very,
when
you're
very
early
on
developing
a
lesson
content,
it's
a
little
much
to
have
to
spit
up
self-medicate
like
right
away
before
you
even
really
get
started.
Because
again,
if
you
don't
have
any
other
way
to
know
that
your
lesson
is
valid,
it's
kind
of
your
only
option.
A
What
would
be
cool
is
if
you
had
a
simple
tool
like
this,
for
the
very
early
portions
of
your
lesson.
You
you
you
just
starting
to
put
the
lesson
definition
in
place
and
put
it
put
the
right
configs
in
place,
and
you
just
want
to
you
just
want
a
basic
check
as
to
what
what's
required.
You
know.
Maybe
your
lesson
guides
aren't
written
at
all,
but
you
want
to
know
like
that.
You've
put
the
lesson
guide.
A
The
blank
lesson
guides
bare
bones:
lesson
guides
in
the
right
place
at
the
very
least,
or
that
you
have
the
configs
in
the
right
place.
At
very
least
this
is
a
cool
tool.
I
think
a
valuable
tool
for
early
on
in
that
contribution
life
cycle,
because
it's
a
and
I
think
the
real
point.
The
the
real
reason
for
that
is
is
it's
very
lightweight.
It
doesn't
require
any
dependencies.
You
can
just
download
the
pre
compiled
version.
You
could
compile
it
yourself
if
you
want,
but
a
lot
of
people
don't
want
to
do
that.
A
No
sorry
I
just
want
to
touch
on
one,
and
that
is
how
to
yell
you,
okay,
here's
how
to
guess
the
sy
our
CTL
did:
I
get
it
okay.
This
is
one
thing
I
want
to
touch
on.
So
if
you
go
to
the
syringe
repository-
and
this
will
again,
this
will
be
something
that
we
linked
to
in
the
docs.
But
if
you
go
to
the
releases
a
section
here,
what
we've
done
is
we've
incorporated
I
built
automation
into
into
our
release
process.
I
spent
a
lot
of
time
over
the
last
week.
A
Enhancing
the
release
process
for
antidote
and
one
of
the
in
one
of
the
enhancements
I
made,
was
compiling
syringe
for
ever
release
and
then
uploading
those
those
compiled
versions
to
the
to
the
actual
release
itself,
and
so
all
you
have
to
do
is
go
to
this
page
to
go
to
the
latest
release.
I
think
this.
This
actually
has
a
link,
yeah,
syringe,
slash,
releases,
slash
latest
and
find
the
platform
for
you.
So
if
you're
running
a
Mac,
it's
gonna
be
Darwin
like
amd64.
A
A
So,
if
you
grab
those,
there
are
two
binaries
in
each
of
those
syringe
D,
which
again
you
can
use.
If
you
want,
but
that's
not
really,
you
know
it's
not
required.
You
can
delete
it
if
you
want
but
sy.
Our
CTL
is
also
in
there
put
that
in
your
you
know
your
bin
directory
or
anywhere
else
you
want
and
then
just
simply
run
it.
A
A
A
A
A
A
A
Oh,
certainly
yeah
I
mean
the
firt,
like
you
can
think
of
it
as
like
three
stages
of
validation.
The
very
first
is
just
basic
amal,
so
we're
using
the
the
standard
library
you
know,
gamal
parser
in
go
to
just
simply
import
all
of
this
content
from
a
yamo
perspective
into
a
ghost
struct,
which
is
actually
automatically
generated
because
of
the
way
we're
doing
protobufs.
But
basically
that's
the
first
step
like
it
needs
to
be
valid
EML
for
sure
the
next
step
is
feel
based.
A
You
know
from
a
field
perspective,
we've
decorated
each
of
those
fields,
not
all
of
them,
but
a
lot
of
them
with
certain
things
like
you
need
to
be
an
integer
or,
if
you
or
even
more
to
that,
even
more
than
that,
you
need
to
be
an
integer
greater
than
X.
Something
like
that.
So
that's
like
the
second
layer
of
validation
and
the
third
one
is,
is
the
more
deep
validation
like
I
showed
you
before,
where
we
deleted
the
config
and
the
code
behind
the
scenes
says:
hey,
you
need
to
config
for
this
stage.
That's
anything!
A
A
A
A
A
A
The
reason
we
had
that
before
was
we're
actually
passing
that
into
the
the
CNI
network
configuration
so
the
way
that
the
networking
works
in
kubernetes
is
via
a
plug-in,
a
CNI
plug-in,
and
it
requires
a
subnet
to
be
specified
in
that
field,
trying
to
figure
out
where
I
changed.
The
actual
configuration
I
thought
it
was
here.
A
Well,
it
preview
it
previously.
You
did
like
I,
said
I
wanted
to
I
wanted
to
I
wanted
to
expose
that
field
into
the
network
addition,
but
to
your
point
from
from
a
from
a
lesson
perspective:
it's
not
really
required.
It's
just
required
because
we
at
that
at
that
time,
we're
passing
it
through
to
the
network
configuration
for
CNI.
A
So,
even
though
you
specify
you
know
I'm
specifying
something
like
I,
don't
know,
10.000
slash,
eight,
something
like
that
behind
the
scenes
it
doesn't
matter
because
because
it's
not
actually
like
enforced
from
a
firewall,
but
it's
not
like
filtering
only
on
that
subnet,
you
can
still
specify
any
IP.
You
want
on
the
actual
devices
like
your
VQ,
FX's
and
whatnot,
and
so
it's
just
taking
one
more
thing
out
of
the
out
of
the
out
of
the
requirement
to
be
specified
in
the
lesson
definition.
A
A
A
A
A
A
A
A
A
A
Yep
yeah
and
to
be
clear,
there
are
a
few
things
that
it
doesn't
figurations
are.
We
might
you
know
we
could
maybe
build
some
basic
parsing
in
there,
but
the
end
of
the
day,
like
you're
still
gonna,
have
to
run
this
in
self
run
your
lessons
in
self
medicate
to
make
sure
that
you
know
things
are
pinging
and
like
the
configuration
is
where
you
want
it
to
go.
A
Your
it's
gonna
need
to
meet.
You
know
your
you're
going
to
need
to
use
that
to
make
sure
things
like
line
up
visually
and
like
all
kinds
of
stuff
like
that,
so
there
is
a
limitation
to
what
this
will
validate
but,
like
I,
said
I
think
early
in
the
process.
It's
super
valuable.
You
don't
even
have
to
start
self
medicate
right
away
if
you,
if
you're,
just
launching
into
starting
you
know,
building
one
lesson,
don't
even
bother
just
start
to
assemble
the
files
and
use
this
s.
A
Why
our
CTL,
validate
command
to
to
you
know
light
your
pass
as
you
as
you
continue
to
go
down
there
and
once
you
have
a
valid
lesson,
start
self,
Medicaid
and
start
putting
the
finishing
touches
on
one
more
thing
just
want
to
touch
on
so
sy.
Our
CTL
itself
is
just
a
come
in
is
really
a
man
line
utility.
A
A
You
Oh,
so-so,
syr,
CT
I'll,
just
to
reiterate
s1r
CT
l
is,
is
the
command-line
utility
for
basically
any
contributor
to
antidote.
The
validate
self
command
is
just
one
piece
of
functionality
that
we've
built
into
it.
Like
I
said
there
are
other
sub
commands
that
have
existed
actually
for
a
couple
months.
They've
really
just
mostly
been
useful
to
me.
So
that's
why
we
haven't
really
talked
about
syr
CT.
All
that
much,
however,
now
that
we
have
this
one
use
case
for
doing
things
beyond
just
like
what
I
want
to
do
like
it's.
A
The
validate
functionality
is
very
useful
for
contributors,
we're
thinking
about
other
contributor
functionality
that
we
can
introduce
into
this
tool.
You
know
now
that
there's
at
least
one
use
case
we're
gonna
be
building
other
cool
things
into
it.
For
instance,
maybe
an
interactive
wizard
for
building
new
lessons
like
if
you
just
want
to
like
go
through
an
interactive,
wizard
and
and
supply
some
information
via
the
via,
like
an
interactive
like
prompt
and
and
have
it
automatically
generate,
like
all
of
the
files
and
lesson
directories
that
are
needed
to
to
start
a
new
lesson.
A
That
way,
you
don't
have
to
create
it
from
scratch
or
copy
from
an
existing
example.
That's
something
we're
thinking
about
doing
so,
basically
going
forward,
don't
think
of
sy,
our
CTL
is
just
simply
a
way
of
doing
validation,
because
that's
just
one
sub
command,
you
can
think
of
sy.
Our
CTL
is
like
you're,
your
friend
through
the
quest
of
contributing
to
energy
labs
and
we're
going
to
be
building
more
functionality
into
that.
As
time
goes
on,.
A
A
A
A
You
know
that's
funny,
you
brought
that
up,
I
didn't
think
so,
but
we
had
some
some
folks
in
turtle
juniper
that
we're
using
self
Medicaid.
They
ran
to
some
issues
with
the
latest
lick
very
latest
version
of
mini
cube,
and
they
were
reporting
that
they
fixed
it.
By
going
back
to
the
version
that
I
happen
to
be
running,
which
is.
A
A
A
But
the
very
first
thing
you
should
do
is,
if
you
have,
if
you're,
having
problems
check
to
see
if
there's,
if
there
are
commits
to
that
repo,
because
usually
when
we
fix
something,
we
push
it
right
away,
and
so
it
helps
to
have
the
latest
version
of
self
Medicaid
in
the
future.
We're
going
to
be
versioning
self-medicated,
so
it
so.
We
know
that
the
existing
the
existing
releases
are
more
or
less.
You
know
stable
we're
not
doing
that
at
the
moment.
We
need
to.