►
From YouTube: CNCF CI Working Group Meeting - 2018-03-13
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.
B
B
A
D
C
C
C
A
Like
emails
and
just
joined
as
well
so
for
folks
who
haven't
met
me,
I'm
Taylor,
Turner,
I'm,
working
on
the
cross
club,
CI
team
I'm
with
Wolcott
and
Lucchino
and.
A
B
A
Great,
so
this
is
the
agenda
notes.
If
this
is
on
the
public
calendar
course
and
CF,
you
can
add
your
agenda
here
or
it's
the
weekly
and
twice
a
month
meetings.
You
can
add
those
in
here
if
you'd
like
to
speak
about
something
at
the
next
meeting.
That's
coming
up
we're
going
to
give
some
updates
on
the
cross,
pod,
CI
project.
A
So
we've
had
a
few
releases
on
the
cross,
but
CI,
and
we
had
one
on
March
7th,
March
12th
and
we
have
one
in
progress
probably
releasing
buy
into
this
week
and
that's
related
to
an
app
and
a
couple
of,
and
so
much
effort
into
this.
So
we've
been
updating
to
support
the
newer
versions
of
kubernetes
and
most
of
that
went
there
pretty
well,
and
there
was
some
items
that
we
need
to
verify
with.
The
integrations
are
doing
that.
A
We've
also
updated
prometheus
birding
a
slicker
day
and
gone
through
and
tested
all
those
and
there's
a
few
items.
We
can
jump
into
that.
We
had
the
change
in
the
system
to
support
so
updating
the
release.
Sometimes
is
a
quick
change
and
we'll
be
looking
at
automating
the
new
releases
as
they
come
out
the
items
that
catch
us
as
when
and
something
they
a
requirement
upstream
breaks
and
or
causes
a
breaking
change
and
how
the
actual
CI
system
marks.
So
we'll
talk
about
a
couple
of
those
thanks
there
in
a
minute
we're
also
updating
documentation.
B
A
Crosscut
CI
and
what
it
does
and
we're
also
going
through
and
at
the
per
component
level
like
the
cloud
provisioning,
we're
trying
to
get
the
documentation
updated
for
each
of
those,
as
well
as
the
install
and
how-to
for
each
of
these
items.
So
we're
going
through
and
updating
those
we're
actually
getting
quite
a
bit
of
feedback
from
several
of
the
projects
like
Prometheus
they're.
Doing
some
testing
there.
So
we're
going
to
keep
updating
those,
especially
as
we're
moving.
D
A
So
one
of
the
big
releases
that
we
had
was
this
one
will
know
and
fluent
D.
That's
a
new
project
that
we
added
and
fluently
required.
Some
changes
on
the
testing
system
itself
to
support
before
release
sews
and
IBM
cloud.
So
that's
a
new
cloud
that
we're
now
supporting
or
provisioning,
kubernetes
and
testing
the
various
projects
on
we
released
that
we
have
linker
D
coming
up
and
liquidy
updated
for
one
through
six,
so
that
was
another
bump
from
the
previous
when
it
came
out
just
as
we
released
one
three
five,
so
we
got
went.
D
A
F
F
F
C
C
If
it
fails,
that's
fine
I
mean
that's
a
totally
normal
thing,
as
the
you
know
command
to
invoke
it
or
some
aspect
of
it
breaks,
but
I
guess
the
part
I'm
unclear
on
is
is
is
the
default
that
the
CI
system
automatically
does
take
in
new
releases
or
does
it
need
to
be
manually
set
every
time
there's
a
new
release.
I.
A
So
right
now
it
does
for
this
stable
releases.
We
are
updating
that
that's
in
the
CNCs
configuration
repo,
that's
across
my
channel,
and
we
do
set
those
for
stable,
there's
a
couple
of
reasons,
and
one
of
them
was
some
of
the
projects
had
multiple
stable
releases
and
just
selecting
that
what
we're
going
to
do
for
that
and
we
may
want
to
stay
with
one
like
kubernetes
for
a
while
some
of
the
projects
wouldn't
work
on
it,
so
we
needed
to
stay
with
a
certain
release.
Most
of
that
seems
to
be
out.
A
The
other
was
the
determining
the
release
was
problematic.
When
we
started
some
of
the
projects
wouldn't
tag,
they
would
create
branches
or
they
wouldn't
have
semantic
versioning.
So
there
was
a
lot
of
items.
Some
of
that
has
gotten
better.
It
looks
like
for
all
of
the
currency
and
CF,
so
I
think
we
could
start
adding
that
and
turning
it
on.
We
support
it
the
automatic
for
commits
so
once
we
can
determine
the
stable
release,
and
that
should
be
okay
that
doesn't
help
with
multiple
stable.
So,
like
your
Burnett
ease,
if
we're
saying.
A
C
A
D
A
And
say:
I'm
going
to
configure
this
to
do
it
on
tags
being
an
external
project,
that's
testing
on
those
projects,
Prescott
CI
testing,
this
we
don't
have
as
much
control
over
how
those
are
triggered.
So
we
have
to
programmatically
figure
out
what
the
releases
are
once
we
do
that
take
the
time
to
say
how,
how
do
we
determine
what
a
release
is
when
a
project
releases
it?
We
can
automate
that
so
that
that
will
be
coming
up
soon.
D
A
We're
here
whenever
these
run
through
are
based
on
own
apps
CI
system
and
then,
when
we
do
after
doing
the
kubernetes
provisioning
to
all
of
the
supported
clouds,
then
we're
taking
the
artifacts
from
the
own
app
container
registry
and
we
deploy
those
so
in
QA
and
going
through
testing
right
now
is
we
have
the
app
deployments
with
the
containers,
we're
using
a
te
test
from
ona
upstream,
and
they
have
a
what
they
call
a
root.
It's
a
robot
container
and
it.
D
A
Quite
a
bit
of
work,
we're
focused
on
their
service
Orchestrator,
so
an
FSO.
So
what
that's
called
and
the
components
are
several
different
containers
to
get
deployed
at
the
same
time
that
we
need
to
do
that
testing
and
it's
currently
working
in
our
dev
and
CI
testing
environments
for
moving
that
through
and
it
should
be
released
pretty
soon
as
much
as
possible.
We're
trying
to
use
upstream
for
e
2e
test
for
helm,
charts
and
this
of
items.
A
So
at
the
moment
we
are
using
custom,
helm,
charts
based
on
theirs
that
were
heavily
patched
actually
function
and
we'll
be
trying
to
create
some
pull
requests
upstream
and
get
those
in
as
they
stabilize
over
the
next
few
weeks
inverse
or
any
specific
thing
that
you
want
to
add
to
that.
Or
does
anyone
have
any
questions?
I.
F
A
Other
projects
I'm
related
to
the
helm,
charts
the
repos
used,
so
that's
affecting
we
make
changes
that
affected,
like
fluency,
supporting
those
different
ones
and
supporting
multiple
containers
and
repos.
That's
also
a
related
item
that
lets
us
have
more
complexion
areas.
Does
anyone
have
any
questions
about
the
own
app
integration
and
integrating
with
the
external
CI?
A
Ok
cool,
so
are
the
cross
group
collaboration
with
other
projects.
We've
been
mentioned,
OpenStack
and
prometheus
Prometheus
is
trying
to
build
out
a
CI
system
covering
quite
a
bit
of
items,
including
performance
testing,
and
we're
actively
working
with
them
to
try
to
build
the
e2e
tests
that
would
be
usable
in
cross
CI
and
complement
what
they're
building
out
at
a
larger
scale
and
for
DNS
as
well.
D
A
So
after
we're
done
with
the
own
app
and
open
sack
were
looking
at
Oracle
for
deployments
and
potentially
inless
and
there's.
Another
cloud
that
looks
like
we
should
focus
on
as
CNI
is
the
next
project
that
we're
targeting,
as
mentioned
earlier,
we're
updating
all
the
documentation,
but
the
readme
and
the
installs
and
trying
to
get
those
different
pieces
working.
A
The
a
t-test
for
adding
those
I
think
is
going
to
be
one
of
the
big
ones
and
we'll
be
doing
that
based
on
information.
So
we
work
with
France
on
Cordina
s
and
the
Prometheus
project,
how
you
can
add
that
stream
EE
tests
and
they
come
usable
for
other
projects
and
to
run
out
of
your
own
system
and
then
making
a
few
other
changes
on
the
the
dashboard
itself.
A
D
D
A
C
A
Yes,
it
is
I'm
open
source
and
there's
some
renaming
of
the
project,
just
some
very
like
high-level
items
that
need
to
be
taken.
Care
of
and
I
would
like
to
have
all
that
done
before
OH&S
it's.
It
is
open
source.
It
just
needs
to
be
those
things,
adjusted
update,
make
sure
everything's
still
running
once
we
make
those
sort
of
changes
and
then
enable
that.
C
Taylor
I
have
another
question
for
you
about
releases
and
you
don't
need
to
address
it
now.
We
can
follow
up
later,
but
just
looking
at
Prometheus,
they
seem
to
be
doing
a
great
job
in
the
releases
page
on
github
of
labeling,
all
their
releases,
so
I
mean
looking
through
here,
I
see
dot,
dunno,
RC,
0
char
c1
and
then
that
that,
oh,
when
they
release
that
and
it's
my
belief
that
the
most
sensitive
projects,
if
not
all
of
them,
are
using
that
release
pages
of
on
github
and
so
I
do
believe.
A
Absolutely
so
when
I
guess
up
until
maybe
three
or
four
months
ago,
and
it
seemed
most
of
they
will
not
miss
them.
There
were
several
projects
that
didn't
have
releases
in
this
release.
Link,
if,
if
you
go
to
that
tab
and
some
of
them,
if
they
didn't
have
that
they
may
have
a
release
tag
so
and
it
may
not
be
using
semantic
versioning.
A
There
was
a
few
of
them
like
that,
and
some
of
them
didn't
have
anything
on
the
actual
release
page.
They
just
tagged.
So
it's
more
of
determining.
How
are
we
going
to
know
when
it's
a
release
like
as
a
human?
We
can
quickly
see
there's
a
programmatic
part
for
that
it
seems
to
be
better
as
you're
seeing
now
it
seems
that
most
most
of
the
CMC
of
projects
are
now
following
those
standards
and
that's
changed
from
what
it
was
many
months
back.
So
I
think
we
can
add
it
now
and.
C
A
As
long
as
we
have
something
consistent
that
we
can
find,
it
makes
it
a
lot
easier.
Otherwise
we
need
to
think
there's
some
fallback
that
we
do
potentially
just
it
uses
the
last
version
and
and
notifies
us
I,
don't
know
whatever.
That
would
be
right
now.
It
looks
like
at
least
the
projects
that
we're
currently
supporting.
We
could
add
something
and
feel
pretty
confident,
but
as
they
do
release
and
work,
we
should
be
good
to
go.