►
From YouTube: Community Standup: 7/31/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).
A
A
A
A
A
A
A
A
A
How
are
you
sounds
like
my
audio
is
bad
hold
on
I'm
gonna
cut
the
plug
on
it
again.
B
It's
just
crazy
to
me
how
that
works.
Then
I
can't
imagine
I.
Don't
people
try
to
start
using
it,
and
then
they
don't
know
how
when
it
doesn't
work
right,
they
don't
even
know
where
to
begin
right,
right,
I'm,
so
I
yeah,
it's
crazy
at
the
amount
of
things
I
had
to
disable
or
enable
or
tune
in
order
to
not
be
slow,
as
is
pretty
crazy,
and
this
is
just
a
no
I.
Have
an
open
to
you
know
desktop
that
has
a
server
profile
just
but
I
happen
to
have
a
GUI
on
top.
B
But
but
good
I
have
I
I
changed
up
the
next
stage.
It's
more
practical,
I
wrote
in
order
to
demonstrate
like
if-then-else
I
wrote
a
script
that
does
that
validates
of
string
as
a
valid
IP
address
for
prefix,
that's
just
written
in
pure.
You
know
UNIX
stuff,
no,
no
other
language.
B
C
B
Has
that
we
haven't
talked
about
yet
that's
talked
about
in
subsequent
lessons,
but
I'm,
making
the
assumption
that
someone
you'll
be
able
to
see
the
if-then-else
bits
and-
and
you
know,
get
a
high-level
idea
what's
happening.
Okay,.
B
A
B
B
B
B
I
thought
I
mean:
we've
talked
about
any
real
ads
before
I'm,
packing
pushers,
haven't
we.
We.
B
A
A
D
A
D
Was
was
waiting
on
some
in
order
to
be
which
are
now
ready
or
almost
ready,
and
so
he
was
thinking
that
that
would
be.
You
know,
because
it's
a
topic
of
a
general
interest,
that
a
lot
of
people
are
familiar
with
or
need
to
be
familiar
with.
He
was
thinking
that
that
might
be
something
that
you
might
be
interested
in
writing
about
as
well.
Okay,.
D
Derek,
can
you
can
you
point,
can
you
point
you
to
that
the
open
config
one
also.
A
B
D
A
Matt
was
thinking
that
it
would
be
ready
the
week
of
the
12th
I
got
it
okay
and
then
for
the
bashed
lessons
I
know
you
you
kind
of
work
a
month
or
so
out.
What
do
you?
What
were
you
thinking,
they're
terribly
funny.
D
D
A
D
D
So,
actually,
by
the
end
of
this
week,
I
should
have
the
governance
stock
in
a
state
that
other
people
and
meaningfully
we
didn't
consume
it.
So
I'm
hoping
that
next
week
we
can
discuss
it
as
a
group,
and
you
know
just
kind
of
get
the
community's
feedback
and
thoughts
about
what
what
would
make
sense
than
what
everybody's
comfortable
with
and
so
forth.
Okay,.
D
D
D
A
D
That
that
kind
of,
like
put
us
several
hours
behind
schedule,
so
we
didn't
make
it
to
Juneau,
but
we
did
they
by
way
of
compensation.
They
took
us
into
this
other
P
word
and
we
got
to
see
other
glaciers
and
stuff
like
that,
and
we
went
and
visited
a
sled
dog
camp
and
road
behind
sled
dog
puppies
and
as
a
result
of
this,
we
now
have
a
dog
of
our
own.
As
of
last
night,
oh
wow.
D
A
C
A
D
D
E
Hey
everybody.
Sorry
I
was
a
little
late
rough
night
last
night
to
say
the
least.
E
She's
fine,
we
just
for
the
past,
like
like
in
the
past
two
weeks
like
as
soon
as
it's
as
soon
as
it
gets
to
be,
like
I,
don't
know
like
bedtime
for
her.
She
turns
into
this
like
she's,
just
never
happy
ever
and
she's
fine
all
day
all
day,
but
soon
as
soon
as
it
gets
to
be,
like
you
know,
738
three.
B
E
D
E
A
E
E
E
Have
started
working
on
well
to
be
honest,
like
I
started
this
two
weeks
ago,
but
I
I
was
interrupted
by
a
few
other
things
so
in
in
in
the
journey
to
turn
the
platform
into
something
that
read
more
more
accurately
represents
what
it
should
be
long
term
long
term.
Excuse
me,
we
there's
a
few
there's
a
few
specific
things
that
we
need
to
take
on
and
I
refer
to
them
as
mini
projects.
I
brought
up
the
idea
of
mini
projects
in
a
previous
stand-up
and
I
think
I
over
viewed.
E
It's
like
six
of
them
that
I
kind
of
want
to
tackle,
in
particular.
What
I'd
like
to
show
very
quickly
is
my
efforts
to
document
the
fur
one
when
I
was
putting
together
the
one
bit
of
platform
plans,
the
very
first
thing
I
did-
and
this
was
months
ago,
was
I
actually
evangelized.
My
ideas
within
juniper
to
some
of
our
to
some
of
our.
E
You
know
the
technical
folks
that
that
I
sort
of
you
know
that
I
solicit
opinions
from
the
CTO
team,
for
instance,
they
they
work
with
kubernetes
salons,
so
I
figured
their
opinions
would
be
useful.
I
also
reached
out
to
a
few
folks
like
Russ,
white
and
David
G,
just
as
a
as
a
technical
review.
You
know
peer
review
kind
of
thing
that
was
that
was
a
while
back
and
it
was.
It
was
primarily
in
like
a
PowerPoint
kind
of
format.
E
So
the
first
exercise
that
I
wanted
to
do
was
convert
that,
to
just
like
you
know,
a
Google
Doc
and
actually
before
I,
publish
it
externally
and
then
share
with
everybody.
I'm
gonna
probably
convert
it
to
something
like
a
plain
text
format,
so
I
can
put
it
in
get
up
that
way.
People
can
review
it
more
easily.
So
all
of
that
to
say
I'll
show
you
how
it
exists
today.
E
Just
understand
the
the
format
might
change,
but
the
content
should
be
much
cleaner
because,
right
now
it's
pretty
messy
in
many
ways
what
I
did
is
I
just
copied.
What
was
in
a
in
a
in
a
you
know,
Google
slide
and
I
just
copied
it
and
pasted
it
into
into
this
doc.
So
it
will
be
a
lot
cleaner,
but
the
content
will
be,
will
be
there
and
probably
even
a
little
clearer,
but
I'll
show
you
how
it
exists
today.
E
So
the
first
thing
is
to
tackle
is
the
syringe
redesign,
it's
the
first
mini
project
and
that's
the
doc
that
I'm
gonna
be
finishing
ideally
by
the
end
of
the
week
and
when
I
say
finish,
I
mean
the
draft
I
mean
I,
mean
I,
mean
converting
from
the
really
rough
like
copy
and
paste
from
PowerPoint
into
this
doc
into
something
that's
reasonably
easy
to
follow.
That
doesn't
mean
it's
like
the
approved
design,
and
it
doesn't
mean
that
it's
finalized.
What
it
means
is.
E
The
draft
is
ready
for
community
consumption,
so
the
first,
the
first
project
is
yeah.
The
syringe
redesigned,
the
second
mini
project,
by
the
way,
as
a
sneak
preview
is
going
to
be
something
related
to
the
antidote
web
for
and
we
are
wrapping
up.
The
engagement
with
bateau
be
for
our
UX
review
of
the
front-end
and
that's
gone
very
well,
and
we
expect
that
they
will
have
a
lot
not
only
to
share
but
also
to
change
in
the
front
end,
and
we
actually
have
budget
to
throw
at
that
problem.
E
So
the
second
mini
project
will
involve
a
lot
of
our
wishlist
items
for
how
the
front
end
should
should
should
evolve
and
then,
of
course,
because
they
know
what
they're
doing
the
front
end
will
probably
look
a
lot
better
once
they're
done
with
it.
So
the
second
mini
project
is
gonna.
Do
is
gonna
effectively
be
a
statement
of
work
for
for
them,
as
well
as
the
rest
of
the
community
for
the
things
that
Toby
doesn't
actually
do
themselves.
So
that's
next,
but
for
now
we're
just
talking
about
the
syringe
redesign.
E
I'm,
not
gonna,
go
through
all
of
this
line
by
line,
but
I'll
do
a
quick
section
overview,
because
I
do
have
other
things.
I
want
to
show.
The
first
thing
is
basically
an
understanding
of
where
we
at
where
we're
at
syringe
is
a
single
binary
which
has
its
advantages.
It's
it's
useful
because
it's
it's
simple:
it
also
doesn't
have
any
external
database
so
everything's
contained
within
that
single
binary.
So
you
know
you
start
syringe
and
it
starts
offering
an
API.
E
E
So
one
of
the
biggest
reasons
why
we're
doing
this
redesign
is
to
is
to
add
mam
from
a
module
from
a
modular
perspective,
be
able
to
add
other
extending
extent
extending
syringe
with
with
certain
functionality,
and
then,
of
course,
you
know,
scaling
concerns
and
and
and
operational
concerns
that
come
with.
You
know,
moving
things
out
into
separate,
but
the
separate
processes
so
pretty
standard
stuff,
but
mostly
I,
think
the
thing
I'm
I'm
pretty
excited
about
is
the
extensibility.
E
The
way
that
we're
doing
this
is
a
model,
that's
very
popular
with
just
sort
of
micro
services
in
general.
This
is
actually
while
none
of
the
technologies
are
the
same.
This
is
actually
the
exact
same
way:
stack
storm
works,
so
you
might
see
the
stack
storms.
Part
of
this
stack
storm
you
can
think
of
is
like
our
as
our
event
and
lurks,
though,
is
if
you
have
certain
components
to
do
certain
things,
and
you
want
say
you
know
when
it
went
a
certain
component.
E
Does
a
certain
task
like
if
a
message,
pops
up
that
says,
hey
somebody's
spinning
up
a
new
lesson
and
you
just
want
something
to
happen
in
response
to
that
sack.
Storm
can
listen
on
the
message,
queue
for
those
events
and
react
to
it.
The
way
that
you
want-
and
you
can
add
those
kind
that
kind
of
functionality
without
changing
syringe,
syringe
will,
will
talk
to
itself
on
this
message.
E
The
other
one
of
the
biggest
things
I
didn't
really
mention
this
at
the
top,
but
one
of
the
biggest
reasons
why
this
will
help
operationally
is
right.
Now,
I
have
very
very
little
visibility
into
when
people
have
problems.
I
can
kind
of
look
at
logs
and
see
errors,
but
it
doesn't
really
help
me
too
much
first
off
on
like
proactive
monitoring
as
well
as
understanding
where
the
actual
problem
is.
You
know
it
kind
of
really
really
depends
on
on
the
error
and
where
and
how
good.
E
My
logging
is
in
that
in
that
part
of
the
code.
So
while
that
needs
to
improve
no
doubt
the
other
thing
that
we
can
do
is
add
open
tracing
functionality
once
we
break
this
out,
that'll
give
us
a
visibility
into
how
long
certain
processes
are
taking.
So
is
the
problem
in
the
API
server.
Well,
maybe
it
could
also
be
in
the
scheduler
it
could
be
in
the
front-end.
Maybe
there's
a
maybe
there's
a
significant
amount
of
latency
between
those
two
endpoints
tracing
kind
of
gives
us
insight
into
that.
E
So,
anyway,
those
are
the
sort
of
the
high-level
things
that
I
want
to
tackle
there.
Of
course,
as
you
can
see,
there's
a
bunch
of
rough
notes
that
I
need
to
reorganize.
That's
the
main
task
for
me
this
week.
What
what
we'll
do,
if
you
saw
the
100
doc
you'll,
see
you'll,
probably
remember
that
there
was
a
little
bit
of
a
timeline.
That
timeline
is
almost
totally
wrong
now,
because
we
were
significantly
delayed
from
from
from
the
original
timeline
that
we
had
laid
out.
E
Nevertheless,
this
dock
is
not
about
timing
anyway,
regardless
of
what
whether
what
that
timeline
is.
So
what
we'll
do
is
we'll
have
a
sort
of
a
central
document
that
that
outlines
when
certain
things
would
ideally
get
done.
You
know
that
might
come
out
first,
that
might
come
out
last
I
kind
of
got
to
figure
out
what
I
want
to
do
there,
but
this
dock,
regardless
doesn't
have
any
of
that,
doesn't
have
any
of
that
timing
or
pora.
You
know
when
certain
things
should
get
done.
E
The
way
that
I,
I'm
gonna
lay
these
design
Doc's
out
is
each
mini
project
is
gonna,
have
milestones,
sort
of
an
order
of
operations
where
I
I
believe
the
order
that
things
should
get
done
in
order
to
accomplish
the
goals
laid
out
in
this
dock
and,
of
course,
like
I,
said
this
is
a
draft,
so
if
somebody
feel
it
feels
like
I'm
putting
one
thing
ahead
of
the
other
and
I
shouldn't
be
then
totally
fine.
We
can
talk
about
that,
but
this
is
the
way
that
I
would
like
to
that.
E
I
would
like
to
at
least
start
start
down
the
process.
So
if
you're
wondering
you
know
how,
what's
the
very
first,
like
you
see
the
design
you're
like
okay,
I,
guess,
I
guess
I
see
what
needs
done
what's.
First,
then,
going
to
the
milestones
will
be
will
be
probably
the
way
you
want
to
do
that
and
last
last
on
this
dock
all
mentioned,
the
milestones
are
also
the
it's
likely
that
that
will
be
the
interface
outside
of
the
stock.
E
So
if
we
do,
when
we
do
have
a
master
dock,
that
sort
of
outlines,
when
certain
things
will
get
done,
picking
a
milestone
will
be
a
good
sort
of
tactical
way
of
saying
like
well.
This
needs
this.
This
particular
task
needs
done
by
date,
X
that
kind
of
thing
I,
also
you'll,
notice,
sell
a
lot
of
these
are
links.
E
Those
are
actually
github
issues,
and
so,
if
you
click
on
any
one
of
these
menu,
what
I
need
to
do
is
I
need
to
add
more
issues
for
the
rest
of
these
but
say
observability
instrumentation,
that's
its
own,
that's
its
own
github
issue,
and
so
what
we
can
do
on
the
sort
of
open
source
management
side
of
things.
We
can
have
somebody
sort
of
assign
themselves
to
to
that
issue
and
they
can
take
that
on
I,
don't
know
where
I
opened
it
I
have
way
too
many
tabs
there.
E
E
Basically
everything
all
of
the
operational
stuff
we
open
sourced,
and
mostly
just
because
it's
you
know,
there's
no
reason
to
not
as
well
as
you
know,
it's
kind
of
useful
for
us
to
be
able
to
talk
about
what
we're
doing
that.
Primarily,
this
repo
is
a
stack
storm
pack,
so
it's
got
workflows
in
it
and
things
like
that.
It's
not
the
only
thing!
That's
in
it,
though.
E
We've
got
like
an
infrastructure
directory
where
all
of
our
terraform
and
ansible
configs
are
managed
for
spit
for
standing
up
the
infrastructure
side
of
things
platform,
as
you
command
is,
is
what
we
use
for
spinning
up
the
platform,
the
antidote
platform
on
top
of
all
that
infrastructure.
But
all
the
other
directories
are
a
stack
storm
pack
in
particular.
If
you
go
to
the
actions
directory,
you
can
see
that
there's
a
number
of
actions
that
we
use.
If
you
go
to
release
curriculum.
E
Now
that
had
some
advantages,
because
it
sort
of
ensured
that
the
curriculum
and
a
platform
were
always
in
lockstep
with
each
other,
like
the
curriculum,
was
never
using
features
that
didn't
exist
in
the
platform
you
know,
but
it
did
mean
that
effectively
we
had
to
wait
for
a
platform
to
need
a
release
effectively
to
be
able
to
release
new
content
and
and
we're
at
the
point
now
where
we
need
to
optimize.
For
that.
That's
it's
important.
E
It's
important
that
we're
able
to
respond
to
new
new
curriculum
content
as
absolutely
quickly
as
possible,
so
to
facilitate
that
instead
of
one
workflow
that
does
everything
we
have
two
workflows,
one
that
manages
releasing
of
the
platform,
the
other
one
that
manages
releasing
of
the
curriculum
and
the
idea
is
the
release
curriculum
workflow
could
be
much
more
frequently
used.
So
if
we
go
to
the
workflows
directory,
you
can
see
how
this
workflow
actually
works
and
in
it
starts
off
very
similar
to
the
platform
workflow.
E
But
the
big
difference
here
is
is
the
way
that
we
is
is
frankly
the
the
this.
The
fact
that
it's
a
little
shorter
than
it
used
to
be
before
because
there's
a
lot
of
things,
we
don't
need
to
do
here
that
we
only
need
to
do
in
the
in
the
platform.
In
particular,
if
you
look
at,
if
you
look
at
the
platform
workflow,
you
can
see,
we've
got
a
like,
compile,
syringe
and
then
publish
docker
images
for
the
for
the
for
the
platform.
E
Things
like
that,
primarily
the
the
we
actually
do
have
to
build
some
docker
images
which
I'll
get
into,
but
compiling
and
uploads
uploading
syringe
assets.
Actually
there
were
other
things
in
here
that
I
took
out
because
the
platform
or
floating's
to
change
now
to
but
that's
that's
you
know
it's
it's
it's
a
lot
shorter
now,
but
effectively
it.
What
we
do
is
is
a
few
things.
We've,
the
the
first
three
tasks
are
kind
of
like
boilerplate
as
assigning
variables
to
certain
values
based
on
input.
E
The
primary
thing
that
we
do
here
is:
first,
we
create
a
git
tag
in
the
curriculum
repo,
so
we
say,
like
you
know,
for
creating
a
version
0.40.
Then
we
create
a
git
tag
that
says
0.49
up
pretty
straightforward.
What
we
then
do
is
we
also
take
the
text,
that's
in
the
changelog
and
we
rotate
it,
and
then
we
create
a
github
release.
Out
of
that,
so
I'll
keep
this
open
and
I'll.
E
E
I
need
to
delete
that
normally,
obviously,
normally,
if
he's
this
release
would
apply
to
this
tag,
so
I'll
fix
that,
but
but
you
can
see
that
basically,
what
we
did
in
the
workflow
is:
we've
taken
the
text
from
the
changelog
all
the
things
that
have
changed
in
the
curriculum
from
the
last
release
and
we've
competent
into
this
into
this
into
this
release.
That's
done
automatically
for
us
as
part
of
this
task.
Now,
that's
all
well
and
good,
but
this
is
this
is
the
most
interesting
part
of
the
of
the
new
workflow.
E
This
is
something
we
weren't
doing
before,
something
that
I
wanted
to
do
for
a
long
time,
because
it's
actually,
this
has
actually
been
kind
of
a
problem
for
us.
If
you
go
to
the
curriculum
repo
you'll
see
that
in
the
in
the
images
directory,
we
have
all
the
images
that
are
used
in
various
lessons,
and
so,
for
instance,
I.
You
know
or
David
G
built
the
terraform
lesson,
and
so
what
he
did
was
he
created
an
image
based
on
our
utility
image.
E
Actually,
he
created
a
docker
image
that
runs
not
only
terraform
as
in
the
software,
but
also
the
specific
provider
that
he
built
and
what
we
do,
then,
is
we
we
build
that
image
and
we
publish
it
on
our
docker
hub
and
then
we
refer
to
that
in
our
lessons
and
and
that
way
the
image
keeps
being
used
there.
Unfortunately,
the
way
that
we
currently
do,
that
is
we
throw
for
most
of
our
lessons.
We
specify
no
docker
tag
and
what
what
happens
when
you
pull
a
docker
image
it
by
default.
E
But
if
we
made
a
change
to
one
of
these
images
we
we
would
effectively
be
impacting
production
directly
and
it
makes
it
really
hard
to
change
to
make
improvements
on
these
images.
If
we
know
that
it's
gonna
make
it
maybe
break
production.
So
that's
not
great,
so
as
part
of
the
new
workflow.
What
we're
doing
is
we're
actually
building
each
one
of
these
images
for
every
release
and
so
we're
not
just
building
it
once
and
then
letting
it
sit
out
there.
E
What
we're
doing
is
we're
for
every
time
we
do
a
release,
we're
building
it
on
demand
and
we're
tagging
it
with
that
specific
version.
So
if
the
curriculum
version
is
you
know
one
node?
Oh
no,
and
we
do
this
workflow.
Not
only
is
the
github
release
gonna
get
created
like
it's
like
I
showed
before,
but
we're
also
gonna
be
building.
E
All
of
these
docker
images
with
that
tag
as
well
and
syringe
in
production
is
going
to
know
to
use
that,
and
so
we'll
be
able
to
do
is
make
changes
to
the
images
without
impacting
production,
and
this
works
today,
so
I
tested
a
few
days
ago
actually
and
that's
exactly
how
the
0.40
release
in
the
curriculum
was
published.
What
I
need
to
do
is
github
is
kind
of
funky.
Apparently
this
tag
vvo
23.3
existed,
even
though
we
didn't
do
a
3.3
release
and
what
what
github
does
is.
E
It
applies
the
release
to
the
to
the
latest
available
tag,
and
so
what
I
need
to
do
is
delete.
It
basically
undo
all
this
and
rerun
it,
but
that's
okay.
This
wasn't
meant
to
be
an
actual
official
release
anyway,
this
is
more
of
a
test
run.
We
we
haven't
decided
if
this
is
the
the
next
version
that
we
want
to
release.
The
point
of
this
is
now
the
way
that
we
released.
D
E
D
E
So
eight,
so
basically
there
were
it's
been
a
while,
since
our
last
release
and
what
we're
doing
now
actually
is
those
we're
just
rolling
forward.
There
were
a
bunch
of
things
we
were
waiting
on
just
because
we
wanted
to
get
a
release
out
the
door,
but
it
we
we
knew.
We
wanted
to
do
this
before
that
first
release,
because
we
wanted
to
make
sure
that
we
had
the
ability
to,
for
instance,
be
able
to
build
images
without
affecting
production.
So
we
went
through
and
we
did
this.
E
E
This
workflow
was
was
a
was
a
big
part
of
it
and
that's
finished,
and
once
you
know
once
like
the
the
the
the
the
the
lessons
we're
working
on
at
the
moment,
once
those
are
finished,
we
can
cut
a
release
of
the
curriculum
and
that,
like
I,
said
that
doesn't
take
long.
It's
you
know
that
it's
fully
automated
and
and
assuming
there's.
E
E
And
we're
pretty
excited
bout
that,
for
a
number
of
reasons,
bare-metal
is
the
service
provider,
because
it's
you
know
bare
metal,
there's
just
a
number
of
things
that
are
that
are
better
about
that.
First
off.
The
servers
that
we
picked
are
actually
cheaper
than
the
VMS
we're
using
right
now.
Google
compute,
but
they're.
E
Like
we've,
we've
we've
held
off
on
using
some
of
our
larger
images,
just
because
we
know
that
they're
gonna
take
a
little
bit
longer
to
spin
up,
but
that's
hopefully,
gonna
be
ameliorated
by
the
move
to
packet.
Also,
toad
could
probably
elaborate
on
this,
but
his
experience
of
the
cumulus
image
has
been
extremely
fast
like
that
thing
boots
very
quickly.
So
we're
also
very
excited
about
getting
lessons
with
that.
Yeah.
B
E
That
is
not.
A
A
C
E
That's
all
that
I
wanted
to
show,
but
yeah
I
mean
I'm.
Sorry,
sorry,
again,
I
joined
a
little
late.
I
feel
bad
about
that,
but
we
were
excited
if
it's
not
clear,
we're
very
excited
about
all
the
failure,
we're
we're
in
a
mode
that
we
don't
hold
that
we
don't
want
to
do
a
lot
of
like
we
don't.
You
know,
want
to
make
a
habit
out
of
like
you
know,
constipating
up
all
these
changes
and
you.
E
Them
go
all
at
once,
like
you
know,
four
months
worth
of
work
all
at
once:
that's
it's
not
very
agile,
so
we
will
have
something
to
show
for
it.
We'll
have
a
lot
of
new
content
all
at
once
and
a
lot
of
cool
new
features
all
at
once,
but
I
I
would
like
to
return
back
to
them
more
agile,
like
you
know,
releasing
something
every
week
or
so
ready
every
two
weeks
or
so.
So,
thanks
for
your
patience,
no.