►
From YouTube: CNCF CI Working Group 2020-07-28
Description
CNCF CI Working Group 2020-07-28
B
B
A
B
B
A
So
whether
what's
what's
missing
from
the
software
that
we've
been
shown
and
the
the
testbed
is
in
some
ways,
you
could
think
of
it
as
like:
a
reference
implementation,
but
on
a
very
maybe
a
it's
not
trying
to
be
as
opinionated
on
on
picking
a
specific
set
of
software,
because
we
want
to
make
it
where
anyone
can
plug
in
whatever
options
they
want.
So
if,
if
you're,
trying
different
network
plugins,
there's
a
lot
of
different
options,.
B
A
B
B
A
Sure-
and
I
guess
maybe
to
a
step
back
a
little
bit
and
then
I
get
back
into
cncfci.
So
ideally
this
whole
meeting.
What
we
would
be
talking
about
on
these
group
meetings-
and
maybe
I
don't
know
if
it
should
be
a
working
group
or
a
user
group
or
what.
But
the
idea
would
be
any
type
of
ci
technology
or
work
that
we
could
share
ideas.
That
would
be
useful
across
any
of
the
cncf
projects
and
not
specific
to
the
cncsci
dashboard.
A
So
if
there's
anything
from
urine,
that's
interesting
and
could
be
shared,
then
that
would
be
good,
and
I
would
like
to
push
the
group
to
be
more
towards
that
versus
a
stat.
It's
not
really
a
status
update
for
this.
I
know
that
that's
kind
of
been
or
where
it
is,
but
I
think
it's
mainly
because
we
haven't
had
people
bringing
up
other
topics.
B
Okay,
that's
good
and
from
my
angle,
it's
really
more
for
how
we
can
encourage
or
have
more
of
the
cloud
native
projects
having
some
element
of
ci
or
validation
on
arm
or
multiple
architectures
overall
and
and
how
we
enabled
that
to
happen.
So
on
the
outside.
We've
worked
with
a
number
of
the
cmci
company
and
frameworks
to
actually
provide
access
to
resource
or
get
them
to
operate
on
our
platforms
as
well,
but
I
think
the
intent
is
is
predominantly
to
really
enable
projects
to
work
seamlessly
across
architectures,
whichever
they
are.
A
A
So
that's,
I
think,
there's
probably
many
different
communities
for
you
to
come
and
talk
to
on
that,
but
with
regard
to
arm
and
just
being
more
independent
of
architecture
for
the
ci,
if
y'all
have
anybody
on
on
your
side,
that
could
talk
about
that
in
best
practices,
and
maybe
this
could
be
a
place
for
that.
So
if
we
say
hey
next
month,
we're
going
to
have
someone
from
arm
talk
about
multi-arc
support
and
we
could
get
it
pushed
to
all
the
different.
A
B
So
that
that's
really
that's,
it
is
something
I
know
has
been
an
issue
for
quite
some
time
and
that
should
be
one
less
blocker
for
enabling
other
things
and
there
is
work
around
envoy
which
is
coming
together
as
well.
So
that's
in
terms
of
ci,
so
that's
something
you
will
be
able
to
pass
along
as
well
and
communicate
here
too.
A
C
So
I
was
interested
in
what's
going
on
in
this
working
group
and
obviously,
if
there's
ways
we
can
help
get
something
I'd
love
to
talk
about.
You
know
whether
it's
you
know.
We
obviously
provide
a
lot
of
free
infrastructure
and
we've
had
some
conversations,
at
least
with
the
kubernetes
community,
around
prowl,
but.
A
The
idea
with
this
is
to
have-
and
this
project
is
currently
in
kind
of
a
maintenance
mode.
Looking
at
a
a
refresh.
Where
are
we
going
to
go
from
here?
But
the
idea
is
for
the
primarily
the
cncf
incubating
and
graduated
projects,
although
looking
at
some
other
projects
how
to
have
a
quick
view
of
their
most
recent
staple
release,
as
well
as
the
latest
commit
on
their
master
branch
or
their
head
on
it
right
now,
it's
a
daily
basis.
A
A
Like
for
deployment
and
then
when
we're
doing
this,
we're
actually
saying
with
the
in
test
environment,
we're
saying
looking
at
the
latest
stable
kubernetes
and
that
we're
supporting
in
the
environment
and
the
latest
head
and
then
some
type
of
combination
of
architecture
and
potentially
other
run
times.
We
had
docker
at
one
point
right
now:
it's
just
container
d,
okay
and
then
saying
so.
If
you
look
at
the
way
these
it
kind
of
flips
between
those.
A
So
it's
a
quick
like
view
of
where
the
projects
are,
and
then
you
get
links
back
into
the
projects
and
of
course
they
can
do
more
extensive
stuff
and
prometheus
does
a
lot
of
scalability
things
which
would
be
more
extensive
than
what
we're
doing.
But
it's
it's
just
another
view
of
of
of
what
this
the
health
of
projects
are,
so
one
tying
into
where
things
are
to
answer
felipe
on
where
things
are
and
where
it's
going.
A
So
it
is
in
maintenance
and
we
are
trying
to
keep
versions,
updated
and
and
other
things,
but
we're
looking
at.
Where
does
where
do
we
want
to
go
with
this,
and
the
the
whole
project
is
built
in
a
lot
of
different
pieces?
There's
a
well
there's
the
pipeline
underneath,
and
that
could
be
any
different
thing,
but
it
happens
to
be
based
on
on
gitlab.
A
The
different
pipelines,
sources
pulled
up
stream
at
one
point,
builds
were
all
done,
internal
so
like,
and
some
of
them
still
are
so
builds
would
be
tested.
So
this
was
about
validating
things
external
to
whatever
the
project
did,
and
they
were
actually
rebuilt.
The
binaries
create
the
artifacts
and
then
push
them
out
and
the
recent
projects,
instead
of
doing
that,
what
we've
done
is
we
have
integrations
to
whatever
ci's
they're
running
and
I
think
one
of
them
that
would
be
a
valid
new
one
I
think,
is
well,
I
can't
recall
denver.
A
A
So
that's
why
these
are
all
n
a
on
that
and
they
may
also
have
failures
because
of
the
other
reasons.
But
but
that
would
be
one
of
the
things.
So
the
idea
with
this
would
be
to
encourage
and
help
the
projects
to
get
all
their
builds
publicly
available
so
that
you
have
public
information
so
that
you
can
see
that
the
actual
binaries
are
building
and
passing
all
of
the
tests.
A
A
A
This
is
what's
pulling
all
the
information
in
about
all
the
projects
and
each
one
of
the
projects
have
their
own
configuration
that
tie
in
and
say
point
to
the
project
and
say
what
architectures
they
support
and
stuff
like
that
and
prometheus
doesn't
have
the
external
ci
information.
But
let
me
see
if
I
can
find
them
real,
quick.
C
A
Right
right,
so
that
this
would
be
an
example
of
the
external
ci.
So
that's
actually
part
of
this
ci
proxy
that
we
have
that
integrates
and
pulls
information
back.
So
github
actions
is
one
of
the
integrations
that
we
were
doing
and
we
actually
have
a
test
project
that
has
some
support
for
of
actions.
A
So
part
of
this
was
waiting
when
is
a
cncf
incubating
or
graduated
project
gonna
fully
move
over
and
a
lot
of
them
were
doing
a
split
type
thing
between
different
ci
systems.
For
quite
a
while,
and
I
believe
that
there's
a
couple
of
the
projects
that
we
were
supporting
and
I
think
we
may
have
actually
disabled
one
recently
that
have
moved
over.
C
Yeah,
that's
interesting,
so
I
guess
I'm
trying
to
like
do
you.
I
guess
part
of
what
it
seems
like
you've
been
trying
to
do
is
provide
infrastructure
which
is
interesting
now.
Is
there
any
anything
you're
trying
to
do
around
validation
or
a
sort
of
some
sort
of
official
statement?
Or
is
it
just
like
hey?
If
you
don't
have
ci
we'll
help
you
get
it
set
up,
so
I'm
trying
to
kind
of
understand,
or
is
it
really
just
this
hey
you've
got
ci.
C
A
A
Well,
it
starts
getting
more
and
more
complex
on
that,
so
that
kind
of
shifted
away
as
far
as
goals.
Although
it's
more
there,
if
we
say
it's
focused
on
the
testing-
and
you
don't
have
to
do
these,
because
these
are
external
but
so
marketing
tying
in.
Like
pushing
like
how
do
what
are
these
looking
like,
these
are
cncf
projects
that
you
could
see
that
and
the
health
of
this,
how
they
work
with
kubernetes
and
different
versions,
and
if
things
are
broken.
A
So
that
moved
away,
I
think
at
this
point,
if
you
were
looking
at
what
the
working
group,
which
would
be
separate
from
the
dashboard,
so
the
dashboard
is
not
the
working
group
from
the
working
group
side
what's
still
listed.
If
you
go
look
at
the
cncf,
sigs
and
working
group
page
is
somewhat
towards
that.
You
could
say
helping
cncf
projects
and
part
of
that
could
be
helping
build
their
ci
out.
A
A
I
I
think
what
would
be
more
likely
chris
is,
if
we
could
say
here's
right
now
to
rather
than
saying
we're
going
to
take
it
all
on
and
solve
all
your
problems
with
one
thing
would
be
providing
a
place
for
people
to
get
started
and
have
options
that
are
easily
available.
So
if
they
said,
where
can
I
run
any
of
this?
Well,
there
is
cncf.
B
C
Yeah,
that
seems
reasonable,
like
I
don't
know
it
feels
like
like.
If
I
sort
of
break
this
down,
like
I
mean
in
the
end,
everybody's
artifact
needs
to
be
a
container
like
how,
however,
it
is
you
get
there
you
get
to
a
container.
I
I
think
the
the
part
that
you
talked
about.
That
seems
interesting,
at
least
from
a
working
group
and
like
how
the
cncf
would
support
projects.
Is
that
testing
thing,
and
I
think
the
dashboard
is
interesting?
It's
like
hey.
C
The
question,
though,
is
how
do
we
do
it
in
a
way
where
the
working
group
is
really
doesn't
have
to
build
out?
Infrastructure
is
the
right
word,
but,
like
hey,
you
provide
your
tests
in
a
uniformly
consumable
way.
It's
like
you
know
you
provide
your
deployment
in
a
uniformly
consumable
way
and
you're
tested
in
a
uniformly
consumable
way
and
we'll
generate
and
run
a
pipeline
across
some
set
of
versions
of
things
and
give
you
a
green
or
a
red
based
on
what
that
is,
seems
really
interesting.
The
build
part
feels
like
yeah.
C
A
I
know
there's
internally,
there's
been
so
many
revisions,
but
the
next
iteration
of
this
is
what
you're
talking
about
chris,
where
the
pipelines
are
externalized
and
the
focus,
and
we
have
a
lot
of
design
around
the
efforts
that
we
did
documentation
on
like
what
would
artifacts
look
like
and
this
what
you
have
right
here
is
kind
of
a
hybrid
where
we
were
essentially
prototyping
it.
So
the
external
proxy
part
which
is
working.
A
We
didn't
expose
this,
but
you
would
ideally
the
links
like
from
tough
wouldn't
go
to
our
system,
which
is
running
it.
This
is
what
how
do
you
actually
run
the
software
together
it,
but
instead
the
links
would
actually
bring
you
directly
to
wherever
tuff
is
which
happens
to
or
the
tess
I'm
sorry.
I
brought
up
the
test
and
for
the
test
that
happens
to
be
travis,
okay,
fine
and
then
it
you
click
another,
and
it
goes
to
you
know,
get
actions,
you
click
another.
A
It
goes
somewhere
else,
so
you
could
ideally
click
these
and
they
go
wherever
they
are
and
on
arm
it
may
be
totally
different.
Maybe
they
have
integrated
and
they're
running
it
in
the
same
ci
pipelines
or
maybe
it's
on
a
totally
different
system.
That's
fine,
but
the
idea
was
to
externalize
that
and
send
them
out,
and
then
yes,
like
what
you're
saying
on
the
testing.
A
You
don't
see
it
in
these
particular
links,
but
we
have
other
places
where
we
did
work.
We're
saying
how
do
we
tie
in
the
artifact
from
the
tess,
and
that
would
be
the
next
this
if
we
go
over
to
x86,
so
the
test
didn't
do
it,
but
if,
if
we
look
at
like
the
another
one,
we
say
where
is
the
artifact?
We
found
your
build
it
passed.
Where
is
the
actual
artifact
for
that
build
that
matches
it?
It's
actually
for
the
commit.
So
we
will
deploy
that
into
our
environment.
A
A
So
that's
the
idea
here
is
we're,
saying
we're
going
to
run
it
ourself
and
make
sure
your
stuff
works
on
these
different
versions.
These
builds
work
with
the
deploy
to
kubernetes
and
ensure
all
of
this
works.
Beyond
this,
maybe
we
decide
we
would
love
to
see
core
dns
work,
our
prometheus
working
with
kubernetes
and
yeager
and
all
of
these
running
together.
A
Well,
good
to
know
they're
still
interested
in
it,
and
I
I
do
think
at
the
top
level.
If
we
can
break
down
the
different
offerings
and
pieces,
then
the
dashboard
would
just
be
one
of
those.
So
we
say
we're
not
gonna,
run
your
actual
pipelines
but
we'll
consume
them
and
show
how
it
works,
but,
and
we'll
also
tell
you
best
practices
on
how
you
should
publish
your
artifacts
as
containers.
A
Here's
how
you
can
do
it.
Here's
some
examples,
because
there
are
examples
that
you
can
see
out
there
on
when
they
publish
and
how
they
show
it,
and
there's
also
we'd
also
like
to
push
ci
systems
that
don't
make
it
easy
to
communicate
what
artifacts
were
published
with
the
pipeline,
because
they
don't
all
do
that.
A
So
if,
if
you
have
a
successful
build
and
you
create
an
artifact,
it'd
be
nice
to
have
that
metadata
in
the
pipeline.
So
if
I
come
in
and
reference
the
actual
pipeline,
I
can
say:
okay,
what's
your
artifact?
Oh
it's
here!
That
relates
all
the
way
back
to
this
commit
we're
good
and
then
you
can
keep
creating
in
the
end.
C
A
All
right
well,
if
y'all
would
like
to
think
about
it,
and
maybe
we
focus
on
something
for
a
next
call
or
something
next
month,
ed.
If
you
want
to
talk
to
anybody
from
the
arms
side
that
wants
to
present
on
arm
items
and
I'm
sorry
fleet,
that's
not
worthless
and
and
from
the
arm
side,
and
then
chris.
If
I
don't,
I
don't
know
what
you
want
to
talk
about
either
from
the
github
site
or
I'd
be.
I
think
it
would
be
really
good
to
look
at
what
type
of.
A
C
Okay,
yes
I'll
think
about
that
some
I
mean
there
might
be
some
based
on
what
like
I
I
like
your
ideas
there
I
mean,
I
think,
that
some
best
practices
some
examples
of
how
to
use
different
things
and
it's
the
other
side.
I
mean
I
really
like
the
idea
of
like
the
dashboard
is
interesting
because
it's
it's
kind
of
for
the
projects,
but
it's
also
for
customers
of
the
projects.