►
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
Birds of a Feather: Telecom User Group - Cheryl Hung, Dan Kohn, Cloud Native Computing Foundation; & Taylor Carpenter, Vulk Coop
CNCF hosts the Telecom User Group (TUG) for service providers and their vendors to discuss the adoption of cloud native technologies. The community is invited to join this birds-of-a-feather (BoF) session to discuss the status of various initiatives and white papers in this space as well as ideas, requirements and best practices to continue moving forward.
https://sched.co/Uakt
A
A
Maybe
five
minutes
on
the
CNF
test
bed,
mainly
for
the
folks
who
haven't
seen
this
stuff
before
and
then
we
can
answer
some
questions
and
talk
about
it
and
because
you've
come
to
this
event,
we
will
go
ahead
and
let
you
in
on
the
super
secret,
deep
dive
event
which
is
occurring
later
this
afternoon.
In
fact,
an
hour
from
now
which
you
can
only
know
about.
A
The
initial
focus
of
our
organization
was
around
enterprises
and
having
them
shift
more
typical
workloads,
in
fact,
that
almost
everybody
starts
with
they're
stateless
workloads
and
are
now
maybe
looking
at
their
stateful
workloads
and
in
the
last
year,
a
year
and
a
half
we've
begun
to
focus
on
additional
vertical
industries.
So
we
have
a
financial
services
user
group
we're
beginning
to
look
at
an
automotive.
We
have
three
automotive
companies.
So
far
we
have
a
research
user
group
and
we
created
this
fourth
one,
the
telecom
user,
because
we
see
so
much
market
opportunity
and
interest
here.
A
Here
is
our
not
up-to-date,
Platinum
members,
which
does
not
show
our
three
new
palo
alto
networks
arm
and
NetApp
that
we're
very
happy
upgraded,
and
this
one
is
correct,
not
quite,
but
we're
gonna
have
likely
a
meeting
on
this.
That's
now
been
renamed
the
Linux
Foundation
member
summit
in
Lake
Tahoe
for
any
Linux,
Foundation,
member
or
CN
CF
member,
and
then
we'll
certainly
be
having
meetings
in
Amsterdam.
The
other
one
that's
missing
here
is
that
we
are
gonna,
have
a
booth
at
Mobile,
World
Congress
in
Barcelona,
and
are
gonna
be
actively
looking
for
edit
demo.
A
A
Helm
is
a
package
manager
for
a
way
of
deploying
things
customized
as
an
alternative
to
that
on
voice
extremely
widely
used
service
proxy.
The
CNF
testbed
tailors
can
tell
us
about
a
second.
The
open
policy
agent
has
a
lot
of
interest
as
a
way
of
being
able
to
set
policy
cluster
wide
and
permitting
and
or
denying
certain
activities.
A
Observability
is
really
key
to
all
of
cloud
native,
and
we
saw
keynote
this
morning
on
open
till
tree
Prometheus
for
monitoring
fluency
for
logging
Jaeger
as
a
tracing
tool
that
just
graduated
a
lot
of
interest
in
service
meshes.
Linker
D,
which
is
a
CNC
F
project,
is
steel,
which
is
not
a
network
service
mesh,
which
is
a
sandbox
project,
but
Frederick
and
no
yeah
there
is,
can
waive
his
arm
there
as
one
of
the
maintainer
x'
that
there's
a
lot
of
interest
in
from
telcos
operators
a
huge
amount
of
interest.
A
This
is
the
idea
that,
when
you
have
an
application
in
your
cluster,
you
create
a
custom
resource
definition
that
includes
a
lot
of
intelligence
about
how
that
application
should
run
so
the
ability
to
update
it
to
configure
it
on
something
like
MySQL,
the
idea
of
being
able
to
vacuum
it,
and
it's
essentially
taking
the
run
book
that
you
that
people
would
would
create
for
an
application
in
instead
encoding
it
in
software.
And
so
the
aspiration
is
to
move
the
entire
software.
A
The
entire
database
administrator
that
you
would
have
had
before
into
software
and
so
there's
a
couple
proposals
operator
framework
out
of
Red,
Hat
Kudo
out
of
d2
IQ
that
are
being
proposed
to
CN
CF
and
that
are
likely
to
move
forward
since
the
kubernetes
community
has
an
IOT
edge
working
group
and
then
there's
a
link
here
to
using
kubernetes
and
from
as
an
inventory
manager.
So
these
are
just
a
few
I
believe
these
are
most
of
the
upstream
projects
and
and
touch
points
that
we
expect
to
follow.
A
So
the
first
thing,
so
the
work
items
that
we're
focused
on
right
now
are
some
white
papers
and
the
CNF
test.
Bed-
and
this
is
I-
have
a
slightly
newer
version
of
it.
But
is
the
idea
of
saying
that
there
are
set
of
virtual
network
functions,
that
our
virtual
machines
that
today
normally
run
on
OpenStack
and
that
a
lot
of
operators
have
expressed
interest
and
having
those
my
grade
to
become
cloud
native
network
functions
or
CN
apps
running
on
top
of
kubernetes
and
then
having
the
opportunity
to
run.
A
This
is
a
quote
from
brian
grant,
who
was
on
stage
yesterday
for
having
kicked
off
the
crew
Bernays
bootstrap
committee,
the
Cougar
days
architecture
can
be
ascribed
as
an
unbounded
number
of
independent
East
synchronous
control,
loops
reading
and
writing
from
to
a
schema,
Ty's
resource
store
as
the
source
of
truth.
This
model
is
proven
to
be
very
resilient,
available
and
extensible.
A
So
it's
not
perfectly
plain
English,
but
there
is
an
image
there
of
not
having
a
single
loop,
but
many
many
loops
that
are
comparing
their
idealized
state
with
the
actual
state
and
then
figuring
out
what
changes
they
need
to
make
and
continue
to
go
through
it,
and
it
is
fundamentally
a
different
architecture,
a
different
approach
than
the
more
sort
of
caps,
chef,
ansible,
puppet
salt
and
older
clay.
It's
a
declarative
approach,
as
opposed
to
a
procedural
one.
Ok,
so
then
I
really
want
to
emphasize
this
concept
of
evolution.
A
There
is
absolutely
no
possibility
of
a
cleanroom
rewrite
from
a
vnf
architecture
to
a
CNF
architecture.
Everyone
in
production
is
going
to
slowly
migrate
from
an
older
to
a
newer
architecture,
and
so
in
order
for
that
to
be
feasible
at
each
step
along
the
way,
they
need
to
see
a
meaningful
benefit
from
having
done
a
change,
and
this
is
the
only
way
that
change
ever
happens.
So,
there's
already
been
migration
from
physical
network
functions
to
virtual
network
functions.
We
need
to
be
able
to
show
how
running
a
small
portion
of
your
network
generally.
A
The
stateless
applications
first
on
top
of
kubernetes
gives
a
bunch
of
advantages
in
terms
of
resiliency,
faster
development,
better
bin
bin,
packing
being
able
to
run
on
a
smaller
number
of
machines
and
then
continue
along
those
lines,
and
this
is
exactly
the
same.
It
extremely
similar
value
proposition
to
what
enterprises
have
been
going
through.
The
other
idea
that
I
want
to
share
with
you-
and
we
are
looking
to
write
this
up
in
a
white
paper-
is
up
what
we
call
bronze
CNF
sand.
A
These
have
been
suggested
that
copper
or
bra
or
some
other
metal-
that
is
much
less
appealing
rust,
has
been
suggested
to
me.
But
the
scenario
is
that
your
firewall
vendor
and
a
legacy
firewall
vendor
and
you
used
to
sell
a
box
that
people
would
plug
in.
It
would
be
a
firewall
and
then
your
customer
said.
Well,
we
don't
want
to
buy
your
box
anymore.
We
want
you
to
just
sell
us
the
software
and
we'll
run
it
on
our
own
servers
in
our
own
racks.
A
So
you
took
all
of
your
software
that
both
user
layer
and
probably
a
ton
of
hacks
on
top
of
Linux
and
packaged
up
as
a
virtual
machine-
and
you
said:
okay,
here's
your
vnf!
Now
your
customer,
the
the
operators
come
back
to
you
and
say
we
don't
want
a
vnf
anymore.
Now
we
want
a
CNF,
a
cloud
native
network
function,
so
that
means
that
you
can
no
longer
do
any
kind
of
kernel,
hacks
or
kernel
Mollet
modules
or
patches
or
otherwise.
A
You
need
to
move
everything
up
into
user
space
and
rely
on
the
fact
that
the
Linux
kernel
is
going
to
be
3
out
of
10
or
higher
to
support
docker
container
D.
But
you
can't
do
it,
but
you
you
now,
but
everything
else
can
still
just
be
a
lift
and
shift
over,
and
if
you
do
that
in
sort
of
the
most
stubborn
way
possible,
you
can
wind
up
with
a
piece
of
software
that
is
not
in
any
way
better.
So
suboptimal
patterns
such
as
a
continued
reliance
on
a
proprietary
management
interface.
A
So
we
do
need
to
have
a
name
for
this,
but
it
is
a
name
in
order
to
avoid
it,
then
you
can
imagine
what
a
gold
CNF
would
look
like,
which
is
trying
to
follow
best
practices
on
a
bunch
of
different
axes,
so
the
first
one
would
be-
and
this
is
in
that
firewall
vendor
scenario-
we've
rewritten,
a
bunch
of
our
software.
So
it's
still
our
software.
It's
still
proprietary.
A
It
still
has
a
legacy
to
it,
but
we're
now
trying
to
take
advantage
of
the
best
practices
of
a
cloud
native
architecture,
so
it
is
compatible
with
any
certified
kubernetes
implementation
out
there.
As
long
as
the
network
supports
what
we
need
its
stateless,
so
it
can
to
the
degree
it
needs
state,
it
can
use
an
external
database
or
get
it
from
config,
Maps
or
environment
variable,
but
the
application
itself
should
ideally
be
stateless
security.
It
runs
unprivileged
a
very
important
piece.
It
should
support
both
horizontal
scaling
into
multiple
machines.
A
Vertical
scaling
into
smaller,
bigger
machines
configuration
life
cycle.
It
should
us
have
best
practices
for
observability,
of
using
open
metrics
to
support
things
like
Prometheus
and
open
telemetry
for
tracing
and
fluency
for
logging,
fluency,
plug-in,
install
bone
upgradeable
and
the
great
needs
custom
hardware.
It
should
define
that
with
the
device
plug-in,
so
that's
sort
of
the
best
case,
but
we
do
need
to
be
realistic
about
the
fact
that
it
is
real
work
to
evolve
current
production
software
to
support
this.
A
So
in
some
ways
the
most
interesting
question
would
be
the
definition
of
a
silver
CNF,
which
is
what's
good
enough
and
we
don't
consider
it
our
job
really
to
try
and
define
what
that
silver
CNF
will
be.
We
we
are.
Our
expectation
is
that
we
will
be
working
with
the
operators
and
with
a
bunch
of
vendors
and
there'll,
be
some
negotiations
here
and,
and
maybe
there'll
be
a
whole
set
of
constraints
or
points
or
other
kinds
of
things.
But
the
idea
is
on
each
of
those
metrics.
A
It
will
have
a
big
impact,
so
I'm
going
to
skip
past
that
part
and
ask
Taylor
to
just
talk
for
a
few
minutes
about
the
CNF
testbed
and
maybe
as
well
on
what
some
of
your
aspirations
are
over
the
next
few
months
on
it.
Did
you
want
me
to
pop
up
a
different
slide
deck,
or
is
this
one?
Okay,
great
and
I
will
hand
it
off
to
you,
and
then
we
can
just
move
to
two
questions
after
this
and
if
you
can
also
share
the
where
the
scenes
all
right.
B
B
B
So
what
have
we
not
gone
over
open
source
initiative
from
CN
CF,
and
this
did
start
before
the
telecom
user
group,
but
it's
the
ideas
and
the
telco
music
Reaper
encompass
the
same
sort
of
goals
that
the
CNF
testbed
hat
and
now
it's
direct
collaboration
and
I.
Think
that
bullet
point
three
there's
one
of
the
main
things
at
so
the
telecom
user
group
is
helping
to
discuss
the
needs
problem
statements.
What
is
the
technology?
B
What
are
all
these
principles
and
and
from
that
you
can
start
looking
at
capabilities
and
benefits
at
some
point
you
want
to
try
things
out
and
specifically,
when
you're
looking
at
the
the
things
that
are
more
on
the
leading
edge
of
the
innovation,
then
being
able
to
try,
multiple
things
out
is
a
pretty
important.
Does
it
match
those
capabilities
and
specifications
that
we're
talking
about?
B
So
the
idea
is
an
exploratory
kind
of
development
environment
and
making
sure
that
early
adopters
of
those
can
try
it
out,
but
also
any
type
of
learnings
and
ideas
that
come
out
of
this.
It
seemed
solid,
then
maybe
they
can
be
fed
fed
out
into
potentially
like
certifications
like
this
gold
silver
bronze.
Maybe
they
go
into
another
testing
platform,
that's
very
specific
and
trying
to
meet
current
goals,
and
that's
the
idea
there.
B
We
also
want
to
make
sure
everything
is
very
reproducible,
but
specifically,
reproducible
outside
of
a
closed
lab.
So
we
chose
to
work
with
packet
which
has
bare
metal,
and
you
can
do
Bethan
demand
reserved
even
customized
hardware,
but
all
available
similar
to
cloud
platform
with
some
other
configurability.
B
We've
had
quite
a
few
contributors
over
the
past
year.
Here's
some
of
them-
and
these
are
from
many
different
projects,
including
FD
IOC
set,
which
does
testing
for
VPP
releases
and
some
of
the
other
related
software
network
service
mesh.
Folks,
some
OpenStack
people
as
well
have
been
contributing,
especially
around
the
VM
side.
B
B
B
We
definitely
encourage
both
issues
for
anything
that
you
find
specifications
but
as
well
as
pull
requests.
So,
if
you
wanted
to
add
support
for
we
have
AWS
bare
metal
or
some
other
provider
would
be.
We
just
see
that
and
use
cases
as
well,
so
we
have
a
spec
board
and
as
well
as
the
issues
with
it,
we're
currently
working
on
to
implement
and
the
spec
board
it's
kind
of
an
area
to
brainstorm
on
something.
B
So,
if
we're
not
quite
sure
that
we've
broken
down
a
use
case
or
user
scenario,
small
enough
to
know
that
we
can
implement
that,
do
we
have
all
the
pieces,
that's
a
good
place
to
start
and
then,
if
there's
anything,
we're
whether
the
deployment
on
kubernetes
or
OpenStack
the
infrastructure
to
improve
that
then
definitely
want
PRS
there
and
we
attend
the
telecom
user
group.
Were
part
of
this
were
involved
in
several
other
groups.
There's
a
couple
of
channels,
including
CNF
testbed,
we're
on
you
can
also
reach
us
via
the
gap.
B
So
we
did
start
I,
guess
back
in
2018
and
what
we
were
looking
at
first
was
actually
own
app.
How
do
we
take
some
of
what
was
the
own
app
demo?
If
that's
a
repo
that
has
a
lot
of
different
use?
Cases
like
a
vcp
use
case
and
different
network
functions
and
those
at
the
time
were
they're
all
VM
based?
And
how
could
we
take
these
and
could
we
just
re,
implement?
What's
there
and
use
own
app
and
all
the
different
parts
and
re-implemented
version
of
it
on
kubernetes
and
kind
of
went
down
that
path?
B
Segoe,
which
started
with
the
bearer
boxes
that
we
started
being
able
to
put
together
these
pieces
build
service
chains.
We
ended
up
as
one
of
the
screens
that
Dan
had
up
earlier
was
some
benchmarking
and
working
with
FDIC
sit.
We
wanted
to
have
baseline
testing
of
the
hardware.
They
have
a
lot
of
testing
for
the
hardware
at
Linux,
Foundation
labs
and
trying
to
verify
that
on
packet.
B
How
can
we
add
these
in
so
one
of
the
things
with
these
goals
is
we
want
to
use
different
technologies,
but
we
also
want
to
support
as
much
as
possible
upstream
so
be
able
to
follow
those
without
saying
that
someone
has
to
learn
every
single
project
if
you're
exploring.
So
how
do
we
do
this,
and
this
is
part
of
the
last
six
to
eight
months-
restructuring
that
we've
done
I'm
going
to
kind
of
skip
forward
here
time?
B
So
what
we
were
looking
at
was
we
want
to
be
able
to
use
more
in-band
components
and
I'm
going
to
talk
about
the
kubernetes
side
here
so
rather
than
using
what
we
had
was
ansible
and
a
lot
of
out
abandoned
components.
We
wanted
to
move
more
of
that
into
either
using
helm
directly
using
upstream
stuff.
B
So
that's
been
a
lot
of
the
effort
and
over
the
last
month
or
two
especially
moving
that
stuff
in
in
place,
we've
been
able
to
add
several.
In
a
simius
cases,
we
have
some
tickets
for
doing
dan
m
and
we
have
sr
v
until
device.
Plugin
example
in
the
last
week
and
a
half
we've
actually
added
a
Malta's
plus
the
device,
plugin
example
and
we're
going
to
continue
adding
these
some
of
them
are
based
on
manifest
and
and
other
pretty
simple
UML
that
you
could
use
cube
kettle.
B
Some
of
them
are
using
helm,
it's
a
mixture
there.
Some
of
them
would
be
full
use
cases
where
you
could
look
at
multiple
containers
that
are
trying
to
exhibit
some
type
of
user
scenario
and
others
are
simpler
examples.
The
idea,
though,
is
they're
all
building
blocks.
So
if,
if
someone's
trying
to
look
at
one
piece,
they
can
see
how
that
fits
together
and
how
you
can
add
them
to
make
more
complex
use
cases.
B
This
select
the
read
map
for
where
we're
going.
We
like
I,
said
we're
gonna
be
using
adding
Dan
M.
The
multi-sexual
II
probably
shift
this
because
we
have
it,
but
what
we
don't
have
is
a
CPU
manager
we'd
like
to
do
that
for
some
isolation
on
CP
course
we're
looking
at
a
collaboration
to
do
a
5g
use
case
with
NS
m
and
potentially
we'll
see.
This
would
be.
B
B
B
Now,
that's
a
good
one,
so
the
santi
tag
meeting
is
still
over
in
the
convention
center.
Let's
see
the
the
the
room
did
not
change,
but
the
time
changed
so
meeting
room.
Two,
that's
the
upper
floor
and
it's
now
4:30
instead
of
4.4,
so
we
actually
have
time
to
get
over
there
for
folks
that
are
going
any
questions.