►
From YouTube: CNCF CI WG Meeting 2020-03-24
Description
CNCF CI WG Meeting 2020-03-24
A
B
C
C
C
C
C
Think
that
covers
it.
So
I
think
one
one
thing
to
bring
up
for
folks
who
haven't
been
attending
I'm,
seeing
some
names
that
I
haven't
seen
on
here.
This
group
is
for
discussing
any
CI
topics,
I'm
specifically
related
to
CN
CF
projects,
but
this
could
be
projects
that
are
focused
on
CI
or
pooling,
or
talking
about
maybe
problems
that
you've
solved,
or
you
have
questions
that
you're
trying
to
resolve
issues
that
you
think
would
be
useful
for
the
whole
community
and
I
think
that
about
that
about
covers
it.
C
There's
service
providers
that
like
packet
and
they
do
a
lot
of
work
with
CN
CF,
so
there's
a
lot
of
items
where
they
focus
on
trying
to
help
different
all
the
different
projects.
So
I
think
with
the
Kim
that
we
have.
We
can
cover
everything
from
development
and
tooling
all
the
way
through
running
stuff
on
different
platforms,
including
arm
and
x86.
C
B
B
B
B
We
do
not
really
know
the
deep
testing
required
inside
code
eNOS,
we
are
Kaos.
Infrastructure
providers
is
a
project.
As
you
might
have
observed.
We
are
now
trying
to
donate
this
project
into
C&C
f.
As
a
sandbox
project.
Last
week
we
had
a
meeting
to
propose
it.
Hopefully
that
will
get
to
the
whole
idea
here
is
we
were
on.
We
think
Latinos
will
be
useful
as
a
CI
project
to
introduce
chaos
for
a
lot
many
other
projects,
but
we
don't
know
where
to
get
started
with
them.
B
C
Thank
you
for
that,
and
thank
you
for
the
adding
the
PR
and
I
saw
that
you've
made
the
updates
that
we
were
asking
about
forearm.
So
thanks
for
that
and
I
think
as
far
as
the
PR
goes
we're
probably
at
a
point
where
we
can
review
that
and
merge
that
so
maybe
the
other
part
is
the
focus
and
so
engaging
other
CNCs
projects.
C
But
it's
something
that
we've
been
talking
about
how
to
where
do?
We
want
to
go
with
this
group,
and
some
of
that
would
have
to
do
with
is
it?
Is
a
working
group
the
best
option,
or
should
we
look
at
switching
this
to
be
a
user
group
or
something
else
so
within
the
same
TF,
there's
different
type
of
communities
and
they
serve
different
purposes
and
potentially
what
you're
talking
about
may
fit
better
for
a
user
group
and
I
think
we
need
to
explore
that,
but
I'm
happy
to
add.
Add
chaos.
C
Testing
is
one
of
the
items
that
would
kind
of
drive
that
conversation
for
what
the
CI
work
group
would
do
and
then,
in
the
meantime
I
can
say
going.
There's
a
there's,
a
few
places
number
one.
Of
course
you
can
go
to
all
the
github
pages
or
the
the
websites
for
those
projects.
Accordion
s
has
a
contributing
guide
and
all
of
the
projects
have
their
own
contributing.
So
that
would
be
one
place
that
you
can
go.
C
The
accordion
s
I
know
is
active
on
slack,
so
there's
a
CN,
CF
and
kubernetes
locks
both
have
a
lot
of
the
San
CF
projects
are
going
to
be
active
in
this.
So
if
you
want
to
have
some
type
of
live
conversation
too,
that
would
be
one
of
the
areas
and
then
probably
the
user
mailing
list
would
be
one
of
the
first
places
to
start
a
conversation
where
it
may
be
kind
of
a
longer
async
type
of
conversation.
C
If
you're
wanting
to
raise
that
there,
so
the
github
which
allows
you
do
like
issues
and
it
whatever
they're
contributing
guides,
are
slack
for
live
conversations
and
then
mailing
lists
and
right
now
it
would
be
targeting
each
one
of
those
there's
there
isn't
anything
at
the
moment.
That's
going
to
come
in
and
and
immediately
get
deep
lied
to
all
of
all
the
projects.
So
I
would
say
my
opinion
on
this
would
be
if
you
went
to
the
san
CF.
C
Main
CN
CF
page,
and
you
start
at
the
the
projects
I,
would
focus
on
the
graduated
projects
and
then
move
forward
to
the
incubating.
So
you
could
just
go
down
the
list.
Accordion
s
is
one
and
reach
out
to
these
individuals,
and
you
have
all
the
links
and
stuff
here
and
I'd
probably
get
some
type
of
pitch
on
engagement,
that's
general,
but
then
look
at
each
one
of
these.
B
Great
that'll
be
helpful.
A
teller
I
will
reach
out
the
common
interest
of
all
these
projects
and
then,
if
you
could
make
the
chaos
testing
is
a
common
topic
that
might
drive
more
community
engagement
as
well
skins.
Here,
our
goal,
probably
is
you
know:
we've
been
using
litmus
quite
effectively
and
to
bring
out
the
bugs
or
electricians
in
couple
of
projects,
namely
open
EBS,
so
we
think
at
least
for
kubernetes
main
project
itself,
where
this
could
bring
out
a
lot
of
value.
B
B
C
Okay,
so
I'm
gonna
step
back
here,
I
can
I
can
go
back
to
CN,
CF
CI
and
talk
about
that
as
related.
One
of
the
things
that
to
keep
in
mind
is
all
of
the
projects
are
running
independently,
so
they
all
have
their
own
and
contributing
guides,
and
they
all
have
their
own
process,
and
there
has
been
some
interest
in
what
are
common
services
that
could
be
provided.
C
There's
no
structure
right
now,
primarily
in
my
mind,
that's
because
the
projects
are
left
to
run
independently
for
most
of
what
they
need,
and
some
of
the
needs
are
quite
different.
Prometheus,
for
instance,
does
some
pretty
large
scale
perform
some
scalability
testing
core
deenis
doesn't
do
the
same
type
of
testing
for
say
their
integration
and
8a
a
test.
They
do
a
different
type.
C
There
is
I
think
some
possibilities
to
do
something
like
a
service
where
you
could
say
all
of
them
maybe
could
get
chaos,
but
that
sort
of
thing,
I,
think,
would
be
much
further
out.
So
right
now,
I
would
think
you
need,
if
you
want
to
get
chaos,
testing
used
by
more
projects,
you're
going
to
have
to
go
after
them
directly
and.
C
With
sanski
FCI,
the
first
thing
to
state
is
it's
right
now
in
a
maintenance
mode
and
there's
a
focus
has
been
moved
to
other
CN
CF
initiatives
right
now
as
primary.
So
it's
it's
it's
in
a
maintenance
phase.
We
do
have
we.
There
was
some
planning
on
the
roadmap
and
the
next
phase
is
beyond
this,
which
would
allow
for
and
prior
talks.
We
actually
showed
some
mocks
and
stuff.
What
we
were
looking
at
that
would
would
allow
for
adding
more
tests.
That
could
be
run.
C
So
it
would
be
a
perfect
way
of
saying
we
want
everything
to
do
chaos,
testing.
We
also
want
them
to
do
whatever
other
testing
is
desired
and
plug
those
in
and
have
those
options
available.
That's
future!
So,
right
now
what
you're
seeing
is
you're
going
to
have
builds
compiles,
builds
unit
tests
which
are
either
going
to
be
running
within
the
system
which
is
based
on
git
lab,
or
it's
going
to
be
all
on
the
remote
system.
C
So
core
DNS
has
their
own
CI
system
and
if
they
have
everything
we
need,
including
published
status
and
artifacts,
then
we
integrate
with
those
and
pull
them.
So
we're
not
re
running
them,
then
we
pull
the
artifacts
undo
to
place
and
then
there's
some
type
of
smoke
tests,
so
very,
very
minimal
tests
to
ensure
that
it's
up,
you
can
see
that
we
have
some
failures
right
now,
some
stuff
going
on
at
least
on
this,
set
whatever
it
is
and
and
then
the
final.
What
we
have
here,
which,
as
you
can
see
is,
is
all
na.
C
There
was
a
point
in
the
past.
It's
been
disabled
for
a
long
while,
but
there
was
a
point
in
the
past
where
we
were
running
e
to
e
test.
That
would
be
I.
Think
what
you're
asking
about
with
the
route
of
what
tests
do
we
run
those
tests
where
possible
what
we
wanted
was
to
run
upstream
tests
and
some
of
the
projects
had
IDI
tests
that
we
could
run,
but
it
was
very
limited
on
on
which
projects
so
those
were
disabled.
C
The
long-term
goal
was
to
work
with
the
projects
so
that
we
could
have
the
people
that
actually
know
that
the
details
of
the
how
the
the
application
should
work
to
have
IDI
tests
that
would
run
and
then
we
would
source
those
and
be
running
them
across
the
matrix.
So
that
that's
another
future
item,
if,
if
and
when
we
move
out
of
this
maintenance
mode
and
start
working
on
the
other.
But
right
now
those
are
disabled.
So
some.
C
Do
have
IDI
tests
and,
if
you're
interested
in
contributing
like
other
types
of
tests,
that
I
definitely
think
some
of
them
like
Horde
enas
Prometheus
were
two
of
them
that
I
could
think
of
immediately
and
that
I
don't
a
Denver,
Watson
or
any
of
y'all.
Remember
any
other
projects
that
were
had
a
t-test.
You
feel
free
to
speaker,
I.
C
Sure
so
the
pr
that
you're
adding
for
this
chaos
stage
in
the
pipeline
that
would
end
that
will
end
up
affecting
the
test.
So
as
as
far
as
the
pipeline
goes,
you
would
end
up
if
there's
a
failure.
Let's
say
that
this
is
specific
to
Cortina,
where,
right
now,
we
don't
you're,
not
doing
chaos
for
all
of
them.
But
if,
if
the
this
stage
fells,
then
we
would
show
a
red
failure
up
here
and
then,
whenever
let's
say
I'm
going
to
click
on
this
Lambie,
so
this
goes
to
the
get
lab.
C
C
C
Denver,
do
you
have
any
comments
on
that?
I
think
the
question
is:
will
this
affect
the
core
deenus?
So
maybe
let
me
step
back
so
the
dashboard
is
a
custom
view
of
status,
information
from
multiple
places.
It's
not
just
get
lab
that
we
source
the
data
from
multiple
places.
The
upstream
we
have
our
own
status
repository
that
has
an
API
that
we
combine
all
the
information
and
it's
retrieved
from
there.
So
this
is
not
a
specific
view
of
this
stages.
C
B
C
C
C
We
can
follow
up
with
you
on
that
offline
because
there's
probably
some
items
that
we
want
to
talk
about
where
it's
gonna
go
rather
than
going
into
it's
basically
not
going
to
show
up
on
production
from
the
start.
We
have
multiple
environments,
but
we
can
follow
up
with
you
on
that
and
well
as
we're
testing.
B
B
C
A
C
A
Yeah,
the
CNF
conformance
suite
is
a
bunch
of
software.
That
is,
they
need
to
see
if
a
CNF,
which
is
a
cloud
native
Network
function,
is
compliant
now.
There's
multiple
aspects
to
that,
but
basically
it's
trying
to
see
if
some
networking
functionality
or
some
networking
software
is
cloud
native.
Now,
there's
a
bunch
of
principles
that
go
along
that
and
Taylor's
displaying
some
of
those
their
compatibility,
compatibility,
statelessness
security,
scalability
configuration
life
cycle,
observability,
install
ability
and
hardware
resource
and
scheduling.
A
Historically,
some
of
those
things
within
the
network
world
were
incompatible
with
cloud
native.
A
lot
of
that
is
not
automated,
not
elastic
and
not
a
bunch
of
these
other
properties,
so
the
conformance
suite
is
made
to
help
users
and
within
this
space,
that
would
be
the
service
providers
like
telcos,
like
a
verizon
or
AT&T,
or
something
like
that
to
be
able
to
see
if
a
network
function
that
they
purchased
or
if
it's
open
source
that
they
downloaded
and
installed
is
compliant
and
cloud
native.
A
A
So
the
conformance
test
suite
itself
needs
to
be
tested,
and
another
thing
I
forgot
to
mention
is
the
cns
conformance
test.
Suite
is
a
sense,
EF
initiative.
It's
not
a
project
to
CNCs
initiative,
it's
still
open
source
and
everything
like
that.
But
so,
as
I
was
saying,
it's
a
test
suite
and
it's
kind
of
weird
because
think
about
it.
A
So
for
the
conformance
suite,
where
right
now
we're
using
Travis
and
everything
that
we're
doing
can
be
seen
inside
the
Travis
animal
and
see
what
else
where
we
within
the
Travis
animal
travis
installs
crystal
they're,
like
the
language
that
the
CNS
lips
form
is
sweet,
is
written
in
as
crystal
we're
going
to
talk
about
that
a
little
bit
later.
And
then
we
have
to
manually
install
going.
A
We
have
to
install
going
in
order
to
install
kind
and
use
that
to,
of
course,
install
the
network
function
to
create
the
kubernetes
cluster
to
install
the
network
function
in,
and
then
we
run
the
integration
test,
which
is
just
the
command
crystals
bank
and
that
and
then
I
guess
we
can
go
to
the
next
slide.
So.
A
Crystal
is
it's
similar
to
Ruby,
so
it's
made
for
humans.
It's
easy
to
read
the
communities
that
were
that
are
out
there
that
are
familiar
with.
Maybe
dynamic
languages
like
Python
or
Ruby
and
within
the
CICE
community
would
be
more
familiar
with
it
and
they
find
it
easier
to
use
it's
statically,
typed
and
compiled.
So
in
that
sense,
it's
similar
to
going
and
Travis.
A
D
A
A
So
we
were
calling
so
within
the
network
function
world.
We
were
calling
that
a
use
case.
So
if
we
were
to
say,
take
core
DNS
and
then
say,
maybe
try
to
use
it
with
a
some
other
layer
to
CNF
that
uses
VPP
for
an
for
instance,
and
we
would
take
both
of
those
and
put
them
together.
The
CNF
test
bed
has
a
bunch
of
use
cases
and
we
wanted
to
be
able
to
maybe
grab
some
of
those
in
the
future.
A
There's
lots
of
use
cases
out
there
and
we
want
to
have
a
strong
narrative
to
be
able
to
test
multiple
what
we
call
CNF
that
together,
which
would
make
a
use
case
so
yeah.
The
answer
is
yeah.
It's
in
the
future
that
that
we'll
be
looking
at
that,
though
the
scene
as
testbed
is,
is
where
we
would
test
these
cases
right
now,
though,
okay.
D
D
The
project
that
I've
been
doing
for
the
past
couple
years
is
called
works
on
arm
is
focused
on
arm
compatibility
for
various
projects,
quite
notably
for
CN
CF
project.
So
next
slide
gives
a
quick
overview
of
things
so
I've
been
following
the
CN
CF
arm
dashboard
and
trying
to
figure
out
where
to
put
energy
and
to
improve
the
state
of
things
so
I
spent
about
an
hour
before
this
call
just
walking
through
each
of
these
projects,
and
this
is
a
working
document
so
far.
D
The
good
news
is
that
core
DNS,
which
was
mentioned
earlier,
is
an
exemplary
project
with
as
far
as
I
couldn't
tell
from
everything.
I
can
see
full
support
in
their
current
release
for
arm
systems
and
therefore
CI
testing.
On
top
of
that
should
have
a
very
good
chance
of
success
for
many
of
the
others
and
there's
details
all
through
here.
D
It's
not
completely
true
everywhere,
there's
at
least
one
place
where
I
saw
a
project
distributing
arm
and
s/390
fineries,
so
they
have
some
multi
architecture
capability,
but
typically,
in
my
experience
with
other
project
development,
there's
a
somewhat
sometimes
messy
build
process
that
spits
out
a
binary
for
x86
that
to
re-architect
it
for
spitting
out
batteries
for
multiple
architectures
takes
a
bit
of
work.
So
there's
a
bit
of
work
out
of
us.
D
The
prometheus
is
another
example,
so
the
CI
process
produces
a
binary
or
or
can
be
coerced
to
produce
a
binary,
but
one
of
the
downstream
consumers
of
those
binaries
is
registries
and
up
until
relatively
recently,
not
every
registry
and
I'm.
Looking
at
Quay
right
now
had
full
multi
architecture,
manifest
support,
and
so
there's
been
some
delays
in
getting
full
architectural
diversity.
As
a
result
of
that,
I
don't
want
to
go
into
lots
of
these
in
lots
of
detail
and
I.
D
I'll
just
comment
that
this
is
similar
in
some
ways
to
the
chaos
question
of
how
do
you
reach
all
the
projects,
and
my
experience
to
Dave
has
been
you
reach
all
the
projects
by
reaching
out
to
each
of
the
projects
and
there's
no
necessarily
easy
way
to
reach
them
all
at
once.
But
sometimes
you
have
projects
like
CNC
FCI.
They
give
you
some
visibility
into
what's
actually
going
on
and
the
suitability
of
maturity
of
them
for
taking
additional
work.
B
D
It's
the
the
the
experience
I've
had
has
been
in
you.
You
find
the
issues
for
each
of
the
projects.
You
read
some
of
them
to
see
what
they're
actually
doing
and
see
how
you
know
receptive.
They
are
and
see
where
they
stand
in
terms
of
project
maturity,
and
then
you
start
to
chip
away
sort
of
one
at
a
time
to
figure
out.
D
C
C
That
would
be
helpful
for
many
projects
and
I.
Think
one
of
the
things
that
we
were
looking
at
beyond
that
was
how
do
you
get
them
to
publish
and
have
this
would
kind
of
be
like
that?
Maybe
onboarding
for
chaos
or
arm
or
anything
making
it
easy
to
publish,
because
you
maybe
follow
us
aspect
that
says
we're
going
to
always
say
the
architecture
we're
going
to
give
artefact,
URLs
and
other
information.
There's
no
real
standard
around
that,
but
I
I
think
that
there's
some
value
and
maybe
pursuing
that
I.
D
Agree,
there's
certainly
support
that
needs
to
happen
in
both
directions.
It
really
helps
for
projects
to
see
customers
or
partners
or
other
folks
pulling
and
asking
for
things
and
as
well.
You
have
to
do
a
certain
amount
of
pushing
and
providing
requests
for
looking
at
code
and
and
other
sorts
of
artifacts.
D
I'd
be
happier
that-
and
you
can
say,
we've
made
a
whole
bunch
of
progress,
but
there's
more
progress
to
be
made.
I'd
look
forward
to
I
can
share
this
worksheet,
it's
a
working
document.
So
if
that's
a
helpful
start
or
just
a
helpful
spike
in
the
ground
as
a
way
of
having
something
to
talk
about
where
we
stand
and
what
the
status
is
and
what
the
next
step
would
be,
I
think
that
might
be
a
good
good
way
to
go.
Yeah.
C
D
Dad
only
one
thing
before
everyone
goes
before
that
meeting
on
April
1st
there's
an
online
conference
called
virtual
rejects
rejects,
was
to
have
been
held
at
the
same
time
as
Hugh
Khan
Oh,
actually
the
weekend
before
for
everyone's
paper,
who
is
rejected
from
Q
Khan.
This
is
a
fringe
festival,
style
event.