►
From YouTube: Tutorial: Hands-on Gitops - Brice Fernandes, Weaveworks
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Tutorial: Hands-on Gitops - Brice Fernandes, Weaveworks (Limited Seating Available - See Description for Details)
In this hands-on tutorial, Brice Fernandes from Weaveworks will go through setting up and using a Gitops pipeline to manage a Kubernetes cluster. This will include setting up monitoring and metric visualisation as well as managing the monitoring configuration using Gitops.After taking this tutorial, attendees will be able to:* Set up their own Gitops pipeline to manage their kubernetes cluster* Compare the desired state of a Kubernetes cluster against the actual state* Deploy Prometheus and Grafana to a Kubernetes cluster* Set up a continuous deployment pipeline for Kubernetes workloadsAttendees should:* Know of kubernetes and the kubectl command line.* Be comfortable with Git* Be comfortable with the Unix command lineNo preparation needed. Attendees will be provided with an online environment to use during the tutorial. Bring a laptop with a modern browser.
To Learn More: https://sched.co/GrT8
A
A
We
kind
of
developed
this
guitar
model
that
you're
here
to
learn
about
today
and
one
of
the
customers
success
engineers
that
we
works,
which
means
I
work
as
an
engineer
with
our
customers
that
you've
got
lots
of
different
titles
in
different
companies
for
the
same
job.
If
you
want
to
find
us
more
about
us,
if
you
want
to
find
more
about
us,
you
can
find
us
at
we've
works,
we've
dot
works
or
just
at
we've
works
on
Twitter.
A
Do
you
get
in
touch
we're
pretty
friendly
Bunch,
so
don't
hesitate
if
you
need
some
help,
jump
on
we've
works
and
ask
questions,
find
our
slack,
which
is
slack
dot.
We've
dot
works
and
ask
questions
there
as
well.
So
today,
I'm
gonna
do
kind
of
split
it
up
in
three
parts.
The
first
part
is
going
to
be
some
get-ups
principles,
so
I'm
gonna
share
with
you
kind
of
how
I
see
get
ups.
A
A
A
Just
to
encourage
you
to
ask
questions
the
first
three
questions
about
guitars
at
least
or
about
the
workshop-
will
get
one
of
the
books
here.
So
I
don't
know
any
questions.
You
know
not
questions
about
astronomy,
but
if
you
want
to
ask
the
question
about
get-ups,
then
you'll
get
a
book.
What
books
are
they?
A
So
the
kind
of
the
first
question
I
want
to
answer
and
kind
of
clarify
and
lay
down
is
what
is
get
ups
and
I
want
to
do
that.
Just
so,
we
can
have
the
understanding
when
we
get
to
the
exercise,
because
one
we
did
with
the
exercise
we're
gonna
get.
Can
you
know
deep
in
the
swamp
of
kind
of
gets
operations
and
merge,
murder,
requests
etc?
So
I
want
to
kind
of
put
a
high-level
overview
first
so
that
we
understand
what
is
get
ups
so
get.
Ups
is
a
bunch
of
things.
A
A
Ethos
is
derived
from
computer
science
and
operational
knowledge,
so
we've
been
running
kubernetes
for
about
three
years
that
we've
works.
So
a
lot
of
the
get-ups
approach
is
derived
from
our
own
operational
expertise
and
there's
a
couple
of
things
that
come
with
output,
the
Preferences
of
get-ups
that
come
from
the
computer
science
side.
A
Name
notwithstanding,
it
is
actually
technology
agnostic.
You
could
do
the
same
things
with
the
same
kind
of
things
with
other
version
control
systems.
So
if
you
want
mercurial
ops,
you
could
do
we
like
it
for
some
interesting
reasons
to
do
with
security
and
trip
auditability,
but
you
can
do
it
with
other
visual
control
systems
and
it's
really
about
the
principles,
not
the.
How
I
mean
we've
works
here.
We
build
tools
about
how
to
do
this,
but
really
this
session
is
about
trans,
transferring
to
you
the
principles
the.
A
So
these
are
kind
of
the
four
principles
of
get-ups
as
I
see
them
and
I'll
go
through
them
one
by
one.
So
the
first
one
is
the
entire
system
is
described.
Declaratively.
That
means
that
everything
in
our
system
is
described
as
data
right.
It's
not
just
code.
It's
data
data
is
implementation-dependent.
A
You
don't
need
a
particular
tool
to
deal
with
data,
even
kind
of
very
novice
programmer
within
the
first
week.
Six
weeks
are
able
to
read
and
write
structured
data,
it's
very
easy
to
abstract
in
simple
ways:
right
data,
abstraction
and
data
templates
are
something
that
pretty
much
everybody
here
is
familiar
with
we're
using
them
a
lot.
It's
easy
to
validate
for
correctness.
A
It's
very
easy
to
do
with
data
to
validate
data,
but
it's
a
much
harder
job
to
validate
code
that
defines
your
infrastructure,
which
is
why
data
is
so
important
there
and
it's
easy
to
generate
a
manipulation
code
right.
It's
very
easy
to
read
and
write
data.
So
how
is
that
a
different
from
infrastructure
s
code?
A
The
issue
we
had
with
infrastructure
as
code
is
that
a
lot
of
the
time
we
we
met
people
and
what
they
the
principles
of
infrastructure
is
code,
is
very
much
about
kind
of
data-driven
declarative
definitions,
but
we
found
people
who
kind
of
put
upon
a
bunch
of
shell
scripts
in
a
repository
and
thought
they
had
good.
This
is
not
the
same
thing
right,
so
it's
about
consistency.
The
failure
case
there's
a
big
difference
between
kind
of
having
some
shell
scripts
running
where
something
could
go
wrong
in
the
middle.
A
So
if
something
goes
wrong
in
the
middle
you're
ending
up
in
a
with
an
inconsistent
system
state
that
you
don't
know
about
right,
there's
a
state
of
your
system
is
now
kind
of
up
for
grabs.
You
don't
know.
What's
going
on
so
doing,
declarative
definitions
of
your
system
means
that
you
can
think
of
transitions
between
state
as
transactions,
which
is
a
very
good
thing
right.
This
is
kind
of
a
very
good
way
of
thinking
about
your
systems,
so
the
next
step
is
the
canonical
desired.
A
State
of
the
system
is
versioned
with
get
alright,
so
you
have
the
you.
Have
this?
The
declaration
of
your
system,
you
really
want
to
have
that
declaration
stored
in
a
version
control
system,
and
this
is
like
your
one
canonical
source
of
truth.
You
want
the
single
place
in
your
system.
That
says
this
is
the
source
of
truth
about
my
sister.
Everything
else
is
derived
and
driven
from
that
source
of
that
source
of
truth.
A
It
trivializes
rollbacks
right
because
a
rollback
now
it
just
becomes
a
get
revert.
You
just
get
revert
to
commit,
and
then
you
just
roll
back
to
your
application
state.
It
has
excellent
security
guarantees.
I
I
will
openly
challenge
anybody
to
find
a
better
system
for
storing
sets
has
changed
and
get
in
a
more
secure
way.
You
can
do
things
like
use
your
key
to
sign,
commits,
etc,
to
enforce
very
strong
security
guarantees
about
authorship
and
provenance
of
your
code.
A
You
can
build
very
sophisticated,
prove
off
process
on
top
of
this
as
well,
so
we
already
have
those
we
have
pull
request:
murder,
request,
processors,
we're
using
them
all
the
time
as
developers,
and
this
is
kind
of
a
good
way
of
thinking
about
your
bringing
those
tools
to
your
application
and
beyond.
Just
human
approval
processes:
we
can
integrate
the
machine
verification
with
our
processes
as
well.
So,
for
example,
it's
a
really
great
place
for
software
and
humans
to
collaborate.
A
A
So
it's
a
really
great
point
when
you've
got
a
git
repository
to
have
your
humans
deal
with
the
code,
but
also
your
machine
deal
with
the
code
and
this
links
back
to
having
the
state
declared
kind
of
the
declaratively
defined,
because
that
declaration
is
readable
by
both
humans
and
machine,
so
approve
changes
to
the
desired
state
are
automatically
applied
to
the
system.
You've
got
this
kind
of
magic
land
of
declared
state.
The
next
step
is
you
don't
just
want
that
to
live
on
its
own?
A
A
The
next
thing
you
want
to
do
is
to
have
software
agents
that
continuously
ensure
correctness
right
your
and
will
alert
you
if
there
ever
diverges
so
you're
continuously.
Checking
that
your
running
system
meets
your
expectations.
You've
encoded!
Your
expectations
you've
done
a
lot
of
work
in
coding,
your
expectations.
Now
you
want
software
that
will
tell
you
whenever
reality
does
not
match
your
expectations,
and
it
means
that
you
can
sell
feel
right.
The
expectations
means
that
you
can,
if
you've
got
those
declared
well,
you
means
that
your
system
can
go.
A
A
So,
just
to
give
you
an
idea
of
kind
of
what
the
pipeline
the
traditional
pipeline
looks
like.
This
is
a
traditional
pipeline
example,
so
you
can
see
in
the
middle
there's
a
CI
step,
so
you
typically
the
CI
system,
you'll,
see
s.
Ci
system
will
have
access
to
your
cluster
and
we'll
start
poking
stuff
into
your
cluster.
When
it
has
a
new
image,
build
right,
you'll
have
some
code
in
your
CI
code
pipeline
that
will
actually
modify
your
system.
A
What
we're
doing
is
removing
all
the
control
from
the
CI
s--
pipeline,
we're
moving
the
control
into
a
config
repository
that
keeps
the
canonical
state
of
the
system.
So
you
have
one
repository
for
your
code
for
your
application
code,
one
for
your
system
configuration
and
that's
what
drives
your
system,
your
or
your
cluster
and
you'll
notice
that
there's
kind
of
the
permissions
to
modify
the
cluster
now
no
longer
live
anywhere
on
the
container
registry,
the
CI
or
your
code
repository.
They
don't
need
authorization
to
do
that,
and
then
you
have
the
operator.
A
That's
you
or
one
of
your
team
members
who
is
going
to
be
working
with
that
configuration
repository
and
you
can
enforce
some
very
good
kind
of
some.
Whatever
your
processes,
your
approval
processes,
you
can
enforce
it
at
that
level
because
you
can
guarantee
provenance
and
origin
etc.
On
the
configuration
repository,
if
you
have
a
good
process
for
enforcing
your
constraints,
that's
got
some
very
good
security
guarantees
and
then
the
actual
state
is
very
well
version
and
you
can
all
date
what
happened?
A
Who
did
it
and
when
and
why
so,
I
kind
of
like
to
think
about
this,
like
functional
reactive
programming,
for
your
infrastructure,
it's
like
react
in
that
you
have
a
state
and
then
your
view
is
derived
directly
from
the
state
automatically
updates.
It's
exactly
like
that
before
your
application.
So
if
you're
a
web
developer,
the
ideas
should
be
somewhat
familiar.
A
So
what
should
be
get
ops
and
and
I
apologize
in
advance
for
get
ups?
That's
a
terrible
term
offence
against
English
grammar,
but
what
should
actually
be
put
under
the
term
get
up
write
a
lot
of
things
so
you're
Cuban
Nettie's
manifests
that's
the
basic
no-brainer
right.
We
all
know
the
Cuban
eTI's
manifesto,
you
know
a
declaration
of
your
state,
that's
great.
The
application
configuration
is
configure.
Humanities
manifest,
is
perfect.
A
You're,
provisioning,
scripts,
you're,
terraform
state
for
your
kind
of
cluster
and
you're
provisioning,
that's
also
kind
of
standard
stuff
to
put
in
there
beyond
that,
though,
we
want
to
have
the
entire
system
defined,
and
that
includes
things
like
dashboards.
You
know
your
dashboard
dashboard
should
be
version
they
should
be
in
get.
You
should
have
access
control
to
your
dashboard,
that's
properly
setup.
You
should
have
a
pipeline
to
continuous
deployment
pipeline
for
your
dashboards
same
for
your
alerts.
You
know
your
all
your
alert
definition.
A
If
your
alerts
live
in
some
third-party
soft
tool
somewhere
that
you
don't
can
you
you
know,
you
can
only
drive
them
through
the
UI.
What
happens
when
something
goes
down?
What
happens
when
something
goes
wrong?
How
do
you
recreate
that
right?
So
your
alerts
deserve
to
live
and
be
first-class
citizens
same
with
your
playbooks
or
run
books.
Your
playbooks
and
run
books
are
the
things
that
you
use
when
you're
on
call,
you
get
an
alert,
something's
gone
wrong.
A
The
play
books
are
the
source
of
information
for
the
on
call
engineer,
so
you're
walking
up
at
3:00.
In
the
morning
the
alert
says
service,
X,
Y
Zed
has
gone
down.
Your
first
kind
of
instinct
is
going
to
your
playbooks
look
up
what
is
service
time,
X
Y
Zed.
What
are
the
common
failure
modes?
How
do
I
fix
it
if
it
goes
wrong
and
then
you
kind
of
go
further
right.
A
Your
application,
checklists
in
four
we've
works,
for
example,
internally
we
encode
best
practices
for
our
application
in
a
small
Yama
file,
and
we
have
a
CI
step
that
enforces
that
those
things
actually
are
true
for
our
services.
So
when
you
release
the
new
services
it
has
to
have
dashboards,
he
has
to
have
alerts.
It
has
to
have
document.
A
It
has
to
have
documentation
so
we're
enforcing
those
kind
of
fairly
high
level
process
ideas
automatically
by
putting
them
in
gear
and
saying
yes,
this
service
has
all
those
attributes,
and
if
it
doesn't,
we
have
an
explicit
exemption
with
a
note
from
the
person
who
made
the
exemption
recording
rule
things
to
do
with
premiere,
prometheus
and
monitoring.
Yeah.
A
So
not
the
application
checklist,
that's
kind
of
deep
in
the
internals
of
our
code
yeah,
so
the
recording
rules
are
kind
of
the
Prometheus
rules
that
you're
going
to
be
using
to
define
alerts,
metrics,
etc,
and
then
you're
sealed
secrets.
So
if
you
look
a
bit
Namie
sealed
secret,
that's
the
way
of
doing
secrets
management
using
the
guitars
approach,
so
everything
right,
your
entire
system
should
be.
A
You
should
be
able
to
have
a
complete
view
of
your
entire
system,
be
able
to
reproduce
the
entire
thing
in
a
new
environment
with
a
few
clicks
right,
if
you,
if
you
have
probably
creating
your
entire
system,
including
the
alerts,
including
all
the
process,
steps
you're
in
trouble
right,
you
now
have
a
system
that
you
no
longer
in
control
of
there's.
Something
goes
wrong,
you're
out
of
luck,
so
this
is
I'm.
Just
gonna
give
you
an
idea
of
kind
of
where
we
apply
this.
This
is
an
alert
definition
in
get.
A
In
this
case,
we
are
we're
using
a
terraform
provider
for
git
github
to
ensure
that
the
defined
state
of
our
guitar
before
ization
kind
of
the
roles
in
github
matches
the
actual
state
of
github
at
any
time.
So
if
something
doesn't
have
doesn't
look,
this
is,
for
example,
a
definition
of
get
a
membership.
For
me,
it's
username
briefs
role
admin.
So
this
is
like
declaration
in
the
terraform
format
of
my
role
within
github
I've,
because
we've
kind
of
kept
pushing
that
approach.
A
Now
I
can
have
all
the
power
I
used
to
have
as
an
admin,
but
as
a
normal
user.
So
who
actually
does
this
is
out
today?
I
should
now
be
just
a
regular
member,
but
the
point
is:
if
something
happens,
if
that
diverges,
we
automatically
get
an
alert
right.
If
the
rules
don't
match
our
expectations,
we
get
an
alert,
so
we've
configured
it
to
give
us
an
alert.
You
could
easily
configure
it
the
same
the
same
tools
to
change
the
roles
back.
A
So
that
kind
of
should
give
you
an
idea
of
kind
of
what
get-ups
is
about
right
and
some
of
the
principles
that
make
it
work
and
you
can.
You
should
be
able
to
see
that
you
can
embody
this
anywhere.
You
want
right.
This
is
not
just
a
particular
to
list
a
set
of
approaches
and,
in
fact,
you'll
probably
use
multiple
tools
to
make
that
work.
A
So
a
lot
of
the
ansible
playbooks
will
have
just
the
imperative
code
in
them
and
that's
where
you
end
up
with
state.
That's
just
you're,
not
sure
what
state
your
system
isn't.
That's
the
big
difference
right,
that's
the
massive
difference,
because
in
practice
things
do
go
wrong
all
the
time
and
and
simple
when
an
ensign
will
playbook
fails
to
perform
its
task,
you're
stuck
somewhere
in
the
middle
and
you're,
not
quite
sure,
on
the
state
of
your
system.
A
Is
it
if
you
actually
do
manipulate
the
state
instead
of
the
instructions
you
have
better
properties
around
kind
of
retrying
things,
knowing
that
you
can
retry,
successfully
etc
and
Cuba
Nettie's
lends
itself
very
well
to
that
approach
right
because
that's
what
it
does
and
I
agree
like
some
systems
won't
have
won't
already
have
the
abilities
to
work
like
this,
so
it's
often
a
case
that
you
kind
of
have
to
put
a
layer
on
top
in
order
to
make
your
work.
Github
is
one
example.
A
I
get
up
does
not
have
a
that's
you
you're,
putting
a
declarative
interface.
On
top
I
mean
it
has
a
REST
API.
So
essentially,
what
you're
doing
is
you're
kind
of
layering
there
it
on
top
of
the
REST
API
okay.
So
now,
let's
kind
of
try
this
now
we've
kind
of
gone
at
the
high
level,
let's
kind
of
go
down
a
level
and
actually
try
and
implement
this.
So
there
should
be
a
repository
at
that
URL.
All
the
instructions
should
be
on
the
repository.
A
What
I'm
going
to
do
is
I'm
going
to
slowly
go
through
it
myself
give
you
an
idea
of
kind
of
how
to
do
things
if
you
want
to
go
and
kind
of
go
ahead
and
keep
going
and
kind
of
I
can
catch
up
with
you
a
little
bit
later.
Just
be
mindful
that
if
you
ask
questions,
I
might
not
be
able
to,
it
might
not
be
useful
to
answer
them
until
everybody's
caught
up
with
you.
A
A
For
the
interactive
environment
that
you're
going
to
be
using
I
highly
recommend
you
try
quatre
Koda
I'm,
not
sure
how
it's
going
to
deal
with
that
many
people
in
the
room
at
the
same
time.
So
we'll
see
if
you
don't
want
to
try
it
out.
If
you
have
a
way
of
provisioning
your
cluster
yourself,
then
please
do
use
it.
If
you
have
mini
cubans,
still
that's
perfect!
That
will
work
with
mini
cube,
so
anything
like
that.
A
A
A
And
while
that's
happening,
you
should
make
sure
that
you
have
the
pre-quiz
prerequisites
for
this
workshop.
You
have
access
to
a
cluster
and
you
have
the
ability
to
create
repositories
on
either
bitbucket
or
github.
If
you
can't
then
you're
going
to
struggle,
because
what
we
need
is,
we
need
to
create
a
remote
repository
to
have
the
control
of
the
state
on
your
cluster.
So
you'll
need
to
be
able
to
create
that
yourself.
A
So
now,
once
we've
got
to
cuba,
Nettie's
cluster
and
we've
got
to
get
hub
or
bitbucket
account.
The
next
thing
you
want
to
do
is
clone
the
repository,
so
you'll
need
to
clone
get-ups
tutorial.
The
repository
you'll
be
you've
been
linked
to
clone
it
in
your
own,
either
bitbucket
or
github
account
and
then
you'll
be
using
that
as
your
remote
repository.
So
all
the
instructions.
When
I
say
you
know
your
URL
of
your
remote
repository
that'll,
be
your
repository
rather
than
in
mine.
I'll
be
working
with
this
one
I'll
be
using
a
this
particular
repository.
A
The
next
thing
to
do
is
we
have
some
files
in
here
that
install
the
the
operator
that's
going
to
be
running
the
show
essentially
for
us,
so
we
have
an
operator
on
the
cluster
and
that
operator
is
going
to
be
responsible
for
watching
the
control
repository
and
as
soon
as
there's
a
change
in
the
control
repository.
The
operator
is
going
to
apply
to
the
cluster.
A
A
Favor,
look
at
what's
inside,
there's
a
set
of
accounts
for
permissions,
so
you'll
need
some
permissions
in
for
flux
to
operate,
because
it's
going
to
be
talking
to
the
cluster
ape
to
the
cluster
itself
modifying
the
cluster
as
a
pod.
So
you
need
some
permissions,
a
specific
account.
So
that's
in
the
flux
account
flux.
Deployment
is
just
the
deployment
of
pods.
The
secret
is
just
defining
the
internal
secrets
that
you're
going
to
be
using
for
flux,
so
you'll
define
a
cuban
NT
secret,
and
then
we've
got
a
memcache
service.
A
A
A
So
what
what
happens
next
now,
we've
got
this
agent
running
in
a
cluster.
We
need
to
do
a
few
things,
so
we
now
should
have
a
repository
control
repository
and
an
agent
running
in
the
cluster.
So
the
next
step
should
be
to
make
sure
that
the
agent
has
access
to
the
repository,
so
it
can
read
and
write
to
it
and
we're
going
to
do
that
by
getting
the
agent
keys
and
then
putting
it,
adding
it
to
our
repository
to
make
sure
we
have
access
and
pointing
then
reconfiguring
the
agent
to
point
to
the
right
repository.
A
A
Yeah
sure
so,
right
now,
after
this,
this
step
is
complete.
So
we
should
have
a
github
repository
set
up
or
bitbucket
repository,
and
then
we
should
have
an
agent
running
on
the
cluster,
this
one
so
the
flux
agent.
However,
the
operator
the
flux
operator
on
the
cluster
doesn't
know
about
the
repository
yet
and
it
doesn't
have
access
to
the
repository
yet
so
what
we're
going
to
do
is
we're
going
to
give
the
flux
operator
access
to
the
repository
by
sharing
its
keys
and
we're
going
to
configure
it
today,
it's
already
reading
the
repository
as
well.
A
A
A
A
So
the
question
was:
does
this
kind
of
work
for
work
for
development
as
well
as
production?
Is
that
so
yeah
I
mean
it
works
great
for
development
as
well,
because
you're
we
mean
our
own
development
cluster
is
run
through
this.
This
is
the
approach
we
take.
What
happens
is
we
continuously
deploy
mostly
for
our
staging
cluster
divet
or
development?
Staging
cluster
we've
worked
with
people.
Who've
used
this
kind
of
approach
with
some
additional
automation
so
that
they
can
create.
Let's
say
everytime,
you
have
a
pull
request.
A
A
All
right,
so,
if
you're
talking
about
like
the
local
development,
then
no
so
like
the
internal
loop,
when
you're
as
a
developer,
you're
developing
an
application,
you're,
probably
gonna,
be
running
Dessel
on
mini
cube
in
your
in
your
own,
on
your
own
machine.
What
happens
there
were
why
this
is
helpful.
There
is
that
you,
it's
really
easy
to
spin
up
a
complete
set
of
kind
of
equivalent
production
set
to
a
complete
cluster,
that's
equivalent
to
your
production
systems
really
easily.
A
That's
the
benefit
that
you
get
because
of
this,
but
you
don't
you
wouldn't
use
it
to
drive
your
local
instance.
If
you
can
kind
of
just
poke
it
yourself,
so
it's
much
much
more
useful
when
you've
got
like
a
shared.
You
know
this
is
like
the
point
is
here:
we're
controlling
shared
stake
right
if
you're
dealing
with
a
state,
that's
owned
by
a
single
person,
gonna
essentially.
A
No,
no,
so
we
have
a
different,
continuous
integration
build
pipeline.
What
we
don't
also
Jenkins,
will
do
both
right
it'll
do
the
building
and
the
deployment.
Basically,
we
we
use
some
tool
to
do
our
build,
and
then
we
use
this
for
our
deployment
yeah.
So
you
could
use
Jenkins
and
this
you
just
restrict
the
responsibilities
for
Jenkins
to
just
building.
A
So
the
the
reason
we
have
a
repository
is
because
we
don't
just
want
to
push
every
new
image,
so
you
need
two
things
where
you
need
a
way
of
telling
it
what
should
be
deployed
kind
of
declaring
these
are
the
things
that
should
be
on
my
cluster,
beyond
kind
of
just
the
images
in
the
repository.
So
it's
easier
to
control
things
from
a
control
repository
that
has
all
the
definitions
than
it
is
to
just
point
the
agent
at
a
whole
bunch
of
different
registries.
A
I
guess
I,
probably
wouldn't
use
the
word
step,
but
kind
of
so
we
have
the
kind
of
the
first
thing
that
happens
is
you
have
our
continuous
integration
pipeline
builds
the
image
tags,
it
puts
it
in
the
registry
and
then
the
operator,
the
operator
picks
up
kind
of
notices
that
there's
a
change
in
the
registry
or
new
image.
It
will
look
at
whether
or
not
it
has
that
particular
services
automated.
A
So
we
have
our
pods
running
on
the
cluster,
which
is
great,
so
the
next
step
is
to
get
the
key,
the
secret
identity,
the
public
key
for
our
pods.
To
do
that
well,
download
a
little
utility
tool.
You
can
do
it
other
ways
you
can
in
fact
configure
the
identity
using
the
tool
is
just
easy
for
this
tutorial
in
a
production
setup.
You
probably
want
to
manage
the
keys
more
deliberately.
A
A
A
A
You
can
basically
choose
how
you
handle
that,
so
in
some
cases
will
automate
the
revert.
So
if
something
goes
wrong,
we'll
just
automate
the
kind
of
going
back
to
the
appropriate
State.
Otherwise,
sometimes
it's
difficult
to
take
on
automated
Oh
kind
of
automated
action,
in
which
case
we'll
create
an
alert
for
our
ops
team.
A
A
A
So?
Yes,
so
the
kind
of
how
do
we
like?
How
do
we
manage
kind
of
versions
is
what
you're
asking
really
so
yeah?
Absolutely
we
use
tag,
so
we
use
semantic
versioning
and
what
we
tend
to
do
is
we
have
a
great
way
of
doing
it?
Is
you
have
not
math,
so
you
have
every
new
commit
on
the
particular
service
tagged
with
the
branch
and
the
short
shell
of
the
kind
of
the
commit
for
the
image
that's
being
built
out
of
it.
A
So
every
kind
of
commit
corresponds
to
an
image
and
then,
when
you
want
to
make
a
release
to
production,
instead
of
just
staging
you'll,
add
a
tag
in
git,
which
is
a
version
semantic
version,
so
you'll
do
V,
0,
1,
1
and
then
1.
That
tag
hits
the
repository
on
the
registry.
You
can
automate
so
that
only
those
tags
get
pushed
to
a
particular
environment.
That's
how
kind
of
we
that's
how
we
break
it
down
into
our
flow
of
commits.
A
A
A
A
A
And
we
should
see
reconfigured
right,
we've
reconfigured
our
cluster,
so
the
next
step
now
is
to
grab
that
once
now
the
operator
is
now
looking
at
the
repository.
We
can
start
adding
something
to
the
repository
and
the
operator
should
pick
it
up
and
act
on
it.
So
we
have
here
in
the
examples
folder
we
have
a
deployment
manifest.
A
A
A
A
So,
no
typically,
what
you
have
is
you'll
have
a
single
one
running
over
on
a
cluster
and
then
what
you
can
do
is
deploy
to
multiple
namespace,
based
on
the
same
repository.
If
you
want
to
display
it
up
into
the
second
a
separate
repository,
you
could
have
multiple
ones
kind
of
it's
kind
of
up
to
you,
but
it's
not
a
typical.
It's
not
a
typical
deployment.
A
So
how
would
the
config
meets
change
by
differ
for
different
namespaces
I
mean
the
the
config
actually
so,
although
community
manifest
is
going
to
have
the
namespace
in
there,
essentially
so
if
they
have
a
namespace
specified
in
the
manifest
when
they
get
deployed
by
flux,
they'll
be
deployed
in
the
right
namespace.
So
if
you
wanted
to
kind
of
segregate
things,
what
you'd
have
is
you'd
have
a
repository
for
a
particular
namespace,
and
then
you
have
one
flux
agent.
Normally
looking
at
that
repository,
for
example,.
A
So
it's
so
the
question
was
it:
are
there?
Is
there
any
support
for
detecting
differences
and
removing
things
that
have
been
deleted?
The
first
one
is
I,
mean
it'll.
Do
the
kind
of
it
will
continuously
check
that
the
two
that
the
running
cluster
and
the
repository
are
matching
in
term
of
the
manifests?
So
that's
number
one
number
two.
A
Therefore,
this
first
problem
as
well
there's
a
bunch
of
tools
that
we
wrote
called
say:
cubed
if
tarot
deck
and
ansible
diff
that
will
come
that
will
proactively
check
differences
in
kind
of
desired
state
versus
actual
state.
So
you
can
find
those
those
are
just
open
source
tools
and
as
far
as
deleting
things
when
we
remove
the
files
we
couldn't
do
that
so
I
personally
would
quite
like
to
configure
a
cluster
like
this,
but
it's
not
possible
because
what
would
happen
is
you'd,
add
flux
to
an
existing
cluster
and
it
would
immediately
delete
everything.
A
A
A
A
So
it's
a
good
question,
so
the
question
was:
after
setting
this
up:
have
you
ever
experienced
something
that
went
wrong?
What
went
wrong
and
how
did
you
kind
of
fix
it?
The
answer
is:
it's
been
the
other
way
around.
We
found
that
this
has
helped
us
fix
things
that
I've
gone
round
elsewhere,
so
we've
never
had
a
problem
with
our
flux
deployment
in
production,
so
we
use
this
in
production
every
day
and
we've
never
had
any
issues
with
that.
A
What
it
has
helped
us
do
is
when
we
had
one
of
our
engineers
accidentally
delete
that
our
entire
AWS
essentially
account.
So
we
lost
everything
like
and
sure
immediately
we
lost
all
our
services,
everything
because
we
had
everything
stored
in
a
git
repository
with
the
daemons.
It
took
us
about
40
minutes
to
half
an
hour
to
bring
it
back,
so
we
went
from
kind
of
nothing
to
everything
running
again
in
about
half
an
hour,
so
it's
the
other
way
around.
A
A
So
the
secrets,
so
the
question
was:
are
the
secrets
also
inside
get
yes,
so
we
use
SIL
secrets,
which
is
a
way
of
encrypting
secrets
in
get
making
them
available
as
kind
of
encrypted
blobs
on
the
cluster
and
then
having
an
operator
on
the
cluster
that
decrypt
them
for
the
particular
workloads.
So
if
you
just
Google
search
bit,
Namie
sealed
secrets,
you'll
find
the
operator
that
does
that
by
the
bit
Namie
crowd,
which
they're
sponsoring
the
Wi-Fi.
Thank
for
this
event.
A
So
the
question
was:
can
you
use
volt
and
said
yeah?
Of
course,
right
absolutely,
there's.
No
reason
I
mean
this.
Doesn't
this
is
not
a
restrictive
approach,
the
secret
management?
If
you
have
another
approach
to
managing
secrets
that
works
too,
absolutely
this
will
take
a
while
and
the
reason
it's
taking
awhile
is
the
polling.
Frequency
is
set
at
five
minutes
by
default,
and
the
reason
for
that
is
we
don't
want
to
blow
up
your
API
limits.
A
A
A
A
A
A
So
yeah
so
I
think
the
in
Google
cloud
you'll
need
to
the
create
a
Google
cloud
service
account
that
will
then
give
permission
to
the
communities
account.
There's
an
account.
I
tried
it
at
the
very
start
as
well.
There's
an
account
issue
where
Google
cloud
doesn't
let
you
give
sufficient
permissions
to
flux
without
going
through
the
Google
Cloud
console.
If
you
have
a
look
at
the,
if
you
have
a
look
at
the
flux,
ap,
the
frost,
documentation
on
get
github.com,
slash,
flux,
get
a
slash.
A
Weevil,
we've
worked,
slash,
flux,
you'll,
find
some
information
about
how
to
configure
gke
and
GCB
right.
So
to
us,
the
operation
about
to
know
us
is
what's
actually
what
the
daemon
is
doing.
Grab
the
logs
the
logs
are
there,
you
can
see
things
like
events
and
you
can
see
it
applying
new
configuration
so
right
now,
for
example,
this
was
the
event
where
the
flux
operator
actually
created
the
pollen
for
deployment,
for
example,.
A
A
Yes,
that's
right!
So
if
you
put
a
the
question
was:
if
you
put
about
a
sh
key,
if
you
gave
a
badass
a
key,
would
it
show
up
in
the
logs
as
failing
to
authenticate
to
github?
The
answer
is
yes,
that's
exactly
what
you'd
see
if
you
had
an
issue,
that's
that
those
are
the
logs.
You
might
want
to
have
a
look
at
okay.
So
now
we've
we've
actually
I
mean
in
our
cluster.
We
should
be
able
to
see.
A
When
my
keystrokes
actually
get
there,
so
we
should
see
the
pod
into
a
pod
running
on
the
cluster.
So
we've
now
the
how
we
deployed
it
was
actually
just
changing
the
github
repository.
We
didn't
actually
do
anything
to
a
cluster.
We
didn't
use,
cube
cuttle
and
that
yet
yet
here
it
is
a
pod
on
our
cluster
running
as
we've
configured
it.
A
So,
while
that's
reloading,
you
can
have
a
look
at
the
next
step.
Once
you've
added
the
Yammer
file
and
you've
seen
the
pod
running,
you
should
be
able
to
manually
delete
the
deployment
yourself
on
your
cluster.
So
that's
the
deployment,
not
just
the
pod.
You
know
if
you
delete
the
pod
and
you
leave
the
deployment
cuba
Nettie's
will
bring
the
pod
back
up.
But
if
you
delete
the
deployment
cuba
Nettie's
assumes
you
that's
what
you
want
so
now.
A
This
takes
kind
of
a
few
minutes
for
that
for
flux,
to
notice
and
then
take
the
right
action,
but
it
will
notice
that
the
deployment
isn't
there
and
it
will
reapply
the
manifests
to
the
cluster
and
enforce
the
state
you
gave
it
and
you
can
look
at
the
logs
the
flux,
flux
logs
to
see
exactly
what's
happening.
It'll
pick
up
that
there's
no
deployment,
it'll
kind
of
continuously
pull
the
images,
it'll
reapply
the
and
then
it
will
reapply
the
manifests
that
you've,
given
it.
A
Are
they
all
timing
out?
Okay,
we've
probably
blown
the
API
limit
for
Kathy
Kota,
so
I'll
have
to
apologize
to
Ben
and
buy
him
a
bottle.
So
the
idea
here,
the
next
kind
of
logical
step,
is
to
modify
the
configuration
and
see
that
coming
up
on
your
cluster,
so
you'll
be
able
to
modify
your
configuration
and
say
scale
it
up,
create
a
commit
and
then
you'll
see
that
be
reflected
in
your
cluster
very
quickly.
A
Yes,
absolutely
so
the
question
is:
can
you
reduce
that
cycle
time
of
five
minutes?
I
hope
that
meant
absolutely
yeah
there
is.
The
answer
is
webhooks.
You
can
get
your
your
repository
and
also
your
image
registry
to
send
webhooks
to
flux
essentially
and
then
flux
will
be
able
to
once
it
gets
the
way
work
do
or
not
to
do
an
update
immediately.
So
you
don't
have
to
wait
for
the
polling,
it
can
happen
automatically.
A
A
And
so
kind
of
the
next
next
thing
I
wanted
to
show
you
technical
issues
notwithstanding
is
actually
setting
up
to
be
automated
or
kind
of
set
up
continuously
Pro
min
so
that
any
time
there's
a
new
image.
It
gets
immediately
pushed
into
your
cluster,
and,
what's
quite
nice
here-
is
that
there's
no
magic?
What
we're
actually
doing
to
tell
flux
we
want
to
automatically
deploy
a
particular
deployment,
is
to
add
some
annotations,
and
so
we'll
add
these
two
annotations
to
our
deployment.
This
is
our
pod
info
deployment
and
will
had
flux
dot.
A
We
use
that
works
tad
net
blow
tester.
This
is
the
name
of
the
deployment
and
will
had
glob
equals
anything.
So
any
new
versions
will
come
up
and
be
deployed,
and
this
is
the
line
that
the
annotation
that
makes
a
work-
that's
dotnet
load
test
should
not
say
that
it
should
just
say
pod
intro,
my
bad.
A
So
pot
info
is
hosted
on
the
cake
he
died.
Oh,
it's
a
publicly
available
service
yeah.
That's
right
and
you'll
see
that
when
you
do
that,
the
image
that
you
that's
there
on
the
example
is
1.0.0
and
once
it's
automated
flexible,
immediately
updated
to
one
point:
four
point:
wine,
which
is
the
latest
image
available
in
the
repository,
and
this
is
a
way
of
kind
of
grabbing.
A
A
So
once
you've
managed
to
kind
of
get
your
deployment
going
so
that
you
automatically
deployed
you.
What
you'll
see
is
that
the
flux
agent
is
going
to
start
making
commits
to
your
repository
it's
going
to
actually
make
a
commit
when
there's
a
new
version
to
change
the
version
number
in
your
deployment,
so
you'll
be
creating
the
commit
that
adds
the
annotations.
That
says.
Please
automate
this
file
and
then
the
flux
agent,
one
there's
a
new
version
will
actually
create
the
create
the
new
commit
to
change
the
version,
just
like
you
would
as
a
human.
A
A
A
So
these
are
image.
Names
is
a
so
these
master
blah
is
an
image
name
in
the
key
K
dot,
IO
repository
image
registry-
and
we
tagged
our
images
with
the
branch
name
and
the
commit
shell
for
the
source
code,
just
to
be
sure
that
we
can
trace
back
all
the
way
to
the
actual
commit
the
source
commit
for
the
application.
A
So
the
question
is:
what
happens
if
an
image
requires
external
resources,
so
all
that
stuff
should
be
encoded
in
your
deployment
manifest
any
dependencies.
Any
services
you're
gonna
need.
It
should
be
deployed
in
your
dependent
in
your
deployment,
manifest
essentially
really
or-
and
your
image
should
also
accept
that
it
might
enter
a
cluster
where
it's
dependencies
aren't
available.
If
you've
got
a
third
like
another
service
there.
That
makes
sense.
A
So
yes,
so
look
I,
think
the
question
is
kind
of
what
happens
if
you,
if
you
need
another
service
on
your
cluster
for
version
2
to
work,
is
that
right,
okay,
I
mean
in
that
case
you'd
have
to
obviously
deploy
your
dependencies
with
or
before
your
new
version
and
so
flux
will
literally
just
synchronize.
Whatever
is
in
your
gate,
repository
to
your
cluster,
it
won't
understand
that
there's
a
link
of
dependency
between
your
images.
A
A
So
right
now
so
you're
asking
whether
we
had
there
is
some
health
check
system
to
ensure
that
a
deployment
works
and
if
it
doesn't
kind
of
revert
back,
the
answer
is
right:
now
we
rely
on
Cuba,
Nettie's
and
communities
has
those
checks
in
so
it
has
readiness
track,
it
has
liveness
checks,
etc,
and
you
can.
The
Cuban
actors
will
use
dos
for
the
plot
for
deployments.
A
A
The
answer
is
yes,
but
you'll
need
another
bit
of
software
running
on
your
cluster
you'll
need
a
kind
of
a
second
operator
to
run
on
your
cluster,
to
be
able
to
understand
helm
resources
as
well
as
the
helm,
helm
operators
can
you
use
flux
to
manage
itself,
and
the
answer
is
not
really
fundamentally
there's
going
to
be
a
layer
somewhere
in
your
system
that
used
manage
the
outside
of
get
ups.
Usually
that's
just
your
flux
deployment.
A
If
you,
if
you're
doing
that
through
our
cloud,
will
like
our
wave
cloud
solution,
what
we'll
do
is
we'll
install
an
agent
that
kind
of
deals
with
with
updating
everything
automatically
at
that
layer.
We've
talked
about
automate
or
kind
of
automated
deletions
of
services
and
deployments,
and
there
is
the
answer.
Is
we
don't
do
that?
Just
yet-
and
the
reason
is
we
would
be,
it
would
be
dangerous
to
apply
flux
to
an
existing
cluster.
And,
finally,
what
happens
if
you
have
custom
resource
definitions
and
the
answer
is
pretty
much.
A
What
you'd
expect
custom
resource
definitions
are
just
cuba
nets,
these
resources
and
flux
deals
with
cuba
nets,
these
resources,
it's
kind
of
agnostic,
about
what
you're
putting
to
the
cluster.
So
it
won't
kind
of
worry
too
much
if
you
have
a
custom
resource
definition
there
and
that's
actually
how
the
flux
in
helm
integration
is
done.
We
define
a
custom
resource
definition,
that's
managed
through
flux,
and
we
have
an
operator
on
the
cluster
that
then
deploys
that
as
a
film
shop.
A
So
the
question
is:
is
there
any
incompatibilities
with
flux
and
other
things
like
k,
native
SEO,
etc?
No,
absolutely
not,
and
in
fact
this
is
often
quite
a
nice
way
of
deploying
those,
because
you
can
just
copy
the
template
that
the
project
will
give
you
for
deploying
communities
paste
it
into
your
repository
and
then
just
watch
flux
to
install
it.
So,
in
a
lot
of
cases,
that's
quite
a
nice
path.
A
A
Yeah,
so
the
question
is,
then:
the
access
control
problem
is
shifted
to
get
up
and
you'll
get
repository,
and
the
answer
is
absolutely
that's.
That's
exactly
what
we're
doing,
and
this
is
in
fact,
a
good
place
to
have
an
access
control
problems
because
of
the
tools
you
have
around
access
control
and
get
right.
You
can
do
things
like
protected
branches,
software
validation,
signing
commits,
etc
and
get
yeah
pull
request
kind
of
things.
A
A
So
is
it
more
than
one
repository
at
the
time?
Yes,
it's
only
one
repository
at
the
time
flux
currently
has
a
limitation.
It
only
looks
at
one
repository.
We
haven't
found
that
to
be
a
practical
problem.
In
practice,
we
haven't
found
that
to
be
problematic,
it's
sufficiently
powerful
that
you
can.
You
can
manage
a
cluster
with
only
one
repository,
and
that
tends
to
match
quite
well
to
have
like
one
plus
two
one
repository,
because
what
you
really
want
is
all
the
state
of
your
cluster
to
be
in
a
single
place.
A
A
So
I
mean
it
fails
to
apply
all
the
time
for
a
random
reason
right.
You
know
you
there's
the
cosmic-ray
factor.
Something
can
go
wrong,
but
because
you'll
continuously
be
retrying
to
apply,
then
it
will
continuously
try
and
if
it's
kind
of
after
a
certain
number
of
retries,
if
it
fails,
still
fails
to
put
the
diploma
together,
it'll
alert
you
and
say
hey.
We
can't
we're
now
unable
to
deploy.
Please
take
a
look,
because,
as
a
software
I,
don't
know
what
to
do.
I'm
a
piece
of
software
I'm
not
intelligent
enough
to
solve
that
problem.
A
Yeah
absolutely
so
the
question
is:
can
you
deploy
offline
on
premise,
etc?
In
air-gap
yeah
I
mean
we,
we've
got
customers
who
have
air
gap
systems
who
need
somebody
to
literally
drive
up
with
you
know
a
USB
stick:
well,
not
a
USB
stick
but
a
validated
release,
and
then
they
have
to
copy
and
paste
it
and
have
you
validated
so
yeah
and
that's
how
you
deploy
software
in
their
environment.
They
just
have
an
internal
registry
and
internal
gate
repository.
A
So
you
can
choose,
you
can
choose
either
way.
We
find
it's
quite
easy
for
us
to
just
have
separate
directory.
In
the
same
repository
you
can
use
separate
branches.
You
can
choose
separate
directories,
you
can
use
separate
repositories
for
us.
We
found
it
easier
to
just
use
separate
directories
that
works
well
for
us.
Multiple
directories
for
each
environment,
yeah.
A
Right
so
if
flux
just
deploys
who's
responsible
for
testing
the
code
installing
dependencies
building
images,
the
answer
is
your
continuous
integration
pipeline
right
that
you
still
have
that
you
still
need
to
build
your
software
flux
and
get-ups
is
about
the
deployment
side.
How
you
build
the
artifacts
you're
going
to
deploy?
It's,
not
something.
That's
in
scope,
right,
there's
something
that
other
tool
do
really
well,
you
can
use
Jenkins.
You
can
use
circle
CI.
You
can
use
github
actions
whatever
it
is
you
could.
A
So,
if
you're,
using
Jenkins
for
everything,
the
biggest
sales
point
is
I
can
half
the
amount
of
code.
You
have
right
now,
that's
dealing
with
continuous
integration
right,
the
the
amount
of
code
you
have
right
now,
that's
dealing
with
continuous
integration
includes
building
but
also
includes
release.
I
can
half
the
release
code
if
you're
releasing
communities.
That
means
half
the
amount
of
deployment
time,
half
the
amount
of
deployment
bugs,
etc,
etc.
That's
the
that's
the
value,
add,
and
that's
so
that's
a
real
kind
of
win.
A
A
So
the
question
is
kind
of
how
does
how
do
we
compare
to
things
like
spinnaker
and
the
new
deployment
pipelines
that
are
coming
up?
I
think
that
the
key
is
kind
of
one
of
the
things
I
mentioned
very
early
is
the
the
fact
that
you
have
the
state
of
your
entire
system
in
get
that
the
fact
that
you
have
social
collaboration
on
that
state?
This
is
not
something
that
spinnaker
does
very
well.
This
is
not
something
that
the
other
tools
handle
particularly
well.
A
There
are
other
get-ups
tool
that
we
don't
build,
so
I
think
I'll
go
is
kind
of
a
new
kid
on
the
block.
That
certainly
does
pipelines,
and
they
say
that
you
get
ups
have
not
kind
of
had
the
time
to
dig
into
all
of
the
details.
But
spinnaker
has
some
problem
around
state
management,
especially
in
the
failure
case.
A
A
Haven't
done
it
for
spinnaker,
get-ups
audits,
remember,
I,
I!
Think
right
now
it
fails
on
a
couple
of
points
of
what
we're
trying
to
achieve
with
get
ops
to
be
kind
of.
It's
just
continue
story
or
a
spinnaker
is
accounting
is
in
continuous
development,
so
that
answer
might
get
stale
in
people
time.
No,
we
don't
we're
not
involve
with
vinegar
okay.
So
we
we
have
about
about
five
minutes
left
I.
Think
before
we
have
to
close
up,
can
I
think
that's
about
right.
So
I'll
take
a
couple
more
question.
A
A
A
A
A
A
So
my
colleagues
might
be
poking
the
cluster
the
same
time
as
me,
they're
doing
demos
on
the
show
floor.
So
if
you
get
some
events,
that's
that's
probably
there.
So
this
is
the
view
of
our
cluster
right
now
and
we
can
see
that
they.
This
is
the
current
running
image
on
the
right-hand
pane
for
all
the
workloads
on
my
cluster,
and
this
is
the
latest
available
image
in
my
image
registry.
A
A
It'll
come
up
with
a
bunch
of
tags
and
what
I
can
do
is
release
a
version,
and
so
the
tool
has
some
kind
of
quality
of
life
features
that
run
on
top
of
flux.
One
of
those
is,
for
example,
showing
you
the
resource,
graphs
and
custom
graphs
when
you're
doing
a
deployment,
so
you
can
see
the
effect
of
your
deployment
on
your
system.
A
A
A
Can
we
find
a
suitable
one
and
then
now,
instead
of
promoting
from
the
from
the
latest
available
image?
If
I
select
a
couple
of
these,
so
let's
be
select
the
front
end.
Maybe
I
can
promote
dose
and
I
can
select
more
than
one
create
a
release,
and
it
should
show
us
the
contact,
the
pods
kind
of
being
updated
to
the
latest
version.
A
So
it's
created
the
commit
on
the
right
on
the
repository
just
like
we
expect,
and
now
it's
doing
the
deployment,
and
we
can
see
four
pods
being
deployed
from
one
version
to
the
next.
So
that
gives
you
an
idea
of
now
we've
kind
of
seen
how
it's
works,
underneath
the
kind
of
raw
commits
how
to
drive
flux.
This
gives
you
an
idea
of
kind
of
the
experience
you
can
build
for
your
teams.
If
you
want.
A
Okay,
I
think:
that's,
that's
it
for
today
I'm
very
happy
to
have
a
chat
with
you
guys
outside.
If
you
want
to
continue
otherwise
get
in
touch
with
us,
this
QR
code
will
take
you
to
a
URL
that
gives
you
a
45
day
trial
of
weave
cloud.
If
you
want
to
try
this
stuff,
it'll
be
I,
think
we're
gonna,
make
it
available.
I
mean
Sonia
is
in
the
room
somewhere,
but
we're
gonna
make
it
available
for
you
guys
and
probably
stop-stop
it
tomorrow.
A
So
if
you
want
to
make
it
take
advantage
of
that,
then
that's
today,
our
default
trials
cover
two
weeks
instead
of
45
days
and
do
get
in
touch
right.
Do
get
in
touch
with
questions,
suggestions,
ideas,
how
you
found
it
kind
of
war
stories.
We
always
like
to
hear
about
people
who've
used
this,
so
please
do
get
in
touch
and
I
think
we
have
three
people
who
use
our
own
books.
I!
Think
you
are
one
sir
and
I
think
the
gentleman
here.
The
front
row
is
as
well
and
I
think
you're
the
third
person.