►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
CNCF Cross-Cloud CI Deep Dive – Denver Williams, Cloud Native Computing Foundation, & Taylor Carpenter, Vulk Coop (Intermediate Skill Level)
"About Denver
N/A
About Taylor
Partner at Vulk Cooperative - http://vulk.coop Co-Lead Cross-Cloud CI project - http://crosscloud.ci OpsDev geek. Elixir and Ruby programmer. Father, book devourer, dark beer lover. I think the concept of a delightful user experience should be applied to all parts of life including software libraries, developer tools, APIs, and web UIs in technology as well the onboarding experience for someone into in a new group. I'm passionate about communication between people, both direct and through the use of technology (eg. UX in software). I care about deeply about ways to improve our connections through methods such things as conflict resolution and Nonviolent Communication."
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
Gonna
be
looking
at
what
is
cross
cloud,
the
provisioner
itself,
the
goals
of
that
particular
component,
the
audience
that
we're
trying
to
target
give
a
little
live
demo
of
that
piece,
a
technology
overview
and
code
overview
that
will
go
into
the
github
code,
a
little
bit,
how
you
collaborate,
QA
and
maybe
a
little
bit
more
after.
So
what
is
it?
This
is
a
multi
cloud,
kubernetes
provisioner
and
it
deploys
vanilla.
B
A
A
C
So
where
we
are
right
now
is
we're
inside
a
docker
container,
so
I
can
jump
out
of
this
quickly,
and
this
is
the
git
repo
cross
cloud
and
then
here's
a
docker
file
that
we
use
to
produce
an
image
called
scenes
here
and
basically,
this
stock
around
is
going
to
pass
in
an
env
file
and
that
just
can
that
mainly
contains
cloud
secrets.
So
AWS
secrets,
google
cloud
secrets
and
then,
if
we
run
that
we
jump
in
here
and
this
directory
is
where
all
the
main
coders
and
at
the
top
here
you
have.
C
These
directories
matching
the
cloud
name
as
your
GCE
and
then
you
have
templates
down
the
bottom,
so
the
fault,
the
directories
that
have
the
cloud
name
there.
That's
the
cloud
resource
specifications
for
creating
the
virtual
machines
security
groups
and
then
the
templates
below
is
cloud
and
up
data.
So
every
cloud
provider
that
were
using
has
supports
cloud
known.
So
it
makes
sense
to
use
that
that
way.
We
have
this
agnostic
template
that
it
doesn't
matter
what
provider
or
on
we
just
feed
it
in
in
it
revisions
the
cluster
and
brings
it
up
for
us.
C
Here
we
have
this
input
file.
This
specifies
the
variables
of
watch
at
the
pod
site
ABI.
What
should
the
service
say
to
be
and
what
artifacts
are
we
using
here
right
now
we're
using
the
default
upstream,
one
team,
but
when
we're
leveraging
in
the
SAS
in
our
CI
system,
we
actually
override
these
with
binaries
we've
compiled
ourselves
so
and
there's
also
another
interesting
phone
here
called
modules
TF
and
this
basically
pulls
in
the
variables
in
that
input,
file
and
there's
different
sections.
So
there's
if
we
scroll
up
a
bit.
C
We
have
this
section
here
for
the
worker
templates
and
what
this
does
is.
It
goes
passes
in
those
variables
sango's.
What
cloud
provider
pod,
cider
and
the
output
of
this
module
is
cloud
net
data,
that's
being
rendered
to
configure
the
worker
node
and
there's
another
identical
scene
section
in
here
for
the
master
nodes
and
then
up
above
we
have
the
same:
wait
integral
sections
for
certificate
generation
and
actual
vm
creation.
C
We
looked
at
some
of
the
tools
that
were
already
out
there
like
cops,
for
example,
but
one
of
the
reasons
we
chose
not
to
use
cops
was
because
we
were
doing
this
for
the
use
case
of
a
CI
system,
which
means
that
we
wanted
to
be
able
to
have
these
immutable
artifacts,
that,
after
a
provision
at
run
and
we
tested
this
class,
so
we
could
bring
it
up
later,
where
with
cops,
it
generates
a
lot
of
data
on
the
fly.
So
it's
hard
to
go
back.
C
C
And
I'm
running
this
twice
because
there's
a
terraform
dependency
issue
that
we
have
with
a
cloud
provider
integration
at
the
moment,
which
means
it
tries
to
create
a
subnet
and
a
new
resource
out
that
before
it
actually
creates
it.
So
it
needs
to
be
run
twice.
But
if
you
specify
the
individual
resource
with
a
rapper,
then
it
doesn't
have
this
problem.
C
So
here
you
can
see
that
it
just
created
the
master
resource,
the
VMS
and
then
the
section
down
here
is
adding
etsy
records
and
the
reason
we're
doing
that
is
it's
allowing
us
to
generate
DNS
compatible
names
on
the
fly
based
on
the
resources
we
create.
So
that
way
we
can
generate
certificates
before
we
actually
have
the
VMS,
which
helps
a
lot
and
especially
when
you're
wanting
to
bring
up
artifacts
that
were
built
in
the
past
and
expect
them
to
still
work.
A
C
C
And
now
we
won't
have
any
notes
yet
because
we
need
to
actually
add
some.
Our
back
rolls
to
make
sure
our
worker
notes
can
actually
join,
and
in
this
we
have
an
API
server.
Cubelet
permission.
The
worker
notes,
cubelet
daemon
is
secured
with
our
rack
authorization,
and
then
we
also
have
TLS
bootstrapping
for
the
worker
notes.
So
we
can
actually
not
know
anything
about
the
worker
notes
and
actually
bring
them
up
and
have
them
securely.
Join
the
cluster.
C
And
in
very
shortly
this
should
join
in
the
ready
state
and
then
from
them
we
could
go
on
and
run
our
communities
conformance
tests,
which
we
do
on
our
CI
system
and
then
in
the
cluster
succeeds.
We
then
go
and
run
additional
testing
like
we'll
deploy
Prometheus
on
that
cluster
and
say
is
Prometheus
working.
A
So
that
was
allocating
the
resources
all
that
deploying
vanilla,
kubernetes
again,
that
would
pull
down
that
we
can
validate
with
test.
Maybe
we've
talked
about
pulling
information
from
test
grid
or
other
places
to
see.
Do
we
want
to
actually
do
this
then
run
our
own
test?
After
the
fact,
we
can
also
enable
specific
flags
or
plug
in
different
versions
of
components
that
go
with
kubernetes,
so
terraform,
as
we
just
saw
cloud
in
it
as
well.
A
This
passed
in
and
the
manifests
are
laid
down
for
the
vanilla,
kubernetes
and
that's
the
main
technology,
for
this
talked
a
little
bit
about
some
of
the
others,
cops
and
stuff,
and
I
think
I'll
just
hold
off
on
this,
and
maybe,
if
folks
have
specific
questions
on,
why
didn't
we
use
x,
then
we
can
get
into
that
in
the
QA.
Did
a
little
bit
of
the
code
walk
through
that's
over
here
again
and
the
cross-cut
CI
project,
the
cross,
clad
component
itself,
and
this
is
a
GCE
module
that
is
looking
at.
A
A
A
So
the
question
is:
am
as
a
end
user.
Would
you
recommend
using
the
cross
cloud
for
deploying
kubernetes
and
with
those
manifest
I
would
say
it
depends
on
the
use
case,
so
this
was
designed
based
on
CI
we're
not
doing
long-term
management
of
a
cluster
of
production
clusters
that
are
running
and
you're
wanting
to
push
updates
and
other
stuff
like
that,
it's
something
that
could
be
built
into
that
a
bit.
It
depends
on
your
use
case
and.
C
One
of
the
big
things
you'll
find
especially
with
tools
that
a
bit
that
are
designed
for
a
maintaining
production
great
clusters
is
that
they
support
your
upgrades
roll
backs,
and
this
is
from
the
perspective
of
we
bring
it
up
and
we
destroy
it.
We
bring
it
up
and
we
destroy
it.
We
not
trying
to
keep
it
around
and
it's
optimized
to
be.
Let's
bring
this
up
as
fast
as
fast
as
possible.
We
want
it
out
within
two
or
three
minutes
where
production
clusters
probably
come
up
a
little
bit
slower.
C
A
C
A
A
Okay,
so
the
question
was
more
on
goals
and
are
we
wanting
to
support
all
the
difference
service
providers
that
kubernetes
is
targeting
and
and
then
some
comments
about
the
test
coverage,
as
can
we
add
more
so
cross,
clad
CI?
The
project
has
goals
for
supporting
a
lot
of
different
testing,
including
profiles,
so
we
could
say
we're
doing
large
clusters
or
storage
specific
pieces,
and
we
we
do
a
lot
of
that.
We've
deploy
applications
as
part
of
the
cross
flat
CI,
so
we'll
deploy
own
app
and
then
run
it's
end
to
end
test.
A
A
The
goals
are
definitely
to
be
a
complement
to
those
type
of
production,
deploys
and
keep
it
as
slim
as
possible
to
fit
in
us
like
a
component
that
you
could
say,
we
run
this
and
we
can
do
a
large
set
of
coverage
and
then
for
our
when
it
hits
production.
If
you
need
it,
we
do
a
very
specific
where
it
runs
like
a
two
day
or
one
week,
long
running
test,
that's
going
to
be
a
different
type
of
setup.
A
Let's
see
did
I
did
I
get
all
this
yet
so
that
right
now,
the
I
far
as
like,
covering
all
of
those
providers,
we're
not
actively
trying
to
do
it,
I
guess
as
a
project
but
we're
open
to
it.
We've
had
a
lot
of
feedback
of
adding
cloud
providers
and
stuff
that
aren't
supported
by
anything
else,
and
so
OpenStack
was
added.
A
Ninety-Eight
percent
just
done
outside
and
we
have
Oracle
coming
up
similar,
so
that
support
would
be.
We
want
to
make
it
easy
for
anyone
else
to
add
support
and
use
it
for
use.
Cases
like
I
think
test-driven
deployments
is
a
great
way
to
look
at
that.
We're
not
gonna,
say
we're
gonna
just
cover
it
all
I
think
it's
it's
fitting
that
middle
ground
and
really
focused
on
end
users
that
are
not
going
to
say,
give
me
service
provider.
Just
give
me
this
I'm
going
to
trust
this.
A
Whatever
you
have
I'm
going
to
make
it
work
on
one
service
provider
or
two
service
provider.
This
is
really
looking
at
end
users
that
want
their
own
thing
and
they
need
to
say
I
can
understand
it
at
this
base
level
and
then
build
on
that
and
those
type
of
users,
something
simpler.
That's
community
maintained
where
the
terraform
site,
so
they
can
handle
all
of
the
provisioning
and
see
how
kubernetes
is
installed.
It
works
really
well
for
that
and
at
even
if
you
want
to
add
new
modules.
A
So
you
say
we
have
our
own
our
own
cloud
and
maybe
it's
you
know
open
sac
based,
so
you
could
say:
I'm
gonna
fork
this
and
we're
going
to
put
all
the
specific
things
we
need
like
to
get
into
this
private
VPN.
Whatever
you
could
do
that
sort
of
thing
real
easy
from
here,
expand
on
that
and
then
you
would
tie
back
in
to
all
of
the
testing
that's
happening
in
kubernetes
and
I.
Think
you
had
a
question.
A
A
Yes,
the
OpenStack
and
the
I
think
I
think
if
I
heard
right,
the
question
was
about
adding
other
hardware
support
or
OpenStack
on
other,
your
own
private,
okay,
right,
private,
open
sack,
lesser
yes,
so
it's
I
think
using
this
public
one,
which
is
a
public
OpenStack
hosting
provider.
It's
a
pretty
standard
stack
and
going
through
here
and
looking
what
that
is.
It
may
fit
immediately
or
it
may
be
something
where
it
would
be
extended
a
little
bit
thanks
any
other
questions.
C
So
this
dashboard
shows
the
component
we
were
just
talking
about,
makes
up
this
Cuban.
It
is
right
here-
and
we
have
this
section
here-
the
built
status
and
what
this
is
is
the
status
of.
Could
we
compile
communities
from
source
for
the
Associated
release?
Here
we
have
v1
10,
and
this
actually
goes
to
the
git
command
that
is
last
made,
and
then
we
can
click
here,
and
this
will
actually
take
us
to
the
console
out
of
the
build
and
we
can
scroll
down,
and
we
can
see
that
we
did.
C
So
here
we
have
the
build
and
we
use
build
released
at
Shell
and
that
runs
through
compiles
the
Cuban,
eighties
binaries
and
then
packages
them
as
Dockers
containers.
And
we
create
this
a
release
file
which
points
to
the
artifact
and
it's
stored
under
job
under
the
job
ID
and
has
a
path.
And
this
is
where,
in
that
input
file.
I
can
actually
go
to
there
and.
C
In
this
section
down
here,
Cuba
artifact
keep
API
severe
artifact
controller
manager,
scheduler
and
proxy.
These
are
just
defaults
and
basically,
when
that
releasing
V
file
is
sourced,
it
overrides
these
with
the
versions
that
we
built,
and
then
it
runs
across
to
these
stages,
where
we
actually
run
that
provisioning
I
run
before
and
before,
and
it
goes
for
provisions.
The
cloud.
C
Resources
and
then
down
the
bottom.
We
have
the
cluster
coming
up
ready
and
then
we
install
home,
which
we
can
then
use
to
create
other
projects
on
or
deploy
the
conformance
tests
and
run
through
those
and
report
the
results
back
somewhere
and
then
the
next
section
we
go
through
once
those
are
up,
as
we
start
deploying
these
other
projects
on
top
of
those
clusters,
I'm
running
their
upstream
tests
that
are
available.
C
So,
for
example,
we've
got
own
app
down
here
and
if
we
run
through
this
job,
we
can
see
that
we
deployed,
and
now
it's
running
through
their
CD
shell,
which
waits
for
the
project
to
come
up
with
an
own
app
takes
a
long
time
to
come
up
because
there's
a
lot
of
moving
parts
and
when
it
does
come
up,
it
runs
through
there
into
in
tests.
And
here
we
see
that
it
passed
that
section
and
the
job
succeeded.
And
then
we
get
return
to
success
status
on
the
dashboard.
A
So,
behind
behind
this,
the
dashboard
is
a
API
server
status
repositories.
What
we
call
it
and
that
pulls
the
data
from
the
different
CI
systems
in
the
backend
and
can
both
pull
and
push
have
in
fit
into
it.
And
then
you
can
pull
the
data
which
is
pulled
on
to
this
dashboard.
The
dashboard
configurable
can
show
different
projects,
and
the
information
available
on
the
screen,
of
course,
is
going
to
be
not
you're,
not
gonna,
be
able
to
display
as
much
as
what
you
can
have
in
the
status
repository
right
now.
A
This
is
the
hoops
right
now.
This
is
the
overview
screen
and
we
have
some
other
screens
like
mocked
and
stuff
for
doing
project
screens,
we're
wanting
to
gather
some
more
feedback
on
this
before
we
move
forward
at
this
point,
but
we
may
end
up
with
a
provisioning
specific
screen.
That's
just
about
cue
brunette
ease
and
may
have
stuff
like
rook
and
some
other
pieces
that
are
just
on
that
layer
versus
things
that
will
run
on
kubernetes
and
don't
care
what
provider
and
what
the
underlying
infrastructure
is.
A
A
We
may
be
pulling
directly
from
test
grid,
we're
talking
with
Aaron
and
some
other
books
about
going
and
saying,
here's
a
new
release
and
here's
some
test
info
and
then
potentially
saying
here's
a
check
mark.
It
passed
all
the
tests,
grit,
here's
what
we
ran
and
what
it
passed
there
and
you
could
gather
all
that
sort
of
info.
We're
gonna
continue
collaborate
there
and.
A
Yes,
absolutely
so
cross
clad
CI
project
is
we're
trying
to
make
it
where
it
could
be
used
for
any
project,
and
the
original
target
was
try
to
support
as
many
of
the
CN
CF
projects
has
made
sense
and
then
Linux
Foundation.
So
this
would
be
the
first
Linux
Foundation
project
we're
trying
to
make
it
available
and
useful
for
anyone
outside.
A
So
whether
that's
the
specific
thing
like
cross
cloud,
which
is
for
provisioning
or
if
you're
interested
in
using
the
whole
CI
system,
the
dashboard,
what
cloud
providers
you
specify
that
you
want
to
use
is
configurable
what
projects
are
there?
That's
all
configurable.
It
could
be
used
for
anything.
This
dashboard
is
specific
to
San
CF
own
app,
though
specific
so
own
app.
This
was
kind
of
a
starter
how
to
get
going
with
them.
A
If
we
support
it,
it
looks
like
we
will
and
if
we
continue
to
support
more
an
app
they,
they
may
end
up
with
their
own
dashboard,
because
there's
so
many
components
and
that
right
now
we're
using
the
service
Orchestrator
as
kind
of
a
test
for
here's,
how
it
could
work.
They've
been
working
to
get
everything
on
kubernetes
hitting
all
of
their
install
stuff
and
getting
it
all.
The
helm.
A
Charts
have
been
a
target,
in
fact
worth
like
a
forked
version
that
we
keep
updating,
but
this
is
service
Orchestrator
component,
the
firm
own
app
and
the
different
little
pieces.
Logging
database
and
some
other
parts
that
are
required
to
run
run
that
so
it's
not
doing
like
full
tests
with
devices
or
anything
else
for
own
app.
Yet.
C
And
cross
squad
CI,
there's
you'll,
see,
there's
these
repositories
called
Cordy
and
esque
configuration
and
there's
Q
Benitez
configuration.
These
are
the
declaration
for
building
the
projects
from
sauce.
So
please
say
a
look
at
the
Cuban,
a
ds1
and
in
this
repository
here
is
the
dot
gate
lab
caml
file.
We
actually
had
a
head
a
bit
of
a
battle
with
the
gate
lab
with
this
one,
because
get
lab
expects
this
yellow
file
to
be
in
the
repository
to
do
the
CI
pipeline,
but
we
want
to
use
the
commits
from
upstream.
C
C
C
So
here
we
do
some
choosing
here
based
on
which
configuration
to
choose
based
on
our
environment.
We
have
dev
and
staging
environments
as
well,
and
then
we
have
our
compiled.
So
this
goes
for
sits
some
registry
variables
installs
dependencies
that
we
need
to
build
communities
from
source
and
then
we
run
on
151
build
release
which
goes
for
compiles
communities,
and
then
we
have
64
that
specifies
that
we
should
store
what
we
just
built
as
artifacts.
C
C
A
Think
your
other
question
as
far
as
adding
new
projects,
so
the
configuration,
if
you,
if
you
have
a
access
to
the
repo,
you
could
add
a
get
lab
CI
mo
or
as
far
as-
and
this
is
the
runner
get
lab,
we're
actually
looking
to
support
different
type
of
runner
workers.
Anything
that
could
have
the
configuration
to
run
those
and
the
actual
deployment
of
Apps
is
part
of
the
cross
project.
D
A
A
Nope,
okay,
so
there's
we're
part
of
the
CI
working
group
and
that's
once
once
monthly.
At
this
point,
there's
a
mailing
list
there's
also
on
the
CNCs
slack,
there's
a
cross
cloud
or
CN
CF
CI
and
some
other
channels
that,
were
there
github
Twitter
love
to
have
some
feedback.
We're
going
to
be
working
on
that
API.