►
From YouTube: Community Standup: 6/11/19
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).
B
We
apologies
that
Lisa
and
I
we
saw
there
was
a
different,
a
different
link
in
in
our
for
some
reason.
In
the
meeting
invite
we
had
organized
for
us
to
be
on
the
call.
There
was
a
different
zoom
link
than
the
one
that's
in
the
community
post
and
we
clicked
the
we
clicked
the
one
in
the
calendar
thinking
they
were
the
same
that
they
weren't.
So
we've
been.
D
B
I'm
Matt,
oh
as
well,
I
built
a
lot
of
this
stuff
from
a
technical
perspective
and
that's
sort
of
my
role
going
forward.
Is
you
know,
I,
let
you
know
a
lot
of
a
lot
of
the
project:
management
curriculum,
stuff,
I'm,
letting
Derek
and
Lisa
handle?
If
you
have
any
questions
about
the
platform
antidote,
specifically,
that's
more
the
thing
that
I'm
focusing
on
lately.
So
that's
that's.
What
I
do.
E
I'm
Greg
ferry
from
packet
pushes
that
guy
I
guess
so
I
just
dropped
in
to
see
what's
happening.
A
A
D
All
right
so
then
fire
remains
mute.
All
right,
see,
I
think
we're
going
to
sweat
the
sweat
the
agenda
a
little
bit,
we'll
kick
it
off
with
Matt
I'm
talking
about
the
the
upcoming
next
release
or
two
and
kind
of
what
he
is
looking
at
doing
sort
of
in
the
context
of
our
priorities
for
the
project
overall
and.
B
Okay,
so
I
also
I'll
show
some
of
the
some
of
the
things
that
I've
been
thinking
about.
One
of
the
things
that
I
need
to
do
in
the
very
near
future
is
clean
up
a
lot
of
a
lot
of
the
the
notes
that
I've
taken
about
the
the
things
that
I
want
to
do
in
the
next
few
releases.
We've
had
a
lot
of
in
the
last
month,
or
so
especially,
we've
had
a
lot
of
like
interrupting
events
like
I
want
on
PTO
for
a
week,
there's
a
few
things
that
that
made
it
the
this.
B
This
next
release
sort
of
like
fall
behind
a
little
bit,
one
of
those
things
I'm
working
on
right
now,
which
I'll
talk
to
you,
because
it's
not
really
part
of
any
release
plan,
but
it's
very
necessary
for
energy
labs.
The
site
is
we're
actually
moving
hosting
providers.
This
is
one
of
the
things
that's
been
taking
my
attention
lately
right
now
we're
in
Google
Cloud.
We
were
originally
in
Google
Cloud,
because
we,
you
know,
we
had
a
lot
of
we.
We
looked
at
a
lot
of
different.
B
We
looked
at
a
lot
of
different
providers
and
Google
Ads
seemed
to
be
the
only
one
that
allowed
us
to
enable
nested
virtualization,
which
is
necessary
for
performance
reasons,
turns
out
that
those
performance
reasons
weren't
good
enough
for
some
of
the
things
that
we
need
to
do
to
be
able
to
do
nested,
virtualization
of
any
kind
is,
is
really
just
a
killer.
So
we
started
shopping
around
and
found
a
bare-metal
as
a
service
provider.
B
That's
very
good
and
we're
currently
moving
the
the
infrastructure
that
we
run
on
on
GC
PA
over
to
over
to
this
provider.
Now
that's
not
really
super
relevant
to
the
to
the
open
source
project,
it's
kind
of
where
we're
running
it,
but
I
say
that,
because
first
off
everything
that
we
build,
that
you
know
all
of
like
the
terraform
definitions
and
all
of
that,
the
power
it
that
make
it
possible
to
move
over
those
are
already
open
source
and
they
will
continue
to
be
open
source.
B
So,
if
you're
interested
in
that
the
antidote,
ops,
repo
is
where
all
that
lives
and
will
live,
I
also
want
to
mention
that,
because
that's
a
pretty
big
undertaking
and
it's
taking
a
lot
of
my
attention.
So
if
there's,
if
there's
a
lay
on
pull
requests,
that's
why?
So?
That's
that's
something.
I
wanted
to
mention
the.
B
So
there's
a
few
things.
A
few
reasons
you
should
be
aware
of.
I
will
caveat
this
once
again
saying
I
need
to
clean
this
up,
but
the
places
that
I'm
about
the
things
I'm
about
to
show
you
the
resources
I'm
about
to
show
you
will
will
will
stay
around
and
they'll
be
good
for
you
to
know
about
because
I
don't
know,
I'm,
not
sure.
If
everybody
knows
about
the
way
that
I
normally
organize
projects
share,
desktop.
B
So,
underneath
the
network,
reliability,
engineering
organization-
if
you
just
go
to
that
on
github,
github.com,
slash
NRA
learning,
you'll
notice,
there
are
all
you
know-
all
of
our
we've
I've
pinned
sort
of
the
six
most
popular
repos
that
we
have
that
powers.
The
project.
If
you
go
to
the
project's
tab,
you'll
see
basically
like
a
Trello
board
if
you're
familiar
Trello,
it's
kind
of
what
it
looks
like,
or
rather
you'll
see
a
list
of
boards.
The
only
board
that
we
have
right
now
is
0
for
2
0.
F
F
B
Is
when
we
release
a
new
version
of
the
platform
or
really
right
before
I'll,
create
the
next
releases
board
and
start
moving
issues
to
it
so
that
we
can
do
some
like
light
release
planning
now,
I've
mostly
been
doing
this
in
isolation.
Not
not
it's
been,
you
know,
I've
been
doing
it
in
the
open,
it's
been
public,
but
it's
it's
been
an
effort
that
you
know
I
sort
of
do
myself,
and
instead
what
we
want
to
do
is
obviously
make
that
more
of
a
community
informed
thing
I'm
happy
to
lead
that
continue
to
lead
that.
B
But
you
know
one
of
the
things
that
I
wanted
to
do
on.
This
call
is,
is
let
you
guys
know
about
it,
so
that
you
can
see
it
and
and
provide
feedback
hey
like
I
think
this
feature
should
be
worked
on
in
this
release
and
so
on
and
so
forth,
and
so
normally
you
know
basically
the
way
that
this
is
very
commonly
done.
This
is
a
very
common
pattern
by
the
way
for
release
planning
I've
been
doing
this
all
kinds
of
different
open-source
projects
that
use
this
kind
of
format
in
Trello,
especially,
is
effectively.
B
You
put
all
all
of
the
issues
or
tasks
that
you
need
to
accomplish
in
a
given
release
over
here
and
to
do
you
might
have
a
different
a
couple
different
to
do.
Columns
based
on
what
kind
of
work
it
is
and
effectively
you'll
move
things
from
left
to
right,
based
on
where
they
are
in
the
in
the
in
the
in
the
process.
B
B
You
know
finish
up,
but
so
keep
that
in
mind.
A
lot
of
this
will
get
cleaned
up,
but
but
this
is
useful
to
know,
because
this
is
basically
what's
in
my
head
with
with
respect
to
what's
going
to
be
put
into
the
next
release.
B
So
yeah,
that's
that's
something
to
be
aware
of
now.
If
you
want
to
zoom
out
just
a
little
bit
a
good
way
of
knowing
what's
on
the
longer-term
roadmap,
will
be
this
dock.
That
I've
been
putting
together
same
situation
as
before,
meaning
this
is
a
not
super
cleaned
up
right
now
and
it
needs
to
have
more
details
added
to
it,
but
I'm,
hoping
by
next
week,
I'll
be
able
to
send
this
out
and
actually
get
like
feedback,
because
it'll
be,
you
know,
not
finished,
because
it's
gonna
be
a
living
document.
B
As
you
can
see,
we
have
release
is
planned
out
through
the
rest
of
the
year
or
at
least
placeholders
for
the
rest
of
year.
So
it's
not
like
it'll
be
finished,
but
there
will
be
enough
information
for
you
for,
for
everybody
to
know
sort
of
what's
going
to
happen
in
the
in
the
very
least
at
the
next.
You
know
for
the
next
two
releases
of
the
platform.
So
if
you
go
to
you
know
this,
this
dock
and,
like
I,
said
I'll,
send
it
out
at
some
point
in
the
future.
B
But
the
really
main
thing
is:
is
you
know,
you've
got
this
sort
of
like
high-level
release,
planning
section,
so
in
many
ways
you've
got
0
for
X.
For
instance,
you
notice
that
those
that
a
lot
of
the
things
discussed
here
will
be
contained
either
within
this
plan.
Sorry
wrong.
Tab,
this
plan
or
a
subsequent
plan-
that's
focused
on
0.40,
something
like
that.
So
basically
you
can
just
you
can
treat.
B
This
is
like
the
master
document
which
says
here
are
the
high-level
things
that
really
important
things
that
we
need
to
accomplish
in
each
release
or
that
we,
the
community,
has
made
clear
we
should
accomplish
in
this
and
in
a
given
release
from
this
document.
What
I'll
do
is
I'll
derive
a
very
detailed
release
plan
for
a
specific
release
version,
so
0.4
dot
0.
This
version
willing
this
plan
will
include
those
those
things,
but
it'll
also
include
other
things
too.
This
doc
is
not
meant
to
track
all
of.
B
Like
the
you
know,
the
github
issues
for
like
bugs,
and
things
like
that.
It's
mostly
meant
to
just
contain
like
high-level
goals.
Here
are
the
things
that
we
really
really
want
to
have
done
by
this
release,
and
so
naturally,
those
things
as
well
as
all
of
the
other
specific
issues
for
bugs
and
whatnot
will
be
contained
in
this
plan
and
we'll
be
tracking
that
as
we
go
through
once
all
of
the
boxes
are
moved
to
the
right.
B
The
release
is
more
or
less
ready
and
we
will
run
the
release
workflow
and
then
everybody
will
get
the
new
version
and
then,
at
some
point
in
the
future,
we'll
update
the
actual
NRE
lab
site
to
use
it
typically
what
we
do
in
terms
of
scheduling
again.
None
of
this
is
super
formalized,
but
just
as
a
matter
of
you
know,
sort
of
past
procedure.
Well,
normally
what
we
do
is
we
release.
That's
very
easy
to
do.
B
B
Cool
I'll
start
with
Brian's
over
chicks.
You
said
something
about.
It
seems
relevant
to
me
if
one
wants
to
host
antidote
on
premises.
Oh
is
that
when
I
was
talking
about
the
bare
metal,
stuff,
sure,
okay,
yeah,
yeah,
yeah,
I,
remember:
okay,
yeah
I
do
I!
Remember
what
I
wrote
a
song
about
yeah
the
everything
everything
we
build
from
an
infrastructure
perspective,
whether
it's,
whether
it's
VMs,
even
physical
servers.
B
We
do
everything
as
code,
meaning
terraform
or
ansible,
depending
on
what
we're
configuring,
but
regardless
no
matter
what,
when
we,
when
we
stand
something
up
from
an
infrastructure
perspective.
This
is
a
really
part
of
the
antidote
platform,
but
we
do
everything
as
as
terraform
or
ansible
configurations,
and
then
we
open
surah.
That's
that's
all
any
antidote,
ops,
repo,
so
yeah
to
your
point.
If
people
do
want
to
replicate
what
we're
doing
or
at
least
get
inspiration
from
that,
you
know
they're
more
welcome
there.
B
The
more
than
welcome
to
do
so
brian
says
I'd
love
to
know
more
about
the
performance
issues
related
to
nested
virtualization,
so
I
don't
have
specific
numbers
like
we
didn't
do
any
benchmarking
or
anything
like
that.
But
there
are
a
few
things
that
are
that
are
that
are
made
a
lot
worse
when
you,
when
you
start
thinking
about
some
of
the
software,
that
sort
of
been
I,
guess
like
it
forced
into
a
virtual
form
factor,
if
you
will
any
performance
penalty,
it
seems
is,
is
really
bad.
B
We
for
in
just
take,
for
instance,
the
VQ
effects
which,
by
the
way,
isn't
a
Juniper
product
it
we
know
we
we
don't
that's
not
something
that
we
support
as
like
a
please
put
this
in
your.
You
know,
put
this
in
your
hypervisor
and
run
production
traffic
through
it.
We
have
other
things
for
that,
like
vm,
x
and
whatnot,
but
the
v
key
effect
specifically
is
more
meant
as
really
just
a
learning
tool.
Really,
because
we
don't
again,
we
don't
support
it
as
an
official
product,
at
least
not
right.
B
Now,
anyway,
the
the
way
that
that's
built
is
there's
a
there's
like
a
component
called
the
I.
Don't
know
I,
don't
know
a
ton
about
this,
but
what
I
do
know
is
there's
a
component
like
the
VP
EFI,
which
we're
gonna
be
releasing
a
new
version
of
that
in
the
near
future.
That's
it's
a
lot
better,
but
the
current
version
is
is
pretty
slow
and
every
time
we
try
to
start
that
frankly
in
in
the
current
environment,
it
takes
about
five
to
ten
extra
minutes
beyond
the
V
key
effects
itself
booting.
B
So
if
you
can
think
of
like
the
control
plane
element,
that's
the
that's
the
element
that
currently
runs
on
all
of
all
the
current
vqf
X's
and
that
that
itself,
doesn't
it
doesn't
boot
super
quickly?
It's
you
know
maybe
takes
five
minutes
or
so,
but
the
the
benefit
of
that
portion
is.
We
can
help
check
it,
so
we
can
send
pings
basically
to
the
TCP
sockets
that
we
know
are
supposed
to
be
responding
and
use
that
to
determine
whether
or
not
the
thing
has
come
up
problem.
Is
the
PFE
isn't
like
that?
B
Pfe
is
separate
it's
running
inside
the
container,
but
we
can't
access
it
directly
and
so
we'll
bring
the
lesson
up
because
all
of
the
other
health
checks
passed,
but
then
the
the
line
card
will
will,
you
know,
won't
be
there
like
the
XE
ports.
Just
won't
exist
for,
like
the
first
five
to
ten
minutes
of
the
lesson
being
available,
which
is
not
great,
so
one
of
many
things
that
we're
doing
to
address
that
is
moving
to
a
bare-metal
provider.
It's
not
the
only
consideration
by
the
way.
B
There's
there's
actually
a
bunch
of
reasons
why
a
bare-metal
provider
is
just
gonna
work
out
better
for
us
I
think,
that's
not
to
say
it
won't
work
in
VMs.
It
certainly
will
in
fact
that's
how
we've
done
it
the
whole
time.
So
it
clearly
works.
It's
just
you
know
we're
optimizing
at
this
point
for
the
for
the
actual
NRI
website,
but
antidote
itself
obviously
doesn't
care
about
amina.
B
Overtrick
says:
could
Matt
describe
the
two
items
in
the
0.4
in
the
document?
Yes,
I
can
so
again
there's
some
there's
some
additional
synchronization
work
that
I
need
to
do
to
make
sure
that
this
document
is
properly
sync
with
the
o
dot
for
plan.
Hopefully,
by
the
end
of
this
week,
the
this
doc,
as
well
as
the
o
dot
floor
plan,
will
be.
You
know,
cleaned
back
up,
but
I'll
talk
to
the
two
I'll
talk
to
the
two
here
now
notice
in
this.
B
In
this
doc,
I
talked
about
0.42
X,
because
I
don't
want
to
get
into
like
really
specific
patch
versions
in
this
doc
I'm,
mostly
just
talking
about
minor
versions,
so
just
FYI
the
reason
I
bring
that
up
is
not
all
of
these
will
be
shown
in
this
page
right
now.
Some
of
them
are
but
but
others
aren't
so
because
I
might
be
waiting
until
like
0.4
that
one,
for
instance-
but
of
course
all
of
this
is
totally
you
know
flexible.
We
can.
We
can
change
this
based
on
on
me.
B
B
That
it's
actually
working
so
it
might
not
work
but
I'll,
give
it
a
shot.
So
collections
are
pretty
cool.
Cool
looks
like
they
do
so
collections
are
pretty
cool.
We
had
a,
we
had
a
need.
We
had
a
few
different,
seemingly
unrelated,
memes,
actually
a
while
back.
So
we
were
even
it's
been
on
our
minds
for
a
while,
and
we
solved
it
with
this,
or
at
least
we
think
you
know
we
have
a
pretty
good
eye,
pretty
pretty
good
feeling
about
how
we've
solved
it.
With
this
few
things.
B
First
off,
we
want
there
for
a
lot
of
lessons.
There
needs
to
be
additional
context.
Like
you
know,
one
of
the
things
like
any
any
lesson
that
we
put
in
that's
got
more
slightly
more,
like
juniper,
leaning,
focused
technology.
What
we
want
to
do
is
make
sure
that
people
are
aware
of
that.
We
don't
you
know
just
out
of
out
of
them
out
of
desire
to
keep
the
spirit
of
NRE
labs
sort
of
the
you
know
what
it
is
multi-vendor
we
don't
try
to.
B
You
know
we
we
don't
do
anything
like
a
sales
pitch
or
anything
like
that.
I'm
not
talking
about
like
we're
showing
off
like
some
proprietary
juniper
technology,
and
that's
that's
not
included
in
what
I'm
talking
about
here.
Let
me
talk
about
a
very
specific
example:
the
current
let
the
the
less
there's
a
lesson
on
J
snappy,
so
Jason
a
P
is
an
open
source
project.
So
it's
not
something
we're
trying
to
like
sell
or
push
or
anything
like
that.
B
It's
just
a
cool
project
that
we
helped
start
that
we
that
we
want
to
talk
about.
However,
it
is
juniper
only
the
way
the
project
works.
It
is
juniper
only
and
even
so,
even
though
it's
open
source,
we
want
to
make
sure
people
have
that
context.
So,
anytime,
there's
like
a
slightly
more
juniper,
leaning
like
content.
We
want
to
make
sure
it's
in
the
juniper
collection
so
that
people
are
aware
of
that.
But
that's
not
the
only
use
case
that
surfaced
from
this
another.
Another
use
case
simply
is
hey.
B
You
know
I
as
a
maybe
I'm
running
a
consultancy
and
I
have
a
bunch
of
people
that
I
that
I
have
put
on
creating
content
for
NRA
labs
like
we
have
a
bunch
of
automation,
people
that
have
a
bunch
of
scripts
that
are
really
awesome,
and
we
want
to
share
that
with
the
world.
I
am
meaning
you
know,
Matt
I
would
love
to
be
able
to
highlight
that
effort.
B
Not
just
not
just
show
the
lessons
but
but
give
people
some
context
around
where
those
lessons
came
from
like,
for
instance,
we
have
a
you
know,
a
bunch
of
partners
here,
let's
say,
know
we're
you
know,
network
to
code,
everybody
everybody
you
know
hopefully,
is
familiar
with
network
to
code
if
they
put
a
bunch
of
people
on
creating
lessons
which
you
know,
a
lot
of
a
lot
of
them
are
thing
about
doing
this.
They
put
a
bunch
of
people
on
creating
lessons.
B
B
Take
you
to
this
sort
of
like
highlight
overview
page
for
for
that
collection,
in
this
case
the
company
network
to
code
and
then
any
lesson
that
they
tagged
with
that
collection.
Id
will
automatically
be
populated
here.
I'll
click
on
the
Juniper
collection.
So
you
can
see
that
in
action,
because
we
do
have
obviously
like
the
PI
easy
lesson
and
it
looks
like
I
need
to
tag
the
Jason.
A
P
lesson
too.
I
haven't
done
that
yet,
but
I
did
tagged
the
PI
easy
lesson,
so
that's
kind
of
how
it
shows
here.
B
So
if
you
just
want
to
see
all
the
lessons
that
Juniper
sort
of
sponsors
quote-unquote,
then
you
can
click.
This
same
thing
applies
to
any
other
collection,
though,
and
you
can
see
we
have
collections
for
all
kinds
of
folks
now
this
is
a
testing
site.
So
not
all
of
the
folks
on
this
list
know
about
this.
Actually,
a
lot
of
them
do,
but
some
of
them
some
of
them
we
just
put
as
sort
of
a
mock.
So
this
will
look
very
different
on
the
production
side.
We
want
to
make
sure
collections
are
only
live.
B
B
B
So
if
you
go
to
a
lesson-
and
it
happens
to
be
in
a
collection,
what
I
would
like
to
have
is
that
there's
a
badge
that
says
that,
like
hey
I'm
in
collection,
whatever
I,
don't
think
that's
done
so
I
need
to
do
that,
but
mostly
mostly
the
collections
feature
is
in
place
so
yeah.
Basically,
what
that
it's
just
like
an
organizational
tool,
if
you
can
think
of
it
that
way.
Yes,.
D
D
You
know
one
of
the
the
benefits
of
being
a
sponsor
could
be,
for
example,
moving
up
in
the
list
or
you
know,
being
highlighted
in
some
fashion,
as
sort
of
one
of
the
benefits
of
being
a
sponsor.
So
that's
you
know.
This
is
something
that's
been
of
interest,
especially
to
a
lot
of
bars
and
assistance.
D
Integrators
who've
had
found
their
way
to
the
project
just
because
they
want
a
way
to
be
able
to
highlight
the
things
that
they
do
and
also
easily
find
the
things
that
they
do,
as
you
know,
ways
to
showcase
their
own
DevOps
practices.
So
that
was
sort
of
the
genesis
of
this
feature,
but
you
know
they're,
there
I
think
additional
ways
that
the
project
itself
can
can
make
use
of
the
collections
feature
from
that
standpoint.
From
the
sponsorship
standpoint.
G
B
I
I
was
I'm
looking
at
the
the
the
the
other
things
here.
There
are
things
we
can
talk
about,
but,
to
be
honest,
like
I
said,
this
needs
to
get
cleaned
up
and
a
lot
of
these
might
shift
around
just
because
you're
not
4.2.
So
if
you
have
feedback
on
on
what
you
think
should
be
there,
you
know
feel
free
to
just
send
it
to
me.
B
That's
that's
fine
because,
like
I
said
I
the
I
created
this
about
a
month
ago
or
maybe
even
two
months
ago,
so
it
definitely
needs
to
be
updated
before
I
before
I
share
it
out
and
I
will
do
that.
But
in
the
meantime,
if
you're,
like
man,
you
know
I
I'm,
looking
at
say
this
plan
and
I
just
don't
see
something
that
I
think
is
important,
just
something
though
I'll
put
it
in
the
doc.
That's
fine
I,
along
of
this
just
needs
to
get
cleaned
up.
It's
not
a
lot
of
the
stuff.
B
That's
here
isn't
here,
because
I
think
very
strongly
that
it
should
be
it's
just
a
placeholder,
mostly
so
I
I'll
clean
it
up.
If
you
have
any
feedback
on
the
specifics,
let
me
know
I
know
over
Dixon
a
few
others
are
interested
in
the
in
the
architecture
and
if
you
do
look
at
the
doc
one
of
them
that
one
of
the
things
you'll
see
is
that
underneath
the
the
timeline,
which
is
a
little
less
detailed,
you'll,
see
a
section
called
mini
projects
which
is
way
more
detailed.
B
I
know
that
there's
some
thoughts
that
some
of
you
might
want
to
share,
but
I
just
want
to
provide
a
teaser
on
this,
because
I'm
gonna
I'm
gonna
be
going
into
a
lot
more
detail
on
this
later,
but
in
short
there,
if
you're
familiar
with
the
way
that
or
if
you're
not
familiar
with
the
way
that
syringe
is
currently
built
and
actually,
if
you're
not
familiar
with
syringe,
let
me
quickly
define
it
so
antidote
is
like
an
umbrella
project.
B
Right
antidote
is
sort
of
the
collection
of
everything
that
we
built
to
make
this
possible
at
any
time.
Talk
about
the
platform
you're
talking
about
you're
talking
about
antidote,
specifically,
if
you,
if
you
look
behind
the
scenes,
you'll
see
that
there
is
one
really
important
component,
which
is
called
syringe,
and
if
you
built
a
lesson,
you
know
what
syringe
is,
because
that's
that's
what
sort
of
gobbles
up
the
the
lesson
definition
and
makes
it
possible.
B
The
way
syringe
is
built
is
it's
currently
all
in
one
program,
so
every
every
bit
of
code
that
goes
into
syringe
ends
up
in
a
single
binary.
That
runs
you
on
your
laptop
in
a
you
know,
in
mini
in
self
medicate,
which
is
mini
cube,
which
we
use
a
mini
cube
or
in
the
case
of
production.
You
know
a
real
kubernetes
cluster,
but
in
either
case
syringe
itself
is
just
a
single
binary.
B
One
of
the
things
that
that
that
one
of
the
benefits
a
lot
of
there's
actually
a
lot
of
benefits
to
that,
and
we
did
this
for
a
pretty
good
reason.
There's
a
you
know:
it's
it's
easy
to
manage,
so
there's
just
a
single
binary,
you
throw
it
on
a
server
and
you
call
it
a
day.
It
provided
us
with
agility.
So
we
had.
You
know
we
built
all
of
this.
B
Basically
in
like
four
months
prior
to
launch,
and-
and
this
is
probably
one
of
the
reasons
we
were
able
to
do-
that
is
because
it's
very
simple,
there's
also
no
external
database,
because
we
just
kept
everything
in
memory,
and
so
it's
just
a
very
simple
architecture.
There
are
two
components
to
that,
even
though
it's
even
though
it's
a
single
binary,
there
are
two
sort
of
subsystems
within
that
running
process:
the
API
and
the
scheduler.
So
you
can
think
of
the
API
as
what's
presented
to
the
front-end.
B
That's
that's
sort
of
what
the
the
web
front-end
consumes
to
know.
What
lessons
are
available
and
when
and
what
lessons
are
you
know
you
know
what
with
the
lesson
catalog,
basically
so
every
DL
the
detail
about
what's
loaded
into
syringes
available
via
API
and
then
on
the
back
end.
We
have
the
scheduler
port
portion,
which
runs
in
parallel
to
the
API
and
that's
responsible
for
talking
to
kubernetes.
So
you
call
the
API
and
say:
hey
like
I
would
like
an
instance
of
lesson,
one
for
instance.
B
What
it'll
do
is
it'll,
say,
cool
well,
I
know
the
scheduler
knows
about
less
than
ID.
One
and
I
know
that
it
has
these
components
so
I'm
gonna
fire
that
message
off
to
the
scheduler
and
the
schedulers
and
and
then
turn
around
and
fire
message
off
to
kubernetes
to
spin
up
all
of
the
actual
containers
to
make
it
possible.
B
So
those
are
the
two
subsystems
within
the
current
syringe
architecture.
It's
one
binary.
It's
managed
as
one
you
just
called
syringe
D,
but
there
are
two
subsystems
within
that
again:
I'm
gonna
clean
this
up
so
that
it's
a
lot
more
clear,
but
one
of
the
things
we're
gonna
be
doing
or
one
of
the
one
of
the
one
of
the
things
we've
thought
about
is
is
is
some
of
the
disadvantages
to
this
model
that
we're
starting
to
we're
starting
to
see?
First
off
it
is
a
single
point
of
failure.
B
B
If
you
look
at
the
graph
on
graphs
for
lesson,
utilization
you'll
see
that
there
there
were
times
right
after
launch
that
it
just
that
there
was
a
bunch
of
people
using
it
and
all
of
a
sudden
it
went
to
zero
a
bunch
of
people
using
it
just
went
to
zero
there's
a
lot
of
there's
there's
a
lot
of
trade-offs
that
we
made
in
the
very
early
early
days
with
respect
to
you
know
how
quickly
we
wanted
to
this
to
run
and
because
it's
a
single
point
of
failure,
if
it
crashes.
For
any
reason.
B
That
state
is
gone,
however,
kubernetes
has
its
own
state,
and
so
because
we
don't
want
those
two
things
to
become
out
of
sync:
what
we
do
when
we
start
syringe
is
we
actually
kill
all
of
the
name
spaces
in
kubernetes
that
were
that
exists
just
to
make
sure
there's
nothing
that
syringe
doesn't
know
about
now,
of
course,
we're
what
six
or
seven
or
more
months
down
the
road
and
a
lot
of
those
bugs
have
been
fixed.
So
now
it's
not
a
huge
deal,
but
it's
still
something
we
we
don't
want
to
remain.
B
We
don't
want
to
leave
in
place.
We
don't
want
it
to
be
a
single
point
of
failure,
we'd
like
it
to
be
much
more
stateless
and
much
more
distributed,
because
the
API
and
the
scheduler
are
kind
of
tightly
coupled
together.
Adding
adding
logic
to
this
and
adding
extensibility
to
this
is
actually
pretty
difficult.
There's
two
ways
to
do
that.
You
could
either
pass
all
of
the
state
you
possibly
need
to
do
it
to
make
an
extension
up
through
the
API.
B
That's
that's
possible,
but
there
are
other
ways
to
do
that
that
I've,
that
I've
actually
used
in
other
projects
that
I
think
might
be
better
and
yeah.
I
talked
about
the
rest
of
the
disadvantages,
so
I
will
I
will
clean
this
up
and
go
through
a
lot
more
detail,
but
I
just
wanted
to
really
quickly
tease.
What's
coming
this,
this
is
a
distributed
sort
of
microservices
architecture.
That's
pretty
popular,
actually
I
use
this.
This
is
the
architecture
that
we
used.
B
A
stack
storm,
which
is
also
pictured
here,
so
I'm,
trying
not
to
be
super
confusing
stack
storm
will
will
have
a
role
in
this
in
this
in
this
architecture,
with
respect
to
adding
functionality
to
things
like
you
know,
our
support
site
or
our
community
site
or
our
discord.
That
kind
of
thing,
but
forget
about
that
for
now
this
is
this
is
more
or
less
sort
of
aside
from
the
point.
For
now,
what
I
want
you
to
look
at
is
is
the
rest
of
the
components
here.
B
You've
got
basically
a
bunch
of
different
processes
that
have
one
very
specific
job
instead
of
one
process
that
has
all
the
jobs,
and
so
that's
a
pretty
common
model.
What
we're
gonna
do
basically
is
move
all
of
the
state
out
of
syringe
itself
and
there's
not
a
lot
I
we're
still
gonna.
Do
we're
not
gonna
like
make
you
go
through
like
a
web
UI
to
generate
lesson,
definitions
or
anything
like
that.
All
that's
still
gonna
be
done
as
code
with
yellow
files.
You
know,
store,
didn't
get
all
of
that's
going
to
be
preserved.
B
Those
are
the
two
really
very
vital
components
that
we
want
to
make
sure
are
sort
of
always
available,
but
there
are
other
components
like,
for
instance,
stats
we
want
to.
We
want
to
be
able
to
export
stats,
and
we
kind
of
just
want
that
to
be
in
its
own
process,
so
that
we
can
manage
that
sort
of
very
simply
same
thing
with
garbage
collection.
There's
really
a
lot
of
need
for
garbage
collect
to
be
done
as
part
of
the
scheduler.
It's
already
it's
kind
of
separate
thing.
B
So
now
it's
is
the
its
you
can
think
of
it
like
a
message
queue,
it's
a
it's.
A
very
fast,
very
simple
message
queue.
So
if
you've
used
something
like
RabbitMQ
I
would
I
would
I
would
caution
you
against
comparing
it
because
it'll
it'll
look
kind
of
bad
in
comparison.
The
trade-off
is
simplicity
for
speed,
and
the
features
that
Nath's
has
is
perfectly
fine,
for
our
use
case,
RabbitMQ
is
is,
is,
is
I've
used
it
before
it's
it's
it's.
B
It's
a
fine
message
queue
it's
just
very
heavy-handed
because
it
does
all
the
things
one
of
the
things
that
does
is
it
is.
It
provides
like
temporary
storage
for
messages.
It
allows
you
to
like
store
messages
for
like
a
long
period
of
time.
You
don't
need
to
do
that.
So
there
are
a
lot
of
features
like
that
that
we
just
don't
need
out
of
that.
Nats
happens
to
be
super
super
fast
and
it
has
all
the
features
we
need
to
be
able
to
pass
messages
between
these
processes.
B
So
that's
how
they
talk.
There
will
be
a
NAT
service
running
and
kubernetes
that
allows
you
to
tie
these
things
together
and,
of
course,
naturally
we'll
make
sure
all
of
this
gets
replicated
to
self-medicate,
as
we
do
today.
So
we'll
modify
self-medicate
to
make
sure
all
this
stuff
gets
stood
up,
so
you
don't
have
to
worry
about
it.
B
The
the
key
here
is
because
we've
split
everything
apart
all
of
the
way
the
syringe
works
is
now
exposed
on
this
message
queue
the
way
that
these
components
talk
is
no
longer
like
in
memory
and
like
opaque.
It's
all
exposed
on
this
message
queue.
B
So
if
we
had,
for
instance,
if
we
wanted
to
place
if
we
wanted
to
do
something
with
really
antidote
or
syringe,
specifically
like
extending
it
or
adding,
maybe
additional
metadata
to
what's
going
on
anything,
really
had
any
sort
of
extensibility
to
the
platform,
we
could
simply
build
it
to
listen
on
this
message,
queue
for
for
data,
and
you
can
do
basically
whatever
you
need
to
do
with
that
data.
The
data
is
all
exposed
on
the
message
queue.
B
So,
by
forcing
these
components
to
talk
over
a
message
queue,
you
can
then
attach
anything
else
to
that
message
queue
and
it
picks
up
that
data
and
you
can
do
whatever
you
want
with
it
now.
One
of
the
examples
like
I
said
one
of
one
such
example
of
that
is,
we
have
a
bunch
of
you,
know,
sort
of
community
resources
for
folks
to
sort
of
get
you
know
to
be
able
to
communicate.
B
One
of
the
things
is
is
adding
the
the
idea
of
badges
in
the
community
site
the
the
discourse
form
that
we
stood
up,
there's
there's
actually
a
concept
of
badges
within
that
site.
We've
been
playing
with
the
idea
of
maybe
awarding
badges
based
on,
completed
lessons
or
maybe
contributed
lessons
that
would
be
kind
of
cool
one
of
the
ways
that
we
know.
If
somebody
one
of
the
ways
in
this
model
that
we'll
know,
if
somebody
completed
a
lesson,
is
there
will
be
a
message.
B
B
So,
anyway,
we're
we're
we're
putting
more
thought
into
what
we
want
to
put
on
here,
but
the
general
architecture
of
syringe
is
what
I
wanted
to
clue.
Everybody
up
about
I
will
go
into
much
more
detail
in
the
future,
but
I
did
want
to
I
did
want
to
talk
a
little
bit
about
it
now,
just
because
I've
been
sitting
on
this
for
a
little
bit
and
I'm
tired
of
sitting
on.
D
D
Okay,
let's
see
so
given
what
folks
from
that
so
far,
you
know.
One
of
the
things
that
that
Matt
and
I
have
been
talking
about
is
how
we
kind
of
start
to
peel
off
the
pieces
of
the
development
from
that
and
kind
of
helps,
help
have
helped
the
community
start
actively
contributing
to
the
development.
F
We
could
use
you
know,
information
about
how
number
1,
how
to
create
images
or
what
are
the
requirements
for
an
image
and
and
I
know.
There's
those
new
changes.
I
looked
at
that
the
video
you
made
yesterday
and
I
see
these
new
changes
coming,
which
are
really
required
to
to
use
it
in
a
better
way,
at
least
in
my
use
case-
and
you
know
once
those
are
implemented.
Some
documentation
helps
us
use
that,
but
especially
around
images,
I,
don't
think,
there's
enough
in
your
Doc's
about
how
to
create
an
image
specifically
for
any
labs.
D
A
A
F
I
think,
with
the
changes
you're
making
like
you're
planning
to
make
you're
getting
really
close
to
something,
that's
generally
usable
by
everybody
and
you're,
just
just
making
it
possible
for
people
to
make
that
last
connection
to
getting
it
working.
Is
it's
going
to
get
everybody,
but
once
once
your
changes
are
made.
It's
going
to
make
this
a
tool
that
I
think
more
people
can
contribute
to.
A
F
F
You've
got
a
Juniper
router
in
in
a
docker
container.
I
want
to
put
another
router
in
a
docker
container
and
and
put
it
in
to
self-medicate
and
I.
Don't
know
how
to
do
that
and
and
I'm
a
beginner
with
docker,
and
things
like
that.
So
think
about
your
your
audience:
they're,
not
necessarily
going
to
be
docker
experts.
So
a
little
bit
of
extra
help.
There
would
be
good
okay,.
G
D
G
Didn't
document
anything
or
share
anything,
we
were
just
trying
to
figure
out
an
actor
to
figure
out
because
I
think
what
our
understanding
was
from
what
we
could
see
online
was
oh,
it's
is
a
simple
process.
You
should
know
how
to
do
this,
but
it's
continue
that
other
people
went
through
that
so
and
the
process
is
really
quite
simple
once
you
have
it
at
least
my
understanding
is,
is
just
pushing.
It
is
pulling
it
from
from
the
old
docker
storage
into
the
mini
cube
environment,
and
then
your
image
can
be
used.
B
Certainly
you
hold
on
a
minute:
no
I'm,
not
okay,
I
mean
all
of
the
all
of
our
documentation
is
hosted
in
the
antidote
repo.
So
if
you
wanted
to
submit
a
PR
changing
the
docs
you're
more
than
welcome
to
do
that,
I'll
review
it
just
like
anything
else.
B
G
B
G
B
Know
the
reason
we
have
it
there.
The
reason
it's
called
antidote
is
because
that
we
also
have
all
of
the
get
sub
modules
there.
So,
instead
of
renaming
it,
if
we
wanted
Doc's
to
be
in
its
own
repo
I'd,
rather
just
move
the
docs
folder
that.
B
Fine,
we
can
do
that.
The
the
reason
the
antidote
repo
is.
There
is
originally
a
little
bit
of
a
history
lesson.
This
is
more
than
a
year
ago,
when
we
first
started
the
project.
We
actually
had
all
code
in
the
antidote
repo
and
now
there's
like
no
code
in
the
internet,
repo.
So
that's
why
that
exists
to
sort
of
keep
to
sort
of
keep
things
as
simple
as
possible.
B
B
B
Well,
it
exists,
but
it's
not
it's
not
sufficient.
Clearly,
so
I
could
actually
send
that
link
out.
This
is
where
it
will
be.
I
know
where
it
will
be
because
the
page
exists.
It
just
needs
more
data,
I
mean
one
phone
so
in
the
chat
Brian,
especially
probably
interested
in
this.
That's
what
I
have
thus
far.
Obviously
it
needs
to
be
expanded,
but
it
does
exist.
So
the
good
news
is
when
I
do
expand
it.
That's
where
that's
where
it
will
be
and
so
feel
free
to
bookmark.
That.
D
Right
so
we
have
five
minutes
left
on
the
call.
I
didn't
really
have
anything
on
this
sort
of
marketing
community
front
really
today,
I
hope
to
have
more
next
week.
Are
there
any
other
comments
or
questions
for
Matt
I
know?
There
was
one
person
who
mentioned
questions
for
with
regard
to
creating
a
lesson
any
other,
any
other
questions
that
we
should
talk
about
today.
D
D
D
B
Just
curious:
what
what
does
everybody
want
that
format
to
be
in
just
curious
like
it?
Would
it
be
best
to
like,
like
put
it
in
a
PR,
somehow
convert
it
to
like
a
like
markdown
and
put
it
in
a
PR,
and
that
way
people
can
relieve?
You
know
comments
on
there.
The
thing
I
like
about
Google
Docs,
is
that
you
can
comment
on
individual
lines
and
like
have
all
that
context
preserved,
but
there.
B
B
Sure
yeah
totally
I
mean
we
can
post.
We
can
do
that.
I
mean
people
can
comment,
they
won't
be
able
to
comment
in
the
doc.
Obviously,
because
I'll
you
know,
that's
not
shared.
It's
not.
You
know
it's
not
like
everybody's
editing,
the
same
dock,
their
own
copies,
but
we
can
certainly
post
it
as
a
doc
in
the
in
the
community.