►
Description
Developer Tooling for Kubernetes Configuration [I] - Gareth Rushgrove, Puppet
Writing Kubernetes YAML files provides a simple starting point for most users of Kubernetes. Mainly through the power of copy and paste we all get our first examples working. But as usage of Kubernetes grows, spanning teams and time, we build up a lot of those YAML files. Many people reach for templating, or look at higher-level tooling like Helm packages next. But catching errors is still mainly a manual process of running the resulting configuration against a working Kubernetes cluster.
In this talk we’ll look at what’s missing in this workflow, looking for inspiration from developer tooling from other languages and frameworks. In particular we’ll consider:
* Ways of providing feedback about invalid configuration in our text editors
* Validating configuration against the Kubernetes types, especially useful when generating that configuration from templates
* Checking Kubernetes configuration is valid for different versions of Kubernetes
* What unit testing our Kubernetes configuration looks like
* How to integrate all of this together into a continuous integration based workflow
We’ll show examples using straight YAML files, templating and higher-level tooling like Helm and Jsonnet. The talk will also cover the benefits of a standard development environment, especially for new users, and provide tips for those getting started and more experienced users. The audience should come away with ideas for making there Kubernetes experience more efficient and more developer friendly.
About Gareth Rushgrove
Gareth Rushgrove is a principal software engineer at Puppet. He works remotely from Cambridge, UK, building interesting tools for people to better manage infrastructure. Previously he worked for the UK Government Digital Service focused on infrastructure, operations and information security. When not working he can be found writing the Devops Weekly newsletter or hacking on software in new-fangled programming languages.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
well
we'll
get
started
ad
quick
shoutout
to
the
AV
people,
who've
just
saved
my
bacon.
My
computer
was
not
working
and
they've
turned
it
with
a
new
one
in
record
time,
so
we
can
actually
get
started
on
time.
So
thank
you.
Every
people,
so
hopefully
you're
here
to
hear
about
developer
tooling
for
Q
betty's
configurations,
so
I
I
work
for
puppet
and
there's
a
few
bits.
All
like
the
background
to
this
talk
is
rooted
in
a
lot
of
my
experience
with
as
a
user
of
puppet
and
then
a
puppet.
A
A
This
talk
is
gonna
cover
a
sort
of
instructors
could
and
testing
infrastructure
as
code
and
why
that's
relevant
and
I'll
prescient,
even
for
kubernetes
community
I'm,
going
to
talk
about
a
lot
of
specific
types
of
testing,
and
that
is
useful
to
do
configuration
I'm
going
to
talk
through
a
bunch
of
demos
and
examples.
They
were
gonna
be
live
demos.
My
laptop
doesn't
work
if
you
want
to
see
them
actually
working
come
see
me
later
so
who,
in
the
rooms
familiar
with
the
term
infrastructure,
is
code.
Lots
of
people
excellent
and
who's
who's
actually
had
experience.
A
Maybe
again,
like
I,
said
only
member
of
people
about
half
again
I'm
Wikipedia
puts
it
like
this
and
sort
of
it's
a
process
of
managing
provisioning
computers
to
machine
readable
definition,
files
rather
than
physical,
Hardware
like
this,
is
how
most
people
are
interacting
with
kubernetes
today,
they're.
Definitely,
writing
machine,
readable
definition.
Files
we'll
come
back
to
whether
llamo
handwriting
mo
is
a
good
way
of
doing
that
later.
Movie.
A
Stepping
back,
and
so
that
concept
has
been
around
a
while:
let's
not
come
from
committees,
it's
not
come
from
puppet.
It
predates
that,
but
one
of
the
roughly
2011
something
interesting
happened
and
actually
wasn't
just
a
spec
puppet.
There
was
chef.
Spec
is
was
the
same
year.
There's
a
few
of
the
tools
and
aspect
pop.
A
It
was
a
tool
for
using
the
Ruby
r-spec
testing
library
to
validate
and
verify
your
puppet
manifests
and
say:
Jeff
Beck
was
exactly
the
same,
and
this
idea
definitely
does
likes
of
span
different
communities,
I
know,
sort
of
public
lens
and
food
critic
from
the
chef
world
and
a
number
of
us
and
I'm
less
familiar
with
some
of
the
salt
Hansel
testing
stuff.
Finding
there's
some
tools
there
and
and
those
tools
have
really
stood
the
test
of
time
in
those
communities
and
they've
been
around
a
while
they've
matured.
A
They've
ended
up
in
the
sort
of
the
actual,
like
the
best
practice
way
of
doing
things.
They've
added
value
and
I
think
it's
an
interesting
sort
of
journey
with
respect
to
where
we
are
today
with
like
configuration
files
for
Cutie's,
because
you
start
asking
the
same
questions
in
those
worlds
as
well
as
this
one
and
which
is
fundamentally,
if
you
like,
but
it's
just
a
declarative
thing
I'm
just
saying
this
is
what
I
like
this
is.
The
state
of
the
system
should
be.
A
Why
would
I
test
that
and
I
think
it's
a
valid
question
and
I
think
as
an
observation
and
increasingly
that
configuration
would
your
past
that
hello
world
when
she'll
pass
that
first
example,
we
shall
pass
that
sort
of
that
first
application
with
a
few
deployments
and
and
you're
into
multiple
teams
and
multiple
bits
for
the
organization
and
you're
into
how
many
ammo
files-
and
you
start
seeing
patterns
emerged,
you
start
seeing
tempting
in
some
cases
you
start
seeing
high
level
tools
and
others,
and
you
start
seeing
logic.
You
start
seeing
wanting
to
pass
arguments.
A
A
A
few
guns
as
well,
but
they're,
sort
of
I
think
this
is
the
direction
that
at
least
a
of
the
community
will
go
as
these
tools,
mature
and
I
know,
as
an
example
of
actually
a
really
good
sort
of
public
example
of
other,
more
real-world
deployment
and
the
bitNami
folks
have
got.
Coup
manifests
reaper
public
for
a
bunch
of
their
services
and
if
you
go
through,
there's
actually
and
they
used
json
e,
which
is
basically
a
sort
of
like
programming
language
for
json
data.
A
But
they've
got
two
thousand
lines
of
that
json
it
and
that
actually
expands
into
more
than
seven
thousand
lines
of
jason
in
their
case.
And
so
you
might
knock
a
few
lines
off
for
yeah
more
but
seems
a
lot
of
the
magnitude,
and
this
is
not
actually
I
mean
I.
Think
they've
got
a
few
clusters
in
there.
A
It's
not
like
organization
large-scale
size
and
but
that's
a
lot
of
content
to
not
use
something
like
JSON
it
or
a
high-level
programming
tool
and
there's
actually
loads
of
those
about,
and
this
isn't
really
to
talk
about
that-
and
this
is
all
a
side
band,
but
I
nothing
Brian
grant
as
part
of
the
setting
of
the
application
definition
working
group
went
out
and
found
I
think
having
a
has
a
list
of
43
I
can't
list
all
of
them.
I
presume
no
one
else
come,
but
there's
definitely
like
that.
A
That
number
points
to
people
with
a
sort
of
a
challenge,
a
problem
and
I-
don't
think
it
is
that
there's
one
answer.
The
variety
of
tools
and
the
different
types
is
interesting:
sort
of
side
conversation
if
you're
interested
in
that
come
and
join
the
application,
definition
and
working
group.
That's
starting
to
get
going
and
talking
about
this
we've
had
a
few
meetings
with
not
much
else
yet.
So
the
sort
of
crooks
of
this
talk
is
that
I
posit
that
the
lessons
learnt,
applying
testing
practices
to
infrastructure
as
code
apply
and
will
increasingly
apply
to
communities.
A
A
But
if
you
look
those
tools,
if
you
look
at
the
sort
of
they're
reasonably
mature
soft
sad
testing
tools
from
some
of
the
configuration
management
tools,
they
prepare
you
sort
of
see
they
break
down
into
sort
of
there's,
often
something
that
deals
with
validation
and
I.
Is
this
going
to
be
valid
and
there's
sort
of
linking?
There
are
practices
that
the
community
has
come
to
that
says.
A
Realistically,
if
you
look
at
testing
tools
for
Java
or
Python
or
JavaScript,
then
you'll
see
this
sort
of
set
of
things
emerge
and
I
want
to
sort
of
start
the
conversation
and
maybe
answer
some
bits
of
like
what
what
would
tools
to
address
these
problems.
Look
like
for
Kiwi
at
ease,
so
first
of
all,
I
want
to
talk
about,
is
validation.
A
So
really
it's
starting
to
our
ask
the
question:
is
this
a
valid
qts
config
file?
And
you
don't
have
to
answer
that?
You
probably
didn't
want
to
answer
that
either,
and
this
is
just
as
much
text
second
again
on
the
slide
reasonable-sized
that
hopefully
people
at
the
back
can
see
as
we've
just
seen
that
even
a
reasonably
sort
of
smallish,
it's
all
set
you're
into
thousands
of
lines
of
this.
Are
they
valid
becomes
a
difficult
question?
Is
this
valid?
A
A
I
was
running
small
clusters
because
I
was
building
tools
against
them.
So
I
got
obsessed
with
the
API
really
quickly,
and
you
have
these
like
really
strong
primitives,
like
deployments
and
pods,
and
services
and
controllers,
and
there's
sort
of
that
there
hundred
and
odd
more
now-
and
this
is
all
described
in
basic-
using
open
API
what
was
originally
swagger.
So
there's
a
community's
description
of
the
entire
API.
That's
also
generated
from
various
different
places
in
the
pub
in
the
communities
code.
A
I
can't
I
I
can't
show
that
I'm
sort
of
brought
this
up
as
a
slight
in
flight
jest,
because
I
think
it's
too
now
eighty
five
thousand
lines
of
Jason
that
describes
the
kubernetes
api.
Again,
you
thinking.
Well,
that's
not
something
that
people
can
read,
that's
something
that
tools
can
use
and
one
of
the
things
about
the
sort
of
the
direction
of
travel
with
open
api.
There's
multiple
different
versions:
committees
using
version
two
there's
some
good
stuff
in
version,
3
I
think
I
talked
to
her
API
machine,
refocus
about
that
and
open
API
descriptions.
A
A
So
what
I
went
about
doing
when
I
was
all
thinking
about?
How
can
I
validate
all
these
things?
Because
I
want
to
do
it?
Client-Side
I,
don't
want
to
have
a
server
for
every
version.
I
want
student
thing
with
and
I
actually
extracted
out
of
the
open,
API
schemas
the
JSON
schema
bits
and
then
broke
that
down
into
separate
files
and
broke
that
down
by
the
versions
of
communities.
I
need
to
automate
this
a
bit
better.
A
Ultimately,
there's
a
repository
filled
for
every
single
version
of
communities,
with
an
entire
set
of
JSON
schemas
for
each
of
the
types
that
we
deal
with
and
there's
ones
that
roll
that
up,
there's
a
bunch
of
different
flavors
and
till
though
that's
a
really
large
amount
of
Jason.
This
got
out
of
hand
quite
quickly
and
really
think
about
this
I
said
the
the
swagger
spec
for
well.
The
open,
API
spec
called
swaggered
of
Jason
in
the
repo
is
about
85,000
lines.
A
That's
25,000
files
in
that
git
repository
amounting
to
seven
half
million
lines
of
Jason
that
describe
the
shape
of
all
of
these
primitives
in
committees
for
every
version
of
Q
Betty's
in
a
bunch
of
different
fibers,
again
they're.
Like
that's
knowledge,
you
need
to
validate
something
that
is
not
knowledge
that
any
one
same
person
could
have
in
their
head.
So
there's
our
yeah
and
actually
then
that's
on
top
of
that
there's.
Actually
all
the
equivalents
for
open
ships
as
well
published
so
there's
they
extend
the
API
in
a
few
different
put
on
top.
A
So
there's
separate
specs
for
that
for
those
that
are
familiar
with
JSON
schema
and
all
those
that
not
it's
bits.
It's
just
a
way
of
describing
a
schema
for
a
JSON
document
in
the
way
that
a
database
schema
describes
a
schema
for
a
database
and
there's
a
whole
bunch
of
sort
of
low-level
tools.
They'll
be
libraries
in
most
programming
languages
that
are
using
the
dirted,
json
schema
and
so
grab.
A
The
sort
of
the
canonical
saw,
Python
client-
and
you
can
do
jet
schema
pointed
out
here
like
well
accumulate
these
config
hello,
nginx
and
I'm
grabbing
them,
basically
just
to
file
off
disk
and
saying
well
grab
me
the
standalone
deployment
scheme,
X
NASA
deployment,
and
it's
saying
well
actually
that's
missing.
A
template.
Template
is
a
required
property
and
this
is
a
useful
integration
point
for
other
tools.
So
if
you
are,
if
you
are
building
something-
and
you
want
to
have
validation
in
your
tool,
then
you
can
just
use
the
schemas
from
a
user
perspective.
A
A
Checking
against
multiple
versions
of
communities
is
a
good
one
there
as
well
you
you
might
be
running
multiple
of
different
versions
in
different
places.
You
might
be
looking
to
update.
You
might
be
looking
to
make
sure
you're
not
doing
something.
That's
going
to
cause
a
migration
to
fail
later.
That's
all
sort
of
valid
use
cases,
and
that's
where
coop
Val
comes
in.
So
this
has
been
around
a
little
a
bunch
of
months.
So
there's
a
few
people
using
this
as
well
now,
but
I've
not
talked
to
loads
about
it.
A
So
four
months
got
into
this
picture
if
I
took
that
recently,
all
this
is
is
a
nice
command-line
interface
for
validating
cue
methods,
configurations
so
I
say
like
you
can
do
it
with
the
jet
and
schemas.
This
adds
a
tool
on
top
that
gives
you
a
friendly
UI.
So
you
can
see
you
can
sort
of
pass
the
different
versions.
You
can
ask
whether
it's
an
open
shift.
A
You
can
actually
host
and
generate
your
own
schemers
if
you're,
adding
custom
resources
and
it's
very
simple
and
you
can
either
just
point
it
out
config
file,
and
it
will
give
you
some
information
about
issues
that
it
finds
it
will
actually
with
a
sensible
status
curve.
But
so
you
can
use
it
as
part
of
a
pipeline
and
it
will
take
things
on
standard
standard
in
so
you
can
just
pipe
things
through
it
and
as
the
saw
chain.
So
it's
hopefully
a
nice
small
well-behaved
little
testing
util
and
it
works
with
Leslie
like
multiple
declaration
files.
A
A
It
would
be
so
nice
to
do
this
with
multiple
versions
and
password
like
so
comma
separated
value
doesn't
do
that
yet,
but
that
would
be
nice
and
because
I
think
this
is
one
of
the
sudden
flight
useful
features,
its
implementing
go
and
Sue's
actually
available
as
a
library
as
well
for
the
ger
tools.
I'm
I
think
that's
pretty
new
I'm
after
as
much
feedback
on
that
as
possible,
because
I'm
not
sure
the
interface
is
right.
A
So
wouldn't
you
have
validation
and
you
cellphone.
You
do
find
that.
That's
not
enough.
A
number
of
people.
I
said
all
that's
all
that's
handy,
but
but
because
realistic
advises,
validation
says
something
is
valid,
but
it
doesn't
say
whether
or
not
it's
what
you
intended
and
it
will
blithely
let
you
do
silly
things
as
long
as
they
valid
so
talking
to
lots
of
people
and
I
know
my
colleagues
running
committees.
Everyone
ends
up
with
this
script
or
a
lot
of
people.
A
I
know
with
this
script
that
they
run
against
all
that
kumail's
configurations
in
probably
in
that
CI
tool
of
choice
that
checks,
a
bunch
of
different
properties,
and
so
I
did
a
talk
to
a
bunch
of
people
in
person
that
I
knew
we're
already
doing
this
I'd
sort
of
put
some
stuff
on
the
internet,
and
we
talked
about
it
say:
gaps
and
a
bunch
of
people
sent
me
these
scripts
and
and
nearly
everyone
was
like.
Oh
yeah,
we
haven't
shared
this
because
it's
really
junky
it's
like
just
this
like
like.
A
It
seems
like
a
good
time.
We
add
on
to
things
and
now
it's
like
loads
of
things,
with
a
lot
of
logic
and
its
really
useful.
We're
like
we
need
it,
but
like
we're,
not
sharing
it,
because
it's
like
horrible
that
came
up
and
like
I'm,
not
going
to
name
any
names,
but
I
mean
like
half
the
people
said
something
similar
and
but
it
to
me,
it's
valuable
like
the
fact
that
people
are
using
it
they're
doing
it.
A
It's
an
emerging
pattern
and
what
I'd
like
to
see
is
basically
a
like
a
way
that
we
can
share
and
use
our
some
of
our
tools
and
not
everyone
has
to
go
through
the
same
thing
and
it
becomes
a
bet
like
more
there's,
more
awareness
of
it
because
there'll
be
lots.
People
thinking,
oh
I,
haven't
so
about
having
a
script.
A
That
checks
my
code-
and
this
was
sort
of
brian
saying,
like
their
internal
tooling,
included
some
new
links,
they're
rendered
helm,
charts
and
validates
certain
rules
so
talking
to
bunch
people
and
some
looking
at
a
bunch
of
these
scripts,
you
see
a
number
of
different
types
of
things.
People
could
regularly
do
and
ultimately
you
have
these
data
structures,
but
lots
of
people
and
say
well:
I,
don't
want
peg
put
in
pods
backs
without
resource
requests.
Like
my
cluster
runs
into
problems,
the
operators
will
hate
me.
A
Let's
make
sure
that
no
pod
specs
don't
have
resource
requests
as
Diane
Miller's
writer
talk
yesterday
about
like
building
things
on
top
of
metadata
and
right.
If
you're
building
things
on
top
of
metadata
and
labels
and
annotations,
you
need
to
make
sure
your
levels
of
annotations
are
there.
So
it's
really
common
for
people
to
say,
like
things,
must
be
labeled
with
these
things
that
maybe
a
label
that
says
this
service
or
deployment
is
owned
by
this
team.
Otherwise,
I'm
not
I'm,
not
deploying
it
not
happening
and
preventing
usage
of
latest
images
again.
A
Sort
of
again,
like
you'll,
read
a
lot
of
the
sort
of
best
practice
type
stuff
committee.
Saying
don't
do
do
that
how'd,
you
make
sure
people
aren't
doing
it.
You
have
a
script
that
reads
your
data
structure
and
there's
a
number
of
other
sort
of
examples
of
the
types
of
things
people
are
doing
so
with
all
of
that
I
wanted
a
tool
that
made
that
sort
of
both
easy
for
you
to
write
those
types
of
scripts,
but
also
then,
hopefully,
share
them
with
the
community
and
so
I'm
being
working
on
a
little
bit
of
this.
A
This
is
coupons,
pretty
mature,
there's
a
bunch
of
people
using
it,
it's
sort
of
both
7:00
or
so
it's
had
a
few
releases
and
a
bunch
of
bug.
Reports
and
Cube
Jesse's
brand
new
I
saw
ship
this
a
couple
of
days
ago,
so
we'll
definitely
have
issues,
but
I
think
that
the
approach
is
hopefully
interesting
and
this
talks,
partly
if
it
hasn't
one
takeaways
like
go,
have
a
look
at
this
and
tell
me
whether
you
like
it
or
not.
A
So
what
coop
test
does
is
basically
allows
you
to
write
tests
against
your
configuration
and
basically
writing
assertions
again
for
those
types
of
things
or
others,
and
again
it's
packaged
a
small
CLI
tool.
You
run
it
against
your
config
files
and
it
will
output
information
about
passing
and
failing
assertions
and
again
in
similar
way.
You
can
pass
things
to
standard
in
and
it
will
hopefully
be
well-behaved.
It
will
output
status
codes
sensibly,
so
you
can
use
it
as
part
of
a
pipeline
tests
themselves
are
written
in
Scylla,
which
is
a
I
sort
of
considered.
A
Writing
this,
as
basically
like,
like
with
like
existing
unit
testing
tools.
What
I
saw
with
what
sort
of
different
organizations
were
doing
was
some
people
just
wrote
a
script?
Some
people
were
like.
Oh
yeah,
like
this
fits
with
like
how
you
write
unit
tests
and
they
would
write
unit
tests
and
they
would
use
the
the
tooling
around
the
unit
test
framework.
The
problem,
very
simply,
everyone
prefers
a
different
language
and
and
the
fits
unless
the
language,
the
problem,
it's
more.
A
The
runtime
and
Ruby
as
a
language
might
be
easy
enough
to
go
like
hey,
it's
Ruby
yeah,
you
can.
If
you
can
program
C
like
language,
you
can
program
Ruby
a
bit
like
just
for
something.
That's
very
Devane
specific.
On
the
other
hand,
now
you
need
to
know
how
to
manage
and
install
Ruby,
and
no
one
wants
to
know
that
I
tell
ask
me
how
I
know
so.
A
Sky
larkings
actually
is
a
dialect
of
Python,
so
it's
actually
super
familiar
to
anyone.
Who's
programmed
anything
like
Python
nods.
Also
like
C
bits
pieces,
it's
untied,
Dannic,
high-level
data
types
with
flourish
and
examples,
but
the
reason
I
picked.
It
is
basically
it's
designed
to
be
embedded
in
other
tools,
so
you
download
coop
test
and
that's
all
you
need.
That's
it.
Everyone
gets
the
sky
like
interpreters
practices,
the
tools
there's
no
other
runtime
is
nothing
else
to
install
and
cube
test
is
written
in
go
so
it
basically
nice
static,
binaries
for
different
operating
systems.
A
I
think
like
for
me
and
I'm
interested
in
feedback
on
this.
I
I'd
like
a
tool
that
facilitates
sharing,
and
I
think
the
moment
you
go
into
different
language
communities.
Basically,
it's
harder
to
share
practices
across
them,
so
hence
an
embedded
language
and
I
went
the
skylight
of
something
like
room,
Ruby,
fed
lot
of
experimental
reasons
more
than
anything
else.
So
what
what
does
that
look
like
what
the
test
actually
looked
like?
Well,
here's
a
few
examples
and
I
mentioned
that
sort
of
idea
of
saying
well
like
we
don't
want
latest
images.
A
Well,
here's
an
example,
and
so
well
again
you
can
solve
it
read
the
code,
but
we
see
if
it's
a
replication
controller,
let's
loop
through
all
the
containers
in
the
template
and
let's
extract
the
tag,
and
let's
assert
that
it's
not
latest
and
testing
the
minimum
over
replicas
again
similar
we're,
saying
well
replication
controller
and
grab
some
information
from
that
structure.
Make
an
assertion
and
that's
the
pattern
that's
the
like,
and
you
might
have
some
get
some
gates.
A
You'll
probably
have
some
extracting
data
out
of
templates
and
you'll
have
some
assertions
and-
and
they
say
that's
Scott
like
as
language.
The
things
to
know
are
the
sort
of
special
bits
that
cube
test
brings
r-spec,
that's
the
objets,
the
committee's
object,
that's
the
that's!
The
deserialized
like
from
llamó
or
jason,
or
other
tools
like
that
has
the
Kubek
use
object
in
and
the
assertions
basically
cube
test
comes
with
a
number
or
a
but
sort
of
ten,
or
so
like
common
assertions
for
common
things,
so
like
assert,
contains
fail
and
not
equal,
equal
assert.
A
True,
you
get
like
common
assertions,
bad
that
you'll,
find
in
unit
testing
tools
and
there's
not
much
magic,
so
another
example
mentioned
sort
of
enforcing
labels.
It's
as
simple
as
something
like
this
also
worth
noting
that,
like
you
kind,
these
are
very
direct.
If
you
had
a
lot
of
them
well,
you
can
write
functions.
You
can
write
your
own
in
skylark
to
be
used
by
others,
so
you
could
boil
it
down
to
your
own
DSL.
A
So
coop,
that's
new
I
would
love
some
feedback.
If
people
are
writing
these
scripts
or
not,
please
have
a
look
I
mentioned
linting
earlier,
but
so
it
went
to
unit
testing
first
because
I
think
what
like
organizations
having
their
very
specific
rules
like?
Oh,
you
must
have
a
team
label
and
it
must
be
one
of
these
teams
and
is
really
useful,
and
you
can't
that's.
A
That's
not
a
general
problem,
that's
specific
to
your
like
patch,
and
but
there
are
things
where
they're
probably
useful,
so
they're
like
best
practices
for
anyone
starting
out
and
what
I
would
like
to
see
is
basically
like.
If,
if
people
like
who
tests,
can
we
build
a
coop
test
test,
suite
that
we
use
as
that
sort
of
common
best
practice,
starting
the
life
linting
tools
and
again
that
becomes
rather
than
you
have
to
write
your
everything
from
scratch?
It
becomes.
Oh
I
have
these
ones
that
everyone
else
thinks
good.
Oh
and
I.
Disagree
with
that.
A
A
Yeah
I'd
like
to
make
maybe
so
event
light
and
out-of-the-box
experience
cube
test
or
something
similar
or
a
separate
repo
with
a
bunch
of
sort
of
common
tests.
There's
actually
collaborated
on
by
loads
of
folks
I'm
gonna
talk
about
a
bunch
of
this
difference.
The
gaps
when
I
get
a
chance.
I
had
finished
writing
things
first,
so
this
was
where
I
was
going
to
dive
into
live
demos.
Unfortunately,
I
can't
as
computers.
Luckily,
I
have
slides
for
everything,
which
was
a
good
job
in
hindsight.
A
A
So
we
love
doing
some
of
the
design
decisions
for
some
of
these
tools
around
being
well
behaved
like
command-line
tools
be
like
standard
in
standard
ow
error
codes
was
because
there
are
lots
of
different
tools
in
using
connections
for
generating
that
configuration
like
from
just
handwriting
yeah
Mille,
to
templates
to
custom
template
thing
like
engines
to
helm
to
case
on
it
to
pop
it
to
cage
like
there
are
loads.
Having
testing
tools
for
individuals.
A
Are
you
individually,
for
those
is
probably
not
the
right
answer,
and
some
of
them
will
have
them
and
puppets
already
good
testing
tools,
JSON,
it
actually
has
a
testing
library,
but
the
more
you
write
tests
for
those
with
individual
tools,
the
more
you're
locked
into
those
tools.
If
you
can
write
your
tests
in
something
more
general,
you
can
swap
the
tools
out
at
the
same
time
as
have
your
tests
and
I.
Think
that
is
really
powerful,
because
what
like
the
tool
is
going
to
get
better.
A
So
if
we
were
to
ruin
helm
template
in
this
case
nginx
from
the
helm
examples,
it
would
output
a
load
of
Jason
or
yeah,
more
I,
think
sam'l
and
again
here.
If
we
pipe
it
through
cube
vowel.
Well,
we
can
verify
that
that
salad
and
and
nicely
it
is
valid.
I
was
happy
with
that.
I
was
thinking
like
odd
I
hope.
This
is
not
an
invalid
one,
because
that
would
that
would
be
bad.
A
A
A
There's
been
some
talks
on
it
already
and
you
end
up
writing
in
a
much
higher
level
language,
and
so
you
can
see
sort
of
variables
and
if
you,
if
you
sort
of
squint,
you
know
yeah,
there's
a
container
and
there's
a
deployment
and
the
deployment
continue
contains
the
container
yep
and
if
we
run
JC
JSON
it
against
that
it
would
output
the
JSON
file,
the
JSON
for
gratis
that
matches
the
API
and
interestingly
Kate
the
case
on
it.
Library
is
actually
built
from
the
open,
API
spec.
A
So
there
is
actually
less
of
a
need
of
like
this
here,
because
this
should
always
be
valid
and,
having
said
that,
it's
because
coop,
like
there
it's
built
from
a
single
version
of
committees,
it's
useful
to
be
able
to
validate
it
against.
Maybe
a
different
one
gets
into
solder,
and
the
coop
test
works
exactly
as
well
with
with
okay
so
on
it
just
on
it,
as
it
does
other
tools
and
again
they're,
like
JSON.
A
A
Similarly,
flip
it,
you
can
write,
create
something
in
there.
Perfect
language
pop
it
yourself
with
a
whole
bunch
of
abstract
things
there.
You
can
use
public
communities
convert
to
generate
that
jason
and
you
can
pipe
that
through
Cleavon
cube
test.
You
get
the
idea.
A
like
this
is,
broadly
speaking,
should
be
true
of
well-behaved
other
tools
in
the
queue
message:
ecosystem,
anything
that
can
output
to
standard
out
or
anything,
so
they
can
output
to
a
file
and
should
work
with
Cooper
and
Cooper
test.
A
Other
said,
the
there
are
a
few
people
using
Cooper
already
Brian
from
sky
in
the
UK
has
sort
of
made.
This
observation
on
Twitter
and
obviously
I've
dissolved
demos.
Examples
have
been
interactive,
they're,
useful,
locally
and
bad.
She
out,
if
you
are
in
a
team,
if
you're
in
a
group
of
people
doing
things
over
time,
you'll
probably
want
to
integrate
them
into
a
CI
system.
So
I've
got
an
example,
repo
up
that
I
sort
of
talked
about
this
na,
and
so
now
we're
a
guy
wrote
a
quick
example.
A
There's
a
travel
example
of
just
doing
of
doing
exactly
this.
So
all
Travis
does
this
pulls
down
COO
Val,
cube
test
and
actually
helm.
It
takes
a
helm
examples
and
validates
it
against.
If
you
can
squint
to
the
bottom,
there's
basically
a
matrix,
build
for
different
environment
variables
for
different
versions.
A
Getting
thar
lines
here
would
be
nice
to
have
saw
one
of
those
like
one-line
install
the
type
things
so
now
coming
in
self
concluding
I
say
if
people
do,
if
you
want
to
see
these
things
in
actually
in
action,
come
and
see
me
later
I,
the
community
is
definitely
still
exploring
different
ways
of
writing.
Qa
these
configurations
and
that
sort
of
tool
explosion
is
part
of
that,
and
but
communities
like
as
a
like
now
we're
tying
one
of
the
themes
of
the
conference.
A
I
guess
has
been:
let's
get
a
lot
more
conversations
going
about
running
things
on
top
of
qu
Betty's,
not
just
humanities
itself.
The
project
over
time
should
be
the
boring
bit,
and
the
things
we
can
build
on
top
should
be
more
interesting.
I
think
the
bad
tools
we
have
there,
the
easier
that
becomes
and
more
people
approacheth.
A
One
of
the
things
I
think
I
keep
going
back
to
in
again
led
some
advances.
Ins
is
this
concept
of
the
configuration
complexity,
clock
and
everyone
sort
of
wants
there
to
be
one
tool
and
that
idea
of
43
tools
is
sort
of
quite
scary
and
and
over
time,
they'll
probably
be
winners
and
the
things
that
have
become
a
bit
more
niche
and
but
it
nearly
never
completely
collapses
to
one
or
two
or
even
three
and
Parv.
It's
this
idea
of
well
actually
hard
coding,
sometimes
is
really
nice.
There's
nothing
in
your
way.
A
There's
not
another
tool
chain.
There's
not
another
thing
to
learn,
there's
not
something
that's
different
to
anything
else
anyone's
doing,
but
that
can
be
really
both
and
you
had
templating
and
variables
and
it's
sort
of
nice
but
then
runs
into
other
problems,
and
you
then
ended
up
solving
a
well.
Can
we
have
a
sort
of
rules
engine
can
we
have
a
domain-specific
language
and
you
get
cross
all
the
way
around.
There
are
trade-offs.
There
are
pros
and
cons,
and-
and
it's
often
based
on
people's
sensibilities
individually,
but
also
the
organization
they
work
in
ones.
A
Who
will
probably
won't
work
for
everyone?
Actually,
if
you
can't
have
build
tools
that
composable,
like
with
the
testing
stuff
that
can
potentially
and
as
I
mentioned
a
few
times,
some
of
them
do
lend
themselves
to
native
testing
if
you're
using
the
Kotlin
DSL,
which
is
really
nice
like
you,
could
just
write
your
testing
Kotlin,
it's
not
as
portable
or
as
understandable
for
the
bigger
broader
community
is
something
like,
hopefully,
good
von
Koopa
test.
A
So
making
them
like
one
of
the
things
I'm
trying
to
do
is
build
tools
that
are
portable
and
I'd
love
to
know
whether
that
works
for
people,
so
that
and
that's
sort
of
two
things.
I
think
there
are
other
two
tools.
Rather,
there
are
other
areas
of
testing
for
humans,
I
think
like
if
we
can
jump
ahead
and
go
like
what
does
the
development
environment
look
like,
so
where
you're
building
things
with
Cuba
at
ease
and
if
you're,
if
you
are
sort
of
totally
abstracted
away,
it's
the
tool?
A
Builders
that
need
these,
not
you,
and
but
if
you
are
building
things
like
natively
run
kubernetes
these
things
become
interesting.
What
are
the
bits
of
testing?
What
do
we
need
without
good
testing
tools?
You
don't
really
attract
the
best
developers
and
when
I
know,
whenever
I
like
look
at
and
you
like
the
programming
language
I'm
always
like.
Well,
what's
the
testing
which
I
want
to
learn
that
all
right
as
well
I
think
once
you
get
into
more
programming
languages,
that's
a
common
pattern.
A
We
need
that
to
bring
more
application
developers
to
humans,
because
there
are
there's
loads
of
inspiration.
We
can
take
from
I,
not
just
the
sort
of
Ironhide.
So
I'll
come
from
that
sort
of
configuration
management
space,
but
what
tools
are
really
good
in
other
space,
other
spaces
and
there's
whole
areas
of
some
interactive
debugging
that
I
haven't
talked
about,
but
I
other
people
will
have
lots
of
experience
with
there's
lots
of
inspiration.
We
can
take
from
things
that
have
worked.
Can
we
jump
ahead
by
just
getting
some
of
that
done
now,
rather
than
realizing?