►
From YouTube: CNCF CI WG Meeting - 2019-07-23
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
Okay,
great
welcome
everyone's
the
Saints,
the
FCI
working
group
monthly
meeting
today
is
Tuesday
July
23rd
and
the
monthly
meeting
is
held
monthly
on
the
fourth
Tuesdays
starting
at
12
p.m.
Pacific
time.
This
meeting
is
recorded
by
CN
CF
and
will
be
published
to
the
san
CF
youtube
channel.
The
links
past
meeting
recordings
is
in
the
monthly
meeting
agenda
and
notes.
A
A
A
The
Open
Networking
summit,
Europe
schedule
was
just
announced
today
by
Linux
Foundation.
That
event
is
held
in
Antwerp
Antwerp
Belgium
September
23rd
through
25th
and
Taylor
carpenter
from
vult
cooperative
will
be
part
of
a
tutorial
about
driving
telco
performance
with
the
cloud
native
network
function
see
enough
testbed,
that's
a
pre-registration
required
event.
So
please
click
through
to
learn
more
and
be
added
to
the
list.
A
A
They
have
hosted
projects
that
schedule
will
be
announced,
Thursday
September
5th,
so
we
will
know
if
our
panel
idea
is
accepted
and
a
couple
of
months
there's
some
co-located
co-located
events
around
cube
con.
One
of
them
is
envoy.
A
con
CFP
is
currently
closed,
but
I
believe
there
are
still
spots
available
if
we'd
like
to
attend
that
co-located
event
click
through
and
there
may
be
other
co-located
events
to
be
announced.
A
A
A
The
dashboard
tests,
the
scene
CF,
hosted
projects
on
several
test
environments,
running
kubernetes,
stable,
kubernetes,
stable
on
x86
and
kubernetes
on
arm,
and
we
run
those
for
stable
and
head
releases
of
kubernetes
on
bare
metal
packet.
The
test
environment
shows
the
status
of
the
provisioning
stage
and
then
the
projects
are
listed
by
status
within
CNCs
we've
got
graduated
projects,
we've
got
incubating
projects
and
we've
got
a
Linux
Foundation
project's
own
app
currently
on
the
dashboard.
A
Let's
say
so:
we
can
change
the
test
environment,
so
this
is
showing
all
the
projects
running
their
bills
and
deploys
on
stable
kubernetes
on
x86.
I
can
also
switch
it
to
arm
and
see
what
projects
are
building
and
deploying
on
arm
which
ones
support
arm
at
this
at
this
moment,
and
the
same
is
true
for
kubernetes,
head
and
communities
arm.
A
The
C&C
FCI
projects
consists
of
the
CI
testing
system,
a
status
repository
server
and
that
user-facing
dashboard
at
scene
CFC.
I,
the
testing,
stayed
the
testing
system
validates
the
building's
employment
of
each
project
for
stable
and
hedonic,
say
six
an
arm
and
the
testing
system
will
be
able
to
reuse
existing
artifacts
from
the
project's
preferred
CI
system.
It
can
also
generate
new,
build
artifacts
and
the
status
repo
collects
those
test
results
and
the
dashboard
displays
them.
A
The
goals
of
the
dashboard
are
to
complement
the
CNC,
F
landscape
and
trail
map
and
promote,
since
they
have
hosted
projects
to
help
attract
more
projects
to
join
the
CNC
F.
We're
also
demonstrating
the
use
of
cloud
native
technologies
and
we'd
like
to
get
feedback
from
cloud
native
end
users
and
projects,
and
this
provides
a
third-party,
unbiased
validation
of
the
builds
deploys
and
ends
end
tests
for
the
same
CF
graduated
and
incubating
projects.
A
Currently,
the
key
features
of
the
current
iteration
of
the
scene,
CFC
I
dashboard,
is
that
it's
project
centric
we're
highlighting
and
validating
the
hosted
graduated
in
incubating
projects,
so
we're
putting
the
project's
front
and
center
and
we
wish
to
increase
collaboration
with
the
scene.
Cf
project
maintainers.
So
as
we'll
see
what
is
in
progress,
we're
refactoring
how
builds
deploys
an
end-to-end
tests
are
currently
retrieved
from
the
dashboard
and
we'll
be
integrating
into
the
project's
own
CI
system,
and
it's
also
agnostic
testing.
A
There
were
validating
the
projects
and
configurable
test
environments,
and
those
configurations
are
currently
the
kubernetes
release
the
architecture
and
we're
running
on
bare
metal
packet.
We
could
run
on
another
provider
bare
metal,
for
example,
so
that's
a
quick
intro
and
here's
what
we've
been
working
on
in
the
past
month,
so
we
recently
released
v2
5.
A
On
July,
9th
and
we've
implemented
supporting
different
scenes,
the
FCI
environments
reach
project
configuration.
We
also
have
changed
where
the
release
details
are
retrieved
for
C&C
FCI
to
allow
for
more
collaboration
and
external
contributions,
and
we've
added
those
sub
headers
to
display
the
projects
by
graduated
incubating
and
Linux
Foundation.
A
So
the
release
details
are
regarding
the
project's
latest,
stable
release
or
the
project's
latest
commit
on
the
master
branch
and
a
C&C
F
project.
Maintainer
can
update
the
release
details
by
going
to
cross
called
CI
on
get
up
opening
up
the
appropriate
project
configuration
repo
for
their
project,
opening
up
the
scene,
CFC
idml
file,
editing
it
to
update
the
stable
ref
and
the
head
ref
as
needed.
So
we
can
take
a
look
at
core
DNS
as
an
example.
A
And
so
we
have
refactored
the
column
1
the
project
column,
where
a
project
maintainer
could
update
the
logo
name
caption,
as
well
as
the
hyperlink.
This
currently
goes
to
the
accordion
s
github
repo,
our
next.
The
next
step
was
to
update
the
release
column,
where
we
have
completed
how
to
update
the
stable
and
ahead
releases
next
or
in
progress
is
the
build
column.
So
that's
what's
in
progress,
ok,
so
that
in
just
a
second,
so
we
also
can
we
also
supported
different
scenes,
the
FCI
environments
for
each
project
configuration.
A
We
also
resolved
an
issue
with
our
gait
lab
license
disabling
the
get
mirroring,
so
the
information
on
scene,
CFC
I,
was
instead
of
refreshing
every
day
at
3
a.m.
Eastern
time
the
license
had
expired,
and
so
the
information
on
since
the
FCI
was
about
6
days
old
and
growing.
So
we
had
help
from
the
get
lab
folks
and
we
had
an
extension
of
our
trial,
and
so
that
will
resolve
the
issue
with
the
disabled,
get
mirroring
everything's
up
to
date,
now
refreshing
every
day
at
3
a.m.
and
the
next.
A
A
We
are
refactoring
the
CI
on
scene,
CFS
di.
We
currently
are
certaintly
used
a
kubernetes
provisioning
tool
that
was
customized
in-house,
called
the
cross
cloud
provisioner
and
we're
switching
from
maintaining
the
cross
cloud
to
kubernetes
provisioner
to
using
cube
spray
and
kinds
with
cube
ADM.
So
it
started
the
refactor
epoch
several
steps.
The
goal
is
to
add
support
to
use,
cube
ATM
for
bootstrapping
kubernetes
clusters
on
the
packet
we
needed
to
update
how
to
provision
Hardware
so
how
to
provision
those
packet
resources.
A
A
B
Sure
this
is
Taylor
and
if
Denver
your
audios
working,
you
can
be
given
update
as
well.
Thanks
for
the
overview
Lucian,
the
cube
spray
being
able
to
create
clusters
on
packet
with
cube
spray.
That
portion
is
done
so
we'd
call
this
like
the
minimal
set
up
and
because
our
the
goal
for
us
is
to
support
stuff
like
at
a
kubernetes
infrastructure
level
being
able
to
plug
in
different
projects,
essentially
cRIO
as
a
runtime
and
as
well
as
container
D
and
use
other
configuration.
That's
a
good
fit
for
something
like
cube.
B
Spray
and
kind
is
very
helpful
if
we
want
to
do
fast,
iterations
and
set
full
separation
of
the
clusters.
First
I
will
say
application
level
projects
that
are
running
on
public
kubernetes,
which
should
be
the
majority
of
the
incubating
incubating
graduated
and
what
will
be
sandbox
projects.
So
we're
designing
this
so
that
we
can
support
both
and
that's
idea
with
the
plugins.
So
it's
essentially
a
very
small
wrapper
that
can
decide
on
using
Q
spray
or
kind
with
cube
spray.
We'd
normally
be
creating
multiple.
B
We
would
provision
multiple
physical
machines
in
the
hardware
stage,
which
has
happens
before
this.
We
could
do
a
single
machine,
but
the
idea
is
multiple
and
then
what
kind
we
could
run
everything
potentially
on
one
machine
which
would
allow
stuff
like
debugging.
If
a
project,
let's
say
fluently,
wanted
to
test
something,
we
could
easily
have
a
cluster
spin
up
and
not
worry
about
a
large
number
of
packet
machines
every
time.
B
So
that's
kind
of
the
idea
here
and
breaking
this
into
pieces
and
the
one
one
thing
that
I
was
just
saying
that
provisioning
the
hardware
provisioning
stage
it
is
complete.
We
did
separate
that
out
from
the
Waycross
cloud
work,
so
a
cross
pod.
You
would
run
it
and
it
would
actually
allocate
the
machines
with
whatever
cloud
provider
and
then
immediately
go
into
provisioning
kubernetes
using
it
was
custom,
dropping
the
all
of
the
manifests
and
everything
for
kubernetes
with
the
new
setup.
B
We
have
it
completely
segmented
off
so
those
physical
machines
and
be
allocated
and
reuse
separately.
So
if
we
want
to
reset
them,
which
is
a
built-in
feature
with
cube
spray,
where
we
can
reset
the
machines
to
before
kubernetes
was
set
up,
we
can
do
that.
So
we
can
get
some
speed
F
in
the
CI
process.
We
can
also
fully
wipe
those
machines
and
and
hand
them
back
to
a
packet
school,
but
it's
a
little
bit
more
configurable
there
and
as
much
as
possible.
B
We're
sticking
with
trying
to
not
have
anything
custom
on
the
cube
spray
kind
side,
but
see
where
we
can
provide
upstream
PRS,
and
that's
where
the
we're
saying
is
arm
support
is
actually
pretty
generic
at
Denver.
If
you're
there.
Maybe
you
could
speak
to
that
if,
if
you're
available,
I
can
give
a
quick
overview,
but
if
you'd
like
to
give
them
a
go
into
that
a
little
bit,
what
we're
doing
a
cube
spray.
B
Okay
looks
like
Denver
sent
me
a
message
to
audio.
You
may
not
be
coming
through
because
I'm
not
hearing
him,
so
the
main
thing
with
cube
spray,
which
we've
again
trying
to
create
PRS
upstream
for
everything
and
provide
test
or
whatever
changes.
We've
added
support
for
doing
a
external
image
repositories
for
the
containers
that
cube
spray
would
use
as
well
as
it
already
supported
the
I
guess,
the
tags
and
different
tags
and
and
images
that
you
could
choose.
So
the
main
thing
was
repositories.
B
We
did
this
primarily
to
get
arm
support,
but
what
it
allows
us
to
do
is
select
different
types.
So,
if
maybe
cube
spray,
doesn't
support
kubernetes
115
release
or
something.
If
it's
a
little
bit
ahead,
then
you
can
actually
select
those
by
specifying
the
specific
tags
that
may
not
be
built-in
and
cube.
Atm
actually
supports
those.
So
that's
fine.
It's
a
cube
spray.
B
Basically,
what
is
the
current
most
tested
stable
and
it's
a
little
bit
behind.
So
that's
the
primary
support.
It
does
get
us
to
be
able
to
add
arm
support
as
well
by
using
the
arm
binaries
that
are
available
upstream
and
if,
if
we
continue
to
need
to
support
any
of
specific
images
for
specific
builds,
that
may
not
be
available
upstream.
Well.
That
allows
us
to
do
that
as
well.
B
So
if
we
say
wanted
to
build
a
version
of
kubernetes
with
a
specific
plug-in
or
something
that
may
not
be
available
upstream,
we
could
still
use
the
same
the
same
framework
and
be
able
to
specify,
say
the
scenes
FCI
registry
or
if
there's
some
other
one
like
maybe
cube
or
Nettie's
testing
sig,
has
something
released.
We
can
do
that,
so
it's
it
should
be
a
pretty
easy
or
I.
B
Think
anybody
that
uses
cube
spray
to
be
able
to
use
custom
registries
and
and
custom
images,
along
with
the
defaults
that
are
built
in
kind,
will
be
kind
of
a
similar
as
a
similar
type
of
thing.
Where
we're
extending
this
a
court
that
it
has
and
we're
also
talking
with
them
about
what
specific
container,
runtimes
and
other
things
that
they're
planning
to
support
so
that
we
can
focus
on
either
helping
them
directly
on
those
and
getting
it
sooner
in
place
or
adding
support
for
the
parts
that
may
be
further
out
in
their
queue.
B
Does
anyone
have
any
questions
about
this
specific
part
of
the?
This
is
the
back
end,
essentially
of
San
CFC
I,
to
go
back
to
it.
There's
your
CI
platform.
This
would
be
similar
to
your
pipelines
and
other
things
you
can
see
in
Travis
or
anywhere
else,
and
then
there's
the
different
stages
for
creating
the
clusters,
which
is
this
that
what
we
were
just
talking
about
and
then
on
top
of
this
is
a
status
repository
and
then
the
actual
dashboard
that
displays
and
and
shows
all
of
that.
B
A
Thanks
Taylor
for
that
information,
it's
a
big
epic,
but
we
are
making
our
way
through
and
making
good
progress.
The
next
epic
that
we
are
also
making
progress
on
is
adding
support
for
external
contributions,
changing
how
information
is
fed
into
the
CI
system
and
status
repo
in
the
dashboard
to
allow
for
external
contributions
and
adding
and
maintaining
projects
faster.
A
A
A
We
decided
to
look
at
Travis
CI
and
look
at
what
projects
are
hosted
by
CN
CF
and
on
Travis
CI
and
on
the
dashboard
we
currently
have
linker
D,
which
points
to
the
original
link,
original
linker
D
project
and
linker
D
has
released
linker
d2
so
to
move
forward
with
two
goals
at
one.
We
are
adding
the
linker
D
to
project
to
C&C,
f,
CI
and
building
the
integration
with
the
linker
T
Travis
CI
system.
A
A
So
we've
started
adding
the
project
details
for
linker
d2
and
confirm
what
the
linker
d2
team
that
they
would
like
it
to
read:
lingered
2,
dot
X.
So
we've
created
a
new
configuration
file
for
linker
D
2.
There
also
exists
a
linker
D
configuration
file,
so
we
built
a
new
one
in
that.
Has
the
project
details.
So
it
has
the
logo
URL,
which
is
fetched
from
the
scene.
Cf
artwork
file,
the
display
name,
linker
T,
2
X.
The
subtitle
remains
the
same
service
mesh.
A
It
was
showing
as
Travis
CIO
aargh
link
or
dealing
critique,
so
that
information
is
all
helping
us
with
project
and
release
columns
on
the
dashboard.
So
next
we
can
take
a
look
at
pull.
Request
number
5
opened
yesterday
by
Taylor
Taylor.
Do
you
want
to
walk
us
through
some
of
the
files
changed
here
and
how
we'll
reuse
this
information
with
other
CN
CF
hosted
projects
going
forward.
B
Sure,
I
guess
I'll
start
a
little
bit
with
plan
here
for
this
build
column.
So
all
of
this
is
related
to
the
on
the
Santi
F
dash
board
the
built
column
and
for
all
projects
other
than
own
app.
B
The
build
column
is
pulling
the
status
information
for
the
compiles
and
running
the
unit
tests
and
whatever
the
artifact
creation.
That's
all
within
the
CN
CF
CI
build
system
which
is
a
get
lab
pipeline.
That's
what
all
of
this
is-
and
you
can
click
like
this-
is
doing
and
then
you're
on
the
project
itself.
So
this
would
be
similar
to
any
other
CI
system.
So,
whether
you're
running
your
own
get
lab
pipelines,
travis
circle
CI,
whatever
you
may
be
using
and
for
CN
CF
CI,
we
were
replicating
what
was
done
by
the
projects.
B
Accordion
s
has
their
NCI
that
they're
running
and
doing
their
own
tests,
and
we
would
look
at
that
and
then
have
to
essentially
copy
everything
over
and
get
that
going.
There's
some
specific
reasons
to
get.
Maybe
the
the
build
artifacts
that
we
needed
that
weren't
available
at
the
time
when
this
was
started
as
well
as
specific
builds
of
different
architectures,
but
the
end
goal
is
where
we're
going
now
is
to
try
to
integrate
with
those
existing
systems.
B
So
that's
what
in
progress
here-
and
this
is
an
example
of
what
we're
saying
a
project
could
can
add
configuration
to
for
integrating.
So
this
CN
CF,
CI
e
mo
would
be
similar
to
like
a
Travis,
CI
or
circle
CI.
It
could
potentially
be
in
in
a
projects
repo
right
now
it
lives
in
what
we're
doing
is
a
per
project
configuration
repository.
B
It
could
be
a
copied
over.
So
what
we
have
here
is
a
section
where
we
can
define
different
CI
system
set
of
project
uses
and
the
first
two
items
are
that
what
we
seen
already
went
over,
what
is
the
CI
system
type?
What
is
actually
URL
to
the
project,
the
additional
pieces
that
we've
started
to
add
or
what
is
the
architecture?
That's
actually
used
on
this,
so
linker
d2
right
now
from
what
we've
seen
the
pipeline
that
we're
referencing
builds
amd64.
B
So
if
they
add
arm
to
this,
we
could
add
another
architecture
in
that
list.
If
they
don't
add
arm,
possibly
we
would
be
adding
it
somewhere
else
in
the
time
being,
or
maybe
I
know
that
arm
themselves
are
working
with
projects
and
they
have
they've
been
using
a
CSS
at
a
different
CI
system.
So
this
would
allow
us
to
actually
add
multiple
CI
system
integrations.
B
This
is
important,
because
the
next
stage
that's
seen
on
the
dashboard
is
the
app
deploy.
So
where
do
we
get
those
artifacts
and
from
our
standpoint
I'm
on
the
CI
side,
we
don't
consider
a
build
to
be
successful
unless
the
artifact
was
created
successfully
and
published,
and
we
verified
that
you
can
access
it.
So
if
someone's
done
a
full
build,
but
there's
no
binaries
or
nothing
that
you
can
actually
use,
then
we're
trusting
we're
only
trusting
the
system
status,
but
not
that
there's
anything
usable.
B
B
We're
supporting,
commit
cha
hash,
and
this
is
specifically
the
NA
character
written,
which
seems
to
be
the
common
one,
that's
spit
by
if
you're
running,
to
get
command-line
tools
which
a
lot
of
projects
seem
to
be
using
when
they're
creating
the
tax.
So
this
is
a
match
for
there
and
what
we're
doing
is
allowing
this
to
be
essentially
a
variable.
So
if
someone
wanted
to
tag
with
just
two
commits,
that's
fine,
they
could
have
different
strings
on
here.
B
That's
what
we're
supporting
right
now,
if
hooks
want
either
I
guess
data
available,
then
we'd
love
to
hear
hear
back
right
now.
The
idea
is,
we
would
want
ideally
every
project
to
create
at
a
minimum
a
additional
tag,
since
you
can
do
multiple
tags
on
images
that
are
pushed
that
have
the
get
commit
so
that
we
can
tie
it
to
a
specific
pipeline
and
build,
and
this
goes
all
the
way
back
to
the
dashboard.
So
we
can
say
here's
a
commit.
B
That's
on
the
git
repo,
which
is
on
the
left
hand,
side
or
at
the
top
you
see
stable,
ref,
that's
the
that
is
what
linker
d2
is
using
for
both
tagging
and
get
as
well
as
tagging
and
docker
images.
That
seems
to
be
the
case
for
the
CNC
F
projects
that
we've
been
looking
at,
that
are
publishing
containers
if
they
have
a
release
and
they
tagged
it
and
get
they've
tagged.
They've
created
a
tag
on
a
docker
image
that
they've
also
published.
B
So
this
is
in
progress.
This
is
about
the
configuration
from
an
end-user
side.
What
would
linker
d2
do
if
they're
going
to
maintain
it,
modify
this
sort
of
things
and
then
what
would
be
behind
the
Saints
which
we're
working
towards?
Is
the
integration
directly
with
Travis
for
checking
the
status
that
you're
saying
based
on
those
URLs
in
using
the
Travis
API
and
then
going
to
whatever
the
container
registry
so
for
right,
image
registry?
C
C
All
right,
this
is
ad
from
packet.
Do
you
have
a
list
of
target
CI
systems
beyond
Travis
and
circle
that
you
mentioned,
or
is
that
primarily
driven
by
the
CI
systems
that
the
project's
actually
already
used.
B
B
Since
we
have
most,
it
were
primarily
working
on
the
incubating
now
at
this
point,
and
we
do
have,
they
graduated
will
kind
of
be
going
back
to
the
projects
that
are
currently
running
on
on
the
dashboard
and
moving
from
internal
CI
to
external
integrations,
and
the
integrations
themselves
will
be
driven
by
those
projects
that
thing
that
the
code
and
how
we're
doing
this
is
is,
of
course,
all
open-source
we're
trying
to
use
as
much
upstream
like
the
cube
spray
and
other
staff.
The
integrations
themselves.
B
Think
Matt
Spencer
from
armed
talking
about
a
river
for
use
on
a
lot
of
the
armed,
builds
and
directly
working
with
projects
for
adding,
essentially
as
an
additional
pipeline
that
does
arm
built.
Since
often
the
projects
are
only
doing
full
testing
and
and
container
publishing
for
x86,
so
there
it
might
be
something
where
Rover
would
maybe
be
a
good
contribution
external,
maybe
from
arm
to
add
support
for
that
and
that
ties
directly
and
with
that
multiple
CI
systems
for
project
the
support
that
we're
trying
to
account.
B
A
All
right,
I'll
wrap
up
this
section
so
that
the
next
presenter
can
have
the
time
for
their
intro
and
roadmap.
So
what's
next
on
scene,
CFC
I
will
be
continuing
on
the
epics
that
we've
been
working
on
the
CI
refactoring
be
creating
that
kubernetes
provisioning
wrapper.
Next,
adding
support
for
external
contributions
will
be
wrapping
up
the
build
integration
with
linker
d2
on
Travis
CI
and
then
starting
on
the
app
deploy
phase
with
linker
d2,
we'll
continue,
adding
linker
t2,
so
the
app
deploy
phase
and
using
their
container
artifacts
that
are
published
and
updating
the
documentation.
A
Accordingly,
we're
also
doing
some
maintenance.
Some
software
updates
on
the
various
system,
various
repos
of
the
system
for
more
information
about
the
C&C
FCI
project.
You're
welcome
to
take
a
look
at
the
intro
to
C&C
FCI,
slides
from
cube
crown
Europe
2019
in
Barcelona,
as
well
as
the
deep
dive
slides
available.
A
We
welcome
your
feedback
to
do
that.
You're,
welcome
to
add
an
issue
to
the
cross
cloud:
CGI
dashboard,
github
repo.
Please
join
the
CNC
app
slack
channel
since
the
FBI
can
send
us
an
email
if
you'd
like
please
join
the
public
mailing
list
and
we
meet
on
the
4th.
Tuesdays
I
had
12
noon.
Pacific
time,
we're
also
on
Twitter
scene,
CF,
CI.
A
D
D
D
We
are
own
core
contributors
in
CN
CF
estates,
prognathous
for
arm
with
its
use,
kisses,
bye,
:,
why
conservation
arm
other
manager,
adding
exporters
building,
did
land
for
CI
process?
We
are
looking
to
contribute
more
into
Ciencias
so
listener.
Can
you
please
help
us
how
we
can
contribute
more
into
this.
A
A
Wonderful,
what
is
it
that
you
would
like
to
help
contribute
with.
D
E
E
Way
too,
so,
just
let
me
give
the
basic
background
like
where
we
came
and
how
we
like
started
contributing
into
CN
CF
like
we
are
a
cool
contributor.
Apart
from
our
product
like
which
is
the
cloud
brain
as
Shiva
mentioned,
we
provide
the
migration
to
Alibaba
guava
and,
as
you
run
AWS
apart
from
that,
we
are
a
contributor
in
open
labs,
hashey
core
and
some
of
the
like
open
labs
and
CNC
a
project,
so
any
line
who's
the
director
of
ciencia.
E
She
asked
us
to:
let's
provide
the
support,
basically
on
arms,
like
testing
on
diff
all
the
projects,
whatever
the
incubator
or
graduated
projects
on
app.
So
that
is
the
first
agenda
that
we
wanted
to
test
all
the
products.
Second,
is
we
have
few
customers
who
wanted
to
like
open
source
their
project
under
C
and
C
F
umbrella?
So
we
are
also
wanted
to
like
give
the
entire
updates
of
how
we
can
contribute
becoming
an
adviser
under
the
CN
CF
umbrella.
So
there
are
two
different
I
mean.
E
A
A
Thank
you
for
the
background.
Let's
see
I'm
trying
to
think
of
some
references
that
the
scene
CF
has
given
projects.
There
is
if
a
one
of
your
customers
wants
to
become
a
scene
CF
project
and
become
open-source,
there's
a
process
to
create
a
pull
request
and
present
to
the
TOC
to
possibly
be
included
as
a
sandbox
projects
or
to
be
become
an
incubating
project.
So
I
could
share
that
link.
It's
on
the
scene,
see
of
TOC
iPhone.
E
Community
meetings
are
both
meeting
where
we
can
present
all
project
details
like
that
project
has
been
already
open-source,
but
it's
not
yet
contributed
in
any
of
the
like
sandbox
or
integrator.
So
we
wanted
to
get
a
couple
of
project
under
this
umbrella.
So
maybe
we
have
like
more
projects
pipeline
in
future,
but
guidelines
have
really
appreciated
absolutely.
A
I'll
share
the
guidelines
with
you.
I
know
the
TOC
has
a
backlog
of
potential
projects,
and
so
you
will
be
able
to
take
a
look
at
the
instructions
and
go
through
the
the
process
that
way
through
the
TOC
and
the
TOC.
The
technical
Oversight
Committee
of
the
cloud
native
computing
foundation
meets
three
times
a
month
and
so
through
their
github
repo
I'll
share
that
in
the
zoom
chat
for
you
and
that
will
have
more
information
on
dates.
A
A
That
looks
great
yeah
I'm
clicking
through
the
TOC.
Oh
I'm,
not
sharing
my
screen,
so
I
can
share
my
screen
and
show
you
where
I'm
going
I'm
in
github.com,
slash
scene,
CF,
TOC
and
I
click
on
proposals,
however,
that
may
not
be
the
best
place
to
start
best
place
to
start
is
usually
seen:
CF
dot,
IO
the
main
CNCs
landing
page.
A
E
B
And
so
one
thing
to
look
at
is
the
different:
the
working
groups
have
their
supporting
many
different
projects
and
the
CI
working
group
and
this
CN
CF
CI,
is
one
initiative.
That's
part
of
this
working
group,
CNC
FCI,
is
providing
a
dashboard,
fourths
and
ZF
that
highlights
the
different
projects
and
helps
with
promoting
them.
It's
not
say
a
CI
system,
that's
taking
over
all
of
the
projects.
So
if
you
are
looking
at
something
like
helping
a
project,
a
saint,
you
have
project
to
support,
multi-cloud
or
something
beyond.
B
This
could
be
something
that,
if
you
reached
out
to
CNCs
staff
directly,
maybe
through
the
help,
the
help
desk
link,
which
is
also
on
that
services
or
the
maintenance
of
TIA
San
fee-fi
o,
then
that
could
help
with
getting
some
direction
if
you're,
if
you're
talking
about
multi-cloud
support
the
CNC
FCI
project
itself
isn't
actually
looking
for
that,
we
actually
removed
that
feature.
It
was
supporting
multiple
clouds
at
some
point,
but
that's
not
the
focus
on
the
dashboard
itself.
E
B
Look
looking
at
the
specific
CNCs
projects
itself
and
seeing
which
may
you
know
I
would
I
would
suggest
actually
looking
at
the
each
project
and
then
Singh
where
it
would
be
a
good
fit
because
CNCs
is
it's
both
hosting
as
far
as
projects
that
are
officially
supported
from
graduated
incubating
and
then
sandbox
for
potential
those
it's
covering
a
lot
of
areas,
and
so
the
multi
cloud
may
or
may
not
fit.
But
if
you'll
go
and
look
at
those,
you
can
probably
see
where
it
might
be
a
good
fit
and
then
the
other
pace
place.
B
B
Various
projects,
groups
and
then
companies
are
providing
services
and
we're
what
click
the
cloud
is
doing
might
fit.
I
know
that
CN
CF
wants
to
wants
to
make
any
type
of
vendor
or
project
findable
or
viewable
in
the
landscape.
So
if
you
could
actually
look
and
kind
of
think
what
are
you
providing
and
what
are
you
trying
to
do
and
that
would
guide
you
on
being
able
to
communicate
what
you
actually
how
you
could
help
the
various
Sancerre
projects?
It's
very
large.
B
But
the
main
thing
here
is
on
the
left
that
what's
listening
is
showing
you
can
select
categories
and
other
stuff
there's
what
type
of
work
you're
going
to
be
providing.
So
if
you
can
do
some
of
that
and
then
look
ahead
once
you're
talking
to
the
the
appropriate
people
and
say
MTF
you'd
be
able
to
communicate
here
so
the
type
of
projects
that
we
can
help
with.