►
From YouTube: CNCF CI Working Group Meeting - 2018-02-27
Description
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
B
B
B
We
want
to
go
over
the
current
own
app
integration,
sort,
we're
working
with
the
o
net
project,
which
is
a
Linux
Foundation
project
to
integrate
with
their
CI
systems
and
do
some
testing
of
their
service
Orchestrator
component,
eventually
adding
more.
And
so
the
current
goal
for
the
initial
integration
is
testing
one
component
and
whatever
the
minimal
requirements
are
for
that
we'll
be
trying
to
use
the
upstream
artifacts
that
they've
provided
from
their
their
build
system
and
their
registry
and
then
try
to
deploy
on
top
of
kubernetes
and
run
e
to
e
test.
B
C
A
C
B
Great
so
cross
cloud
system,
the
cross-cut
CI
system,
it's
split
into
three
main
parts,
build,
builds
cloud,
provisioning
and
then
app
deployment,
which
does
the
EDA
testing
and
all
of
these
parts
can
be
used
independently.
B
So
for
systems
that
projects
that
don't
have
their
own
build
system,
we
can
I'm
going
to
kind
of
skip
down
in
here.
These
slides
will
be
available
for
a
further
overview.
Let's
see,
I
think
I
went
too
far.
So
on
the
build
system
itself,
I
can
bring
this
up,
see
yeah,
see,
I,
get
lambent
CSCI
the
build
system,
we
can
mirror
and
the
project's
source
code
and
do
builds
and
compiles
so
for
sake
or
DNS.
B
We're
just
running
the
upstream,
build
scripts
make
or
whatever
it
may
be,
depending
on
it
and
then
creating
those
artifacts
and
pushing
them
up,
and
then
once
we
have
those
we'll
do
we'll
be
using
our
own
provisioning
for
kubernetes
and
we
provision
the
different
clouds
and
then
once
we
have
those
we'll
take
the
artifacts
from
the
builds
on
each
project
and
deploy
those
and
deploy
potentially
an
EDD
test
container
or
whatever.
We
need
to
do
to
run
the
EDD
test
so
for
own
app
itself.
Let
me
go
to
a
different
environment
here.
B
B
They
have
a
nexus
for
their
registry
container
registry
and
some
other
items
and
for
the
stable
release.
What
we
have
here,
v1
one,
which
is
what
they
call
Amsterdam
we
can
their
releases,
are
not
too
frequent,
so
we
actually
can
specify
those
like
we
do
for
all
the
other
ones
and
say
there's
a
new
release.
It's
going
to
go
and
check
that
that's
available
in
the
registry
make
sure
its
downloadable
to
the
system
externally
and
does
some
validation
so
that
we
can
use
that
artifact
in
later
stages,
for
the
weave
has
a
problem
here.
B
Maybe
check
that
out.
So,
for
the
let's
see
it
looks
like
there
is
a
when
it
went
out
for
the
nightly
release
is
what
they
have,
so
they
have
nightly
builds
of
their
master,
and
what
we're
doing
here
is
we're
actually
going
and
looking
at
those
nightly
builds
on
Jenkins
and
we
check
the
status,
who
actually
had
a
failure.
It's
showing
that
there
was
a
failure
on
their
last
nightly,
so
this
is
whatever
they
were
in
yesterday
and
we
can
see
we
tied
that
into
their
commits
for
their
the
service
Orchestrator
project.
B
Here,
it's
just
a
mirror
of
Gerrit,
which
is
what
these
internally
and
they
had
some
errors
here
and
that's
what
caused
the
build.
So
we're
not
running
the
build,
but
we're
trying
to
do
is
integrate
with
whatever
they're
doing
so
that
we
can
update
here.
If
it
does
pass
we're
going
to
set
all
those
success
and
then
we
continue
on
and
validate
the
container
that
we
figure
out
dynamically.
What
container
did
they
create
based
on
this,
and
then
they
registered
that
into
there?
B
Are
they
uploaded
that
to
the
registry
and
we'll
make
sure
that's
available,
and
then
we
create
all
of
our
pinning
configuration
for
both
of
the
releases
that
we
can
then
use
for
app
deployments
and
run
those
deploys
of
the
containers
once
that
is
complete,
then
we're
ready
to
do
the
ete
test
and
that's
part
of
the
app
deployment
phase.
So
if
we
in
these
pipelines
here,
oh
I,
just
clicked
in
there
online
come
back
so
I
felt
like
it's
a
linker
day,
there's
an
app
deploy
and
that
didn't
work
what's
happening
here.
Denver.
B
Let
me
know
if
I'm
going
to
the
wrong
area
looking
at
some
live
stuff
here,
okay,
so
the
app
deploy
phase
in
this
stage
we
actually
run,
but
we
run
the
actual
deployment
using
helm
to
put
the
application
on
kubernetes
and
then
by
default.
What
we're
running
is
will
deploy
a
e
to
e
container
and
then
run
those
tests
that
are
within
the
the
a
te
container
for
own
app.
B
They
actually
have-
and
this
isn't
something
to
show
you
because
we're
in
the
midst
of
doing
this,
but
they
have
their
own
test
framework
and
they
use
something
called
robot
and
have
a
large
set
of
test
robots,
a
piece
of
software
that
allows
you
to
define
test
and
you
can
split
those
out
into
different
files
if
you're
familiar
to
cucumber
and
r-spec,
it's
it's
similar
to
other
things,
except
for
it
at
kind
of
a
higher
higher
level
defining
the
test.
And
then
you
go
in
and
implement
this.
B
So
we're
going
to
be
utilizing
those
for
our
tests
and
we're
doing
a
subset
of
those
tests
that
are
just
specific
to
onap.
So
once
we
get
done
with
the
app
deploy
for
the
different
releases
will
be
focused
on
the
the
actual
e
to
e
test
and
running
those
containers
and
hopefully
not
having
to
do
much
modification.
B
B
Kind
of
split
these
out,
but
if
anyone's
interested
to
come
and
look
as
the
progress
goes
so
from
a
poor,
DNS
perspective,
this
project,
the
own
app
integration
that
we're
doing
is
quite
a
bit
more
complex,
I
think
than
what
we
were
looking
at
for
poor,
DNS
and
I.
Think
if
we
look
at
what
we're
doing
for
own
app
is
kind
of
a
reference,
we
could
probably
go
with
something
even
simpler
if
we
can
define
it
sounds
like
we
have
the
three
different
areas
and
that
we
could
test
so.
A
B
B
So
we're
gonna
after
finishing
or
I
should
say
besides
the
oneth
integration
that
we're
working
on
and
currently
that
deployments,
we
will
be
enabling
IBM
cloud
and
soon
and
then
OpenStack
is
we're
hoping
to
have
that
up
soon
after
we're
collaborating
with
one
of
the
OpenStack
folks
to
get
that
integration.
Affluent
D
is
in
testing,
so
that
should
go
active
pretty
soon.
B
C
C
C
So
if
you
go
yes
in
accordion
s,
so
when
each
time
we
make
a
commit,
there
is
a
CI
that
start
and
that
one
kind
of
test
that
are
defined
in
this
repository,
but
we
have
also,
if
you
click
on
code,
E
and
s,
we
have
accordion
s
CI,
which
was
a
jury
that
run
a
bunch
of
tests.
We
did
not
want
it
to
put
inside
directly
inside
our
code.
If
you
go
to
no
sorry
to
deterred
Kotian
sei.
C
Here
you
are
in
coordinates,
flash
coordinates
or
yes,
that's
here.
Oh
yes,
very
glad
this
one!
Yes,
so
these
are
a
branch
of
test,
not
that
we
are
running
that
we
we
have
a
specific
of
your
mom
packet.
Are
you
to
run
this
integration
tests
that
are
mostly
not
not
only
but
mostly
testing
the
interface
between
Korean,
Air's
and
kubernetes,
but
it
is
something
that
is
a
side
of
the
regular
Travis
CI.
C
C
What
happened
s
core
DNS
is
going
as
the
default
DNS
service
of
kubernetes
cárdenas
itself
is
is
a
DNS
service
that
is
not
linked
at
the
beginning
to
kubernetes,
but
it
has
kind
of
plug-in
for
kubernetes
and
we
are
very,
as
you
say,
that
very
attentive
to
make
it
work
with
communities
so
that
why
we
have
deployed
a
specific
CI
and
then
we
will.
We
want
to
extend
this
CI
to
have
some
long
run
test.
C
Some
performance
tests
so
I
try
to
know
to
not
overlap
with
your
work
or
to
consolidate
with
your
work
so
because
you
are
deploying
in
several
in
in
you
are
already
deploying
on
several
type
of
container
or
server
platform.
I
would
like
to
take
advantage
of
this
deployment
to
make
run
our
CI
into
your
environment
or
your
deployed
already
deployed
environment.
So
my
question
is:
how
do
we
tie
together.
B
B
A
C
B
A
B
C
B
C
A
C
You
build
and
and
run
in
an
existing
environment.
So
it's
not
exactly
how
you
are
doing.
You
are
doing
a
deployment
of
communities,
I,
understand
all
deployment
of
something
and
then
run
the
test,
but
I
don't
know
we
are
open
to
find
what
what
what
is
the
best
tool
to
to
keep
on
your
organization.
But
what
I
want
to
know
is
how,
where
do
I
write
some
tests
to
make
them
run
in
your
environment,
for
example,
at
first
and
then
can
we
share
this
one?
C
A
C
This
document
read
the
my
ticket
and
then
I
will
you
can
either
add
to
to
the
when
you're
ready,
just
say
it
on
the
issue
on
cars?
Sorry,
the
cost
cloud
issue,
CI
issue,
23
and
I-
will
we
will
schedule
a
meeting
who
is
also
Chris?
However,
this
guy
here
that
did
this
all
this
work
he's
working
with
me.
Okay,.
B
Sounds
good
so
in
general,
how
the
test
work
our
will
track.
We
will
figure
out
what
we
need
to
run.
So
if
you
had
something
as
simple
as
make
test
there,
if
you
had
a
task
runner
of
some
type,
then
we
would
add
that
to
the
deployment.
So
during
the
app
deploy
we
would
have
a
job
that
starts
and
it's
the
only
thing
it
would
run
would
be
say,
make
test
or
make
e2e
test
or
if
there's
a
script
that
we
run.
That's
fine.
B
Essentially
we
need
to
know
how
do
you
run
your
tests
and
then
we
add
those
tasks
into
that
that
face
so
I
was
shown
earlier,
the
pipeline's
here
so
right
here.
So
when
we
get
to
after
this
f2
ploy
and
we're
going
to
run
this
e
to
e
test
job,
we
will
define
that
job
based
on
whatever
information
that
you
have.
So
if
that.
C
B
Go
back
here
so
if
what
what
I
would
anticipate
is
whatever
runs
whenever
you
add
this
slash
integration
in
the
comment
for
the
PR
that
in
triggering
some
set
of
commands,
it
seems
like
that
might
be
a
good
place
to
start
whatever
command
this
triggers
to
run.
So
that's
probably
in
here
somewhere
this
test
deployment
of
test
kubernetes.
So
there's
probably
yeah.
Let's
see
like
this
test
kubernetes,
so
we
probably
don't
need
this
fetch
core
DNS.
So
there's
some
other
things
build
docker
that
we're
handling.
B
B
So
it's
it
looks
like
we'd
package
up
this
test
and
then
we
would
want
our
job
to
then
run
the
make
test
or
make
test
skates,
and
that
should
be
a
good
starting
place,
that's
kind
of
what
I'm
thinking,
but
that's
generally,
what
we'll
do
we'll
figure
out?
What
is
the
project?
Currently
do
for
a
t-test
if
anything
and
then
try
to
run
those,
as
is
so.
If
that
works.
That's
fine
and
the
thing
concerns
that
I've
have
or
what
are
the
requirements
for
this
to
run?
B
Does
it
expect
for
the
for
the
cordeen
s
to
be
set
up
in
a
certain
way
and
I
see
some
stuff
on
the?
This
is
the
repo
here,
but
if
we
looked
at
okay,
the
build,
so
is
there
anything
specific
for
Cordy
Ness
that
we
need
to
know
when
we're
deploying
Cordy
mess
should
anything
be
started
up,
but
I
think
this
is
a
good
start.
We
can
take
a
look
at
running.
Go
tests
from
this
repo
on
our
kubernetes
to
play
with.
According
us.
C
B
So
we're
gonna,
deploy
by
the
container
they
a
container
that
has
core
DNS
and
whatever
containers
are
needed
for
to
run
the
application,
and
then
we've
normally
been
deploying
a
container
which
has
the
ad
test,
and
then
we
run
those
tests,
which
is
often
the
start
command
for
when
the
container
starts
up.
That's
usually
what
just
immediately
starts.
B
If
for
a
project
that
doesn't
need
separate
container
or
maybe
it,
it
should
run
the
80
tests
that
are
in
the
actual
application.
That
container.
We
could
do
that
as
well,
so
I'm
not
sure
exactly
what
y'all
have
it
may
be
that,
rather
than
deploying
an
80
container
separately
and
then
that
starts
up
and
runs,
it
may
be
that
during
the
ad
job,
we
actually
go
out
to
the
Cordy
Ness
container
and
run
something
that
was
already
built
and
inserted
into
the
app
app
container.
Okay,.
C
B
So
after
deploying
after
we
have
kubernetes
that's
on
all
the
clouds
they're
provisioned,
then
the
next
step
is
to
deploy
a
container
with
core
dns,
and
that
happens
right
here.
So
this
is
in
the
cross
project.
So
and
then
that
is
like
right
here
we
have
a
deployment
to
AWS
or,
and
we
deploy
the
actual
a
container
that
has
core
dns
and
that's
then
running
on
top
of
kubernetes.
So
I.
B
That
core
DNS
could
be
a
plug-in
for
kubernetes
for
its
DNS.
It
can
also
be
run
independently,
just
as
a
DNS
server.
Yes,
we're
not
testing
all
of
those
in
one
go
right
now,
that's
probably
something
that
we
need
to
look
at,
like
all
the
different
I
guess,
the
different
types
of
tests
would
require
different
deployments.
C
B
B
So
what
we
had
been
running-
and
so
this
is
what
we
need
to
talk
to
you
about
what
would
be
the
different
types
of
tests
that
we
look
at
what
we
were
running
with
DNS
tests,
your
general
DNS
test
and
not
kubernetes
specific
yeah.
We
weren't
running
tests
that
are
validating
and
that
kubernetes
can
talk
to
for
DMS.
C
A
B
Absolutely
so
when
we're
testing
kubernetes
so
from
the
cue
Brunetti
side
here
when
we're
testing
doing
conformance
tests
of
kubernetes
we're
not
currently
plugging
in
all
DNS
servers
that
could
be
used
for
kubernetes
and
testing
all
of
us,
so
we're
right
now
we're
only
selecting
one
that
might
be
something
that
we're
going
to
add
in
the
future.
So
we
go.
We've
tested
DNS
with
this
thing,
this
server
we're
going
to
test
with
14s
or
in
test
those
right
now
we're
selecting
one
and
just
then
saying
that
that's
working
but
yep
and.
C
B
Absolutely
from
the
standpoint
of
the
cross,
Claude
CI
testing
like
what
can
we
do
and
what
have
we
done?
We
test
we've
tested
core
DNS
as
the
plugin
we've
used,
we've
gone
back
and
forth
since
we
have
no
nothing
currently
displayed
from
a
dashboard
side.
So
when
we're
looking
at
C&C
FCI
here
we're
saying
what
is
tested
here,
we
don't
have
a
way
currently
to
display
which
DNS
server
is
being
plugged
in
from
the
back
end,
though.
B
Yes,
we
can,
we
can
select,
what's
there
so
build
process
on
everything
else,
we
could
use
either
one
so
we're
good
to
go
when
it
goes
to
fault,
accordion
s
and
I'm.
The
conformance
test,
as
you're
saying
part
of
what
they
do
is
actually
validate
that
DNS
works.
So
when
that
goes
into
place,
it
will
be
tested.
Yes,.
C
Okay,
yeah,
it's
good,
so
let's
focus
on
core
DNS
tests
and
the
way
to,
but
my
my
main
focus
right
now
is
when
I
want
to
add
test.
I
would
like
to
consolidate.
To
is
what
you
are
doing,
so
we
do
not
make
two
branch
on
to
to
kind
of
to
kind
of
see
eye
test.
So
that's,
okay.
Let's
look
on
your
side.
I
will
comment.
I
will
look
with
quiz,
however,
so
we
can
explain
you
what
we
are
doing
right
now
and
and
make
a
plan.
C
B
So
I
think
the
next
step
would
be
what
the
what
happens,
what
runs
whenever
you
get
this
PR?
That
has
the
slash
integration.
What
are
the
actual
commands
that
are
run
and
that's
I
think
what
we
would
want
to
plug
in
here
priority
test
and
try
to
see
if
we
can
use
those
upstream
that
the
way
that
you're
running
them
now
and
see
what
may
need
to
be
adjusted
if
we
can
and
if
that
makes
sense-
and,
like
you
said
ideally,
we
can
use
these
rather
than
having
two
sets
of
tests.
B
B
So
during
the
build
phases
when
so
during
this
face,
whenever
we
do
compiles-
and
everything
is
where
you
would
say-
unit
tests
would
be
run
and
if
everything
past
here,
then
we're
going
to
make
those
the
compiled
artifacts
available.
And
then
we
go
through
this
stage
and
we
would
run
this
integration
test.
C
B
B
B
A
C
A
C
C
A
C
C
C
C
B
B
C
C
B
We
were
using
the
make
file
release
to
create
a
release.
Then
we
added
added
to
the
container
that
we
deployed
well.