►
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
Deep Dive: kubespray - Antoine Legrand, Red Hat & Chad Swenson, AT&T
Kubespray is one of the most versatile kubernetes-cluster manager and benefits of an extremely active community. The first half of the session we will demo and discuss the most recent features such as deploying on hybrid linux-windows cluster, enabling GPU compute nodes, share useful tips and focus in general to get more from Kubespray. On the second half of the deep-dive we would like to give voice to the community and open a discussion about how to keep moving the project forward, next priorities and allow a large amount of time for questions.
To learn more: https://sched.co/Grdp
B
B
Ok,
so
cute
ray
studied
with
committees,
one
zero
is
one
of
the
oldest
projects
in
the
ecosystem,
so
2015
one
friend
and
s
colleague
as
may,
encourage
just
was
always
on
the
edge
of
every
technology.
He
came
to
me
and
made
me
a
demo
of
communities.
I
was
like
wow,
that's
amazing,
and
now
we
were
like
just
show
me
believer
that
committed
to
the
future
in
a
large
organization,
and
we
started
like
a
small
campaign
to
convince
everyone.
B
We
need
to
rent
that
in
production,
but,
to
be
honest,
we
failed
to
convince
anyone
with
a
project
we
took
to
DevOps,
because
the
main
answer
was
like:
okay,
that's
nice
on,
so
you
have
a
cluster,
but
all
we
get
there.
It's
to
add.
It's
got
to
maintain
its
what
to
manage.
So
we
didn't
stop
there
and
we
decided.
This
is
how
we
decide
to
create
cool
spray
to
make
it
easy
to
install
and
manage
cluster.
B
So
that
was
like
the
starting
point
and
inside
this
mission,
because
we
are
for
our
own
usage,
we
had
some
goals.
One
was
not
not
to
deploy
proof
of
concept.
We
really
wanted
to
deploy
to
production,
so
one
core
course,
of
course,
is
deployed
prediction.
Readiness,
cluster
other
part,
is
always
focus
on
the
metal
first,
that
was
our
environment.
A
So,
in
keep
spray,
we
define
production
readiness
by
these
four
tenets:
high
availability,
security,
maintenance
and
observability.
This
is
the
same
list
of
tenants
that
antwon's
followed
since
the
beginning
of
the
project.
These
these
goals
just
drive
our
decisions.
What
on
keep
spray
when
the
exceptional
in
the
kubernetes
community
and
containers
in
general
are
changing
and
evolving
so
rapidly,
and
there's
always
going
to
be
something
new.
A
And
so
what
does
it
mean?
Have
an
H,
a
node?
Well,
the
nodes.
You
have
to
keep
working
so
the
components
that
govern
A's,
components
that
run
on
each
node
need
to
have
guaranteed
resources
it
yet
with
quality
of
service
class,
that
you
put
the
components
in
the
resource,
reservations
and
limits
that
are,
and
also
we
introduced
priority
class
and
once
that
feature
became
available,
which
gives
you
a
priority
and
scheduling
against
other
other
pots
and
workloads
in
the
cluster.
A
So
you
know
you
have
these
these,
these
controls
and
composability
over
all
this
as
well,
because
there's
many
different
use
cases
for
kubernetes
and
different
clusters
have
different
needs
out
of
the
communities
components.
So
we,
you
know,
have
some
sensible
defaults
for
for
all
of
these,
but
we
leave
it
configurable
for
the
user.
A
You
know
and
also
type
different
types
of
node
and
just
describe.
The
topology
is
really
really
easy,
with
cube
spray
just
ansible
in
general,
and
that
gives
you
even
more
flexibility
and
tailoring
keeps
great
to
your
use
case.
Another
thing
that
I've
done
just
some
work
in
on
the
side
haven't
pushed
a
PR.
Yet
is
a
no
problem
detector,
which
gives
you
ability
to
define
these
these
custom
detection
x'.
A
For
really
anything
on
a
node,
you
has,
like
a
log,
see
an
error,
and
you
can
also
even
write
custom
scripts
to
write
your
own
plug-ins
for
it,
and
you
can
interact
with
your
nez
api
to
you
know,
respond
to
any
of
these
detected
problems
and
even
write.
You
know
self-healing
recovery
controllers.
I
don't
have
any
of
that.
Keep
spray
yeah.
I've
been
experimenting
with
that
on
the
side,
but
expect
probably
something
coming
in
2019
or
will
be
introduced
in
the
cubes
right,
so
at
CD.
A
This
is
actually
the
easy
one
for
them
to
make
highly
available
its
RAF
base.
So
you're
familiar
with
raft,
you
don't
want
to
use
an
even
number
of
nodes
because
you're
increasing
your
quorum
size
without
actually
any
true
benefit
electric
fault
tolerance.
We
actually
have
a
pre
check
for
that.
If
you
try
to
create
a
cluster
with
an
even
number
of
@cd
nodes
will
prevent
you
before
proceeding
and
it's
you
know:
H
I,
but
H
a
by
default
with
with
three
nodes,
because
you
know
one
is
an
H
I.
A
Obviously,
you
don't
want
to
do
two,
and
then
three
three
is
the
the
minimum
for
H
a
and
we,
the
other
thing
that
makes
high
availability
is
he
from
went
for
for
anything?
That's
accessing
at
CD?
Is
that
it
has
this
smart
client
feature
where
you
can
basically
provide
a
list
of
endpoints
and
convinced
roles
to
your
client
and
the
the
client
will
resolve,
while
the
load,
balancing
and
failover
just
internally
with
without
having
to
depend
any
external
source
of
lb
the
control
plane.
A
One
one
common
debate
is
you
know
something
like
keep
alive
D,
which
would
be
a
proxy
that
runs
on
every
single
node
and
basically,
you
know
cubelet
any
other
components
that
need
to
contact
the
API
server
just
go
through
that
local
proxy
and
that's
load
balance
across.
Potentially
you
know
many
API
servers
or
nginx.
You
can
set
up
an
engine
next
thing
on
every
node.
That
is
something
similar.
You
straight
currently
has
there's
trade-offs
to
both
of
those
with
the
with
this
proxy
approach.
A
A
A
We
are
actually
using
cube
ATM
by
default
now
and
will
benefit
from
any
of
the
features
or
best
practices
that
were
implemented
into
cube
ATM,
and
then
you
also
have
this
other
use
case
for
high
availability
and
your
control
plane,
which
is
external
access.
So
you
know
something
these
are
using
cube,
CTL
or
any
other
controller
that
accesses
or
code
that
accesses
your
cluster
from
outside
of
it.
A
And
so
you
have
a
few
options
here,
and
it
really
depends.
A
lot
on
your
infrastructure.
External
DNS
is
is
a
commonly
as
one,
however,
goop
spray
will
integrate
with
whatever
solution.
You
have
it's
quite
easy
to
setup
all
the
PKI
to
assign
your
your
load,
balancers
and
dns
names
just
through
the
keeps
reconfiguration
yeah
you
know,
so
we
can
essentially
integrate
with
whatever
option
you
have
there
so
quickly.
B
To
like
to
keep
spray
the
solution,
we
have
any
one
solution
for
know:
either
Ingenix
so
on
each
node,
Winstar
nginx
proxy,
that
is
configured
to
a
load
balance
to
every
master
and
the
local
and
the
cube,
let's
just
reach
locally
design
genex.
So
this
is
now
in
kill
spray.
Are
we
achieve?
I
opt
for
the
master
from
the
node,
but
I
say
in
the
future,
we're
going
to
align
with
whatever
sick,
just
a
life
cycle.
Decide
on
that
and.
A
And
also,
if
you
do
have
external
DNS
or
something
as
an
option,
you
can
integrate
that
very
cleanly
with
keep
spray
and
and
use
that
across
your
closer
for
cluster,
for
both
internal
access
to
the
API
server
and
external,
it's
actually
recommended
practice.
That's
what
I
personally
do
is,
if
you
can,
if
you
have
that
option,
so
the
cluster
services
are
basically
any
any
pods
that
are
Koreans
components
themselves
to
degree.
So
a
good
example
would
be
the
cluster
DNS
and
we
need
to
make
these
highly
available
as
well.
A
So
one
way
to
do
this,
I
mean
it's,
it's
a
lot
easier
because
we're
in
kubernetes
land
at
this
point
so
Pyrenees
has
a
lot
of
nice
features.
4-H
a
built
in
one
thing
that
we
take
advantage
of
is
the
cluster
proportional
autoscaler
for
our
DNS
replicas,
and
we
use
this
for
both
cube
DNS
mode
and
core
DNS
mode.
Accordion
s
is
the
new
default
by
the
way
and
it
basically,
you
can
define
how
many
replicas
of
your
DNS
pod
should
exist.
A
Based
on
how
many
nodes
are
in
the
cluster,
how
much
CPU
capacities
in
the
cluster
there's
a
few
configurable
fields,
and
this
this
works
quite
well,
because
you
know,
as
the
cluster
grows,
the
the
strain
put
on
these.
These
cluster
services
grows
as
well.
So
you
want
to
make
sure
it's
scaled
proportionally
and
we
may
also
add
vertical
pot
out
of
scaling
which
gives
you
the
ability
to
adjust
the
resource
requests
in
limits
of
a
pod
dynamically.
A
It's
still
an
alpha
feature
and
there's
a
couple
of
things
that
it's
less
like
recreate
the
pod,
because
you
can't
because
those
field
during
mutable
on
a
pod
but
yeah.
We
look
look
into
that
and
probably
adopt
that
and
for
some
of
these
cluster
services,
as
as
the
feature
matures
so
security
very
important
to
keep
spray
as
well.
So
our
back
is
on
by
default
and
if
you
don't
know
in
our
Beca,
that's
an
authorization
mode,
that's
built
into
the
3
RDS
API
server,
its
role
based,
often
yep
so
you've
got
so.
A
You've
got
components
that
use
our
back,
and
you
can
also
create
your
own
custom
roles
and
bindings
for
for
users.
We
also
have
configurable
authentication
modes,
webhook,
authentication,
just
token
authentication
basic
off
you
could
use
the
OID.
C
is
also
supported,
so
you
can
plug
in
with
whatever
existing
authentication
system.
A
A
We
have
gone
to
great
lengths
to
ensure
some
of
these
features,
still
work
across
all
of
various
versions
of
cura
Nettie's
and
at
CD
and
other
components
that
were
not
necessarily
decided
with
designed
with
upgrade
in
mind,
especially
not
automated
upgrade,
but
a
lot
of
workarounds
were
required
to
keep
this
working
and
will
continue
to
be,
and
it's
getting
better
though
the
community
is
looking
for
more
repeatable
approaches
going
forward.
There's
some
discussions
in
the
computer
summit
on
Monday
we're
going
around
that
so
will
be
some
interesting,
interesting
developments,
they're
scaling
a
cluster.
A
You
know
adding
adding
some
additional
worker
notes
or
cluster
removing
nodes
or
removing
an
entire
cluster.
These
are
you
know.
These
are
all
features
of
full
cluster
lifecycle
that
it
keeps
very
supports,
backup
and
restore.
So
we
do
currently
take
at
CD
snapshots
before
an
upgrade
is
performed
just
in
case.
Something
off.
Ik
happens:
you
need
to
roll
back
and
expect
some
improvements
here
or
in
2019
as
well.
A
Just
a
list
of
some
of
the
the
ants
will
play
books
that
provide
these
features.
You
have
cluster,
it's
for
installing
new
cluster
or
reconfiguring
cluster.
You
have
upgrade
cluster,
which
performs
a
graceful
upgrade
in
a
rolling
fashion.
The
way
that
works
is
it
will
perform
an
upgrade
on
a
configurable
amount
of
nodes
at
a
time.
I
think
the
default
is
twenty
percent
of
all
your
notes
and
it'll
first
drain
them
to
make
sure
all
the
pods
workloads
running
on
those
nodes
are
moved
to
other
nodes
to
the
cluster.
A
They
don't
perform
the
upgrade
and
then
it'll
on
coordinating
absolute,
also
accordance
your
notes,
but
in
the
uncoordinated
once
the
nodes
are
fully
upgraded
so
that
you
can
return
them
for
scheduling
additional
workloads
and
remove
no
reset
somewhat
self-explanatory.
I've
talked
about
those
a
little
bit.
You've
wanted,
removing
it.
Individual
node
can
use,
remove.
Node
reset
is
for
uninstalling
all
of
the
things
to
keep
spray
installed
and
observability,
and
this
is
another
area
that
we
would
definitely
like
to
get
better
at
and
plan
to.
A
We
currently
have
metrics
server
as
as
an
optional
add-on,
and
we
don't
have
really
many
d.
Fokin
integrations
other
than
just
what
the
provides
to
a
user
by
default.
But
it
is,
it
is
there.
It
is
an
install
option
in
2019
we'd
like
to
revisit
prometheus,
there
were
previously
some
versions
of
Prometheus.
Where
think
you
spray
those
have
all
been
removed.
By
now,
we
would
like
to
use
the
Prometheus
operator
and
figure
out
some
ways
to
provide
some
default
configurations
for
the
operator.
A
That
would
make
sense
or
could
be
tunable
enough
for
users
to
and
that
are
using
cube
spray.
So
that'll
be
interesting,
because
people
need
a
lot
of
different
things
out
of
Prometheus,
and
it
very
much
depends
on
how
you're
using
hearing
IDs
so
we'll
try
to
provide
some.
You
know
reconfigurable,
but
sensible,
defaults,
I.
Think.
B
A
A
Okay
and
next,
another
goal
of
keeps
very
after
production.
Readiness
is
where
bare
metal
first
for
on
premise
scenarios.
So
what
does
it
mean
to
be
bare
metal
first?
Well,
we
want
to
make
sure
that
keeps
freight
works
well
on
bare
metal.
There's
a
few
reasons
why
one
it's
one
of
the
it
was
this
one
of
the
original
use
cases
and
it's
one.
One
reason:
many
people
come
to
cute
spray.
A
Also,
if
you
need
to
overly,
if
you,
if
you
if
you
target
bare
metal
first,
a
lot
of
the
cloud
providers
are
also
easier
just
with
the
models
we
have,
because
this
is
a
bare
metal
is
a
good
fit
for
ansible.
His
ssh
is
the
only
protocol
needed
it's.
You
can
use
SSH
strung
on
any
distro,
and
the
idempotency
of
playbooks
can
account
for
variants
ii
across
different
OS
images.
So
you
know
just
because
you
have
multiple
hosts
per
bit.
A
You
get
up
to
those
provisions,
go
to
the
exact
same
operating
system,
the
exact
same
hardware.
It
could
look
completely
different
and
we
want
to
be
able
to
target
that
use
case.
That's
a
very
common
use
case.
So
the
way
that
works
is
ansible
will
first
check
to
see
if
a
change
is
already
in
place
or
in
so
many
packages
already
in
place
before
attending
to
install
it.
A
That's
said
two
things,
and
so
we
also
want
to
make
sure
that
all
of
our
OS
packages
are
tunable
and
and
supplements
what's
already
in
place
or
you
know,
if
it's
not
there
and
again.
So
if
you,
if
you
target
very
metal
first,
you
you
get
a
lot
of
benefits
with
with
other
types
of
infrastructure
providers,
because
you've
really
solved
a
lot
of
the
hard
problems
that
you
may
not
have
had
this
Alban,
your
clever
writer,
but
you
know
we
do
support.
We
run
on
public
cloud,
private
cloud,
bare-metal.
B
I
will
cheat
a
little
bit
more
there
because
there
is
a
lot
of
work
on
progress.
So
what
means
compatibility
means
we
let
as
a
maintainer,
we
don't
want
to
make
decision
about
what
kind
of
technology
you
want
to
run.
So
you
can
choose
your
cluster.
Like
your
cloud
provider
is
our
own
pamita.
You
can
choose
the
operating
system
you're
going
to
use
the
network
plug
in
the
state
management,
come
to
his
vault
or
open
SSL
the
container
engine,
so
dr.
B
Roquette
contains
the
cryo,
etc,
and
also
we
are
like
remote
to
deployment
cube
ATM
and
the
cube
spray
native
one.
So
I
think
this
is
like.
Also
one
of
the
reason
is
very
different
from
any
other
insider,
but
so
many
things
is
look
nice
there,
but
in
practice
is
a
complete
mess
to
to
test
and
maintain.
So
all
of
these
like
translate
by
different
paths
in
the
code.
So
if
you
shoot
this
OS
we're
going
to
trigger
this
role,
if
you
should
continue
continuity,
we're
going
to
trigger
this
one
and
not
this
one.
B
So
you
can
think
there
is
like
a
lot
and
a
lot
of
pass
to
test.
Like
it's,
it's
not
mating
involved
at
this
point,
so
we
decided
to
review
all
this
option
and
and
try
to
clean
up
this,
because
this
last
goal
it's
even
complete
conflict
in
production.
Witness
if
we
contest
you
can
maintain
it.
We
can't
ensure
quality
of
releases.
B
So
we
have
an
issue
and
it's
still
open.
So
the
discussion
is
ongoing,
a
new
opinion
about
any
of
things
we
should
keep
just
joined
before
we
remove
them,
because
this
I
think
quite
important
decision
to
make
so
far.
We
agree
on
these
points
so
on
the
DNS,
but
we
have
caught
in
a
skew
business,
cube,
DNS,
DNS,
Marathi,
honest
your
and
we
decided
to
just
keep
the
last
one
just
caught
us
the
deployments.
B
B
Is
it
with
docker
continuity,
or
is
it
a
binary
with
a
system
D
like
there
is
immutable
things
we
not
sure
which
one
we're
going
to
pick,
but
we
sure
we
want
to
pick
only
one,
because
it
doesn't
make
sense
to
maintain
all
of
them
in
the
end
fodder
for
the
user.
You
don't
have
any
pro
tool
of
this
choice
and
set
management.
This
is
more
because
we
didn't
have
no
maintainer,
so
maybe
what
we
come
back,
but
for
now
we
have
been
remove
it
so
and
I
think
also.
B
This
is
not
something
especially
there
is
a
gem
coming
and
I
think
this
is
not
something
we
sure
this
is
something
we
should
work
with:
seacrest
a
life
cycle
and
not
inside
close
pray
for
the
operating
system.
For
the
network
plugin
for
the
cloud
provider,
we
decided
to
keep
them
all,
because
this
is
clearly
not
a
choice
of
the
maintainer
to
make.
A
B
It's
like
200
pass
and
with
some
improvement
in
the
CI
ii
ii
ii
just
correlate
things
together.
We
don't
need
to
end-to-end
test
everything,
just
like
the
OS
does
it
instil
where
with
kentucker
and
then
we
don't
need
to
test
for
all
installation,
but
even
if
we
test
all
this
is
like
much
more
clean
to
maintain
so
yeah
I
want
you
to
pause
on
that
because
at
some
question,
but
why
did
you
remove
out
why
we
have
less
choice?
A
So
this
year
in
review,
it
was
a
very
big
year
for
kid
spray,
most
notably
recently
we
release
version
2.8
and
in
2.8
we've
deprecated
the
cube,
ATM
deployment
method,
I'm,
sorry,
deprecated,
the
non
cutie
cube,
ATM
deployment
method
and
in
version
2,
9,
nan,
Katie,
cube
ATM
will
be
removed
entirely
point
out,
though
we
we
do
play
in
the
retain
support
for
upgrades
from
non
cube.
Atm-
and
you
know,
if
you
see
any
issues
with
that
or
anything,
and
you
have
anything
else
with
this
transition.
A
Please
please
report
it,
and
so
next
our
keep
spray
repo
moved
to
the
community
SIG's
github
project.
Community
SIG's
is
where
oh,
the
the
cig
own
projects
and
kubernetes
are
are
being
you
know
if
they're
new
they're
being
created
there
and
others
are
being
transitioned
through
there
slowly
over
time,
we
were
previously
in
coordinated
incubator
and
the
invader
program
was
retired.
Retired,
probably
you
know
so
almost
two
years
ago.
So
it's.
C
A
Decision-
and
you
know
we're
just
trying
to
say-
is
closely
aligned
with
seed
cluster
lifecycle,
as
we
can
anyway.
So
again,
if
you
see
issues
with
that,
you
know
any
broken
links
or
any
integrations
that
are
failed.
Please
report
we
added
variety:
new
network,
plugins,
psyllium,
cube,
router
and
multis.
A
We
also
mean
there's
only
three
here
on
this
list:
we've
implemented
tons
and
tons
of
nuclear
age
features
cuz,
you
know
you
and
the
greater
crewnecks
community
is
just
keep
killing
it
and
putting
out
you
know,
new
new
features
and
things
that
keep
spray
users
absolutely
need.
So
we've
continued
to
integrate
upon
security
policy.
Priority
classes,
I
know
kids
with
these
types
of
things
and
as
Antoine
was
mentioning,
we
moved
many
of
the
non
core
components,
some
add-ons
that
bring
them
not
use
much
and
we're
also
distracting
from
our
main
goal
of
production
readiness.
B
B
B
So
since
now
we
are
spoons
sponsor
officially
secret,
so
lifecycle
we're
going
to
work
more
closely
with
them
and
integrate
decision
major
so
and
also
the
CI.
So
one
of
the
idea
of
the
CI
a--
is
when
there
is
a
cube,
AGM
match,
let's
say,
or
every
two
hours
we're
going
to
ruin
this
new
key
body
and
release
also
master
branch.
We
skip
spray
and
say:
yes,
it's
still
working,
oh
no.
B
This
is
the
quality
of
Kabul
iam,
also
service
component
config,
bender
and
last
one.
It's
Satyam.
This
is
I,
think
still
a
cab
that
has
been
approved
by
the
sea.
It's
a
way
to
manage
and
deploy
at
city
a
little
bit
like
a
gem,
but
for
EDD.
So
as
soon
as
it's
available,
we're
going
also
to
replace
our
it's
installation
with.
B
So
the
last
great
next
is
decent
rest,
okay,
orchestration,
meaning
right
now
we
have
like
one
on
cyber
node
to
deploy
everywhere
every
time
we
need
to
do
an
upgrade.
We
go
back
and
do
again,
and
we
had
this
idea
from
the
beginning
that
at
some
point
is
maybe
not
required.
Let's
say
why
should
a
node
know
about
puzzle,
node,
can't
it
just
configure
itself,
can
he
just
upgrade
just
download
the
latest
epic
cube?
B
So
there
is
a
lot
of
thinking
around
that
I
think
we
are
quite
far,
but
we
really
want
to
tackle
this
because
it
enabled
automatically
read
or
at
least
very
easily
just
say:
oh
I
want
an
expression
and
just
wait.
It
will
make
it
much
much
faster
at
scale,
because
if
each
node
are
independent,
if
you
spin,
ten
node
or
thousand
node
will
be
the
same,
you
just
maybe
have
20
working
40,
but
you
don't
have
to
wait
for
the
thousand
work
to
end
the
script
and
same
for
auto
scaling.
B
If
it's
not
an
independent
unit
can
know,
if
you
are
on
the
cloud
configure
things
say,
oh
I
was
right
might
know
that
we
just
touch
this
cube
spray
container
or
still
need
to
be
determined.
Are
we
going
to
configure,
but
that's
the
main
main
ID
and
that's
probably
going
to
be
four
cubes
Freight
tree
because
see?
What's
going
all
we
be
able
to
switch
to
this
architecture
and
upgrading
from
previous
interested?
B
A
So,
who
here
uses
cube
spray
just
show
hands,
I'll,
very
cool,
so
cube
spray
is
used
by
you
know
pretty
much.
Every
sides
of
business,
startup,
small,
medium
large
enterprise
and
even
some
governments,
I
found
out
recently
it's
a
comment
option
because
it
does
work
in
so
many
different
scenarios,
different
types
of
infrastructure
and
with
composability
to
tailor
kubernetes
to
your
use
case.
A
It
supports
upgrades
another
great
reason
why
a
lot
of
people
pick
it
it's
easy
to
contribute
to
it's
another
strong
reason
to
my
opinion:
it's
why
we've
had
so
much
success
with
it
open
source
projects
you
just
keep
spray
for
for
their
CI
and
general
automation
and
there's
even
a
number
of
courageous
distribution,
vendors
that
build
products
on
top
of
cube
spray
and
use
it
to
and
further
cluster
installations
and
keeps
ready.
You
know
it's
a
completely
community
driven
project
project,
the
free
and
open
source
always
has
been
always
will
be.
A
A
We
had
three
hundred
and
nine
unique
contributors
that
actually
created
pull
requests.
I
think
now
we're
we're
around
ten
thousand
unique
visitors
per
week
to
the
key
to
a
repo
page
on
github.
Forty,
eight,
oh
seven
stars-
and
you
know
we're
frequently
the
despite
commits.
If
you
look
at
Deb
stats,
where,
within
the
top
two
most
active
repos,
usually
only
after
kubernetes
lash
kubernetes
it,
so
you
should
almost
always
within
the
top
five
and
we're
actually
competing
against
three
other
repos
that
are
mostly
just
commits
generated
by
bots.
A
So
it's
it's,
it's
a
very
active
and
wonderful
community.
So
we
are,
you
know
growing
fast.
Most
of
the
activity
of
so
half
of
a
more
than
half
the
activity
of
the
entire
over
the
entire
lifetime
of
the
project
was
in
the
past
six
month
was
very
strong
about
six
months.
Their
active
select
channels,
please
join
them,
and
there's
no
company
behind
keep
spray.
It's
it's
completely
community
driven
and
it
you
know,
I
always
will
be,
and
there's
no
single
entity
that
controls
that
it's,
the
community
and
I.
B
Think,
like
this
adoption
is
part
of
some
of
the
rescission,
like
it's
part
of
the
other
ton
of
communities
and
I.
Think
many
it's
the
same
issue
I.
It
is
still
like
three
years
later,
still
are
to
install
communities
and
Chris
pray
gave
this.
This
ability
to
manage
its
so
as
people
discover
communities
and
try
to
find
solution
to
install
it
in
manage
it
and.
A
A
A
C
A
It's
in
our
roadmap
there's
currently
an
ssh
provider
for
cluster
api
that
cube
spray
could
leverage
how
what
that's
going
to
look
like
will
be
interesting,
because
there's
some
overlap
with
some
of
the
other
providers
that
you
know
we
may
not
have
to
use
the
cube
spray
version
of
that
automation,
but
there
yet
we
definitely
plan
to
the
support
that
cuz
there's
just
a
ton
of
power.
If,
if
you
haven't
gone
to
a
talk
on
cluster
api,
I
would
highly
recommend
that.
B
D
B
The
on
the
CI,
we
do
end-to-end
tests,
so
we
actually
deploy
a
cluster
and
we
create
resources
right
now
on
Google
cloud,
so
it's
expensive.
So
the
process
is
someone
need
to
review
and
accept
this
to
be
a
test.
So
I
think
the
common
is
like
CI
check
this
from
one
of
the
maintainer
and
after
this
it
will
be
able
to
trigger
the
CRA.
So
with
no
one
have
been
this,
you
can
just
bring
any
of
the
maintainer
or
go
on
slack
and
on
this
date
and.