►
From YouTube: KinD-ly Validating Your K8s Apps Automatically Per PR - Sarah Khalife & Grant Griffiths
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
KinD-ly Validating Your K8s Apps Automatically Per PR - Sarah Khalife, GitHub & Grant Griffiths, Portworx
Kubernetes application developers working on successful projects thrive on collaboration that is transparent, consistent, and rigorous. This is one of the reasons many open source projects excel. However, a common pitfall that app developers face is manually testing against inconsistent environments. Testing k8s application correctness can differ per developer environment. It is also very time consuming to spin up and down k8s clusters. In this talk, we will demonstrate a simple set of steps to create and automate a homogenous testing environment for your application. We will be using KinD, a tool for running Kubernetes in Docker, and CI to automatically run e2e tests across a common environment for a k8s application. To maintain consistency, we will automate the creation of this environment per pull request and run the test suite before deploying to production.
https://sched.co/Zele
A
A
To
give
you
a
little
background
about
myself,
I'm
a
field
solutions
engineer.
I'm
I've
been
at
github
for
11
months
now
previously
I
was
a
cloud
apps
and
platform
engineer
at
ge,
where
I
worked
on
microservices
kubernetes
and
cloud
foundry.
Today,
I'm
focusing
on
intersource
automation
and
improving
the
software
development
lifecycle
for
fun.
I
enjoy
volleyball
traveling
and
the
beach.
B
A
A
All
right,
let's
jump
into
our
agenda,
so
today
we'll
give
you
a
quick
overview.
What
our
motivations
are,
what
our
challenges
are
we'll
go
into.
Why
kinds
jump
into
our
automation
and
continuous
integration?
Conversations
give
you
a
quick
overview
of
what
we'll
be
testing
we'll.
Do
a
live
demo
right
after
that
and
then
talk
about
our
takeaways.
A
So,
let's
start
off
with
our
overview.
So
what
why
did
we?
Why
did
we
want
to
do
this
talk?
Well,
we
wanted
to
be
able
to
collaborate
successfully
in
both
internal
and
open
source
projects.
We
had
some
challenges.
What
were
those
challenges?
Well,
collaborating
needs
to
be
transparent,
consistent
and
rigorous
testing
kubernetes
applications
varies
varies
all
the
time
between
per
developer
environment.
It
can
vary
against
the
different
configurations
that
you
have
when
set
up
for
your
environments
and
it's
time
and
resource
consuming
to
constantly
spin
up
kubernetes
applications
and
kubernetes
clusters.
B
As
you
know,
this
conference
was
supposed
to
be
in
amsterdam.
So
try
to
keep
the
theme
going
strong,
so
yeah
we're
going
to
talk
about
kind
now,
so
kind
is
basically
kubernetes
and
docker.
It's
similar
in
usage
to
meaning
something
like
mini
cube
or
k3s.
Basically,
a
different
disk
of
of
k3s
of
sorry
kubernetes,
it's
great
for
local
testing
or
testing
even
remotely
in
ci
cd.
B
And
if
you
want
to
learn
more,
you
can
go
to
kind.sigs.k
s,
dot,
io
yeah!
All
you
need
is
docker
and
you
can
spin
up
your
own
kubernetes
cluster,
so
yeah.
How
do
you
actually
do
this?
So,
if
you're
on
a
mac
or
if
you
have
brew
installed,
all
you
need
to
do
is
to
brew,
install
kind
and
then
kind
create
cluster.
So
it's
extremely
easy
to
get
started,
probably
the
lowest
barrier
of
entry
tool
to
kind
of
spin
up
your
own
container
scheduler.
Ever
it's
very
awesome
and
a
really
cool
tool
to
use.
B
So
just
a
quick
comparison,
you
might
be
using
another
tool
out
there,
maybe
k3s
or
mini
cube.
So
I
pulled
up
a
quick
comparison
here
chart
from
this
blog
post.
We
found
and
basically
compares
all
the
different
miniature
versions
of
kubernetes,
pretty
much
so,
for
example,
there's
a
mini
cube
that
that
actually
requires
the
vm,
but
it's
a
single
node
kubernetes
itself.
They
didn't
change
any
of
the
kubernetes
code.
That's
the
main
difference
between
k3s
and
mini
cube.
K3S
is
actually
a
slimmed
down
version
of
kubernetes.
B
They
actually
pulled
out
things
like
the
the
volume
drivers.
You
can
only
use
csi
and
they
pulled
out
some
other
things
that
are
deprecated
to
basically
lower
the
binary
size
so
that
it's
very
quick
and
a
minimal
version
of
kubernetes
and
kind.
As
we
mentioned,
it's
quick
easy
to
deploy
low
barrier
entry
and
great
for
testing.
A
So,
let's
jump
into
our
automation
and
our
continuous
integration
today
will
be
we
have
today.
We
have
a
couple
of
goals
that
we
wanted
to
achieve
when
we
ran
our
tests,
so
the
first
goal
is
to
run
our
validation
test
on
new
code
changes
that
helps
us
reduce
the
amount
of
bugs
and
validate
before
it
hits
production
want
to
block
merge
to
production
if
tests
have
failed.
A
You
also
want
to
set
up
a
pre-configured
environment
when
testing
this
helps
you
allow
to
systematically
this
helps
you.
This
allows
you
to
systematically
catch
problems
with
your
application
with
your
application
logic,
and
it
helps
you
maintain
consistency
across
the
results
that
you
receive
from
your
tests.
A
Automate
everything
with
event
triggers
that
increases
the
frequency
of
your
test
runs
that
makes
it
more
repeatable
and
generally
more
efficient.
You
don't
want
to
spin
up
a
test
if
it's
just
a
simple
code
fix
on
a
readme,
but
you
want
to
spin
up
a
test
when
it's
a
pull
request
against
your
production
code.
A
All
of
that
is
great,
but
what's
also
top
of
mind,
even
from
an
individual
developer
point
of
view
or
from
a
enterprise
point
of
view
from
our
organization
point
of
view
is
resource
is
costa.
Sorry,
it
is
the
cost
efficiency
of
using
up
resources,
and
you
don't
want
to
reinvent
the
wheel
if
somebody
has
already
worked
on
something
similar.
A
So
what
do
you
think
about
when
you
do
that
open
source,
open
source
comes
into
mind
into
my
mind,
all
the
time,
especially
because
90
of
today's
software
is
composed
of
open
source
software
you're
using
dependencies
you're
using
scripts
that
people
have
worked
on.
So
with
that
in
mind,
what
did
we
do
next?
Well,
we
found
an
open
source
action
that
spins
up
kubernetes,
spins
up
kind
and
darker
for
us
sorry
kind
in
kubernetes
and
docker
for
us.
So
with
that
we
were
able
to
find
a
pre-existing
action.
A
A
After
that
we
spin
up
our
kind
creation,
our
kind
cluster
creation,
our
kubernetes
testing-
that's
great,
but
I
also
said
that
the
kind
action
was
configurable
second
test
against
a
kubernetes
version.
Well,
we
use
a
matrix
build
to
actually
test
against
three
different
kubernetes
versions,
because
I
want
my
application
to
be
able
to
run
across
all
of
these
and
be
compatible
once
we
have
all
of
the
tests
passing
and
we're
confident
that
this
is
not
going
to
break
any
of
our
production
code.
That's
when
we
decide
to
merge.
B
B
But
there
are
some.
There
are
some
reasons
as
to
why
you
might
not
want
to
actually
use
integration
tests.
It
can
be
very
resource
and
time
intensive
or
basically
unit
tests
can
cover
a
lot
of
business
logic.
You
don't
need
to
spend
three
or
four
hours
running
all
of
your
unit
tests
within
against
against
an
actual
kubernetes
cluster,
because
that
would
be
way
too
time-consuming
and
not
very
smart
use
of
infrastructure.
B
So
an
example
of
out
there
you
can
actually
see
for
yourself
is
being
used
in
production.
Is
the
kubernetes
side
team
has
something
called
csi
release
tools,
just
a
repo
that
has
all
the
release
tools,
basically,
that
we
use
to
to
basically
test
all
the
different
repositories
for
kubernetes
csi
and
inside
of
there
is
something
called
pow.sh
and
what
it
does
is.
It
creates
a
kind
cluster.
It
deploys
a
sample
of
csi
driver
and
its
side,
cars,
so
basically
it's
dependencies,
and
then
it
runs
some
tests
against
them.
So
basically
it's
an
example.
B
The
kubernetes
team
itself
actually
uses
to
do
development
and
what
we
did
actually
for
our
example
today
is
we
did
something
similar.
We
basically
started
a
works,
e2e
tests,
a
regular
works,
so
it's
a
project
that
I
work
on
in
a
is
something
called.
Pork
security
basically
prevents
users
unauthenticated
users
from
accessing
the
platform,
so
you
basically
can't
create
a
volume
or
mount
the
volume.
B
If
you
don't
have,
if
you
don't
have
the
correct
token
secret,
so
that's
kind
of
the
test
we're
going
to
be
going
over
and
we'll
be
testing
using
the
porix
csi
driver,
which
basically
is
a
driver
that
allows
you
to
create
storage,
storage
volumes,
so
yeah
and
open
storage.
Just
so
we're
clear
is
the
open
source
control
plane
for
portworx?
So
it's
basically
all
of
the
code
that
basically
handles
like
all
the
different
control
plane
components.
B
It
doesn't
have
the
actual
storage
layer,
so
yeah,
let's
go
into
our
e2e
test,
so
basically
the
first
step
you'll
see
and
actually,
when
we
talk
about
the
demo,
this
is
the
same
scenario
that
we're
going
to
demo.
So
basically,
the
first
step
is
to
create
a
kind
cluster
and
inside
of
that
kind.
Cluster
we're
going
to
have
a
cube
system
space
and
then
a
user
space
as
well.
B
And
then,
what
we're
going
to
do
is
deploy
the
forex
csi
driver,
that's
going
to
be
in
the
cube
system,
space
and
all
of
its
dependencies
will
be
there
as
well.
Next
we're
going
to
create
a
token
secret.
This
basically,
is
basically
your
password
and
it's
basically,
the
the
token
that's
required
in
order
to
authenticate
with
poll
works.
B
B
B
So
what
we're
going
to
do
is
we're
basically
going
to
open
a
a
little
pr
inside
of
this
pr,
we're
just
going
to
change
really
quickly
and
basically
do
change
from
debug
f
to
info
ref,
not
the
biggest
change
in
the
world,
but
for
a
demo,
it's
nice
and
then
what
we're
going
to
actually
do
is
we're
going
to
notice
that
the
test
is
failing,
because
I've
manually
set
the
token
secret
to
be
invalid
and
then
so.
What
happens?
B
Actually
as
a
result
is
that
the
tests
here
are
failing,
as
you
can
see,
so
it's
preventing
merging
from
happening
because
we
have
protected
branch
which
sarah's
going
to
talk
about
in
a
little
bit.
So
basically,
what
we
do
is
we
can
bring
up
this
test
and
we
can
look
inside
and
we
can
see.
Oh,
what
happens
so
run
test
failed.
B
B
However,
the
pvc
was
not
bound
after
15
seconds,
so
basically,
poll
works
wasn't
able
to
create
the
volume,
and
it
said
who
is
this
person
trying
to
create
a
volume,
because
you
don't
have
the
correct
token,
so
I'm
not
going
to
let
you
create
a
token,
create
a
volume.
So
that's
the
reason
for
the
test.
Failing
so
let's
go
ahead
and
actually
fix
that
live
right
now,
so
what
we're
going
to
do
is
inside
of
here.
We
can
actually
just
edit
this.
A
Awesome
and
then,
let's
jump
into
a
quick
overview
of
what
that
will
look
like
it.
Just
kicked
off
our
build
test
here
and
we
can
see
that
it's
building,
running,
building
and
running
our
docker
image
builds
so
now
that
we
are
seeing
this
in
action,
let's
jump
into
the
actual
yaml,
so
we
can
talk
through
that
here
we
have
our
e
with
kind
yaml
file.
This
is
our
automated
workflow,
as
grant
mentioned,
we're
only
running
this
on
pull
request
and
specifically
on
pull
request
master.
The
point.
A
The
reason
is
around
this:
is
we
don't
want
to
run
our
end-to-end
testing
every
time?
There's
a
push
or
a
small
change.
We
actually
want
to
run
it
only
in
pull
request,
because
that
will
be
the
time
where
new
new
code
is
being
introduced
into
a
master
branch,
in
this
case
we're
using
our
master
branch
as
our
production
branch.
So
we
don't
want
to
merge
any
code
that
hasn't
passed
into
any
testing
in
the
first
place.
A
So
now
that
we
have
our
trigger
here,
let's
jump
into
our
different
jobs,
so
our
jobs
here
we
have
two
main
jobs,
our
build
and
our
test
job.
In
reality,
what
we
first,
what
we
have
learned
trying
to
achieve
this
overall
workflow
is
that
we
originally
had
our
build
and
test
job
only
in
a
single
job,
so
it
did
builds
and
tests
all
in
once,
all
at
once.
What
that
really
did
not
that
why
that
really
did
not
work
is
because
the
testing
and
the
build
jobs
had
two
functionalities.
A
The
the
reason
for
the
build
job
was
to
run
and
sorry
run
up,
make
docker
build
osd
and
that
on
ultimately
builds
our
image
and
then
pushes
it
to
quay
in
our
second.
In
our
second
job,
we
actually
have
our
full-blown
integration
testing
running
with
kind,
spinning
up
the
cluster
and
running
our
test
scripts.
We
split
these
up
in
the
first
place,
because
our
kind
cluster
creation
and
our
tests
are
going
to
be
run
against
three
different
kubernetes
version.
A
But
when
we
build
our
our
image,
we
only
need
to
build
it
on
a
single
on
a
single
version.
So
we're
running
ubuntu
latest
for
both
of
these,
but
we
did
not
need
to
spin
up
a
docker,
sorry
different
kubernetes
version
to
run
our
build
job,
but
let's
jump
into
our
test
job.
So
you
can
see
what
we
mean.
A
So
we
have
our
test
job.
We
said
that
our
test
job
needs
our
build
job,
because
our
build
job
runs
and
validates
our
content
and
then
pushes
the
image
to
a
dtr
docker
trusted
registry
registry
to
quay
or
to
get
her
packages
wherever
you
want
to
store
it.
But
in
this
case
we
the
test
job,
needs
the
build
job
and
similarly
to
above
we're
running
in
ubuntu.
A
A
As
you
see
here,
this
is
similar
to
what
we
showed
in
the
powerpoint,
but
this
has
the
configuration
that
I
mentioned
we're
using
this
open
source
action
and
configuring
it
with
our
specific
use
cases.
So
we
named
our
cluster
name,
we
had
our
cluster
name,
we
set
up
our
yamo
and
we
are
testing
against
the
different
kubernetes
versions.
Using
the
matrix
build
with
that
matrix,
build
in
mind.
We
then
set
it
up
correctly
to
spin
up
all
of
our
applications,
and
then
we
have
our
test
being
run
in
this
case
here.
A
So
now
that
we've
seen
all
of
that,
let's
go
into
a
quick,
a
quick
overview
of
what
the
branch
protections
rules
look
like.
So
here
we
have
our
master
branch.
This
is
the
name
pattern
that
you
couldn't
decide
on
how
you
want
to
configure
it
in
this
case
we
call
it
master,
but
you
can
have
a
prod.
You
can
have
release,
you
can
call
it
main.
A
So
in
this
case
I'm
requiring
a
pull
request
review
before
merging.
So
I'm
only
requiring
one
reviewer
most
of
the
times
you
probably
want
to
have
a
code
owner,
that's
more
knowledgeable
of
the
code,
changes
that
are
happening
and
we're
also
requiring
a
couple
status
checks.
So
in
this
case
we're
running
the
build
job,
so
that's
also
required,
and
then
we
also
have
our
three
test
jobs
running
against
the
three
different
kubernetes
versions.
The
reason
why
this
is
important
is
because
again
we
are
compatible.
A
A
Sweet,
so
we
just
ran
a
couple
of
our
components.
We
see
our
setup
kind
job
spun
up.
We
have
our
start:
open,
storage,
job,
oh
sorry,
start
open
storage,
step,
also
running
and
now
we're
running
our
environment
checks.
So
great,
do
you
want
to
talk
a
little
bit
about
the
different
checks
that
we're
running
through.
B
B
Next,
what
we're
doing
actually
is
we're
checking
to
see
if
the
environment
is
set
up.
This
is
important
because
you
can't
run
the
test
until
you've
ensured
that
basically,
the
environment
is
set
up,
or
else
it
basically
won't
ever
run.
So
what
actually
is
happening
live
now,
as
you
can
see,
is
that
the
containers
are
spinning
up.
B
B
Now
we're
basically
yeah
test
passed
luckily
and
then
live
demos
are
always
nervous
nervous,
but
yeah
test
passed,
it's
all
good
and
yeah,
so
everything
looks
good.
So
what
we
did
is
we
introduced
that
fix
and
it
fixed
everything,
and
now
the
test
is
passing
and,
as
you
can
see,
if
you
go
back
to
the
pr
and
refresh
you
can
see
that
all
of
the
tests
have
passed.
We
just
need
to
get
someone
to
review
this
pull
request
before
we
can
merge
it,
but
that's
for
another
day.
A
B
A
A
So,
let's
jump
into
sorry,
let's
jump
back
to
our
slides.
So
let's
talk
about
our
takeaways
here.
So
what
did
we
learn
today?
Normal
manual
work,
you
can
decide
on
the
events
that
you
want
to
trigger
your
automated
workflows
with
deciding
what
type
of
events
make
best
make
sense
for
your
that
suit,
the
job
that
you
need
to
run.
So
in
this
case
I
have
two
examples.
Should
I
run
this
test
on
every
push
to
main,
or
should
I
run
it
on
a
specific
push
domain?
A
In
this
case,
I
decided
to
only
run
it
against
our
branch,
our
main
branch,
and
only
our
on
our
pull
request
to
our
main
branch
as
well.
When
should
I
deploy
to
my
my
app
to
gke?
Well,
I
don't
want
to
deploy
it
every
time.
Somebody
makes
a
push.
I
don't
want
to
deploy
it
every
time.
Somebody
creates
a
pull
request
in
this
case.
I
only
want
to
deploy
it
when
I
create
a
release
and
and
that's
how
you
can
show
it,
and
this
is
similar
way.
A
A
So
next,
up
after
we
decided
what
our
trigger
was,
let's
decide.
Let's
talk
about
our
workflow,
our
workflow
here
talks.
These
are
two
examples
of
our
workflow.
I
need
to
build
my
docker
image
and
push
a
dtr.
That's
one
workflow
and
then
the
other
workflow
was
our
kind
workflow.
I
want
to
set
up
kind
spin
up
and
run
it
run.
My
test
against
that
and
I
need
docker,
builds
to
be
successful
beforehand,
just
to
make
sure
that
all
the
images
that
we're
pulling
are
the
latest
code.
A
We
also
decided
to
set
up
branch
protections
in
these
branch
protections
we
decided.
Oh,
we
need
a
code
reviewer,
we
need
to
have
status
checks
and
we
also
disabled
force
push.
We
do
not
want
any
time.
We
don't
want
any
anybody
to
erase
any
commits
accidentally
when
they
do
a
force
push
into
our
master
branch.
A
So
let's
do
a
quick
recap.
Our
dev
introduced
some
new
code
and
created
a
pr,
so
that
was
an
event
trigger
using
the
pull
request
events.
Then
we
kicked
off
our
first
build
job
following
up
with
our
kind
of
cluster
creation
job
and
with
that
second
job,
we
actually
had
a
matrix,
build
that
had
three
parallel
jobs
to
test
against
all
kubernetes
versions.
And
finally,
we
had
branch
protection
rules
already
set
where
you
can
only
merge
your
branch.
A
So
lessons
learned
what
were
the
lessons
learned
break
down
the
build
job
and
the
kind
jobs
into
two
separate
ones
that
made
that
made
it
much
easier
to
have
a
cleaner
workflow
and
to
have
different
configurations
for
each
of
those
jobs
triggering
end-to-end
testing
on
only
pr's
to
the
master
branch?
You
don't
need
to
have
end-to-end
testing
on
every
single
push
unless
that
pushes
the
master
use
matrix,
builds
to
run
your
tests
to
validate
against
multiple
kubernetes
versions.
A
Well,
in
this
case,
we
had
our
application
running
against
three
different
kubernetes
versions
to
make
sure
it's
compatible
across
all
three
and
lastly,
test
against
the
same
image
in
all
your
workflows.
If
you
are
building
a
brand
new
image
during
your
workflow,
then
you
should
use
that
exact
same
image.
You
shouldn't
have
to
build
it
every
single
time.
You
don't
need
to
use
a
pre-existing
one.
A
A
Having
the
concurrent
testing
with
the
same
automation,
script
made
your
life
as
a
developer,
a
little
easier
because
you
don't
have
to
write
another
automation
script
and
it
spun
up
everything
based
on
our
existing
configuration
and
at
the
end
of
the
day,
you
always
want
to
save
time
and
resources.
You
don't
want
to
reinvent
the
wheel.
You
don't
want
to
talk
about.
A
Creating
something
from
scratch
when
somebody
else
has
already
done
that
job
for
you
and
if
it's
open
source
you
can
just
use
the
open
source
projects
and
leverage
them
for
your
use
case,
you
can
contribute
back
when
you
find
a
bug,
you
can
contribute
back
if
you
want
to
enhance
that
open
source
project
at
the
end
of
the
day,
it's
up
to
you
as
a
developer
to
decide.
You
know,
what's
the
best
solution
that
I
need
to
achieve,
and
this
is
the
and
you
can,
and
how
can
I
do
that
in
an
automated
way?
A
In
addition,
using
you
can
use
a
docker
registry
quay
packages
or
whatever
you
want
to
manage
your
docker
images
with
and
pull
from
that
image,
because
you
want
it
to
always
be
auditable
and
you
can
refer
back
to
it
if
a
change
did
happen
and
you
want-
and
there
was
a
breaking
configuration
change,
you
can
always
refer
back
to
it
and
analyze
that
and
use
that
image
in
your
following
and
your
following
tests.
So
with
that
I'll
pass
it
off.
Oh
yeah.
B
B
Okay,
so
yeah,
let's
we're
just
going
to
go
through
some
of
the
questions
that
we
have
in
the
platform.
So
let's
see
the
first
one,
how
you
wrote
the
test
to
create
storage
class.
I
actually
answered
this
and
you
can
actually
check
the
actual
github
code
itself.
So
just
github.com,
open,
storage
and
all
the
code
is
in
the
demo
folder
there.
You
can
see
the
link
in
the
q
a
section.
A
Awesome
so
I'll
be
answering
alexander's
question:
do
you
suggest
to
launch
this
per
on
the
cicd
pipeline
on
each
commit,
or
only
on
pr
or
a
specific
branch?
In
this
case,
we
are
only
running
it
on
pr
to
our
master
branch,
we're
not
running
in
on
each
commit.
Since
it's
end-to-end
testing,
we
figured
it's
not
necessary
because
it
will
use
it
too.
Many
resources.
B
A
B
The
answer
is
it
can
be
both
if
you
would
like,
if
your
integration
test
may
involve
application
logic
and
yeah,
you
could
totally
test
both
with
this
method.
This
method,
basically
just
shows
you
how
you
could
spin
up
a
cluster
and
run
any
set
of
tests.
It's
up
to
you
what
you
want
to
test
with
this.
B
A
Yeah
you
can,
you
can
delete
it.
You
don't
have
to.
You,
can
just
put
a
new
image
with
a
new
version
number
that
is
based
on
the
commit
or
hash
code
that
you're
using
or
shop
code
that
you're
using
in
this
case
deleting
it
will
save
you
some
resources.
So,
yes,
you
can
clean
it
up
afterwards.
If
you
want
to
refer
back
to
it
and
understand
why
it
failed,
you
can
always
pull
that.
Keep
that
image
there
and
pull
it
locally.
So
then
you
can
run
your
own
tests
locally.
B
Yeah
the
next
one
is:
can
this
pattern
be
used
to
test
and
validate
kubernetes
animals?
Yes,
definitely,
that's,
probably
the
most
useful
one
of
the
most
useful
use
cases
is
actually
interacting
with
kubernetes
through
these
tests,
because
you
can't
really
do
that
easily
through
unit
tests.
It's
just
not
natural
to
do
it
that
way
so
yeah,
you
could
totally
do
this.
B
A
A
B
Yep
so
another
quick
question:
can
I
get
the
github
link
of
the
demo?
Please
yeah,
we'll
I'll
answer
the
I'll
answer
with
the
link
there
in
a
second,
but
it's
basically
yeah.
It's
also
in
one
of
the
other,
the
other
answers
but
I'll
send
you
the
link
in
a
second
question
on
kinds:
are
we
using
self-hosted
gha
running
on
kubernetes
pods?
Will
I
be
able
to
create
the
kinds
in
pod
kind
of
using
the
self-hosted
gdha,
not
sure
what
the
question
is
asking
you
know.
A
B
It's
github.com
yeah,
it's
s,
github.com,
it's
s,
k,
h,
a
l,
I
f
e
slash,
open
storage,
one
word
and
inside
of
there
you'll
see
a
demo
folder
and
I'll
send
that
in
the
answer
for
the
q
a
there
as
well
cool,
so
yeah,
it
looks
like
there's
a
couple
more
questions,
but
unfortunately
we're
going
to
have
to
end
here
again.
Both
of
us
are
available
on
the
cncf
slack.
So
let
us
know
if
you
have
any
questions
there.
Do
you
want
to
what's
your
handle
on
the
cncf
slack.