►
Description
The fifth installment of our SIG group that’s dedicated to reviewing the challenges that come with building, deploying, maintaining, supporting, and using open source CMSs on Kubernetes — features two short presentations:
Nick Santamaria talks about horizontally scaling app pods using custom metrics
Kevin Bridges reviews the Kubernetes SIG governance model and how it could help others
Catch up with the group on GitHub: http://bit.ly/338dXC5
A
A
As
a
result
of
these
conversations,
there's
a
lot
of
different
companies
across
the
world
that
are
using
kubernetes,
it's
a
very
popular
project
and
provides
a
lot
of
functionality
and
utility
for
systems
like
Drupal,
so
very
interested
to
see
how
this
ends
up
evolving
and
what
comes
out
of
it
to
go
ahead
and
kick
it
off.
We
tend
to
do
quick
introductions,
so
this
should
be
relatively
painless
since
there's
a
few
of
us
in
here,
if
the
first
Nick
Nick
Santa
Maria
is
it?
Is
that
how
you
pronounce
your.
C
Yeah
I'm
Brad,
Jones
I'm
in
Denver
I
do
a
bunch
of
Drupal
development
and
increasingly
mostly
actually
DevOps
stuff
I'm
a
freelancer
but
I
also
am
the
product
owner
and
at
agency
here
in
town,
that's
building
an
ounce
hosting
platform
at
fruition.
So
not
maybe
doing
the
things
at
the
same
scale
as
some
of
the
rest
of
you,
but
all
the
same
problems.
E
C
A
B
B
B
Alright,
so
just
quickly
a
bit
of
a
recap
on
how
the
horizontal
auto
scalars
work,
so
you
know
we're
all,
probably
using
kubernetes
deployments
or
replication
controllers
to
deploy
our
applications
out.
So
these
objects
have
a
replicas
parameter,
which
is
basically
the
number
of
pods
that
you
want
running
at
any
given
time.
We
then
have
a
horizontal
pod
autoscaler,
which
you
can
figure
with
various
thresholds,
metrics
that
you
want
to
when
those
thresholds
are
exceeded.
You
want
to
trigger
a
scaling
event,
so
yeah
that
you
know
that
might
typically
be
CPU
or.
B
B
B
Another
cool
improvement
from
another
cool
improvement
on
version
2
of
HPA
is.
We
now
have
a
first
class
integration
with
metrics
exposed
by
other
kubernetes
components.
So
in
this
example,
you
can
see
an
example
of
how
like
scaling
your
application,
based
on
the
number
of
requests
per
second
at
the
ingress
level,
which
is
pretty
cool,
and
you
can
do
this
without
any
sort
of
custom
code
or
or
workflows
so
yeah.
What
about
custom
metrics
well
in
this
context,
custom
is
first
anything
that's
not
provided
by
kubernetes
itself,
so
we're
all
running
PHP.
B
Many
of
us,
probably
PHP
fpm,
and
you
know,
there's
potentially
like
treasure
trove
of
metrics
in
there
that
you
might
want
to
scale,
and
you
know
available
workers.
You
know
maybe
proc
memory
consumed
and
things
like
that.
So
I
give
you
the
PHP,
fpm
Prometheus
explored
a
project,
so
this
is
just
on
github.
It's
like
pretty
pretty
solid
and
you
can
see
there.
This
is
all
of
the
metrics
that
it
gives
you
by
default.
So
there's
tons
of
possibilities
here
for
scaling.
B
Now
the
next
step
is
well.
How
do
we
get
these
metrics
that
are
exposed
by
your
PHP
SPM
pod
into
your
liking,
to
a
point
where
your
horizontal,
odd
order?
Scalar
can
use
them?
Well
then,
this
is
when
you
need
a
Prometheus
adapter,
so
this
is
a
bit
of
a
high-level
chart
of
how
the
whole
thing
looks
and,
and
so
we
basically
have
a
slash,
metrics
endpoint
on
our
on
our
PHP
FTM
pods,
which
Prometheus
is
scraping
and
crew.
Benitez.
B
Has
this
metrics
aggregator
component,
which
you
know
you
can
configure
to
look
at
a
bunch
of
different
places
to
call
metrics
and
use
so
your
HPA
is
but
we'll
have
a
Prometheus
adapter
which
sits
in
between
your
Prometheus
instance
and
the
metrics
aggregator.
It's
just
a
translation
layer.
Essentially
now
there's
two
projects
I
found
that
allow
you
to
do
this
and
you
know,
without
writing.
Any
code
yourself
so
the
first
one
is
probably
the
more
supported
one
based
on.
B
B
So
you
know
quickly
go
show
you
the
config
for
that
first
project,
and
so
this
is,
if
your
this
is
the
configuration
file
for
the
Prometheus
adapter,
and
it
basically
is
telling
you
like.
So
this
is
this
query
here
is
called
my
client
connected
and
it
has
a
Prometheus
query
and
you
so
basically,
every
time
the
metric
server
tries
to
scrape
data
from
your
adapter.
It
runs
that
query
and
exposes
it
as
a
metric
called
my
app
client
connected
and
then
on
your
horizontal
port
autoscaler.
B
B
Now,
if
that
doesn't
it's
like
trying
to
you
know
if
you're
not
running
Prometheus
currently
or
all
of
that
stuff
sounds
like
bird
and
that
you're
not
particularly
wanting
to
run
with,
then
you
can
roll
your
own
custom.
Metrics
API
server
build
your
own
intermediary.
If
you
want
so
this
project
from
kubernetes
incubator
is
essentially
the
coop
builder
of
custom.
Metrics
servers
and
we've
had
a
bit
of
a
play
around
with
that
too.
B
C
So
at
what
weight
do
you
find
that
the
usual
performance-enhancing
methods
that
are
less
complex,
right,
CBN's,
good,
caching
layer?
You
know
reverse
proxy
caching
layers,
all
that
kind
of
thing.
At
what
point
does
this
become
a
thing
for
your
clients
and
then?
Secondly,
you
know
how
you,
how
does
this
sort
gets
sold
right?
This
is
all
very
value-added
stuff,
because
you're
probably
know
these
applications
need
to
be
scalable.
C
B
Yes,
that's
to
the
question
on
you
know
what
point
do
you
start
considering
these,
you
know
yeah
value-added
things
like
auto
scaling
and
custom,
auto
scaling
it.
It
really
depends
I
mean
yet
like
we.
We
had
a
bugging
out
what
I
scale
up,
but
we
didn't
notice
for
maybe
a
month
or
something
and
nothing
caught
on
fire.
B
C
C
But
I
don't
know
if
anybody
has
particular
thoughts
on
it,
which
is
like
the
the
metrics
that
come
out
of
like
Prometheus
or
like
I
guess
they
go
into
Prometheus
from
monitoring,
especially
on
gke,
like
about
memory
or
rather
opaque,
like
the
the
concept
of
like
a
victim
memory,
and
things
like
that,
it
doesn't
seem
like
a
lot
of
that
gets
sort
of
surfaced
very
well.
So
it
seems
to
me,
as
looking
looking
at
these
issues,
there's
a
little
bit
of
a
garbage
in
garbage
out
component.
B
Yeah,
there's
definitely
like
a
like.
The
information
community's
aggregates
in
the
Prometheus
by
default
can
be
pretty
overwhelming
and
yeah
I
want
to
see
a
lot
of
that
I.
Don't
I
haven't
dug
into
to
understand
what
it
is.
That's,
oh
yes,
oh
man,
but
I
guess
thinks
that
focus
of
this
talk
was
more
about
life.
Yeah
more
talking
about
what
the
applications
themselves
are,
exposing.
B
A
And
then
that
PHP
fbm
exported
actually
adds
a
lot
of
really
useful
information
that
PHP
developers
can
relate
to
really
quickly.
Can
you
maybe
talk
a
little
bit
more?
You
mentioned
the
concept
of
standing
up
of
an
intermediate
API.
If
you're
not
going
with
a
full-blown
prometheus
solution
that
might
go
over
quite
a
few
people's
heads,
can
you
maybe
talk
about
why
one
would
want
to
do
that
and
what
it
would
accomplish.
B
Don't
know
if
it's
necessarily
something
we'll
run
long
term,
but
it
certainly
was
an
interesting
experiment
just
to
see
how
that
had
met.
Metrics
adaptive
framework
tool,
works,
yeah,
but
I
think
that
it's
probably
for
your
vast
majority
of
these
cases
that
using
the
Prometheus
exporter
is
going
to
be
a
better
better
option.
We.
B
E
E
Like
gray
area
around,
like
practices
to
scale
to
report,
I
think
that's
a
really
meaty
topic,
but
like
these
kinds
of
Kohli's
to
so
they
how
people
are
doing
it
because
they
I
think
he
can
get
that
like
80%
or
90%,
just
by
turning
on
CPU
or
no
scaling.
But
then
yeah
there
is
all
this
stuff
around,
like
HTTP
requests
and
memory
and
there
which
which
do
do
you
help
you
but
which
do
you
save
your
ass,
sometimes
but
yeah.
It's
interesting.
B
Looking
to
do
is
actually
expose
and
the
average
amount
of
memory
the
application
is
actually
using.
So
you
know
you
might
go
and
profile
an
application
before
launches,
and
then
you
know,
just
after
a
year
of
entropy
that,
like
you
know
your
modules
get
added
or
you
know
you're
dealing
with
like
we
educate
content,
that's
getting
uploaded,
and
now
you
no
longer
know
your
developers
no
longer
know
how
much
memory
it
actually
needs,
and
so
often
the
developers
reactions
I'll.
Just
you
know
kick
memory
limits
to
geek
or
something
crazy
like
that.
A
A
C
C
So
there's
like
a
library
to
explore
matrix
in
that
format,
a
library
and
been
yeah,
we've
just
kind
of
been
thinking
about
what
we
could
add
to
it
and
what
could
be
expose
to
like
a
new
platform
that
we're
building
but
ya,
feel
great,
a
jump
in
and
have
a
look
at
it
and
go.
Try
some
issues
or
whatever
cool,
got
a
plug-in
architecture.
So
you
can
easily
extend
it
with
new
different
matrix.
A
Well,
that's
a
fairly
decent
segue
into
the
next
lightning
talk.
This
one
is
going
to
be
fairly
quick
and
just
generally
covered.
The
kind
of
community
makeup
of
kubernetes
out
kubernetes
functions
a
little
bit
on
the
governments
model
and
kind
of
you
know
what
the
sig
concept
is
and
how
that
actually
fits
into
the
equation.
I
think
that
there's
a
fair
amount
of
information
that
the
Drupal
community
could
learn
from.
F
A
A
result
of
going
through
some
of
the
structure
that
is
in
place
as
a
result
of
the
kubernetes
community,
so
I'm
gonna
start
by
just
going
through
a
couple
of
links.
The
first
one
is
github.com,
slash,
kubernetes,
slash
community.
The
first
thing
that
you'll
notice
here
is
that
there's
a
very
good
set
of
documentation,
a
very
good
understanding
of
what
the
governance
model
is,
and
basically
every
question
that
you
could
possibly
have
with
being
able
to
participate
in
the
kubernetes
community
is
available
here.
A
So
basically,
the
code
of
conduct
is
pretty
thorough,
pretty
straightforward
and
it
models
itself
after
at
the
cloud
native
code
of
conduct
and
is
represented
in
many
different
languages.
Kubernetes
again
is
a
very
youth
project
and
I.
Think
that
there's
a
lot
of
opportunity
that
the
you
know
Drupal
community,
could
learn
from
some
of
what's
going
on
here.
But
if
you
have
a
few
minutes,
it's
been
some
time
reading
about
it.
It's
generally
just
touching
on
things
that
you
would
expect
be
respectful
for
people,
don't
sexually
accost
people,
no
trolling
or
insulting,
don't
harass.
A
A
With
a
little
bit
more
structure,
we
ended
up
forking,
some
of
what
the
kubernetes
said
community
does
to
create
this
group,
so
the
readme
file
on
the
github
repo
is
auto-generated
in
the
same
way
that
you
would
auto
generate
a
fishel
kubernetes
stick
and
the
idea
there
is
that
it's
kind
of
like
programming
right.
You
have
an
interface.
That
interface
defines
that
there
should
be
participants
that
there
should
be.
A
It
may
be
people
governing
the
direction
other
project
that
there
should
be
regular
meetings,
that
there
should
be
ways
to
communicate
about
those
meetings
that
there
should
be
agendas
in
place
and
references
to
all
of
the
documentation
is
created
in
a
very
public
way.
So
that's
kind
of
what
the
same
concept
does
and
then
again
on
the
readme.
They
just
go
down
and
touch
on
how
to
get
in
touch
with
them,
how
to
contact
them,
be
it
for
a
special
interest
group
or
for
the
kubernetes
project
as
a
whole.
A
They
do
run
a
slatton
channel
and
even
go
as
far
as
publishing
slack
guidelines
to
help
people
understand.
You
know
what
it
takes
to
get
involved
in
and
in
the
community
what
it
takes
to
create
a
new
working
group,
what
it
takes
to
bring
your
ideas
out
there
and
essentially
articulate
them
with
different
people
and
how
to
get
responses.
So
a
lot
of
times,
like
you
know,
a
new
contributor
coming
into
the
Drupal
slack
rooms.
A
They
might
be
a
little
intimidated
as
far
as
what
rooms
they
need
to
go
into
or
or
where
they
need
to
go
to
get
specific
information
on
this
kind
of
documentation.
These
combinations
of
SIG's
working
groups
and
user
groups,
which
we'll
go
over
in
a
little
bit,
really
play
well
to
get
new
contributor
contributors
up
to
speed
quickly
because
they
can
move
at
their
own
pace
and
they
have
all
of
the
information
that
they
need
to
be
able
to
do
it.
A
They
also
do
a
really
neat
thing
here
with
this
tool
called
temp
Ellis,
which
is
an
automated
way
of
managing
slack.
So,
essentially,
if
you
want
to
create
a
new
channel,
you
open
up
a
pull
request.
If
you
want
to
create
a
new
conversation,
you
do
it
through
get
essentially,
which
is
something
that
most
developers
are
pretty
familiar
with
by
now,
but
it's
a
pretty
cool
way
of
doing
things.
A
Governance
model
is
basically
at
this
community
governance
AMD.
It's
really
nice
to
wear
it
through
and
again
you'll
note
that
they
immediately
focus
on
the
code
of
conduct,
so
proper
behavior
inside
of
this
community
is
really
a
critical
part
of
who
they
are
and
what
they
are
looking
to
accomplish
and
then
getting
into
the
values
like
I
mentioned,
it's
very,
very
important
to
have
a
vision
and
values
right
and
some
of
the
values
that
they
have
here
are
very
good
tenants.
A
A
lot
of
them,
you
know,
could
be
applied
in
a
lot
of
different
software
principles
or
disciplines,
but
distribution
is
better
than
such
with
centralization.
So
the
idea
of
bottlenecks,
the
idea
of
you
know
maintaining
a
core
group
of
people
that
are,
you
know
smarter
than
everybody
else
and
end
up
becoming
the
bottlenecks,
because
they're
so
good
at
what
they
do
is
something
that
this
project
constantly
strives
not
to
do
and
has
good
checks
and
balances
in
place
to
help
with
that
they
focus
on
the
concept
of
a
community
of
a
product
or
a
company.
A
So
that's
something
that
you
know
I
think
the
Drupal
community
does
very
well.
We
don't
like
to
endorse
products.
We
don't
like
to
push
products
we
like
to
do
things
in
a
very
generic
and
open
way,
and
the
community
is
very
important.
That's
why
we
spend
the
time
that
we
do
on
community
and
talking
about
it.
Drupal
would
not
be
where
it
is
without
it
and
they
have
a
high
tendency
to
focus
on
automation
over
process,
and
you
know
I
think
that
all
of
us
can
relate
to
this
and
some
some
capacity
as
complexity
increases.
A
It
becomes
more
and
more
difficult
to
be
able
to
interact
with
the
system
as
long
as
there's
manual
process
and
place
to
interact
with
the
system.
It
continues
to
get
more
complicated
until
eventually
it
becomes
untenable,
but
for
a
small
amount
of
people
by
focusing
on
automation
over
process,
they
open
it
up
to
be
able
to
grow
essentially
and
do
it
in
a
sustainable
way
and
then
a
a
couple,
more
inclusive
is
better
than
exclusive
I.
Think
that
we've
learned
that
pretty
well
through
the
the
diversity
initiative.
A
It's
great
to
have
a
wide
range
of
opinions,
a
wide
range
of
ideas,
a
wide
range
of
people
that
are
capable
of
helping
and
that
might
have
different
perspectives
that
we
don't
have
and
the
final
one
is
evolution
is
better
than
stagnation,
so
I
think
the
way
that
I
interpret.
That
is
that
you
know
we
need
to
be
consistently
open
to
new
ideas,
it's
very
easy
to
to
get
caught
in
the
trap
that
oh
well,
we've
been
working
on.
This
really
great
thing
for
the
past
X
amount
of
time,
and
nobody
else
is
doing
it.
A
So
it
must
be
something
special,
but
in
reality
there
might
be
better
ways
of
doing
what
you're
thinking
about
or
better
ways
of
addressing
a
specific
problem.
If
you
can
get
the
right
kind
of
engagement
from
the
community,
the
right
kind
of
conversations
happening,
you
tend
to
evolve
instead
of
stagnate,
which
is
it
which
is
very
nice.
A
Let's
see
the
general
working
structure
of
kubernetes
as
a
project
is
very
interesting.
It
took
Drupal
a
long
time
to
get
a
good
governance
model
in
place
and
it
took
a
little
while
before
we
had
initiative
leads.
So
there
was
a
time
when
things
were
a
little
bit
more
Wild
West
than
they
currently
are
see.
If
I
can
hide
some
of
the
Sun.
But
this
is
the
basic
governance
model
of
kubernetes.
A
There's
larger
steering
committees
that
act,
I,
don't
know
almost
is
like
the
general
directions
setting
navigator
of
the
ship
for
lack
of
a
better
way
of
saying
that,
but
the
steering
committees
they
have
project
level
governance.
They
may
or
may
not
be
completely
open
in
public,
and
they
kind
of
have
the
last
say
in
what
this
SIG's
do.
So
they
also
serve
as
an
arbiter
of
difficult
conversations
and
help
to
really
guide
the
community
a
little
bit.
A
They
tend
to
stay
out
of
the
way
as
much
as
possible
unless
there's
a
specific
reason
for
them
to
be
there
Security's
a
good
one
that
tends
to
have
steering
committees
involved,
there's
not
a
lot
of
public
communication
that
can
happen
around
security
issues.
They
need
to
be
solved
kind
of
in
private
and
there's
a
very
specific
structure
for
that
to
end
up
happening.
The
decision
Pratt,
a
path
that
we
tend
to
go
through
is
very
similar.
A
I
in
both
cases
here,
but
these
generally
represent
what
you're
saying
so
your
sis
or
your
you
know,
domain
or
horizontal
special
interest
groups,
and
each
of
the
the
SIG's
are
kind
of
what
we're
doing
here.
It's
a
cool
group
of
people
that
are
focused
in
a
specific
topic
area
that
might
be
networking
that
might
be
disc.
A
That
might
be
memory
for
us,
it
might
be
CMS's
or
Drupal
and
then,
from
there
the
SIG's
have
the
ability
to
spit
out
split
out
into
different
sub
projects
in
the
sub
projects
are
basically
each
of
these
groups
are
permanent
once
accepted
into
the
community
until
they
determine
they
self
deselect.
By
determining
that,
their
topic
area
has
been
handled
or
doesn't
mean,
isn't
relevant
anymore,
so
they
can
either
deprecated
themselves,
so
they
can
be
instructed
from
larger
steering
committee
or
one
of
the
special
interest
groups
to
go
ahead
and
deselect.
A
On
the
other
thing,
that's
really
unique
that
we
have
in
the
kubernetes
space
that
doesn't
really
exist
in
the
drupal
space.
Is
the
concept
of
these
working
groups
and
working
groups
can
be
impromptu
kind
of
cross-discipline
conversations
that
need
to
happen
in
in
a
cohesive
way.
So
a
good
example
of
that
might
be.
You
know,
file
systems
keep
coming
up
when
we
talk
about
kubernetes
and
rule
or
PHP
CMS
is
in
general,
and
I
work
a
lot
with
the
type
of
three
community.
A
So,
for
example,
a
working
group
might
spawn
up
that
has
some
folks
from
the
drupal
community.
Some
people
from
the
typo3
community
there
are
a
common
bind.
Is
that
their
PHP
developers
that
are
working
on
a
a
common
problem
and
as
a
result
of
that
working
group,
they
may
be
able
to
do
something
that
stands
a
specific
special
interest
group
but
provides
a
good
amount
of
value.
A
So,
for
in
that
particular
example,
they
might
come
up
with
a
composer
package
that
is
specifically
meant
to
work
with
distributed
file
systems
and
then
share
that
in
a
more
global
way
that
sadly
accessible
to
solve
the
problems
for
both
the
Drupal
space
and
for
the
type
of
three
space.
So
it's
a
very
interesting
working
arrangement
that
they
have,
that
I
think
works
pretty
well
going
into.
A
You
know
the
details
of
each
of
these.
This
is
the
sig
reference,
so
I've
already
touched
on
this.
You
know
it's
a
special
interest
group.
It
can
be
focused
on
things
like
networking
discs.
They
can
go
horizontal
focus
on
things
like
scalability
and
specific
architecture
topics,
but
they
can
be
project
related,
so
testing
release,
Docs
contributor
experience.
A
Basically,
what
they're
looking
for
is
a
very
standard
structured
model
for
being
able
to
do
these
things,
and
these
exist
in
a
yamo
file.
Essentially,
so,
if
you
go
into
I,
believe
the
community
group
you'll
notice
that
there
is
a
make
file
in
this
mate
file,
we'll
go
through
and
generate
all
of
the
content
for
this
entire
repository
and
as
you
go
through
each
of
these
you'll
start
to
see
that
there's
common
simin
what
similarities
so
like.
For
example,
if
we
look
at
this
interest,
which
is
the
drug
drug.
A
It
follows
the
same
format
as
any
other
special
interest
group
out
there,
because
it's
all
automatically
generated
it's
a
very
good
structure,
because
it
takes
a
lot
of
things
into
account.
Helps
you
understand
where
the
lines
of
communications
are.
What
the
contact
points
are
for.
A
specific
project
allows
that
project
to
break
up
into
specific
github
teams,
so
that
you
say,
for
example,
there's
an
API
group
or
some
subset
of
the
special
interest
group
that
has
expertise
that
the
rest
of
the
community
might
be
able
to
use.
A
Inside
of
this
has
the
concept
of
sub
projects,
and
all
of
this
again
is
represented
in
the
animal
files
and
what
you
need
to
do
to
kind
of
go
through
and
get
started,
how
to
discuss
things,
how
to
get
tied
into
slack
and
what
it
takes
to
actually
contribute
and
where
the
recorded
meetings
are.
So,
basically,
it's
a
very
quick
and
simple
way
to
create
a
functional
working
group
that
again,
in
the
open-source
spirit,
leverages
a
lot
of.
A
What's
already
been
done
out
there,
a
lot
of
the
smarter
people
that
are
capable
of
managing
massive
projects.
You
have
the
ability
to
leverage
what
they've
done
and
take
it
to
your
own
project
or
become
a
part
of
this
larger
tremendous
community
and
I.
Think
that
there's
a
lot
of
opportunity
there,
particularly
for
some
of
the
distributions
that
might
be
in
existence
in
Drupal,
as
some
of
the
you
know,
different
working
groups
that
are
in
existence
in
Drupal
there's
a
lot
that
can
be
learned
here.
A
It's
very
simple
to
go
about
creating
some
of
this
stuff,
so
just
so
that
you
can
see
what
was
necessary
to
actually
create
this
thing
that
we
currently
run.
There's
a
full
request
out
here
that
I
have
and
you'll
see
that
it's
very
simple
you,
basically
just
edit
the
ammo
file
and
it's
specific
parts
inside
of
there
did
a
couple
of
modifications
to
be
able
to
extend
this
outside
of
the
kubernetes
slack.
But
from
there
you
have
the
ability
to
go
through
it's
all
auto-generated.
A
So
the
way
that
you
create
one
of
these
groups
is
by
following
this
process.
You
start
with
the
templates.
They
give
you
a
very
specific
example.
So
the
idea
here
is
that
anybody
can
really
pick
these
up
run
with
them
and
be
able
to
do
really
amazing
things
very
quickly.
There's
a
definite
structure
to
all
this
and
I
again
think
that
the
Drupal
community
can
really,
you
know,
maybe
learn
a
little
bit
from
what's
happening
inside
of
kubernetes
I.
A
A
And
ultimately,
if
we
can
say
you
know
that
type
of
three
example
with
the
file
system
is
a
key
one
for
me,
you
know
if
we
can
come
together
and
be
able
to
have
those
conversations
in
a
way
that
allows
for
others
to
participate,
then
we're
going
to
get
better.
It
will
do
and
that's
basically
it
just
a
super
quick
walk
through
any
questions.
A
I've
taken
a
first
draft
at
as
much
of
it
as
I
can,
and
it
does
link
back
to
the
kubernetes
project.
So
if
there's
any
gaps,
there
definitely
help
me,
identify
them
and
we'll
get
those
filled
in
and
populated.
The
other
thing
that
I'm
definitely
looking
for
is
somebody
to
help
basically
govern
this
specific
cig.
A
One
of
the
requirements
for
doing
a
proper
cig
inside
of
Drupal
or
kubernetes.
Is
that
there's
at
least
two
participants
at
that
level
and
that's
an
open
invitation
to
anybody
that
would
like
to
participate.
So
if
you
would
like
to
participate
in
contact
with
me
offline
happy
to
share
the
responsibility
and
help
grow
this
a
little
bit.
The
other
thing
that
I'd
like
to
talk
a
little
bit
about
is
potentially
changing
the
the
name
of
the
cig
to
be
a
little
more
generic.
A
So
right
now
it's
called
cig
drupal
and
it's
focused
specifically
on
drupal,
but
I
just
spent
a
lot
of
time
in
europe,
a
lot
of
PHP
conferences
and
that
type
of
three
conferences-
and
there
are
other
people
out
there
that
would
like
to
participate
in
something
like
this
and
by
branding
it
as
a
drupal
specific
activity.
It
might
in
fact
discourage
some
of
that
participation,
so
I
generally
like
to
throw
that
out.
There
is
a
question:
does
that
sound
like
something
that
you
know
would
be
worth
addressing
or
or
does
that
sound
like?
B
F
A
Of
the
things
that
I
saw
the
last
time,
I
did
a
composer
install
of
Drupal
8
is
that
some
of
the
typo3
packages
actually
are
included
in
court
Drupal
these
days.
The
other
thing
that
I
noticed
about
that
is
that
when
I
do
a
composer
install
of
a
type
of
3
system,
I,
don't
see
anything
from
the
Drupal
community.
That's
contributing
to
that
conversation.
So
one
of
the
nice
things
I
think
would
be
to
be
able
to
get
that
cross-pollination
going
a
little
bit
better.
C
C
You
know,
I
think
some
of
the
conversation
can
sometimes
be
a
little
academic
about,
like
maybe
nice,
things
to
do.
If
you
have
like
one
application
or
everybody
can
get
on
the
same
page,
but
you
know
there's
probably
broadening
that
pool
will
make
it
easier
to.
You
know
maybe
address
issues
around
like
progressive
cloud
migration.
C
You
know
with
kubernetes
because
a
lot
of
these
workloads
just
like
either
the
budget
is
not
there
or
the
client
and
buy-in
of
whatever
is
not
there,
but
there's
still
things
that
we
can
do
to
improve
that
so
I'm
I'm,
all
for
it
and
it'll
probably
give
some
better.
You
know
broad
exposure
right
if
we
can
get
twice
as
many
people
on
the
call
be
better
I.
Think.
A
A
Next
agenda
item
is
basically
any
recent
challenges
or
celebrations
that
people
would
like
to
share.
As
far
as
the
Gwinnett
East
is
concerned,
I
can
go
ahead
and
start
I've
become
particularly
interested
in
the
build
pack
project.
So
it's
I
think
build
pack
Co,
it's
a
relic
of
Heroku
I,
don't
know
Heroku
I,
don't
know
if
we're
all
like
is
the
right
word
that
I
should
use
there,
but
essentially
what
Heroku
has
done
is
become
part
of
the
cloud
native
foundation
in
supporting
this
specific
project.
A
They
work
with
piffle
labs,
which
is
a
fairly
large
company
that
has
a
pretty
decent
interest
in
these
boom
packs,
as
well
I
mean
if
you
get
a
chance
to
look
through,
build
apps,
they're,
pretty
phenomenal
and
they
kind
of
sound
like
they
could
be
used
as
a
way
to
strongly
define
what
Drupal
actually
is
on
kubernetes
or
or
in
general,
and
the
end
result
of
these
build
packs
are
that
they
will
build
out
a
docker
container
that
essentially
represents
kubernetes.
That
might
have
you
know
all
of
the
community
generated
logic.
A
B
Yeah
I'll
throw
one
out,
so
we've
been
grappling
with
how
to
handle
backups
and
restores
and
environment
seeking
and
things
along
that
line.
So
we
started
out
many
months
ago,
looking
it
into
Ark,
which
is
now
falero,
which
is
you
know
the
community's
backup
system,
which
takes
all
your
objects
in
it.
So
we
found
that
was
a
bit
problematic
in
some
ways,
because,
whilst
yeah
you
captured
the
entire
state
of
deployment,
you
didn't
made
it
difficult.
B
If
you
just
wanted
to
capture
the
state
of
the
application,
it's
about
four
files
in
the
database,
so
we
using
cout
builder
I've
got
a
backup
and
a
restore
operator
that
you
know
is
like
so
Drupal
centric
in
terms
of
it
looks
up
the
config
map
and
secrets
for
our
Drupal
deployments
and
then
just
intuitively
knows
how
to
dump
the
database
dump
the
files
directory
and
and
then
yeah
and,
conversely,
do
the
restores
in
the
opposite
direction.
So
we're
using
rustic
under
the
hood
just
to
manage
the
actual
and
like
backup,
repository
and
yeah.
B
B
With
rustic,
you
get
essentially
like
a
repository,
so
you
interact
with
it
using
the
rustics
CLI
and
you
can
say
you
know,
dump
out
a
particular
file
or
it's
a
particular
path
at
this
version,
or
you
can
restore
the
entire
thing.
So
yes,
it's
quite
it's
even
got
a
really
nice
fuse
file
system
that
you
can
play
with.
B
So
when
you
create
a
backup,
you
can
give
it
tags,
or
you
know
some
sort
of
label
to
identify
why
you
created
it
or
you
know
what
pipeline
is
created
it
and
in
your
fuse
file
system
you
get
this
great,
you
might
keep
you
on.
You
know
repo,
slash
tags,
it
gives
you
all
the
tags
that
have
been
created
in
that
repository.
F
C
And
so
for
for
initiating
those
backups,
it
sounds
like
you're
using
some
sort
of
we're,
not
on
AWS
I.
Don't
know
the
parameters
are
different,
but
it
sounds
like
you're
using
some
sort
of
like
distributed.
You
know
EBS
or
something
like
that
like
where,
where
do
you
run
and
what
runs
those
backups
I'm,
sorry
yeah.
B
Yeah,
so
so
the
backup
so
like
so
now
operator
creates
a
job.
So
this
couple
of
containers
that
run
that
you
know
do
the
Dom
for
the
database
and
then
the
rest
ik.
They
copy
things
into
that
and
our
the
wrested
repo
is
just
stored
on
a
persistent
volume
claim
so
where
we've
got
ours
in
AFS.
But
you
know
you
could
just
as
easily
sorry
as
it's
in
s3
yeah,
but
you
could
just
as
easily
do
it
on
an
80s
for
anymore.
Or
what
have
you.
B
B
How
they
kicked
off
so
they're
kubernetes
objects.
So
so
you
know
how
developers
can
go
through
our
command
line,
they
can
go.
You
know,
skip
a
backup,
create
and
it'll
create
a
backup
object
which
then
kicks
off
all
the
other
stuff,
but
yeah
I
mean
you
could
also
have
other
entry
points
like
a
scheduled
cron
job
that
creates
them
as
well.
C
Yeah
we're
still
trying
to
kind
of
figure
out
the
right.
You
know
we
have
we're
doing
sort
of
dr
appropriate
backups
with
Valero,
because
it's
great
for
that,
but
sort
of
that
more
point
in
time,
especially
to
the
file
system
right
with
purpose.
Persistent
volume
claims
it
stopped.
So
that's
cool
to
see
yeah.
E
And
Valera
doesn't
cover
your
like
once
you
move
MySQL
out
of
the
cluster,
so
if
you're
running
it
on
RDS
or
something
to
that
effect
and
Valero
doesn't
doesn't
cover
that
for
you,
so
you
don't
really
have
that
full
source
of
truth.
Like
you,
you
can
either
write
a
plug-in
which
then
dumps
the
database
and
then
stores
it
in
in
Resta
core,
where,
if
you
want
it
to
go
or
or
you
just
kind
of
defer
to
the
mic
on
AWS
RDS
is
backup
policies
and
services.
E
But
then
you
have
this
kind
of
decoupled
restore
where,
where,
if
you
want
to
do
it
on
demand
for
a
developer
yeah,
you
kind
of
constrained
by
like
what
Valera
can
do
as
well
as
what
IDs
can
live
in
that
book
and
that
doesn't
really
always
work
out
too
well,
but
yeah.
We,
we
sort
of
found
ourselves
writing
like
that,
well
plug
in
and
then
you're
kind
of
going
will
resting,
is
kind
of
the
awesome
source
under
this.
E
If
you
don't
want
to
back
up
the
kubernetes
objects
themselves,
if
you
want
to
take
state
which
is
kind
of
the
thing
that
we
all
care
about,
the
most
is
that,
like
files
and
database,
the
rest
you
can
kind
of
recreate
like
or
you
can
just
still
useful
area
to
snapshot
those.
But
if
you
care
at
state
land,
yeah
rustic
is
definitely
definitely
worth
a
look
for
sure,
and
even
and
even
if
you're,
just
running
the
ends
or
whatever
you're
doing
definitely
have
a
look
at
rustic
I'm,
looking
at
it,
I'm
gonna
start
using
it.