►
From YouTube: Kubernetes SIG Apps 20171113
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
And
we've
got
a
handful
of
thing
so
before
we
get
into
today,
we've
got
some
updates
from
core
projects
and
from
ecosystem
projects.
We've
got
a
discussion
and
we
have
a
demo,
maybe
and
a
number
of
announcement,
so
I'm
gonna
start
with
the
announcements
first
of
all,
normally
around
the
US
Thanksgiving
holiday,
because
so
many
people
are
out,
we
have
a
tendency
to
cancel
the
Monday
before
Thanksgiving.
We
can
do.
A
There's
been
some
talk
about
the
Monday
before
Thanksgiving,
because
I
know
some
people
take
off
those
three
days
to
get
a
really
long,
Chuck
a
time
off
or
the
Monday
following.
Do
we
have
any
preference
on
this
or
thoughts
from
folks?
The
current
plan
is
to
take
off
next
Monday,
because
just
so
many
people
would
be
gone.
A
A
If
you're
interested
in
what's
happening
in
those
conversations
as
well,
that
all
falls
under
say
gaps,
but
we've
actually
gotten
a
separate
channel
for
those,
because
it's
kind
of
a
subtopic
of
everything
that
we
do
and
so
look
out
for
that
coming
hopefully
by
the
27th
I'll,
be
able
to
share
a
URL
or
on
the
list
before
then.
The
other
thing
that
isn't
on
here
for
the
announcements
we'll
be
updating
the
calendar,
invite
for
this
meeting
a
new
invite
soon
because
of
some
logistical
stuff.
A
We
don't
control
the
invite
anymore,
which
is
why
some
folks
have
asked
for.
Can
you
get
the
agenda
attached
to
it?
Can
we
get
some
changes
to
it?
It
turns
out.
We
don't
actually
control
how
to
invite
anymore
and
we've
got
to
go
clean
that
up
and
so
we'll
be
getting
a
new
invite
here
in
the
near
future.
Some
keep
a
lookout
for
that,
probably
on
the
27th
I'll,
announce
it
and
it'll
come
out
to
the
list
by
then
we're
just
giving
you
a
heads
up,
and
so
with
that
those
are
our
quick
announcements.
A
A
A
A
Thank
you,
so
it
doesn't
sound
like
we
have
anybody
on
to
talk
about
that
all
right,
so
we're
gonna
actually
have
to
get
on
that
pretty
soon.
For
anybody
who
knows
or
is
interested
in
this
topic,
because
we
have
code
slush
coming
up
on
Monday,
the
20th
and
code
freeze
on
the
22nd,
and
so
if
we're
actually
gonna
make
that
switch
and
then
pull
it
off
cleanly
across
everything,
we
need
to
get
it
done
now
and
so
I'll
fire
off
some
emails.
Ten
I
see
you're
on
now.
A
A
No,
maybe
not
alright,
well
I
will
have
to
chase
this
one
down
offline.
If
anybody
runs
into
somebody
working
on
that,
please
chase
them
down
and
make
sure
otherwise
I'll
be
doing
that
as
well.
Then
we've
got
jobs.
We
do
have
a
flaky
failing
test
for
jobs
as
well.
Is
anybody
on
to
talk
about
jobs?
Who
can
talk
about
them?
Let's
jobs
and
cron
job.
A
B
I
I
there's
a
great
blog
post
on
the
Microsoft
blog
about
Brigade.
If
you
want
to
get
started
and
kind
of
read
up
on
it,
but
and
new
stack
ran
an
article
recently
about
it
too,
but
in
a
nutshell,
what
we
wanted
to
do
was
we
wanted
to
build
a
system
that
would
work
sort
of
like
shell
scripting
for
kubernetes.
So
when
you
think
of
writing,
like
a
bash
shell
script,
this
is
kind
of
how
it
goes
right.
B
You
say:
okay,
there
are
a
bunch
of
tools
that
I
already
have
on
my
system
that
accomplish
bits
and
pieces
of
various
tasks
right,
there's
a
sort
command
I
can
use
to
sort
stuff.
There's
an
LS
command.
I
can
use
to
list
the
directories
of
in
my
in
my
file
system
and
so
on.
Right
they're,
a
bunch
of
binary
commands
that
each
do
separate
things,
but
a
shell
script
is
basically
a
way
of
combining
them
and
building
something
bigger
and
better
out
of
those
things.
So
you
know
I,
add
a
little
bit
of
control
structures.
B
I
had
a
little
bit
loopy
and
things
like
that,
and
suddenly
my
eight
or
ten
different,
disparate
binary
commands
that
exist
on
my
operating
system
can
be
glued
together
to
build
something
more
elaborate.
Now
when,
when
we
looked
at
the
way,
kubernetes
was
going,
we
noticed
some
interesting
trends
and
one
of
them
is
that
kubernetes
is
remarkably
good
at
running
one-off
tasks.
We
have
both
the
job,
API
and
sort
of
the
pod
primitive.
B
The
batch
API
has
jobs
in
it
in
the
pod,
primitive,
both
of
which
are
very
good
at
running
individual
tasks,
but
it's
also
very
good
at
running
servers
right
and
we
have
focused
very
heavily
on
operating
servers
on
kubernetes,
but
not
so
much
on
running
individual
tasks.
So
we
got
to
playing
around
with
this,
and
we
said
you
know
what
what
could
we
do?
That
would
show
off
more
of
kubernetes
usefulness
when
it
comes
to
running
these
tasks
and
we
thought
well
on
on
a
standard
operating
system.
B
The
kinds
of
things
you
like
be
able
to
do
is
script
up
different
things
and
be
able
to
run
them,
and
that's
what
sort
of
set
us
on
the
course
about
a
year
and
a
half
ago
to
writing.
Brigade
brigade
is
essentially
a
tool
for
building
pipelines
in
kubernetes,
scripting
pipelines
in
kubernetes,
so
that
you
can
kick
off
a
particular
task
and
a
particular.
You
know
at
a
very
high
level
right,
I
want
to
kick
off
some
process
and
have
it
run
a
whole
bunch
of
individual
jobs
and
pass
data
from
one
part
to
another.
B
So
what
you're
gonna
see
is
a
way
of
event-driven
scripting
of
execution
of
well,
essentially
zero
or
more
containers
in
such
a
way
that
you
can
chain
them
together
and
do
some
fairly
elaborate
things
with
them
all
right.
So
I'm
gonna,
try
and
share
my
screen
here.
I'm
just
going
to
share
the
console.
B
B
Miss
Brenna
says
you
know,
so:
let's
try
clearing
that
again,
all
right,
so
here
I
am
in
a
directory.
I've
got
a
brigade
script
here
now.
Brigade
can
listen
to
all
kinds
of
events,
so
you
can
set
it
up
to
listen
to
github
web
hooks.
You
can
write
fairly
sophisticated
ones
on
your
own,
but
the
most
trivial
one
that
we
can
do
is
to
just
use
the
brigade
command
line,
which
is
brig.
So
this
is
brig
here.
B
Brig
has
a
couple
of
interesting
commands,
so
we're
gonna
just
list
out
projects
so
when
I
create
a
new
brig
set
up,
whyisign
I
create
projects
and
a
project
is
basically
the
way
for
me
to
divvy
up
who's
allowed
to
do
what
we're
OK
and
a
script
then
gets
assigned
to
a
project.
So
I'm
going
so
I've
got
a
couple
projects
there.
B
B
Here's
my
script,
okay,
so
it's
a
very
simple
Java
Script.
We
pick
JavaScript
for
a
very,
very,
very
straightforward
reason.
We
went
and
looked
at
all
the
language
rankings
on
all
the
different
languages
compiled
a
none
compiled
and
Java
Script
tends
to
float
in
the
top
three
positions
on
just
about
every
language
ranking
we
could
find.
So
we
went
alright
if
we're
gonna,
try
and
do
something,
that's
easy
to
use.
B
Let's
go
with
the
one
that
you
know
hovers
right
at
the
top,
so
we
picked
a
JavaScript
engine
and,
and
so
the
language
for
expressing
these
scripts
is
JavaScript.
So
here's
my
little
brigade
script,
all
it's
going
to
do
is
it's
going
to
listen
on
an
event
called
exec
which
happens
to
be
brigades
default
event
and
every
time
the
exact
exec
event
is
fired.
It's
going
to
log
the
console
message:
we'd,
okay!
B
B
Now
it's
starting
up
a
couple
of
pods
inside
of
my
kubernetes
kubernetes
cluster:
it's
starting
up
a
kind
of
master
worker
pod,
which
is
the
important
one
and
that
one's
going
and
firing
off
and
there
we
go
so
it
started
up
a
master
worker
pod
loaded,
the
JavaScript
into
it,
dropped
to
the
console
the
message
weave
and
then
destroy
it.
Okay,
so,
let's
you
know
kind
of
start
to
get
a
little
idea
for
what
else
we
can
do
with
this
okay.
B
So
the
way
you
chained
things
together
is
you
declare
jobs,
so
here's
what
a
job
looks
like
will
be
proper
and
do
VAR.
J
1
equals
new
job,
so
every
job
has
to
have
a
name
and
then
a
job
will
execute
a
pod
or
a
container
so
I'm
going
to
specify
one
for
us.
What
is
the
current
Alpine?
Is
it
3
5
3
6
we'll
go
with
3
6?
Okay,
so
this
is
just
going
to
download
and
execute.
This
is
actually
just
going
to
load
up
the
alpine
container.
B
If
we
want
to
run
the
alpine
container,
we
just
tell
it
hey.
We
want
you
to
run
that
ok,
so
right
now
we
have
a
script
that
if
I
ran
it
would
just
start
up
a
new
pod
running
Alpine
3
6
run
whatever
its
default
target
was
and
then
exit
not
terribly
interesting,
because
Alpine
has
no
default
tasks.
So
what
we're
gonna
do
is
we're
gonna,
add
and
I.
B
That's
in
the
tasks
list
is
getting
executed
inside
the
container,
so
the
job
says
this
is
the
container
I
want
to
use,
and
the
task
says
this
is
what
you're
going
to
do
inside
the
container.
So
if
I
were,
for
example,
compiling
a
go
program,
I
could
pull
down
the
go
colon
goal
and
:
you
know
1/8,
pod
or
whatever,
and
then
my
tasks
list
I
could
do
a
go,
build
or
something
like
that,
but
I'm
just
going
to
do
something
in
simple
JavaScript
or
a
simple
shell
command
here
and
do
an
echo
hello.
B
B
There
we
go
so
now:
it's
gonna
spin
up.
First,
the
worker
pod
executes
the
J
s
and
there
that
that
worker
pod
is
going
to
start
its
own
hello
world
one,
and
we
can
see
that
the
hello
world
one
actually
started
up
here
and
then
fired
and
then
exited
now
I
didn't
see
the
hello,
because
I
didn't
tell
it
to
do
anything
with
that.
I
would
have
to
dump
that
information
back
out
to
the
console.
If
I
wanted
to
do
that.
So
we
use
if
you're
familiar
with
Java
scripts
method
of
promises
and
promise
resolution.
B
B
So
again,
we're
running
this
is
going
to
start
up
the
worker
pod.
It's
going
to
kick
off
that
Alpine
pod,
but
this
time
it's
going
to
wait
till
that
Alpine
pod
finishes
and
then
it's
going
to
grab
the
result
of
that
Alpine
pod
and
dump
it
out
to
the
command
line.
So
here
I
can
see
here's
my
hello,
so
pod
echoed
hello
to
its
to
its
output.
The
JavaScript
captured
that
and
then
logged
that
to
my
console.
B
B
B
B
This
should
run
two
pods
for
us
and
run
them
sorry
about
that
should
run
those
in
parallel.
So
we
should
see
it
try
and
start
up
both
the
J
one
pod
and
the
J
two
pod,
both
around.
At
the
same
time,
it
actually
started
them
both
very
fast
finished,
both
of
them.
We
see
the
output
of
the
first
one
because
we
log
that
one
to
the
console,
but
we
can
get
fairly
sophisticated
and
we
can
start
doing
things
like
group.
B
B
So
there
we
go
so
this
is
sort
of
like
a
short
and
simple
demo
of
the
kind
of
starting
point
for
what
we're
working
on
with
Brigade.
So
you
can
begin
to
imagine
the
kinds
of
things
that
you
can
do
with
a
system
like
this,
where
you
can
take
a
fairly
sophisticated
set
of
containers
and
you
can
pull
these
those
two
containers.
I
pulled.
There
are
just
two
straight
up
alpine
pods
out
of
docker
okay,
so
you
don't
have
to
write
custom
containers
to
use
this.
It's
just
like
the
way
you
shell
script.
B
When
you
shell
script,
you
just
use
the
commands.
The
OS
provides
you,
you
add
the
write
flags,
you
add
the
right
arguments
and
it
just
runs,
and
then
you
can
pipe
data
from
one
to
the
other.
That's
basically
the
same
kind
of
model
that
we're
going
after
here
you
can
execute
container
after
container.
You
can
pipe
data
from
one
into
the
other,
there's
some
more
sophisticated
kinds
of
things
that
we
could
look
at
at
some
point
in
the
future,
like
being
able
to
persist
data
from
one
job
to
another
on
a
file
system.
B
So
you
can
dump
one
thing:
dump
a
file
dump
a
bunch
of
files
from
one
container
and
then
read
them
back
into
the
next
container,
and
we
also
didn't
look
at
gateways
today.
Gateways
are
the
ways
of
piping
data
from
outside
the
cluster
in.
If
you
go
take
a
look
at
the
brigade
repository
there's
a
video
there
where
we
basically
take
Trello
and
you
drag
items
from
one
board
to
an
from
one
column
to
another
in
Trello
and
that
acts
as
the
trigger
it
fires
off
an
event
and
that
kicks
off
a
brigade
script.
B
So
in
that
case,
and
then
that
in
turn
comes
and
notifies
you
via
slack,
that
a
thing
was
moved
from
one
column
to
another
and
it
stores
it
in
a
database
because
we
can
start
to
orchestrate
some
fairly
elaborate
pipelines
by
using
brigade
this
way.
So
what
I
wanted
to
give
you
today
was
just
sort
of
like
a
very
quick.
B
You
know,
relatively
dirty
demo
of
sort
of
like
the
core
functionality
of
Brigade,
and
you
know,
coming
over
over
time
here
will
start
to
show
off
some
of
the
other
features,
probably
not
always
in
cig
a
but
here
and
there
and
record
some
videos
for
you.
But
this
was
just
designed
to
kind
of
give
you
a
little
bit
of
an
introduction
happy
to
answer
any
questions.
Otherwise,
that's
all
I
got.
C
B
Good
catch
good
catch,
so
behind
the
scenes
we
want
to
make
sure
that
job,
1
and
job
to
have
some
place
where
they
can,
where
they
can
store
information
in
a
common
space.
So
so
what
you
saw
there
is
each
time
I
spin
up
a
new
worker.
It
also
grabs
a
PVC
and
it
grabs
one.
That's
a
that's
a
rewrite
many
PVC
and
it
mounts
that
PVC
to
any
job.
That
asks
to
have
a
mount
point
for
that.
B
So
say
that
I'm
building,
you
know
your
kind
of
basic
build
tool
chain
right
and
I
want
to
run
a
go,
build
on
my
first
step,
say:
I've
got
a
project
that
has
some
go
code
in
some
JavaScript
code.
Right
I
want
to
run
a
go,
build
on
my
first
step,
so
I
want
to
go
container
there
and
I
want
to
transcode
some
typescript
to
JavaScript
in
my
second
one,
but
I
want
to
do
that
on
the
same
piece
of
you
know
the
same
trunk
of
the
file
system.
B
So
we
use
that
PVC
system
and
we're
still
kind
of
trying
to
tune
that
one
up
a
little
bit,
which
is
why
I
didn't
show
it
here
because
right
now,
it's
kind
of
slow,
but
we
want
that
PVC
volume
as
sort
of
a
way
where
we
can
mount
the
same
shared
file
system
for
all
of
them.
There's
a
second
PVC
volume
that
you
can
optionally
mount
that
allows
you
to
have
a
job,
a
job
cache.
So
again,
going
back.
To
that
go
example
say:
I
want
to
cache.
B
Data
between
two
separate
hook
runs
okay,
so
you
know
I
want
to
cache
my
internet
intermediary,
build
data,
or
maybe
the
resolved
version
of
my
dependencies
I
can
do
a
cache
which
will
span
multiple,
builds
for
the
same
job
and
then
what
you
were.
What
you
pointed
out
was
a
build
wide
shared
file
storage
that
goes
from
one
job
to
another,
so
we
have
both
sort.
You
can
think
of
them
as
a
horizontal
and
a
vertical
method
of
storing
and
sharing
files,
rhod
asked
any
thoughts
on
declarative
API
for
Brigade,
something
like
concourse.
B
We
started
with
yeah
mole
and
we
realized
that,
just
as
it
would
be
very
difficult
to
have
a
completely
declarative,
scripting
language,
it's
very
difficult
to
accomplish
the
main
kind
of
stuff
we
do,
but
we
had
talked
here
and
there
about
adding
sort
of
like
a
simple
ammo
format.
On
top
to
allow
very
basic
pipelines.
B
We
just
never
bothered
pursuing
it
because
everything's
written
in
JavaScript,
you
could
actually
implement
that
in
JavaScript
on
your
own
and-
and
that
would
be
a
relatively
straightforward
kind
of
thing,
but
our
our
design
goal
was
to
build
a
scripting
language,
thus
not
necessarily
declarative
in
the
in
the
typical
sense
of
like
you're
straight
forward.
Yeah
no
file
or
something
like
that.
That
answer
that
question
cool.
D
The
question
about
sort
of
I
guess
your
intended
scope
when
you
just
talked
about
processing
events
from
Trello,
it
started
reminding
me
a
little
bit
of
lambda
and
some
of
the
sort
of
workflow
stuff
stuff
than
Amazon
does.
Is
that
something
as
an
area
that
you
have
in
mind?
Do
you
have
sort
of
like
an
upward
limit
on
the
volumes
of
events
you
the
process
in
this
way,
or
do
you
have
thoughts
on
developing
into
that
area?
Yeah.
B
Very
good
questions,
so,
first
of
all,
comparisons
to
lambda
or
any
kind
of
function
as
a
service
are
an
interesting
comparison
because
in
in
several
ways,
you'll
see
notable
overlap,
especially
the
sort
of
the
concept
of
an
event-driven
thing,
which
is
by
no
means
unique
to
a
fast
sort
of
system.
But
it's
definitely
a
prominent
characteristic
of
a
function
as
a
service
system,
and
we
did
I
mean
the
way
I
would
describe.
This
is
yeah.
B
It
is
also
an
event-driven
system,
also
couldn't
be
used
to
solve
many
of
the
same
class
of
problems
but
again,
but
but
with
an
inverted
model
right
where
the
lambda
model
is
you,
you
write
the
functions
as
the
big
piece
right,
and
so,
if
you,
a
five
step,
application
requires
five
different
lambda
functions
to
execute
our
tweet
right.
We
actually
ended
up
sort
of,
and
this
wasn't
intentional-
we
weren't
intentionally
trying
to
one-up
lambda
or
anything
like
that.
B
We
were
just
trying
to
realize
our
vision
of
a
shell
script
and
what
ended
up
being
the
case
was
ours.
Focus
is
more
on
flow
where
the
implementation
details
are
localized
in
containers,
while
lambda
and
other
kinds
of
things,
the
emphasis
is
on
how
you
describe
each
step
and
flow
is
sort
of
a
secondary
concern.
So
they
end
up
being
kind
of
interesting
comparison,
contrast
models
and
sort
of
one
of
those
things
that
we
didn't
really
realize
it
till.
We
were
well
down
the
path
and
then
we
went
oh
wait
a
minute
people
are
gonna.
B
Ask
us:
how
does
this
compare
to?
You
know
functions
as
a
service,
and
at
that
point
we
went
oh
interesting.
You
know
there
are
some
definite
overlaps
and
some
definite
differences,
and
in
some
cases
you
would
use
you
could
use
either
tool
to
solve
the
same
problem
and
someone
or
the
other
is
going
to
be
a
much
clearer
case.
B
The
second
question
you
asked
was
a
volume
based
right:
what's
the
volume
something
like
this
could
handle
so
our
projects
about
to
been
open
source
for
about
two
weeks?
So
so
we
actually
have
no
data
about
what
the
upper
volume
is,
our
sort
of
intention
when
we
designed
it
was-
and
this
is
mainly
for
organizational
purposes-
that
you
would
tend
to
install
brigade
into
basically
like
your
namespace
inside
of
a
cluster-
keep
them
relatively
constrained,
and
you
might
have
several
different
brigade
instances
in
several
parts
of
your
cluster.
B
We
could
run
at
a
time
or
anything
like
that
if
anybody
ends
up
testing
it
and
hits
some
limits,
please
let
us
know,
because
it'd
be
nice
to
have
some
targets
to
shoot
for.
Oh
thank
you,
Adam
Adam
dropped
into
chat
and
the
link
to
the
project,
which
is
good,
Brigade
SH
is
sort
of
like
the
front
website
to
it,
but
it's
a
better
place
to
go
is
straight
to
the
github
repo
and
dive
into
the
docs
folder
there.
A
You
thank
you
Matt
for
the
demo
and
thanks
everyone
for
the
lively
discussion.
So
with
that
we
have
a
handful
of
tooling
stand-ups.
We
wanted
to
walk
through.
If
you
have
your
own,
that
you
wanted
to
talk
about,
please
feel
free
to
add
it
to
the
list
under
tooling,
stand-ups
and
we'll
get
to
it.
But
we
do
have
a
number
here.
So
let's
start
rockin
through
them
and
see
who's
here
to
talk
about
it.
First,
one
there's
a
project
called
telepresence.
Does
anybody
here
to
talk
about
it?
Hi
I?
A
D
So
telepresence
is
basically
a
two-way
proxy.
It's
designed
for
for
debugging
and
developing
services
in
kubernetes.
So
a
lot
of
times
when
you're
working
at
on
top
of
kubernetes.
It's
really
easy
to
create
services
that
depend
on
a
lot
of
other
services,
and
that
makes
writing
code
kind
of
a
pain,
because
you
can't
run
that
code
locally
at
least
not
easily
as
soon
as
it
grows
too
many
other
either
kubernetes
service,
dependencies
or
external
cloud
dependencies,
and
so
telepresence
telepresence
aims
to
solve
that
problem.
It
really
takes
the
way
it
works.
D
D
We
can
that
we
then
direct
it
to
either
process
a
local
process
on
your
laptop
or
a
local
container
or
local
container
network
on
your
laptop,
and
then
we
also
capture
any
outgoing
network
traffic
and
we
capture
DNS
as
well
from
your
application,
so
any
any
outgoing
traffic
from
either
that
process
or
the
container
network
gets
routed
back
into
the
cluster.
And
you
know
just
as
if
your
code
was
actually
running
inside
the
cluster.
We
also
proxy
the
environment
variables
down
and
we
proxy
the
filesystem
down
as
well.
D
So
you
can
have
access
to
any
secrets
or
volume,
outs
or
config
maps
that
your
code
would
need
to
access
that
we're
actually
running
in
the
cluster,
and
this
lets
you
use
all
of
your
local
dev,
tooling,
sort
of
exactly
the
way
way.
You
would,
if
you're,
hacking
on
things
locally,
but
actually
run
your
code
as
if
it
was
in
the
cluster.
E
Yeah
hi
this
is
Scott
I,
seem
to
remember
when
we
were
working
on
our
after
core
OS
fest.
There
was
a
small
working
group
to
think
about
local
development
using
kubernetes
and
not
too
long
after
that.
Telepresence
came
up
a
lot
in
conversation.
I
was
wondering,
if
you
wouldn't
mind
just
going
through
that
scenario.
How
would
one
do
that
or
maybe
I'm
totally
mistaken
and
that's
this
is
really
not
the
tool
for
that.
E
But
at
that
point
we
were
talking
about
using
host
1/2
and
running
locally,
using
mini
cube
at
that
time
and
I
think
like
relatively
soon.
You
know,
docker
for
Mac
is
gonna,
have
native
or
I
guess,
maybe
a
dozen
I
just
don't
have
the
beta
yet,
but
native
act
developed
our
native
kubernetes
stuff
built
in
but
I
think
a
lot
of
people
are
thinking.
How
are
we
going
to
develop
locally
with
this?
If
we're
not
going
to
use
a
cloud
ID
yeah.
D
Yeah
sure
so,
there's
a
couple
of
different
strategies,
and
so
one
way
is,
you
can
forget
about
containers
at
all,
just
sort
of
run,
whatever
application
you're
running
locally
and
then
telepresence
provides
two
methods
it
can.
It
can
use.
What's
it
called
LT
uses,
LD
preload
to
override
override
network
calls
and
intercept
DNS
and,
and
you
just
it,
just
sort
of
works
as
a
process
launcher
that
way.
So,
instead
of
launching
your
application,
you
launch
telepresence
and
you
facet
the
name
of
your
application.
D
D
If
LD
preload
doesn't
work
with
statically
linked
Braton
binaries,
it
doesn't
work
with
note
I'm,
so
certain
the
certain
applications
that
you
can't
develop
on
using
the
LD
preload
method.
The
VPN
method
is
more
robust
from
an
application
perspective.
It's
also
a
little
more
brittle
from
a
from
a
sort
of
from
an
environmental
perspective,
because
you
know
it
messes.
D
With
IP
tables
and
stuff
like
that,
and
that
just
you
know,
is
that's
different
on
every
laptop
we've
even
found
that
Mac's,
which
are
all
supposed
to
be
the
same
Macs
with
the
exact
same
version
or
the
exact
same
OS,
which
are
all
supposed
to
be
the
same,
have
random
environmental
differences
that
cause
things
to
mysteriously
break
when
you
try
and
do
that
kind
of
stuff.
So
that's
you
know
always
a
challenge,
but
when
it
works
it
works
great
and
then
the
other
method
is,
you
know,
just
tie
into
docker
networking.
D
We
basically
run
the
VPN
inside
a
network
and
we're
inserting
inside
a
docker
container,
and
then
you
can
launch
as
many
other
containers
as
you
want
to
docker
containers
locally,
as
you
want
to
that
are
on
that
same
network
and
and
so,
if
you
have
tooling
that
lets
you
sort
of,
if
you,
if
you're
willing
to
put
your
development
environment
inside
docker
I,
have
yet
still
keep
it
local,
that's
a
pretty
good
option
and
I
know.
There's
some
tooling
that
I
know
like
there's
some
tooling.
That
works
pretty
well
with
that.
D
D
One
of
the
things
we're
interested
in
is
getting
a
feedback
on
what
works
for
people
and
sort
of
trying
to
streamline
those
experiences.
We
know
we
know
people
use
it
for
debugging
and
there's
sort
of
certain
cases
where
you
can
debug
things
a
lot
faster.
This
way
we
want
to
make
it
sort
of
more
streamlined
and
better
used
for
just
sort
of
everyday
dev
experience
work
out
of
the
boxes
we
want
to
find
out,
like
I'd,
say.
Basically
at
a
project
level,
we
have
two
challenges
and
two
things
we're
focusing
on
now.
D
Right,
one
is
one
is,
as
I
said,
testing
right,
because
there's
a
lot
of
different
permutations,
there's
a
lot
of
cluster
vert.
You
know,
there's
different
cluster
versions.
You
know
we
try
to
work
with
OpenShift.
We
try
to
work
with
different
versions
of
kubernetes.
We
try
to
work
with
mini
cube
and
they're
all
a
little
bit
different
and
you
know,
and
of
course
we
try
to
work
on
mac
and
linux
and
we
even
have
some
attempts
that
doing
stuff
on
windows
as
well.
D
So
there's
a
lot
of
permutation
so
involved
with
testing
all
those
different
permutations
is
sort
of
complicated
and
slow.
So
we're
looking
at
trying
to
figure
out
better
strategies,
better
approaches
for
that
and
and
then
the
other
thing
is
just
sort
of
getting
feedback
on.
You
know
what
are
the
different
things
that
what
are
the
different?
What
are
the
most
useful
ways?
People
are
using
it
because
if
we're
kind
of
flying
a
little
bit
blind
like
we
know
certain
certain
things
are
more
brittle
than
others.
But
we
don't
know
what
are
the?
D
A
Alright,
that's
alright,
because
it's
your
first,
you
want
a
little
longer
than
we
normally
go,
but
you
were
able
to
fill
people
in
on
what's
going
on,
so
thank
you.
Okay,
yeah!
Thanks
for
a
spot
along
to
my
question,
appreciate
it
alright,
then
I
guess
we
can
move
on
to
the
helm
one
do
we
have
somebody
who
wants
to
talk
about
how
and
what's
going
on
with
it.
A
B
B
Yes,
it's
out
now
I
believe
it's
out
now
yeah
we
released
it
couple
weeks
ago,
so
we're
continuing
down
the
two-seven
line
of
and
the
2.8
stuff
is
getting
queued
up,
but
we're
trying
to
sync
up
the
2.8
release.
You
know
a
week
or
so
week
or
two
after
the
next
major
kubernetes
release
sooner.
If
the
kubernetes
api
is
free
sooner,
we
are
well
into
the
planning
phase
for
the
helm
summit
and,
if
Michelle
is,
is
around
and
wants
to
jump
in
here
I'll.
F
Hey
I'm
here,
working
on
locking
down
a
date
from
the
venue
right
now
scheduled
for
the
first
week
of
February,
but
that's
not
110
percent
confirmed
like
99%
of
the
way
there
and
we
originally
had
it
for
January.
But
plenty
of
people
came
back
to
me
and
said
that
was
really
close
to
kukai.
They
wanted
me
to
move
it
to
February.
So
that's
what
we
did.
The
CFP
is
open
if
somebody
could
drop
a
link
to
that
forum,
that'd
be
really
great.
F
If
you
have
a
home
story
or
something
you'd
like
to
talk
about
around
the
home
community
like
a
plug-in
or
a
workflow
tool
that
you
created,
on
top
of
it,
you're
welcome
to
submit
a
CFP.
Well
we're
extending
the
CFP
deadline,
I
think
the
first
week
after
coop
con,
and
you
should
get
the
results
a
week
after
that.
That's
it
for
me:
I'll
pass
it
back
over
to
Matt
Farina.
Thank.
A
You
and
so
the
next
one
up
is
charts
and
so
I'll
talk,
charts
real,
quick
here.
So
we're
talking
about
the
community
charts
repo
and
so
there's
a
few
things
going
on
there.
One
of
them
is
that
we're
talking
about
moving
towards
owners
files
so
that
way,
different
charts
can
have
owners
and
not
just
a
maintainer
in
the
file
but
they're
able
to
merge
and
do
other
things
on
them
to
try
to
enable
more
people
to
merge
things
to
speed
up
the
pace.
So
the
chart,
maintainer
x',
don't
become
a
bottleneck
on
the
process.
A
That's
going
to
take
a
little
while
I'm
guessing
a
couple
of
months,
but
we're
looking
at
all
the
things
needed
to
generate
those
files
make
sure
the
right
people
have
permissions
on
the
repo
and
then
the
bot,
the
current
functionality
that
allows
kubernetes
to
do
that.
Isn't
something
called
munch
github,
it's
being
moved
into
prowl,
so
we're
setting
everything
up
and
then
we're
gonna
wait
for
proud
to
take
on
that
functionality.
And
then
prowl
is
what
we'll
go
ahead
and
move
forward
with.
A
So
we
are
looking
at
moving
that
over
and
so
that's
one
of
the
upcoming
things
that
repo
we're
also
looking
at
how
we're
going
to
end
up
with
migration
paths.
So
lots
of
folks
are
using
things
like
apps
v1
beta-2
on
the
workload
API
items
that
they're
using
while
in
kubernetes,
I'm,
gonna,
say:
110,
that's
not
gonna,
be
there
anymore,
so
we're
gonna
look
at
how
we
can
start
notifying
people
and
get
things
moving
to
shift
some
of
those
things
to
use
apps,
v1
or
to
get
into
capabilities
and
how
that's
going
to
work.
A
A
C
C
What
else
we
need
a
lot
of
help
in
terms
of
the
helm
chart
for
chart
museum
so
right
now
you
can
go
to
the
kubernetes
home
incubator
and
bunch
rzm,
but
it's
using
a
what's.
It
called
a
empty
empty
durval
you!
So
if
anyone
can
get
this
working
with
s3,
especially
a
lot
of
people
are
looking
for
that.
Also
we
were
talking
a
while
ago
about
as
your
support
tube.
So
if
anyone's
interested,
please
reach
out
to
me
I'm
on
slack
thanks,
there's
also
a
chart
museum
also
called
slack
channel
as
well.
A
F
I
can
talk
about
draft,
so
yeah
we're
moving
the
line,
we've
gotten
some
user
feedback
lately,
which
is
really
awesome,
so
we're
working
around
some
details
with
Josh
pack
changing
some
of
those
things
very
minor
changes,
there's
a
homebrew
formula
out
there
and
now
so
the
Installer
experience
is
a
little
bit
easier.
The
latest
release
with
ODOT
8
I
believe
if
you
have
any
feedback
or
want
to
check
it
out,
you
know
feel
free
to
jump
in
the
issue,
queue
or
the
slack
channels.
Thanks.
A
G
That
was
me,
I
decided,
so
the
I'm
busy
talking
at
coop
con
about
a
whole
bunch
of
solid
testing,
workflow
tools,
I'm
doing
a
lot
of
research
at
the
moment
and
Michelle
up
the
retweeted
this
and
got
a
few
more
people,
and
anyone
who
has
done
like
is
doing
like
sort
of
linting
or
sort
of
testing
of
committees.
Configs
I
found
I've
sort
of
found.
Is
that
there's
lots
of
people
everyone's
got
this
hats
or
hockey
script?
That
makes
a
bunch
of
assertion
so
we're
not
using
these
resources
or
all
of
our
resources.
G
Have
these
annotations
or
these
labels
or
the
naming
convention
is
always
like
this
or
images
never
use
the
latest
tag.
That's
the
some
of
that
is
generic
I
sort
of
best
practice.
Everyone
might
agree
on.
Some
of
it
is
very
organizational
specific,
like
we
use
this
tag,
schema
and
I'm
trying
to
collect
as
many
examples,
because
what
I'm
interested
in
doing
and
what
I've
got
well
I'll,
probably
hopefully
have
shipped
next
week
in
at
least
the
sort
of
basic
form
is
a
cool
web
tool.
G
That
does
that,
where
we
can
at
all
then
just
not
share
the
tests
without
worrying
about
the
implementation,
without
worrying
about
the
language
they're,
all
written
in
and
all
other
other
bits
so
yeah
if
anyone
who's
doing
any
like
sort
of
linting
of
configs,
I'd
love
to
know
so,
Gareth
at
more
than
seven
dot.
That
or
Gareth
are
on
Twitter.
All
slack
be
a.
G
The
idea
is
basically
that
we've
liked
coop
vowel,
which
is
a
tool
that
does
like
validation
against
the
schema
and
that
validates
against
schema,
but
doesn't
tell
you
the
song,
like
your
organization's
usage,
coop
test
will
be
a
tool
that
allows
you
to
write
assertions
against
all
yokan
things.
So
you
see
it
as
something
that's
complementary
to
something
like
Coopersville
right,
yeah,
yeah,.
A
G
That
the
thinking
here
is
that,
like,
if
you've,
got
a
if
your
programming,
whether
that's
actually
in
your
just
describing
the
date
or
you're,
generating
that
data
with
a
high-level
tool.
You
want
to
know
whether
it's
valid
ie.
But
you
also
want
to
know
that
it's
correct
and
according
to
what
you're
trying
to
do
with
it
and
like
in
programming
languages,
you
would
tend
to
have
some
sort
of
syntactic
validator,
possibly
a
linter.
G
That
sort
of
is
community
good
practice
and
also
then
unit
tests,
which
are
specific
to
your
use
case
and
I'm
sort
of
Kouvola
addresses
the
first
of
those
cube
tests.
The
intention
is
to
address
the
other
two
and
in
that
we
can
share
a
set
of
tests
that
the
community
can
come
to
some
agreement
on
yeah
I'm,
doing
as
much
research
and
finding
as
many
bits
of
prior
art
as
I
can
do
we're.
G
A
One
two
going
three
times
all
right,
then.
The
last
item
we
have
on
here
is
a
discussion
of
one
and
a
half.
So
behind
the
scenes
and
some
mailing
lists
and
other
places,
we've
been
talking
about
the
discoverability
of
things
in
the
ecosystem
and
well,
there's
a
lot
going
on
when
you
think
about
it.
So,
for
example,
well
we'll
get
into
linting.
A
I
was
looking
for
linting
projects
the
other
day
and
it
came
over
the
handful
and
then
I
got
into
a
conversation
with
somebody
who
told
me
about
another
one,
and
it
turns
out
that,
at
least
in
my
experience
in
the
experience
that
I've
had.
Is
that
it's
difficult
to
find
all
of
the
things
that
are
happening
in
a
space?
Where
do
you
want
to
consume
them
or
collaborate
on
them
or
that
kind
of
thing?
A
G
As
a
Faraday
point,
I
did
a
business
either
the
last
time
a
coop
con
in
Europe
on,
like
they
see,
high-level
tools
for
managing
Q,
Massey's,
config
and
I
did
bunch
of
looking
around
a
fungal
load
and
people
came
up
to
me
and
said:
oh,
that's,
quite
can
you
add
mine
that
you
didn't
find
and
the
conversation
was
also
people.
People
mentioned
several
and
yeah,
there's
like
at
the
moment.
The
only
way
of
discovering
any
of
it
is
ad
hoc,
okay,.
A
So
one
of
the
ideas
that
in
fact,
I've
started
a
crafter
proposal
with
some
others
here
is
to
say:
could
we
create
something
that
collected
those
and
made
it
easy
to
search
and
browse
things
by
category
and
things
like
that?
What
do
you
all
think
of
something
like
that?
You
can
think
of
it
as
like,
an
Amazon
Marketplace
except
everything's,
not
just
an
installable
right.
You
could
think
of
it
like
if
you're
familiar
with
Drupal
or
WordPress,
the
plugins
listing,
although
they
don't
have
to
be
hosted
by
that
they
can
be
hosted
anywhere.
A
It's
just
kind
of
an
indirection
pointer,
almost
like
a
if
folks
are
familiar
with
PHP
and
packages
packages
doesn't
like
npm
or
the
others.
It
really
is
just
a
a
metadata
repository
that
points
you
in
the
right
direction
to
things.
What
do
you
all
think
of
something
like
that
to
help
make
it
searchable
and
easy
to
discover
and
find.
E
E
A
Thinking,
I'm,
not
thinking
about
apps,
this
isn't
like
a
preju,
stree
or
helm
charts,
because
something
like
coop
Val
that
doesn't
necessarily
belong
in
a
chart.
It
might
be
just
a
local
thing.
You
use
a
local
application
or
draft,
and
so
a
directory
of
lots
of
things,
not
just
installable
runnable
applications.
E
A
Do
because
you
got
things
like
Kubb
apps
com
built
on
monocular,
and
things
like
that
at
this
point,
I'm
getting
less
into
the
runnable
tools
and
more
of
the
developer
tools
yeah,
but
I
can
see
how
there
might
be
overlap
between
these
areas.
Yeah.
A
Because
in
my
experience
anyway
and
others
please
by
the
way,
I'm
talking
about
my
personal
view
here,
if
you
have
a
different
view
or
a
different
slant
on
this,
please
speak
up.
I
want
to
hear
it
and
I
love
to
have
my
views
on
this
stuff
challenge.
But
in
my
view
and
experience
is
that
this
there's
a
human
discoverability
problem
here
right,
and
so
it
would
be
to
solve
that
human
discoverability
problem
of
getting
tools,
not
so
much
the
machine.
A
Now
we
may
eventually
get
into
that,
but
if
you've
got
three
validators
and
you're
gonna
try
to
look.
You
know.
Okay,
give
me
the
validators.
Okay,
now
I've
got
to
try
to
decide
between
those,
that's
a
very
human
problem
based
on
taste
and
features,
and
things
like
that,
and
so
how
would
you
provide
a
place
where
P
could
search
and
find
the
validators
and
then
maybe
have
enough
information
to
say?
Okay,
these
are
the
ones
I'm
gonna,
learn
more
about
and
then
follow
through
to
those
locations
and
make
their
decision.
A
G
That
feels
like,
then
it's
the
I
couldn't
find
anything
that
did
what
I
was
looking
for.
Something
then
I
found
something
later
and
that
can
be
just
handing
on
both
sides
of
like
the
person
who
created
the
first
one
and
the
person
who
create
the
second
one
and
obviously
happens
more
than
once
yeah
so
I,
say
I
with
I
know.
Obviously,
it's
limited
to
get
herb,
but
github
topics
it
as
a
lo-fi
way
of
starting
something
off
here
and
busy
bootstrapping
that
data
set.
A
G
Like
that
would
immediately
give
us
like
some
tools
and
again
it's
opt-in
from
the
point
of
view
of
the
the
creators.
What
you
think
is
the
right
way
around,
and
but
also
then
that
gives
us
so
that
gives
us
a
set
of
things
that
keep
growing
without
having
to
be
curated,
and
ultimately
we
might
want
to
bet
a
user
interface.
G
That
would
give
us
an
idea
of
how
many
there
are
and
whether
that
view
is
useful
in
a
really
low
fi
way
like
no
one's
built.
Anything
at
that
point
it
has
limitations,
but
that
might
be
an
interesting
style.
I.
A
Do
like
how
you've
jumped
from
its
of
not
just
a
valid
assumption,
but
here's
how
we
go
build
it
to
just
just
back
up
for
a
moment
while
I
like
what
we're
going.
Does
anybody
have
any
other
opinions
on
just
whether
this
would
be
useful
or
not
they're
happy
with
something
cuz
like
there's
an
awesome
list
out
there
today
and
are.
Is
that
acceptable?
Sorry,
Rafael
yeah.
D
So
well,
and
what
you're
talking
about
is
I
first
of
all,
I
do
think
it's
a
real
problem
and
it
kinda
reminded
me
of
an
interaction.
I
saw
the
other
day,
I'm
coming
any
slack
and
I
mean
I
I'm
in
the
communities.
D
Looking
for
a
simple
like
one
line
tool
to
deploy
my
house
and
cops
all
right
and
and
that
well
to
me,
it
pointed
to
a
little
bit
sort
of
a
of
a
human
community
of
almost
like
a
user
community
problem
right,
because
there's
sort
of
a
lot
of
different
potential
roles
when
it
comes
to
interacting
with
kubernetes
they're
they're
people
that
tend
them
sort
of
more
operated
and
then
there's
people
that
are
just
trying
to
build
applications
on
it.
And
so,
and
there
was
definitely
cross
talk
going
on
there
and
and
sort
of
miscommunication.
D
Because
of
that
and
then
I
know,
there's
a
whole
lot
of
other
channels
on
on
there
that
are
sort
of
more
narrowly
focused
on
different
different
topics.
But
yeah
I
do
feel
like
there's
a
real
problem
when
it
comes
to
sort
of
funneling
people
who
are
new
to
kubernetes
and
they
know
what
they
want
to
accomplish
and
there's
a
whole
set
of
there's
a
whole
tooling
ecosystem
out
there
and
a
set
of
choices
to
do
it
and
they
they
I,
feel
like
they
almost
need
to
talk
to
the
right
set
of
people.
D
B
I
think
to
piggyback
on
what
Raphael
is
saying
and
come
back
to
what
something
that
Matt
Farina
mentioned
earlier.
You
know,
I
did
Drupal
development
for
a
while
as
well,
and
the
experience
of
findability
from
drupal.org
is
vastly
vastly
superior.
You
know
from
you
know:
I
was
counting
if
any
of
you
didn't
read
my
blog
post
about
this
because
I
about
it
a
couple
weekends
ago,
you
know
in
three
clicks
I
could
find
out
all
the
implementations
of
whatever
I
was
looking
for
all
the
different
to-do
lists
modules,
all
the
different
database
bag.
B
B
You
go
you
put
it
there,
and
people
can
find
it
immediately
and
the
documentation
is
all
centralized
and
is
all
in
the
you
know
same
theme,
so
it's
fairly
easy
to
navigate
and
that
experience
man
I
miss
that,
because
in
the
kubernetes
world,
even
before
I
can
do
anything
like
start
a
new
project
or
work
on
anything.
It's
like
a
little
bit
of
googling
a
little
bit
of
navigating
github
a
little
bit
of
asking
around
and
even
at
the
end
of
that,
I
rarely
feel
like
I
have
a
full
vision
of
all
the
work.
B
Different
people
have
done
in
related
areas
and
several
times
I've
started
projects
only
to
find
out.
You
know
several
thousand
lines
of
code
in
that
there
was
already
something
out
there
that
was
very
similar
and
nothing's
worse
than
wasting.
That
kind
of
time.
Only
to
discover
that,
then,
then
you
end
up
looking
like
a
jerk,
because
you're
reimplemented
something
somebody
else
did
too
so
anything
that
could
increase
findability,
allow
people
to
self
register
I
like
Gareth's
idea
that
you
know
tags
are
an
easy,
simple
way
to
opt
into
something.
B
But
opting
in
is
the
point
that
I
think
is
salient
there
right,
so
yeah
self
registration
ease
of
or
standardization
of
how
to
get
to
documentation.
So
there
would
be
a
link
or
something
like
that,
and
you
know
that
kind
of
stuff
I
think
alone
would
go
a
vast
distance
in
helping,
especially
people
who
are
new
to
kubernetes,
find,
what's
out
there
what's
available,
reduce
duplication
of
work,
increase
the
general
level
of
our
very,
very
large
user
community
yeah.
D
Just
I
I
think
that's
I,
think
those
are
some
great
thoughts
that
I
just
something
you
said.
Maybe
think
of
that.
What
is
it?
The
term
expert
blind
spot
I
feel
like
right
and
Eddie's
is
really
really
good.
Wendy's
is
a
really
powerful
tool,
but
it
has
a
huge
learning
curve
and
so
there's
a
big
expert
blind
spot.
That
sort
of
the
community
needs
to
cope
with
and
so
I
feel
like
it's
all.
It
might
help
them,
maybe
almost
think
of
it
as
a
two-step
process.
D
Right
one
find
the
other
people
that
are
trying
to
do
the
same
thing
I'm
doing
and
to
look
at
the
tools
that
they're
using
to
accomplish
it,
because
that
way,
you'll
get
sort
of
the
new
users
course,
whatever
the
same
level
kind
of
collaborating
to
document
how
to
learn
what
it
is
that
they
learned
at
the
sort
of
their
stage
of
the
journey
and
they
won't
suffer
from
the
entry
points
button.
So
you
get
sort
of
the
right
documentation
for
that
that
point
in
the
learning
curve.
A
All
right
folks,
well,
thank
you
for
the
lively
discussion
we
are
at
the
top
of
the
hour,
which
means
our
meeting
has
come
to
an
end
if
anybody
is
interested
in
maybe
working
on
a
problem
like
this
at
some
point,
I'll
be
if
this
is
something
we
move
forward
on,
I'll
definitely
be
coming
looking
for
other
folks,
thank
you
for
the
input
and
thank
you
for
a
lively,
full
meeting.
Today.
Everyone
have
a
wonderful
two
weeks.
Remember:
we
are
off
next
Monday
for
the
u.s.