►
From YouTube: It wasn’t DNS. We checked! Infra CICD with KubeVirt and Tekton -Cansu Kavili Oernek & Tyler Auerbeck
Description
It wasn’t DNS. We checked! Infra CICD with KubeVirt and Tekton - Cansu Kavili Oernek & Tyler Auerbeck, Red Hat
Speakers: Tyler Auerbeck, Cansu Kavili Oernek
You must have heard of this very famous haiku: It’s not DNS There is no way it’s DNS It was DNS Unfortunately, it was, cause we forgot about that change... We know that testing infra components can be hard. It's not cheap to have or maintain test environments or sometimes access to these systems is highly restricted. Also, we often don’t let our infrastructure codebase benefit from CICD practices as our app codebase does, even though it is getting more and more complex each day. But the good news is, with tools like KubeVirt and Tekton, we can rely on a common platform to test our infra-related deployments and changes (DNS, networking, ansible roles..) safely before pushing things straight to prod! And of course, that common platform is K8s! During this talk, we’ll cover how to orchestrate the testing and deployment of the changes safely on OpenShift by using Tekton and KubeVirt.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
B
Yeah,
sorry
about
it,
but
it
will
be
taking
a
second
okay
pipeline
finished.
Everything
is
green.
Just
just.
Let
me
check
if
I
can
see
this
page
and
maybe
it
will
take
more
than
a
minute.
I'm
sorry
just
give
me
a
sec.
I
I
don't
really
understand,
but
but
exactly
everything
is
green
and
that
line
is
fine.
Fists.
A
A
A
B
A
A
All
right
and
welcome
back
to
the
show
everybody.
This
is,
of
course,
as
you
just
heard,
it
wasn't
dns
we
checked
ci
cd
for
your
infrastructure
with
hubert
and
tekton.
I
am
tyler
arvik
and
with
me
today,
we've
got
my
good
friend
chansu
a
little
bit
about
myself,
real,
quick,
I'm
an
architect
at
red
hat,
open
innovation,
labs,
focusing
on
site,
reliability,
engineering
and,
as
you
can
guess,
bringing
reliability
to
to
not
just
our
applications
but
all
of
our
infrastructure
as
well.
A
B
B
So
let's
see
what
just
happened
as
a
patient
techie
in
order
to
make
my
application
work
or
my
new
shiny
future
work,
I
did
a
couple
of
changes
right.
I
had
a
couple
of
changes
in
my
source
code
and
I
also
did
some
changes
and
other
stuff,
and
I
pushed
my
changes
to
the
source
code
report,
which
triggered
the
pipeline
to
build
my
code
to
test
my
code,
to
check
my
code
quality
and
to
deploy
my
application
in
china
environments.
B
B
Recovery,
enhanced,
test,
reliability,
better
quality,
a
lot,
and
so
I
was
living
the
good
life
by
knowing
that,
if
anything
wrong,
my
pipeline
would
catch
it
and
wouldn't
allow
me
to
deploy
my
stuff
to
production,
because
ci
city
basically
is
here
to
save
me
from
myself
right
and
my
pipeline
didn't
smoke.
Actually
I
mean
it
checked
my
collar
it.
It
saw
that
nothing
is
wrong.
It
was
all
green.
Everything
was
fine,
but
still
something
didn't
something.
A
And
that
is
why
we're
here
to
talk
to
you
today,
it's
great
to
capture
all
of
these
all
of
our
application
bits
right.
You
know
it's
good
to
test
all.
You
know
that
all
the
the
pieces
are
working
together,
but
what
about
the
lonely
old
infrastructure
you
know
rocking
around
in
the
back
end,
never
gets
enough
love.
It's
always.
Oh.
We
need
to
make
that
change.
Okay,
someone
log
into
the
ui
and
make
that
change
or
hey.
Maybe
we
have
that
in
a
bash
script
somewhere
yeah
you
go
and
run
the
bash
script.
A
That's
that's
how
we've
always
done
it
right.
You
know
you
know
it
always
comes
to
and
then
comes
to
great
deployment.
All
of
your
all
of
your
tests,
all
of
your
ci
cd
for
your
app
runs,
but
then
it's
time
for
the
deployment
it's
time
to
go
to
to
go
out
into
the
world
and
everything
gets
deployed
just
like.
A
A
Great,
this
should
be
going
great.
Why
isn't
it
going
great?
Oh,
no,
it's
not
going
great,
and
then
you
start
flipping
tables,
and
you
know
cursing
all
over
the
place,
and
you
know
we
don't
want
to
live
in
this
world
anymore
right.
This
is
why
we
can't
have
nice
things.
If
we're
not
treating
you
know,
having
a
reliable
application
is
only
half
the
battle,
you
can
have
a
reliable
application
that
runs
on
its
own.
A
It
none
of
that
matters.
The
application
is
only
half
the
battle.
If,
if
you
can't
rely
on
the
underlying
infrastructure,
none
of
this
is
worth
it.
You
can
drive
a
car
you,
you
can't
drive
a
fast
fast
if
the
car
has
no
wheels
right,
that's
kind
of
one
of
the
things
I
always
like
to
say.
We
should
be
able
to
lean
on
these
processes.
We've,
like,
like
johnson,
said,
we've
been
doing
this
for
years
with
applications.
Now
you
know
whether
it's
you
know
with
our
own
fancy
tools,
or
you
know.
A
A
B
Well
as
everything-
and
this
is
also
a
process
and
there's
going
to
need
to
be
a
little
bit
of
investment
here,
but
ideally
the
important
thing
is
that
here
we
can
lean
on
platforms
that
are
like
lightly
already
running,
rather
than
having
to
figure
out
how
to
interact
with
all
these
different
apis.
All
these
different
infrastructure
components.
In
order
to
just
do
our
testing,
we
can
rely
on
our
good
old
body
kubernetes
api
in
here,
and
this
is
super
exciting.
B
This
is
this
is
really
great,
because,
by
being
able
to
rely
on
a
common
platform
just
to
replicate
our
infrastructure
components,
it's
it's
really
reduced
overhead
of
having
to
maintain
all
these
different
tools,
different
numerous
code
bases,
but
I'm
talking
about
infrastructure
components
which
heavily
based
on
virtual
machines,
and
how
are
we
gonna
do
that
right?
We
would
like
to
rely
on
this
kubernetes
api
and
it
sounds
like
possible
now,
tyler.
Is
it.
A
Yes,
absolutely
a
good
old
friend,
cuber
right
here.
You
know,
I
don't
I
didn't,
have
a
tech
concert,
so
I'm
one
queue
for
sure
today.
You
know
it's.
It's
now
possible,
like,
like
trunks,
said
to
use
that
common
ape.
You
know
that
core
api
server
to
to
describe
everything
in
a
similar
format,
and
yes
that
comes
down
it's
yaml.
We
may
not
like
it,
but
we
may
not
like
it,
but
we
come
to
to
love
it
and
just
accept
it
into
our
lives
right
and
with
cubert.
A
You
know
just
like
we,
we
define
our
applications,
we're
now
able
to
plot
to
define
our
our
virtual
machines
in
the
same
way.
In
that
same,
you
know
we
we
can
it
and
it's
it's
kind
of
an
ecosystem
of
tools.
You
know
there's
kind
of
the
core
cube
verb,
which
you
know
spins
up
the
virtual
machines,
but
there's
also
a
bunch
of
tools.
Now
that
allow
you
to
define
your
own
gold
image
so,
rather
than
just
like
pulling
a
container.
A
Off
of
fedora
or
red
hat,
or
you
know,
whatever
you
know,
operating
system,
you
want
to
use
for
your
virtual
machine.
You
can
literally
take
the
thing
that
is
running
on
your
virtual
machines
and
bring
it
right
into
into
kubernetes,
bring
it
into
openshift
and
run
it
right
there.
So
it's
not
just.
Oh.
Let
me
run
something
that
looks.
B
A
A
So
it's
it's
not
running
something
that
looks
like
a
vm,
it's
running
a
vm
inside
of
openshift,
and
this
has
become
one
of
my
favorite
tools
to
to
create
what
I
like
to
call
ghost
systems
things
that
are
exactly
what
I
am
running
out
here
in
virtual
land
without
having
to
kind
of
take
up
a
bunch
of
bare
metal
machines
or
or
resources.
On
my
on
my
my
hypervisor
things
like
that,
it's
hey,
I'm
already
running
tests
so
likely
I'm
already
running
tests
over
here
in
my
kubernetes
platform.
Now
let
me
bring
all
these.
B
B
So,
instead
of
this
kind
of
engine,
tecton
introduced
bunch
of
custom
custom
resource
definitions
into
the
cluster.
I
need
to
use
all
these
custom
resource
definitions
like
building
blocks
which
you'll
see
in
a
demo,
but
before
the
demo.
Let
me
just
let
me
just
confuse
you
a
little
bit
so
in
tecton
there
are
steps
and
steps.
B
So
it
may
sound
complicated,
but
it
concrete
representations
of
all
these
blocks
as
declarative
configuration
technology
creates
a
standard
platform.
In
the
same
way,
your
kubernetes
provides
for
your
application
deployments
like
we
said
in
the
clipboard.
This
prevents
us
to
reinvent
the
wheel
and
and
use
and
rely
on
what
we
already
have
in
our
hands.
A
A
It
sounds
like
a
lot
of
moving
pieces
right,
but
the
nice
thing
is
that
now
we
don't
have
these
things
that
are
kind
of
interdependent
in
one
pipeline.
It's
not
going
to
impact
the
other.
It's
all
about
you
know
these
things
are
kind
of
off
in
their
own,
their
their
kind
of
name,
space
they're
off
in
their
own
world.
A
As
long
as
you
don't
kind
of
give
them
too
much
permission,
of
course,
but
it's
all
about
making
sure
we're
running
things
in
environments
that
aren't
impacting
each
other
there's
no
dependencies
kind
of
cross
pipeline
where
well.
This
thing
needs
to
be
this
version,
and
that
needs
to
be
this
version.
It's.
B
A
A
To
take
a
and
take
a
look
at
our
repo
here
and
I'll
try
not
to
I,
I
examine
anyone
here
with
our
with
all
of
our
yaml,
but
just
just
like
everything
else,
we
you
know
we
want
to.
We
want
to
test
our
code.
We
want
to
test
multiple
things
about
our
code.
We
don't
want
to
just
test
that
this
thing
deploys.
We
want
to
test
that.
You
know,
let's,
let's
try
to
save
ourselves
as
much
time
as
possible.
A
Let's
you
know,
make
sure
let's
learn
things:
let's
lint
our
infrastructure's
code,
let's
deploy
the
things
we
want
so
you'll
see
here
in
we
we've
got
our
techton
repo,
which
will
contain
the
tasks
and
pipelines
that
the
chunks
we
talked
about.
We've
got
our
back
because
hey
we
want
to.
We
want
to
run
this
every
single
time
and
we
want
to
make
sure
nothing
gets
left
behind.
So
it'll.
A
Back
and
the
name,
space
and
pipeline
service
account
things
of
that
nature,
and
then
we've
got
cnb,
which
stands
for
our
virtualization
and
in
there
we've
got
just
just
a
handful
of
things
that
we
want
to
run
so
we've
got,
you
know,
ansible,
we
we've
got
our
persistent
volume
claims.
So
that's
what
ansible
and
shared
data
is
fedora
is
our
is
our
virtual
machine
and
our
echo
deployment
is
just
going
to
be
a
silly
just.
B
A
Dummy
app
that
we
can
use
to
test
things
out
once
we
have
our
dns
up
and
running
so
from
there.
We've
then
got
the
actual
ansible.
That
runs
because
you
know
we
want
to
test
that.
Hey
does
dns
spin
up
like
we,
we
expect
it
to
or
does
it
not
because
sometimes
it
does
not
and-
and
you
know
really
just
running
running
ansible-
to
stand
up
the
dns
server
and
and
things
like
that.
A
One
thing
we
will
call
out
because
spinning
vms
up
in
in
our
openshift
platform,
especially
kind
of
the
smaller
cluster
that
we're
running
in
or
you
know
or
your
kubernetes
platform,
it
runs
the
same
regardless.
But
one
thing
I
can
tell
you
is
regardless
of
where
you
run:
it
takes
a
little
bit
of
time.
A
So
if
you
take
a
look
at
our
pipeline
and
we'll
provide
the
repository
where
all
the
slips,
so
you
can
play
around
with
it
on
your
own,
is
that
we've
commented
out
a
lot
of
things
because
we're
going
to
do
a
little
baking
baking
show
today.
Where
look
we
put
this
thing
in
the
oven?
Look,
it's
already
ready
to
come
out.
So
you
can
see
we
commented
out
for
time
where
the
actual
creation
of
the
virtual
machine
is
happening
and
we're
not
waiting
for
things
and
we're
just
you
know.
A
Basically
all
of
that
is
because
I've
already
got
a
virtual
machine
already
stood
up.
So
all
that's
happening
inside
of
our
our
pipeline
is
that
we're
checking
out
our
code
just
like
you
would
any
other
time,
because
we
need
our
code
to
work
with.
We
pull
down
our
infrastructure's
code.
We
lint
our
ansible
to
make
sure
that
there's
no,
you
know
terrible
terrible
issues.
A
That
is
where
we've
been
say:
hey.
Does
that
look
all
good?
Let's
spin
up
our
virtual
machine
make
sure
it's
it's
healthy
and
then
we'll
run
our
ansible
so
from
there
you
can
see
that
we,
this
is
kind
of
like
a
little
hacky,
where
we're
doing
this.
We're
we're
in
the
process
of
making
some
some
nice
shiny,
formal
steps
that
we're
going
to
submit
upstream.
A
A
So
you
can
actually
see
things
happening
traditionally
like
like
johnson
mentioned,
there's
a
bunch
of
moving
parts
with
with
techcon
we
would.
You
would
really
want
to
use
something
like
triggers
that
way.
I
I
submit
a
pull
request.
It
kicks
off.
You
know
it
kicks
something
off
in
in
techcon,
where
I
have
to
start
running.
My
pipeline
pipeline
report
status
back
out,
so
we'll
go
ahead
and
kick
this
off.
A
You
can
see
I'm
specifying
what
what
volume
claims
to
run,
what
service
account
to
run
as
and
go
ahead
and
run
that,
and
it
tells
me
hey.
You
want
to
look
at
your
logs
go
ahead
and
look
at
our
logs
as
this
is
running,
so
far's
up
starts,
checking
out
our
code
and
the
nice
thing,
and
one
warning
I
tell
you
all-
is
don't
ignore
your
pipeline
logs.
Just
because
something
green
is
green,
now
doesn't
mean
it
will
remain
green.
Sometimes
it
tells
you
hey,
there's
a
warning.
A
You
should
take
a
look
at
this
because
there's
not
there's
there's
smoke,
there's
not
fire
yet
so
you
don't
you're
not
like
oh
it's
broken,
but
smoke
means
there
will
be
fire.
So
deal
with
it,
so
you
can
see
things
like
warnings
and
deprecation
warnings.
So
where
do
the
wise
always
pay
attention
to
your
pipeline?
Mods.
A
A
A
A
Why?
Because
we
fixed
the
error
that
that
chonsu
had
shown
us
at
the
beginning.
You
know
we
we
no
more
no
more
kind
of
typo
and
things
because
we're
keeping
all
of
this
as
code
now
right,
just
like
just
like
we
had
before
you
know
we
check
in
the
change
it's
going
to
show
us
the
change,
and
you
know
as
long
as
we
see
that
everything
runs
well
in
here.
We
can
feel
comfortable
that
when
it
gets
pushed
to
the
real
servers,
it
will
be
what
what
it
looks
like.
A
B
A
A
I
can
start
building
out
all
my
apps
and
I
can
have
a
true
integration
test
for
my
entire
production
environment
and
I
can
all
I
can
shove
that
all
into
it
a
kubernetes
cluster
test,
it
out
feel
comfortable
that
everything's
in
place
when
I'm
making
these
large
changes,
maybe
you're,
maybe
you're,
just
completely
yanking
out.
You
know
your
switches,
maybe
you're,
switching
from
one
vendor
to
another
hey.
I
want
to
see
what
this
looks
like
when
I
throw
this
thing.
A
Well,
if
they
give
you,
if
they
give
you
an
appropriate
image,
just
slap
it
right
slap
it
right.
In
I
mean
we,
we've
seen
other
kind
of
talks
like
this,
where,
where
folks
have
hey
they've
done,
a
completely
virtual
network
change
saw
that
it
worked
fine
and
then
they
went
and
bought
the
equipment
like
you.
B
B
A
B
But
now
it's
quite
stable
in
my
point
of
view,
but
this
shouldn't
be
intimidate
you
and-
and
this
is
you,
should
you
sh
you
should
you
can
find
a
lot
of
now?
The
examples
around
these?
Are
it's
actually
there's
a
there's.
A
project
under
cupid
called
copper,
tecton
test.
So
all
all
these
tasks
that
you
just
show
and
more
around
it
like
how
to
add
ssh
key
into
those
virtual
machines,
etc.
B
You
can
find
those
tactile
tests
so
just
and
since
that
everything
is
on
top
of
your
kubernetes
cluster
and
everything
is
escort
and
it's
easy
to
get
a
sandbox
environment.
On
top
of
these
clusters,
you
can
keep
playing
and
keep
trying
and
keep
learning,
and
so
don't
just
don't
just
think
that
oh
this
takes
a
lot
of
time
to
spin
up
or
there's
something
wrong
or
well.
How
can
I
get
this
information
from
payload
or
things
like
that?
It
will
be
great,
but
why
you
make
it
make
it
run
the
fields.
A
It's
it's
just
it's
the
same
feeling
you
get
with
your
application
pipelines
when
they
run
oh
yeah,
they
ran.
Now
you
get
a
double
now
you
get
to
get
it
with
your
infrastructure
as
well
and
you're
right.
This
is.
It
is
a
these
are
two
very
large
projects
and
there's
a
lot
to
kind
of
rock
and
kind
of
get
your
head
around.
But
once.
A
It's
good
and
the
best
part
about
this
is
you
know
there
are
tons
of
docs
out
there
that
you
know
sometimes
you're
like.
I
don't
need
to
read
that
I
can
make
this
work
and
then
you,
like
bang
your
head
against
keyboard
for
a
little
bit.
Trust
us
read
the
docs.
The
dots
are
great.
The
community
is
great.
Ask
questions.
A
A
I
needed
to
specify
hey
run.
This
is
my
pipeline
essay,
because,
if
I
didn't
it
wasn't
going
to
have
access
to
the
persistent
volume
claims
it
wasn't
going
to
have
access
to
to
the
virtual
machines,
because
it's
a
you
know
the
crd
that
doesn't
naturally
have
access
to
things
in
that
in
that
name,
space
so
remember
always
check
permissions.
I
lost
an.
B
Another
thing
that
I
can,
I
think
we
try
to
find
a
find
that
worker
out
is
that
the,
since
everything
is
an
bronzing
container
that
runs
the
spot
and
intact
on
that.
Also
every
single
task
has
their
own
code.
It's
kind
of
hard
to
share
information
between
these
posts,
like
the
steps
of
one
task.
In
order
to
in
order
to
share
the
information
from
last
test,
you
need
to
rewrite
many
stories.
B
If
you
would
like
to
use
that,
if
you
would
like
to
use
that
kind
of
information
or
results
between
the
tests-
and
that's
you-
you
don't
always
get
to
rewrite
many
stories
easily.
So
there
are
some
creative
ways
around
this.
You
can
find
it
easily
on
the
on
github.
You
can
see
that
so
don't
worry.
If
you
don't.
A
A
Well
that
wraps
it
up
for
us
today.
Hopefully,
this
is
is,
is
useful,
is
beneficial.
Of
course,
you
know
this
is
kind
of
like
a
dummy
demo
thing,
but
we
think
this
could
definitely
be
useful
in
the
real
world.
We
hope
to
see
more
people
using
it
like
this,
and
if
you
have
any
questions,
you
know,
of
course
feel
free
to
reach
out
to
us
directly.
A
B
A
That's
good,
so
thanks
for
watching
everyone,
I
think
we
have
a
few
minutes
here
for
a
quick,
quick
questions.
I
see
one
over
there
in
the
q,
a
if
you
have
more
feel
free
to
drop
them
over
there,
but
question
from
adam
was
speaking
of
dns:
can
processes
inside
a
cubert
machine
access
in
cluster
services
via
their
in
cluster
dns?
Name?
Yes,
absolutely,
and
that's
that's
exactly
how
we
interacted
with
some
of
the
services
we
were
using
as
part
of
that
pipeline,
but
then
we
also.
A
Container
running
that
we
gave
an
actual
like
non-cluster,
dns
name,
which
was
where
you
saw
things
initially
break
there,
and
it
was
just
me
titling
the
wrong
thing,
but
yeah
yeah
you
can
from
a
from
a
cube
vm.
It
has
access
to
everything,
that's
running
in
the
cluster
and
you
should
be
able
to
access
it
just
like
here.
You
know
just
like
anything.