►
From YouTube: CNCF Telecom User Group Meeting - 2020-06-01
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Sounds
good
well,
we
can
get
started
so
this
is
telcom
is
a
group,
and
this
is
the
15
utc
or
8
a.m.
A
Pacific
time
call
that's
going
to
be
happening
every
other
month,
we're
switching
from
the
twice
monthly
to
every
other
well
to
once
a
month
where
the
call
time
is
going
to
switch
monthly,
so
next
month
same
first
monday
will
be
the
11
am
etc
or
7
pm
china
standard
time
call
same
zoom
if
we
there's
a
lot
of
sub
groups
and
related
collaboration
with
other
groups,
and
we
thought
a
once
a
month
would
should
be
a
good
fit.
A
Well,
so
right
now
we
have
two
topics:
I'm
going
to
give
an
intro
and
a
status
update
on
the
cnf
conformance
and
then
there's
the
discussion
about
management,
plane
and
installers
for
cns
and
how
that's
related
to
other
topics
at
other
groups
and.
A
A
Some
of
the
benefits,
I
think,
overlap
with
other
groups
that
we
already
think
about
this
efficiency
of
using
a
cloud
native
platform,
and
all
of
these
things,
the
the
part
to
maybe
point
out.
That's
a
little
bit
different
on
the
cnf
conformance
versus
some
of
the
other
groups
is
feedback
for
development,
so
that
we
can
look
at
how
to
improve
both
the
cns
for
the
application
development,
as
well
as
the
platforms
and
getting
feedback
to
that
and.
B
A
C
A
All
right
so
some
definitions.
We
have
a
definition
that
we're
following
for
the
cns
or
the
applications,
and
this
has
been
shared
with
many
of
the
groups,
and
this
is
based
on
the
white
papers
around
cloud
native
principles.
A
A
So
the
plan
to
go
back
where
we
were
is
to
help
both
the
cnf
developers
to
demonstrate
conformance
and
implementation,
as
well
as
provide
that
feedback
so
that
they
can
improve
the
software
and
then
ideally,
operators
can
have
test
results
that
they
can
use
when
they're
considering
what
software
they
want.
This
is
going
to
be
part
of,
I
think,
a
multitude
of
testing
when
you're
looking
at
the
operators
that
they
care
about
and
cloud
native
would
be
one
of
the
aspects
that
that
will
come
into
play.
A
A
A
This
is
on
github
and
we're
leveraging
upstream
tests
and
test
suites,
which
gives
us
a
possibility
of
integrating
and
working
with
other
projects
like
opnfv
and
ovp,
which
have
different
tooling
and
allow
us
to
contribute
upstream.
Any
fixes
that
we
may
find
the
framework
itself
does
support
both
workload
and
platform.
A
Although
most
of
the
tests
right
now
have
been
about
the
workload
or
testing
specific
cns,
but
the
framework
we
will
be
able
to
use
to
test
platform
and
there's
going
to
be
a
lot
of
tests
that
require
specific
platforms,
maybe
for
the
applications
or
the
workload
to
run
so
we'll
be
able
to
see
more
of
that
as
we
go
on
and
then
the
instructions
so
implementation
and
time
with
the
goals.
So
what
we're
looking
at
is
something
that
a
cnf
developer
specifically
could
quickly
get
going
and
use
the
software.
A
So
you
should
be
able
to
follow
the
instructions
and
bring
up
the
whole
suite
and
start
testing
if
an
application
that
you're
writing
quickly
and
test
it
in
various
environments
is
the
goal
there
and
the
test
suite
itself
and
the
way
that
this
is
being
run.
We
have
all
of
the
test
suite
running
in
a
ci
pipeline
and
this
is
allowing
us
to
more
quickly
iterate
on
tests.
A
Add
new
tests,
hopefully
start
getting
contributors
externally
to
contribute,
and
we
have
all
prs
and
merges
are
tested
in
the
ci
so
that
we
can
validate
if
something
changes
and
breaks
so
that
we
can
have
more
confidence
in
the
test
results
and
also
speed
up
development,
the
scoring.
So
this
goes
back
to
not
only
feedback
for
the
developers,
but
also
the
operators,
it's
very
configurable
and
it's
external
to
the
tests
themselves.
A
It's
a
yaml
configuration
file
that
allows
us
to
go
in
and
if
we
discuss
a
specific
test
that
we
may
want
to
have
a
higher
score,
it's
more
it's
something
that
we
say
as
a
group,
and
this
would
be
where
we
want
collaboration
from
specifically
operators,
but
cnf
developers,
vendors
and
everybody
as
well.
If
a
specific
property
or
a
cloud
native
principle
is
a
hard
requirement,
we
could
say
this
gets
a
higher
score.
A
A
We
have
both
static
and
runtime
tests
that
are
there,
so
we
can
actually
test
before
you
start
running
a
workload
on
a
platform.
You
can
also
deploy
a
workload
and
test
that
there's
a
mvp
set
of
workload,
tests
that
are
complete
and
some
that
are
in
progress,
we'll
go
back
to
that
here
in
a
minute
and
we
have
a
set
of
install
instructions
for
both
cnf
developer
that
are
pretty
straightforward.
A
So
here's
a
quick
look
at
the
mvp
set
of
tests,
so
we're
looking
at
is
what
are
the
plan
here
is
to
have
releases
where
we
can
say
here
is
what
we
have
covered
so
far.
We
expect,
based
on
feedback,
to
continue
to
add
new
tests,
as
well
as
to
prioritize
different
aspects
of
the
workload
and
platform
that
we
would
want
to
test.
A
So
this
is
an
initial
set
that
we've
picked
out,
based
on
the
ability
to
say,
let's
get
these
completed
and
they
should
provide
some
feedback,
and
these
are
covering
the
different
categories
that
we
showed
earlier.
So
microservice
compatibility
doesn't
have
anything
right
now,
stateless
though
security,
scalability,
etc,
resilience,
these
and
yellow.
These
are
the
ones
that
are
in
progress
and
we'll
be
bringing
pretty
soon.
A
These
some
of
these
are
leveraging
the
litmus
chaos
project
so
upstream
test
and
there's
all
these
others
also
leverage
upstream
tooling,
so
the
next,
whatever
the
version
number
here
is.
These
are
just
examples,
but
the
next
set
of
tests,
here's
what
we're
looking
at
and
what
I'm
not
showing
here.
These
are
all
workload
tests,
but
what's
coming
and
we're
planning
right
now,
I'm
getting
feedback
and
talking
following
the
cnt
efforts
and
other
things
or
what
the
platform?
A
A
C
No,
I
I
think
one
question
that
came
up
and
you
might
want
to
get
to
it
later,
actually
is
about
the
two
sides
of
the
test
suite
where
I
think
you've
been
focused
mainly
on
the
part
that
runs
on
the
the
cns
themselves.
That
looks
at
the
artifact
and
and
confirms
that
it's
acceptable,
but
I
I
was
hoping
you
could
also
describe
the
part.
That's
confirms
that
the
platform
is
compliant
and
is
built
on
top
of
the
existing
kubernetes
conformance
suite.
A
Up
I
kind
of
jumped
past
this
slide
earlier,
but
this
would
address
part
of
that.
So
the
whole
initiative
for
the
cnf
conformance
is
based
on
the
kubernetes
conformance
program,
which
is
you
could
really
think
two
parts.
So
the
kubernetes
conformance
program
is
has
there's
a
certification
piece
that
uses
the
test
suite
and
then
there's
the
test
suite
itself
and
that's
primarily
what
you
hear.
A
We
actually
have
wrapped
and
can
run
and
we'll
run
the
the
sauna
boy,
kubernetes
conformance
on
against
the
platform
that
we're
testing,
and
then
we
will
have
additional
tests
beyond
that.
So
the
very
first
thing
that
we
want
on
any
cloud
native
telecom
platform
is
that's
running
kubernetes.
Does
it
pass
kubernetes
conformance?
That's
the
very
first
thing.
So
if
you
have
a
kubernetes
certified
platform,
then
that
means
you
should
have
already
passed
the
kubernetes
conformance
and
then
beyond
that
we'll
be
looking
at
additional
tests.
A
Some
of
those
may
run
from
say
the
kubernetes
ed
test.
There
are
ede
tests
which
cover
some
items
that
we
care
about,
and
cntt
specifically
cares
about.
There's
a
in
the
platform
requirements
where
we
can
use
a
kubernetes
zde
test
to
validate
some
of
those
things
and
then
beyond
that,
there's
many
other
tools
and
stuff
that
we
want
to
pull
together.
So,
in
the
end,
we're
going
to
aggregate
the
kubernetes
conformance
and
many
other
testing,
and
some
some
may
be
written
somewhat
from
scratch
to
cover
those
so
that
we
cover
platform
as
well
as
workload.
A
And
I
heard
someone
else
a
moment
ago:
did
someone
else
have
a
question
or
comment
either
one.
B
A
Regarding
security
tests,
so
right
now,
as
you
see
in
the
in
the
mvp
set,
there's
only
one
test,
this
one
is
finished.
This
is
a
as
does
it
run
in
privilege
mode.
This
particular
test
is
not
a
just
a
pass
fail
which
I
can
get
back
to,
but
we
do
have
a
much
larger
list
of
tests
that
we're
planning
and
ideas
for
tests.
So,
if
you
have
in
the
future,
so
we
definitely
want
to
expand
on
this.
A
A
What
we're
trying
to
do
is
get
this
down
to
here's.
The
first
set
that
we're
we're
completing
now
and
then
what
is
the
next
set
that
we're
thinking
about
the
next
set?
Potentially,
we
could
shift
around
if,
if,
if
someone
said
here's
a
security
one
and
it's
something
that
is
well
defined,
it
doesn't
have
any
blockers
because
of
maybe
there's
some
implementation,
that's
not
available
yet,
but
if,
if
you
have
any
thoughts
on
security
or
any
other
ones,
then
we'd
be
happy
to
hear
them.
E
Yeah
to
add
a
little
bit
to
that
as
well,
when
the
young
privileged
bit
gets
you
a
long
way
in
kubernetes
and
at
least
from
the
application
and
as
a
generic
application
running
on
kubernetes
kubernetes
itself
already
has
a
large
test
suite
in
regards
to
what
can
an
application
do
or
or
not
do,
and
of
course
it
doesn't
cover
anything
about
what
the
applications
themselves
and
so
that
that
may
be
a
gap
that
you
may
want
to
to
bring
up
and
try
to
identify.
E
A
Topics
I'm
not
going
to
go
through
all
of
this,
but
just
a
quick
overview
as
part
of
working
with
cnt
and
other
groups.
A
We
started
saying:
what
can
we
do
to
share
the
knowledge
of
of
the
tests
that
we
think
are
important
from
cloud
native,
so
this
particular
one
is
looking
at
the
cnt
reference
architecture
requirements
and
then
looking
at
the
priority
from
a
cntt
perspective,
and
then
how
is
it
a
priority
for
testing
as
in?
Is
this
related
to
cloud
native?
Is
it
out
of
scope,
so
some
of
these
things
we're
at
least
saying
right
now
out
of
scope,
we're
not
looking
at
testing
ips,
ipsec
acceleration,
but
others
in
here
which
I'm
not
going
to
get
into.
A
This
is
a
public
document
shared
with
cnt
and
it's
it's
in
the
the
tug,
the
tug
meeting
notes.
Some
of
them
are
related
to
security,
and
we
have
either
pointed
out
potential
tests
and-
and
in
the
section
marked
cnf
conformance
notes,
you
can
see
this
area
or
we
may
have
mapped,
which
is
another
thing.
Is
this
something
that
we
see
as
covered
by
kubernetes
e
to
e
or
kubernetes
conformance
test?
A
So
if,
if
there
is
anything,
please
let
us
know
and
we
are
looking
at
stuff,
I
think
falco
assistig
projects
and
many
other
ones
we're
already
starting
to
use
and
tests,
so
we'll
be
going
beyond
the
privilege
mode
on
the
privilegement
itself.
Just
one
thing
to
point
out
that
we're
doing
beyond
simply
testing
does
a
pod.
Does
it
run
in
privilege
mode
or
not?
This
particular
test
allows
you
to
white
list
a
pod.
A
So
if
you
said
we
are
okay
with
this
single
pod
having
privileged
all
the
rest
of
them
in
the
workload
that's
running
are
unprivileged,
but
this
one
we
know
that's
one
where
we
can
allow
it
to
pass
and
then,
if
there's
a
workload
that
you
could
build
out
the
same
implementation
and
have
no
privilege,
maybe
we
give
it
more
points
and
then,
if,
if
you
don't
whitelist
or
anything
else,
maybe
we
give
negative
points.
So
this
is
going
back
a
little
bit
to
what
I
haven't
got
into,
but
the
scoring
itself.
A
So
the
flexibility
of
that
and
there's
going
to
be,
I
think,
a
lot
of
different
paths
on
many
of
these.
So
one
of
the
aspects
on
the
security,
the
privilege
mod,
is
something
as
frederick
said.
You
get
a
lot
from
that
by
covering
privilege
mode.
What
we
need
is
help
breaking
down
the
higher
level
security.
So
if
we
say
a
topic
that
doesn't
cover
down
to
a
pod
or
is
it
something
that
we
can
do
a
pass
fail
test
on?
A
We'd
want
to
break
down
those
topics,
but
if
you
have
thoughts-
or
you
want
to
brainstorm
on
that,
there's
several
places,
including
you
can
get
on
slack
and
you
can
reach
out
to
us
that
way.
The
scene
as
a
test
bed.
A
A
Several
documentation
that
have
been
published
the
place
to
get
started.
First,
I
would
say,
is
the
cnf
developer
installing
usage
guide?
This
is
all
part
of
the
this
is
published
on
github
and
there's
much
more
extensive
documents.
If,
if
you
want
to
go
into
the
usage
beyond
this,
but
this
particular
one
has
a
focus
more
focused
subset
going
over
the
prerequisites
and
the
general
setup
and
initialization
of
the
suite
configuring,
a
cnf
that
you
want
to
test
for
these
workload
tests.
A
A
This
will
continue
to
expand
right
now,
it's
a
a
pretty
simple,
straightforward.
Cnf,
a
yaml
file
that
covers
all
the
different
items
like
white
listing,
different
pods,
the
deploy
information,
published,
helm,
charts
and
other
things,
and
we
have
many
examples
as
cns
that
are
upstream
applications
that
we've
tested
those
configuration
files
are
in
the
repo.
So
you
can
look
at
those.
A
So
the
general
I'm
going
to
do
a
walk
through
this
is
a
general
usage
of
the.
If
you
want
to
test
as
a
cnf
developer.
So
this
is
you
have
a
application
that
you're
providing
some
type
of
network
services,
and
you
want
to
test
that.
The
focus
right
now
is
on
a
single
you
could
think
of
the
it's,
the
microservice
or
the
that
single
component
in
a
in
a
full
workload,
we'll
be
we're
slowly,
adding
support
for
larger
use
cases
or
multiple
cns,
and
maybe
you
call
them
service
chains
right
now.
A
So
you
need
a
platform
that
you're
going
to
test
on
and
at
the
moment
for
the
workloads,
the
workload
testing
we
have
been
able
to
support
kind.
So
that's
what
we're
showing
right
here.
We
also
have
tested
and
continue
to
test
on
bare
metal
clusters
on
packet,
so
those
seem
fine.
This
is
vanilla,
kubernetes
that
we're
showing
right
here
we're
not
using
any
additional
add-ons
or
like
cni's
or
anything
else,
though
we
have
tested
with
some
like
multis
and
other
things
for
testing
some
of
the
service
chains
and
we'll
have
more
extensive
examples
later.
A
But
right
now
the
focus
and
tying
in
with
mvp
is
a
more
simple.
Let's
focus
on
a
single
pod
and
make
sure
that
it
follows
cloud
native
principles.
So
if
you
have
access
to
a
cluster,
what
that
means
is
you
have
your
kubernetes
access,
information
and
you've
saved
that
to
a
file
or
somewhere,
where
you
can
set
your
cubeconfig
environment
variable
and
once
you
have
that
and
you're
able
to
access
the
kubernetes
cluster,
then
you
should
be
good
on
the
first
requirement.
A
A
The
next
is
also
pretty
straightforward.
We're
publishing
snapshot
releases
tied
in
with
the
passing
ci,
builds,
we'll
eventually
start
having
full
beta
releases
and
other
things,
and
those
are
on
the
github
release
page
and
you
can
install
a
binary
right
now.
It's
download
the
binary
and
make
it
executable
and
the
feature
will
possibly
have
some
type
of
installers
or
create
packages
for
different
platforms,
ubuntu
centos,
whatever
else
right
now,
it's
a
a
binary.
A
So
what
I
didn't
go
over
was
the
entire
test.
Suite
compiles
down
to
the
running
part
of
the
software
compiles
down
to
one
binary
and
this
you
can
go
and
if
you're,
if
you
care
about
it,
you
want
to
get
involved
as
test
filter
just
interested.
You
can
look
at
the
language
and
other
things
behind
this,
but
it
compiles
down
to
a
binary.
What
releasing
right
now
is
amd
64
static,
binaries
to
make
sure
that
it
should
run
on
as
many
machines
as
possible
that
are
amd
64.
A
and
we'll
look
at
providing
binaries
releases
for
other
platforms
based
on
interest
and
demand.
So
once
you've
downloaded
that
and
made
it
executable,
you
can
put
that
somewhere
in
your
path
or
you
could
run
it
from
wherever
you
downloaded
it,
and
the
next
step
is-
and
I'm
gonna
see
if
I
can
click
presenter
mode.
Let
me
know
if
this
doesn't
work
for
y'all.
A
It
should
be
a
little
bit
more
readable,
so
the
next
step
is
to
initialize
the
actual
conformance
suite
this
one
right
now,
since
we're
in
this
pre-beta
stage,
you're
seeing
a
lot
of
extra
output,
so
what
it's
doing
is
making
sure
that
it
has
all
of
the
dependencies
it
uses.
A
lot
of
upstream
software
like
helm
is
shown
there.
A
It's
downloading
those
make
sure
that
it
has
a
version
of
cube
cuddle,
that
it
expects
and
other
things
like
that
and
gets
whatever
other
base
configuration
ready,
including
downloading
the
default
published,
scoring
template,
which
is
on
the
the
repo
and
then
once
that's
ready.
Then
you
need
some
type
of
a
you
need,
a
configuration
that
covers
the
actual
test
run
and
right
now
again,
this
is
a
focused.
This
is
focused
on
the
cnf
that
you're
going
to
test.
So
this
example
is
using
coordinates,
so
cordiness
could
be
your
dns
service.
A
That's
part
of
your
any
workload
like
the
vcp
use
case
has
a
dns
server,
and
this
could
be
that
so
you're
going
to
configure
that
this
this
example
is
actually
a
few
weeks
old.
So
there's
some
more
information,
that's
going
to
be
in
there
and
you're
going
to
define
all
the
different
things
like
the
chart,
repo,
that's
you're,
pulling
from
there's
a
published
chart.
A
So
the
very
first
thing
that
we're
doing
right
now
that's
about
to
be
updated.
There
was
a
step
where
you
would,
if,
if
you're
wanting
to
deploy
the
pod
and
the
the
actual
cnf,
we
support
automatically
deploying
if
it
has
a
helm
chart
and
you
could
run
a
setup
command
with
the
configuration
file
and
it
will
ensure
it's
in
the
test
area.
It's
deployed
to
the
cluster.
Everything
looks
good
before
you
run
the
full
test.
A
This
is
about
to
be
updated,
to
be
combined
in
the
initial
start,
to
simplify
this,
so
that
you
can
actually
pass
the
configuration
file,
and
this
will
all
be
handled
now,
if
you
want
to
deploy
your
cnf
outside
of
this.
There
are
ways
to
do
that,
but
I'm
giving
you
a
walkthrough
of
the
simplest
path.
If
you
have
a
helm,
deployable,
cnf.
A
A
You
would
pass
this
and
skip
the
last
step
for
setup
and
you
will
actually
pass
the
configuration
file
and
then
it
will
get
everything
set
up
and
run
all
the
different
tests
and
it'll
give
you
the
output
of
either
it's
passed
or
failed
for
every
test
on
workload,
we're
going
to
see
something
similar
for
platform
type
test
and
then,
when
that's
complete,
you're
going
to
have
some
type
of
score.
These
are.
This
is
just
an
example
down
here
and
I
the
scores
are,
the
points
are
much
can
be
much
higher.
A
They
could
be
different
things,
but
you'll
have
some
score
and
then,
if
I
can
get
my
screen
to
the
little
slide
thing
so
that
the
next
part
after
that
is
everything
is
saved
to
a
an
external
file.
So
you
have
all
the
results,
as
well
as
additional
information
in
the
results.
File.
Final
score
scores
for
every
test
and
you
can
use
that
as
input
for
whatever
you
want.
You
can
read
it
directly.
It's
a
yaml
file,
that's
readable!
A
You
could
also
use
it
to
pull
in
and
display
in
some
fashion
or
potentially
integrate
with
some
other
test.
That's
doing
things
beyond
what
the
cnf
conformance
is
so
a
little
bit
more
about
the
the
scoring
itself.
A
So
all
of
the
tests
inside
have
individual
pass
fail.
Those
are
binary,
past
cells
and
then
those
roll
up
into
scoring
that
we
can
say,
give
some
type
of
range
and
then
eventually
all
of
that
goes
up
to
the
final
sum
for
all
of
those
individual
and
group
scores
so
that
you
have
this
final
score
of
the
total
maximum
points
you
could
have
had
and
for
the
say,
the
most
cloud
native
that
could
be
the
full
pass
gold
type
standard
and
then
what
score
did
you
get?
A
To
get
negative
points
and
so
on,
so
we
or
you
can
get
positive
points,
so
we
have
that
capability.
This
is
a
eml
configuration
file
for
the
scoring
it
can
it
maps
to
each
of
the
tests.
A
You
can
say
whether
something
is
required,
and
ideally
we
get
input
from
operators
and
and
cnf
developers
saying
what
what
they
think
is
important,
and
then
we
can
start
putting
more
adjusting
the
points
to
to
meet
something.
Of
course
someone
could
take
this
and
if,
if
you
said
maybe
a
particular
operator
says
we
really
care
about
one
test,
even
though
no
one
else
does
so
we're
going
to
make
it
required.
That's
totally
fine
as
well.
It's
fully
configurable.
A
We've
you've
been
using
the
cnf
testbed
framework
for
deploying
clusters,
the
platform
itself
to
packet,
so
bare
metal
and
setting
up
networks
on
the
fly,
and
so
there's
collaboration
at
that
level.
There's
collaboration
around
the
certification
with
rc2
and
and
then
those
gap
analysis
that
we're
doing
with
the
requirements
like
that
spreadsheet.
A
A
I'm
open
for
questions
here
just
showing
this
slide
for
those
who
haven't
seen
it.
There
is
a
cnf
conformance,
and
I've
mentioned
cnf
testbed
channel
as
well
as
this
tug
slack
on
this
is
the
cncf
slack
and,
if
you're
interested,
please
join
that.
A
So
beyond
this
and
I'm
happy
to,
if
anyone
has
any
questions
and
you're
muted,
please
ask
I
do
want
to
point
out
that
we
are
getting
started
on
beta
testing
and,
if
you're
interested
in
being
a
beta
tester,
then
here's
a
google
form
and
submit
this.
What
we're
looking
at
right
now
is
testing
specifically
on
the
workload
test,
but
one
of
the
biggest
focus
that's
going
to
help
with
platform,
and
everything
is
feedback
on
setup
and
installation
for
usage
of
the
suite
for
getting
the
feedback
from
the
suite.
A
All
right
are
there
any
questions,
otherwise
I'll
hand
it
over.
I
know
that
we
only
have
10
minutes,
hopefully
frederick
you
can
get
some
men.
E
Sure
so
I'll
make
this
quick,
and
we
may
need
to
continue
the
discussion
at
a
later
time.
In
terms
of
the
the
context
to
repeat
it
again,
one
of
the
things
that
we
discovered
when
we
were
working
on
ovp
phase
two
this
morning
was
that
there
may
be
a
a
gap
that
needs
to
be
filled
in
terms
of
in
terms
of.
E
Of
of
cms,
and
so
what
so
obp
phase
two
itself
is:
it's
primarily
in
the
business
of
consuming
and
credentialing,
basically
through
verification
of
requirements,
but
they're
not
in
the
business
of
creating
requirements,
and
so
to
give
you
an
example,
when
you
look
at
something
like
how
do
you
install
a
cnf
like
a
lot
of
the
discussions
we've
had
around
cnfs
have
been
like:
do
they
do
they
meet
certain
requirements
in
terms
of
like
do
they
do
they
require
privileges?
E
How
can
they
can
they
scale
horizontally,
or
you
know,
happens
if
one
of
them
fails
or
so
on?
But
in
terms
of
I
don't
know,
if
there's
anything
that
covers,
how
do
you
actually
install
a
cnf
in
a
kubernetes
environment,
so
something
that's
a
little
bit
more
more
concrete,
it's
still
a
cnf,
even
if
it
doesn't
have
such
a
an
installer
is
my
is
my
understanding,
but
at
the
same
time
there's
when
it
comes
to
actually
credentialing
these
systems,
then
something
needs
to
be
defined
there.
F
E
Cnfs
and
if
not,
would
the
telecom
user
group
be
the
appropriate
place
to
host
such
requirements
so
that
groups
like
ovp
phase
two
can
then
consume
them?
So
that's
that
that
that's
the
that's
the
question.
F
It
also
I
came
late,
so
I
apologize
and
this
might
have
been
covered
in
the
initial
parts,
and
this
is
definitely
out
of
the
scope
of
what
was
being
shown
for
mvp,
but
I'm
kind
of
just
building
upon
what
frederick
said.
What
about
like.
You
know
conformance
stacks
themselves,
so,
like
one
of
the
issues
I'm
running
into-
and
I
look
at
like
deploying
5g
in
containers-
is
vendors
either
want
to
bring
their
own
stack
so
they
can
control
the
kpis
and
slash
or
they
want
some.
F
You
know
really
really
deep
discussions
on
lines
of
demarcation
between
where
it
is
like
support
in
for
their
app
versus
the
platform
etc.
You
know
they
typically
have
strong
opinions
on
what
the
infrastructure
looks
like
so
would
this
eventually
grow
and
evolve
to
where
you
know
beyond
just
a
reference
architecture,
we
have
a
conformant
architecture
like
here's,
the
key
kpis
you
have
to
meet
within
your
kubernetes
stack
and
then
you
could
take
that
to
a
vendor
and
say:
look
I
have
a
conformance
stack.
C
Jeff
that
ladder
vision
is
very
much
what
we're
trying
to
do
here,
and
so
our
expectation
is
that
if
you
are
a
telcom
operator
and
you
are
running
a
conformant
stack
and
that
can
be
a
commercially
provided
one
by
a
number
of
vendors
or
the
vanilla
upstream
version
or
your
own,
you
know
modified
version
of
the
vanilla
upstream,
but
that
you
can
demonstrate
that
it
passes
our
conformance
and
you
have
a
cnf
that
you
that
also
passes
conformance
that
those
two
things
should
run
together
and
that
if
they
don't
it
is
a
bug
that
maybe
there
is
some
interface,
that's
not
included
in
in
the
conformance
test.
C
Maybe
it's
a
process
that
we
need
to
improve
and
change
and
such,
but
my
perspective
at
least,
is
that
that's
the
whole
thing
we're
doing
here
that
if
we
don't
actually
live
up
to
that
expectation
that
we've
just
wasted
years
of
effort-
and
unfortunately
I
mean
I
do
want
to
be
crystal
clear-
that
your
concern
is
not
an
academic
one.
C
It
is
very
much
the
case
that
in
principle,
these
standards
have
enabled
interoperability
and,
in
reality,
tons
of
operators
have
found
that
they've
needed
to
take
both
their
network
functions
and
their
platform
from
the
same
vendor.
In
order
to
actually
have
it
work
well,
together,
exactly.
F
F
You
know
the
management
plan
that
frederick
was
just
bringing
up
right
like
there's
all
these
like
real
world
things
that
we
don't
capture
when
we're
talking
at
the
10
000
foot
view
on
actually
making
this
stuff
work,
and
you
know
I'm
trying
to
not
relive
2010
when
I
try
to
put
these
things
in
my
network.
If
you
get
my
get
my
dress.
C
Yeah,
so
I
think
those
kinds
of
real
world
conversations
are
exactly
the
the
things
that
we
would
love
to
do,
and
so
even
just
opening
up
an
issue
to
describe
them.
Some
of
them
in
this
cnf
conformance
github
would
be
a
place.
To
start,
I
mean
storage,
as
is
often
the
case,
is
sort
of
a
special
case.
The
kubernetes
absolutely
does
have
this
csi
api,
that
that
does
provide
some
level
of
abstraction,
but
I
think
we
could
agree.
C
It
provides
less
abstraction
or
allows
more
of
the
details
to
kind
of
filter
through
than
some
of
the
other
apis
like
like
cni
or
sport,
or
the
cri.
But
cni
is
another
good
example
of
that,
where
cnfs
are
going
to
need
a
way
of
being
able
to
say
that
the
network
interface
needs
to
provide
at
least
these
capabilities.
But
if,
if
they
just
say
yeah,
I
can
only
work
with
with
a
cni
from
acme
corporation
and
that
cni
has
to
be
the
only
cni
running
in
the
on
the
platform.
C
Then
the
vendor
has
just
succeeded
in
in
in
again
doing
a
completely
proprietary
vertical
stack
again.
So
the
the
expectation
here
is
that
we
need
to
be
defining
the
requirements
in
the
way
based
on
what
the
actual
requirements
are
about.
You
know
latency
or
qos
or
or
a
policy
or
other
kinds
of
functionality,
not
to
try
and
lock
people
in
to
a
single
vendor
solution.
E
I
was
going
to
ask,
but
would
opening
up
these
type
of
questions
in
the
in
the
cnf
conformance
github
issues
be
the
right
to
be
the
right
place
and
we
can
start
discussing
things
like
like
installers
and
other
and
other
similar
type
of
concerns
that
are
on
the
manager
of
thing.
C
I
think
that's
probably
a
good
place,
and
then
we
can
certainly
move
them
to
the
mailing
list
or
slack
if,
if
we
won't
find
out
having
more
general
issues
or
just
have,
the
next
call,
for
example,
focused
on
that.
F
Okay
makes
sense:
hey
taylor.
Do
you
want
us
to
like
put
any
metadata
when
we
open
up
an
issue,
because
what
I
don't
want
to
do
is
take
away
from
all
the
fantastic
work,
that's
being
done
for
the
mvp
and
like
delay,
progress,
you
know
chasing
a
bunch
of
rabbits
down
random
holes.
Do
you
do
you
want
us
to
kind
of
like
put
something
in
so
that
way
we
can
kind
of
like
categorize
these
types
of
things,
and
so
that
we're
not
taking
away
from
the
work.
That's
being
done
right
now,.
A
Yeah,
that's
that's
a
good
idea
and
there
are
there's
multiple
projects
on
the
cnf
conformance
so
having
stuff
associated
with
maybe
a
project,
that's
more
about
ideas
would
work
and
labeling
them.
So
we've
started
doing
that
for
some
of
the
upcoming
things
like
the
beta
testing
and
bugs
and
other
stuff
to
separate
it.
A
There
was
a
comment
earlier
that
this
these
set
of
questions
should
be
part
of
what
the
telecom
user
group
is
discussing.
I
think
that's
true,
so
if
we
say
as
a
user
group
as
a
group
developers
and
operators,
what
are
the
different
things
that
we
care
about?
Yes
and
then
what
initiative
should
work
on
it?
That's
what's
in
scope,
I
think
that
needs
to
be
defined
and
from
my
my
view
would
be
to
not
have
one
particular
one.
A
D
And
I
think
to
comment
to
echo
taylor's
point:
we
need
to
be
very
careful
when
we
think
when
we
set
requirements,
for
I
think
you
mentioned
jeff
demarcation
point
between
what
the
application
provides
and
what
the
infrastructure
provides,
and
certainly
within
the
cntt
there's
a
lot
of
effort
going
around
trying
to
define
what
is
responsibility
from
the
infrastructure.
D
What
would
be
the
demarcation
point
for
the
application
now
now
there
are
some
requirements,
some
areas
where
cnt
are
covering,
but
there
are
some
areas
which
frederick
mentioned
to
when
it
comes,
for
example,
the.
How
do
you
actually
deploy
the
the
cnf?
E
Would
that
change
anything
in
kubernetes
core
itself
and
I
sort
of
think
of
cnt
being
similar
if
helm
were
to
disappear,
then
what
what
would
change-
and
I
think
the
answer
would
be
from
the
cmtp
perspective-
nothing
but
from
the
cnf
management
and
life
cycle.
A
lot
could
change.
E
So
we
need
to
make
sure
that
we
capture
those
those
type
of
requirements
somewhere
also
to
to
help
mitigate
the
risk
in
the
future
when
help
changes
when
newer
technologies
come
out
so
that
we
can
give,
we
can
give
guidance
as
as
things
progress
forward,
because
this
is
still
a
fast
moving
space.
So
we
need
to
make
sure
that
we
have
a
handle
on
this
stuff.
A
I'm
going
to
bring
up
an
example,
that's
non-helm
for
those
who
haven't
seen
it
you'll,
probably
seen
it
so
this
this
red
hat
project
turnadot
it's
trying
to
do
something
that
somewhat
overlaps
with
helm,
but
not
completely
using
tosca
and
to
build
on
what
you're
saying
frederick,
define
what
I
would
say
is
defining
the
requirements
that
we
care
about
on.
The
workload
is
more
important
than
saying
what
a
specific
implementation
is
so
orchestrating
and
composing
workloads
and,
and
then
that
sounds
good
and
then
do
we
want
it
to
be
declarative.
A
I
think
we
do
a
declarative
type
of
language.
You
want
policy
based
service
composition,
I'm
taking
this
from
right
here,
but
a
lot
of
this
you
could
put
in
any
other
tool.
So
we
can
come
up
with
the
different
names
that
we
care
about.
Then
we
can
look
at
what
tools
are
out
there
that
implement
those
we're
already
doing
that
from
the
platform
side.
A
So
if
we
did
it
from
the
life
cycle
management
of
the
cns,
if
we
do
the
same
sort
of
thing,
then
we'll
be
able
to
go
beyond
whatever
tooling
is
here
now
to
what
may
come
in
the
future
and-
and
it
doesn't
lock
us
in
if,
if
there's
new
requirements,
that
an
operator
wants
that
some
other
tool
has
and
it
covers
everything.
A
So
I
think
that
that
could
tie
in
and
that
would
help
with
scope
as
well
and
in
the
end.
What
we
have
is
that
on
the
cnf
conformance,
what
we
care
about
is
requirements
that
that
we
want
to
check
for
on
any
implementation
and
most
of
the
time
that
shouldn't
be
checking
that
a
specific
tool
is
there
but
saying
that
where
application
is
being
used,
but
instead,
how
does
the
application
behave
and
that
way
an
operator
could
pick
and
choose
from
the
vendors
any
vendor
that
follows
those
standards
and
meet
those
standards.
A
A
All
right,
we
are
over
time
if
we
want
to
carry
on
this.
This
conversation,
the
slack
cncf
slack
for
tug
as
well
cnf
conformance,
will
be
one
way
if
you
want
some
type
of
live,
chats
reach
out
jeffrey.
A
Reminder
next
month's
meeting
is
going
to
be
at
11
utc,
which
is
7
pm
7
pm
china
standard
time.